date:20140708

 On Mon, 7 Jul 2014, Michał Górny wrote:

 iii. that the games group along with the game-specific install tree
 should be deprecated and phased out. Games should be installed alike
 any other applications.

The install locations (/usr/games, /usr/share/games, /var/games, etc.)
are specified by the FHS. So they're not entirely games team policy.

Ulrich


pgpJt9yhIEkOb.pgp
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller u...@gentoo.org wrote:
 On Mon, 7 Jul 2014, Michał Górny wrote:

 iii. that the games group along with the game-specific install tree
 should be deprecated and phased out. Games should be installed alike
 any other applications.

 The install locations (/usr/games, /usr/share/games, /var/games, etc.)
 are specified by the FHS. So they're not entirely games team policy.

I just checked some random packages on Debian and found that adherence
to this path there is mixed.  I'd say the majority of packages I
checked installed in /usr/games, but quite a few did not.  Many of the
ones that tended to install there were games that probably predate the
Linux kernel, but this was by no means exclusively the case.

Their official policy says that games should go in /usr/games though.
They also state Each game decides on its own security policy.  They
apparently only use a games group for things like high scores and save
game dirs, and use sgid on the binary to accomplish this (minimizing
its use in general).  (Note, I don't run Debian much, so this is the
result of a quick scan of their policies and the real world may vary.)

Just another data point - we're not obligated to do things one way or
the other...

Rich

[gentoo-dev] Re: The request to abolish games team policy

On 07/08/2014 07:45 AM, Michał Górny wrote:
 Dear Community,
 
 First of all, please do not take this personally. I don't want to
 attack any member of the games team or the team in general. I respect
 their experience and long-term contribution to Gentoo. However,
 I strongly disagree with the policy games team has established and I
 believe that their actions do not serve the best interest of Gentoo.
 
 I am therefore going to propose this request to the next Council. Since
 this will likely require a fair amount of prior discussion, I would
 like to start it already, hopefully reaching at least some point before
 the appropriate Council meeting.
 
 
 I would like to ask the Council to abolish the following policies that
 have been established by the games team:
 
 1. that the games team has authority over the actual maintainers
 on every game ebuild,
 
 2. that every ebuild has to inherit games.eclass as the last eclass
 inherited [1], even if it actually increases the ebuild size rather
 than helping,
 
 3. that games must adhere to games team-specific install locations
 and ownership rules, shortly listed in [2].

Why is Council intervention needed to abolish these policies? They're
not binding.
As far as I know, the games team has no special status so like any other
project they can recommend whatever they want - nobody is obliged to
listen (I certainly don't).

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 6:52 AM, Michael Palimaka kensing...@gentoo.org wrote:
 On 07/08/2014 07:45 AM, Michał Górny wrote:

 1. that the games team has authority over the actual maintainers
 on every game ebuild,


 Why is Council intervention needed to abolish these policies? They're
 not binding.
 As far as I know, the games team has no special status so like any other
 project they can recommend whatever they want - nobody is obliged to
 listen (I certainly don't).


Gentoo projects should probably be viewed as having more authority
than random package maintainers, though not in any absolute sense.
However, they should also generally allow anybody to join them, and
must have an annual election of lead.  The Games project hasn't been
migrated to the Wiki and the page hasn't been touched since 2006, so
I'm a bit skeptical of that (though for all I know they're active and
the membership/lead just hasn't changed).  To the extent that we give
projects a preferential status with regard to authority/etc it really
should only be to the extent that projects uphold their side of the
bargain by following the rules.

Bureaucracy aside, for something as broad as Games I think we should
keep distro-level policy on the light side.  I don't think that it
makes sense to try to establish a security model that amounts to
SELinux-light.  Admins of multi-user systems have much better tools
these days to control what happens on their systems.  I don't have a
problem with generally trying to follow FHS, but I don't see the need
for debates over where kpat goes.

But, that is my own personal two cents.  I'm interested in what active
members of the games project have to offer.

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

Dnia 2014-07-08, o godz. 20:52:49
Michael Palimaka kensing...@gentoo.org napisał(a):

 On 07/08/2014 07:45 AM, Michał Górny wrote:
  I would like to ask the Council to abolish the following policies that
  have been established by the games team:
  
  1. that the games team has authority over the actual maintainers
  on every game ebuild,
  
  2. that every ebuild has to inherit games.eclass as the last eclass
  inherited [1], even if it actually increases the ebuild size rather
  than helping,
  
  3. that games must adhere to games team-specific install locations
  and ownership rules, shortly listed in [2].
 
 Why is Council intervention needed to abolish these policies? They're
 not binding.
 As far as I know, the games team has no special status so like any other
 project they can recommend whatever they want - nobody is obliged to
 listen (I certainly don't).

The games team believes that they're binding. In fact, I recall one of
the team members remarking explicitly that they're going to alter
ebuilds that were committed without their approval.

In fact, they did remove ebuilds from the tree in the past for this
reason [1].

[1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny mgo...@gentoo.org wrote:

 The games team believes that they're binding. In fact, I recall one of
 the team members remarking explicitly that they're going to alter
 ebuilds that were committed without their approval.

 In fact, they did remove ebuilds from the tree in the past for this
 reason [1].

 [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0

This was 3 weeks ago, so certainly relevant.  Was this removal by
mutual agreement (ie the games team and maksbotan ?

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

 On Tue, 8 Jul 2014, Rich Freeman wrote:

 On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller u...@gentoo.org wrote:
 The install locations (/usr/games, /usr/share/games, /var/games, etc.)
 are specified by the FHS. So they're not entirely games team policy.

 I just checked some random packages on Debian and found that adherence
 to this path there is mixed.  I'd say the majority of packages I
 checked installed in /usr/games, but quite a few did not.  Many of the
 ones that tended to install there were games that probably predate the
 Linux kernel, but this was by no means exclusively the case.

 Their official policy says that games should go in /usr/games though.
 They also state Each game decides on its own security policy.  They
 apparently only use a games group for things like high scores and save
 game dirs, and use sgid on the binary to accomplish this (minimizing
 its use in general).  (Note, I don't run Debian much, so this is the
 result of a quick scan of their policies and the real world may vary.)

It certainly differs between distros. Debian generally uses /usr/games
and has a games group for score files. Fedora has chosen to ignore the
FHS and installs everything in /usr/bin. IIUC, they also use an own
group for each game if it needs to write shared score files. [1]

Ulrich

[1] http://thread.gmane.org/gmane.comp.freedesktop.games/365


pgpXJ63S4Lv_h.pgp
Description: PGP signature

[gentoo-dev] Re: The request to abolish games team policy

On 07/08/2014 09:38 PM, Michał Górny wrote:
Dnia 2014-07-08, o godz. 20:52:49
Michael Palimaka kensing...@gentoo.org napisał(a):

On 07/08/2014 07:45 AM, Michał Górny wrote:
I would like to ask the Council to abolish the following policies that
have been established by the games team:

1. that the games team has authority over the actual maintainers
on every game ebuild,

2. that every ebuild has to inherit games.eclass as the last eclass
inherited [1], even if it actually increases the ebuild size rather
than helping,

3. that games must adhere to games team-specific install locations
and ownership rules, shortly listed in [2].

Why is Council intervention needed to abolish these policies? They're
not binding.
As far as I know, the games team has no special status so like any other
project they can recommend whatever they want - nobody is obliged to
listen (I certainly don't).

The games team believes that they're binding. In fact, I recall one of
the team members remarking explicitly that they're going to alter
ebuilds that were committed without their approval.

In fact, they did remove ebuilds from the tree in the past for this
reason [1].

[1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0

These sorts of actions are contrary to GLEP 39. I would encourage anyone
who is a victim of such behaviour to file a complaint with Comrel.

Whether we like it or not, the only projects with any kind of real
authority are those authorised by the Council. Whatever the games teams
happens to believe is irrelevant. They're free to petition the Council
to change reality of the situation if they don't like it.

Re: [gentoo-dev] Re: The request to abolish games team policy

 On Tue, 8 Jul 2014, Michał Górny wrote:

 In fact, they did remove ebuilds from the tree in the past for this
 reason [1].

Given that this was a live ebuild that failed to compile [2] and was
dumped onto the games team few weeks after it was committed to the
tree [3], I can even understand their reaction, in this particular
case.

Ulrich


[2] https://bugs.gentoo.org/show_bug.cgi?id=431552
[3] 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/metadata.xml?hideattic=0r1=1.1r2=1.2


pgpw_hLtRboPg.pgp
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-08 Thread Tomáš Chvátal

2014-07-08 14:42 GMT+02:00 Ulrich Mueller u...@gentoo.org:

  On Tue, 8 Jul 2014, Michał Górny wrote:

  In fact, they did remove ebuilds from the tree in the past for this
  reason [1].

 Given that this was a live ebuild that failed to compile [2] and was
 dumped onto the games team few weeks after it was committed to the
 tree [3], I can even understand their reaction, in this particular
 case.


[2] Clear upstream bug, we remove live versions when from time to time
upstream break their repo? If you take look on 1.0 it IS almost the same
ebuild?
[3] I remved myself from maitnainership as I found out I don't have enought
time to work on stuff in Gentoo to keep myself only in office and to make
them working... So if they didn't want the live version it is perfectly
sane reasoning for pruning that before, but removing the 1.0 commited few
weeks ago it is just utter stupid approach and reason why I avoid to have
to touch anything with games team in Gentoo.

Tom


 Ulrich


 [2] https://bugs.gentoo.org/show_bug.cgi?id=431552
 [3]
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/metadata.xml?hideattic=0r1=1.1r2=1.2

Re: [gentoo-dev] Re: The request to abolish games team policy

Dnia 2014-07-08, o godz. 08:10:14
Rich Freeman ri...@gentoo.org napisał(a):

 On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny mgo...@gentoo.org wrote:
 
  The games team believes that they're binding. In fact, I recall one of
  the team members remarking explicitly that they're going to alter
  ebuilds that were committed without their approval.
 
  In fact, they did remove ebuilds from the tree in the past for this
  reason [1].
 
  [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0
 
 This was 3 weeks ago, so certainly relevant.  Was this removal by
 mutual agreement (ie the games team and maksbotan ?

I'm afraid not though I don't know for sure. Maks doesn't seem to be
around at the moment. Judging from the bug [1], I'd dare say
the proxied maintainer had to notice the disappearing ebuild file
himself.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=470188#c6

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

 On Tue, 8 Jul 2014, Tomáš Chvátal wrote:

 [3] I remved myself from maitnainership as I found out I don't have
 enought time to work on stuff in Gentoo to keep myself only in
 office and to make them working... So if they didn't want the live
 version it is perfectly sane reasoning for pruning that before, but
 removing the 1.0 commited few weeks ago it is just utter stupid
 approach and reason why I avoid to have to touch anything with games
 team in Gentoo.

I fear it's not such a simple black-and-white picture here. They have
removed a package belonging to the games herd (and not working at that
point), which I believe is in their right. Later this package was
resurrected, I suppose without talking to them. (?)

Not sure how I would react if I had removed a package from app-emacs,
and some developer would restore it, without consulting the emacs team
first. (Well, probably I'd have a serious word with the dev, at that
point ...)

Ulrich


pgpgthirFlmnq.pgp
Description: PGP signature

[gentoo-dev] Looking for alternative to RESTRICT=userpriv

Hello, developers.

I've been doing some research wrt use of RESTRICT=userpriv [1] lately
and found out that most of the affected packages use it solely to gain
access to files or devices that are restricted to specific groups. I've
specifically noted three cases:

1) ebuilds using CUDA that needed to access /dev/nvidia* (restricted to
video group),

2) game ebuilds that needed to access game executables (restricted to
games group but hopefully subject to change),

3) qmail-related ebuilds that needed to access restricted files (no
details yet).

I believe that most (if not all) of uses of RESTRICT=userpriv are
overkill. It implies elevating privileges for the whole build process
while what's really needed is an access to a particular file or device,
or a capability of some kind for a single command execution.

I would therefore like to ask the Community for ideas on how
RESTRICT=userpriv could be effectively replaced by something safer.


I can enumerate the following possibilities:

a) explicitly requesting user to alter group membership for the build
user. This is already done in some of the CUDA ebuilds.

Advantages:

- limits elevated privileges to a particular group access,

- works now.

Disadvantages:

- requires manual intervention (we even can't properly name the user
  since there's no PMS function/variable to obtain it),

- increases privileges for all ebuilds rather than the one needing it.
  Developers using it will not get proper failures for ebuilds not
  having the check,

- doesn't cover other uses of FEATURES=userpriv.


b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups() to
transparently enable group membership for the build process.

Advantages:

- transparent, relatively simple.

Disadvantages:

- quite ugly name ;),

- doesn't cover other uses of FEATURES=userpriv.


c) 'esudo' helper [3]. This is a more generic form of (2), with support
for other potential privilege changes.

Advantages:

- allows to raise privileges precisely for one command,

- flexible -- may alter EUID, EGID, groups, capabilities.

Disadvantages:

- hard to implement -- especially if we want to make it capable of
  running bash functions.


What do you think? Do you have other ideas?


[1]:https://bugs.gentoo.org/show_bug.cgi?id=516568
[2]:https://bugs.gentoo.org/show_bug.cgi?id=516614
[3]:https://bugs.gentoo.org/show_bug.cgi?id=516616

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 8:42 AM, Ulrich Mueller u...@gentoo.org wrote:
 On Tue, 8 Jul 2014, Michał Górny wrote:

 In fact, they did remove ebuilds from the tree in the past for this
 reason [1].

 Given that this was a live ebuild that failed to compile [2] and was
 dumped onto the games team few weeks after it was committed to the
 tree [3], I can even understand their reaction, in this particular
 case.

I'm talking about the removal of 1.0 3 weeks ago, not the removal of
the live ebuild 2 years ago.

I don't know if the new maintainer was aware that the package had
previously been removed, but I'm not sure that it really matters.  As
long as the maintainer actually intended to maintain it I think that
matters more.  If the package had security issues/etc that would be a
different matter.

The 1.0 package was not a live ebuild, either.  Removing packages that
are live ebuilds that have no maintainer and a dying upstream is a bit
different from removing packages that are not live ebuilds that do
have a maintainer, even if upstream isn't necessarily better off.  In
any case, the maintainer certainly should have been consulted.

I'd encourage anybody re-introducing a package to also try to talk to
those involved with removing it, but it might not be obvious if an
obscure package had been removed two years in the past.

Uh, and what is up with games-strategy/openxcom and
games-engines/openxcom?  Was the re-introduction a dup?  If so, then
removal of it makes sense, though for that reason, and not simply
because it was added without talking to the games herd...

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

Dnia 2014-07-08, o godz. 09:38:08
Rich Freeman ri...@gentoo.org napisał(a):

 Uh, and what is up with games-strategy/openxcom and
 games-engines/openxcom?  Was the re-introduction a dup?  If so, then
 removal of it makes sense, though for that reason, and not simply
 because it was added without talking to the games herd...

Well, looking at that it seems that the games-engines/ version was
introduced 5 minutes after removing games-strategy/. So it was more of
a takeover + package move than removal.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: Looking for alternative to RESTRICT=userpriv

 On Tue, 8 Jul 2014, Michał Górny wrote:

 a) explicitly requesting user to alter group membership for the
 build user. This is already done in some of the CUDA ebuilds.

 [...]

This doesn't work out of the box for users, therefore it is not really
a solution.

 b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups()
 to transparently enable group membership for the build process.

 Advantages:

 - transparent, relatively simple.

 Disadvantages:

 - quite ugly name ;),

Certainly this can be changed. :)

 - doesn't cover other uses of FEATURES=userpriv.

Which ones? Are there examples for such uses in the Portage tree?

 c) 'esudo' helper [3]. This is a more generic form of (2), with
 support for other potential privilege changes.

 [...]

 Disadvantages:

 - hard to implement -- especially if we want to make it capable of
   running bash functions.

Any idea how to implement it? Does it imply adding app-admin/sudo to
the system set?

 What do you think? Do you have other ideas?

Looking at the bugs that you have filed, it looks like most ebuilds
using userpriv restriction could be fixed, without any additional
support added to the package manager.

How many ebuilds will be left, after doing these fixes? Is it really
worth the effort then?

Ulrich


pgpJHuxhCGDUf.pgp
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-08 Thread Maxim Koltsov

2014-07-08 16:10 GMT+04:00 Rich Freeman ri...@gentoo.org:

 On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny mgo...@gentoo.org wrote:
 
  The games team believes that they're binding. In fact, I recall one of
  the team members remarking explicitly that they're going to alter
  ebuilds that were committed without their approval.
 
  In fact, they did remove ebuilds from the tree in the past for this
  reason [1].
 
  [1]:
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0

 This was 3 weeks ago, so certainly relevant.  Was this removal by
 mutual agreement (ie the games team and maksbotan ?

 Rich


No, I was not notified beforehand (or failed to recieve such notification,
it does not matter now). This was a proxied commit, I did a usual check of
the ebuild and found no problems. I admit that the ebuild was
not-so-compliant to games herd rules, though. Still, immediate removal
without notification and/or discussion did annoy me.
BTW, I fail to see the reason of move to games-engines, but that's another
issue.

-- 
Regards, Maxim.

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-08 Thread Samuli Suominen

On 08/07/14 17:18, Maxim Koltsov wrote:

2014-07-08 16:10 GMT+04:00 Rich Freeman ri...@gentoo.org
mailto:ri...@gentoo.org:

On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny mgo...@gentoo.org
mailto:mgo...@gentoo.org wrote:

The games team believes that they're binding. In fact, I recall
one of
the team members remarking explicitly that they're going to alter
ebuilds that were committed without their approval.

In fact, they did remove ebuilds from the tree in the past for this
reason [1].

[1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0

This was 3 weeks ago, so certainly relevant. Was this removal by
mutual agreement (ie the games team and maksbotan ?

Rich

No, I was not notified beforehand (or failed to recieve such
notification, it does not matter now). This was a proxied commit, I
did a usual check of the ebuild and found no problems. I admit that
the ebuild was not-so-compliant to games herd rules, though. Still,
immediate removal without notification and/or discussion did annoy me.
BTW, I fail to see the reason of move to games-engines, but that's
another issue.

--
Regards, Maxim.

Did you get the ebuild reviewed and accepted for committing at
#gentoo-games as per existing guidelines[1]?
If you didn't, then you propably managed to annoy them first, and the
outcome was expected (as in, the missing work
was done for you, with best intentions)
I've never had any issues with getting games ebuilds reviewed at
#gentoo-games and I've committed dozen(s) of
games to tree.
I've been on the channel, almost always I'm online, I haven't seen
people getting ignored there who have proper
initial work done first (if the ebuild is in a shape you'd have to
rewrite every second line, you might get ignored,
and I find that to be reasonable, since we are all volunteers, afterall)

[1] http://dev.gentoo.org/~vapier/i-wanna-be-in-the-games-herd.html

And some personal thoughts about the initial proposal...
I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
and 2. should definately
stay as is. Since games ebuilds are low maintenance, there is no intrest
in getting dozens of 'eclass porting
bugs', which is why inheriting games last prevents future breakage as
well as ensure the eclasses
exported phases are respected.
It seems to me like people aren't making the effort of joining to the
team and meeting the high quality
ebuild syntax they've kept up...

- Samuli

[gentoo-dev] Re: The request to abolish games team policy

On 07/09/2014 01:22 AM, Samuli Suominen wrote:
 And some personal thoughts about the initial proposal...
 I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
 and 2. should definately
 stay as is.
What authority does the game team have over anything? Did it get special
blessing from the Council? Isn't it just another regular project as per
GLEP 39?

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 12:17 PM, Michael Palimaka kensing...@gentoo.org wrote:
 On 07/09/2014 01:22 AM, Samuli Suominen wrote:
 And some personal thoughts about the initial proposal...
 I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
 and 2. should definately
 stay as is.
 What authority does the game team have over anything? Did it get special
 blessing from the Council? Isn't it just another regular project as per
 GLEP 39?


While I tend to agree with the sentiment, and it may not be productive
to try to turn this into a bunch of rules, it is beneficial to have
guidelines/etc managed by projects in general, and to have maintainers
generally try to follow them.

So, if you're using the multilib eclass in your ebuild then it only
make sense to coordinate with the project that manages that.  It isn't
so much about following rules as it just makes sense to not have
everything randomly break anytime somebody changes something.

If the games team is active and wants to help steer contributions that
isn't a bad thing.  I'd suggest a bit more finesse though - they can
at least talk to maintainers before doing a package move.

I've managed exactly one game package and I can't say that working
with the games herd has ever been a problem.  For the most part
they're fairly hands-off as long as you follow their rules.

That said, if anybody wants to be able to tell others what they can
and can't do then they should be prepared to have their rules
bikesheded in public from time to time.  That's just the price of
fame, and if all games are supposed to follow the game project rules,
then those rules are perfectly good cannon fodder for -dev, whether it
gets escalated to council or not.  :)

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-08 Thread hasufell

Samuli Suominen:
 
 It seems to me like people aren't making the effort of joining to the
 team and meeting the high quality
 ebuild syntax they've kept up...
 

There is no games _team_. There is Mr_Bones_ (and I have learned a lot
from him and am able to collaborate with him).

And that is that.

There is no active lead and the lead ignores joining requests and
doesn't care about non-trivial games libraries like SDL2.

So, it really isn't as you say.

[gentoo-dev] Re: The request to abolish games team policy