Re: [gentoo-dev] Package up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On May 28, 2016 5:41:40 AM PDT, rindeal wrote: >On 28 May 2016 at 11:14, Pacho Ramos wrote: >> Markos is not having much time to handle his packages and, then, he >> would like to get other people involved in them. The idea is to keep >> him in metadata as co-maintainer but, please, don't hesitate to add >> yourself if wanted: >> app-admin/verynice >> app-crypt/zuluCrypt >> dev-cpp/luabind >> dev-libs/angelscript >> dev-libs/libntru >> dev-libs/libuv >> dev-lua/luvit >> dev-python/pathtools >> dev-python/pygame_sdl2 >> dev-python/pyuv >> dev-python/watchdog >> dev-vcs/git-imerge >> media-gfx/pornview >> media-sound/pnmixer >> net-firewall/pglinux >> net-im/bitlbee-steam >> net-im/purple-events >> net-misc/connman-gtk >> net-misc/connman-ui >> net-p2p/pybitmessage >> sci-geosciences/cdat-lite >> sci-geosciences/congen >> sci-geosciences/tcd-utils >> sci-libs/libspatialindex >> www-apps/hiawatha-monitor >> www-servers/hiawatha >> x11-plugins/hexchat-javascript >> x11-plugins/pidgin-birthday-reminder >> x11-plugins/purple-libnotify-plus >> x11-terms/terra >> x11-themes/geany-themes >> > >You've posted it here a week ago and already received responses, why >are you posting it again? Unchanged? I don't remember seeing the explanation regarding Markos and asking that people keep him as a co-maint. I'm on my phone right now though so I could be mistaken. - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAldJvZYACgkQASQOlFA54XD7XQ//Rsuz0Klivf8o/nAw JbpDs6vuvk0hKBGUy94kTDA8w2h+T8OFqHOer6qaDtmWFGTJKWTkAJoS0M1VtpjR LAkw2TLdpSfgVUTV+bsDiDyCVNk1lxag/oU6rY7N0fFUxvhTn1ran2jkchWJMF5q vs8LN/Cyv8Dxq8IUL9zDMdlw76EuP5Ktw/HBJkSaloZkqPPlLFJka2g5azaAJkez tV6LWv+/gt+B+XMo2ZJ3+dNfm46dB1ye5R9hIxi0vvVhfuIEpcSloCpJrGmUBfiV Qqe/Ik89evri2GWVTKDDqV54BDnrFluG6gqtmwgEgIid7Lb+lF++LACrD8MIOlOX W/m8F3TS/qW7mHE4imrXWwjWVwqhvJKVkXbnUtd0YKSD1ocRPcnQifQSXrH3GvLK b2FXqtpwhl0OrU2y/yR1T/xECefvbzxZXtafZKDpGgvLL2az6tAv5rdd7ZVH n/43zDQH8MM6656aOqby9xzncRl5Twm3G59JygrTmBt6Y5jwcY8/kW8+erd642S4 4JdOdVMUes6p9Osd2N+otfVEE6oEHKXZmueWstz6VgIIOT9x1rbI3p70MTBWANwT XKJS1e9VOpEzp9ccKZA8lsU8uSZWmNmt62Zf0rrnuDD9KTN4vOUZLrlNQ/S2drEf Gq1NwMncjsSotwvWw7BOluyeMMQ= =/9ya -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Global USE=gui
On June 1, 2016 7:29:55 AM PDT, Mart Raudsepp wrote: >Hello, > >So here's something more simple wrt GUI USE flags. > >Global USE=gui for >gui - enable an optional graphics user interface or extra GUI tool > >(wording improvements welcome, once it's in principle agreed; but no >point in bikeshed painting description wording till it is) > >Local USE flag description overrides to specify exactly what extra tool >is built and installed with the flag are encouraged. > > >This is meant to cover the cases where a package has an optional GUI, >as a user facing graphical application, whichever the toolkit. > >It is meant as a feature based USE flag, as opposed to the "extra dep" >based USE flags we've been using for this. >There are a lot of those with USE=gtk right now. In many cases it's >some little add-on graphical utility for a library, or some graphical >configuration GUI in addition to command line, or some bigger cases in >more modular packages that provide multiple frontends, and not all of >them are graphical, but CLI or TUI (TUI meaning ncurses-based or >similar). >Also there are various with USE=X where it's also about that, but X >isn't the only way to do GUI these days (any gtk3 app that doesn't >directly use libX11/libxcb/etc themselves natively supports wayland, >for example). > >Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead >of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is >available in only one toolkit version. So hence feature based flag, not >dependency-based. > >http://tinyurl.com/gtk-use was an old analysis of USE=gtk usage in tree >by Gilles over a year ago. That suggests that at least 80+ USE flags >should be then USE=gui instead of USE=gtk out of that analyzed USE=gtk >subset alone, not counting USE=X and others. > >There are some other things in the ideas pipeline for when there are >multiple toolkit choices, but that's something for a different thread, >a different day and more controversial. > > >Mart This idea is solid imo, but only in the case where there's a single (optional) GUI to use. We've discussed the finer points of this on IRC and, as you noted, the specifics need some more input and refinement, but in essence I like and support this idea. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On June 1, 2016 6:46:28 AM PDT, Mart Raudsepp wrote: >Ühel kenal päeval, K, 01.06.2016 kell 15:18, kirjutas Dirkjan Ochtman: >> On Wed, Jun 1, 2016 at 3:09 PM, Michał Górny >> wrote: >> > Excuse me but are you really serious? We are in this swamp because >> > someone tried to be too smart. And what solution do you propose? >> > Let's add another layer of complexity and smartness, for a single >> > variable. Obviously nothing can go wrong with this. >> >> Please stop the derogatory remarks and unnecessary cynicism. If you >> think some proposed solution is a bad idea, just explain why you >> think >> it's a bad idea. Not everyone has the same perspective as you on >> these >> things; nor are they likely to be converted to your stance by your >> scolding them. > > >+1 >Especially given the followup mail. >Really unprofessional. > >So lets have users set multiple variables for the same thing, so it's >done properly because users need to care about env variable intricacies >in package management deep guts. >That said, maybe indeed better to force them to set it twice, as >discussed in my followup mail. > > >Mart Unprofessional? We're volunteers. We're already bound by a CoC so there's no need to bring up a meaningless buzzword to describe behavior. I'm not defending Michal's tone (sorry, not sure how to add the slash to the glyph on my phone), but 'unprofessional' is hardly an accusation to be taken seriously here. "Snarky", "rude", "unconstructive"; *something* that's descriptive and meaningful would make your point clearer. - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAldPTnUACgkQASQOlFA54XBZOg/8CRPXRWvH+GSQN9xG JIybw5gNmDqfddmaHWTN4+8MzV8BEyeO2/n3NDfCV0awqgx2trdrBw8c1Us4JC2y 2PO6PWEsxIPWrUOI10VyF3nSFr7sPJuQcD6oOMpeUkzGSI7FjzsWuZ/BeBASAWDq F6Z/kqJVCD3pHLxqBKPd9oUeLOND5hDYkx9il9GWW+Bl1xIP2wZLf8nnI73Uqk70 vaklt1rpIeh+CDJu6ToAg/yohUb0vFvUi/TffqLVvXXTa/IJCyhDHPbjQvqOfkJx 3Xc+IQvddwO3R04MG2Ram43Q3QB90NZ3fBA5lpGZo4lS/yFxFrYnEC2tQHe0sHFB MGCJ642ly0pobbaFSkrXoXQl4NtSXSSPnab0OMo3XbHekDXcqwuRYYCQIzHljgND lAZtYtBGgIsqAzyyJA+JezQAkM6SRgh+CQomzJZU7vZ68HQiwnJRZksYKwdC7d9S W0ityGD6ECwFNV9+k+Oa2qoSEfGE2hF7fSIVh2HLReegdWKEajA6TyPpNrQ57mD5 0gFgqAi6F9r6vxUd7bTiWLu7aeJ94iWjr3eL+NbxPvqO/gIzggdyIWdGPYW76bgd /Je99P9Q4uGy23WPNJ2P1844SjqpFAB/F3I3YVBekyhMvsOxaGpd8JQDVr5Q+45C xTkvtwIPG/iImPgYOXkUvdWAB5U= =cZZa -END PGP SIGNATURE-
Re: [gentoo-dev] Repo mirror & CI project news: 'stable' gentoo branch, new repo stats, faster CI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On June 5, 2016 9:04:26 AM PDT, "Michał Górny" wrote: >Hello, everyone. > >I have the pleasure to announce that a few improvements have been >deployed by the Repository mirror & CI project today. > > >1. The mirror for 'gentoo' repository [1] now has a default 'stable' >branch. It is updated automatically by the gentoo-ci checker, >and therefore always contains the latest repository state that has been >confirmed 'green' by CI. While this is far from perfect, it's the first >step towards preventing major issues from being deployed on our users. > >If you are already using the mirror, you will need to either switch >branch manually, or re-add it. > > >2. The repository QA report [2] has been extended with some repository >statistics. In particular, the timestamp of the newest commit >and the number of valid (that is, those not dying in global scope) >ebuilds are reported. Additionally, the homepage link is now included >as well. > >This enables the Overlays team members to easily check which >repositories >are unmaintained and/or empty, and handle the issues more efficiently. >It can also be useful to users who want to figure out whether there's >a point in using a particular repository. > > >3. I've tried to optimize the logic used to run QA checks on >repositories, and I think I was able to even the load better. >Additionally, I've repacked the git repositories to get rid of huge >number of loose objects. > >As a result, CI now runs faster. The gentoo-ci runs are down from 10-12 >minutes to 7-8 minutes, and pull requests from 16-18 minutes to 9-14 >minutes. However, I don't have exact results yet as the server is still >busy removing old files ;-). > > >4. Finally, the mirroring code has been updated to correctly handle git >repositories for which 'master' is not the default branch. > > >Enjoy! > > >[1]:https://github.com/gentoo-mirror/gentoo >[2]:https://qa-reports.gentoo.org/output/repos/ Sounds like a big improvement. I'm not too familiar with CI, so forgive me if this is obvious: should overlays now use the 'stable' branch as their primary remote, so they can ensure that any breakage introduced is caused by their own overlay instead of a flub by us? If so, then I wonder if this will help indirectly improve overlay quality. Being able to say "as of X commit, the tree is in good shape" is a big deal imo. Thanks for working to make that happen. Is there anything other devs can do to assist your development, or do we stick to the usual 'if in doubt talk to QA'? - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAldUXhUACgkQASQOlFA54XC2HxAAx3HV3YbjfzEJg2FC 8QJus2qwU63+Agqr84R9X9zQMMUGqkRoFglNBg6slxdSzV3s/2SASYlj3ShGWLvR sYMgKXmDVvIZ/z5qaepIcmIz0pHc+NjITebZ+zq09IoH8uI2fFFNFibCNAwdz9X1 CWzj5q1i1D9LSaIU0Jmd9N21168V7jSViHx1HeRR/ECx8G0fvaC8mPxpiULmcdA2 ZWqzRfkXLeckNHfJsrQFQQR89WAa20IJSajTitkA9BejNZyMrnjALxFLx6reZ5W6 IK3KR2IaGgnjof5BfBoyX6q2MXT8psJZBusPeQvX1U8COfBFgpX1QfpDdEZzn1PF BQMOa2mqwHkk7dlL5VT5ue9towFCYpN/J0PJa8+bB+jmTXFgtHYPn50POEiyebyt il9+bieLs2jqGwIQBwhgwAwL6SXX0EcbyaW2Ja44A4z6e4kFAqgqifP2+C4g6l6Y Mz36uedDmviL1PWttAjsvROh4X6d1P3frWKdxnYYHdlYjFXig6pEZE87Hnxc3j0C wBGnYg5qUP8Q65MeLRzpPzBkxHJODgVEQP+sVM5f6Vs5RjAafApit/6SHgbzCqZH LB3MzYyReJOd/taCLfUgfBp0hnlOlSyuHT3sQmqjJpqPnwisoIEerWHJuUrp7Nn3 Fz19qALKqvESRV42YCz7Zy9Z+ig= =sgMj -END PGP SIGNATURE-
Re: [gentoo-dev] Need design help/input for eclean-kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On June 30, 2016 6:19:23 AM PDT, "Michał Górny" wrote:
>On Thu, 30 Jun 2016 05:55:42 -0700
>Daniel Campbell wrote:
>
>> On 06/30/2016 05:38 AM, Michał Górny wrote:
>> > Hello, everyone.
>> >
>> > Back in 2011 I started a project called eclean-kernel. The idea was
>> > pretty simple -- to have a tool that would clean the old kernels
>for
>> > me since their install is not controlled by the package manager.
>This
>> > little project of mine seems to have gained a lot of popularity.
>> >
>> > Sadly, over time a lot of people had trouble with it. Aside to
>minor
>> > Python problems, eclean-kernel proved too simple to handle
>multitude of
>> > user systems with varying /boot layouts. In fact, even I don't use
>it
>> > on all of my systems since it doesn't handle them properly.
>> >
>> > After being buried in another set of bug reports, I'd like to
>> > officially ask Gentoo developers and users for help. I think it's
>> > impossible to solve most of the bugs reported so far in the current
>> > program design. Therefore, I'd like to rewrite it in a more
>flexible
>> > manner.
>> >
>> > For this reason, I would like to ask you to provide me with
>> > different /boot layouts you may have, had or seen. Basically, the
>idea
>> > is to collect as many different layouts as necessary, and use that
>to
>> > design eclean-kernel in a way making it possible to easily
>configure it
>> > to handle proper variant -- or even possibly make it capable of
>> > autoconfiguration.
>> >
>> > So if you have some time, please reply to this thread with
>> > a specific /boot layout that you think needs to be handled, with
>> > as much helpful information as possible -- including possible
>> > distinctive features and pitfalls.
>> >
>> > Thanks in advance.
>> >
>> I'm not sure if this is the info you're looking for, but I'll give it
>a
>> shot:
>>
>> I have grub-static installed to /boot/. I like to organize my kernels
>> with the filenames as linux-${version}-gentoo-${buildno}. So my first
>> build of 4.5.0, for example, would be 'linux-4.5.0-gentoo-1'. It has
>all
>> the info I need for reference should something go awry.
>>
>> I have three symlinks: current, last, backup
>>
>> I wrote scripts that will update those symlinks for me, which makes
>the
>> process of kernel management pretty painless. Now that I'm thinking
>> about it, it could be simple in my case to simply clean any kernel
>that
>> wasn't linked to.
>>
>> My /boot/:
>>
>> grub
>> lost+found
>> backup -> linux-4.4.1-gentoo-2
>> boot
>
>What's 'boot' here? Is that relevant?
>
>> current -> linux-4.4.6-gentoo-1
>> initrd
>
>Is that a single initrd for all kernels?
>
>> last -> linux-4.4.1-gentoo-3
>> linux-4.4.1-gentoo-2
>> linux-4.4.1-gentoo-3
>> linux-4.4.6-gentoo-1
>
>And most importantly, how are all those files referenced in grub? I
>suspect you are using the symlinks in grub.conf but want to confirm.
'boot' is a symlink to '.'. Not really sure why it's there but if I remove it,
things break. Probably a minor misconfiguration.
Yes, the same initrd is used for all kernels. I use LUKS and LVM, so I need the
initrd to boot. I produced the initrd using genkernel and it's worked ever
since.
Yes, grub.conf indeed references the symlinks and never an explicit kernel path.
Sorry I wasn't clear in my first mail.
- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-BEGIN PGP SIGNATURE-
iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6
bGdAZ2VudG9vLm9yZz4FAld1m50ACgkQASQOlFA54XCEOg//W1uQNSgnGxu7OAUe
13gLTgDN3+DMolhB/peyNRW3MxMyYaIr3PiG3DscLF538wevyx6ANp4eOHrEsANg
bFoA4BR1rPeB55A5zcQg4rnZnD23EHPkg56MDq6mtnib1ewK09sK6XbhrEMQ+eKr
LnAAUgwvkJab2Dd1q/thi3fGaIdJ8OgFAQLWnW4frqyIM7XgY+jLJCtSf7gaVKHx
7X/ZF9WyvZaGxQK64b6wuMQ4OdCGaQA6cCz4z3CYnFGh6bvAvKhQ+vaoTCJweCDS
ik0VuExsS9ILjMD8L5eQ2wYKmv2Ip/ua2fg+rV+8DzMzqQglYwkyrirjgVAXsnGb
/qBlJnuM7FCbTxjJ+eVjBAWvj8Iy8L4UPiFV62Qzvxr8jtPsjs6048x8tRLKaA8R
0XcH2zbujymz4Tbj+wwZtzNmdXLinOsFdU9O+0QEvQr7D4jaRNheNLtgExBVe8ho
kS3+DmgUL+GgKLUKiXTV6bRnrNHFNFZpQjuy6FMxqR4UZ+95r+YSORRDsJw5dg2M
1Esa4tyPjvezeGwdnZceFyok2G/qSQoYKYP766p9JmT2KegwCCiQNReRlVyEADz3
rpklcgBivkX7XkPlC94u9vEFbXpY3CG73eWczFFfrKPH9C9lwE3d1NQcNcEqRDiu
O1T2ae+TKH2d379E2Rn/sTQOVN4=
=4A8G
-END PGP SIGNATURE-
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On October 23, 2016 11:29:49 PM PDT, "Michał Górny" wrote: >Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell > napisał(a): >>On 10/19/2016 02:10 AM, Ulrich Mueller wrote: On Wed, 19 Oct 2016, Kent Fredric wrote: >>> On Tue, 18 Oct 2016 21:45:05 -0500 Matthew Thode wrote: >>> > Does pram allow you to pass options to git > am (signedoffby for instance)? >>> It doesn't presently allow arbitrary arguments, and it would probably be wise to avoid need for such arguments and prefer convention over configuration, given what this is. >>> --signoff is already a default: >>> >>https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71 >>> >>> Maybe I have missed something, but why would one use --signoff for >>> a Gentoo commit? >>> >>> For Linux (the kernel), the meaning of the line is that the >>> contributor certifies the DCO (Developer's Certificate of Origin) >>[1]. >>> As we don't have a Gentoo DCO, it is not at all clear to me what the >>> meaning of a Signed-off-by: line would be in the context of the >>gentoo >>> tree. >>> >>> Even worse, I see commits having Signed-off-by: lines with obvious >>> pseudonyms instead of a real name, which would be meaningless even >if >>> one would say that the Linux rules apply. (Also, we have the rule >>that >>> real names must be provided for all developers, with no exceptions >to >>> be made for people doing copyrightable work [2].) >>> >>> Ulrich >>> >>> [1] >>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428 >>> [2] >>https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F >>> >>The way I understood "signed off by" for Gentoo is "I am a developer >>who >>looked at the code and tested it, confirming it works on my system". >If >>an AT signs off, they are certifying that it passes their test muster. >> >>It's a more formal "looks good to me", and provides a point of >>accountability if the commit _isn't_ up to par. > >How about Gentoo developers stopping to reuse things that have >well-defined meaning for something completely different? I did say "to my understanding". I wasn't aware of DCOs. Regardless, practices and workflows differ between projects, and it doesn't surprise me to see projects that use the same words differently. Not that we should, of course. What would you call what I decribed, though; Acked? - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAlgNtlQACgkQASQOlFA54XDmhw/9HbEDo60eZp38AUMf TgCnj8fYka65Pc9CjLBpJAcvekM2oRcSHB61FdAy8tqIVb7Zx8IvIXNXseOc9sP4 0qNSy89gOKkNRIPx/DC8JFVlmK6YoD5ezZ05tKdzFwcdBvHcJWhKfbO2R2f6L/g5 woLZb4qgxQdFNwOykDy2Ux83W075hFbHaAw9zwpVKAb9LvtMfiJJ2AYEecmnOZDx uVVnkxMrOpAKABhcUqc3d8MnB2NCPwZogL3Z+71duy3puU+71Y338w64vrXDioBY 4pPVIrXk4Ifa799xjCj+Wr2sWYzgHqdJe/cReYZXjRMRzxbvLiZo1PWLejMWgczk CRX0lh6o0cohDxX8oEMiY3s3COqQvD928FzppGkW+8+XQaqXE64VEyHszMuILPL3 cLBbRt39ujmSPJUp/5mX3yUA761QcvRv4wPaDAf81NYllepLoYh2IL9j+5Iqfrf4 QNm/bUeuwxnvLZOMNGTyih/5w2GvhKhLunp170Lm4LGf6BQoEw60ZYot6OlvKFLF Th8oaacTc9acVa7K2lDlH+2ARsqFvfwQgEjGaLczfhFXi8lzIckgtb7Shn1UjEB5 u/7AwgGmO0rC3Mt9GXL7P5xYgWInNxEeyNP+O0d7Lu5CnBsKI9fUvoYnGZblSAWn yt44aBJYOgIzLklGfuQm6xhgdDc= =eesR -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New Project: MATE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/02/2015 12:40 PM, NP-Hardass wrote: > Greetings all, > > Looking for some feedback on creating a new project and herd for > the MATE Desktop environment. The goal, like many other DE based > projects, is to provide up to date packaging and as complete an > offering of the DE's packages as possible. > > Currently, the packages of the MATE Desktop DE are listed as > maintained by TomWij (who is on long term devaway). Prior to > acceptance into the Gentoo repo, it was worked on by lxnay and > steev. All 3 have either not responded to inquiries, or have > expressed limited interest in maintaining the DE. As a result, I > felt the best way to support users was to move support of MATE away > from any individual, and create a project and associated herd to > manage the packages, thus allowing any developer that is interested > in helping out an easy means of doing so. > > I've created a prospective Wiki project page: > https://wiki.gentoo.org/wiki/Project:MATE and intend to have a > mail alias, m...@gentoo.org, and an email channel for Gentoo > support and development, #gentoo-mate. > > Any feedback regarding the aforementioned would be greatly > appreciated. > > The wiki page says "Gentoo Gnome Project" in the description. Typo? I also think you mean an IRC channel, not an e-mail channel. Nitpicks aside, I think it's an overdue change. Each DE should have a project attached to it IMO. - -- Daniel Campbell OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIbBAEBCAAGBQJVlknFAAoJEAEkDpRQOeFwjIMP9AuYaBTgP96q93iwCjUyjrPz M+j9jXUWtJixNFs0iNTfivTeVLtggTQExVSmTUfodxZYKEl1RqYPktaUS6R4QUct 8kZz+7FRbPBElaGOUTcQR9OLrVhkClrnV8FLPCsviJFDTwQQZeDw8GSKLUDuFoet 7saDfVUi9RIs1FztkjWNDeB3Oj1mmuJ+xUFkcD92elMQxTw9hEkItvuwbuIDNARF k1NTTIGZk8yBBsGRB58SIhOjrY6i4vG+MTlQUED+rXgikFWN8SI7jNqhO0908ps9 uIk7P5C+CH9U57WpE9kO8p79i7+6UmL2xwiRfVTtSHvBsDtY/a0alEyRHvdEvcwS ffQKzj22KW2ybBRc0o2IZlA5TGeXR5JRmki87FpQ3Yvc9pwkyfKFe8qmQSAcbqeS FTyiK/ReTL4nRxtP7qU1P6xj6pvQGE/5UIwc3D25oQNKOrCx86rTpJeXtuIH7CaQ UYE3/lplCHxZx7HaOViVjWF3vFTRSf7b/UELhIb8/ZaTBtV9WFG/sIjjphZ2dRss 4DPcjiTCeIqqhn6ka7tWuoRbi3DjmiCpFYXZPctQ6jsxRqbG0MjBjrC3iYSVXOCl sz/5TUvnJg487EIEIG4gYUX9kdYJllaLCB7nK7cj9KuLnmxaTvDtVMEr4Jfjqx9d 94g0WtTqih+CBsgWA3Q= =Nqnd -END PGP SIGNATURE-
Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/02/2015 02:39 PM, Robin H. Johnson wrote: > Hi all, > > The Git migration is moving forward, and I'd like to announce a > tentative schedule for that end. > https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Stat us > > 2015/08/08 15:00 UTC - Freeze 2015/08/08 19:00 UTC - Git commits > open for developers 2015/08/09 01:00 UTC - Rsync live again (with > lagged changelog) 2015/08/11 - History repo available to > graft 2015/08/12 - rsync mirrors carry up-to-date > changelogs again > > I've allocated time for an 8 hour freeze, but hope to be completed > much sooner than that. > This is great news! I assume docs have been written for git-commit standards as well? - -- Daniel Campbell OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVlkrrAAoJEAEkDpRQOeFwxooP/iKN3RvNrITSwvihcIG4B8e8 w7acqsgCfIQTTza9sq+SQ5HXsmVadC+u702RSa5CqfgYw9JXSAdwhPVksGCt0iiL 9WdhVsRm8LE3O8B8gqGZLvG7+8OB19RCsbPN+fy0aQi+R2rtyQItibdpLLfzHw90 qfsw/JdI09ndRLh21gpmJnrC/fgelafQE0o/Z8Sl6akjwl44+dkAtPTDOroev3IF xDs1FyhSS2gzfAKcrXFoTetdmccUs/rQcCNzB3VeqciwfDvmJvAXtnN50VefpNt0 yID2ud7DDAPDTBH74gZEteARv6abQTqdToCEiczzaDSggiJGD/mS/F4jRgeWTeOP zgUcNyaLcjXIbb1QoBIEgBQHFXsOaiHegkuoGlNqCTCpffKBblDD38rBq/GBssce Y4cG8jvmapXKjph0c4BC+1V3p3Slj4AcnKfIk/Rkoc+YeLcGr5VUcOJXNHvJ85ZG M9c9kEW2X8/cscuRiS5tBMOROzculEAdEOOJZB6RJm2qk+yJ64MaiZVBd7Z6aUIx QmJvAenWeVZcw9Pz6MSmOCszLMD6MJOWx9tUCSUiiXEd9KoSAeKrXUraZpj76fOV Qv8jpCUd045RHTWvBqWs9g+ZPvb28rRoDzi5Xu+XU4FiTn9m079LJ5GUZvhsVFHn exhczY0a0hFXJaExF5R7 =MoQS -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/27/2015 03:26 PM, William Hubbs wrote: > All, > > I have been looking over this bug for some time attempting to find > a good solution [1]. > > The original proposal is to add a "want" dependency which would > work like "need" but would not fail if the services wanted did not > start [2]. > > I agree that the "want" dependency is a valid feature request. > However, I believe there is a better way to handle the issue in the > original bug. Basically, I want to follow the suggestion in this > bug instead [3]. > > My concern about the original proposal is that it will make > netmount try to start all daemons that handle file systems, whether > or not they are actually necessary. > > The proposal in [3], on the other hand, is to create a mount script > that works like netifrc. It would mount a single file system, which > would be determined by the link it was called from, much like how > netifrc determines which interface to work on. > > Some of the advantages of this approach are listed in the bug. Here > are a few more I can think of. > > - it will eliminate some of our incompatibilities with busybox [4] > [5]. > > - It will give us honest reports of success or failure with regard > to mounting file systems (netmount and localmount can't do that). > > - Currently, we have to skip over certain file systems that we > can't unmount during shutdown. With the new approach, if the mount > script mounts a file system during boot, it will be able to unmount > the same filesystem during shutdown, so that will eliminate more > complexity in our mount/unmount handling. > > The one down side of the new approach is the migration away from > netmount and localmount. I I will need to keep them as wrappers for > a release or two so we can fix all of our other services that have > dependencies on them. > > I'll also work on making the transition as smooth as possible for > our users. I believe I'll be able to set up the initial symlinks > for the multiplexed mount script based on fstab contents > automatically, but I'm not sure about how much more automation I'll > be able to do. I will automate more as I come across ways to do so, > and I am open to suggestions for how to do so. > > Let me know what you think. > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=537996 [2] > https://bugs.gentoo.org/show_bug.cgi?id=406021 [3] > https://bugs.gentoo.org/show_bug.cgi?id=426944 [4] > https://bugs.gentoo.org/show_bug.cgi?id=468600 [5] > https://bugs.gentoo.org/show_bug.cgi?id=468604 > What would a migration be like? For example, I manage filesystems exclusively through fstab (to my knowledge). Would this be useful for, say, mounting over the network? What would managing FSes with openrc look like? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVtugMAAoJEAEkDpRQOeFwBcUQAMb8I39T8ie4S6BWN3+dQ3FC GlzTaTTVn3cghMsjD956T3pwnKVp7Nak4FOEZj19LAciulP+++/me+pIEYMioR5x 3d8237OCgAmSAFk5/ej1wHdQrVR8rOcwgxtqtYLs77RJDwJ1/eMfmlbBzBTpdE8O bmEuVHCJdxvKbp+ZUjka6BTYr7rzpU5w+wUW9SWR3CBW4a1E3JKs9XurGt9JUmTa l1h2Ftw0xZkKXvKt6pJ7obBTrA7fXcuWw/hgvWz4iyofQlsvSmkC+GmIL/nstZMs bBgkTv8idtSNoGZebtM7jxdzIpUnn6j9rZcpo0J5ZQdEDt4xkw6YtfsrMH1mPmI8 2KYzKw/hesVtOtWgyEJvbRbIrrTKA+rKoIxx928dMHVJBqn2/LJa0QUn/oGFaOcX P/5UzzXdDJlbQYKRGH/xU1d5hu/B3DGI6MTgfsGjgr7Bn5+W8PZhO9zcKKJwjxn0 Fl0MD5ibp759ESr07YcjqKOHr0vurc1/Ww9xn9s/gdvcMQxCdzKp/olo3GOxCi66 TjU25hTbUOA6ZuQe/n3zZ+I/ud/uPYbVX6hdT/oNaiCob3PR6zH6/cc8FuVAEryV jqEVrIvnbN+CTi1DTIPAFOPq5PcOvO7NHCLXYqcS3gXH/JEIq0U2+BWdx13s4Whz Run8YkWYZjNl4Fz2a+oA =7yuO -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/28/2015 06:57 AM, William Hubbs wrote: > On Mon, Jul 27, 2015 at 07:25:20PM -0700, Daniel Campbell (zlg) > wrote: >> What would a migration be like? For example, I manage >> filesystems exclusively through fstab (to my knowledge). Would >> this be useful for, say, mounting over the network? What would >> managing FSes with openrc look like? > > I don't quite understand your question, but I'll give it a shot. > > With the new mount service, it will not matter whether the file > systems are local or on the network. It will be up to you to > configure the mounts for each file system to start in the right > order and configure their dependencies. > > I am not looking at deprecating fstab at this point; I'm not sure > how I would go about figuring out the locations of mount points > without it yet. > > William > Okay, so OpenRC's filesystem management is more like an enhancement for standard /etc/fstab mounts? My apologies for the vague questions. Perhaps I should spend my next weekend off learning a bit more about how OpenRC handles mounting. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVuJSnAAoJEAEkDpRQOeFwBdcQALtzqCDnXHI364vVJhWXQRac FRtALTx/RlgG2BS7fclMp5PPC7TYWG4jH50ZD35qozH46JJuhocMwfL02g+FXHIa 1MfaIzXuvhPMotj05PxoaBVBU7TmyhNEFiQJqD7qNu2vgsrknjc2QxXc1+INSgby cfMhmh49nxi6ZxvFAEBXlk2U0RRpomKh/og4NHSd2CiNFDHyg9r2D21S1YAaIAmh n4SHfh1c3y0sDOlhdOaEi6D0a5IGJqM9779LMeKOSjiSGXU+d3Xk+Vhkyo+SXrco 2jk6svz/Sm0XdOz4tCenr/j9PmGSN7UP8QUitoKm+2LmII+ZXkyzWYi5s41knl+2 49fw0fwGKIWJyQKV1f6IHTKOEKaAkxsWIjcmRcVxrQjiZ619ptZJIAv0ILEjZgtr 3/BNV5wiupRuz5aTTnCQdXwBX6wyQnLDsHHLInSjIcM4HCw9Ao2RfEJIAHrS0Sgj rnMV20ixNUgGY+WAv5HXF2HhNNa1ugzuwm+jZqgTjXqubHv9YfUHcJK8ahuWqiN8 IFJde5byla1zom7v+xkwi7rB0WE2La+oGndF+7lxgPkHD5JLtZTzgagYEVVeyFFT xczket5z0LjiRU4GSgucq+vAQUJqyocOprccOn/o5jkRuCexdnLPkZdiMgYzAPN6 cwluPs5OA8LMQPogcrVQ =Q+eI -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/30/2015 09:55 AM, Alon Bar-Lev wrote:
> On 30 July 2015 at 19:15, Ian Stakenvicius wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 30/07/15 01:55 AM, Duncan wrote:
>>> Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as
>>> excerpted:
>>>
On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev
wrote:
> On 29 July 2015 at 23:20, William Hubbs
> wrote:
>>
>> so that there is a better idea out there of what I'm
>> talking about, the OpenRC github repository now has a
>> mount-service branch.
>
> But I still trying to figure out why do we need to keep
> fstab around. It is pure legacy.
>
>
On what planet is fstab pure legacy? Many utilities use it
and expect it to exist. For example the ability to do "mount
/foo" requires a properly configured fstab file (also mount
-a).
>>
>> I think there are two meanings of the word legacy here.
>>
>> #1, /etc/fstab on linux is not legacy, and I don't think anyone
>> here (except possibly for WilliamH as I can't actually tell from
>> his statements) has been calling it 'legacy' in this context.
>
> /etc/fstab is legacy in the sense it did not evolve since early
> days of UNIX. Imagine /etc/crontab was left the same single file,
> but it at least evolved to usr /etc/cron.*/ to ease management of
> multiple sources and ease packaging/maintenance without need to
> parse and rewrite single file when provisioning.
>
> Nobody ignores /etc/fstab existence, I provided solutions of how
> /etc/fstab can be read in flexible method as netifrc does (which
> was actually the core idea of this move), doing so will make the
> service much simpler as it can use external helper scripts to
> provide the data out of whatever source, please re-read my
> message.
>
> However, having the option *NOT* to use /etc/fstab has many
> advantages in security (storing credentials in own files),
> provisioning (no need to race parse/rewrite), dynamic (define the
> location of nfs server based on logic) and many more.
>
> I do not understand why people are so sensitive for a change that
> does not effect the outcome of their need, all that I recommended
> to add is driver:
>
> mount_driver_\${NAME}=fstab mount_mountpoint_\${NAME}=/mnt/auto
>
> driver will be executed by the service, in this case:
>
> openrc-mount-helper-${openrc_mount_driver_\${NAME}}
> ${mount_mountpoint_\${NAME}}
>
> the output will be evaluated. This simple solution will enable the
> service to be generic and provide flexible pure configuration
> (whatever we choose), while support any source of information that
> is capable of constructing this configuration.
>
> Loose nothing gain some, simpler service and constraint fstab
> within driver.
>
> Another drive I can think of is UPnP.
>
> Regards, Alon
>
I'm having a hard time understanding why we need daemons to handle our
filesystems. Can you give me a use case that /etc/fstab is
insufficient for solving?
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJVvxa+AAoJEAEkDpRQOeFwGWUQAKCnuRLHYmUikYu+u0+1Tkck
eFmzW7C/G+Tbm5vqkRwk0F781gIPbpV36QOdIoTfBB65HJ9155VnsISXmQskf1+7
HN2guLTBrtOttZXOyF4KU7klGwElYTmD6tjMmH7aTxy6ID3lMKNtWDlktNgxPcH8
lfYsmB2DJ3+pxdMpPLCg0tGcR+s2RjNKJUnbXNGXO3vzO7PH/gPG9KkqtlVI/78I
Xf1m1e/MCEpRU8c2GCRzDuUkznUp3OMoXysMo3a/1c7NYx+KZ9CIlFZXiOX8CKJ5
hVf1xE0g8spRnH5Bq/EXO0mMhdWLB82ax4mD+jXdMR7H1i8SHjHGqQwQlKRFGIyg
UFfFcgz1GswGGar/AjkKz02FuiMYgJ7kU2nRHBlNsfjnjsdc8iIxPGhcCMWYZjuD
kLE/c6487ymQTMMYlIZ/qG7/90k57/TXZq0AuBPCB4/HD2vHMJBcYQkoWlnQSGEC
oYrVEvb9N1eKYe7/IpxnKVGKTZY1OP+xtDGvpPwp1MtE0GZ9VQbhS1+aJy6nVrs1
Uxx6/H7RTFwD5Af4V6mNe20ucz5mkEJxX9qTsNMrDAu+DHFUC3CTtYmeRN9Fsbve
ibHsIh1N0mI0bOvN16VK2s/ToahnsP09WvkJpnMIyJSfs4qWfpOhTWN8JEMWEdo2
j7V+HGJZ2GNYm3K0hFJI
=YuTA
-END PGP SIGNATURE-
Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/02/2015 12:12 PM, Rich Freeman wrote: > On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko > wrote: >> >> This is a clean solution for developers and maintainers, but not >> for ordinary users — they will confused by "qt qt4 qt5": "what >> is 'qt', how is it different from 'qt4' and 'qt5'. What you are >> really doing is implementing second-level USE flags, while they >> were supposed to be linear. > > No argument that it isn't intuitive, but setting USE=qt and > forgetting about it certainly seems more user-friendly than setting > qt4/qt5 on individual packages and worrying about which is better > where. To some extent the current qt policy accomplishes this, but > it sacrifices control when users actually do want it. > > I'm a bit torn on the issue myself, but just telling users to set > USE=qt and forget about it unless you really care seems pretty > simple to me. The documentation for USE=qt4/qt5 could say "this is > an advanced setting for users who want to prefer the qt4 > implementation over others - set USE=qt if all you care about is qt > support." > I like this idea. USE=qt for all apps that optionally support or need it, qt4/qt5 for apps that support both. We can default to qt5 and users can still choose qt4 if they prefer it. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVvxjcAAoJEAEkDpRQOeFwbIsQAJeCSW9NHUFyXirEhh/pL7cP Vc5F6bgxZhJ1svHiCxMAQuFz5POG/yxjq6iAwjtCaDaWBDj/HbSDe69Pu0HBcCkK ezb2AJTtacvkWDxlJhH4H9m7QB3M9/XWlKlfMAhKnDEaSFS/yieR578LE1sNd2aF A9JditTliVqmRr3DYNvT4JlqGIBJyU43gR75gW2gHyWE0FTZ4Rv8k6DQHJuseFb6 OvWWrDCKZQZqLmLIvpvz1ksyXuFis8qqCPLws37awo56kjT8jDJ+kdulwFGdvxui zrau+MtufhDwehVsVKKe1j/6dhVnmOqlIZd3H7Pule9jFsH6AGRN4s2dL2bp9vqi WdmQI8B6eDvdUK0Il1+zd7V1Uq8DXIYpTlOYrUHtnAlyaT8ln7FqojSKODASZ/10 LkJQ9SLv7ej6nQLnkYe4F1FQqssPqGe4v2tAZcFVu2pYda3KCP7PJKT70oFtzwrQ 76jVgp5Ryp/cbZrM2tOEcvb/3kTXDHDW2Wavh+VV7XwBmTvXoXqZas+eHMMtbyDJ 1cofAFRvu6HWnITTg3ZPoiQbm5Sq4rjG7aUvkyUxIoC8YzhXdHOTBpaYaFe6nZ/f 45e7lHq4iDsArmBn2BiF4kBKZh8I5xMY1/K10mC8/4emBS3NHbafOUKqujCCqLMj dhh/jF4gLzALPIDGXBRp =j7X5 -END PGP SIGNATURE-
Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/02/2015 10:33 AM, Andrew Savchenko wrote: > On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote: >> Recently some team members of the Qt project have adopted these >> ebuild policies: >> https://wiki.gentoo.org/wiki/Project:Qt/Policies >> >> I have an issue with the policy adopted under "Requires one of >> two Qt versions". In my opinion, in the case where a package >> offers a choice between qt4 or qt5, we should express this in >> explicit useflags > > This is what the policy does: "Implement both qt4 and qt5 USE > flags" > >> and a REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the >> clearest choice. > > This will create insane amount of blockers if users have both > flags in make.conf (and this is a common scenario). > >> Other developers state that users are not interested in such >> implementation details, or that forced choice through >> REQUIRED_USE is too much of a hassle. This results in current >> ebuilds such as quassel to not make it clear that qt4 is an >> option. >> >> This goes against the principle of least surprise, as well as >> against QA recommendations. I would like to hear specifically >> from QA about how we should proceed, but comments from the wider >> developer community are also welcome. > > As far as I understand this is done to simplify user's experiense: > usually people set both USE="qt4 qt5" in global make.conf, because > they want qt in the first place. > > This policy will allow to USE both qt versions whichever is > available preferring newer one. Quite reasonable approach. > Alternatives (^^() and ??()) will require micromanagement (e.g. > pagkage.use.conf) for dozens if not hundreds of packages for no > good reason. If someone still needs to override such policy (e.g. > to use qt4 when both are available), this can be done by > per-package configuration. > > My idea is that packages should be fully controllable, but choises > of default behaviour should be done so, that in most cases > micromanagement will not be necessary. > > I like this qt policy and I'm not sure if it violates any current > rule. But even in such case this rule should be fixed. Moreover, > this problem is not limited for qt: we have exactly the same issue > with gtk2 vs gtk3 and probably some other technologies. > > Of course in theory it is possible to build package with two sets > of binaries supporting both qt4 and qt5, but I see little > practical need for that. > > So I propose to add somewhere to devmanual/policies the following > recommendation: "If package supports several versions of the same > technology (e.g. qt4 and qt5) and more than one is enabled by USE > flags, ebuild should prefer the later one (in terms of technology > generation).". > > Best regards, Andrew Savchenko > +1 - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVvxlqAAoJEAEkDpRQOeFwRqAP/jLkyzsJ0lPind06f8YvQ4aF Nog8g2pJHJUYXryJwCZpedj4Ju8QWnlE9qOLFO/PvKjNq1AddI7PB/BpUAK1HBuq 9T319lQttGyZAFqEeYm3j1c7IcQInNSXaGLJnLVw19UWgUg1ZuTxiec7XJ7Qovmy D1BdZrMSVhxzSfCKN0kGM3IDxgInVWnEhPCiqDzDMT/U9j1K1sOFA/77/M+HbEvp LP26R/ICdznLNTRqAQxBn6TnZ0D6LMp+ngWCvSa07XCyn3O2K1cQA012l3hQ4/Jb +GP3mk6UM3rhn5saZ+2nJM5axFNylTFcJnqJFjU6//Q7q3C0Xh4sEuu8n3ywgiG4 8Mmta0i9TgGcIjfnCcDpMO6Yvs1g79Hgg3A87tCzJEaYRXWlHjGY+YsoYVIvPS6d qNdhG8+/8hhQUQy4gcmT7M5HZVkMj/hmju+X9bCPbDrJY6Xii90ZbvCZGiPBAJbm VebTPg5CAzybhqtYAOiygLKMqh1Sw8LrFlBSAMJpLr89CHN0ODuzQp+Rho6rYcp0 t2J8AWJHW2XJ8TePvDpCDkEog83c1sSxKPqsu8AHTPcw+Bvol4vpmUsv0BQlp9aa F4ZXxccqTzbZtwJ9x7jBGjlBl6H4Bu0OE/y7nUPG9aTldxMfnEgJeEktUtpAlWCu fYSYVLjlNUl9OtL/ElnI =fRV1 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/03/2015 12:47 AM, Brian Dolbec wrote: > On Mon, 3 Aug 2015 00:22:42 -0700 "Daniel Campbell (zlg)" > wrote: > > >> I'm having a hard time understanding why we need daemons to >> handle our filesystems. Can you give me a use case that >> /etc/fstab is insufficient for solving? > >> - -- Daniel Campbell - Gentoo Developer > > > It is about defining proper dependencies and not blindly returning > a success result when there were actual failures to start some > files systems. So in some ways it is a bugfix. But it is actually > a re-design which will overcome shortcomings/limitations in the > fstab, netmount, localmount designs. > > Net result should be better configurability, proper error > reporting, proper service order startup,... > > Downside, it will likely mean a little migration/transistion. > > I'm in favour of the change. Good work William. > > I'm okay with a change as long as it's relatively manageable and offers some real benefits. If I understand correctly, this new mounting will allow us to declare mounting dependencies the same way we declare service/daemon dependencies, correct? So say I want to have an ownCloud instance that provides a single /usr or /etc for any Gentoo system that wants it on my local network. Is that a use case that would benefit from this new mounting? I'm just trying to understand which use cases benefit and why, and what it is that fstab isn't good enough for right now. As a developer, I want to be able to support users on this if/when it hits mainline OpenRC. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVv/uOAAoJEAEkDpRQOeFwcYUP+wcyl4leWeX8lYrsIXc1Ukzs /uU33M1zcFM8Sya7ywO3cjGvS/3d1P9qkVeDy1S/Cfb8SGGGECsNbVpN0Dht9un7 UxOejDuTXdqD5+XWVBsoXYcWbvVFtOPGnSJtQSd8nU0RQ9jOxQqKjk05Of/e0mKT yT91GFvbBpTFyzM+cnXPN/OKHBOEg0Aq51JmtQ2jn8fjrUml87C7MrqwmX1PnQPN mvxhtTAvmj4LMIIRnUsPZOl/6NfeHgWeepkYcKEJiAlBasr4eMawhR+cbQmvLDeg skmvptRU42GQ3Ah/IDXvBN1dZGwXv1lYb+r5NqxxNK8RqsaWHMQ25278Fr1HVgj9 julvufmP8mrhe/Q939qW+Z7efhT2Mn+VFaX4woqSSNw8iqy/zgwtWlVHInpd3Q7B xpIRkpeJxNBLfYAh61RvBqbQuf9jsNoy8fabyx3LaHKwif7sjKEfx++lGc4Eq9b4 vEB+HdMXGJsP2AeFg/QDa8ioaYpIwCPDtTliQBjGs7KW/4gzJdg1A/iLux0J9dAQ snhRP4QYmBEU1V8XiCRYk68QBdsOFkN5sPoad1/ZIN+jQMSn3uXcEeflWoj+z+GZ K7p6xSdPkowBmrJrn1SkgpIlqyqUSNUB6haT1SKPPUBAye3JHZATpwgaF3teuPOG Kw8VULdYOad9ynaMO8g1 =sGaS -END PGP SIGNATURE-
Re: [gentoo-dev] Git Migration: go-live!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/08/2015 10:36 PM, Robin H. Johnson wrote: > On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote: >> On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson >> wrote: >>> 2015/08/08 15:00 UTC - Freeze 2015/08/08 19:00 UTC - Git >>> commits open for developers > This is going live in a few minutes. There was a lot of delays and > snags that were hit. QA has a lot of reviewing to do of in-tree > patches with long-standing CVS keyword damage. gkeys is also not > sufficiently baked, so we're using some scripting for now instead > [1]. > > The new setup DOES enforce that commits AND pushes are signed. > > I'm only 90% sure that everything works, but I've spent almost the > entire day on it, and there's more to go tomorrow. > > Other old CVS repos are still closed for the moment, they will > re-open tomorrow. > >>> 2015/08/09 01:00 UTC - Rsync live again (with lagged >>> changelog) 2015/08/11 - History repo available to >>> graft 2015/08/12 - rsync mirrors carry up-to-date >>> changelogs again > These parts are still pending. > > Quick instructions: Set PORTAGE_GPG_KEY="0xLONG-GPG-KEY" in your > make.conf $ git config user.signingkey 0xLONG-GPG-KEY $ git clone > git+ssh://g...@git.gentoo.org/repo/gentoo.git $ vim ... $ repoman > commit -m '...' [2] $ git push --signed > > (some time later, when you have local unpushed commits you want to > rebase instead of merging) $ git pull --rebase -S $ vim ... $ > repoman commit -m '...' $ git push --signed > > (some time later, when you have a local branch you want to merge) $ > git merge -S some-branch $ git push --signed > > [1] The keys as they are in LDAP right now have been used. If you > need to change your key, please ping infra as well, so I can update > the temporary setup. $ ldapsearch 'gentooStatus=active' > gpgfingerprint -Z -LLL \ |grep gpgfingerprint |cut -d: -f2- |tr -d > ' ' \ |grep -v 'undefined' | xargs gpg --recv > > [2] If you commit directly with "git commit" you MUST pass -S (and > ideally -s). > I'd like to thank you and anyone else who's worked on the Git migration. It's not a trivial undertaking and I look forward to working on ebuilds with Git! The workflow wiki page is very helpful; I've added it to my Watchlist so I can stay up to date on changes. Thanks again for your efforts! If you'd like any assistance in setting up hooks, I'd be glad to help. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVx7H1AAoJEAEkDpRQOeFwYloQAIPXgVMhCvT6xLxPd6OVtOtU pDHuRUS3aGXWowGnf4BFTvV3ILpca/qm/ExVe+As1B7atCkP3XeRYP4y0TB31Ol1 QQMNvIZ8XkItjbQg8QTg0EMqA45IKMV//4ZwVdsAjPq3686nLOtfjAREB6SwO3nS 5huXcJ2+D1wxKAAAORGwkNYIjKzwGd/BnbDWTyNR/pUekrd6nBo/du5v7vo5j00S ORsc4JXjhoQ56KCvNDz4kkzcCiPE0equto7b/7ZL7Cb7hkV6d8u5YmwzQPGwzk4I OztEF88xpOvDHsgVuV1UStOLX3trVmkUZElwIektw7+ZOZZ7IwLzPRGHUDronSR/ mO6gdxaPqUCfjMNsg7n54dJVUNhkPjCu/8IispfnfmFJ/xGdnznAizkW25zJH5Vx +DVC8wac46/74SBmJlipRuMiMKAQu5kZP4szGFd/n4bYyQplnQ/7u+aX/IbMQoY+ JWWNHRZfjHYKjJcWA+sxYuWQp5RwcL//o07BR3zjjv7LOTEVwtnOApppV+E9bOyF 2OgTDPOhLao+D5Gm0b7T7nMT34DAw9Io2D7Nbo29YQFuXim6/6jPB9uJeSswan5J uUUJQnJOElSiM85EUJm4ZjKXS0zHjNMoiyFTWi7C8eUu1eeJgCsTNqFb0/3vDOct 9OfweV2Hm2CY/G6Vwk00 =2eg6 -END PGP SIGNATURE-
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/09/2015 11:49 AM, Davide Pesavento wrote: > On Sun, Aug 9, 2015 at 8:43 AM, Mike Gilbert > wrote: >> On Sun, Aug 9, 2015 at 11:30 AM, hasufell >> wrote: >>> On 08/09/2015 05:19 PM, Tobias Klausmann wrote: Hi! On Sun, 09 Aug 2015, Sven Vermeulen wrote: > On Sun, Aug 09, 2015 at 04:43:36PM +0200, Dirkjan Ochtman > wrote: >>> I think "X-Gentoo-Bug: 557022" also makes the job >>> easier for tools that parse commit messages. >> >> I don't. Just the "bug " prefix should be fine for almost >> all purposes, even for tools. > > I'm pretty sure the majority of developers don't care that > one developer uses "X-Gentoo-Bug" and another just adds it > to the commit title. > > I like /guidelines/ in the sense that, if I don't know > something, I can look it up. But don't make it mandatory > until we start depending on it (for instance, when we would > automate stuff based on the content of the commit > message). I'd just go with "Gentoo-Bug". The X- is pointless since it was for eXtending Email-Headers. And what we do is only linked in style. >>> >>> I'd be fine with that and add a reference to the kernel >>> guideline [0] to the wiki as well, so that it is clear that we >>> also allow/use Acked-by, Reviewed-by, Suggested-by and >>> whatnot. >>> >>> I'll wait for more ++ though. >> >> I like Gentoo-Bug. Much nicer without the X-. >> > > +1 for Gentoo-Bug (or Gentoo-bug? not sure about the > capitalization) > I guess I'm the third +1 here. Gentoo-Bug: xx is far better than linking to it, since the URL scheme may change in the future. Bug number is not likely to and it's clear what the number is referring to. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVx+k8AAoJEAEkDpRQOeFwff8P/ROogCO8pBB7GH7epA3E/ObZ udQIG8qupPiXfY9JUSR64ST4qNeeRL9Exu0RqeicgbLWdm0fXfmVkxzFmtGjahlp nkNIGQOZX4f8Y27+2Ly9HO3oJqTNVq6sKgJBNkRnybOhqOFgaqEYWiJUZVdcNfUZ 7G1aS3MXTxysG2CzQwt3sEQSoMFKwp1PetXgF2f4ZsQlr/wHkyyd3yllQyKS9iqK VG+IawTTYylQa04MTn8V9oW0jdoU8uL0HEH+3FKFZJq7t2bGT/GsW6iIxW78kaVt iBQCkW6CK24IFRnP31oz8zuwbtK6OFg1Cx5fIRYYfsvaqCDzg5HqV81I5iZ61ZEr GWUwoHYRXrw2RG6kC0V6TyvOVUDGTAGA+9jYIRNkMJtNhTlDosztyhCmkXLvajZE QWXQ4FYXJy0OXytk1kK2+6cRNUJLhz/QfwXOlsSQNHfcCJuZQJ2xN73twzOpSPo+ ZCDclX84MV+cLJslZZVLNcjWToE/LZLw4a1VKvt3MDOAlhpMiPfcABWB65RcR7N4 7LcOM6APIsaYsJsgsZDSNlq5ckIkqZk55d6S7LADHwbyQac/o7kP05atGOuiaw9/ EbmTcXoM73+oemhce/dGc5/iPH+JYkoAkN94pbqWhj4wWykatcmE2TW1FLNPZdmi /a0RFqIXsv8k9y0MZvEs =ydn7 -END PGP SIGNATURE-
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/09/2015 02:11 PM, Michał Górny wrote: > Dnia 2015-08-09, o godz. 23:01:32 hasufell > napisał(a): > >> On 08/09/2015 09:56 PM, Michał Górny wrote: >>> Dnia 2015-08-09, o godz. 16:09:29 hasufell >>> napisał(a): >>> On 08/09/2015 03:58 PM, Michael Weber wrote: > commit: 40b3fd64ec9c5d6d94f0f0897740bc77622c24a1 > Author: Michael Weber gentoo org> > AuthorDate: Sun Aug 9 13:58:26 2015 + Commit: > Michael Weber gentoo org> CommitDate: Sun > Aug 9 13:58:26 2015 + URL: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40b3fd64 > > > sci-libs/opencascade: add USE=vtk (bug 557022, thanks Helmut Jarausch). > I was wondering if we should set a standard for referencing bug reports. The portage team already does something like that: https://github.com/gentoo/portage/commit/b7149002bf23889f280c502afe 6ceda0b1345ca3 Following that, the commit could have been: = sci-libs/opencascade: add USE=vtk thanks to Helmut Jarausch X-Gentoo-Bug: 557022 X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=557022 = >>> >>> Which is terribly redundant. Just put the whole bug URL. >>> Advantages: >>> >>> - keeps the bug namespaced to bugs.gentoo.org, - has the bug no >>> inside, - is convenient -- you can click it instead of >>> copy-pasting the no. >>> >>> Also there are some standard keywords that are sometimes used >>> to reference bugs, like 'Fixes:' used by x.org. >>> >> >> I am not sure what exactly you do propose. > > Fixes: https://bugs.gentoo.org/show_bug.cgi?id=557022 References: > https://bugs.gentoo.org/show_bug.cgi?id=557022 X-Bug-URL: > https://bugs.gentoo.org/show_bug.cgi?id=557022 Whatever: > https://bugs.gentoo.org/show_bug.cgi?id=557022 > > Just no magical numbers which are meaningless without the context. > The issue with linking is that we may not be using show_bug.cgi (or 'id' in GET) forever. Bug numbers would be feasible to migrate outside of Bugzilla, and technically a webserver can be used to translate those URLs, but the important bit of information is the bug number. I don't know about you guys, but I have a "smart bookmark" in Firefox where I type "bgo xx" and it'll take me to the relevant bug. It'd be trivial to set that up as a bash alias, too. There are tons of ways to get to a bug; the important part is the bug number. I think putting the URL in there adds extra work for us later down the road should we migrate away from Bugzilla. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVx+oQAAoJEAEkDpRQOeFwoYwQAKSYfi2sXsYfghAsA/ym+sV9 aP6+1iTlOqxibYwfMrF5S6PeCIZDgfX/FMV41L344b2nchcOQz6JrgZ/iAWeOOHR fvlzP1jz879P3xW2vktdOpEBK8j2Pz8M12qJuYLCM98u2mTqGKl6MieuTD5l5LDq PASSyI1BckNcBDgiiI9IDkXzINLEYDIoTKCLvndyCBabeF+0ydRK9iX+iHHPhnG7 qz7AndjuSl6JbT0W6IPvkpssSFC67bfq2vEUows+Ek3CvhE/K+qcopcbnJjJyfsf 0ELaKUzNgioW6blX/uQK6pfs5QIsZpfM/mhrMa5y03a7b+JZUt+HEsyh8hmSf7lP LhfOnV+h4EAAREFdYa9MI1Hn+rZ/lfTOY1Gp0pHFKAX9cu7Xhxn6uu9he6M8EOPG es03hoB5cyzvsBJ/r7OggySidXeovtFVdPuPDkom82KqqrB/qG9qM458u4d8uWh/ y3nMLKCPuOiKL981RNijXwjZ5MKxSFrgrutgEQ+tJfiLfncz8ySmqNjrP2DJQBwi +vK7/trpooh//6yEFVq+MYH8COqFzQrImkHe4OprrxQFBTLeCfVwMp15Usw73Wbh D8+7rW2uz9TYqBom/dAdEzLNO00DKpJpp724k4RXsE6FCeT2N+6vIJZfyNTiB8f1 ohES4L5gJI3GZnr556G3 =pxsK -END PGP SIGNATURE-
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/09/2015 04:46 PM, hasufell wrote: > As I see it, a lot of people already stuff the bug number into the > summary and I can't really say anything against that. It gives a > nice overview when you look at it: > https://gitweb.gentoo.org/repo/gentoo.git/log/ > > Given that fact, I am not sure we can convince people to repeat the > bug number in the description of the commit. However, the bug url > definitely does not fit into the summary, but in the description. > That would be an argument for the bug url thing (so we actually > have both). > > As in: try to stuff the bug number in the summary and also give a > link in the commit description in the form of "Gentoo-Bug-url: > ...". > I'd be willing to accept a Gentoo-Bug-URL:, on the condition that it's not required as long as Gentoo-Bug: or the bug's number is in the description/summary. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVx+rIAAoJEAEkDpRQOeFw7xYQAN2HMXnULjqEHQiTIAAq++xg t352gwmNsyOxOFBsOlDX5xW55mx+z2BFw4S65PoRYn76ds+eSn5GDxuDjHFijcTm ZkJEIkNLUCvt4wKILgBKTbiy5AkqTGZMyGiQT6dkAZexeoE5mQ6HVVjeLzaMilp+ 1vtqIAwYnz9PqTdP2GxeGNAkhha//gy6M5s3jJqcY1JfnvrhIBcdaOP4aXE4BbKj asPWvlz+Fgx8ZC9ankobyyCdhaPBH3tOKWdquKHR9hwx59S4sxo6VF14IdG1yxaZ JCe7qyQdCi5aLs6IsoMGdcQubuMPF68ugj9Z4/+yKGqxt7e3meGmO5SzwGjvG8a8 RfWIa587Uxkh+Egs/I5wMbKGFUr5QMQwgXjjjC7+dLCyVT/wQXXF+Y/vL60vO41l tRXNe0dye251+H23eOjePJ/UrViJNpq2V0SAMz8Y2ild5TGZD6rIu25WZzyT/cHb yikvRxCUYlu9UttbKuaCCZy+69vbPkV2ugCT9e6uq1vh7uUrFTeg60KYsp6aotcm EmPZFiLFG1BRu2tOw8KQdEvPPkZpjCg+m+rE3OrThI+c2AkaMR4TB17PyL5wXZ6c ZwzJnJ6Sqkv7RdZAQkq5tIUN29qgtSR+DT6VLZ7E1ZmbFqn66jiIE7+Hm+Wm4Q5p s3DHH6qJxM40Jr5jQ+B2 =/qBQ -END PGP SIGNATURE-
Re: [gentoo-dev] .gitignore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/10/2015 08:09 AM, Rich Freeman wrote: > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert > wrote: >> >> Expanding on this: the rsync master creates the following >> files/directories under metatdata. On my own system, I like to >> symlink them to locations outside my repo so that related portage >> features continue to work. >> >> I would like to have these added in .gitignore. >> >> metadata/dtd/ # used by something? metadata/glsa/ # used by the >> GLSA utilities? matadata/herds.xml # used by equery from >> gentoolkit metadata/news/ # used by eselect news >> > > As a side note, it probably wouldn't hurt to set up a guide for > running git on /usr/portage, including setting up these symlinks, > running egencache after emerge --sync, etc. I imagine that this is > a configuration that many developers will tend to use, and with > the advent of git we may see more users who tend to contribute > doing the same. > ++ - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVyO2pAAoJEAEkDpRQOeFwmMwQAMBNw6VA3UEINvi6RgyW6NJJ a+6QYB2RigTxOJP3nlnTXywahme1Mxtdp8X/rcebHZ0LUi5XSup+n6mGljcUHsx+ Gl09zShXoHxRdDX2JFsptt6YSVr7gXMgT83iFUDGRAKVPFIvJ4Q0jFzWjj0MD0KW 4363Oz2+5/Wdt85vKcLuT8QLG+9niEaxHab2VgauHieFYPALdTdhaEX0DTxTf/6s M7oz8IN8p+iKbXbks0q0ZhsbJSIcOKLxE6IQ1alftFFeMkbP5wyxH5QLOFKlk6eG oojNVXlxwvcz+nVnnYVPLhGDpPjdOndjkJ0P+uqsuLA/QIK7rwKy7VGDaFNX9zUD 2fxUNqKXstQXUBkvrzXDNDBpqWuh9v27bbS9Dx+5iJMVIUNm1YegM+JyIor9bBVT UKeixNwYanYtWNJDGmFluc3vnIwuDqgMXC9dYrDdk3a1wPXj2l/kUmljl1wr5Ora 9BCaVSLAENg+VaNhQ8IkY5LcUnyLw/O3T4SLydqAJwc0u9+uwrcmSndwPAmRnp7U eg/AccY1/PXARTK+u56yVzmApP6GHUz+tFIQ3frobYO3YOhT0xZojP8ecuMAkeiw C4KRtVDRgNXmu/5FPvIMzhNNJPB0U1WFS7ZphOtGG2adRkXl4kGzmVi9QEFGGL3+ sDIclOHeOXp1LGP17Ek4 =jJqm -END PGP SIGNATURE-
Re: [gentoo-dev] git commit / push signing error
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/10/2015 06:15 AM, Doug Goldstein wrote:
> On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn
> wrote:
>> Doug Goldstein schrieb:
>>> gpg: cancelled by user gpg: skipped "0xA2BC03DC87ED1BD4":
>>> Operation cancelled gpg: signing failed: Operation cancelled
>>> error: gpg failed to sign the data
>>
>> There was an IRC discussion yesterday about this. Probably your
>> pinentry tries to talk to a GUI and fails. Try:
>>
>> unset DISPLAY export GPG_TTY=$(tty)
>>
>> to make it fall back to curses, or use "eselect pinentry" to
>> select curses as default.
>>
>> Interestingly, git requires GPG_TTY if eselect-pinentry is set to
>> gtk-2 or qt4, but repoman doesn't.
>>
>>
>> Best regards, Chí-Thanh Christopher Nguyễn
>>
>>
>
> $ eselect pinentry show Current pinentry binary implementation:
> pinentry-curses
>
> $ eselect pinentry list Available pinentry binary implementations:
> [1] pinentry-curses *
>
> Its the only version I've got on this machine. The box is headless
> and I ssh into and I use keychain to manage my SSH and GPG agent.
>
What's your keychain line look like in your .bashrc/.bash_profile?
Here's the relevant portion of mine. I was also having problems with
it until I changed the order of the arguments:
[snip]
/usr/bin/keychain --agents ssh,gpg ~/.ssh/id_rsa ${GPGKEY}
source ~/.keychain/sporkbox-sh > /dev/null
source ~/.keychain/sporkbox-sh-gpg > /dev/null
[snip]
For some reason, it's important that ssh comes before gpg. I got this
advice straight from drobbins, so unless it's changed, that's the way
to get it working.
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJVyPVAAAoJEAEkDpRQOeFwOb4P/1o4qUuUTstuz5A57V9bGX97
D6sWioMhjjRX//951064Q7sHmQbb3CbDpUanPg0Np0devXai4OipuQCKf773OkVI
iFCHH1vm9U5qi70O7ylBKpjzfI5SLS/evlFOmP9e/wmrp482FsuODM+VqSx6i1Yb
P1wIbnttNJI/qFu23Y6XkE3cIwrzXWUrjm1ROFWir1x/xy9SwoWe3hcdy/HNVokS
jlM+RJL9bByEioWQXnxR0p2VLHr45bGXtBj+8m4rciAFFiqbNLaoGWt6+fpCR36g
YYLYPiZ4XTWUamTBtsIVBwx+t0E2oj9AReejKjIxbysUFyd0KyrVqg4Ri+YMdr0x
4j1uR9MZ39ItKjlGIncizPNjc7IAUDubxt8tuY4ndayr5lgtML4vGSbb2XDd2H3A
tlAS5QbV0k+eQQak8Mff0UmRfQE/IsWaPKe21ymBXI7wQPhrXCAZ+LwqdvTtiYJT
bFzezJ9HKTscHrRywDNPmzIDER6y6tkOdCkhjFpOGt+9zvadTN3Mt0ZJSiknZasT
35irU1s+ulFFgczW8FBm0kliFRJIf7n8BbyJpsMcIE4qekTiwRLi2x4VbrFVDn1v
/0R8sGAWNJRcSv0e9OI7oLfbT76seP+Bh5nK6Vt4szDzm+XCiPeQEZc8jCqwc9M0
PigIGXV12N6k/4usjY8e
=OUvd
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/11/2015 03:41 AM, Sergey Popov wrote: > I'd suggest to make a QA team meeting to override this policies > with more correct and rationale. > > Qt team members are greatly appreciated on this meeting. Even more, > i think that we should not take any decision on this without at > least Qt team lead(or half of Qt team devs) > > So, let's arrange some time and talk about this, cause it is > really confusing. Qt team point is understandable, but it's still > wrong. Let's make some consensus here. > > 02.08.2015 19:34, Ben de Groot пишет: >> Recently some team members of the Qt project have adopted these >> ebuild policies: >> https://wiki.gentoo.org/wiki/Project:Qt/Policies >> >> I have an issue with the policy adopted under "Requires one of >> two Qt versions". In my opinion, in the case where a package >> offers a choice between qt4 or qt5, we should express this in >> explicit useflags and a REQUIRED_USE="^^ ( qt4 qt5 )". This >> offers the user the clearest choice. >> >> Other developers state that users are not interested in such >> implementation details, or that forced choice through >> REQUIRED_USE is too much of a hassle. This results in current >> ebuilds such as quassel to not make it clear that qt4 is an >> option. >> >> This goes against the principle of least surprise, as well as >> against QA recommendations. I would like to hear specifically >> from QA about how we should proceed, but comments from the wider >> developer community are also welcome. >> >> -- Cheers, >> >> Ben | yngwin Gentoo developer >> > > I'm interested in this meeting as well, as maintainer of a package that can be built with one of two toolkit versions. At the moment, I'm using REQUIRED_USE with a preference preset for users that don't care, but it does cause a problem when both flags are set (so it's something I'd like to fix). I'd like to be part of the conversation if you don't mind. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVykQPAAoJEAEkDpRQOeFwVAgP+wYqVva9YHWmUOwC2dyrUFhx EjnPHBRaAsd6vOdoKKoFbO2c4wMhcoXb2C9pgLDw4O+eB2Q7JE3iMiiG/vAwGGtN 10meoAjvFV+DxpB7EYiHNj8NtlKq8PAncHusu6H/eP7YwdS37ruO4E89nBbXzxjU JQru2bxL6Jf7m/LuI5lihdU6fwe1GrsDz0fCaeZ/49zBE8EPY1PjDbV8G8vHq/S6 UAgGXmFbzN8lPXfgBgnaD4O6So+WrhILUeTy4CVUQu0599W4UFmLqOmupeRHD0SM wHjtJ/0gW+Wfb7VbuQsfrmNYuu0Fh/Wx15qs62/8YcgIOxb5YI31cefPa7e3HZbm RQ52JC16Pl7VxPEsf5jhcQ6+QCpdOi/jH7B72JQiSgmtLF9N6j4kcr8XGtJB/HLy PlJES1865ugS8LWpMiJCCwGyO8o/lOi4scbumw+XxjWj43Z93d66wGK84Yf2goAL VBVA0JjzrJ46EIrBbqOPECMZZvJjeq4t28V3DHAdLPZmxhvLQjIjEqb8wywR5USa NJ4kDgP5H85udznBk7JWapFu+ipphFm8uzKt6nqCeAfVc/y3n4rLZ9aUDCBVKodv lzr652TmUw2sBvmhM6oRqsGZuMg6t0peBOOTFjTMJl+WYG+eUybvsWk9RQ9HQpuW aqpPa6GiLL9Gbx8JTX8F =JOKI -END PGP SIGNATURE-
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/11/2015 07:32 AM, Michał Górny wrote: > Hello, everyone. > > Now that we're officially on git and can officially use pull > requests to provide rapid community interaction, it'd be convenient > to have a little better framework for pinging package maintainers. > > With the unofficial mirror/pull request project, I was either > looking for project member GitHub accounts and pinging found > project members by name, or talking to them directly on IRC. > However, with the growth in number of pull requests this will > become more and more inconvenient. Therefore, I think it's time to > be able to mirror teams willing to work with GitHub community there > for easier 'pings'. > > I have two ideas right now: > > 1. creating GitHub Gentoo project teams corresponding to willing > Gentoo teams, > > 2. preparing lists of GitHub usernames on project wiki pages. > > Solution 1. is cleaner. In this case, we create GitHub teams under > the Gentoo projects, and add appropriate Gentoo developers having > GitHub accounts to the teams. Then, in PRs we can just ping the > whole team like @Gentoo/Qt or like. > > Solution 2. avoids adding any GitHub teams. In this case, in team > wiki page we collect team member usernames like "@Pesa, > @kensington, ..." so we could copy-paste it to pull requests. We > still require extra effort when 'assigning' PRs but at least I > don't have to lookup the same people over and over again. > > With some Wiki people help, we could even implement updating > GitHub teams automatically following Wiki member changes. > > Your thoughts? > Sounds good, but my GitHub nick doesn't match my dev nick, and that nick is taken on GitHub. What do? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVzEjGAAoJEAEkDpRQOeFwtagP/3TSjgxe/X2UoWelHfkWE55k KpmEhbzMBi6Q9WApJ2gv1700zmw2wh/M9xwjFgXor7jDY65opOq7mH1NWZ3Qt/nE e9BR+HxJ4sJLYAVmuXcV4yPK5VftK8kf2lq0XsiJh+jlCWOZ1opKf3wXJOcN9/1I xB9e3nG4i25Xk9XEIRLX0fWDcu03YvQjP11Zb/FxUYhc29gr0b3am7FLGGgeCUmo pRPLcPm+9JvxzCy0n9PofFgoZBtt7RFkOobK8aOC+MM1xSBoSf/r8iQ8bKLXrApY LB4YltxbTWCbFAi7dwmQInhbw73K4cIK1Id5UooiOkFnDz1o8FhKE9Y9jRlvsqMM rLgKBJD12ZwlDPSN5Zomu2U7A42hCQ8AemWaOBR6oyh/yiy8Jw1jKI7Apdi43EIU iA5DUGdvwpRd47N5LXQAXfVBw3t4GJzznyTgzpDAFLojqX22Q9jtmFXh/qi87d+f O2dyziqGwQyP06j1XxNvHLKaIidUCPwh+ienB9+J5JvokPVXPyhcwRKnfpsBRaWR B+98s7o8nJMhkgzGGIBdvSLlgs7PcIBnYemoqtTYTvIjGPCWEpSx1JK7KKV1Ueid qcmf48TAtdnFyJ0fpPFFyMbvUjFp88+mOrM3ziGWosTIRfWRQppNgnPhS5XRyTv1 ntkGum5DLHVN3ltpFEXS =Jgfc -END PGP SIGNATURE-
Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/13/2015 12:43 PM, Robin H. Johnson wrote: > On Thu, Aug 13, 2015 at 10:36:16AM -0500, William Hubbs wrote: >> I understood the usefulness of this line to some when we were >> using CVS since it expanded into the ebuild revision, date, etc. >> >> This expansion doesn't take place under git, so now I don't >> understand the usefulness of this line. If I have missed >> something, can someone fill me in, or if it isn't useful any more >> can we consider removing it? > The following is the official answer of Infra, regarding the $Id$ > expansion. > > The intent is that the ONLY place the keywords are expanded, will > be in the rsync export. FUTURE tense, it's not ready yet. > > If there is demand (and I think the consensus is actually the > OPPOSITE), we could also have it expand on your local checkouts. > > It expands to the hash of the blob of that file; and from that, you > can identify which commits the blob exists in. > > The primary use case of it is to allow users to easily see what > version of a given ebuild they are using. > I honestly don't see the point of this when `git log` or even `git diff` or standard `diff` will tell you if what's in your overlay differs from the source. With some bash magic it could even be automated. The point of that 'feature' is to see what, if anything, has changed between one's overlay and Gentoo's running tree. A diff would not only be able to tell you *if* anything changed, but also *what*, without adding around 5-7 extra bytes per ebuild. Sure, it's only bytes, but when multiplied against the number of ebuilds we have, it can make a few hundred KB difference. When expanded, that number multiplies. Is it worth adding this extra bloat to something that a standard utility can expose better than a hash? Just my two cents. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVzbCnAAoJEAEkDpRQOeFwlvkP/1KVnAH09LmHlO7kFPdFhEvE IhoscaZc/Pve4QcLMwnWAq2T3Uq4EzqYW2hICyuOAvp6bvca1ybpv7U6k+FYws8V lSarmFidfd0LKRqwPzrEjZb6kVxkKefzsAyqAZK9JcU5AhkI6cjIjMRihbxSVAJv BphWmbZBVuU4ZmoRiUcGR0Qzhcd4D4K0qjk6R4r5yCKaU5ACXj+ul5FOiD4GmsKc 288YgkLO8l+MQhLAQ5Ie6lL5E3tfVzgJ2U0F6R7xIG0uT8kXU5p7OuBN3ATEP96E P92T6QIOGug4fjjpdInjQPMaY+NnF3x6LshHgRQXHO1lWNIceJKTX+em4VqU4JEH UCsWgh+QPppPXrXTNE0J94BMK0DLP2iiHxYFtKT8u7ABfhAOvuTbA6B/H2ujjIaT 919htZGbSt3JkLCo5/gxqrJbntmqG0hehYr25C/XTHXJ+c5B5reaWKwuYW1Smpg7 whVLUcEHVFiU32bMFiETKfNVIGa3mxNUfO9wHpqBD4lSUNr3eJao5R25t5NMDJkL /znRsFb5h49uZEASjBWTICIsKjfjqaydRS5oQ9VZZcxdo3azZboqxLeuEAUnSSrn H8/F6HNbSJ5MVetRG2DrLpWFCS94LSjhF4DYQk0xzK3lvMXHMrdhZI0G94ZTx9PW X2I5+Y9cj1mVLzWrxHyu =W4Zd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: .gitignore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/13/2015 06:29 PM, wireless wrote: > On 08/13/2015 05:28 PM, Duncan wrote: >> wireless posted on Thu, 13 Aug 2015 08:33:13 -0500 as excerpted: >> >>> On 08/12/2015 09:52 PM, Mike Frysinger wrote: On 12 Aug 2015 18:27, Brian Dolbec wrote: > 2) There is another alternate location that you can define > files to ignore locally without having to commit them to > .gitignore. Consider .gitignore a global setting. There is > another setting inside .git/info/exclude which is a local > config file that will persist and not be affected by > pulls. as i stated, there's no reason for these paths to ever be committed. conversely, some people (not unreasonably so) will place files in there that have historically had known meanings. adding these to the global gitignore is simply the right thing to do and negatively impacts no one. >>> >>> As a gentoo user now coding again, I find the need to have >>> things "logically organized" really helps in my efforts. Like >>> most others, I get codes from a variety of places and try to >>> follow the 'logical gentoo organization'. I use >>> /usr/local/portage extensively for ebuilds that I develop. >>> There is also /opt/ which seems to collect up a variety of >>> ebuilds > >> Confused... >> >> What do /opt and /usr/local/portage have to do with the gentoo >> repo's .gitignore, which should only need ignore settings for >> locations inside the main tree, /usr/portage by default? A >> .gitignore listing for /usr/portage/local and >> /usr/portage/distfiles, etc, makes sense, since that's inside the >> default tree location. But /opt and /usr/local/portage aren't >> inside that default location and are thus about as apropos to >> that as the price of tea on Mars, aren't they? > > /distfiles/ /local/ /packages/ > > Other postings in this thread mention /var/ and /usr/ My bad, I > thought those official directories that were up for discussion on > gitignore relevancy? > >> /usr/portage/local was the original location for the user's own >> personal ebuild space - an "overlay" if you will. >> /usr/portage/distfiles and /usr/portage/packages are there >> because that's where ports has put them for decades, and no-one >> has gotten around to changing it in portage yet. FreeBSD defines >> the use of /usr very differently to what Linux users are used >> to. >> >> Those dirs really should be in /var/portage, and the user's >> overlay has no business being under main tree itself > > > Ok, so why is net-analyzer/jffnms found in /usr/portage/distfiles > yet it is installed in /opt/ ? If jffnms was (properly) installed > like other net-analyzer packages, would it not be in the portage > tree? There is no reason for it to remain in /opt/, that I'm aware > of. But jffnms could benefit form gitignore as other packages do, > regardless of where it is installed. If I may take a stab at this: /usr/portage/distfiles is simply the files Portage needs to fetch in order to extract them, build, and install the package. If ./distfiles/ is in .gitignore, then nobody can accidentally commit a package's source tarball or other related file. /opt/ is just the installation location for the live system that it's being installed on. The Portage tree (known forward as the Gentoo repository) is the collection of ebuilds that allow a Gentoo system to build the software. It's historically been in /usr/portage/, and installs to a variety of locations, be it /bin, /sbin, /usr/bin, /usr/sbin, /lib, and so on. Without reading the ebuild, jffnms likely has special properties or is built with specific technologies that indicate its files belong in /opt. Given that the Gentoo repository by default resides in /usr/portage, a .gitignore file can only apply to paths *under* that particular path. So it would cover ./local and ./distfiles, but not /opt, as /opt is outside the /usr/portage location and not under Git control. Was I able to explain that sufficiently? > > > Looking at the documentation for gitignore it would seem that the > benefits of using gitignore on those /opt/ packages could be > useful; so would it not be up to the particular package maintainer > to make that decision? Regardless of where non-devs develop > packages for gentoo, using gitignore might be useful during the > development of the packages, particularly if it is destine for the > portage tree (eventually). > > Apologies in advance if I have missed some key points already > established by the gentoo dev community I'm certainly no whiz > with git*. /opt is simply the chosen place for certain programs to be installed based on how they are structured, their licensing, or the way similar packages get handled. Users can use the INSTALL_MASK variable in /etc/make.conf to exclude any paths from having files installed, but if things break they get to keep the pieces. > > > > James > tldr .gitignore just
Re: [gentoo-dev] RFC: EAPI 4 deprecated & ban
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/14/2015 03:05 PM, Johannes Huber wrote: > Hello Gentoos Penguins, > > if we want to attract more contributors we should consider to have > one supported EAPI (latest). EAPI 4 is the last not marked as > deprecated (< EAPI 5). The move in ebuilds from EAPI 4 to EAPI 5 is > very simple replacing the declaration. As we have now git in place > we could easily do this with one commit (awesome). > > So please discuss this to get it ready for decision on next > council meeting. > > Have fun, > I think it's a good idea, but as others in this conversation have indicated, it's not exactly a quick sed script. I'd rather see a reporting tool that can scan the tree and expose which packages (latest stable and latest ~arch only) are still on EAPI < 5. That way, developers would understand *where* the attention would be (cat/pkg-ver) and *what* work would need to be done (EAPI 3 -> 5, for example). As a bonus, it could accept an argument as its "less than" search. so `eapi-report 6` would show all packages with an EAPI under 6. That case isn't useful *now*, but it would be going forward and still meets the needs of understanding what and where work needs to be done. I have a 10 day work week coming up soon so I can't work on it immediately, but I wouldn't mind assisting in the creation of this tool. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVzudxAAoJEAEkDpRQOeFwEYsP/iCKVEAWgatC5k4crLEGnmRb 1e29e2RTWTuuQ9OPCNfJK017uFiky7psgFey/0TOB6c0E3onnVwJYIt452tkcI/C y91CfCPB5dAKhz0VG62WTbnUxKszRKgfBYVSd6a5aTfrQuchnmbGuirB+N4rc1Mh usJs2IrhDy8CHMe3P3hCXQ8DE/hGfTt05+ljoLM4pBiouoz2Zlda37uCJHsjkSYu L20imAu/u/w+DHuzmBQlhi7WLFEBaNXe/yck1w3/s4/UYOBOa/mSQ88ao1UfIZ08 QkFjpcnGOs20apVzv4lu/sgJ7GNSS92G5hsS5161TZF/wp+bBqD87vciHlkbANtN UIvQVxzUSKvNflmdmP1NqWKHXszuMQKSzMiBq19fgPd8t72ZwrOe5g2Pcp8lykov GDveUUGN3mqXRilO+RzbqXoQXgNEUxZAS5TzN1+fUNBQj4qajPDVVY1vgWkCA6bA mqF+l5jrbMBc6TmPja6sj8kcoIPRiAYMgmAdtZI5/MV4cIDFAbyJuSWbwcKw8WRz EkirDtqtWzyg1aKAKK9GAZiKlyBxPT/nzCayuyBmTxj0rABwkcOmb1LUIS5HR5kx EW1z/8GUTfIIc1aN/qI/GOiGrZa2H3BVYG3rdJEhjTE4UP8wUwgS3idZ0uKDSMES PLSfQooYoh1onIdfcABs =J28V -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Referencing bug reports in git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/14/2015 01:04 PM, Andrew Savchenko wrote: > On Thu, 13 Aug 2015 19:19:10 +0800 Ben de Groot wrote: >> I vote for a simple >> >> Bug: 333531 > > +1 > > Of course, for external bugs (e.g. in other projects) full URI > should be used. > > > Best regards, Andrew Savchenko > ++ - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVzuebAAoJEAEkDpRQOeFw+lEP/jzDH6e7fOGdKuLGafvM1n5j tg4otbjmK6p/IL5i3RoOP0e9dRejKjIjkiWEi5gdDhG82ZXfuK2F9ym9Z3OMsNI5 x/4uRk/0rU9Fa9Aaoo9Xwh7LUvL3DyB5qspLf45FZNTNX5qizHL+kmWv2Jl3ei9P rmS/dfVMZbAPguiaatiutTHPQ/MWRlv2NhNu7r9I1supI5cGs59O8nAp2Gc2IApI cGYozTWs5C73cPeEnzKnWNRsvvjyxE2tCTk84OGRAgCw9QcC7FJMOI32hcX6fUvY cckVBu19HRN+PJAGqF6ONjJm9KJ1iFKc77v2fg5hzrwAGyDf6VLeFVBUL9BZFAqI vPTfGV/TIu+ro6xLJFoTPcaKl9EQHbIXHZDbQyx7QpazPaALdunj7qAChFyVVPVU hA9kadV5sMO0mUqvue2vOw2bpqZnZMn3kO14trlsu7BrwPHPJ/8LQJCBAXXQOR1d 9vVZ5h0wl2XhQ3qBwlji+2y+zinCNJJ8FIFYyQdnjN1v53y1MKLssKM+OguiET4v ytfcxmI+PtbaL3Lx9zKeoEd37hxeGIa5HdEYEo6LRjFltKTTX0gwWAQHact/hHtD QaIVFHuIYfg2walhSJYj9n3gJpb8mx9vDT0eInhoFUumZyjfx1GXz9Az71pjliaP HnlMBdyUGldz4uq8ahnC =gih6 -END PGP SIGNATURE-
Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/20/2015 10:42 AM, Michał Górny wrote: > Hi, > > Right now, a number of game packages are using USE=dedicated to > control 'installing a dedicated game server only'. Aside to that, > some game packages also have USE=server that controls building the > server itself. Non-game package use USE=client and USE=server. > > In order to improve uniformity of USE flags across different > packages, the QA team would like to deprecate USE=dedicated and use > USE=client and USE=server as appropriate. > > The problems I see with USE=dedicated are: > > - it is game-specific. The term 'dedicated server' is not used > amongst other server/client model packages. > > - It uses negative logic. Instead of enabling something, it > disables client. Pretty much 'dedicated' == 'noclient'. Negative > logic is confusing. > > - In packages having USE=server as well, it can lead to really > absurd combinations, like what does 'USE=dedicated -server' mean? > Will it build no executables at all? If we add > REQUIRED_USE='dedicated? ( server )', this gets quite unfriendly. > > As an alternative, we would use USE=client and USE=server along > with proper IUSE defaults to control client & server builds > appropriately. Both flags use positive logic, and REQUIRED_USE='|| > ( client server )' is rather clear. > > Does anyone see any real problems with that? > Based on what I'm seeing in this thread, the problem seems to center around the description and application of the `dedicated` flag. I'm fully in favor of the `server` and `client` flags because they're clear and consistent. *However*, it was mentioned elsewhere in the thread that some games don't allow a client and a server at the same time. Personally I find that behavior odd and indicative of poor design, and I think packages that can't be built that way should have REQUIRED_USE or simply a `foo-server` package to unambiguously show that they're server-only. I'd rather see something to make client+server work for every single game instead of forcing people to use other packages or pick and choose; I see no reason why a gamer should have to choose between client and server. There's a perfectly legitimate use case of someone who hosts their own server but also plays the game, either on their own server or on someone else's. With an 'either or' approach, that use case is impossible. Those ebuilds need to be fixed. If any games I played were that way, I'd gladly help out with that. As it stands, I haven't figured out how to get a few games I'd like to see in the tree (Wizorb and A Virus Named Tom). With the games.eclass deprecated, I don't really have a "good practice" guide for making gaming ebuilds. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV1uHfAAoJEAEkDpRQOeFwdK8P/2iiwl3Nt1om4GOPe4OkZA8u a+ad28vmiFMOTchBU8Gdouom0ZFPIWNluxCfLzUNc5kMArDAUXUSqAudaloyYTVx q7x+6ihHGAchefVHT9xPVh/ny0gmKEIkLL6lFkPGGfP7cpv2Rucn4djIr6RPS4WV Ju3tZZifiemUUlfoOx836mUGOeRtWP8AcbeuAYu+ruB6gJmryQKUbuD6ezIEmgVy MAFjYCQZ4gx1NyzjlN1v5j+eLeDh+HoTQlJkECc2NWY1ULOkdWvjCpRMcjmKXDgI db6Cazs70jqQr/QIX7XcRPyemnci/wZqzJ6uzVZSM2LSn74Tbqvyu3ch5wzDKMlS VnF3LRx7YlM1+ggqVxFxOm3rjjLsUHdnoSzPYQCW0TwLPU+acwFHtDDUqBxkRyEg UCXa1I60AAbXf4QjPQG5S3P9eOKAal4iPfsf8IiQSHMpOUwgrA+4qK+amhr3nkwg g5TsWB9GkBndlYKxQyXiDwTPuZvZtDhjbfhddhLa/bmWV4LpcaTSDgRrmFXkv4oP 9cNdygCa2TdBMfd/9duenedaHgDhhvVNPhSsDPHTAP0vesXr7ntK41V9RDMgm0w5 CZAPYOr6Ew5v2SeK+hFwoVfjdpmmCHGtrqBjIfyzHTUuHj/YSFTDxRWaZVjS/m6o vXKxlcB2TySZX6pCZRje =LqFQ -END PGP SIGNATURE-
Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/21/2015 03:31 AM, Rich Freeman wrote: > On Fri, Aug 21, 2015 at 4:31 AM, Daniel Campbell (zlg) > wrote: >> Based on what I'm seeing in this thread, the problem seems to >> center around the description and application of the `dedicated` >> flag. I'm fully in favor of the `server` and `client` flags >> because they're clear and consistent. > > ++ > >> *However*, it was mentioned elsewhere in the thread that some >> games don't allow a client and a server at the same time. > > Can we actually get an example of one before we go making policy > based on what seems like a really strange case (one which I'm > skeptical actually exists)? I'm not aware of such use-case, as it was mentioned by someone else. It's a theoretical possibility, though, and games aren't always known for having sane build systems or programming practices, so I think it's worth considering. > > It seems that in these cases either REQUIRED_USE gets used, but > preferentially the build system should be fixed or the package > should be split. Agreed. > >> With the games.eclass deprecated, I don't really have a "good >> practice" guide for making gaming ebuilds. > > Just make them like any other ebuild. The main thing games.eclass > did was force users to be in the games group to run games, and > install them in a special location. > > The eclass isn't officially deprecated, but it probably should be. > You should install a game just like you'd install a word-processor > or a web browser. It is just another desktop application (99% of > the time). > Thanks, I'll keep that in mind when I get around to writing those ebuilds. I'll also consult the games team before committing. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV13ylAAoJEAEkDpRQOeFwWgsQAKYTlKXP1bgyN68cDbVddnfE kgggdVy3R2Zv0AHRfqbip4prrbbDv5+M0qifQ8RGa9WxQ4Fu5kVxUrFsJ1l2xO7O VNSYDeBl4NVC+AqePDSsqzKCWojYR8hMbEhBvsC3hsxGeD28dBJ5P3yhQMHORvSy T2K45wj/lXlJDKTrnI/3cwpWSNJM6u209pXLlU6XydsXt0lh9C+3pV2NGNuXuucw jSkA2cGxRCGQqaGxWcVjXyPr2tRkWsFYr1kxyNqaJ7Meb9kX5QUFzkwBZAWR6Eq4 HV7kiM8CLujDJapbN2NwpsBs6Bo5e4jlJwmw8+kOLeMVXBbZFzf5q/vy3+vB9hds ibGEc90tdEb+zo6lHMD8EhI7OlR5ckJ4yuLykzYqanB5bLzBXA9OKe/IgUtgrtVT RadKh0v42Qo6Rck1uzCus0ZiTME1cykvvyrz+wQIvl1PHrdArwtqPNSIOtVGnngt W2cjJUVs8bE2JA/ftHjrj7cLrsSicvJ9aRKCZLNMFHJIs7Wq923wQTCVZ/8/mhsf Z2eX74plPuwk6H/8EmJPNTW2JmA5R2t759chJcaSfEW/Tgc0w1nsoMUCWnwxjF5E x2Qxx5P7I0kEVqYXCJ2Z14NtRafO+Oq31t9OcxGuRYv/r/dK17w70uA652jr8FmX arJW7R1aiYqch1p6FKhM =Y7o9 -END PGP SIGNATURE-
Re: [gentoo-dev] games.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/21/2015 10:39 AM, Rich Freeman wrote: > On Fri, Aug 21, 2015 at 11:10 AM, hasufell > wrote: >> On 08/21/2015 08:50 AM, Ulrich Mueller wrote: On Fri, 21 Aug 2015, hasufell wrote: >>> Like allowing that devs may or may not use games.eclass, so that users cannot expect consistent behavior for games anymore? >>> >>> Sorry, but that is not accurate. Usage of games.eclass has >>> been deprecated by QA [1] (with the council's mandate [2]), so >>> devs should not use it any longer. >>> >>> Maybe QA should be stricter in enforcing its policies, in order >>> to avoid such false impressions in future? >>> >>> Ulrich >>> >>> [1] >>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summa ries#Games_team_policies_issue >>> >>> [2] https://projects.gentoo.org/council/meeting-logs/20140812-summary.tx t >>> >> >> >> May I remind you that >> >> """ - Motion: "The council encourages the games team to accept >> join requests and elect a lead. In the event they don't elect a >> lead within 6 weeks, we will consider the team as dysfunctional >> and thus disband it." Accepted with 6 yes votes and 1 >> abstention. """ >> >> has never happened? There has been no vote, but the team has not >> been considered dysfunctional. Instead we are just acting like it >> doesn't exist, more or less. Sounds good? > > Well, we did say we would disband it. We just didn't follow > through. Would you be happier if we did disband it? > > The goal was to try to leave the structure there in case anybody > steps up, but I don't really see the harm in acting as if the team > doesn't exist. It essentially doesn't. Disbanding it would just > make it formal. > > Sure, we did drop this, but I don't really see this line of > argument actually accomplishing anything productive. Creating a > games team that fixes these issues would be productive. Letting > others fix them is also productive. Nobody is opposed to having a > games project - it just seems like nobody cares enough to actually > make it happen. That's ok - we can still get things done. > What would be required to revive the games project? One of the reasons I became a dev was to help out the games team, and if it's defunct, I want to see what's necessary to fix it. I'm still a new dev (May 2015), but I wouldn't mind doing some dirty work if it means we can put squabbles like this behind us and get enough devs together to give game ebuilds the attention they deserve. I don't have a lot of free time, but sitting here discussing stuff isn't fixing anything, either... If I can spend what little Gentoo time I have on fixing things, I'd be glad to. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV138OAAoJEAEkDpRQOeFwSbAP/jBciQLb6oHqNyiXUEIyEWtq ja1arNrRtgLq3x6invviwB+AilkFPAcyVHGJkrwDxRPN0Ykt/VZ3Raf3BF4asCM8 zRTwEJHGvf+JsShMM5dujqdArhfoGNuRjdCNY8QfveVzBBDGtWLM6zGA/rhc/jDG 0OkLkaFiTSx6qy9aEDoj+PfBSpZcEdNSWx3zxthrWbnFO3qD6hgy8PUizwsRM2+t PKvD6t6uaraql15+dcFGosiT9KgwjvONvEHaH12T8n73VR3xgbYFo1zM44LbQ8kH h90zjOU7rKKy6Pplbqvz6rlWpytOq5+KrLuikYnd4wcmLxYEq/NWzsStOVUNq1Vn IeUyxTjxRgpHvdlNgxiqgVpbAGxR7uR0DM1Ayj7K0ow1b2jRu+/A6XLn7spV+f3Z fPA0Kz/FO7lEaOn561ENdBd6QUAYf5zpNlOVyD+GSWGUWsCp3fwqfZc/xSXetzCL TyYJlcvpEFcwzUSxactkVqCLIAaxubxna0SnNclBVoIrocvOk9MF7ayCXHNRX2uC nW01Ye50x1WsHflzLyHEVZrh6uaovhBqqvAwkD0+FW4jeJnO5fTfkHzcB8egqk78 0K5K5u25cuGpteVIzvFdudxEEm9Owf5NdZkdrX5ay61HSB4QmOfHRmnbJk1xOj+u wFjThVYPKxIyASR6uhun =FlQB -END PGP SIGNATURE-
Re: [gentoo-dev] games.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/21/2015 02:09 PM, James Le Cuirot wrote: > On Fri, 21 Aug 2015 12:42:07 -0700 "Daniel Campbell (zlg)" > wrote: > >>> Sure, we did drop this, but I don't really see this line of >>> argument actually accomplishing anything productive. Creating >>> a games team that fixes these issues would be productive. >>> Letting others fix them is also productive. Nobody is opposed >>> to having a games project - it just seems like nobody cares >>> enough to actually make it happen. That's ok - we can still get >>> things done. >> >> What would be required to revive the games project? One of the >> reasons I became a dev was to help out the games team, and if >> it's defunct, I want to see what's necessary to fix it. I'm still >> a new dev (May 2015), but I wouldn't mind doing some dirty work >> if it means we can put squabbles like this behind us and get >> enough devs together to give game ebuilds the attention they >> deserve. I don't have a lot of free time, but sitting here >> discussing stuff isn't fixing anything, either... If I can spend >> what little Gentoo time I have on fixing things, I'd be glad to. > > At last, some positivity! As I said before, I would like to work on > a few games too. I would certainly take up any Java-based ones and > I have four of those in mind already. I've dabbled with ebuilds for > many other games in the past, some already in the tree and some > not, and some from source, some not. The Humble Bundle games are of > particular interest to me. I'm obviously bogged with the more > boring Java stuff for the foreseeable future though so as much as > I'd like to, stepping up to be a lead would be unwise. I, too, have interest in Humble Bundle games since most of the games I have and can test come from them. > > Do we actually need a team? Games come in all shapes and sizes so > I think the assertion that they should be handled like any other > application is somewhat valid. Many games are commercial so it's > likely that certain games would only be handled by one or two team > members anyway. The main thing I've been concerned about in the > past is how to handle data. Should it be packaged separately? How > do we handle the cdinstall flag these days when there are also > multiple online sources like Humble Bundle and GOG? Do we just do > whatever seems best for the game in question? I'd be happy to hold > such discussions in a distro-wide fashion though. > Despite games being "just another application", I think they differ simply because they're a *different type* of application. Fonts and icon-sets are similar to games in that they are mostly assets, and they get the separate treatment they deserve. Games are an odd mix of software and assets, so I think they deserve to be considered their own type of software. They're also built in different ways than most typical software is. Great question on the 'cdinstall' flag. Games from Humble Bundle and GOG are basically fetch-restricted and require the user to put the relevant distfile in /usr/portage/distfiles to install. 'cdinstall' could be applied only for games that the user wants to install via optical media. With it off, it could default to the fetch restriction. However, that could result in different checksums for the source. It may not be feasible to go the cdinstall route forever. Honestly, I'd need a concrete example and knowledge of the other releases to offer a better-informed opinion. I think hasufell works on games... thoughts? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV2CW8AAoJEAEkDpRQOeFwmD4QAK+XDYvgKngBsF2PAZahSrSz zxkp3fRdkTf81ZojI5u3bqby15n93026FoIXCkWEdjcJnV4xIxGDLSqIJ7BfxObS MtGsk48upYO3K0/af4AYCLOU7P8B22SNrkgCYyS0v++4ZOEkdLV+i2TdCXwSEXNW lJig9X3iot1oYRsHHNnmlfPhkHgZsaeox48m1DazxlcWbVDHvcq8kiATaUyOLB1O +nOJEXBMI9bXaUjCW7kX7OGROJrzP6zpU/lGoEE4+jHg1X39chlIUJnJbaBkcHUG MoUc25NLB72C+dPhnsQQPMh/MA4bI6K2IhpIWR1Pthebb+GslwBMxxKkxop+tRpV 2nuz9qRRqVQWN55ugwBlFhG8nUA+jIIFaWNKl/4sF9FyZ1AT/yoZYldvlRF6OtT2 sm9H0XlXr2kdO3kFdD9ZiyA/APivAtBTUxeDGmvAd/iuzrjOUhXNX8zmuVYQGGtu 3C4y3IK9nFpFtAInfTGuwq5iRtfVOt0DmEEwF6ad8qofxigopRkKX0eWOgapeZtx 0PkUjv99bt2lc3Hrn0kA9ECUJ8X8pT3aZhVSuV/bZpwG1fqOTkNzFEQgm15PyMVN v45z3/s6A4dJgZtGdlAB6c0/8kA+Ae4Fg5n65mQJqIoS2UqEQGf8FaTv0YpKYwc1 Qngd4iwJUUpcgm2DNey9 =A20Q -END PGP SIGNATURE-
Re: [gentoo-dev] games.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/22/2015 04:10 AM, hasufell wrote: > On 08/22/2015 09:33 AM, Daniel Campbell (zlg) wrote: >> On 08/21/2015 02:09 PM, James Le Cuirot wrote: >>> On Fri, 21 Aug 2015 12:42:07 -0700 "Daniel Campbell (zlg)" >>> wrote: >> >>>>> Sure, we did drop this, but I don't really see this line of >>>>> argument actually accomplishing anything productive. >>>>> Creating a games team that fixes these issues would be >>>>> productive. Letting others fix them is also productive. >>>>> Nobody is opposed to having a games project - it just seems >>>>> like nobody cares enough to actually make it happen. That's >>>>> ok - we can still get things done. >>>> >>>> What would be required to revive the games project? One of >>>> the reasons I became a dev was to help out the games team, >>>> and if it's defunct, I want to see what's necessary to fix >>>> it. I'm still a new dev (May 2015), but I wouldn't mind doing >>>> some dirty work if it means we can put squabbles like this >>>> behind us and get enough devs together to give game ebuilds >>>> the attention they deserve. I don't have a lot of free time, >>>> but sitting here discussing stuff isn't fixing anything, >>>> either... If I can spend what little Gentoo time I have on >>>> fixing things, I'd be glad to. >> >>> At last, some positivity! As I said before, I would like to >>> work on a few games too. I would certainly take up any >>> Java-based ones and I have four of those in mind already. I've >>> dabbled with ebuilds for many other games in the past, some >>> already in the tree and some not, and some from source, some >>> not. The Humble Bundle games are of particular interest to me. >>> I'm obviously bogged with the more boring Java stuff for the >>> foreseeable future though so as much as I'd like to, stepping >>> up to be a lead would be unwise. >> >> I, too, have interest in Humble Bundle games since most of the >> games I have and can test come from them. >> >> >>> Do we actually need a team? Games come in all shapes and sizes >>> so I think the assertion that they should be handled like any >>> other application is somewhat valid. Many games are commercial >>> so it's likely that certain games would only be handled by one >>> or two team members anyway. The main thing I've been concerned >>> about in the past is how to handle data. Should it be packaged >>> separately? How do we handle the cdinstall flag these days when >>> there are also multiple online sources like Humble Bundle and >>> GOG? Do we just do whatever seems best for the game in >>> question? I'd be happy to hold such discussions in a >>> distro-wide fashion though. >> >> Despite games being "just another application", I think they >> differ simply because they're a *different type* of application. >> Fonts and icon-sets are similar to games in that they are mostly >> assets, and they get the separate treatment they deserve. Games >> are an odd mix of software and assets, so I think they deserve to >> be considered their own type of software. They're also built in >> different ways than most typical software is. >> > > Games differ in a lot of ways and they _require_ different > policies. In some cases this also means more lax policies and in > some cases more strict policies. > > An example is unbundling libraries. While unbundling libraries is > often a good idea for regular well-maintained projects, it can > often cause various problems for games: * games upstreams often > modify 3rd party libraries * games upstreams often use libraries in > very fishy ways, so you really need a very specific version * for > proprietary games breakage often happens randomly at runtime * > proprietary games may also break silently when library XY is bumped > in the tree Great points. Games often do rely on their bundled libraries, and that's one of the biggest exceptions to the rule that I see *needs* to apply to games; if bumping a dependent library breaks it, then we at least need an option to make sure the game continues to work. > I've seen both opensource games and proprietary games that break > when you unbundle libraries. One example is > games-action/supertuxkart that was broken by a lot of packagers > (including archlinux), because they didn
Re: [gentoo-dev] RFD: News item format 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I don't see why backwards compatibility would be a problem. The older news format spec supports fewer features, so the new spec should be much like newer EAPIs and 'just work'. I'm in favor of all the changes you laid out. A good number of us are already familiar with git-style limitations, and they're rather sane to begin with. I could see issues with bigger changes fitting into 50 characters, but I guess that's what creative wording is for. :) It's odd that news items even have the Content-Type attribute. Before removing it, are there any other formats we could feasibly want in the future? I can't think of any formats we'd want to use, but maybe someone else has an idea. In general, though, I'm in favor of the changes if it makes life easier for those writing news. I don't write news items right now, but I may end up doing it in the future. Sorry for top-posting. I didn't see a way to do proper replies in K-9. On January 12, 2016 10:13:39 AM PST, Ulrich Mueller wrote: >In its last meeting the council has accepted an extension of the >news item format which allows EAPI=5 style package dependency >specifications. This has triggered a discussion if this change is >backwards or forwards compatible, and what should be the new format's >version number [1]. Also it is not entirely clear if the term >"backwards-compatible" used in GLEP 42 correctly describes what was >originally intended [2]. > >In any case, both portage [3] and paludis [4] will have to be updated >for the new format because the change is not forwards-compatible. > >Therefore, we could use the opportunity to add some other features. >So far, this includes: > >1. Display-If-Installed: Allow EAPI=5 style package dependency > specifications (see above). > >2. Display-If-Profile: Allow wildcards like default-linux/* [5]. > >3. Title: Increase maximum length. In the past, devs repeatedly > struggled with the current 44 character limit. (Can anyone > enlighten me where this originates from? I cannot find anything in > the discussions around the time when GLEP 42 was submitted.) > The eselect news reader could still display a 51 character title > in one line for the "list" and "read" commands, on an 80 character > wide terminal. > I suggest we round this down to a maximum length of 50 characters, > which (together with the 72 character limit for the body) would > nicely agree with the limits recommended for git commit messages. > >4. Content-Type: Only one value is allowed for this header, namely > text/plain. We might as well drop it, because any changes there > will require an increment of the News-Item-Format. > >If these changes find agreement, I would prepare a new GLEP for news >item format 2.0. > >Ulrich > > >[1] https://bugs.gentoo.org/show_bug.cgi?id=568068#c4 >[2] >https://archives.gentoo.org/gentoo-dev/message/d30de011db9067ae3cc298de2b4ee1b2 >[3] >https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/news.py?id=7c94014a32d173ae61919b762140ac1c32d3b522#n273 >[4] >http://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/e_repository_news.cc?id=1684b446715907515359cd310c1e7bd93bad5a2e#n326 >[5] https://bugs.gentoo.org/show_bug.cgi?id=290038 - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAlaVkQkACgkQASQOlFA54XAYuQ/9F0qt4BaPTan+rMBd MkbjA1A4EeaLgGT0BAlv5oKhfR5VC4fNoWcfCB+Z11Bkyi+8DRGLWoEqF1KvFKsb CLu8a8Q/+T34JuvKznCJrHfnkFYwARVXpOVX70t3Sr50BSpe5lvmQ4PQ8PpOFTnJ O4bo9GjxKTujVvu1LxYSv3CLJ6AV9HANsl5rkBQ+TKi4qrwqBTWK4VGNTCon/DFt EUTRuz7TXlpE6quMTTk7Wx8yldRgC7mL2SwYsH0KosrBaMTv5yVWipZMdEP6oPRp ovYhPNgPYPrct8DuiOOXvNJms8Ll5oS/m07w5MUr7KzWAoWjFluQAVR+HOACfXuk 7YiSk9FbH+a3t6aEGNrEX7VRcG8A2UG6nDsc5GNXLc+ObPvfsykXZs6vchfC8J+j wJp8R/dXecAyw9HmjQ6cx3N3lw65YG+3I1cK883GuvGGb7P9BOeWuloouhqEfOc5 OaptMrWWJM9T8FNzgZVXc8tJmrCexw1HFKUfjhcJinIffHfRoeIjmSJcTtKliW/k 0VHtmhjr4OkBr+wcjf5uZEAstq/4/Jp1ArS3URaXtDEBuY0xKaR/WLMPtcuu4X1K fFkah8qS/jR8qqE9KecULE25c8C47im6EJGk6Wgzb/8MNx3J4iZ8P0PHS+kLEZFq uyrSyEwwvx2ES92sDb+EaXW0B08= =7A0/ -END PGP SIGNATURE-
