On Fri, Aug 17, 2012 at 10:50 PM, Tiziano Müller wrote:
> I'm already working on some of the boost-1.49/50 breakages and 1.51 is
> already in the pipeline, so 1.50 has to leave p.mask in a month or so
> anyway.
Thanks, at least somebody's doing something to help.
By the way I forgot to say in my
On Fri, Aug 17, 2012 at 10:44 PM, Mike Frysinger wrote:
> there's a trivial patch needed to make 1.49 work. forcing people to use 1.50
> is purely the boost's maintainers choice.
[...]
> there's a trivial patch long been available that you've refused to merge. so
> any errors here are of your
Am Samstag, den 18.08.2012, 01:44 -0400 schrieb Mike Frysinger:
> On Saturday 18 August 2012 01:16:29 Diego Elio Pettenò wrote:
> > - everything depending on boost (current 1.49 won't work, you need
> > 1.50, and quite a few things break with 1.50);
>
> there's a trivial patch needed to make 1.49
On Saturday 18 August 2012 01:16:29 Diego Elio Pettenò wrote:
> - everything depending on boost (current 1.49 won't work, you need
> 1.50, and quite a few things break with 1.50);
there's a trivial patch needed to make 1.49 work. forcing people to use 1.50
is purely the boost's maintainers choi
On Fri, Aug 17, 2012 at 8:31 PM, Mike Frysinger wrote:
> there's a few packages still known to
> build fail, but they've had quite some time to sort their stuff out, so i
> don't
> see delaying further making a difference there.
So you're saying you're fine to break:
- everything depending on
On Tuesday 14 August 2012 13:37:25 Alexis Ballier wrote:
> it breaks on _pie_ executables, which are not that common if you dont
> run hardened.
every Gentoo system has PIEs on it. not many, but some.
file /*bin/* /usr/*bin/* | grep shared.object
(i wonder why cups is building itself as PIE act
people seem to be settling on x86_64-pc-linux-gnux32 as the default tuple, so
i'll be updating our profiles to use that by default. this shouldn't impact
anyone already running x32 as the existing tuple/ABI settings should continue
to work just fine (no plans to ever change that).
-mike
signa
with glibc-2.15 gone stable, it's time to get 2.16 in the pipe. the big
issues have been sorted out already. there's a few packages still known to
build fail, but they've had quite some time to sort their stuff out, so i don't
see delaying further making a difference there. if anything, they'
On Thursday 16 August 2012 16:19:44 Michał Górny wrote:
> --- a/eutils.eclass
> +++ b/eutils.eclass
>
> +# Install all specified s into . This doesn't modify global
> +# 'insinto' path. Alike doins, calls 'die' on failure in EAPI 4+; in earlier
> +# EAPIs, returns false in that case.
i don't real
On Tuesday 14 August 2012 16:39:57 Michał Górny wrote:
> On Tue, 14 Aug 2012 12:46:30 -0700 Zac Medico wrote:
> > On 08/14/2012 02:44 AM, Michał Górny wrote:
> > > As some of you may have noticed, lately introduced 'double include
> > > preventions' have caused changes in effective phase functions
On Tuesday 14 August 2012 17:59:40 Zac Medico wrote:
> That just means that somebody made a mistake. They should have put the
> EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people
> about the correct place to put the EXPORT_FUNCTIONS call, and that
> problem is solved.
sounds
On Monday 06 August 2012 15:45:46 Kent Fredric wrote:
> Looking at the source of eutils.eclass ' # Let people filter things
> dynamically ' suggests to me that this field is for use by a end user
> via package.env and friends.
no, it is meant for packagers to have a single patch tarball, setup
E
It has come to my attention that gentoo supports "relative" ROOT, which
is to say that, by design, portage will act as though (in bash terms):
ROOT
equals
"${PWD}/${ROOT}"
when (again in bash terms):
[[ $ROOT != /* ]]
at the moment execution crosses the boundary between a non-portage
On Fri, Aug 17, 2012 at 9:03 PM, Rich Freeman wrote:
> On Thu, Aug 16, 2012 at 11:26 PM, Michael Mol wrote:
>> Bootstrapping is an inherently curious problem. Most systems are built
>> upon the systems they themselves build, but getting to that
>> self-hosting state always requires some unclean s
On Thu, Aug 16, 2012 at 11:26 PM, Michael Mol wrote:
> Bootstrapping is an inherently curious problem. Most systems are built
> upon the systems they themselves build, but getting to that
> self-hosting state always requires some unclean solution.
Yup, I never viewed getting rid of @system as a s
http://www.flameeyes.eu/autotools-mythbuster/forwardporting/automake.html
configure.in is deprecated for some time now, but it will be fatal for
upcoming automake 1.13 afais.
Simply doing mv configure.in configure.ac in eautoreconf function should
do the trick, no?
Opinions? Can't think of a cas
On 08/16/2012 08:26 PM, Michael Mol wrote:
> Ideally, you'd want as narrow a bootstrapping channel as possible.
> Assuming things start off statically linked, what's the sequence for
> going from an empty chroot to stage 1, 2, 3...? What are the starting
> conditions?
We use sys-apps/catalyst, whi
On 8/16/2012 8:26 PM, Michael Mol wrote:
Ideally, you'd want as narrow a bootstrapping channel as possible.
I guess I tend to think that, too, and I'm pretty sure it's correct. But
I don't normally think about why, and since you've prompted me to do so,
perhaps it's a good moment to interjec
On Fri, 17 Aug 2012 18:53:43 +0200
Jeroen Roovers wrote:
> On Thu, 16 Aug 2012 22:19:44 +0200
> Michał Górny wrote:
>
> > ---
> > eutils.eclass | 37 +
> > 1 file changed, 37 insertions(+)
>
> Could you provide a couple of use cases?
Patch 2 does that. It'
On Thu, 16 Aug 2012 22:19:44 +0200
Michał Górny wrote:
> ---
> eutils.eclass | 37 +
> 1 file changed, 37 insertions(+)
Could you provide a couple of use cases?
jer
On Fri, 17 Aug 2012 03:23:52 +0200
"Jason A. Donenfeld" wrote:
> This isn't a topic meant for bike shedding, but just kind of loose
> exploratory inquiry. I saw a bug report about adding systemd's
> tmpfiles.d config format support to OpenRC (accomplished) and then
> some discussion about adding
21 matches
Mail list logo
