On 03/21/2017 04:43, Kristian Fiskerstrand wrote:
> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
>> In general, the concept of code-sharing common blocks of logic between
>> multiple
>> ebuilds in a specific package directory that is not a top-level eclass is not
>> entirely without merit. But th
On 03/21/2017 07:33 PM, Michał Górny wrote:
>>
>>
>> yes you're right, but that still doesn't justify pushing straight to
>> stable for a package in @system
>> (the same applies to the other patches)
>
> If you really believe users should suffer a 30-minute rebuild for
> a build-time fix, sure.
>
On Tue, 21 Mar 2017 19:33:46 +0100
Michał Górny wrote:
> On wto, 2017-03-21 at 17:55 +0100, Alexis Ballier wrote:
> > On Tue, 21 Mar 2017 17:30:29 +0100
> > Michał Górny wrote:
> >
> > > On wto, 2017-03-21 at 17:05 +0100, Alexis Ballier wrote:
> > > > On Tue, 21 Mar 2017 16:46:43 +0100
> >
On wto, 2017-03-21 at 17:55 +0100, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 17:30:29 +0100
> Michał Górny wrote:
>
> > On wto, 2017-03-21 at 17:05 +0100, Alexis Ballier wrote:
> > > On Tue, 21 Mar 2017 16:46:43 +0100
> > > Michał Górny wrote:
> > >
> > > > Use --cache-file to reuse the pre
On Tue, 21 Mar 2017 17:30:29 +0100
Michał Górny wrote:
> On wto, 2017-03-21 at 17:05 +0100, Alexis Ballier wrote:
> > On Tue, 21 Mar 2017 16:46:43 +0100
> > Michał Górny wrote:
> >
> > > Use --cache-file to reuse the previous check results in the
> > > subsequent configure script runs. This g
On wto, 2017-03-21 at 17:05 +0100, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 16:46:43 +0100
> Michał Górny wrote:
>
> > Use --cache-file to reuse the previous check results in the subsequent
> > configure script runs. This gives a major speed advantage (beating the
> > previous parallel runs) a
Currently puppet is fairly simple in how it handles portage packages.
It doesn't handle package (un)install options, package sets or purging
of packages. Also, iirc, uninstallation is fairly limited in what it
can handle (can't handle uninstalling a slot iirc).
The new version fixes these limitat
//
Since this does not affect existing ebuilds, I'd like to apply it along
with the epunt-cxx patch to avoid two major cache regens a week ;-).
---
eclass/epatch.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass
index fb0a10b53583..905f68f8e
On Tue, 21 Mar 2017 16:46:43 +0100
Michał Górny wrote:
> Use --cache-file to reuse the previous check results in the subsequent
> configure script runs. This gives a major speed advantage (beating the
> previous parallel runs) and significant CPU savings.
Just in case (didn't try nor do I know t
Use --cache-file to reuse the previous check results in the subsequent
configure script runs. This gives a major speed advantage (beating the
previous parallel runs) and significant CPU savings.
---
sys-libs/ncurses/ncurses-6.0-r1.ebuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On pon, 2017-03-20 at 21:12 -0400, Mike Frysinger wrote:
> On 20 Mar 2017 20:35, Michał Górny wrote:
> > Remove the parallel econf logic that adds a lot of complexity for minor
> > gain. It results in the output from different configure scripts being
> > mixed in the build log, making it unreadable
Am Montag, 20. März 2017, 09:35:44 CET schrieb Mike Frysinger:
> On 16 Mar 2017 10:38, Michał Górny wrote:
> > Convert the usage of eblits in sys-devel/autoconf into an equivalent
> > eclass. This makes the ebuilds more readable, more predictable and fixes
> > compliance with stricter versions of t
On 03/21/2017 11:00 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 10:41:58 +0100
> Kristian Fiskerstrand wrote:
>
> yes, that's the naming i suggested in the part you cut :)
Indeed
>
> but then you'd need boilerplate duplicated code to ensure nothing but
> the dedicated package can use tha
On Tue, 21 Mar 2017 10:41:58 +0100
Kristian Fiskerstrand wrote:
> On 03/21/2017 10:17 AM, Alexis Ballier wrote:
> > On Tue, 21 Mar 2017 09:43:37 +0100
> > Kristian Fiskerstrand wrote:
>
>
> > (up to discussion ofc)
> >
> > Pros for eblits vs the above eclasses:
> > - Let eclass/, which is a
On 03/21/2017 10:17 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 09:43:37 +0100
> Kristian Fiskerstrand wrote:
> (up to discussion ofc)
>
> Pros for eblits vs the above eclasses:
> - Let eclass/, which is a toplevel directory, be a place for code
> useful to several packages, not a random
On Tue, 21 Mar 2017 09:43:37 +0100
Kristian Fiskerstrand wrote:
> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
> > In general, the concept of code-sharing common blocks of logic
> > between multiple ebuilds in a specific package directory that is
> > not a top-level eclass is not entirely without
On 03/21/2017 09:28 AM, Joshua Kinard wrote:
> In general, the concept of code-sharing common blocks of logic between
> multiple
> ebuilds in a specific package directory that is not a top-level eclass is not
> entirely without merit. But the only way this idea can be realized in a
> suitable man
On 03/20/2017 15:25, Ulrich Mueller wrote:
>> On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
>> What makes me wonder more are the proposed solutions: So far the
>> only proposals I've seen are either inlining *all* the code or
>> moving *all* the code into an eclass. Having a quick look at
>> au
18 matches
Mail list logo
