On Mon, Jul 07, 2014 at 11:45:02PM +0200, Michał Górny wrote:
I would like to ask the Council to abolish the following policies that
have been established by the games team:
Why? What's the use case? Or in other words, what has ticked you off
to request the abolishment of status-quo?
The
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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.
On 07/09/2014 02:58 AM, Rich Freeman wrote:
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,
El mar, 08-07-2014 a las 17:15 +, hasufell escribió:
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
Pacho Ramos:
What kind of games packages does he want to maintain in a strictly
way? Maybe one way to cooperate would be to have two herds:
- games-base (or similar) - the more stricter and the one Mr_Bones
would likely still prefer to handle himself. It would take care of
central libs
arm has a historical problem with stabilization, while keywording
doesn't require access to all arm sub-arches the problem with the
stabilization slowness causes running a full ~arm to become hard. By
that I mean that if someone keywords something for arm because it works
on armv7 and I run ~arm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/08/2014 08:32 AM, Ulrich Mueller wrote:
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
On 08/07/14 19:17, Michael Palimaka 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
On Wed, 09 Jul 2014 06:55:54 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
On 08/07/14 19:17, Michael Palimaka 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
Hello fellow Portage developers,
attached portage patch draft aims to allow for easy distributing eclasses to be
tested by
multiple tinderboxes on various architectures, without being active for normal
installs.
Usage is to have in make.conf (or profile): PORTAGE_ECLASS_VARIANTS=testing
and
Am 08.07.2014 18:58, schrieb Michael Haubenwallner:
Hello fellow Portage developers,
attached portage patch draft aims to allow for easy distributing eclasses to
be tested by
multiple tinderboxes on various architectures, without being active for
normal installs.
What does the patch
Am 2014-07-08 19:11, schrieb Sebastian Luther:
Am 08.07.2014 18:58, schrieb Michael Haubenwallner:
Hello fellow Portage developers,
attached portage patch draft aims to allow for easy distributing eclasses to
be tested by
multiple tinderboxes on various architectures, without being active
32 matches
Mail list logo
