Why do we let utterly *useless* discussions eat into our precious
developer time?
Why is it that this thread has 500 replies, but Mart's
maintainer-wanted thread has less than 10?
I *do not care* if the ebuild format will not be "properly extensible"
when the need arises. We'll cross that bridge
Petteri Räty posted 4a0dd0ed.1070...@gentoo.org,
excerpted below, on Fri, 15 May 2009 23:30:37 +0300:
> Indeed there's no problem switching EAPIs as long as a stable Portage
> supports the EAPI you are migrating to. Portage was buggy with this when
> EAPI 2 was introduced but that has since been
On Sat, 16 May 2009 02:31:45 +0300
Petteri Räty wrote:
> > On the other hand you also have to make sure you have a stable
> > portage for a time long enough so mostly everyone has it installed.
> > Otherwise you could break users systems pretty badly depending on
> > the packages. And Arch-Teams u
Tiziano Müller wrote:
> Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty:
>> William Hubbs wrote:
>>> On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
> Thanks Robin for finally pushing this in the
Luca Barbato wrote:
Duncan wrote:
Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe?
Right, anyway either one or two vars, anybody has a strong feeling
towards one of them or against any of them?
QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS, that's it.
-USE_EXPAND="APACH
Le 15/05/2009 23:20, Ryan Hill a écrit :
Could I ask that people stop closing bugs against the gold linker with
such classy witticisms as "patches welcome".
Honestly, a little heads up before gold hit portage would have been nice
too.
I already had 2 bugs with gold-related issues even before
Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty:
> William Hubbs wrote:
> > On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
> >> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
> >>> Thanks Robin for finally pushing this in the tree, just didn't find t
Could I ask that people stop closing bugs against the gold linker with
such classy witticisms as "patches welcome". There is no patch a user can
provide to make a package build with the gold linker. These bugs should be
assigned to toolchain, not the maintainer of the package that gold happens to
On Friday 15 May 2009 21:06:13 Steven J Long wrote:
> In practical terms, this is a useless proposal. It rightly got trashed
> last year.
No, it did not get "trashed", despite some people's attempts to make their
side sound more popular than it really is. Some people like the idea, some
don't,
William Hubbs wrote:
> On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
>> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
>>> Thanks Robin for finally pushing this in the tree, just didn't find the
>>> time to.
>>>
>>> Maybe it's a good time to emphasize this: Keep
On Fri, 15 May 2009 21:06:13 +0100
Steven J Long wrote:
> > Before an ebuild has had its metadata generated, its EAPI is
> > unknown. At this point, the package manager assumes EAPI 0.
> >
> With the format restriction, that everyone last year seemed happy
> with, apart from the few pushing GLEP-5
Ciaran McCreesh wrote:
> Steven J Long wrote:
>> Robert R. Russell wrote:
>>
>> > If I understand the problem GLEP 55 is trying to solve correctly,
>> > it stems from portage's assumption that an unknown EAPI is equal to
>> > EAPI 0.
>>
>> No, portage will reject an ebuild with an unknown EAPI, a
On Fri, 15 May 2009 14:43:29 -0500
William Hubbs wrote:
> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> > It can't, because it doesn't know the EAPI until it's sourced the
> > thing using bash. Using things like += in global scope will break
> > older bash versions to the poin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> It can't, because it doesn't know the EAPI until it's sourced the thing
> using bash. Using things like += in global scope will break older bash
> versions to the point that they can't
Robert Bridge wrote:
> Patrick Lauer wrote:
>> On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
>>> On Thu, 14 May 2009 20:06:51 +0200
>>>
>>> Patrick Lauer wrote:
Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=
>>> Uh, so horrib
On Fri, 15 May 2009 20:12:03 +0100
Steven J Long wrote:
> Robert R. Russell wrote:
>
> > If I understand the problem GLEP 55 is trying to solve correctly,
> > it stems from portage's assumption that an unknown EAPI is equal to
> > EAPI 0.
>
> No, portage will reject an ebuild with an unknown EAP
Robert R. Russell wrote:
> If I understand the problem GLEP 55 is trying to solve correctly, it stems
> from portage's assumption that an unknown EAPI is equal to EAPI 0.
No, portage will reject an ebuild with an unknown EAPI, as per the spec.
(This is important for shared overlays.) Search for:
On Sat, 16 May 2009 00:28:36 +0530
Arun Raghavan wrote:
> As I've stated a long time ago, I'm for this solution. My
> understanding is that there are 2 objections to this:
3) It doesn't solve the problem. It doesn't allow things like version
format extensions.
That's the big one, not the other t
On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote:
[...]
> So if you were a lazy Unix coder you'd just restrict the current rules a bit
> so that there's only one line starting with EAPI= allowed (or maybe you just
> take the first or last one, but that's annoying) and if no such line matche
On Fri, 15 May 2009 11:16:11 -0500
"Robert R. Russell" wrote:
> If I understand the problem GLEP 55 is trying to solve correctly, it
> stems from portage's assumption that an unknown EAPI is equal to EAPI
> 0. Could that assumption be changed to an unknown EAPI is equal to
> the latest supported E
On Friday 15 May 2009 05:44:47 Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > On Thu, 14 May 2009 20:06:51 +0200
> >
> > Patrick Lauer wrote:
> >> Let EAPI be defined as (the part behind the = of) the first line of
> >> the ebuild starting with EAPI=
> >
> > Uh, so horribly utterly and obviou
# Merged in dev-texlive/texlive-langmongolian-2008, use that instead
# Masked for removal on 15 June 2009
dev-texlive/texlive-langmanju
Alexis.
signature.asc
Description: PGP signature
# Alex Legler (15 May 2009)
# Masked for removal wrt bug #251833. Due for removal in 30 days.
# Use app-admin/eselect-ruby instead.
dev-ruby/ruby-config
=dev-lang/ruby-1.8.6_p114
Ruby _p114 is the last Ruby with Oniguruma patches, however there are numerous
security issues. Ruby 1.9.1 will conta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
> > Thanks Robin for finally pushing this in the tree, just didn't find the
> > time to.
> >
> > Maybe it's a good time
Sven posted loom.20090514t182756-...@post.gmane.org,
excerpted below, on Thu, 14 May 2009 18:34:29 +:
> Duncan <1i5t5.duncan cox.net> writes:
>> FWIW, that'd not be a portage issue per se, but an EAPI issue, since it
>
> I see, very interesting! Sounds like a lengthy process, but never min
Daniel Pielmeier posted
6142e6140905150344y4a8007b5wd352ffe891e49...@mail.gmail.com, excerpted
below, on Fri, 15 May 2009 12:44:47 +0200:
> 2009/5/15 Marijn Schouten (hkBst) :
>>
>> Thilo Bangert wrote:
>>>
>>> Fedora is a much more current distribution than Gentoo - and has been
>>> for a coupl
On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote:
> > This .uselect
> > should not contain symlinks, but plain (text?) files only.
> Do we really need more than one file?
No, at least not to define the _values_ of a profile.
> Checklist:
> * Hostname
> * Uname
> * {$chost}
>
> Mmm...
Thanks Robin for finally pushing this in the tree, just didn't find the
time to.
Maybe it's a good time to emphasize this: Keep in mind that changing the
EAPI in an ebuild requires a revision bump (including reset to unstable
keywords, etc.).
Cheers,
Tiziano
Am Donnerstag, den 14.05.2009, 17:06
On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano Müller wrote:
> Thanks Robin for finally pushing this in the tree, just didn't find the
> time to.
>
> Maybe it's a good time to emphasize this: Keep in mind that changing the
> EAPI in an ebuild requires a revision bump (including reset to unstabl
Ciaran McCreesh wrote:
On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer wrote:
Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=
Uh, so horribly utterly and obviously wrong.
inherit foo
EAPI=4
where foo is both a global and a non-glob
2009/5/15 Marijn Schouten (hkBst) :
>
> Thilo Bangert wrote:
>>
>> Fedora is a much more current distribution than Gentoo - and has been for
>> a couple of years...
>
> Please elaborate what exactly you think Fedora does better than we do. I have
> no
> first-hand experience with Fedora, but from
Thilo Bangert wrote:
AFAIK, we have never explicitly made this distinction clear. if we had, we
would have to remove stuff from portage which doesnt live up to the
standards.
I'm all for that. In reality we tend to leave them alone until a
security issue actually comes up, which is probabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thilo Bangert wrote:
> Richard Freeman said:
>> AllenJB wrote:
>>> All that's going to happen is Gentoo will have many many buggy and
>>> out of date packages in the MAIN TREE. Exactly where they shouldn't
>>> be. You claim quality won't be sacrificed
Richard Freeman said:
> AllenJB wrote:
> > All that's going to happen is Gentoo will have many many buggy and
> > out of date packages in the MAIN TREE. Exactly where they shouldn't
> > be. You claim quality won't be sacrificed, but I simply can't see
> > this without any attempt to solve the manp
On Friday 15 May 2009 02:42:33 George Prowse wrote:
> Having countered those four points I guess you agree with the other five
> then. Over 50% success rate (by your definition) is hardly being
> ignorant or trolling
In that case we can assume that Patrick agrees with all my counterpoints,
since
35 matches
Mail list logo
