Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)

[Alec Warner]

Jason Stubbs wrote:
> On Saturday 05 November 2005 03:53, Alec Joseph Warner wrote:
> 
>>As far as including news in the tree goes, news is repository bound
>>information.  Each repository may in fact have relevant news, and in
>>preparation for multiple repositories this is how the news should be
>>handled.  It goes with the rest of the repo-specific information.  That
>>is why it should be in the tree.
> 
> 
> I seem to be repeating myself... What's an example of repository-specific 
> non-package-specific news? Why does `emerge --changelog` not suffice for 
> package-specific news?
> 
> --
> Jason Stubbs

Ok so I'm pwned there ;)

emerge --changelog has no 'official' format.  I believe echangelog
actually puts the changes in the correct format for emerge -l to read,
however not everyone uses echangelog.  Many developers commit in an
incompatable syntax causing the parsing to fail.  This I believe, is an
implementation issue.  Obviously if someone is trying to get an upgrade
guide to users they aren't going to commit in an incompatable format.

We had a similar discussion before and many people wanted gentoo
changelogs to stay true to only gentoo changes, thus some think a gentoo
changelog is an inappropriate place to look for upgrade guides and
errata.  Changelogs are also not easy to search through and the current
syntax does not provide all the benifits of the syntax provided by GLEP 42.

So the options for using emerge --changelog are basically, updating the
syntax to make it useful, probably audit the changelog code in emerge to
make sure it works better ( even half decent 'entries' aren't grabbed,
but I haven't looked at the changelog code in months ).  This of course
makes emerge the newsreader you didn't want, although I'm sure the
eselect module could be modified to read Changelog's just as easily.

Also, nothing covers the expiration of Changelog contents vs expiration
of news items, since the news items are file independent, what if a
bunch of commits basically erases a relevant news item out of the changelog?

Certainly I would support either way ( news or changelog ) although in
the latter case there are some seperate issues that need to be worked
out ( mostly policy issues ).
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] use.defaults ( auto-use )

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Could we by chance, mandate some sort of comment field in that file not
unlike package.mask?

I usually like to know the reason why these flags are being switched on.
Certainly there are some flags that I don't mind and there are others
where I just have to wonder why the hell it's in use.defaults in the
first place.

I'm also a bit worried that things were placed in there a while ago and
are no longer needed, may also be a good idea to date the entries.

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

iQIVAwUBQ278wWzglR5RwbyYAQIauA//bRjPMeA001oaclmvIYT7i+dDUPbsSW0O
xm+4hF1rKj6ip9VyQJyNXAMvh858ZdgNAmQxUlA62fMQFXmvz/KgRKgteeIgHztW
vp7PnbW0hN3vTRiGXkOgsZJoDxoqVLcdcup0sN3EmEyOofwjHNPH7WGnn/hj4g3d
XcS8TB2wWsA9lTJUV3+Jh9ZYt2ou6Qg6Nyruz9C8AKTWQWfPd3CCb/840nFIHBvy
ehZcSg+oAmGQMxaIRN4GnaHwkWlz3BP7qcn6mEBdPxMKM0H3elN/uKcT+RiPr86m
Hw+H0zdofxp2UEyHi81iOJT2ndxqKORUHcZZ39AnGeMCmp777j6tcTwqGuaTqmKX
Y1ievL9MyYp8jQleT9CPOIJmeMAiJzZXXwHS+i0o+FAWezzDB1byi5TSuzFGHPPn
OBZsRgdrre/q3KuPqVGzr0KLy2YJYw1G0/3dMvDaokAn1XGm50RzP+nFkE5fLbtQ
/IMgj9iNFLSR/TOe2X9vYzyZMMCfoptC03RCUZVyqM5h92ghOjQzLX8Qw8Wr39Kf
KWHyg9eQKsHfioKZFGKsT623QaL0BzNuRpScbzXk89J9sdGGZIXGYE/ScQD74UAe
96GZl6wiex31DSByf8npKmbos4ez7GIYg1IV6rQSWgVOwamumesustDZfWY/UhtR
71CNIE1d3kk=
=wtV6
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] use.defaults ( auto-use )

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger wrote:
> On Mon, Nov 07, 2005 at 02:05:37AM -0500, Alec Warner wrote:
> 
>>Could we by chance, mandate some sort of comment field in that file not
>>unlike package.mask?
> 
> 
> what really needs explanation ?  i mean, why do you need a comment for say:
> aalib   media-libs/aalib
> canna   app-i18n/canna
> and every package in there is the same way
> 
> 
Because I want to know WHY this flag is required to be in use.defaults
vs a normal flag?  Because maybe flags were added in the past to cover
situation X and now that situation is fixed another way and we can pull
the flag out of use.defaults.

>>I'm also a bit worried that things were placed in there a while ago and
>>are no longer needed, may also be a good idea to date the entries.
> 
> 
> like what ?  dating is pointless imo, use `cvs ann` :P
> -mike

Right..cvs ann...how do I do that from viewCVS again? :)

In the end I just wonder at the use of these things.  They are both
helpful and bad.  Fex, canna is in there, probably to tell the system
that I have canna installed.  However, I don't think auto-use should be
for that purpose.  If I want to tell portage that I have canna installed
and applications should add canna support, I should set USE=canna.
Yeah, I may have to recompile some stuff b/c I forgot to set it prior,
but IMHO thats my fault, not the build-systems.

Mostly this cropped up from me installing sqlite, for supybot, which
needs sqlite for it's karma storage.  Fine by me.  Then I go to install
php and find it wants to pull in some fandangled php->sqlite deal and I
go wtf, I don't have that set...ohhh use.defaults... Why the hell is
sqlite in use.defaults?!?  That kind of deal.  There are a lot of odd
situations where I think use.defaults is useful ( although there are
times where i wish people would just add to make.defaults in profile so
I can nuke it there ).  I'd just like to know why the flag is being
forced on.  The same reason why I want to know why a package is p.masked.

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

iQIVAwUBQ29t/WzglR5RwbyYAQLvAQ/9ElDpxqcY7Di9ixrcsPv9grY3QjPeE4Ms
hgJn0eXj62cQ363AyE6WRyv0I9oHI7KnHwMWOg6aV+o1nfdyAJnA6iXiosoroZLr
qs2Px2GYR6tKjKghbOJZAbZHe8zNrKIasRnUrbfQW+5tlVnasXUzNkbFYcb95BZ2
YG7DFteGf8kaB909Yfnz2YXAyh2P7kRiOrtwfzeuBC18RZKoCjEnh+n7VA3s+Z15
DVb2V7ZHYsGauryi0cf6RLRaWCNKFQSZEgwTQUSwadMB2DoW+U3uKsrvANsFvSsK
e4iv0SX8544y6J/RzBvP6osx8HWcN+1b/VBOoqynPQ+c/8/nHAOaAYAMnqyMvOOh
ndu9bpnHd/+I/+ZcZ7DarZ5Syspg4a1wo+E0bcsgMhkEbKxxhWU1sW5SCabMskvY
cXc8PTb2iTg9t0f7HN93ekqMBnBtO3pxd+A3rU23AEDWT7vpNFhCY2yDJ/gKJS3X
9NhAbk4lU2Hd8Rjh7h89KUJRluRkn1ly7cPJBd1GnnRDVSMVTZ1oLGjqzke/nmJR
UiR5by5fkt8K/KNh62eY6iu972HmBoJweISuHeFMGbWCj4FFLrSZhq1k/vreubCF
OgKpM/Iy5zDYwW6EEHY4H+wt/VPZR/Pi/pQsDqaoFkhbCtTpsI5pilxrPSza8+8q
Z5hL1qLdFXk=
=21QK
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] use.defaults ( auto-use )

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger wrote:
> On Mon, Nov 07, 2005 at 10:08:45AM -0500, Alec Warner wrote:
> 
>>Mike Frysinger wrote:
>>
>>>On Mon, Nov 07, 2005 at 02:05:37AM -0500, Alec Warner wrote:
>>>
>>>
>>>>Could we by chance, mandate some sort of comment field in that file not
>>>>unlike package.mask?
>>>
>>>
>>>what really needs explanation ?  i mean, why do you need a comment for say:
>>>aalib   media-libs/aalib
>>>canna   app-i18n/canna
>>>and every package in there is the same way
>>
>>Because I want to know WHY this flag is required to be in use.defaults
>>vs a normal flag?  Because maybe flags were added in the past to cover
>>situation X and now that situation is fixed another way and we can pull
>>the flag out of use.defaults
> 
> 
> i think you're confusing use.defaults with the USE in profile make.defaults
> 
> use.defaults is there to simply automatically enable USE flags if a package 
> is 
> installled, nothing more and nothing less
> 
> 
>>>>I'm also a bit worried that things were placed in there a while ago and
>>>>are no longer needed, may also be a good idea to date the entries.
>>>
>>>
>>>like what ?  dating is pointless imo, use `cvs ann` :P
>>
>>Right..cvs ann...how do I do that from viewCVS again? :)
> 
> 
> well, if i had to guess, i'd say try clicking the link that says '(annotate)'
> 
> 
>>In the end I just wonder at the use of these things.  They are both
>>helpful and bad.
> 
> 
> if you want to start a thread about punting use.defaults, then do it ... 
> trying to slowly bleed the file of entries is dumb
> -mike

I know what use.defaults does.  I'm saying that:

A. use.defaults exists for a reason, and developers are using it to
enable functionality.
B. Turning off a flag in use.defaults may cause undesired behavior.

If the developed enabled a flag in there, I generally think that the
developer knows they are doing, maybe thats a bad assumption? :)  If
there are no consequences to removing auto-use from USE_ORDER I'll do it
( I do similar things on my lone server ).  If I am going to over-ride a
flag in use.defaults, I know what it does, but I don't know what it
affects.  Obviously the flag was added to use.defaults for a reason,
either because it's required for something, or it adds value to the
system, or something I can't think of ;)  I simply want to know what
that reason is.  If it doesn't do anything useful, then yeah, I'd like
to see the flag punted from use.defaults because then it's just fluff.

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

iQIVAwUBQ293tmzglR5RwbyYAQIP4g/+Jw9dOjK619VOmOPyq5LsSwZW3oYZDuWA
6TKu7JBjofefCchsERhRo75N8SHc1keCdoQ1cxdSgy366Gau6H+6TRKzhlP3ls9D
Ax7XHN5A2P7F8xz07vRqMoq/u9qAtunhB9wiQKwnUrjUvz+uaYL9O9m+P7BU3aRd
k99ds87794Y2JEhJR2u5xz80Yaqe/4Dq7wktm38immIVmF8njKRfq5T1O8jAamBh
qlWv/DXllBKvBnFnJlkXSyXLkPN9fOewvEHm++RB2fNjf2wt2sWWRUiXrK/wPmaT
t+B2lN86EljsGXbT1AVUHy/3bgeOMGHPL81zAbMHIiEZPIarwkX6g2khm9xVhrJt
3ig3WZxXahV03Mv3PKgdERSHNxuN2b1CXiK+8bSfYUftmZMIs/ddlUXft9kiDTRU
H1tc6FjXoxFCtROsThMI8er6NOP0gB5y+O4F6JWq2I0ScwAcb22K8Jjn4XX4KJDI
qZhbXTJCLhEV5TTznClAPCSeWRVqKGX1jRZnOXfq+fZ+W7MsAPzphZFYySHyx9dY
A74z0UHQJUeJodrJlCWcyFlkd4hgXyLnLJqcMBNJVpMCYj1uh3pYUN8U5AKKNVeR
3N2oNQusTefTzq/IsU3svwQgDmudKBcU8+DhqkjXf4r+J6zxESXt/s5wms7xfPGU
D2HwELW0Ojc=
=8L7y
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
> On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <[EMAIL PROTECTED]>
> wrote:
> | 2. What choices/options are on the table for this feature?
> 
> The big controversy seems to be over whether repositories carry a
> unique identifier string (for example, in metadata/repository_id) or
> whether it's user-assigned. The former is clearly the more sensible
> option, since it lets you do things like (syntax made up):
> 
> DEPEND=">=foo-bar/baz-2.1::ciaranmssekritrepo"
> 
Well lets return to normal syntax for a moment.
DEPEND=">=foo-bar/baz-2.1"
And lets assume this package is named "blar" because I enjoy that name.

emerge blar --repo=ciaranmssekritrepo

This accomplishes the same thing, except I get to name the repo whatever
I wish, and you lose the ability to specify repositories in DEPEND.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ6JSdWzglR5RwbyYAQJsbg/7B8XgQlR6bcTOyeLG2IrguyDh9HJJfhlP
HtiypusFdXF35mFhS469Tsc/dIXPCFbVf7OnflO+m7MCiwryQu19v58R+K5dZgli
lkObsiLmafsdXLE5TGlJ7CuB0yboHrjR/hT8n7tomRuQ/g4YcpvCCL96eSlaQ5iX
tpebI/U0VzOHayoWeGXeMp4oEN197eSg4IM8Q5TQgwh84boDnj/gZAuY11g0nUCL
l3Ardv1qjWHwhmVDnKSxF6fR6EAug0ldNNFL94+xRw1r9Z9pIchC4OO90SBRx6dl
MuwvQLCo9N+HaZgztcXUR0uUFE2H7sTjTVHiIW4KUfZYvoslvNRq9SLBCkn39fQp
LSO4cIpKq81Tov7Ngk/bx7NYfcwv34X6q0ezKCfE4ZYdilST0189Jd6NN2/SiGy6
HOdQh1YWre2jQbcS54Z7p+DSOX6XBg3yUQZTtxDKlaP4vTJdMVjUgqSXdLGFCnGV
suDshDnNQY4opFzmu158U36vX10H5DLqLTTlrJ+3igzb9msnQ/CVnT+lbUFACpq2
DzrBOuJBJcCq+5KPoBk295VozOILjK2hGo+uLLqhA43G4K+mxOD1ER1SOo4osfF2
YBU26fhm14Xxzcf64MtOKB5EzaewX12uzBPFh/a3Ps9VEWCOadhELO0xSENm+ewP
CwxPxIcmsTw=
=HKbW
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
> On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <[EMAIL PROTECTED]>
> wrote:
> | emerge blar --repo=ciaranmssekritrepo
> | 
> | This accomplishes the same thing, except I get to name the repo
> | whatever I wish, and you lose the ability to specify repositories in
> | DEPEND.
> 
> ...and it stops you from being able to package.mask things in a given
> repository, 
Ideally there will be per-repo package.mask entries as well, since .mask
files are typically repository-based.

> and it stops you from being able to stick to a given
> repository for world entries, and it stops you from being able to use
/var/lib/portage/world sucks on the whole.
> it in all those zillion other locations where you can currently use a
> dep atom to do something useful.
Anything in particular other than "those other useful things"?
> 
> Really, emerge blar::ciaranmssekritrepo with Portage creating the
> 'restricted' world entry (and the same behaviour for SLOT deps) would
> be so much more useful...
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ6JXY2zglR5RwbyYAQLnNA//W12tpNkaXMZ3y3qVKvOX2SsP/5gem/vY
wZHeUn/h0zYFJ4cMvo/+at2Q6/+c4lIqpac8ihoxJowJX4UnXECk29vHRsZVOcMm
GzO6aiB0MHd+IdBV/yLc3g8gLP2qOaFPIhnGzZw5wG87+nh6x4E9enZ50akgViSN
gpYNF6fPhvjio7ugTYiXSyf3ScVWq/LP/Cf8TI4Dj9QeoeO/Lfg3sEq93JysctZs
XxpiazkHk4X8p0Gpk62PCwEtk/uA/VYC8+4JysMi1t3UZyqcghREVNRzNu7w8ErU
eonwty/PANReP9f74i7l6cV9y/HTrkkmmh/hxWhKqnuXAkki208D58f5vrkgTr/h
nk41lWAQ0neh2sBQ4EPs8X7SjVgrxYnsZRicWDa7LosZpSOQwb47XZYZyHvTS0/z
LyMaHC5JniGHis8XGOeI9nLnTRsiItoF+6DK15t8Pel2RyE2FsgkZWCwU0w4s8QE
yC8d9ZW2/nim205jqDlpIZZJIQw7d1RAA+FTJNxDrlcSbxK/AjTajOajdY7wRU22
rmGMrkhXyXnIB6lmiwPYzYHoUi0SoJ8NwurjghjhePNGDfPbyVzKJmlaz9Hz3mo3
Z796P05FPW+EwiNv9MYAfXz5ImgSAmWekUcdiCl5VmWnqfNq+GW6q4fDB1z+f205
fD5eCWHusmk=
=XC8n
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Moderated WIki -> ( Was Re: [gentoo-dev] Monthly Gentoo Council Reminder for January )

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've actually been tinkering with this idea for a whole mostly due to
the gross amount of crazy crap that is posted to gentoo-wiki.com ( no
offense to the site which otherwise does a great job ).  However I was
under the impression that the docs team wanted things GuideXML'd and not
wikified ( cvs stuff and all ).  Are you willing to host Quasi-official
docs ( ie dev approved ) on something not GuideXML, or how exactly would
that work, and I realize we should probably move this to the docs list
so I'll cross-post and subscribe ;0

> [3] Something like Microsoft's KB where common issues are well explained,
> resolutions documented and where a good search mechanism is in place to
> help find the right solution. Would require moderation so that solutions
> are correct. Could provide dual solutions: one community-written (open
> wiki), one developers accepted (moderated wiki).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ7sOb2zglR5RwbyYAQKlHBAAnd5Q3gOXft2mWicW5967Dk3Ybly/CxZw
a3lHemiKAflzrvdY1ERXhR4NdQc/OkoxZQkZFBDKIgNQZIyVigJFkBlBx8UTvoKd
mTH+AaCxh+m2BwppCwa9QQacwa0QY5O1OZjucaZ2aoqToCxxpdtr2HCfluNPWH4O
mAZlVafORHvx/v2msziBNru0tG40aXv+VpENoYzhskRW8KUlEpHXd5Hv3iNf3v8q
GJ6/b4DwWpe0D25CmcixJdHzo8Cw9WCwIMbnWDP7sYJXryY4aOk2Kvj0oyejWc/y
f4bS+ujlcWXNKMFY48vCz7St8JmUgYcvbPfv2WgrzChL/1xvdEA1J0QegS1nWDOe
6Bp8rGjSsnJ+V2sOI3o/sr4fi/pztIdgjFmAe9u4XKN9YomAIQ8kspqbGOS2AW35
QO2Aj0YGdLpg41JiJAnQxf0ApnfBubCA6tkADIxrm+1DtBPUgjqu1ZBKhmAb7aUp
Rlt7G7jD0moPRUpdkH2RG2sVHtUFeliMJCsJnxIVJZe9OFMMfNat068ElL/Cg74F
ZFjU8aDlFzAtcbDxyT6qsYEaQCfq4jJPIXAHhxBNEf/LP+qXpjpBMtOQVO+h/cJw
LgI69P44YgU/lsw1olFARtJOOu1Gu7eUyfqyYRsoHEyxLHSDoD2O/hRIgc+coP44
XhyAA+BjZjU=
=ZdSD
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kurt Lieber wrote:
> On Wed, Jan 04, 2006 at 07:57:06PM -0800 or thereabouts, Greg KH wrote:
> 
>>>Which is why Gentoo has jumped the shark and is now on a long, slow
>>>decline.
>>
>>Ok, then what should Gentoo do to fix this percieved decline?
> 
> 
> Exactly what a lot of folks will have kittens about; appoint a CEO, leader,
> boss, manager, etc.  (you know, all those corporate-type words that raise
> the hackles of nearly everyone on this list.)
> 
> Right now, Gentoo is this gigantic, obese amoeba that just sort of sits in
> one place.  Different parts of it try to go in different directions, with
> the net result being that the whole body never goes anywhere.  We haven't
> done anything interesting or innovative over the last...year?  two years?
> We have no effective leadership whatsoever.  We spend far too much time
> arguing amongst ourselves instead of working as a team towards a common
> goal.

 I think some people have attempted things that are interesting or
innovative, although they may not have gotten off of the ground quite
yet.  I think for instance, that Stuart's webapp-config project is a
good idea, and while I also think his first attempt sucked, that perhaps
in the future it could be a great tool, especially for large virtual
host places.  I think it sucks that he has gotten the flack from it here.

The Gentoo Installer is an interesting project, not only for the
graphical frontend, but for the Distro-sponsored Network installer that
is being worked on.  I think many distributions lack tools in this area
and we can be interesting and helpful here.

The Portage project has some cool stuff coming up.  I realize that the
2.X codebase scares a lot of people away due to it's nature but recently
there has been a lot more active development in features and planning.
Plus there is code in the savior branch to do some "interesting" things :)

> 
> adhere to the decisions and, if they don't, invite them to find other
> opportunities for their creative outlet.
This sounds to me like "if they don't like it then send them on their
merry way"  which is kind of a bad attitude IMHO.  If they are working
on something it usually is because they are interested.  You can't
really say "well your interest is useless so work on something else
instead" and expect them to comply.  If they are either going to work on
something they enjoy and contribute to Gentoo or do nothing at
all...well I'll take the former :)

> 
> That person should figure out what Gentoo wants to be when it grows up.
> S/he should carefully consult the various stakeholders, look at the
> strengths/weaknesses of Gentoo as it stands currently and then figure out
> where the best direction is for it to proceed.  They should then be
> responsible for making sure everyone (and I mean *everyone*) executes
> according to this direction.  Folks who disagree with the vision will be
> able to go their own direction and start their own projects.  That's the
> beauty of the GPL.

If this Gentoo project fails/falters (like you seem to think it is
heading) you are free to do the same, form your own project with it's
own set of rules and leader if you so choose.

> 
> Anyway, I have no illusions of this idea ever being implemented in the
> current Gentoo environment.  /shrug.  It was a good ride.
> 
> --kurt

I would agree overall that inter-project communication is lacking in
many areas.  I also think that people are uncompromising.  Everyone is
over-worked, everyone has no time, if you want thing X done, get
cracking...etc... I don't think that is an especially healthy attitude
to getting larger/cooler things accomplished.  If there is an entity
that can help "persuade" projects to listen to one another that would be
 great, but in the end what can you really do?

Partially I ( as currently still a user at this point ) would like to
see a bit more project management.  I see that webapps posted a monthly
meeting reminder to -dev, but how many projects really have meetings
that often?  Do they accomplish anything?  Should we have someone that
tries to attend most meetings to make sure things are going smoothly, or
going at all?  Do we need to have slacking projects that get killed off
by the council as well as "slacker" council members?

More things to consider ;)

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

iQIVAwUBQ7yw+WzglR5RwbyYAQK4og/+PYsiv3BsbcUZhfF1UG5RLj/OtJckNO/D
B/FT4lvux06EcoyOtKlZUQTb6b95cP7UTHWT1x+HHTamwljNo1GVDFB7OXvYInLK
npcL+cEe23+792sNCm4ldpN3+rhosVW2fqIBD6lHBNJ9cXhf7B+ftz+lHXV78gWB
GXMSLkqtaZ3/lxLYhPHPeC6RwFtYDxTF6SnlRlsGQsr0KMb//EzIuaO5CDVcmTR9
amkajrrs

Re: [gentoo-dev] Projects and simple guides

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lance Albertson wrote:
> Luis Medinas wrote:
> 
>>On Sun, 2006-01-08 at 12:54 -0600, Lance Albertson wrote:

> 
> 
> I had thought about creating some kind of a site like this, but not
> necessarily in a wiki form. I don't like the idea of letting users add
> random docs. There's too much room for error and how do you deal with
> accountability? There has to be a developer who either will take the
> time to maintain it or accept responsibility for any errors it may have.
> I like the idea of having an area for herds to keep track of their
> internal thing, but I fear it will just end up replacing what the GDP
> (and our www site) does. Its too easy for them to just start adding docs
> there instead of on www because its 'too hard' to deal with guidexml.
> 
> If the issue here is guidexml, lets figure out the problem. We need to
> define what exactly is the problem before we decide on an
> implementation. Is the problem that there's no central place for herds
> to put updates/goals/etc? Is the problem that there's no easy way for
> users to submit new docs for people to use? Is the problem that guidexml
> hampers development time with regard to creating docs and you wish to
> have a better/easier way to create such docs?
> 
> Simply saying 'we need a public wiki' is great an all, but I'd rather
> ask 'What problem(s) does the wiki solve' before we even get farther.
> There might be better ways to solving the problem other than putting up
> a wiki.
> 

I think the big problem with certain pieces of documentation is the fact
that:
A) They change too often for any sort of static webpage.  If I'm writing
portage docs GuideXML is probably not how I want to go, the docs are
essentially fluid for most of the development time, they change often,
entire sections are ripped out and moved as I go.  In that type of case
any sort of static webpage is utterly horrible.  Rather go a wiki route
( or something similar ) to allow easy access & modification.

One could say, build the docs offline and then submit them later for GDP
to stick into GuideXML, but then only I can contribute to them ( myself
not being a developer ).  I guess I could host my own Anon-svn for the
docs while they are being written, but not particularly my cup of tea.

B) Non-developers want to contribute.  The devwiki currently doesn't
allow this, so I ended up asking Patrick at ge.org for an account to
start a wiki there, hoping eventually to move it somewhere else ( or if
events stay as they are, it can stay there )  Not many people want to
make diffs on guideXML ( I know I hate editing it ), and to fix a small
error or add a tidbit, no one wants to file a bug about it.

Those are the two biggest, docs change fast and non-devs want to
contribute to documentation in an easier way.

Problems with any sort of wiki solution thats Gentoo-wide comes down to
people editing projects they know nothing about, and managing
permissions should they be implemented.  I could probably do well
editing the Portage section, but perhaps no so much in any Hardened area
of the wiki.  Problem is maintaining that number of users/permissions is
a nightmare.

But those are the two biggest problems in my estimation.  No one wishes
to impede the GDP here,  Most of the docs I want to write are internal
portage API docs/FAQ/Howto's, and I doubt you will see users pounding on
the door to read them :)

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

iQIVAwUBQ8GBPWzglR5RwbyYAQINoA//U6CGfhwWcIKWOdr2UmbtarIbPoiFZ7Hc
2TcITLjnEqNFq28Va7cjKsS3Ef4BdoWY4UbhP+YCWPhqCPiFEOG4hEjsxeBQC4/v
7mvaC9EB2kVJRRZtl5WCtWeOzrsxc/ebtgOL1F8TL040AevD5BTYQKngS/9sEdl6
HyfY/i6Jbg5m8oFRCzA2vvzZAVHDPV92qxzKpfdfcAPC6FMHtdzimlASmcjjhAy2
FcUkYazzyy4888eO8tYZqpPX7ps8wUYVKfeLe55+EHpCC2jBp82NE++V2g9B0KcY
9T4yfELm1UXs1C4GDaukpqjrhj+vUSrf1/fK9k1ebmEaW29cEGATjYqCxKEXqQ8R
iCTgvpWDkc9yFRBLjscVW5ZS+jjfST/YlyCuLFNbFKoze1fyj6xqVVwMbnONNklO
X3979tn8bz377ZRNdbURkllc3Rgs0U6hHhowM917s2KULis4XnNhQ01DIomTH3cO
a0BVZo0tCYcNxPLqqlMD2xqTpgRrN7NPOOSTJIWQyWrzctnF2RaeznJSd96zzVPB
XDY/OsmRLulJIrAQcGQHpkYnhlk0Oy1kglWqXlvF8+Zf8O65qoFeSYvy2Ettuh06
jziyI4rDzfdDSgBmDX9jcShLoKIfoIxIGH6HvuphSXTIVqgDEr/63tEcYbXnomMv
qNdS/bUOXAg=
=rMLi
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: pending dooooooom of use.defaults

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


>>According to previous posts, USE_ORDER will be going away with
>>use.defaults, because that was really the only reason it was there in the
>>first place as there's no other sane ordering possible, if it is removed.
> 
> 
> There are other sane orderings possible, one being pkg:env:conf:defaults
> so that USE=xxx emerge -NpDuv world will show exactly what adding xxx to
> make.conf will do. I don't recall where I saw this, unfortunately, but I
> do know that some people actually use it for this. (Okay, maybe that's
> really the only other sane ordering.)

I would prefer to keep USE_ORDER for now, since I was going to replace
the "auto" dict with the "default-iuse" which means you can choose not
to stack these new flags.  Although it may be a hack, we have no better
way of managing use flag stacks at the moment.

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

iQIVAwUBQ8h0XGzglR5RwbyYAQJ5rRAAie3nIGMJQQQuy/tI9as+jniZ2BJ5fDSj
Z0sMS/qdPUItdfMQ6WLAthG7Y7RBA3u8rKuYMEDGUZ4ile7s43s7YPpCUXuwwmF8
a4uiX2TY16yE+1I9W7Agp1Bl3fmtL79vYg+39BQooFq2kmcWMFmTO+dE/jbO2bxI
2ttPVERaKHJn+Nu44otqQ84hQ2bQ2tJtLBlmUvCwz5RBVhN9Jj8G/3ZOc/hMuUDo
W/ytxHr4AJ/fpMa4ksRBI4jz2KjDbBurYH5tyI3ZRNqVGxzB4Oj4CzakRHevHGs1
h7NeJM2ZGI2r6K5iZlzPMUO2UWaO17KUo1C2w1Oa7Xyl5Zhd8UDphsf/xXCsr13d
Goyg/zwCJUIp3cSvp3ajQgxVCDQtHVcT4TKz/6ph7A/UTRn67Byl80cm8rHc7Xl+
Bi6X7UHPURzYEqxqshbfL0eEoOjqxqgQTl9i9lAmiKBIjlgPxH8DuxNOJx1JmcTV
tFAa3ktDRWJMjuSPN+9dn4P+9msdlhB1OVQtM9sEvb4Wu2TQzzPWijn42bsWLwxB
EBESmuXyycrwuaJD2YC+bdHsFEsdNssKeM1rU7w332fMefQu4ttXYaoAh2HtR9Pf
5lzB2aOp5iL9CCXL+SIQzsRcoIkSva+4xUGMgsRW4ulpVsy5sy9gOO5CHY0s4YjQ
jEiI5ljabUo=
=dbSA
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Find apps not ported to modular X

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
> Lares Moreau wrote:
> 
>> Could you post updates once a week(or two), similar to what [EMAIL PROTECTED]
>> does with the aging ebuilds.  I don't feel a play-by-play is necessary.
> 
> 
> I will be posting daily updates until it goes into ~arch, planned for
> Jan. 25.
> 
> Thanks,
> Donnie

Did you find another way to do those deps then?  We haven't released
2.0.54 with that fixed yet...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ9BVW2zglR5RwbyYAQKyuw//Y8+vkiigZLEYTUCwlb5cHw4XC+mO/ILb
YxLicKimZJYQvpBCSs++ngc6tmvwh8SL2KBnsgHR/tOq8zpt/8q9POwBiif4HFpp
GxhFjr9cnaiwLxWyr8iLKUGsoEibo/i7T8owBxovsJcVA9Y7PafAOPbDgVM6n6l3
ACcsqAskM+VifPG3DL68MhgmZthz+neNpdlUAmrRbZTFeK57zvD9FjWe8jApz2ZC
g61JWClt45Ev6eKvrju0IkgS0QygVcpeg1X+TRtrIf+UOlHKHomETgzgw5KEoL7Z
P2QpjVGfyFoBcjBcGMi/L/iS5sHC8nRDHMpcRpofx5LqW50XoaVEENialhZOw0aC
OYWfBzZm+Z8OO6A1VU+oKMNrXRfzZJz8JzICAxg1SnRyuGZbFnz3h0lLZG3YNCGk
K0dy15M+UsR0KyAVcF60jNdjhQCHTiGYkzCERwgSw0wYbw6Nkdg+3rnPCLK08O7Y
QO3bTU3opZcunnkMHU4X3LTD5NOp9tZKn9wvJQf/h+Q7MoPrJTWljWnwg4my27GG
J7abWdF8OvPFSNCXKH9+wKPz18AKcwY1UMkDSoNxMHXwczgPfX/LOTiuZa7wHoz+
ZDZ7BqjYhUTFdkwlVoHMKqAi+mLPe9zMqwwRU5J/fVCkJjsGwHJnDcG7G9x3zOwg
t48ogJg9Y3U=
=T9MO
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] emerge --update has problem with slotted packages?

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sven Köhler wrote:
> Hi,
> 
> so look at this:
> 
> # equery l |grep sun-jdk
> dev-java/sun-jdk-1.4.2.10
> dev-java/sun-jdk-1.5.0.06-r2
> 
> # emerge -up sun-jdk
> 
> These are the packages that I would merge, in order:
> 
> Calculating dependencies ...done!
> 
> # emerge --oneshot =dev-java/sun-jdk-1.4* -p
> 
> These are the packages that I would merge, in order:
> 
> Calculating dependencies ...done!
> [ebuildfU ] dev-java/sun-jdk-1.4.2.10-r2 [1.4.2.10]
> 
> 
> So portage does not list sun-jdk-1.4.2.10-r2 as an update - only if i
> specify it manually. That is - well - suboptimal. I'd like to know about
> any update within the same SLOT(s) as the installed package(s).
> 
> 
> Is this a known problem?
yes
bug 4698

> 
> 
> Thanks
>   Sven
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ9EHLWzglR5RwbyYAQK1fw//YTjW5U6qkmJLVIayNWbnj0Sx2XFZ4+GZ
cAMMKcNLxsxi7zt0Ja4EaSB35tZ7xMlSTi9feszYgzMlgFkdLLldJIJxPKtbIKQw
abZt3bE8KER7uLSdXWJyuyU79kfbZwLqnxxnUrQgonRw2mPNHwow/DJ5RTRQiq6+
yUh/P7VzLMnXtqYiV7Rp5zC6HVKV50PyfyYz+9FmEqehimaZQWViplLqYEX+Z/NR
3ZJz7lqK3v2IGj4xHBEySNnIiGD5vkPL/8VGACTOHypZGK51la0D4KMXKsTeEgmO
EgTfIGyHCNHs6V7mfkYRaZKy6LXlqnuF1Fqg2XYV3zu4Yzak2U/OuZRI5whcMUrp
/9Mr2+7FmSxr6mF+CIAipc1HHyOC9akNRNf2nWWBm4wRAcrdMuxa3HUfMSkqho53
m8V7AY+cskSZCox8gz3fhiyraQW8VMN1L/QWkGs2+xOK5LAvL5Krw9TfL4lisDbz
VFOyvDZtYbO00xk8iahvJEFBbMHeaXxFuVZWoXUwZn47onmVFrGF/VRLxlBqSFvu
aXDu7PeIHtjzke2wPgaUMV9LEPPw5938G584rAfSOJqTnbgj8Ia8UVqu7WhRaeuq
q7GcoCGeIHk3SKqxZmPv/h5qPQMj4MtznG8ccHtSiHpmWWVS85ZOAJKxpJ+4I7zh
ncpOdt2w3ss=
=0+sD
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] package.mask cleanups

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I figured it was time for a bit of cleaning... I ended up writing a
really crappy script for stable to do a check of whether package.mask
entries were really referencing anything or not.  Luckily Brian was able
to write a much better one for bcportage.

So the list of invalid masks is at [1].
The script source is at [2].

Please have a look and see if any of the packages are yours.  Entries in
 package.mask should have a corresponding ebuild in the tree somewhere.
 I'd like to see the number of entries chopped by a fair margin.

* Yes there is an exception thrown for kde-base/metadata.xml.  I have
nfc what the hell that is doing in package.mask, but I was told it was
already fixed ;)

- -Alec Warner (antarus)

[1] http://dev.gentoo.org/~ferringb/stale-p.mask.list
[2] http://dev.gentoo.org/~ferringb/stale-p.mask.py
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ9Y29GzglR5RwbyYAQIJRw//UhlSU/KC1qyZKF8l51k6I+fVs8Bc6nz+
ZJ4IIjk1MCuHBfXWpfA0G9mpPrlxTvwZoSUW1DtRIH8GimB9aeRjjOi3V+7ph6+M
SaWYgYCGmDhvk3TkbrZWHT56hIa5EJXpe7QswbjpOMA3Jtl7X/uC5h5VbeMEog2a
E8fcQvO0K9lrxWEE/Rr+Ub+StigvRvtZjV1hxCr+0Hh1kHPWD4fb44z0BCTMha+m
HeK2i/bFCgAzHMA+5dFUzcBnmXALMDphVtq1jPfVAiURBcnBhUqnIYp/y5Be7e8F
6sHd+iGVZiFt7EDOnzA4NFSphpf/rTMDRpnMa6oTlOXml9Ai7w4oJxzskI7+uBIr
zMsprv9WvLIbyDR34//1WjPoPkNuDH1X4wG+E92tBjA/qWsH4xU4A4PvUkrm/BpA
/MqweGM5nMD5SMST8/UlApr9dnmzm6G0Hs3ZnGW1tTVbJDJ05p5+bxDl6XgC+023
wFULR6FGgQO3HG+txiyCt0AHd2PrY2q6l1wOSZm3dd0nYmPIC7yOdDCBSC8KAra9
Fsw1+6UFWtZcQY43CDljr5bCY8IVD80OPy31S8lo4Lrg9OaQOwvCmfoIWi3tnsLy
XhbNa2RehILTyLbpx8Rmf2ihe7yZkPfqX3gXbMpWxWq8tARA3dmrJZEyFnKbB1cC
F7hsH+G4ToY=
=cIlU
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] package.mask cleanups

[Alec Warner]

Marius Mauch wrote:


On Tue, 24 Jan 2006 09:17:24 -0500
Alec Warner <[EMAIL PROTECTED]> wrote:

 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I figured it was time for a bit of cleaning... I ended up writing a
really crappy script for stable to do a check of whether package.mask
entries were really referencing anything or not.  Luckily Brian was
able to write a much better one for bcportage.
   



Why are people so obsessed with cleaning package.mask all the time?
Sure makes sense to remove three year old unused entries from time to
time, but not everything that isn't actively used is invalid
automatically (quite sure that kde-3.5.1 stuff is a preventive mask
for example).

Marius

 

I was attempting to be helpful and filter out valid packages from the 
list.  I could have been an ass and been like "Yo I think package.mask 
is bloated go clean it" and not given a list at all, but that is not 
very useful.


I never said ( or meant for ) everything in that list to be cleaned, and 
perhaps I should have added a "use your own descretion" deal.  The goal 
was to have a list that someone can quickly glance over and be like "hmm 
I maintain one or two of those lets check it out".

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] package.mask cleanups

[Alec Warner]

Marcus D. Hanwell wrote:


On Tuesday 24 January 2006 14:17, Alec Warner wrote:
 


I figured it was time for a bit of cleaning... I ended up writing a
really crappy script for stable to do a check of whether package.mask
entries were really referencing anything or not.  Luckily Brian was able
to write a much better one for bcportage.

So the list of invalid masks is at [1].
The script source is at [2].

Please have a look and see if any of the packages are yours.  Entries in
package.mask should have a corresponding ebuild in the tree somewhere.
I'd like to see the number of entries chopped by a fair margin.

   

All of the KDE stuff is the upcoming 3.5.1 release which we are working on in 
p.mask until the official release. There *are* ebuilds for all this stuff in 
the tree right now. So that has chopped the number of entries by a fair 
margin, but for the script to be useful it should be able to detect they have 
valid ebuilds.
 

It may be Brian hadn't cvs up'd lately, I am not sure.  On my box I 
don't see any kde-3.5.1 ebuilds for some random items that I plucked out 
of the list (qtsharp fex).  Regardless, if it's a preventive mask or 
whatnot I'm not going to make you take it out or anything.  The list is 
only meant to help spot old packages, or pkgmoved packages or whatnot.  
If you as the maintainer know the mask is valid, then don't touch it.  
If you as the maintainer know that package is long dead, then remove 
it.  Thats basically it.




--
gentoo-dev@gentoo.org mailing list

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] Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

MIkey wrote:
> 
>>As for the stage 1 problems you described, this is exactly what i
>>already told you in the same thread. Supporting stage 1 costs extra
>>resources, this thread is a perfect example of it.
> 
> 
> And this is the primary point I am arguing.  I keep hearing it, over and
> over.  My testing leads me to a much different conclusion, I offered
> details describing why I reached my conclusions.  It is the developers that
> decided to stop supporting the stage1 installation method, without asking
> users.  I am asking you all to justify that decision, preferrably with
> facts.  I am claiming that that the stage1 installation method is in fact
> much easier, quicker, cleaner, and more dependable.  I have still not heard
> a reasonable argument to refute that basic assertion.  I have heard vague
> claims but no quantification.
> 
> I even went as far as posting patches to fix some of the major bugs that
> have gone unnoticed for, how long?  Which is, in effect, me offering
> solutions.  I have also posted proposals with patches for simple,
> incremental changes in portage that would make gentoo more palatable in an
> "enterprise" environment.  
> 
> So far it has been a fairly fruitless endeavor...
> 

Maybe you think fixing a circular dep is easy, I know I do.  But when
Joe Shmoe think it's OMG U63r 1337 to install gentoo using a stage1
because it makes his system so awesomely fast ( hence, The Conrad
install on the forums, heh ;) ) and he has no ing clue how any of
this crap works, and you tell him to fix the circular deps.  He isn't,
he is going to file a bug, which will be marked WONTFIX.  We know there
are circular deps, it's unavoidable in many situations.

The problem with a stage1 as *I* see it, is it that it's a grab-bag
system.  A half-built system that some user, even following the official
docs, can fuck up in a myriad of ways, just by turning on use flags.
USE flags that that enable things that cause dep circles, enabling
things that cause other things to not compile because the stage1 ISN'T a
full system.  Our deptrees aren't complete, they make assumptions about
the current system, and those assumptions generally are not true on a
stage1 or stage2 system.

There is no way around this, in my reckoning, without giving the user a
complete system to start with.  Then they can't trigger silly ass
circular deps, because guess what, the base system is already installed!
  If openSSL depends on perl and perl depends on openSSL, who cares,
they are both installed, not a problem!

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

iQIVAwUBQ9kB82zglR5RwbyYAQKvZBAAk6NARUbJUy4jnwrGeA2Skod+zduvvKKH
a1/JDbDYTa/zB1zgxyLp28DAT8SBdCjuZ3oaA39txI/ZBgt7QvdtdmrHfWYKOXh2
EI2lGKXsc7f5Boo4SVaMPKYhUcUzLO2c7wuTMTylpL5VHX+JhdFBShCXD6s5CQ3x
glhWWnLBLCAbY0h3PYMwTJKgW+FeD7PMF67RBasYFTxZE5rNFMBv9gOSvZ6Da8oY
mJjBCbXIILcSYHKqPFw7nSHKm9JCRJUAV/kls0GoxqzOEFt5DJyCazPBHAMjflT4
Uw2n0JGIQVy+OREV1iho4S5SjBwLcSeDhs0kXPFL0Kp7GxBjSKO3l5PITp7iXe2F
ubNi5quuG5ElMetPK9bRk+V1m3NYZB+y1m+Ui5ZhsbiRwIvkrrUJbej0gd+SV6Aq
Y9+jAACRfnWFFElSTTkeg5PFrTX3Pq0cuT/XSmt3qFxWwUfqVKNbG3UkIlD05XeQ
VjM/oOaGdw/sWRahzvh2mFKRvRuHESRrByRBjRRqaypbu0lN7MfDwYqXLct2rc89
qFJXNWWisX9vxUDnxZ3OkHZJBQwS+VLy/oL1crhpBH0l45UR/Fzb8l2z5GQfxrrS
88EB7mby4+Owf2ZAgcbAYWOBya2/g9ZbAi/08xv9bYjKZQbyDya8iaEXgzRz3Mui
M0PpX65pkFY=
=xbGa
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Repoman and his automagic

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There are a couple of bugs against repoman that request repoman detect
and do things for the developer.  The two cases are:

repoman does not auto-commit new license files[1]
repoman should cvs add files/ if it isn't already[2]

I personally am against both of these, mostly due to their automational
nature.  In both cases repoman should report that they aren't in cvs, so
that it can generate a warning ( it does this currently for files/ but
no so for licenses ).

Part of me does not want repoman to do automated tasks for developers,
and part of me wants a set of *well written* tools to aid developers in
their tasks.  I mean when one commits say, all of kde, you don't want to
sit there and type in all that crap, you'd rather script it.  However, I
don't see it as repoman's job to do that for you.  I would like others
opinions on this though.

[1] http://bugs.gentoo.org/show_bug.cgi?id=30235
[2] http://bugs.gentoo.org/show_bug.cgi?id=32529
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ9qzgWzglR5RwbyYAQKJVg/+O+6YHf24IwC20lNDd53TvPxpA3MSBtM8
1I1mpjHMkvjhG7ewqVjF/sjpO98ImUGUtGbEehSDkj3s6ap40sT0BxCPoCb4VfAe
6EhJzLTYhLumBYmBB8a2lf/JVRCWBtVGp+kJ7tmUPwruL6ldt6wjmO/MeWUoPvJB
PLcPejOzb8PIKNdzl/Difuxii+K5yq2q39ycPaKrBS4E7U9K6WP6zuJMdN353wlJ
0qi9sS95XQK+jf6NmH9fpYloLKLzYngfTtM4NjJ4shs7H/aGe4QAxIPlWGC2QL/s
N30A4v8ELeUwSMWpMOqmuqfGf1ZAe0zvRvq1tr+5lnrYlCMBLO1i7vI2SPU+VmZ6
1HVCK2QdzlRFBakASBObRnVJPJ2LXtOQnAxtpg54YafprZKk4/ksRJgtd7YuDmre
phU8iJcN8l43f37UeCo2SnHIlnCWwckc6VOTS7jwPydhqTqX1weI1af0oFqzimUL
oy1/tKgRdsAM+HE+P+xIvIs3ktvrQKxn29vTXRZY2PhdAJet46Uoeo/tit6I20gz
OyWpB9O7JWi4AVUdYIcH9h00XgTc6VQW215WD2YGzrDzGf8SResWazv0Zbjx3hfh
cEzrjDr/9MyUbuZctNWrKPkuvWBE1b1mZEaG8jGUwUjSoOC0dJh9UnI8wg5ojb8+
YxFDZ/WB72g=
=C/C/
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Make logrotate a global USE flag?

[Alec Warner]

Marcelo Góes wrote:
> It seems there are some ebuilds with a logrotate USE flag:
 
> Perhaps it should be a global USE flag?

We have discussed this "fairly recently"[1] so I'll post the link to
save everyone the hassle.

[1] http://marc.theaimsgroup.com/?l=gentoo-dev&w=2&r=1&s=logrotate&q=b

> 
> Marcelo
> 
> --
> Marcelo Góes
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [OT] Test

[Alec Warner]

I've been having a crapton of problems with sending to this list, just
making sure I got them all resolved :)

Sorry for the Spam

-Alec Warner


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] IUSE and LINGUAS?

[Alec Warner]

Mike Frysinger wrote:
> On Sunday 05 February 2006 09:51, Diego 'Flameeyes' Pettenò wrote:
> 
>>On Thursday 02 February 2006 20:55, Ciaran McCreesh wrote:
>>
>>><[EMAIL PROTECTED]> wrote:
>>>| Yeah that would help. But in the mean time what should we do?
>>>
>>>What you should always do. Do the right thing, even if repoman
>>>disagrees.
>>
>>Seems like repoman is actually our boss in this case, so I was forced to
>>put the linguas_* to use.local.desc.
> 
> 
> that's retarded, please remove all such linguas_* crap from use.desc files
> -mike
> 

There is nowhere else to put it.  It was suggested on bugs to put a new
directory in $PORTDIR/metadata/desc/ and have the $USE_EXPAND.desc files
in there for portage/repoman to read in.  I don't have a problem with
doing that but would like feedback on it before jumping right in.

Obviously the QA team should be aware of the issue with USE_EXPAND and IUSE.

I don't want to rush this, is my point ;)

-Alec Warner



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables

[Alec Warner]

Grobian wrote:
> Please find attached GLEP 47: "Creating 'safe' environment variables".
> 
> The GLEP is a Gentoo/Alt initiative.  Constructive comments are welcome.
> 

> 
> The variables ``ELIBC``, ``KERNEL`` and ``ARCH`` are currently set in
> the profiles when other than their defaults for a GNU/Linux system.
> They can as such easily be overridden and defined by the user.  To
> prevent this from happening, the variables should be auto filled by
> Portage itself, based on the ``CHOST`` variable.
> 
> A map file can be used to have the various ``CHOST`` values being
> translated to the correct values for the four variables.  This change is
> invisible for ebuilds and eclasses, but allows to rely on these
> variables as they are based on a 'safe' value -- the ``CHOST`` variable.

Assuming the CHOST variable is 'safe' is not a good thing, users can
over-ride this variable.  Can you specify some behavior when it's set to
something bogus ( invalid form ) or something thats not in the mapping?

> Ebuilds should not be sensitive to the keyword value, but use the
> aforementioned four variables instead.  They allow specific tests for
> properties.  If this is undesirable, the full ``CHOST`` variable can be
> used to match a complete operating system.


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: /etc/rc.conf

[Alec Warner]

Forrest Voight wrote:
> What happens if two env.d files set the same variable?
> 
You write an eselect module to choose between them :)

> On 2/13/06, Olivier Crete <[EMAIL PROTECTED]> wrote:
> 
>>On Mon, 2006-13-02 at 16:51 -0500, Forrest Voight wrote:
>>
>>>What about env.d? Gnome could install and env file that by default
>>>sets XSESSION to gnome.
>>
>>Can't do... you can have gnome, kde, xfce, etc all installed at the same
>>time.
>>
>>

-Alec Warner


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] "dopython"

[Alec Warner]

So "dopython" is old and sucky, so we want to remove it.  A cursory grep
of both the main and alt trees shows no one using it, but I figured I'd
send mail anyway.  If you are using dopython, you should probably be
using python -c 'foo' instead, unless for some reason that isn't
possible ( PATH issues? ).

If anyone has any reason to keep dopython around please voice your
concerns now, as we will probably be killing it in the next bump of 2.1

-Alec Warner


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner]

Ciaran McCreesh wrote:
> 
> | > * In the case of disagreement on policy among QA members, the
> | > majority of established QA members must agree with the action.
> | 
> | Perhaps pushing it to an open forum on -dev/-core for consensus works
> | better here?
> 
> The problem with that is, it usually ends up with too many pointless
> comments from people saying how things could be fixed in the distant
> future, or whining that it isn't explicitly forbidden by policy on
> situations where the screwup was too weird to be documented previously.
> 

The rather blunt point here is to limit the power of the QA team itself.
 The QA team decides what new policy to enforce, and when the QA team
can't agree "the majority of established QA members" must agree to
action.  Which is in itself rather vague.

Perhaps "The majority of active QA members, where an active member is
designated as 'a QA member who responds to the corresponding mail to the
qa'".  This would be similar to how the recent QA lead was chosen, mail
was sent, yay's and nay's were collected from those who cared, and then
the decision was made.

This is meant to prevent the case where the QA team ( or a subset; "the
established QA members" ) decides to make unilateral changes to the tree
( or large subset thereof ) without even necessarily talking to the
affected developers.

While you may not think that soliciting comments is useful ( and in some
limited cases I would agree with you ) giving people the opportunity to
comment also means you just covered your ass, in terms of people going
"where the hell did that come from?"

-Alec Warner


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] SRC_URI component naming collision

[Alec Warner]

Daniel Ostrow wrote:
> On Sun, 2006-02-26 at 22:17 +, Stuart Herbert wrote:
> 
>>On Sun, 2006-02-26 at 17:02 -0500, Daniel Ostrow wrote:
>>
>>>That would work for fetch restricted packages, not nomirrored ones.
>>>
>>>--Dan
>>
>>/me nods.  That's what we'll have to do.  Unfortunately, it leaves users
>>with a worse experience than before, but until I can find a way to reach
>>the QA team and help them see my pov as the package maintainer, what
>>else can I do? :(

It's only 'worse' than before if you assume that all your users read the
documentation, otherwise they end up futzing around with their distfiles
trying to figure out why the checksum is incorrect.  This way the ebuild
will die right off and the information is presented at the same time.
They can go get the ebuild and rename it ( hell you can even provide
them with the wget command to do so ).  As such, glad this is resolved
with at least some agreement on all sides :)

--Alec Warner


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] bug #20201 and bbapm

[Alec Warner]

bbapm has been masked due to no one responding with anything useful to
last rites e-mail.  It will be punted in 30 days.

-Alec Warner


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bug #20201 and bbapm

[Alec Warner]

Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner <[EMAIL PROTECTED]>
> wrote:
> | bbapm has been masked due to no one responding with anything useful to
> | last rites e-mail.  It will be punted in 30 days.
> 
> No no no. Do this properly. Clean up *all* the broken blackbox applets,
> not just the one that has someone whining on a bug report. There are at
> least two in the tree that're more broken than this.
> 

I am not the blackbox maintainer, nor do I wish to be.  In this
particular case I'm just tired of hearing Jakub and you go at it, and
since no one else acted, I chose to act.  Sorry if you thought otherwise.

-Alec Warner



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner]

Stephen P. Becker wrote:
> Grant Goodyear wrote:
> 
>>Ciaran McCreesh wrote:
>>
>>>My point is that that's a nasty QA bug that's relying upon input from
>>>Stuart to be fixed. Whilst that one's still alive, I'm not going to go
>>>around filing more similar "breaks non-interactively" bugs because the
>>>discussion will just get repeated over and over.
>>
>>Huh?  I just read through the bug, and it actually appears to be
>>resolved pending Chris' testing w/ the needed USE flags added to the
>>various profiles.  I'll admit that the fix is inelegant, but I'm missing
>>where it's waiting upon Stuart for additional info.  Am I missing something?
> 
> 
> Yes, you are missing that the bug really isn't fixed.  There are still
> USE combinations which would be otherwise perfectly valid, but which
> cause php to fail to emerge, thus reaking non-interactivity and forcing
> people to (ab)use /etc/portage/package.use to get things working properly.
> 
> -Steve

The bug is about *default* use flags breaking interactivity.  There are
donzens of packages that die in pkg_setup if incorrect USE flags are
sepcified, because use-dependencies are not implemented.  I don't
believe anyone is trying to enforce interactivity in that case, because
as far as I'm aware there is no workaround present.

-Alec Warner


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner]

Ciaran McCreesh wrote:


On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
| OK, so kernel-2.eclass is abusing the slot as well, go scream on
| kernel devs.

No. kernel-2 installs sources, not an actual package.

| > | Yeah, it checks for that since that's the way the eclass is
| > | designed. You can't declare a slot in a kernel ebuild either.
| 
| > One is a design flaw. The other is not.
| 
| Ah, tell me about the dual standards :P


Not dual standards at all. There's nothing wrong with saying "don't do
x unless you're doing y", with appropriate justification.

| > | Well, starts to be boring - so, either come with something valid
| > | from QA standpoint or stop now.
| 
| > This is a valid issue from a QA standpoint. This is also why I'm not

| > going to waste my time doing a proper list -- rather than addressing
| > issues, they are being passed off as irrelevant or even features.
| 
| Next time, rather think a couple of times up before claiming

| something very broken on a public mailing list where you have no
| proof for such claims. Will be immensely helpful for everyone
| involved.

No proof?

Sheesh, you'll probably claim that this isn't broken next too:

   if [ "${IS_UPGRADE}" = "1" ] ; then
   einfo "Removing old version ${REMOVE_PKG}"

   emerge -C "${REMOVE_PKG}"
   fi

 

Semantics of the logic aside, calling emerge from within an ebuild is a 
BIG nono.


-Alec Warner
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner]

Mike Frysinger wrote:
> On Tuesday 28 February 2006 16:02, Jakub Moc wrote:
> 
>>28.2.2006, 21:39:43, Mike Frysinger wrote:
>>
>>>whats your point ?  if an ebuild author wants to control the SLOT, then
>>>they should be able to without having an invalid warning issued on the
>>>subject
>>>
>>>considering the nature of the warning, it should be trivial to make it
>>>into a proper QA check by having the class see where files were installed
>>>and then warn/abort if certain conditions are met
>>>
>>>there's no reason for the user to see this crap
>>
>>Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
>>eclass inherited illegally crap and a couple of others - this isn't going
>>anywhere.
> 
> 
> unrelated ... that is a portage limitation that has deeper work going on 
> around it to resolve the issue properly ... this is an eclass limitation that 
> can be resolved now
> 
> 
>>You are trying to solve something that noone ever complained about. Why not
>>rather solve stuff like ebuilds that depend unconditionally on arts, but
>>because they inherit kde eclass they get bogus arts use flag from the
>>eclass. This is an issue that's truly confusing and that people are filing
>>bugs about. There's the difference between doing something useful and
>>wasting time on an artificially invented issue.
> 
> 
> right, so from now on people shouldnt bother fixing issues until a bug is 
> filed, that way we know someone actually cares enough to have the issue 
> resolved
> 
> today's lesson: proactive QA is frowned upon, it's only a bug when a user 
> files a report at bugs.gentoo.org
> -mike

Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see
bugs filed in almost all circumstances.  If QA and the maintainer can
fix stuff without bugs, thats cool, especially for trivial matters.  If
QA and the developer aren't getting along on a specific issue then there
is no reason NOT to have a bug open.

Otherwise you get circumstances that were also discussed, such as "I
told the maintainer in person over a year ago..." which may in fact be
true, but people forget things and make mistakes and now you have
nothing to point at for proof of inactivity except a vague statement.
Better to cover your rear and be able to point to a year old bug with a
solution attached, and be like "look there is a bug and a fix and no one
did jack squat."  Essentially you have a case for any sane developer to
agree with.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] QA Roles v2

[Alec Warner]

Mark Loeser wrote:
> Here is my updated version after some feedback from people:
> * In the case of disagreement on policy among QA members, the majority
>   of established QA members must agree with the action.

What is an "Established QA member"?

> 
> 
> I guess this won't be reviewed by the council for another month, but I'd
> like to get all of the debate out of the way now.
> Please lets keep the discussion on topic and constructive.
> 
> Thanks,
> 


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] QA Roles v2

[Alec Warner]

The whole argument here is that bailing out with conflicting use flags
breaks some extensive compiles. So you suppose users will be sitting in
front of their monitor and stare on the screen waiting for a scary warning?
No, they won't. And even if they were, how exactly is that warning better


No they won't, but elog in portage-2.1 will gladly send them a message 
via whatever configuration they have about the warning that the ebuild 
produced.


-Alec Warner
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Change layout of distfiles

[Alec Warner]

Michael Renner wrote:
> Hi,
> 
> as suggested by Mike in http://bugs.gentoo.org/show_bug.cgi?id=123335,
> here's my proposal for changing the layout of the distfiles tree:

> Introducing an additional directory hierarchy should fix this, and is
> the common solution for this problem for various projects, be it debian
> [1], cpan [2], slackware [3], etc.
> 
> 
> One migration scenario for a better future:
> 
> Create subdirectories named after the first letter of each file and move
> the files in their respective directories.
> 
> Either sym- or hardlink the files from the current distfiles
> root-directory to the specific directory where they reside in. (Check
> with the mirror admins first (depending on the chosen linktype) if rsync
> hardlink support is enabled or their web/ftp servers allow/follow symlinks)
> 
> Adapt the build scripts so that they look for the files in their new
> location.
> 
> Change the scripts which fetch the files for distfiles so that they save
> them under the new location.
> 
> Wait a few weeks... (months? years? decades?) until the last user has
> updated and/or a clean upgrade-path exists, which doesn't rely on the
> old file locations.
> 
> Drop the sym/hardlinks.
> 

Is this plan for server side only distfiles, or do you want
/usr/portage/distfiles/{a-z}/ on the local system as well.  If that is
the case the answer is probably no.  We've been asked in the past to
implement a DISTFILES_PREFIX type system which would work in a similar
manner, and it really only complicates things.  Is there any needed
performance benefit out of the current scheme?  Can you give some
numbers as to how much this will help the average user?

I believe the Infrastructure team also doesn't want to change the
layout, but I'll leave it up to them to comment on their own policy ;)

> best regards,
> Michael Renner - admin of gentoo.inode.at/rsync1.at.gentoo.org
> 
> [1] http://debian.inode.at/debian/pool/main/
> [2] http://www.slackware.at/data/slackware/slackware/
> [3] http://cpan.inode.at/modules/by-authors/id/


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] QA Roles v2

[Alec Warner]

Paul de Vrieze wrote:

On Saturday 04 March 2006 15:45, Danny van Dyk wrote:


Just to throw in my 2 cents into this discussion: I'm all against
die-ing during the update process. However, i think that stopping
before the update process would be the best solution at hand. I'd like
to propose the addition of a dedicated USE conflict detection to
ebuilds which need it.



Perhaps it would be possible to tell portage to have a 
"build-what-you-can" mode, where it tries to build as much as possible 
after a compilation failure. At the end it then can report on the 
packages that were not compiled.




We've had a bug for this for years, no one has implemented it.

Most of the Portage developers would prefer USE-deps to anything else, 
as this is what that is really trying to cover.  The only alternative 
I'm willing to support at this time is moving the death ( per 
Kugelfang's suggestion ) to right after depgraph building.  Thus a user 
will find out right away that their USE flags conflict and need to be 
changed.  Even with USE deps, there cases that just aren't resolvable, 
they are "unsolveable" and I think coming up with some sort of structure 
to inform the user of this is a good idea.


However we have talked about this and the DEPEND syntax doesn't seem to 
cut it for showing USE conflicts and dependencies.  Certainly right now 
the resolver has no metadata whatsoever to work with, so it can't even 
tell if a specific set of USE flags conflict or not, if we provide it 
with that information it can at least die during depgraph creation 
stating what the problem is with the depgraph ( getting closer to having 
actaul buildplans... ).


-Alec Warner
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Change layout of distfiles

[Alec Warner]

Michael Renner wrote:

Kurt Lieber wrote:


If we can come up with a seamless, painless transition process, great,
let's make it happen.



 From the _MIRROR_-side using hardlinks should be fine enough, we'd just 
have to ensure that every mirror uses -H (preserve hardlinks). And for 
the mirrors not using -H this will just result in increased traffic and 
diskusage (42GB at the moment, might hurt a bit ;) ). Shouldn't be a 
problem though ensuring that every mirror uses -H (and I think they 
already do, since we already did hardlink magic when moving old releases 
to historical)


I guess the more complicated part will be adapting the ebuild system to 
look for/store the files in the new location.


Taking the earlier comment ( changing files only on the mirrors ) there 
are no portage changes that are technically required.  However, you'd 
need to change about 1 ( random number I pulled out of my ass, but 
there are many affected ) SRC_URI's to point to the new format, or 
produce some sort of hack that translates between the two, and I 
wouldn't be to fond of the latter effort, mostly because it would 
probably rot in the tree for way too long ;)


And you need to modify policy for placing files on the mirrors, but 
thats not a portage problem either; from the portage POV the change is 
relatively seamless.




best regards,
Michael

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Change layout of distfiles

[Alec Warner]

Simon Stelling wrote:

Daniel Ostrow wrote:

Hrm, /me thinks you are missing something there, almost the entire 
tree doesn't explicitly state the mirror://gentoo SRC_URI, portage 
handles that automatically. That being the case portage would have 
change so that the automatic lookup was mirror://gentoo/${firstchar}/. 
So that is at least one portage change I can think of being required


1925 ebuilds ( with a hacked up SRC_URI checking script )[1] 
URI_check.py "mirror://gentoo"





Huh? What does it state then? AFAIK ebuilds should ALWAYS use the 
mirror:// URI when possible, and since this change is only affecting our 
own mirrors, it is always possible.


Sure I can still see your point about needing to manually change the 
packages that do explicitly state mirror://gentoo in their SRC_URI, 
but given that you would have to do the above anyway



Huh?? My point was that we shouldn't have to change all those ebuilds 
but instead just changing the mirror://gentoo-mapping.




See if we do it the ebuild way we can filter via EAPI.  The ebuild has a 
EAPI=2 SRC_URI, but portage is only EAPI=0, then the ebuild is 
automagically filtered; as opposed to the ebuild failing miserably. 
It's getting close to the point where we can finally leverage EAPI to 
push features out faster because backwards compatability is maintained ( 
for portage ).  Infra is still screwed essentially doing 2 
implementations until such time as the old one can die.


I'd prefer the mirrors not be special cased in a mapping since.  URI's 
are URI's are URI's...


-Alec Warner


-
[1] dev.gentoo.org/~antarus/URI_check.py

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)

[Alec Warner]

On Monday 06 March 2006 17:39, Paul de Vrieze wrote:


I guess some advanced /etc/portage/bashrc magic isn't enough for you?
There are some neat tricks you can play with that.




While magic is great, it is also not for all end users.  bashrc magic is 
not officially supported by the Portage team, so while it's a powerful 
tool for some users, it's also quite volatile in terms of how it is 
sourced.  It should not be depended on.


-Alec Warner
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] x86-fbsd keyword in main tree?

[Alec Warner]

Diego 'Flameeyes' Pettenò wrote:
> Okay, solar asked me yesterday, and I think this might be the good moment to 
> start this out.
> Right now the x86-fbsd keyword is not being used in the main tree, and the 
> whole Gentoo/FreeBSD is handled in an overlay, sharing the ~x86 keyword with 
> standard Gentoo/Linux.
> Unfortunately this has a series of drawbacks:
> 
> - we need to package.mask packages that could just not have ~x86-fbsd keyword 
> at all (because being linux specifics);
> - we can see the last working version of a package go away because later 
> versions are ~x86 and they don't work for us (old flex might have been an 
> example but that's now fixed; findutils can be another example);
> - we cannot make sure that the deptree is satisfied.
> 
> To bring ~x86-fbsd keywording in main tree, we mainly need to move a true 
> profile in the tree, not a dummy one, mark it as indev and start the 
> keywording. (I've already cleaned up the default-bsd/fbsd profile so that it 
> does work with the current base/ profile.
> As long as virtual/libc is not in the dependencies, it shouldn't trigger any 
> kind of problems to leave the sys-freebsd category in the overlay, if we 
> really need to start needing that, I'll see to make the ebuild quality level.
> 
> It's not going to be a quick thing, as I'm mostly alone with Gentoo/FreeBSD 
> right now (help is always welcome), but times are mature so that I can 
> provide a decent experience to users.
> 
> Can anybody name a showstopper to this?
> 

Yes, x86-fbsd is not a 'working'[1] profile keyword.

[1]The same reason why ppc-macos has some weird and potentially
dangerous profile tricks to keep their systems running.  We are looking
at adding PROFILE_ARCH, or use.force to the profiles to remedy the
situation.  Basically portage expands $ARCH into use ( so x86-fbsd has
ARCH x86, and would get "x86" in use, which IMHO, isn't that horrible ).
 However, you also don't get x86-fbsd shoved into USE, so you have to
inject it elsewhere, and then users could do something stupid like
-x86-fbsd in make.conf, and unset their ARCH flag = bad.

PROFILE_ARCH='x86-fbsd' -> would get forcefully injected into USE, OR
use.force: x86-fbsd -> a use flag that isn't killed by -*.

Whatever the fix is we should be able to make a 2.0.54-r1 release with
it, still need to talk to Zac, if anyone has any comments on this, now
would be the time ;)

-Alec Warner



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] x86-fbsd keyword in main tree?

[Alec Warner]

Stephen Bennett wrote:

On Thu, 09 Mar 2006 10:20:33 -0500
Alec Warner <[EMAIL PROTECTED]> wrote:



Basically portage expands $ARCH into use ( so
x86-fbsd has ARCH x86, and would get "x86" in use, which IMHO, isn't
that horrible ). However, you also don't get x86-fbsd shoved into
USE, so you have to inject it elsewhere, and then users could do
something stupid like -x86-fbsd in make.conf, and unset their ARCH
flag = bad.



The profiles currently in the overlay set ARCH=x86-fbsd. Whether that's
right or not is another debate, but it invalidates that particular
problem.


The problem being that your ARCH (architecture) IS x86, just as 
ppc-macos's architecture is ppc, and there may be patches that apply to 
both sets equally, and conversely things that apply to only linux.


Now if GLEP47 is approved, then the point is moot ( x86 implies 
x86-linux, or whatever the corresponding keyword is ).


If this is the tract we are going to head in I need to change the docs 
to reflect what ARCH really means.


At present in man portage:
ARCH   Architecture type (x86/ppc/hppa/etc...).
PROFILE_ARCH
   Distinguish machines classes that  have  the same ARCH.  All 		 
  sparc machines have ARCH=sparc but set this to either 'sparc32'

   or 'sparc64'.

Ciaran had suggested pushing PROFILE_ARCH into USE, although that 
implies that x86? = ARCH x86 and not necessarily 'x86-linux' since 
anything running on x86 would have ARCH=x86.


While I think the above is the 'proper' way to do things, it would 
require a massive migration of ebuilds in the tree, and no one has 
volunteered for that task, as well as making sure anything that uses 
'x86' in this case runs on everything running on x86..it becomes quite 
complicated, even if it is the most flexable.


Regardless, I'd like to reach a conclusion about this, was GLEP 47 
submitted to the council for the next meeting?


-Alec Warner

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] USE_EXPAND in IUSE ( again )

[Alec Warner]

So folks seem to want things both ways.

Some people believe that USE_EXPAND'd variables are private:

|| I have yet to be enlightened on any merit of USE_EXPAND is so perhaps
|| you could explain as to why there should be
|| user-configured-yet-undocumented options for ebuilds? More precisely,
|| how should they be documented if not via use.desc?
|
|1. Because for things like LINGUAS, there are arbitrarily many legal
|values, and documenting them all and keeping the list up to date would
|be extremely difficult.
|
|2. Because USE_EXPAND is used for special USE things like arch and
|userland, and because we undocumented the special arch USE flags
|because they're not user settable.

That leaves a couple of things, first off, how do users figure out that
a particular setting affects an ebuild.  If I have no VIDEO_CARDS set,
for example, how do I as a user figure out that that the new modular X
ebuilds actually use VIDEO_CARDS?

Secondly, some USE_EXPAND'd things are user-settable, and some are not.
 Arguably, some may belong in IUSE, others are just not appropriate (
VIDEO_CARDS and LINGUAS both being rather large and difficult to maintain.

The current state of things is that:

1.  Repoman complains to developers when they use USE_EXPAND in IUSE and
there are not entries in use.desc  This check for USE_EXPAND'd variables
can be turned off, if the community feels that USE_EXPAND should remain
undocumented.  Or we can commit Diego's patch that reads USE_EXPAND
descriptions from $PORTDIR/profiles/desc/USE_EXPAND.desc

2.  Portage complains about USE_EXPAND flags not in IUSE when they are
used, because they are not user settable.  This ties into the above,
either USE_EXPAND flags modify ebuilds publically (IUSE) or they modify
it privately ( no IUSE ).  I don't really want to see it both ways, as
we then need a constant list of USE_EXPAND flags that are supposed to
set off warnings versus those that don't.  Or we just kill the warnings
for any USE_EXPAND variable, which I hope the QA team will comment on.

3.  Jason Stubbs has commited code in portage 2.1 to show USE_EXPAND
flags in output.  I'm not sure who likes or dislikes this, but depending
on that outcome of this discussion, that code may need to be modified.


Conclusion:

Either USE_EXPAND always goes in IUSE, or USE_EXPAND never goes in IUSE.

If you want USE_EXPAND that sometimes goes in IUSE and sometimes doesn't
you better have a good plan for keeping those lists of proper USE_EXPAND
flags and improper flags in sync.  I mean I'd love to do it that way,
but I'll bet those lists get old and nasty and we will have people
complaining about QA warnings that they thought were fixed or that there
were no QA warnings when there should have been...etc..

-Other ideas are always welcome; I'd prefer to get this solved soon.

-Alec Warner


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Making the developer community more open

[Alec Warner]

m h wrote:
> I'm not a gentoo dev (just a satisfied user), but I lurk on this list.
> 
> I was at PyCon last month.  I would estimate that about 40% of the
> people there ran linux on their laptops.  The most popular distros
> were gentoo and ubuntu.  (Not this is not a scientific study, just my
> observations from talking to people there).  While I was there the
> person next to me starting hacking the ebuild classes to handles eggs
> (so he could emerge turbogears).  I talked to at least 3 others who
> were running gentoo.   I asked all of them if they had worked on
> portage.  Most said "No, the code is a little scary".  (I'll concur
> with that sentiment, as the code doesn't feel very pythonic).
> 
> If you want to attract more developers (python people), a few things are 
> needed:

That depends on how they contribute, I personally don't want random
python master bob contributing pieces to portage itself.  Portage things
are not necessarily as simple as people make them out to be.  Even
developers who know the code well make mistakes in adding and removing
code.  As solar once pointed out "the only man I trust to touch the
resolver is Jstubbs."  I realize thats a bit elitest...but at the same
time...I am overly cautious ;)

However we always accept patches and I think we get most of them
critiqued, sometimes it may take an extra prodding mail or two.  We
usually don't implement your features for you though ;)

> 
>  * Portage documentation.  How the innards work.  There is very little
> docs/comments in the portage code

Someone has to write them; I have some of it done, it's been a longtime
project that I've worked on off and on; I actually had more done last
year and I know kutsuya did some as well.  However these are not
particularly interesting..and no one wants to document the 2.X branch.

>  * Unittests - without this how do I know that my change to portage
> didn't break someone else's corner case
No one is writing unittests for the 2.X branch
>  * Refactoring into a more pythonic style.  Note that this is pretty
> hard without unittests.
See above :)

> 
> Take this as a grain of salt, from an observer, who believes that
> there are a lot of potential users (who know python), and who could
> easily contribute, if the bar was lowered a bit.  (Or steps were
> provided to reach a little higher ;))
> 
> -matt
> 


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Sandboxes

[Alec Warner]

To hijack the overlay thread, I see a few things here:

MOTIVATION:

a) Developers don't like putting experimental stuff in the tree: This is
usually because Joe Ricer picks up the ebuild, 'tests' it, it breaks and
he files a bug.  Joe Ricer has no clue what went wrong or what he is
doing and said Developer gets annoyed as hell by Joe Ricer's lack of
knowledge/co-operation with regards to bug report.  For more popular
packages, multiply Joe Ricer by some random two digit number.

b) Developers want users to contribute too: Users don't have commit
access to the main tree (for good reason, as stated in the other
thread).  However developers would like users to be able to contribute
in some meaningful way to a project/package without the red tape that is
bugzilla.

PROPOSAL:

a) overlays.gentoo.org -> A sub-domain for hosting overlays or
'development sandboxes'.  Developers want an area for sandboxed
development of packages outside of the main tree.  As stated in the
previous thread this allows faster developer with less overread (QA,
changelogs, etc..).  These sandboxed areas also allow non-developers to
contribute to projects in a useful manner.

b) overlays.gentoo.org -> Is not meant for public consumption by users.
 overlays.gentoo.org is merely a development aid and not meant for
public consumption.  Users tend to not know how overlays are
implemented.  Multiple activated overlays also can cause hard to debug
issues as overlays over-ride ebuilds and eclass in each other and the
tree itself.

c) Overlays may be secured on an per-overlay basis to prevent normal
users from both reading and writing to the overlay.  For example a
project may wish to have an overlay and invite two or three
non-developers to contribute.  This makes creating small development
units easy, while keeping QA the main tree relatively high.

This is what I see, and this is kinda what I would want.  As an overlay
"creator" I should be able to add/remove accounts from my own overlay (
to reduce the load on the overlay project/infra ).  In essence, creating
a bunch of small communities for development.

Thoughts on ideas on this somewhat more focussed idea? ( or at least I
think it's more focused :P )

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sandboxes

[Alec Warner]

Stefan Schweizer wrote:
> On 3/24/06, Alec Warner <[EMAIL PROTECTED]> wrote:
> 
>>Thoughts on ideas on this somewhat more focussed idea? ( or at least I
>>think it's more focused :P )
> 
> 
> IMO motivation b) is not taken into account enough.
> 
> You are missing out a general-user-overlay, where the developer adding
> a user to the access list would be responsible for him.

Hmmm that is not an intended goal at this time.  "User-Contrib" sounds
overly too large.  The aim is to make the overlay rather small, to allow
normal users to contribute to development of packages.

> We really need a general user overlay for stuff that is abandoned in
> the treee ([EMAIL PROTECTED]) or stuff that has not even
> been added to the tree ([EMAIL PROTECTED]). Those are
> ebuilds that no developer is interested in, so a general way for users
> needs to be present to be able to take care of those in a
> policy-based-overlay instead of bugzilla. Also the overlay will be
> easier to access and more bug-free as every person who is trusted by
> gentoo-devs can just fix bugs that come up without spamming every CC:
> on the list as it would be in bugzilla.

This generally breaks the rule of "overlays.gentoo.org is not for end
users."  The support in portage isn't there, the debugging is a
nightmare.  The point of overlays is to expedite *development* where
user A wants to help maintain package B because it's pragmatic for him
to do so, but he doesn't want to be a full Gentoo developer.  It is not
meant to be a "User-Contrib" overlay.  I think that should be a seperate
( if related ) project with different semantics.

> 
> Regards,
> Stefan
> 


-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Official overlay support

[Alec Warner]

Chris Gianelloni wrote:
> On Fri, 2006-03-24 at 08:59 +, Stuart Herbert wrote:
> 
>>>It is a Gentoo problem, because Gentoo gets innundated with bogus bug
>>>reports when users screw up their systems in weird ways and don't
>>>realise the cause.
>>
>>Convince me that this is something more than just a power play, and
>>I'll work with you.  But that's the hurdle you'll need to overcome
>>first.
> 
> 
> Perhaps because he's not the only one saying it?
> 
> Really, people, can we leave our personal bullshit out of a technical
> discussion *just once*?
> 
> 
>>Second hurdle is that you need to convince me that you "get" what the
>>overlays are there for.  If you can't, then I can have no confidence
>>that any policies you bring forward are appropriate for the work we're
>>trying to enable.
> 
> 
> They are there to speed development and to allow users to contribute
> more directly.  They should not be readable by the public, otherwise we
> run into the problem of users that don't know what they are doing and
> followed some half-way written guide on the forums using ebuilds from
> these overlays, breaking their systems, and filing bugs.  This is *not*
> acceptable.  I see no problems with allowing users to gain read and even
> write access to overlays, but it must be done with a certain level of
> caution of the main tree, or you'll have a very hard time getting
> support from the developer community at large.
> 

+1

At least in my mind the overlays should be developmental overlays; not
for public comsumption.  This doesn't mean "don't tell anyone about it
so that no one shows up."  It means "interested users will probably
inquire about helping out, etc...and can be granted access fairly easily."

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Alec Warner]

Stuart Herbert wrote:
> Thanks for the summary.  I think that's a fair assessment of where we are at.
> 
> The offered software will be trac, svn, and moinmoin.  I'm going to
> look at darcs, and with the help of the haskell team and infra
> determine if we can support it or not.  No-one has expressed a
> preference for a different distributed VCS instead of darcs.

bazaar-NG is distributed VCS, but requires only a web server so you
can't really 'prevent' it's use.

> 
> Just one more thing ...
> 
> On 3/24/06, Daniel Ostrow <[EMAIL PROTECTED]> wrote:
> 
>>On a less technical note there is also the question of using the o.g.o
>>frontpage as a means to point to existing repositiories of user created
>>overlays in order to promote them.
> 
> 
> There are no plans to use the o.g.o frontpage in this manner.  The
> frontpage will only point to overlays owned by Gentoo developers.
> 
> I'm not saying 'never'.  But this isn't something I'm going to roll
> out in the initial deployment.
> 
> Best regards,
> Stu
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/ocaml - to be or not to be

[Alec Warner]

Ingo Bormuth wrote:

Hi dev-list,

what is the rule concerning when to introduce new virtuals?

I created an ebuild for metaocaml which is a real drop in replacement for 
the ocaml programming language allowing for metaprogramming and dynamic 
linking. Metaocaml in fact is a patched version of ocaml.
For licence reasons the patch is not available so I cannot optionally 
apply it in the ocaml ebuild.


Would you in such a case create a new virtual or just 
PROVIDE "dev-lang/ocaml" in the metaocaml ebuild ?


More information: Bug #111407

Thanks Ingo




For a small number of deps ( IE 2 providers ) you can use an || depend atom.

|| ( dev-lang/ocaml dev-lang/metaocaml ) -> for example

Regardless of the outcome ( virtual vs no virtual ) the virtual should 
be a new style, and not an old style virtual.  I would say one is not 
necessary here however.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/acl

[Alec Warner]

Ciaran McCreesh wrote:
> On Sun, 2 Apr 2006 18:26:27 +0100 Stephen Bennett <[EMAIL PROTECTED]>
> wrote:
> | We have a fair number of packages in the tree (57 someone said, but a
> | non-trivial number) which depend upon sys-apps/acl for ACL support.
> | Since the packages needed for this differ between platforms
> | (sys-apps/acl is for linux only), if noone has any reasonable
> | objections I will be adding a (new-style) virtual/acl for these
> | packages sometime in the next week or so.
> 
> Good. This'll move the icky deps to one place rather than all over the
> tree, at least.
> 
> As an aside, and not directed at spb... Would be nice if in the future
> this kind of discussion were done *before* packages start to be changed
> in weird and wonderful ways. It's generally considered bad manners to
> start screwing around with other people's packages without asking...
> Plus there's the whole "learn from past mistakes" issue.
> 

Drop it.

-Antarus
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] emerge resume list

[Alec Warner]

evader wrote:
> Hi,
> 
> I'm not sure if this is the correct list to send this too, but it is
> the  only gentoo one I am currently subscribed to.
> 
> When I do an emerge -e world where is the list of files to be merged 
> stored? For example if I break an emerge, and want to resume later from
> a  different position, can I edit the packages to be emerged list so I
> don't  have to do emerge --resume --skipfirst constantly?
> 
> Thanks,
> 
> evader

The list is stored in a small database file in /var/cache/edb/mtimedb

It is a binary file full of pickled python objects.  I was actually
poking around it and thought about writing a tool.  I will commit more
time to it if you are interested; although be warned that editing things
in that file is not particularly recommended.  The dependency resolution
 for the packages in the list is done and the list is created.  Removing
items from it could cause packages to not build, and the dependency tree
to essentially be broken for that list.

Also, portage questions are generally well received at
gentoo-portage-dev@gentoo.org, or on IRC: irc.freenode.net #gentoo-portage.

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Improving Gentoo User Relations

[Alec Warner]

Thomas de Grenier de Latour wrote:
> On Fri, 7 Apr 2006 10:21:54 +0100,
> Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> 
> 
>>* If we're looking to increase the flow of end users -> super users ->
>>developers, perhaps we should focus more upon improving development
>>tools or development documentation.
> 
> 
> I would also suggest creation of a gentoo-dev-help@ mailing-list.
> Something similar to what, i guess, the homonym IRC chan is, but for
> people who don't like IRC.  Maybe i'm wrong and that's not the
> intention, but after 4 years of reading on gentoo-dev@ (yeah, today is
> anniversary of my subscription - yik, that's more than 36K emails in
> this maildir) , my feeling is that it's not the right place for users
> to ask technical questions about development/contributing (ebuilds
> writing, etc.).  It's not that i fear this ML, but i see it mainly as a
> place for dev-to-dev communication on general/important topics (gleps
> discussion, common sense reminders, random flamewars, etc.), and thus i
> see the occasional "How {c,sh}ould i do something?" messages about
> small details as somehow off-topic, and i tend to avoid posting some.
> 
> Seeing how more numerous this kind of messages are on "Portage &
> Programming" forums, or on gentoo-user*@ lists, i guess i'm not the
> only user with such feeling.  But forums or users MLs are not really
> satisfactory for non-obvious questions, because the devs/users rate
> there is too low.
> 
> So, what i usualy do when i'm not sure about something, in an ebuild i
> wrote for instance, is to post  it as-is on bugs.g.o, with the
> questions left open in my report. But they will stay unanswered if
> the bug falls in the "maintainer-wanted@" oubliettes, or if the
> assignee is too short in time to explain me why he choosed one solution
> rather than an other. And even if i get my answer, it will be from a
> single dev, whereas others might have had a different views on the
> topic.
> 
> Finally, i think such a mainling list could give good hints on what to
> improve in the documentation. Some legitimate questions may point to
> real lacks in the documentation, and some answers could be starting
> point for new chunks to add to the official or unofficial handbooks.
> 
> --
> TGL.

+1, plus the ML is archived unlike IRC, and users can search archives
and we could more easily compile a FAQ about ebuild writing and such.

-Alec Warner

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Let portage symlink latest version of installed docs

[Alec Warner]

Simon Stelling wrote:

Graham Murray wrote:


Fabian Neumann <[EMAIL PROTECTED]> writes:


What I'd like portage do to is to create a symlink to the latest version
of a package's documentation. Just omitting the version number would of
course not work as slotted packages may have multiple versions of docs
installed.  The first format coming to my mind would be:



What would be even nicer would be if it could create and maintain an
html index, for example at /usr/share/doc/index.html, to all package
html documentation in a similar way to that which gnu info maintains
the top level index to all info documentation on the system.



This would be a very cool feature. Not for portage though. Portage is a 
package manager, and a package manager has nothing to do with generating 
indexes of HTML files.




Yes this is why we created phase hooks :)  Portage shouldn't symlink 
docs, but adding scripts to do so should be relatively simple ;)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] slots and libraries.

[Alec Warner]

Paul de Vrieze wrote:

Hi all,

what did happen to my surprise. I remerged some libraries. Suddenly my 
subversion client stopped working because of missing libraries. Please 
remember, this is the reason we have SLOTS. The slot of a library package 
should change whenever the SONAME does. This is also true for (in this 
case apr-util-1.2 and neon-0.25


Paul



Expat?  If so we already discussed why SLOTS are not appropriate.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automatically killing invalid CFLAGS/warning about bad CFLAGS

[Alec Warner]

Patrick McLean wrote:
> For about a month now, we (amd64) have had some code in our
> profile.bashrc that filters CFLAGS that are unrecognized by gcc, and
> warnings the user about bad CFLAGS.
> 
> So far it has worked fairly well, and it has really cut down on the
> number of bugs that filed by people with extreme ricer CFLAGS. It might
> be an idea to have something similar in the global bashrc, and have a
> system for arches to customize the CFLAGS that are warned about.
> 
> The code is at gentoo-x86/profiles/default-linux/amd64/profile.bashrc
> for those who want to see it.

Except you need a way for them to turn it off, and you do not currently
provide one.  We can set default flags all we want, but I don't see
filtering 'bad' flags as necessarily our problem.  If you want to say:

"Hey we have had issues with people filing bogus bug reports with CFLAGS
that are completely inappropriate, so by default we check the sanity of
your CFLAGS, this is how you turn those checks off." then I'd be ok with it.

Most of the Ricers won't read it, and maybe you can print a warning that
CFLAG checking is disabled.

However leaving it on all the time merely imposes penalties on the power
users who wish to use your profile.  Your profile is a tool that should
be useful to all classes of users.

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Alec Warner]

Donnie Berkholz wrote:

Simon Stelling wrote:


Donnie Berkholz wrote:


We are working to ensure the dependencies work as smoothly as possible,
but I expect there will be some issues since it's difficult to require
updates to all these optional drivers following an update to the server.


wouldn't !< atoms solve that problem?



The drivers cannot be upgraded until a newer server is installed. So
technically, this would allow things to work by forcing people to
unmerge all their drivers before upgrading, then remerge the new
versions. That's not a very desirable solution either, but do you think
it's the best one?

Thanks,
Donnie



Well the semantics of the blocker is that the new driver won't work with 
the old server; is that true?  Or just the old drivers won't work with 
the new server?


I dislike using blocks to push users to fix issues; instead using guides 
and such.  But this is one of those things; how do you inform a bunch of 
 people, many who don't understand what an ABI is, to upgrade their 
system in the proper order without them getting all pissed off at you 
for lack of guidance ;)


My experience is limited only to #gentoo and the forums, but upgrade 
snags of that sort generally hit both of those areas rather quickly, 
making them easier to find.  Of course this screams changelogs/news GLEP 
 material as well ;)


-Alec

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Alec Warner]

Donnie Berkholz wrote:

Olivier Crête wrote:


On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote:


Alec Warner wrote:

Well the semantics of the blocker is that the new driver won't work 
with the old server; is that true?  Or just the old drivers won't 
work with the new server?


New server requires new drivers. Old server requires old drivers. 
There is no valid combination of new and old.



Then you should probably has new drivers block old servers and new
servers block old drivers...



OK, let's think about the results of this.

New drivers block old servers:
Rather, why wouldn't new drivers depend on a new server? This makes 
sense and is already what we're doing.


New servers block old drivers:
This will require people to uninstall all their drivers to upgrade 
their server. It will not automatically reinstall them in the 'emerge -u 
xorg-server' case, but it _should_ reinstall them in the 'emerge -u 
world' case _if_ they're using the xorg-x11 metabuild.




I'll take TGL's suggestion, New server PDEPENDS on new drivers.

New drivers need new server, old drivers won't work with new server, 
doesn't touch the old driver ebuilds at all; I don't particularly see a 
down side ;)


I'm not sure whether portage does a --deep by default now, but I think 
that's what is necessary for correct behavior in the 'emerge -u world' 
case.

It doesn't.


Thanks,
Donnie


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Alec Warner]

A valid problem with this approach. Is requiring everyone to unmerge 
drivers a worse solution than breaking some people who emerged drivers 
directly?




I very much dislike making people unmerge things.  It's not intuitive 
for anyone, having to remove the old program to upgrade a dependency of 
the new one?



Thanks,
Donnie


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Portage Features That Depend on Binaries [WAS: Re: [gentoo-portage-dev] Re: Re: 2.1 release candidate soon? ]

[Alec Warner]

Philipp Riegger wrote:
> On Apr 15, 2006, at 6:10 PM, Duncan wrote:
> 
>>> But i really think this is not about helping but about confusion.  If i
>>> post my emerge --info you don't know if i really use confcache  even
>>> if i
>>> have FEATURES="confcache", because emerge --info does not say if i  have
>>> emerged confcache and, if i have emerged it, which version it is.  I
>>> think
>>> this should also be listed in emerge --info.
>>
>>
>> Very good point.
> 
> 
> Should i file a bug on this?
> 
> Philipp
> 

Nope, lets bring it to -dev ( yay crossposting )

The issue for those on the -dev ML, is that portage has some features
that require binaries ( sandbox, ccache, confcache ) and so you need two
things for them to work.  You need FEATURES={sandbox,ccache,confcache}
and you need each package installed.  The FEATURES line is already
printed.  sandbox is already in info_pkgs.

Is there any problem with adding dev-util/confcache and dev-util/ccache
to info_pkgs?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] DEPEND/RDEPEND question

[Alec Warner]

Alin Nastac wrote:
> Lets say a package foo depends on bar, both at compile time and run time.
> Shouldn't DEPEND _and_ RDEPEND of the foo package reflect that
> dependency? I usually set DEPEND="$RDEPEND ..." or vice-versa (depending
> on which is the most demanding). Am I utterly wrong here?
> I know that when a package is installed the usual way (not from a binary
> tarball) dependencies==RDEPEND+DEPEND, but portage functionality could
> change in the future. It may not be the wisest decision ever made, but
> portage could very well remove whatever dependencies are found in DEPEND
> - RDEPEND, once the package is installed.

It needs to be in both.  For example if you only set it in DEPEND,
merging to ROOT!=/ would break as the dep would get installed in / and
not ROOT, so the app would fail to run.

-Antarus
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Gentoo, Google's Summer of Code, and You

[Alec Warner]

As many of you know by now, Gentoo has been chosen to fill one of the
last spaces in this year's Google Summer of Code.  This is a great
opportunity for developers and users to interact and help out Gentoo as
well as the OSS community.

For those of you who haven't heard of Google's Summer of Code, here is a
quick overview.  Google's SoC is an initiative whereby Google funds the
development of a selected number of OSS projects.  This year, only
students are allowed to do actual development for Google's SoC.  But
anyone who is a Gentoo developer can mentor a Student on one of the
projects for which Gentoo is the Mentoring Organization.

The role of a Mentor is as someone who has knowledge in the project
domain and can assist the student in a strategic development role, as
opposed to actually writing code.  Mentors are involved in evaluating
the work of the student and monitoring the project's progress, and is
also instrumental in enabling the student to complete the project by
providing the student with the tools needed to complete the project
(think about someone who needs read-only cvs access to the tree, for
example).

Prospective Mentors:
All Gentoo developers should have received the mail sent to -core about
Gentoo's acceptance into Google SoC.  The information and links to sign
up as a Mentor for Gentoo are enclosed in that mail, whose message ID
has been provided for your reference [1].  If you are interested please
see the -core e-mail for details, as well as the Mentor FAQ[6].  You
cannot be both a Mentor and a Student in SoC.  Please choose carefully
which role you will play.  Those who are not Gentoo developers may stll
apply for the role of Mentor on behalf of Gentoo.  If you are
not a Gentoo developer but are interested in applying, please stop by
the IRC[4] channel or send mail to Gentoo User Relations[7].  Please
have a few projects in mind when applying for Mentorship.  The Gentoo
SoC team is hoping to have more Mentors than projects; backup Mentors
are encourage by Google.

Attention Gentoo developers: You cannot be both a Mentor and a Student,
so please be aware that you must work on a proposal that is different
from your normal Gentoo work if you are looking to participate in SoC as
a Student.

Mentors, if you have applied and have not yet heard back please contact
the Gentoo SoC project leads for the outcome of your application[2].

Prospective Students:
If you are interested in participating as a student with Gentoo for the
SoC, please take a look at our current project list[2].  Note that it is
undergoing continuous improvement as we add proposals, Mentors, etc.

All interested students should refer to Google's Student FAQ[3] to check
whether they are eligible to participate in the SoC with Gentoo.  For
Gentoo developers who are also Students, you are probably eligible to
work on SoC for Gentoo provided you work on a proposal that is in a
different area than your normal Gentoo developer work.  Once again
please check the Student FAQ[3] for more details.  Student applications
are open May 1st through the 8th.  The URL for the student application
is not yet known.  The project page will be updated with the link as
soon as we receive it from Google.

Project Ideas/Discussion:
Anyone can submit project ideas and contribute to the discussion of
existing project ideas.  Those who have new ideas or comments on
existing ideas for Gentoo's SoC, please submit them via E-mail to the
Gentoo SoC mailing list[4] or on IRC[5].  If you are unsure of your idea
or wish to ask questions you may do so via the same means. As always,
feel free to ask any questions using those two avenues of communication
to ensure that the correct people receive your thoughts.

Thanks,

The Gentoo Summer Of Code Project

[1] Message-ID: <[EMAIL PROTECTED]>
[2]
http://www.gentoo.org/proj/en/devrel/user-relations/summerofcode/index.xml
[3] http://code.google.com/soc/studentfaq.html
[4] [EMAIL PROTECTED]
[5] #gentoo-soc @ irc.freenode.net
[6] http://code.google.com/soc/mentorfaq.html
[7] [EMAIL PROTECTED]
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo, Google's Summer of Code, and You

[Alec Warner]

Alec Warner wrote:

> But
> anyone who is a Gentoo developer can mentor a Student on one of the
> projects for which Gentoo is the Mentoring Organization.

I had four people proofread and I still screwed up.  Once again, ANYONE
is eligible to Mentor a student on behalf of Gentoo.  If you are not a
developer but are interested, please contact the Gentoo SoC project on
IRC[1] or via e-mail[2].

[1] #gentoo-soc @ irc.freenode.net
[2] [EMAIL PROTECTED]
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo: State of the Union

[Alec Warner]

Ryan Phillips wrote:
> This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and
> seemant's letter on herds, teams, and projects.
> 
> I believe the way Gentoo is doing things is broken.  There I have said it.  
> The
> entire project has reached a level of being too political and trying to solve
> certain problems in the wrong way.
> 
> Some of these problems are intermixed.  Please consider them starting points
> for discussion.
> 
> __Problem: Developer Growth__
> 
> I find that developer growth as being a problem.  Adding a developer to gentoo
> should be as easy as 1. has the user contributed numerous (~5+) patches that
> helps the project move forward.  If yes, then commit access should be given.
> Adding a developer is usually quite a chore.  There are numerous reasons why
> this is a problem: having a live tree, taking a test, and not defining within
> policy when a person could possibly get commit access. 
> 
> All these reasons leave the project stagnant and lacking developers.
> 
> Why do people have to take a test?  Is it to make sure they won't break the
> tree?  If it is, then the solution of a test is wrong.  We do want to make 
> sure
> our developers understand gentoo, but I argue that the bugtracker is all we
> need.  As long as a person is adding value to gentoo and they have "proven"
> themselves, then they *should* have commit access. 
> 
> Perhaps its because of a live tree...
> 

I am relatively new, I lurked for quite some time on IRC ( a yearish )
before finally becoming a dev, and the quiz was not particularly
difficult, and the questions I didn't know, I asked my Mentor about.  I
think Mentors in general don't do a very good job ( not complaining
about mine, mind, just in general ).  I think in some cases, people are
afraid to ask questions.

We have the madly successful AT project, and a new Herd Tester project
is in the works.  I find both of these to be very good ideas and have
aided in developer growth.

As for your suggestion, with a "Live Tree" you cannot give random users
who contribute "5 patches" commit access.  Commiting comes with it an
inherit responsibility.  The following is an example only:

I can go in right now and commit something that destroys anyone's box
not running SElinux, just bump portage and then watch anyone that uses
the new version destroy their machine.  Part of this involves having a
reputation based system.  IMHO this is part of our own tree security.
I have worked hard in the community to become a developer, and throwing
that all away to ruin some boxes is silly.  Sure once my changes are
found they can be revert and a new portage thrown into the tree, but how
many boxes were ruined first?  What if my commit was unintentional?

> __Problem: Live Tree__
> 
> Having a live tree requires people to be perfect.  People are not perfect and
> requiring it is ridiculous.  I love having commits in my local tree within the
> hour, but having a stable and unstable branch makes a lot of sense.  
> 
> CVS doesn't do branching nor tags very well... 

More details on how Branches and Tags solve the Live Tree problem would
be good.

> 
> __Problem: CVS__
> 
> CVS is one of the worst application ever created.  The portage tree needs to
> move to subversion.  A lot of the problems within the project would be solved
> by using a better SCM system.  The previous problems regarding the Live Tree
> and Developer Growth would be solved, IMHO, by just switching.  Branches Work.
> Tags Work.  Reverts work.  Moves work.  I don't see any reason not to use it.
> It just plain works.
> 
> Projects (gentoo/bsd, embedded, hardened) could choose to keep their own
> branches of the portage tree and merge with trunk as needed.  Projects could
> stick to traditional solutions like profiles if they so wished. 
> 
> Some will probably ask who will merge between branches.  We can do that easily
> ourselves.  If I think a package is good to go, then svn merge -r1123:1124 to
> the branch. 
> 
> Huge projects like Apache, GCC, and KDE already use SVN.

We have people looking into this.  Once more testing is done it will
probably be proposed in an official capacity, for now I think a test svn
with the whole tree plus tools porting from cvs to svn is the priority.

> 
> __Problem: QA Policies__ 
> 
> http://article.gmane.org/gmane.linux.gentoo.devel/37544
> 
> It seems that the QA Policies are a product of a Live Tree, and going 
> partially
> non-live would solve the problems listed. 
> 
> Everyone here is on the same team.  There will be some breakages in the tree
> and those can be dealt with.  Like Seemant [1] said, herds are just groups of
> like *packages*.  The QA Policy is wrong when it says cross-team assistance; 
> we
> are all on the *same* team.  The tree should naturally work.  If it doesn't
> then that is a bug for all of us.
> 
> Conflict resolution should not be a subproject.  It should *not* exist at all.
> Rules need to be in place to avoid conflict.  Ha

Re: [gentoo-dev] Gentoo: State of the Union

[Alec Warner]

Luca Barbato wrote:
> Alexandre Buisse wrote:
> 
> 
>>[1] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
>>[2] http://www.opensolaris.org/os/community/tools/scm/bzr-eval/
>>[3] 
>>http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/
>>[4] http://www.opensolaris.org/os/community/tools/scm/git-eval.txt
>>
> 
> 
> 
> Those figures are slightly old, some of the issues are probably
> addressed both on mercurial and git.
> 
> I'd say that both are nice and are probably a good solution.
> 
> if there is space and cpu I'd like to have someone playing with them and
> send benchmark results.
> 

I am currently working on this, I have a page under
proj/en/infrastructure where I am describing my efforts but I need a bit
more time to make it pretty ;)  Currently cvs2svn is almost done, and
git cvsimport is chugging along.  Not really a fan of bzr for us but we
use it for pkgcore, so I'll fire that up as well.

I haven't looked at mercurial but it is on the list ;)

-Alec Warner

> Mercurial should use a bit less disk and git should be a little faster
> and with better merge/conflict resolution features.
> 
> lu
> 
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [Fwd: [gentoo-portage-dev] Breakout etc-update, dispatch-conf]

[Alec Warner]

In an attempt to receive more comments and to request comments on the 
virtual/config-manager, I have forwarded this mail here.  Please comment 
+ point out weird things wrong.  I'd prefer to make either dispatch-conf 
 or cfg-update the default for the virtual, but I am definately open to 
discussion on that.
--- Begin Message ---
A bunch of bugs have been fixed with both of these lately, anyone
against splitting them out, please speak up now, otherwise I will split
them out later this week and portage will depend on some nasty virtual
whose name I have not come up with yet ( new style virtual ).

-Antarus
-- 
gentoo-portage-dev@gentoo.org mailing list
--- End Message ---

[gentoo-dev] Discussion

[Alec Warner]

Please don't commit files to profiles/ unless it has been discussed previously 
on this ML.  I don't care if your file is insignificant or 'won't affect 
anything else' or that it's 'completely necessary'.  Please discuss it first.

You don't have to ask for a vote on it, or make everyone agree with you.  You 
don't even need to wait three weeks to make sure everyone read your mail.  
This is definately one of those times where the apache lazy concensus works.

"Hi I'm adding this file to profiles/ for reason X in three days if no one has 
any issues with it."

Thats really all I'd like to see.  Something documented...So when I find the 
file magically in profiles/ a week later I can be like "Oh, that was due to 
mail on -dev" and not be like "hmm who did that" and then cvs log the file 
and then have to hunt you down on irc to figure out why it's there.

Courtesy towards fellow developers, especially when commiting to global spaces 
such as profiles/ is appreciated by all.

-Thanks

Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Discussion

[Alec Warner]

On Wednesday 10 May 2006 01:26 pm, Ciaran McCreesh wrote:
> On Wed, 10 May 2006 10:13:36 -0700 Donnie Berkholz
>
> <[EMAIL PROTECTED]> wrote:
> | Ciaran McCreesh wrote:
> | > On Wed, 10 May 2006 00:07:29 -0700 Donnie Berkholz
> | >
> | > <[EMAIL PROTECTED]> wrote:
> | > | so discussion with at least the portage team would be merited.
> | >
> | > Already happened, in amongst all the other GLEP 42 stuff.
> |
> | Then I wonder why a member of the portage team was taken by surprise?
>
> Because he wasn't paying attention? Or because he knew fine well and
> just felt like taking a dig...
>

It was discussed a while back yes, there was no firm "this is what will be 
done" and I don't have any issues with what was put into the tree.  As I 
stated on IRC, I'd like a heads up if things there are going to change, as it 
affects more than just you ( or paludis ).  All I request is an attempt to 
keep each other informed.  I try to e-mail this list whenever stuff like that 
changes (I think I changed info_pkg's a while ago, for example) to let people 
know whats going on; I ask that you do the same.

> --
> Ciaran McCreesh
> Mail: ciaran dot mccreesh at blueyonder.co.uk
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Alec Warner]

Ciaran McCreesh wrote:

On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <[EMAIL PROTECTED]>
wrote: 
| vdb changes )- wrong place to be deploying incompatibilites that paludis 
| introduces is into the production tree without appropriate 
| containment/protection.


Uh, VDB isn't part of the tree. Nor does it introduce any breakages for
existing users, except those who do something especially dumb. Even if
a user *does* change their profile to a Paludis profile, it won't cause
Portage to explode in such a way that switching profiles back won't fix
it.



I would prefer to see the profile you are commiting then; do you have a 
link?


-Alec Warner

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 259 paludis-profile messages. ENOUGH!

[Alec Warner]

Peter wrote:

Imagine a new user or visitor trolling this ML. They want to learn more
about Gentoo. Then they come across the Paludis thread. How TF can they
possibly follow what is going on? Then, as the thread wears on it
degenerates into more personal attacks. So it's Bennett/McCreesh against
the world. OK. However, continuing the thread serves no useful purpose
except, IMHO, to completely obfuscate the original point of the thread --
to allow paludis to have a profile or sub profile and/or whether or not it
should be on the tree or in an overlay.

While I am completely against any form of censorship, I certainly wish I
had the ability to block that thread and all further postings to it. Maybe
paludis can set up a blog on the berlios site?

There are many important issues that have surfaces WRT paludis that affect
the core of gentoo (pun intended). These issues cannot be resolved on a
ML. There appear to be certain policy issues that the council needs to
resolve.

So, while I am not endorsing pablum, at least let's cut the thread. I see
nothing useful coming from it anymore.

No one forces you to read, feel free to ignore this thread, others are 
gleaning useful information from it.


-Alec Warner

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Alec Warner]

I've read every mail thus far (even the mails sent from next month ).

There is no technical reason that the profile shouldn't go in.  Past 
precedent is set, most of the kinks regarding the profile have been 
worked out, yet members of the community are dead set against the idea.


I think I was dead set against it too, a few weeks ago.

However, everyone has the silliest of reasons, or so it seems.  Everyone 
is afraid of switching, fear is good, fear keeps one cautious.  However 
fear is also stifling, stifling innovation in this instance.  Paludis is 
 a way forward, as is any portage rewrite.  It has bugs yes, it works 
for the most part yes.  So why not give it a fair shot?


Fear the Slipperly slope:
First a new profile, then an eclass, then the tree!  Paludis will take 
control of everything!


Only if you let it.  And to an extent, why not let it.  Who has to 
commit all that crap that uses all the new shiny features?  Thats right, 
developers do.  If thats the way developers wish to go, than thats the 
way Gentoo may go.  Of course, you need to keep standards in the tree, 
EAPI helps this a bit.  Use something new in Paludis, EAPI it.  Portage 
will gladly mask it properly.  This is where the problem lies however.


None of the paludis folk are asking for ebuild changes at this time.  I 
say give them their profile; tell them if they make any ebuild changes 
you will cut their nuts off.  Take it to the council and figure out a 
plan for migration, since there is more than one alternative coming up. 
 We may need a plan similar to the CVS migration where someone goes off 
and does some testing and figures out what is best for Gentoo.


The problem being with multiple implementations of something we have no 
standard for...they all need to match ;)  Otherwise paludis will end up 
being...well..a fork.


-Alec Warner
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Alec Warner]

Paul de Vrieze wrote:
The promissed glep on package manager requirements. Please comment on it. 
There are some parts that may be controversial (portage has in the past not 
provided support for reverting to stable either), but please keep the 
discussion on topic.


Paul




s/primary/official/g

This primary business is silly IMHO.  GCC is Gentoo's official compiler, 
 baselayout is the "official" init system, etc...


There is precedent here, and you are ignoring it.

Basically this whole GLEP is a reactive farse.  I realize thats not your 
intention, you seriously want a defined manner in which many package 
managers can live.  However reading the GLEP it seems to be built 
completely against Paludis; stacking the deck as it were.  However I 
left other comments below ;)








[Gentoo]  	[*Gentoo Linux Home 
*] [*GLEP Index 
*] [*GLEP Source 
*]


GLEP:   49
Title:  Alternative Package Manager requirements
Version:2214
Last-Modified:	2006-05-20 14:51:41 +0200 (Sat, 20 May 2006) 
 


Author: Paul de Vrieze ,
Status: Draft
Type:   Standards Track
Content-Type:   text/x-rst 
Created:18-May-2006
Post-History:   19-May-2006



Contents

* Abstract <#abstract>
* Motivation <#motivation>
* Rationale <#rationale>
* Backwards Compatibility <#backwards-compatibility>
* Categories of package managers <#categories-of-package-managers>
* Package manager requirements <#package-manager-requirements>
  o primary package manager requirements
<#primary-package-manager-requirements>
  o candidate primary package manager requirements
<#candidate-primary-package-manager-requirements>
  o secondary package manager requirements
<#secondary-package-manager-requirements>
  o third party package manager requirements
<#third-party-package-manager-requirements>
* transition phases <#transition-phases>
  o primary package manager transition phase
<#primary-package-manager-transition-phase>
  o Secondary package manager to candidate primary package
manager transition

<#secondary-package-manager-to-candidate-primary-package-manager-transition>
  o Third party to other transition
<#third-party-to-other-transition>
* References <#references>
* Copyright <#copyright>


  Abstract <#id7>

This GLEP describes four classes of package managers. What the 
requirements for them are, and what support they can receive.



  Motivation <#id8>

To set a standard that package managers that seek gentoo project 
approval and support should adhere to.



  Rationale <#id9>

Currently portage is showing its age. The code of portage does not seem 
to be salvageable for new versions. There are two known alternative 
package managers that claim a level of portage compatibility. These 
alternatives are paludis  [1] <#id1> and 
pkgcore  [2] 
<#id3>. Before these alternatives are developed further, a set of rules 
should be created to level the playing field and ensuring that decisions 
can be made clearly.



  Backwards Compatibility <#id10>

Not a problem for this GLEP. There is no previous standard as the issue 
did not exist before. This GLEP is to prevent future compatibility issues.



If there is Official and 'everything else" I think this whole section 
can be dropped.



  Categories of package managers <#id11>

We distinguish four categories of package managers. While a package 
manager can transition from one category to another, it can not be in 
two categories at the same time. It can be in a state of transition though.


/Primary Package Manager/
There is one primary package manager. Currently this position is
held by portage. The primary package manager is assigned by the
council and all packages in the official tree must be installable by
a useable version of the primary package manager.
/Candidate Primary Package Managers/
A candidate Primary Package Manager does aim, or show an aim, at
replacing the current primary package manager. At a point where the
package manager is deemed stable a decision must be made whether
this package manager should become the new primary package manager.
At that point the primary package manager transition phase
<#primary-package-manager-transition-phase> starts.
/Secondary Package Managers/

A secondary package manager is a package manager that coexists with
the primary package manager, while not aiming to rep

Re: [gentoo-dev] GLEP 49 - take 2

[Alec Warner]

Ciaran McCreesh wrote:
> On Mon, 22 May 2006 14:59:33 -0400 Ned Ludd <[EMAIL PROTECTED]> wrote:
> | It should be pretty clear that one of the main problems is letting 
> | others decide which features we will and wont have and defining our 
> | standards based on their needs and not our own.
> 
> So where are the use and slot deps?
> 

You will be tired of hearing this but backwards compat is a big issue.
It is an issue that I think the portage team took into consideration far
too much in the past, leading to this current situation.  Most sane
people realize that many of the features people want are not possible
with the 2.X Portage codebase; except if the codebase is gutted.  The
Portage team didn't want to break backwards compatability a half dozen
times, making people rewrite all the necessary tools in order to work
with the new code.

Perhaps this was a mistake, perhaps the portage team should have done so
in the past in order to push the required features.  At this point I
don't see portage going anywhere, if only because it has the same
problems it always did.  Too much spaghetti code, too much code
dependency, bascailly requiring a rewrite of 6000+ lines of code just to
make it "usable".

You make it seem like some easily solvable thing that anyone can do.
You make it seem like the dep-resolver the portage team envisions is
child's play to write.  Frankly I don't see where these assertions come
from.

Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 49 - take 2

[Alec Warner]

Ciaran McCreesh wrote:
> On Mon, 22 May 2006 19:10:22 -0400 Jon Portnoy <[EMAIL PROTECTED]> wrote:
> | Well, let's take the real life example of paludis vs. portage:
> | Paludis is controlled by a former developer known for being hard to
> | work with, Portage (being a Gentoo project) by necessitity has to be
> | controlled by someone other developers can work with (else the
> | council can intervene and fix the problem with new management).
> 
> So why has the council not intervened to demand that all those features
> that Gentoo developers require be introduced?
> 



Well I'd gather the same reason the council hasn't denounced infra for
not implementing what I want them to implement.  The council isn't the
tool to force people to do things.  You can't wave a wand and make
features happen.  I can't wave a wand and make infra do my bidding, even
if it's merited on a technical level.



-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [Last Rites] x11-wm/blwm-1.0.4 Bug # 71479

[Alec Warner]

This doens't build at all as the buildsystem is too old and needs
updating to work with new automake versions.

I will pmask this and remove it in 30 days unless someone speaks up.

-Antarus
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] pmask cleaning

[Alec Warner]

I've taken the liberty of cleaning out some of pmask.

Pretty much anything pre-2004 that covers stuff that isn't in the tree.

Removed:

Bug 43658 is closed, we only have ebuilds for 1.2.10
# <[EMAIL PROTECTED]> (03 Mar 2004)
# security problems. see bug #43658.
 (30 Dec 2004)
# Junkie being masked per security bug #74696
net-ftp/junkie

The rest are a bit newer, or I'm unsure of, or need 30 days waiting to
get punted from the tree.  You will be getting bugs filled for old crap
as I go over package by package.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [Last Rites] www-client/prozilla

[Alec Warner]

This guy is a security nightmare and has been masked on and off for
security vulnerabilities[1] for the last two years.  If no one objects I
will punt it from the tree in 30 days.

[1]http://bugs.gentoo.org/show_bug.cgi?id=70090


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] dev-db/xmysqladmin & dev-db/mysqlnavigator removal

[Alec Warner]

Francesco Riosa wrote:
> Both dev-db/xmysqladmin and dev-db/mysqlnavigator has no active homepage.
> Both need to be patched to compile agains mysql-4.1.10a (avoiding
> OLD_FUNCTIONS workaround).
> expecially "xmysqladmin" seems to be unsupported anymore.
> 
> It's possible to remove them from portage tree?
> If not please let me know I'll try to patch the source code to compile
> against mysql-4.1
> 
> Francesco
> 
> -- 
> gentoo-dev@gentoo.org mailing list
> 
> -- 
> gentoo-dev@gentoo.org mailing list

dev-db/xmysqladmin has a security bug [1] and it says to punt it, so
consider this it's last rites e-mail.  It's already masked, but I'll
give it the 30 days everything else gets ;)

[1] http://bugs.gentoo.org/show_bug.cgi?id=93792#add_comment


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [Last Rites] net-misc/powerd pmasked with security issues

[Alec Warner]

powerd has an open security vulnerability [1] and no maintainer.

Someone can claim it in the next 30 days or I will punt it then.

[1] http://bugs.gentoo.org/show_bug.cgi?id=70373


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [Last Rites] sys-fs/convertfs

[Alec Warner]

sys-fs/convertfs has an open bug [1] and is seeking a maintainer, if
none is found I will punt it in 30 days, per the usual.

-Antarus

[1] http://bugs.gentoo.org/show_bug.cgi?id=107635
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Last rights for dev-util/perforce

[Alec Warner]

Stuart Herbert wrote:
> Hi,
> 
> The dev-util/perforce packages:
> 
> - dev-util/perforce
> - dev-util/perforce-cli
> - dev-util/perforce-gui
> - dev-util/perforce-proxy
> - dev-util/perforce-server
> 
> are in need of a new maintainer.  If no-one volunteers in time, the
> packages will be masked Saturday 8th April, and removed from the tree
> shortly after.
> 
> Best regards,
> Stu

This has been masked as of today, awaiting it's 30 day countdown for
removal.

-Alec


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [Last Rites] dev-libs/nana

[Alec Warner]

Good candidate for last rites...

- SRC_URI dead, so this only lives on Gentoo mirrors
- no maintainer, this bug[1] has been sitting here for 2 1/2 years

So without further ado, pmasked for 30 days pending removal.

[1] http://bugs.gentoo.org/show_bug.cgi?id=32672


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]

[Alec Warner]

So we created this awesome alias to put ebuilds that need a maintainer.
 Good idea at the time, decent idea still.  The problem?  We have nearly
2000 open bugs assigned to maintainer-wanted[1].  I would like to
discuss policy on these.  Do we keep them, do we get a group of people
to slowly review and discard them?  Do we mind having a ton of things
open like this (a quasi-ebuild db of sorts).  Is bugs the right place
for this sort of thing, or can we improve somewhere/how?

[1] http://tinyurl.com/m3dmq


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [Last Rites ipkg-utils]

[Alec Warner]

ipkg-utils was maintained by tigger who is no longer a dev.  As far as 
tigger/solar are aware there is no reason to keep it in the tree.  It 
will be pmask'd and punted in 30 days at their request.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Glep 49 (g2boojum's version)

[Alec Warner]

Stephen Bennett wrote:

On Fri, 2 Jun 2006 19:48:39 +0200
Paul de Vrieze <[EMAIL PROTECTED]> wrote:



The problem is actually that such a document is a living thing and it
must not only exist initially but be maintained continuously.



Must it? I'd be more inclined to say that if it needs to change, a new
specification should be created based on the current one, and EAPI
bumped. Each individual document should remain more or less unchanged
once it's finalised, barring minor bugfixes.


I think this is what he means by maintained...aka someone needs to 
either update the spec, or create a new one.

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] QA subproject, TreeCleaners

[Alec Warner]

I propose a new QA subproject, the TreeCleaners.

This is a delicate subject for some developers, other developers don't 
care, and yet others want the cruft in the tree removed.  The Tree 
Cleaning project's main goal is to identify broken and unmaintained 
packages in the tree and either get them fixed or mask and remove them.


Criteria:
1.  Packages slated for removal must have no active maintainer.  This is 
accomplished by looking in the package's metadata.xml for the maintainer 
tag.  The maintainer tag must contain an active (non-retired) developer 
or team.  The tree cleaners will maintain a list of ebuilds assigned to 
maintainer-needed; this list may end up on the web similar to Debian's 
WNPP[1].  A package with missing metadata.xml is assumed to be unmaintained.


2.  Packages slated for removal must have open bugs filled against them. 
 It is not the policy of the QA team nor this subproject to remove 
packages because they have no maintainer.  There are plenty of 
completely working packages in the tree with no maintainer; we are not 
trying to remove those.


3.  Packages slated for removal with simple to fix bugs may be fixed by 
the tree cleaners if a project member elects to do so.  Many of the bugs 
are relatively minor ( depend fixes, revbumps, etc ) and could be done 
by someone given a bit of time.  This isn't meant as a means to 
perpetually keep crap in the tree, moreso that in some cases minor bugs 
against a package are not grounds for removal.


4.  Preferably packages slated for removal shall have a dead or 
unresponsive upstream.  An upstream that isn't interested in maintenance 
means more work for Gentoo in keeping the package up to date.  For 
packages that already lack a maintainer in Gentoo, a dead upstream means 
there is no developer and no upstream for a package; aka no one to do 
the work.  A dead upstream is not *required* however, crap ebuilds for 
packages with an active upstream are still valid to be removed if there 
are major bugs filed against them.


5.  Packages slated for removal shall have a last rites e-mail sent to 
the gentoo-dev mailing list.  There will be no packages disappearing 
randomly out of the tree due to the tree cleaner project members. 
Transparency is key here, both on bugs, in package.mask, and on the 
mailing list.  developers and users both need to know what is going on.


6.  Packages slated for removal shall have a 30 day period in 
package.mask prior to removal.  This is tree cleaner policy, and it's 
one that I hope other developers will adopt.  I've seen things pmasked 
and removed after a week, a "couple of days", or just pmasked and never 
removed.  The 30 day period allows everyone using the package to see the 
masking message and the corresponding bug when they use portage.


Questions and Comments are welcome, as always.

-Alec Warner

[1] http://www.debian.org/devel/wnpp/
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv

[Alec Warner]

Diego 'Flameeyes' Pettenò wrote:

On Sunday 04 June 2006 14:56, Mike Frysinger wrote:


what about TV_CAPTURE_CARDS


You got it quite wrong, it's not about the TV cards :)
It's about TV guide grabbers.



TV_GUIDE_GRABBERS

see that was easy ;)
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] new repoman check

[Alec Warner]

Slipping this in before 2.1 goes stable, it's a small check.

Basically if your ebuild inherits a VCS eclass ( currently darcs, 
subversion, cvs ) AND your ebuild has stable keywords on any arches 
repoman will report an error.


One thing to note here:

Are there any cases when one inherits a VCS eclass but the ebuild itself 
is not a live checkout ebuild.


I don't see any, looking at the eclasses.

This repoman check attempts to enforce policy in the developer handbook[1].

""Live" cvs.eclass ebuilds are generally only intended for the 
convenience of developers and should always be masked with a ~[arch] 
keyword. It is impossible to guarantee the reliability of a "live" 
cvs.eclass ebuild since the upstream cvs tree may change at any time, 
which is why they should always be masked.


Whether a "live" CVS ebuild or a "snapshot" CVS ebuild, you the 
developer are responsible for ensuring that the ebuild works correctly. 
This is particularly difficult to do with "live" cvs ebuilds for obvious 
reasons."


[1]http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Alec Warner]

Harald van Dijk wrote:

On Mon, Jun 05, 2006 at 02:24:24AM -0700, Brian Harring wrote:


On Mon, Jun 05, 2006 at 11:14:45AM +0200, Harald van Dijk wrote:


On Mon, Jun 05, 2006 at 01:54:08AM -0700, Brian Harring wrote:


On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote:


On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote:


On Monday 05 June 2006 02:07, Harald van Dijk wrote:


Some gnustep stuff inherits cvs, but uses -D in the cvs options to
always download exactly the same thing.


then arent you just adding overhead to the poor gnustep cvs servers ?  why not 
roll a cvs snapshot tarball and distro via our mirrors


Yeah, that'd probably be a better idea, but even if the current ebuilds
are less than perfect, it seems like a valid use of the eclass to me, so
making repoman error out is a bad idea, I think. A warning would be
useful, though.


'Cept standards for ebuilds is typically http/https/ftp access for 
fetching files- forcing pserver means people behind firewalls are 
screwed... which is why non standard uri that is generally accessible 
to users must be http/https/ftp, and if they aren't, upload the file 
to the mirrors.


Ebuilds might work, don't think they qualify as valid though- assume 
initially it was easier to just copy the ebuild and lock the date; 
doesn't make it valid though. :)


I now checked:

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

If it's explained how to do it in the docs, I consider it valid,
regardless of how bad an idea it may be.


Except the doc specifically states they should be package.mask'd if 
added; what that doc is talking about is vcs head ebuilds, not an 
ebuild that's locked down to an exact rev/date.



It first lists the disadvantages of CVS sources in general, and then
the disadvantages of live CVS sources. If it only applied to live CVS
sources, why would it split them up?


As mike said, why hammer on their servers?  The ebuild isn't changing 
(it's effectively a locked version), tarball it and upload it.



And as I said, I agree that that would be a better idea.


Basically, the locked cvs version ebuild referenced above seems like a 
lazy trick someone did to avoid rewriting it to drop the cvs usage.




Should be an error imo- there isn't any real requirement for a 
cvs/git/darcs/subversion eclass consumer to be visible really.

~harring


Are you hoping for even ~arch cvs ebuilds to cause a repoman error?


Original rules *were* that no vcs head based ebuild should be visible, 
that it must be masked.  Current devrel docs contradict that (those 
docs bluntly are wrong- that change I don't think anyone ever agreed 
to), devmanual states it correctly.



The devmanual states that they should not "generally" be added to the
tree softmasked or unmasked. It does not state that they should never
be added as such at all. Or, in other words, there can be exceptions.




The error has been dropped to a warning, repoman will presently complain 
for any ebuild which has stable keywords and inherits a "VCS" eclass. 
Repoman will then list off all the arches that are keyworded stable.


*In General* Inheriting a VCS eclass and having stable keywords means 
you are doing something wrong, there are exceptions; thats why warning 
is important here (more effective than an error as I think more about 
it).  It's a warning to allow exceptions, expect the QA team to nudge 
you about ebuilds with odd keywording though.


I am attempting to enforce current devrel policy with this change.  I 
will push for policy to be changed later to pmask as I think that is the 
proper way to go about things.  However that is seperate discussion.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA subproject, TreeCleaners

[Alec Warner]

Peter Volkov (pva) wrote:

On Втр, 2006-06-06 at 00:17 +0200, Diego 'Flameeyes' Pettenò wrote:


That's why we use a SCM for managing the ebuilds: the removed ebuilds
are still found via cvs commands and on sources.gentoo.org 



But how can I search for removed ebuild in cvs? Is there any quick way
for such things?

Peter.


I am still thinking about hosting the ebuilds in an overlay somewhere, 
but yeah the ebuilds will be in the Attic, if/when we migrate to 
something !CVS, Attic migrates with us.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1

[Alec Warner]

Grant Goodyear wrote:

Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]


Mike Frysinger wrote:


this is a *huge* con ... developers are lazy, *i'm* lazy ... i
certainly do not want to go through every single package i maintain
and add 'debug-build' to IUSE or 'inherit some-new-eclass'


Sometimes it takes a little extra work to do things right, but
hopefully it will pay off in the long run.  A poor design decision
made now can haunt us for years to come.



A "little extra work"?  I'm pretty sure that such an eclass would be
required for better than half the tree (every package that contains some
C or C++).  If almost everybody has to add the same piece of
boilerplate to their ebuilds, then perhaps a sane package manager should
be able to figure out what to do without the boilerplate.  That
rationale seems especially true in this case, where nostrip and
debugging flags will do no harm for packages that aren't C or C++.


I tend to agree here on pragmatic principal as opposed to bowing to 
"this is the ideal case" that some members of the portage team seem to 
want.  debug-build can always be expanded to turn on generic debugging 
for other build systems and languages.


I realize it's not the "perfect solution."  But no one has implemented a 
better one.  People only wait so long for things before getting fed up 
and saying "it's going in anyway."





if the large majority of packages are going to be taking advantage of a 
feature, isnt the logical thing to opt everyone in rather than forcing the 
majority to opt themselves in ?


It really depends on the pros/cons applying something on a *global*
scale, like you propose.  A package manager (such as portage) will
never be able to make debug-build decisions that work well for *every*
ebuild.  That's why it's better for ebuilds to make those decisions
themselves (with the help of eclasses).



I would think that your argument would depend on the probability of a
package being an exception to the general rule.  How many packages
actually fail to do what is expected when compiled with -g and nostrip
(noting that those cases without binaries to strip don't count)?
Unless that percentage is significant, then I would think that a simple
solution that handles the common case is a very good thing.

Wouldn't the "simple" solution be to have package.* files that allow the
user to specify FEATURES, CFLAGS, and CXXFLAGS per package?  (Of course,
I do realize that it's the lack of such files that lead vapier to
propose his solution, which is rather more convenient for one-off
builds.)


We've discussed this multiple times, and it's always been the conclusion 
that per package.env should go in bashrc, as bashrc is generally more 
powerful than anything we could devise.  The only downside afaik, for 
bashrc is that you can't do per package FEATURES as FEATURES is a 
python-side var.  But you shouldn't need per package FEATURES by design;

FEATURES are for portage, not your ebuild.



-g2boojum-


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1

[Alec Warner]

Ned Ludd wrote:

On Wed, 2006-06-07 at 16:05 -0400, Alec Warner wrote:


We've discussed this multiple times, and it's always been the conclusion 
that per package.env should go in bashrc, as bashrc is generally more 
powerful than anything we could devise.  The only downside afaik, for 
bashrc is that you can't do per package FEATURES as FEATURES is a 
python-side var.  But you shouldn't need per package FEATURES by design;

FEATURES are for portage, not your ebuild.




This is a thumbs up? I've got the code sitting in my
$PORTDIR/profiles/base/profile.bashrc to give us just this.
I'd be all to happy to commit it. So that's a yes right? :)




As I told you on IRC, it's not your job to listen to the portage devs on 
 this one, you know what was intended for that support, we've argued 
over it a dozen times.  There is nothing we can do to stop you from 
"mis-using" something in portage, aside from complaining and removing it 
in the next version.  I believe we have made our recommendation and you 
know what we think you should do, but we are not Gentoo.


I would be more concerned with convincing the rest of the developers. 
adding crap in base profile.bashrc will affect 99% of users, so it 
better be friggin correct and useful, otherwise you will piss a ton of 
people off.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1

[Alec Warner]

Mike Frysinger wrote:

On Wednesday 07 June 2006 19:12, Alec Warner wrote:


I would be more concerned with convincing the rest of the developers.
adding crap in base profile.bashrc will affect 99% of users, so it
better be friggin correct and useful, otherwise you will piss a ton of
people off.



versus the people who are really annoyed that such support hasnt yet been 
integrated into portage proper ?


yes, from the portage side of things, it may be a pita to implement 
per-package env ... but from the user side of things, it's a huge help

-mike


My e-mail was basically worded as to say "Solar paste your crap to this 
ML."  Is there any reason you need package.env in portage proper as 
opposed to bashrc?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?

[Alec Warner]

Matteo Azzali wrote:

This is just a mine question, but it seems that since gcc-4.1 got it's
way into portage (~branch) things are getting slower.

Lots of the bugs blocking  bug #117482 -
http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report
or an ebuild for revision bump, tested working.
They just don't get committed (or, sometimes, closed).

IMHO these bugs should get some kind of "priority", cause actually any
unstable system having one of these "blocking ebuilds"
in world tree will have issue emerging,for sure.
( for who didn't noticed: gcc-4.1 is actually in portage testing , no
more unmasked).


Sometimes people get busy, I know I haven't looked at my bugs all week, 
been busy at work 12 hours a day.  As such if it's a big problem you can 
always gcc-config  and then compile any 
problem packages.  I know that breaks the whole 'my whole system is 
compiled w/gcc-4.1' deal, but if it's that big of a blocker, take 
action.  Or hell, patch the ebuild yourself.


I think this distro was (or is?) about giving users the ability to do 
what they needed.  If something is masked, you can unmask it, if it's 
not keyworded you can keyword it, if it's not patched, you can patch it




thanks for your time and for listening my 2 cents.

mattepiu


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1

[Alec Warner]

Ned Ludd wrote:

On Thu, 2006-06-08 at 06:49 -0400, Alec Warner wrote:


Mike Frysinger wrote:


On Wednesday 07 June 2006 19:12, Alec Warner wrote:



I would be more concerned with convincing the rest of the developers.
adding crap in base profile.bashrc will affect 99% of users, so it
better be friggin correct and useful, otherwise you will piss a ton of
people off.



versus the people who are really annoyed that such support hasnt yet been 
integrated into portage proper ?


yes, from the portage side of things, it may be a pita to implement 
per-package env ... but from the user side of things, it's a huge help

-mike


My e-mail was basically worded as to say "Solar paste your crap to this 
ML." 



Alright...

tail -n 6 /usr/portage/profiles/uclibc/profile.bashrc

#for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
#   if [[ -r /etc/portage/env/$CATEGORY/${conf} ]]; then
#   . /etc/portage/env/$CATEGORY/${conf}
#   break
#   fi
#done


Ideas on multipile sources?

Aka, I want all these env things enable for kde-base/* but for 
kde-base/foo I want extra stuff ( or to negate things ), it looks like 
this only sources things once?


Could we define a stacking order here and let them stack?




Is there any reason you need package.env in portage proper as 
opposed to bashrc?



Nope.. bashrc is the only way to access the variables in a way that 
is the most friendly to the bash side of things.




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Alec Warner]

Jon Portnoy wrote:

On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote:


On Thu, 08 Jun 2006 09:20:18 -0400
Chris Gianelloni <[EMAIL PROTECTED]> wrote:


Please keep the games bugs in bugzilla.  Making this change is a direct
change in games team policy without any prior notice to the games team
and without our permission.


No one needs permission to put ebuilds from bugs.gentoo.org into an
overylay. The ebuilds, assuming they have the proper header, are all
"Distributed under the terms of the GNU General Public License v2".

~tcort



I do not object to the concept of ebuilds in overlays.

I do very much object to using any gentoo.org infrastructure or 
subdomains to do so. If someone is going to tackle that, it should be 
done outside of Gentoo proper. We don't need to be stuck maintaining and 
supporting a semiofficial overlay.




It is my understanding the the Sunrise overlay is not open to "anyone to 
commit", so it is not a contrib/  The sunrise project is the owner of 
the overlay and they are responsible for it's contents.  The people 
commiting are responsible for what they commit.  The point of the 
Sunrise project as I understand it is to aid in the development of 
ebuilds in maintainer-wanted, such that they may improve and be added to 
the tree; as well as to give frequent 'not quite a dev' and 'I don't 
have a bunch of time but would like to help' people a place to commit to.


-Alec
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Alec Warner]

Grant Goodyear wrote:

Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT]


Initially jokey and myself will be working on this. The current focus is to
migrate ebuilds from bugzilla into the overlay and to get contributors to
commit their changes to the overlay instead of updating the bugzilla every
time.



I'm not opposed to what would essentially be an overlay of
maintainier-wanted ebuilds, but I would actually prefer to see that
happen by pulling from the bugzilla database instead of trying to
replace bugzilla altogether.  My reasoning is that bugzilla provides a
place for community development of an ebuild (including commentary!),
which would not be true of just the overlay.  If one were instead to add
a magical bugs whiteboard status or keyword that let a script know that
there's an ebuild to pull from bugzilla that should be added to the
there-be-dragons-here overlay, I'd think that would make life
much simpler for everybody.

-g2boojum-


FYI I've been tinkering with something similar using gentoo-bugger, but 
I haven't had time to work on it recently.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Alec Warner]

Why? Because having two year old bugs is simply inexcusable. Especially
when many have not had any activity for a long time. Having
maintainer-wanted bugs for months on end is silly. Giving a user who files
a ebuild request or submits an ebuild deserves the chance to take
ownership of it. It's a good way to get a more experienced user, and
hopefully one day, a future dev.


Why inexcusable?  Why is leaving a bug open indefinately a bad thing? 
If someone wants it, they can comment on the bug.  This isn't a software 
development project (for the most part :)) so leaving a bug open causes 
no harm, other than to make it a bit difficult in some instances to find 
what you are looking for among the large number of filings.





--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] client+server packages - build which one?

[Alec Warner]

Roy Marples wrote:
Some packages provide both a client and a server. As such, users usually only 
want one or the other - and rarely both.


A good candidate is net-misc/dhcp as it installs a DHCP client and server. 
Which makes no sense really, so I'd like to put some USE flags here to show 
what I want, or not want to build.


A quick scan through the use flags show no real consistency, so here's what I 
propose


USE client server
client - just build the client - duh
server - just build the server - duh
client and server OR neither then build both.

Other packages to possably beneift
udhcp
mldonkey
samhain
bacula
boxbackup

Interestingly, many packages have a server USE flag but not a client one - 
maybe make both a global USE flag?


Good idea? Bad idea? Thoughts?



My thought is wait until portage-2.2_alpha where we will have default 
USE flags.  Then I can see putting client/server flags up and having 
both be default, letting the user turn off clients and servers in 
/etc/portage/package.use.



Thanks



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Portage-2.1 released

[Alec Warner]

Portage-2.1 final is released,

RELEASE-NOTES[1]
NEWS[2]
BUGS-FIXED[3]
STABLIZING BUG[4]

[1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup
[2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup
[3]http://bugs.gentoo.org/show_bug.cgi?id=115839
[4]http://bugs.gentoo.org/show_bug.cgi?id=136198
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage-2.1 released

[Alec Warner]

Wernfried Haas wrote:

On Fri, Jun 09, 2006 at 12:12:31PM -0400, Alec Warner wrote:


Portage-2.1 final is released,



Congrats to the portage team!

While i'm at it, may i ask which files are affected by these changes /
which docs i missed to read?
* config files as directories enabling more flexible settings
management.


/etc/portage/package.mask/* fex, assuming I am remembering correctly.

Then you can maintain:

/etc/portage/package.unmask/xorg
/etc/portage/package.unmask/paludis
/etc/portage/package.unmask/... you get the picture?



Oh, and -U has finally been killed :-)

cheers,
Wernfried



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Alec Warner]

Roy Marples wrote:

On Friday 09 June 2006 23:34, Mike Frysinger wrote:


On Friday 09 June 2006 16:35, Chris Gianelloni wrote:


This is the "official" (hehe) request for comments on making a policy of
how to handle ebuilds than can be used for either client or server and
how to allow for building client-only.


rather than moving to some sort of policy that satisfies no one completely
and we'll have to back out of later, why dont we wait until portage can
give us proper support for USE=client/server
-mike



So we have two use flags - client and server. Here are the possabilities

-client -server
+client -server
+client +server
-client +server

Do we read -client -server and +client +server to mean the same thing?
If so the logic can read

if use client || ! use server ; then
# build client 
fi

if use server || ! use client ; then
# build server
fi

How does portage stop us from doing that now?



built_with_use is then incorrect, since for -client -server you really 
built both.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Alec Warner]

Lack of content and poorly written or incorrect articles are often
justified by the GWN team on grounds of overwork and insufficient
manpower. When I asked why they were not recruiting, I was informed that
no-one has any interest in contributing.


There's a big difference between one-off articles and continuous
contribution. Also those that I found most willing to contribute had the
biggest language problems - what we need is support from the native
speakers.




Have the GWN posted to -core in a sane time period prior to it's 
release.  I seriously doubt anyone cares about whether the publication 
is always "on time" (whatever that may be).  If it's a bi-weekly 
publication it doesn't always have to go out on the same day, as long as 
you get it out in the general time period.  I sometimes respond with 
corrections/additions but they never make it because it is released 
before my mail is sent.  Often when I see the core mail I don't even 
bother reading it since by looking at the timestamp I can guess it's 
already been mailed.


-Alec
--
gentoo-dev@gentoo.org mailing list