[gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Jeroen Roovers]

On Fri, 18 Oct 2013 18:18:43 +0000
bugzilla-daemon@gentoo.org wrote:

> DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
> whose email is mentioned below. To comment on this bug, please visit:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=488318
> 
> Tom Wijsman (TomWij) <tomwij@gentoo.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Summary|media-video/mpv broken
> |media-video/mpv[luajit] - |dependency on               |Keyword
> request on alpha, |dev-lang/luajit:2           |arm, ppc, ppc64, sparc
> 
> --- Comment #10 from Tom Wijsman (TomWij) <tomwij@gentoo.org> ---
> (In reply to Jeroen Roovers from comment #5)
> > No, you broke it for HPPA users and for devs working on mpv.
> 
> Yes, HPPA only because of the comment in package.use.mask; no
> problems for devs.

"Breaking the tree" in this case quite literally means "using repoman
commit --force" because repoman would not otherwise let you do that[a].
As I explained to you in comment #5[b] you should have simply dropped
the keywords instead of messing with the profiles and you should have
notified the affected arch teams (all of them):

> > Sometimes you may need to remove a keyword because of new unresolved
> > dependencies. If you do this, you *must* file a bug notifying the
> > relevant arch teams."[1]
> 
> For all arches Nikoli planned to do this (#gentoo-desktop; to avoid
> filing duplicate, I didn't); he delayed this, but this should not
> form a problem since the temporary masks are in place. It does on
> HPPA, as I am not permitted to remove the keyword on the USE flag.
> 
> > *After* you broke the tree.
> 
> The comment literally says to file a bug instead of touching it; so,
> yes, as a result of what I am requested to do by that comment the
> tree breaks for HPPA.

You didn't file a bug report and you committed a broken ebuild.

> That's what the file is designed to solve; and as far as I can tell,
> only HPPA does it different so as I'm new to doing this on the HPPA
> arch I'm not sure what you want instead. We did plan to do what was
> intended; so, why is it atrocity?
> 
> We should pursue consensus on consistent USE masking on the
> profile.use.mask [1] thread as two different methods of which one
> undocumented doesn't make much sense; anyhow, that's outside the
> scope of this bug.

As it has been discussed on this mailing list endlessly, there already
is a consensus:

1a) you drop the affected keywords, unless
1b) this causes you to drop (many) more keywords on revdeps, in which
    case you can package.(use.)mask the relevant bits
2) you inform the affected arch teams

Step 2) could easily be done well in advance of 1/a). In the
media-video/mpv case, nothing was stopping you from doing the most
easy, single-line-of-code change to fix the issue, which was to drop
the affected keywords. Instead you chose to edit a multitude of files
in profiles/ without notification to the arch teams.

> [1]
> http://gentoo.2317880.n4.nabble.com/best-way-to-use-profiles-and-package-use-mask-td16465.html

Well, you read my response there. Nothing has changed. devmanual hasn't
changed either. What is your point here?


      jer


[a]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-video/mpv/mpv-0.2.0.ebuild?view=log
[b] https://bugs.gentoo.org/show_bug.cgi?id=488318#c5

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Tom Wijsman]

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

On Sat, 19 Oct 2013 19:01:44 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Fri, 18 Oct 2013 18:18:43 +0000
> bugzilla-daemon@gentoo.org wrote:
> 
> > (In reply to Jeroen Roovers from comment #5)
> > > No, you broke it for HPPA users and for devs working on mpv.
> > 
> > Yes, HPPA only because of the comment in package.use.mask; no
> > problems for devs.
> 
> "Breaking the tree" in this case quite literally means "using repoman
> commit --force" because repoman would not otherwise let you do
> that[a]. As I explained to you in comment #5[b] you should have
> simply dropped the keywords instead of messing with the profiles and
> you should have notified the affected arch teams (all of them):

Yes, I will drop the HHPA keyword in the future, that was a mistake; as
for notifying the arches, that was planned so why do you repeat that?

> > > Sometimes you may need to remove a keyword because of new
> > > unresolved dependencies. If you do this, you *must* file a bug
> > > notifying the relevant arch teams."[1]
> > 
> > For all arches Nikoli planned to do this (#gentoo-desktop; to avoid
> > filing duplicate, I didn't); he delayed this, but this should not
> > form a problem since the temporary masks are in place. It does on
> > HPPA, as I am not permitted to remove the keyword on the USE flag.
> > 
> > > *After* you broke the tree.
> > 
> > The comment literally says to file a bug instead of touching it; so,
> > yes, as a result of what I am requested to do by that comment the
> > tree breaks for HPPA.
> 
> You didn't file a bug report and you committed a broken ebuild.

Because I prefer not to file a duplicate, Nikoli planned to file it;
this was decided in #gentoo-desktop.

> > That's what the file is designed to solve; and as far as I can tell,
> > only HPPA does it different so as I'm new to doing this on the HPPA
> > arch I'm not sure what you want instead. We did plan to do what was
> > intended; so, why is it atrocity?
> > 
> > We should pursue consensus on consistent USE masking on the
> > profile.use.mask [1] thread as two different methods of which one
> > undocumented doesn't make much sense; anyhow, that's outside the
> > scope of this bug.
> 
> As it has been discussed on this mailing list endlessly, there already
> is a consensus:
> 
> 1a) you drop the affected keywords, unless
> 1b) this causes you to drop (many) more keywords on revdeps, in which
>     case you can package.(use.)mask the relevant bits
> 2) you inform the affected arch teams

Please provide a reference to this consensus.

> Step 2) could easily be done well in advance of 1/a). In the
> media-video/mpv case, nothing was stopping you from doing the most
> easy, single-line-of-code change to fix the issue, which was to drop
> the affected keywords. Instead you chose to edit a multitude of files
> in profiles/ without notification to the arch teams.

Or committing the same effort to package.use.mask; which appears to be
fine for all other architectures but an exception on HPPA, which does
not appear to have consensus, so that's where the breakage comes from.

One can also edit the package.use.mask in the base file, which I have
learned as per the thread [1] below; so it doesn't have to be multitude.

As said before numerous time, the notification was planned; since your
architecture is the only one instructing me to do an exception as per
the comment, it broke.

For the others there is no need for urgency, because of the temporary
mask the Portage tree is not broken for them; it might have caused the
delay, because Nikoli might have not been aware of HPPA breaking,
which might have been an error in communication on our side.

Sorry for that too, I'll prefer to file the bugs myself in the future...

> > [1]
> > http://gentoo.2317880.n4.nabble.com/best-way-to-use-profiles-and-package-use-mask-td16465.html
> 
> Well, you read my response there. Nothing has changed. devmanual
> hasn't changed either. What is your point here?

Consistency. Such that HPPA members do not need to yell "atrocity" at
people; your reply and comment in package.use.mask are red herrings.

Please handle small mistakes like this is a professional way, I'm all
fine with you having a certain vision and using it on your
architecture. But if it is undocumented and/or does not have consensus
then please do not expect people to be able to do the right thing right
away, or to suppose they agree with your vision of dropping a whole
keyword as opposed to dropping a keyword on an USE flag.

Human errors and conflicts happen due to the unawareness of certain
undocumented exceptions that exist; since our efforts are limited, we
can't be expected to know every single undocumented exception out there.

So, I have done exactly what was stated in the comment...

Yes, I've made a small mistake; due to an exception I haven't heard of.

P.S.: It is interesting to see the effects of AutoRepoman beating
people to filing bugs, maybe I should write AutoNotifyman as a response
to not having the chance to file the bug in a reasonable time frame.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Markos Chandras]

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

On 10/19/2013 06:43 PM, Tom Wijsman wrote:
> On Sat, 19 Oct 2013 19:01:44 +0200 Jeroen Roovers <jer@gentoo.org>
> wrote:
>> 
>> As it has been discussed on this mailing list endlessly, there
>> already is a consensus:
>> 
>> 1a) you drop the affected keywords, unless 1b) this causes you to
>> drop (many) more keywords on revdeps, in which case you can
>> package.(use.)mask the relevant bits 2) you inform the affected
>> arch teams
> 
> Please provide a reference to this consensus.

It's probably best to document it somewhere then...

> 
> P.S.: It is interesting to see the effects of AutoRepoman beating 
> people to filing bugs, maybe I should write AutoNotifyman as a
> response to not having the chance to file the bug in a reasonable
> time frame.
> 
The AutoRepoman script is there just for convenience. You shouldn't
take it too seriously and go filing bugs like crazy. The affected
packages can slowly be fixed. It's not like they are totally broken
but it's more like of another way to tell you that a few QA problems
exist and that it would be nice to fix them whenever you find some time.

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

iQJ8BAEBCgBmBQJSY63sXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88Mv0P/31GkGTmWbtJy11g1bA+Xtdp
8g5eRP9S3Xj9kXjkKMczCqP5U2T5lgavMqnIDytLJehK9BxkbyDfUHqWkFmTvLAa
hGrD/ioVG3pw5ugdJmTNkhrj8bBshYIDCZiU6137nRmX7sR6k0KENPpfDndkZ2Wc
Tp8/Kb/M7gPhFy5g4NFKg4ovbYOwwGcFdkt/2VRSQtlycW1gx+U744C+T5CYO/+J
9U91d8mm12TdzOKGbvUllBTuPut8PCSg/Y/3SWCCt9+pTRhDTt7uK+ChuR11Cy6F
TBs5hLT0X1dc5WD6GBXLwRJcK8yEue1uOnZ5NqKwb9G9EH28Ud/uaVe80HKY27+d
/3IjHAUZ128vRXgMW+RlEhf3Jd5XUCy6xTzzgW8dhmttYfmfdPpNe6KP6LyKSi5E
VZiff82haP78vWoYil+4RgTEnqNRTzmcWAMxSZQpsW1FolI5P3s/l3+ltrEpo8iC
Kkn9s3M9Zv085PL0e5aTVn0Bz8PXP3KhxzsoUPwt+yT4mIIF/2QU9n+6ywx9RQoP
ijeKj2rkbsy4XLDIZbFogpU1oRi59dUag38nhuguGQZ2dBR108z/H5+IFHDfDMjt
3kVLfBunRJ4VlYY7s608NVabAQtXrJP4huHz+NvViu0K/nbRE4RgihxC03l/RDcy
UTeRGFTNJ/qXa/I1/753
=0WvP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Patrick Lauer]

On 10/20/2013 06:18 PM, Markos Chandras wrote:
> On 10/19/2013 06:43 PM, Tom Wijsman wrote:

>> P.S.: It is interesting to see the effects of AutoRepoman beating 
>> people to filing bugs, maybe I should write AutoNotifyman as a
>> response to not having the chance to file the bug in a reasonable
>> time frame.
> 
> The AutoRepoman script is there just for convenience. You shouldn't
> take it too seriously and go filing bugs like crazy.

Every dependency-warning it creates is a failure of one or more devs to
check dependencies and reverse-dependencies or the effects of
package.mask'ing or removing ebuilds.

They should not happen, yet I file on average one or two bugs a day
because of this.
(And most affected are the "big minor arches", arm/hppa/ppc, as they
have the largest set of keyworded packages and the least amount of devs
proportionally. It's not nice to keep breaking their stuff ...)

> The affected
> packages can slowly be fixed. It's not like they are totally broken
> but it's more like of another way to tell you that a few QA problems
> exist and that it would be nice to fix them whenever you find some time.

You mean situations where there is user-visible breakage in the
dependency graphs?

If I were a member of the QA team (which for various reasons I've never
been allowed to be, which is quite hilarious) I'd ask you to remember
the "repoman || die" motto we beat into every new recruit and/or ask you
to honourably disable your commit privileges.

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Markos Chandras]

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

On 10/20/2013 11:40 AM, Patrick Lauer wrote:
> 
>> The affected packages can slowly be fixed. It's not like they are
>> totally broken but it's more like of another way to tell you that
>> a few QA problems exist and that it would be nice to fix them
>> whenever you find some time.
> 
> You mean situations where there is user-visible breakage in the 
> dependency graphs?
> 
> If I were a member of the QA team (which for various reasons I've
> never been allowed to be, which is quite hilarious) I'd ask you to
> remember the "repoman || die" motto we beat into every new recruit
> and/or ask you to honourably disable your commit privileges.
> 

No I never meant broken depgraphs. Well for broken deps, repoman does
not let you commit. If you use --force to workaround broken deps,
well, then you get what you deserve.
I was mostly referring to whitespaces, too long descriptions and other
non-fatal warnings that a few devs may ignore.

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

iQJ8BAEBCgBmBQJSY8FOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88fwkP/2fAxRXcL0xnc8mpYJkePdLJ
A9H31frBhC7braP9Vhev+JadoVKYXYqZUGE6V5RTs49gc75iIZscysRYlRWWTzuZ
E7hQmLKuoXUcm8QlpXlK506MvJQ2KbiA7B+z3MYXQfldynFGr4xG1a/y+SyT5+Cg
QfN+m1KInY/+b9TO4G0EG2gxEa4H9L4ZrVGBgBTlnw3w1i62MwSVQVyTaGJZdOi0
fGbnjtw3weUhapxqw8d/yQwwpa5Zcp7zbeCsPR/1TEwBrCBYeT8lebAQ2d7n56Tz
bemTvBegxCfqeg2ODMI/ZdxrZHre7wDL5VL28VOZycDB2ukhsNJ0ZfVa9r61czCY
L0+yXUv1Qcu4nf+NQBgwHnN6FJHrhZD3WamL9sNpJ+io2nDO+hi/BKJAF2UC2Ilq
2XZlQrHAO28NyTTx1hRce+hDqOQeoNjWkkiyvNjzMapcbE1BGebOOY1XQYPKxZwS
VszF4wBsuDS79Ccbw3XZLZMJ/RztTh8dEkCq2Zu5MnhRyKTJy1lKyRD9jVY6gRQB
Q5txomsA/bOnl5WRnyvISoatZmys0oAhz8VxZkjeI1BFPhPAP3/Ptcf60mgnPP9C
LgxgNWmRauiGZPCmRAaoaBhShNdBMPDPL/B8GT6pIuQVR4afWGLyt7kOTEkGGAkq
nTaPUOLkdxYwztioeJq9
=8+LQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Tom Wijsman]

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

On Sun, 20 Oct 2013 11:18:20 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> > P.S.: It is interesting to see the effects of AutoRepoman beating 
> > people to filing bugs, maybe I should write AutoNotifyman as a
> > response to not having the chance to file the bug in a reasonable
> > time frame.
> > 
> The AutoRepoman script is there just for convenience. You shouldn't
> take it too seriously and go filing bugs like crazy. The affected
> packages can slowly be fixed. It's not like they are totally broken
> but it's more like of another way to tell you that a few QA problems
> exist and that it would be nice to fix them whenever you find some
> time.

Sorry, I was trying to refer to automating that I am currently manually
filing a bug when committing, because its contents are usually the same.

When committing a package I could have repoman ask to "File a bug?" and
then it would drop the keywords or package.use.mask them (it kind of
depends on what we decide we consistently want to do) and then make a
KEYWORDREQ bug based on the list of keywords that it warned about.

That way deferring it to other persons or delaying it for later in the
day won't happen as side effects.

These kind of dropped keywords happen frequently with Java packages;
version bumps usually bring in new and/or rare dependencies that are
only keyworded for amd64, whereas the package itself has multiple.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJSY8thAAoJEJWyH81tNOV9PgsH/1MCH0VbDKgkoPhN854plaUZ
/O5uYz6YeodkBo1q+1Ipc0/vz/+V/+sCgrXlthwKOyWwmecBk6TOLngBt4z5zDfs
CnG5tsBUYyoATYbtVopCBkcZDVY9vjSGn5nbZOVHO3MFjIbw/ODe2R2stIZ72ur8
2wZMEUlUDoSVvKF/HWSGHOdHXP0AM647h3bWlHD6MZ13l4nP8P0Mbo1ZXzxJMxZa
9UYoiKQ9tf9hHa05ez6fsBZOZ0z0jMblCjz2B2FzOkJziB5zQAkV2qIu8q4aIZIm
Hx2uaFkABz1Msv7Q/okwT9bMrSqNzbSlQ8OxwAmKHOkErCeNO/Nfw/2i1DRQo7M=
=xVxd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Tom Wijsman]

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

On Sun, 20 Oct 2013 12:41:02 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> No I never meant broken depgraphs. Well for broken deps, repoman does
> not let you commit. If you use --force to workaround broken deps,
> well, then you get what you deserve.

Yes, I am sorry for that; it didn't came to mind to unkeyword HPPA,
because I planned to unkeyword the USE flags instead and have planned
to have a bug filed, I'll pay more attention to not -f again in a hurry.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJSY80AAAoJEJWyH81tNOV9owgH/j46KFLZDCGkzuO8PMqYIGxd
2SCdwdAs7gPofOOKrR9szdK/WVYtI0w00WBcbMeSGUOMjfICJ5EARpE+4gbLLNqs
zqLsXc+gBoYjPvwXqEhlq7S7jCZ9XiEBx3oi0jIp9p+cO54N9FEZ2c03ZtaKqPHF
j8kPfE8mhJEgqN0TmO099aDzK7ARRO+Kpxbc4eCbzlCuzzgudUe7CU6H388DbJ61
CJ8Wknt8me2D3WyvsBm5/WotjiVdqHGDHeLSGzX6LNldHymTKuIWMvgJFnPUVCYU
2Rtp5XgIwwmVHwJmRs4PDB5vlryD/EfZeVIEBcjeZavHTcyOY/6gax/iiJZTRP8=
=1CsE
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Patrick Lauer]

On 10/20/2013 07:41 PM, Markos Chandras wrote:
> On 10/20/2013 11:40 AM, Patrick Lauer wrote:
> 
>>> The affected packages can slowly be fixed. It's not like they are
>>> totally broken but it's more like of another way to tell you that
>>> a few QA problems exist and that it would be nice to fix them
>>> whenever you find some time.
> 
>> You mean situations where there is user-visible breakage in the 
>> dependency graphs?
> 
>> If I were a member of the QA team (which for various reasons I've
>> never been allowed to be, which is quite hilarious) I'd ask you to
>> remember the "repoman || die" motto we beat into every new recruit
>> and/or ask you to honourably disable your commit privileges.
> 
> 
> No I never meant broken depgraphs. Well for broken deps, repoman does
> not let you commit. If you use --force to workaround broken deps,
> well, then you get what you deserve.

Sadly that's not true - for ebuild additions and most keyword changes
repoman works well. But you can make things fail in many creative ways,
like ...

- stale or only partially up-to-date checkout
- package.mask changes
- accidental stable keyword removal
- accidental slot or useflag removal
- failed commits (easy to accidentally overlook)

and so on. Most of that affects reverse dependencies, which are not
checked by default - a good part of the depgraph breakage could be
avoided if everyone ran full-tree scans, but that's extremely
time-consuming (I'm burning 120 CPU-minutes @ 3.4Ghz amd64 for a full
tree scan) and inconvenient.

So for now I just hope that my constant bug-nagging motivates people to
be a bit more careful :)

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Jeroen Roovers]

On Sun, 20 Oct 2013 12:41:02 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> No I never meant broken depgraphs. Well for broken deps, repoman does
> not let you commit. If you use --force to workaround broken deps,
> well, then you get what you deserve.

No, apparently tomwij can get not only away with this (and apparently
others as well on a regular basis). Not just that: he gets to write a
lengthy "apology" that merely blames others / documentation / common
sense, and then proceeds to call me "unprofessional" for pointing out
in public the several mistakes he made. I feel very much that he's not
getting it (what he deserves).


     jer

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Jeroen Roovers]

On Sun, 20 Oct 2013 14:30:56 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> Yes, I am sorry for that; it didn't came to mind to unkeyword HPPA,
> because I planned to unkeyword the USE flags instead and have planned
> to have a bug filed, I'll pay more attention to not -f again in a
> hurry.

There is no "instead". The default policy (did you read the devmanual
yet?) is to DROP KEYWORDS (and let arch teams re-add them) -unless- that
is really cumbersome (when you need to drop more and more keywords as
a result).

Since you don't seem to get why this is. Let me give you an example.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Minor Arch User: I want cat-more/pkg with USE=foo but I can't enable it.
Why is USE=interesting masked?
Minor Arch Dev: I don't know. Let me look it up.
Minor Arch Dev: Ah, it's in
profiles/default/linux/somearch/package.use.mask:
# Some Package Maintainer <some@package.maintainer> (1 Jan 1970)
# dev-libs/interesting not keyworded so disabling, kthxbye
cat-more/pkg interesting
Minor Arch Dev: Apparently it was put there a long time ago. It has no
bug reference and I can't find a ChangeLog entry. Oh wait, it's
mentioned in profiles/ChangeLog-1971 but with the same uninformative
text.
Minor Arch User: So what do I need to do?
Minor Arch Dev: Er, you write an entry
in /etc/portage/profile/package.keywords for the dev-libs/interesting
package (make sure to put the ~arch or '**', yeah?), and another entry
in /etc/portage/profile/package.use.mask with the same entry as
package.use.mask (but with the sign of the USE flag inverted, right?).
Then when you have successfully re-emerged cat-more/pkg with
USE=interesting, send me a new bug report so we can start removing the
bitrot from the arch profile and keywording stuff properly.

(Several portage configuration explanations and bug hunts later.)

(Minor Arch User exits stage left having gained happy happy support for
"interesting" in his pkg.)
Minor Arch Dev: O, if only the keyword had been dropped at the time,
and two more keywords had been re-added to cat-more/pkg and
dev-libs/interesting at the time, none of this would have been needed.
Mercy!
(Minor Arch Dev drinks the poison and drops to the floor)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


     jer

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Tom Wijsman]

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

On Mon, 21 Oct 2013 15:50:34 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sun, 20 Oct 2013 14:30:56 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> There is no "instead".

Why is there no "instead"?

> The default policy (did you read the devmanual yet?)

Which policy are you referring to? (Did you refer me to anything?)

> is to DROP KEYWORDS (and let arch teams re-add them)

Which is what I exactly did for the USE flags on most of the arches;
and a bug was planned to be filed, such that they can decide on it.

> -unless- that is really cumbersome (when you need to drop more and
> more keywords as a result).

Please do not make additional exceptions, we have enough of them.

> Since you don't seem to get why this is. Let me give you an example.
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Minor Arch User: I want cat-more/pkg with USE=foo but I can't enable
> it. Why is USE=interesting masked?
> Minor Arch Dev: I don't know. Let me look it up.
> Minor Arch Dev: Ah, it's in
> profiles/default/linux/somearch/package.use.mask:
> # Some Package Maintainer <some@package.maintainer> (1 Jan 1970)
> # dev-libs/interesting not keyworded so disabling, kthxbye
> cat-more/pkg interesting
> Minor Arch Dev: Apparently it was put there a long time ago. It has no
> bug reference and I can't find a ChangeLog entry. Oh wait, it's
> mentioned in profiles/ChangeLog-1971 but with the same uninformative
> text.

Right; bug reference added, I see no other problem here.

> Minor Arch User: So what do I need to do?
> Minor Arch Dev: Er, you write an entry
> in /etc/portage/profile/package.keywords for the dev-libs/interesting
> package (make sure to put the ~arch or '**', yeah?), and another entry
> in /etc/portage/profile/package.use.mask with the same entry as
> package.use.mask (but with the sign of the USE flag inverted, right?).

Whether you change package.keywords twice or change both once; it
doesn't result in a difference in effort, I do not see your point here.

> Then when you have successfully re-emerged cat-more/pkg with
> USE=interesting, send me a new bug report so we can start removing the
> bitrot from the arch profile and keywording stuff properly.

Why file a duplicate bug?

> (Several portage configuration explanations and bug hunts later.)

For what?

> (Minor Arch User exits stage left having gained happy happy support
> for "interesting" in his pkg.)
> Minor Arch Dev: O, if only the keyword had been dropped at the time,
> and two more keywords had been re-added to cat-more/pkg and
> dev-libs/interesting at the time, none of this would have been needed.
> Mercy!
> (Minor Arch Dev drinks the poison and drops to the floor)

Two entries will continue to be two entries; so, I do not see where the
difference in work comes from. Can you now please explain the exception?

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> 
>      jer
> 

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Tom Wijsman]

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

On Mon, 21 Oct 2013 15:32:10 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sun, 20 Oct 2013 12:41:02 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
> 
> > No I never meant broken depgraphs. Well for broken deps, repoman
> > does not let you commit. If you use --force to workaround broken
> > deps, well, then you get what you deserve.
> 
> No, apparently tomwij can get not only away with this (and apparently
> others as well on a regular basis). Not just that: he gets to write a
> lengthy "apology" that merely blames others / documentation / common
> sense, and then proceeds to call me "unprofessional" for pointing out
> in public the several mistakes he made. I feel very much that he's not
> getting it (what he deserves).

This is a first time I mask an USE flag on a package for a very small
single issue, please do not get upset over it. If I do it perfectly on
other achitectures which do not point anything out about it; then there
must be a reason as to why this happened *, please assume good faith
and do not see my explanation as a way to blame people or words. You or
your comment is not the reason to it, rather my misinterpretation of it.

My replies are rather intended to make sure "apparently others" do not
experience this again in the future; by introducing consistency,
deciding on policy, clarifying documentation and so on...

It simply does not work to say to me that "you're supposed to" when
that doesn't reflect what other arches do as well as the docs; I have
learned early on to not be convinced by inviduals, but rather to base
myself on consensus as to avoid people telling me conflicted matters.

To some extent I might be trying to be too professional; but, I'm
rather scared of not being professional enough, so I try not to be
careless when checking whether there is a consensus on matters.

You very well know that this is not intended, that I apologize and that
I will not let it happen again; so, the only thing left I ask from
Gentoo and you is to bring more consistency in this matter so all of us
do not have to go through this again.

If there's no consistency, no policy for the HPPA exception and missing
documentation; then ask yourself, what alerts and/or prevents the next
new developer from making this mistake again once he gets to USE flag
dependencies that need to be masked?

Nothing, and that concerns me.

As for blaming you; it is quite the opposite, I have actually been
trying to become friends with you because we share some common concerns
(bug wrangling, keeping #gentoo clean, ...) but I find it much harder
to do that these days running into these roadblocks ("atrocity" when
making a mistake because of an unexpected comment, changing the patch
name in tinyproxy, getting away and getting what I deserve, ...) that
are the result of us not communicating in a professional way.

I very well respect your position as an arch member, your concerns to
keep maintaining the arch easy and more; I'm not bothered by you, even
rather admire some of the work you do.

I do speak up to improve our maintenance to be more efficient, to
improve Gentoo and to increase the general user experience; then if
problems or complexity sits in the way of that, I want to
explain, discuss and improve it. When that is reasonably possible.

Please note that I however do not insist on it; if nobody's interested,
then I am okay with that. What I didn't get here is why that comment is
in place in the HPPA package.use.mask; my confusion on this should be
clear from the other reply I gave on your example.

I'm not at all here to convince you; rather, I'm here to try to
understand its meaning. If you do not want to clarify that or provide
facts or references; then I agree to disagree with your opinion for
adding that comment. Regardless of that, the mistake won't happen again.

Thank you for the great work, your understanding and have a nice day.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Jeroen Roovers]

On Mon, 21 Oct 2013 17:32:03 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Mon, 21 Oct 2013 15:50:34 +0200
> Jeroen Roovers <jer@gentoo.org> wrote:
> 
> > On Sun, 20 Oct 2013 14:30:56 +0200
> > Tom Wijsman <TomWij@gentoo.org> wrote:
> > 
> > There is no "instead".
> 
> Why is there no "instead"?

"I planned to unkeyword the USE flags instead" - this is wrong. The
policy (see below for the link - you seem to have trouble finding it
every time I point it out) is to drop keywords (that is entries in the
KEYWORDS variable, see below for an extra explanation since you seem to
be confused as to what it means).

> > The default policy (did you read the devmanual yet?)
> 
> Which policy are you referring to? (Did you refer me to anything?)

http://devmanual.gentoo.org/keywording/index.html

   "Sometimes you may need to remove a keyword because of new unresolved
    dependencies. If you do this, you *must* file a bug notifying the
    relevant arch teams."

> > is to DROP KEYWORDS (and let arch teams re-add them)
> 
> Which is what I exactly did for the USE flags on most of the arches;
> and a bug was planned to be filed, such that they can decide on it.

You are apparently confusing "dropping keywords" (entries in the
KEYWORDS variable in an ebuild) with "masking USE flags". Why would you
do that? I know you are smarter than this.

> > -unless- that is really cumbersome (when you need to drop more and
> > more keywords as a result).
> 
> Please do not make additional exceptions, we have enough of them.

What do you mean? This common sense policy has been in place for years.
If dropping one keyword breaks many (rev-)deps and is therefore not an
option, it's quite the norm to either file a keyword request bug well in
advance of anything in the tree breaking, or temporarily mask either
ebuilds or USE flags, generally or specifically for an arch profile,
and inform the arch teams.

> Right; bug reference added, I see no other problem here.

That should also tell you that it helps to inform arch teams by
filing a bug report -before- you drop keywords or mess up the profiles.

> Two entries will continue to be two entries; so, I do not see where
> the difference in work comes from. Can you now please explain the
> exception?

There is no exception. You've made that bit up.

The proper procedure is to ask arch teams to re-keyword the ebuild you
had to drop their keyword for. If that is impossible, several other
scenarios can be played out, such as use.masking to cover up a
deficiency in porting to said arch, dropping keywords for that arch
altogether, or whatever might work. The point is that you shouldn't be
making that decision - you just maintain the package, not the arch
profile, and you ran into a problem which you didn't propose they fix
- you just covered it all up.

The difference in work would amount to editing two files in the
profiles/ subdir per architecture you want to abuse profiles/ for
instead of asking their actual opinion, then later both undoing all
that work and simply changing the files that matter, the ebuilds and
auxiliary files (some 6 files in the example).

For an arch developer wanting to test if the new dep should really be
masked, or actually works just fine on his arch and should have been
keyworded long ago, the improper procedure involves both unmasking the
new dep in package.keywords as well as unmasking the USE flag on the
test system, and then reversing the profile change and adding the
keyword to the new dep.

With just the dropped keyword, everything is normally much simpler. I
don't see how you count up "entries" here - from experience re-adding
keywords is a lot easier than removing profile masks.


     jer

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Tom Wijsman]

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

On Mon, 21 Oct 2013 18:31:43 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> "I planned to unkeyword the USE flags instead" - this is wrong. The
> policy (see below for the link - you seem to have trouble finding it
> every time I point it out) is to drop keywords (that is entries in the
> KEYWORDS variable, see below for an extra explanation since you seem
> to be confused as to what it means).
> 
> > > The default policy (did you read the devmanual yet?)
> > 
> > Which policy are you referring to? (Did you refer me to anything?)
> 
> http://devmanual.gentoo.org/keywording/index.html
> 
>    "Sometimes you may need to remove a keyword because of new
> unresolved dependencies. If you do this, you *must* file a bug
> notifying the relevant arch teams."
> 
> > > is to DROP KEYWORDS (and let arch teams re-add them)
> > 
> > Which is what I exactly did for the USE flags on most of the arches;
> > and a bug was planned to be filed, such that they can decide on it.
> 
> You are apparently confusing "dropping keywords" (entries in the
> KEYWORDS variable in an ebuild) with "masking USE flags". Why would
> you do that? I know you are smarter than this.

TL;DR: Clarified my misunderstanding, I agree now that I understand.

Because the end result (a change in visibility) is mostly the same.

I agree that "keywording" and "masking" are not the same; I however
have considered that "masking is the scope of an arch" equals to
"unkeywording" for that particular architecture. The difference in what
happens towards the end result here is thus quite small; but now that
you point it out, I do now understand that the words can carry quite a
different meaning. A meaning that depends on how they are understood.

Thanks you for highlighting that.

> > > -unless- that is really cumbersome (when you need to drop more and
> > > more keywords as a result).
> > 
> > Please do not make additional exceptions, we have enough of them.
> 
> What do you mean? This common sense policy has been in place for
> years. If dropping one keyword breaks many (rev-)deps and is
> therefore not an option, it's quite the norm to either file a keyword
> request bug well in advance of anything in the tree breaking, or
> temporarily mask either ebuilds or USE flags, generally or
> specifically for an arch profile, and inform the arch teams.

+1 Sorry, I was thinking about an end package as opposed to a library.

> > Right; bug reference added, I see no other problem here.
> 
> That should also tell you that it helps to inform arch teams by
> filing a bug report -before- you drop keywords or mess up the
> profiles.

This is what I've almost always have done; but I went wrong here by off
sourcing it this time to the proxy maintainer, will not do that again.

> > Two entries will continue to be two entries; so, I do not see where
> > the difference in work comes from. Can you now please explain the
> > exception?
> 
> There is no exception. You've made that bit up.

http://gentoo.2317880.n4.nabble.com/best-way-to-use-profiles-and-package-use-mask-td16465.html

From that thread I get that half of the people agree and that half of
the people don't; looking at the package.use.mask I have seen non-arch
members touch them from time to time, so while it might not
necessarily be the exception I'm not so sure if it is the rule.

Regardless of that view on it, I find your argument that you give
below about the amount of files changed (adding + removing) and the
difference between keywording and masking both requiring more work
quite convincing; so I totally agree with you on that.

> The proper procedure is to ask arch teams to re-keyword the ebuild you
> had to drop their keyword for. If that is impossible, several other
> scenarios can be played out, such as use.masking to cover up a
> deficiency in porting to said arch, dropping keywords for that arch
> altogether, or whatever might work. The point is that you shouldn't be
> making that decision - you just maintain the package, not the arch
> profile, and you ran into a problem which you didn't propose they fix
> - you just covered it all up.
> 
> The difference in work would amount to editing two files in the
> profiles/ subdir per architecture you want to abuse profiles/ for
> instead of asking their actual opinion, then later both undoing all
> that work and simply changing the files that matter, the ebuilds and
> auxiliary files (some 6 files in the example).
> 
> For an arch developer wanting to test if the new dep should really be
> masked, or actually works just fine on his arch and should have been
> keyworded long ago, the improper procedure involves both unmasking the
> new dep in package.keywords as well as unmasking the USE flag on the
> test system, and then reversing the profile change and adding the
> keyword to the new dep.
>
> With just the dropped keyword, everything is normally much simpler. I
> don't see how you count up "entries" here - from experience re-adding
> keywords is a lot easier than removing profile masks.

I was reading your example from an user perspective the first time; in
that perspective the user's work stays the same, I've mislead myself. :(

Thank you very much for elaborating.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Markos Chandras]

On 10/21/2013 02:32 PM, Jeroen Roovers wrote:
> On Sun, 20 Oct 2013 12:41:02 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
> 
>> No I never meant broken depgraphs. Well for broken deps, repoman does
>> not let you commit. If you use --force to workaround broken deps,
>> well, then you get what you deserve.
> 
> No, apparently tomwij can get not only away with this (and apparently
> others as well on a regular basis). Not just that: he gets to write a
> lengthy "apology" that merely blames others / documentation / common
> sense, and then proceeds to call me "unprofessional" for pointing out
> in public the several mistakes he made. I feel very much that he's not
> getting it (what he deserves).
> 
> 
>      jer
> 

Lets calm down a little bit. Our documentation is nowhere near perfect
and common sense is not always obvious (we have hundreds of people
claiming that the opposite). Instead of arguing in public how about we
contribute some patches in devmanual to avoid similar problems in the
future?

-- 
Regards,
Markos Chandras

[Bug 304435] Developer Handbook should document how/when to touch arch profiles' files (was: Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc)

[Tom Wijsman]

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

On Mon, 21 Oct 2013 20:16:01 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> Lets calm down a little bit. Our documentation is nowhere near perfect
> and common sense is not always obvious (we have hundreds of people
> claiming that the opposite). Instead of arguing in public how about we
> contribute some patches in devmanual to avoid similar problems in the
> future?

Hello, that indeed should be the way to go; but I came across something
relevant to this, as I was searching for an unrelated devmanual bug.

It seems like we do should discuss this in public:

    https://bugs.gentoo.org/show_bug.cgi?id=304435#c33 (Comment 33)

Looking a bit back up, it seems I've got a blanket to touch them:

    https://bugs.gentoo.org/show_bug.cgi?id=304435#c23 (Comment 23)

And that's also probably why a lot of other people have done so.

Though I agree with Jeroen Roovers as to why not to, because it results
in more work (as more files are touched) and there are some arches that
simply don't want it. So, I think we should proceed with discussing
this amongst the architectures and perhaps council and then proceed on
getting it into the devmanual so that we can act consistently.

Therefore I suggest that the arch teams and/or the council clarify when
developers can touch which files in the architecture sub directories of
profiles/.

I do want to help by writing up a patch, but I'd like to see consensus
first to avoid documenting something that not every arch team follows.

I'd suggest we discuss and/or vote on Jeroen Roovers' opinion:

    http://article.gmane.org/gmane.linux.gentoo.devel/88609

Prior discussion that lead to this:

    http://thread.gmane.org/gmane.linux.gentoo.devel/88562 (frames)
    http://www.gossamer-threads.com/lists/gentoo/dev/279926 (plain)

The bug that has lead to the prior discussion:

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

Prior discussion with Jeroen Roovers' opinion that was not answered to:

    http://gentoo.2317880.n4.nabble.com/best-way-to-use-profiles-and-package-use-mask-td16465.html

Please note that I do not intend a negative connotation with the word;
I agree with it, as it seems like common sense to me. But I just label
it opinion because I am unsure if this is collaborative knowledge [or
common sense] among archictecture teams; in any case, for outstanders
this is undocumented which can lead to moments of misunderstanding.

Thank you very much in advance.

CC-ed: Arch leads, frequent arch member, related persons, council.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]