On 03/18/2017 10:26 AM, Michał Górny wrote:
> @@ -129,6 +130,9 @@ class EbuildPhase(CompositeTask):
> # If the environment.bz2 doesn't exist, then ebuild.sh
> will
> # source the ebuild as a fallback.
>
> + if self.phase == "unpack":
> +
Fix emerge --usepkg to use a binary package when the corresponding
ebuild is not available (and --use-ebuild-visibility is not enabled),
in cases when no other package is available to satisfy the dependency.
This reverts an unintended behavior change from commit
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. It causes econf to be run
> in a subshell which is a PMS
On Mon, 20 Mar 2017 20:35:52 +0100
Michał Górny wrote:
CCing maintainer
> 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. It causes
On Mon, 20 Mar 2017 20:35:51 +0100
Michał Górny wrote:
CCing maintainer
> The parallel econf code is used only with USE=static-libs, and even in
> that case provides negligible speed gain. At the same time, it adds
> a lot of complexity, causes the build logs to be unreadable
On Mon, 20 Mar 2017 22:19:16 +0100
Michał Górny wrote:
> On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> > On Mon, 20 Mar 2017 19:24:58 +0100
> > Michał Górny wrote:
> >
> > > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > >
On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 19:24:58 +0100
> Michał Górny wrote:
>
> > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > What makes me wonder more are the proposed solutions: So far the
> > > only proposals I've
On Mon, 20 Mar 2017 20:25:52 +0100
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
On Mon, 20 Mar 2017 19:24:58 +0100
Michał Górny wrote:
> On pon, 2017-03-20 at 18:01 +0100, 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
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. It causes econf to be run
in a subshell which is a PMS violation and can cause issues with some of
package
The parallel econf code is used only with USE=static-libs, and even in
that case provides negligible speed gain. At the same time, it adds
a lot of complexity, causes the build logs to be unreadable mix of
output from both configure scripts and violates PMS by calling econf
in parallel which can
> 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
> autoconf, it seems to me an intermediate solution
On Mon, Mar 20, 2017 at 2:15 PM, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 13:40:51 -0400
> Mike Gilbert wrote:
>
>> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
>> wrote:
>> > I just tried and with portage 2.3.5, FILESDIR is
On pon, 2017-03-20 at 18:01 +0100, 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 autoconf, it seems to me
> an intermediate
On Mon, 20 Mar 2017 13:40:51 -0400
Mike Gilbert wrote:
> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
> wrote:
> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
> > global scope here. At least an 'ewarn "${FILESDIR} blah"' outputs
>
On Mon, Mar 20, 2017 at 10:27 AM, William Hubbs wrote:
> Hi David,
>
> I'm curious, why the revbump?
>
> If all other eapis are staying in the eclass and the support is
> identical, you don't need to create a new eclass, and there is a lot
> less work involved in updating the
On 03/17/2017 03:51 AM, Brian Dolbec wrote:
On Fri, 17 Mar 2017 06:58:23 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
Brian Dolbec posted on Thu, 16 Mar 2017 01:08:30 -0700 as excerpted:
We could also increase the max. line length to something like
120 or 130.
I think more people should
On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier wrote:
> I just tried and with portage 2.3.5, FILESDIR is unset/empty in global
> scope here. At least an 'ewarn "${FILESDIR} blah"' outputs only ' blah'.
I cannot reproduce this behavior.
% emerge --version
Portage 2.3.5_p2
On Mon, 20 Mar 2017 15:12:43 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
> >> After the PMS change, we will have the same properties for DISTDIR,
> >> FILESDIR, WORKDIR, and S. Namely:
> >>
> >> - All four variables will be valid in src_*
Hi David,
I'm curious, why the revbump?
If all other eapis are staying in the eclass and the support is
identical, you don't need to create a new eclass, and there is a lot
less work involved in updating the ebuilds that inherit it. :-)
Thanks,
William
signature.asc
Description: Digital
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
>> After the PMS change, we will have the same properties for DISTDIR,
>> FILESDIR, WORKDIR, and S. Namely:
>>
>> - All four variables will be valid in src_* phases and in global scope
>> - They will have a consistent value in the ebuild
On Mon, 20 Mar 2017 10:49:40 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Mike Frysinger wrote:
>
> > obvious NAK until you sort out the open questions already raised
> > about the backwards breaking change you're trying to land in PMS.
>
> There are indeed
> On Mon, 20 Mar 2017, Mike Frysinger wrote:
> obvious NAK until you sort out the open questions already raised
> about the backwards breaking change you're trying to land in PMS.
There are indeed some PMS patches pending about DISTDIR, FILESDIR,
WORKDIR, and S, but I fail to see where they
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 the package manager (i.e. a future
> release of Portage).
obvious NAK
24 matches
Mail list logo