Re: [gentoo-dev] tests
Hi Daniel, Am Mittwoch, 2. Mai 2007 schrieb Daniel Gryniewicz: Honestly, tests are nice, but too many of them are broken upstream, and we are not (and should not be, IMO) in the position of fixing them all. If a developer wants to work with her upstream to fix the tests in her packages, great and more power to her. Most of us are swamped just supporting them, let alone fixing test cases. You really need an upstream who cares a lot about tests for the tests to be meaningful and work. Lots of upstreams don't currently care, and have inherited obsolete and (now) broken tests from previous maintainers. When you read Piotr's original mail carefully, you will see that he lists 'non-functional' as category, and nobody keeps you from declaring your packages' test-suites as such. However, keep in mind that several other maintainers don't have so many problems with their test-suites. I think this thread in general overestimates the value of tests in packages. I think we will find, if we go through the effort, that more of them are useless and/or broken than are useful. My 2 cents. As a member of the sci team I have to say I completely disagree with you here. sci-* packages mostly have reasonable test suites, the importance to run them is very high (you do want reproducable and correct results, don't you?). However, sometimes you cannot run those tests from an ebuild's environment, for example when you need a running x-server. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tests
Am Mittwoch, 2. Mai 2007 schrieb Rémi Cardona: Piotr Jaroszyński a écrit : On Tuesday 01 of May 2007 21:53:36 Maurice van der Pot wrote: I'm not sure why this is a reply to my message instead of the message I replied to. They both provide more or less the same choice to the user. Err I wasn't providing any choices for users yet, I only thought about the below as things that can be wanted by users/devs and asked whether I missed something. How we will end up distinguishing them is another story... - run all tests - run only reasonable tests - run only necessary tests - don't run tests at all Philosophical question : What's reasonable? Where do you draw the line? Same question for necessary. Re 'necessary': Tests for scientific packages are surely necessary, i'd even claim they're mandatory. Nothing is as bad as having a program that yields unreproducable (read: wrong) results. Been there, seen that, had the primordial urge to kill things. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Planning for automatic assignment of bugs
Am Freitag, 27. April 2007 schrieb Robin H. Johnson: On Fri, Apr 27, 2007 at 02:57:59AM +0300, Mart Raudsepp wrote: This is exactly the reason that I proposed the contact=0 attribute - for some of the packages that I maintain, I do not want the bugs assigned directly to me, but to the herd instead. While for others I _do_ want the duplicate. Could contact be named differently then? 'autocontact' then? Both 'assign' and 'cc' (and derivations thereof are not suitable). notification=assignment|cc|none ? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Mittwoch, 25. April 2007 schrieb Ciaran McCreesh: On Tue, 24 Apr 2007 12:31:48 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: printf _rc%d%04d%02d%02d,$RC,$YEAR,$MONTH,$DAY Funnily enough... If we're going by PMS drafts, that's illegal whereas multiple suffixes are legal. PMS permits multiple suffixes, but limits any individual version component to eight digits to avoid problems with integer overflows, floating point precision etc. My point was to avoid providigin existing practice which might need to be respected by either PMS or tree policy. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Mittwoch, 25. April 2007 schrieb Ciaran McCreesh: On Tue, 24 Apr 2007 12:31:48 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: printf _rc%d%04d%02d%02d,$RC,$YEAR,$MONTH,$DAY Funnily enough... If we're going by PMS drafts, that's illegal whereas multiple suffixes are legal. PMS permits multiple suffixes, but limits any individual version component to eight digits to avoid problems with integer overflows, floating point precision etc. And when PMS specifies that together with a proper way to compare multiple suffixes there will be no problem. This Council decission was to avoid 'existing practice' that might be necessary to include in PMS. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Hi all, [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th, 2007] A subset of council members decided today that multiple version suffixes are illegal in the tree pending further notice. This decission can be appealed at the next Council meeting. If there is sufficient public demand, an earlier meeting can be held. This decission has been made to prevent sufficient precedence for unilateral changes to the tree structure. So far the following package versions are considered illegal: media-viode/mplayer-1.0_rc2_pre20070321-r4 media-video/transcode-1.0.3_rc2_p20070310-r1 An illegal version specification of media-sound/alsa-driver has already been removed from the tree. I would like to ask the affected package maintainers to move these versions to sane version specifications as soon as possible. Thanks in advance for this. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Dienstag, 24. April 2007 schrieb Danny van Dyk:
Hi all,
[CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th,
2007]
A subset of council members decided today that multiple version
suffixes are illegal in the tree pending further notice. This
decission can be appealed at the next Council meeting. If there is
sufficient public demand, an earlier meeting can be held.
This decission has been made to prevent sufficient precedence for
unilateral changes to the tree structure. So far the following
package versions are considered illegal:
media-viode/mplayer-1.0_rc2_pre20070321-r4
media-video/transcode-1.0.3_rc2_p20070310-r1
As requested by Daniel (dsd) on irc, let me state what is wrong with
these versions:
All upstream version suffixes may only be used once. This doesn't affect
the -r1 (ebuild revision) suffix, as that is no upstream suffix but
internal to Gentoo's versioning scheme only.
Examples:
* _alphaX_betaY - illegal
* _rcX_preY - illegal
* _alphaX_preY - illegal
* ...
* _{rc,alpha,beta,...}-rX - legal
The rationale behind this is the following:
* certain combinations of suffixes don't make sense.
* only recent Portage versions support it.
If this feature should be allowed again then we need to document a
sensible subset of suffix-combinations prior to adding them to the
tree.
Hope that clarifies it a bit more :-)
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Dienstag, 24. April 2007 schrieb Doug Goldstein: Danny van Dyk wrote: Hi all, [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th, 2007] A subset of council members decided today that multiple version suffixes are illegal in the tree pending further notice. This decission can be appealed at the next Council meeting. If there is sufficient public demand, an earlier meeting can be held. This decission has been made to prevent sufficient precedence for unilateral changes to the tree structure. So far the following package versions are considered illegal: media-viode/mplayer-1.0_rc2_pre20070321-r4 media-video/transcode-1.0.3_rc2_p20070310-r1 An illegal version specification of media-sound/alsa-driver has already been removed from the tree. I would like to ask the affected package maintainers to move these versions to sane version specifications as soon as possible. Thanks in advance for this. Danny So apparently as little as 1 council member can make a decision and it be binding unless appealed to the entire council at the next meeting. No, that's not correct. 1 council member can't do that. During the council meeting of March 8th 2007 the Council decided that at least 2 members are necessary to act for the whole Council. FYI this decission has been made by 3 Council members, which have been Robin, Bryan and which has been initiated by myself. Further, QA indicated approval prior to this council decission. Danny, This wouldn't have to be because you have a vested interest in paludis and paludis does not support this syntax and there happens to be no reasonable way to support that? Doug, a) Paludis could support arbitrary combinations of multiple version suffixes the same way as Portage currently support this. The Paludis developers chose not to, because b) A very large number of possible suffix combinations aren't sensible. Instead of implicitly allowing every possible combination, one should explicitly allow the sensible subset and explicitly disallow the rest. c) I try very hard to seperate my interest and work on Gentoo and the Council and my interest and work on Paludis. Personally, I would appreciate if you got back to me before you make claims as the ones i just responded to. Both claims are wrong: One evidently so (you can ask kloeri and robbat2), for the other you have to trust either me or ask the other Paludis devs. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Dienstag, 24. April 2007 schrieb Steve Dibb: Hi all, [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th, 2007] A subset of council members decided today that multiple version suffixes are illegal in the tree pending further notice. This decission can be appealed at the next Council meeting. If there is sufficient public demand, an earlier meeting can be held. This decission has been made to prevent sufficient precedence for unilateral changes to the tree structure. So far the following package versions are considered illegal: media-viode/mplayer-1.0_rc2_pre20070321-r4 media-video/transcode-1.0.3_rc2_p20070310-r1 MPlayer needs to be fixed, though it's in the same boat as transcode ... it's a release candidate plus a patch level. Multimedia apps are infamous for rarely having releases, so we are stuck with SVN snapshots. What we really need is a suffix for RCS systems, since that's what they really are. However, if anyone has any suggestions for naming schemes in the meantime, I'm all ears. Only a short response, as I'm a bit in a hurry right now. From #gentoo-council earlier: 18:25 @robbat2 make him covert it to _rc%04d%04d%02d%02d,$RC,$YEAR, $MONTH,$DAY I hope that helps, Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Dienstag, 24. April 2007 schrieb Petteri Räty: Danny van Dyk kirjoitti: Hi all, [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th, 2007] A subset of council members decided today that multiple version suffixes are illegal in the tree pending further notice. This decission can be appealed at the next Council meeting. If there is sufficient public demand, an earlier meeting can be held. This decission has been made to prevent sufficient precedence for unilateral changes to the tree structure. So far the following package versions are considered illegal: What is the reason this needed an urgent decision? This was first added to the tree little under three months ago so why not just wait for the next council meeting? *alsa-driver-1.0.14_rc2_p3234 (04 Feb 2007) 04 Feb 2007; Diego Pettenò [EMAIL PROTECTED] +alsa-driver-1.0.14_rc2_p3234.ebuild: Add a new snapshot required for kernel 2.6.20. From my POV: * alsa version commited to the tree, * mplayer version has been commited, * alsa version has been removed, * general discussion started on what combinations are allowed * somewhere in between the transcode version was added My rationale was and is to stop people continueing to add such versions w/o prior discussion. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Dienstag, 24. April 2007 schrieb Jurek Bartuszek: Only a short response, as I'm a bit in a hurry right now. From #gentoo-council earlier: 18:25 @robbat2 make him covert it to _rc%04d%04d%02d%02d,$RC,$YEAR, $MONTH,$DAY Let me see if I have this straight: suppose we have package foo-0.1_rc2 released (very outdated) and we're waiting for foo-0.1_rc3. Then example of something between those two would be foo-0.1_rc000220070313? Would that force portage to update to this version? Wouldn't that prevent portage from enforcing update to _rc3 when it's delivered? Of course I might be wrong and if this is the case then excuse me for the whole fuss ;) Existing _rcX cases can be handled like this: _rc2-rMMDD Portage will update from _rc2 to a version with revision part 0. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Dienstag, 24. April 2007 schrieb Jurek Bartuszek: Existing _rcX cases can be handled like this: _rc2-rMMDD Portage will update from _rc2 to a version with revision part 0. However, _rc2-rMMDD-r1 would *not* be valid anymore, and I think it's quite easy to imagine when this additional -r1 would be neccessary. I'd like to refer you that this is kind of 'best-practice' for the tree. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
Am Dienstag, 24. April 2007 schrieb Piotr Jaroszyński: foo-0.1_rc2 foo-0.1_rc000220070313 foo-0.1_rc3 Leading zeros are ignored (unless in very special cases in the version spec and since a recent portage version also in the revision part), so the above is incorrect - generally spoken. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Am Sonntag, 22. April 2007 schrieb Michael Cummings: On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. FWIW, I've used the $Header $ to determine if a person is looking at the latest greatest or needs to synch up first (in particular when I was dealing with an eclass bug). Very useful when dealing with bugs and you need to confirm that the user is completely synch'd up and looking at a current tree or not (because just asking when the last time they synch'd doesn't help). This can be done using checksum like SHA1 much better, as people can edit their ebuilds/eclasses/profiles and forget/lie about it, and still have the same $Headers$ line. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Am Sonntag, 22. April 2007 schrieb Kevin F. Quinn: On Sun, 22 Apr 2007 17:46:18 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: Am Sonntag, 22. April 2007 schrieb Michael Cummings: On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. FWIW, I've used the $Header $ to determine if a person is looking at the latest greatest or needs to synch up first (in particular when I was dealing with an eclass bug). Very useful when dealing with bugs and you need to confirm that the user is completely synch'd up and looking at a current tree or not (because just asking when the last time they synch'd doesn't help). This can be done using checksum like SHA1 much better, as people can edit their ebuilds/eclasses/profiles and forget/lie about it, and still have the same $Headers$ line. In practice I find it's rare that a user has been hacking around in the eclasses. All the SHA1 tells you is that it's not the most recent, but it's not easy to determine from the SHA1 exactly which version they do have (so it's not enough to determine what's different). Having said that, the most accurate way to find out what they have is to get them to attach the eclass and diff it yourself. However relying on the SHA1 also means you can't just say things like, Check eclass blah is version 1.836 (look at the $Header line at the top of the file). In the case of GIT you can just use 'git diff SHA1SUM' to see what has changed or 'git log SHA1SUM..HEAD' to show a list of revisions in between. So _if_ we changed to git, this would be no problem as long as every user has sha1sum installed [which is part of coreutils]. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 14:09 schrieb Wernfried Haas: If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. Especially as there are council members who don't rely like any privacy in that at all. vapier comes to my mind there :-D Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty: Torsten Veller wrote: * Mike Doty [EMAIL PROTECTED]: apparent decline of QA in our packages. Why do you want this to be a council topic if it wasn't even a topic here or on gentoo-qa@ ? Because our QA sucks and noone is doing a damn thing about it. I disagree. The QA team is doing a lot of work. * Mr_Bones still runs QA checks on the whole tree daily and people are still scared if he pops up and pastes his repoman/pquery output. * Tove still looks out for anything obviously wrong, and he's quite good at constantly buggering people about it. * Other people including myself run different (selected) kinds of QA checks on a case by case basis and usually fix the affected parts of the tree, and sometimes nobody but the maintainers notice that. * You don't need to be a member of the QA project/team to do QA. I say this here, but i think that should be self-evident. * Antarus and spb are preparing to take actions against at least one persistent QA offender, and devrel told them how to do it properly. * QA team, one of its subprojects to be precise, has recently published the draft for Package Manager Specifications. * The work of our QA team is mostly under the hood (and i don't mean sekrit by that!), and that's how it should be done imho. Naturally this can mean that people think they aren't working at all if they don't see flamewars and/or big announcements/blog entries on how they fixed QA problem X. I prefer a silent QA team personally. * There is at least one outstanding QA issue that i know of which is related to Portage and can't be fixed w/o slot deps properly. Read: KDE's problems with ranged deps and the way it currently breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs. * There is a _lot_ of minor QA stuff on bugs.g.o, and everybody (not only QA team members) are invited to work on it. The only prerequisite for helping with it is: Know what you do. If you don't, learn it. * QA _starts_ by such minor things as whitespace problems or proper ChangeLog entries, so there is enough work for everybody out there to help with! If anybody is interested, i can provide you (this is all gentoo ebuild devs*) either with lists of QA problems in the tree to fix, or with tools that enable you to search for one particular (kind of) QA violation in the whole tree, whatever your prefer. Danny *I'm only adressing gentoo devs here as patches against the whole tree don't make sense. The tree changes to fast for it. -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 21:20 schrieb Mike Frysinger: On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? -mike What happened to 1 year? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 23:24 schrieb Brian Harring: On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote: Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty: Torsten Veller wrote: * Mike Doty [EMAIL PROTECTED]: apparent decline of QA in our packages. Why do you want this to be a council topic if it wasn't even a topic here or on gentoo-qa@ ? Because our QA sucks and noone is doing a damn thing about it. I disagree. The QA team is doing a lot of work. * Mr_Bones still runs QA checks on the whole tree daily and people are still scared if he pops up and pastes his repoman/pquery output. Last I knew, bones wasn't part of the QA team anymore. Historically See my comments regard QA team membership and doing QA work. Having a QA team doesn't magically improve the quality of the tree. he's operated as the scary guy who didn't need a team to spank your ass anyways. (that's a joke about him, not the QA team also). pcheck btw, not pquery (former does quality checks, latter is for metadata lookup). And you claim you can recommend to people which tools to use :-) I never claimed i'd recommend your set of tools. This doesn't mean they are inferior, it's just that i can't recommend what i don't use and know. * You don't need to be a member of the QA project/team to do QA. I say this here, but i think that should be self-evident. Agreed, although worth keeping in mind the question specifically was what the QA _team_ was up to; thus would try to address that instead of pointing out non-qa team folk do things. Simple example- I still do a bit of QA, doesn't mean it's even remotely quantifiable as QA team work (which is what he was asking) :) Don't particularly want to get sucked into yet another QA team are lazy slackers discussion, just pointing out bits above. Advice wise, take it or leave. Heh... Meanwhile onto the real meat of the email... * There is at least one outstanding QA issue that i know of which is related to Portage and can't be fixed w/o slot deps properly. Read: KDE's problems with ranged deps and the way it currently breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs. Elaborating a bit, this actually is only a problem for pkgcore and paludis; portage isn't affected since it prefers to try pulling the metadata from $PORTDIR; reasoning is that way screw ups in the metadata that are now locked in the vdb can be worked around via it. AFAIK zmedico spoke about moving portage to use vdb metadata instead. Before this could happen we needed a fix for it. You can trigger the same issue in portage via wiping pretty much everything in PORTDIR (switching the tree, or just a literal rm of everything but profiles crap), but that's fairly corner case. Don't much like the behavior myself, but updates/* would need expansion to address the (massively long term) reasoning for portages behavior. Upshot, running from vdb only instead of the dual lookup would speed up portages resolution via less IO/parsing... Either way, the kde/qt issue was known from the get go- since slot deps weren't available when they started down this path, they should have used new style virtuals instead. Yes it's ugly, backwards compatibility usually isn't utterly pretty- upshot of it however is that the upgrade node is just a new style virtual, no real cost for the operation. Breaking EAPI=0 via pushing slot deps in isn't much of an option in my opinion; usual needs to have been on release media for at least 6 We can push for an EAPI=1 == (EAPI=0 + slot deps)... months would apply here at the very least. The problem is that 2.1.2 is the first portage version to have slot deps- that is a fairly recent stabling, so there still would be a good chunk of time to wait *if* the daft old method of just shoving stuff in and watching things break was took. What breakage specifically? Portage versions that don't support EAPI? Meanwhile, worth remembering during the interim while slot deps aren't usable, new style virtual does address it (even if it's a gross trick) I prefer we solve this problem instead of hacking around it once more. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Freitag, 6. April 2007 00:41 schrieb Vlastimil Babka:
Brian Harring wrote:
Breaking EAPI=0 via pushing slot deps in isn't much of an option
in my opinion; usual needs to have been on release media for at
least 6
We can push for an EAPI=1 == (EAPI=0 + slot deps)...
Can, yep, although that was originally blocked by EAPI=0 must be
defined, which folks seem to have backed off on.
Not sure if slot deps themselves could even replace version ranges
hacks without also solving bug 4315 (native version ranges) in all
cases. IMHO it should be possible at least to specify slot+usual
version limit, to make it worth EAPI bump.
Please have a look at the slot dep format proposal. AFAIK none of the
P{aludis,kgcore,ortage} devs disagreed on that.
One issue with adding EAPI=1 having just slot deps is that it skips
out on some long term changes intended- default src_install for
So what, longer term changes could wait for EAPI=2. Why not make
experience with EAPI bumping with something smaller for a start,
instead of trying to make one big bump that will bring all changes we
can think of now, but will be implemented only in 2010...
I agree fully. Nobody said we can't finetune the EAPI steps/bumps.
Now it may look like I contradict myself saying to bump ASAP but not
without solving bug 4315 first. But I see slot deps without limits
only half of a feature.
Nobody but talked about that.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Freitag, 6. April 2007 00:11 schrieb Brian Harring:
You can trigger the same issue in portage via wiping pretty much
everything in PORTDIR (switching the tree, or just a literal rm
of everything but profiles crap), but that's fairly corner case.
Don't much like the behavior myself, but updates/* would need
expansion to address the (massively long term) reasoning for
portages behavior. Upshot, running from vdb only instead of the
dual lookup would speed up portages resolution via less
IO/parsing...
Either way, the kde/qt issue was known from the get go- since
slot deps weren't available when they started down this path,
they should have used new style virtuals instead. Yes it's ugly,
backwards compatibility usually isn't utterly pretty- upshot of
it however is that the upgrade node is just a new style virtual,
no real cost for the operation.
Breaking EAPI=0 via pushing slot deps in isn't much of an option
in my opinion; usual needs to have been on release media for at
least 6
We can push for an EAPI=1 == (EAPI=0 + slot deps)...
Can, yep, although that was originally blocked by EAPI=0 must be
defined, which folks seem to have backed off on.
EAPI=0 will be defined by PMS once accepted by the council
One issue with adding EAPI=1 having just slot deps is that it skips
out on some long term changes intended- default src_install for
example, hell, making the default phase functions into an eclass
equivalent template. Clarifying, instead of
src_compile() {
default src compile crap
}
would do
base_src_compile() {
default src compile crap
}
That way if you just need to tweak one thing, you can still use the
default src_compile- basically same trick EXPORT_FUNCTIONS does.
What has that to do with slot deps? You can incremently define EAPI=2
and include it there.
Either way, EAPI=1 *should* have a bit more then just slot deps in my
opinion; very least it needs discussion to discern what folks want.
Is there any technical reason why EAPI=1 should be a major step that
includes all we want to get in/get rid off?
months would apply here at the very least. The problem is that
2.1.2 is the first portage version to have slot deps- that is a
fairly recent stabling, so there still would be a good chunk of
time to wait *if* the daft old method of just shoving stuff in
and watching things break was took.
What breakage specifically? Portage versions that don't support
EAPI?
Breakage there I'm referring to trying to is a set of folks
trying to shove it into EAPI=0.
I was not talking about that at all. And yes, i know how you are
refering to. And yes, it's up to the council to decide that.
And yes, there is a bug[1] covering it.
Meanwhile, worth remembering during the interim while slot deps
aren't usable, new style virtual does address it (even if it's a
gross trick)
I prefer we solve this problem instead of hacking around it once
more.
Even with EAPI=1 route, still going to require some time to actually
address it- have to define EAPI=1, make sure portage supports it
fully, make sure it's stable for all arches, etc. That's a several
month proceess, best case, 30 days if somehow everyone agrees to
eapi=1 today, zac implements it tonight, and releases it tomorrow
morning (with no bugs).
Very well. I'd like to target this for KDE people to use it for kde-4.
So... again- it's not pretty, but it's not an issue that's going to
be solved tomorrow, so it's not a bad idea to take a look at ways to
work around it. Very least, if the new style virtual route was
taken, switching over to slot deps (when available) would be easy-
update the virtual, then start pruning the tree for anything
depending on the virtual.
And what about the vdb RDEPENDs on said virtual? That the whole point,
sanitize the vdb metadata.
Danny
[1] https://bugs.gentoo.org/show_bug.cgi?id=170161
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Am Freitag, 30. März 2007 23:13 schrieb Christopher Sawtell: On Saturday 31 March 2007, Ciaran McCreesh wrote: On Fri, 30 Mar 2007 21:13:18 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Thu, 29 Mar 2007 18:50:59 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. You seem to be under the misapprehension that Portage == Gentoo. No no, I'm saying that at present Portage is one of Gentoo's most severe limiting factors. In which case your Paludis fork of Gentoo will take off like a Please, pretty please with sugar atop: Stop this FUD about forking Gentoo. Paludis is not a fork of Gentoo, it's new package manager. The relation between Portage and Paludis can, if at all, probably be compared to dselect vs apt. Don't reply to this mail, just let it drop. Thank you very much. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New ALSA maintainers
Am Donnerstag, 29. März 2007 03:50 schrieb Steve Long: Daniel Drake wrote: I have suggested that herd support for the kernelspace side (alsa-driver) be slowly reduced, by redirecting users who file bugs against it to reproduce with the in-kernel drivers, and then let kernel handle the bug resolution. This will remove duplicated maintenance efforts. This is perfectly reasonable where it is a card with drivers in both, but alas-drivers supports a broader range of hardware, eg the echo audio cards (guess who has one ;) which have never been available in-kernel. Like those in sound/pci/echoaudio/ ? Which have been in there since the commit labelled: 2006-06-28 Giuliano Pochini [ALSA] Add echoaudio sound drivers I guess this is either point c) or point f) of Daniel's list. But he should probably add a bullet point g) Hasn't looked yet. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Am Samstag, 24. März 2007 20:53 schrieb Luca Barbato: Ciaran McCreesh wrote: Which is all very nice in theory, but completely impractical and useless in practice. There's far too much difference and far too much complexity implementation-wise to make this practical for any non-trivial functionality. I'd like to have more details, please. Trivial functionality would be already fine for most of the front-ends IMHO. * Paludis supports multiple repositories, don't know about pkgcore, but i guess they support it as well. Portage doesn't. (actually it has 3 repositories, but that's not really related to multiple repository support) * Paludis handles ENVVARs on a per package basis, Portage doesn't. (no idea about how pkgcore does it) * Paludis repositories aren't necessarily ebuild repositories. This is what comes to my mind right now. The list is certainly not complete :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
Am Freitag, 16. März 2007 23:16 schrieb Ned Ludd: On Mon, 2007-03-12 at 19:15 -0400, Mike Frysinger wrote: On Monday 12 March 2007, Mike Frysinger wrote: Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. sci-mathematics/octave/octave-2.1.57-r1.ebuild:34: sci-mathematics/octave/octave-2.1.69.ebuild:36: ^^ fixed. Must have slipped through in my first round. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
Am Dienstag, 13. März 2007 00:36 schrieb Ned Ludd: instead, since we require bash for our ebuilds, use the builtin `type -p` err i botched that ;) `type -p` is almost a complete drop in replacement for which ... it does not work on bash builtins however, so people should use `type -P` to force the PATH search in other words, `type -p echo` would return while `type -P echo` would return /bin/echo -mike Quick search shows the following ebuilds are abusing this behavior. Matches `which sci-chemistry/molden/molden-4.3.ebuild:30: sci-libs/blas-atlas/blas-atlas-3.6.0-r1.ebuild:33: sci-libs/blas-atlas/blas-atlas-3.6.0-r2.ebuild:34: sci-libs/blas-atlas/blas-atlas-3.6.0.ebuild:28: sci-libs/lapack-atlas/lapack-atlas-3.6.0.ebuild:64: sci-libs/lapack-reference/lapack-reference-3.0.ebuild:52: sci-mathematics/octave/octave-2.1.57-r1.ebuild:34: sci-mathematics/octave/octave-2.1.69.ebuild:36: ^^^ fixed. And matches $(which sci-geosciences/grass/grass-6.2.0-r1.ebuild:111: sci-geosciences/mapserver/mapserver-4.10.0.ebuild:106: sci-misc/boinc/boinc-4.72.20050813-r3.ebuild:56: sci-misc/boinc/boinc-5.2.14.ebuild:57: sci-misc/boinc/boinc-5.4.11.ebuild:53: sci-misc/boinc/boinc-5.5.6.ebuild:59: ^^^ fixed as well. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
Am Dienstag, 13. März 2007 01:14 schrieb Thomas de Grenier de Latour: On 2007/03/12, Ned Ludd [EMAIL PROTECTED] wrote: Matches `which ... And matches $(which ... Also there are some occurences in eclasses: ./eclass/fortran.eclass: elif [ -x $(which ifc 2 /dev/null) ]; then ./eclass/fortran.eclass: if [ -x $(which f2c 2 /dev/null) ]; then ./eclass/fortran.eclass: if [ -x $(which g77 2 /dev/null) ]; then ./eclass/fortran.eclass: if [ -x $(which gfortran 2 /dev/null) ]; then ./eclass/fortran.eclass: if [ -x $(which ifort 2 /dev/null) ]; then ^^^ fixed. And in a few more ebuilds (if which, plus a few weirdnesses): ./sci-libs/plplot/plplot-5.5.2.ebuild: use fortran ! use ifc || if [ -z 'which g77' ]; then ./sci-visualization/xd3d/xd3d-8.2.1.ebuild: which g77 2 /dev/null || die No GNU Fortran compiler found! ^^^ fixed, too. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] stop using $IMAGE
Am Freitag, 9. März 2007 19:08 schrieb Petteri Räty:
Mike Frysinger wrote:
so in your pkg_* functions, use $D, not $IMAGE, to refer to the
temporary install
-mike
[EMAIL PROTECTED] /mnt/checkouts/devmanual $ grep IMAGE -r .
./trunk/ebuild-writing/functions/pkg_preinst/.svn/text-base/text.xml.
svn-base: version in c${IMAGE}/etc//c (see
./trunk/ebuild-writing/functions/pkg_preinst/text.xml: version in
c${IMAGE}/etc//c (see
./trunk/general-concepts/install-destinations/.svn/text-base/text.xml
.svn-base:c${IMAGE}/c.
./trunk/general-concepts/install-destinations/text.xml:c${IMAGE}
/c.
Can you corrent the devmanual then?
Done.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)
Hi Daniel, I'm also curious as to why people should be expected to assign copyright to a group that is known for licence violations and removing attribution from documents. How does this protect anything? Copyright assignment (first to Gentoo Technologies, Inc., then to Gentoo Foundation, Inc.) has *ALWAYS* been Gentoo policy. Not quit true, it *had* been policy: 1) Since the copyright agreement has been taken back by the foundation several gentoo devs joined who never agreed on assigning copyright of their work to the foundation. 2) There are countries who acutally adhere to the Berne Convention (1886). This means even the deed of commiting sources with a Copyright (C) Gentoo Foundation is useless in most countries of the EU. E.g, *none* of the stuff that I ever commited to Gentoo's repositories is copyrighted (solely) by the Gentoo Foundation, due to me being German citizen and writing that stuff in Germany. FYI, there isn't even something like Copyright in Germany. We have an Author's right which agree with the Berne Convention and deviates from copyright in several points. 1) Any material created by Gentoo developers, as part of an official Gentoo Project, needs to have copyright assigned to the Gentoo Foundation, whether or not it is currently included in the Portage tree. This protects all of our collective contributions against misuse, which is why it is policy. As I pointed out above, that's useless. See the Berne Convention and keep in mind that only half of the (active) developers come from the US. 2) Any material not assigned to the Gentoo Foundation cannot be considered an official Gentoo Project. It would not fall under the FUD. Honestly, Gentoo as a project should not care if it is copyrighted to the Foundation. The *Foundation* should strive to work with the Authors on a mutually acceptable way of copyrighting it. umbrella/scope of the development project that is Gentoo, which is in part a legal structure to protect our collective work, (code, logos, etc.) and would be considered a third-party project. I'd be really surprised - flabbergasted, really - if this has changed. But at this point I almost wouldn't be surprised. :) Suprise! :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)
Am Samstag, 3. März 2007 19:48 schrieb Thomas Rösner: Hi, Danny van Dyk schrieb: 2) There are countries who acutally adhere to the Berne Convention (1886). This means even the deed of commiting sources with a Copyright (C) Gentoo Foundation is useless in most countries of the EU. E.g, *none* of the stuff that I ever commited to Gentoo's repositories is copyrighted (solely) by the Gentoo Foundation, due to me being German citizen and writing that stuff in Germany. FYI, there isn't even something like Copyright in Germany. We have an Author's right which agree with the Berne Convention and deviates from copyright in several points. Except that you giving away copyright or donating to public domain is understood by (german) courts to give away usage rights, which is exactly what is intended, no? That doesn't come down to the effects for the Gentoo Foundation: Corporation Foo uses the Gentoo-x86 tree in violation of GPL. Foundation tries to sue them, as they think they have the copyright. Corporation Foo's lawyers say: Uh, you don't even have the copyright on all of gentoo-x86. See the problem? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Am Donnerstag, 22. Februar 2007 14:26 schrieb Brian Harring: On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: On Thu, 22 Feb 2007 04:04:37 + Steve Long [EMAIL PROTECTED] wrote: | I'm saying that until there is an independent implementation, | the specification is worthless and will contain huge numbers of | errors. | | Seriously? Without an implementation, your spec of what should | happen will have loads of errors? Yes. It will describe what people think is allowed, rather than what really is. [snip] Perfect example -- we'd never have caught the multiple sourcing issue without an independent implementation. That issue was caught long ago by the portage branch of ebd (now known as pkgcore) actually, portage-2.1_alpha20050718 being the specific released version (rest where unofficial tarballs). Tree has degraded a bit since then, but already went after the issue a long while back to try and get things cleaned. I'm well aware thats going to be read nya nya, we saw it first; that's not the intention. Intention is to point out that y'all are basically covering territory others may already have, thus potentially making the same mistakes others did. Re: env save/reload mistakes, will address it in a seperate email within next day or so (need to write it mainly). | In process terms, I can't understand why the team working on it | isn't a pkgcore dev (eg marienz if you can't communicate with | ferringb) mild reordering follows b) they're more interested in replacing the ebuild format Pure and absolute FUD; recall which project has added incompatible version extensions, which is dropping running *rm when reinstalling the same ver, which *still* doesn't actually implement overlay logic, leading to overlay authors having to copy master files into each overlay branch. Please have a look at our code before you make such claims. Also have a look at our statements regarding overlays again. Overlays can't be configure properly. Multiple repositories can. Nobody says there should be no sharing between them, but it needs to be configured by the user. Not intending on bashing, point is, pkgcore has *never* pushed replacing the ebuild format, nor realistically changes to the ebuild/repo/configuration formats; implying otherwise is indicative of one being out of touch with reality. Because a) they haven't asked, Oddly enough, asked. Got the we give access to those who are useful response several time over. Bringing up the issue, generally seems to trigger that response. and c) every other time they've gotten involved they've been highly unhelpful. And what on earth do infrastructure have to do with a package manager specification? Wolf31o2 (chris) is releng moreso; one of the few folks doing non-trivial things with the profiles pretty much, with long term experience doing so. In that regard, he's one of a few handful of people who basically could be considered profile experts- further, he's a catalyst monkey, which at least currently, is the stage building method. He said there would be no need for infrastructure to be involved; a claim i back. Nobody said Chris shouldn't be involved, and further more as Chris is a council member he has the opportunity for read-only access or a copy of the PMS repository under the prerequsite that it will not be shared until it's finished. Both kloeri and I have taken this opportunity and we told the other council members in one of the meetings. Somehow I don't think you have the slightest clue what the scope of the document is... The suggetions he's laying out is intended to get multiple folks involved who each have their own specialized domain knowledge. For example, dismissing Chris when he's effectively the profiles guy. Granted, can involve him afterwards, but don't much see the point in *not* doing it up front. Read again, he did not dismiss Chris, he dismissed the claim that Infrastructure should send somebody to discuss the package manager standard. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Am Donnerstag, 22. Februar 2007 17:41 schrieb Brian Harring: On Thu, Feb 22, 2007 at 05:07:22PM +0100, Danny van Dyk wrote: Am Donnerstag, 22. Februar 2007 14:26 schrieb Brian Harring: On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: On Thu, 22 Feb 2007 04:04:37 + Steve Long [EMAIL PROTECTED] wrote: | In process terms, I can't understand why the team working on | it isn't a pkgcore dev (eg marienz if you can't communicate | with ferringb) b) they're more interested in replacing the ebuild format Pure and absolute FUD; recall which project has added incompatible version extensions, which is dropping running *rm when reinstalling the same ver, which *still* doesn't actually implement overlay logic, leading to overlay authors having to copy master files into each overlay branch. Please have a look at our code before you make such claims. I meant the overlay logic, and my share of this discussion is still down the mail. Yet you discussed things I didn't even remotely mention. Further, getting away from the daft FUD we're trying to 'replace the ebuild format' that was leveled. Also have a look at our statements regarding overlays again. Overlays can't be configure properly. Multiple repositories can. Nobody says there should be no sharing between them, but it needs to be configured by the user. master_repository is a new one added within the last two weeks; stand corrected. Repository defaults have been in a little bit longer I think. looking up 2007-01-26 Ciaran McCreesh [EMAIL PROTECTED] * doc/configuration.html.skel, paludis/environment/default/default_config.cc, paludis/util/collection.hh, paludis/util/collection_concrete.hh: Add support for a repository_defaults.conf file. There we go. And what on earth do infrastructure have to do with a package manager specification? Wolf31o2 (chris) is releng moreso; one of the few folks doing non-trivial things with the profiles pretty much, with long term experience doing so. In that regard, he's one of a few handful of people who basically could be considered profile experts- further, he's a catalyst monkey, which at least currently, is the stage building method. He said there would be no need for infrastructure to be involved; a claim i back. Nobody said Chris shouldn't be involved snip Read again, he did not dismiss Chris, he dismissed the claim that Infrastructure should send somebody to discuss the package manager standard. SRC_URI restrictions (port, protocol, etc) are one angle of why at least poking them matters- really depends upon what PMS is going to address, standalone spec, or gentoos form- if the latter, then port/protocol restrictions apply, if the former then those restrictions need to wind up somewher as an extension of the spec. What has that to do with the PMS? PMS doesn't talk about how mirrors should work or how to stage files. It's a spec for the package manager. What you are talking about are implementation details, and even those which are only remotely related to how the package manager handles stuff. This matters once we should ever start writing a Gentoo Distribution Backstage Spec. Re: dismissing chris being seperate from dismissing infra, yep, misinterpretted the phrasing- still would suggest hauling in one of the actual profile/catalyst monkeys however since some of the stuff they have in there aren't well documented. s/well//. And I don't think that anything or anyone speaks or spoke against Chris getting access to PMS and commenting on it. And to reiterate: this holds true for all council members. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] custom-cflags global USE
Am Mittwoch, 21. Februar 2007 18:25 schrieb Timothy Redaelli: Ciaran McCreesh wrote: On Wed, 21 Feb 2007 14:32:56 +0100 Timothy Redaelli [EMAIL PROTECTED] wrote: | What do you think about custom-cflags global USE? I think it encourages policy violations. http://devmanual.gentoo.org/general-concepts/user-environment/index .html I know the policy, but sometimes upstream does not want user CFLAGS, zsnes developers will remove support for Gentoo hosts from their bug reports if i remove custom-cflags use and also mplayer. What about making custom-cflags default in the base profile? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Richard Brown (rbrown)
Am Mittwoch, 21. Februar 2007 20:10 schrieb Stephen Bennett: Please welcome Richard to our ranks, or accuse him of being an evil cabalist (he works on Paludis, particularly maintaining its Ruby bindings), as you see fit. Welcome aboard Richard! Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Am Dienstag, 20. Februar 2007 18:33 schrieb Brian Harring: On Tue, Feb 20, 2007 at 05:22:59PM +, Stephen Bennett wrote: On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Right now I'm placing a higher priority on getting a degree. It'll be done when it's done, which is not now. Council- y'all were after getting this finished as far as I know, perhaps you could discuss intentions? Why? There is work done on this, and there will be further work being done. Several council member have access to it - including me - and are quite confident about what is already done. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Google Summer of Code 2007
Am Freitag, 16. Februar 2007 17:35 schrieb Diego 'Flameeyes' Pettenò: On Friday 16 February 2007, Grant Goodyear wrote: - I don't know what happened to q[u]aludis, nor I care to be honest as it's an external project; For the sake of completeness and correctness: a) It's _qualudis_ ;-) b) David - our SOC student - started his project to mutual satisfaction. However, mid-term he got seriously ill and had to stop participating in GSOC. His work up to this point helped to get qualudis to mostly compile (again) after leaving it dangling during other paludis work. Further he gave some interesting input on how to handle the profiles-to-test internally. c) It's not as external as say rpm or any other unrelated package manager. Also, if you have a look at the AUTHORS file you can count how many Gentoo developers contribute(d) to it, including yourself ;-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Google Summer of Code 2007
Am Samstag, 17. Februar 2007 00:52 schrieb Diego 'Flameeyes' Pettenò: On Saturday 17 February 2007, Danny van Dyk wrote: a) It's _qualudis_ ;-) Whatever, can we get back on track? How much good did Google Summer of Code to the Gentoo _community_ ? How much the project were of use for the Gentoo (Linux) project? Not so much, this very project wasn't completed. (As I wrote in my initial mail) My intentions were to fill in a whole in your list, no more. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] matrox.eclass
Hi,
besides a deprecated call to check_KV, matrox.eclass sets
SLOT=${KV}
which breaks the metadata cache. Any objections to change it
to
SLOT=0
anyone?
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Am Mittwoch, 8. November 2006 16:07 schrieb Kurt Lieber: On Mon, Nov 06, 2006 at 11:25:19PM +0100 or thereabouts, Danny van Dyk wrote: Kurt: Please write up a short text to explain why you think this is necessary for Gentoo mailservers. Thanks in advance! http://dev.gentoo.org/~klieber/spf.txt Thank you very much. I'm reading it right now Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Am Montag, 6. November 2006 20:37 schrieb Chris Gianelloni: On Sun, 2006-11-05 at 13:36 +0100, Jakub Moc wrote: Alin Nastac napsal(a): Mike Frysinger wrote: On Sunday 05 November 2006 05:39, Alin Nastac wrote: Mike Frysinger wrote: that's nice, but again, why arent these being directed to infra ? It could be considered as organization policy, so I assumed council had to be involved in this decision. it isnt ... so file a bug for infra done in bug 154120 . And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. I disagree here. Let's put both items on the agenda. That finalizes the decission. In regard to 'Reply-To:'-munging: I'm going to vote to keep it as is, and i don't think that anybody would be able to convince me otherwise. In regard to SPF: If klieber (or any other infra member) can explain to me why SPF is a good thing(tm) to have for Gentoo Infrastructure, and convince me that it is the best way to go, i'll vote to keep it. Otherwise, i'm going to vote to remove it. Kurt: Please write up a short text to explain why you think this is necessary for Gentoo mailservers. Thanks in advance! Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Am Montag, 6. November 2006 20:37 schrieb Chris Gianelloni: On Sun, 2006-11-05 at 13:36 +0100, Jakub Moc wrote: it isnt ... so file a bug for infra done in bug 154120 . And WONTFIXed in 15 minutes. In that case, I'd like to resubmit it to the council... :/ So because you didn't like the answer from the people responsible for this, you'd rather go over their heads and try to bring this up to the council, so we can override their decisions? Not bloody likely. Uhm, i tend to disagree. I think we should evaluate the situation, and if _we_ think it is the best to override Infra's descision, we can and should do it. A completely different thing is, what our evaluation leads to. I for one would like to take both Reply-To:-Munging and SPF on our agenda. My current thoughts re these topics is as following: - Reply-To:-Munging: My vote: should stay as it currently is. Chris already pointed out how to modify the behaviour using procmail. - SPF: I currently don't understand what it is useful for in the current setup. I would appreciate if Kurt could write up a short text which explains why SPF is a good thing(TM) for Gentoo Infrastructure, so I can understand it :-) My vote would be: Remove, unless there is a real need for it. But this could change rather quickly once Kurt (or anybody else from Infra) has replied. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Council] Summary of the last meeting
Hi all, On behalf of the Council: following a summary of topics discussed during the last Council meeting. (2006/10/19) 1) As requested by Robbin H. Johnson, the Council discussed the member's current involvement with Gentoo projects: Chris Gianelloni: games, gwn, genkernel, catalyst, new profile structure, planning for 2007.0 Robbin H. Johnson: tree-signing, infra (Bugzilla, anon(cvs|svn)) Danny van Dyk: AMD64 releng (testing, soon new profiles) Kingtaco: infra(Bugzilla, anon(cvs|svn), utf8 on pecker) Mike Frysinger:toolchain, base-system Diego Petteno: Gentoo/FreeBSD Bryan Ostergaard: Devrel (Developer stats, fact-finding) 2) Chris Gianelloni had issued a small agenda for this meeting Inter-project communication: Consensus that communication has improved as of late. This covers especially spread information about project work from Portage/Devrel/Infra to the developers. Additionally, the council wants to put meeting summaries on Planet Gentoo and the Gentoo Forums starting with this summary. Design phase for new projects: New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -dev prior to creating the project. This proposal was accepted with 6 members voting yes and one member abstained from voting Devrel etiquette guide: Needs still work before Council can discuss. Rescheduled for next meeting. Bryan Ostergaard will be working on it. QA Policies: Nothing new and QA lead was not available during the meeting. Discussion has been rescheduled for the next meeting. You can find a log of the meeting attached to this mail. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project [21:59] *** robbat2 sets the channel mode to 'moderated'. [21:59] wolf31o2|mobile and I have those profiles mostly done... I've been trying to update them a bit so they're not so far out of date [21:59] wolf31o2|mobile heh [22:00] Kugelfang wolf31o2|mobile: what we could discuss is, when to use it [22:00] kloeri lo all [22:00] wolf31o2|mobile hi [22:00] Flameeyes good, 22CEST here, time to start [22:00] robbat2 heya [22:00] * KingTaco peeks in [22:00] Kugelfang wolf31o2|mobile: care to send them to me in a free minute or two? [22:00] -- diox has joined this channel ([EMAIL PROTECTED]/contributor/diox). [22:00] Flameeyes vapier [22:00] *** Kugelfang sets the channel mode to 'moderated'. [22:00] Kugelfang consider this as start :-) [22:00] Flameeyes so who's starting? [22:01] robbat2 besides wolf31o2's agenda, could we all mention stuff we're working on lately? [22:01] wolf31o2|mobile Kugelfang: well... they're really rough right now... I was planning on sending them to everyone [22:01] robbat2 i've got a few bits on infra things [22:01] wolf31o2|mobile I'll start, if nobody minds [22:01] Flameeyes robbat2, to which detail? [22:01] Flameeyes wolf31o2|mobile, you have the stage [22:01] Kugelfang wolf31o2|mobile: go ahead [22:01] robbat2 wolf31o2|mobile, go [22:01] Kugelfang i hope vapier isn't late again :-) [22:02] wolf31o2|mobile games, gwn, genkernel, catalyst... other than that, I've been working on a set of profiles that allow for multiple inheritance, which I plan on showing to everyone once I've got them mostly workable [22:02] Flameeyes Kugelfang, he was discussing with mcummings on #-dev a while ago [22:02] vapier your mom is late again [22:02] wolf31o2|mobile we've started taking requests for 2007.0 on the gentoo-releng mailing list, so planning for that has begun [22:02] wolf31o2|mobile that's about it [22:03] * wolf31o2|mobile hands the floor to robbat2 [22:03] robbat2 besides the tree-signing (i'll return to it in a moment), I've been working with KingTaco on two infra projects [22:03] robbat2 firstly is anoncvs/anonsvn [22:03] robbat2 it's ready to roll, with the exception of one weird iptables issue affecting bandwidth [22:04] robbat2 until that's solved, you can use it, but it is painfully slow [22:05] robbat2 secondly is the new bugzie [22:05] wolf31o2|mobile yay! [22:05] Kugelfang (yay) [22:05] Kugelfang :-) [22:05] Flameeyes new bugzie or new bugzie setup? [22:05] robbat2 that ones a lot further behind unfortuntely, for a couple of reasons [22:05] kingtaco|laptop you'll get both [22:06] robbat2 originally we were going to go with a cluster-aware FS for the two database boxes, but then found the status of that in Linux (esp the kernels used by infra), was badly lacking [22:07] robbat2 I've come up with another idea instead for the DB stuff, and I've been prototyping it on the fibrechannel gear I have at home, but it may fall over because of some of the bugzilla code [22:07] robbat2 worst case here, is that we can't use both of the DB boxes we've got [22:07] kingtaco|laptop in this way [22:08] kingtaco|laptop remember, they still have local 320 [22:08
[gentoo-dev] [ANNOUNCE] Creation of eselect-1.0.x branch
Hi all, this announce is aimed at everyone who commits to eselect's repository. As of r326, the eselect SVN repository contains a 1.0.x branch. Trunk will now be used for the upcoming 1.2.x release. In future, please * Fix bugs of existing modules in trunk/ and backport them to branches/branch-1.0.x. * Use only modules from branch-1.0.x when you update/bump packages in the tree, as it will take sometime till 1.2.x will hit the tree. Thank you for your attention :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Am Montag, 16. Oktober 2006 00:59 schrieb Alec Warner: Ciaran McCreesh wrote: | | Uh, what kind of conflicting behaviour and what sanity checks are | you talking about here? Did you _really_ miss the whole point of | this feature? Before changing default values for USE flags, arch and release people have to make sure that that change won't do something nasty like introduce circular or built_with_use deps into the default system resolution. I don't see how the location of the default USE affects these things. If I change default USE in my ebuild; I have to do sanity checks. If I change default USE in the profile; I have to do sanity checks *in that profile*. So if your argument is that it's cheaper to check just N profiles ( the profiles affected by my change ) versus all available profiles; then I agree with you on that point. However I still believe there exist examples where default USE in an ebuild is a better solution. From my point of view as an architecture dev and releng member: Having all default USE-flags at one spot (per profile) _is_ easier to maintain. Ciaran has a point here: Default useflags have annoyed me in the past while building releases, and having to change several packages (and redigesting them) for the snapshot is way more: * complicated * time-consuming * error-prone than changing them in the profiles directory. Chris: I'd like to have your thoughts on this. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] *plop*
Thierry, Thanks for your dedication to Gentoo, especially for your persistent work on both the security team and the metastructure reorganisation. I will always remember you for that (and the discussions during FOSDEM '05). Farewell, good bye and all the best to you and your family. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
Am Mittwoch, 11. Oktober 2006 20:36 schrieb Brian Jackson:
On Oct 11, 2006, at 12:37 PM, Zac Medico wrote:
encies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
Yay!
I thought we were eventually going to use that format to specify deps
with specific USE set.
Nope, that was ${CATEGORY}/${PN}[foo].
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Am Sonntag, 8. Oktober 2006 12:05 schrieb Stuart Herbert: Hi Zac, On 10/8/06, Zac Medico [EMAIL PROTECTED] wrote: I'm only proposing that we add support to portage now because it seems like it will be useful in the future. How and when people make use of this support does not concern me much. Zac I believe that multiple parent support would be useful for the Seeds project; it would allow the LAMP Developer Desktop (for example) to inherit from both the generic 2006.1/x86 profile and the LAMP Server profile. Well, once we have that support the structure of profiles will radically change. The following is also something I'd like to be done while i'm in council. This is why i asked Zac to send the RFC to gentoo-dev. Thanks Zac :-) I for one favour a more flattened profiles/ and a way to mark a profile as 'not standalone', similar to a deprecated file, that isn't inherited, to stop users biting their own asses. The following sample is not complete, but should give the right impressions. profiles +-obsolete, which contains the old cascaded profiles. Let's remove | the current obsolete/ contents. | +-default-linux, minimal default useflags here | | | +-linux-2.4, would be handy for x86 :-) amd64 has no supported 2.4 | kernel. | +-hardened, minimal default useflags here | +-default-bsd, minimal default useflags here | | | +fbsd, inherits default-bsd/ | +-base | | | +amd64, inherits base/ | +-releases | +-2006.1, does not inherit anything, stuff like nptl nptlonly here | +-amd64-linux, inherits default-linux/, base/amd64; standalone | +-amd64-hardened, inherits hardened, base/amd64; standalone | +-amd64-fbsd, inherits default-bsd/fbsd/, base/amd64; standalone This is a hot shot and I'm waiting for comments. Wolf? Agaffney? I'm prepared to do the work here and, as this new layout would take some time, it should be done in a seperate repository for the time being. The Seeds project could do something like this: +-Seeds | +-amd64-lamp, inherits releases/2006.1/amd64-hardened and adds lamp specific useflags/packages. But i lack knowledge here. Stuart? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
Hi Tim, Am Samstag, 7. Oktober 2006 23:19 schrieb Tim Yamin: I'm afraid that I find that my position with Gentoo is no longer tenable. Over the past year and especially over the past few months the ability to keep Gentoo a coherent and smooth environment has been eroded and hindered at practically every opportunity by bad decisions, staff, and in some cases, downright incompetence. I'm sorry to see you go, but i cannot agree with you here. More below. It transpires that from the recent barrage of developers leaving, the disquiet and increasing lack of congruence of the developer (and to some extent also the user) communities that something is inherently wrong. I'm leaving it as an exercise to the reader to explore exactly what (if anything) is wrong. Honestly, i think you're showing a weak shell here, but that's my personal opinion. QA and council asked you to do something you didn't like to do, and i still don't understand your reasoning. Please think about this decision over a week or so. Kloeri: Please don't file a retirement bug immediately. Seeing as we have failed to address these challenges over the course of many months and as a result of continuous recent discussions (which half the time end up being totally redundant due to miscommunication) both on -core and on -dev, it is evident that something is wrong with the core management (or lack thereof, depending on your point of view). I no longer have the commitment or desire to follow the road in solving the above challenges. I'm not really sure whether there even is a solution. I'd like to add that I have really enjoyed my time in the past three years working with Gentoo and helping to contribute to the then vibrant and dynamic community. As have I while working with you, especially and mainly in release engineering. Lately however, the fun and the motivation just hasn't been there for the reasons I've outlined above; it's finally taken its toll, and I believe the time to move onto new projects and ventures has finally come for me. As longas you stay away from microphones ;-) I would like to wish all of you the very best, and would like to thank all of you who have (and haven't) made my time here so enjoyable. Thank you very much So long, and thanks for all the fish... I think you oughta know that I'm feeling very depressed :-( Danny, who hopes to see you again next year! -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [ANNOUNCE] Bugzilla Account for Gentoo Council
Hi all, FYI, I just created a Bugzilla account for the Council. You can assign/CC us on bugs via '[EMAIL PROTECTED]'. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
Am Samstag, 30. September 2006 19:02 schrieb Jakub Moc: Mike Frysinger wrote: seriously jakub, stop responding ... you have nothing technical to offer to the issue at hand let the people who work on portage handle it -mike Eh, the whole technical point here is that paludis behaviour differs from portage (and differs from pkgcore, FWIW). This has little to do with why this change to the devmanual has been done. So, hiding the inconsistency via altering the profiles doesn't change anything. Plus, the point of the bug's flame fest was that bugzilla is not a proper place to request such behaviour changes, and definitely not a reason for QA to mess with the profiles. Sticking the stuff in package.mask won't make the inconsistent behaviour vanish in any way, it will just hide it. It is not a behaviour change imho. The packages file changed its meaning subtly after introducing cascading profiles. As ciaranm already pointed out: It is not meant to mask -like versions anymore. It's meant to - Describe the system package set - Define which versions are _at least_ needed for a profile. So, I'd kinda appreciate if concerned folks (including portage and relevant affected arches) were involved in this discussion, instead of sneaking the changes in under QA disguise. Release engineering arch coordinators, which happen to be the people who maintain the profiles below default-linux/ for their relevant arches, have been CCed and Chris already stated that he forgot/didn't realize to fix this problem for no-nptl/2.4's package.mask. Jakub: Please reevaluate the behaviour you showed on both the bug and this mailing list. I for one don't consider it anywhere near appropriate. This shall be no offense, just a comment in regard that you can do better. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New project: Gentoo Seeds
Am Mittwoch, 20. September 2006 23:33 schrieb Chris White: On Wednesday 20 September 2006 13:27, Ciaran McCreesh wrote: I was under the impression that you were supposed to GLEP anything of this scope and get council approval... The anyone can make a project rule doesn't replace the requirement to GLEP large changes. Why? It's in an overlay so it's not actually part of the Gentoo project, Wrong. It is a new (top-level) project. it's using existing methods with a difference in distribution formats Partly wrong. Gentoo/Seeds wants to use stage4 tarballs, among other things. to provide something that will be hopefully usefull to the community. I'm also sorry that you think my flame guide is a ... um.. GLEP(?). I guess I'm enhancing Gentoo by requesting that more llama action be put in GLEPS (rar?). Senseless. What did you want to contribute to the discussion? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Removed net-wireless/{bcm43xx,ieee80211softmac}
net-wireless/{bcm43xx,ieee80211softmac} had been in package mask since
June, as they
* didn't work with recent kernel versions
* were moved into kernel as of 2.6.17.
* were plain obsolete.
I just removed them.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Council] #gentoo-council
Just a short note: The new council will be showing more presence in #gentoo-council. This means: even when no meeting is taking place you can reach us all together on IRC to discuss Gentoo development or to point out problems. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] colon separated variables in /etc/env.d/
Am Montag, 11. September 2006 03:44 schrieb Zac Medico: Hi everyone, Portage currently has two hard-coded lists of variables that control the behavior of env-update. The same applies to eselect env. I'd like to make these variables configurable so that package maintainers have direct control over them. The variables break down into two basic types: colon separated and space separated. Wrong, there is another type of var, namely those which are not cummultative(sp?). What is the best way to propagate information about these two variable types? For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. Variable names not listed in COLON_SEPARATED can be assumed to be space separated. Does anyone have any ideas to share about how this information should be propagated? a) You'd need two variables to store that info, as we have 3 classes of envvars. b) This is in no way related to the package tree. Those vars don't magically change their class from colon separated to non cummultative. I'd like to keep it hardcoded, as loading of such variables can go wrong and you'd end up without a working env tool. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Am Donnerstag, 7. September 2006 11:11 schrieb Stuart Herbert: On 9/7/06, Carsten Lohrke [EMAIL PROTECTED] wrote: How wonderful this sort of maintenance is you can read here: https://bugs.gentoo.org/show_bug.cgi?id=146626 Am I the only one who has a problem with this? No. And I'm sure I'm not the only one who has a problem with your comment in that bug either. Bugzilla isn't there for flaming other devs. There was a time when we used to suspend devs for doing that. Sadly we don't suspend developers for extended history of QA violations. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
The Age of the Universe (was: Re: [gentoo-dev] Gentoo 2006.1)
Am Samstag, 2. September 2006 13:18 schrieb Edgar Hucek: 2.) Enable the use flage accessibility gnome cant be merged. It fails on compile the speech-tools. It seams that USE flags are not realy tested or how can it happen that there are already know bugs in the stable distro ? http://bugs.gentoo.org/show_bug.cgi?id=116030 Festival and the speech-tools are well know not to compile with gcc =4. Well, you know - if you go to read the speech-tools/festival co. bug, and read the ebuild, you'll see that the whole thing and code is one huge mess, that doesn't compile even w/ gcc-3.3 without patching. You'd probably prefer to never put out a new release, I guess? How many people are using this one, and how does it justify delaying the release even more? From my point of view, should it be garanted that a package and depencies compiles when all use flags are enabled. If a depency can't be compiled the use flag and depence should be dissabled/removed from a package. Please _think_ before you make such a demand. Just a small investigation would show this: dev-lang/php-5.1.4-r6 has _96_ USE flags. That makes 2^96 = 7.9928+28 combinations. Given the (unreasonable) assumption that each compilation would only take 1s and each compilation would actually succeed, you'd still have ~8e28 seconds. The age of the universe is approximately 4e17 seconds. This hasn't yet investigated allt he possible combinations of packages depending on dev-lang/php, or the ~10,000 other packages in the tree. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] repoman: check for deprecated eclasses
Am Freitag, 1. September 2006 17:05 schrieb Alec Warner:
Stefan Schweizer wrote:
Hi,
Repoman needs to check for deprecated eclasses, see
http://bugs.gentoo.org/141677
As a result of the discussion in the bug, we would like to add
$PORTDIR/qa-data/eclass.deprecated
to allow to deprecate eclasses properly and make repoman fail.
This will allow us to avoid problems with new ebuilds for
deprecated eclasses which result in bugs like
Bug 141629 dev-util/systemtap-20060325.ebuild uses deprecated
kernel-mod.eclass
I believe the developer has not known anything about that
kernel-mod is deprecated when making that ebuild. Now he ignores
the bug and we have that old eclass used again :(
Best regards,
- Stefan
I would prefer to see a patch for this first, and then modify
gentoo-x86 second; but I agree in principle. What of the
conversation about 2 files, one for this eclass is currently being
deprecated - repoman warning; and this eclass is no longer usable
- repoman failure.
Also the deprecated - new-eclass mapping. Afaik that didn't go so
well for me; but I still like it ;)
old new
- --
foo.eclassnew-foo.eclass
We don't need a new file for that IMHO. I'd propose to add something
like
ECLASS_DEPRECATED=${ECLASS_DEPRECATED} foo
ECLASS_REPLACEMENTS=${ECLASS_REPLACEMENT} new-foo
to foo.eclass. In my eyes this is much less work as repoman merely has
to check for 2 envvars.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] repoman: check for deprecated eclasses
Am Freitag, 1. September 2006 19:37 schrieb Brian Harring:
old new
- --
foo.eclassnew-foo.eclass
We don't need a new file for that IMHO. I'd propose to add
something like
ECLASS_DEPRECATED=${ECLASS_DEPRECATED} foo
ECLASS_REPLACEMENTS=${ECLASS_REPLACEMENT} new-foo
to foo.eclass. In my eyes this is much less work as repoman merely
has to check for 2 envvars.
As much as I'm a fan of embedding the metadata into the object
itself, this sucks; reliant on either
1) grepping it out of the file (which means there is the potential
for rare false positives to occur).
Correct, i don't like to grep for it.
2) bastardizing inherit to grab it, thus forcing a sourcing for every
single ebuild regardless of staleness
Exactly.
Your example above seems to indicate preferring #2, which folks will
probably tell you to get stuffed on, forcing a regen of the packages
they're examining they won't like (will slow repoman down even
further).
Well, one has to decide between functionality and speed at times. I
think it's better to have the ebuild sourced on every run instead of
sourcing it only when it cache is stale.
Also, the new-foo renaming can't be reversed cleanly; consider if the
old class was kernel-mod, new class is kernels, how do you know where
to split old/new? You can search ECLASS_DEPRECATED, but potential
for collision there makes it a crappy option, in the previous example
consider if kernel-mode and kernel were two deprecated eclasses, it
would falsely label the new class as mod-kernels.
ECLASS_DEPRECATED=${ECLASS_DEPRECATED} foo:new-foo,new-foo-modules
Meanwhile; I'd just stick a file up somewhere on gentoo.org, and
mangle repoman to pull down a copy every N days as needed and have it
use that; code can be reused from metadata.dtd usage.
I like this option better than sticking another file into the public
tree that no user will ever need.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 39 compliance
Am Mittwoch, 30. August 2006 14:26 schrieb Alec Warner: Eselect, your project pages lists retired developers (Ciaran).[4] Ciaran is the original Author, and he still helps more than ocassionally with problems and bugs. I won't remove him from that page. As precedences, the Gentoo Handbook list of authors contains former Gentoo devs. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for cleaning portage a bit (themes and other eyecandy stuff)
Am Samstag, 19. August 2006 04:11 schrieb Michael Cummings: Ciaran McCreesh wrote: On Fri, 18 Aug 2006 08:44:04 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | What would be more interesting is something like | app-portage/g-cpan for various themes sites. This way, individual | themes wouldn't need to get packaged and maintained. If anyone's looking to experiment with this kind of thing... Paludis supports multiple repository formats. We're already supporting CRAN, and we might do CPAN, really? i thought you told me in irc we weren't worth it or something like that...honestly not trying to troll or incite flame, you gather enough of that, but last we spoke about incorporating g-cpan like functionality into paludis on irc, it wasn't worth your time (choice expletives were used). from the gist of that conversation, paludis was not up to this job if the repository didn't fit some rather strict guidelines. Actually, the conversation was more like: ciaran) What do we do next? CPAN? CTAN? kugelfang) let's ask mcummings for CPAN help. The deps can't be easily resolved iirc. mcummings) no other way, meta.yml isn't always there, and even g-cpan.pl needs several runs, and might even get the deps not correctly. ciaran) screw it then. kugelfang) CTAN? no deps at all. ciaran) screw it. From my POV those screw it were related to 'what do we do next', and not CPAN. Especially as CPAN wasn't the only option in consideration. In regard to the to the 'strict guidelines' and 'paludis not up to the job'. We _could_ implement it, but none of the possible implementations is really elegant. We considered these possibilites: * using an external repo, that autogenerates the dep information _after downloading all of CPAN_. (yes, that would be necessary) * g-cpan mode of autogenerating the builds, where the distfiles need to be downloaded recursively at dep-resolution time. Just to get the facts straight. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
Am Mittwoch, 9. August 2006 17:50 schrieb Mike Frysinger: On Wednesday 09 August 2006 10:57, Duncan wrote: Mike Frysinger [EMAIL PROTECTED] posted Pure speculation here, but the idea /might/ have been to separate prebuilt binary stuff into /emul, so it wouldn't conflict with future multiarch portage support (which would presumably use /lib32), which IIRC was hoped to be here by now, but turned out to be rather complicated and had no portage devs which had that particular itch they needed to scratch, so... (IOW, no blame or finger pointing, just that we'd hoped it'd be here by 2.1, and it isn't, and that's a fact amd64 continues to have to deal with.) from what i remember, /emul was done because that's how some other distro was doing it ... but at the time i was staying out of multilib development because it sucked and i didnt have an amd64 now i have an amd64 and this current state annoys me greatly, so rather than bitch all the time, i want to fix it Herbs is maintaing the emul-libraries. IMHO it shouldn't be to hard to change it from /emul to /lib32 and /usr/lib32. And yes, /emul was there from the very beginning aka Tester/brad_mssw :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Brand spanking new developer - Anrdrew Ross aka aross
Am Dienstag, 8. August 2006 13:00 schrieb Christel Dahlskjaer: Well, well.. who was I to complain when Gentoo had to fly me to Melbourne, Australia to check out our newest recruit. Like a scene out of Home and Away (ok, it's the only Australian TV show I know) we swam with dolphins, we ran along the beach.. *snap* Ok, so Gentoo didn't fly me to Oz, not that I would have complained if they did.. but we did gain another australian developer. The name is Andrew, Andrew Ross. He takes it shaken, not stirred. Studies Computer Science, admins Gentoo servers for a living (how sick of this will he get?), reads scifi and fantasy, spends time with his girlfriend; Fiona. For us he will be maintaining xen alongside chrb and agriffis, considering latching on to the hardened team in a bit and may offer a hand or two to the zope team. Not to forget he's working on an eselect module for app-admin/logrotate. Welcome aboard, Andrew! Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
Am Samstag, 5. August 2006 11:19 schrieb Kevin F. Quinn: On Sat, 5 Aug 2006 02:39:16 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: Am Samstag, 5. August 2006 02:11 schrieb Kevin F. Quinn: At the very least, ebuild maintainers and ATs should be running with tests switched on. If the tests are known to fail then the ebuild can either RESTRICT=test, or just return successfully from src_test() where the test report is useful even if some tests fail. Thoughts? * autoconf takes ages (longer than compiling glibc here). * glibc tests fail on amd64 since at least a year. * automake|e2fsprogs|neon|gettext|tar have failed tests for me more than once. As soon as these are fixed, i wouldn't mind making FEATURES=test a default. Well, if something fails its tests but you still want it regardless or you want to skip the test phase for some other reason, you can always do FEATURES=-test emerge foo. Changing the default doesn't prevent people from skipping tests, however in the long term it will reduce the amount of stuff committed to the tree that doesn't pass tests. It will increase the amount of times a system or world update falls over, but changing the default will raise the priority for getting these things fixed. There are many packages in the tree for which it is clear the maintainer did not even attempt to run the tests - e.g. https://bugs.gentoo.org/show_bug.cgi?id=139414 To my mind committing packages without even bothering to try the test phase is inexcusable. Something? Please re-read the list of packages that fail tests: * glibc * autoconf * gettext * tar That makes _4_ system packages. Before I would consider making FEATURES=test a default, I would add least want the system set to actually merge with it. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
Am Samstag, 5. August 2006 02:11 schrieb Kevin F. Quinn: At the very least, ebuild maintainers and ATs should be running with tests switched on. If the tests are known to fail then the ebuild can either RESTRICT=test, or just return successfully from src_test() where the test report is useful even if some tests fail. Thoughts? * autoconf takes ages (longer than compiling glibc here). * glibc tests fail on amd64 since at least a year. * automake|e2fsprogs|neon|gettext|tar have failed tests for me more than once. As soon as these are fixed, i wouldn't mind making FEATURES=test a default. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] webdav global use flag and default
Am Freitag, 28. Juli 2006 10:18 schrieb Stefan Schweizer: Hi we currently have both webdav and nowebdav ueflags, this is confusing: # grep webdav /usr/portage/profiles/use.local.desc dev-util/git:webdav - Adds support for push'ing to HTTP repositories via DAV dev-util/subversion:nowebdav - Disables WebDAV support via neon library net-misc/sitecopy:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. This system allows users to collaborate on websites using a web based interface. See the ebuild for an FAQ page. Enables neon as well to handle webdav support. www-apps/open-xchange:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. www-servers/lighttpd:webdav - Enables webdev properties The proposed solution is to make webdav a global useflag and set it as a default use flag to have the same effect as the current nowebdav use flag in subversion. 5 packages, and only one has nowebdav, and you want to make it a default USE flag? I strongly disagree here. Make it a plain useflag and notify users of subversion that the behaviour changed. Much better than informing users of the other 4 packages that the behaviour changed. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Am Mittwoch, 12. Juli 2006 15:23 schrieb Matthias Schwarzott: On Wednesday 12 July 2006 15:16, Danny van Dyk wrote: Hi all, While reading your list I have seen pcmcia often. e.g. on my ebuild v4l-dvb-hg not supporting pcmcia as conditional. A bit digging showed that linux-mod.eclass contains this code: --cut-- IUSE= # don't put pcmcia here, rather in the ebuilds that actually support pcmcia SLOT=0 DESCRIPTION=Based on the $ECLASS eclass RDEPEND=kernel_linux? ( virtual/modutils pcmcia? ( virtual/pcmcia ) ) --cut-- I don't know if pcmcia should then be added to every ebuild including linux-mod.eclass. Please solve this before adding pcmcia on every kernel-module-ebuild. I've ceased adding pcmcia to IUSE after 3 commits. genstef will be talking with kernel team about this. I'd suggest to split the pcmcia dep to a different eclass, but that's just my opinion. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Am Mittwoch, 12. Juli 2006 17:00 schrieb Aron Griffis: Danny van Dyk wrote: [Wed Jul 12 2006, 09:16:30AM EDT] There are 505 ebuilds which are missing use flags in IUSE that they use in other places. Much of those 505 violations are a missing pcmcia flag, which i stopped to fix once i was notified of pending linux-mod.eclass bug. I once wrote a script (attached) to update IUSE automatically. To use it, simply: $ cd games-emulation/xmess $ fixiuse It reports what it changed, and give you a resulting repoman commit line which you can cut-and-paste. Thanks very much, but all violations have already been fixed :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Am Mittwoch, 12. Juli 2006 15:36 schrieb Jakub Moc: Danny van Dyk wrote: Wrt the pcmcia thing, well not really ebuilds' fault, see http://bugs.gentoo.org/show_bug.cgi?id=122868 Yeah, genstef is working on it. There are already bugs filed for some of the rest, please go fix them ;) http://tinyurl.com/glq4m going to. http://bugs.gentoo.org/show_bug.cgi?id=136953 The arch stuff (x86, amd64...) - well I don't really think they should be in IUSE. Here's a log for the rest, without the arch flags: Nobody talked about adding those to IUSE. The log says that usage of '!arch' _maybe_ a QA problem. QA people need to check those manually. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
OK, this rfc/proposal is competing with Flameeye's proposal: I suggest to add a CPUFLAGS USE_EXPAND variable to the tree. This should be set to sane defaults in the profiles. I.e. for x86, it should not set CPUFLAGS at all, and on AMD64 it should be CPUFLAGS=mmx sse sse2 I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty, and ppc/ppc64 should set CPUFLAGS=altivec. The main reasons for a USE-like implementation om contrast to Diego's proposal are: a) There is no call to gcc involved, but only a call to use(). This allows usage in metadata phase. b) There is no implicit (non-transparent) choice made for the users. c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo) with the purpose of optional codepaths. I know, there aren't use-based deps in portage yet, but I really feel uncomfortable to be unable to use cpuflags in metadata phase. This is what worries me most. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Am Freitag, 7. Juli 2006 16:19 schrieb Diego 'Flameeyes' Pettenò: On Friday 07 July 2006 16:20, Danny van Dyk wrote: I suggest to add a CPUFLAGS USE_EXPAND variable to the tree. Improvement respect the current situation? You're just asking for the same exact treatment that is in place now, but changing its name like it is a change... USE_EXPAND useflags do not need to be added to either use.desc nor use.local.desc. Further, we keep track of other hardware-related metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
Am Dienstag, 4. Juli 2006 21:04 schrieb Mike Frysinger: from current council: koon / agriffis / azarah / seemant / solar some other peeps: Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg Thanks, I accept this nomination. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Last Rites] app-text/bow
* No maintainer. * It is a library w/o executable in the tree (would be Rainbow, Crossbow or Arrow). * It has one open bug (#88302). * No upstream release since 2002, so little chance to fix bug #88302. app-text/bow is already masked, pending removal in 30 days unless someone steps up to maintain it. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Hi Kumba, In a similar vein, will this eselect tool eventually supplant the functionality of binutils-config as well (and thus need its own wrapper script)? Have a look at eselect binutils please, which is shipped with app-admin/eselect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Hi Diego, It's sub-optimal compared to eselect compiler, x86_64 ld does not work with i686. eselect binutils should be as capable as binutils-config. AFAIK the stated behaviour is no regression. If it is a regression, please file a bug against it. If it isn't, file a bug for an enhancement request. I'm quite positive we can get it going. :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer: And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. Only when you got FEATURES=collision-protect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer: And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. That is only true, if you have enabled FEATURES=collision-protect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer: And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. Only when you have FEATURES=collision-protect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Am Montag, 5. Juni 2006 18:03 schrieb Stefan Schweizer: today I would like to propose a few default keywords for removal. keywords? They are outdated and no longer needed on current systems: -fortran - Do we really need this outdated language as a default in gcc? Remove this and you'll break merging of approx. 30% of the ebuild in scientific herd. As long as there is no use-based deps, fortran should stay in default. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 27 Proposal - Feedback Requested
Hello Mike, Am Dienstag, 30. Mai 2006 05:29 schrieb Mike Kelly: I'm Mike Kelly, one of the SoC-ers. I'll be working on GLEP 27 for the summer. Right now I'm looking for some basic feedback on my proposal. In particular, I know that at one point there was a push for the user info files to be XML, but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), since my plan was to write the core of the implementation in shell (e.g. as an eclass). From your proposal: - Add code to the eutils.eclass which will detect if the installed version of portage supports the new system, notifies the operator that the current ebuild is using depreciated code, and properly add the user using the new system's code. This would check for the proper EAPI version to know when to execute the new code instead. As a member of Release Engineering who encountered already a problem with user-management code in eutils.eclass, i beg you: _plase_ don't add it to that eclass. Instead, create a new eclass 'euser' or something similar and add it there. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] New eselect modules for blas, cblas, lapack
Hi Donnie, Am Freitag, 26. Mai 2006 05:20 schrieb Donnie Berkholz: With great pleasure, I announce the testing release of new eselect modules for BLAS, CBLAS and LAPACK implementations. You may say, But we already have 'eselect blas' and 'eselect lapack,' Donnie! What are you thinking? In reply, I would say, The current eselect modules have many limitations. And rightfully so! :-) Thanks for all your efforts here, it is really appreciated. One of the main problems with the existing setup is that available implementations are hardcoded into the modules rather than being autodetected from the system. This just doesn't scale well, and it ties upgrades and changes to BLAS/LAPACK/whatever into a required update of eselect. A point of disagreement between Danny van Dyk (Kugelfang) and myself is handling systems with multiple libdirs (e.g., AMD64). To understand our quandary, you'll first need to understand how the new modules work. My opinion is that if you want to switch implementations, you should be warned if any available libdir failed to switch to the implementation you selected. The tradition of Unix tools says they should be silent when everything works as expected and be loud on errors. Right, emphasis on error here. Not switching for all libdirs when you explicitly said you wanted to switch your whole system is an error, even if the implementation isn't currently available for all your libdirs. Anything else will require adding hackish special cases to the code and doesn't fit with my model of how the modules should work. See, i don't see the explicity of 'all libdirs' when not specifying any libdirs at all. In my eyes, 'eselect blas set acml' doesn't mean: 'switch to acml in _all libdirs_', but 'switch to acml in _all libdirs it is installed to_. Danny thinks instead that the modules should list all libdirs for which the implementation was changed rather than warn about libdirs for which it wasn't. This opposes the Unix philosophy. Danny also thinks that the modules should silently fail when no implementations are available for a certain libdir when the user wants to switch the whole system. I disagree and think the modules should warn the user. In addition, Danny brings up a specific subprofile on amd64 called no-symlink, in which lib32, lib, and lib64 are all directories rather than symlinks. He says the 'lib' directory is only for arch-independent (ABI-independent) files, so we should also add a special case for that. Knowing my hatred of special casing, you may guess I disagree. Motivation for this special casing is, that this warning would appear any time the user doesn't specify the libdirs, and there is nothing the user can do against it. There just is no way to install any blas/cblas/lapack implementation to /usr/lib on no-symlink profile. I'm strongly against warnings that can't be turned off. Futher, this would be no additional special case, it can easily be merged with the previous special casing: only swithch on libdir that the package is installed to. The main issue needing resolution is whether to warn on failures to switch given libdirs when trying to switch the whole system, or whether to say which successfully switched. One way is the Unix philosophy, and the other way is ... something else. :-) Without further ado, you may get all the ported BLAS/CBLAS/LAPACK implementations as well as the new eselect modules from my overlay [1]. They will remain there until more widespread testing is completed. Donnie: RFC: should ACML be modified to install both ABIs? (i.e. x86 and amd64). I'd say no, as no packages but glibc/gcc/binutils currently do that. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cmake.eclass
Hi Carsten, Am Donnerstag, 25. Mai 2006 13:31 schrieb Carsten Lohrke: Don't repeat a failure of the past. Do NEED_CMAKE x.y inherit foo ... instead this ugly toplevel function call. And this is no ugly toplevel function fall? i currently see no major difference between doing 'need-cmake x.y' and 'NEED_CMAKE x.y'... Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cmake.eclass
Am Freitag, 26. Mai 2006 00:50 schrieb Panard:
I removed need-cmake function and add :
if [ ! -z ${NEED_CMAKE} ]; then
DEPEND=dev-util/cmake
else
DEPEND==dev-util/cmake-${NEED_CMAKE}
fi
RDEPEND=
is it ok ?
Rather use
DEPEND=dev-util/cmake-${NEED_CMAKE+-${NEED_CMAKE}}
please.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cmake.eclass
Am Freitag, 26. Mai 2006 01:10 schrieb Danny van Dyk:
Am Freitag, 26. Mai 2006 00:50 schrieb Panard:
I removed need-cmake function and add :
if [ ! -z ${NEED_CMAKE} ]; then
DEPEND=dev-util/cmake
else
DEPEND==dev-util/cmake-${NEED_CMAKE}
fi
RDEPEND=
is it ok ?
Rather use
DEPEND=dev-util/cmake-${NEED_CMAKE+-${NEED_CMAKE}}
please.
Sigh, too tired. I meant
DEPEND=dev-utils/cmake${NEED_CMAKE+-${NEED_CMAKE}}
of course.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] I'm retiring
Rob, Am Mittwoch, 17. Mai 2006 21:56 schrieb Rob Holland: As I've done very little Gentoo work in last few months and have generally lost interest in Gentoo, I'll be retiring. If you need to reach me you can find me at [EMAIL PROTECTED], or on IRC where I'll continue to sit in #gentoo-audit. Credit to the security/audit team for being fun and interesting enough that this didn't happen earlier, despite my lack of enthusiasm for Gentoo as a distribution now. I'll continue to sit in the sec/audit channels and generally be available there as best I can. Please close any accounts I have, and if possible, change my bugzilla account to be [EMAIL PROTECTED] All email/home stuff can go. Thanks, and maybe cya around :) It's sad to see you go, but i'm at least happy you will stay in touch. I which you all the best for whatever you'll be doing next. :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Am Dienstag, 16. Mai 2006 20:35 schrieb Gustavo Zacarias: Stephen Bennett wrote: That's my proposal. The benefits I like to think are obvious. The drawbacks are, as far as I can see, in tree size, which should be minimal. Those concerned about local tree size can exclude it, and for size on the mirrors it's trivial compared to the rest of the tree. Comments? As long as it's outside the stable (200x.y) portage profiles i'm fine with it for SPARC. I think Ferris was testing paludis so i'm sure he can handle it. With respect to the hey support omg! comments i say stick a big fat README about being an experimental profile or something like that and that's it. Usually bug reports require emerge --info so it'll be easy to flag invalid ones anyway. [Disclaimer: I'm involved in paludis development and may be biased] I talked with the other AMD64 leads about adding a paludis subprofile to default-linux/amd64. Blubb said he'd rather have a global profile, Kingtaco state to be neutral in regard to adding another amd64 subprofile. I'd rather have a global profile, too. Summary: amd64 team can live with a paludis profile, we prefer to have a global profile, though. PS: As a sidenote to people who test or play with paludis and find packages that don't compile/install: Please don't file bugs with gentoo. Come to #paludis and discuss with us. If we tell you to do so, file bugs with [EMAIL PROTECTED] We are really interested to know which packages don't work. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New ebuild Developer: Christian Hartmann (ian!)
Hi, It is my pleasure to announce publicly that ian! has passed all necessary quizzes to touch our holy gra^H^H^H portage tree. He'll be helping mcummings in his perpetuate combat with perl and its dependencies. May the source be with him. Congratulations Christian! :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Renewed security risk uhm Dev
Hi list, [Yik, another belated announcement. I'm a slacker :-)] It is a personal pleasure to announce that Stefan Cornelius, one of the Operation Lead Developers of the Gentoo Security Project has passed all necessary quizzes to fiddle with the tree. Beware!!!one! Stefan, congratulations! Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: bbj
Hi list, [Another late one. You know already, I'm a slacker] Please help me to welcome Benigno Batista Júnior aka bbj, the latest addition to the growing population of the Gentoo/ALT Project. bbj is located somewhere between Sao Paulo, Rio de Janeiro and Minas Gerais (Related to Minas Tirith? ;-)). His current work is a research job at the Federal University of Itajubá where he tries to build Cylons^H^H^H neural networks. At least this is more exciting than his brother's job who's a math professor. bbj, welcome aboard! Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
Mike, Am Montag, 3. April 2006 23:38 schrieb Mike Frysinger: dont get me wrong, i hate documenting common sense as much as the next sane guy, but it seems Gentoo has come to the point where this needs to be done many thanks to the Ubuntu guys and to solar for doing the real work here: http://dev.gentoo.org/~solar/xml/conduct.html i dont see how anyone can be against this (unless you're a terrorist!), so this is on track to be integrated as-is into the dev handbook Etiquette section -mike Well, you're wrong. I'm against this conduct in its current form and I am no terrorist. Further, i really dislike how you tried to avoid public discussion by deeming everyone who disagrees as a terrorist. There are several occasions where a Gentoo developer is asked to initiate publis discussion when he introduces something that affects the whole tree. The council demands 14 days to publicly discuss GLEPs that shall be voted upon. But when a document which has such a great impact as this conduct you (and others) propose, and which is possibly controversely discussed among developers, is just passed by w/o discussion I really start wondering if the community aspect (which is emphasized by this document) is really of interest to you. I understand that you're not happy with the status of developer relation (not to be confused with Gentoo DevRel) right now, but please choose another way. I don't agree with some of the wording of the conduct, mostly with the last paragraphs. For example: Repeated disruptive behaviors will be viewed as a security and stability Who is to judge what behavior is disruptive? threat to Gentoo. Your access to Gentoo infrastructure may be suspended without notice if it is deemed that you fall into this category. If your This would allow to infra to say: I don't like your way, you're disruptive! Your access will be suspended. And honestly, i think this is what just happened. account is suspended, you will still retain full developer status -- you will simply not have access to Gentoo infrastructure. You may continue to do development work during your suspension. You may elect to save up your This is awful: Oh, a suspended developer is _allowed_ to not give his things out to the public. Please change remove this first part of this sentence completely. changes until such a point where your access has been reinstated, or you may work with another developer to have them commit changes on your behalf. If you choose the latter option, please ensure members of the Infrastructure project have reviewed and approved the proxy relationship to avoid having access cut off for both developers. IMHO, this is rediculous as well. We already had this discussion during the last incident. Infrastrucure has no hold on what and how developers commit user contributed changes, as long as these changes are lawful (read: license/copyright problems) and no security thread. It's infras job to enforce the permissions as given by devrel. If devrel says, somebody is allowed to commit in the main tree, nobody but devrel should be allowed to revoke this. The only exceptions are those case already stated above. This is how it has been handled so far except in the ciaranm incident. This is how I personally think this should be handled in future. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
Hi Stuart, I'd like to comment on some of your plans for overlays.g.o. Am Mittwoch, 22. März 2006 23:03 schrieb Stuart Herbert: It's probably the right time for me to flesh out what I've been planning for overlays.g.o. The vision I have for overlays.g.o is one official home for all Gentoo overlays run by projects and by individual Gentoo devs. I see the Also for Arch/Herd Testers? homepage itself running Planet (just like planet.g.o), using the RSS feeds from the overlays to display the changelogs from all the overlays. The links down the left hand side of the page go to the homepage for each of the overlays. The homepages are separate wiki instances. Well, there is a couple of Gentoo devs who are not particularly comfortable with wikis (including myself). Why change things the way they are currently? I'd suggest to use one repository per project and to add a 'website' or 'site' directory. In this case we could use the good ol' GuideXML/SCM combination. http://overlays.g.o/proj/project-name/ for overlays run by herds listed in herds.xml http://overlays.g.o/svn/project-name/ for the SVN repos and Like above: use http://o.g.o/proj/project-name/ for the information content and http://o.g.o/proj/project-name/svn/ for the overlay. http://overlays.g.o/dev/developer/ for overlays run by individual developers http://overlays.g.o/svn/developer/ for the SVN repos same as above :-) There's a practical limit to the amount of software we can support on overlays.g.o. The less we install, the less the overhead of administrating this system for infra and the overlays admin team (I'm looking for responsible volunteers to join that team, if you're interested). Another reason for dropping the wiki I'd like to offer two wiki engines and two version control systems on overlays.g.o. I believe that gives us enough choice without us loading the box with too much software for us to keep on top of. In case we use wiki, why _two_ wiki engines? To answer Daniel's question about official ... the overlays hosted on overlays.g.o would be official. The overlays project will be accountable for overlays.g.o overall. It would make sense for the overlays project to be a sub-project of infra. To ensure officialness and (what I personally care more about) accountability, project overlays will be created for projects that meet the description of a project in the metastructure [1]. The overlays team will have to be strict on this, to ensure officialness. The overlay must be requested by one of the leads of the project. The lead(s) would be jointly accountable for the overlay and all its contents. Leads will be able to ask for commit / wiki edit access for non-devs. Please consider also to let QA and Security have commit access to all overlays (If they're so inclined). Developer overlays would only be created for active Gentoo developers, and they would be accountable for its contents. Non-developers will not be given write access to developer overlays. By default - working on the same principle of trust that governs all developers w.r.t. the Portage tree - all developers will be able to commit to all overlays. If we can't trust you to respect other people's overlays, then we can't trust you with commit access to the Portage tree, and you're not fit to be a Gentoo dev in the first place I would say this should be clarified some more. Surely anybody with an access to an overlay can commit, but the projects should be the keepers of the keys. Overlays are not the tree, they are probably very experimental. I could imagine that i wouldn't want anyone to modify say an experimental gcc ebuild from toolchain's overlay for example. Stuart: Overall, i like your proposal. I would suggest to turn it into a GLEP and I'm willing to help you with this. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: Karol Pasternak (reb)
Ladies and Gentoo-men, [This announcement comes a bit late, sorry :-)] It is my honour to proudly present you Karol Pasternak, also known as reb. Karol lives in Koszalin, Poland and turned 20 some days ago (I hope you had a happy birthday). Besides his interest in computer, he likes climbing and swiming, watching movies and chilling with his favourite music. Karol joined Gentoo to help with the Gentoo/OpenBSD project. I guess Flameeyes will be happy with another slav^H^Hminio^H^H^Hhelping hand :-) Karol, welcome aboard :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Thomas,
Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour:
One point of view on this issues is that the ebuilds are wrong, because
they are abusing the said USE flags, and they should rather die. Imho,
it makes sense, but if such a strict policy was applied to every
ebuilds which atm are abusing flags this way, it would become really
hard to put anything in the make.conf USE variable without breaking
emerge -uD world.
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.
This detection function (for example pkg_prepare()) must be executed for every
package in the depgraph right after the depgraph has been built and has only
the possibility to either mark the package as 'go' or 'no-go'. In case that
any package has been marked as 'no-go', the whole process stops.
A possible implementation from the build side could look like this:
# the next two functions would be candidates for eutils.eclass
emutexuse() {
eerror The following USE flags are mutually exclusive:
eerror [EMAIL PROTECTED]
eerror Please choose only one of the above and disable the remaining
eerror USE flags. For additional information about this problem, see
eerror http://www.gentoo.org/some place to store add. info about
this
echo
}
emissinguse() {
eerror In order to enable the ${2} USE flag you need also to enable
eerror the ${1} USE flag. For additional information
echo
}
pkg_prepare() {
local ret=0
if use foo use bar ; then
emutexuse foo bar
ret=1
fi
if use fnord2 ! use fnord ; then
emissinguse fnord fnord2
ret=1
fi
return ${ret}
}
Comments?
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
Am Mittwoch, 1. März 2006 08:21 schrieb Jakub Moc: 28.2.2006, 16:31:26, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze [EMAIL PROTECTED] | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote: | Yes, it's an utterly trivial problem, but it is a QA violation. | Getting a complete list is something that takes a heck of a lot | longer, and I have yet to be convinced that my time would not be | better spent elsewhere. | | Where is a coding style problem related to quality of code in general | and assurance in particular? It's more relevant than you might think. Screwing up layout like that breaks various QA checking tools that assume that things are in the standard format. A tool that chokes on coding style (like tabs and whitespaces) should be ifself fixed. Hmm, you never used repoman, right? repoman checks for whitespace and tab oddities and warns you, if you want to commit them. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Policies (was: [RFC] QA Team's role)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jakub, Jakub Moc schrieb: | 28.2.2006, 16:29:07, Stephen Bennett wrote: |When and where has been the following change discussed and who |approved that? | |http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25r2=1.26root=gentoo |According to my recollection, it was discussed between members of QA |and devrel. According to the CVS logs, it was committed by a member of |devrel, at QA's request. You can't pass it off as a QA project |conspiracy, since they didn't make the change. | I'm sorry, but discussing such stuff affecting pretty much everyone who | writes ebuilds among a couple of people simply isn't enough to make this a | policy. And then silently applying this and starting to scream QA | violation, look, what a nasty QA violation!!! is plain ridiculous. Well, it was common sense before. Especially because it was part of the devmanual. I know, the next argument will be: The devmanual is not official. However, this particular text had been part of the devmanual for a long time. Many devs read it and afaict nobody objected against it while it was 'unofficial'. In my opinion, there was enough time to raise a hand and yell: 'I don't like it'. Beside this, I'd like to support the non-interactive mode on the base of efficiency: It is better to install a package with a default and sane set of USE flags instead of breaking the whole update process. However, this incident should be logged by portage. | Punting every single piece of broken sh*t from the tree requires notifying | everyone on -dev ml and allowing a period of time before it's actually done, | so silently changing/stating policies is a very broken practice. Nobody changed anything. It was written down before in the devmanual and then incorporated into the developer handbook. If you don't agree with the contents, why didn't you raise your opposition earlier? If you agree with the contents, please ask yourself if the current discussion is necessary. I'm looking forward to your answers on the last 2 points. Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBHk1aVNL8NrtU6IRAlRbAKCH233GWmOQWlRy/DQQh/aRR++4ZACfd230 rYQgmnvH9Y/0YSijnCSAOIc= =QQEa -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Moc schrieb: | 28.2.2006, 18:38:10, Ciaran McCreesh wrote: | No, I won't claim that... I'd rather love to know why didn't you point out | to an obvious eclass flaw about 30 emails and many hours ago, saving us from | all the eclass formating, slotting and ewarn blurb. The above needs to be | fixed, period. | | To return to the original topic - focus your QA efforts on real issues. Same | goes for that non-interactivity stuff. QA that serves no other purpose than interactivie stuff in the tree (outside of pkg_config() function) _is_ a QA problem. | inventing problems to enforce an inevitably hackish solution (there's no | good one because the needed tools are not available) is not useful at all. | Portage is a tool to install and manage packages, and serves no good purpose | on its own. Crippling installed packages and their available features for | the sole purpose of having nice ebuild tree with clean bash code is not what | QA is for. Improving the whole process is fine and welcome, as long as it Wrong. This is exactly what QA is for. There are additional duties for the QA team beside clean bash code. Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBKe7aVNL8NrtU6IRAl75AKCT9h+9V4sM9YxRgIoaD+136dug9ACgkqoI chBYTGNn2hEChDAi/WfV1+k= =INNg -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: Tobias Matzat (SirSeoman)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all! Please help me to welcome Tobias Matzat aka SirSeoman who just entered the ranks of Gentoo Developers. Tobias is our new German GWN Translator. He is 25 years old and lives in Trier where he studies computer science at the Trier University of Applied Sciences. Though he's been using Linux and Gentoo for several years now, he found and still find time playing basketball, reading a good book (especially Tolkien and Tad Williams) and listening to loud music. Welcome aboard Tobias! Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuaJ3aVNL8NrtU6IRAnEQAJoDDRQHVYLNVZFU2V6PEmBvgWss+ACgi9uJ h6r5VkppC9fwBbDeL3cGg2I= =4kSa -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Moc schrieb:
|
|Currently there are quite a few ebuilds in the tree that execute dodoc or
|dohtml for files that do not exist. I think it would be nice to have
|ebuilds die if this is the case. To not break current ebuilds this would
|only happen with FEATURES=stricter.
|
|
| Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
| checks implemented in recent portage versions. Some of these bugs are
| completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
| etc. What's the point of this breakage? Why are these QA checks fatal,
| causing ebuilds to bail out? How can you disable such checks per-ebuild
| (AFAIK - you can't) to not annoy users with QA notices and breakage
one can
| do nothing about anyway?
You can disable them. Have a look at dyn_install in ebuild.sh.
There are 2 categories of such QA violations:
* One category (qa_sucks_for_sure) currently only consists of ebuilds
~ that have run-paths pointing to a subdir of ${BUILDDIR}. Such bugs can
~ always be fixed (as it never affects binary packages) and thus this
~ category of bug lets the build process always die.
* The other category (qa_kinda_sucks) only causes the death of the build
~ process when the user has FEATURES=stricter and the ebuild doesn't
~ have RESTRICT=stricter.
The obvious solution for unfixable (binary) packages is to set
RESTRICT=stricter for them. On the other hand, some binary UPSTREAMs
are very kind and competent to handle such bugs if you tell them. AMD
for example, who will fix an exectuable stack problem in ACML after
the holidays.
Danny
- --
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDr+j8aVNL8NrtU6IRAq0kAJ92IHWPU/WRRzj5F807yU+89bm87gCfbbBF
lkpmuU3EgpaFHfaCaiShQxI=
=drQA
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: codergeek42
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, please help me to welcome Peter Gordon aka codergeek42, our latest addition to the ranks of Gentoo Developers. And someone please explain to him how to secure his bum in SpanKY's immediate vicinity ;-) Peter is a global moderator in the Gentoo forums and for further introduction I'll let him speak himself: I'm a 19 year old caffeine-addicted geek, living in Anaheim, California. I'm in my second year of college (full-time student) and I've been using Linux for almost three years (since Feb 2003); Gentoo since mid-2004. I greatly enjoy science fiction and consider myself somewhat of a Trekkie; as well as spending time with friends and family. You'll never find me without a recent copy of Knoppix. ;-) Along with this, I work full-time for a microelectronics research development firm, helping manage inventory control and various clerical duties. I also am a big fan of the GNU project and the Free software ideologies it puts forth. Welcome Peter! Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDsBORaVNL8NrtU6IRAm3SAKCCI/h2dUunDSPS7WlE8CXrmbTDRwCgjjAv JPA1b/iQML4Bdq34jcNUOtM= =s+M0 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner schrieb:
|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.
No, it doesn't. How would you add repository-specific items to
/etc/portage/package.* ?
Futher, imagine this: The gentoo-x86 repo is split into, say, 4
repositories: gentoo-{system,base,desktop,games}. How would you
reference DEPENDs from one repo to the other in this case?
An optional namespace modifier for *DEPENDS is Good Thing(tm) in my
eyes, and I'd really appreciate it being added to portage rather sooner
than later.
Just one remark: What about making the syntax a bit more familiar to C++
users:
~ DEPENDS=gentoo-foo::foo-bar/baz-2.1
Comments?
Danny
- --
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDooISaVNL8NrtU6IRAshlAKCKAolTb0XsgiO8c3dlw23e0fvdgACgkELL
S5i83H5SZvsDXL55JJLCzqw=
=gnt7
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh schrieb: | | Proposed change: | | | | ``Posted:`` | | Date of posting, in ``-mm-dd`` format (e.g. 2001-08-14) for | | compatibility with ISO-8601. UTC time in ``T19:53:46+`` | | format may also be included (`date --iso-8601=seconds`). Mandatory. | | I'll accept that change if you get Grant to accept a mini-GLEP | switching the GLEPs over to use that format too. I don't think that we need a GLEP for it, no matter how 'mini' it would be.. Just asked Grant if I can convert dates in current GLEPs, and he's ok with, though he wanted to have input from -dev first, so: Anyone objecting to change those dates from dd-mon- format to -mm-dd? If not, i'll commit my diff in 24h... Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDnzCgaVNL8NrtU6IRAgcOAJ0b/to61rIrLyyMLfNpx4rRrvDRDwCeLufm vqe7CvpCLGklzdgsb3DUq54= =offW -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
