On Tue, 2015-12-01 at 22:58 +, James Le Cuirot wrote:
> Sorry
[snip]
> gentle! :)
Not sure I have anything meaningful to contribute to the discussion
from a technical perspective at the moment, but I just wanted to voice
my support for what you're doing with cross: I think Gentoo is setting
s
On Wed, 2015-12-02 at 08:06 +0100, Michał Górny wrote:
> On Tue, 01 Dec 2015 18:12:17 -0800
> "Gregory M. Turner" wrote:
>
> > On Tue, 2015-12-01 at 07:18 -0500, Anthony G. Basile wrote:
> > > So on that bug we're talking about selectively
> >
On Tue, 2015-12-01 at 18:45 +0100, Michał Górny wrote:
> On Tue, 1 Dec 2015 11:38:08 -0600
> William Hubbs wrote:
>
> > I find the multilib eclasses and their separate multilib phase
> > functions
> > to be confusing, so I was wondering if we could discuss making
> > multilib
> > support native t
On Tue, 2015-12-01 at 07:18 -0500, Anthony G. Basile wrote:
> So on that bug we're talking about selectively
> adding -std=c++11 (or possibly gnu++11) to packages.
Yes, this is the biggest real-world problem we face. It requires an
immediate solution in the ~* branches; the affected ebuilds just
On Sun, Nov 29, 2015 at 10:42 PM, Michał Górny wrote:
> On Sun, 29 Nov 2015 19:56:04 -0800
> "Gregory M. Turner" wrote:
> > the mess gets magically cleaned up by robots somehow.
>
> Sadly := can't help here since gcc switches occur independently of
> packag
I'm quoting myself from bug #566328 here. These were off-the-cuff
remarks that got away from me and became a call-to-arms...
(In reply to Michał Górny from comment #7)
> This is never this simple. C++11 can change the ABI. So the point kinda is,
> we need to ensure that all C++ libraries in a dep
On 4/15/2013 10:31 AM, Steven J. Long wrote:
On Mon, Apr 15, 2013 at 12:01:24PM +0100, Ciaran McCreesh wrote:
On Mon, 15 Apr 2013 10:56:45 +
"Aaron W. Swenson" wrote:
ROOT being a user set variable, having ROOT be an empty string by
default still does not guarantee that ROOT won't end with
On 4/2/2013 10:54 AM, Duncan wrote:
Tho in practice, if you're here long you do develop a rather thick hide.
Nothing NEAR what it was a few years ago, tho. Before it gets anywhere
near that, there's warnings, these days.
Kinda just what happens, when you put a bunch of unpaid, sleep-deprived,
On 4/13/2013 2:23 PM, Michał Górny wrote:
Your thoughts?
+1, this causes untold agonies for my pet platform. See #465772 for
more thorough griping :)
-gmt
On 4/13/2013 9:56 PM, Ryan Hill wrote:
On Fri, 12 Apr 2013 13:04:57 -0700
"Gregory M. Turner" wrote:
What do people think of something like this? Obviously the equivalent
patch to prefix would need to include a test for
PREFIX_DISABLE_GEN_USR_LDSCRIPT:
Author: Gregory M. Turner
D
What do people think of something like this? Obviously the equivalent
patch to prefix would need to include a test for
PREFIX_DISABLE_GEN_USR_LDSCRIPT:
Author: Gregory M. Turner
Date: Fri Apr 12 11:13:21 2013 -0700
eclass/toolchain-funcs: Add target-has-split-usr API
Move the
On 10/20/2012 4:07 PM, Zac Medico wrote:
On 10/20/2012 03:51 PM, Gregory M. Turner wrote:
Anyhow, given that eclasses can probably avoid auto-die() if they need
to, this leaves the issue of nonfatal allowing die to return to
callers... is there really any reason that die() needs to work this
On 10/20/2012 11:16 AM, Zac Medico wrote:
On 10/20/2012 03:52 AM, Gregory M. Turner wrote:
EAPI[0-3] conventions encourage the habit of writing ebuild code like
invoke_fn || ... # handle error, probably by die()ing but maybe not
But eclasses that auto-die violate this expectation and
On 10/20/2012 4:05 AM, Ciaran McCreesh wrote:
On Sat, 20 Oct 2012 03:52:49 -0700
"Gregory M. Turner" wrote:
Took me a while, but I think I see why this is correct, now (mostly
-- see below). The source of my confusion was a mistaken assumption
that die() would not respect PORTAG
Thanks for your reply, but I still have some concerns about this.
On 10/19/2012 8:11 AM, Zac Medico wrote:
Regardless of EAPI, don't call the helpers that die in EAPI 4 unless you
want the function to die when the helpers fail, and use helper || die so
it behaves the same regardless of EAPI.
T
I'm cooking up some eclass functions and it occurred to me that perhaps
I had some responsibility regarding EAPI4's new error handling
semantics. After looking into it, it seems that, superficially, the
answer to my question is "no, the EAPI4 changes only apply to ebuild
helpers."
Even so, t
On 10/14/2012 9:29 PM, Mike Frysinger wrote:
On Sunday 14 October 2012 04:49:28 Gregory M. Turner wrote:
"Thirdly" has been addressed ad nauseam in this thread and will be
solved by prepending the LDFLAG rather than appending, or, preferably,
by patching autotools (but only if I
On 10/12/2012 4:03 AM, Gregory M. Turner wrote:
First, something puts in all kinds of inappropriate amd64 multilib paths
(this ends up being harmless as wrong-arch libraries get rejected at
link-time and treated as non-matches for -lclauses... still, WTF?).
Secondly, something puts the built-in
On 10/11/2012 3:31 PM, Ben Kohler wrote:
There are other ways to achieve a "lighter" system, but that's not really
what this is about. The server profiles are not any lighter than the base
profiles.
To those in favor of keeping some kind of "server" profile around, how
would it differ from the
On 10/11/2012 2:40 PM, Marien Zwart wrote:
I'm going to do something potentially rude and comment on this without
having read the entire thread.
On Thu, Oct 11, 2012 at 10:39 PM, Gregory M. Turner wrote:
Anyhow one thing I have figured out is how things can work correctly on
Linux wihto
On 10/11/2012 1:04 PM, Walter Dnes wrote:
On Thu, Oct 11, 2012 at 03:22:17PM -0400, Mike Frysinger wrote
sounds like something to fix rather than punt. i don't know why
you think having server profiles is "undesirable", but i certainly
desire it on many systems. like servers. the desktop and
On 10/11/2012 8:50 AM, Mike Frysinger wrote:
On Thursday 11 October 2012 05:35:21 Gregory M. Turner wrote:
On 10/10/2012 9:14 PM, Mike Frysinger wrote:
it's not particularly important, but on one hand, the LDFLAGS parsing logic
should not be in the tree ever.
I've no major attach
On 10/10/2012 9:14 PM, Mike Frysinger wrote:
On Wednesday 10 October 2012 23:37:26 Gregory M. Turner wrote:
(1) is worse than (2), but it does have some quasi-legitimate usages.
For example, prefix bootstrap does this (or used to), as do many of the
crossdev-wrapper scripts. I've also res
On 10/9/2012 2:26 PM, Mike Frysinger wrote:
On Saturday 06 October 2012 03:47:57 Gregory M. Turner wrote:
My god, I am a horrible self-editor. Sorry. Please ignore the magnum
opus above and allow me to try again.
In dev-lang/python*, we use
append-ldflags '-L.'
to ensure
On 10/6/2012 1:31 AM, Fabian Groffen wrote:
On 06-10-2012 00:47:57 -0700, Gregory M. Turner wrote:
In dev-lang/python*, we use
append-ldflags '-L.'
to ensure linking is performed against the built libpython.so in-tree,
rather than than in the one in $(libdir). But, this doesn
My god, I am a horrible self-editor. Sorry. Please ignore the magnum
opus above and allow me to try again.
In dev-lang/python*, we use
append-ldflags '-L.'
to ensure linking is performed against the built libpython.so in-tree,
rather than than in the one in $(libdir). But, this doesn't w
[ "eclass/flag-o-matic.eclass" ]->8->
--- PORTAGE/eclass/flag-o-matic.eclass
+++ OVERLAY/eclass/flag-o-matic.eclass
@@ -117,6 +117,42 @@
return 0
}
+# @FUNCTION: prepend-ldpath
+# @USAGE:
+# @DESCRIPTION:
+# Place the specified ldpath into LDFLAGS before any options which co
Brian Harring wrote:
1) We need a thin manifest -> thick manifest converter. Thin
manifests are used for git- they store just DIST entries. Thick (also
known as 'full'), are what cvs/rsync users are familiar with- it holds
checksums for all content.
carebear is the current person volunteering
If you're going to paint me and the other folks expressing opinions as
entitled mouth-breathers, certainly you can't expect not to hear any
reply because it's "off-topic"!
On 10/1/2012 2:00 PM, Diego Elio Pettenò wrote:
On 01/10/2012 13:54, Rich Freeman wrote:
I don't think we can keep the di
On 10/1/2012 10:29 AM, Rich Freeman wrote:
Looking at the tracker [1], we need a pre-upload hook (I'm not quite
sure why), an rsync conversion script, the ability to validate the
converted tree, and documentation. There is still an open bug for
commit signing, and I'm not quite sure why as thi
On 9/17/2012 1:00 AM, Ciaran McCreesh wrote:
On Mon, 17 Sep 2012 00:58:02 -0700
"Gregory M. Turner" wrote:
Unless I'm missing something, it seems that once we deprive the
ebuild developer of this feature, there is no simple, supported way
to retrieve the information except
My main focus here is switching built_with_use to actively nagging
> people to stop using it; this includes nagging EAPI0/1 users of it.
Sans the implementation details, anyone got complaints with the
intent?
I have a concern about it, yes. But, maybe there's a good answer to my
concern, s
On 9/12/2012 5:58 AM, Ian Stakenvicius wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/09/12 05:55 AM, Gregory M. Turner wrote:
Note that, effectively, we have this already, and it's called
"portage". But one could certainly make a case for modularizing it
better,
On 9/11/2012 9:54 AM, Ian Stakenvicius wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/09/12 12:43 PM, Zac Medico wrote:
On 09/11/2012 09:36 AM, viv...@gmail.com wrote:
Dunno where to place this request, but if we go for something
like EJOBS could we also make it phase specific? S
On 9/10/2012 10:39 PM, Duncan wrote:
Gregory M. Turner posted on Mon, 10 Sep 2012 20:29:53 -0700 as excerpted:
However, IIRC, /etc/make.conf is just ignored by portage if
/etc/portage/make.conf is present, so symlinking, or even better, if
possible, hardlinking those files would probably &qu
On 9/9/2012 6:34 PM, Zac Medico wrote:
On 09/09/2012 05:59 PM, Duncan wrote:
To your knowlege (IOW have you tested) having /etc/make.conf either a
symlink to /etc/portage/make.conf or a simple one-line
"source /etc/portage/make.conf"?
I've tested them both just now, and they work for me. Why w
On 9/7/2012 10:32 AM, Fabian Groffen wrote:
With the introduction of IMPLICIT_IUSE (scheduled for EAPI 5), a phrase
has been added to PMS, that finally makes a statement on what's supposed
to be in IUSE, and what not[2]. To me, this patch means that things like
userland_BSD, elibc_glibc, etc. d
On 9/6/2012 5:56 AM, Ian Stakenvicius wrote:
On 06/09/12 03:55 AM, Ulrich Mueller wrote:
On Thu, 06 Sep 2012, Gregory M Turner wrote:
${ROOT:=/} EPREFIX="@GENTOO_PORTAGE_EPREFIX@"
EROOT="${ROOT}${EPREFIX}"
When ROOT is undefined or empty, this script will assign &quo
On 9/6/2012 12:55 AM, Ulrich Mueller wrote:
On Thu, 06 Sep 2012, Gregory M Turner wrote:
Several correct-ish solutions exist, i.e., in the above we could change
the concatenation statement to read:
EROOT="${ROOT}${EPREFIX#/}"
I'd rather do it the other way around:
EROOT=${R
Hello, in my overlay I need to fix a bunch of issues that crop up when
implementing EPREFIX construction in scripts due to Cygwin's
idiosyncratic, but POSIX-compliant, handling of paths beginning with
"//" (Cygwin does some arguably pathological stuff when such paths are
used).
Almost all of
On 8/31/2012 4:48 AM, Rich Freeman wrote:
On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny wrote:
So please introduce virtual/compiler, virtual/linker,
virtual/posix-system, virtual/sratatata and add them to DEPEND of every
single ebuild.
Every ebuild doesn't need all of those - that is the who
On 8/28/2012 4:05 PM, Diego Elio Pettenò wrote:
On 28/08/2012 15:36, Mart Raudsepp wrote:
static-libs is for installing static libraries IN ADDITION to shared
libraries, not instead.
USE=static is for what you have in mind there.
PE is not the same as ELF so on Windows you either build one or t
On 8/28/2012 1:09 AM, Michał Górny wrote:
On Tue, 28 Aug 2012 02:15:40 +0200
hasufell wrote:
static-libs
pointless
I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay,
where one can have static or dynamic, but not both, as per. upstream
requirements (no idea why). So FTR,
On 8/18/2012 5:50 PM, Ian Stakenvicius wrote:
On 2012-08-17, at 11:00 PM, "Gregory M. Turner" wrote:
greg@fedora64vmw /tmp $ mkdir foo
greg@fedora64vmw /tmp $ ROOT=foo portageq envvar ROOT
/tmp/foo/
Does /anybody/ use this feature?
Sorry for the HTML response... am on th
On 8/16/2012 6:26 PM, Rich Freeman wrote:
On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol wrote:
The limited-visibility build feature discussed a week or so ago would
go a long way in detecting unexpressed build dependencies.
[snip]
If portage has the
dependency tree in RAM then you just need
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 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 8/16/2012 4:59 AM, Rich Freeman wrote:
On Wed, Aug 15, 2012 at 3:18 PM, Michael Mol wrote:
It also sounds like something like that could be a benefit to shrinking @system.
I think the solution to the circular dependency issue isn't to make
Portage able to completely bootstrap the whole sy
I've stumbled onto an interesting little problem trying to build my
64->32 cross-prefix, which I bootstrapped with a no-multilib 32-bit
crossdev toolchain.
Please see https://bugs.gentoo.org/show_bug.cgi?id=430722, especially
the final two posts.
I'd appreciate input on the correctness/feasi
On 7/26/2012 11:26 AM, Rich Freeman wrote:
I've been messing around with namespaces and some of what systemd has
been doing with them, and I have an idea for a portage feature.
But before doing a brain dump of ideas, how useful would it be to have
a FEATURE for portage to do a limited-visibility
- Original Message -
> i'm pleased to announce the initial x32 release candidate:
> http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz
Also pleased to hear this! Thanks! Can't wait to find the time to play with
it. Did you do all that work yourself? Is there a wiki or
- Original Message -
> > 'if not os.environ["PORTAGE_PYTONPATH"]:'
> If PORTAGE_PYTHONPATH is not in os.environ then it will raise a
> KeyError, that is why we are doing a contains to begin with.
I somehow got the idea that the python gods had sprinkled magical syntax-sugar
on bool(x[y])
- Original Message -
> On Mon, Mar 26, 2012 at 4:12 PM, Gregory M. Turner
> wrote:
> > https://github.com/gmt/gmt-cygwin-overlay/blob/master/sys-apps/portage/files/portage-2.2.01.20271-cygdll_protect.patch
> Consistency in the style would be nice.
>
> For inst
Hello, I would appreciate if those of you with portage development experience
and a moment to spare could please take a look at:
https://github.com/gmt/gmt-cygwin-overlay/blob/master/sys-apps/portage/files/portage-2.2.01.20271-cygdll_protect.patch
Not gunning for upstream or anything, but I woul
54 matches
Mail list logo
