st 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 Mon, Nov 30, 2015 at 10:34 AM, Greg Turner <g...@be-evil.net> 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 <bluen...@gentoo.org>
lect 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, Greg Turner <
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 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 guess,
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 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,
On Mon, Jul 7, 2014 at 4:14 AM, Rich Freeman ri...@gentoo.org 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
On Fri, Jun 20, 2014 at 1:10 PM, Ian Stakenvicius a...@gentoo.org 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
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 Thu, Jun 19, 2014 at 1:02 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com 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
On Fri, Jun 13, 2014 at 6:38 AM, Rich Freeman ri...@gentoo.org 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
On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers j...@gentoo.org 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
On Tue, Jun 10, 2014 at 5:48 PM, Duy Nguyen pclo...@gmail.com 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.
Just a few practical notes on this...
On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev
tetrom...@gentoo.orgwrote:
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.
On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev
tetrom...@gentoo.orgwrote:
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
Holy crap, that looks awesome! How does one pronounce your name, Александр?
On Thu, Feb 13, 2014 at 11:28 PM, Александр Берсенев b...@hackerdom.ru wrote:
Ok, I'll work on it.
2014-02-13 23:00 GMT+06:00 Rich Freeman ri...@gentoo.org:
On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec
On Wed, Dec 11, 2013 at 2:41 PM, Michał Górny mgo...@gentoo.org 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
On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger vap...@gentoo.org wrote:
URL: https://bugs.gentoo.org/487478
Perhaps, with this bug resolved, this matter falls under the more
trouble than its worth to fix category -- but...
My hunch is that the decision to put the config.{sub,guess}
replacement
On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger vap...@gentoo.org wrote:
+ sed -i \
+ -e
1s:^#![[:space:]]*/bin/sh:#!$CONFIG_SHELL: \
+ ${ECONF_SOURCE}/configure \
+ || die
On Wed, Dec 11, 2013 at 11:20 PM, Michał Górny mgo...@gentoo.org 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
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
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
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
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,
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
@@
# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald hasuf...@gentoo.org
+# @AUTHOR:
+# Julian Ospald hasuf...@gentoo.org
+# Michał Górny mgo...@gentoo.org
+# Greg Turner g...@be-evil.net
# @BLURB: wrapper for multilib builds providing convenient multilib_src_* functions
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
On Wed, Dec 11, 2013 at 2:40 PM, Michał Górny mgo...@gentoo.org 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;
On Wed, Dec 11, 2013 at 2:41 PM, Michał Górny mgo...@gentoo.org 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
On Wed, Dec 11, 2013 at 2:01 PM, hasufell hasuf...@gentoo.org 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
On Wed, Dec 11, 2013 at 1:44 PM, hasufell hasuf...@gentoo.org 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 1:37 PM, hasufell hasuf...@gentoo.org 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
On Wed, Dec 11, 2013 at 6:33 PM, Jonathan Callen jcal...@gentoo.org 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
On Wed, Dec 11, 2013 at 10:33 PM, Michał Górny mgo...@gentoo.org 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/
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny mgo...@gentoo.org 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
On Thu, May 2, 2013 at 5:26 AM, Michał Górny mgo...@gentoo.org 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
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny mgo...@gentoo.org 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 mgo...@gentoo.org 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 Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky mich...@orlitzky.com wrote:
On 06/12/2013 01:13 PM, Ciaran McCreesh wrote:
On Wed, 12 Jun 2013 19:05:29 +0200 hasufell hasuf...@gentoo.org
wrote:
Isn't it more an indication that Gentoo needs better package
management support for overlays?
42 matches
Mail list logo
