[gentoo-dev] Re: New project: Gentoo Seeds

2006-09-21 Thread Daniel Watkins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Being a top level project, you are in essence saying that we want to do this on our own without the help of a group that has been doing a less focused version of what you are aiming to provide. It goes against the entire point of the cooperation

[gentoo-dev] Re: New project: Gentoo Seeds

2006-09-21 Thread Daniel Watkins
Thomas Cort wrote: On Tue, 19 Sep 2006 21:11:17 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: why does it need to be part of releng ? releng and seeds will be doing similar tasks, releasing stage tarballs. Might I ask why it needs to be anywhere specific until it's actually had more than

[gentoo-dev] Re: New project: Gentoo Seeds

2006-09-21 Thread Christian 'Opfer' Faulhammer
Tach Ramon, 0x2B859DE3 (PGP-PK-ID) Thanks for that post. Ramon van Alteren schrieb: 9. Most of this mail has been on policies, expected behavior and perceived behavior. I would like to get this discussion back to technical issues wrt to generating stages/seeds

[gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Alin Nastac
I'm annoyed about impossibility to fix a certain class of breakages (other than reemerging the failing package). I am referring to the breakages occurred when foo has been upgraded, but the bar package cannot work with it because it was build against the old foo version. We all had to run

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Luca Barbato
Alin Nastac wrote: I reckon this could be solved by yet another *DEPEND variable. The only atoms accepted by this variable would be CATEGORY/PN. Every time when a package gets updated from PV1 to PV2 (distinct versions, revisions will not count), portage will automatically re-emerge those

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Brian Harring
On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote: Alin Nastac wrote: I reckon this could be solved by yet another *DEPEND variable. The only atoms accepted by this variable would be CATEGORY/PN. Every time when a package gets updated from PV1 to PV2 (distinct versions, revisions

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Alin Nastac
Luca Barbato wrote: Alin Nastac wrote: I reckon this could be solved by yet another *DEPEND variable. The only atoms accepted by this variable would be CATEGORY/PN. Every time when a package gets updated from PV1 to PV2 (distinct versions, revisions will not count), portage will automatically

Re: [gentoo-dev] The Seed Project - Try 2

2006-09-21 Thread Lance Albertson
Donnie Berkholz wrote: 3) Mirror storage seemed to be an issue. There are plenty of offerings from the adopt-a-dev project for bandwidth and server space that I think could be utilized to suit this and let release engineering utilize the official space for their releases. Seems to me the

Re: [gentoo-dev] GLEP updates

2006-09-21 Thread Marius Mauch
Sorry for the late reply, had some problem with my mail setup recently. On Sun, 3 Sep 2006 22:53:44 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: Thanks to atarus, I've updated a number of GLEPs: 40 (arch teams) Now marked Final 44 (manifest2)Now marked Final I wouldn't consider

Re: [gentoo-dev] The Seed Project - Try 2

2006-09-21 Thread Lance Albertson
Mike Frysinger wrote: 3) Mirror storage seemed to be an issue. There are plenty of offerings from the adopt-a-dev project for bandwidth and server space that I think could be utilized to suit this and let release engineering utilize the official space for their releases. isnt it an issue

[gentoo-dev] Notification about MD5 support

2006-09-21 Thread Marius Mauch
Ferringb recently told me that this info apparently wasn't mentioned explicit enough in Glep 44: Manifest2 records do not contain a MD5 checksum. The only guaranteed checksum type there is SHA1. So once manifest1 is phased out the tree will not contain MD5 checksums anymore. This is just a

Re: [gentoo-dev] The Seed Project - Try 2

2006-09-21 Thread Stuart Herbert
On 9/21/06, Lance Albertson [EMAIL PROTECTED] wrote: Stuart: When you get a chance, can you please either message me on irc or send em an email with your thoughts on how hosting might work so we can start planning that? Lance: Will do. Everyone else: Please stop speculating about how we're

Re: [gentoo-dev] The Seed Project - Try 2

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 09:27, Lance Albertson wrote: Mike Frysinger wrote: 3) Mirror storage seemed to be an issue. There are plenty of offerings from the adopt-a-dev project for bandwidth and server space that I think could be utilized to suit this and let release engineering

Re: [gentoo-dev] Notification about MD5 support

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 09:34, Marius Mauch wrote: Manifest2 records do not contain a MD5 checksum. The only guaranteed checksum type there is SHA1. So once manifest1 is phased out the tree will not contain MD5 checksums anymore. by guaranteed do you mean guaranteed to be in the records

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 06:35, Alin Nastac wrote: For instance, the recent openssl-0.9.8* update broke dev-libs/neon (and consequently subversion) because neon library isn't happy just by linking with libssl.so.0.9.7 but also check the libssl version when loads the ssl library. Another

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 07:59, Brian Harring wrote: Why have the explicit var? Because 0.9.7a through 0.9.7c may all be compatible, but 0.9.7d isn't. If you force an automatic algo that tries to (effectively) guess, you get a lot of rebuilds through a,b,c, end result being folks likely

Re: [gentoo-dev] Notification about MD5 support

2006-09-21 Thread Brian Harring
On Thu, Sep 21, 2006 at 09:49:18AM -0400, Mike Frysinger wrote: On Thursday 21 September 2006 09:34, Marius Mauch wrote: Manifest2 records do not contain a MD5 checksum. The only guaranteed checksum type there is SHA1. So once manifest1 is phased out the tree will not contain MD5 checksums

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Brian Harring
On Thu, Sep 21, 2006 at 09:52:27AM -0400, Mike Frysinger wrote: On Thursday 21 September 2006 07:59, Brian Harring wrote: Why have the explicit var? Because 0.9.7a through 0.9.7c may all be compatible, but 0.9.7d isn't. If you force an automatic algo that tries to (effectively) guess, you

Re: [gentoo-dev] Notification about MD5 support

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 10:00, Brian Harring wrote: On Thu, Sep 21, 2006 at 09:49:18AM -0400, Mike Frysinger wrote: On Thursday 21 September 2006 09:34, Marius Mauch wrote: Manifest2 records do not contain a MD5 checksum. The only guaranteed checksum type there is SHA1. So once

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Donnie Berkholz
Mike Frysinger wrote: On Thursday 21 September 2006 07:59, Brian Harring wrote: Why have the explicit var? Because 0.9.7a through 0.9.7c may all be compatible, but 0.9.7d isn't. If you force an automatic algo that tries to (effectively) guess, you get a lot of rebuilds through a,b,c, end

[gentoo-dev] gnutls-1.4.4 unmasked and becoming stable

2006-09-21 Thread Daniel Black
As previously mentioned versions prior to gnutls-1.4.4 have an outstanding security bug https://bugs.gentoo.org/show_bug.cgi?id=147682. This package (gnutls-1.4.4), and (libtasn1-0.3.5), have now been unmasked and some are stabled. After emerging these packages a revdep-rebuild will be

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Alin Nastac
Brian Harring wrote: On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote: There is one flaw with this though; packages can provide both libraries _and_ binaries. Our dependencies don't represent whether the dep is actual linkage, or just commandline consuming, so (using the

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 10:14, Donnie Berkholz wrote: Not adding it into the ebuild means that it's impossible to show in advance what packages will actually be installed, because you don't know whether the sover will bump. sometimes you dont know as the ABI bump may be arch or feature

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 10:04, Brian Harring wrote: I agree; while I'm labeling it ABI, includes both bad soname handling and seperate sonames. those people should be smacked (for the interest of disclosure, i have violated the bad soname rule for the sake of following upstream) Feel

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 10:38, Alin Nastac wrote: Brian Harring wrote: There is one flaw with this though; packages can provide both libraries _and_ binaries. Our dependencies don't represent whether the dep is actual linkage, or just commandline consuming, so (using the openssl

Re: [gentoo-dev] Notification about MD5 support

2006-09-21 Thread Vlastimil Babka
Mike Frysinger wrote: ok, but it just seems silly to go cutting MD5 but leaving SHA1 ... if we're going to be leaving an insecure format, we might as well keep the one that is a virtual standard in and of itself (MD5) -mike GLEP 44 says: snip For compability though we have to rely on at

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Donnie Berkholz
Mike Frysinger wrote: On Thursday 21 September 2006 10:14, Donnie Berkholz wrote: Not adding it into the ebuild means that it's impossible to show in advance what packages will actually be installed, because you don't know whether the sover will bump. sometimes you dont know as the ABI bump

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Duncan Coutts
On Thu, 2006-09-21 at 09:52 -0400, Mike Frysinger wrote: On Thursday 21 September 2006 07:59, Brian Harring wrote: Why have the explicit var? Because 0.9.7a through 0.9.7c may all be compatible, but 0.9.7d isn't. If you force an automatic algo that tries to (effectively) guess, you get a

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 10:54, Donnie Berkholz wrote: Yes, I agree with you. For example, take expat. The maintainers have refused to allow both versions to exist simultaneously on a system because it apparently causes more breakage than just breaking every app on your system by removing

Re: [gentoo-dev] Notification about MD5 support

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 10:49, Vlastimil Babka wrote: GLEP 44 says: touche -mike pgpy7mqcfngBq.pgp Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Brian Harring
On Thu, Sep 21, 2006 at 05:38:08PM +0300, Alin Nastac wrote: Brian Harring wrote: On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote: There is one flaw with this though; packages can provide both libraries _and_ binaries. Our dependencies don't represent whether the dep

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Brian Harring
On Thu, Sep 21, 2006 at 10:43:11AM -0400, Mike Frysinger wrote: On Thursday 21 September 2006 10:04, Brian Harring wrote: I agree; while I'm labeling it ABI, includes both bad soname handling and seperate sonames. those people should be smacked (for the interest of disclosure, i have

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Simon Stelling
Duncan Coutts wrote: So for it's something like: # for C: ABI=${SONAME} # for python ABI=${PY_PV} # for haskell: ABI=${GHC_PV} paludis has something going in this direction but I don't think it'd quite solve the python/ghc abi issue. It was aimed more at cases like mips with it's

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Mike Frysinger
On Thursday 21 September 2006 10:56, Duncan Coutts wrote: If we do go in this direction it'd be great to be able to slot on the ABI and still have dependencies resolved correctly. For example imagine having parallel python-2.3 and 2.4 installations with some libs installed for both. Crucially,

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Duncan Coutts
On Thu, 2006-09-21 at 11:11 -0400, Mike Frysinger wrote: On Thursday 21 September 2006 10:56, Duncan Coutts wrote: If we do go in this direction it'd be great to be able to slot on the ABI and still have dependencies resolved correctly. For example imagine having parallel python-2.3 and 2.4

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Alin Nastac
Brian Harring wrote: BDEPEND was actually a seperate proposal/idea, intention there was to have that be the deps that *must* be CHOST (gcc would be an example); bits that are used to actually build the pkg, not data it consumes in building (headers would be data). Well, until now I

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Alin Nastac
Mike Frysinger wrote: i think you're merging the two issues you brought up ... there is binary ABI issues (which should not require a new DEPEND variable as portage can extract that information out at runtime) and there is runtime plugin issues with packages using dlopen() (which portage

[gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Grant Goodyear
For whatever it's worth, I rather like the Gentoo Seeds project, although I'm more interested in nice tools to make the seeds, than in having pre-existing seeds. Ciaranm has argued that the project really should have been GLEPped. Although I wouldn't have opposed such a GLEP, it's not clear to me

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Luca Barbato
Duncan Coutts wrote: So my point is, I don't think it can be simply dismissed as ABI nonsense that we don't have to deal with. Being able to SLOT on the compiler flavour (and possibly version) would allow us to do useful things that we cannot currently do. what about making them build what

Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Simon Stelling
Grant Goodyear wrote: If we (being Gentoo) say that we're going to do something, and then things fall through, it might make us look bad, after all. Maybe it's just me being stupid, but what exactly do we have to loose? (This is a serious question, I'd appreciate serious answers.) -- Kind

Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-21 Thread Nick Rout
On Wed, 20 Sep 2006 23:53:39 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 20 Sep 2006 18:42:13 -0400 Alec Warner [EMAIL PROTECTED] wrote: | As Donnie said; if this is the thanks one gets for trying out a new | idea; then why try at all. The complaints are not that Stuart tried a

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Brian Harring
On Thu, Sep 21, 2006 at 08:15:48PM +0300, Alin Nastac wrote: Brian Harring wrote: BDEPEND was actually a seperate proposal/idea, intention there was to have that be the deps that *must* be CHOST (gcc would be an example); bits that are used to actually build the pkg, not data it consumes

Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-21 Thread Alec Warner
However the behaviour displayed in this list, and in particular this thread are downright embarassing. I used to be proud of being a gentoo user and following a group of dedicated and clever developers. Now I just want to find a quick and easy way to get rid of it. You have had your antics

Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Joshua Jackson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: Grant Goodyear wrote: If we (being Gentoo) say that we're going to do something, and then things fall through, it might make us look bad, after all. Maybe it's just me being stupid, but what exactly do we have to loose?

Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Ciaran McCreesh
On Thu, 21 Sep 2006 20:28:46 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Grant Goodyear wrote: | If we | (being Gentoo) say that we're going to do something, and then things | fall through, it might make us look bad, after all. | | Maybe it's just me being stupid, but what exactly do we

Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Simon Stelling
Ciaran McCreesh wrote: Huge amounts of time, effort and users. How much arch team time was spent fixing genkernel? How much time was spent fixing the OS X mess? How many users did we lose as a result of all the QA screwups? Eh, I wanted answers, not more questions :P As much as I hate

Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Mike Pagano
On 9/21/06, Simon Stelling [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Huge amounts of time, effort and users. How much arch team time was spent fixing genkernel? How much time was spent fixing the OS X mess? How many users did we lose as a result of all the QA screwups? Eh, I wanted

Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Lance Albertson
Grant Goodyear wrote: To some extent, we're back to determining what the word official means in these cases. My goal in making projects easy to create was to support innovative ideas. Most innovative ideas don't pan out, however, so a corollary has to be that just because a project exists

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Duncan Coutts
On Thu, 2006-09-21 at 20:27 +0200, Luca Barbato wrote: Duncan Coutts wrote: So my point is, I don't think it can be simply dismissed as ABI nonsense that we don't have to deal with. Being able to SLOT on the compiler flavour (and possibly version) would allow us to do useful things

[gentoo-dev] Re: seeds, GLEPs, and projects

2006-09-21 Thread Peter
On Thu, 21 Sep 2006 17:01:02 -0400, Mike Pagano wrote: Maybe a recruiting drive to help with the maintenance. A typical business brings on new blood and assigns them just that role to free up more senior developers for more complicated projects. New developers should definitely meet a

Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-21 Thread Nick Rout
On 9/21/2006, Alec Warner [EMAIL PROTECTED] wrote: However the behaviour displayed in this list, and in particular this thread are downright embarassing. I used to be proud of being a gentoo user and following a group of dedicated and clever developers. Now I just want to find a quick

Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Luca Barbato
Duncan Coutts wrote: On Thu, 2006-09-21 at 20:27 +0200, Luca Barbato wrote: Duncan Coutts wrote: So my point is, I don't think it can be simply dismissed as ABI nonsense that we don't have to deal with. Being able to SLOT on the compiler flavour (and possibly version) would allow us to do

[gentoo-dev] waimea needs to be fixed or removed

2006-09-21 Thread Joe Sapp
Hi all, As upstream is pretty dead [1][2] and bug #127241 [3] is still applicable, I'd like to request that somebody more knowledgeable take over the work I started on fixing the waimea window manager (see [3] for files and info), if possible. If nobody lets me know to the contrary, I'll remove

Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-21 Thread Dice R. Random
On 9/21/06, Wernfried Haas [EMAIL PROTECTED] wrote: Please keep in mind that only a few of the approximately 300 Gentoo developers are taking part in this discussion and only a few of them actually seem to get a bit more heated than it should be. If you think they are behaving poorly, feel free