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
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 x
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 usef
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 fin
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 s
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 t
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 exi
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
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 rel
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 w
-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 lo
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 display
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 con
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
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
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 yo
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
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
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
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 a
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. Crucial
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
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
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
>
On Thursday 21 September 2006 10:49, Vlastimil Babka wrote:
> GLEP 44 says:
touche
-mike
pgpy7mqcfngBq.pgp
Description: PGP signature
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 remov
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
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 ma
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:
For compability though we have to rely on at least one
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 op
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)
> Fe
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
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
>
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 required
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 resul
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 o
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) gues
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 chec
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 lik
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. Anothe
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 rec
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 engineer
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 g
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 remind
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
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
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 t
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 aut
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, revi
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 packa
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 revdep-r
51 matches
Mail list logo
