Re: [gentoo-dev] impending c++11 clusterfuck?

[Gregory M. Turner]

On Wed, 2015-12-02 at 08:06 +0100, Michał Górny wrote:
> On Tue, 01 Dec 2015 18:12:17 -0800
> "Gregory M. Turner"  wrote:
> 
> > On Tue, 2015-12-01 at 07:18 -0500, Anthony G. Basile wrote:
> > > So on that bug we're talking about selectively
> > > adding -std=c++11 (or possibly gnu++11) to packages.  
> > 
> > Yes, this is the biggest real-world problem we face.  It requires
> > an
> > immediate solution in the ~* branches; the affected ebuilds just
> > dump a
> > bunch of gcc gobbldeygook and crash.
> > 
> > If I understand the generalized problem we are facing there, as a
> > package gets "c++11-ized", all of its reverse-BDEPs find themselves
> > in
> > the following situation:
> > 
> > Imagine cat/foo is a library.  cat/foo-3.0 is the newest non-c++11-
> > ized 
> > version (in its slot, perhaps).  Now cat/foo-3.1 comes along and
> > from
> > then on, anything BDEPENDing on it must be built with -std=c++11
> > (I'm
> > ignoring the c++11 vs. gnu++11 but presumably we'll eventually need
> > to
> > figure out some kind of game plan about that).
> 
> Just to be clear, this only happened because upstream started to use
> C++11 features in API. Normally libraries don't go that far, or use
> #ifs to support C++03.
> 
> > So, now, "everything" pulling in headers from  cat/foo finds itself
> > in
> > this situation:
> > 
> >  o if it pulls in headers from  >  o if it pulls in headers from >=cat/foo-3.1, we must add a CFLAG
> > 
> > I guess the reasonable way to achieve that sort of behavior is
> > pkgconfig (which is not really a rock-solid solution.  First, some
> > packages might fail to put it in there (but, OK we just add it
> > ourselves, let's say).  Second, how many of cat/foo's reverse BDEPs
> > side-step pkgconfig?  Sometimes this is pretty common, I'm afraid.
> >  
> 
> pkg-config is not a solution. -std= flags don't belong there.
> Furthermore, if you put -std= flags there, it is likely to override
> ${CXXFLAGS} and in particular make it really painful to force other
> standard on ebuild's end.

I see what you mean.  Maybe pkgconfig needs a new feature?  I wonder if
they are already thinking about it in pkgconfig-land.  I'll look around
on their ml/bugdb and see if I can find anything.

> > So, let's say lots of packages depending on cat/foo have this
> > pkgconfig
> > side-stepping problem, we could theoretically write some eclass to
> > inject it when appropriate, and expect those side-stepping ebuilds
> > to
> > consume it, no?  That seems pretty easy and hopefully wouldn't
> > require
> > any of the scary ideas that have been discussed in this thread.
> 
> So you're saying we should write a whole eclass to do:
> 
>   append-cppflags -std=c++11
> 
> ?

If we could just do "append-cppflags" somewhere, it'd be a non-bug as
we would have just done it.  That doesn't seem to be the case.

If I'm not mixed up, the difficulty is determining /when/ that's
appropriate.  Specifically, this c++11 requirement can bubble up
indirectly through deep dependencies or even non-DEPENDencies.  Source
file "X" just needs to #include header "Y" that #include's header "Z"
with the c++11 requirement, and "kablooey!".

So, yeah, an eclass that figures out when to append the flag (and then,
as you say, appends it) doesn't seem so crazy to me.

For example: if we can identify the dependencies, deep, hidden, or not,
that cause these failures (i.e., by waiting for bugzilla reports and
acting on them), we could pretty trivially fix them with such an
eclass.

So, just imagining one possible implementation of that, here's a
possible user-story -- which I mean, an eclass user (and therefore and
ebuild or eclass developer, but developer-story isn't a word afaik):

Bug wranglers observe that www-client/frobzilla ebuilds are crashing
due to headers, which are coming, ultimately, from net-libs/tldr. 

Assignees of the bug would:

o figure out which versions of net-libs/tldr trigger the problem
  and ensure they are selected by the hand-crafted list of
  DEPENDency specifiers that live in cxx11reqs.eclass.

o add the following code to all affected www-client/frobzilla ebuilds:

  CXX11REQ_CULPRITS=( net-libs/tldr )
  inherit cxx11reqs

This would cause the right thing to happen (CXXFLAGS augmentation) when
and only when the affected versions of tldr are installed.

Only thing left to do is to check that frobzilla doesn't strip the flag
back out, for some reason; if it did, perhaps it could add it back in,
by calling a xxx11reqs eclass API.

Note that frobzilla might not even DEPEND on tldr (not even indirectly
through several layers of DEPENDency); this would still do the trick;
the eclass could just use has_version to find out if the flag is
needed, according to a hand-crafted dependency specifier table.

I guess as far as bright ideas go, that's the best I've got, for now.

If a fully automagical solution is practical to implement, I haven't
yet imagined it.

-gmt

Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

[Alexis Ballier]

On Sat, 28 Nov 2015 22:14:39 +0100
Ulrich Mueller  wrote:

> As you may know, we intend to move the functionality of
> versionator.eclass to the package manager, possibly in EAPI 7.
> The following is what mgorny and myself have come up with, see
> bug 482170 [1], especially comments 15 and 16 there.
> 
> Currently there are 15 functions defined in that eclass, and we
> believe that it will not be feasible to implement all of them.
> However, several of the functions are similar to each other and can
> be combined. Two of them, namely get_version_component_range() and
> replace_version_separator(), account for the vast majority of what
> is used by ebuilds.
> 
> We therefore think that the following three functions would be
> sufficient to cover all ebuilds' needs:

What's the point, need or advantage in moving this to all-ebuild-scope?

Usually eclass refactor/api cleanup are done in a -r{n+1} while
deprecating -rn. This would have the advantage that you can quickly
post a complete implementation and get wider reviews.

Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7

[Alexis Ballier]

On Tue, 1 Dec 2015 18:45:20 +0100
Michał Górny  wrote:

> On Tue, 1 Dec 2015 11:38:08 -0600
> William Hubbs  wrote:
> 
> > I find the multilib eclasses and their separate multilib phase
> > functions to be confusing, so I was wondering if we could discuss
> > making multilib support native to portage in eapi 7 so that we can
> > use the normal phase functions again?  
> 
> That won't help you since the in-spec support would require special
> phase functions anyway.


Not really. PM can call something like 'multilib_foreach_abi
src_compile'. This would actually simplify stacking: e.g. cmake +
multilib wouldnt require an extra eclass.

Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

[Alexis Ballier]

Wow, what a lengthy email :)

On Tue, 1 Dec 2015 22:58:55 +
James Le Cuirot  wrote:
[...]
> 
> I raised one further point with mgorny that he feels could potentially
> go into EAPI 7 but I think could remain an implementation detail. In
> cases #3 and #4 (basically when ROOT != / and
> PORTAGE_CONFIGROOT != /), the toolchain needs to know how to source
> headers and libraries from ROOT instead of /.

Use SYSROOT. ROOT has nothing to do with building. This should be
defined in PMS though.


> gcc and friends support a --sysroot argument. It used to be the case
> that this didn't work on a toolchain configured without a sysroot,
> possibly creating issues for #4, but I've tested and it now works
> regardless.

$ gcc --sysroot=/tmp/foo -I/usr/include foo.c
/usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
this linker was not configured to use sysroots
collect2: error: ld returned 1 exit status

Two problems here:
1. link fails
2. gcc doesn't warn for -I/usr/include with sysroot (iirc crossdev's
gcc do)

[...]
> CMake supports a CMAKE_SYSROOT argument that you set in the toolchain
> file. We currently don't set this but it could easily be added to
> cmake-utils.eclass as well as (or instead of?) the similar variables
> that we already do set.

iirc, CMAKE_SYSROOT is only for your case #4 and behaves more like
'build as if I had chrooted in CMAKE_SYSROOT' and thus doesn't help at
all for cross-compilation

> The vast majority of configure scripts (using libtool and not ancient)
> support a --with-sysroot argument that can easily be detected by
> grepping for lt_sysroot. The behaviour of econf is largely defined by
> PMS, hence why mgorny thinks this particular detail could go into
> EAPI 7, but it only says which arguments must be passed and doesn't
> say that the PM can't pass additional ones. I don't wish this force
> this stuff upon Paludis and pkgcore unnecessarily.


This could help your case #4. Or, e.g., stage building:
https://bugs.gentoo.org/show_bug.cgi?id=563034

toolchain's sysroot seems way more reliable though

[...]

Alexis.

Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

[Ulrich Mueller]

> On Wed, 2 Dec 2015, Alexis Ballier wrote:

> What's the point, need or advantage in moving this to all-ebuild-scope?

> Usually eclass refactor/api cleanup are done in a -r{n+1} while
> deprecating -rn. This would have the advantage that you can quickly
> post a complete implementation and get wider reviews.

A proof-of-concept implementation for the two version manipulation
functions is here:
https://482170.bugs.gentoo.org/attachment.cgi?id=418072
Add some comments and you'll have a working eclass. :)

Some details are still to be discussed, e.g. what should be the
behaviour if the version string starts or ends with a separator?

Also version_test is missing, but the idea there was to avoid
redundancy and use the implementation that already exists in the
package manager (which does version comparison all the time). This is
one of the reasons for moving it to the package manager.

Ulrich


pgpfAcHBwp126.pgp
Description: PGP signature

Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

[Alexis Ballier]

On Wed, 2 Dec 2015 13:04:19 +0100
Ulrich Mueller  wrote:

> > On Wed, 2 Dec 2015, Alexis Ballier wrote:  
> 
> > What's the point, need or advantage in moving this to
> > all-ebuild-scope?  
> 
> > Usually eclass refactor/api cleanup are done in a -r{n+1} while
> > deprecating -rn. This would have the advantage that you can quickly
> > post a complete implementation and get wider reviews.  
> 
> A proof-of-concept implementation for the two version manipulation
> functions is here:
> https://482170.bugs.gentoo.org/attachment.cgi?id=418072
> Add some comments and you'll have a working eclass. :)

Yes, but I don't see the point of defining bash code in PMS and
copy/pasting it in every compliant PM, when said code used to be in
only one place. Sounds like a "regression" to me.


[...]
> Also version_test is missing, but the idea there was to avoid
> redundancy and use the implementation that already exists in the
> package manager (which does version comparison all the time). This is
> one of the reasons for moving it to the package manager.


well, then maybe version_test is the only one that makes sense to be
added to PM. Though it is unclear to me how to interface it: spawning a
python interp. every time the function is called doesn't seem to be a
terrible idea wrt performance.

Re: [gentoo-dev] impending c++11 clusterfuck?

[Patrick Lauer]

On 12/02/2015 08:38 AM, Anthony G. Basile wrote:
> On 12/2/15 2:06 AM, Michał Górny wrote:
>> So you're saying we should write a whole eclass to do:
>>
>>   append-cppflags -std=c++11
>>
>> ?
>>
> I think you mean append-cxxflags.  Anyhow, I had an off list discussion
> with David Klaftenegger about the semantic difference between c++11 and
> 98 with respect to their atomics and I'm convinced that a global
> -std=c++11 could get us into trouble on packages that make use of
> threading.  So drop my idea of global c++11 and you'll have to catch
> these on a per package basis.
>
Could we use something along the lines of a use_expand'ed variable?

CXX_ABI="03"

==> DEPEND="dev-libs/boost[cxx_abi_03]"

Would need some CFLAGS injection, but like this any C++ packages can be
forced to 'same' ABI in a more reasonable fashion, and it wouldn't
require global overrides.
 

Re: [gentoo-dev] impending c++11 clusterfuck?

[Michał Górny]

Dnia 2 grudnia 2015 11:00:20 CET, "Gregory M. Turner"  
napisał(a):
>On Wed, 2015-12-02 at 08:06 +0100, Michał Górny wrote:
>> On Tue, 01 Dec 2015 18:12:17 -0800
>> "Gregory M. Turner"  wrote:
>> 
>> > On Tue, 2015-12-01 at 07:18 -0500, Anthony G. Basile wrote:
>> > > So on that bug we're talking about selectively
>> > > adding -std=c++11 (or possibly gnu++11) to packages.  
>> > 
>> > Yes, this is the biggest real-world problem we face.  It requires
>> > an
>> > immediate solution in the ~* branches; the affected ebuilds just
>> > dump a
>> > bunch of gcc gobbldeygook and crash.
>> > 
>> > If I understand the generalized problem we are facing there, as a
>> > package gets "c++11-ized", all of its reverse-BDEPs find themselves
>> > in
>> > the following situation:
>> > 
>> > Imagine cat/foo is a library.  cat/foo-3.0 is the newest non-c++11-
>> > ized 
>> > version (in its slot, perhaps).  Now cat/foo-3.1 comes along and
>> > from
>> > then on, anything BDEPENDing on it must be built with -std=c++11
>> > (I'm
>> > ignoring the c++11 vs. gnu++11 but presumably we'll eventually need
>> > to
>> > figure out some kind of game plan about that).
>> 
>> Just to be clear, this only happened because upstream started to use
>> C++11 features in API. Normally libraries don't go that far, or use
>> #ifs to support C++03.
>> 
>> > So, now, "everything" pulling in headers from  cat/foo finds itself
>> > in
>> > this situation:
>> > 
>> >  o if it pulls in headers from > >  o if it pulls in headers from >=cat/foo-3.1, we must add a CFLAG
>> > 
>> > I guess the reasonable way to achieve that sort of behavior is
>> > pkgconfig (which is not really a rock-solid solution.  First, some
>> > packages might fail to put it in there (but, OK we just add it
>> > ourselves, let's say).  Second, how many of cat/foo's reverse BDEPs
>> > side-step pkgconfig?  Sometimes this is pretty common, I'm afraid.
>> >  
>> 
>> pkg-config is not a solution. -std= flags don't belong there.
>> Furthermore, if you put -std= flags there, it is likely to override
>> ${CXXFLAGS} and in particular make it really painful to force other
>> standard on ebuild's end.
>
>I see what you mean.  Maybe pkgconfig needs a new feature?  I wonder if
>they are already thinking about it in pkgconfig-land.  I'll look around
>on their ml/bugdb and see if I can find anything.

Please don't. Pkg-config is already bad enough as it is, and they are known to 
break stuff without any concern for compatibility.

>
>> > So, let's say lots of packages depending on cat/foo have this
>> > pkgconfig
>> > side-stepping problem, we could theoretically write some eclass to
>> > inject it when appropriate, and expect those side-stepping ebuilds
>> > to
>> > consume it, no?  That seems pretty easy and hopefully wouldn't
>> > require
>> > any of the scary ideas that have been discussed in this thread.
>> 
>> So you're saying we should write a whole eclass to do:
>> 
>>   append-cppflags -std=c++11
>> 
>> ?
>
>If we could just do "append-cppflags" somewhere, it'd be a non-bug as
>we would have just done it.  That doesn't seem to be the case.
>
>If I'm not mixed up, the difficulty is determining /when/ that's
>appropriate.  Specifically, this c++11 requirement can bubble up
>indirectly through deep dependencies or even non-DEPENDencies.  Source
>file "X" just needs to #include header "Y" that #include's header "Z"
>with the c++11 requirement, and "kablooey!".
>
>So, yeah, an eclass that figures out when to append the flag (and then,
>as you say, appends it) doesn't seem so crazy to me.
>
>For example: if we can identify the dependencies, deep, hidden, or not,
>that cause these failures (i.e., by waiting for bugzilla reports and
>acting on them), we could pretty trivially fix them with such an
>eclass.
>
>So, just imagining one possible implementation of that, here's a
>possible user-story -- which I mean, an eclass user (and therefore and
>ebuild or eclass developer, but developer-story isn't a word afaik):
>
>Bug wranglers observe that www-client/frobzilla ebuilds are crashing
>due to headers, which are coming, ultimately, from net-libs/tldr. 
>
>Assignees of the bug would:
>
>o figure out which versions of net-libs/tldr trigger the problem
>  and ensure they are selected by the hand-crafted list of
>  DEPENDency specifiers that live in cxx11reqs.eclass.
>
>o add the following code to all affected www-client/frobzilla ebuilds:
>
>  CXX11REQ_CULPRITS=( net-libs/tldr )
>  inherit cxx11reqs
>
>This would cause the right thing to happen (CXXFLAGS augmentation) when
>and only when the affected versions of tldr are installed.
>
>Only thing left to do is to check that frobzilla doesn't strip the flag
>back out, for some reason; if it did, perhaps it could add it back in,
>by calling a xxx11reqs eclass API.
>
>Note that frobzilla might not even DEPEND on tldr (not even indirectly
>through several layers of DEPENDency); this would still do the trick;
>the eclass could just use has_version to fi

[gentoo-dev] Last rites: dev-php/pecl-zendopcache

[Brian Evans]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

# Brian Evans  (02 Dec 2015)
# Zend Opcache was integrated into PHP versions 5.5 and later
# PHP 5.4 is End of Life and masked for admins to migrate
# Masked for removal in 30 days
dev-php/pecl-zendopcache

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWXwg5AAoJENH3ge/59KO2BjwQAKpDt/Hov6XP45+kQxbkbMsD
PCnLxK5hvuf13ooTbyAfVpqRMlwKP5NQI792iAgBLwY8vE+XWBpSOwv/HMXyIoJ+
cLe1toJY3QIKZ0MDcbJRVooKV4JTsTrdbI89v/AETU7NTWvr34KOUq6rqqEv8VKk
mgXV3AfKEwmP7mJKM8G7KDSvugvXHRumyF3+ZNWgc+BJ4PNgxIquSC7zv5MRPfMA
0Lnir01eA17Ly+g9f52BzOD2pNob5/804NHfwoEwJG/lHaeBvHNoU8S3VWfVb8MM
76AtdPyLWVZDkBQ15D4WXQuwdLJgADgTviXwvGYv2WT1wf/pilhyOu6M+V1e+sbg
gzmQm93D1BkTgICOAAoDfBIftChNLq60CI/gy1JopLFp0aQ+C0nSefwINvcR57Ks
8r13ZN6+X6McntDPWKy+Jp3/nVCJqMm7x3qcsl8UcIIbaLtnkErMrUvVTDJSaYG2
3kkat/vDrFIlZm0b6IDhgIei61POFYuU4ekepVNqzYah6TU8TsgFfhcRtwL8W5dG
rbght9OaOjEdl8iuMKxWojedAxL0Nn/zHrCx2Pyt0SorMkr7/mY2HVT2xtXdC5Oj
5163lonDRSSqlr5BLVgP6DPcL4ldlwsvAbODfbxAKTYQbnHvJ05sgBh2DGG1B5dB
DBVkLpawFuRYpIPrLtSD
=bWsN
-END PGP SIGNATURE-

Re: [gentoo-dev] New arches??

[Mike Frysinger]

On 26 Nov 2015 20:43, Andreas K. Huettel wrote:
> just curious, where did "riscv" come from
> 
> (and nios2, but that seem's to have been around for longer...)

people are testing/working on them, and adding them to the profile
makes things simpler.  whether they mature enough to start adding
to ebuilds has yet to be seen, but there's no overhead in being in
the profile.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7

[Mike Frysinger]

On 01 Dec 2015 11:38, William Hubbs wrote:
> I find the multilib eclasses and their separate multilib phase functions
> to be confusing, so I was wondering if we could discuss making multilib
> support native to portage in eapi 7 so that we can use the normal phase
> functions again?

we cannot hardcode the actual ABIs in PMS because adding/removing ones
would require an EAPI update which is a terrible idea

i don't see a benefit in adding the helper/phase functions either and
wouldn't actually address your concern: you'd still need to know the
API and how to use them.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/

[Brian Evans]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/1/2015 1:45 AM, Alon Bar-Lev wrote:
> Yes, sorry my bad, repoman did not complain.

This is still not working because some packages, i.e sys-fs/ntfs3g,
have a dependency like  
> On 1 December 2015 at 08:44, Michał Górny 
> wrote:
>> On Tue,  1 Dec 2015 06:16:40 + (UTC) "Alon Bar-Lev"
>>  wrote:
>> 
>>> commit: 1519f072b810c69428badbe5fc54960f1a2a12b3 Author:
>>> Alon Bar-Lev  gentoo  org> AuthorDate: Tue Dec
>>> 1 06:16:26 2015 + Commit: Alon Bar-Lev 
>>> gentoo  org> CommitDate: Tue Dec  1 06:16:26 2015 + 
>>> URL:
>>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1519f072
>>> 
>>> dev-libs/libgcrypt: cleanup
>>> 
>>> Package-Manager: portage-2.2.20.1
>>> 
>>> dev-libs/libgcrypt/Manifest|  1 - 
>>> .../libgcrypt/files/libgcrypt-1.5.0-uscore.patch   | 33
>>> - .../files/libgcrypt-1.5.4-clang-arm.patch  |
>>> 84 -- 
>>> dev-libs/libgcrypt/libgcrypt-1.5.4-r1.ebuild   | 57
>>> --- dev-libs/libgcrypt/libgcrypt-1.5.4-r100.ebuild
>>> | 58 ---
>> 
>> Isn't the point of compatibility slots like :11 there that they
>> should be kept for binary packages to work? Because you just
>> removed that, plus all 1.5* versions, effectively causing huge
>> breakage:
>> 
>> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/2.html#l1193
>>
>> 
https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/2.html#l1219
>> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1082
>>
>> 
https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1108
>> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1134
>>
>> 
https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1997
>> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l208
>>
>> 
https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l234
>> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l249
>>
>> 
https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l460
>> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/12.html#l898
>>
>> 
https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/12.html#l2088
>> 
>> Please fix this ASAP and next time check reverse dependencies
>> before removing packages.
>> 
>> -- Best regards, Michał Górny 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWX0pBAAoJENH3ge/59KO2paIP/2HD9sGS51V3SblZlC28YHLv
96eBOqlmaWbYlOPsHjYvnTot4B3bQauLeobAEWsmOQ5nTaPW1qPD2jjli6+p48lB
KBlU1n6RP6JSoaTet5fiAxe65Ih4/rEb24de0MniF4pAtU6U+QP01wW59pHrgWlj
pe6PafUtAiW7RdnoZ5t/QKmrnJYd1qYk7KsJMo+xZYqejKi6QJaURnrExI9A4X3e
kxcDHOv1ugyQUW3SKOeyUXNi8Hxuhvod5ENYrPdIxWBvS4ncXgmh61vCfQCbTLY4
VbkMCh5mnnrbfWLRb2btucqP2N+PhAUkGh0rtD5ELNrmznWMDZoUuFD2SNEPZN8Q
UOpEWbIIF2YfxMIukfPfibEJ4fWch8GnnOfhUwulitjLLZ1Cx+tFOlvWKFNxf0Fp
Qo2LfWULiu220ocF6TAig3uCdWV0sL5qfCHGyno28aMfhXET81umzc1IHhWTeZcs
jkCE6cq9HYybZ0wAGGp7IWoyqOnsrE3/0QubiLXICb48AhxuqRIeSmllfrmn+B4O
K9l4+KQaX3pSuudakm23HaNVhpRaAq/OjX1phTXJO8EvAjgyWv0TKVMihrSp5dDj
smINjuwHkV3PnK5L3c+enNT9P65sZrNAU1IqoDtVpGzJgEyZyZ/gD7QYBUFcj69/
bqHlLvtROzoUv4/S8R0E
=zvh3
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/

[Alon Bar-Lev]

On 2 December 2015 at 21:45, Brian Evans  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/1/2015 1:45 AM, Alon Bar-Lev wrote:
> > Yes, sorry my bad, repoman did not complain.
>
> This is still not working because some packages, i.e sys-fs/ntfs3g,
> have a dependency like 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/

[Michał Górny]

On Wed, 2 Dec 2015 21:48:24 +0200
Alon Bar-Lev  wrote:

> On 2 December 2015 at 21:45, Brian Evans  wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 12/1/2015 1:45 AM, Alon Bar-Lev wrote:  
> > > Yes, sorry my bad, repoman did not complain.  
> >
> > This is still not working because some packages, i.e sys-fs/ntfs3g,
> > have a dependency like  
> in this specific case ntfs3g-2014.2.15-r1 is stable the previous
> versions should be cleaned up.

It is *your* responsibility to ensure that previous versions are
cleaned up *before* you remove libgcrypt. Also, I'm more worried about
sys-power/suspend where the stable version still requires it. And yes,
you've broken the stable tree and I'd really appreciate having it fixed
right away.

-- 
Best regards,
Michał Górny



pgpKCTolfBpp0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/

[Alon Bar-Lev]

On 2 December 2015 at 21:52, Michał Górny  wrote:
> On Wed, 2 Dec 2015 21:48:24 +0200
> Alon Bar-Lev  wrote:
>
>> On 2 December 2015 at 21:45, Brian Evans  wrote:
>> >
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 12/1/2015 1:45 AM, Alon Bar-Lev wrote:
>> > > Yes, sorry my bad, repoman did not complain.
>> >
>> > This is still not working because some packages, i.e sys-fs/ntfs3g,
>> > have a dependency like >
>> in this specific case ntfs3g-2014.2.15-r1 is stable the previous
>> versions should be cleaned up.
>
> It is *your* responsibility to ensure that previous versions are
> cleaned up *before* you remove libgcrypt. Also, I'm more worried about
> sys-power/suspend where the stable version still requires it. And yes,
> you've broken the stable tree and I'd really appreciate having it fixed
> right away.

OK, done.

>
> --
> Best regards,
> Michał Górny
> 

Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

[James Le Cuirot]

On Wed, 2 Dec 2015 12:40:08 +0100
Alexis Ballier  wrote:

> On Tue, 1 Dec 2015 22:58:55 +
> James Le Cuirot  wrote:
> [...]
> > 
> > I raised one further point with mgorny that he feels could
> > potentially go into EAPI 7 but I think could remain an
> > implementation detail. In cases #3 and #4 (basically when ROOT != /
> > and PORTAGE_CONFIGROOT != /), the toolchain needs to know how to
> > source headers and libraries from ROOT instead of /.
> 
> Use SYSROOT. ROOT has nothing to do with building. This should be
> defined in PMS though.

In case #2, ROOT != / but SYSROOT = / so I take your point that SYSROOT
would negate the need to check which use case we're dealing with.

I looked into SYSROOT while I was writing cross-boss. It's used in some
crossdev scripts, most notably cross-pkg-config, but not by pkg-config
itself. It's also used in a small handful of eclasses and other *-config
scripts but that's all. Conversely, the aforementioned libtool patch
uses ROOT and I suspect many other things do too. In practise, you need
to set both.

On reflection, I'm now thinking that we should call it something less
generic. I also found that the Qt build uses SYSROOT for its own
purposes so you cannot rely on it in toolchain wrappers. ROOT is
probably just as unreliable. For that reason, I ended up using
CB_SYSROOT in cross-boss.

I forgot to mention earlier that if ROOT were used, PMS actually
forbids it from being referenced in the src_* phases so this
restriction would need to be lifted. Relying on the toolchain's
internal sysroot is not sufficient.

> > gcc and friends support a --sysroot argument. It used to be the case
> > that this didn't work on a toolchain configured without a sysroot,
> > possibly creating issues for #4, but I've tested and it now works
> > regardless.
> 
> $ gcc --sysroot=/tmp/foo -I/usr/include foo.c
> /usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> this linker was not configured to use sysroots
> collect2: error: ld returned 1 exit status
> 
> Two problems here:
> 1. link fails
> 2. gcc doesn't warn for -I/usr/include with sysroot (iirc crossdev's
> gcc do)

Yeah, turns out my hello.c test was not sufficient. It seems gcc is
fine with it but binutils isn't. This seems silly to me so maybe this
could be patched out or perhaps building the native binutils with
--with-sysroot=/ would work?

I know about -Wpoison-system-directories. We only enable it for
cross-compilers but I think it only triggers when cross-compiling
anyway. It's a shame they didn't make it dependent on --sysroot
instead.

To be honest, these points are only an issue for #4, which is a use
case that I don't particularly care about. I only mentioned it because
I wanted to know if others were interested and what they expected from
it. Both problems can be worked around with an "x86_64-cross-linux-gnu"
toolchain, which is probably the only sane way to do this anyway for
the reasons I mentioned in the previous mail.

> [...]
> > CMake supports a CMAKE_SYSROOT argument that you set in the
> > toolchain file. We currently don't set this but it could easily be
> > added to cmake-utils.eclass as well as (or instead of?) the similar
> > variables that we already do set.
> 
> iirc, CMAKE_SYSROOT is only for your case #4 and behaves more like
> 'build as if I had chrooted in CMAKE_SYSROOT' and thus doesn't help at
> all for cross-compilation

Even without CMAKE_SYSROOT, since fixing the toolchain file stuff in
cmake-utils.eclass a little while back, CMake has actually been doing a
very good job of cross-compiling anyway. I doubt setting this would
make it any worse.

> This could help your case #4. Or, e.g., stage building:
> https://bugs.gentoo.org/show_bug.cgi?id=563034

I touched on these issues, including the subslot problem, in my
previous mail but it's good to know I'm not the only one who noticed.
This is really case #2 though. drobbins is using the same Portage
configuration so ensuring / is up to date should be sufficient. You
don't want to muddy that use case with the more tricky aspects of #4.

> toolchain's sysroot seems way more reliable though

As I said above, it only gets you so far. Trust me, I've seen enough
autotools failures to know. :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpwLmdl04aGg.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: generic "container" keyword for init scripts

[William Hubbs]

On Tue, Dec 01, 2015 at 03:28:44PM -0600, William Hubbs wrote:
> On Tue, Dec 01, 2015 at 11:21:49AM -0800, Zac Medico wrote:
> > On 12/01/2015 10:19 AM, William Hubbs wrote:
> > > On Tue, Dec 01, 2015 at 11:26:19AM -0600, William Hubbs wrote:
> > >> On Tue, Dec 01, 2015 at 09:00:55AM -0800, Zac Medico wrote:
> > >>> On 12/01/2015 08:50 AM, William Hubbs wrote:
> >  The "container" keyword, being generic, would have its meaning expanded
> >  to cover new container systems as they come along. This means if a
> >  service script has the keyword "-container" it will not work under any
> >  current or future container systems. On the other hand, adding
> >  "container" means it will work under all of them.
> > >>>
> > >>> If it's similar to how license groups work, then there is room for doing
> > >>> things like "-@container docker" which means no containers except
> > >>> docker, or "@container -docker" which means all containers except
> > >>> docker. Keyword groups can be implemented using a simple expansion
> > >>> mechanism, just like license groups.
> > >>  
> > >> Keyword groups are an interesting idea; I'll think about this approach.
> > > 
> > > One question that comes to mind is,, who defines which keywords go in
> > > each group?
> > > 
> > > The containers or virtualization systems themselves can be autodetected
> > > so they are the same everywhere, but keyword groups are not able to be
> > > detected.
> > 
> > The groups should go in a configuration file somewhere. For example,
> > they could be defined in rc.conf with a variable setting like this:
> > 
> > rc_keyword_group_container="docker lxc openvz vserver"
> 
> If we keep the keywords as they are, I am starting to think we can just
> add a container keyword that would be valid for all of the containers;
> that way a script could be set up to work for no containers or for
> specific ones like we are talking about.
 
Here is where my thoughts are on this now. There will be a
"-containers" keyword, which will expand to list all of the containers
 we can detect on the operating system OpenRC is running on -- for
 example, on Linux it might be:

 "-docker -lxc -openvz -rkt -systemd-nspawn -vserver"

 So any time you list -containers as a keyword it would expand
 appropriately.

> OpenRC currently doesn't do any detection of virtual machines, so maybe
> that could be another expansion of this -- add a keyword "vm" and
> keywords for the virtual machines.
 
 VM's will be a separate project that I will look at later.

Thoughts?

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: generic "container" keyword for init scripts

[Zac Medico]

On 12/02/2015 03:49 PM, William Hubbs wrote:
> On Tue, Dec 01, 2015 at 03:28:44PM -0600, William Hubbs wrote:
> Here is where my thoughts are on this now. There will be a
> "-containers" keyword, which will expand to list all of the containers
>  we can detect on the operating system OpenRC is running on -- for
>  example, on Linux it might be:
> 
>  "-docker -lxc -openvz -rkt -systemd-nspawn -vserver"
> 
>  So any time you list -containers as a keyword it would expand
>  appropriately.

Sounds good.

>> OpenRC currently doesn't do any detection of virtual machines, so maybe
>> that could be another expansion of this -- add a keyword "vm" and
>> keywords for the virtual machines.
>  
>  VM's will be a separate project that I will look at later.
> 
> Thoughts?

How about a bare-metal keyword?
-- 
Thanks,
Zac