Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote: >On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote: >> * Posting to the list will only be possible to Gentoo developers and >> whitelisted additional participants. > >This is so contrary to what I and I thought Gentoo stands for: >openness, transparency, inclusiveness even when these require a rather >thick skin and result in high noise. It's a price worth paying. > >I guess I should a) pay more attention to council elections b) consider >the idea that the whole council thing as it stands now is just not >working. > Wow. I couldn't have said it better. Seems we're turning into an elitist club or something... I wonder how many users we're going to loose on this one. Well done council :-( -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpp26P9mjsBM.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote: > * Posting to the list will only be possible to Gentoo developers and > whitelisted additional participants. This is so contrary to what I and I thought Gentoo stands for: openness, transparency, inclusiveness even when these require a rather thick skin and result in high noise. It's a price worth paying. I guess I should a) pay more attention to council elections b) consider the idea that the whole council thing as it stands now is just not working. -- Eray
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 01/09/2018 07:37 PM, Philip Webb wrote: > > I'm very sorry that Council approved this proposal > & hope that it will soon see sense & rescind it. In an effort to reduce noise on the gentoo-dev mailing list, Gentoo will now require every user to send an email to the gentoo-dev mailing list asking us to let him post to the gentoo-dev mailing list. \_(ツ)_/¯
Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue
On 01/09/2018 07:07 PM, William Hubbs wrote > > However, I'm not sure how to deal with the hard link issue in a way that > will not break service scripts. > Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by default, but they have the liberty of requiring a relatively new Linux kernel. The larger problem there is that, unless you have some kernel protection built-in, the "Z" type in the tmpfiles.d spec is always going to be exploitable: * https://github.com/OpenRC/opentmpfiles/issues/3 * https://github.com/systemd/systemd/issues/7736 (I didn't realize at the time that the OpenRC fix still contained a race condition.) Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory that is not writable only by yourself and root. There's some precedent for this in e.g. https://wiki.gentoo.org/wiki/Hardened/Grsecurity_Trusted_Path_Execution where they refuse to *execute* something that is writable by others. But a solution like that would break existing scripts. If it's any consolation, the tools like chown, chgrp, chmod, setfacl, etc. are all vulnerable to the same issue themselves. GNU chown has the "--from" flag (which still contains a race, by the way), but the other tools don't, and are all exploitable in the same way. Again the advice seems to be "don't do things if somebody can write to the directory you're in." Here's a very tedious proposal for OpenRC: 1. Create a new helper, called e.g. "newpath", that is like checkpath but only creates things, and doesn't modify them. 2. Have newpath throw a warning if it's used in a directory that is writable by someone other than root and the OpenRC user. This will prevent people from creating /foo/bar after /foo has already been created with owner "foo:foo". In other words, service script writers will be encouraged to do things in a safe order. Since we're starting over, this might even be made an error. 3. Deprecate checkpath 4. Wait a million years for people to switch from checkpath to newpath 5. Get rid of checkpath I'm not even sure that this solves the problem completely, but it's the only idea I've got left.
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel wrote: > During the last Gentoo council meeting, the decision was made to implement > changes to the gentoo-dev mailing list [1]. > > These changes affect only the gentoo-dev mailing list, and will come into > effect on 23 January 2018. > > * Subscribing to the list and receiving list mail remains as it is now. > * Posting to the list will only be possible to Gentoo developers and > whitelisted additional participants. > * Whitelisting requires that one developer vouches for you. We intend this > to be as unbureaucratic as possible. > * Obviously, repeated off-topic posting as well as behaviour against the > Code of Conduct [2] will lead to revocation of the posting permission. > > If, as a non-developer, you want to participate in a discussion on > gentoo-dev, > - either reply directly to the author of a list mail and ask him/her to > forward your message, > - or ask any Gentoo developer of your choice to get you whitelisted. > > If, as a developer, you want to have someone whitelisted, please comment on > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching > for a contributor you are expected to keep an eye on their activity. It seems like the obvious way this fails is some Gentoo developer acks one of the problem people. I don't think that's particularly unlikely. Then what do we do?
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
180109 Andreas K. Huettel wrote: > During the last Gentoo council meeting, the decision was made > to implement changes to the gentoo-dev mailing list [1]. > These changes affect only the gentoo-dev mailing list > and will come into effect on 23 January 2018. > > * Subscribing to the list and receiving list mail remains as it is now. > * Posting to the list will only be possible to Gentoo developers and > whitelisted additional participants. > * Whitelisting requires that one developer vouches for you. We intend this > to be as unbureaucratic as possible. > * Obviously, repeated off-topic posting as well as behaviour against the > Code of Conduct [2] will lead to revocation of the posting permission. > > If, as a non-developer, you want to participate in a discussion > on gentoo-dev, > - either reply directly to the author of a list mail and ask him/her to > forward your message, > - or ask any Gentoo developer of your choice to get you whitelisted. > [1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt > [2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct I'm very sorry that Council approved this proposal & hope that it will soon see sense & rescind it. As an ordinary user since 2003, I've subscribed to user + dev lists & have rarely encountered bad behaviour on either : it looks as if a sledge-hammer is being used to crack a nut. I followed the recent discussion here, but didn't offer comment, as there seemed to be little rationale or evidence behind the proposal & I didn't expect Council to pay any attention. That said, I would like to be able to offer my views on the dev list, which is likely to be rarely & will always be polite, as I have done occasionally during the past 15 years . Is one of the devs willing to sponsor me ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue
All, please take a look at the following issue. https://github.com/openrc/openrc/issues/195 The first part of the fix is committed to master as shown on the issue; checkpath should *never* follow symbolic links when changing ownership, so I have moved to the lchown call instead of chown. However, I'm not sure how to deal with the hard link issue in a way that will not break service scripts. If anyone has any suggestions for this, let me know. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Tue, Jan 9, 2018 at 5:20 PM, Francesco Riosa wrote: > > 2018-01-09 22:20 GMT+01:00 Andreas K. Huettel : > >> [...] > > > >> * Whitelisting requires that one developer vouches for you. We intend this >> to be as unbureaucratic as possible. >> > > May I ask to some random developer to vouche for me (Francesco Riosa > a.k.a. vivo)? > I'd like to be able to seldom post here. > Yes > > [...] > >> [1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt >> [2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct >> [3] https://bugs.gentoo.org/644070 (alias g-dev-whitelist) >> >> -- >> Andreas K. Hüttel >> dilfri...@gentoo.org >> Gentoo Linux developer >> (council, toolchain, perl, libreoffice, comrel) > > >
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
2018-01-09 22:20 GMT+01:00 Andreas K. Huettel : > [...] > * Whitelisting requires that one developer vouches for you. We intend this > to be as unbureaucratic as possible. > May I ask to some random developer to vouche for me (Francesco Riosa a.k.a. vivo)? I'd like to be able to seldom post here. [...] > [1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt > [2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct > [3] https://bugs.gentoo.org/644070 (alias g-dev-whitelist) > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, perl, libreoffice, comrel)
[gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
During the last Gentoo council meeting, the decision was made to implement changes to the gentoo-dev mailing list [1]. These changes affect only the gentoo-dev mailing list, and will come into effect on 23 January 2018. * Subscribing to the list and receiving list mail remains as it is now. * Posting to the list will only be possible to Gentoo developers and whitelisted additional participants. * Whitelisting requires that one developer vouches for you. We intend this to be as unbureaucratic as possible. * Obviously, repeated off-topic posting as well as behaviour against the Code of Conduct [2] will lead to revocation of the posting permission. If, as a non-developer, you want to participate in a discussion on gentoo-dev, - either reply directly to the author of a list mail and ask him/her to forward your message, - or ask any Gentoo developer of your choice to get you whitelisted. If, as a developer, you want to have someone whitelisted, please comment on bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching for a contributor you are expected to keep an eye on their activity. [1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt [2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct [3] https://bugs.gentoo.org/644070 (alias g-dev-whitelist) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-dev-announce] [RFC/announcement] ARM64 project / architecture team
On Tue, 2018-01-09 at 08:29 -0500, Aaron Bauman wrote: > > On January 8, 2018 4:32:29 AM EST, Mart Raudsepp > wrote: > > Hello, > > > > I have created a new ARM64 project[1] as an architecture team > > project, > > as I don't find it appropriate to handle this under the ARM project > > and > > all its legacy (including confusing stabilization rules, etc). It > > is > > also clearer that way, who is taking care of arm and who arm64, > > based > > on the members list. > > > > The current main goal is to fix up the deptree and get some arm64 > > profiles stable. To that effect, I'd like to ask package > > maintainers to > > kindly consider with arm64 as they CC architecture teams for > > (re)keywording or stabilization, as if it was a stable arch. > > > > New members are expected to have long-term interest in the > > architecture > > and the work involved with that. Or responsibly removing themselves > > from the project when their short-term interest fades. > > > > > > [1]: https://wiki.gentoo.org/wiki/Project:ARM64 > > It is great to see you have reached the point of creating the arm64 > project :) > > Would you like security to CC as well while to assist the arch as you > work toward a stable profile? This would not hold/delay the security > bug process until you are officially security supported, but I > believe it will help achieve your goal of stabilization. I would like arm64 to be CCed when appropriate (older version is marked arm64 stable) as a courtesy on security bugs as well as STABLEREQ and KEYWORDREQ bugs, and not hold back any security things for now, yes. > If you desire to do so, security team can discuss support and our > internal way forward to assist. I think we should reach a stable profile first, or be much closer to it. Mart
[gentoo-dev] Re: Last-rites: media-video/2mandvd
Andreas Sturmlechner posted on Tue, 09 Jan 2018 02:49:27 +0100 as excerpted: > # Andreas Sturmlechner (09 Jan 2018) > # Dead upstream, depends on dead Qt4. > # Bug #643976. Masked for removal in 30 days. > media-video/2mandvd Is there a timetable for the "dead" qt4 removal yet? Where will it go when removed, kde-sunset, graveyard, or...? I'm asking because I still run the not in-tree any longer superkaramba, which wasn't ported to kde-frameworks5/qt5. That's the only package (beyond a handful of kde4 packages and use-flag-triggers on other packages supporting it) I have still depending on qt4, so a timetable as to qt4 removal giving me some idea how long I have to find, install and configure an alternative, and an idea where I'll be looking for it if I don't get that conversion done by then, would be very useful. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] [PATCH] profiles.desc: Explicitly indicate maintainers for each profile
W dniu wto, 09.01.2018 o godzinie 11∶15 -0500, użytkownik Alec Warner napisał: > On Tue, Jan 9, 2018 at 10:11 AM, Alec Warner wrote: > > > > > On Tue, Jan 9, 2018 at 9:43 AM, Michał Górny wrote: > > > > > Add @MAINTAINER comments before each profile set indicating > > > the effective maintainer for the following set of profiles. While most > > > of those entries may seem obvious at first, I expect that some > > > of the sub-profiles will eventually 'change hands', e.g. the /hardened > > > sub-profiles would be maintained by Hardened, etc. > > > > > > The main goal is to provide a clear indication of who maintains each > > > profile. This will be of great help both to bug-wranglers (who currently > > > have to pretty much guess who to assign profile bugs to) and to other > > > developers who plan to commit larger changes and want to get ACK from > > > appropriate parties. > > > --- > > > profiles/profiles.desc | 23 +++ > > > 1 file changed, 23 insertions(+) > > > > > > diff --git a/profiles/profiles.desc b/profiles/profiles.desc > > > index 66dd7a32799f..8c9bd78143a1 100644 > > > --- a/profiles/profiles.desc > > > +++ b/profiles/profiles.desc > > > @@ -7,6 +7,7 @@ > > > #arch profile_directory status > > > > > > # Alpha Profiles > > > > > > How are machines supposed to read this data? > > Can we consider structured data? > > > > Sorry using more words: > > Currently the data is 'structured' in that its space separated data; and > you can probably use basic csv parsers to get at it (but not comments.) Now > we are adding a maintainer field. But its in a comment (so machines can't > read it). So how will machines read this data; or just make an explicit > goal that machines shouldn't. > Similar to eclassdoc. Grep for @MAINTAINER comment preceding the profile, read the line and grab e-mail address(es). This is a non-obligatory extension. We can't change the file format without breaking existing tools. Comments are safe. -- Best regards, Michał Górny
[gentoo-dev] eselect-1.4.11: updated profile module
eselect-1.4.11 contains two changes in the profile module: - "eselect profile list" now shows the status of each profile (stable/dev/exp) in addition [1]. - "eselect profile set" will refuse to select an experimental profile. If you know what you're doing, you can override this limitation with the --force option, or by specifying the profile's name instead of the number. Please give this version some testing. I intend to go for fast-track stabilisation, i.e. file a stable request on the next weekend. Ulrich [1] https://bugs.gentoo.org/643864 pgp0zdQghPO7M.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] profiles.desc: Explicitly indicate maintainers for each profile
On Tue, Jan 9, 2018 at 10:11 AM, Alec Warner wrote: > > On Tue, Jan 9, 2018 at 9:43 AM, Michał Górny wrote: > >> Add @MAINTAINER comments before each profile set indicating >> the effective maintainer for the following set of profiles. While most >> of those entries may seem obvious at first, I expect that some >> of the sub-profiles will eventually 'change hands', e.g. the /hardened >> sub-profiles would be maintained by Hardened, etc. >> >> The main goal is to provide a clear indication of who maintains each >> profile. This will be of great help both to bug-wranglers (who currently >> have to pretty much guess who to assign profile bugs to) and to other >> developers who plan to commit larger changes and want to get ACK from >> appropriate parties. >> --- >> profiles/profiles.desc | 23 +++ >> 1 file changed, 23 insertions(+) >> >> diff --git a/profiles/profiles.desc b/profiles/profiles.desc >> index 66dd7a32799f..8c9bd78143a1 100644 >> --- a/profiles/profiles.desc >> +++ b/profiles/profiles.desc >> @@ -7,6 +7,7 @@ >> #arch profile_directory status >> >> # Alpha Profiles > > > How are machines supposed to read this data? > Can we consider structured data? > Sorry using more words: Currently the data is 'structured' in that its space separated data; and you can probably use basic csv parsers to get at it (but not comments.) Now we are adding a maintainer field. But its in a comment (so machines can't read it). So how will machines read this data; or just make an explicit goal that machines shouldn't. -A > > -A > > >> +# @MAINTAINER: al...@gentoo.org >> alpha default/linux/alpha/13.0stable >> alpha default/linux/alpha/13.0/desktopstable >> alpha default/linux/alpha/13.0/desktop/gnome stable >> @@ -19,6 +20,7 @@ alpha >> default/linux/alpha/17.0/desktop/gnome/systemd >> exp >> alpha default/linux/alpha/17.0/developer exp >> >> # AMD64 Profiles >> +# @MAINTAINER: am...@gentoo.org >> amd64 default/linux/amd64/13.0 >> stable >> amd64 default/linux/amd64/13.0/selinux >> dev >> amd64 default/linux/amd64/13.0/desktop >> stable >> @@ -48,6 +50,7 @@ amd64 default/linux/amd64/17.0/x32 >> dev >> >> # Experimental SYMLINK_LIB=no profiles >> # Run app-portage/unsymlink-lib *before* switching the profile. >> +# @MAINTAINER: mgo...@gentoo.org >> #amd64 default/linux/amd64/17.1 exp >> #amd64 default/linux/amd64/17.1/selinux exp >> #amd64 default/linux/amd64/17.1/hardened exp >> @@ -63,6 +66,7 @@ amd64 default/linux/amd64/17.0/x32 >> dev >> #amd64 default/linux/amd64/17.1/systemd exp >> >> # ARM Profiles >> +# @MAINTAINER: a...@gentoo.org >> arm default/linux/arm/13.0 stable >> arm default/linux/arm/13.0/desktop dev >> arm default/linux/arm/13.0/desktop/gnomedev >> @@ -90,6 +94,7 @@ arm default/linux/arm/13.0/armv7a/desktop/gnome >>dev >> arm default/linux/arm/13.0/armv7a/developer dev >> >> # ARM64 Profiles >> +# @MAINTAINER: ar...@gentoo.org >> arm64 default/linux/arm64/13.0dev >> arm64 default/linux/arm64/13.0/desktopexp >> arm64 default/linux/arm64/13.0/desktop/systemddev >> @@ -102,6 +107,7 @@ arm64 default/linux/arm64/17.0/developer >> exp >> arm64 default/linux/arm64/17.0/systemdexp >> >> # HPPA Profiles >> +# @MAINTAINER: h...@gentoo.org >> hppadefault/linux/hppa/13.0 stable >> hppadefault/linux/hppa/13.0/desktop dev >> hppadefault/linux/hppa/13.0/developer dev >> @@ -110,6 +116,7 @@ hppadefault/linux/hppa/17.0/desktop >>exp >> hppadefault/linux/hppa/17.0/developer exp >> >> # IA64 Profiles >> +# @MAINTAINER: i...@gentoo.org >> ia64default/linux/ia64/13.0 stable >> ia64default/linux/ia64/13.0/desktop stable >> ia64default/linux/ia64/13.0/desktop/gnome stable >> @@ -122,6 +129,7 @@ ia64 >> default/linux/ia64/17.0/desktop/gnome/systemd >> stable >> ia64default/linux/ia64/17.0/developer stable >> >> # M68K Profiles >> +# @MAINTAINER: m...@gentoo.org >> m68kdefault/linux/m68k/13.0 exp >> m68kdefault/linux/m68k/13.0/desktop exp >> m68kdefault/linux/m68k/13.0/desktop/gnome exp >> @@ -132,6 +140,7 @@ m68k
Re: [gentoo-dev] [PATCH] profiles.desc: Explicitly indicate maintainers for each profile
On Tue, Jan 9, 2018 at 9:43 AM, Michał Górny wrote: > Add @MAINTAINER comments before each profile set indicating > the effective maintainer for the following set of profiles. While most > of those entries may seem obvious at first, I expect that some > of the sub-profiles will eventually 'change hands', e.g. the /hardened > sub-profiles would be maintained by Hardened, etc. > > The main goal is to provide a clear indication of who maintains each > profile. This will be of great help both to bug-wranglers (who currently > have to pretty much guess who to assign profile bugs to) and to other > developers who plan to commit larger changes and want to get ACK from > appropriate parties. > --- > profiles/profiles.desc | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git a/profiles/profiles.desc b/profiles/profiles.desc > index 66dd7a32799f..8c9bd78143a1 100644 > --- a/profiles/profiles.desc > +++ b/profiles/profiles.desc > @@ -7,6 +7,7 @@ > #arch profile_directory status > > # Alpha Profiles How are machines supposed to read this data? Can we consider structured data? -A > +# @MAINTAINER: al...@gentoo.org > alpha default/linux/alpha/13.0stable > alpha default/linux/alpha/13.0/desktopstable > alpha default/linux/alpha/13.0/desktop/gnome stable > @@ -19,6 +20,7 @@ alpha > default/linux/alpha/17.0/desktop/gnome/systemd > exp > alpha default/linux/alpha/17.0/developer exp > > # AMD64 Profiles > +# @MAINTAINER: am...@gentoo.org > amd64 default/linux/amd64/13.0 > stable > amd64 default/linux/amd64/13.0/selinux > dev > amd64 default/linux/amd64/13.0/desktop > stable > @@ -48,6 +50,7 @@ amd64 default/linux/amd64/17.0/x32 > dev > > # Experimental SYMLINK_LIB=no profiles > # Run app-portage/unsymlink-lib *before* switching the profile. > +# @MAINTAINER: mgo...@gentoo.org > #amd64 default/linux/amd64/17.1 exp > #amd64 default/linux/amd64/17.1/selinux exp > #amd64 default/linux/amd64/17.1/hardened exp > @@ -63,6 +66,7 @@ amd64 default/linux/amd64/17.0/x32 > dev > #amd64 default/linux/amd64/17.1/systemd exp > > # ARM Profiles > +# @MAINTAINER: a...@gentoo.org > arm default/linux/arm/13.0 stable > arm default/linux/arm/13.0/desktop dev > arm default/linux/arm/13.0/desktop/gnomedev > @@ -90,6 +94,7 @@ arm default/linux/arm/13.0/armv7a/desktop/gnome >dev > arm default/linux/arm/13.0/armv7a/developer dev > > # ARM64 Profiles > +# @MAINTAINER: ar...@gentoo.org > arm64 default/linux/arm64/13.0dev > arm64 default/linux/arm64/13.0/desktopexp > arm64 default/linux/arm64/13.0/desktop/systemddev > @@ -102,6 +107,7 @@ arm64 default/linux/arm64/17.0/developer > exp > arm64 default/linux/arm64/17.0/systemdexp > > # HPPA Profiles > +# @MAINTAINER: h...@gentoo.org > hppadefault/linux/hppa/13.0 stable > hppadefault/linux/hppa/13.0/desktop dev > hppadefault/linux/hppa/13.0/developer dev > @@ -110,6 +116,7 @@ hppadefault/linux/hppa/17.0/desktop >exp > hppadefault/linux/hppa/17.0/developer exp > > # IA64 Profiles > +# @MAINTAINER: i...@gentoo.org > ia64default/linux/ia64/13.0 stable > ia64default/linux/ia64/13.0/desktop stable > ia64default/linux/ia64/13.0/desktop/gnome stable > @@ -122,6 +129,7 @@ ia64 > default/linux/ia64/17.0/desktop/gnome/systemd > stable > ia64default/linux/ia64/17.0/developer stable > > # M68K Profiles > +# @MAINTAINER: m...@gentoo.org > m68kdefault/linux/m68k/13.0 exp > m68kdefault/linux/m68k/13.0/desktop exp > m68kdefault/linux/m68k/13.0/desktop/gnome exp > @@ -132,6 +140,7 @@ m68kdefault/linux/m68k/17.0/desktop/gnome > exp > m68kdefault/linux/m68k/17.0/developer exp > > # MIPS Profiles > +# @MAINTAINER: m...@gentoo.org > mipsdefault/linux/mips/13.0/o32 dev > mipsdefault/linux/mips/13.0/n32 dev > mipsdefault/linux/mips/13.0/n64 exp > @@ -146,10 +155,12 @@ mips > default/linux/mips/13.0/mipsel/multilib/n32 >dev > mipsdefault/linux/mips/
[gentoo-dev] [PATCH] profiles.desc: Explicitly indicate maintainers for each profile
Add @MAINTAINER comments before each profile set indicating the effective maintainer for the following set of profiles. While most of those entries may seem obvious at first, I expect that some of the sub-profiles will eventually 'change hands', e.g. the /hardened sub-profiles would be maintained by Hardened, etc. The main goal is to provide a clear indication of who maintains each profile. This will be of great help both to bug-wranglers (who currently have to pretty much guess who to assign profile bugs to) and to other developers who plan to commit larger changes and want to get ACK from appropriate parties. --- profiles/profiles.desc | 23 +++ 1 file changed, 23 insertions(+) diff --git a/profiles/profiles.desc b/profiles/profiles.desc index 66dd7a32799f..8c9bd78143a1 100644 --- a/profiles/profiles.desc +++ b/profiles/profiles.desc @@ -7,6 +7,7 @@ #arch profile_directory status # Alpha Profiles +# @MAINTAINER: al...@gentoo.org alpha default/linux/alpha/13.0stable alpha default/linux/alpha/13.0/desktopstable alpha default/linux/alpha/13.0/desktop/gnome stable @@ -19,6 +20,7 @@ alpha default/linux/alpha/17.0/desktop/gnome/systemd exp alpha default/linux/alpha/17.0/developer exp # AMD64 Profiles +# @MAINTAINER: am...@gentoo.org amd64 default/linux/amd64/13.0stable amd64 default/linux/amd64/13.0/selinuxdev amd64 default/linux/amd64/13.0/desktopstable @@ -48,6 +50,7 @@ amd64 default/linux/amd64/17.0/x32 dev # Experimental SYMLINK_LIB=no profiles # Run app-portage/unsymlink-lib *before* switching the profile. +# @MAINTAINER: mgo...@gentoo.org #amd64 default/linux/amd64/17.1 exp #amd64 default/linux/amd64/17.1/selinux exp #amd64 default/linux/amd64/17.1/hardened exp @@ -63,6 +66,7 @@ amd64 default/linux/amd64/17.0/x32 dev #amd64 default/linux/amd64/17.1/systemd exp # ARM Profiles +# @MAINTAINER: a...@gentoo.org arm default/linux/arm/13.0 stable arm default/linux/arm/13.0/desktop dev arm default/linux/arm/13.0/desktop/gnomedev @@ -90,6 +94,7 @@ arm default/linux/arm/13.0/armv7a/desktop/gnome dev arm default/linux/arm/13.0/armv7a/developer dev # ARM64 Profiles +# @MAINTAINER: ar...@gentoo.org arm64 default/linux/arm64/13.0dev arm64 default/linux/arm64/13.0/desktopexp arm64 default/linux/arm64/13.0/desktop/systemddev @@ -102,6 +107,7 @@ arm64 default/linux/arm64/17.0/developer exp arm64 default/linux/arm64/17.0/systemdexp # HPPA Profiles +# @MAINTAINER: h...@gentoo.org hppadefault/linux/hppa/13.0 stable hppadefault/linux/hppa/13.0/desktop dev hppadefault/linux/hppa/13.0/developer dev @@ -110,6 +116,7 @@ hppadefault/linux/hppa/17.0/desktop exp hppadefault/linux/hppa/17.0/developer exp # IA64 Profiles +# @MAINTAINER: i...@gentoo.org ia64default/linux/ia64/13.0 stable ia64default/linux/ia64/13.0/desktop stable ia64default/linux/ia64/13.0/desktop/gnome stable @@ -122,6 +129,7 @@ ia64 default/linux/ia64/17.0/desktop/gnome/systemd stable ia64default/linux/ia64/17.0/developer stable # M68K Profiles +# @MAINTAINER: m...@gentoo.org m68kdefault/linux/m68k/13.0 exp m68kdefault/linux/m68k/13.0/desktop exp m68kdefault/linux/m68k/13.0/desktop/gnome exp @@ -132,6 +140,7 @@ m68kdefault/linux/m68k/17.0/desktop/gnome exp m68kdefault/linux/m68k/17.0/developer exp # MIPS Profiles +# @MAINTAINER: m...@gentoo.org mipsdefault/linux/mips/13.0/o32 dev mipsdefault/linux/mips/13.0/n32 dev mipsdefault/linux/mips/13.0/n64 exp @@ -146,10 +155,12 @@ mips default/linux/mips/13.0/mipsel/multilib/n32 dev mipsdefault/linux/mips/13.0/mipsel/multilib/n64 exp # Nios II Profiles +# @MAINTAINER: ? nios2 default/linux/nios2/13.0exp nios2 default/linux/nios2/17.0exp # PP
[gentoo-dev] Re: [gentoo-dev-announce] [RFC/announcement] ARM64 project / architecture team
On January 8, 2018 4:32:29 AM EST, Mart Raudsepp wrote: >Hello, > >I have created a new ARM64 project[1] as an architecture team project, >as I don't find it appropriate to handle this under the ARM project and >all its legacy (including confusing stabilization rules, etc). It is >also clearer that way, who is taking care of arm and who arm64, based >on the members list. > >The current main goal is to fix up the deptree and get some arm64 >profiles stable. To that effect, I'd like to ask package maintainers to >kindly consider with arm64 as they CC architecture teams for >(re)keywording or stabilization, as if it was a stable arch. > >New members are expected to have long-term interest in the architecture >and the work involved with that. Or responsibly removing themselves >from the project when their short-term interest fades. > > >[1]: https://wiki.gentoo.org/wiki/Project:ARM64 It is great to see you have reached the point of creating the arm64 project :) Would you like security to CC as well while to assist the arch as you work toward a stable profile? This would not hold/delay the security bug process until you are officially security supported, but I believe it will help achieve your goal of stabilization. If you desire to do so, security team can discuss support and our internal way forward to assist. -Aaron -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On January 8, 2018 9:39:47 PM EST, Benda Xu wrote: >Hi kuzetsa, > >kuzetsa writes: > >> The term "beyond" feels wrong & confusing. >> (Not sure what to replace it with though) > >How about this? > > default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ > default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+ > default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ > >Yours, >Benda I like this as it is shorter and makes the version ranges more clear. Lgtm. -Aaron -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Re: [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.
> On Wed, 3 Jan 2018, Ulrich Müller wrote: > Split off functions preserve_old_lib and preserve_old_lib_notify > from eutils.eclass into a dedicated preserve-libs.eclass. [...] > For backwards compatibility, eutils inherits the new eclass in > existing EAPIs. Pushed. Maintainers, please update your ebuilds to inherit preserve-libs directly. Ulrich pgp6LdiXzVXvn.pgp Description: PGP signature
