Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Daniel Campbell (zlg)]

-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] Need design help/input for eclean-kernel

[Daniel Campbell (zlg)]

-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] Repo mirror & CI project news: 'stable' gentoo branch, new repo stats, faster CI

[Daniel Campbell (zlg)]

-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] [RFC] Masterplan for solving LINGUAS problems

[Daniel Campbell (zlg)]

-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] [RFC] Global USE=gui

[Daniel Campbell (zlg)]

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] Package up for grabs

[Daniel Campbell (zlg)]

-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] RFD: News item format 2.0

[Daniel Campbell (zlg)]

-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-

Re: [gentoo-dev] games.eclass

[Daniel Campbell (zlg)]

-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)
 z...@gentoo.org 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

[Daniel Campbell (zlg)]

-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) 
 z...@gentoo.org 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't ask upstream if it was a
 good idea to unbundle Irrlicht. It wasn't. Another example is
 games-rpg/baldurs-gate-ee which has some weird graphical glitches
 when you unbundle libraries.
 
 The primary concern of gamers is that the game runs and that they
 can reasonably install it (see the games-roguelike/nethack bug
 which was unsolved for 8 years).

What happened with that bug? 8 years? That's insane!

 Because of that, I provide a 'bundled-libs' USE flag for almost
 all proprietary games I package (e.g. those from GOG). So in case
 something breaks, the user can still opt-out of all this.

Right, that flag is really handy in my experience. If you've worked on
Torchlight, Rochard, or Shatter, I'd like to thank you for your work
on them. 'bundled-libs' is a lifesaver with those games because they
*do* use modified libraries and it's the path of least pain to get
them to work. Sure

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Daniel Campbell (zlg)]

-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)
 z...@gentoo.org 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

[Daniel Campbell (zlg)]

-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 hasuf...@gentoo.org
 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] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Daniel Campbell (zlg)]

-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] Re: Referencing bug reports in git

[Daniel Campbell (zlg)]

-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] RFC: EAPI 4 deprecated ban

[Daniel Campbell (zlg)]

-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] Infra plans regarding $Id$ - official answer...

[Daniel Campbell (zlg)]

-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

[Daniel Campbell (zlg)]

-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?
 
 snip /distfiles/ /local/ /packages/ end/snip
 
 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 applies to the Gentoo repository, not an entire
Gentoo system.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: 

Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Daniel Campbell (zlg)]

-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] Re: useflag policies

[Daniel Campbell (zlg)]

-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] .gitignore

[Daniel Campbell (zlg)]

-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 flop...@gentoo.org
 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

[Daniel Campbell (zlg)]

-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 
 chith...@gentoo.org 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] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Daniel Campbell (zlg)]

-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] Git Migration: go-live!

[Daniel Campbell (zlg)]

-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/)

[Daniel Campbell (zlg)]

-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 hasuf...@gentoo.org
 napisał(a):
 
 On 08/09/2015 09:56 PM, Michał Górny wrote:
 Dnia 2015-08-09, o godz. 16:09:29 hasufell
 hasuf...@gentoo.org napisał(a):
 
 On 08/09/2015 03:58 PM, Michael Weber wrote:
 commit: 40b3fd64ec9c5d6d94f0f0897740bc77622c24a1 
 Author: Michael Weber xmw AT gentoo DOT org 
 AuthorDate: Sun Aug  9 13:58:26 2015 + Commit:
 Michael Weber xmw AT gentoo DOT 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/)

[Daniel Campbell (zlg)]

-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 flop...@gentoo.org
 wrote:
 On Sun, Aug 9, 2015 at 11:30 AM, hasufell hasuf...@gentoo.org
 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] Re: rfc: openrc mount service prototype

[Daniel Campbell (zlg)]

-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)
 z...@gentoo.org 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] useflag policies

[Daniel Campbell (zlg)]

-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] useflag policies

[Daniel Campbell (zlg)]

-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
 birc...@gentoo.org 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] Re: rfc: openrc mount service prototype

[Daniel Campbell (zlg)]

-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 a...@gentoo.org 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 
 alo...@gentoo.org wrote:
 
 On 29 July 2015 at 23:20, William Hubbs
 willi...@gentoo.org 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] rfc: improve file system mounting and unmounting in OpenRC

[Daniel Campbell (zlg)]

-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] rfc: improve file system mounting and unmounting in OpenRC

[Daniel Campbell (zlg)]

-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] New Project: MATE

[Daniel Campbell (zlg)]

-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)

[Daniel Campbell (zlg)]

-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-