Re: [gentoo-dev] April Council meeting summary
Very good job. 2007/4/13, Mike Frysinger <[EMAIL PROTECTED]>: here is a summary of this month's meeting. people seem to think that the CoC is set in stone now when in reality it is not ... feel free to hilite anything you feel wasnt addressed in the previous discussion or anything new you've thought of (i went through the previous threads and tried to distill out things that were missed, but i cant catch it all). CoC: - amne has been doing a good job putting the group together - ask proctors to address these two issues for next meeting: - add a "mission" statement - fix wording to have a positive spin sync Social Contract with Gentoo Foundation (external entities): - trustees will review the statement to clarify things and then we'll look again at syncing documentation for mail servers: - they are supposed to be finished in terms of content - wolf will look at getting them actually committed PMS: - current status looks good in getting issues resolved - should be up and running on Gentoo infra by next meeting - let the devs sort out the todo as the current work flow seems to be getting things done finally splitting gentoo-dev mailing lists: - no real favorable backing for this - people dont like -dev because of the crap, splitting the lists will just move the crap else where, not really solving anything - let proctors do their thing and if need be, review this again limiting of council powers: - doesnt seem to be real backing for this from dev community or the council itself - if a majority of developers are truly upset/disturbed by a council decision, it should show easily - if you dont like a council member, dont vote for them next time moving gentoo-core to public archives: - many people dislike this moving forward - use -dev over -core for most things - not going to happen at this time - look into getting a dev-only archive finally surveys: - robbat2 will look at getting user/dev surveys in place after the release of 2007.0 - probably try and take fresh surveys after each bi-annual release from now on to see if we're meeting many of users' desires new metastructure proposal: - doesnt seem to address any of the problems it proposes to - a large majority of developers and users prefer the single tree development style that Gentoo has versus many smaller trees full log at the normal place: http://www.gentoo.org/proj/en/council/meeting-logs/20070412.txt -mike -- [EMAIL PROTECTED] mailing list
[gentoo-dev] app-admin/{user,web}min needs a maintainer
beu has retired, and this is a widely used package. If any dev is using this and want to maintain it, please feel free to take it. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] start-stop-daemon changes in baselayout-2
Hi fellow devs start-stop-daemon binary in baselayout-2 will require the use of the --name or --pidfile argument in --start if the binary in question changes it's process name. This also applies to any interpreted daemon, such as ddclient or amavisd which are perl programs. This is because according to the kernel, perl is the executable and not ddclient or amavisd. Of course, this also applies to shell, ruby, python and all the other interpreted programs too. baselayout-2 requires this so it can track daemons and work out if they have crashed or not, or even started correctly. Also, some people use the following statement start-stop-daemon --stop --oknodo --signal HUP --exec /some/daemon To send signals to daemons, but not stop them. That incredibly long winded, so alpha2 will support the following start-stop-daemon --signal HUP --exec /some/daemon Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] app-admin/{user,web}min needs a maintainer
On Friday 13 April 2007 11:22, Raúl Porcel wrote: > beu has retired, and this is a widely used package. > > If any dev is using this and want to maintain it, please feel free to > take it. And take care of the security issue on bug #168878 https://bugs.gentoo.org/show_bug.cgi?id=168878 -- Sune Kloppenborg Jeppesen (Jaervosz) pgpwOGKV4FkFF.pgp Description: PGP signature
[gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
Hi List
bsaelayout-2.0.0_alpha2 will ship without any volume support for things
like LVM, RAID, etc. We only ship the hooks right now, but we won't
ship those any more as we can't seem it get it right.
If you care about such things, then you need to pester the maintainer
of said package to write an init script for it that has the following
dependency
depend() {
before checkroot
}
Any other dependencies should be done by the USER
in /etc/conf.d/foo like so
RC_NEED="bar"
Which shows that foo needs bar. Or rather dm-crypt needs lvm or some
such. Of couse, same USER can add RC_NEED="lvm"
to /etc/conf.d/localmount or any other service too.
This is kind of required so that /dev managers don't have to use nasty
hacks either.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Wed, 11 Apr 2007 15:41:01 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Thu, 5 Apr 2007 15:11:47 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > 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. > > Well, EAPI 1 needs to be delivered quickly... So it's down to what > Portage can give quickly... Candidates, I believe, being: > > * SLOT deps, but probably not USE deps > * Remove automatic directory making for do* No > * do* fail on missing files > * Phase changes: src_fetch -> src_unpack -> src_prepare -> > src_configure -> src_compile -> src_test -> src_install No to src_fetch > * src_test always called except if RESTRICT=test I don't think this would fit into EAPI, to me it's an implementation detail of the package manager, or why should the ebuild care about it? Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Marius Mauch wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > * src_test always called except if RESTRICT=test > > I don't think this would fit into EAPI, to me it's an implementation > detail of the package manager, or why should the ebuild care about it? hmm, i'd have to agree ... this is something that could be done easily via the profile in EAPI-0 now ... requiring package managers to behave this way doesnt really gain anything -mike pgpIuUWQaxIjP.pgp Description: PGP signature
[gentoo-dev] disabling old linux baggage
i plan on adding old-linux to use.force in the linux-2.4 profiles and converting the "no-old-linux" USE flag to that ... that way things like module-init-tools from now on will only support linux-2.6+ any comments ? -mike pgpreBOGaB1uH.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 13 April 2007 12:41:43 Roy Marples wrote: > If you care about such things, then you need to pester the maintainer > of said package to write an init script for it that has the following > dependency I'll look into it, any idea when you are going to making baselayout-2 stable so I have an ETA on when this has to be done by? Anyone that has time and wants to submit some patches (I don't think that there is too much that is bash specific in it off the top of my head) to test, simply bug it to me. - -- - -- Benjamin Smee (strerror) crypto/forensics/netmail/netmon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGH33NAEpm7USL54wRAk7hAJ48F37vuznJtds+A6wNGq9cTTaiEwCfaX+Z 3cvPtD4+tSAN0wNs1HDjo3c= =xDjO -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On Friday 13 April 2007, Benjamin Smee (strerror) wrote: > On Friday 13 April 2007 12:41:43 Roy Marples wrote: > > If you care about such things, then you need to pester the maintainer > > of said package to write an init script for it that has the following > > dependency > > I'll look into it, any idea when you are going to making baselayout-2 > stable so I have an ETA on when this has to be done by? Anyone that has > time and wants to submit some patches (I don't think that there is too > much that is bash specific in it off the top of my head) to test, simply > bug it to me. ha, it wont even be leaving package.mask soonish, so i doubt you have any stable worries i wonder how hard we want to ride this though ... target 2007.1 ? -mike pgpzVu8jCpc3j.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] New metastructure proposal
On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote: > as everyone probably noticed, there is a current atmosphere of sinking ship, > with quite a lot of people leaving and many agreeing that gentoo is no fun > working on anymore. Before it's too late, I'd like to propose a big > reformation A well considered and thoughtful message. Reinvigorating communities is hard, and I hope the rest of the Gentoo developer community will find inspiration from the gentle encouragement to be positive, even if it turns out the specific ideas aren't the direction you want to go. For all that the original poster got hammered about the stage4 thing, as a long time Gentoo advocate I must admit that the constant stream of negativity connected with so many developers getting upset and leaving in a relatively short period of time is vaguely unsettling. It's good to see other developers noting that they are happy - it balances things. One of the hallmarks of Gentoo has been whole tree co-ordination and the fact that developers are able to cover for each other is really rather cool. Regardless of any structural changes you might make, this characteristic co-ordination and co-operation is what has made Gentoo an impressive distribution and so I hope you manage to maintain this spirit in the years to come. AfC Bangalore -- Andrew Frederick Cowie Technology strategy, managing change, establishing procedures, and executing successful upgrades to mission critical business infrastructure. http://www.operationaldynamics.com/ Sydney New York Toronto London signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 14:21:16 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: > On Wed, 11 Apr 2007 15:41:01 +0100 > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > * Remove automatic directory making for do* > > No It masks all kinds of programming screwups. doblah should make a blah, not make a blah and possibly make a directory. > > * do* fail on missing files > > * Phase changes: src_fetch -> src_unpack -> src_prepare -> > > src_configure -> src_compile -> src_test -> src_install > > No to src_fetch Why? It would be useful for CVS, SVN etc ebuilds. I'm not suggesting it be used for SRC_URI things. > > * src_test always called except if RESTRICT=test > > I don't think this would fit into EAPI, to me it's an implementation > detail of the package manager, or why should the ebuild care about it? It's the best way of ensuring that ebuilds have a working src_test. Arch teams need this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 15:24:25 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Brian Harring <[EMAIL PROTECTED]> wrote: > >> 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. > > > > Well, EAPI 1 needs to be delivered quickly... > > Why exactly does EAPI=1 need to be rushed? Because the tree needed the functionality in question several years ago. > I thought the whole point of 0 was allowing a base, so that new stuff > could be developed while guaranteeing certain behaviour. What's the > hurry? It's not like there are systems b0rking or anything because > EAPI=1 isn't around; Except there are. Hence why we want EAPI 1 in the short term, not several years from now. The stuff that will take longer can go into a later EAPI. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Ciaran McCreesh wrote: > Marius Mauch <[EMAIL PROTECTED]> wrote: > > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > > * Remove automatic directory making for do* > > > > No > > It masks all kinds of programming screwups. doblah should make a blah, > not make a blah and possibly make a directory. name one you're proposing we suddenly bloat all of our src_install functions for no gain at all ... sounds like a no brainer to me > > > * src_test always called except if RESTRICT=test > > > > I don't think this would fit into EAPI, to me it's an implementation > > detail of the package manager, or why should the ebuild care about it? > > It's the best way of ensuring that ebuilds have a working src_test. > Arch teams need this. then arch teams can update their profiles -mike pgpKNXQ9ag1os.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] New metastructure proposal
On Fri, 2007-04-13 at 19:26 +0530, Andrew Cowie wrote: > On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote: > > as everyone probably noticed, there is a current atmosphere of sinking ship, > > with quite a lot of people leaving and many agreeing that gentoo is no fun > > working on anymore. Before it's too late, I'd like to propose a big > > reformation > > A well considered and thoughtful message. Reinvigorating communities is > hard, and I hope the rest of the Gentoo developer community will find > inspiration from the gentle encouragement to be positive, even if it > turns out the specific ideas aren't the direction you want to go. > > For all that the original poster got hammered about the stage4 thing, as > a long time Gentoo advocate I must admit that the constant stream of > negativity connected with so many developers getting upset and leaving > in a relatively short period of time is vaguely unsettling. It's good to > see other developers noting that they are happy - it balances things. > OK, I'm a happy developer. > One of the hallmarks of Gentoo has been whole tree co-ordination and the > fact that developers are able to cover for each other is really rather > cool. Regardless of any structural changes you might make, this > characteristic co-ordination and co-operation is what has made Gentoo an > impressive distribution and so I hope you manage to maintain this spirit > in the years to come. > > AfC > Bangalore > Thanks for the kind words; positive posts are always welcome. :) I believe it is very much our intent to "maintain this spirit [of co-operation]". Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Ciaran McCreesh wrote: > Steve Long <[EMAIL PROTECTED]> wrote: > > Ciaran McCreesh wrote: > > > Brian Harring <[EMAIL PROTECTED]> wrote: > > >> 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. > > > > > > Well, EAPI 1 needs to be delivered quickly... > > > > Why exactly does EAPI=1 need to be rushed? > > Because the tree needed the functionality in question several years ago. > > > I thought the whole point of 0 was allowing a base, so that new stuff > > could be developed while guaranteeing certain behaviour. What's the > > hurry? It's not like there are systems b0rking or anything because > > EAPI=1 isn't around; > > Except there are. Hence why we want EAPI 1 in the short term, not > several years from now. The stuff that will take longer can go into a > later EAPI. this is really up to the portage team to drive -mike pgpZGiG319O6e.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 11:11:07 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > Except there are. Hence why we want EAPI 1 in the short term, not > > several years from now. The stuff that will take longer can go into > > a later EAPI. > > this is really up to the portage team to drive If they instead decide that EAPI 1 is a long term goal, will the Council intervene? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 10:53:38 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > It masks all kinds of programming screwups. doblah should make a > > blah, not make a blah and possibly make a directory. > > name one dosym's old behaviour prevented a broken Vim release (upstream screwed up a Makefile dependency) from getting into the tree unnoticed. Had that happened after you changed some (but not all) of the do* utilities, the duff symlinks would probably have gone unnoticed for a while. > you're proposing we suddenly bloat all of our src_install functions > for no gain at all ... sounds like a no brainer to me No, I'm proposing that functions not have strange side effects. > > > > * src_test always called except if RESTRICT=test > > > > > > I don't think this would fit into EAPI, to me it's an > > > implementation detail of the package manager, or why should the > > > ebuild care about it? > > > > It's the best way of ensuring that ebuilds have a working src_test. > > Arch teams need this. > > then arch teams can update their profiles Well no, they can't, because there are a whole load of ebuilds that will break if they do that. But if it's introduced as mandatory (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly move towards everything that reasonably can do having working test suites, which will be a huge step forward for QA. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] April Council meeting summary
On Thu, 12 Apr 2007 18:45:13 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > PMS: > - should be up and running on Gentoo infra by next meeting What is the justification for making this change? It's already inconvenient enough having to have someone else make bugzilla changes for me on PMS bugs that I didn't submit; what reason is there for extending this annoyance to the source too? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Mike Frysinger napsal(a): * Remove automatic directory making for do* >>> No >> It masks all kinds of programming screwups. doblah should make a blah, >> not make a blah and possibly make a directory. > > name one > > you're proposing we suddenly bloat all of our src_install functions for no > gain at all ... sounds like a no brainer to me +1, this is a horrible idea that would just cause loads of bugs impossible to check for in advance, major work for lots of people and major bloat for no good reason. Bleh. :/ -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 17:36:33 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Mike Frysinger napsal(a): > * Remove automatic directory making for do* > >>> No > >> It masks all kinds of programming screwups. doblah should make a > >> blah, not make a blah and possibly make a directory. > > > > name one > > > > you're proposing we suddenly bloat all of our src_install functions > > for no gain at all ... sounds like a no brainer to me > > +1, this is a horrible idea that would just cause loads of bugs > impossible to check for in advance What? No it wouldn't. It would ensure that bugs were caught during the src_install phase rather than after a package has been installed. >, major work for lots of people Again, no. > and major bloat for no good reason. What? No it wouldn't. Very few things rely upon the automatic directory creation behaviour. We know this because we have Paludis warning us when it's used... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Ciaran McCreesh wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > Except there are. Hence why we want EAPI 1 in the short term, not > > > several years from now. The stuff that will take longer can go into > > > a later EAPI. > > > > this is really up to the portage team to drive > > If they instead decide that EAPI 1 is a long term goal, will the > Council intervene? the Council, as always, will act as it deems necessary -mike pgpbRAPgCXLL4.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Ciaran McCreesh wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > It masks all kinds of programming screwups. doblah should make a > > > blah, not make a blah and possibly make a directory. > > > > name one > > dosym's old behaviour prevented a broken Vim release (upstream screwed > up a Makefile dependency) from getting into the tree unnoticed. Had > that happened after you changed some (but not all) of the do* > utilities, the duff symlinks would probably have gone unnoticed for a > while. improper package testing that was saved by a dosym that did not create directories ... useful mayhaps, but not nearly enough to justify the proposed change > > you're proposing we suddenly bloat all of our src_install functions > > for no gain at all ... sounds like a no brainer to me > > No, I'm proposing that functions not have strange side effects. the behavior here is desired ... you install into a directory, then the directory should exist > Well no, they can't, because there are a whole load of ebuilds that > will break if they do that. But if it's introduced as mandatory > (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly move > towards everything that reasonably can do having working test suites, > which will be a huge step forward for QA. that's really the QA's job to enforce, not the package manager if the QA team wants to spear head a tree wide effort at getting src_test up and running, they're certainly free to -mike pgpgrmm8aWRkT.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On 4/13/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: ha, it wont even be leaving package.mask soonish, so i doubt you have any stable worries i wonder how hard we want to ride this though ... target 2007.1 ? It's mid-April and 2007.0 is still nowhere in sight, so the idea that there will be a 2007.1 is looking increasingly unrealistic. Please don't make baselayout-2's unmasking contingent on that. What I'd like to find out is whether baselayout-2 allows the crypt-swap non-random key issue [1] to be properly solved. --Alex [1] http://bugs.gentoo.org/show_bug.cgi?id=134489 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh napsal(a): > What? No it wouldn't. It would ensure that bugs were caught during the > src_install phase rather than after a package has been installed. What kind of bugs exactly? The ones *created* by this behavior change? I'd rather not create such bugs for starters, because it's plain pointless. If the Makefiles suck, file bugs upstream instead of dumping the stuff on Gentoo users. People are already pretty much overloaded by the tons of various QA checks all over the place... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On Friday 13 April 2007, Alex Tarkovsky wrote: > On 4/13/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > ha, it wont even be leaving package.mask soonish, so i doubt you have any > > stable worries > > > > i wonder how hard we want to ride this though ... target 2007.1 ? > > It's mid-April and 2007.0 is still nowhere in sight you're clearly not part of the release process > so the idea that > there will be a 2007.1 is looking increasingly unrealistic. Please > don't make baselayout-2's unmasking contingent on that. read what i said again, i'm talking about stabilizing -mike pgpXS6ofSpiSf.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 18:22:24 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh napsal(a): > > What? No it wouldn't. It would ensure that bugs were caught during > > the src_install phase rather than after a package has been > > installed. > > What kind of bugs exactly? The ones *created* by this behavior change? > I'd rather not create such bugs for starters, because it's plain > pointless. You're missing the point. As of a year or so ago, dosym will succeed even if the dosym target directory doesn't exist, and even if it means creating arbitrary directories. Some other utilities, such as dohard for example, will fail under otherwise identical circumstances. There is nothing in dosym's name that suggests that it will create a directory as well as a symlink -- it is not like, for example, dobin or dosbin in this respect, both of which clearly are allowed to create a well defined, non-variable path. If anyone really *is* relying upon dosym to create a directory, rather than having it happen by accident, adding in a dodir beforehand when switching EAPIs is easy, and will prevent accidental directory creation. > If the Makefiles suck, file bugs upstream instead of dumping the stuff > on Gentoo users. It's not the users that will see this. It's developers. The only time it will fail for users and not developers is when something's broken anyway, and that's far better than ending up with a broken install. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 11:52:16 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > you're proposing we suddenly bloat all of our src_install > > > functions for no gain at all ... sounds like a no brainer to me > > > > No, I'm proposing that functions not have strange side effects. > > the behavior here is desired ... you install into a directory, then > the directory should exist These fail: cp somefile dirdoesnotexist/ mv somefile dirdoesnotexist/ ln -s somefile dirdoesnotexist/ dohard somefile dirdoesnotexist/ mkdir dirdoesnotexist/newdir This succeeds: dosym somefile dirdoesnotexist/ > > Well no, they can't, because there are a whole load of ebuilds that > > will break if they do that. But if it's introduced as mandatory > > (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly > > move towards everything that reasonably can do having working test > > suites, which will be a huge step forward for QA. > > that's really the QA's job to enforce, not the package manager > > if the QA team wants to spear head a tree wide effort at getting > src_test up and running, they're certainly free to The arch teams have been pushing for this for a long time. They're trying to get this enforced, but are having limited success because there's no way for FEATURES=test to become widely used that won't lead to broken user systems. Moving src_test to be always on in future EAPIs is an easy way of helping arch teams achieve this goal without breaking anyone's system in the meantime. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On 4/13/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Friday 13 April 2007, Alex Tarkovsky wrote: > It's mid-April and 2007.0 is still nowhere in sight you're clearly not part of the release process Can you tell us the release date then? I didn't think so. :) --Alex -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On Fri, 2007-04-13 at 11:23 -0500, Alex Tarkovsky wrote: > It's mid-April and 2007.0 is still nowhere in sight, so the idea that > there will be a 2007.1 is looking increasingly unrealistic. Please > don't make baselayout-2's unmasking contingent on that. I guess I should just delete all this 2007.0 media we've been working on then, huh? I'm simply amazed at the level of complete and total bullshit that some people spout off on this list without bothering to check facts or take 3 seconds to talk to the people in the know. If you don't know what you're talking about, rather than open your mouth and prove to everyone that you are clueless about the particular topic, it's probably best to either ask someone or talk about something you're actually familiar with, instead. For those of you wondering, 2007.0 is close to being finished. You can blame the abnormally high number of security vulnerabilities in large packages for the delays. Also, the dates given on the Release Engineering pages are nothing more than guesses made by me months before we even start the release. They are in no way binding. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On Friday 13 April 2007, Alex Tarkovsky wrote: > On 4/13/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Friday 13 April 2007, Alex Tarkovsky wrote: > > > It's mid-April and 2007.0 is still nowhere in sight > > > > you're clearly not part of the release process > > Can you tell us the release date then? > > I didn't think so. :) i never said i was part of the release process -mike pgp7B0ITyAAAD.pgp Description: PGP signature
Re: [gentoo-dev] April Council meeting summary
Ciaran McCreesh wrote: > On Thu, 12 Apr 2007 18:45:13 -0400 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > >> PMS: >> - should be up and running on Gentoo infra by next meeting >> > > What is the justification for making this change? It's already > inconvenient enough having to have someone else make bugzilla changes > for me on PMS bugs that I didn't submit; what reason is there for > extending this annoyance to the source too? > > I'd say Ciaran has to have write access to any such repository, as one of the main contributors. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh napsal(a):
> You're missing the point.
>
> As of a year or so ago, dosym will succeed even if the dosym target
> directory doesn't exist, and even if it means creating arbitrary
> directories. Some other utilities, such as dohard for example, will
> fail under otherwise identical circumstances.
>
> There is nothing in dosym's name that suggests that it will create a
> directory as well as a symlink -- it is not like, for example, dobin or
> dosbin in this respect, both of which clearly are allowed to create a
> well defined, non-variable path.
Err, your suggestion was:
* Remove automatic directory making for do*
So, yeah I really fail to see the point of doing stuff like this:
-dobin foo
+dodir /usr/bin
+dobin foo
or
-exeinto /usr/share/${PN}/scripts
-doexe scripts/*
+exeinto /usr/share/${PN}/scripts
+dodir /usr/share/${PN}/scripts
+doexe scripts/*
all over the tree.
> If anyone really *is* relying upon dosym to create a directory, rather
> than having it happen by accident, adding in a dodir beforehand when
> switching EAPIs is easy, and will prevent accidental directory creation.
And who will wade through the entire tree and check for such stuff? You?
>> If the Makefiles suck, file bugs upstream instead of dumping the stuff
>> on Gentoo users.
>
> It's not the users that will see this. It's developers. The only time
> it will fail for users and not developers is when something's broken
> anyway, and that's far better than ending up with a broken install.
Well of course it's the users who will see it, see above. It's not like
that we would have 100 volunteers around to drop everything they have in
their hands a go spend days on changing ebuilds that are not broken just
because of this idea.
--
Best regards,
Jakub Moc
mailto:[EMAIL PROTECTED]
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: April Council meeting summary
On Fri, 13 Apr 2007 17:58:52 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Mike Frysinger <[EMAIL PROTECTED]> wrote: > >> PMS: > >> - should be up and running on Gentoo infra by next meeting > > > > What is the justification for making this change? It's already > > inconvenient enough having to have someone else make bugzilla > > changes for me on PMS bugs that I didn't submit; what reason is > > there for extending this annoyance to the source too? > > > [16:47] vapier: it is already a QA subproject > > It's not such a big deal in practise is it? Yes, it is. It's a change in workflow, and it at least doubles the amount of work for each commit. > Unless you're saying you can't use git? Which would be decidedly > strange for a kernel contributor.. I'm saying I don't see any point in it when svn is doing the job just fine now. If someone can provide a good reason for changing to a system that's more work, I'll change. If there isn't a good reason, I won't. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Jakub Moc kirjoitti: > > Well of course it's the users who will see it, see above. It's not like > that we would have 100 volunteers around to drop everything they have in > their hands a go spend days on changing ebuilds that are not broken just > because of this idea. > > We are talking about EAPI=1 so it's not magically going to change anything for current ebuilds. EAPI=1 should also change do* functions to die on failure so at best the ebuilds would die when the directory is not created and maintainers who commit stuff with trying to emerge them first shouldn't be devs in the first place. Not that it would mean that having to add dodir's for everything is a good idea. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 19:06:42 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Err, your suggestion was: > > * Remove automatic directory making for do* Because I was giving a one line summary, rather than a description of the full change. The full description has been discussed elsewhere several times. > So, yeah I really fail to see the point of doing stuff like this: > > -dobin foo > +dodir /usr/bin > +dobin foo Which was not what was being discussed. > > If anyone really *is* relying upon dosym to create a directory, > > rather than having it happen by accident, adding in a dodir > > beforehand when switching EAPIs is easy, and will prevent > > accidental directory creation. > > And who will wade through the entire tree and check for such stuff? > You? Uh. What. There's no need to do that. That's the whole point of sticking it in at an EAPI change. When people switch an ebuild's EAPI, they test it. That's required anyway because EAPI changes various behaviour options. Ebuilds whose EAPI isn't switched aren't affected. > >> If the Makefiles suck, file bugs upstream instead of dumping the > >> stuff on Gentoo users. > > > > It's not the users that will see this. It's developers. The only > > time it will fail for users and not developers is when something's > > broken anyway, and that's far better than ending up with a broken > > install. > > Well of course it's the users who will see it, see above. It's not > like that we would have 100 volunteers around to drop everything they > have in their hands a go spend days on changing ebuilds that are not > broken just because of this idea. Explain in more detail how users will see it please. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: April Council meeting summary
Ciaran McCreesh napsal(a): > If someone can provide a good reason for changing to a system that's > more work, I'll change. If there isn't a good reason, I won't. Maybe if you actually read the council log, you'd see the reason? yeah, it's indeed there, believe me. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 13:02:00 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Friday 13 April 2007, Ciaran McCreesh wrote: > > These fail: > > > > cp somefile dirdoesnotexist/ > > mv somefile dirdoesnotexist/ > > ln -s somefile dirdoesnotexist/ > > dohard somefile dirdoesnotexist/ > > mkdir dirdoesnotexist/newdir > > > > This succeeds: > > > > dosym somefile dirdoesnotexist/ > > any other obvious statements you care to make ? > > compare your standard handwritten Makefile install: target to > src_install() in an ebuild ... i'll take the much shorter > src_install() any day Except that we already know that it doesn't make a substantial difference to the lengths of src_installs in the tree. Very few packages are relying upon the automatic directory creation. > > The arch teams have been pushing for this for a long time. They're > > trying to get this enforced, but are having limited success because > > there's no way for FEATURES=test to become widely used that won't > > lead to broken user systems. Moving src_test to be always on in > > future EAPIs is an easy way of helping arch teams achieve this goal > > without breaking anyone's system in the meantime. > > if you have a problem with the QA team then complain to your buddy spb Er, no, I'm explaining why enforcing src_test for EAPI 1 will be helpful for an awful lot of Gentoo developers. Please refrain from that kind of comment. It doesn't help anyone. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: April Council meeting summary
On Fri, 13 Apr 2007 19:20:46 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh napsal(a): > > If someone can provide a good reason for changing to a system that's > > more work, I'll change. If there isn't a good reason, I won't. > > Maybe if you actually read the council log, you'd see the reason? > yeah, it's indeed there, believe me. I did, and I don't see it. Perhaps you'd care to paste what you think the relevant parts are? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On Friday 13 April 2007, Chris Gianelloni wrote: > On Fri, 2007-04-13 at 11:23 -0500, Alex Tarkovsky wrote: > > It's mid-April and 2007.0 is still nowhere in sight, so the idea that > > there will be a 2007.1 is looking increasingly unrealistic. Please > > don't make baselayout-2's unmasking contingent on that. > > I guess I should just delete all this 2007.0 media we've been working on > then, huh? > > I'm simply amazed at the level of complete and total bullshit that some > people spout off on this list without bothering to check facts or take 3 > seconds to talk to the people in the know. If you don't know what > you're talking about, rather than open your mouth and prove to everyone > that you are clueless about the particular topic, it's probably best to > either ask someone or talk about something you're actually familiar > with, instead. For those of you wondering, 2007.0 is close to being > finished. You can blame the abnormally high number of security > vulnerabilities in large packages for the delays. Also, the dates given > on the Release Engineering pages are nothing more than guesses made by > me months before we even start the release. They are in no way binding. so full of hate ! -mike pgpmIIhmWYNvQ.pgp Description: PGP signature
[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: >> > > you're proposing we suddenly bloat all of our src_install >> > > functions for no gain at all How big a bloat is it? Surely it's a coupla lines in the eclasses? Cos the behaviour is inconsistent, as Ciaran pointed out. >> > Well no, they can't, because there are a whole load of ebuilds that >> > will break if they do that. But if it's introduced as mandatory >> > (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly >> > move towards everything that reasonably can do having working test >> > suites, which will be a huge step forward for QA. >> >> that's really the QA's job to enforce, not the package manager >> >> if the QA team wants to spear head a tree wide effort at getting >> src_test up and running, they're certainly free to > > The arch teams have been pushing for this for a long time. They're > trying to get this enforced, but are having limited success because > there's no way for FEATURES=test to become widely used that won't lead > to broken user systems. Moving src_test to be always on in future EAPIs > is an easy way of helping arch teams achieve this goal without breaking > anyone's system in the meantime. > I have to say Mr McCreesh's argument has persuaded me on this aspect too. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: April Council meeting summary
Ciaran McCreesh napsal(a): > On Fri, 13 Apr 2007 19:20:46 +0200 > Jakub Moc <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh napsal(a): >>> If someone can provide a good reason for changing to a system that's >>> more work, I'll change. If there isn't a good reason, I won't. >> Maybe if you actually read the council log, you'd see the reason? >> yeah, it's indeed there, believe me. > > I did, and I don't see it. Perhaps you'd care to paste what you think > the relevant parts are? > [16:49] infra won't give any access to non-devs that needs SSH keys. Isn't that hard to find I'd say? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
Alex Tarkovsky kirjoitti: > > So I promise to get myself a clue just as soon as you've changed your > policies to be more inclusive and less hostile towards users. Deal? :) > The thing is that your comment was probably perceived as a negative comment about our releases being late or something like that at least that's how it come out to me at least. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: April Council meeting summary
On Fri, Apr 13, 2007 at 07:20:46PM +0200, Jakub Moc wrote: > Ciaran McCreesh napsal(a): > > If someone can provide a good reason for changing to a system that's > > more work, I'll change. If there isn't a good reason, I won't. > > Maybe if you actually read the council log, you'd see the reason? yeah, > it's indeed there, believe me. Jakub: Please refrain from comments like that one, it does not help creating a productive atmosphere. Everyone else: Please do not feel tempted to reply with a snappish answer here. Thanks everyone, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgplKwHDU0eB2.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Ciaran McCreesh wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Friday 13 April 2007, Ciaran McCreesh wrote: > > > These fail: > > > > > > cp somefile dirdoesnotexist/ > > > mv somefile dirdoesnotexist/ > > > ln -s somefile dirdoesnotexist/ > > > dohard somefile dirdoesnotexist/ > > > mkdir dirdoesnotexist/newdir > > > > > > This succeeds: > > > > > > dosym somefile dirdoesnotexist/ > > > > any other obvious statements you care to make ? > > > > compare your standard handwritten Makefile install: target to > > src_install() in an ebuild ... i'll take the much shorter > > src_install() any day > > Except that we already know that it doesn't make a substantial > difference to the lengths of src_installs in the tree. Very few > packages are relying upon the automatic directory creation. i bet you have hard #s to back that up ? since you dont, bloating src_install is not the answer to a marginalized issue > > > The arch teams have been pushing for this for a long time. They're > > > trying to get this enforced, but are having limited success because > > > there's no way for FEATURES=test to become widely used that won't > > > lead to broken user systems. Moving src_test to be always on in > > > future EAPIs is an easy way of helping arch teams achieve this goal > > > without breaking anyone's system in the meantime. > > > > if you have a problem with the QA team then complain to your buddy spb > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be > helpful for an awful lot of Gentoo developers. except that you back the tree into a corner that it cannot come out of > Please refrain from that kind of comment. It doesn't help anyone. the answer is the same: talk to the QA team to get the tree into a state where having src_test enabled by default is feasible and then the QA team can change the profile enforcing via spec is the wrong way to go here ... spec is for defining how the ebuilds work, not for forcing policy down peoples throats -mike pgp8eKt8kvPvt.pgp Description: PGP signature
Re: [gentoo-dev] disabling old linux baggage
On Friday 13 April 2007 14:42:41 Mike Frysinger wrote: > i plan on adding old-linux to use.force in the linux-2.4 profiles and > converting the "no-old-linux" USE flag to that ... that way things like > module-init-tools from now on will only support linux-2.6+ > > any comments ? > -mike Go ahead, I already only use no-old-linux on 20 or so systems. Just remind me once you do that, that I should add that flag to the hardened/x86 profile (or you could add that flag yourself). Regards, Christian -- Christian Heim GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
> > > The arch teams have been pushing for this for a long time. They're > > > trying to get this enforced, but are having limited success because > > > there's no way for FEATURES=test to become widely used that won't > > > lead to broken user systems. Moving src_test to be always on in > > > future EAPIs is an easy way of helping arch teams achieve this goal > > > without breaking anyone's system in the meantime. > > Hmm, as an arch tester, i completely agree that packages where src_test fails are an annoyance. However, I would not suggest to activate src_test by default, as for normal users, it just introduces another source of potential defects, without that much benefits. Instead, i think that arch teams should refuse to stable packages that fail with FEATURES=test and thus encourage ebuild developers to either fix their tests, or to deactivate them explicitly. Matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
> > The arch teams have been pushing for this for a long time. They're > trying to get this enforced, but are having limited success because > there's no way for FEATURES=test to become widely used that won't lead > to broken user systems. Moving src_test to be always on in future EAPIs > is an easy way of helping arch teams achieve this goal without breaking > anyone's system in the meantime. > > Erm, no I have not at all (speaking as a project lead for x86). Test is not viable for a lot of reason as being on by default. One that I can come up with off the top of my head is php. The test suite for it makes test inadvisable on any desktop system, I'd say the same for a server as well. Not to mention that a lot of upstream test functions are in fact themselves broken because they require dependencies that are not required for the application itself. This is not a simple case of downstream (being gentoo) doing this. There has to be quite a bit changed for test to be viable and even then I don't think it really is unfortunately due to test packages that can take 12+ hours on a decently equipped modern system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: April Council meeting summary
On Fri, 13 Apr 2007 19:43:51 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > [16:49] infra won't give any access to non-devs that needs > SSH keys. > > Isn't that hard to find I'd say? That's not a reason for moving. That's a reason for not using infra. -- Ciaran McCreesh signature.asc Description: PGP signature
2007.0 release (was: Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc))
Chris Gianelloni <[EMAIL PROTECTED]> said: > I'm simply amazed at the level of complete and total bullshit that some > people spout off on this list without bothering to check facts or take > 3 seconds to talk to the people in the know. If you don't know what > you're talking about, rather than open your mouth and prove to everyone > that you are clueless about the particular topic, it's probably best to > either ask someone or talk about something you're actually familiar > with, instead. this seems to come up more often than you like. is this the release tracker bug? http://bugs.gentoo.org/show_bug.cgi?id=156814 kind regards Thilo pgp6f0tOTxktm.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 11:16:14 -0700 Joshua Jackson <[EMAIL PROTECTED]> wrote: > Erm, no I have not at all (speaking as a project lead for x86). Test > is not viable for a lot of reason as being on by default. One that I > can come up with off the top of my head is php. The test suite for it > makes test inadvisable on any desktop system, I'd say the same for a > server as well. Not to mention that a lot of upstream test functions > are in fact themselves broken because they require dependencies that > are not required for the application itself. This is not a simple > case of downstream (being gentoo) doing this. There has to be quite a > bit changed for test to be viable and even then I don't think it > really is unfortunately due to test packages that can take 12+ hours > on a decently equipped modern system. If a test suite isn't viable, the ebuild should be RESTRICTing test anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: 2007.0 release
Thilo Bangert wrote: Chris Gianelloni <[EMAIL PROTECTED]> said: I'm simply amazed at the level of complete and total bullshit that some people spout off on this list without bothering to check facts or take 3 seconds to talk to the people in the know. If you don't know what you're talking about, rather than open your mouth and prove to everyone that you are clueless about the particular topic, it's probably best to either ask someone or talk about something you're actually familiar with, instead. this seems to come up more often than you like. is this the release tracker bug? http://bugs.gentoo.org/show_bug.cgi?id=156814 It's not exactly a release tracker...more for the release *snapshot*. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: 2007.0 release
Thilo Bangert napsal(a): > this seems to come up more often than you like. is this the release > tracker bug? > http://bugs.gentoo.org/show_bug.cgi?id=156814 > > kind regards > Thilo Yeah. It's restricted to developers only, though, so not much useful for users. :) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh wrote: >> Why exactly does EAPI=1 need to be rushed? > > Because the tree needed the functionality in question several years ago. > >> I thought the whole point of 0 was allowing a base, so that new stuff >> could be developed while guaranteeing certain behaviour. What's the >> hurry? It's not like there are systems b0rking or anything because >> EAPI=1 isn't around; > > Except there are. Hence why we want EAPI 1 in the short term, not > several years from now. The stuff that will take longer can go into a > later EAPI. > Man here we go again: I spend a lot of time helping and being helped by other gentoo users. *There has been no significant system b0rkage for nearly a year* *QA is getting better not worse* and *the gentoo development process works* You may have your issues with the gentoo dev team, but spreading this kinda FUD is outta line imo. 3 months for specification of EAPI 1 after a year for EAPI 0 is not exactly moving slowly. And there are clearly other viewpoints as to what is needed. Personally speaking, I'd like to find out what those are, as it's both instructive for me, and better for the distro I use. If there really are problems with *portage* those are not your concern: Paludis users presumably don't get that kinda b0rkage so all you need to do is /wait/ and let the technical superiority of your product win the argument. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Empty DEPEND strings in virtuals
[EMAIL PROTECTED] /usr/portage/virtual $ grep 'DEPEND=""' -r . | wc -l
97
[EMAIL PROTECTED] /usr/portage/virtual $ find -name "*.ebuild" | wc -l
102
[EMAIL PROTECTED] /usr/portage/virtual $ find -name "*.ebuild" | xargs
grep -L 'DEPEND=""' | xargs grep DEPEND
./pmake/pmake-0.ebuild:RDEPEND="!userland_BSD? ( sys-devel/pmake )"
./perl-Scalar-List-Utils/perl-Scalar-List-Utils-1.19.ebuild:RDEPEND="~perl-core/Scalar-List-Utils-${PV}"
./c++-tr1-type-traits/c++-tr1-type-traits-0.ebuild:DEPEND="|| (
>=sys-devel/gcc-4.1 dev-libs/boost )"
./c++-tr1-memory/c++-tr1-memory-0.ebuild:DEPEND="|| (
>=sys-devel/gcc-4.1 dev-libs/boost )"
./c++-tr1-functional/c++-tr1-functional-0.ebuild:DEPEND="|| (
>=sys-devel/gcc-4.1 dev-libs/boost )"
so only three virtual ebuilds have a DEPEND
So it seems most ebuilds for new style virtuals don't have DEPENDs.
Anyone have any idea on how these are supposed to work or are they
buggy? PMS currently says that RDEPEND doesn't have to be installed at
the time a package is emerged so as far as I understand it this means
that DEPEND="virtual/foobar" could mean that it could happen that
nothing providing the virtual is available. So should we be changing the
DEPEND atoms to DEPEND="${RDEPEND}" or is there something I am missing here?
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: 2007.0 release (was: Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc))
On Fri, 2007-04-13 at 20:23 +0200, Thilo Bangert wrote: > Chris Gianelloni <[EMAIL PROTECTED]> said: > > I'm simply amazed at the level of complete and total bullshit that some > > people spout off on this list without bothering to check facts or take > > 3 seconds to talk to the people in the know. If you don't know what > > you're talking about, rather than open your mouth and prove to everyone > > that you are clueless about the particular topic, it's probably best to > > either ask someone or talk about something you're actually familiar > > with, instead. > > this seems to come up more often than you like. is this the release > tracker bug? > http://bugs.gentoo.org/show_bug.cgi?id=156814 No. We don't track releases via bugs. Things simply change too fast for it to be a usable solution. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 18:17:32 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > > Except there are. Hence why we want EAPI 1 in the short term, not > > several years from now. The stuff that will take longer can go into > > a later EAPI. > > > Man here we go again: I spend a lot of time helping and being helped > by other gentoo users. *There has been no significant system b0rkage > for nearly a year* *QA is getting better not worse* and *the gentoo > development process works* > > You may have your issues with the gentoo dev team, but spreading this > kinda FUD is outta line imo. You don't know what QA problems EAPI 1 will solve, do you? It's not FUD at all. > 3 months for specification of EAPI 1 after a year for EAPI 0 is not > exactly moving slowly. And there are clearly other viewpoints as to > what is needed. Personally speaking, I'd like to find out what those > are, as it's both instructive for me, and better for the distro I use. We're not talking specification. We're talking implementation time. Many of the things likely to be in EAPI 1 were needed years ago, and the tree has huge problems as a result. The simplest example is the KDE and Qt dependency hell that's come about as a result of not having slot deps. > If there really are problems with *portage* those are not your > concern: Paludis users presumably don't get that kinda b0rkage so all > you need to do is /wait/ and let the technical superiority of your > product win the argument. *Of course* Paludis users will get the same b0rkage that Portage users do, since it's using the same ebuilds. Please refrain from contributing if you don't understand the issues at hand. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: 2007.0 release
On Fri, 2007-04-13 at 20:40 +0200, Jakub Moc wrote: > Thilo Bangert napsal(a): > > this seems to come up more often than you like. is this the release > > tracker bug? > > http://bugs.gentoo.org/show_bug.cgi?id=156814 > > > > kind regards > > Thilo > > > Yeah. It's restricted to developers only, though, so not much useful for > users. :) Yeah, I did that because we had users adding their favorite apps to the snapshot tracker, which had absolutely no place there. All in all, we have found that things seem to work best when we just hide in our little corner of IRC, shut up, and work. We use the tracker bug during the initial snapshot phase since we're reporting bugs in the tree. Once we've taken the snapshot, however, we don't use bugs since many of them are fixed in the tree, but not in our snapshot. Currently, I keep track of the release via a spreadsheet, but I've been working towards getting a project tracking software package setup and configured to replace this functionality. Of course, that tracker won't be public. It's much simpler to answer the few questions we get than it is to answer the floods of questions we *used* to get when we posted dates everywhere. The nature of the tree simply makes it impossible for us to accurately estimate a release date. This release we even went so far as to create a completely new snapshot due to there being so many changes necessary in our original one and the packages getting too stale. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Ciaran McCreesh wrote: > Joshua Jackson <[EMAIL PROTECTED]> wrote: > > Erm, no I have not at all (speaking as a project lead for x86). Test > > is not viable for a lot of reason as being on by default. One that I > > can come up with off the top of my head is php. The test suite for it > > makes test inadvisable on any desktop system, I'd say the same for a > > server as well. Not to mention that a lot of upstream test functions > > are in fact themselves broken because they require dependencies that > > are not required for the application itself. This is not a simple > > case of downstream (being gentoo) doing this. There has to be quite a > > bit changed for test to be viable and even then I don't think it > > really is unfortunately due to test packages that can take 12+ hours > > on a decently equipped modern system. > > If a test suite isn't viable, the ebuild should be RESTRICTing test > anyway. which doesnt apply here ... some packages have ridiculous awesome coverage for their source code and take much longer to run than even compile the package care to force mysql test suites on everyone ? php ? gcc ? binutils ? -mike pgpgbVsfBNopy.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
Alex Tarkovsky wrote: > Can you tell us the release date then? > > I didn't think so. :) > > --Alex Dickish messages like this one might possibly earn you some "cold shoulder" or "hostility" from people who work very hard for you... -- Jeffrey Gardner Gentoo Developer Public PGP Key ID: 4A5D8F23 hkp://pgpkeys.mit.edu -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: 2007.0 release
Chris Gianelloni napsal(a): > On Fri, 2007-04-13 at 20:40 +0200, Jakub Moc wrote: >> Thilo Bangert napsal(a): >>> http://bugs.gentoo.org/show_bug.cgi?id=156814 >> Yeah. It's restricted to developers only, though, so not much useful for >> users. :) > > Yeah, I did that because we had users adding their favorite apps to the > snapshot tracker, which had absolutely no place there. I'm not implying there's anything wrong w/ restricting the bug; just that pointing users here to it won't get them very far. ;) > Currently, I keep track of the release via a spreadsheet > but I've been working towards getting > a project tracking software package setup and configured to replace this > functionality. Sounds cool, good luck. Homebrew one, or something else? :) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On 4/13/07, Jeffrey Gardner <[EMAIL PROTECTED]> wrote:
Alex Tarkovsky wrote:
> Can you tell us the release date then?
>
> I didn't think so. :)
>
> --Alex
Dickish messages like this one might possibly earn you some "cold
shoulder" or "hostility" from people who work very hard for you...
1) It's a friendly joke. Note the smiley face, which wouldn't be used
if it weren't a joke. Well, I might use a scowly face. >;^{
2) Why must some Gentoo devs like yourself and Mr. Gianelloni reply
with expletives to things you disagree with? It's no wonder you need
proctors; unwarranted escalation and invective seems to come so
naturally here.
--Alex
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh wrote: > > If a test suite isn't viable, the ebuild should be RESTRICTing test > anyway. > That means ALL the media applications, almost all the toolchain applications, most languages and a couple of other items I don't touch. I don't think it shoud be part of the spec even if you don't have test broken on delivery. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 15:06:44 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > If a test suite isn't viable, the ebuild should be RESTRICTing test > > anyway. > > which doesnt apply here ... some packages have ridiculous awesome > coverage for their source code and take much longer to run than even > compile the package > > care to force mysql test suites on everyone ? php ? gcc ? > binutils ? A separate solution is needed for those anyway, since there're plenty of people running with FEATURES=test. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
Alex Tarkovsky wrote: > 2) Why must some Gentoo devs like yourself and Mr. Gianelloni reply > with expletives to things you disagree with? It's no wonder you need > proctors; unwarranted escalation and invective seems to come so > naturally here. Oh come on. Your mail wasn't based on actual facts, you were just ranting, so you were asked to stop that. Escalation is what you're doing right now. So just get a beer and be cool, okay? It's friday, after all... Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 21:29:29 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > If a test suite isn't viable, the ebuild should be RESTRICTing test > > anyway. > > That means ALL the media applications, almost all the toolchain > applications, most languages and a couple of other items I don't > touch. What, you're saying they all ship with test suites that exist but don't work? > I don't think it shoud be part of the spec even if you don't have test > broken on delivery. src_test is already part of the spec, and ebuilds are supposed to either support it or RESTRICT it. I'm just proposing that EAPI 1 be a lot stricter about it... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
> > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be > > > helpful for an awful lot of Gentoo developers. > > > > except that you back the tree into a corner that it cannot come out of > > Huh? Not at all. If a package can't use its test suite, the ebuild can > set RESTRICT=test. > > > > Please refrain from that kind of comment. It doesn't help anyone. > > > > the answer is the same: talk to the QA team to get the tree into a > > state where having src_test enabled by default is feasible and then > > the QA team can change the profile > > That isn't going to happen any time soon. There are too many changes > and the impact of turning it on is too high. A gradual migration via > EAPI is much safer and much more useful. > > > enforcing via spec is the wrong way to go here ... spec is for > > defining how the ebuilds work, not for forcing policy down peoples > > throats > > And whether or not src_test is called is part of how ebuilds work. > Policy is whether or not src_test is required to do something in all > situations, or whether it can be RESTRICTed out as necessary. First off...wow...long time since I've been active...so if anyone wants to discount my comments based on that alone feel free. I'm trying to get back in the game and I think a few e-mails as participation might be best...hopefully you'll actually see me online soon. Now on to the real topic at hand. For src_test I see things this way. 1). Even though src_test is not mandatory in the here and now any package that provides a test suite that fails said tests has a bug. It may not be a critical bug but it is in fact a bug. 2). The proper fix, again in the here and now, for said bug is either to a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since sec_test is not mandatory however these things happen rarely if at all. With the above in mind I entirely agree that adding it as a mandatory phase for EAPI=1 makes sense. Think of it this way: 1). Developer A is bumping a package and is including some new functionality in his ebuilds that require something in EAPI=1, say for example a SLOT dependency. As such Developer A is already editing the ebuild *and* testing it. 2). As part of his test he checks if the built in test suite works, something he should be doing *anyway*. If it does great, if it doesn't then he has two choices, as above, fix it or add a RESTRICT="test", at *worst* adding 15 whole characters (16 if you include the extra carriage return he will need to add) to his ebuild. 3). Developer A then marks his ebuild as EAPI=1 and off he goes on to bigger and better things. This will allow a whole slew of VERY useful information to be available: 1). The QA team can now query the tree for packages that have known bad test suites simply by looking for ebuilds that have RESTRICT="test". As it stands now this is impossible to accomplish. 2). Interested volunteers, both developer and user alike, who are looking for ways to help out, can now be given a concrete list of known test suites to go and fix, this improves the QA of the packages in the tree. 3). The fact that a bug in the test suite exists is no longer hidden from view. 4). Since the test suites are now mandatory end users can feel more confident in the state of their installed software, this is no silver bullet but it is a step in the right direction. The *only* downside that I can see here is that by default the package installation process gets a little longer. To get around this some method of globally opting out of src_test should be provided to the end user, however since it is an on by default feature someone at least has *tried* the test suite. Again, since src_test would only be turned on by default for ebuilds marked EAPI=1, not globally for the whole tree, the only additional work required of developers would be to actually run the test suite and possibly fix a bug in one of two accepted ways. After all, the ebuild is being touched *anyway*. As with all the phase changes under discussion *no one* is talking about making a global tree change, src_test would just be default for those ebuilds that have EAPI >= 1. Just my 2 cents... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
> The *only* downside that I can see here is that by default the package > installation process gets a little longer. To get around this some > method of globally opting out of src_test should be provided to the end > user, however since it is an on by default feature someone at least has > *tried* the test suite. More to the point a facility to opt out either on a per-package basis or globally should be allowed. But that is an implementation detail not a specification one. The spec should say that running src_test is default. There is nothing in that statement that says that there shouldn't be a way to turn it off if the end user doesn't want it. Take paludis for example, with SKIP_FUNCTIONS you can already do this with a simple case statement, that however as I said is implementation specific not a spec issue. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On Fri, 13 Apr 2007 21:40:53 +0200 Jan Kundrát <[EMAIL PROTECTED]> wrote: > So just get a beer and be cool, okay? It's friday, after all... No! No beer until my work shift ends! Then I'll join you. -- Andrej -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
On Friday 13 April 2007 21:55, Andrej Kacian wrote: > On Fri, 13 Apr 2007 21:40:53 +0200 > > Jan Kundrát <[EMAIL PROTECTED]> wrote: > > So just get a beer and be cool, okay? It's friday, after all... > > No! No beer until my work shift ends! Then I'll join you. Your work shift ending? Hah you're a dev so your shift never ends :) Who want to drink beer friday night when they can dance with Bugzie while staying on their lazy ass? /me invites Bugzie for another dance and swirls off -- Sune Kloppenborg Jeppesen (Jaervosz) pgpUhhgfAXnto.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-lang/ruby-cvs
dev-lang/ruby-cvs builds the latest Ruby 1.9.x version from CVS. Except... upstream has moved to SVN, so this ebuild no longer works. It's now masked and will be removed in 30 days. An initial ruby-svn ebuild can be found in https://bugs.gentoo.org/ show_bug.cgi?id=173817 and will hopefully be included in our CVS soon. Hans -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 2007-04-13 at 12:17 -0700, Daniel Ostrow wrote: > > > > > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be > > > > helpful for an awful lot of Gentoo developers. > > > > > > except that you back the tree into a corner that it cannot come out of > > > > Huh? Not at all. If a package can't use its test suite, the ebuild can > > set RESTRICT=test. > > > > > > Please refrain from that kind of comment. It doesn't help anyone. > > > > > > the answer is the same: talk to the QA team to get the tree into a > > > state where having src_test enabled by default is feasible and then > > > the QA team can change the profile > > > > That isn't going to happen any time soon. There are too many changes > > and the impact of turning it on is too high. A gradual migration via > > EAPI is much safer and much more useful. > > > > > enforcing via spec is the wrong way to go here ... spec is for > > > defining how the ebuilds work, not for forcing policy down peoples > > > throats > > > > And whether or not src_test is called is part of how ebuilds work. > > Policy is whether or not src_test is required to do something in all > > situations, or whether it can be RESTRICTed out as necessary. > > > > First off...wow...long time since I've been active...so if anyone wants > to discount my comments based on that alone feel free. I'm trying to get > back in the game and I think a few e-mails as participation might be > best...hopefully you'll actually see me online soon. > > Now on to the real topic at hand. For src_test I see things this way. > Welcome back to the real (Gentoo, that is) world. :) Good summary of the situation, I think (although I've snipped it since everyone's read it once.) --- snip --- > Just my 2 cents... > > --Dan Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: dev-lang/ruby-cvs
Hans de Graaff wrote: dev-lang/ruby-cvs builds the latest Ruby 1.9.x version from CVS. Except... upstream has moved to SVN, so this ebuild no longer works. It's now masked and will be removed in 30 days. Not sure there's any point to waiting the usual 30 days when the ebuild just can't work anymore.. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: 2007.0 release
On Fri, 2007-04-13 at 21:16 +0200, Jakub Moc wrote: > I'm not implying there's anything wrong w/ restricting the bug; just > that pointing users here to it won't get them very far. ;) *I* didn't point anyone to that bug, as I knew it was locked and wouldn't provide our users with much of anything in the way of information regarding the release. > > Currently, I keep track of the release via a spreadsheet > but I've > been working towards getting > > a project tracking software package setup and configured to replace this > > functionality. > > Sounds cool, good luck. Homebrew one, or something else? :) I'm using dotproject currently. I am hoping that we can eventually move it to another machine, but for the time being I just have to take the time to fill in all of the tasks. It really sucks when doing this since every single task has to be duplicated for every architecture. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Empty DEPEND strings in virtuals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
> so only three virtual ebuilds have a DEPEND
According to GLEP 37 [1], they should only define RDEPEND. The
reason that only RDEPEND is needed is that a package that has a
virtual dependency has freedom to include the virtual atom in any of
DEPEND, RDEPEND, and PDEPEND as necessary. Note that when portage's
$ROOT feature is used, DEPEND is installed to the build platform.
The virtual ebuild itself does not make this decision, but rather
the package that has a virtual dependency.
> So it seems most ebuilds for new style virtuals don't have DEPENDs.
> Anyone have any idea on how these are supposed to work or are they
> buggy? PMS currently says that RDEPEND doesn't have to be installed at
> the time a package is emerged so as far as I understand it this means
> that DEPEND="virtual/foobar" could mean that it could happen that
> nothing providing the virtual is available.
The bit about "RDEPEND doesn't have to be installed" is only for
solving circular RDEPEND during the installation process. When a
package has RDEPEND that is not installed, it must be considered
unusable and therefore this state should only exist for a relatively
short period of time during the installation process.
> So should we be changing the
> DEPEND atoms to DEPEND="${RDEPEND}" or is there something I am missing here?
We should not, as I've explained above.
Zac
[1] http://www.gentoo.org/proj/en/glep/glep-0037.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
iD8DBQFGH/fs/ejvha5XGaMRAhZoAJwPH7W04pL8EfkJ4STM+79Drl0jcQCdGjGz
n4Ee8wfFp3RgpKy25ftjoXo=
=TBuW
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 and volumes (raid, lvm, crypt, etc)
Mike Frysinger wrote: > On Friday 13 April 2007, Chris Gianelloni wrote: > >> On Fri, 2007-04-13 at 11:23 -0500, Alex Tarkovsky wrote: >> >>> It's mid-April and 2007.0 is still nowhere in sight, so the idea that >>> there will be a 2007.1 is looking increasingly unrealistic. Please >>> don't make baselayout-2's unmasking contingent on that. >>> >> I guess I should just delete all this 2007.0 media we've been working on >> then, huh? >> >> I'm simply amazed at the level of complete and total bullshit that some >> people spout off on this list without bothering to check facts or take 3 >> seconds to talk to the people in the know. If you don't know what >> you're talking about, rather than open your mouth and prove to everyone >> that you are clueless about the particular topic, it's probably best to >> either ask someone or talk about something you're actually familiar >> with, instead. For those of you wondering, 2007.0 is close to being >> finished. You can blame the abnormally high number of security >> vulnerabilities in large packages for the delays. Also, the dates given >> on the Release Engineering pages are nothing more than guesses made by >> me months before we even start the release. They are in no way binding. >> > > so full of hate ! > -mike > http://en.wikipedia.org/wiki/Scott_Tenorman_Must_Die I say we never piss Chris off again... ever... -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Empty DEPEND strings in virtuals
Zac Medico kirjoitti: > > [1] http://www.gentoo.org/proj/en/glep/glep-0037.html We should link this info to the devmanual. Opened a bug about this: https://bugs.gentoo.org/show_bug.cgi?id=174530 Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Empty DEPEND strings in virtuals
On Fri, 13 Apr 2007 21:50:50 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] /usr/portage/virtual $ grep 'DEPEND=""' -r . | wc -l
> 97
> [EMAIL PROTECTED] /usr/portage/virtual $ find -name "*.ebuild" | wc -l
> 102
>
> [EMAIL PROTECTED] /usr/portage/virtual $ find -name "*.ebuild" | xargs
> grep -L 'DEPEND=""' | xargs grep DEPEND
> ./pmake/pmake-0.ebuild:RDEPEND="!userland_BSD? ( sys-devel/pmake )"
> ./perl-Scalar-List-Utils/perl-Scalar-List-Utils-1.19.ebuild:RDEPEND="~perl-core/Scalar-List-Utils-${PV}"
> ./c++-tr1-type-traits/c++-tr1-type-traits-0.ebuild:DEPEND="|| (
> >=sys-devel/gcc-4.1 dev-libs/boost )"
> ./c++-tr1-memory/c++-tr1-memory-0.ebuild:DEPEND="|| (
> >=sys-devel/gcc-4.1 dev-libs/boost )"
> ./c++-tr1-functional/c++-tr1-functional-0.ebuild:DEPEND="|| (
> >=sys-devel/gcc-4.1 dev-libs/boost )"
>
> so only three virtual ebuilds have a DEPEND
>
> So it seems most ebuilds for new style virtuals don't have DEPENDs.
> Anyone have any idea on how these are supposed to work or are they
> buggy? PMS currently says that RDEPEND doesn't have to be installed at
> the time a package is emerged so as far as I understand it this means
> that DEPEND="virtual/foobar" could mean that it could happen that
> nothing providing the virtual is available. So should we be changing the
> DEPEND atoms to DEPEND="${RDEPEND}" or is there something I am missing here?
As soon as a dependency chain has a DEPEND element then all lower
RDEPEND elements get converted into DEPENDs as well. Guess that might
be confusing, so example would be:
- app/bla has DEPEND="virtual/foo"
- virtual/foo has RDEPEND="lib/bar"
- in the internal depgraph app/bla gets DEPEND="lib/bar" as a result of
the transitive dependency
At least that's just how it should behave conceptually.
Marius
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 13 Apr 2007 18:18:27 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Fri, 13 Apr 2007 19:06:42 +0200 > Jakub Moc <[EMAIL PROTECTED]> wrote: > > Err, your suggestion was: > > > > * Remove automatic directory making for do* > > Because I was giving a one line summary, rather than a description of > the full change. The full description has been discussed elsewhere > several times. I don't remember any discussion about this, so a more specific pointer would be appreciated. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: 2007.0 release
On 4/13/07, Chris Gianelloni <[EMAIL PROTECTED]> wrote: On Fri, 2007-04-13 at 21:16 +0200, Jakub Moc wrote: > I'm not implying there's anything wrong w/ restricting the bug; just > that pointing users here to it won't get them very far. ;) *I* didn't point anyone to that bug, as I knew it was locked and wouldn't provide our users with much of anything in the way of information regarding the release. The channel topic in #gentoo-releng points to it. Steered this user wrong. --Alex -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Sat, 14 Apr 2007 00:02:29 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: > > Because I was giving a one line summary, rather than a description > > of the full change. The full description has been discussed > > elsewhere several times. > > I don't remember any discussion about this, so a more specific pointer > would be appreciated. For do*, the suggestion was to remove automatic directory creation for utilities where the directory to be made isn't clear and static based upon the utility name. In practice, this means removing it from dosym, not adding it to dohard, and cleaning up doins in some unspecified manner. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: dev-lang/ruby-cvs
Hans de Graaff wrote: > dev-lang/ruby-cvs builds the latest Ruby 1.9.x version from CVS. > Except... upstream has moved to SVN, so this ebuild no longer works. It's > now masked and will be removed in 30 days. > Is there any point in waiting 30 days? Since the ebuild just doesn't work because of a VCS change, it's clear it won't work at all for anyone no matter how much hacking they do. The 30 day rule in this case should not apply. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: 2007.0 release
Alex Tarkovsky wrote: On 4/13/07, Chris Gianelloni <[EMAIL PROTECTED]> wrote: On Fri, 2007-04-13 at 21:16 +0200, Jakub Moc wrote: > I'm not implying there's anything wrong w/ restricting the bug; just > that pointing users here to it won't get them very far. ;) *I* didn't point anyone to that bug, as I knew it was locked and wouldn't provide our users with much of anything in the way of information regarding the release. The channel topic in #gentoo-releng points to it. Steered this user wrong. And #gentoo-releng is a channel for devs that are members of releng, not users. There's a reason why it's +m. The information isn't there for users. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: dev-lang/ruby-cvs
Doug Goldstein wrote: Hans de Graaff wrote: dev-lang/ruby-cvs builds the latest Ruby 1.9.x version from CVS. Except... upstream has moved to SVN, so this ebuild no longer works. It's now masked and will be removed in 30 days. Is there any point in waiting 30 days? Since the ebuild just doesn't work because of a VCS change, it's clear it won't work at all for anyone no matter how much hacking they do. The 30 day rule in this case should not apply. Yes ... upstream moved to SVN right around the first of the year. If you want, I'll file something in bugzilla to get the details for Ruby 1.9 into Portage as an enhancement. Most of my Rubyist friends go right to the source repositories anyhow, so I'm not sure it even needs to be in Portage at this point. 1.9 is scheduled for release around Christmas 2007. "jRuby" should be closely tracked, however -- they will be at 1.0 in a few weeks, I think. -- M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P) http://borasky-research.net/ If God had meant for carrots to be eaten cooked, He would have given rabbits fire. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 13 Apr 2007 20:33:09 +0100: > On Fri, 13 Apr 2007 15:06:44 -0400 > Mike Frysinger <[EMAIL PROTECTED]> wrote: >> > If a test suite isn't viable, the ebuild should be RESTRICTing test >> > anyway. >> >> which doesnt apply here ... some packages have ridiculous awesome >> coverage for their source code and take much longer to run than even >> compile the package >> >> care to force mysql test suites on everyone ? php ? gcc ? binutils ? > > A separate solution is needed for those anyway, since there're plenty of > people running with FEATURES=test. FEATURES=bigtest ?? Interesting idea. Then default test to on and bigtest to off, with appropriate user descriptions and developer guidelines for when use of "bigtest" is appropriate (extra deps, long runtime, etc.). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Ciaran McCreesh wrote: > On Sat, 14 Apr 2007 00:02:29 +0200 > > Marius Mauch <[EMAIL PROTECTED]> wrote: > > > Because I was giving a one line summary, rather than a description > > > of the full change. The full description has been discussed > > > elsewhere several times. > > > > I don't remember any discussion about this, so a more specific pointer > > would be appreciated. > > For do*, the suggestion was to remove automatic directory creation for > utilities where the directory to be made isn't clear and static based > upon the utility name. In practice, this means removing it from dosym, > not adding it to dohard, and cleaning up doins in some unspecified > manner. dohard has been fixed to match the behavior of all the other do* bins -mike pgpv2jQxAzL3w.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Friday 13 April 2007, Daniel Ostrow wrote: > 1). Even though src_test is not mandatory in the here and now any > package that provides a test suite that fails said tests has a bug. It > may not be a critical bug but it is in fact a bug. > > 2). The proper fix, again in the here and now, for said bug is either to > a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since > sec_test is not mandatory however these things happen rarely if at all. > > With the above in mind I entirely agree that adding it as a mandatory > phase for EAPI=1 makes sense. Think of it this way: > > 1). Developer A is bumping a package and is including some new > functionality in his ebuilds that require something in EAPI=1, say for > example a SLOT dependency. As such Developer A is already editing the > ebuild *and* testing it. > > 2). As part of his test he checks if the built in test suite works, > something he should be doing *anyway*. If it does great, if it doesn't > then he has two choices, as above, fix it or add a RESTRICT="test", at > *worst* adding 15 whole characters (16 if you include the extra carriage > return he will need to add) to his ebuild. > > 3). Developer A then marks his ebuild as EAPI=1 and off he goes on to > bigger and better things. > > This will allow a whole slew of VERY useful information to be available: > > 1). The QA team can now query the tree for packages that have known bad > test suites simply by looking for ebuilds that have RESTRICT="test". As > it stands now this is impossible to accomplish. > > 2). Interested volunteers, both developer and user alike, who are > looking for ways to help out, can now be given a concrete list of known > test suites to go and fix, this improves the QA of the packages in the > tree. > > 3). The fact that a bug in the test suite exists is no longer hidden > from view. > > 4). Since the test suites are now mandatory end users can feel more > confident in the state of their installed software, this is no silver > bullet but it is a step in the right direction. > > The *only* downside that I can see here is that by default the package > installation process gets a little longer. To get around this some > method of globally opting out of src_test should be provided to the end > user, however since it is an on by default feature someone at least has > *tried* the test suite. so you've validated that the platform the developer testing the ebuild on works ... you know nothing about any other platform that Gentoo supports and in the end, the users continue to hit src_test failure after src_test failure which, after they quickly get tired of filing [duplicate] bugs, they realize they have no way at all of disabling the mandatory test ... RESTRICT is an ebuild variable, not a package manager variable as you said yourself, it may not be a critical bug, but it's still a bug and users have no way of trivially bypassing it or even opting out of tests in the first place. you may enjoy running src_test on every single machine of yours out there, but i certainly dont. this is why implementing it via the profile FEATURES works ... users can still easily opt out and in case of some catastrofuck and we havent screwed ourselves into a corner by mixing policy with spec -mike pgpks5ACl0q1j.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, Apr 13, 2007 at 03:06:44PM -0400, Mike Frysinger wrote: > which doesnt apply here ... some packages have ridiculous awesome coverage > for > their source code and take much longer to run than even compile the package Furthermore, there are packages with testcases where if you want them, you basically need to build in a specific way, and then rebuild again for the version that you install (or build twice during src_compile in the first place). -- Robin Hugh Johnson Gentoo Linux Developer & Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpWHJGzcy2Bs.pgp Description: PGP signature
[gentoo-dev] Re: Last rites: dev-lang/ruby-cvs
On Fri, 13 Apr 2007 18:49:05 -0400, Doug Goldstein wrote: > Hans de Graaff wrote: >> dev-lang/ruby-cvs builds the latest Ruby 1.9.x version from CVS. >> Except... upstream has moved to SVN, so this ebuild no longer works. >> It's now masked and will be removed in 30 days. >> >> > Is there any point in waiting 30 days? Since the ebuild just doesn't > work because of a VCS change, it's clear it won't work at all for anyone > no matter how much hacking they do. The 30 day rule in this case should > not apply. I agree that in this case it's not needed, but I think it's the courteous thing to do and AFAIK no electrons will be unduly harmed by it. Also, it makes it easier for someone in the ruby team to look at the ebuild for reference when working on the ruby-svn ebuild. Hans -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh wrote:
> What, you're saying they all ship with test suites that exist but don't
> work?
anything that takes more than 10m to test is broken from an user point
of view: you want the application, not having it tested.
I'd rather keep it in features since tests are _optional_, not necessary
to use the applications, just a waste of user time if they aren't
concerned (e.g.: nobody but some would care about ffmpeg failing to do
bit exact decoding of an ${fringe codec} nobody but who is developing it
uses, and surely will be angry at me not being able to get those 20%
speed improvements on h264).
>
>> I don't think it shoud be part of the spec even if you don't have test
>> broken on delivery.
>
> src_test is already part of the spec, and ebuilds are supposed to
> either support it or RESTRICT it. I'm just proposing that EAPI 1 be a
> lot stricter about it...
>
Adding more build time, requirements (yes, there are some tests that
needs more ram and cpu to complete than the actual build phase) w/out
ways to opt out is just hindering our users.
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] RFC - Keywording scheme
Fabian Groffen wrote: > This GLEP has been laying around for some long time now in my gleps dir. > I nearly forgot about it. Anyway, feedback is appreciated. > Since it is "a keywording scheme that is compatible with the scheme that is currently in use" and fulfils all the requirements, it sounds like a no-brainer to me.. i'm sure someone will flame me for daring to say so but wtf ;) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: April Council meeting summary
Ciaran McCreesh wrote: >> It's not such a big deal in practise is it? > > Yes, it is. It's a change in workflow, and it at least doubles the > amount of work for each commit. > do what? if it's so tricky write a script.. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Saturday 14 April 2007 18:14:48 Luca Barbato wrote: > Ciaran McCreesh wrote: > > What, you're saying they all ship with test suites that exist but don't > > work? > > anything that takes more than 10m to test is broken from an user point > of view: you want the application, Indeed, but speaking as a user, one wants the application to build and work, that is after all the whole point of installing a package. > not having it tested. That all depends. If having it tested means that it _will_ work, I'd be infavour of that. However I do appreciate that having every user's install repeating tests which have been done thousands of times before is probably un-neccessary. How abouot setting the _default_ for test flags to true for '~' builds and false for supposedly stable builds? [ all good stuff ] -- CS -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: April Council meeting summary
Ilya A. Volynets-Evenbakh wrote: > I'd say Ciaran has to have write access to any such repository, > as one of the main contributors. > Face it, he's never going to get write access to gentoo infra. The best gentoo can give him is access via spb, who has made it clear he'll simply be pulling in whatever ciaran commits. What is the issue? -- [EMAIL PROTECTED] mailing list
[gentoo-dev] OT: was 2007.0 release
Hi, Tempted by this recent thread, wanna just voice my thoughts. Can't there be some way (GWN, Bug, some general-purpose IRC channel etc.) on which users could at least be informed that work is under way to release 2007.0, with some kind of feedback. Releng could just choose to ignore it at all, but it's a possibility to inform users that work is done (once in a week or two). It's clear nobody can work on a busy/noisy street ;) so the current ways are ok. It's also evident that people who donate there time/force to work for others can't be pushed for anything, just a way to escape creating some tension among users. Somebody might want to know (for a new install) for how long (eventually) he/she will have to wait. A true community must communicate to be a community at all. The errors/"weak points" we make is what makes are go forward :) So nothing wrong with any kind of problems here (don't imply there are any). Time to finish, lets hope i could make myself clear enough. NO flames intended. Rumen -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Deps (was Re: Empty DEPEND strings in virtuals)
Petteri Räty wrote: > We should link this info to the devmanual. Yeah that was v. instructive. Since there's only 3 ebuilds left with the old syntax, the obvious question is: is there anything else holding up impl of the GLEP? Also, would the preferred syntax be open to usage in eg recommended deps as opposed to mandatory ones? I appreciate that it's not the same GLEP or anything. I'm also curious about impl date of ranged deps and use deps, without wanting to start a flamewar about the merits or lack thereof. -- [EMAIL PROTECTED] mailing list
