Re: [gentoo-dev] What are blocks used for?

[Michael Haubenwallner]

On Wed, 2008-04-16 at 07:34 +0100, Ciaran McCreesh wrote:

> Case D, Current Behaviour: User tries to upgrade coreutils. User gets a
> big flashy block error saying coreutils blocks mktemp. User doesn't
> realise that the safe upgrade path is to force the package manager to
> ignore the block, then manually uninstall mktemp straight afterwards.
> User instead uninstalls mktemp, which is a moderately critical binary.

Or user uninstalls coreutils - yes, a colleague of mine actually did...

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] New developer : Markus Duft (mduft)

[Michael Haubenwallner]

On Wed, 2008-04-30 at 13:35 +0200, Denis Dupeyron wrote:
> It's my pleasure to introduce Markus Duft (mduft) as a new developer.
> He will go among us under the name of mduft, and will work in the
> Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that
> means Gentoo on Win32.

Yes, today isn't April, the first (remember geNToo).
Heh - today is April, the last!

> Please everybody, give a very warm welcome to mduft.

Enjoy geVISToo ;)

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"

[Michael Haubenwallner]

On Mon, 2008-06-30 at 14:10 -0600, Ryan Hill wrote:
> On Mon, 30 Jun 2008 21:42:49 +0300
> Petteri Räty <[EMAIL PROTECTED]> wrote:
> 
> > Mike Frysinger kirjoitti:

> > > imo -Wl,-O1 should go into base
> > > -mike
> > 
> > So seems like we should just do it (tm).
> 
> Why not default/linux?

Just wanted to ask the same...

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Michael Haubenwallner]

On Thu, 2008-10-09 at 20:11 +0200, Fabian Groffen wrote:

>   ia64-hpux

There's one thing to say for this platform to avoid later confusion:

'ia64-hpux' is the keyword for 32bit on that platform.
'ia64w-hpux' would be the 64bit keyword (not in prefix-tree yet).

This might seem confusing, but is the way HP does for various reasons.

HP-UX is the only OS I know that does multilib on the ia64 CPU, and the
default compiler output is 32bit without any additional switch.

I can provide more details if necessary.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Michael Haubenwallner]

On Mon, 2008-10-13 at 19:59 +0200, Fabian Groffen wrote:
> On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
> > On Mon, 13 Oct 2008 06:16:01 +0100
> > Steve Long <[EMAIL PROTECTED]> wrote:
> > > Unless someone can say what using PROPERTIES=prefix would break, I'd
> > > go with that. It's a /classic/ usage of that variable, as it's simply
> > > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
> > > support it. It'd be great to see the prefix branch finally merged so
> > > we all get to play with it.
> > 
> > It would break. Prefix ebuilds won't work unless ED is set, and a non
> > PROPERTIES aware or non-prefix-property aware package manager won't set
> > ED. Unless prefix is reimplemented to require no package manager
> > changes for the install to / case, PROPERTIES is out.
> 
> Just to comment on this possibility; I see an option, given the
> definition of ED and EROOT to do Prefix without them, by e.g. using
> ${D}${EPREFIX} instead of ${ED} as shorthand.  When ${EPREFIX} would be
> unset, this would result in simple ${D}, which is "backwards
> compatible".  This is not all what is necessary, but a big deal of it.
> 
> Question here, however, is whether this is worth it.  Personally, I
> prefer the shorthands, as they give a lot of readability.

Could it also work to initialize them in profile.bashrc if they are
unset?

Something like
: ${EPREFIX=}
: ${ED=${D}}
: ${EROOT=${ROOT}}

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Michael Haubenwallner]

On Thu, 2008-10-09 at 20:11 +0200, Fabian Groffen wrote:

>   sparc-solaris
>   sparc64-solaris
>   x64-solaris
>   x86-solaris

> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
> and should we use something like PREFIX_KEYWORDS?

Maybe there is one thing we should consider:
Since the Solaris kernel is Open now (=OpenSolaris), one could have the
strange idea of adding some "sys-kernel/solaris-sources-2.11.ebuild", to
build some distribution eventually called "Gentoo Solaris", which might
be comparable to Nexenta[1], which uses Debian's APT AFAICS.

As "Gentoo Solaris" would not be the same as "Gentoo Prefix on Solaris",
it should not share the *-solaris keywords used for Prefix via the same
KEYWORDS-setting.

For me, this is a (maybe strange, but valid) reason for something like
PREFIX_KEYWORDS.

[1] http://www.nexenta.org/

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Michael Haubenwallner]

On Fri, 2008-11-14 at 15:35 +0100, Rémi Cardona wrote:
> Alexis Ballier a écrit :
> > Hi,
> > 
> >> (I think pulseaudio is fixed, actually.)
> > 
> > For what it's worth: removing the .la files from pulseaudio breaks its
> > module loading on freebsd; and it's an elf system. I don't know what
> > you mean by fixed 
> 
> It's not fixed and it can't be. libtool's cross-platform dlopen()
> wrapper library (libltdl) needs .la files even on ELF systems.
> 
> The only way to fix this is to use dlopen() instead...

Never *unconditionally* switch back from libltdl to dlopen&co in source
code, as it is likely to break many non-linux platforms (Darwin, AIX,
HP-UX, ...).

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Michael Haubenwallner]

On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote:
> get opinions [..] to get some idea what the general developer pool thinks.
> only allowed to post a single reply to this thread

Thank you for that, I usually don't follow long threads, so apologies if
things have been discussed already.

Basically, I'm all for having GLEP55 "as good as possible" in favour of
"as soon as possible" before implementation, even if it fits my
thoughts quite good already (see below).

> 2) EAPI in file extension

IMO, this should define *how* to read the *final* EAPI from the ebuild.
The *how* does not necessarily mean to /source/ the ebuild, so the terms
"pre-source EAPI" and "post-source EAPI" IMHO are too strongly focussing
on "(bash)> source $EBUILD" when used in a generic GLEP. Eventually, the
 "pre-source" EAPI could be called "major" EAPI, and the
"post-source" EAPI could be called "major.minor" EAPI (see below).

The "EAPI in file extension" also should define the filename-part of the
versioning rules.

>   a) .ebuild-
>   c) ..
> - ignored by current Portage
>   b) ..ebuild
> - current Portage does not work with this

"ignored by current portage" is an important point for me to
*theorethically* guarantee for a possible upgrade path even over long
time.

> 3) EAPI in locked down place in the ebuild

This "lock down" should be done by "EAPI in file extension" above.
"lock down" can mean any of: "post-source (real bash-source)",
"self-parse (grep?)", "fixed-byte/line-offset", "..."

My thoughts are to split EAPI into several levels (rename them however
you like):

entry-point:
Specifies how to read the "filename-scope" EAPI.

filename-scope EAPI:
Think as "major" EAPI.
Specifies the filename-part of versioning rules.
Specifies how to read the "global-scope" EAPI (can, but
eventually should not require bash-sourcing the ebuild).
May allow to not define "minor", assuming "$major.0.0" then.

global-scope EAPI:
Think as "$major.minor" EAPI.
May specify how to define additional versioning rules.
Specifies how to define metadata information.
Specifies which metadata information is
required/optional/cached/... Specifies how to utilize external
resources (eclasses).
Specifies which/how actions can/must be defined (pkg_*, src_*
functions).
Specifies how to read the "local-scope" EAPI.
May allow to not define "micro", assuming "$major.$minor.0"
then.
May disallow a "local-scope" EAPI, specifies it instead.

local-scope EAPI:
Think as "$major.$minor.micro" EAPI.
Specifies which PM-functions are available for use in actions
(fex 'doman' inside src_install).
May be specified as part of "minor" EAPI.

Thanks!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Michael Haubenwallner]

On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote:

> I think the idea of ebuilds as scripts showing directly how to build 
> software is a core part of the Gentoo build-system philosophy. This 
> proposal pushes ebuilds toward a formatted file that is not a script. 
> Instead, it is more like an Ant XML file that more abstractly describes 
> a build. I think this is the wrong direction for ebuilds because they 
> should directly resemble how software is built by hand.

Fully agreed here, "keep it simple software".
Even if there are slightly more bits to write in the ebuilds.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Michael Haubenwallner]

Hi,

Reminder (for myself):
As long as we want/have to support PMs lacking EAPI detection in
'*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
to an '*.ebuild' must be hackish. So we can try to find the least ugly
hack, or we need to change the extension.

So just another idea, based on the "eapi() function" one:
As inherit() is the only(?) global function provided by old PMs, the
first non-commentary/non-blank line in '*.ebuild' could read:

   inherit eapi

Compliant PMs identify 'eapi' as a special eclass name (with or without
sourcing the ebuild), to know that "this ebuild specifies an EAPI".

For non-compliant PMs, we need to provide an 'eapi.eclass', which just
spits some 'your PM lacks EAPI support' message and causes the PM to
mask this ebuild 'by corruption' or the like.

Or - what are old PM's messages when an eclass is missing?

Eventually, this line also could finally specify the EAPI and read:

   inherit eapi 4

Because non-compliant PM's already quit because of (missing or dying)
eapi.eclass, there is no need to have a '4.eclass'.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Michael Haubenwallner]

On Mon, 2009-03-09 at 15:39 -0700, Donnie Berkholz wrote:

> > * Utility commands, even the ones that aren't functions, should die. To
> >   get a non-die version, prefix the command with nonfatal (e.g.
> >   'nonfatal dodoc README', which just returns non-zero on failure
> >   rather than splatting).
> 
> Sounds useful to have less '|| die' all over the place.

Whats wrong with 'set -e' and doing '|| true' behind?
IMO this would feel more shell-ish.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Michael Haubenwallner]

(trying to have people understand the idea, not to discuss in this
thread)

On Fri, 2009-03-13 at 06:18 +1300, Alistair Bush wrote:

> > As long as we want/have to support PMs lacking EAPI detection in
> > '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
> > to an '*.ebuild' must be hackish. So we can try to find the least ugly
> > hack, or we need to change the extension.

> >inherit eapi 4
> > 
> > Because non-compliant PM's already quit because of (missing or dying)
> > eapi.eclass, there is no need to have a '4.eclass'.
> 
> How would the 4.eclass determine whether the package manager actually 
> supports the eapi?
> 
> inherit is a function remember so any "special" parsing will not change 
> the fact the the inherit function will be called.
> Will then need to determine whether there is actually a PM that doesn't 
> support the eclasses EAPI and then die.

The most important point here I thought everyone is aware of:
inherit() is a function provided *by* PM - or am I wrong here?

So it already *knows* to handle the 'eapi' argument as special when the
PM is compliant, to not read *any* eclass for this one inherit-call when
the ebuild gets sourced (assuming selected eapi specifies to
shell-source the ebuild).
And non-compliant PMs would mask the ebuild 'by corruption', because of
either missing or globalscope-dying eapi.eclass, whatever can be made
look more obvious to the user.

> What are the implications of calling inherit multiple times within an 
> ebuild?

A compliant PM does allow this if the selected eapi specifies to inherit
eclasses, a non-compliant PM will not come to a subsequent inherit call
after 'inherit eapi'.

> Im sorry,  but this just sounds like a HACK, and a hacky hack at that.

Agreed (see above).
Again - the only reason for this idea is to eventually allow for keeping
the '.ebuild' extension, because EAPI 0 does not allow for specifying
*any* eapi at all. It just forces PM to provide inherit() as the only
PM-defined global-scope function. So whatever we try, specifying an eapi
inside an .ebuild *without* changing the extension *will* be a hack,
just more ore less ugly.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] newins "-" for standard input?

[Michael Haubenwallner]

On Mon, 2009-03-23 at 17:11 +0100, Timothy Redaelli wrote:
> On Monday 23 March 2009 09:22:06 Ulrich Mueller wrote:

> >
> >newins - baz <<<$'# a short\n# file'
> 
> Why can't you use "newins /dev/stdin foo" that it works out of the box?

Nope, /dev/stdin isn't portable.

While Linux and Solaris have it, AIX and HP-UX do not
provide /dev/stdin. Unsure about Interix and MacOSX.

Using '-' sounds familiar for me too.

/haubi/

[gentoo-dev] Gentoo as Meta Distribution?

[Michael Haubenwallner]

Hi people,

I've been cooking a thought for some time now, and now I'm inviting you
to have a look at and share your thoughts about it:

The title could be somehow like:

How to use "Gentoo, the Meta Distribution" to create my own
"Enterprise Distribution"?

When I say "my own Enterprise Distribution", I mean doing my own arch
testing and stable keywords, for a small number of packages - less than
200 here including @system.

"Doing my own stable keywords" does not mean to throw away upstream
(=Gentoo) keywords, but reuse them as unstable keywords for my
distribution, so my distro-users can easily emerge packages which are
either upstream-stable or even -unstable, assuming they know what they
do then.

Additionally, I want to have my own release cycles, using my own release
profiles.

This all implies that I "track" (=git-speaking) upstream tree in some
scm, ideally with only my release profiles and my keywords as the only
local difference.

Now for how to specify the keywords:

Assume upstream ebuild contains:
KEYWORDS='  amd64 ~hppa ~mips  ppc  x86'

my local ebuild then *additionally* might contain:
HAUBIDIST_KEYWORDS='amd64  hppa~x86'

Now I want to tell PM which ebuild-keywords to use for my
distro-instance, where only 1. and 2. really would make sense:
 1. ' amd64  hppa~x86'
 2. ' amd64  hppa ~mips ~ppc ~x86'
 3. ' amd64  hppa ~mips  ppc ~x86'
 4. '~amd64 ~hppa ~mips  ppc ~x86'
 5. ' amd64 ~hppa ~mips  ppc  x86'

This could be done by telling PM - in etc/make.conf or profile/make.conf
- how to merge $KEYWORDS and $HAUBIDIST_KEYWORDS. According to above
numbering, this might look like (with value-order being important):
 1. ACCEPT_DISTRO_KEYWORDS=' HAUBIDIST'
 2. ACCEPT_DISTRO_KEYWORDS=' HAUBIDIST ~GENTOO'
 3. ACCEPT_DISTRO_KEYWORDS=' HAUBIDIST  GENTOO'
 4. ACCEPT_DISTRO_KEYWORDS='~HAUBIDIST  GENTOO'
 5. ACCEPT_DISTRO_KEYWORDS=' GENTOO  HAUBIDIST'
where 'HAUBIDIST' maps to ebuild's $HAUBIDIST_KEYWORDS and 'GENTOO' maps
to ebuild's $KEYWORDS.

This eventually also could apply for Gentoo Hardened, to not have that
large list in package.mask, but HARDENED_KEYWORDS in the ebuilds, and
ACCEPT_DISTRO_KEYWORDS='HARDENED ~GENTOO' in make.conf.

And when HARDENED_KEYWORDS is in upstream ebuilds, also this could work
for HAUBIDIST in make.conf then:
ACCEPT_DISTRO_KEYWORDS='HAUBIDIST ~HARDENED'

Now when "Gentoo" stands for either "Gentoo Linux" or "Gentoo Prefix":

We could have PREFIX_KEYWORDS in the maintree-ebuild, and for HAUBIDIST
- when it is a "Prefix Distribution" - to have in make.conf:
ACCEPT_DISTRO_KEYWORDS='HAUBIDIST ~PREFIX'

So for the vanilla "Gentoo Linux Distribution", this would mean:
ACCEPT_DISTRO_KEYWORDS='GENTOO'
the vanilla "Gentoo Prefix Distribution" would ship with:
ACCEPT_DISTRO_KEYWORDS='PREFIX'
and the vanilla "Gentoo Hardened Linux Distribution" with:
ACCEPT_DISTRO_KEYWORDS='HARDENED ~GENTOO'

What else would be needed for the whole topic:
  * helper scripts to manage/merge/update my private distro-tree.
  * helper scripts to set up my private distro's distfiles mirror.
  * repoman support for additional keyword variables
  * more thoughts
  * ...

Thank you for your time reading until here!

/haubi/ (-> weekend now)
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Preserving mtimes for EAPI3

[Michael Haubenwallner]

On Mon, 2009-03-30 at 19:14 +0200, Ulrich Mueller wrote:

> I'll try to summarise the current state of discussion in
> <https://bugs.gentoo.org/264130>. The goal is to satisfy two
> (apparently contradictory) requirements:
> 
>   a) Some packages need a preserved ordering of file modification
>  times, therwise things will break at run time (see above).
> 
>   b) Files in the installed system should not have mtimes that are
>  older than the build time of the package. 
> 

> Now, is it possible to satisfy both? I think that the following
> procedure would accomplish it:
> 
>   1. Record two timestamps:
>  before calling pkg_setup, timestamp1;
>  after src_install has completed, timestamp2.
> 
>   2. After src_install and before merging (the exact time would be
>  implementation dependent), scan ${D} for files having
>  mtime < timestamp1 or mtime > timestamp2.
>  Update their mtimes to timestamp1 or timestamp2, respectively.
> 
>   3. Otherwise (i.e. for files with timestamp1 <= mtime <= timestamp2),
>  preserve modification times when merging ${D} to ${ROOT}.
> 
> This way, any files generated during the build process (*.pyc, *.fasl,
> *.elc) would end up with timestamps newer than their corresponding
> source files (*.py, *.lisp, *.el).

Please keep this user-situation in mind, which complicates things:

When developing local applications outside of portage, they often have
autogenerated makefile-dependencies on host-os headerfiles.
Now when a host package gets remerged, and the headerfiles don't change,
all the local applications recompile everything for nothing...

OTOH, when the headerfile changes, it should have mtime updated to
'merge time', because local applications _should_ recompile then.
And using 'build time' is of less use with binary packages, it should be
'merge time' instead.

Maybe this could be done somehow like this, with 'merge time'
calculation for each file based on above steps 1.-3.:
  * When a to-be-merged file does not exist before, set mtime to
'merge time'. 
  * When a to-be-merged file does exist already, and its content
does not change, take the mtime from the already existing file. 
  * When a to-be-merged file does exist already, and its content
does change, set mtime to 'merge time'.

Maybe this should be done for header files only, or with some black- or
whitelisting mechanisms, or for files which have mtime<'build time'?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] RFC: EAPI cheat sheet for your desktop

[Michael Haubenwallner]

On Tue, 2009-03-31 at 18:48 +, Ferris McCormick wrote:
> On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote:
> > Hi everyone,
> > 
> > with EAPI 3 confusion about what is in which EAPI may increase,
> > although appendix E of the PMS is quite helpful here.  Anyway,
> > something handy to put on your desk is my little EAPI leaflet which
> > gives you all important (in my eyes) information in one leaf.  Have a
> > look at http://v-li.de/temp/eapi_cheatsheet.pdf>, print it, fold
> > it and tell me if you like or not (and especially what exactly).
> > 
> > V-Li
> 
> I like it.  It's useful to me, at least, and I like having this
> information available where I can find it in case I need it.

+1

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Michael Haubenwallner]

If there is a different place for requirement discussion of Gentoo
specific GSoC projects, please tell, and sorry for bothering here then.

On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote:
> Here are the main interest ideas:
> * actions can be run system-wide and per-user:
> # action user moo
> # action system moo

Are there any thoughts to support something more fine granular settings
than system and user?

What I'm after:
We are developing multiple source projects with multiple release
branches on the same host here. These projects do have some script to
set up the project specific environment. One os-user is working on
multiple projects or branches, entering a project's environment by
sourcing its environment script.

Naturally, these projects do have different requirements to - for
example - the java-vm version. The project admin needs to select the
java-vm on a per-project basis, and does want to use the system-vm as
fallback, never wants to use the user-vm.

With current eselect (and java-config-2), this would be something like
setting $HOME on the per-project basis - or not using java-config at
all.

Would it make sense to explicitly set the system-vm (whatever version it
is or will be changed to), while leaving it unset would fall back to the
user-vm?

More toughts?

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Michael Haubenwallner]

On Tue, 2009-05-12 at 15:32 +0100, Sérgio Almeida wrote:
> > On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote:
> > > Here are the main interest ideas:
> > > * actions can be run system-wide and per-user:
> > > # action user moo
> > > # action system moo
> > 
> > Are there any thoughts to support something more fine granular settings
> > than system and user?
> 
> Indeed, user is not "for all the users". It's an action that can be run
> by the users to change it's own settings without touching the system's
> fallback default.

Seems you didn't really understand my problem yet - another try:
The *one* and *same* user does need different settings at the *same*
time depending on the project he's currently working on in different
shells. The actual setting needs to be set up by the project's
environment script (when the users enters the project), not the user's
profile script (when the user logs in).

> That's the point of the uselect tool. Per-System settings, Per-User
> settings (2 different ssh sessions of the same user can still have
> different environment settings too).

This maybe is what I'm after: Question still is how to easily set up the
different environment?

> I work as a sysadmin and manage mainly multi-user gentoo environments
> where people develop calculus c/python/fortran/R/whatever code using
> wathever utilities we can imagine. Everytime a new project is beeing
> done people need to set the environment variables themselves when they
> are kind enough not to ask me. That's mainly the whole purpose of this
> uselect tool, easy multi user environments managing.

Seems like we have a similar job ;)
Maybe it's the wording only, but in addition to the multi-user dimension
I'm still missing the multi-project dimension for one user.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Michael Haubenwallner]

On Tue, 2009-05-12 at 21:45 +0100, Sérgio Almeida wrote:

> How about having the profile switch automatic whenever
> you call "uselect something" getting the current profile settings from
> current dir's .uselect folder?

Yeah, this indeed could work!

But there is one restriction:
This .uselect folder must be able to be checked in into some VCS, so it
should not contain symlinks, but plain (text?) files only.
We also want to use this on Windows based filesystems where symlinks
don't work at all.

Ohw, I do have another requirement:
We do check-out/compile/develop/run/test the same package on different
hosts and platforms. Each of these hosts might require slightly
different settings. ATM, the package's environment script handles this
by acting differently based on `hostname` and `uname` or "${chost}".
Ohw, it even does different settings based on the username (`id -un` or
`whoami`), because in production these projects usually run under a
specific user with less restrictive settings than for developers.

What if there is some hierarchy in .uselect/ much like the profiles in
gentoo-x86 tree, using some kind of 'parent' files to inherit/override
settings for this one project, where 'parent' can contain something like
$(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)?

I'm unsure if managing different settings based on hostname, uname/chost
and username (the inheritance tree) is uselect's job. It eventually
should optionally listen to some cmdline-parameter or environment-
variable where to look for the uselect settings instead, which could be
stored and regenerated using such profile hierarchy mechanism/utility.
Or even the whole uselect settings optionally come from stdin (and go to
stdout), to be managed/stored within that profile hierarchy.

Ha! This kind of inheritance tree could be a solution for my long
standing bug here to simplify our way too complex environment script...

Ah, don't forget to put a version number as the very first value into
the uselect settings, to avoid backwards compatibility issues in the
future. And when uselect settings can be read from stdin (stored in
simple text files), this version number could occur multiple times
there, as the stored files simply will be concatenated. And subsequent
values might override previous ones then.

Uh, so many strange ideas!
More of them?

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Michael Haubenwallner]

On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote:

> > This .uselect 
> > should not contain symlinks, but plain (text?) files only.

> Do we really need more than one file? 

No, at least not to define the _values_ of a profile.

> Checklist:
> * Hostname
> * Uname
> * {$chost}
> 
> Mmm... Maybe we can simplify this with a parameter like:
> 
> # eval something
> eval "hostname" "superhost"
> what
> to
> do
> # end something
> 
> Then if command "hostname" outputs "superhost" we know "what-to-do". 

Eventually, we should pass something like "-Dhostname=superhost" as
cmdline parameter to uselect...

> 
> This way it would get ultra versatile.
> 
> > What if there is some hierarchy in .uselect/ much like the profiles in
> > gentoo-x86 tree, using some kind of 'parent' files to inherit/override
> > settings for this one project, where 'parent' can contain something like
> > $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)?
> > 
> 
> Would this really be necessary? We can define hierarchy into a
> single .uselect file. Even the use of folders (folder .uselect/) isn't
> necessary. I think a single file can handle all this... 

Eventually yes.

> Lets see an
> example:
> 
> # profile something

I don't like to have anything interpreted after the usual and well-known
comment-marker, this just feels hackish.

> 
> do this 3 <- override the overridden =)

> The actions to be done like "do this 3" are a simple call to uselect
> using module "do" and action "this" with "3" as parameters.

fine.

I do have something like this content-syntax in mind for .uselect (or
eventually some .uprofile) file:

8<8<8<
version "0.1"

include "path/to/another/uselect/file"

profile "generic solaris" {
  module A actionAX "valueAX1" "valueAX2"
  module B actionBX "valueBX1" "valueBX2
}

profile "generic host" {
  module C actionCX "valueCX1"
}

profile "superhost" {
  inherit profile "generic solaris"
  inherit profile "generic host"
  module C actionCX "newvalueCX1"
  module A actionAX "newvalueAX1" "newvalueAX2"
  module D actionDY "valueBY1" "valueBY2"
}

profile "generic user" {
  module E actionEX "valueEX1"
}

profile "user haubi" {
  inherit profile "generic user"
  module F actionFX "valueFX1"
}

profile "any user on superhost" {
  module G actionGX "valueGX1"
}

profile "fallback host" {
  inherit profile "generic host"
  module A actionAX "valueAX1" "valueAX2"
}

activation "superhost activation" {
  in category "host"
  on fallback level 0
  when $hostname matches string "superhost"
  activate profile "superhost"
}

activation "haubi on superhost" {
  in category "user"
  on fallback level 0
  when $username matches string "haubi"
  when $hostname matches string "superhost"
  activate profile "any user on superhost"
  activate profile "user haubi"
}

activation "haubi" {
  in category "user"
  on fallback level 1
  when $username matches string "haubi"
  activate profile "user haubi"
}

activation "gentoo host" {
  in category "host"
  on fallback level 1
  when $hostname matches regex ".*\.gentoo\.org"
  activate profile "fallback host"
}
>8>8>8

I'm not sure to have an ascending "fallback level" or descending
"priority" value, but both should allow for negative integer values.

The selection of one or more profiles is controlled by "activation"
entries, independent for each "category". The order and selection of
categories is done via a commandline argument, fex "--categories".

Profiles are selected when all of the "when" entries (besides "category"
and "fallback level") in "activation {}" do match.
Selected are *all* of the matching profiles in the *lowest* "fallback
level" *only*, which does have at least one matching profile.

And I'm thinking of something like this commandline:
$ uselect \
  --categories host,user \
  --define hostname=`hostname` \
  --define username=`whoami`

> 
> Remember that profile creation/storing/managing should be automatic and
> nothing would need to be written by hand.

Yes, would be fine. When using something like above configuration file
syntax, some GUIding tool would be useful, at least to see which
profiles are selected for specific cmdline args.

>  By other words, create a basic
> profile automatically using your currently running settings and then
> alter the profile with the util to add constrains to it.

Sounds interesting...

> Remember that
> all the machines that this profile is read would need to have the same
> uselect modules into it's /usr/share/uselect/modules or similar.

Indeed, yes.

> > Ha! This kind of inheritance tree could be a solution for my long
> > standing bug here to simplify our way too complex environment script...
> > 
> 
> This is a basic idea from softenv so it has has it's place into uselect.

Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/
Do you mean this one?

> The question now is, bloat it all into uselect or create a uprofile
> util? I like the idea of having to use only uselect for basic profiling
> and using uprofile for 

[gentoo-dev] GLEP 55: another approach: display pretty messages with old PMs

[Michael Haubenwallner]

loads: 0 kB

This is: one additional nice line for each unsupported ebuild, except
for the version format change, which shows 'Invalid ebuild name'.

But how many such new version formats will exist while there are no
other ebuilds with unsupported eapi but compatible version format, and
how long do we really plan to support PMs not pre-source reading the
eapi?

When there is no supported ebuild available, this would look like:

$ ACCEPT_KEYWORDS='~x86' emerge -1pv '>net-misc/mico-2.3.13'

These are the packages that would be merged, in order:

Calculating dependencies |
Invalid ebuild name: /usr/portage/net-misc/mico/mico-2.3.13_live.ebuild
 * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r3.
 * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r2.
 * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r1.  

... 
done!

!!! All ebuilds that could satisfy ">net-misc/mico-2.3.13" have been 
masked.
!!! One of the following masked packages is required to complete your 
request:
- net-misc/mico-2.3.13-r3 (masked by: corruption)
- net-misc/mico-2.3.13-r2 (masked by: corruption)
    - net-misc/mico-2.3.13-r1 (masked by: corruption)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

my 2ct...

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Michael Haubenwallner 
# Purpose: Inform the user that another version of the PM is required to
# support this ebuild.
#

if [[ ${EAPI+set} != 'set' ]]; then
if [[ ${PR:-r0} == 'r0' ]]; then
ewarn "Need >=sys-apps/portage-2.3 to support ${CATEGORY}/${P}."
else
ewarn "Need >=sys-apps/portage-2.3 to support 
${CATEGORY}/${P}-${PR}."
fi
exit 0
fi

[gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs

[Michael Haubenwallner]

On Thu, 2009-05-28 at 19:17 +0200, Michael Haubenwallner wrote:

> inherit eapi 4
> 
> Now when the PM is capable of pre-source EAPI detection, it will set
> EAPI before sourcing, eapi.eclass can see EAPI already being set and not
> do the 'exit' in global scope. Or even the PM's inherit-implementation
> expects to be first called with arguments "eapi 4", and not reading the
> eapi.eclass at all, so the 'eapi.eclass' does not need to check for
> anything, just needs to 'exit' when inherited.

Ohw, the latter would be necessary here, or '4.ebuild' would not be
found.

eapi.eclass could also be renamed to sth. like eapisupport.eclass or
eapivalidation.eclass, to write this way:
EAPI="4"
inherit eapisupport
But then the eclass has to detect which EAPI's are supported by the
running PM to 'exit' upon an unsupported one.

Btw.: What do non-EAPI-aware PMs do with ebuilds using EAPI 1 and 2 -
how become they masked _now_? What did I miss here?

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs

[Michael Haubenwallner]

On Fri, 2009-05-29 at 10:42 +, Duncan wrote:
> Michael Haubenwallner  posted on  Fri, 29
> May 2009 10:14:46 +0200:
> 
> > Ohw, the latter would be necessary here, or '4.ebuild' would not be
> > found.
> 
> s/4.ebuild/4.eclass/ I assume.

Indeed.

> Except...  since an ebuild must presently be sourced to (properly) 
> determine EAPI, it still doesn't work for changes that break sourcing or 
> other pre-EAPI processing (like parsing PN and PVR out of the filename), 
> so the changes allowed with a simple EAPI change are still rather limited.

As long as the *whole* ebuild content (including the filename) needs to
be successfully interpreted just for EAPI detection, we will have to
change the extension or wait the extended period for each incompatible
EAPI change. So this full interpretation for EAPI detection doesn't feel
like a good way to go at all.

> That's why the change to GLEP55 or alternative, whether in-filename or
> in-file-itself, will again require either an extended wait after 
> introduction (the old way) or at minimum, a one-time change to extension 
> such that old PM versions don't even see the currently EAPI incompatible 
> changes.

Wouldn't it be possible to avoid both the extension change and another
extended wait period for new incompatible(*) EAPIs, when we do this
early and silent exit hack for unsupported ebuilds with old PMs that
still do full interpretation for EAPI detection?

And after another extended wait period(**), we can start dropping the
silent exit hack, so we finally have switched to EAPI detection without
full interpretation, but still have the .ebuild extension.

(*) The incompatibility of EAPIs must not begin (meaning the bytewise
ebuild content) before the end of both the ebuild's EAPI value
definition and the silent exit hack.
But this IMO is an acceptable compromise.

(**) After this wait period, the incompatibility of EAPIs can start
after the end of the ebuild's EAPI value definition.

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] A new glep: Ebuild format and metadata handling

[Michael Haubenwallner]

On Sun, 2009-05-31 at 15:56 +0200, Patrick Lauer wrote:

Thank you for collecting this up!

> parsers: The current practise of putting the eapi definition near the top of
> the ebuild, combined with the need to state it for all non-EAPI0 ebuilds,
> suggests that it can be parsed without having to source the ebuild.

Would it improve parsers' performance to explicitly define EAPI="0" in
EAPI0 ebuilds too, so it always can find an EAPI value?

> "haubi"
> He proposes to use an eapi.eclass and define eapi as a function.

Erm, unlike earlier I did not propose eapi as a function this time.

Instead, my proposal is identical to the "parsers" one, but with a
backwards compatible syntax for defining the EAPI value that allows to
have non-parsing PMs (nearly) silently ignore the ebuild, so we do not
have to wait another extended period (=year) to put "parsed" EAPI values
in the tree after a "parsing" PM became stable.

This backwards compatibility syntax is done with the eapi.eclass, which
does nothing but early exit when inherit'ed by an old (=non-parsing) PM.

It is up to the "parsing" PM (the PMS) if 'eapi.eclass' actually gets
read in, as the implementation of 'inherit' is part of the PM and has to
detect "eapi" as special argument anyway, otherways it would fail to
find "4.eclass" when used this way:
>inherit eapi 4

But I can also think of this syntax:
  EAPI="4"# parsers read this line only
  inherit eapi# compat for non-parsing PM only

Here the 'inherit eapi' line can be dropped as soon as we do not need to
support non-parsing PMs any more. However, parsing PMs either need to
ignore "eapi" as argument to 'inherit', or need to inform eapi.eclass
somehow that the EAPI was parsed already.
There might be a better name than 'eapi.eclass' here. With
'eapicompat.eclass' fex this would read:
   EAPI="4"
   inherit eapicompat

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] GLEP 55 Version 2

[Michael Haubenwallner]

On Sat, 2009-06-06 at 23:31 +0100, Roy Bamford wrote:

> I've spent some time reading all of this years emails on GLEP55 and 
> added a few lines to version 1.5 which is the last offical version.

Is there a specific reason not to include the "inherit eapi"[1][2]
thing?

IMHO this would fit best in "Abstract Solution (Part 1)" somehow like:

-There are two potential solutions to this part of the problem,
+There are three potential solutions to this part of the
problem,

* wait for old package managers to fall into disuse
* 'blind' old package managers to ebuilds using later
constructs
+   * use "inherit" to have old package managers almost silently
+ ignore unsupported ebuilds

[1] 
http://archives.gentoo.org/gentoo-dev/msg_b2656aca1d124658b3df73d3d6804b7e.xml
[2] 
http://archives.gentoo.org/gentoo-dev/msg_348f84690f03e597fb14d6602337c45f.xml

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Packages maintained by mduft need a co-maintainer

[Michael Haubenwallner]

On 04/14/2012 01:30 PM, Pacho Ramos wrote:
> Due long devaway, his packages need a co-maintainer, feel free to add to
> metadata if you want. Thanks:
> app-portage/prefix-chain-setup
> sys-apps/prefix-chain-utils

Even if prefix-chaining most likely is broken ATM in prefix-portage,
(IMO) they still belong to prefix herd. Why have they shown up at all?

> sys-libs/suacomp
> sys-devel/parity
> sys-libs/itx-bind

Added myself, target Interix/Windows only.
Not sure if we can/want/should take them to prefix herd.

> net-proxy/cntlm

Still open.

/haubi/

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Michael Haubenwallner]

On 04/27/12 00:03, Andreas K. Huettel wrote:

 as soon as possible (which likely means in the next EAPI?):

* two new files in profile directories supported, package.use.stable.mask and
package.use.stable.force
* syntax is identical to package.use.mask and package.use.force
* meaning is identical to package.use.mask and package.use.force, except that
the resulting rules are ONLY applied iff a stable keyword is in use


Wouldn't it be more obvious/simple to have an extra profile subdirectory
containing package.use.mask and package.use.force?

Maybe in combination with 'eselect profile' to be able to select multiple
profiles [1], selecting both what /etc/make.profile pointed to as symlink
as well as some /usr/portage/profile/unstable/$arch - to avoid the need
for having an extra unstable/ subdir within each (selectable) profile dir.

Actually, I do have an extra unstable/ subdir for each selectable profile
here, besides an extra buildbot/ subdir too...

As a side effect, this wouldn't affect EAPI in any way.

[1] 
http://archives.gentoo.org/gentoo-dev/msg_a69bee8bfa00146ee05e49adf722e791.xml

my .02
/haubi/
--
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] Re: [PATCH 1/4] profiles/prefix: Add arch/base to parent

[Michael Haubenwallner]

On 02/13/2017 03:40 PM, Michał Górny wrote:
> ---
>  profiles/prefix/parent | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/profiles/prefix/parent b/profiles/prefix/parent
> index 8f0e9fd7471d..3eaf2c441360 100644
> --- a/profiles/prefix/parent
> +++ b/profiles/prefix/parent
> @@ -1 +1,2 @@
> +../arch/base
>  ../features/prefix/rpath
> 

This causes duplicate inheritance of arch/base for prefix/linux/* profiles,
as they get arch/base via default/linux/* anyway.

Fixed in
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3bf75385caac73e1ffb7035b37add91ef57583fe

/haubi/

[gentoo-dev] profiles/arch/amd64/no-multilib cleanup WAS: [PATCH 1/8] profiles/hardened: Include base amd64-multilib profile in subprofile

[Michael Haubenwallner]

On 01/21/2017 11:59 PM, Michał Górny wrote:
> Include arch/amd64/no-multilib in the hardened no-multilib amd64
> variant. Confirmed with profile-dumper that it does not currently change
> anything.
> ---
>  profiles/hardened/linux/amd64/no-multilib/parent | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/profiles/hardened/linux/amd64/no-multilib/parent 
> b/profiles/hardened/linux/amd64/no-multilib/parent
> index 8305c3556463..0defac31415d 100644
> --- a/profiles/hardened/linux/amd64/no-multilib/parent
> +++ b/profiles/hardened/linux/amd64/no-multilib/parent
> @@ -1,2 +1,3 @@
> +../../../../arch/amd64/no-multilib
>  ..
> 

As hardened/linux/amd64 does inherit arch/amd64, this way arch/amd64
always overrides arch/amd64/no-multilib, rendering the latter useless.

Instead, profiles/hardened/linux/amd64/no-multilib/parent should read:
 ..
 ../../../../arch/amd64/no-multilib

Beyond that:
While arch/amd64/no-multilib of course _is_ an override to arch/amd64,
question is whether it also should _perform_ the override by itself.

Currently it does perform the override, causing lots of subsequent profiles
to end up with arch/amd64 inherited multiple times - most prominent is the
default/linux/amd64/13.0/no-multilib profile.

So removing arch/amd64/no-multilib/parent would simplify things here.

Thoughts?
/haubi/
From 9457fd8eb330a94a15bb91decec522fe1c027986 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Thu, 2 Mar 2017 13:52:58 +0100
Subject: [PATCH] profiles/hardened/linux/amd64/no-multilib: inherit
 arch/amd64/no-multilib late

Whether  arch/amd64/no-multilib  does _inherit_  arch/amd64
or not,  arch/amd64/no-multilib  does _extend_   arch/amd64 anyway.

So inheriting  arch/amd64/no-multilib  before  arch/amd64  always will
reset the  arch/amd64/no-multilib  to the  arch/amd64  values.
---
 profiles/hardened/linux/amd64/no-multilib/parent | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/profiles/hardened/linux/amd64/no-multilib/parent 
b/profiles/hardened/linux/amd64/no-multilib/parent
index 2909df6..9bf59c5 100644
--- a/profiles/hardened/linux/amd64/no-multilib/parent
+++ b/profiles/hardened/linux/amd64/no-multilib/parent
@@ -1,2 +1,2 @@
-../../../../arch/amd64/no-multilib
 ..
+../../../../arch/amd64/no-multilib
-- 
2.10.2

From 3f8eb7869937d6da2f79b0a6eeb448f6eedea7b3 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Thu, 2 Mar 2017 14:45:16 +0100
Subject: [PATCH] profiles/arch/amd64/no-multilib: do not inherit arch/amd64

While arch/amd64/no-multilib of course _is_ an override to arch/amd64,
is should not _perform_ the override by itself, as that causes lots of
subsequent profiles to end up with arch/amd64 inherited multiple times,
most prominent is the default/linux/amd64/13.0/no-multilib profile.
---
 profiles/arch/amd64/no-multilib/parent | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 profiles/arch/amd64/no-multilib/parent

diff --git a/profiles/arch/amd64/no-multilib/parent 
b/profiles/arch/amd64/no-multilib/parent
deleted file mode 100644
index f3229c5..
--- a/profiles/arch/amd64/no-multilib/parent
+++ /dev/null
@@ -1 +0,0 @@
-..
-- 
2.10.2

[gentoo-dev] Re: Integrating Ada into toolchain.eclass, again

[Michael Haubenwallner]

Hi Luke,

On 05/19/2017 09:08 PM, Luke A. Guest wrote:
> Hi,
> 
> I posted a bug back in August,
> https://bugs.gentoo.org/show_bug.cgi?id=592060, to discuss adding Ada
> support into Gentoo's toolchain.eclass.

> Thoughts?

Did you have a look at https://bugs.gentoo.org/show_bug.cgi?id=592060 ?

I had been almost there, but then I stopped because George seemed to return
(turned out as retirement), and my only need for Ada is to bootstrap gcc-trunk
sometimes (not since then). Beyond that: I'm lacking basic Ada knowledge to
correctly finalize the missing bits, but I'm wondering why my patch still is
larger than yours.

HTH,
/haubi/

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

[Michael Haubenwallner]

On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
> On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote:
>> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
>>  wrote:
>>> arfrever suggests I send a mail here, as there are other packages which
>>> may be affected by this issue and perhaps a more generalized fix is
>>> required instead of an explicit fix in sys-libs/ncurses and other ebuilds
>>> that may require it.
>>
>> I think the solution here is to remove those overly broad "find
>> -delete" statements and replace them with something safer.
>>
>> Ideally the build system(s) would be patched to not compile static
>> libs in the first place.
>>
>> If that's not possible, perhaps an eclass function could be created to
>> safely remove static libs.
>>
> Honestly I already have a pr up that fixes this particular package's
> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
> 
> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> @@ -241,7 +241,8 @@ multilib_src_install() {
>   # Provide a link for -lcurses.
>   ln -sf libncurses$(get_libname) 
> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
>   fi
> - use static-libs || find "${ED}"/usr/ -name '*.a' -delete
> + # don't delete '*.dll.a', needed for linking #631468
> + use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a' 
> -delete

In prefix overlay we have this version:

  use static-libs || find "${ED}"/usr/ -name '*.a' -not -name "*$(get_libname)" 
-delete

/haubi/

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

[Michael Haubenwallner]

On 09/29/2017 10:33 AM, Marty E. Plummer wrote:
> On Fri, Sep 29, 2017 at 08:29:07AM +0000, Michael Haubenwallner wrote:
>> On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
>>> On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote:
>>>> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
>>>>  wrote:
>>>>> arfrever suggests I send a mail here, as there are other packages which
>>>>> may be affected by this issue and perhaps a more generalized fix is
>>>>> required instead of an explicit fix in sys-libs/ncurses and other ebuilds
>>>>> that may require it.
>>>>
>>>> I think the solution here is to remove those overly broad "find
>>>> -delete" statements and replace them with something safer.
>>>>
>>>> Ideally the build system(s) would be patched to not compile static
>>>> libs in the first place.
>>>>
>>>> If that's not possible, perhaps an eclass function could be created to
>>>> safely remove static libs.
>>>>
>>> Honestly I already have a pr up that fixes this particular package's
>>> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
>>>
>>> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>> @@ -241,7 +241,8 @@ multilib_src_install() {
>>> # Provide a link for -lcurses.
>>> ln -sf libncurses$(get_libname) 
>>> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
>>> fi
>>> -   use static-libs || find "${ED}"/usr/ -name '*.a' -delete
>>> +   # don't delete '*.dll.a', needed for linking #631468
>>> +   use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a' 
>>> -delete
>>
>> In prefix overlay we have this version:
>>
>>   use static-libs || find "${ED}"/usr/ -name '*.a' -not -name 
>> "*$(get_libname)" -delete
>>
> Won't work here, as $(get_libname) returns .dll in this case, which is
> why the symlinking is busted

Indeed! Although I do believe get_libname should return the (dynamically) 
linkable file
name rather than the dynamically loadable one, because a build system's target 
often is
the dynamically linkable file, creating the loadable as side effect. Note that 
only COFF
based systems (AIX, Windows) may distinguish (dynamically) linkable and 
loadable files.

Additionally (although unused in Prefix), AIX allows for one single file libN.a 
containing
Shared Objects, which can be statically linked too!

And for winnt I've yet to decide the value for $(get_libname) as the Import 
Library:
Candidates are ".so", ".dll.a", ".dll.lib" - as I do support all of them in the 
msvc
wrapper ("parity") to reduce the need of patching various build systems for 
now...

So probably the real safe one here is (in case get_libname may return ".a"):

  use static-libs || find "${ED}"/usr/ -name '*.a' -not -name '*.dll.a' -not 
-name "*$(get_libname)" -delete

OR: Really have some function prune_static_libs to remove library files serving 
as
Static Library only - neither as Import Library nor Shared Library: Implemented
for some platforms to ignore the file name but inspect the content instead.

Remember: This is (related but) different from prune_libtool_libs,
which suggests the find "${D}" -name '*.la' -delete alternative only.

/haubi/

[gentoo-dev] Re: Open Build Service

[Michael Haubenwallner]

Hi,

another two cents:

On 11/10/2017 12:03 AM, Samuel Bernardo wrote:
> Hi,
> 
> I send this email to know the devs opinion about Gentoo integration with
> Open Build Service[1].
> 
> When creating specialized images and using an automated process for
> testing before deployment, I think that Open Build Service would be
> useful. It already support all major binary based distros and I think
> that Gentoo could be in there also.

Well, Gentoo is a Meta Distribution, and it's binary instantiation usually
does emerge on the users machine(s). So users actually do have their private
binary distribution - either with or without caching the binary packages.
(In my opinion, a binary distribution is little more than a cache for binary
packages, to avoid the need for compilation resources on the target machine.)

Of course there is chance that users do have identical profile setups (USE 
flags,
optimization flags, etc.), which is where OBS (or similar) indeed feels useful.

Rather than sharing binary packages, an idea is to share Gentoo user's profile
setups - with the cache for binary packages to be optional (yet powered by some
open build service). Note that some USE flags disallow binary packaging at all.

Wouldn't we gain something like a "Social Linux Distribution Network" then?

/haubi/

[gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

[Michael Haubenwallner]

Hi,

HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining"
portage patch I've carried in prefix-overlay all the time, thank you for that!

However, a first thing being unclear already came up when bumping EAPI 6 to 7:

For example, the current app-misc/ca-certificates ebuild (EAPI 6) contains:

 # c_rehash: we run `c_rehash`
 # debianutils: we run `run-parts`
 RDEPEND="${DEPEND}
 app-misc/c_rehash
 sys-apps/debianutils"

 pkg_postinst() {
if [ -d "${EROOT}/usr/local/share/ca-certificates" ] ; then
# if the user has local certs, we need to rebuild again
# to include their stuff in the db.
# However it's too overzealous when the user has custom certs in place.
# --fresh is to clean up dangling symlinks
"${EROOT}"/usr/sbin/update-ca-certificates --root "${ROOT}"
fi
 }

Thing is, these RDEPENDs are not really required to "run" ca-certificates, but 
to
administrate it - which eventually is done on the CBUILD machine (from within 
the
ebuild, like in pkg_postinst currently), not necessarily on the CHOST machine.

So I do not necessarily want these RDEPENDs to be installed on the CHOST 
machine,
given that they may not be executed from within the CBUILD machine at all.

So the first idea is to move both RDEPENDs into BDEPEND.  But then, they are
not guaranteed to be available during pkg_postinst - like for a binary package.

Question now is: Is this wrong behaviour in the ebuild,
or is this something where EAPI 7 is still insufficient for?

When this is wrong (probably independent of EAPI 7 already) in the ebuild:
How can the ebuild get such a use case right, especially with EAPI 7?

Thanks!
/haubi/

Re: [gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

[Michael Haubenwallner]

On 05/31/2018 12:58 AM, Zac Medico wrote:
> On 05/30/2018 04:49 AM, Michael Haubenwallner wrote:
>> Hi,
>>
>> HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining"
>> portage patch I've carried in prefix-overlay all the time, thank you for 
>> that!
>>
>> However, a first thing being unclear already came up when bumping EAPI 6 to 
>> 7:
>>
>> For example, the current app-misc/ca-certificates ebuild (EAPI 6) contains:
>>
>>  # c_rehash: we run `c_rehash`
>>  # debianutils: we run `run-parts`
>>  RDEPEND="${DEPEND}
>>  app-misc/c_rehash
>>  sys-apps/debianutils"
>>
>>  pkg_postinst() {
>> if [ -d "${EROOT}/usr/local/share/ca-certificates" ] ; then
>> # if the user has local certs, we need to rebuild again
>> # to include their stuff in the db.
>> # However it's too overzealous when the user has custom certs in 
>> place.
>> # --fresh is to clean up dangling symlinks
>> "${EROOT}"/usr/sbin/update-ca-certificates --root "${ROOT}"
>> fi
>>  }
>>
>> Thing is, these RDEPENDs are not really required to "run" ca-certificates, 
>> but to
>> administrate it - which eventually is done on the CBUILD machine (from 
>> within the
>> ebuild, like in pkg_postinst currently), not necessarily on the CHOST 
>> machine.
>>
>> So I do not necessarily want these RDEPENDs to be installed on the CHOST 
>> machine,
>> given that they may not be executed from within the CBUILD machine at all.
>>
>> So the first idea is to move both RDEPENDs into BDEPEND.  But then, they are
>> not guaranteed to be available during pkg_postinst - like for a binary 
>> package.
> 
> Right, so it really belongs in RDEPEND *and* BDEPEND.

RDEPEND doesn't feel correct - see below.

> 
>> Question now is: Is this wrong behaviour in the ebuild,
>> or is this something where EAPI 7 is still insufficient for?
> 
> If we want to tune the dependencies more finely, we'll need new EAPI.

Probably - with explicit "dependencies for merge and configuration phases"?
For consistency with DEPEND+RDEPEND, I can imagine BDEPEND+*BRDEPEND*.

> 
>> When this is wrong (probably independent of EAPI 7 already) in the ebuild:
>> How can the ebuild get such a use case right, especially with EAPI 7?
> 
> What's wrong with putting it in both?

In RDEPEND, they are provided as CHOST binaries (in EROOT), but they are
executed on the CBUILD machine during merge and configuration phases.

In BDEPEND, they are not guaranteed to be available with binary packages.

For a workaround (in another prefix-chaining portage patch), it might work to
guarantee BDEPEND be available even for merge and configuration phases, no?

-- 
Thanks!
/haubi/



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: EAPI 7, BDEPEND and pkg_*inst

[Michael Haubenwallner]

On 06/04/2018 01:40 PM, Michał Górny wrote:
> W dniu śro, 30.05.2018 o godzinie 13∶49 +0200, użytkownik Michael
> Haubenwallner napisał:
>> Hi,
>>
>> HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining"
>> portage patch I've carried in prefix-overlay all the time, thank you for 
>> that!
> 
> I'm sorry for not replying earlier.  I meant to, but I failed to mark
> the mail and I've forgot about it.

This is what a (long) weekend is for: forget about it - at least for some time 
;)

>>
>> However, a first thing being unclear already came up when bumping EAPI 6 to 
>> 7:
>>
>> For example, the current app-misc/ca-certificates ebuild (EAPI 6) contains:
>>
>>  # c_rehash: we run `c_rehash`
>>  # debianutils: we run `run-parts`
>>  RDEPEND="${DEPEND}
>>  app-misc/c_rehash
>>  sys-apps/debianutils"
>>
>>  pkg_postinst() {
>> if [ -d "${EROOT}/usr/local/share/ca-certificates" ] ; then
>> # if the user has local certs, we need to rebuild again
>> # to include their stuff in the db.
>> # However it's too overzealous when the user has custom certs in 
>> place.
>> # --fresh is to clean up dangling symlinks
>> "${EROOT}"/usr/sbin/update-ca-certificates --root "${ROOT}"
>> fi
>>  }
>>
>> Thing is, these RDEPENDs are not really required to "run" ca-certificates, 
>> but to
>> administrate it - which eventually is done on the CBUILD machine (from 
>> within the
>> ebuild, like in pkg_postinst currently), not necessarily on the CHOST 
>> machine.
>>
>> So I do not necessarily want these RDEPENDs to be installed on the CHOST 
>> machine,
>> given that they may not be executed from within the CBUILD machine at all.
>>
>> So the first idea is to move both RDEPENDs into BDEPEND.  But then, they are
>> not guaranteed to be available during pkg_postinst - like for a binary 
>> package.
>>
>> Question now is: Is this wrong behaviour in the ebuild,
>> or is this something where EAPI 7 is still insufficient for?
> 
> It's a known deficiency discovered just a while too late to address it. 
> It comes from the fact that we never really had proper dependencies for
> pkg_*inst phases.  So far we've ignored the problem because our work-
> arounds were sufficient for our use cases but cross definitely needs
> something better.
> 
>> When this is wrong (probably independent of EAPI 7 already) in the ebuild:
>> How can the ebuild get such a use case right, especially with EAPI 7?
> 
> I think the 'closest' thing to right would be to use BDEPEND+RDEPEND. 
> It won't cover cross+binpkg but I guess it's as good as you can get.
> 

Having BDEPEND in RDEPEND will fix binpkg, but break cross again - which
BDEPEND aims to help firsthand (as far as I understood).

To get both binpkg and cross working, although not combined together,
what about something like this workaround:

EAPI=7
IUSE="+bindist"
BDEPEND="some-cbuild/tool"
RDEPEND="bindist? ( ${BDEPEND} )"

It should be easy for cross profiles to use.mask "bindist".

For cross (without binpkg), BDEPEND should still be around during pkg_*inst,
even if not specified per PMS.

-- 
/haubi/

[gentoo-dev] [PATCH 2/5] toolchain.eclass: D->ED for where to start cleanups

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index fe41a80db28..a51d8e84f5e 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1720,9 +1720,9 @@ toolchain_src_install() {
S="${WORKDIR}"/build emake -j1 DESTDIR="${D}" install || die
 
# Punt some tools which are really only useful while building gcc
-   find "${D}" -name install-tools -prune -type d -exec rm -rf "{}" \;
+   find "${ED}" -name install-tools -prune -type d -exec rm -rf "{}" \;
# This one comes with binutils
-   find "${D}" -name libiberty.a -delete
+   find "${ED}" -name libiberty.a -delete
 
# Move the libraries to the proper location
gcc_movelibs
@@ -1731,7 +1731,7 @@ toolchain_src_install() {
if ! is_crosscompile ; then
local EXEEXT
eval $(grep ^EXEEXT= "${WORKDIR}"/build/gcc/config.log)
-   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${D}"
+   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${ED}"
fi
 
dodir /etc/env.d/gcc
@@ -1810,7 +1810,7 @@ toolchain_src_install() {
|| prepman "${DATAPATH#${EPREFIX}}"
fi
# prune empty dirs left behind
-   find "${D}" -depth -type d -delete 2>/dev/null
+   find "${ED}" -depth -type d -delete 2>/dev/null
 
# install testsuite results
if use regression-test; then
@@ -1966,7 +1966,7 @@ gcc_movelibs() {
for FROMDIR in ${removedirs} ; do
rmdir "${D}"${FROMDIR} >& /dev/null
done
-   find -depth "${D}" -type d -exec rmdir {} + >& /dev/null
+   find -depth "${ED}" -type d -exec rmdir {} + >& /dev/null
 }
 
 # make sure the libtool archives have libdir set to where they actually
-- 
2.16.1

[gentoo-dev] [PATCH 0/5] toolchain.eclass: Prefix patches, Cygwin related

[Michael Haubenwallner]

Hi,

please review these patches we have in prefix-overlay,
where patches 3-5 are for Gentoo Prefix on Cygwin.

Thanks!
/haubi/

[gentoo-dev] [PATCH 1/5] toolchain.eclass: ROOT->EROOT at looking for gcc specs file

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 68e4ce15b37..fe41a80db28 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -2207,7 +2207,7 @@ do_gcc_config() {
[[ -n ${current_specs} ]] && use_specs=-${current_specs}
 
if [[ -n ${use_specs} ]] && \
-  [[ ! -e 
${ROOT}/etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
+  [[ ! -e 
${EROOT}etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
then
ewarn "The currently selected specs-specific gcc 
config,"
ewarn "${current_specs}, doesn't exist anymore. This is 
usually"
-- 
2.16.1

[gentoo-dev] [PATCH 3/5] toolchain.eclass: avoid leading double slash

[Michael Haubenwallner]

Path starting with "//" is a Network path for Cygwin:
As DATAPATH starts with EPREFIX, we have to use it with ${ROOT%/}.
---
 eclass/toolchain.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a51d8e84f5e..bc3a80e0e8a 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -2133,12 +2133,12 @@ toolchain_pkg_postinst() {
 
mkdir -p "${EROOT}"usr/{share/gcc-data,sbin,bin}
# DATAPATH has EPREFIX already, use ROOT with it
-   cp "${ROOT}${DATAPATH}"/fixlafiles.awk 
"${EROOT}"usr/share/gcc-data/ || die
-   cp "${ROOT}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT}"usr/sbin/ || die
+   cp "${ROOT%/}${DATAPATH}"/fixlafiles.awk 
"${EROOT}"usr/share/gcc-data/ || die
+   cp "${ROOT%/}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT}"usr/sbin/ || die
 
# Since these aren't critical files and portage sucks with
# handling of binpkgs, don't require these to be found
-   cp "${ROOT}${DATAPATH}"/c{89,99} "${EROOT}"usr/bin/ 2>/dev/null
+   cp "${ROOT%/}${DATAPATH}"/c{89,99} "${EROOT}"usr/bin/ 
2>/dev/null
fi
 
if use regression-test ; then
-- 
2.16.1

[gentoo-dev] [PATCH 4/5] toolchain.eclass: Cygwin provides posix threads

[Michael Haubenwallner]

Upstream Cygwin does build their gcc with posix threads for ages,
at least since gcc4-4.5.1-1.cygport (committed on Oct 3, 2010).
---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index bc3a80e0e8a..faf96d2a41f 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1034,7 +1034,7 @@ toolchain_src_configure() {
confgcc+=( --enable-shared )
fi
case ${CHOST} in
-   mingw*|*-mingw*|*-cygwin)
+   mingw*|*-mingw*)
confgcc+=( --enable-threads=win32 ) ;;
*)
confgcc+=( --enable-threads=posix ) ;;
-- 
2.16.1

[gentoo-dev] [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

Download and apply patches found in Cygwin's gcc.cygport, maintained at
github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
---
 eclass/toolchain.eclass | 28 
 1 file changed, 28 insertions(+)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index faf96d2a41f..a16bfadc301 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -309,6 +309,14 @@ gentoo_urls() {
 #  ten Brugge's bounds-checking patches. If you want to 
use a patch
 #  for an older gcc version with a new gcc, make sure you 
set
 #  HTB_GCC_VER to that version of gcc.
+#
+#  CYGWINPORTS_GITREV
+#  If set, this variable signals that we should apply 
additional patches
+#  maintained by upstream Cygwin developers at 
github/cygwinports/gcc,
+#  using the specified git commit id there.  The list of 
patches to
+#  apply is extracted from gcc.cygport, maintained there 
as well.
+#  This is done for compilers running on Cygwin, not for 
cross compilers
+#  with a Cygwin target.
 get_gcc_src_uri() {
export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
@@ -375,6 +383,10 @@ get_gcc_src_uri() {
fi
fi
 
+   # Cygwin patches from https://github.com/cygwinports/gcc
+   [[ -n ${CYGWINPORTS_GITREV} ]] && \
+   GCC_SRC_URI+=" elibc_Cygwin? ( 
https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.zip )"
+
echo "${GCC_SRC_URI}"
 }
 
@@ -481,6 +493,8 @@ gcc_quick_unpack() {
 
use_if_iuse boundschecking && unpack 
"bounds-checking-gcc-${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
 
+   [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
"${CYGWINPORTS_GITREV}.zip"
+
popd > /dev/null
 }
 
@@ -505,6 +519,7 @@ toolchain_src_prepare() {
fi
do_gcc_HTB_patches
do_gcc_PIE_patches
+   do_gcc_CYGWINPORTS_patches
epatch_user
 
if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
vanilla ; then
@@ -645,6 +660,19 @@ do_gcc_PIE_patches() {
BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
 }
 
+do_gcc_CYGWINPORTS_patches() {
+   [[ -n ${CYGWINPORTS_GITREV} ]] || return 0
+   use elibc_Cygwin || return 0
+
+   local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
+   for p in $(
+   eval "$(sed -ne '/PATCH_URI="/,/"/p' < "${d}"/gcc.cygport)"
+   echo ${PATCH_URI}
+   ); do
+   epatch "${d}/${p}"
+   done
+}
+
 # configure to build with the hardened GCC specs as the default
 make_gcc_hard() {
 
-- 
2.16.1

[gentoo-dev] Re: [PATCH 3/5] toolchain.eclass: avoid leading double slash

[Michael Haubenwallner]

On 06/21/2018 12:40 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 20 Jun 2018, Michael Haubenwallner wrote:
> 
>> Path starting with "//" is a Network path for Cygwin:
>> As DATAPATH starts with EPREFIX, we have to use it with ${ROOT%/}.
>> ---
>>  eclass/toolchain.eclass | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
>> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
>> index a51d8e84f5e..bc3a80e0e8a 100644
>> --- a/eclass/toolchain.eclass
>> +++ b/eclass/toolchain.eclass
>> @@ -2133,12 +2133,12 @@ toolchain_pkg_postinst() {
>  
>>  mkdir -p "${EROOT}"usr/{share/gcc-data,sbin,bin}
>>  # DATAPATH has EPREFIX already, use ROOT with it
>> -cp "${ROOT}${DATAPATH}"/fixlafiles.awk 
>> "${EROOT}"usr/share/gcc-data/ || die
>> -cp "${ROOT}${DATAPATH}"/fix_libtool_files.sh 
>> "${EROOT}"usr/sbin/ || die
>> +cp "${ROOT%/}${DATAPATH}"/fixlafiles.awk 
>> "${EROOT}"usr/share/gcc-data/ || die
>> +cp "${ROOT%/}${DATAPATH}"/fix_libtool_files.sh 
>> "${EROOT}"usr/sbin/ || die
> 
> Looks a bit short-sighted for the destinations, since EROOT lost its
> trailing slash in EAPI 7. So better use "${EROOT%/}/" there too.

Well, DATAPATH already has the leading slash, and I have to avoid double slash 
here.

/haubi/

[gentoo-dev] Re: [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

On 06/20/2018 09:56 PM, Michał Górny wrote:
> W dniu śro, 20.06.2018 o godzinie 19∶49 +0200, użytkownik Michael
> Haubenwallner napisał:
>> Download and apply patches found in Cygwin's gcc.cygport, maintained
>> at
>> github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
>> can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
>> ---
>>  eclass/toolchain.eclass | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
>> index faf96d2a41f..a16bfadc301 100644
>> --- a/eclass/toolchain.eclass
>> +++ b/eclass/toolchain.eclass
>> @@ -309,6 +309,14 @@ gentoo_urls() {
>>  #   ten Brugge's bounds-checking patches. If
>> you want to use a patch
>>  #   for an older gcc version with a new gcc,
>> make sure you set
>>  #   HTB_GCC_VER to that version of gcc.
>> +#
>> +#   CYGWINPORTS_GITREV
>> +#   If set, this variable signals that we
>> should apply additional patches
>> +#   maintained by upstream Cygwin developers at
>> github/cygwinports/gcc,
>> +#   using the specified git commit id
>> there.  The list of patches to
>> +#   apply is extracted from gcc.cygport,
>> maintained there as well.
>> +#   This is done for compilers running on
>> Cygwin, not for cross compilers
>> +#   with a Cygwin target.
>>  get_gcc_src_uri() {
>>  export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
>>  export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
>> @@ -375,6 +383,10 @@ get_gcc_src_uri() {
>>  fi
>>  fi
>>  
>> +# Cygwin patches from https://github.com/cygwinports/gcc
>> +[[ -n ${CYGWINPORTS_GITREV} ]] && \
>> +GCC_SRC_URI+=" elibc_Cygwin? (
>> https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.zip
>> )"
> 
> Why not .tar.gz?

Didn't know .tar.gz works - the webpage provides [Download ZIP] only, thanks!

> 
>> +
>>  echo "${GCC_SRC_URI}"
>>  }
>>  
>> @@ -481,6 +493,8 @@ gcc_quick_unpack() {
>>  
>>  use_if_iuse boundschecking && unpack "bounds-checking-gcc-
>> ${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
>>  
>> +[[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack
>> "${CYGWINPORTS_GITREV}.zip"
>> +
>>  popd > /dev/null
>>  }
>>  
>> @@ -505,6 +519,7 @@ toolchain_src_prepare() {
>>  fi
>>  do_gcc_HTB_patches
>>  do_gcc_PIE_patches
>> +do_gcc_CYGWINPORTS_patches
>>  epatch_user
>>  
>>  if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened )
>> && ! use vanilla ; then
>> @@ -645,6 +660,19 @@ do_gcc_PIE_patches() {
>>  BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-
>> ${PIE_VER}"
>>  }
>>  
>> +do_gcc_CYGWINPORTS_patches() {
>> +[[ -n ${CYGWINPORTS_GITREV} ]] || return 0
>> +use elibc_Cygwin || return 0
>> +
>> +local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
>> +for p in $(
>> +eval "$(sed -ne '/PATCH_URI="/,/"/p' <
>> "${d}"/gcc.cygport)"
> 
> The eval here is completely unnecessary, and can easily wreak havoc. 
> Don't do that.

Erm - multiline commands from $() seem to fail without eval:

# sed -ne '/PATCH_URI="/,/"/p' < ./gcc.cygport
PATCH_URI="
0001-share-mingw-fset-stack-executable-with-cygwin.patch
...
"

# $(sed -ne '/PATCH_URI="/,/"/p' < ./gcc.cygport)
-bash: PATCH_URI=": command not found

# eval "$(sed -ne '/PATCH_URI="/,/"/p' < ./gcc.cygport)"

# declare -p PATCH_URI
declare -- PATCH_URI="
0001-share-mingw-fset-stack-executable-with-cygwin.patch
...
"

/haubi/

[gentoo-dev] Re: [PATCH 0/5] toolchain.eclass: Prefix patches, Cygwin related

[Michael Haubenwallner]

On 06/20/2018 07:49 PM, Michael Haubenwallner wrote:
> Hi,
> 
> please review these patches we have in prefix-overlay,
> where patches 3-5 are for Gentoo Prefix on Cygwin.

Thanks for the reviews, will reorder to account for EAPI 7 paths first.

One minor thing still unclear to me, beyond no _leading_ double slash:
Do we try hard to avoid redundant slashes _in between_ too?

Thoughts behind this question:
Beyond the eventual trailing slash, the {,E,SYS,ESYS,B}ROOT variables
may be empty, so Cygwin really requires the ${%/} modifier for them
to not end up with a network location by accident (in EAPI before 7).

But D,ED are not expected to be empty, and the ${%/} modifier will avoid
an extra slash _in between_ only, not a leading one.

So with D,ED the ${%/} modifier feels needless, reducing readability only.

Just wondering if we have some guidance here,
/haubi/

[gentoo-dev] [PATCH 0/5]-r1 toolchain.eclass: Prefix patches, Cygwin related

[Michael Haubenwallner]

Hi,

now reordered for EAPI 7 first.

Also, the downloaded cygwindist patches file now is renamed to
gcc-cygwindist-.tar.gz rather than just .tar.gz.

Thanks for the reviews,
/haubi/

[gentoo-dev] [PATCH 1/5] toolchain.eclass: EAPI 7 aware for D,ED,ROOT,EROOT

[Michael Haubenwallner]

These variables may or may not have the trailing slash. Additionally,
avoid leading double slash (a network location for Cygwin) with ROOT and
EROOT because they may be empty, while D and ED never should be empty
and there is no reason so far to avoid double slashes in between.
On the other hand, eclass variables like DATAPATH and LIBPATH do contain
the leading slash, so an extra slash reduces readability for no reason.
---
 eclass/toolchain.eclass | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 68e4ce15b37..3916555cb21 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1793,13 +1793,13 @@ toolchain_src_install() {
 
cd "${S}"
if is_crosscompile; then
-   rm -rf "${ED}"usr/share/{man,info}
+   rm -rf "${ED}"/usr/share/{man,info}
rm -rf "${D}"${DATAPATH}/{man,info}
else
if tc_version_is_at_least 3.0 ; then
local cxx_mandir=$(find 
"${WORKDIR}/build/${CTARGET}/libstdc++-v3" -name man)
if [[ -d ${cxx_mandir} ]] ; then
-   cp -r "${cxx_mandir}"/man? 
"${D}/${DATAPATH}"/man/
+   cp -r "${cxx_mandir}"/man? 
"${D}${DATAPATH}"/man/
fi
fi
has noinfo ${FEATURES} \
@@ -1850,7 +1850,7 @@ toolchain_src_install() {
# libvtv.la: gcc itself handles linkage correctly.
# lib*san.la: Sanitizer linkage is handled internally by gcc, and they
# do not support static linking. #487550 #546700
-   find "${D}/${LIBPATH}" \
+   find "${D}${LIBPATH}" \
'(' \
-name libstdc++.la -o \
-name libstdc++fs.la -o \
@@ -1916,7 +1916,7 @@ gcc_movelibs() {
# code to run on the target.
if tc_version_is_at_least 5 && is_crosscompile ; then
dodir "${HOSTLIBPATH#${EPREFIX}}"
-   mv "${ED}"usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die
+   mv "${ED}"/usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die
fi
 
# For all the libs that are built for CTARGET, move them into the
@@ -2113,7 +2113,7 @@ gcc_slot_java() {
 
 toolchain_pkg_postinst() {
do_gcc_config
-   if [[ ${ROOT} == / && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
+   if [[ ! ${ROOT%/} && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
eselect compiler-shadow update all
fi
 
@@ -2128,17 +2128,17 @@ toolchain_pkg_postinst() {
echo
 
# Clean up old paths
-   rm -f "${EROOT}"*/rcscripts/awk/fixlafiles.awk 
"${EROOT}"sbin/fix_libtool_files.sh
-   rmdir "${EROOT}"*/rcscripts{/awk,} 2>/dev/null
+   rm -f "${EROOT%/}"/*/rcscripts/awk/fixlafiles.awk 
"${EROOT%/}"/sbin/fix_libtool_files.sh
+   rmdir "${EROOT%/}"/*/rcscripts{/awk,} 2>/dev/null
 
-   mkdir -p "${EROOT}"usr/{share/gcc-data,sbin,bin}
+   mkdir -p "${EROOT%/}"/usr/{share/gcc-data,sbin,bin}
# DATAPATH has EPREFIX already, use ROOT with it
-   cp "${ROOT}${DATAPATH}"/fixlafiles.awk 
"${EROOT}"usr/share/gcc-data/ || die
-   cp "${ROOT}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT}"usr/sbin/ || die
+   cp "${ROOT%/}${DATAPATH}"/fixlafiles.awk 
"${EROOT%/}"/usr/share/gcc-data/ || die
+   cp "${ROOT%/}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT%/}"/usr/sbin/ || die
 
# Since these aren't critical files and portage sucks with
# handling of binpkgs, don't require these to be found
-   cp "${ROOT}${DATAPATH}"/c{89,99} "${EROOT}"usr/bin/ 2>/dev/null
+   cp "${ROOT%/}${DATAPATH}"/c{89,99} "${EROOT%/}"/usr/bin/ 
2>/dev/null
fi
 
if use regression-test ; then
@@ -2154,7 +2154,7 @@ toolchain_pkg_postinst() {
 }
 
 toolchain_pkg_postrm() {
-   if [[ ${ROOT} == / && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
+   if [[ ! ${ROOT%/} && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
eselect compiler-shadow clean all
fi
 
@@ -2165,16 +2165,16 @@ toolchain_pkg_postrm() {
 
# clean up the cruft left behind by cross-compilers
if is_crosscompile ; then
-   if [[ -z $(ls "${EROOT}"etc/env.d/gcc/${CTARGET}* 2>/dev/null) 
]] ; then
-   rm -f "${EROOT}"etc/env.d/gcc/config-${CTARGET}
-   rm -f "${EROOT}"etc/env.d/??gcc-${CTARGET}
-   rm -f "${EROOT}"usr/bin/${CTARGET}-{gcc,{g,c}++}{,32,64}
+   if [[ -z $(ls "${EROOT%/}"/etc/env.d/gcc/${CTARGET}* 
2>/dev/null) ]] ; then
+   rm -f "${EROOT%

[gentoo-dev] [PATCH 2/5] toolchain.eclass: ROOT->EROOT at looking for gcc specs file

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 3916555cb21..36c9f8e78fc 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -2207,7 +2207,7 @@ do_gcc_config() {
[[ -n ${current_specs} ]] && use_specs=-${current_specs}
 
if [[ -n ${use_specs} ]] && \
-  [[ ! -e 
${ROOT%/}/etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
+  [[ ! -e 
${EROOT%/}/etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
then
ewarn "The currently selected specs-specific gcc 
config,"
ewarn "${current_specs}, doesn't exist anymore. This is 
usually"
-- 
2.16.1

[gentoo-dev] [PATCH 3/5] toolchain.eclass: D->ED for where to start cleanups

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 36c9f8e78fc..4b94f78bfa9 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1720,9 +1720,9 @@ toolchain_src_install() {
S="${WORKDIR}"/build emake -j1 DESTDIR="${D}" install || die
 
# Punt some tools which are really only useful while building gcc
-   find "${D}" -name install-tools -prune -type d -exec rm -rf "{}" \;
+   find "${ED}" -name install-tools -prune -type d -exec rm -rf "{}" \;
# This one comes with binutils
-   find "${D}" -name libiberty.a -delete
+   find "${ED}" -name libiberty.a -delete
 
# Move the libraries to the proper location
gcc_movelibs
@@ -1731,7 +1731,7 @@ toolchain_src_install() {
if ! is_crosscompile ; then
local EXEEXT
eval $(grep ^EXEEXT= "${WORKDIR}"/build/gcc/config.log)
-   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${D}"
+   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${ED}"
fi
 
dodir /etc/env.d/gcc
@@ -1810,7 +1810,7 @@ toolchain_src_install() {
|| prepman "${DATAPATH#${EPREFIX}}"
fi
# prune empty dirs left behind
-   find "${D}" -depth -type d -delete 2>/dev/null
+   find "${ED}" -depth -type d -delete 2>/dev/null
 
# install testsuite results
if use regression-test; then
@@ -1966,7 +1966,7 @@ gcc_movelibs() {
for FROMDIR in ${removedirs} ; do
rmdir "${D}"${FROMDIR} >& /dev/null
done
-   find -depth "${D}" -type d -exec rmdir {} + >& /dev/null
+   find -depth "${ED}" -type d -exec rmdir {} + >& /dev/null
 }
 
 # make sure the libtool archives have libdir set to where they actually
-- 
2.16.1

[gentoo-dev] [PATCH 4/5] toolchain.eclass: Cygwin provides posix threads

[Michael Haubenwallner]

Upstream Cygwin does build their gcc with posix threads for ages,
at least since gcc4-4.5.1-1.cygport (committed on Oct 3, 2010).
---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 4b94f78bfa9..aa62010be6e 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1034,7 +1034,7 @@ toolchain_src_configure() {
confgcc+=( --enable-shared )
fi
case ${CHOST} in
-   mingw*|*-mingw*|*-cygwin)
+   mingw*|*-mingw*)
confgcc+=( --enable-threads=win32 ) ;;
*)
confgcc+=( --enable-threads=posix ) ;;
-- 
2.16.1

[gentoo-dev] [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

Download and apply patches found in Cygwin's gcc.cygport, maintained at
github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
---
 eclass/toolchain.eclass | 28 
 1 file changed, 28 insertions(+)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index aa62010be6e..22936175125 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -309,6 +309,14 @@ gentoo_urls() {
 #  ten Brugge's bounds-checking patches. If you want to 
use a patch
 #  for an older gcc version with a new gcc, make sure you 
set
 #  HTB_GCC_VER to that version of gcc.
+#
+#  CYGWINPORTS_GITREV
+#  If set, this variable signals that we should apply 
additional patches
+#  maintained by upstream Cygwin developers at 
github/cygwinports/gcc,
+#  using the specified git commit id there.  The list of 
patches to
+#  apply is extracted from gcc.cygport, maintained there 
as well.
+#  This is done for compilers running on Cygwin, not for 
cross compilers
+#  with a Cygwin target.
 get_gcc_src_uri() {
export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
@@ -375,6 +383,11 @@ get_gcc_src_uri() {
fi
fi
 
+   # Cygwin patches from https://github.com/cygwinports/gcc
+   [[ -n ${CYGWINPORTS_GITREV} ]] && \
+   GCC_SRC_URI+=" elibc_Cygwin? ( 
https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.tar.gz
+   -> gcc-cygwinports-${CYGWINPORTS_GITREV}.tar.gz )"
+
echo "${GCC_SRC_URI}"
 }
 
@@ -481,6 +494,8 @@ gcc_quick_unpack() {
 
use_if_iuse boundschecking && unpack 
"bounds-checking-gcc-${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
 
+   [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
"${CYGWINPORTS_GITREV}.tar.gz"
+
popd > /dev/null
 }
 
@@ -505,6 +520,7 @@ toolchain_src_prepare() {
fi
do_gcc_HTB_patches
do_gcc_PIE_patches
+   do_gcc_CYGWINPORTS_patches
epatch_user
 
if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
vanilla ; then
@@ -645,6 +661,18 @@ do_gcc_PIE_patches() {
BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
 }
 
+do_gcc_CYGWINPORTS_patches() {
+   [[ -n ${CYGWINPORTS_GITREV} ]] || return 0
+   use elibc_Cygwin || return 0
+
+   local -a patches
+   local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
+   readarray -t patches < <(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
"${d}"/gcc.cygport)
+   for p in ${patches[*]}; do
+   epatch "${d}/${p}"
+   done
+}
+
 # configure to build with the hardened GCC specs as the default
 make_gcc_hard() {
 
-- 
2.16.1

[gentoo-dev] Re: [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

On 06/22/2018 03:10 PM, Michael Haubenwallner wrote:
> Download and apply patches found in Cygwin's gcc.cygport, maintained at
> github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
> can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
> ---
>  eclass/toolchain.eclass | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index aa62010be6e..22936175125 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -309,6 +309,14 @@ gentoo_urls() {
>  #ten Brugge's bounds-checking patches. If you want to 
> use a patch
>  #for an older gcc version with a new gcc, make sure you 
> set
>  #HTB_GCC_VER to that version of gcc.
> +#
> +#CYGWINPORTS_GITREV
> +#If set, this variable signals that we should apply 
> additional patches
> +#maintained by upstream Cygwin developers at 
> github/cygwinports/gcc,
> +#using the specified git commit id there.  The list of 
> patches to
> +#apply is extracted from gcc.cygport, maintained there 
> as well.
> +#This is done for compilers running on Cygwin, not for 
> cross compilers
> +#with a Cygwin target.
>  get_gcc_src_uri() {
>   export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
>   export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
> @@ -375,6 +383,11 @@ get_gcc_src_uri() {
>   fi
>   fi
>  
> + # Cygwin patches from https://github.com/cygwinports/gcc
> + [[ -n ${CYGWINPORTS_GITREV} ]] && \
> + GCC_SRC_URI+=" elibc_Cygwin? ( 
> https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.tar.gz
> + -> gcc-cygwinports-${CYGWINPORTS_GITREV}.tar.gz )"
> +
>   echo "${GCC_SRC_URI}"
>  }
>  
> @@ -481,6 +494,8 @@ gcc_quick_unpack() {
>  
>   use_if_iuse boundschecking && unpack 
> "bounds-checking-gcc-${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
>  
> + [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
> "${CYGWINPORTS_GITREV}.tar.gz"

Of course this should read

+   [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
"gcc-cygwinports-${CYGWINPORTS_GITREV}.tar.gz"


> +
>   popd > /dev/null
>  }
>  
> @@ -505,6 +520,7 @@ toolchain_src_prepare() {
>   fi
>   do_gcc_HTB_patches
>   do_gcc_PIE_patches
> + do_gcc_CYGWINPORTS_patches
>   epatch_user
>  
>   if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
> vanilla ; then
> @@ -645,6 +661,18 @@ do_gcc_PIE_patches() {
>   BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
>  }
>  
> +do_gcc_CYGWINPORTS_patches() {
> + [[ -n ${CYGWINPORTS_GITREV} ]] || return 0
> + use elibc_Cygwin || return 0
> +
> + local -a patches
> + local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
> + readarray -t patches < <(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
> "${d}"/gcc.cygport)
> + for p in ${patches[*]}; do
> + epatch "${d}/${p}"
> + done
> +}
> +
>  # configure to build with the hardened GCC specs as the default
>  make_gcc_hard() {
>  
> 

[gentoo-dev] Re: RFC: new USE="win32" flag for mingw and prefix/windows support

[Michael Haubenwallner]

On 04/20/2016 09:01 PM, Anthony G. Basile wrote:
> On 4/20/16 2:17 PM, Mike Frysinger wrote:
>> On 20 Apr 2016 21:01, Alon Bar-Lev wrote:
>>> On 20 April 2016 at 18:52, Ian Stakenvicius wrote:

 Comments?
>>>
>>> You should be able to achieve similar behavior by looking at libc
>>> and/or CHOST without introducing new USE flag, just like we do for
>>> aix/solaris/freebsd etc...
>>
>> agreed ... we have kernel_Winnt & elibc_Winnt already.  i think
>> those represent a mingw environment (vs a cygwin env).

Nope: We have used kernel_Winnt and elibc_Winnt for the native MS
Visual Studio compiler, wrapped with Parity[1] to provide a gcc-like
commandline interface for the toolchain.  Independent of Parity I've
seen traces of native cl.exe/lib.exe support within libtool as well.

[1] https://github.com/haubi/parity

> The way I think of it is
> 
> the operating system (ie kernel) = kernel_Winnt
> the system libraries (=~libc)= elibc_Winnt
> the executable binary format = win32

Right now, for kernel_Winnt, in the prefix/windows profiles we have:

  + elibc_Interix
. runtime environment: Interix libc, CHOST=i586-pc-interixN.N
. python+bash+portage: yes
. accessible API (UI): POSIX (X11 client)
. executable format  : PE32 executable for MS Windows (POSIX) Intel 80386 
32-bit
. compiler: GNU gcc
. used as : build environment for elibc_Winnt: 
CBUILD=CHOST=i586-pc-winntN.N (non-cross)
. state   : dead, but in production here

  + elibc_Winnt (32bit only for now)
. runtime environment: MSVCRT, CHOST=i586-pc-winntN.N
. python+bash+portage: no
. accessible API (UI): Win32 (Win32)
. executable format  : PE32 executable for MS Windows ({console,GUI}) Intel 
80386 32-bit
. compiler: MSVC cl.exe (wrapped by Parity)
. used as : runtime environment for my company's application
. state   : old, in production here, to be updated

  + elibc_Cygwin
. runtime environment: newlib (Cygwin), CHOST={i686,x86_64}-pc-cygwin
. python+bash+portage: yes
. accessible API (UI): POSIX (X11 client), Win32 (Win32)
. executable format  : PE32 executable ({console,GUI}) Intel 80386, for MS 
Windows
   PE32+ executable ({console,GUI}) x86_64, for MS 
Windows
. compiler: GNU gcc
. used as : build environment for elibc_Winnt: CBUILD=CHOST=i586-pc-winnt 
(non-cross)
build environment for elibc_Mingw: 
CBUILD=CHOST={i686,x86_64}-w64-mingw32 (non-cross)
. state   : under construction, cygwin fork patch necessary (upstream 
review pending)


For MinGW, IMHO it feels more straightforward to add something like:

  + elibc_Mingw (mingw-w64.org I guess, not mingw.org)
. runtime environment: MinGW-W64, CHOST={i686,x86_64}-w64-mingw32
. python+bash+portage: no
. accessible API (UI): Win32 (Win32)
. executable format  : PE32 executable ({console,GUI}) Intel 80386, for MS 
Windows
   PE32+ executable ({console,GUI}) x86_64, for MS 
Windows
. compiler: GNU gcc
. used as : runtime environment for various applications
. state   : proposal

> I don't know that we need an executable binary format flag, but we might
> because they're working on windows 10 so it can natively run ELF.

Well, nope:
Although Windows Desktop (only, not Windows Server) can run ELF somewhat 
"natively",
it is not possible to start Windows executables from within a Linux executable.
This makes me assume there is no access to the Win32 API from within Linux 
either.
Also, they explicitly focus on the commandline only, not the GUI.

So WSL (Windows Subsystem for Linux) does not seem to be useable as replacement 
for
any of these currently possible non-crosscompiling setups:
  * Interix/Cygwin building Winnt (.exe runs natively)
  * Interix/Cygwin building Mingw (.exe runs natively)
  * Linux building Mingw (.exe runs in Wine)

For the USE flag:
As Cygwin allows for both X11 and Win32 UI, I do see fit for an additional 
"win32ui"
or similar (win32gui, w32ui, w32gui, winui, wingui, wntui, wntgui) USE flag.

And what about the new "win8ui" (formerly called Metro):
Do/will GTK+, Qt and others support that too eventually?

Probably we may end up with something like: IUSE="X aqua win32ui win8ui"

My 2*2 cents,
/haubi/

[gentoo-dev] Re: Empty project: ADA

[Michael Haubenwallner]

On 08/22/2016 05:58 PM, Pacho Ramos wrote:
> Now https://wiki.gentoo.org/wiki/Project:Ada is empty

While not using any Ada thing myself, occasionally I'm in need to fully
bootstrap upstream gcc, which requires C,C++,Ada compilers these days.

There's some basically accepted patches in [1] already: I've expected George
to be back and catch up here eventually - but stranded. I may not update and
commit them before I need to hack upstream gcc-trunk again...

[1] https://bugs.gentoo.org/547358

/haubi/

[gentoo-dev] [PATCH] multiprocessing.eclass: work around Cygwin FIFO shortcoming

[Michael Haubenwallner]

Hi,

same patch is about to be applied to portage:
https://github.com/gentoo/portage/pull/86

Thanks for comments!
/haubi/

>From dc80b87a87f407cece9abad81a5369e2ec5ae2a5 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Wed, 27 Apr 2016 15:21:52 +
Subject: [PATCH] multiprocessing.eclass: work around Cygwin FIFO shortcoming

Cygwin does not support multiple read-handles for one FIFO (yet).
As we really need just one readonly- and one writeonly-handle, we can
reorder to open one single readwrite- and one writeonly-handle.

X-Gentoo-Bug: 583962
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=583962
---
 eclass/multiprocessing.eclass | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
index 70ca475..67f7e2d 100644
--- a/eclass/multiprocessing.eclass
+++ b/eclass/multiprocessing.eclass
@@ -139,11 +139,16 @@ multijob_init() {
 
 	# Setup a pipe for children to write their pids to when they finish.
 	# We have to allocate two fd's because POSIX has undefined behavior
-	# when you open a FIFO for simultaneous read/write. #487056
+	# when using one single fd for both read and write. #487056
+	# However, opening an fd for read or write only will block until the
+	# opposite end is opened as well. Thus we open the first fd for both
+	# read and write to not block ourselve, but use it for reading only.
+	# The second fd really is opened for write only, as Cygwin supports
+	# just one single read fd per FIFO. #583962
 	local pipe="${T}/multijob.pipe"
 	mkfifo -m 600 "${pipe}"
-	redirect_alloc_fd mj_write_fd "${pipe}"
 	redirect_alloc_fd mj_read_fd "${pipe}"
+	redirect_alloc_fd mj_write_fd "${pipe}" '>'
 	rm -f "${pipe}"
 
 	# See how many children we can fork based on the user's settings.
-- 
2.7.3

[gentoo-dev] Re: Unused profiles

[Michael Haubenwallner]

On 01/22/2017 07:56 PM, Fabian Groffen wrote:
> On 19-01-2017 20:47:46 +0100, Michał Górny wrote:

>> prefix/aix/7.1.0.0/ppc

This one I've added to profiles.desc,

>> prefix/hpux/B.11.11/hppa2.0

while just dropping this one, silently.

I've completely given up on HP-UX here already, and one would
hardly find anything working in current tree at all. Unless we
see some interest in HP-UX by someone within some time, all hpux
profiles (and keywords) may eventually go.

> Please don't remove these.  Most seem missing profile.desc ptrs to me,
> but some are odd, which needs investigation.
> 
> Thanks,
> Fabian


Thanks for notifying!
/haubi/

Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files

[Michael Haubenwallner]

On 12/10/2012 12:10 AM, "Paweł Hajdan, Jr." wrote:
>> I propose that we say, once a year, schedule a tree-cleaning of old
>> updates files.  These updates files could be added to a tarball made
>> available for download.  That way if they are needed to update a system
>> older than what the main tree has been tree-cleaned to. They can then be
>> manually downloaded, extracted to the normal location and then run the
>> "fixpackages" command.
> 
> I think that complicates the process. :-/ But maybe the advantages
> outweigh that.
> 
>> The main question here is what is a reasonable length of time to keep
>> the updates actively in-tree?
>>
>>  -- From my experience in the forums, I think any updates older than 
>> 4 years should be subject to tree-cleaning.  
> 
> Yeah, 4 years is ancient and would probably be non-trivial to update anyway.
> 
>>  -- Most old systems that have been updated tend to be less than that,
>> probably about 2 years.
> 
> 2 years seem reasonable.

For the records:
We do have some Gentoo box serving as VirtualBox host here, installed in early 
2010,
not updated since then, with an uptime of 836 days right now. It is subject to 
upgrade,
but there may come another year until that to happen ("never change a running 
system").
Although I do not expect the update to be trivial, keeping things like pkgmove 
for at
least 4 years sounds reasonable.

/haubi/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Haubenwallner]

On 01/23/13 19:29, Felix Kuperjans wrote:
> Samuli Suominen wrote:
>> please review this news item, seems we need one after all
> 
> /dev/root is no longer available in this udev version, so people who put
> this in their /etc/fstab might end up with an unbootable system.
> 
> I suggest including in the news item, that /dev/root must be replaced
> with the actual root device or LABEL=..., UUID=... and the like in
> /etc/fstab.

I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
/dev/sda1 due to some kernel driver change (took me a while to find out).
I'm not using genkernel or any initramfs, nor do I have separate /usr.

The only way I've found to keep the system bootable with both kernels
(for the upgrade process until the new kernel config was good enough)
was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.

How would this be done when there is no /dev/root any more?

So yes, please include the /dev/root drop (at least) in the news item.

/haubi/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Haubenwallner]

On 01/24/13 16:49, Michael Orlitzky wrote:
> On 01/24/13 05:02, Michael Haubenwallner wrote:
>>
>> I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
>> encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
>> /dev/sda1 due to some kernel driver change (took me a while to find out).
>> I'm not using genkernel or any initramfs, nor do I have separate /usr.
>>
>> The only way I've found to keep the system bootable with both kernels
>> (for the upgrade process until the new kernel config was good enough)
>> was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.
>>
>> How would this be done when there is no /dev/root any more?
> 
> These are the Compaq SmartArray controllers (usually found in HP
> Proliants). They used to have their own block driver, but these days
> they're just grouped with the rest of the SCSI drives.

Yep, this is a HP DL380 G6, and lspci says:
04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers 
(rev 01)

> The old driver:
> 
>   Block Devices -> BLK_CPQ_CISS_DA
> 
> The new one is under,
> 
>   SCSI device support -> SCSI low-level drivers -> SCSI_HPSA
 
> The HPSA driver does *not* work on older Proliants, so I can only assume
> that HPSA is receiving active maintenance while the old block driver is
> not. Nevertheless, if the block driver worked for you in an old kernel,
> you could simply disable HPSA on the new one.

Well, I'm pretty sure to have started with BLK_CPQ_CISS_DA=y in the new kernel
config, but this driver doesn't seem to feel responsible for that controller
any more - or what else could have make me wonder where /dev/cciss/* has gone?
Finally I went along [1] to identify SCSI_HPSA as the correct driver.
[1] 
http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch08s02.html

> When the time comes that you need to boot two newish kernels, you can
> re-enable HPSA and update fstab to use the new name.

So this didn't work out IIRC - but I won't retest that now. For the curious:
  $ cat /sys/bus/pci/devices/\:04\:00.0/vendor 
  0x103c
  $ cat /sys/bus/pci/devices/\:04\:00.0/device 
  0x323a

/haubi/

Re: [gentoo-dev] Automagic pax-mark

[Michael Haubenwallner]

On 04/08/2013 12:08 AM, Anthony G. Basile wrote:
> On 04/07/2013 05:20 PM, Mike Gilbert wrote:
>> On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn
>>  wrote:
>>> Hello All,
>>>
>>> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call 
>>> no
>>> longer has a || die. This means that the resulting binaries may have PT_PAX,
>>> XATTR_PAX, both or neither markings depending on kernel configuration,
>>> filesystem and mount options.

Although not used to PaX in general, I've fixed a bug report[1] where "pax-mark 
-c" was
sufficient to get some prebuilt thirt-party binary to run on user's hardened 
machine.

>> In the mean time, maybe we could disable XATTR_PAX markings by default
>> for people not using the hardened profile.
>>
> You can disable either or both type of pax markings by setting PAX_MARKINGS.
> We can change the default in the eclass.  Its currently set to "PT XT".
> Setting it to "PT" would revert to only doing PT_PAX markings.
> Then users will have to manually set XT in their make.conf.

While fixing that bug I've discovered the default value of PAX_MARKINGS="PT"
(has changed to "PT XT" since), but no profile actually setting 
PAX_MARKINGS="none".

Actually I've wondered if it would make more sense to default to 
PAX_MARKINGS="none",
and have the hardened profiles (or the user in make.conf) set a different value.

But thinking again now, I'm wondering if pax-mark should be done in pkg_preinst 
rather
than src_install - for the sake of binary merges when the build machine has 
different
PAX_MARKINGS than the target machine (no idea if that ever would happen).

[1] https://bugs.gentoo.org/show_bug.cgi?id=456694

my 2 cents
/haubi/

[gentoo-dev] [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

[Michael Haubenwallner]

Hi all,

as you might or might not be aware of, elibtoolize() originally was for applying
patches to ltmain.sh, but now also applies patches to configure scripts.

The problem is that finding configure scripts to be patched is based on where
ltmain.sh is found in ${S}, wild guessing that ltmain.sh may reside in 
subdirectories,
trying ./configure, ../configure and ../../configure inconsistently.

But especially with gettext, this wild guess does not identify each configure 
script.

Attached patch drops that wild guesses, explicitly applying configure-patches to
configure scripts, while still explicitly applying ltconf.sh-patches to 
ltconf.sh.

WDYT?

Thank you!
/haubi/

Index: libtool.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v
retrieving revision 1.106
diff -u -r1.106 libtool.eclass
--- libtool.eclass  11 May 2013 11:17:58 -  1.106
+++ libtool.eclass  12 Nov 2013 10:10:46 -
@@ -204,9 +204,9 @@
# Reuse "$@" for dirs to patch
set --
if [[ ${do_shallow} == "yes" ]] ; then
-   [[ -f ${S}/ltmain.sh ]] && set -- "${S}"
+   [[ -f ${S}/ltmain.sh || -f ${S}/configure ]] && set -- "${S}"
else
-   set -- $(find "${S}" -name ltmain.sh -printf '%h ')
+   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h ')
fi
 
local d p
@@ -225,8 +225,12 @@
ewarn "  avoid this if possible (perhaps by filing a 
bug)"
fi
 
+   local ret
+
+   # patching ltmain.sh
+   [[ -f ${d}/ltmain.sh ]] &&
for p in ${elt_patches} ; do
-   local ret=0
+   ret=0
 
case ${p} in
portage)
@@ -258,17 +262,6 @@
ELT_walk_patches "${d}/ltmain.sh" "${p}"
ret=$?
;;
-   uclibc-conf)
-   if grep -qs 'Transform linux' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 'Transform linux' 
"${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
uclibc-ltconf)
# Newer libtoolize clears ltconfig, as 
not used anymore
if [[ -s ${d}/ltconfig ]] ; then
@@ -276,34 +269,12 @@
ret=$?
fi
;;
-   fbsd-conf)
-   if grep -qs 'version_type=freebsd-' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 
'version_type=freebsd-' "${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
fbsd-ltconf)
if [[ -s ${d}/ltconfig ]] ; then
ELT_walk_patches 
"${d}/ltconfig" "${p}"
ret=$?
fi
;;
-   darwin-conf)
-   if grep -qs '&& echo \.so ||' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs '&& echo \.so ||' 
"${d}/../configure" ; then
-

[gentoo-dev] Re: [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

[Michael Haubenwallner]

On 11/13/2013 10:14 AM, Michael Haubenwallner wrote:
> Hi all,
> 
> as you might or might not be aware of, elibtoolize() originally was for 
> applying
> patches to ltmain.sh, but now also applies patches to configure scripts.

> Attached patch drops that wild guesses, explicitly applying configure-patches 
> to
> configure scripts, while still explicitly applying ltconf.sh-patches to 
> ltconf.sh.

One update to this patch, to run elibtoolize once per directory again,
even if both filenames are in that same directory:

-   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h ')
+   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h\n' | sort -u)

> WDYT?

Without objections, I plan to commit this patch by the end of next week.

Thank you!
/haubi/
Index: libtool.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v
retrieving revision 1.106
diff -u -r1.106 libtool.eclass
--- libtool.eclass  11 May 2013 11:17:58 -  1.106
+++ libtool.eclass  15 Nov 2013 09:57:08 -
@@ -204,9 +204,9 @@
# Reuse "$@" for dirs to patch
set --
if [[ ${do_shallow} == "yes" ]] ; then
-   [[ -f ${S}/ltmain.sh ]] && set -- "${S}"
+   [[ -f ${S}/ltmain.sh || -f ${S}/configure ]] && set -- "${S}"
else
-   set -- $(find "${S}" -name ltmain.sh -printf '%h ')
+   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h\n' | sort -u)
fi
 
local d p
@@ -225,8 +225,12 @@
ewarn "  avoid this if possible (perhaps by filing a 
bug)"
fi
 
+   local ret
+
+   # patching ltmain.sh
+   [[ -f ${d}/ltmain.sh ]] &&
for p in ${elt_patches} ; do
-   local ret=0
+   ret=0
 
case ${p} in
portage)
@@ -258,17 +262,6 @@
ELT_walk_patches "${d}/ltmain.sh" "${p}"
ret=$?
;;
-   uclibc-conf)
-   if grep -qs 'Transform linux' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 'Transform linux' 
"${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
uclibc-ltconf)
# Newer libtoolize clears ltconfig, as 
not used anymore
if [[ -s ${d}/ltconfig ]] ; then
@@ -276,34 +269,12 @@
ret=$?
fi
;;
-   fbsd-conf)
-   if grep -qs 'version_type=freebsd-' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 
'version_type=freebsd-' "${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
fbsd-ltconf)
if [[ -s ${d}/ltconfig ]] ; then
ELT_walk_patches 
"${d}/ltconfig" "${p}"
ret=$?
fi
   

[gentoo-dev] Re: [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

[Michael Haubenwallner]

On 11/15/2013 11:02 AM, Michael Haubenwallner wrote:
>> as you might or might not be aware of, elibtoolize() originally was for 
>> applying
>> patches to ltmain.sh, but now also applies patches to configure scripts.

>> Attached patch drops that wild guesses, explicitly applying 
>> configure-patches to
>> configure scripts, while still explicitly applying ltconf.sh-patches to 
>> ltconf.sh.

> One update to this patch, to run elibtoolize once per directory again,
> even if both filenames are in that same directory:

> Without objections, I plan to commit this patch by the end of next week.

committed.

/haubi/

Re: [gentoo-dev] mbox -- looks sort of interesting

[Michael Haubenwallner]

On 02/11/14 01:36, Jason A. Donenfeld wrote:
> Hey folks,
> 
> Late night clicking-while-drooling, I came across something a few
> minutes ago that mildly piqued my interest -- mbox
> . It's a sandbox that uses a
> combination of ptrace and seccomp bpf; neither ours nor exherbo's uses
> both of these together. The killer feature, for us, that's motivating
> me to write to this list, is that it creates a "shadow file system",
> and then has the option to commit the changes of that file system to
> the real file system, piece by piece, when the process is done. It
> made me think of some discussions we had at FOSDEM about Portage
> evolution and whatnot. I haven't looked at this tool past an initial
> glance, but it does look like interesting food for thought.

Sounds interesting, especially the "without special privileges" bit...

/haubi/

Re: [gentoo-dev] new profile layout with flavors and mix-ins

[Michael Haubenwallner]

On 07/03/2014 08:18 AM, Joshua Kinard wrote:
> On 07/02/2014 13:54, Michał Górny wrote:
>> Dnia 2014-07-02, o godz. 10:44:16
> [snip]
>>
>> I don't feel like we ought to vote on something like this without
>> understanding most of the current profiles. And I'm afraid there are
>> only few people who have any idea about the current profile
>> structure...
>>
> 
> I am going to throw this out there and see what people think.  Maybe it's
> insane, maybe it's not, maybe it's a mix of insane and not-insane.
> 
> Years ago, before we had the current stacking profile design (we were
> discussing the current design, actually), I kinda conjured up this "building
> blocks" like approach for a profile design.

> The idea being that, in /etc/make.conf (or wherever that file is now), you'd
> define $PROFILE like this:
> 
> linux-mips o32 uclibc server:
> PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0"

What about making /etc/portage/make.profile a directory rather than a symlink,
having /etc/portage/make.profile/parent to reference all the flavours?

Tools that need to respect the /current/ profile should work without any 
change, and
tools that need to respect the /available/ profiles (repoman) already do have a 
list
of profiles to respect (profiles/profiles.desc).

So the only missing thing would be the eselect profile module to manage entries 
of
/etc/portage/make.profile/parent, maybe using 
/usr/portage/profiles/profiles.desc
as the source for available flavours.

my 2 cents
/haubi/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Michael Haubenwallner]

Am 2014-07-30 14:33, schrieb Samuli Suominen:
> 
> There is no need to package.mask if proper if -logic is used, like, for
> example,
> 
> if [[ ${PV} == * ]]; then
> inherit git-r3
> KEYWORDS=""
> else
> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
> fi
> 
> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
> the KEYWORDS
> ready, and 1.2.3 and  ebuilds can be identical

Which instance of the KEYWORDS line is touched by the ekeyword tool these days?

To have ekeyword touch the else-part in the release ebuild, what about this:

if [[ ${PV} == * ]]; then
  inherit vcs...
  :; KEYWORDS=""
else
  KEYWORDS="..."
fi

/haubi/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Michael Haubenwallner]

Am 2014-07-30 19:33, schrieb Samuli Suominen:
> 
> On 30/07/14 20:29, Michael Haubenwallner wrote:
>> Am 2014-07-30 14:33, schrieb Samuli Suominen:
>>> There is no need to package.mask if proper if -logic is used, like, for
>>> example,
>>>
>>> if [[ ${PV} == * ]]; then
>>> inherit git-r3
>>> KEYWORDS=""
>>> else
>>> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
>>> fi
>>>
>>> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
>>> the KEYWORDS
>>> ready, and 1.2.3 and  ebuilds can be identical
>> Which instance of the KEYWORDS line is touched by the ekeyword tool these 
>> days?
>>
>> To have ekeyword touch the else-part in the release ebuild, what about this:
>>
>> if [[ ${PV} == * ]]; then
>>   inherit vcs...
>>   :; KEYWORDS=""
>> else
>>   KEYWORDS="..."
>> fi
>>
>> /haubi/
>>
> 
> You are propably looking for this,
> http://bugs.gentoo.org/show_bug.cgi?id=321475
> 

Indeed, thanks!

/haubi/

Re: [gentoo-dev] New staff : Elias Pipping (pipping)

[Michael Haubenwallner]

On Sat, 2007-10-27 at 16:21 +0200, Fabian Groffen wrote:
> On 27-10-2007 16:14:42 +0200, Denis Dupeyron wrote:
> > It's my pleasure to introduce Elias Piping (pipping) who is joining us
> > as staff. He will do general development and bug solving for the
> > Gentoo/alt project.
> > 
> > Elias is familiar with Tcl, Ruby, Python, Perl, Java, sed, awk and
> > bash. He admits having above average knowledge of regular expressions,
> > and I suspect that should be read "way above average". He has
> > previously contributed to the MacPorts project.
> > 
> > Elias studies mathematics in Berlin where he has always lived as he
> > doesn't like to travel. He doesn't have a TV and reads only
> > programming-related books. He enjoys english and frequently goes to
> > the movies.
> > 
> > Please everybody, give a very warm welcome to Elias.
> 
> Yay!  Welcome to my^W^Wthe team!

Welcome team-colleague!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] POSIX shell and "portable"

[Michael Haubenwallner]

On Sat, 2007-11-03 at 00:47 +, Roy Marples wrote:

As it seems too few people really accept your suggestion, I feel it's
time for me to chime in too, although I don't know what exactly POSIX-sh
standard defines.

> On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote:
> > On 02-11-2007 17:35:08 +, Roy Marples wrote:
> > > I don't see them as inferior.
> > > I see them as more portable and less confusing.
> > 
> > Please stop calling it "more portable".
> 
> But is it more portable as then then works across more than one shell.
> 
> >   The shell code you see in
> > configure can in a way be called "portable".  Your POSIX compliant stuff
> > isn't.
> 
> Sure it is - it should work on a shell that claims POSIX compliance.
> 
> >   In fact, by stating #!/bin/sh you actually make the code useless
> > on a number of platforms, where it would have been working fine if there
> > just were #!/bin/bash there.
> 
> Then the issue is to fix their sh so it follows POSIX compliance.
> As soon as a dash, bb or FreeBSD sh issue is found where it deviates
> from POSIX but it works on bash a lot of people say "dash bug, therefore
> invalid

Agreed, but (speaking for alt/prefix):

Alt/prefix is designed to (mainly) work without superuser access on the
target machine, which may also be Solaris, AIX, HP-UX and the like.
/bin/sh on such a machine is not POSIX-shell, but old bourne-shell
(unfortunately with bugs often).
And it is _impossible_ to have sysadmins to get /bin/sh a POSIX-Shell
nor to have that bugs fixed.

But yes, on most machines there is /bin/ksh, which IMHO is POSIX
compliant (maybe also with non-fixable bugs).

Although I do not know yet for which _installed_ scripts it'd be really
useful to have them non-bash in alt/prefix, I appreciate the discussion.

To see benefits for alt/prefix too, it _might_ require that discussion
going from requiring /bin/sh being POSIX-sh towards being
bourne-shell...

> 
> > It seems to me that you actually mean "more FreeBSD-able" or something,
> > which is a high price to pay for a relatively small part of Gentoo as a
> > whole.
> 
> More embeddable.
> More BSDable.
> More Linuxable - bash isn't the only linux shell, there are plently of
> others.

More (generic) unix-able.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] POSIX shell and "portable"

[Michael Haubenwallner]

On Mon, 2007-11-05 at 10:13 +, Roy Marples wrote:
> While I still have access to the [EMAIL PROTECTED] email, I'll respond here.
> 
> 
> On Mon, 2007-11-05 at 10:22 +0100, Michael Haubenwallner wrote:
> > On Sat, 2007-11-03 at 00:47 +, Roy Marples wrote:
> > 
> > As it seems too few people really accept your suggestion, I feel it's
> > time for me to chime in too, although I don't know what exactly POSIX-sh
> > standard defines.
> 
> > Agreed, but (speaking for alt/prefix):
> > 
> > Alt/prefix is designed to (mainly) work without superuser access on the
> > target machine, which may also be Solaris, AIX, HP-UX and the like.
> > /bin/sh on such a machine is not POSIX-shell, but old bourne-shell
> > (unfortunately with bugs often).
> > And it is _impossible_ to have sysadmins to get /bin/sh a POSIX-Shell
> > nor to have that bugs fixed.
> > 
> > But yes, on most machines there is /bin/ksh, which IMHO is POSIX
> > compliant (maybe also with non-fixable bugs).
> > 
> > Although I do not know yet for which _installed_ scripts it'd be really
> > useful to have them non-bash in alt/prefix, I appreciate the discussion.
> > 
> > To see benefits for alt/prefix too, it _might_ require that discussion
> > going from requiring /bin/sh being POSIX-sh towards being
> > bourne-shell...
> 
> Actually you missed the mark completely.
> Nothing in the tree itself specifies what shell to use - instead it's
> the package manager. So the PM on Gentoo/Linux/FreeBSD *could*
> be /bin/sh and on the systems where /bin/sh is not possible to change to
> a POSIX compliant shell then it can still use /bin/bash or wherever it's
> installed.

So "have the installed scripts to not require bash" is another topic ?

Ok then:
Given that we want to have the tree "more generic unix-able":
What is the benefit from having the tree being POSIX- but not
bourne-shell compatible, so one still needs bash on Solaris/AIX/HP-UX ?
Because I'd say those three are the biggest substitutes for "unix",
while I'd call *BSD and Linux just "unix derivates" (although with
enhancements)...

> 
> This also applies to the userland tools. If the ebuild or eclass *has*
> to use the GNU variants then it should either adjust $PATH so that it
> finds them first, or it prefixes them all with g, like it does on
> Gentoo/FreeBSD.
> 
> None of this is technically challenging in itself, it's just that the
> key people who would have to do the work to make this possible have
> already given a flat out no.

In the early prefix days I had some portage enhancement, providing a
wrapper-function around all coreutils/findutils/diffutils/grep/others,
trying to find a GNU implementation for them. And if not found, try to
map some args to the native ones ("xargs -r" fex - although didn't work
as shell-function).
But then we decided to always provide USERLAND=GNU in prefix and this
portage patch was thrown away.

> 
> > > > It seems to me that you actually mean "more FreeBSD-able" or something,
> > > > which is a high price to pay for a relatively small part of Gentoo as a
> > > > whole.
> > > 
> > > More embeddable.
> > > More BSDable.
> > > More Linuxable - bash isn't the only linux shell, there are plently of
> > > others.
> > 
> > More (generic) unix-able.
> 
> Exactly so :)

Not really as long as not being bourne shell compatible like autoconf's
configure. I won't trust to have a POSIX shell like /bin/ksh everywhere,
but /bin/sh only, which usually is just a bourne shell on "unix".

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] POSIX shell and "portable"

[Michael Haubenwallner]

On Mon, 2007-11-05 at 23:18 +, Roy Marples wrote:
> On Mon, 2007-11-05 at 16:21 -0400, Mike Frysinger wrote:
> > we want the installed environment to be portable, not the build 
> > environment.  
> > i do not see any benefit from forcing the build environment to be pure 
> > POSIX 
> > compliant and i see many many detrimental problems.
> 
> Oh I don't know. Imagine how cool it would be for starting a new port.
> 
> 1) Install PM
> 2) Wang on a portage tree
> 3) emerge ready to go
> 
> Obviously it's not quite that simple as portage requires python and
> pkgcore require python, paludis requires tr1-whatever libs - but that's
> the restriction of the PM used. Maybe one day Gentoo will have a PM that
> doesn't require any of that and is just written in C and sh, using POSIX
> libc where it can.
> 
> But enough pipe dreaming :)

Stop dreaming: Some very rudimentary thing like this already exists:

To bootstrap an alt/prefix instance on AIX, HPUX, whatever-unix-without-
sufficient-GNU-userland, we're using some "prefix-launcher"[1].
This simply is a "package fetcher/patcher/builder/installer", where a
single package is defined by some ".build"-script, which is written in
plain bourne shell. You might (should) find some gentoo ideas if you
look inside it ;)

Now to install {python, bash, (prefix-)portage, wget, patch, diffutils,
findutils, gcc, etc.} one single command[2] (think "emerge system") does
it all, just requiring GNU make, /bin/sh being bourne shell, some ansi-c
compiler, some (non-GNU) tar, gunzip, (non-GNU) sed, (non-GNU) whatever.

So the only non-native (not installed by default) thing required is GNU
make, which is available as binary package without any dependencies for
each "unix" I've seen.

[1] http://sourceforge.net/projects/prefix-launcher/
[2] http://prefix-launcher.wiki.sourceforge.net/

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Michael Haubenwallner]

On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote:


Seems that there is a chain of different metadata levels:

1) The parser/interpreter/compiler/whatever to grok the ebuild.
2) *How* to extract the EAPI value from the ebuild(-filename), using 1)
3) The *value* of EAPI for that ebuild, using 2)
4) The contents of the ebuild, based on 3)

To 1: for me it's absolutely acceptable to have it encoded in the
filename (or extension). Fex we want to switch from bash to xml (for
whatever reason), we could rename from *.ebuild to *.xbuild.

> But yeah, to be honest, you're right that my original "as long as
> ebuilds stay bash" was a bit optimistic: it was assuming there would 
> be no decision of changing that rule as long as there would be no good
> reason for it (like a switch to xml or whatever other not-bash
> format).

To 2: it might be acceptable to have it encoded into the filename.

To 3 (and 2): Thomas++

> I still think that changing file names when absolutly required
> (switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or
> switching to xml, etc.) is less disturbing than changing it for every
> single new EAPI. It's not because one new extension may not be
> eternally enough that we should introduce an infinity right now.

To 4: we agree that this never will be encoded in the filename ;)


Just another bit of brainstorm (forget it if too broken):

What if we do not start with "EAPI=1" variable, but "eapi 1" function
immediately ?

I could think of several implementations to let PM detect EAPI:

*) Given it is the first bash-command in the ebuild:
Just 'echo' the required EAPI and exit while PM is in "look-for-eapi"
mode (remember 'eapi' function is part of PM, or profile.bashrc as
fallback for ancient PM).

*) As 'eapi' being a bash function, it could *migrate* the
bash-environment from the PM's default EAPI to the given one - or just
spit "cannot migrate EAPI from A to B"...

*) Or just spit a message "update your PM" (from profile.bashrc) ...

Just want to show that using 'eapi-function' should be more flexible
than 'EAPI-variable', and thus will not be subject to change too often
and require 2) (see above).

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Michael Haubenwallner]

On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:

> I'm thinking about having them embedded in the comment as first line as
> something like
> 
> #!/usr/bin/env emerge --eapi $foo

OT: It actually works adding this first line and do chmod +x foo.ebuild:

#! /usr/bin/env ebuild

Then you can do: ./foo.ebuild {digest,install,merge,whatever}

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Michael Haubenwallner]

On Thu, 2007-12-27 at 20:48 +0100, Marius Mauch wrote:
> On Thu, 20 Dec 2007 17:22:22 +0100
> Luca Barbato <[EMAIL PROTECTED]> wrote:
> 
> > I'm thinking about having them embedded in the comment as first line as
> > something like
> > 
> > #!/usr/bin/env emerge --eapi $foo
> 
> Unfortunately the "emerge --eapi $foo" part would be passed as a single 
> argument to /usr/bin/env, therefore can't work.

This also could be done as (using 'ebuild' instead of 'emerge')

#! /usr/bin/env ebuild.1

and PM could provide some 'ebuild.1' executable, at the bare mimimum
doing nothing but

#! /bin/sh
exec ebuild --eapi 1 "$@"

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [RFC] Reducing the size of the system package set

[Michael Haubenwallner]

On Tue, 2008-01-08 at 14:37 -0800, Chris Gianelloni wrote:
> Implicit dependencies waste more time than pretty much anything else.  Almost 
> all circular
> dependency issues we currently have are due to implicit dependencies.

Maybe OT (an idea in a very early state):

For the implicit dependencies one could think of path-sandbox to help:

Inform libsandbox which files are provided by packages both in *DEPEND
and the system package set, and let it completely deny access to
not-listed files.

Or let it report any access to not-listed files to help finding the
implicit dependencies.

Thoughts?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Reducing the size of the system package set

[Michael Haubenwallner]

On Thu, 2008-01-10 at 14:32 -0500, Mike Frysinger wrote:
> On Thursday 10 January 2008, Michael Haubenwallner wrote:
> > On Tue, 2008-01-08 at 14:37 -0800, Chris Gianelloni wrote:
> > > Implicit dependencies waste more time than pretty much anything else. 
> > > Almost all circular dependency issues we currently have are due to
> > > implicit dependencies.
> >
> > Maybe OT (an idea in a very early state):
> >
> > For the implicit dependencies one could think of path-sandbox to help:
> >
> > Inform libsandbox which files are provided by packages both in *DEPEND
> > and the system package set, and let it completely deny access to
> > not-listed files.
> >
> > Or let it report any access to not-listed files to help finding the
> > implicit dependencies.
> 
> it'd be quite some time before this would see implementation, but can you 
> summarize the ideas and open a feature request in bugzilla please

done: http://bugs.gentoo.org/show_bug.cgi?id=205312

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Packages up for grabs

[Michael Haubenwallner]

On Tue, 2007-12-25 at 18:19 +, Christian Heim wrote:

> As usual you are free to pick them up, if you'd like to maintain them...

>  - app-admin/chrpath

Late, but I should be able to take this one..

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays

[Michael Haubenwallner]

On Sat, 2008-01-19 at 00:26 +0200, Alon Bar-Lev wrote:
> On 1/18/08, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > On Thursday 17 January 2008, Robin H. Johnson wrote:
> > > anonvcs.gentoo.org: anoncvs, anonsvn, anongit
> > > - Anonymous SVN is changing from http:// to svn:// [1]
> > > overlays.gentoo.org [3]:
> > > - Anonymous SVN is changing from http:// to svn://
> >
> > i'd point out that http:// syncing is usable from behind firewalls while
> > svn:// is not ... while this does not affect me personally, it's something 
> > to
> > keep in mind.
> > -mike
> >
> >
> 
> Just wanted to note this too... I am one of the affected ones...

I'm also behind some firewall: +1 for keeping http.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] VDB access

[Michael Haubenwallner]

On Wed, 2008-02-06 at 07:30 +0100, Vlastimil Babka wrote:
> Zac Medico wrote:

> or we would want to use the general metadata query also for other
> purposes.

> Anyway, restricting ebuilds from vdb access sounds like a good idea to me.

+1 for general metadata query interface.

In prefix (specifically on AIX) we have some nasty requirement to merge
object files inside archive files, because shared-objects should be
members of a static libraries, fex libstdc++.so.6 is an archive member
of libstdc++.a.

This (still experimental) inside-library-merge currently is done using
some hackery in profile.bashrc, but this requires access to vdb/CONTENTS
in pre_pkg_postrm() to clean up after unmerge.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Michael Haubenwallner]

On Mon, 2008-03-03 at 15:53 +0100, Fabian Groffen wrote:
> On 03-03-2008 13:36:25 +, Roy Marples wrote:
> > On Thursday 28 February 2008 11:22:13 Roy Marples wrote:
> > > So the only thing left (aside from bug fixing) is to instruct OpenRC
> > > dependency
> > > code that it's in a prefix and to respect the noprefix keyword in 
> > > services,
> > > or
> > > to provide dummy services.
> > 
> > This is now done.
> > 
> > I have OpenRC fully working in a prefixed non priviledged install on a 
> > NetBSD 
> > box.
> 
> Can you define how this is working?  Do you just have NetBSD and install
> OpenRC in /my/arbitrary/path, or do you have a full set of utilities
> under /my/arbitrary/path with OpenRC as one of them?
> 
> > The only question I have left is what mechanism resets service state, as 
> > the 
> > prefixed state dir needs will presist between reboots which isn't desirable.
> 
> startprefix could maybe start some sort of process that lives on,
> activated like keychain does, such that multiple startprefix invocations
> do not start the system all the time -- if that is desired at all. In
> a real scenario it may be just a hook from the host OS's start/stop
> mechanism to tell OpenRC in what state it should run.

Must admit not having looked at OpenRC yet - maybe I understood sth.
wrong, but:

+1 for registering OpenRC into host OS's specific init.d mechanism.

Here I'm doing so with distccd on ia64-hpux, having some (host OS
specific) script in (not yet gentoo-) prefix, understanding additional
'--install [name]' - or have a separate command for that.
This needs to be run as root once to register into host OS's init.d
mechanism.

For hpux fex this just is adding some symlinks:
/sbin/init.d/name -> /my/prefix/sbin/init.d/distccd
/sbin/rc3.d/S990name -> /sbin/init.d/name   # to start in runlevel 3
/sbin/rc2.d/K100name -> /sbin/init.d/name   # to kill for runlevel 2

When doing so with OpenRC's main process, it could integrate smoothly
with normal system reboot and start prefixed init.d scripts.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] stacking profile.bashrc?

[Michael Haubenwallner]

Hi,

I'm facing this problem in Prefix on AIX, although it is a generic
problem IMO:

We do have post_src_install() hook in profiles/prefix/profile.bashrc to
drop charset.alias for packages != libiconv, required for non-glibc
platforms.

In profiles/prefix/aix/profiles.bashrc, there is another
post_src_install() hook with some aix specific hacks, required for
portage to allow for merging shared libraries there.

The problem now is that the latter post_src_install() overrides the
former, and I get collisions on charset.alias as the former is not
executed.

Is this a portage bug (each of them should be executed)?
Or is there some defined way to handle this I just was unable to find?

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

On Mon, 2009-07-13 at 16:36 +0100, Sérgio Almeida wrote:
> Hello,
> 
> Missed a weekly report, busy week. Will try to post 2 reports this week
> as I am also working twice as much time.
> 
> Progress since last report:

> * symlinking dependencies (ex: ruby and ruby-gems)

Sorry, I've lost track on what's really going on here:
Does 'symlink' mean symlinks on the filesystem like 'ln -s' does?
Or, more important, does uselect create those symlinks itself?
If yes, please don't forget that OS without symlinks...

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] stacking profile.bashrc?

[Michael Haubenwallner]

(seems the first mail was dropped somewhere, sorry when doubled)

Hi,

I'm facing this problem in Prefix on AIX, although it is a generic
problem IMO:

We do have post_src_install() hook in profiles/prefix/profile.bashrc to
drop charset.alias for packages != libiconv, required for non-glibc
platforms.

In profiles/prefix/aix/profiles.bashrc, there is another
post_src_install() hook with some aix specific hacks, required for
portage to allow for merging shared libraries there.

The problem now is that the latter post_src_install() overrides the
former, and I get collisions on charset.alias as the former is not
executed.

Is this a portage bug (each of them should be executed)?
Or is there some defined way to handle this I just was unable to find?

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

On Wed, 2009-07-15 at 16:43 +0100, Sérgio Almeida wrote:
> On Tue, 2009-07-14 at 17:07 +0200, Michael Haubenwallner wrote:
 
> > So it should be fine as long as 'symlink' can potentially be implemented
> > as 'copy' for specific platforms.

> ... can be easily replaced for copy. What should be the default?
> Should uselect be able to supply both options like "uselect --copy bla
> bla" overrides os.symlink to copy function?

Ideally it is transparent to the uselect-user (either end-user or
developer) if the implementation actually does the symlink or emulates
it via copy.
It might be enough to select the implementation based on the
"host-system" (CHOST), which may be different to the
"build-system" (CBUILD).
Eventually, uselect won't need to detect the CHOST itself, but get it
from some external resource (cmdline, env-var, config-file, ...).

> Thanks for the hint!

nP.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] stacking profile.bashrc?

[Michael Haubenwallner]

On Wed, 2009-07-15 at 11:39 -0700, Zac Medico wrote:
> Michael Haubenwallner wrote:
 
> > We do have post_src_install() hook in profiles/prefix/profile.bashrc ...
> > In profiles/prefix/aix/profiles.bashrc, there is another
> > post_src_install() hook ...
> > The problem now is that the latter post_src_install() overrides the
> > former, ...

> The pre/post phase hooks are not designed for this, they are only
> intended for users to put in /etc/portage/bashrc. For what you are
> trying to do, it seems like a registration interface would be more
> appropriate (something like register_die_hook).

Should this registration api be provided by portage, or by
base/profile.bashrc?
Hmm, will have to be portage, because /etc/portage/bashrc would override
base/profile.bashrc too. base/profile.bashrc just might jump in when not
provided by installed portage yet.

>  Maybe the usage
> could go something like this:
> 
>   register_phase_hook install post my_post_src_install

For readability, I'd more like to have 'post' in front of 'install'.

Or eventually something like:

register_phase_hook \
  --before-src_install my_pre_src_install_1 my_pre_src_install_2 \
  --after-src_install my_post_src_install_1 my_post_src_install_2 \
  --before-  

Or with phase-names instead of phase-function-names:

register_phase_hook \
  --before-{setup,nofetch,unpack,prepare,configure,compile,...}  
\
  --after-{...,test,install,preinst,postinst,prerm,postrm} 

Suggesting "before&after" here as I'm always confused with
pre_pkg_preinst, post_pkg_preinst, pre_pkg_postinst, post_pkg_postinst,
pre_pkg_prerm, post_pkg_prerm, pre_pkg_postrm, post_pkg_prerm.

Anyway: besides implementation, what else does it need to get this done?

Thank you!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

Sérgio Almeida wrote:
> On Thu, 2009-07-23 at 17:28 +0200, Robert Buchholz wrote:
>> On Thursday 23 July 2009, Sérgio Almeida wrote:
>>> You changedir, you call uprofile, and
>>> voila, new profile. You login again, default profile.

..., change back to your home dir, call uprofile, and you have your
default (=login) environment.

> if cmd = 'chdir':
>   uprofile

> What do you guys think?

While the per-directory profile sounds interesting and useful (a really
good idea!), as it might solve the requirement for per-project
environment here, the automatism for the 'cd' command feels like more
confusing than useful: "WTF does 'cd' more than change directory?"

Instead, provide a command to update the environment for the current
directory, which does search for an .uprofile/ in all the parent
directories when there is no local one.
Additionally, (let the user) define a *new* command that does both
changing directory and updating the environment.

Another point: the per-directory profile solution feels like there is no
need to distinguish between user- and directory-profile any more - as
the user-profile would not be anything different than ~/.uprofile/, no?

Thank you!

/haubi/

Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

Sérgio Almeida wrote:
> On Fri, 2009-07-24 at 10:22 +0200, Michael Haubenwallner wrote: 

>>> if cmd = 'chdir':
>>>   uprofile

>> ..., the automatism for the 'cd' command feels like more
>> confusing than useful...

> Atm, cd just changes dir as it is supposed to. Robert alerted us to the
> fact that we can trigger a PRE_CMD on most shells when a CHANGEDIR
> occurs. 
 
>> Instead, provide a command to update the environment for the current
>> directory, which does search for an .uprofile/ in all the parent
>> directories when there is no local one.
>> Additionally, (let the user) define a *new* command that does both
>> changing directory and updating the environment.
>>
> 
> This is the question... Call uprofile manually or detect the profile
> automatically? Both capabilities? Mmm...

I'd say leave it to the user to either use the CHANGEDIR event,
or define some alias like 'ucd', or call 'uprofile' manually only.
Eh - provide an uselect-module to select the variant...

>> Another point: the per-directory profile solution feels like there is no
>> need to distinguish between user- and directory-profile any more - as
>> the user-profile would not be anything different than ~/.uprofile/, no?
> 
> Yes and no. ~/.uselect/ contains a bin/ environment (prepended to your
> PATH by /etc/profile or something) a env.d/ and most probabily
> something else that gets executed uppon login.
> 
> This does not invalidate you having a ~/.uprofile/. uprofile will
> configure your ~/.uselect/ and your environment variables. Your user
> profile will not be interpreted by python, uprofile turns profile files
> (from python) into bin/ and env.d/ environment on your ~/.uselect.

Ohw, there is .uselect/{bin,env.d}/ ...

What about a per-directory .uselect/{bin,env.d}/ too?
I'd like to set up the complete environment/profile for a development project,
to completely take precedence over the users' environment/profile who are
working on that project, to have something like this order:
PATH=/my/project/.uselect/bin:/home/user/.uselect/bin:/etc/.uselect/bin:/usr/bin:/bin

Maybe this already is how it works?

> 
> This may seem confusing, but that's the best way I can explain. Later
> this weekend will send a call for ideas/call for modules to the dev
> list to get everyone known with the uselect environment. I'm just
> finishing cleaning up the code to start commiting and using git
> branches.

Whenever I come to test uselect/uprofile, I'll do this in Gentoo Prefix
on several platforms, not on my stable Gentoo Desktop...

Thank you!

/haubi/

Re: [gentoo-dev] python-wrapper breaks init scripts

[Michael Haubenwallner]

Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-10-04 20:32:17 Hanno Böck napisał(a):
>> I just stepped over a problem with the new python-wrapper. If I interpreted 
>> the changelogs correctly, since eselect-python-20090801 /usr/bin/python is 
>> no 
>> longer a symlink, but a wrapper.
> 
> Since eselect-python-20090804 /usr/bin/python is a symlink to a wrapper.
>  
>> I find this a questionable idea simply for the overhead it causes, but it 
>> seems that this breaks all init-scripts using start-stop-daemon for python 
>> scripts.
>>
>> Example:
>> http://bugs.gentoo.org/show_bug.cgi?id=286191
>>
>> (same issue happens with some self-written python daemons we're using on our 
>> servers)
>>
>> I don't know what the reasons were for the change from symlinks to a wrapper
> 
> Ebuilds (usually through python.eclass) need to be able to set requested 
> version
> of Python without changing /usr/bin/python symlink. This is performed by 
> setting
> EPYTHON environment variable ("E" in the name of this variable is related to 
> words
> "ebuild" and "eclass"). If this variable isn't set, then Python wrapper uses
> version of Python configured using `eselect python`. Otherwise it uses 
> version of
> Python referenced by this variable.

The problem here IMO is that this wrapper executes python2.6 with argv0 set
to python2.6, while it should be the argv0 from how the wrapper was executed.
At least this is what init.d scripts expect (seen with ntlmaps too).

/haubi/

[gentoo-dev] RFC: multilib and the compatibility to singlelib

[Michael Haubenwallner]

Hi devs,

while there is the appreciated multiple ABI portage support going on,
a thought on the intentions of the multilib profiles.

Some background:
I do have to support building an older, but still maintained large
application software, that simply does not work when built as 64bit.
As it does not have the need itself for >32bit pointers, and all
the 64bit target platforms do support 32bit binaries too, the plan
to fix the code for 64bits has been cancelled.

I'm using gcc to build the application on all the target unices,
as well as autotools for build management.

As I'm building the toolchain myself too, I configure it with the
32bit host triplet on each platform, usually disabling multilib.

This simply works for ppc-aix, hppa-hpux, ia64-hpux, sparc-solaris,
x86-solaris, even if the underlying OS/kernel is 64bit.
It isn't even necessary to explicitly use --{build,host} at all,
as config.guess tells the 32bit triplet on these platforms.
Additionally, even their default compiler output is 32bit.

But Linux "is not Unix":
Configuring both binutils and gcc needs to be done with:
  $ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ...
This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib,
64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux.

Problem is that, as x86-linux isn't a multilib target, both ld and gcc
search for 32bit libs&objects in /usr/lib:/lib, as they don't know about
/usr/lib32:/lib32. The error when bootstrapping gcc is:
  /usr/lib/crti.o: file not recognized: File format not recognized

While it is possible to patch binutils[1] and gcc[2] to search in
/usr/lib32:/lib32 even with this otherways non-multilib target,
it doesn't feel like the "right thing" to enable multilib for
just one multilib option.

Isn't the intention of multilib to have a new (64bit) system
be compatible with the corresponding old (32bit) system?

Please comment, thank you!
/haubi/

[1] http://overlays.gentoo.org/proj/alt/changeset/51324
[2] http://overlays.gentoo.org/proj/alt/changeset/51325

Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib

[Michael Haubenwallner]

Mike Frysinger wrote:
> On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
>> As I'm building the toolchain myself too, I configure it with the
>> 32bit host triplet on each platform, usually disabling multilib.
> 
> this doesnt make any sense to me

What exactly doesn't make sense to you:
* building the toolchain in general:
   The application is quality assured to one specific gcc version, and
   I cannot expect that exactly this one version is available on the
   target machine, especially when some specific patches are required,
   or there is no gcc available at all, or the installation is just broken.
   And sometimes I do have multiple application releases on the same
   machine, requiring different gcc versions...
* using the 32bit host triplet:
   see below
* or disabling multilib:
   whenever possible I'd like to avoid messing with multilib.

>> But Linux "is not Unix":
> 
> you're right, so i'm not terribly concerned with compatibility with non-Linux 
> systems.  comparing the native Gentoo/Linux multilib setup to another Linux 
> multilib setup is the only useful comparison.

Agreed. Although it is uncommon that Linux causes more headaches than Unix,
especially when it is about GNU packages.

>> Configuring both binutils and gcc needs to be done with:
>>   $ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ...
>> This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib,
>> 64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux.

> i dont get it.  why does the i686-pc-linux-gnu toolchain target matter on an 
> amd64 multilib system ?  the native x86_64-pc-linux-gnu toolchain should 
> already do the right thing when given -m32.

It is more an administrative thing: On Unix as well as x86-linux I simply
get 32bits from gcc. But for x86_64-linux I'm in need of an exception to
build/use some x86_64-gcc and wrap it with -m32, because I don't want to
force the application-maintainers to add this exception to add CFLAGS=-m32,
which can be interpreted as "require some change to keep it unchanged".
And it is ways easier to use --{build,host} than to create wrappers.

>> Isn't the intention of multilib to have a new (64bit) system
>> be compatible with the corresponding old (32bit) system?
> 
> your description of "compatible" is pretty vague.  ignoring /lib -> /lib64 
> symlink (which shouldnt matter to any binaries), i'm not aware of any 
> differences off the top of my head.

Well, "compatible" here means to me that when I do
$ configure --{build,host}=i686-pc-linux-gnu
on x86-linux, I'd like to expect this working on x86_64-linux too, as the
"_64" can be seen as an "extension"[1] to x86 I just do not want to use.

It turns out that it is the "/lib resolving to 64bit" thing only that
causes me headaches here, which actually is distro-specific.

[1] http://en.wikipedia.org/wiki/X86-64

/haubi/

Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib

[Michael Haubenwallner]

Mike Frysinger wrote:
> On Wednesday 21 October 2009 07:34:18 Michael Haubenwallner wrote:
>> Mike Frysinger wrote:
>>> On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
>>>> As I'm building the toolchain myself too, I configure it with the
>>>> 32bit host triplet on each platform, usually disabling multilib.
>>> this doesnt make any sense to me
>> What exactly doesn't make sense to you:
> 
> it doesnt make sense to build your own toolchain when the default native one 
> Gentoo provides includes all multilib support already.
> 
> but i guess when you're commercially developing a binary-only package, people 
> tend to not have such freedoms as the binary-only mentality infects all 
> layers.

Even if it's commercially, it isn't binary-only here. But it is bound
to a specific set of (likely older) toolchain versions usually not
available on the target system.
I just don't want to make an exception for Gentoo Linux hosts when it
does work on both RedHat and SuSE Linux as well as *nix.

>>>> Isn't the intention of multilib to have a new (64bit) system
>>>> be compatible with the corresponding old (32bit) system?
>>> your description of "compatible" is pretty vague.  ignoring /lib ->
>>> /lib64 symlink (which shouldnt matter to any binaries), i'm not aware of
>>> any differences off the top of my head.
>> Well, "compatible" here means to me that when I do
>> $ configure --{build,host}=i686-pc-linux-gnu
> 
> assuming you simply forgot the forcing of -m32 here, or you have a fully 
> named 
> i686-pc-linux-gnu-... toolchain

I do (like to) have a fully qualified i686-pc-linux-gnu-* toolchain.
Adding -m32 would require to create the i686-pc-linux-gnu-gcc wrapper,
resulting in some kind of a fully qualified i686 toolchain again.

>> It turns out that it is the "/lib resolving to 64bit" thing only that
>> causes me headaches here, which actually is distro-specific.
> 
> i'm not against changing things to fall in line with what other distros have 
> settled on (guess that's the risk you take when you're one of the first 
> distros to do multilib), i just want this kind of decision to be fully 
> informed / thought out before making it.  it's not something i'd label 
> "trivial".

Fully agreed. But as I don't have time to carry on this symlink change,
I'm going to live with the patches for now (in Prefix).
OTOH, Debian uses /lib->/lib64 symlink too IIRC...

Thank you!
/haubi/

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Michael Haubenwallner]

Alex Alexander wrote:
> On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
>> I sometimes think the main problem is the tree itself. Portage really
>> should had a directory of its own, but maybe with anoher structure,
>> like /var/portage, /var/portage/tree (the current
>> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
>> itself), /var/portage/overlays/layman or /var/portage/layman.
>> I of course realize that change the structure of the whole portdir would
>> had inresting complications, so take this comment just as serious as you
>> like.
 
> /var/portage/
> /var/portage/tree
> /var/portage/layman
> /var/portage/overlays (non-layman managed, layman could also be in here)
> /var/portage/distfiles
> /var/portage/packages

Not that I really care, but are these "portage-only" and we might need
/var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

[Michael Haubenwallner]

Tomáš Chvátal wrote:
> Hi,
> we prepared new eclass for x11 packages that should be used as
> replacement for x-modular.eclass.

> Prefix support done.

There's one thing I don't find addressed yet:

When some patch[1] necessary for some (prefix-) platform has to touch
configure.ac or Makefile.am, rendering eautoreconf mandatory on
*each* platform, there's no way to tell xorg-2_reconf_source() to
do the eautoreconf instead of elibtoolize *unconditionally*.

We had to have libXaw.ebuild do the eautoreconf unconditionally[2] after
x-modular_src_unpack() - which just did elibtoolize on some platforms,
causing elibtoolize to get run twice, resulting in bug#232820 [3].

Even if libXaw doesn't need those patches any more it seems,
there's no reason such patches won't become necessary again.

[1] 
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-libs/libXaw/files/libXaw-1.0.5-darwin.patch?rev=37037
[2] 
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-libs/libXaw/libXaw-1.0.6.ebuild?rev=49677#L43
[3] http://bugs.gentoo.org/show_bug.cgi?id=232820

/haubi/

PS: Just a suggestion what an ebuild could do in this case:
 src_prepare() {
 xorg-2_src_prepare --force-eautoreconf
 }
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

[Michael Haubenwallner]

Tomáš Chvátal wrote:
> Dne 22.2.2010 11:50, Michael Haubenwallner napsal(a):
>> PS: Just a suggestion what an ebuild could do in this case:
>>  src_prepare() {
>>  xorg-2_src_prepare --force-eautoreconf
>>  }
> SNAPSHOT="yes" xorg-2_src_prepare
> 
> ^ this does not fit your needs? It does exactly what you want :]

Uhh, this doesn't look like the "clean" way and depends on 
exakt knowledge how xorg-2_src_prepare works - shouldn't
eclasses provide something like an "intuitive API" to some
degree, especially if they are "new"?

However - I'll continue looking into the eclass impl details...

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

[Michael Haubenwallner]

Tomáš Chvátal wrote:
> and renamed snapshot variable into saner XORG_EAUTORECONF.

> Does it fit your needs?

Sane enough for me ;), thank you!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] RFC: fox.eclass update

[Michael Haubenwallner]

Must admit that I have no idea of what "fox" is at all, but:

On 09/16/2010 08:32 PM, Peter Volkov wrote:
> В Чтв, 16/09/2010 в 16:24 +0200, Matti Bickel пишет:
>> -   elibtoolize
>> +   eautoreconf
> 
> Hm, is this change necessary?

The obvious reason for eautoreconf here is:
fox_src_prepare() updates configure.{ac,in} and Makefile.am's just before.

The non-obvious reason is:
Ebuilds may have to patch these files too for random (usually prefix) platforms.

Iff not eautoreconf but elibtoolize were done here, the ebuild would have to do 
the
eautoreconf itself, which doesn't work right now[1] when elibtoolize was called 
before.

[1] http://bugs.gentoo.org/show_bug.cgi?id=232820

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree

[Michael Haubenwallner]

On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
> as I've only recently "graduated to developer", I've got a question about 
> this. Diego, your request makes perfect sense to me. But, so far I always 
> thought "Python, portage, and gcc are the things that I really need to rely 
> on, so whatever I do, I'll keep those stable."
> 
> (My development machine(s) are also my real-life work machines.)

As I do second these concerns, another thought:

While /portage/ is vital to our distro (not only) for end users (including
devs doing their workwork on Gentoo systems), /repoman/ isn't.

So - would it make sense to split repoman into its own ebuild?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] libstdc++ compatibility and -bin packages

[Michael Haubenwallner]

On 10/11/2010 04:40 PM, "Paweł Hajdan, Jr." wrote:
> Today I got http://bugs.gentoo.org/340517 filed against chromium-bin.
> The machine that compiled the package had only gcc-4.4.3 installed.
> 
> It'd probably be difficult to solve the problem using dependencies (the
> bug reporter had gcc-4.4.3 installed, but active version was 4.3.4).
> 
> I was thinking about using a lower version of gcc on the builder, like
> 4.1.2 or 4.3.4.
> 
> However, I'm not sure how likely this is to cause C++ ABI mismatch
> issues. I remember some problems with half of KDE compiler with one GCC
> version and half with a more recent version.
> 
> What do you think?

Iff the bug reporter would have selected gcc-4.4.3 being the active version
using 'gcc-config', his chrome should have been working IMO.

But I don't think this is an acceptable fix:

Instead, gcc-config should sort available gcc's libdirs into /etc/ld.so.conf
by /descending gcc-version independent of which one is currently selected/, as
gcc libraries are backwards compatible AFAICS when they have the same SONAME.

For linking, the selected compiler's libs are used anyway.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] new glep draft: Portage as a secondary package manager

[Michael Haubenwallner]

Hi ebuild devs,

Here's a glep draft now for (a part of) the long-term portage-goal
"act as a secondary package manager" ...

Comments welcome,
  haubi
-- 
Michael HaubenwallnerSALOMON Automation GmbH
Forschung & Entwicklung  A-8114 Friesach bei Graz
mailto:[EMAIL PROTECTED]  http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html

GLEP: XXX
Title: Portage as a secondary package manager
Version: $Revision: 1.5 $
Last Modified: $Date: 2005/04/27 09:29:06 $
Author: Michael Haubenwallner <[EMAIL PROTECTED]>
Status: Draft
Type: Standard Track
Content-Type: text/x-rst
Created: 25 Apr 2005
Post-History:


Abstract


When administrators have to compile and install third party packages on their
unix systems, most of the time they want to install them in a prefix other than
``/usr``. The common example is ``/usr/local``.

This document is intended to describe how to write ebuilds to work with both
primary (prefix ``/usr``) and secondary (other prefixes) portage instances,
and how portage has to be modified to get able to act as a secondary package
manager too.


Motivation
==

Right now, many of the administrators do maintain their self-compiled packages
even manually or with their own scripts.

As portage is already a package manager for a source-based Linux distribution,
the idea is to use it also as a secondary package manager for prefixes other
than ``/usr``.


Rationale
=

Currently, ``/usr`` is used hardcoded as the prefix in the ebuild-tree,
unless the portage provided functions econf/emake and the like are used.
If so, the prefix setting is delegated to those functions.

To get a prefix under portage's control, a portage instance has to be installed
into this prefix. To perform this install, just have recent python and bash
installed somewhere in PATH (they need not to be installed in destination
prefix) and install portage like most of other open source packages::

 $ bunzip2 < portage-XXX.tar.gz | tar xf -
 $ cd portage-XXX
 $ ./configure --prefix=/new/prefix
 $ make
 $ make install

Portage will create its own database there [#vdb]_.
This document prefers a filesystem hierarchy under this prefix as close as
possible to the current filesystem hierarchy used in Gentoo Linux [#FHS]_.

After setting up an ebuild-tree there and tweaking the parameters in
``/new/prefix/etc/make.conf``, ebuilds supporting such an installation can be
proceeded with this just installed portage. The ebuilds will install their
packages into the same prefix as portage is installed.


Changes for ebuilds
===

Portage will provide an environment variable ``PREFIX``, containing ``/usr``
when acting as the primary package manager (as in Gentoo Linux), or the prefix
it is installed to when acting as the secondary package manager for that prefix.

There are some difference between prefix ``/usr`` and other prefixes:
``/usr`` has its configuration-files, state-dirs and others in ``/``
(as ``/etc``, ``/var``, ``/other``) while ``/new/prefix`` has them directly in
``/new/prefix`` (as ``/new/prefix/etc``, ``/new/prefix/var``,
``/new/prefix/other``).

So there is one more variable needed to be set by portage to get the pathes
right for those dirs residing in ``/`` for prefix ``/usr``. This variable is
called ``AFFIX``, and is empty for prefix ``/usr``, but set to ``new/prefix/``
for prefix ``/new/prefix``, and to ``usr/local/`` for prefix ``/usr/local``.

The difference for the ebuild now is to use ``${PREFIX}`` and ``/${AFFIX}``
instead of hardcoded ``/usr`` and ``/``, like this::

   src_compile() {
 - ${S}/configure --prefix=/usr --sysconfdir=/etc
 + ${S}/configure --prefix=${PREFIX} --sysconfdir=/${AFFIX}etc
   make
   }

And of course, a new keyword [#keyword-glep]_ has to be added to the ebuild
to get a package unmasked for a platform where portage acts as a secondary
package manager.


Backwards Compatibility
===

To keep ebuilds working with old portage versions not setting PREFIX and AFFIX,
the default value for ``PREFIX`` can be set within the ebuild-tree in
``profiles/base/profile.bashrc`` like this::

 [[ -z $PREFIX ]] && PREFIX=/usr
 export PREFIX

The default value for ``AFFIX`` is empty and needs not to be set explicitly.


Implementation
==

A patch for portage to set ``PREFIX`` and ``AFFIX`` can already be found in
gentoo bugzilla [#bgo87877]_.


References
==

.. [#vdb] ``${PREFIX}/var/db/pkg``, for example ``/new/prefix/var/db/pkg``.

.. [#FHS] http://www.pathname.com/fhs/ with one exception:

FHS-2.3 says the variable data dir for ``/usr/local`` resides in
``/var/local``, and in ``/var/opt`` for prefix ``/opt`` while this
document will install them to ``/usr/local/var``, ``/opt/var`` or even
``/new/prefix/var``.

But there's also a possibility in FHS-2.3 to have ``/var/local`` and
``/var/opt`` as softlinks 

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Michael Haubenwallner]

Brian Harring wrote:
> On Mon, May 02, 2005 at 03:13:56PM +0100, Ciaran McCreesh wrote:

>>Why did you post this without addressing the problems I pointed out to
>>you previously? Writing something up as a GLEP doesn't magically fix all
>>the holes in it.
> 
> State said problem for the general community.  Guessing you're 
> referencing the issue/request that being able to manage home, and 
> 'global' installations?
> 
> I'd still posit that the issue of installing to a user's home when 
> portage's base prefix is /usr/local (fex) is a seperate issue.  What 
> you were requesting for vim plugins goes beyond haubi's initial 
> goals...

Exactly that, and according to glep 1 a glep should address just *one*
problem at once...

IMO a secondary package manager just has to manage the files/packages
installed into the same prefix the pkgm is installed to, nothing else.
If you want to use a pkgm for ~, then set up a pkgm with prefix=~,
and use an ebuild-tree or profile containing packages dedicated to
be installed into ~.

And once portage is able to act as a secondary pkgm, this does not imply
that the whole ebuild-tree makes sence to install with a 2nd pkg mgr,
fex baselayout, which is already virtualized for baselayout-lite
(eh, what is Linux VServer ?).

~haubi
-- 
Michael HaubenwallnerSALOMON Automation GmbH
Forschung & Entwicklung  A-8114 Friesach bei Graz
mailto:[EMAIL PROTECTED]  http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html


-- 
gentoo-dev@gentoo.org mailing list