Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Michał Górny]

On Wed, 29 Jun 2016 15:47:43 -0700
Daniel Campbell  wrote:

> On 06/29/2016 10:11 AM, Michał Górny wrote:
> > Hello, everyone.
> > 
> > Over half a year has passed since Council decided upon the fate of
> > games in Gentoo. Over that period, the games team has neither showed
> > any will to respect the Council decisions, nor officially appealed to
> > them.
> > 
> > For this reason, the QA team would like to officially start supporting
> > the migration of ebuilds out of games.eclass. Any developer wishing to
> > help is more than welcome to take any games.eclass ebuild, bump its
> > revision and remove the games.eclass-specific bits from it. Updating to
> > EAPI 6 would also be welcome. A short update guide is provided at
> > the end of mail.
> > 
> > Please note that since this is considered a matter of QA action with
> > a long waiting period, no explicit approval from games team is
> > necessary to commit the conversion, nor games team is allowed to reject
> > or revert such commits as long as they are valid.
> > 
> > If you need any help doing that and the games team refuses to provide
> > it, please do not hesitate to contact me or ask in #gentoo-qa. If you
> > are interested in helping out with games, feel free to join games team
> > since it still lacks new members.
> > 
> > Thank you for all the help.
> > 
> > 
> > Migration notes
> > ---
> > 
> > TL;DR: nothing special required, remove games.eclass and all
> > unnecessary games.eclass customization, and follow upstream. Make sure
> > not to break stuff.
> > 
> > 
> > The Council decisions can be summarized the following way:
> > 
> > 1. The 'games' group, formerly used to control access to games, must
> > not be used. Games should be executable for all users like any other
> > program [1].
> > 
> > 1a. For score files and similar writable shared data, the 'gamestat'
> > group (enewgroup gamestat 36) can be used. The old 'games' group is not
> > appropriate since sysadmins were expected to add users to it which
> > defeated its purpose.
> > 
> > 2. Gentoo path customization for games must be removed and regular
> > install locations (without explicit control via GAMES_* variables)
> > should be used [2]:
> > 
> > 2a. /usr/games and /etc/games directories are forbidden,
> > 
> > 2b. /usr/share/games can be used for data if that directory is used
> > upstream,
> > 
> > 2c. /var/games can be used for shared writable data.
> > 
> > 
> > This is mostly achieved through removing games.eclass inherit,
> > customization specific to it and replacing the helpers with generic PMS
> > helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
> > The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
> > removed altogether.
> > 
> > In some cases it will also be beneficial to remove patching added to
> > support non-standard locations.
> > 
> > Please remember to always rev-bump and not edit in place, to ensure
> > proper upgrade. When dealing with dependencies, please make sure to
> > check if the package does not rely on dependency installing data in
> > a specific location. If that is the case, then you need to use
> > appropriate >= deps to ensure clean upgrade.
> > 
> > If you would like to report bugs requesting games.eclass removal,
> > please make them block the tracker [3].
> > 
> > 
> > [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
> > [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
> > [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
> >   
> I'm glad to see some reach-out here and taking responsibility for
> decisions. However, what does the QA team have to say about systems that
> want games on other media (such as an SSD or separate HDD), or wish to
> restrict the use of games on their system to certain accounts?
> 
> Bumping EAPI won't magically allow those to happen, and removing the
> eclass *will* break those use cases. What's the "blessed" way to do those?

If you want to do custom stuff, you're on your own. There are tricks to
do that (package.env, bashrc). Don't expect developers to patch packages
to satisfy your corner case.

-- 
Best regards,
Michał Górny



pgptJSC38tSn6.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Daniel Campbell]

On 06/29/2016 04:02 PM, Rich Freeman wrote:
> On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell  wrote:
>> I'm glad to see some reach-out here and taking responsibility for
>> decisions. However, what does the QA team have to say about systems that
>> want games on other media (such as an SSD or separate HDD), or wish to
>> restrict the use of games on their system to certain accounts?
>>
>> Bumping EAPI won't magically allow those to happen, and removing the
>> eclass *will* break those use cases. What's the "blessed" way to do those?
> 
> Per-package install locations?  Sounds like a possible future EAPI
> feature?  Of course, the real trick is when packages need to interact
> and the files aren't in a fixed location.
> 
> In general right now I don't think we have a blessed way to install
> stuff in non-standard locations.  Obviously you can fork an ebuild and
> modify it, but if somebody wants to install KDE in /usr/kde/ and X11
> into /usr/X11R6/ there isn't a clean way to do it.
> 
A conversation or two I've had about it pointed to EPREFIX or some other
variable/function that (I was told) the Prefix team would know a bit
more about. I'm not even looking for something supported, per se.
Supporting ebuilds that can be installed anywhere is a bit much for
maintainers to worry about. But having the ability to, and having it
documented, would be great. Even if it's something like "Gentoo Linux
does not officially support or endorse this method, but here's how to
get it working". An EAPI bump may be nice on paper, but I have a feeling
implementing it would be a pain to support tree-wide.

Does the Prefix team have any recommendations in that department?

That's what I think this drama is about; changes being pushed from
people who don't work on games, then leaving these game maintainers (and
users) in the dark without a "correct" way to achieve what they're
after. We can do better than that, and it's solvable in a technical
manner, which is why I'm focused on it.

---

On the political side...

Do teams hold any authority (or veto power, whatever you want to call
it) over their own ebuilds? Is it reasonable to rip functionality out
from under a group of developers and tell them to deal with it?

I think teams deserve autonomy over their own ebuilds, and should
ideally follow QA guidelines *where reasonable*. Any good QA team should
have iron-clad reasons behind their decisions, and answers for
'what-ifs' that exist outside of the ideal perfection that QA tends to
operate in.

Removing eclasses without really good reason and without replacements
for missing use cases simply shouldn't happen. I wouldn't want that done
to me, and I'd definitely not (knowingly) help someone else do it.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: kde-misc/kgtk

[Johannes Huber]

# Johannes Huber  (30 Jun 2016)
# Andreas K. Huettel  (22 Mar 2012)
# Masked for removal in 30 days. Dead upstream. Superseded
# by oxygen-gtk long time ago.
#
# (Original mask: Even its author admits that it's an ugly
# hack. Crashes e.g. firefox with kde-4.8. Unmask at your own
# risk.)
kde-misc/kgtk

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Need design help/input for eclean-kernel

[Michał Górny]

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.

-- 
Best regards,
Michał Górny



pgpgyiPNQAZea.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Rich Freeman]

On Thu, Jun 30, 2016 at 12:54 AM, Daniel Campbell  wrote:
>
> Do teams hold any authority (or veto power, whatever you want to call
> it) over their own ebuilds? Is it reasonable to rip functionality out
> from under a group of developers and tell them to deal with it?

Generally speaking, yes.  If somebody has an issue with a project's
policies they should try to work it out with the project lead, and
failing that with the council.  In this particular case the Council
has issued decisions, and these override all projects.

> I think teams deserve autonomy over their own ebuilds, and should
> ideally follow QA guidelines *where reasonable*.

QA is a special project (as is Comrel).  They do not require the
approval of other projects to take action.  If somebody has a concern
with their actions they may be appealed to the Council.  The Council
can of course decide on whether QA is acting reasonably.

We can't just let any project in Gentoo decide what is or isn't
reasonable with finality.  Any developer can start a Gentoo project
(that's a good thing), and we'd have chaos if they all could just hold
ultimate veto on what goes into their part of the tree.

If you want ultimate veto over what goes in, just do your work in an
overlay.  Nobody will even have the access to touch your stuff.

For the most part we try to be hands-off with this stuff and when you
look at the months it took leading up to the Council decisions on the
games issues, it is fairly obvious that we didn't want to meddle more
than absolutely necessary.  For the most part the changes just make
games like any other package, which is a fairly conservative change.
If somebody wanted to install all text editors into /usr/texteditors/
I'm sure we'd have ended up having the same discussion at some point.

Don't get me wrong - if somebody comes up with a reasonable way to let
users control where packages get installed I'm all for it.  I see that
use case as having validity, and beyond games as well.

Certainly you could install games in a prefix-like environment as you
suggested.  Gentoo Prefix should certainly work on Gentoo.

-- 
Rich

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Michał Górny]

On Wed, 29 Jun 2016 22:37:27 -0700
Daniel Campbell  wrote:

> On 06/29/2016 10:11 PM, Michał Górny wrote:
> > On Wed, 29 Jun 2016 15:47:43 -0700
> > Daniel Campbell  wrote:
> >   
> >> On 06/29/2016 10:11 AM, Michał Górny wrote:  
> >>> Hello, everyone.
> >>>
> >>> Over half a year has passed since Council decided upon the fate of
> >>> games in Gentoo. Over that period, the games team has neither showed
> >>> any will to respect the Council decisions, nor officially appealed to
> >>> them.
> >>>
> >>> For this reason, the QA team would like to officially start supporting
> >>> the migration of ebuilds out of games.eclass. Any developer wishing to
> >>> help is more than welcome to take any games.eclass ebuild, bump its
> >>> revision and remove the games.eclass-specific bits from it. Updating to
> >>> EAPI 6 would also be welcome. A short update guide is provided at
> >>> the end of mail.
> >>>
> >>> Please note that since this is considered a matter of QA action with
> >>> a long waiting period, no explicit approval from games team is
> >>> necessary to commit the conversion, nor games team is allowed to reject
> >>> or revert such commits as long as they are valid.
> >>>
> >>> If you need any help doing that and the games team refuses to provide
> >>> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
> >>> are interested in helping out with games, feel free to join games team
> >>> since it still lacks new members.
> >>>
> >>> Thank you for all the help.
> >>>
> >>>
> >>> Migration notes
> >>> ---
> >>>
> >>> TL;DR: nothing special required, remove games.eclass and all
> >>> unnecessary games.eclass customization, and follow upstream. Make sure
> >>> not to break stuff.
> >>>
> >>>
> >>> The Council decisions can be summarized the following way:
> >>>
> >>> 1. The 'games' group, formerly used to control access to games, must
> >>> not be used. Games should be executable for all users like any other
> >>> program [1].
> >>>
> >>> 1a. For score files and similar writable shared data, the 'gamestat'
> >>> group (enewgroup gamestat 36) can be used. The old 'games' group is not
> >>> appropriate since sysadmins were expected to add users to it which
> >>> defeated its purpose.
> >>>
> >>> 2. Gentoo path customization for games must be removed and regular
> >>> install locations (without explicit control via GAMES_* variables)
> >>> should be used [2]:
> >>>
> >>> 2a. /usr/games and /etc/games directories are forbidden,
> >>>
> >>> 2b. /usr/share/games can be used for data if that directory is used
> >>> upstream,
> >>>
> >>> 2c. /var/games can be used for shared writable data.
> >>>
> >>>
> >>> This is mostly achieved through removing games.eclass inherit,
> >>> customization specific to it and replacing the helpers with generic PMS
> >>> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
> >>> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
> >>> removed altogether.
> >>>
> >>> In some cases it will also be beneficial to remove patching added to
> >>> support non-standard locations.
> >>>
> >>> Please remember to always rev-bump and not edit in place, to ensure
> >>> proper upgrade. When dealing with dependencies, please make sure to
> >>> check if the package does not rely on dependency installing data in
> >>> a specific location. If that is the case, then you need to use
> >>> appropriate >= deps to ensure clean upgrade.
> >>>
> >>> If you would like to report bugs requesting games.eclass removal,
> >>> please make them block the tracker [3].
> >>>
> >>>
> >>> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
> >>> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
> >>> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
> >>> 
> >> I'm glad to see some reach-out here and taking responsibility for
> >> decisions. However, what does the QA team have to say about systems that
> >> want games on other media (such as an SSD or separate HDD), or wish to
> >> restrict the use of games on their system to certain accounts?
> >>
> >> Bumping EAPI won't magically allow those to happen, and removing the
> >> eclass *will* break those use cases. What's the "blessed" way to do those? 
> >>  
> > 
> > If you want to do custom stuff, you're on your own. There are tricks to
> > do that (package.env, bashrc). Don't expect developers to patch packages
> > to satisfy your corner case.
> >   
> 
> Why not document those tricks in the same section of the wiki that
> indicates games.eclass's deprecation? A heads-up with a link?

Wiki is public. You are free to provide useful information if you like.
I don't feel like working on unsupported hacks that won't work reliably
and don't give much benefit to anyone. Just please keep that on
a separate page so that people don't think it's officially supported.

> _Something_. This isn't my use case, but we owe it to users to give them
> ways 

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Daniel Campbell]

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
current -> linux-4.4.6-gentoo-1
initrd
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
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: www-apps/egroupware

[Aaron Bauman]

# Aaron Bauman  (30 Jun 2016)
# Unpatched security vulnerability per bug #509920.
# Removal in 30 days
www-apps/egroupware

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Michał Górny]

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.

-- 
Best regards,
Michał Górny



pgp2SGj_trs0X.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Michał Górny]

On Wed, 29 Jun 2016 21:54:44 -0700
Daniel Campbell  wrote:

> That's what I think this drama is about; changes being pushed from
> people who don't work on games, then leaving these game maintainers (and
> users) in the dark without a "correct" way to achieve what they're
> after. We can do better than that, and it's solvable in a technical
> manner, which is why I'm focused on it.

I'd really appreciate if you did some research before accusing people.

> On the political side...
> 
> Do teams hold any authority (or veto power, whatever you want to call
> it) over their own ebuilds? Is it reasonable to rip functionality out
> from under a group of developers and tell them to deal with it?
> 
> I think teams deserve autonomy over their own ebuilds, [...]

No, they do not and I will not allow that to happen ever again. And I'm
pretty sure I'm not the only one here that was unhappy with the way
Games team pushed everyone around over the years.

If you want autonomy, fork Gentoo or use your own repository. The core
Gentoo repository is community-maintained -- either live with it, or
leave. We do not need more people causing massive community damage for
years with nobody being bold enough to stop them.

People and teams have reasonable right to develop policies and maintain
their own packages. However, they have no right to assume sole
ownership of all packages with generic characteristic, and hold it
for years while preventing anyone from having any saying on anything.

Rephrasing Rich's words, how would you feel if I established 'Text
editors' project and claimed final saying on every single text editor
in Gentoo? Then I would develop policies I find useful, ignore any
input, ignore join requests and discourage anyone from contributing.
Is that the Gentoo you desire?

> and should
> ideally follow QA guidelines *where reasonable*. Any good QA team should
> have iron-clad reasons behind their decisions, and answers for
> 'what-ifs' that exist outside of the ideal perfection that QA tends to
> operate in.

The whole point of QA is to provide good quality *everywhere*, and it
is *unacceptable* to have developers decide if they want to follow
policies or not. It is reasonable to adjust the policies as necessary,
or allow grace periods. But there is no point in having policies that
are fully optional depending on the mood of the developer.

That said, this is completely irrelevant to the topic at hand. This
isn't QA's decision. It's a long process started by individual
developers *interested in helping out with games* years ago, which
ended up with Council appeal. The source of the policy is the Council,
not QA.

QA is merely concerned with the fact that Games team ignores
the policies established by the Council. This results in two different
layouts being deployed over the repository which results in increased
confusion (which you are victim of), and decreased quality. QA offers
to help in solving that.

> Removing eclasses without really good reason and without replacements
> for missing use cases simply shouldn't happen. I wouldn't want that done
> to me, and I'd definitely not (knowingly) help someone else do it.

Your disagreement with the rationale does not make it bad.

-- 
Best regards,
Michał Górny



pgpr0npxdXcCX.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Daniel Campbell]

On 06/29/2016 10:11 PM, Michał Górny wrote:
> On Wed, 29 Jun 2016 15:47:43 -0700
> Daniel Campbell  wrote:
> 
>> On 06/29/2016 10:11 AM, Michał Górny wrote:
>>> Hello, everyone.
>>>
>>> Over half a year has passed since Council decided upon the fate of
>>> games in Gentoo. Over that period, the games team has neither showed
>>> any will to respect the Council decisions, nor officially appealed to
>>> them.
>>>
>>> For this reason, the QA team would like to officially start supporting
>>> the migration of ebuilds out of games.eclass. Any developer wishing to
>>> help is more than welcome to take any games.eclass ebuild, bump its
>>> revision and remove the games.eclass-specific bits from it. Updating to
>>> EAPI 6 would also be welcome. A short update guide is provided at
>>> the end of mail.
>>>
>>> Please note that since this is considered a matter of QA action with
>>> a long waiting period, no explicit approval from games team is
>>> necessary to commit the conversion, nor games team is allowed to reject
>>> or revert such commits as long as they are valid.
>>>
>>> If you need any help doing that and the games team refuses to provide
>>> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
>>> are interested in helping out with games, feel free to join games team
>>> since it still lacks new members.
>>>
>>> Thank you for all the help.
>>>
>>>
>>> Migration notes
>>> ---
>>>
>>> TL;DR: nothing special required, remove games.eclass and all
>>> unnecessary games.eclass customization, and follow upstream. Make sure
>>> not to break stuff.
>>>
>>>
>>> The Council decisions can be summarized the following way:
>>>
>>> 1. The 'games' group, formerly used to control access to games, must
>>> not be used. Games should be executable for all users like any other
>>> program [1].
>>>
>>> 1a. For score files and similar writable shared data, the 'gamestat'
>>> group (enewgroup gamestat 36) can be used. The old 'games' group is not
>>> appropriate since sysadmins were expected to add users to it which
>>> defeated its purpose.
>>>
>>> 2. Gentoo path customization for games must be removed and regular
>>> install locations (without explicit control via GAMES_* variables)
>>> should be used [2]:
>>>
>>> 2a. /usr/games and /etc/games directories are forbidden,
>>>
>>> 2b. /usr/share/games can be used for data if that directory is used
>>> upstream,
>>>
>>> 2c. /var/games can be used for shared writable data.
>>>
>>>
>>> This is mostly achieved through removing games.eclass inherit,
>>> customization specific to it and replacing the helpers with generic PMS
>>> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
>>> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
>>> removed altogether.
>>>
>>> In some cases it will also be beneficial to remove patching added to
>>> support non-standard locations.
>>>
>>> Please remember to always rev-bump and not edit in place, to ensure
>>> proper upgrade. When dealing with dependencies, please make sure to
>>> check if the package does not rely on dependency installing data in
>>> a specific location. If that is the case, then you need to use
>>> appropriate >= deps to ensure clean upgrade.
>>>
>>> If you would like to report bugs requesting games.eclass removal,
>>> please make them block the tracker [3].
>>>
>>>
>>> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
>>> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
>>> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
>>>   
>> I'm glad to see some reach-out here and taking responsibility for
>> decisions. However, what does the QA team have to say about systems that
>> want games on other media (such as an SSD or separate HDD), or wish to
>> restrict the use of games on their system to certain accounts?
>>
>> Bumping EAPI won't magically allow those to happen, and removing the
>> eclass *will* break those use cases. What's the "blessed" way to do those?
> 
> If you want to do custom stuff, you're on your own. There are tricks to
> do that (package.env, bashrc). Don't expect developers to patch packages
> to satisfy your corner case.
> 

Why not document those tricks in the same section of the wiki that
indicates games.eclass's deprecation? A heads-up with a link?
_Something_. This isn't my use case, but we owe it to users to give them
ways forward when we break things, even if they aren't what we
personally use. If another developer (or team of developers) rendered
your use case(s) unsupported or flippantly wrote it off as a corner case
(with no documentation on restoring your previous use case), what would
you do?

Other breakages have been handled much better, such as the separate /usr
switch. Mentions of that were almost always followed up with "If you
wish to keep this, use an initramfs". That is an example of breakage
handled correctly: the change is explained, use cases that would break
were identified, 

Re: [gentoo-portage-dev] [PATCH] repoman: Make LIVEVCS.* checks fatal

[Michał Górny]

On Tue, 28 Jun 2016 12:40:07 -0700
Zac Medico  wrote:

> On 06/28/2016 11:30 AM, Michał Górny wrote:
> > Make LIVEVCS.* checks fatal to prevent people from committing ebuilds
> > using live eclasses instead of package.masking them afterwards by QA.
> > ---
> >  repoman/pym/repoman/qa_data.py | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/repoman/pym/repoman/qa_data.py b/repoman/pym/repoman/qa_data.py
> > index 48ab389..738368e 100644
> > --- a/repoman/pym/repoman/qa_data.py
> > +++ b/repoman/pym/repoman/qa_data.py
> > @@ -270,8 +270,6 @@ qawarnings = set((
> > "repo.eapi.deprecated",
> > "usage.obsolete",
> > "upstream.workaround",
> > -   "LIVEVCS.stable",
> > -   "LIVEVCS.unmasked",
> > "IUSE.rubydeprecated",
> >  ))
> >  
> >   
> 
> Looks good.

Signed and pushed!

-- 
Best regards,
Michał Górny



pgpr98ZWnpyED.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Joseph Booker]

As someone using eclean-kernel somewhat regularly, I figured I should
mention what running `make all modules_install install` in the kernel
source looks like:

$ ls -F1 /boot
config-4.6.0-gentoo
config-4.6.1-gentoo
config-4.6.2-gentoo
config-4.6.3-gentoo
efi/
grub/
initramfs-4.6.0-gentoo.img
initramfs-4.6.1-gentoo.img
initramfs-4.6.2-gentoo.img
initramfs-4.6.3-gentoo.img
lost+found/
System.map-4.6.0-gentoo
System.map-4.6.1-gentoo
System.map-4.6.2-gentoo
System.map-4.6.3-gentoo
vmlinuz-4.6.0-gentoo
vmlinuz-4.6.1-gentoo
vmlinuz-4.6.2-gentoo
vmlinuz-4.6.3-gentoo

This is from running `make install` with files in /etc/kernel/postinst.d to
run the following:
cd /boot; dracut --force --kver=$1 --install "
grub2-mkconfig -o /boot/grub/grub.cfg

/etc/grub.d/10_linux (in sys-boot/grub:2) does have a collection of names
it searches through as well, including 13 variants of initrd for the same
kernel version.

Thanks for maintaining this tool, it's pretty useful in this
straightforward case.

On Thu, Jun 30, 2016 at 8: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.
>
> --
> Best regards,
> Michał Górny
> 
>

Re: [gentoo-dev] Need design help/input for eclean-kernel

[R0b0t1]

On Thu, Jun 30, 2016 at 7:38 AM, Michał Górny  wrote:
> 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.

/boot on removable media.

I am busy with work now, but I had a set of scripts to compile,
package, and install a kernel and initrd. At some point I realized I
was recreating portage.

I have a mostly complete plan for a replacement, but it is not quite
presentable yet.

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Marc Schiffbauer]

* Michał Górny schrieb am 30.06.16 um 15:19 Uhr:
> > My /boot/:
> > 
> > grub
> > lost+found
> > backup -> linux-4.4.1-gentoo-2
> > boot
> 
> What's 'boot' here? Is that relevant?

This might be a symlink to '.' which I too have on many systems. You 
need it, so grub can find files that start with /boot/ if you have /boot 
in its own partition. (IIRC)

-Marc


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Mike Gilbert]

On Thu, Jun 30, 2016 at 8:38 AM, Michał Górny  wrote:
> 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.

Standard "make install" layout with dracut and grub2:

/boot/vmlinuz-$KV{,.old}
/boot/config-$KV
/boot/System.map-${KV}
/boot/initramfs-$KV.img
/boot/grub/grub.cfg generated by grub2-mkconfig contains menu entries
for each pairing.

The other layout I use on my UEFI laptop is the typical systemd-boot
(gummiboot) layout, which you are probably familiar with. I don't use
dracut on that, so I'm not certain where the initramfs lives.

[gentoo-dev] Re: Need design help/input for eclean-kernel

[Jonathan Callen]

On 06/30/2016 08: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.
> 

https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/

${MACHINE_ID} is the contents of /etc/machine-id

Boot loader config:
/boot/loader/entries/${MACHINE_ID}-${KV}.conf

Kernel, initramfs, etc.:
/boot/${MACHINE_ID}/${KV}/linux
/boot/${MACHINE_ID}/${KV}/initrd
/boot/${MACHINE_ID}/${KV}/config
/boot/${MACHINE_ID}/${KV}/System.map

Can be generated by kernel-install(8) (part of systemd).

-- 
Jonathan Callen



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Daniel Campbell]

On 06/30/2016 06:17 AM, Michał Górny wrote:
> On Wed, 29 Jun 2016 21:54:44 -0700
> Daniel Campbell  wrote:
> 
>> That's what I think this drama is about; changes being pushed from
>> people who don't work on games, then leaving these game maintainers (and
>> users) in the dark without a "correct" way to achieve what they're
>> after. We can do better than that, and it's solvable in a technical
>> manner, which is why I'm focused on it.
> 
> I'd really appreciate if you did some research before accusing people.

I've read the council meetings that I was able to find on it and have
explored the perspectives of both sides of the subject. What research
are you asking for? I've not attacked anyone.
> 
>> On the political side...
>>
>> Do teams hold any authority (or veto power, whatever you want to call
>> it) over their own ebuilds? Is it reasonable to rip functionality out
>> from under a group of developers and tell them to deal with it?
>>
>> I think teams deserve autonomy over their own ebuilds, [...]
> 
> No, they do not and I will not allow that to happen ever again. And I'm
> pretty sure I'm not the only one here that was unhappy with the way
> Games team pushed everyone around over the years.
> 
> If you want autonomy, fork Gentoo or use your own repository. The core
> Gentoo repository is community-maintained -- either live with it, or
> leave. We do not need more people causing massive community damage for
> years with nobody being bold enough to stop them.
Our ebuilds are maintained by developers, with the occasional
proxy-maintainer or contributor. Your previous statement combined with
this amounts to "QA owns and manages the Gentoo repository." You just
said teams have no autonomy over their own ebuilds, which naturally
extends to individual developers lacking autonomy for their ebuilds, as
well.

This has little to do with what I want. I don't seek any of the use
cases that games.eclass made possible, but that doesn't mean my use
cases won't be axed in the future with the same lack of care and for
similarly petty reasons.

> 
> People and teams have reasonable right to develop policies and maintain
> their own packages. However, they have no right to assume sole
> ownership of all packages with generic characteristic, and hold it
> for years while preventing anyone from having any saying on anything.
> 
> Rephrasing Rich's words, how would you feel if I established 'Text
> editors' project and claimed final saying on every single text editor
> in Gentoo? Then I would develop policies I find useful, ignore any
> input, ignore join requests and discourage anyone from contributing.
> Is that the Gentoo you desire?
No, it's not the Gentoo I desire. I've seen that claim thrown around and
I've not seen any evidence of it happening follow it. I get it if you or
others have a vendetta against the games team -- I don't know any of
them really -- sometimes people don't get along. But ripping out the
eclass is a "solution" that creates more problems than it solves.
Changing its default prefix values to follow Gentoo's standard and
allowing users to change it meets the needs of both parties, and yet it
seems nobody considered that option. Rich suggested maybe its
functionality could be put into a later EAPI, but as he noted there are
hurdles in generalizing that behavior. If its values default to match
Gentoo's, then only the people who need the path flexibility will need
to change it. That's one of the recent trends for us lately, isn't it?
Leave sane defaults, but if people want to change them and/or break
things, they're free to.

I expect to be told that use case is poor or irrelevant. Who decides
which use cases are valid and what qualifies them to make those claims?
> 
>> and should
>> ideally follow QA guidelines *where reasonable*. Any good QA team should
>> have iron-clad reasons behind their decisions, and answers for
>> 'what-ifs' that exist outside of the ideal perfection that QA tends to
>> operate in.
> 
> The whole point of QA is to provide good quality *everywhere*, and it
> is *unacceptable* to have developers decide if they want to follow
> policies or not. It is reasonable to adjust the policies as necessary,
> or allow grace periods. But there is no point in having policies that
> are fully optional depending on the mood of the developer.
And how is a QA group taken seriously if they don't address breakage
that they introduce? Is QA not held to a standard at all? Is it a set of
arbitrary rules laid down from this separate project that nobody else
can examine or call for re-examination?

A key ingredient to QA is knowing quality code when one sees it, and
fully understanding the use cases that a given set of code makes
possible. Ideally, they also understand and suggest best practices so
people are aware of how to 'color inside the lines'.

This games.eclass decision breaks use cases, supplies no replacement or
forward-facing route for users, and is being swept under the 

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Gordon Pettey]

On Thu, Jun 30, 2016 at 5:22 PM, Daniel Campbell (zlg) 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> 'boot' is a symlink to '.'. Not really sure why it's there but if I remove
> it, things break. Probably a minor misconfiguration.
>

/boot/boot -> /boot allows you to prefix every reference to a kernel image
with /boot, regardless of whether you are running something in userspace on
a fully mounted system or in GRUB or syslinux or the kernel where "/boot"
is actually /dev/sda1 or some such and effectively /. Likely irrelevant to
eclean tools.

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Rich Freeman]

On Thu, Jun 30, 2016 at 7:19 PM, Daniel Campbell  wrote:
> Our ebuilds are maintained by developers, with the occasional
> proxy-maintainer or contributor. Your previous statement combined with
> this amounts to "QA owns and manages the Gentoo repository." You just
> said teams have no autonomy over their own ebuilds, which naturally
> extends to individual developers lacking autonomy for their ebuilds, as
> well.

QA has authority over the Gentoo repository, but their scope for
exercising this authority is relatively narrow.  Ultimately we expect
them to police themselves, but if they become a problem any developer
can appeal to the Council.  For the most part the policies they
enforce have either been the sorts of things almost anybody would
agree with, or they're Council decisions.

If the Council decides on a policy, then QA is completely within their
rights to take action to enforce that policy.  If somebody wants to
appeal they can, but of course they're going to be appealing to the
Council that set the policy.  That is by design.  The whole point of
the Council is to have some way to reach a "final" decision when there
isn't consensus.  Of course, Councils can change their mind, but in
practice this has been rare.

> But ripping out the
> eclass is a "solution" that creates more problems than it solves.

Trust me, this wasn't something the Council undertook lightly.


>
> I expect to be told that use case is poor or irrelevant. Who decides
> which use cases are valid and what qualifies them to make those claims?

Ultimately the Council, by sole virtue of election.  It isn't perfect,
but it is a process that has a form of accountability and it at least
is capable of yielding a final decision.  On a lot of issues either A
or B is better than endlessly bickering between them.  Of course, the
Gentoo way is to support choice and if somebody comes up with a good
way to push the decision into the hands of the end user then we can
just argue over the most sane default.  No matter how you slice it,
there will always be decisions that people disagree over.

Personally, I don't really buy into the SSD use case.  It isn't that I
don't agree with the virtues of SSDs, but the most straightforward
solution to this is to stick / and /usr on the SSD so that all
applications benefit from this.  An entire Gentoo install is only a
few GB worth of binaries/libraries/etc and it is probably a lot more
straightforward to indiscriminately put these on the SSD than to pick
and choose.  Plus, your system will boot a LOT faster.  This is what I
do - basically / is on an SSD and then I mount stuff on top from hard
drives when I need space.

In an earlier email you mentioned that this wasn't a big concern for
you personally but you were concerned for our end users.  One bit of
advice that I'll offer is that if this is the case, let them speak for
themselves.  Speaking personally, I'm interested in feedback from
anybody I get it from.  However, when somebody comes to the Council
with an argument like "somebody, somewhere, might disagree" and nobody
is actually saying "this affects me" then it probably won't get a lot
of weight.

Ultimately, though, you're going to have to trust the judgment of the
council.  Or, whether you trust it or not, you will ultimately have to
abide by it for anything you do using your commit access.

> And how is a QA group taken seriously if they don't address breakage
> that they introduce? Is QA not held to a standard at all? Is it a set of
> arbitrary rules laid down from this separate project that nobody else
> can examine or call for re-examination?

QA is enforcing a Council policy.  Whether something is considered
breakage ultimately is up to the Council.  Who is on the Council is of
course up to all of us.  While I don't advise turning an election into
a referendum on one particular decision I certainly encourage
developers to be selecting Council members based upon their ability to
strike an appropriate balance here.  The Council's ability to dictate
tree-wide policies like these are probably the area where it has the
biggest impact on developers being able to scratch their itches.  So,
this stuff is really important.

The Council also confirms the lead of QA.  And of course there is the
ability to appeal.  There are of course issues with any human-run
organization but I struggle to think of conflicts the QA team has had
with developers which weren't addressed by the QA lead or the team.
Certainly I don't recall actually getting any actual appeals (for QA,
and in my time on the Council I've only seen one Comrel appeal).  I
don't want to get into Comrel but the principle is the same with that
organization, just with a different scope of operations.

> This games.eclass decision breaks use cases, supplies no replacement or
> forward-facing route for users, and is being swept under the rug as
> quickly as possible.

There is no intent to stifle discussion.  You're welcome to state 

[gentoo-dev] Last rites: www-servers/monkeyd

[Aaron Bauman]

# Aaron Bauman  (1 Jul 2016)
# Unpatched security vulnerabilities and dead upstream
# per bugs #459274 and #473770  Removal in 30 days
www-servers/monkeyd

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Matt Turner]

On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell  wrote:
> I'm glad to see some reach-out here and taking responsibility for
> decisions. However, what does the QA team have to say about systems that
> want games on other media (such as an SSD or separate HDD), or wish to
> restrict the use of games on their system to certain accounts?

Has anyone complained about either of these features going away? If
they're purely theoretical concerns...

The games.eclass saga has gone on plenty long enough. I would much
prefer that we not relitigate it. I understand that you may not have
been around when most of it happened initially, but please understand
that it's not feasible to reconsider every decision when new
developers join the project.

[gentoo-dev] why is the security team running around p.masking packages

[Anthony G. Basile]

I'm going to ask the security team to please stop running around
p.masking packages without acknowledgement from the maintainers.  I'm
referring in particular to commit
135b94c85950254f559f290f4865bce8b349a917 regarding monkeyd.  Both of the
cited "security bugs" were long fixed, and even if the were not, they do
not merit masking because they were at best some information leakage
with minor impact.  I have reverted that commit and would ask that
security stop this practice.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] Re: [QA] Official support for migrating ebuilds out of games.eclass

[Duncan]

Rich Freeman posted on Thu, 30 Jun 2016 20:24:43 -0400 as excerpted:

> In this case I can assure you that people were frustrated that it took
> as long as it did to end up with a decision, and it largely was because
> we recognized the controversy.  There were multiple rounds of meetings
> and numerous opportunities to provide feedback.  Ultimately, however,
> providing feedback does not guarantee any particular result.

Indeed.  

This bit of the previous discussion has been missing from this round so 
far, but FWIW, one of the big frustrations from the council side and I 
think from most looking on (certainly me) was that they /begged/ games 
team to step up and present a reasonable defense of their policy and 
provide some sort of presumably opposing viewpoint from which to work 
toward a compromise somewhere in the middle.

And they begged games team to work with them to let other devs on the 
team and help get them up and running with policies, etc, as bugs were 
piling up.

But the problem was, games team was pretty much MIA, in terms of any form 
of communication whatsoever.  While some individual games team members 
were still maintaining their individual ebuilds, /nobody/ was willing or 
able to speak for the team, and to help with other ebuilds that were 
effectively left rotting, because games team, at least as an actually 
working /team/, simply /wasn't/, any more.

There were volunteers who /tried/ to get on the team.  No ack from the 
lead or anybody to speak for the team.  Nobody to bring them upto speed 
on policies, etc.  And nobody answered council or QA questions about why, 
and what could be done to fix it.  And the eclass was left rotting as 
well, an area that's definitely QA's territory, again seemingly with 
anybody willing to reply apparently vanished from earth.

Meanwhile, games were flourishing in overlays, because games in gentoo 
itself had become a toxic wasteland with the absent games team asserting 
control, but with nobody willing or able to do anything about it.


So eventually, after repeated /begging/ from both QA and council with, 
essentially, crickets in response...

Council had to act to bring back some sort of sanity.  Including working 
to finally close a long open security bug on at least one game /because/ 
of the way gentoo was handling things -- it wasn't a problem on other 
distros because they didn't have a special games group to deal with.

Even then, /nobody/ was willing to volunteer to lead the newly reforming 
games team, and few were willing to even be members.  By this time 
everything involved with it was simply too toxic, I guess.

So what council did first, was basically formerly declare than anyone 
that wanted could commit new (not yet in-tree) games on their own, 
without having to fear games team vetoing or reverting.  And the eclass 
was deprecated as effectively unmaintained, simply recognizing the fact.

And even /that/ was basically the minimum necessary to get some 
functionality back, hoping it might wake someone up on games team to at 
least have someone to work with and to try to compromise with.

But six months later, we still don't see a newly reactivated and gaining 
health games team trying to get back in the game, as it were.

And the /biggest/ problem, we /still/ don't have anyone of the former 
members (remember, no one further could join as it was too dysfunctional) 
volunteering to step up and actually head the thing, maintain or arrange 
for maintenance of the eclass, etc, despite the fact that some are still 
raising objections to moving ebuilds off the eclass, etc.

Bottom line, the former games team is /still/ dysfunctional and basically 
dead, and can't even pull itself together enough for there to be any 
other realistic alternative /but/ to have QA continue to work on moving 
existing ebuilds off of it, as proposed here.  This has gone on for 
/years/, and truth be, it's really a bit late now, even if games team 
/were/ to suddenly resurrect and try to reverse things now.

But that /still/ isn't happening.  There's others objecting, still saying 
it's not their use-case but it's a shame... and it is a shame... but at 
some point, that stinking rotting corpse just /must/ be buried or burned 
or otherwise disposed of.  Otherwise, it's just a worsening public health 
hazard, however much of a shame that death might be.

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

[gentoo-dev] Re: Need design help/input for eclean-kernel

[Duncan]

Michał Górny posted on Thu, 30 Jun 2016 14:38:26 +0200 as excerpted:

> [P]lease 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.

This is surely more info than you need, but I imagine it's one of the 
more unique and complex layouts you'll see and thus might need additional 
explanation for some bits.  Trouble is I don't know which bits, so...

I have never used eclean-kernel and probably won't as I have my own 
scripts to handle things (as I was doing even back over a decade ago on 
mandrake, before I switched to gentoo), but here's the layout, in case 
you find it useful (or a fun challenge? =:^) to support.

So what I have for boot:

/boot itself is a symlink, normally pointing at /bt, the mountpoint for 
my working boot partition, but setup with /boot as a symlink so I can 
point it at /bk/bt, where I can mount my backup boots on other devices, 
when I want to install grub to them.

/bt, LABEL=bt0238gcn1+35l0 : working boot mountpoint and filesystem when 
mounted, where the /boot symlink normally points.  Filesystem is btrfs 
mixed-blockgroup dup mode.  This is a partition on one of a pair of 238 
GiB (256 GB) Corsair Neutron SSDs.


/bk/bt: mountpoint for my backup boots.  The /boot symlink can be 
adjusted to point here when I want to install grub to one of the backup 
boots.

LABEL=bt0238gcn0+35l1 : primary backup boot filesystem, also btrfs mixed-
blockgroup dup, a partition on the other one of the pair of 238 GiB SSDs.

LABEL=bt0465gsg0+47f0 : secondary backup boot filesystem, reiserfs on a 
partition on a 465 GiB spinning rust seagate.

Various other removable drives and their labels for further backups...

All bootable storage (including removable) is GPT partitioned with both a 
legacy-BIOS partition to which grub2 is installed and an EFI partition 
reserved for future use.  Each installed grub points at the /bt boot 
partition on that device, so I can at least get both a grub prompt and a 
bootable kernel on any of them, even with all other storage 
disconnected.  From there it's up to where I point the kernel using root= 
on the kernel commandline, but FWIW, each grub is configured with a menu 
from which I can choose any of my working or primary or secondary backup 
root.

On each of these boot partitions the filesystem layout is:

amd64/
64-bit kernels, configs, system-maps, symlinks...

boot -> .

grub/

[x86/]
[when I had the 32-bit netbook, this was its kernels, etc.]

[A single zero-length file named working, backup, backup2, etc, so I can 
easily confirm which one I actually booted to when testing an updated 
grub install or the like.]


The kernel dirs are laid out as...

$$ ls -1 /bt/amd64

config@
config-4.5.0-dirty
config-4.6.0-dirty
config-4.6.0-rc7-00096-g685764b10-dirty
config.old@
config.stable@
System.map@
System.map-4.5.0-dirty
System.map-4.6.0-dirty
System.map-4.6.0-rc7-00096-g685764b10-dirty
System.map.old@
System.map.stable@
vmlinuz@
vmlinuz-4.5.0-dirty
vmlinuz-4.6.0-dirty
vmlinuz-4.6.0-rc7-00096-g685764b10-dirty
vmlinuz.old@
vmlinuz.stable@


That's three symlinks for each of the map, config and kernel.  They point 
to current, old (previous) and stable.  Since I often test/run and 
occasionally bisect git kernels, current and old often point to git and 
perhaps bisect-bad kernels, and during a bisect I may have nearly a dozen 
kernels and associated files, tho my scripts only maintain the current/
old symlinks.  I update the stable symlink manually, when I consider a 
released version tested well enough locally to be confident doing so.

Only the working boot gets the git kernels.  I update the primary backup 
with the new release-stables each kernel cycle, and only update the 
secondary backup every few kernel cycles.

The git kernel testing and bisects are why I prefer to do my own kernel 
cleanups.  That way I can keep the first git kernel I saw the problem in 
around until I get around to doing a bisect, if the problem hasn't been 
caught and fixed upstream by then, making the bisect easier than it would 
be if I kept updating to see if the problem was fixed, losing track of 
the first bad kernel I saw in the process and thus perhaps forcing 
another round or two of bisection to track down the problem.

And for sure I don't want anything touching the stable symlinks but me, 
manually, when I am sufficiently confident I can do so and won't be left 
in a hole without an easy way to dig myself out as a result.

I use a dracut-built initr*, compressed and appended as an initramfs to 
each kernel built and tested, so once I know the kernel/initramfs 
combination work, I don't have to worry about a buggy initr* update 
breaking older kernels as they have their initramfs builtin.  The dracut-
built initr* is kept on a different filesystem in ordered to leave more 
room in the boot and backups for kernels.


More 

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Patrick McLean]

On Thu, 30 Jun 2016 14:38:26 +0200
Michał Górny  wrote:
> 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.
> 

All of our systems have this:
/boot/${KV}/{vmlinuz,initramfs,System.map,perf,config}-${KV}

With these symlinks
/boot/vmlinuz -> ${KV}/vmlinuz-${KV}
/boot/initramfs -> ${KV}/initramfs-${KV}
/boot/config -> ${KV}/config-${KV}
/boot/System.map -> ${KV}/System.map-${KV}

Some systems also have:
/boot/${KV}/vmlinux-${KV}

/boot/vmlinux -> ${KV}/vmlinux-${KV}

When updating to a new kernel, we generally unpack a tarball
containing the new kernel to /boot and update the symlinks to point to
the new versions. All files related to a kernel are in that kernel's
directory, which makes cleanup somewhat easier.

The values of KV look like one of these:
4.4.14-vanilla-base-1
4.4.14-gentoo-r1-base-1
4.7.0-rc5-vanilla-base-1
4.7.0-rc5-vanilla-base-1+
4.7.0-rc5-vanilla-base-1-00254-g1a0a02d

Mostly, it's a version, sources version, configuration type and
version. These are generated via setting CONFIG_LOCALVERSION, and
whatever else gets spit out by the build system.

[gentoo-dev] Last rites: dev-ruby/rails:3.2 and related packages

[Hans de Graaff]

# Hans de Graaff  (1 Jul 2016)
# With the release of Rails 5.0 versions older than 4.2 are no longer
# supported. Mask Rails 3.2 and related packages for removal in 30
days.
dev-ruby/rails:3.2
dev-ruby/railties:3.2
dev-ruby/activerecord:3.2
dev-ruby/actionmailer:3.2
dev-ruby/actionpack:3.2
dev-ruby/activeresource:3.2
dev-ruby/activemodel:3.2
dev-ruby/activesupport:3.2
dev-ruby/coffee-rails:3.2
dev-ruby/sass-rails:3.2
dev-ruby/activeldap:3
=www-apps/redmine-2.6.10

signature.asc
Description: This is a digitally signed message part

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-