Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

2013-04-13 Thread Fabio Erculiani
On Fri, Apr 12, 2013 at 10:41 PM, Tom Wijsman tom...@gentoo.org wrote: Hello everyone Attached you will find the various changes I plan to apply to kernel-2.eclass after a week if there are no objections, feel free to take a look at them. A summary of the changes: - Added a warning after

Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

2013-04-13 Thread Tom Wijsman
On Sat, 13 Apr 2013 08:03:22 +0100 Fabio Erculiani lx...@gentoo.org wrote: Why? Because people (eg. you) use the undocumented variable KERNEL_BASE_URI. Just to annoy people who have successfully used kernel-2.eclass until now, and in my case for half a decade (or even more)? If you use an

[gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix.

2013-04-13 Thread Michał Górny
The edos2unix is quite useful when handling DOS-sourced packages. But since it's a bash function, you can't reasonably use it from within find invocation. And often you hit packages which are all flooded with CRLFs that you need to convert. That's why I'm suggesting to make edos2unix recursive.

[gentoo-dev] Re: Pass ${@} in phase functions Re: [PATCH] Introduce cmake-multilib wrapper for cmake-utils.

2013-04-13 Thread Steven J. Long
On Sat, Apr 13, 2013 at 03:04:51AM +0200, Michael Weber wrote: I'm not sure if it's a sane way to push make -j1 via src_compile() { cmake-multilib_src_compile -j1 } but I detected a lack of functionality in the current cmake-multilib.eclass. Both cmake-utils.eclass and

Re: Pass ${@} in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.

2013-04-13 Thread Michał Górny
On Sat, 13 Apr 2013 03:04:51 +0200 Michael Weber x...@gentoo.org wrote: Hi, I'm not sure if it's a sane way to push make -j1 via src_compile() { cmake-multilib_src_compile -j1 } but I detected a lack of functionality in the current cmake-multilib.eclass. Both cmake-utils.eclass

Re: [gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix.

2013-04-13 Thread Mike Gilbert
On Sat, Apr 13, 2013 at 10:44 AM, Michał Górny mgo...@gentoo.org wrote: The edos2unix is quite useful when handling DOS-sourced packages. But since it's a bash function, you can't reasonably use it from within find invocation. And often you hit packages which are all flooded with CRLFs that

Re: Pass ${@} in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.

2013-04-13 Thread Ciaran McCreesh
On Sat, 13 Apr 2013 03:04:51 +0200 Michael Weber x...@gentoo.org wrote: I'm not sure if it's a sane way to push make -j1 via src_compile() { cmake-multilib_src_compile -j1 } Well the Council doesn't approve of it for default phase functions... -- Ciaran McCreesh signature.asc

Re: [gentoo-dev] glibc: pt_chown setuid going away by default

2013-04-13 Thread Jeroen Roovers
On Fri, 12 Apr 2013 16:08:10 -0400 Mike Frysinger vap...@gentoo.org wrote: that you remember. i think it's more likely you copy pasted some line a long time ago than baselayout modified it for you. Exactly, but where did that come from? two people who have installs that are a decade old

Re: Pass ${@} in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.

2013-04-13 Thread Michael Weber
On 04/13/2013 05:50 PM, Michał Górny wrote: That's my mistake most likely. Please commit the patch. done. + 13 Apr 2013; Michael Weber x...@gentoo.org cmake-multilib.eclass: + Pass ${@} in phase functions. Approved by author on dev-ml. + -- Michael Weber Gentoo Developer web:

[gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread William Hubbs
All, this eclass is an alternative to systemd.eclass, and maintains full compatibility with it; however, it expands it so that it can query pkgconfig for the directory paths. It returns the same default paths as systemd.eclass if there is an error with pkgconfig. I am sending this out for review

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread Rich Freeman
On Sat, Apr 13, 2013 at 3:43 PM, William Hubbs willi...@gentoo.org wrote: I am sending this out for review so we can commit it to the tree when we commit our alternate systemd ebuild in a few days. This will be set up so that users can choose which systemd package they want to install, and it

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread Diego Elio Pettenò
It's happening that we seem to have a bunch of crybabies in Gentoo that don't get along together and instead of figuring out their differences are going to screw up users even more. Bunch of chipmunks in our ranks as well I suppose. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu —

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread William Hubbs
On Sat, Apr 13, 2013 at 04:15:03PM -0400, Rich Freeman wrote: On Sat, Apr 13, 2013 at 3:43 PM, William Hubbs willi...@gentoo.org wrote: I am sending this out for review so we can commit it to the tree when we commit our alternate systemd ebuild in a few days. This will be set up so that

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread Rich Freeman
On Sat, Apr 13, 2013 at 4:57 PM, William Hubbs willi...@gentoo.org wrote: It is not an upstream fork, it is a configuration/installation approach that follows upstream's recommendations for install locations. It also allows the user more choices wrt which parts of systemd are built or

[gentoo-dev] [RFC] Cleaning up PMS to have ${D} not end with a slash

2013-04-13 Thread Michał Górny
Hello, As most of you probably doesn't know, PMS guarantees that ${D} always ends with a slash. It seems that this particular wording was enforced by historical portage behavior (instead of fixing the ebuilds...) yet it didn't ever get really widespread. Specifically, it is awfully

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread Michał Górny
On Sat, 13 Apr 2013 14:43:14 -0500 William Hubbs willi...@gentoo.org wrote: this eclass is an alternative to systemd.eclass, and maintains full compatibility with it; however, it expands it so that it can query pkgconfig for the directory paths. It returns the same default paths as

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread William Hubbs
On Sat, Apr 13, 2013 at 11:27:24PM +0200, Michał Górny wrote: On Sat, 13 Apr 2013 14:43:14 -0500 William Hubbs willi...@gentoo.org wrote: this eclass is an alternative to systemd.eclass, and maintains full compatibility with it; however, it expands it so that it can query pkgconfig for

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread Markos Chandras
On 13 April 2013 22:30, William Hubbs willi...@gentoo.org wrote: On Sat, Apr 13, 2013 at 11:27:24PM +0200, Michał Górny wrote: On Sat, 13 Apr 2013 14:43:14 -0500 William Hubbs willi...@gentoo.org wrote: this eclass is an alternative to systemd.eclass, and maintains full compatibility with

Re: [gentoo-dev] new eclass: systemd-next.eclass

2013-04-13 Thread William Hubbs
On Sun, Apr 14, 2013 at 12:41:59AM +0100, Markos Chandras wrote: On 13 April 2013 22:30, William Hubbs willi...@gentoo.org wrote: On Sat, Apr 13, 2013 at 11:27:24PM +0200, Michał Górny wrote: On Sat, 13 Apr 2013 14:43:14 -0500 William Hubbs willi...@gentoo.org wrote: this eclass is an

[gentoo-dev] Re: rfc: toolchain-funcs: target-has-split-usr API?

2013-04-13 Thread Ryan Hill
On Fri, 12 Apr 2013 13:04:57 -0700 Gregory M. Turner g...@malth.us wrote: What do people think of something like this? Obviously the equivalent patch to prefix would need to include a test for PREFIX_DISABLE_GEN_USR_LDSCRIPT: Author: Gregory M. Turner gmturner...@ameritech.net Date:

[gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?

2013-04-13 Thread Ryan Hill
On Fri, 12 Apr 2013 23:41:05 +0200 Tom Wijsman tom...@gentoo.org wrote: - Make use of readme.gentoo.eclass to make the user aware of the Gentoo Linux Kernel Upgrade Guide only the first time he emerges the package. Fixes bug #457598. Call me crazy, but upgrade guides seem like something