On Mon, Nov 30, 2015 at 10:34 AM, Greg Turner wrote:
> https://youtu.be/Ic4j0ujWL-A looks interesting too.
--> https://sourceware.org/libabigail/
-gmt
Greg Turner
g...@be-evil.net
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
makes for pretty interesting reading on this topic.
https://youtu.be/Ic4j0ujWL-A looks interesting too.
-gmt
-gmt
Greg Turner
g...@be-evil.net
On Mon, Nov 30, 2015 at 3:31 AM, Anthony G. Basile wrote:
> On 11/30/15 6:17
hen we eselect c++abi set some-new-value, we could just take all
those maybe meaningless -- but presumptively not
meaningful-but-incorrect -- values in the vdb, and queue up rebuild
nags for all the ones that don't match.
-gmt
Greg Turner
g...@be-evil.net
On Mon, Nov 30, 2015 at 2:16 AM, Gre
his setting?
Almost never...
Well just thinking out loud, I probably have horrible thinkos above,
but ya gotta start somewhere...
-gmt
Greg Turner
g...@be-evil.net
On Wed, Jul 9, 2014 at 5:34 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Have you /tried/ backtrack=0?
Yeah. I had backtrack=1 as my default for a good while before my
overlay started getting cray-cray. It's fast -- well, less slow -- but
diagnostically unhelpful when anything goes "wrong".
I gues
On Mon, Jul 7, 2014 at 9:39 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> But from the sound of things, default backtrack=10, multilib, full
> @system set and default profile use, on spinning rust, is getting all but
> intolerable now. =:^(
Actually a mix of RAID0 and RAID1 over fast, new-ish SSDs --
On Mon, Jul 7, 2014 at 4:14 AM, Rich Freeman wrote:
> Well, more like unspecified behavior. PMS just says that the PM has
> to accept any package in the list. It is silent on the matter of
> which one is to be preferred, or to what degree.
In general the PMS dependency language seems quite libe
On Mon, Jul 7, 2014 at 4:02 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> [FWIW, the HTML isn't particularly appreciated.]
Ugh, embarrassing. Been having mail client trouble for the past
several years :) Starting to come to the conclusion that aside from
the many respectable curses-based readers, k
WTF is up with it? Why does it love the first Atom so much more than the
others?
It could be such a useful feature, but, in practice, it just never seems to
do what I want it to. Is it a bug?
-gmt
On Fri, Jun 20, 2014 at 1:10 PM, Ian Stakenvicius wrote:
> Thoughts [about wrapping gcc, so that non-native multilib-build ABI's can
finally return to a world where [[ ${GCC} != *' '* ]] ]?
TLDR: good idea, I'm strongly in favor of it.
A wrapper would fix horrors like the following, which, last
On Thu, Jun 19, 2014 at 1:02 PM, Ciaran McCreesh
wrote:
>> "|| (
>> >=foo/bar-3.5:3[${MULTILIB_USEDEP}]
>> >=foo/bar-4.5:4[${MULTILIB_USEDEP}]
>> >=foo/bar-5.2:5[${MULTILIB_USEDEP}]
>> )"
>>
>> would solve such a problem correctly.
>
> No it wouldn't... Best version first in a || block
Ouch!
I suspect a nice side-effect of this policy is that portage will be
faster as it will be less prone to backtracking.
One thing people should be aware of is how this policy will interact
with slotted ebuilds. >=foo/bar-3.5[${MULTILIB_USEDEP}] could be met
by the ancient >=foo/bar-4.0 EAPI0
On Fri, Jun 13, 2014 at 6:38 AM, Rich Freeman wrote:
> add the strip-flags statement to the ebuild and be done
> with it
To do it "greenly" we'd obviously want to know the precise surface
area of the problem and then to correctly express those circumstances
in eblit code that could stand up to th
On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers wrote:
>
> Will bug #332823 and its ilk somehow be mitigated? Emerging glibc with
> -fstack-protector still leads to similar problems. There doesn't
> currently seem to be a bug report about this that isn't marked INVALID.
Is this a bug/limitation i
On Tue, Jun 10, 2014 at 5:48 PM, Duy Nguyen wrote:
> Since v1.9.0 we can clone from a shallow repository.
Wow, awesome! Thank you, git developers, you rock (and sorry I'm too
lazy to tell you in your own mailing list :) )!
See https://bugs.gentoo.org/show_bug.cgi?id=511414.
-gmt
PS: I sent this once before from the wrong e-mail address -- I'm pretty
sure the list will therefore silently drop it. But if I'm wrong, sorry for
the dup.
On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev
wrote:
> is there any legitimate reason for
> wanting crossdev's i686 wrappers when on a multilib amd64 profile?
>
One other note: legitimacy is in the eye of the legitimizer, I suppose, but
there are sometimes practical reasons to want a no-m
Just a few practical notes on this...
On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev
wrote:
> > Now, SYSROOT is chosen from multiple conditions. When emerging a
> > package, that happens to be "/" and thus results in:
> > "//usr/lib/pkgconfig://usr/share/pkgconfig"
>
Bleh. This is wher
Holy crap, that looks awesome! How does one pronounce your name, Александр?
On Thu, Feb 13, 2014 at 11:28 PM, Александр Берсенев wrote:
> Ok, I'll work on it.
>
>
> 2014-02-13 23:00 GMT+06:00 Rich Freeman :
>
>> On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec wrote:
>> > Yes, if you can please w
On Wed, Dec 11, 2013 at 2:41 PM, Michał Górny wrote:
> Very limited usefulness, a lot of extra complexity. We'd rather work on
> making eclasses simpler.
Sorry to beat a potentially dead horse, but many days later, I still
can't bring myself to agree with this, at least, not with respect to
src_c
On Wed, Dec 11, 2013 at 11:20 PM, Michał Górny wrote:
> Real life example first, pathological theories later.
As I stated before, I don't have a 100% real-life example as I've
found other workarounds in each case, as, clearly, has gx86, thus-far.
However, the problem pertains to any non-header-w
On Wed, Dec 11, 2013 at 10:33 PM, Michał Górny wrote:
>> Regardless, if our standard advice is "try not to use this automagic
>> header wrapping feature, it can break autoconf assumptions" (IIRC, it
>> is -- but if it isn't, it probably should be), then we ought to
>> provide /some/ convenient mea
On Wed, Dec 11, 2013 at 6:33 PM, Jonathan Callen wrote:
> The *last* eclass inherited
Well I'll be ferschnookered!
Googling confirms this. I'm quite shocked. I have believed the
opposite, for a very long time, with perfect confidence. No idea why
I thought so -- in retrospect, I'm pretty sure
On Wed, Dec 11, 2013 at 1:37 PM, hasufell wrote:
> On 12/11/2013 10:18 PM, Greg Turner wrote:
>>
>
> this needs more explanation. Why do we want this?
Sometimes the automagic header stuff is working against the ebuild
author, or at least threatens to, in the future.
The most pla
On Wed, Dec 11, 2013 at 1:44 PM, hasufell wrote:
> It should be made clear who is the initial/original author. Maintainer
> can be quite anyone.
IIRC there's now a @DOC_THINGY for that; I'll use it in the next
version of this patch series, should there be one.
-gmt
On Wed, Dec 11, 2013 at 2:01 PM, hasufell wrote:
> I actually feel that some parts of this is not documentation, but rather
> "wiki". So maybe that's exactly where to put it?
>
> The doc in the eclass should only describe the behavior of the eclass
> and the main points you need to know in order t
On Wed, Dec 11, 2013 at 2:41 PM, Michał Górny wrote:
> Very limited usefulness, a lot of extra complexity
Can't say I entirely agree on either point, but it wouldn't
meaningfully jam up my patch queues, which makes me much less inclined
to be attached to it.
Another reason, upon consideration, n
On Wed, Dec 11, 2013 at 2:40 PM, Michał Górny wrote:
>> This patch adds multilib_src_{configure,compile,test}_all
>> callbacks, analogous to the existing multilib_src_install_all
>> callback.
>
> No real benefit in having those.
There is no fundamental semantic benefit I can think of; indeed, as
-5,6 +5,10 @@
# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald
+# @AUTHOR:
+# Julian Ospald
+# Michał Górny
+# Greg Turner
# @BLURB: wrapper for multilib builds providing convenient multilib_src_* functions
# @DESCRIPTION:
# multilib-minimal implements src_configure, src_compile, src_test
This patch adds a new frob, MULTILIB_PARALLEL_PHASES, to
multlib-minimal.eclass, which implements eclass-consumer-selectable
parallelization of src_configure, src_compile, and src_test.
By default, all parallelization is deactivated, which represents
a change from the previous gentoo-x86 behavior
This patch adds multilib_src_{configure,compile,test}_all
callbacks, analogous to the existing multilib_src_install_all
callback.
--- 003-in-source-doc/multilib-minimal.eclass 2013-12-03 02:45:19.428664959 -0800
+++ 004-multilib-phase-all/multilib-minimal.eclass 2013-12-03 02:54:40.045335905 -080
This rewrites the multilib-minimal.eclass in-source documentation,
providing considerably more hand-holding for end-users, exploring
some pitfalls that users may encounter, and clarifying some
less-than lucid language.
It also reverses an existing in-source comment about inheritance
ordering, whi
Groking flow-of-control in multibuild-based ebuilds is
nontrivial. These can help.
--- 000-header/multilib-minimal.eclass 2013-12-03 02:13:48.115445273 -0800
+++ 001-debug-print-function/multilib-minimal.eclass 2013-12-03 02:17:30.144384409 -0800
@@ -36,7 +36,11 @@ EXPORT_FUNCTIONS src_configure
Add a MULTILIB_INSECURE_INSTALL variable to eclass/multilib-minimal.eclass
Sometimes the "multilib magic header" business is an unwanted
feature. For example, it is infuriating to be forced
to wrap a header file (or, less offensively, but still quite
offensively, to be forced to implement inter-
sorry for attaching these rather than in-lining but google insists on
78-wrapping plain-text e-mail. If HTML mail would be a better
solution for people I'd be happy to re-send (unless maybe a single
person requests it and a chorus of objections are raised :P).
This series is available also in bug
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny wrote:
>
> We have four active Gentoo developers in the team and one very helpful
> user. Plus a number of developers who are working in their narrow areas
> and supporting us indirectly. That's more than I expected,
> and the project has bright future
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny wrote:
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=485046
Hey, that looks familiar... same basic problem exists in bzip2[static]
src_compile:
https://bugs.gentoo.org/show_bug.cgi?id=485690
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny wrote:
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=485046
Hey, that looks familiar... same basic problem exists in bzip2[static]
src_compile:
https://bugs.gentoo.org/show_bug.cgi?id=485690
On Thu, May 2, 2013 at 5:26 AM, Michał Górny wrote:
> Hi,
>
> I've thought for a bit and got the conclusion that the best solution
> for quite an irritating syntax of autotools-multilib is to use
> sub-phase functions.
Sorry for the delayed response, but having been playing with this
stuff lately
On Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky wrote:
> On 06/12/2013 01:13 PM, Ciaran McCreesh wrote:
>> On Wed, 12 Jun 2013 19:05:29 +0200 hasufell
>> wrote:
Isn't it more an indication that Gentoo needs better package
management support for overlays?
>>
>>> No.
>>
>
> We need wor
40 matches
Mail list logo
