[gentoo-dev] Unmasking modular X

[gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Here's my proposal for dealing with modular X entering ~arch.

Yes, some packages are going to break. But I intend to keep this to a
minimum on packages people care about, as measured by the existence of
an open porting bug.

So here's my plan: Before modular X enters ~arch, I will ensure that all
porting bugs blocking #112675 are closed. As new bugs are filed, I will
ensure that they are closed within 2 days, giving their maintainers that
long to respond and close it themselves. After 2 days, I, or other
members of the x11 team and any volunteers, will jump in and fix it
ourselves.

Earlier tonight, I discussed with halcy0n our differing opinions of the
need for modular X to enter ~arch and break trees for some ~arch users.
In my opinion, this is acceptable and beneficial, as ~arch users should
already be those willing to help out. It will assist in learning which
of the still-unported apps are actually in use and help compile a
possible list of tree removal candidates. halcy0n, on the other hand,
feels that any breakage of the ~arch tree is anathema.

Please contact me if you'd like to be one of these volunteers. Requirements:

A) You have commit access to gentoo-x86, AND
B) you're comfortable with the porting process OR are adept with ebuilds
and would like to help

It's my earnest hope that this proposal makes everyone happy, because I
refuse to let modular X get old and rusty in package.mask while hundreds
of unmaintained (or undermaintained, for whatever reason) applications
hold it back.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Ciaran McCreesh]

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

On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Here's my proposal for dealing with modular X entering ~arch.

What's wrong with the original idea of just making any unported ebuild
pull in all of modular X (minus drivers)? Yes, it means that some
people will pick up unnecessary deps until all packages are ported, but
it avoids anyone having to see flashy red errors.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
> <spyderous@gentoo.org> wrote:
> | Here's my proposal for dealing with modular X entering ~arch.
> 
> What's wrong with the original idea of just making any unported ebuild
> pull in all of modular X (minus drivers)? Yes, it means that some
> people will pick up unnecessary deps until all packages are ported, but
> it avoids anyone having to see flashy red errors.

The problem with that is that it removes all motivation to ever port the
packages. They'll just stay that way forever, where forever means "until
I threaten to remove that from the virtual," in which case we'll be in
the same scenario we are now. Why? Because people have better things to
do than fix stuff that isn't broken.

Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Robin H. Johnson]

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

On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote:
> A) You have commit access to gentoo-x86, AND
> B) you're comfortable with the porting process OR are adept with ebuilds
> and would like to help
I'm up for being a volunteer here.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Unmasking modular X

[Christian Heim]

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

On Tuesday 24 January 2006 09:34, RH wrote:
> On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote:
> > A) You have commit access to gentoo-x86, AND
> > B) you're comfortable with the porting process OR are adept with ebuilds
> > and would like to help
>
> I'm up for being a volunteer here.

Same for me.

-- 
Christian Heim <phreak@gentoo.org>
Gentoo Linux Developer - vserver

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

Re: [gentoo-dev] Unmasking modular X

[Carlos Silva]

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

On Tue, 2006-01-24 at 13:38 +0100, Christian Heim wrote:
> On Tuesday 24 January 2006 09:34, RH wrote:
> > On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote:
> > > A) You have commit access to gentoo-x86, AND
> > > B) you're comfortable with the porting process OR are adept with ebuilds
> > > and would like to help
> >
> > I'm up for being a volunteer here.
> 
> Same for me.
> 

Add me there
-- 
Carlos "r3pek" Silva
Gentoo Developer (kernel/amd64/mobile-phone)

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

Re: [gentoo-dev] Unmasking modular X

[Marcelo Góes]

On 1/24/06, Carlos Silva <r3pek@gentoo.org> wrote:
> On Tue, 2006-01-24 at 13:38 +0100, Christian Heim wrote:
> > On Tuesday 24 January 2006 09:34, RH wrote:
> > > On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote:
> > > > A) You have commit access to gentoo-x86, AND
> > > > B) you're comfortable with the porting process OR are adept with ebuilds
> > > > and would like to help
> > >
> > > I'm up for being a volunteer here.
> >
> > Same for me.
> >
>
> Add me there

volunteer++;

> --
> Carlos "r3pek" Silva
> Gentoo Developer (kernel/amd64/mobile-phone)
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux)
>
> iD8DBQBD1iMmttk+BQds59QRAvnVAKCH/SahwwKfVxeTU95fULRg8SFm1wCfTlq3
> 0Q/HwMiAQdF2DaCe/X8HnR4=
> =SXF6
> -----END PGP SIGNATURE-----
>
>
>


--
Marcelo Góes
marcelogoes@gmail.com
vanquirius@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Chris Gianelloni]

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

On Mon, 2006-01-23 at 23:06 -0800, Donnie Berkholz wrote:
> Earlier tonight, I discussed with halcy0n our differing opinions of the
> need for modular X to enter ~arch and break trees for some ~arch users.
> In my opinion, this is acceptable and beneficial, as ~arch users should
> already be those willing to help out. It will assist in learning which
> of the still-unported apps are actually in use and help compile a
> possible list of tree removal candidates. halcy0n, on the other hand,
> feels that any breakage of the ~arch tree is anathema.

Funny enough, I kinda agree with both of you.  I am currently working
through the *enormous* number of packages in games-* but with the
release forthcoming and also very busy.  Any help here would be
appreciated.  I would hope to get as much of this done as possible
*before* the packages go into ~arch, rather than after.

> It's my earnest hope that this proposal makes everyone happy, because I
> refuse to let modular X get old and rusty in package.mask while hundreds
> of unmaintained (or undermaintained, for whatever reason) applications
> hold it back.

In our case, it is simply sheer numbers.  We have a small group
responsible for a large number of packages.  We are definitely agreeable
to getting some help with this, as we don't want to be the cause of
holding back modular X in any way.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Unmasking modular X

[Mark Loeser]

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

Donnie Berkholz <spyderous@gentoo.org> said:
> Ciaran McCreesh wrote:
> > On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
> > <spyderous@gentoo.org> wrote:
> > | Here's my proposal for dealing with modular X entering ~arch.
> > 
> > What's wrong with the original idea of just making any unported ebuild
> > pull in all of modular X (minus drivers)? Yes, it means that some
> > people will pick up unnecessary deps until all packages are ported, but
> > it avoids anyone having to see flashy red errors.
> 
> The problem with that is that it removes all motivation to ever port the
> packages. They'll just stay that way forever, where forever means "until
> I threaten to remove that from the virtual," in which case we'll be in
> the same scenario we are now. Why? Because people have better things to
> do than fix stuff that isn't broken.

It'd be nice if you reconsidered this as it will minimize any breakage that
may occur.  Knowing that >800 packages are broken, and going to unmask it
knowing that just doesn't seem acceptable in my eyes.  ~arch isn't meant to
be "things are known to be broken."  It's meant to mean, we think all of this
is ready to be stable, which it certainly won't be in this case.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Unmasking modular X

[Lares Moreau]

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

On Tue, 2006-01-24 at 12:25 -0500, Mark Loeser wrote:
> > The problem with that is that it removes all motivation to ever port the
> > packages. They'll just stay that way forever, where forever means "until
> > I threaten to remove that from the virtual," in which case we'll be in
> > the same scenario we are now. Why? Because people have better things to
> > do than fix stuff that isn't broken.
> 
> It'd be nice if you reconsidered this as it will minimize any breakage that
> may occur.  Knowing that >800 packages are broken, and going to unmask it
> knowing that just doesn't seem acceptable in my eyes.  ~arch isn't meant to
> be "things are known to be broken."  It's meant to mean, we think all of this
> is ready to be stable, which it certainly won't be in this case.

I did some rough calculations and we are porting about 29 pkgs/day.
At this rate it will take roughly 30 days to have all packages ported to
ModX.

spyderous wants it tomorrow,
HalycOn wants it when all is ported.

A (perhaps overly) simple solution is to split the difference.

In 15 days ModX goes ~arch. 8 February

-Lares
-- 
Lares Moreau <lares.moreau@gmail.com>  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net                 |
Gentoo x86 Arch Tester                 |               ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |          Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E

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

Re: [gentoo-dev] Unmasking modular X

[Mark Loeser]

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

Lares Moreau <lares.moreau@gmail.com> said:
> I did some rough calculations and we are porting about 29 pkgs/day.
> At this rate it will take roughly 30 days to have all packages ported to
> ModX.
> 
> spyderous wants it tomorrow,
> HalycOn wants it when all is ported.

I didn't say all of it ported.  It seems unreasonable to move it when we have
atleast 800 packages that are not working though.

I don't care the exact date that it happens, nor do I think we should aim for
one.  We should aim for when it will be done in a way that minimizes the
breakage for all of our users.  Yes, breakage will happen, but we can wait
until its down to a more reasonable value.  This huge push to get everything
ported over only started recently, and I think we need more time.


-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Unmasking modular X

[Wernfried Haas]

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

On Tue, Jan 24, 2006 at 01:44:28PM -0500, Mark Loeser wrote:
> We should aim for when it will be done in a way that minimizes the
> breakage for all of our users.  Yes, breakage will happen, but we can wait
> until its down to a more reasonable value.

And we probably should announce somewhere that this is going to happen
(if not done already, haven't been following the modular X thing too
closely). 

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

Re: [gentoo-dev] Unmasking modular X

[Mike Doty]

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

Donnie Berkholz wrote:
> Here's my proposal for dealing with modular X entering ~arch.
> 
> Yes, some packages are going to break. But I intend to keep this to a
> minimum on packages people care about, as measured by the existence of
> an open porting bug.
> 
> So here's my plan: Before modular X enters ~arch, I will ensure that all
> porting bugs blocking #112675 are closed. As new bugs are filed, I will
> ensure that they are closed within 2 days, giving their maintainers that
> long to respond and close it themselves. After 2 days, I, or other
> members of the x11 team and any volunteers, will jump in and fix it
> ourselves.
> 
> Earlier tonight, I discussed with halcy0n our differing opinions of the
> need for modular X to enter ~arch and break trees for some ~arch users.
> In my opinion, this is acceptable and beneficial, as ~arch users should
> already be those willing to help out. It will assist in learning which
> of the still-unported apps are actually in use and help compile a
> possible list of tree removal candidates. halcy0n, on the other hand,
> feels that any breakage of the ~arch tree is anathema.
> 
> Please contact me if you'd like to be one of these volunteers. Requirements:
> 
> A) You have commit access to gentoo-x86, AND
> B) you're comfortable with the porting process OR are adept with ebuilds
> and would like to help
> 
> It's my earnest hope that this proposal makes everyone happy, because I
> refuse to let modular X get old and rusty in package.mask while hundreds
> of unmaintained (or undermaintained, for whatever reason) applications
> hold it back.
> 
> Thanks,
> Donnie
> 

I think before you go forward with something like this you should give a
suitable period of warning, it's going to create a lot of bug work for
all of us.

- --
=======================================================
Mike Doty                           kingtaco@gentoo.org
Gentoo/AMD64 Strategic Lead         PGP Key: 0xA797C7A7
Gentoo Developer Relations
                 ===GPG Fingerprint===
   0094 7F06 913E 78D6 F1BB  06BA D0AD D125 A797 C7A7
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD1oUV0K3RJaeXx6cRAg/2AKC3yopH5VUPjw+2BAPnD29Ippqw2gCfXRgu
cL+GSnyiLPWxwOuwZIVpczw=
=ze8X
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Mike Doty wrote:
> I think before you go forward with something like this you should give a
> suitable period of warning, it's going to create a lot of bug work for
> all of us.

Have you seen my daily emails for the past week and a half? =)

I have the feeling that it will create the most work for Jakub and
whoever besides myself volunteers to help out with the porting. Most
other groups, besides games, have very few packages, and if they're
feeling lazy, they can just wait a day and get them fixed by us.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Mark Loeser wrote:
>>> On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
>>> <spyderous@gentoo.org> wrote:
>>> What's wrong with the original idea of just making any unported ebuild
>>> pull in all of modular X (minus drivers)? Yes, it means that some
>>> people will pick up unnecessary deps until all packages are ported, but
>>> it avoids anyone having to see flashy red errors.
>> The problem with that is that it removes all motivation to ever port the
>> packages. They'll just stay that way forever, where forever means "until
>> I threaten to remove that from the virtual," in which case we'll be in
>> the same scenario we are now. Why? Because people have better things to
>> do than fix stuff that isn't broken.
> 
> It'd be nice if you reconsidered this as it will minimize any breakage that
> may occur.  Knowing that >800 packages are broken, and going to unmask it
> knowing that just doesn't seem acceptable in my eyes.  ~arch isn't meant to
> be "things are known to be broken."  It's meant to mean, we think all of this
> is ready to be stable, which it certainly won't be in this case.

No, it won't. It will just postpone the same breakage, as I said above.
You haven't provided any logic or backup to your contrary statement,
just said that somehow a large portion of the other 800 will magically
get ported.

Let me break this down again: of that 800, about 250 are unmaintained
packages according to metadata.xml or lack thereof. About 200 are games.
About 150 more belong to largely inactive herds. That's roughly 600 that
we already know will not get ported in a timely fashion, if left to
their maintainers, all because of lack of manpower. What do you propose
to deal with them? All I've heard besides mine is proposals that delay
the same breakage, not actually get anything fixed.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Olivier Crete]

On Tue, 2006-24-01 at 13:32 -0800, Donnie Berkholz wrote:
> Mark Loeser wrote:
> >>> On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
> >>> <spyderous@gentoo.org> wrote:
> >>> What's wrong with the original idea of just making any unported ebuild
> >>> pull in all of modular X (minus drivers)? Yes, it means that some
> >>> people will pick up unnecessary deps until all packages are ported, but
> >>> it avoids anyone having to see flashy red errors.
> >> The problem with that is that it removes all motivation to ever port the
> >> packages. They'll just stay that way forever, where forever means "until
> >> I threaten to remove that from the virtual," in which case we'll be in
> >> the same scenario we are now. Why? Because people have better things to
> >> do than fix stuff that isn't broken.
> > 
> > It'd be nice if you reconsidered this as it will minimize any breakage that
> > may occur.  Knowing that >800 packages are broken, and going to unmask it
> > knowing that just doesn't seem acceptable in my eyes.  ~arch isn't meant to
> > be "things are known to be broken."  It's meant to mean, we think all of this
> > is ready to be stable, which it certainly won't be in this case.
> 
> No, it won't. It will just postpone the same breakage, as I said above.
> You haven't provided any logic or backup to your contrary statement,
> just said that somehow a large portion of the other 800 will magically
> get ported.

Why not just postpone the unmasking by a few days... and lets say give
48h from now for all devs to fix their apps and have the volunteers
finish off the rest. Btw, I'll volunteer to help if I have any free time
this week. And then the unmasking can be much less painful. 

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Alfredo Perez]

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

You can count me too :)
   
  Alfredo

Christian Heim <phreak@gentoo.org> wrote:
  On Tuesday 24 January 2006 09:34, RH wrote:
> On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote:
> > A) You have commit access to gentoo-x86, AND
> > B) you're comfortable with the porting process OR are adept with ebuilds
> > and would like to help
>
> I'm up for being a volunteer here.

Same for me.

-- 
Christian Heim 

Gentoo Linux Developer - vserver
  


[-- Attachment #2: Type: text/html, Size: 731 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Marius Mauch]

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

On Tue, 24 Jan 2006 13:32:00 -0800
Donnie Berkholz <spyderous@gentoo.org> wrote:

> Mark Loeser wrote:
> >>> On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
> >>> <spyderous@gentoo.org> wrote:
> >>> What's wrong with the original idea of just making any unported
> >>> ebuild pull in all of modular X (minus drivers)? Yes, it means
> >>> that some people will pick up unnecessary deps until all packages
> >>> are ported, but it avoids anyone having to see flashy red errors.
> >> The problem with that is that it removes all motivation to ever
> >> port the packages. They'll just stay that way forever, where
> >> forever means "until I threaten to remove that from the virtual,"
> >> in which case we'll be in the same scenario we are now. Why?
> >> Because people have better things to do than fix stuff that isn't
> >> broken.
> > 
> > It'd be nice if you reconsidered this as it will minimize any
> > breakage that may occur.  Knowing that >800 packages are broken,
> > and going to unmask it knowing that just doesn't seem acceptable in
> > my eyes.  ~arch isn't meant to be "things are known to be broken."
> > It's meant to mean, we think all of this is ready to be stable,
> > which it certainly won't be in this case.
> 
> No, it won't. It will just postpone the same breakage, as I said
> above. You haven't provided any logic or backup to your contrary
> statement, just said that somehow a large portion of the other 800
> will magically get ported.
> 
> Let me break this down again: of that 800, about 250 are unmaintained
> packages according to metadata.xml or lack thereof. About 200 are
> games. About 150 more belong to largely inactive herds. That's
> roughly 600 that we already know will not get ported in a timely
> fashion, if left to their maintainers, all because of lack of
> manpower. What do you propose to deal with them? All I've heard
> besides mine is proposals that delay the same breakage, not actually
> get anything fixed.

How about delaying it as long as n packages are ported per day? Kinda
stupid idea, but it ensures that things won't get hold up due to
unmaintained packages/inactive devs and might even speed the process up
(that's an illusion probably).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Marius Mauch wrote:
> How about delaying it as long as n packages are ported per day? Kinda
> stupid idea, but it ensures that things won't get hold up due to
> unmaintained packages/inactive devs and might even speed the process up
> (that's an illusion probably).


if n>4, that was yesterday.

Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Donnie Berkholz wrote:
> So here's my plan: Before modular X enters ~arch, I will ensure that all
> porting bugs blocking #112675 are closed. As new bugs are filed, I will
> ensure that they are closed within 2 days, giving their maintainers that
> long to respond and close it themselves. After 2 days, I, or other
> members of the x11 team and any volunteers, will jump in and fix it
> ourselves.

I've thought a bit about this, and it just doesn't make sense to wait
two days. There's no real good reasons why we shouldn't just fix things
right away, and it'll probably make a lot of people concerned about
ongoing tree breakage happier.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Alec Warner]

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

Donnie Berkholz wrote:
> Donnie Berkholz wrote:
> 
>>So here's my plan: Before modular X enters ~arch, I will ensure that all
>>porting bugs blocking #112675 are closed. As new bugs are filed, I will
>>ensure that they are closed within 2 days, giving their maintainers that
>>long to respond and close it themselves. After 2 days, I, or other
>>members of the x11 team and any volunteers, will jump in and fix it
>>ourselves.
> 
> 
> I've thought a bit about this, and it just doesn't make sense to wait
> two days. There's no real good reasons why we shouldn't just fix things
> right away, and it'll probably make a lot of people concerned about
> ongoing tree breakage happier.
> 
> Thanks,
> Donnie
> 

Well IMHO, you can do what you want and if any arch team doesn't like it
they can always pmask it themselves in their arch profile.  I will say I
disagree with putting it into ~arch in the current state, although I
agree with the rationale, and it IS your package(s), just as it's
essentially their arch.

I guess the deal here is to not encourage this type of behavior;
intentially breaking ~arch all the time and then making the arch teams
"clean up" so to speak.  I don't believe this to be the case here, I
just don't want to see it become commonplace ;)

Alec Warner (antarus)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ9awSGzglR5RwbyYAQIYAhAAiTkJ8Om/wHwrfdcvfGZbrVhu6glPTz0o
2vcZ2eY1B8ew5RXW9g+/ujZrCS6Bx0Sisi3nIJ94pxvwsmTvTtnKRcmYAZjxnwUD
3XS+UW3bRMjdpxksGeCFsRgq0ji3rwywrJ50DKySKjNMstO5is6ocK1coD3UzKMi
/2wF62aV5onaSNGkxjtYAdM7GjkqLAlLNpE4+kUv876E4PZYIvJnBOBssi21xy+Y
fsgQ07TGqJLSXZQ0I51ONfYc1H9UZdPyXI96UfFSsohuzIeoi1fyGgB8aNRpDb5v
WQWTyM4aVK8vbDWp0k5oVAPva5Uuep0AIrWAr7mUlK8U6kAeCxfMbVQot84qSRlr
7S8uDZY/rvBz4MPh1JlVLuv6t2Q32KpE0S7Y0vIbZTuJCvkYBQL1n9/x0JSCqRLO
0yWg3HfdLD6xrvKOnOxJfQ2SwxzIz6hiaFRIWrqqgqLp5T78arc+9TR41ap8go+E
PMVag4J0F5im8RxpDlahdOfsBk6dDANVgtslTwr8lLVoh8x4xjYgUJX+D9gnGGd6
E9UtnHhgnTIgnwr00ounVQlE11248ukze1J43fHomTpm59tMtTZnH/7rQc10BeHH
aBPEUCTXotEjKCbgliwr7lHhcjDfhjvVLbxbWZY2w2MGbRMXXMV+1HUoLib5+XGj
FO4wGHPXGHg=
=2kL5
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Alec Warner wrote:
> Well IMHO, you can do what you want and if any arch team doesn't like it
> they can always pmask it themselves in their arch profile.  I will say I
> disagree with putting it into ~arch in the current state, although I
> agree with the rationale, and it IS your package(s), just as it's
> essentially their arch.
> 
> I guess the deal here is to not encourage this type of behavior;
> intentially breaking ~arch all the time and then making the arch teams
> "clean up" so to speak.  I don't believe this to be the case here, I
> just don't want to see it become commonplace ;)

I'm certainly not trying to put any extra work on the arch teams; this
is conceptually arch-independent, and the only extra work should be on
the x11 team and on maintainers of unported apps.

But if there are archs that would rather not move to modular X, that's
their prerogative. The way I look at it is, sometimes change comes at a
price. I really hope they aren't any archs I use though, because I take
a certain amount of pride in making the best and newest X available.
When people remask it, it's like they're directly battling against the
whole reason I'm involved in Gentoo.

Thanks,
Donnei


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Georgi Georgiev]

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

maillog: 24/01/2006-12:25:01(-0500): Mark Loeser types
> Donnie Berkholz <spyderous@gentoo.org> said:
> > Ciaran McCreesh wrote:
> > > On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
> > > <spyderous@gentoo.org> wrote:
> > > | Here's my proposal for dealing with modular X entering ~arch.
> > > 
> > > What's wrong with the original idea of just making any unported ebuild
> > > pull in all of modular X (minus drivers)? Yes, it means that some
> > > people will pick up unnecessary deps until all packages are ported, but
> > > it avoids anyone having to see flashy red errors.
> > 
> > The problem with that is that it removes all motivation to ever port the
> > packages. They'll just stay that way forever, where forever means "until
> > I threaten to remove that from the virtual," in which case we'll be in
> > the same scenario we are now. Why? Because people have better things to
> > do than fix stuff that isn't broken.
> 
> It'd be nice if you reconsidered this as it will minimize any breakage that
> may occur.  Knowing that >800 packages are broken, and going to unmask it
> knowing that just doesn't seem acceptable in my eyes.  ~arch isn't meant to
> be "things are known to be broken."  It's meant to mean, we think all of this
> is ready to be stable, which it certainly won't be in this case.

Don't let the numbers trick you, guys. Everything in app-xemacs/ is in
that list only because xemacs is broken. Fix that one package and you
get 115 packages done. I wonder how many others are like that.

-- 
\    Georgi Georgiev   \   Professor: Now, be careful, Fry. And if   \
/     chutz@gg3.net    /  you kill anyone, make sure to eat their    /
\  http://www.gg3.net/ \  heart to gain their courage. Their rich    \
/  ------------------- /  tasty courage.                             /

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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Robin H. Johnson wrote:
> On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote:
>> A) You have commit access to gentoo-x86, AND
>> B) you're comfortable with the porting process OR are adept with ebuilds
>> and would like to help
> I'm up for being a volunteer here.

All devs who've volunteered, please /j #gentoo-x on IRC. We're
collaborating there, and trying to avoid working on the same packages twice.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Ciaran McCreesh]

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

On Mon, 23 Jan 2006 23:33:32 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| > What's wrong with the original idea of just making any unported
| > ebuild pull in all of modular X (minus drivers)? Yes, it means that
| > some people will pick up unnecessary deps until all packages are
| > ported, but it avoids anyone having to see flashy red errors.
| 
| The problem with that is that it removes all motivation to ever port
| the packages. They'll just stay that way forever, where forever means
| "until I threaten to remove that from the virtual," in which case
| we'll be in the same scenario we are now. Why? Because people have
| better things to do than fix stuff that isn't broken.

Ok. So... As far as I can see:

* There is a clean upgrade solution available that will result in
non-ported packages merely pulling in a load of extra unnecessary
packages (that non-modular users have anyway).

* The clean solution visibly illustrates that a package is unported.
Users who are running ~arch can clearly see this, and can file bugs and
(if they care) attempt a --nodeps installation. The bugs can be picked
up by the package maintainers or the volunteers on this list.

* The clean solution is the solution originally proposed to this list,
and the reason we are using new style virtuals.

* There is an alternate upgrade solution that means that any users who
have an unported package will get their screen filled with several
pages of incomprehensible bright red crap.

* There are currently enough unported packages that many ~arch users
will probably have one or two installed (assumption: many users have
several utterly random non-mainstream packages installed).

* Despite your original assurances to this list, you intend to go ahead
and take the alternate solution, which will lead to one of the most
user visible and hardest to fix breakages we've ever had.

* You are doing this because you believe that it is better to get every
package ported over extremely quickly rather than having the odd
package with extra unnecessary listed dependencies, and you do not
consider the impact upon our users to be relevant.

Is my understanding correct?

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

[gentoo-dev] Re: Unmasking modular X

[Duncan]

Alec Warner posted <43D6B048.6010903@egr.msu.edu>, excerpted below,  on
Tue, 24 Jan 2006 17:55:04 -0500:

> I guess the deal here is to not encourage this type of behavior;
> intentially breaking ~arch all the time and then making the arch teams
> "clean up" so to speak.  I don't believe this to be the case here, I
> just don't want to see it become commonplace ;)

FW an ~arch  user's opinion is worth:

This is my feeling as well.  As Spyderous says, I'm ~arch because I want
to help out with bug reporting and the like, so I don't mind the
occasional deliberate breakage as long as it remains occasional, and
announced in advance where I'm likely too see it (here) as someone
following development in ordered to get a headsup on such things.

Personally, I'm already on modular-X, having unmasked it and tried it out
some weeks ago (and having tried it almost as soon as it was available in
the tree, but having it not work so I remasked it for a few weeks to let
it stabilize and until I had time to investigate my issues).  Still, I've
gone thru the posted list, to see what there might apply to me, and am
aware of things just in case something breaks that was somehow missed.

Similarly with portage's use.default thing.  I'm following it and have
in fact already tried a rename of the file in my cascading profile, then
an emerge -NuD world to see what it changed.  In fact, I'm now
rsync-excluding use.default, and have gone thru and removed other
instances of it in my local tree instance as well, now that they are
rsync-excluded.  Nothing's going to break for me on that day, as it has
already been taken care of.

The point being, as a responsible Gentoo user aka Gentoo sysadmin,
deliberately running ~arch, I do the due diligence necessary by following
this list and getting a headsup on the deliberate stuff well before it
hits.

Of course, we wouldn't be going thru the whole news GLEP process if
everybody did that, but unfortunately... .  Still, IMO, if those that
don't, particularly those running ~arch, get a bit of breakage now and
then, maybe they'll learn to be a bit more careful.

Anyway, yes, I say the ground has been prepped, the warning given, it's on
~arch which is by definition testing, so go for it!  As long as it remains
something that when it happens, is in development for months first, and as
long as there are hints here during that time and  more dire warnings a
week in advance, it's a good thing, not a bad thing, and as Spyderous
says, it's what ~arch users are signing up for by going ~arch in the first
place.  If it breaks a few that didn't understand that, well, they'll know
it now!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Unmasking modular X

[Duncan]

Wernfried Haas posted <20060124185229.GB18929@superlupo.rechner>,
excerpted below,  on Tue, 24 Jan 2006 19:52:29 +0100:

> On Tue, Jan 24, 2006 at 01:44:28PM -0500, Mark Loeser wrote:
>> We should aim for when it will be done in a way that minimizes the
>> breakage for all of our users.  Yes, breakage will happen, but we can wait
>> until its down to a more reasonable value.
> 
> And we probably should announce somewhere that this is going to happen
> (if not done already, haven't been following the modular X thing too
> closely).

There has been some coverage in GWN.  Readers know modular-X is coming,
have been invited to test it, and know how to get to it now (the modular-X
HOWTO was linked), along with the fact that it's a big change and may
cause some breakage.

However, I do NOT believe a specific warning was given that it's going to
happen on $DATE and ~arch users should know there might be a bit of
breakage at that time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Jason Wever]

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

On Tue, 24 Jan 2006 15:35:07 -0800
Donnie Berkholz <spyderous@gentoo.org> wrote:

> But if there are archs that would rather not move to modular X, that's
> their prerogative. The way I look at it is, sometimes change comes at
> a price. I really hope they aren't any archs I use though, because I
> take a certain amount of pride in making the best and newest X
> available. When people remask it, it's like they're directly battling
> against the whole reason I'm involved in Gentoo.

As an arch team, SPARC would like to move to modular X.  However if
packages are broken by this unmasking, it *will* be masked on SPARC
until such a time that this is fixed.  Also a complaint will be filed
with developer relations and QA as this blatantly and knowingly defies
the policies regarding keywording that were put in place to
intentionally prohibit this kind of behavior.

I'm not trying to be a party pooper here, but breaking the portage tree
should never be an acceptable answer.

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] Unmasking modular X

[Joshua Baergen]

Jason Wever wrote:
> However if
> packages are broken by this unmasking, it *will* be masked on SPARC
> until such a time that this is fixed. 
>   
<snip>
> I'm not trying to be a party pooper here, but breaking the portage tree
> should never be an acceptable answer.
>
> Cheers,
>   

To be clear here: nothing will be broken.  Xorg 7.0 will just not 
provide virtual/x11 (and in fact blocks it), so there will be issues 
with blocks showing up due to the upgrade path.  Avoiding the upgrade 
(and blockage) is very easy if necessary (eg, you use 200 unported 
packages or something).

Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Ciaran McCreesh]

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

On Tue, 24 Jan 2006 23:00:14 -0700 Joshua Baergen
<joshuabaergen@gentoo.org> wrote:
| To be clear here: nothing will be broken.  Xorg 7.0 will just not 
| provide virtual/x11 (and in fact blocks it), so there will be issues 
| with blocks showing up due to the upgrade path.  Avoiding the upgrade 
| (and blockage) is very easy if necessary (eg, you use 200 unported 
| packages or something).

That is exactly the issue. Your average ~arch user is going to get
pages and pages of nasty red incomprehensible blocks simply because
you're making Xorg 7 block the virtual rather than provide it.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> On Tue, 24 Jan 2006 23:00:14 -0700 Joshua Baergen
> <joshuabaergen@gentoo.org> wrote:
> | To be clear here: nothing will be broken.  Xorg 7.0 will just not 
> | provide virtual/x11 (and in fact blocks it), so there will be issues 
> | with blocks showing up due to the upgrade path.  Avoiding the upgrade 
> | (and blockage) is very easy if necessary (eg, you use 200 unported 
> | packages or something).
> 
> That is exactly the issue. Your average ~arch user is going to get
> pages and pages of nasty red incomprehensible blocks simply because
> you're making Xorg 7 block the virtual rather than provide it.

Where are you getting this idea of pages and pages? Your previous
statement was that the average ~arch users would likely have a couple of
unported apps. Unless they're using 1-line terminals, this just doesn't
translate to "pages and pages" for me.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> * There is a clean upgrade solution available that will result in
> non-ported packages merely pulling in a load of extra unnecessary
> packages (that non-modular users have anyway).
> 
> * The clean solution visibly illustrates that a package is unported.
> Users who are running ~arch can clearly see this, and can file bugs and
> (if they care) attempt a --nodeps installation. The bugs can be picked
> up by the package maintainers or the volunteers on this list.

Yes, for all 3 people who have a clue what it means when virtual/x11
gets pulled in. How many users do you seriously think will have a clue
and think "Oh, virtual/x11 is getting pulled in here. I must have a
package that isn't ported to modular X somewhere in this list. Let me
track it down and file a bug."?

> * The clean solution is the solution originally proposed to this list,
> and the reason we are using new style virtuals.

No, this is wrong. The reason we are using new style virtuals is so we
could have a versioning in what provides virtual/x11. Namely, 6.8 or older.

> * There is an alternate upgrade solution that means that any users who
> have an unported package will get their screen filled with several
> pages of incomprehensible bright red crap.

Several pages? How is that coming from a single unported package? Also,
it's not incomprehensible and shouldn't be to anyone on ~arch (or
frankly, anywhere), because packages involving blockers regularly have
to be dealt with.

> * There are currently enough unported packages that many ~arch users
> will probably have one or two installed (assumption: many users have
> several utterly random non-mainstream packages installed).

Possible, but we can't prove this one way or the other. Certainly very
few modular X users have encountered apps that are still unported, as
evidenced by very few remaining blockers on #112675. And there are a
fairly large number of

> * Despite your original assurances to this list, you intend to go ahead
> and take the alternate solution, which will lead to one of the most
> user visible and hardest to fix breakages we've ever had.

Yes, I suggested handling this differently back in early August, when
these things were in the planning stage. But even later that month, I
posted saying that wasn't the best way to handle it. It's not difficult
to imagine that things can change over the course of 6 months.

> * You are doing this because you believe that it is better to get every
> package ported over extremely quickly rather than having the odd
> package with extra unnecessary listed dependencies, and you do not
> consider the impact upon our users to be relevant.

I consider ~arch users to have agreed to help test and fix new things.
This is included. I would not do the same thing to our stable tree, or
if we only had a stable tree.

Yes, I do think it is better to have a quick solution and let some of
our ~arch users see a couple of blocks, for which they will file bugs.
Then these bugs will be fixed within a day, and those users will again
have working systems.

I don't see what the big deal is. By being ~arch users, they're already
asking to use ebuilds that have a chance of breaking their systems
permanently, let alone a single 'emerge sync'.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Donnie Berkholz wrote:
> Possible, but we can't prove this one way or the other. Certainly very
> few modular X users have encountered apps that are still unported, as
> evidenced by very few remaining blockers on #112675. And there are a
> fairly large number of

... people using modular X already, from personal reports to me as well
as reporters and CC members on modular X-related bug reports.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Donnie Berkholz wrote:
> Please contact me if you'd like to be one of these volunteers. Requirements:
> 
> A) You have commit access to gentoo-x86, AND
> B) you're comfortable with the porting process OR are adept with ebuilds
> and would like to help

I've decided to give it a wait for a few days until unmasking while our
new porting task force tears through lots of packages. With the task
force, I feel enough visible, reasonable progress is being made to help
me avoid being frustrated with the people saying I should wait for
something that would never happen.

If you want to join the task force, just hop on IRC and /j #gentoo-x. We
can always use more help. Right now, we've got 12 people in there.

Also, Robin's created a new script to tell exactly which apps are broken
with modular X, and which ones only have something in their dep tree
broken. A run of this script on yesterday's results shows that there are
only 558 "real" broken modular packages out of 867 total.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Ciaran McCreesh]

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

On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Yes, for all 3 people who have a clue what it means when virtual/x11
| gets pulled in. How many users do you seriously think will have a clue
| and think "Oh, virtual/x11 is getting pulled in here. I must have a
| package that isn't ported to modular X somewhere in this list. Let me
| track it down and file a bug."?

When users suddenly see lots of extra X packages being pulled in that
they don't need, it'll be rather obvious (and trivial to track down
with --tree). Especially if it's documented somewhere that "packages
that suddenly pull in lots of extra X packages usually means porting
needed".

| > * The clean solution is the solution originally proposed to this
| > list, and the reason we are using new style virtuals.
| 
| No, this is wrong. The reason we are using new style virtuals is so we
| could have a versioning in what provides virtual/x11. Namely, 6.8 or
| older.

Uh, given that you can do that with old style virtuals, methinks that
isn't the case...

| > * There are currently enough unported packages that many ~arch users
| > will probably have one or two installed (assumption: many users have
| > several utterly random non-mainstream packages installed).
| 
| Possible, but we can't prove this one way or the other. Certainly very
| few modular X users have encountered apps that are still unported, as
| evidenced by very few remaining blockers on #112675.

Sure, but that's because there are relatively few users using hard
masked packages. When you add it to ~arch the number will go up
massively.

| > * You are doing this because you believe that it is better to get
| > every package ported over extremely quickly rather than having the
| > odd package with extra unnecessary listed dependencies, and you do
| > not consider the impact upon our users to be relevant.
| 
| I consider ~arch users to have agreed to help test and fix new things.
| This is included. I would not do the same thing to our stable tree, or
| if we only had a stable tree.
| 
| Yes, I do think it is better to have a quick solution and let some of
| our ~arch users see a couple of blocks, for which they will file bugs.
| Then these bugs will be fixed within a day, and those users will again
| have working systems.

...or you could do things as originally planned, and have no
non-working systems at all and the only consequences for end users will
be a small number of extra packages (that they previously had installed
anyway as part of hugeass X) being pulled in.

| I don't see what the big deal is. By being ~arch users, they're
| already asking to use ebuilds that have a chance of breaking their
| systems permanently, let alone a single 'emerge sync'.

They are asking to use ebuilds that may have undetected issues. They
are not asking to use things that we know fine well are broken. ~arch
is for "will hopefully go stable after further testing", not "stuff
that has a very high chance of screwing you over".

You're deliberately causing nasty problems for ~arch users when there's
a very easy, clean workaround with far lower consequences and the same
end result. This is unacceptable.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Wednesday 25 January 2006 15:53, Ciaran McCreesh wrote:
> On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz
> <spyderous@gentoo.org> wrote:
> | > * The clean solution is the solution originally proposed to this
> | > list, and the reason we are using new style virtuals.
> | 
> | No, this is wrong. The reason we are using new style virtuals is so we
> | could have a versioning in what provides virtual/x11. Namely, 6.8 or
> | older.
> 
> Uh, given that you can do that with old style virtuals, methinks that
> isn't the case...

Only by modifying every ebuild that has a virtual/x11 dependency. The atom 
"virtual/x11" cannot be limited to specific versions on its own with old 
style virtuals.

> | > * You are doing this because you believe that it is better to get
> | > every package ported over extremely quickly rather than having the
> | > odd package with extra unnecessary listed dependencies, and you do
> | > not consider the impact upon our users to be relevant.
> | 
> | I consider ~arch users to have agreed to help test and fix new things.
> | This is included. I would not do the same thing to our stable tree, or
> | if we only had a stable tree.
> | 
> | Yes, I do think it is better to have a quick solution and let some of
> | our ~arch users see a couple of blocks, for which they will file bugs.
> | Then these bugs will be fixed within a day, and those users will again
> | have working systems.
> 
> ...or you could do things as originally planned, and have no
> non-working systems at all and the only consequences for end users will
> be a small number of extra packages (that they previously had installed
> anyway as part of hugeass X) being pulled in.

The premise for not doing this is that packages will never be fixed, right? 
Why not make the modular X provide virtual/x11 and just institute a policy 
that no new packages can go into stable with a virtual/x11 dependency? It 
could even be easily enforcable if necessary.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz
> <spyderous@gentoo.org> wrote:
> | Yes, for all 3 people who have a clue what it means when virtual/x11
> | gets pulled in. How many users do you seriously think will have a clue
> | and think "Oh, virtual/x11 is getting pulled in here. I must have a
> | package that isn't ported to modular X somewhere in this list. Let me
> | track it down and file a bug."?
> 
> When users suddenly see lots of extra X packages being pulled in that
> they don't need, it'll be rather obvious (and trivial to track down
> with --tree). Especially if it's documented somewhere that "packages
> that suddenly pull in lots of extra X packages usually means porting
> needed".

Where do they define "lots"? Many packages will legitimately pull in a
large quantity of libs or apps that are not installed by someone
emerging xorg-server, e.g.

> | > * The clean solution is the solution originally proposed to this
> | > list, and the reason we are using new style virtuals.
> | 
> | No, this is wrong. The reason we are using new style virtuals is so we
> | could have a versioning in what provides virtual/x11. Namely, 6.8 or
> | older.
> 
> Uh, given that you can do that with old style virtuals, methinks that
> isn't the case...

Really? It's certainly not made clear. Has the ability existed for long?
I can only find a single example of it in the virtuals files, which was
added last summer. I don't make a habit of browsing through profiles
every few months to see whether some new undocumented feature has appeared.

There are no existing examples anywhere in the documentation I've seen,
and only a vague hint that virtuals could be any DEPEND atom. Given that
virtual dependencies couldn't work properly with versions, it was a
carryover that virtuals could also not be provided by versioned things.

I guarantee you that adding all of modular X to the virtual/x11 will
make this drag out for years, and THAT is unacceptable to me.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Jason Stubbs wrote:
> Only by modifying every ebuild that has a virtual/x11 dependency. The atom 
> "virtual/x11" cannot be limited to specific versions on its own with old 
> style virtuals.

Is that so? I guess this must be wrong, then:

/usr/portage/profiles/base/virtuals:# Only have this for >=pam-0.78, as
we want to make use of the 'include'
/usr/portage/profiles/base/virtuals:virtual/pam
>=sys-libs/pam-0.78

> The premise for not doing this is that packages will never be fixed, right? 
> Why not make the modular X provide virtual/x11 and just institute a policy 
> that no new packages can go into stable with a virtual/x11 dependency? It 
> could even be easily enforcable if necessary.

How does that fix the stale, unmaintained here and upstream apps that
are in stable now and have no ~arch ebuilds?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Ciaran McCreesh]

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

On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| > Uh, given that you can do that with old style virtuals, methinks
| > that isn't the case...
| 
| Only by modifying every ebuild that has a virtual/x11 dependency. The
| atom "virtual/x11" cannot be limited to specific versions on its own
| with old style virtuals.

Oh? There's at least one old style virtual that specifies a full dep
atom rather than a package name. I know this because it broke my first
virtuals parser that was expecting a straight name...

| The premise for not doing this is that packages will never be fixed,
| right? Why not make the modular X provide virtual/x11 and just
| institute a policy that no new packages can go into stable with a
| virtual/x11 dependency? It could even be easily enforcable if
| necessary.

Much more sensible.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Unmasking modular X

[Ciaran McCreesh]

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

On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Where do they define "lots"? Many packages will legitimately pull in a
| large quantity of libs or apps that are not installed by someone
| emerging xorg-server, e.g.

Heck, add in a "non-ported-package" fake package hack if you really
think ~arch users will have a hard time telling.

| I guarantee you that adding all of modular X to the virtual/x11 will
| make this drag out for years, and THAT is unacceptable to me.

Why must it drag out for years? There's no difference in the speed of
porting between the solutions. The only difference is the impact upon
end users.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz
> | I guarantee you that adding all of modular X to the virtual/x11 will
> | make this drag out for years, and THAT is unacceptable to me.
> 
> Why must it drag out for years? There's no difference in the speed of
> porting between the solutions. The only difference is the impact upon
> end users.

And impact creates motivation. If it isn't literally broken, 95% of devs
just have better things to do than fix it.

Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Wednesday 25 January 2006 16:19, Donnie Berkholz wrote:
> Jason Stubbs wrote:
> > Only by modifying every ebuild that has a virtual/x11 dependency. The atom 
> > "virtual/x11" cannot be limited to specific versions on its own with old 
> > style virtuals.
> 
> Is that so? I guess this must be wrong, then:
> 
> /usr/portage/profiles/base/virtuals:# Only have this for >=pam-0.78, as
> we want to make use of the 'include'
> /usr/portage/profiles/base/virtuals:virtual/pam
> >=sys-libs/pam-0.78

Yep, portage simply removes the >= and 0.78 parts and makes all versions of 
sys-libs/pam a provider of virtual/pam. Why there is no warning I don't know.

> > The premise for not doing this is that packages will never be fixed, 
> > right? Why not make the modular X provide virtual/x11 and just institute a 
> > policy that no new packages can go into stable with a virtual/x11 
> > dependency? It could even be easily enforcable if necessary.
> 
> How does that fix the stale, unmaintained here and upstream apps that
> are in stable now and have no ~arch ebuilds?

It wouldn't, but at least there'd be fewer packages to deal with in the final 
cleanup. It was just an innocent question though; as far as I can tell, 
emerging any application (ported or not) on a clean system will not break 
even after modular X is unmasked. It's a fine line between whether packages 
"needlessly" not working together due to incompatible (deep) dependencies is 
considered breakage or not though...

/me steps away from the flames for fear of getting burned.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs <jstubbs@gentoo.org>
> wrote:
> | The premise for not doing this is that packages will never be fixed,
> | right? Why not make the modular X provide virtual/x11 and just
> | institute a policy that no new packages can go into stable with a
> | virtual/x11 dependency? It could even be easily enforcable if
> | necessary.
> 
> Much more sensible.

I've thought some about this. It would be acceptable to me for
virtual/x11 to provide modular X deps, if we also instituted a repoman
death upon any attempt to commit to a directory for which the best
visible package is broken.

This will accomplish the goal of discovering completely unmaintained
packages but will fail in the goal of discovering which packages nobody
uses. They'll still continue to rot in the tree, unmaintained, unused
and taking up space in everybody's syncs.

How's that sound?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Ciaran McCreesh]

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

On Tue, 24 Jan 2006 23:34:49 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Ciaran McCreesh wrote:
| > On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz
| > | I guarantee you that adding all of modular X to the virtual/x11
| > | will make this drag out for years, and THAT is unacceptable to me.
| > 
| > Why must it drag out for years? There's no difference in the speed
| > of porting between the solutions. The only difference is the impact
| > upon end users.
| 
| And impact creates motivation. If it isn't literally broken, 95% of
| devs just have better things to do than fix it.

This does not give you the right to deliberately break things for our
users.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> On Tue, 24 Jan 2006 23:34:49 -0800 Donnie Berkholz
> <spyderous@gentoo.org> wrote:
> | Ciaran McCreesh wrote:
> | > On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz
> | > | I guarantee you that adding all of modular X to the virtual/x11
> | > | will make this drag out for years, and THAT is unacceptable to me.
> | > 
> | > Why must it drag out for years? There's no difference in the speed
> | > of porting between the solutions. The only difference is the impact
> | > upon end users.
> | 
> | And impact creates motivation. If it isn't literally broken, 95% of
> | devs just have better things to do than fix it.
> 
> This does not give you the right to deliberately break things for our
> users.

I disagree, for ~arch users. But it seems we've hit upon a different
solution elsewhere in the thread, so there's no point in continuing this.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Wednesday 25 January 2006 16:40, Donnie Berkholz wrote:
> Ciaran McCreesh wrote:
> > On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs <jstubbs@gentoo.org>
> > wrote:
> > | The premise for not doing this is that packages will never be fixed,
> > | right? Why not make the modular X provide virtual/x11 and just
> > | institute a policy that no new packages can go into stable with a
> > | virtual/x11 dependency? It could even be easily enforcable if
> > | necessary.
> > 
> > Much more sensible.
> 
> I've thought some about this. It would be acceptable to me for
> virtual/x11 to provide modular X deps, if we also instituted a repoman
> death upon any attempt to commit to a directory for which the best
> visible package is broken.
> 
> This will accomplish the goal of discovering completely unmaintained
> packages but will fail in the goal of discovering which packages nobody
> uses. They'll still continue to rot in the tree, unmaintained, unused
> and taking up space in everybody's syncs.
> 
> How's that sound?

I'm not exactly sure what you mean by "broken" in the first paragraph nor how 
a check can help with unmaintained (=no commits, no?) packages, but if a 
repoman check will hasten package porting while smoothing the users' ride, 
I'm personally all for it.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Jason Stubbs wrote:
> I'm not exactly sure what you mean by "broken" in the first paragraph nor how 
> a check can help with unmaintained (=no commits, no?) packages, but if a 
> repoman check will hasten package porting while smoothing the users' ride, 
> I'm personally all for it.

By "broken" I mean unported. In other words, directly depending on
either virtual/x11 or x11-base/xorg-x11. The check will help discover
unmaintained packages by not allowing people to do flyby fixes without
also fixing this.

What can I do to speed up the process of getting this into a 2.1
release? Keep in mind my python is beyond bad.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Wednesday 25 January 2006 17:43, Donnie Berkholz wrote:
> Jason Stubbs wrote:
> > I'm not exactly sure what you mean by "broken" in the first paragraph nor 
> > how a check can help with unmaintained (=no commits, no?) packages, but if 
> > a repoman check will hasten package porting while smoothing the users' 
> > ride, I'm personally all for it.
> 
> By "broken" I mean unported. In other words, directly depending on
> either virtual/x11 or x11-base/xorg-x11. The check will help discover
> unmaintained packages by not allowing people to do flyby fixes without
> also fixing this.
> 
> What can I do to speed up the process of getting this into a 2.1
> release? Keep in mind my python is beyond bad.

Perhaps not so easy. What specific states need to be checked for to regard a 
package as broken? Depending on "x11-base/xorg-x11" is one. Depending on 
"virtual/x11" seems to be valid looking at the porting guide though. Would 
considering a package broken if it contains "virtual/x11" where the token 
immediately preceding the surrounding brackets is not "||" be correct?

DEPEND="x11-base/xorg-x11"              # wrong
DEPEND="virtual/x11"                    # wrong
DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
DEPEND="|| ( misc/atoms virtual/x11 )"  # right

There's a small possibility that broken packages will be missed by this, but 
is there any chance that valid packages will be incorrectly flagged? If this 
gets a go-ahead, it'll be easy enough to get in for the next release (which 
is likely this coming Saturday).

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Jason Stubbs wrote:
> On Wednesday 25 January 2006 17:43, Donnie Berkholz wrote:
>> Jason Stubbs wrote:
>>> I'm not exactly sure what you mean by "broken" in the first paragraph nor 
>>> how a check can help with unmaintained (=no commits, no?) packages, but if 
>>> a repoman check will hasten package porting while smoothing the users' 
>>> ride, I'm personally all for it.
>> By "broken" I mean unported. In other words, directly depending on
>> either virtual/x11 or x11-base/xorg-x11. The check will help discover
>> unmaintained packages by not allowing people to do flyby fixes without
>> also fixing this.
>>
>> What can I do to speed up the process of getting this into a 2.1
>> release? Keep in mind my python is beyond bad.
> 
> Perhaps not so easy. What specific states need to be checked for to regard a 
> package as broken? Depending on "x11-base/xorg-x11" is one. Depending on 
> "virtual/x11" seems to be valid looking at the porting guide though. Would 
> considering a package broken if it contains "virtual/x11" where the token 
> immediately preceding the surrounding brackets is not "||" be correct?
> 
> DEPEND="x11-base/xorg-x11"              # wrong
> DEPEND="virtual/x11"                    # wrong
> DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
> DEPEND="|| ( misc/atoms virtual/x11 )"  # right
> 
> There's a small possibility that broken packages will be missed by this, but 
> is there any chance that valid packages will be incorrectly flagged? If this 
> gets a go-ahead, it'll be easy enough to get in for the next release (which 
> is likely this coming Saturday).

It sounds right. There should be no valid instance of virtual/x11 that
is not within an || dep.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote:
> Jason Stubbs wrote:
> > DEPEND="x11-base/xorg-x11"              # wrong
> > DEPEND="virtual/x11"                    # wrong
> > DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
> > DEPEND="|| ( misc/atoms virtual/x11 )"  # right
> > 
> > There's a small possibility that broken packages will be missed by this, 
> > but is there any chance that valid packages will be incorrectly flagged? 
> > If this gets a go-ahead, it'll be easy enough to get in for the next 
> > release (which is likely this coming Saturday).
> 
> It sounds right. There should be no valid instance of virtual/x11 that
> is not within an || dep.

I've implemented and tested the check locally but haven't committed it yet. 
Repoman isn't really structured to allow for tests against a set of ebuilds 
so the checks are done on every version. There is also definitely one false 
positive (virtual/x11-6.8) so, for this and the fact that every version is 
tested, it would probably better to just make it a warning. Thoughts?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Brian Harring]

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

On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote:
> On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote:
> > Jason Stubbs wrote:
> > > DEPEND="x11-base/xorg-x11"              # wrong
> > > DEPEND="virtual/x11"                    # wrong
> > > DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
> > > DEPEND="|| ( misc/atoms virtual/x11 )"  # right
> > > 
> > > There's a small possibility that broken packages will be missed by this, 
> > > but is there any chance that valid packages will be incorrectly flagged? 
> > > If this gets a go-ahead, it'll be easy enough to get in for the next 
> > > release (which is likely this coming Saturday).
> > 
> > It sounds right. There should be no valid instance of virtual/x11 that
> > is not within an || dep.
> 
> I've implemented and tested the check locally but haven't committed it yet. 
> Repoman isn't really structured to allow for tests against a set of ebuilds 
> so the checks are done on every version. There is also definitely one false 
> positive (virtual/x11-6.8) so, for this and the fact that every version is 
> tested, it would probably better to just make it a warning. Thoughts?

Curious about the mechanism you're using for this... a hardcoded set 
of atoms in repoman doesn't sound very nice to me ;)

~harring

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

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Wednesday 25 January 2006 20:46, Brian Harring wrote:
> On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote:
> > On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote:
> > > Jason Stubbs wrote:
> > > > DEPEND="x11-base/xorg-x11"              # wrong
> > > > DEPEND="virtual/x11"                    # wrong
> > > > DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
> > > > DEPEND="|| ( misc/atoms virtual/x11 )"  # right
> > > > 
> > > > There's a small possibility that broken packages will be missed by 
> > > > this, but is there any chance that valid packages will be incorrectly 
> > > > flagged? If this gets a go-ahead, it'll be easy enough to get in for 
> > > > the next release (which is likely this coming Saturday).
> > > 
> > > It sounds right. There should be no valid instance of virtual/x11 that
> > > is not within an || dep.
> > 
> > I've implemented and tested the check locally but haven't committed it 
> > yet. Repoman isn't really structured to allow for tests against a set of 
> > ebuilds so the checks are done on every version. There is also definitely 
> > one false positive (virtual/x11-6.8) so, for this and the fact that every 
> > version is tested, it would probably better to just make it a warning. 
> > Thoughts? 
> 
> Curious about the mechanism you're using for this... a hardcoded set 
> of atoms in repoman doesn't sound very nice to me ;)

Get off it. There's no other way to do it given repoman's state and the 
requirements. If you'd like to make repoman pluggable, convert all the 
current checks to plugins and then make a new plugin for this one and do it 
all by this weekend, be my guest. :P

Besides, what's wrong with hardcoded atoms in repoman anyway? Repoman doesn't 
have to stand the test of time. Conversely, it should represent checks for 
whatever issues are present in the tree at the time of its release.

http://dev.gentoo.org/~jstubbs/x11_deprecation_check.diff

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Brian Harring]

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

On Wed, Jan 25, 2006 at 09:18:28PM +0900, Jason Stubbs wrote:
> On Wednesday 25 January 2006 20:46, Brian Harring wrote:
> > On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote:
> > > On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote:
> > > > Jason Stubbs wrote:
> > > > > DEPEND="x11-base/xorg-x11"              # wrong
> > > > > DEPEND="virtual/x11"                    # wrong
> > > > > DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
> > > > > DEPEND="|| ( misc/atoms virtual/x11 )"  # right
> > > > > 
> > > > > There's a small possibility that broken packages will be missed by 
> > > > > this, but is there any chance that valid packages will be incorrectly 
> > > > > flagged? If this gets a go-ahead, it'll be easy enough to get in for 
> > > > > the next release (which is likely this coming Saturday).
> > > > 
> > > > It sounds right. There should be no valid instance of virtual/x11 that
> > > > is not within an || dep.
> > > 
> > > I've implemented and tested the check locally but haven't committed it 
> > > yet. Repoman isn't really structured to allow for tests against a set of 
> > > ebuilds so the checks are done on every version. There is also definitely 
> > > one false positive (virtual/x11-6.8) so, for this and the fact that every 
> > > version is tested, it would probably better to just make it a warning. 
> > > Thoughts? 
> > 
> > Curious about the mechanism you're using for this... a hardcoded set 
> > of atoms in repoman doesn't sound very nice to me ;)
> 
> There's no other way to do it given repoman's state and the 
> requirements.

I was talking long term.  One time kludges suck (but occur), would 
like to see something a bit less short sighted for this though- 
variants of this request will come up sooner or later (most likely in 
the form of can we warn/error on new commits of deprecated deps).

Might be wise discussing potential solutions for it.


> If you'd like to make repoman pluggable, convert all the 
> current checks to plugins and then make a new plugin for this one and do it 
> all by this weekend, be my guest. :P

Harass antarus, he's been working on integrating swegeners rewrite of 
repoman checks (plugins effectively) into mainline repoman. :P

Besides, a massive change to repoman with 3 days to go is a no go 
anyways (kind of limited the choices there) ;)

> Besides, what's wrong with hardcoded atoms in repoman anyway?

portage (by extension repoman) is used beyond gentoo.  Not everyone 
may be at the same step as we are for mod x.  End result of hardcoding 
gentoo specific crap into repoman is that you force derivatives of 
gentoo (vidalinux or genux fex) to start hacking up portage source to 
remove said hardcoding.

Portage exists beyond gentoo; thus gentoo specific hacks should be 
avoided when possible.

So... long term?

~harring

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

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Wednesday 25 January 2006 21:47, Brian Harring wrote:
> On Wed, Jan 25, 2006 at 09:18:28PM +0900, Jason Stubbs wrote:
> > There's no other way to do it given repoman's state and the requirements.
> 
> I was talking long term.  One time kludges suck (but occur), would like to 
> see something a bit less short sighted for this though- variants of this 
> request will come up sooner or later (most likely in the form of can we 
> warn/error on new commits of deprecated deps).   
>
> Might be wise discussing potential solutions for it.

This is off-topic now.

> > If you'd like to make repoman pluggable, convert all the current checks to 
> > plugins and then make a new plugin for this one and do it all by this 
> > weekend, be my guest. :P 
> 
> Harass antarus, he's been working on integrating swegeners rewrite of 
> repoman checks (plugins effectively) into mainline repoman. :P 
> 
> Besides, a massive change to repoman with 3 days to go is a no go anyways 
> (kind of limited the choices there) ;) 

Would 10 days or 17 days really be any different?

> > Besides, what's wrong with hardcoded atoms in repoman anyway?
> 
> portage (by extension repoman) is used beyond gentoo.  Not everyone may be 
> at the same step as we are for mod x.  End result of hardcoding gentoo 
> specific crap into repoman is that you force derivatives of gentoo 
> (vidalinux or genux fex) to start hacking up portage source to remove said 
> hardcoding.  
> 
> Portage exists beyond gentoo; thus gentoo specific hacks should be avoided 
> when possible. 

Such as warning/failing on:
* the server's repository path is "/space/cvsroot"
* any extensions to metadata.xml
* larger-than-20k-files
* not being copyrighted to Gentoo Foundation
* not being distributed under GPLv2

There's probably others but all of those things are Gentoo specific and cause 
no less trouble than what a virtual/x11 check might cause.

> So... long term?

Refactor/rewrite/modularize/blah repoman. In the mean time, make do with what 
we have and let Gentoo derivatives do the same.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Jason Stubbs wrote:
> I've implemented and tested the check locally but haven't committed it yet. 
> Repoman isn't really structured to allow for tests against a set of ebuilds 
> so the checks are done on every version. There is also definitely one false 
> positive (virtual/x11-6.8) so, for this and the fact that every version is 
> tested, it would probably better to just make it a warning. Thoughts?

I'd rather see the xorg-x11 check removed and make this a repoman
failure than keep it a warning. Would it be possible to factor it up a
little bit so that virtual/x11 is a failure and xorg-x11 is a warning?

It doesn't bother me that checks are done on every version, but what it
does mean is that the next committer will need to port any modular X
changes to all the ebuilds, since we've generally just been putting them
in the latest ~arch and newer (p.mask). This should mostly be a copy and
paste issue, but it will be a minor annoyance even though it's the best
thing we could do, IMHO.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 10:48 -0800, Donnie Berkholz wrote:
> changes to all the ebuilds, since we've generally just been putting them
> in the latest ~arch and newer (p.mask). This should mostly be a copy and

We have?  No wonder it's been taking me so fscking long to get all of
the games stuff done.  I've been doing it for every version of all
offending packages, not just the ones in ~arch, since we can't be sure
if a user is using a mixed stable/testing system or not.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Chris Gianelloni wrote:
> On Wed, 2006-01-25 at 10:48 -0800, Donnie Berkholz wrote:
>> changes to all the ebuilds, since we've generally just been putting them
>> in the latest ~arch and newer (p.mask). This should mostly be a copy and
> 
> We have?  No wonder it's been taking me so fscking long to get all of
> the games stuff done.  I've been doing it for every version of all
> offending packages, not just the ones in ~arch, since we can't be sure
> if a user is using a mixed stable/testing system or not.

Sorry about the confusion there =(

People using mixed stable/testing can deal with the consequences (i.e.,
also ~arch broken packages) until the proper app maintainer gets around
to fixing all the deps.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Donnie Berkholz wrote:
> Chris Gianelloni wrote:
>> On Wed, 2006-01-25 at 10:48 -0800, Donnie Berkholz wrote:
>>> changes to all the ebuilds, since we've generally just been putting them
>>> in the latest ~arch and newer (p.mask). This should mostly be a copy and
>> We have?  No wonder it's been taking me so fscking long to get all of
>> the games stuff done.  I've been doing it for every version of all
>> offending packages, not just the ones in ~arch, since we can't be sure
>> if a user is using a mixed stable/testing system or not.
> 
> Sorry about the confusion there =(
> 
> People using mixed stable/testing can deal with the consequences (i.e.,
> also ~arch broken packages) until the proper app maintainer gets around
> to fixing all the deps.

Ah, forgot to mention this.

That is the process the task force is using to port packages. The
package maintainers may want to work differently by fixing all the
ebuilds for a given package, because repoman will soon refuse to let you
commit anything unless they're all ported.

The task force is doing enough to get the tree working for ~arch users
and to set an example that package maintainers can port over to the rest
of their ebuilds.

As you're really more of a package maintainer for the games you're
porting, you will probably want to stick with the way you're doing things.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 12:36 -0800, Donnie Berkholz wrote:
> As you're really more of a package maintainer for the games you're
> porting, you will probably want to stick with the way you're doing things.

Yeah, there's very few things in games-* that have an actual maintainer
listed, as we tend to do everything as a group.  Oh yeah, I said it.

Anyway, I do appreciate any work that you're doing on any games ebuilds.
I just hope we don't end up in the exact same situation a (few?) month
or so down the line when this stuff goes stable as we are in now.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Chris Gianelloni wrote:
> Anyway, I do appreciate any work that you're doing on any games ebuilds.
> I just hope we don't end up in the exact same situation a (few?) month
> or so down the line when this stuff goes stable as we are in now.

What I expect is that many of the newly ported apps will go stable
before modular X does. Also, nobody will be able to commit to any
directory with an unported ebuild in any keywording state, so that will
serve to fix many more problems.

What it boils down to is that there's a chance completely untouched,
unmaintained packages that somehow still have an ~arch ebuild could
break when modular X goes stable.

Untouched packages for which the latest (and therefore, ported) ebuild
is stable should work fine. Untouched packages for which the latest
ebuild is ~arch and is never keyworded stable could break.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Jason Stubbs wrote:
> http://dev.gentoo.org/~jstubbs/x11_deprecation_check.diff

Just tested this out. Is there some way to make it more obvious exactly
_what_ is causing the usage.deprecated error by default?

As it is, a test run of this in app-editors/xemacs returns about 50
lines of output without telling you what's wrong besides somehow your
usage is deprecated.

It prints about 10X of crap like this:

virtual/libc !virtual/xemacs berkdb? ( =sys-libs/db-1*
>=sys-libs/gdbm-1.8.0 ) >=sys-libs/zlib-1.1.4 >=dev-libs/openssl-0.9.6
>=media-libs/audiofile-0.2.3 gpm? ( >=sys-libs/gpm-1.19.6 ) postgres? (
>=dev-db/postgresql-7.2 ) ldap? ( net-nds/openldap ) nas? (
media-libs/nas ) dnd? ( x11-libs/dnd ) X? ( virtual/x11 ) motif? (
>=x11-libs/openmotif-2.1.30 ) athena? ( virtual/x11 ) Xaw3d? (
x11-libs/Xaw3d ) neXt? ( x11-libs/neXtaw ) xface? ( media-libs/compface
) tiff? ( media-libs/tiff ) png? ( =media-libs/libpng-1.2* ) jpeg? (
media-libs/jpeg ) canna? ( app-i18n/canna ) !amd64? ( freewnn? (
app-i18n/freewnn ) ) >=sys-libs/ncurses-5.2 !bootstrap? ( sys-devel/patch )

Then doesn't print the one line saying
"app-editors/xemacs/xemacs-21.4.15-r3.ebuild: RDEPEND has deprecated x11
dependencies" without a "full" listing? That doesn't make sense -- if it
has to be one way or the other, it should be the reverse.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Thursday 26 January 2006 16:08, Donnie Berkholz wrote:
> It prints about 10X of crap like this:
> 
> virtual/libc !virtual/xemacs berkdb? ( =sys-libs/db-1*
> >=sys-libs/gdbm-1.8.0 ) >=sys-libs/zlib-1.1.4 >=dev-libs/openssl-0.9.6
> >=media-libs/audiofile-0.2.3 gpm? ( >=sys-libs/gpm-1.19.6 ) postgres? (
> >=dev-db/postgresql-7.2 ) ldap? ( net-nds/openldap ) nas? (
> media-libs/nas ) dnd? ( x11-libs/dnd ) X? ( virtual/x11 ) motif? (
> >=x11-libs/openmotif-2.1.30 ) athena? ( virtual/x11 ) Xaw3d? (
> x11-libs/Xaw3d ) neXt? ( x11-libs/neXtaw ) xface? ( media-libs/compface
> ) tiff? ( media-libs/tiff ) png? ( =media-libs/libpng-1.2* ) jpeg? (
> media-libs/jpeg ) canna? ( app-i18n/canna ) !amd64? ( freewnn? (
> app-i18n/freewnn ) ) >=sys-libs/ncurses-5.2 !bootstrap? ( sys-devel/patch )

This was testing/debugging left in by mistake.

> Then doesn't print the one line saying
> "app-editors/xemacs/xemacs-21.4.15-r3.ebuild: RDEPEND has deprecated x11
> dependencies" without a "full" listing? That doesn't make sense -- if it
> has to be one way or the other, it should be the reverse.

That's a standard repoman thing. Details are only printed if there are less 
than 12 occurrences of a specific warning unless "repoman full" is run. Not 
sure why it wasn't being displayed if there was only one occurrence.

The patch now has the debugging output and x11-base/xorg-x11 check removed.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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

Jason Stubbs wrote:
> That's a standard repoman thing. Details are only printed if there are less 
> than 12 occurrences of a specific warning unless "repoman full" is run. Not 
> sure why it wasn't being displayed if there was only one occurrence.

As it turns out, there were exactly 12.

> The patch now has the debugging output and x11-base/xorg-x11 check removed.

Excellent. Works perfectly. Since we're failing on them, perhaps we can
say "obsolete" instead of "deprecated"?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unmasking modular X

[Brian Harring]

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

On Wed, Jan 25, 2006 at 06:06:02PM +0900, Jason Stubbs wrote:
> On Wednesday 25 January 2006 17:43, Donnie Berkholz wrote:
> > Jason Stubbs wrote:
> > > I'm not exactly sure what you mean by "broken" in the first paragraph nor 
> > > how a check can help with unmaintained (=no commits, no?) packages, but if 
> > > a repoman check will hasten package porting while smoothing the users' 
> > > ride, I'm personally all for it.
> > 
> > By "broken" I mean unported. In other words, directly depending on
> > either virtual/x11 or x11-base/xorg-x11. The check will help discover
> > unmaintained packages by not allowing people to do flyby fixes without
> > also fixing this.
> > 
> > What can I do to speed up the process of getting this into a 2.1
> > release? Keep in mind my python is beyond bad.
> 
> Perhaps not so easy. What specific states need to be checked for to regard a 
> package as broken? Depending on "x11-base/xorg-x11" is one. Depending on 
> "virtual/x11" seems to be valid looking at the porting guide though. Would 
> considering a package broken if it contains "virtual/x11" where the token 
> immediately preceding the surrounding brackets is not "||" be correct?
> 
> DEPEND="x11-base/xorg-x11"              # wrong
> DEPEND="virtual/x11"                    # wrong
> DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
> DEPEND="|| ( misc/atoms virtual/x11 )"  # right
> 
> There's a small possibility that broken packages will be missed by this, but 
> is there any chance that valid packages will be incorrectly flagged? If this 
> gets a go-ahead, it'll be easy enough to get in for the next release (which 
> is likely this coming Saturday).

Patch misses on 
|| ( virtual/x11 )
|| ( x86? ( virtual/x11 ) b )
via the latter, kind of guranteed it's going to miss on
|| ( x86? ( valid-dep ) virtual/x11 )
also...

Fixing it's a bit fun.  fixed a few of the issues in 
dev.gentoo.org/~ferringb/deprecated-x11-scan.py , but some of the 
cases still exist.
~harring


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

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

On Thursday 26 January 2006 20:56, Brian Harring wrote:
> Patch misses on 
> || ( virtual/x11 )

A theoretical case, but if you want to cover it...

> || ( x86? ( virtual/x11 ) b )
> via the latter, kind of guranteed it's going to miss on

It's not a "miss" per se as much as other dependency checks that aren't 
performed are a miss when there is invalid syntax - which prevents a commit 
anyway. If you make "b" a proper atom that specifies a category it'll be 
picked up.

> || ( x86? ( valid-dep ) virtual/x11 )

There is no way that I can see around this without highly increasing the 
possibility of false positives. Are you planning to treat arch flags 
separately?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Jason Stubbs]

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

On Thursday 26 January 2006 22:09, Jason Stubbs wrote:
> There is no way that I can see around this without highly increasing the 
> possibility of false positives.

I extracted a list of cps from repoman, modified your script to check all cpvs 
(rather than only the best) and compared that with repoman's cps. The 
attached result.diff file prefixes repoman-only detection with a "-" and the 
separate tool-only detection with a "+".

Your fixes to seem to producee many false positives and introduce some false 
negatives as well. There may be true positives that I'm missing but I 
couldn't find one picking a few cases at random.

Either way, it doesn't matter if there a few false negatives as it's only 
meant to be an aid. False positives on the other hand are unacceptable.

--
Jason Stubbs

[-- Attachment #2: result.diff --]
[-- Type: text/x-diff, Size: 4981 bytes --]

+app-accessibility/gok
-app-cdr/nero
+app-editors/nvu
+app-editors/vim
+app-editors/zoinks
-app-emulation/cedega
+app-emulation/dosemu
-app-emulation/pearpc
-app-emulation/point2play
+app-emulation/vice
-app-emulation/vmware-workstation
+app-emulation/wine
-app-emulation/winex-transgaming
+app-i18n/kinput2
-app-i18n/uim-svn
+app-misc/beagle
+app-misc/oneko
-app-misc/tkpasman
-app-office/mozilla-sunbird-bin
+app-office/magicpoint
+app-office/openoffice
+app-office/openoffice-ximian
-app-pda/qtopia-desktop-bin
-app-portage/portagemaster
+app-portage/test
+app-shells/fish
+app-text/cstetex
+app-text/gv
+app-text/ptex
-dev-embedded/ponyprog
+dev-games/ode
-dev-java/gnu-classpath
+dev-java/blackdown-jre
-dev-lang/smalltalkx
+dev-lang/swi-prolog-lite
-dev-lisp/mit-scheme
+dev-util/insight
-dev-util/weka
-games-action/phobiaiii
+games-action/tuxkart
+games-action/xpilot
+games-action/xpilot-ng
-games-arcade/emergence-bin
+games-arcade/koules
-games-arcade/mtp-target-bin
+games-arcade/ppracer
+games-arcade/xgalaga
+games-arcade/xjump
+games-board/cgoban
-games-emulation/boycott-advance-sdl
-games-emulation/dgen-sdl
-games-emulation/hugo
-games-emulation/kigb
-games-emulation/mastergear-bin
+games-emulation/snes9x
-games-emulation/vgba
-games-fps/fuhquake-bin
-games-fps/postal2mpdemo
-games-fps/unreal
-games-fps/vendetta-online-bin
-games-puzzle/pauker
-games-puzzle/triptych-demo
+games-puzzle/xwelltris
+games-roguelike/nethack
-games-server/WarpPipe
+games-server/crossfire-server
+games-sports/miniracer
+games-sports/ultimatestunts
+games-strategy/freeciv
+gnome-base/control-center
+gnome-base/nautilus
-mail-client/ciphire-mail
-mail-client/mozilla-thunderbird-bin
+kde-base/kdesktop
+mail-client/mozilla-thunderbird
+media-fonts/x11fonts-jmk
+media-gfx/fbida
-media-gfx/povtree
-media-libs/devil
+media-libs/gd
+media-libs/giblib
+media-libs/glide-v3
-media-libs/hamlib
+media-libs/libcaca
+media-libs/libmpeg2
+media-libs/libquicktime
+media-libs/plib
+media-libs/urt
-media-libs/xpm
+media-plugins/libvisual-plugins
-media-radio/tucnak1
-media-radio/xconvers
-media-radio/xdx
-media-radio/xlog
-media-sound/mup
+media-tv/kdetv
+media-tv/xdtv
+media-video/motioneye
+media-video/mplayer
+media-video/xanim
-media-video/yanc
+net-analyzer/sara
-net-im/ymessenger
+net-libs/gecko-sdk
-net-misc/ltsp
-net-misc/mindterm
-net-misc/nxserver-business
-net-misc/nxserver-enterprise
-net-misc/nxserver-personal
+net-misc/vnc
-net-misc/xsmbrowser
-net-nntp/bnr2
-net-p2p/phex
+net-print/xpp
+net-www/gnash
+net-www/mplayerplug-in
+sci-chemistry/ghemical
+sci-chemistry/gopenmol
-sci-chemistry/nmrpipe
-sci-chemistry/nmrview
+sci-chemistry/rasmol
+sci-chemistry/viewmol
+sci-electronics/spice
+sci-libs/libgdgeda
+sci-misc/boinc
+sys-apps/pcmcia-cs
+sys-devel/gcc
+www-client/elinks
-www-client/mozilla-bin
-www-client/mozilla-firefox-bin
+www-client/mozilla
+www-client/mozilla-firefox
-www-client/opera
+x11-libs/Xaw3d
+x11-libs/libdockapp
+x11-libs/libxsettings-client
+x11-libs/qt
+x11-libs/startup-notification
+x11-misc/3ddesktop
+x11-misc/accessx
+x11-misc/autocutsel
-x11-misc/commonbox-utils
+x11-misc/chgres
+x11-misc/dclock
+x11-misc/electricsheep
+x11-misc/fireflies
+x11-misc/fspanel
+x11-misc/fxred
+x11-misc/hsetroot
+x11-misc/imwheel
+x11-misc/mixer_app
+x11-misc/numlockx
+x11-misc/obpager
+x11-misc/pogo
+x11-misc/seyon
+x11-misc/skippy
+x11-misc/temperature-app
+x11-misc/transset
+x11-misc/vnc2swf
+x11-misc/wayv
+x11-misc/x2vnc
+x11-misc/x2x
+x11-misc/xautomation
+x11-misc/xbatt
+x11-misc/xbattbar
+x11-misc/xcalendar
+x11-misc/xcb
+x11-misc/xclip
+x11-misc/xcompmgr
+x11-misc/xcut
+x11-misc/xdaf
+x11-misc/xdaliclock
+x11-misc/xearth
+x11-misc/xfishtank
+x11-misc/xfm
+x11-misc/xhkeys
+x11-misc/xinput
+x11-misc/xkbd
+x11-misc/xkeycaps
+x11-misc/xmountains
+x11-misc/xnc
+x11-misc/xnview
+x11-misc/xplanet
+x11-misc/xrestop
+x11-misc/xrmap
+x11-misc/xsetleds
+x11-misc/xsimpsons
+x11-misc/xsnap
+x11-misc/xsnow
+x11-misc/xstroke
+x11-misc/xteddy
+x11-misc/xtoolwait
+x11-misc/xtrlock
+x11-misc/xvidcap
+x11-misc/xvkbd
+x11-misc/xwit
+x11-misc/xwrits
+x11-misc/xxkb
+x11-plugins/allin1
+x11-plugins/cputnik
+x11-plugins/enigmail
+x11-plugins/wmCalClock
+x11-plugins/wmMatrix
+x11-plugins/wmMoonClock
+x11-plugins/wmSMPmon
+x11-plugins/wmSpaceWeather
+x11-plugins/wmSun
+x11-plugins/wmacpiload-ac
+x11-plugins/wmacpimon
+x11-plugins/wmalms
+x11-plugins/wmapm
+x11-plugins/wmapmload
+x11-plugins/wmappl
+x11-plugins/wmbatteries
+x11-plugins/wmbattery
+x11-plugins/wmbinclock
+x11-plugins/wmbio
+x11-plugins/wmbluecpu
+x11-plugins/wmbutton
+x11-plugins/wmcalc
+x11-plugins/wmcdplay
+x11-plugins/wmclock
+x11-plugins/wmcp
+x11-plugins/wmcpuload
+x11-plugins/wmcube
+x11-plugins/wmdf
+x11-plugins/wmdiskmon
+x11-plugins/wmdl
+x11-plugins/wmdots
+x11-plugins/wmfire
+x11-plugins/wmfsm
+x11-plugins/wmget
-x11-plugins/wmpager
+x11-plugins/wmppp
+x11-plugins/wmwifi
+x11-terms/xterm
+x11-wm/enlightenment
-x11-wm/pawm
+x11-wm/wmi
+xfce-extra/xfce4-minicmd

Re: [gentoo-dev] Unmasking modular X

[Mark Loeser]

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

Donnie Berkholz <spyderous@gentoo.org> said:
> Jason Stubbs wrote:
> > The patch now has the debugging output and x11-base/xorg-x11 check removed.
> 
> Excellent. Works perfectly. Since we're failing on them, perhaps we can
> say "obsolete" instead of "deprecated"?

Can we put this back to being a warning?  It makes things a pain for arch
teams that are trying to mark a completely unrelated version of the package.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Unmasking modular X

[Patrick McLean]

Mark Loeser wrote:
> Donnie Berkholz <spyderous@gentoo.org> said:
>> Jason Stubbs wrote:
>>> The patch now has the debugging output and x11-base/xorg-x11 check removed.
>> Excellent. Works perfectly. Since we're failing on them, perhaps we can
>> say "obsolete" instead of "deprecated"?
> 
> Can we put this back to being a warning?  It makes things a pain for arch
> teams that are trying to mark a completely unrelated version of the package.
> 
Agreed, this makes keywording packages that have old, non-ported versions still 
floating around very difficult.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Unmasking modular X

[Joshua Jackson]

Mark Loeser <halcy0n <at> gentoo.org> writes:

> 
> Donnie Berkholz <spyderous <at> gentoo.org> said:
> > Jason Stubbs wrote:
> > > The patch now has the debugging output and x11-base/xorg-x11 check removed.
> > 
> > Excellent. Works perfectly. Since we're failing on them, perhaps we can
> > say "obsolete" instead of "deprecated"?
> 
> Can we put this back to being a warning?  It makes things a pain for arch
> teams that are trying to mark a completely unrelated version of the package.
> 
> Thanks,
> 

I will have to agree that this change has made it a pain to mark anything
stable. I had 4 out of the 6 I did today bail out because of this. I took the
simple easy fix and removed the check to stabalize the packages I needed to. I
know we have people who want modular X yesterday, but causing trouble for dev's
going about business that doesn't involve the modular problems directly is only
going to cause resentment and frustration to all the teams involved.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unmasking modular X

[Donnie Berkholz]

Joshua Jackson wrote:
> I will have to agree that this change has made it a pain to mark anything
> stable. I had 4 out of the 6 I did today bail out because of this. I took the
> simple easy fix and removed the check to stabalize the packages I needed to. I
> know we have people who want modular X yesterday, but causing trouble for dev's
> going about business that doesn't involve the modular problems directly is only
> going to cause resentment and frustration to all the teams involved.

Why is the simple fix not copying over the already fixed dependencies in 
the latest ebuild? It's not as if that's a lot of work. That's the 
intent of this failure -- to avoid flyby commits by people when they 
could just fix the deps (which are already available in ~arch) while 
they're there.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unmasking modular X

[Joshua Jackson]

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

Donnie Berkholz wrote:
> Joshua Jackson wrote:
>> I will have to agree that this change has made it a pain to mark
>> anything
>> stable. I had 4 out of the 6 I did today bail out because of this.
>> I took the
>> simple easy fix and removed the check to stabalize the packages I
>> needed to. I
>> know we have people who want modular X yesterday, but causing
>> trouble for dev's
>> going about business that doesn't involve the modular problems
>> directly is only
>> going to cause resentment and frustration to all the teams involved.
>
> Why is the simple fix not copying over the already fixed
> dependencies in the latest ebuild? It's not as if that's a lot of
> work. That's the intent of this failure -- to avoid flyby commits by
> people when they could just fix the deps (which are already
> available in ~arch) while they're there.
>
> Thanks,
> Donnie
In the oldest version of the package (as all these were), I don't see
much point in the change. They will be removed within a fairly short
amount of time. Secondary, you are suggesting that any dev who comes
across a modular x problem to fix it..even if this is a direct
violation of the guidelines set forth in the documentation? I'm
curious as to why you want potentially 200+ dev's to violate it, to
push modular so quickly?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD3wfrSENan+PfizARApkUAJ4/Rfr/iMwZMD1lCkhwBnGH+BhUVwCdHqsD
Rc97k6+FBAKp59MAa2t16Ig=
=P92T
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unmasking modular X

[Donnie Berkholz]

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

Joshua Jackson wrote:
> In the oldest version of the package (as all these were), I don't see
> much point in the change. They will be removed within a fairly short
> amount of time. 

Fairly short meaning what, 6 months? A lot of old ebuilds tend to stick
around forever.

> Secondary, you are suggesting that any dev who comes
> across a modular x problem to fix it..even if this is a direct
> violation of the guidelines set forth in the documentation?

Which guidelines, exactly? I'm having trouble finding these vague
guidelines to which you refer.

I found one that said "If you make an internal, stylistic change to the
ebuild that does not change any of the installed files, then there is no
need to bump the revision number."

I also found "When a package version has proved stable for sufficient
time and the Gentoo maintainer of the package is confident that the
upgrade will not break a regular Gentoo user's machine, then it can be
moved from ~ARCH to ARCH," which, to my reading, can also apply to
transferring ~arch modular X deps to stable.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Unmasking modular X

[Joshua Jackson]

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

Donnie Berkholz wrote:
> Joshua Jackson wrote:
>> In the oldest version of the package (as all these were), I don't
>> see much point in the change. They will be removed within a
>> fairly short amount of time.
>
> Fairly short meaning what, 6 months? A lot of old ebuilds tend to
> stick around forever.
>
True, some older packages stay around longer then they probably
should, and was a exageration on my part but it does prove the point
that the check is somewhat superfluous for most users, since it seems
that most people (from a rough estimate of 2 years on the forums)
seems that 1month is about the outside for most people's updates. As
the point has been brought up about packages being in there longer,
it'd be interesting to write something to do a check for multiple
stable versions with a older version being >=6 months old. Something I
might go look into.
>> Secondary, you are suggesting that any dev who comes across a
>> modular x problem to fix it..even if this is a direct violation
>> of the guidelines set forth in the documentation?
>
> Which guidelines, exactly? I'm having trouble finding these vague
> guidelines to which you refer.
>
> I found one that said "If you make an internal, stylistic change to
> the ebuild that does not change any of the installed files, then
> there is no need to bump the revision number."
>
> I also found "When a package version has proved stable for
> sufficient time and the Gentoo maintainer of the package is
> confident that the upgrade will not break a regular Gentoo user's
> machine, then it can be moved from ~ARCH to ARCH," which, to my
> reading, can also apply to transferring ~arch modular X deps to
> stable.
>
> Thanks, Donnie
>

To quote one of the ebuild-quiz questions:  You wish to make a change
to an ebuild, but you checked the ChangeLogs and metadata.xml and it
appears to be maintained by someone else. How should you proceed?

A general response that is obtained from the documentation source
(either the unofficial dev guide or the developer doc's) Concerns
getting in contact with the maintainer before you make the changes.
Explaining the how and why and either asking them to take care of it
or asking for permission to do so. We've had many developers get
highly upset at another developer changing even a minor thing in their
ebuild...such as the simple changing of depends.

Bringing it back around to Mark's initial point, the check causes
extra work for a arch developer that would require stepping on another
herd/developers package's..this is a Relations nightmare. Not to
mention Quality Control implications it can have, something that I
think as a whole development community we've worked very hard at
improving vastly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD3x1lSENan+PfizARAqFoAJ9tAQ9UI0X3MCXG9A7DjWgrheBWfgCgnUG+
gRDzL4aW8JKoiZEcdNAPgLk=
=/VRh
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unmasking modular X

[Donnie Berkholz]

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

Joshua Jackson wrote:
> To quote one of the ebuild-quiz questions:  You wish to make a change
> to an ebuild, but you checked the ChangeLogs and metadata.xml and it
> appears to be maintained by someone else. How should you proceed?
> 
> A general response that is obtained from the documentation source
> (either the unofficial dev guide or the developer doc's) Concerns
> getting in contact with the maintainer before you make the changes.
> Explaining the how and why and either asking them to take care of it
> or asking for permission to do so. We've had many developers get
> highly upset at another developer changing even a minor thing in their
> ebuild...such as the simple changing of depends.

Only two groups have mentioned anything about touching modular X deps:
gnome and games. Gnome (in the form of dang) requested bugs filed, and
games requested they be contacted about changes made.

> this is a Relations nightmare. Not to
> mention Quality Control implications it can have, something that I
> think as a whole development community we've worked very hard at
> improving vastly.

For the relations side, see above.

I'm not really seeing the quality control aspect. Can you explain to me
how that works, given that all these deps have been tested in ~arch?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Unmasking modular X

[Jason Stubbs]

On Tuesday 31 January 2006 13:49, Joshua Jackson wrote:
> Mark Loeser <halcy0n <at> gentoo.org> writes:
> > Donnie Berkholz <spyderous <at> gentoo.org> said:
> > > Jason Stubbs wrote:
> > > > The patch now has the debugging output and x11-base/xorg-x11 check 
> > > > removed. 
> > > 
> > > Excellent. Works perfectly. Since we're failing on them, perhaps we can
> > > say "obsolete" instead of "deprecated"?
> > 
> > Can we put this back to being a warning?  It makes things a pain for arch
> > teams that are trying to mark a completely unrelated version of the 
> > package. 
> 
> I will have to agree that this change has made it a pain to mark anything
> stable. I had 4 out of the 6 I did today bail out because of this. I took 
> the simple easy fix and removed the check to stabalize the packages I needed 
> to. I know we have people who want modular X yesterday, but causing trouble 
> for dev's going about business that doesn't involve the modular problems 
> directly is only going to cause resentment and frustration to all the teams 
> involved. 

Is there any need for the packages to go into stable without the X deps being 
fixed? Why not just open a bug for the package maintainer and mark it against 
whatever bug is requesting stabling of that package? Moving something to 
stable that you know is going to be broken within a relatively short 
timeframe seems like a very bad idea...

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unmasking modular X

[Mark Loeser]

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

Jason Stubbs <jstubbs@gentoo.org> said:
> Is there any need for the packages to go into stable without the X deps being 
> fixed? Why not just open a bug for the package maintainer and mark it against 
> whatever bug is requesting stabling of that package? Moving something to 
> stable that you know is going to be broken within a relatively short 
> timeframe seems like a very bad idea...

We are talking about completely unrelated versions, not what we are touching.
For example, old imagemagick ebuilds sitting around, where the newer ebuilds
are fixed, but old ones are not.  We have a security bug open about this
package right now, and having an error about deps in some old version doesn't
really help arch teams at all.

I am all for getting stuff ported, but making things harder for arch teams is
not the way to go about it.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Re: Unmasking modular X

[Donnie Berkholz]

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

Mark Loeser wrote:
> Jason Stubbs <jstubbs@gentoo.org> said:
>> Is there any need for the packages to go into stable without the X deps being 
>> fixed? Why not just open a bug for the package maintainer and mark it against 
>> whatever bug is requesting stabling of that package? Moving something to 
>> stable that you know is going to be broken within a relatively short 
>> timeframe seems like a very bad idea...
> 
> We are talking about completely unrelated versions, not what we are touching.
> For example, old imagemagick ebuilds sitting around, where the newer ebuilds
> are fixed, but old ones are not.  We have a security bug open about this
> package right now, and having an error about deps in some old version doesn't
> really help arch teams at all.

Oh, so we just screw up people using modular X on a stable system by
breaking the latest stable ebuild..

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Unmasking modular X

[Ciaran McCreesh]

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

On Tue, 31 Jan 2006 10:41:36 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Mark Loeser wrote:
| > We are talking about completely unrelated versions, not what we are
| > touching. For example, old imagemagick ebuilds sitting around,
| > where the newer ebuilds are fixed, but old ones are not.  We have a
| > security bug open about this package right now, and having an error
| > about deps in some old version doesn't really help arch teams at
| > all.
| 
| Oh, so we just screw up people using modular X on a stable system by
| breaking the latest stable ebuild..

It shouldn't be a critical error. Criticals make it very hard for
people to fix other legitimate issues.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Re: Unmasking modular X

[Jason Stubbs]

On Wednesday 01 February 2006 02:28, Mark Loeser wrote:
> Jason Stubbs <jstubbs@gentoo.org> said:
> > Is there any need for the packages to go into stable without the X deps being 
> > fixed? Why not just open a bug for the package maintainer and mark it against 
> > whatever bug is requesting stabling of that package? Moving something to 
> > stable that you know is going to be broken within a relatively short 
> > timeframe seems like a very bad idea...
> 
> We are talking about completely unrelated versions, not what we are touching.
> For example, old imagemagick ebuilds sitting around, where the newer ebuilds
> are fixed, but old ones are not.  We have a security bug open about this
> package right now, and having an error about deps in some old version doesn't
> really help arch teams at all.

Security bugs are about the only time I can see any urgency. That's not
a good reason to completely degrade the error though. A switch similar
to --ignore-other-archs that skips certain checks for urgent fixes seems
reasonable though.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unmasking modular X

[Mark Loeser]

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

Jason Stubbs <jstubbs@gentoo.org> said:
> On Wednesday 01 February 2006 02:28, Mark Loeser wrote:
> > We are talking about completely unrelated versions, not what we are touching.
> > For example, old imagemagick ebuilds sitting around, where the newer ebuilds
> > are fixed, but old ones are not.  We have a security bug open about this
> > package right now, and having an error about deps in some old version doesn't
> > really help arch teams at all.
> 
> Security bugs are about the only time I can see any urgency. That's not
> a good reason to completely degrade the error though. A switch similar
> to --ignore-other-archs that skips certain checks for urgent fixes seems
> reasonable though.

I don't really see why anyone that is marking an ebuild stable needs to have
a fatal error because an older version of that package isn't ported yet.  We
are perfectly capable of mentioning this on the bug so the maintainer can fix
it later :) A flag to ignore it will make me, and probably other archs, happy
though.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Re: Unmasking modular X

[Donnie Berkholz]

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

Mark Loeser wrote:
> I don't really see why anyone that is marking an ebuild stable needs to have
> a fatal error because an older version of that package isn't ported yet.  We
> are perfectly capable of mentioning this on the bug so the maintainer can fix
> it later :) A flag to ignore it will make me, and probably other archs, happy
> though.

I see broken dependencies with modular X as much more important than
most things repoman warns about now: trailing whitespace, spaces instead
of tabs, etc. So it merits more than they get. Jason's idea of a flag
makes sense to me, because it should require some effort to avoid
porting; it shouldn't be as easy as just not reading warnings.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Unmasking modular X

[Ciaran McCreesh]

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

On Wed, 01 Feb 2006 00:25:25 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Mark Loeser wrote:
| > I don't really see why anyone that is marking an ebuild stable
| > needs to have a fatal error because an older version of that
| > package isn't ported yet.  We are perfectly capable of mentioning
| > this on the bug so the maintainer can fix it later :) A flag to
| > ignore it will make me, and probably other archs, happy though.
| 
| I see broken dependencies with modular X

They're not broken. They're sub-optimal.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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