Ulrich Mueller posted on Thu, 06 Sep 2012 07:30:46 +0200 as excerpted:
>> On Thu, 06 Sep 2012, Jorge Manuel B S Vicetto wrote:
>
>> Title: make.conf and make.profile move to /etc/portage
> 0112233
> 12345678091234567890123456789012345678
On Wed, 5 Sep 2012 18:15:43 +0200
Michał Górny wrote:
> If we really want to go this route, then please at least require
> explicit label at start of DEPENDENCIES. And the same when appending
> to DEPENDENCIES -- just so 'unlikely' mistakes will leave us with
> hours of debugging.
We should take
> On Thu, 06 Sep 2012, Jorge Manuel B S Vicetto wrote:
> Title: make.conf and make.profile move to /etc/portage
0112233
12345678091234567890123456789012345678901234567
Too long, maximum 44 characters are allowed.
> Display-If-Profile:
On Wed, Sep 05, 2012 at 10:11:05PM -0400, Walter Dnes wrote:
> I saw this a couple of days ago on the busybox mailing list. See...
> http://comments.gmane.org/gmane.linux.busybox/36695
Probably a question best for vapier & our toolchain folks, but any
reason we can't modify splitdebug to put the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Following the July 24th thread about changing the default location of
make.conf and make.profile in the new stages, I propose to commit 2
news items in 2 or 3 days.
The first one (previous email) was directed to all users and informs
about the cha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Following the July 24th thread about changing the default location of
make.conf and make.profile in the new stages, I propose to commit 2
news items in 2 or 3 days.
The first one (this one) is directed to all users and informs about
the change and
I saw this a couple of days ago on the busybox mailing list. See...
http://comments.gmane.org/gmane.linux.busybox/36695
> By default, modern GCC generates DWARF2 debug/unwind tables in the
> .eh_frame section of the object files/binaries. This adds significant
> bloat (as much as 15%) to the si
On Tue, Sep 04, 2012 at 09:03:55PM -0400, Michael Orlitzky wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
> >>
> >> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> >> are valid. If someone would benefit from such a bump, he can file a bug
> >> and know that it won't b
# Samuli Suominen (05 Sep 2012)
# Replaced by dev-java/antlr wrt bug #255699 and bug #430078
# Removal in 30 days
dev-util/pccts
=dev-util/-3.1.4-r1
(The patches of -r1 was ported to -r0 for most part)
On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
>>>
>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>>> are valid. If someone would benefit from such a bump, he can file a bug
>>> and know that it won't be closed WONT
On Wed, 05 Sep 2012 00:06:45 +
"Jorge Manuel B. S. Vicetto" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 31-08-2012 20:46, Ciaran McCreesh wrote:
>
>
>
> > Also, we're getting rather a lot of *DEPEND variables here... If
> > we're making people make major changes to the
On Wed, Sep 5, 2012 at 2:46 PM, Rich Freeman wrote:
> On Wed, Sep 5, 2012 at 7:27 AM, Ciaran McCreesh
> wrote:
>> Uhm. O(n) == O(n/2). Anything assuming they're different is just wrong.
>
> We're basically debating definitions. O notation is used to indicate
> how algorithms scale and nobody use
On Wed, 5 Sep 2012 08:46:13 -0400
Rich Freeman wrote:
> On Wed, Sep 5, 2012 at 7:27 AM, Ciaran McCreesh
> wrote:
> > Uhm. O(n) == O(n/2). Anything assuming they're different is just
> > wrong.
>
> We're basically debating definitions. O notation is used to indicate
> how algorithms scale and n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/09/12 07:25 AM, Michał Górny wrote:
> Finally, I don't think eclasses are really forced to use
> src_fetch() from day one. src_unpack() will still work for them,
> and we can adjust them gradually.
>
...except for the fact that the whole poin
On Wed, Sep 5, 2012 at 7:27 AM, Ciaran McCreesh
wrote:
> Uhm. O(n) == O(n/2). Anything assuming they're different is just wrong.
We're basically debating definitions. O notation is used to indicate
how algorithms scale and nobody uses O(n/2) and such as a result.
An algorithm that is twice as s
On Wed, 5 Sep 2012 13:23:19 +0200
Fabio Erculiani wrote:
> If you consider parsing an ebuild something hidden behind a lot of
> abstraction layers, O(n) vs O(n/2) is a big difference, even if both,
> normalized, are still O(n). And I would never design an API which
> assumes that O(n/2) equals to
On Wed, 5 Sep 2012 12:07:22 +0100
Ciaran McCreesh wrote:
> On Wed, 5 Sep 2012 13:00:05 +0200
> Michał Górny wrote:
> > > I guess that's a pretty comprehensive "we need to do this
> > > properly" then.
> >
> > Did I say we don't need to? We have the two eclasses which need to
> > do this properl
On Wed, Sep 5, 2012 at 12:44 PM, Rich Freeman wrote:
> On Wed, Sep 5, 2012 at 3:19 AM, Fabio Erculiani wrote:
>> The complexity would become:
>> O((b + r + p) * P)
>> b = amount of buildtime dependencies
>> r = amount of runtime dependencies
>> p = amount of post-dependencies
>> P = amount of pac
On Wed, 5 Sep 2012 13:00:05 +0200
Michał Górny wrote:
> > I guess that's a pretty comprehensive "we need to do this properly"
> > then.
>
> Did I say we don't need to? We have the two eclasses which need to do
> this properly, right? So what's your problem?
The problem is that we need to work ou
On Wed, 5 Sep 2012 11:49:03 +0100
Ciaran McCreesh wrote:
> On Wed, 05 Sep 2012 12:45:16 +0200
> "Andreas K. Huettel" wrote:
> > > And yes, it is *very* unlikely that someone uses a slotted live
> > > ebuild with two branches being meaningful and managed in the same
> > > repo. Even if such thing
On Wed, 05 Sep 2012 12:45:16 +0200
"Andreas K. Huettel" wrote:
> > And yes, it is *very* unlikely that someone uses a slotted live
> > ebuild with two branches being meaningful and managed in the same
> > repo. Even if such thing exists, it is broken anyway because you
> > can't say that re-fetchi
> And yes, it is *very* unlikely that someone uses a slotted live ebuild
> with two branches being meaningful and managed in the same repo. Even
> if such thing exists, it is broken anyway because you can't say that
> re-fetching the branches back and forth is a correct solution. And it
> breaks ex
On Wed, Sep 5, 2012 at 3:19 AM, Fabio Erculiani wrote:
> The complexity would become:
> O((b + r + p) * P)
> b = amount of buildtime dependencies
> r = amount of runtime dependencies
> p = amount of post-dependencies
> P = amount of packages i need to apply the filter to
>
> Instead of just:
> O(b
> On Wed, 5 Sep 2012, Michał Górny wrote:
> On Wed, 5 Sep 2012 11:07:44 +0200
> Ulrich Mueller wrote:
>> > On Wed, 5 Sep 2012, Michał Górny wrote:
>>
>> > And yes, it is *very* unlikely that someone uses a slotted live
>> > ebuild with two branches being meaningful and managed in the sa
On Wed, 5 Sep 2012 11:07:44 +0200
Ulrich Mueller wrote:
> > On Wed, 5 Sep 2012, Michał Górny wrote:
>
> > And yes, it is *very* unlikely that someone uses a slotted live
> > ebuild with two branches being meaningful and managed in the same
> > repo.
>
> We do that all the time for app-edito
> On Wed, 5 Sep 2012, Michał Górny wrote:
> And yes, it is *very* unlikely that someone uses a slotted live
> ebuild with two branches being meaningful and managed in the same
> repo.
We do that all the time for app-editors/emacs-vcs. For example, we
used to have live ebuilds for the trunk an
On Wed, 5 Sep 2012 08:25:54 +0100
Ciaran McCreesh wrote:
> On Tue, 4 Sep 2012 19:23:51 +0200
> Michał Górny wrote:
> > > The 'checking out' language for src_unpack() sounds like it
> > > assumes a DVCS such as mercurial or git. What about cvs or svn,
> > > where fetching is also checking out? (T
On Wed, 5 Sep 2012 09:19:45 +0200
Fabio Erculiani wrote:
> So, let's say that I only want to apply a filter function against the
> buildtime dependencies, in that case I'd need to parse *all* the
> dependencies anyway?
Yes, and? If your dependency parser's time isn't "so tiny it makes
absolutely
On Tue, 4 Sep 2012 19:23:51 +0200
Michał Górny wrote:
> > The 'checking out' language for src_unpack() sounds like it assumes
> > a DVCS such as mercurial or git. What about cvs or svn, where
> > fetching is also checking out? (This is probably a trivial thing to
> > clear up, though.)
>
> They e
On Wed, Sep 5, 2012 at 2:06 AM, Jorge Manuel B. S. Vicetto
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 31-08-2012 20:46, Ciaran McCreesh wrote:
>
>
>
>> Also, we're getting rather a lot of *DEPEND variables here... If
>> we're making people make major changes to their deps, wh
30 matches
Mail list logo
