[gentoo-dev] [PATCH] python-utils-r1.eclass: Change python_export_utf8_locale to deal with LC_ALL=C

Paludis sets LC_ALL=C to ensure a 'sane' build environment. We only want to override LC_CTYPE, so we break LC_ALL into separate LC_* overrides and set LC_ALL to blank. --- eclass/python-utils-r1.eclass | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git

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

2015-11-30 7:10 GMT+03:00 C Bergström : > > On Mon, Nov 30, 2015 at 10:56 AM, Gregory M. Turner wrote: > > I'm quoting myself from bug #566328 here. These were off-the-cuff > > remarks that got away from me and became a call-to-arms... > > > > (In

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

Dnia 30 listopada 2015 09:07:30 CET, "Anthony G. Basile" napisał(a): >On 11/30/15 1:42 AM, Michał Górny wrote: >> On Sun, 29 Nov 2015 19:56:04 -0800 >> "Gregory M. Turner" wrote: >> >>> I'm quoting myself from bug #566328 here. These were off-the-cuff

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

Dnia 30 listopada 2015 10:18:53 CET, "Gregory M. Turner" napisał(a): >On Sun, Nov 29, 2015 at 10:42 PM, Michał Górny >wrote: >> On Sun, 29 Nov 2015 19:56:04 -0800 >> "Gregory M. Turner" wrote: >> > the mess gets magically cleaned up by

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

On Mon, Nov 30, 2015 at 12:07 AM, Anthony G. Basile wrote: > If we record enough information at build time (eg. gcc version or > libcxx/clang) then we can build tools that intelligently predict if > there's an abi incompatibility. Yes, exactly the type of thing I'm thinking

Re: [gentoo-dev] [PATCH] eutils.eclass: In EAPI conditionals, replace "has" by case statements.

, Dnia 30 listopada 2015 07:52:59 CET, Ulrich Mueller napisał(a): >> On Mon, 30 Nov 2015, Davide Pesavento wrote: > >>> The patch below replaces them by case statements. (Unfortunately we >>> cannot use fall-through (&;) because it is a bash 4 feature.) > >> Sounds

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

> Perhaps a solution to this cxx11 clusterfuck can be found that works > more like perl? Or a "use vX" that simply causes the later version to behave like the earlier one? At that point a single flag/directive could keep things at least consistently behaving as if the upgrade never happend.

Re: [gentoo-dev] [PATCH] eutils.eclass: In EAPI conditionals, replace "has" by case statements.

On Mon, Nov 30, 2015 at 7:52 AM, Ulrich Mueller wrote: >> On Mon, 30 Nov 2015, Davide Pesavento wrote: > >>> The patch below replaces them by case statements. (Unfortunately we >>> cannot use fall-through (&;) because it is a bash 4 feature.) > >> Sounds reasonable, although

[gentoo-dev] [PATCH 6/8] systemd.eclass: Ban systemd_with_* in EAPI 6

Deprecate systemd_with_* and ban it in EAPI 6. Those are only convenience wrappers for systemd_get_* which barely save typing and are much less readable than explicit --with-* parameters. --- eclass/systemd.eclass | 10 ++ 1 file changed, 10 insertions(+) diff --git

[gentoo-dev] [PATCH 2/8] systemd.eclass: systemd_get_unitdir -> *systemunitdir for consistency

Rename systemd_get_unitdir to systemd_get_systemunitdir for consistency with other functions. Ban the old name in EAPI 6 onwards. --- eclass/systemd.eclass | 34 ++ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/eclass/systemd.eclass

[gentoo-dev] [PATCH 1/8] systemd.eclass: Introduce a common getter for systemd directories

Add a _systemd_get_dir function that serves as a common getter for all directories returned by the eclass. Add proper error handling for the variable getter. --- eclass/systemd.eclass | 38 +++--- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git

[gentoo-dev] [PATCH 3/8] systemd.eclass: Update the example for best practices

--- eclass/systemd.eclass | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass index 7dd914a..72771df 100644 --- a/eclass/systemd.eclass +++ b/eclass/systemd.eclass @@ -15,13 +15,12 @@ # inherit systemd # # src_configure() {

[gentoo-dev] [PATCH 8/8] systemd.eclass: Enable EAPI=6

--- eclass/systemd.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass index ae933aa..f6cc004 100644 --- a/eclass/systemd.eclass +++ b/eclass/systemd.eclass @@ -27,7 +27,7 @@ inherit toolchain-funcs case ${EAPI:-0} in -

[gentoo-dev] [PATCH 4/8] systemd.eclass: Remove long-deprecated systemd_to_myeconfargs

Remove systemd_to_myeconfargs function that was supposed to be removed 2013-10-11. It is no longer used by any ebuild in the repository. --- eclass/systemd.eclass | 19 +-- 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass

[gentoo-dev] [PATCH 7/8] systemd.eclass: Allow systemd_update_catalog only during pkg_post*

--- eclass/systemd.eclass | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass index c0c21a1..ae933aa 100644 --- a/eclass/systemd.eclass +++ b/eclass/systemd.eclass @@ -353,7 +353,7 @@ systemd_with_utildir() { # @FUNCTION:

[gentoo-dev] [PATCH 5/8] systemd.eclass: Add missing ||die on ntp file writes

--- eclass/systemd.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass index e4349bc..8ec0c5d 100644 --- a/eclass/systemd.eclass +++ b/eclass/systemd.eclass @@ -296,7 +296,7 @@ systemd_enable_ntpunit() { if [[ !

[gentoo-dev] [v2] systemd.eclass cleanup & EAPI 6 support

Hi, Here's an updated patch set. Two major changes: - systemd_get_unitdir replaced by systemd_get_systemunitdir, for consistency with other functions, - ban messages now explicitly suggest replacement. -- Best regards, Michał Górny

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

On Mon, Nov 30, 2015 at 10:34 AM, Greg Turner wrote: > https://youtu.be/Ic4j0ujWL-A looks interesting too. --> https://sourceware.org/libabigail/ -gmt Greg Turner g...@be-evil.net

Re: [gentoo-dev] [PATCH 8/8] virtualx.eclass: Simplify API into single virtx()

On Sat, Nov 28, 2015 at 4:50 PM, Justin Lecher (jlec) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 28/11/15 16:28, Davide Pesavento wrote: >>> else - nonfatal ${VIRTUALX_COMMAND} "$@" + >>> nonfatal "$@" >> >> Please take the opportunity to

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

https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html makes for pretty interesting reading on this topic. https://youtu.be/Ic4j0ujWL-A looks interesting too. -gmt -gmt Greg Turner g...@be-evil.net On Mon, Nov 30, 2015 at 3:31 AM, Anthony G. Basile wrote: >

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

One thing to point out.. trying to detect and using vX are just hacks for what this really is - Adding abi (C++STL/ABI) information to the ebuilds/packages. To extend this - what happens when you have a compiler that isn't compatible with the system default? When the package is merged should some

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

A quick grep in the tree shows the following existing cases (wrapped for line length). $ git grep -E \ 'keyword .*(lxc|systemd-nspawn|vserver|prefix|openvz|uml|jail|xen)' sys-apps/kmod/files/kmod-static-nodes-r1: keyword -lxc -systemd-nspawn sys-fs/eudev/files/udev-postmount:

Re: [gentoo-dev] Ban package.provided in next EAPI?

On Mon, Nov 30, 2015 at 9:15 AM, Ulrich Mueller wrote: > package.provided is listed in PMS as "strongly deprecated" and > "optional" since a long time. Does anybody still need the file as part > of a profile, or could we finally ban it in the next EAPI? > > (This is _not_ about

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

All, it has been proposed to me that we create a "container" keyword for OpenRC init scripts, which would take the place of the various keywords we have currently for separate container types, such as lxc, systemd-nspawn, etc (basically the values RC_SYS can be set to). We would keep all of the

Re: [gentoo-dev] Ban package.provided in next EAPI?

> On Mon, 30 Nov 2015, Mike Gilbert wrote: > On Mon, Nov 30, 2015 at 9:15 AM, Ulrich Mueller wrote: >> (This is _not_ about package.provided in /etc/portage which is >> Portage only and unspecified by PMS.) > I believe that Portage does not support package.provided in >

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

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

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

Yes, sorry my bad, repoman did not complain. 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

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

On Tue, 1 Dec 2015 08:45:53 +0200 Alon Bar-Lev wrote: > Yes, sorry my bad, repoman did not complain. Repoman only checks dependencies of the package you're running it on. If you want to check reverse dependencies, you'd have to run it on all of them (or on the whole repo, if

Re: [gentoo-dev] [PATCH 8/8] virtualx.eclass: Simplify API into single virtx()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30/11/15 18:40, Davide Pesavento wrote: > > The scenario of bug 517976 is different. I think a minimized test > case is the following (untested): > > foo() { die "meh" return 0 } > > src_test() { virtx foo } > This example will still break

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

On 11/30/15 1:42 AM, Michał Górny wrote: > On Sun, 29 Nov 2015 19:56:04 -0800 > "Gregory M. Turner" wrote: > >> I'm quoting myself from bug #566328 here. These were off-the-cuff >> remarks that got away from me and became a call-to-arms... >> >> (In reply to Michał Górny from

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

Actually, come to think of it, there's an even dumber, easier approach: just have some "is it c++" heuristics like, does it dynamically link to a libstdc++? Did it inhert qt.eclass? etc. So we have a boolean "is it probably a c++ package" heuristic boolean (or maybe a vector of per-compiler

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

On 11/30/15 4:52 AM, Michał Górny wrote: > > Dnia 30 listopada 2015 09:07:30 CET, "Anthony G. Basile" > napisał(a): >> On 11/30/15 1:42 AM, Michał Górny wrote: >>> On Sun, 29 Nov 2015 19:56:04 -0800 >>> "Gregory M. Turner" wrote: >>> I'm quoting

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

On 11/30/15 6:17 AM, Anthony G. Basile wrote: > different direction: what about building with > rpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/ and then making sure that > portage respects that library file during any --depclean or > @preserved-rebuild? i'm not sure how we'd > inject

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

On Sun, Nov 29, 2015 at 10:42 PM, Michał Górny wrote: > On Sun, 29 Nov 2015 19:56:04 -0800 > "Gregory M. Turner" wrote: > > the mess gets magically cleaned up by robots somehow. > > Sadly := can't help here since gcc switches occur independently of > package

[gentoo-dev] Ban package.provided in next EAPI?

package.provided is listed in PMS as "strongly deprecated" and "optional" since a long time. Does anybody still need the file as part of a profile, or could we finally ban it in the next EAPI? (This is _not_ about package.provided in /etc/portage which is Portage only and unspecified by PMS.)