[gentoo-project] Call for agenda items - Council meeting 2013-10-08

[gentoo-project] Call for agenda items - Council meeting 2013-10-08

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 638 bytes --]

In two weeks from now, the council will again have its regular monthly 
meeting. Now is the time to raise and prepare items that the council should 
put on the agenda to discuss or vote on.

Please respond to this message with agenda items. Do not hesitate to repeat 
your agenda item here with a pointer if you previously suggested one (since 
the last meeting).

The agenda for the next meeting will be sent out on Tuesday 2013-10-01.

Please respond to the gentoo-project list, if possible.

Best, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2013-10-08

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/24/2013 09:48 PM, Andreas K. Huettel wrote:
> In two weeks from now, the council will again have its regular
> monthly meeting. Now is the time to raise and prepare items that
> the council should put on the agenda to discuss or vote on.
> 
> Please respond to this message with agenda items. Do not hesitate
> to repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).
> 
> The agenda for the next meeting will be sent out on Tuesday
> 2013-10-01.
> 
> Please respond to the gentoo-project list, if possible.
> 
> Best, Andreas
> 
Hi,

Back in May 2013, Tomáš (scarabeus) had posted a new Code of
Conduct[1][2]. This has been discussed in the council[3] but at the
point it was voted to discuss it again in the future[4]
(Unfortunately there is no summary for that meeting, look at the
<11.06.2013 19:31> lines). Therefore, I think it's time to bring this
to the Council again.

[1] http://thread.gmane.org/gmane.linux.gentoo.project/2470
[2] http://dev.gentooexperimental.org/~scarabeus/gentoo-coc.txt
[3] http://thread.gmane.org/gmane.linux.gentoo.project/2486/focus=2488
[4] http://www.gentoo.org/proj/en/council/meeting-logs/20130611.txt

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQJ8BAEBCgBmBQJSQ0YOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun886cYQAL8+JEJ4fcGHZdlWqG23yV0R
606v+CV8SbQjdqEjsfMTRyYyk4SE2wLJM3b2Hh5e+AknoNW0bSafYOYi0jmfp0lr
/cz/KjUnGvDeEVGTTwUO+GSRXYSIGyXNP3rtlt10GFcI76MWdE9H3Ko8wnwWsJ6d
UVSCR0S7QO2n/zgoUxst8x6vRBqVJR3+sa2EAxcB4qGWPjTptZvUPt10+W1mBT7i
1owujHY9F2BcZfnQ3eM58osLwSkmjvlvG6pCAuXkuZMVRK5+Hw0r8XnIRgzC4hSo
QtJd1hVYBcbaUYARdQI772enw1keDE5le7RnYd9B77cQfrVQO6FKrT0VSsLChG2z
Hek9p6JA2umhSP8WkNp22H7bRMXCMU9aY3qAp6jOIA3I6ym5XSRyr5QIquitVnFr
SdPrDOjn5HstQIYfd/xw8cOtXdD8A+RsZb/bLjj8e4BvWPCCnGle+3fGMfB5BF8x
FCCeOUExDJdfArvHSoyAahQ3HRtOQ33243blA00V1ZkktR4oBxb4YJkzi6/YliBK
VVbxKxBzMxOymwKaMvHvzZ27HVna9hKvho0Fo5KJ4Y/kAIFnXd/YFp/eH+1iXLI4
TbTrq/w9zuLpGA4HDzKS2zrXSMLhpcFSAHUQSRvwXhSrrElbx/8NkuogT42jnRHg
2/28jnEkCaKOMuX9eVuZ
=3wub
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2013-10-08

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

Council members,

a policy was just pointed out to me on IRC today that I think we should
look at changing with regard to how we are supposed to deal with live
ebuilds.

According to the dev manual, all live ebuilds are supposed to be put in
package.mask [1]. The reality of the situation, however, is that we are
mostly using empty keywords for live ebuilds.

I think the policy of requiring package.mask for live ebuilds happened
before the empty keywords option was available.

Can we discuss and maybe vote on how we want live ebuilds in the tree? I
see three possibilities:

1) empty keywords (this appears to be what most people are doing)
2) package.mask (not required, the way I see it, because of 1 and
because package.mask shouldn't be permanent)
3) both package.mask and empty keywords (this would be double masking,
and again shouldn't be necessary)

Thoughts?

William

[1]
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2013-10-08

[Agostino Sarubbo]

On Saturday 02 November 2013 13:52:17 William Hubbs wrote:
> 1) empty keywords (this appears to be what most people are doing)
> 2) package.mask (not required, the way I see it, because of 1 and
> because package.mask shouldn't be permanent)
> 3) both package.mask and empty keywords (this would be double masking,
> and again shouldn't be necessary)
> 
> Thoughts?

The goal is avoid to install them without any type of interactions. I guess 
empty keywords respect that and at the same time avoid us to write the 
package.mask file.
-- 
Agostino Sarubbo
Gentoo Linux Developer

Re: [gentoo-project] Call for agenda items - Council meeting 2013-10-08

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/02/2013 02:52 PM, William Hubbs wrote:
> Council members,
> 
> a policy was just pointed out to me on IRC today that I think we should
> look at changing with regard to how we are supposed to deal with live
> ebuilds.
> 
> According to the dev manual, all live ebuilds are supposed to be put in
> package.mask [1]. The reality of the situation, however, is that we are
> mostly using empty keywords for live ebuilds.
> 
> I think the policy of requiring package.mask for live ebuilds happened
> before the empty keywords option was available.
> 
> Can we discuss and maybe vote on how we want live ebuilds in the tree? I
> see three possibilities:
> 
> 1) empty keywords (this appears to be what most people are doing)
> 2) package.mask (not required, the way I see it, because of 1 and
> because package.mask shouldn't be permanent)
> 3) both package.mask and empty keywords (this would be double masking,
> and again shouldn't be necessary)
> 
> Thoughts?

Personally, I prefer option 1.  That said, there is a reason for Options
2 and 3.

When using a minor arch, a lot of packages are not keyworded for that
arch, which then requires me to install them with KEYWORDS="**" and that
pulls in live ebuilds all the time.  Personally, I'm fine dealing with
things like that, but that would be a valid reason for requiring
package.mask.  That said, if we want to persue that, I would say that we
should start adding keywords to live ebuilds (~arch obviously) and
p.mask them so we know what arches it is expected to work on.


> 
> William
> 
> [1]
> http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSdVGkAAoJEKXdFCfdEflKRFsP/1dfWkoiEyJtCXlOfdFaYQpm
YtSvp8Oqs6dv+aRISHWemDC3bplc2h5jZ+kKrDC+TpXmX6jdrTlScaSeu0qTtbFK
elnjI9fuqcn6AQGhV5hicY/tqlmiHTLE7BqC12lLceFhkrdXsvSXrlt9JW+ZoBcG
lVzUrTFN4oU8ZMhxV/KN9tmE4p6lGdKPweqsF50Zpj6la/BkupSiteyPALseye+Q
0waJPParnFSnYO/YsxjyvyBrlpQJ1TIsYNRbiTuc/uurFSTuXbxC0O8bm1sd3Jmd
xp45KCZ5qAM4p3PDFYKLhRcgszjbieJK8KaoVyLKFe//2OT+gtmU6ggcbi3Cyj77
FN0k9yV6dyp6cAIf/nqRwDKGQ/iSvgEA/JnEKwwB29pXctO/l3HxB5/RxJbdclnR
LBDV1PHI3M18hS4+r9Mc8MreJuPRnO4/wKFpaCqI6hZRQ+wm58OXW2qzZ+lByKzA
AH3938cXX7F1a65rtxBazVOGEcZXxVk66GHm2QinHkUd5uu+Ry8n6Z87TVl6yRVe
BxB0nT9gXJghtO+BCqPUTa25k/g8YrHKbQkHMPfZTBPvh9mxfun28vBjHykcGQM2
W4Twkt6WPKW2XdRRw+NZS08MnZk6Bz+6ppxH9zxG3RYg3daxN1OoTAYUk1iqqgJs
tu5bke0ykV0tD0WqvAs6
=lnIf
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2013-10-08

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On Sat, Nov 02, 2013 at 01:52:17PM -0500, William Hubbs wrote:
> Council members,
> 
> a policy was just pointed out to me on IRC today that I think we should
> look at changing with regard to how we are supposed to deal with live
> ebuilds.
> 
> According to the dev manual, all live ebuilds are supposed to be put in
> package.mask [1]. The reality of the situation, however, is that we are
> mostly using empty keywords for live ebuilds.
> 
> I think the policy of requiring package.mask for live ebuilds happened
> before the empty keywords option was available.
> 
> Can we discuss and maybe vote on how we want live ebuilds in the tree? I
> see three possibilities:
> 
> 1) empty keywords (this appears to be what most people are doing)
> 2) package.mask (not required, the way I see it, because of 1 and
> because package.mask shouldn't be permanent)
> 3) both package.mask and empty keywords (this would be double masking,
> and again shouldn't be necessary)

Ok folks, we were talking about this on #g-council, and there actually
is a bug about this that would resolve the issue, so we don't need this
on the agenda [1].

Sorry for the noise.

William

https://bugs.gentoo.org/show_bug.cgi?id=421993

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2013-10-08

[Markos Chandras]

On 11/02/2013 09:24 PM, William Hubbs wrote:
> On Sat, Nov 02, 2013 at 01:52:17PM -0500, William Hubbs wrote:
>> Council members,
>>
>> a policy was just pointed out to me on IRC today that I think we should
>> look at changing with regard to how we are supposed to deal with live
>> ebuilds.
>>
>> According to the dev manual, all live ebuilds are supposed to be put in
>> package.mask [1]. The reality of the situation, however, is that we are
>> mostly using empty keywords for live ebuilds.
>>
>> I think the policy of requiring package.mask for live ebuilds happened
>> before the empty keywords option was available.
>>
>> Can we discuss and maybe vote on how we want live ebuilds in the tree? I
>> see three possibilities:
>>
>> 1) empty keywords (this appears to be what most people are doing)
>> 2) package.mask (not required, the way I see it, because of 1 and
>> because package.mask shouldn't be permanent)
>> 3) both package.mask and empty keywords (this would be double masking,
>> and again shouldn't be necessary)
> 
> Ok folks, we were talking about this on #g-council, and there actually
> is a bug about this that would resolve the issue, so we don't need this
> on the agenda [1].
> 
> Sorry for the noise.
> 
> William
> 
> https://bugs.gentoo.org/show_bug.cgi?id=421993
> 
package.mask means "the package may or may not work which is true for
live ebuilds"

KEYWORDS="" means "the package may or may not work on $ARCH" which is
true for live ebuilds

So they are two different kind of maskings and they are both valid to me.

-- 
Regards,
Markos Chandras

[gentoo-project] Re: Call for agenda items - Council meeting 2013-10-08

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/02/2013 03:25 PM, Rick "Zero_Chaos" Farina wrote:
> 
> When using a minor arch, a lot of packages are not keyworded for that arch, which then requires
> me to install them with KEYWORDS="**" and that pulls in live ebuilds all the time.  Personally,
> I'm fine dealing with things like that, but that would be a valid reason for requiring 
> package.mask.

Just as a FYI, to get the "stable or testing on any arch" semantics that are probably what you
want, instead of "completely ignore keywords" which is what "**" gets you, you can use
ACCEPT_KEYWORDS="* ~*" (or the equivalent in package.accept_keywords).  "*" means "stable
anywhere", "~*" means "testing anywhere", so by including both, you match everything except empty
keywords (and the nearly meaningless "-*" keywords).

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJSduwxAAoJELHSF2kinlg4JP4QAK+267ptNky01+0i3p+4xQde
UNaD3lajCHNlv3RDy0oaB8yx3Qz2Ox3ZWPJc4sGJs+L3VWc3okRI8pKyHmbx7Kl7
/QCdSF7j71kNFl2h1NqMLkJLewlwRbVwYmH4YlSMJMPIPaoK4j2ZA9F6YFpBoofI
OKzL5Q06ch7lJwydkkafnzD/ohPn2RSUytHypZlCsmR+uQVFk2qssiYHQdHcc27k
rXhWElxQmZ+Lxr2/2AoxowEYcQfYhHbm9jUy16K1EcHvlKIW9QRLv9w57+ve2SSY
8xs5GGl1sBOjjipibCVfKqcoeyBNR4u8b3ffde3NpFC2z+yFVALxUR0HEGLsZ310
ce1CfhESVePGmrypWlxjzqMJxnUQoiWAHR/ZoywRZWArnPo0qX5jltQojh+4B87x
PdhpzKWtcfQm+dwNkJQMoUZo96H85LgVwLU6loi7T4RoFmCS2PhpxjQbtHFMUQIQ
g2qXXtMQuSXN0PIXRAIPONdBteRkNpPYqmf3jjfD0z2YwEdJXBm0JyTCEJ5T+i54
uLpM8a0Vmc8vs1gEnbTpuIj6GV3/RqYkdfU1qB8QPebj7IYFYRC2XhhEy+KoopaV
ba/TusZwyp45a+wUlcSTpPhQe9o63TZasoUkwOkxp6SwmjyhO6XeNxoV1DZTTdQa
spaKxDaPF8fEBttacZQz
=mYxH
-----END PGP SIGNATURE-----