Coming back to this old thread (from July 2019). After some discussion
in #gentoo-pms today, here is an updated version of the patch.
Cross-posting to gentoo-dev and CCing prefix again, to make sure that
everyone is on the same page.
Ulrich
From 712772b7ef5543693147d8f96c03189e810a6ee8 Mon Sep
On Sat, 3 Aug 2019 00:07:13 +0100
James Le Cuirot wrote:
> Any better?
I think I would be personally aided by a description of what sort of
environment is expecting the various values, eg:
I know if I build for a target that I'll eventually have to "chroot" to
get into, paths that get "made con
On Thu, 1 Aug 2019 16:27:22 +0200
Alexis Ballier wrote:
>
> > What I am trying to say (somewhat unsuccessfully!) is that the value
> > of (E)SYSROOT only changes how the package is built, not what the
> > resulting package looks like. It's where all the headers and libraries
> > are sourced from a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 31 Jul 2019 21:40:19 +0100
James Le Cuirot wrote:
> On Wed, 31 Jul 2019 15:51:58 +0200
> Alexis Ballier wrote:
>
> > On Tue, 30 Jul 2019 23:26:27 +0100
> > James Le Cuirot wrote:
> >
> > > > Admittedly without a full understanding of th
On Wed, 31 Jul 2019 21:40:19 +0100
James Le Cuirot wrote:
> So why does ROOT affect it? Normally you install the packages for
> BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and
> RDEPEND are installed to different locations (ROOT!=/) then DEPEND will
> almost always be installed
On Wed, 31 Jul 2019 15:51:58 +0200
Alexis Ballier wrote:
> On Tue, 30 Jul 2019 23:26:27 +0100
> James Le Cuirot wrote:
>
> > > Admittedly without a full understanding of the problem, but this
> > > looks wrong to me: SYSROOT, EPREFIX and BROOT are only relevant in
> > > build phases (src_*); (E
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, 30 Jul 2019 23:26:27 +0100
James Le Cuirot wrote:
> > Admittedly without a full understanding of the problem, but this
> > looks wrong to me: SYSROOT, EPREFIX and BROOT are only relevant in
> > build phases (src_*); (EPREFIX is a little spe
On Mon, 29 Jul 2019 14:05:10 +0200
Alexis Ballier wrote:
> There seems to be unneeded whitespace only changes here that make the
> diff less readable
Sorry about that. I've only changed one cell in that table.
> Admittedly without a full understanding of the problem, but this looks
> wrong to m
On Sun, 28 Jul 2019 22:37:35 +0100
James Le Cuirot wrote:
[...]
> -& \t{BDEPEND} &
> \t{DEPEND} & \t{RDEPEND}, \t{PDEPEND} \\
> +& \t{BDEPEND} &
> \t{DEPEND}& \t{RDEPEND}, \t{PDEPEND} \\
> \mid
It was originally envisaged (but not stated in PMS) that SYSROOT would
only ever need to equal / or ROOT as a distinct SYSROOT would have no
benefit. A check was added to Portage to ensure this held. Myself, the
ChromiumOS team, and others have since been caught out by this check
when trying to boo
> On Fri, 1 Aug 2014, Martin Vaeth wrote:
> Ulrich Mueller wrote:
>>> On Sat, 26 Jul 2014, Martin Vaeth wrote:
>>
>>> Quite the opposite, PMS claims that one cannot rely on
>>> anything stored in /var/db
>>
>> Where does it say so?
> "Appendix B: Unspecified Items
> The following item
Ulrich Mueller wrote:
>> On Sat, 26 Jul 2014, Martin Vaeth wrote:
>
>> Quite the opposite, PMS claims that one cannot rely on
>> anything stored in /var/db
>
> Where does it say so?
"Appendix B: Unspecified Items
The following items are not specified by this document,
and must not be relied
(Somewhat late, but here we go )
> * PKG-PRETEND
critical
> * SLOT-OPERATOR-DEPS
yes
> * USE-DEP-DEFAULTS
critical
> * DEFINED-PHASES
critical
> * PROPERTIES
critical
> * SRC-INSTALL
critical
> * CONTROLLABLE-COMPRESS
critical
> * DODOC
yes
> * DOINS
yes
> * ANY-USE
whatever
> * BAN
On 20:59 Sun 12 Apr , Ciaran McCreesh wrote:
> Hopefully we can get a final list decided upon and provisionally
> approved by the next Council meeting, and then as soon as Portage is
> ready to go we can merge everything into PMS proper and get a signed
> approval tag as we did for EAPI 2.
>
>
On Sun, Apr 12, 2009 at 2:59 PM, Ciaran McCreesh
wrote:
> I've got the EAPI 3 branch for PMS more or less ready:
>
> http://github.com/ciaranm/pms/tree/eapi-3
> Here's the list:
>
> * PKG-PRETEND
critical
> * SLOT-OPERATOR-DEPS
critical
> * USE-DEP-DEFAULTS
critical
> * DEFINED-PHASES
critical
This reply's just for minor wording things. If anyone's wanting to
turn any of these into something more substantial, please change the
subject and cut it back to one topic per subthread.
On Tue, 21 Apr 2009 05:11:15 +0300
Mart Raudsepp wrote:
> query/yes; but the default src_install maybe should
On P, 2009-04-12 at 20:59 +0100, Ciaran McCreesh wrote:
> I've got the EAPI 3 branch for PMS more or less ready:
>
> http://github.com/ciaranm/pms/tree/eapi-3
>
> The provisional included feature list is everything that was ready
> before the deadline.
>
> Before the next Council meeting (id
Ciaran McCreesh wrote:
> I've got the EAPI 3 branch for PMS more or less ready:
>
> http://github.com/ciaranm/pms/tree/eapi-3
>
> The provisional included feature list is everything that was ready
> before the deadline.
>
> Before the next Council meeting (ideally a week before, so we've got
> On Mon, 20 Apr 2009, Tiziano Müller wrote:
>> * CONTROLLABLE-COMPRESS
> no.
Without this we cannot get rid of the "prepalldocs" calls in the tree.
Ulrich
Am Sonntag, den 12.04.2009, 20:59 +0100 schrieb Ciaran McCreesh:
> I've got the EAPI 3 branch for PMS more or less ready:
>
> http://github.com/ciaranm/pms/tree/eapi-3
>
> The provisional included feature list is everything that was ready
> before the deadline.
Thanks a lot for your work.
Sor
I've got the EAPI 3 branch for PMS more or less ready:
http://github.com/ciaranm/pms/tree/eapi-3
The provisional included feature list is everything that was ready
before the deadline.
Before the next Council meeting (ideally a week before, so we've got
time to get the questions worked out),
On Monday, November 3, 2008 02:22:12 Peter Volkov wrote:
> В Вск, 02/11/2008 в 12:11 -0700, Gordon Malm пишет:
> > You can cry "abuse" all you want. You FAIL to offer any alternatives or
> > solutions. I'll ask again, how do you detect that you are compiling code
> > destined to be run in-kernel
В Вск, 02/11/2008 в 12:11 -0700, Gordon Malm пишет:
> You can cry "abuse" all you want. You FAIL to offer any alternatives or
> solutions. I'll ask again, how do you detect that you are compiling code
> destined to be run in-kernel from within gcc without checking for the
> __KERNEL__ macro?
On Sun, 2 Nov 2008 12:11:10 -0700
Gordon Malm <[EMAIL PROTECTED]> wrote:
> > Have you conclusively established that they do build fine in
> > parallel? If so, how? And why do they break in parallel only under
> > distcc? Given how distcc works, this strikes me as somewhat
> > implausible...
>
> Ye
On Sunday, November 2, 2008 03:26:14 Ciaran McCreesh wrote:
> On Sat, 1 Nov 2008 18:29:03 -0700
>
> Gordon Malm <[EMAIL PROTECTED]> wrote:
> > You're the one assuming the only purpose would be to mask parallel
> > make problems. Apparently it does have a purpose though since
> > avidemux builds fi
On Sat, 1 Nov 2008 18:29:03 -0700
Gordon Malm <[EMAIL PROTECTED]> wrote:
> You're the one assuming the only purpose would be to mask parallel
> make problems. Apparently it does have a purpose though since
> avidemux builds fine in parallel but NOT via distcc.
Have you conclusively established th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gordon Malm wrote:
All the technical discussion on the above is perfectly fine, but the way
the arguments are being presented and the tone used by both sides is
getting arguments into a thin line from becoming flames.
Please step back before turning
On Saturday, November 1, 2008 15:57:52 Ciaran McCreesh wrote:
> > Parallel building problems can often and should be addressed
> > properly. I don't want the answer to every one that comes along to
> > be to add RESTRICT="distcc". This is something to be addressed
> > through developer documentat
On Saturday 01 November 2008 20:57:17 Gordon Malm wrote:
> I'd like to get "distcc" added as one of the FEATURES we are able to
> RESTRICT.
Regardless of whether it's a good idea or not, does it fix all the known
issues if the ebuild sets DISTCC_HOSTS="localhost" in the environment?
Gordon Malm wrote:
It looks to me like you've already made up your mind. How is hardened doing
the entirely wrong thing?
From the page [1] you mentioned:
"If so, that seems to me like an abuse of the -D option."
The abuse is in changing the compiler behavior based on -D options.
What do you
On Sat, 1 Nov 2008 15:47:09 -0700
Gordon Malm <[EMAIL PROTECTED]> wrote:
> > It looks to me like hardened is doing entirely the wrong thing.
> > Thus, the proper fix is to make hardened behave itself.
>
> It looks to me like you've already made up your mind. How is
> hardened doing the entirely w
On Saturday, November 1, 2008 15:11:16 Ciaran McCreesh wrote:
> On Sat, 1 Nov 2008 14:58:39 -0700
>
> Gordon Malm <[EMAIL PROTECTED]> wrote:
> > I use madwifi-ng extensively and have experienced the same issue with
> > madwifi-ng as stated in that bug. For bug #167844, please read
> > comment #13
On Sat, 1 Nov 2008 14:58:39 -0700
Gordon Malm <[EMAIL PROTECTED]> wrote:
> I use madwifi-ng extensively and have experienced the same issue with
> madwifi-ng as stated in that bug. For bug #167844, please read
> comment #13 and http://code.google.com/p/distcc/issues/detail?id=25.
> There's nothin
On Saturday, November 1, 2008 14:28:06 Ciaran McCreesh wrote:
> On Sat, 1 Nov 2008 14:21:43 -0700
>
> Gordon Malm <[EMAIL PROTECTED]> wrote:
> > If you're compiling an out-of-tree module that requires the kernel be
> > compiled with support for a particular item and the distccd host's
> > kernel do
On Sat, 1 Nov 2008 14:21:43 -0700
Gordon Malm <[EMAIL PROTECTED]> wrote:
> If you're compiling an out-of-tree module that requires the kernel be
> compiled with support for a particular item and the distccd host's
> kernel does not have that support compiles fail. Reference bug
> #120001 (though I
If you're compiling an out-of-tree module that requires the kernel be compiled
with support for a particular item and the distccd host's kernel does not
have that support compiles fail. Reference bug #120001 (though I know that
it was properly diagnosed there).
Then there's also this doozie. -
On Sat, 1 Nov 2008 13:57:17 -0700
Gordon Malm <[EMAIL PROTECTED]> wrote:
> But in the case of out-of-tree kernel modules the idea
> of distributing compile jobs to other machines is fundamentally
> flawed IMO.
Why? And how are out of tree kernel modules in any way special when it
comes to distcc?
I'd like to get "distcc" added as one of the FEATURES we are able to RESTRICT.
It is true that RESTRICT="distcc" is usually not the proper solution to
problems. But in the case of out-of-tree kernel modules the idea of
distributing compile jobs to other machines is fundamentally flawed IMO.
A
On Mon, 24 Dec 2007 08:27:39 + (UTC)
Duncan <[EMAIL PROTECTED]> wrote:
> The problem right now is that while you are correct, that's the
> official list, due to technical/political issues, the Gentoo-official
> PMS repo doesn't (or didn't as of the last council meeting, according
> to the log)
* Donnie Berkholz <[EMAIL PROTECTED]>:
> - Where is the PMS repo?
> - robbat2 has imported it. It's in git. Need to ping him for
> details.
Robin, how can I clone the repository?
Who maintains PMS now?
--
[EMAIL PROTECTED] mailing list
On Wed, 2007-04-07 at 22:11 +1000, Paul de Vrieze wrote:
> On Sat, 30 Jun 2007 01:12:02 Olivier Crête wrote:
> > On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> > > Paul de Vrieze wrote:
> > > > There are various problems that need to be addressed for cross
> > > > development and (especia
On Sat, 30 Jun 2007 01:12:02 Olivier Crête wrote:
> On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> > Paul de Vrieze wrote:
> > > There are various problems that need to be addressed for cross
> > > development and (especially) multilib/abi. One of the other ones that
> > > you didn't ment
On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> Paul de Vrieze wrote:
> > There are various problems that need to be addressed for cross development
> > and
> > (especially) multilib/abi. One of the other ones that you didn't mention is
> > some kind of subpackage support. For example w
Paul de Vrieze wrote:
> There are various problems that need to be addressed for cross development
> and
> (especially) multilib/abi. One of the other ones that you didn't mention is
> some kind of subpackage support. For example when one installs 32 bit gtk+ to
> use binary firefox on an 64bit
On Wednesday 06 June 2007, Luca Barbato wrote:
> yesterday we discussed about cross development and why the gentoo
> support for it works just to a point (and then has something missing)
>
> There are already some convoluted ideas about multiabi/multilib support
> with patches being discussed and t
Stephen Bennett wrote:
On Thu, 7 Jun 2007 22:38:49 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
If Portage currently happens to, say, disable sandbox if an ebuild
sets GIVE_ME_A_COOKIE="yes" globally, it does not mean that ebuilds
may rely upon this behaviour, nor does it mean that Portage
On Thu, 7 Jun 2007 22:38:49 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> If Portage currently happens to, say, disable sandbox if an ebuild
> sets GIVE_ME_A_COOKIE="yes" globally, it does not mean that ebuilds
> may rely upon this behaviour, nor does it mean that Portage cannot
> change in s
On Thu, 7 Jun 2007 23:31:38 +0200
Harald van Dijk <[EMAIL PROTECTED]> wrote:
> If the question is whether it's accepted, what matters is whether it's
> accepted. If you're interested in legality, ask whether it should be
> accepted, not whether it is. spb did that in the same message, and I
> respon
On Thu, Jun 07, 2007 at 10:15:35PM +0100, Ciaran McCreesh wrote:
> On Thu, 7 Jun 2007 22:52:39 +0200
> Harald van Dijk <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 07, 2007 at 09:40:20PM +0100, Ciaran McCreesh wrote:
> > > On Thu, 7 Jun 2007 22:33:21 +0200
> > > Harald van Dijk <[EMAIL PROTECTED]> wrot
On Thu, 7 Jun 2007 22:52:39 +0200
Harald van Dijk <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 07, 2007 at 09:40:20PM +0100, Ciaran McCreesh wrote:
> > On Thu, 7 Jun 2007 22:33:21 +0200
> > Harald van Dijk <[EMAIL PROTECTED]> wrote:
> > > An ebuild's PROVIDE list.
> >
> > Nnnnope. Not legal.
>
> The qu
On Thu, Jun 07, 2007 at 09:40:20PM +0100, Ciaran McCreesh wrote:
> On Thu, 7 Jun 2007 22:33:21 +0200
> Harald van Dijk <[EMAIL PROTECTED]> wrote:
> > An ebuild's PROVIDE list.
>
> Nnnnope. Not legal.
The question was "Is there any place in the tree where a dep atom and a
CPV are both accepted?" Lo
On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
> Carsten, no offense but I think you totally misunderstood the scope of
> what I was trying to convey
Yeah, sorry, should have had read your initial email carefully. Taking
anything before the last - as version information is indeed a Portage bu
On Thu, 7 Jun 2007 22:33:21 +0200
Harald van Dijk <[EMAIL PROTECTED]> wrote:
> An ebuild's PROVIDE list.
According to PMS at least, PROVIDE only allows category/package, with
no versioning.
--
[EMAIL PROTECTED] mailing list
On Thu, 7 Jun 2007 22:33:21 +0200
Harald van Dijk <[EMAIL PROTECTED]> wrote:
> An ebuild's PROVIDE list.
Nnnnope. Not legal.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, Jun 07, 2007 at 09:31:44PM +0100, Stephen Bennett wrote:
> On Thu, 7 Jun 2007 19:42:45 +0200
> Marius Mauch <[EMAIL PROTECTED]> wrote:
>
> > Thing is: if you see sys-fs/ntfs-3g, is that an atom or a CPV? You
> > don't know unless you actually check the tree.
>
> Is there any place in the
On Thu, 7 Jun 2007 11:28:26 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> 4. If the first character was a !, then remember that, strip the !
> from S, and repeat from 2.
> 5. If you reach this point, you have something that is not valid.
Sorry, but I completely fail to understand what tha
On Thu, 07 Jun 2007 15:04:17 -0400
Doug Goldstein <[EMAIL PROTECTED]> wrote:
> That's exactly what I'm saying. CPV (Category/Package/Version)
> requires =, >=, <, <= to begin it.
Nope. Something that starts with an operator is a versioned atom. A CPV
is used in other places when a specific versio
Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
> > That's exactly what I'm saying. CPV (Category/Package/Version) requires
> > =, >=, <, <= to begin it.
>
> So you'd like to change every foo/bar occurrence (and that's the common case)
> to >=foo/bar
On Thu, 7 Jun 2007 19:42:45 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
> Thing is: if you see sys-fs/ntfs-3g, is that an atom or a CPV? You
> don't know unless you actually check the tree.
Is there any place in the tree where a dep atom and a CPV are both
accepted? Should there be?
--
[EMAIL
Carsten Lohrke wrote:
> On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
>
>> That's exactly what I'm saying. CPV (Category/Package/Version) requires
>> =, >=, <, <= to begin it.
>>
>
> So you'd like to change every foo/bar occurrence (and that's the common case)
> to >=foo/bar-0 !? Comp
On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
> That's exactly what I'm saying. CPV (Category/Package/Version) requires
> =, >=, <, <= to begin it.
So you'd like to change every foo/bar occurrence (and that's the common case)
to >=foo/bar-0 !? Completely out of line, imho. I don't understand
Robin H. Johnson wrote:
> On Thu, Jun 07, 2007 at 02:04:08PM -0400, Doug Goldstein wrote:
>
>>> Thing is: if you see sys-fs/ntfs-3g, is that an atom or a CPV? You
>>> don't know unless you actually check the tree.
>>>
>> I thought that was the whole point of =. That identifies CPV instead
On Fri, 8 Jun 2007 02:57:28 +0900
Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> maillog: 07/06/2007-19:42:45(+0200): Marius Mauch types
> > Thing is: if you see sys-fs/ntfs-3g, is that an atom or a CPV? You
> > don't know unless you actually check the tree.
>
> Isn't "sys-fs/ntfs-3g" the atom and
On Thu, Jun 07, 2007 at 02:04:08PM -0400, Doug Goldstein wrote:
> > Thing is: if you see sys-fs/ntfs-3g, is that an atom or a CPV? You
> > don't know unless you actually check the tree.
> I thought that was the whole point of =. That identifies CPV instead of
> an atom.
If you look the DEPEND/RDEPE
Marius Mauch wrote:
> On Thu, 07 Jun 2007 12:32:40 -0400
> Daniel Drake <[EMAIL PROTECTED]> wrote:
>
>
>> Doug Goldstein wrote:
>>
>>> Currently in the tree we have sys-fs/ntfs3g. However the proper
>>> upstream name and name referenced in every single doc in the world
>>> is "ntfs-3g". I t
maillog: 07/06/2007-19:42:45(+0200): Marius Mauch types
> On Thu, 07 Jun 2007 12:32:40 -0400
> Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> > Doug Goldstein wrote:
> > > Currently in the tree we have sys-fs/ntfs3g. However the proper
> > > upstream name and name referenced in every single doc in th
On Thu, 07 Jun 2007 12:32:40 -0400
Daniel Drake <[EMAIL PROTECTED]> wrote:
> Doug Goldstein wrote:
> > Currently in the tree we have sys-fs/ntfs3g. However the proper
> > upstream name and name referenced in every single doc in the world
> > is "ntfs-3g". I tried to rename the package however, Por
Doug Goldstein wrote:
Currently in the tree we have sys-fs/ntfs3g. However the proper upstream
name and name referenced in every single doc in the world is "ntfs-3g".
I tried to rename the package however, Portage does not let me since it
is invalid naming. marienz and genone informed me it's inv
Doug Goldstein wrote:
> Howdy all,
>
> I just bumped into something I feel is a Portage and PMS bug. Since I
> believe in concrete use cases, I'll just go with that.
>
> Currently in the tree we have sys-fs/ntfs3g. However the proper upstream
> name and name referenced in every single doc in the wo
Howdy all,
I just bumped into something I feel is a Portage and PMS bug. Since I
believe in concrete use cases, I'll just go with that.
Currently in the tree we have sys-fs/ntfs3g. However the proper upstream
name and name referenced in every single doc in the world is "ntfs-3g".
I tried to renam
Ciaran McCreesh wrote:
> On Wed, 06 Jun 2007 11:24:00 +0200
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> PMS overlords what's your take?
>
> You need to start by identifying use cases. Are you discussing handling
> cross compiling,
Yes
multilib,
Ok
C++ / python ABIs
Aargh, ehm, should we
On Wed, 06 Jun 2007 11:24:00 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> PMS overlords what's your take?
You need to start by identifying use cases. Are you discussing handling
cross compiling, multilib, C++ / python ABIs or all of them? Then you
need to identify what packages would need to do
yesterday we discussed about cross development and why the gentoo
support for it works just to a point (and then has something missing)
There are already some convoluted ideas about multiabi/multilib support
with patches being discussed and there are some handy scripts that let
you cross emerge st
Donnie Berkholz napsal(a):
> Stephen Bennett wrote:
>> The open bug list is down to two, on which I want more input before
>> resolving them. We could also use more eyes again to bring up any other
>> issues before it's reckoned final.
> Could we get a pointer to that bug list?
All bugs: http://t
On Wed, 11 Apr 2007 16:22:28 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Stephen Bennett wrote:
> > The open bug list is down to two, on which I want more input before
> > resolving them. We could also use more eyes again to bring up any
> > other issues before it's reckoned final.
> >
> >
Stephen Bennett wrote:
The open bug list is down to two, on which I want more input before
resolving them. We could also use more eyes again to bring up any other
issues before it's reckoned final.
The PDF is still at http://dev.gentoo.org/~spb/pms.pdf; anon SVN is
still available at http://svn.
The open bug list is down to two, on which I want more input before
resolving them. We could also use more eyes again to bring up any other
issues before it's reckoned final.
The PDF is still at http://dev.gentoo.org/~spb/pms.pdf; anon SVN is
still available at http://svn.attenuate.org/pms.
--
ge
77 matches
Mail list logo
