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
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
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.
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
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
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
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
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
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:
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
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
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 —
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
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
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
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
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
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
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
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:
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
21 matches
Mail list logo