Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?
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 the variables that modifying other variables in the eclass is not supported, there is a chance that we will not fix resulting bugs. Fixes bug #421721. Why? 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 need help with maintaining the current eclass functionality, I'd be more than happy. I don't really want to fork it myself :-). [..] - Kernel sources and (gen)patches now use xz instead of bz2. Fixes bug #421721. As I said in the bug, next time you plan a migration like that, it would be nice to send an heads up on the ML beforehand. Like you did in this case, but actually, _beforehand_ and not ~one month later. [...] Have a nice day. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -- Fabio Erculiani
Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?
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 undocumented variable, it is bound to fail at some point; this comment clarifies that we are not bound to fix resulting bugs, that of course does not mean we're not willing to help. As shown on the bug, it's quite the opposite, I've shown for multiple comments that I am willing to collaborate if you state me what the problem is. If I then get no answer to that, please don't feel annoyed; I may have came over as annoyed myself near the end, sorry for that. Your problem wasn't clear before I found above undocumented change; because as I said so on the bug, I covered the whole migration and am willing to convert still missing genpatches files and put them on the mirror right away. A change in KERNEL_BASE_URI is something which you can not cover in advance, because I do not know which changes are out there it is impossible for me to contact them all; the MLs target the wrong people. We're sorry this broke it for you and will use these lists from now on. If you need help with maintaining the current eclass functionality, I'd be more than happy. I don't really want to fork it myself :-). You'll want to ask Mike Pagano about that, not my take; he's both the lead of the kernel team and has been my mentor, he acknowledged the commit we are discussing here too without prior mails. Your suggested patch likely does not work with genpatches, since I don't think that the infra team will want to host files for forks of Gentoo; if they do, please let them tell me that, IRC or GPG signed. You will either want to fork this yourself or request the genpatches URI to become a documented variable such that you can host your own genpatches, either way I think you will need to convert them yourself. As I said in the bug, next time you plan a migration like that, it would be nice to send an heads up on the ML beforehand. Everything in the Portage tree was migrated just fine, there is also no certainty I will reach all people outside of the tree by this. But as said on that same bug, along a sorry, I will do so in the future... Happy to help, you may see me contribute to Sabayon/systemd-love. :-) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix.
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. The posted patch
changes the function to use find+sed for the substitution, passing given
paths as the 'path' arguments to find.
Whenever files are passed, nothing changes for ebuilds. If a directory
is passed, find converts it recursively. The only potential breakage is
when a non-file was passed and something weird was expected of it.
Any thoughts? If nobody opposes, I will commit the patch in 7 days.
---
gx86/eclass/eutils.eclass | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 467cf17..9e3a347 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -651,15 +651,16 @@ emktemp() {
}
# @FUNCTION: edos2unix
-# @USAGE: file [more files ...]
+# @USAGE: path [...]
# @DESCRIPTION:
# A handy replacement for dos2unix, recode, fixdos, etc... This allows you
# to remove all of these text utilities from DEPEND variables because this
-# is a script based solution. Just give it a list of files to convert and
-# they will all be changed from the DOS CRLF format to the UNIX LF format.
+# is a script based solution. Just give it a list of files or directories
+# to convert and they will all be changed from the DOS CRLF format
+# to the UNIX LF format recursively.
edos2unix() {
[[ $# -eq 0 ]] return 0
- sed -i 's/\r$//' -- $@ || die
+ find $@ -type f -exec sed -i 's/\r$//' -- {} + || die
}
# @FUNCTION: make_desktop_entry
--
1.8.1.5
[gentoo-dev] Re: Pass ${@} in phase functions Re: [PATCH] Introduce cmake-multilib wrapper for cmake-utils.
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 multilib-build.eclass
have it, so it might be sound to continue with this behavior.
Comments, pls.
I can't speak to the cmake bit, but passing $@ makes a lot of sense,
and puts the decision in the hands of the ebuild author, where it belongs.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: Pass ${@} in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.
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 and multilib-build.eclass
have it, so it might be sound to continue with this behavior.
That's my mistake most likely. Please commit the patch.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix.
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 you need to convert. That's why I'm suggesting to make edos2unix recursive. The posted patch changes the function to use find+sed for the substitution, passing given paths as the 'path' arguments to find. Whenever files are passed, nothing changes for ebuilds. If a directory is passed, find converts it recursively. The only potential breakage is when a non-file was passed and something weird was expected of it. Any thoughts? If nobody opposes, I will commit the patch in 7 days. If used improperly, this could easily end up breaking binary files that happen to contain the '\r' byte. Maybe a DEPEND on dos2unix would be a better option in the case where many files must be converted. I don't think it is necessary to convert DOS text files unless they somehow break on a UNIX system. Shell scripts are a good example, as well as some autotools files. No need to convert README though. I would guess that this patch is a response to bug 465790. I'm ok with requiring that python scripts be in UNIX format, although the python interpreter seems to work with either format.
Re: Pass ${@} in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.
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
Description: PGP signature
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
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 doesn't incline me to write a news entry. not when the ebuild itself contains a sanity check that triggers exactly as needed and includes an error message explaining things. we aren't talking about an upgrade here that will silently accidentally break your box on next boot (like udev friends), or will break running programs (like SONAME bumps, although that's a much less of a problem now that portage handles things automatically). -mike I have been looking through old copies of the Handbook in the last hour, assuming the fstab entry may have been included there at some point. I haven't done anything like a thorough search, but I assume it may have slipped into the handbook at some point and was later removed (as some CVS log entries from 2004 seem to suggest). jer
Re: Pass ${@} in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.
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: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
[gentoo-dev] new eclass: systemd-next.eclass
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 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 will default to the current systemd package.
Thanks,
the systemd-next team
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/systemd.eclass,v 1.22 2013/03/18
06:29:03 mgorny Exp $
# @ECLASS: systemd-next.eclass
# @MAINTAINER:
# willi...@gentoo.org
# ssuomi...@gentoo.org
# @BLURB: helper functions to install systemd units
# @DESCRIPTION:
# This eclass provides a set of functions to install unit files for
# systemd within ebuilds. It maintains compatibility with
# systemd.eclass by default, but it also allows querying pkgconfig.
#
# @EXAMPLE:
#
# @CODE
# inherit autotools-utils systemd-next
#
# src_configure() {
# local myeconfargs=(
# --enable-foo
# --disable-bar
# )
#
# systemd_to_myeconfargs
# autotools-utils_src_configure
# }
# @CODE
inherit toolchain-funcs
case ${EAPI:-0} in
0|1|2|3|4|5) ;;
*) die ${ECLASS}.eclass API in EAPI ${EAPI} not yet established.
esac
DEPEND=virtual/pkgconfig
# @FUNCTION: _systemd_get_unitdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed unitdir.
_systemd_get_unitdir() {
if $($(tc-getPKG_CONFIG) --exists systemd); then
echo $($(tc-getPKG_CONFIG) --variable=systemdsystemunitdir
systemd)
else
echo /usr/lib/systemd/system
fi
}
# @FUNCTION: systemd_get_unitdir
# @DESCRIPTION:
# Output the path for the systemd unit directory (not including ${D}).
# This function always succeeds, even if systemd is not installed.
systemd_get_unitdir() {
has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
debug-print-function ${FUNCNAME} ${@}
echo ${EPREFIX}$(_systemd_get_unitdir)
}
# @FUNCTION: _systemd_get_userunitdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed userunitdir.
_systemd_get_userunitdir() {
if $($(tc-getPKG_CONFIG) --exists systemd); then
echo $($(tc-getPKG_CONFIG) --variable=systemduserunitdir
systemd)
else
echo /usr/lib/systemd/user
fi
}
# @FUNCTION: systemd_get_userunitdir
# @DESCRIPTION:
# Output the path for the systemd user unit directory (not including
# ${D}). This function always succeeds, even if systemd is not
# installed.
systemd_get_userunitdir() {
has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
debug-print-function ${FUNCNAME} ${@}
echo ${EPREFIX}$(_systemd_get_userunitdir)
}
# @FUNCTION: _systemd_get_utildir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed utildir.
_systemd_get_utildir() {
if $($(tc-getPKG_CONFIG) --exists systemd); then
echo $($(tc-getPKG_CONFIG) --variable=systemdutildir systemd)
else
echo /usr/lib/systemd
fi
}
# @FUNCTION: systemd_get_utildir
# @DESCRIPTION:
# Output the path for the systemd utility directory (not including
# ${D}). This function always succeeds, even if systemd is not
# installed.
systemd_get_utildir() {
has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
debug-print-function ${FUNCNAME} ${@}
echo ${EPREFIX}$(_systemd_get_utildir)
}
# @FUNCTION: systemd_dounit
# @USAGE: unit1 [...]
# @DESCRIPTION:
# Install systemd unit(s). Uses doins, thus it is fatal in EAPI 4
# and non-fatal in earlier EAPIs.
systemd_dounit() {
debug-print-function ${FUNCNAME} ${@}
local INSDESTTREE
insinto $(_systemd_get_unitdir)
doins ${@}
}
# @FUNCTION: systemd_newunit
# @USAGE: oldname newname
# @DESCRIPTION:
# Install systemd unit with a new name. Uses newins, thus it is fatal
# in EAPI 4 and non-fatal in earlier EAPIs.
systemd_newunit() {
debug-print-function ${FUNCNAME} ${@}
local INSDESTTREE
insinto $(_systemd_get_unitdir)
newins ${@}
}
# @FUNCTION: systemd_dotmpfilesd
# @USAGE: tmpfilesd1 [...]
# @DESCRIPTION:
# Install systemd tmpfiles.d files. Uses doins, thus it is fatal
# in EAPI 4 and non-fatal in earlier EAPIs.
systemd_dotmpfilesd() {
debug-print-function ${FUNCNAME} ${@}
for f; do
[[ ${f} == *.conf ]] \
|| die 'tmpfiles.d files need to have .conf suffix.'
done
local INSDESTTREE
insinto /usr/lib/tmpfiles.d/
doins ${@}
}
# @FUNCTION: systemd_newtmpfilesd
# @USAGE: oldname newname.conf
# @DESCRIPTION:
# Install systemd tmpfiles.d file under a new name. Uses newins, thus it
# is fatal in EAPI 4 and non-fatal in earlier
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 will default to the current systemd package. Did I miss some kind of announcement for what is going on here? An additional implementation in portage along with an eclass probably is worth some kind of intro on-list. I don't think you need to seek approval/etc, but it would be nice to know what your goals/etc are. Is this just a different installation/configuration approach, or is this some kind of upstream fork? Rich
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 — http://blog.flameeyes.eu/ On Sat, Apr 13, 2013 at 10:15 PM, Rich Freeman ri...@gentoo.org 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 users can choose which systemd package they want to install, and it will default to the current systemd package. Did I miss some kind of announcement for what is going on here? An additional implementation in portage along with an eclass probably is worth some kind of intro on-list. I don't think you need to seek approval/etc, but it would be nice to know what your goals/etc are. Is this just a different installation/configuration approach, or is this some kind of upstream fork? Rich
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 users can choose which systemd package they want to install, and it will default to the current systemd package. Did I miss some kind of announcement for what is going on here? An additional implementation in portage along with an eclass probably is worth some kind of intro on-list. I don't think you need to seek approval/etc, but it would be nice to know what your goals/etc are. Is this just a different installation/configuration approach, or is this some kind of upstream fork? 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 installed and allows more fine-grained use dependencies for other packages. William pgpK72hHPItle.pgp Description: PGP signature
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 installed and allows more fine-grained use dependencies for other packages. Thanks. Might not hurt to document somewhere (wiki/etc) so that users can make an informed choice and to understand the contrasting philosophies. Dennis recently blogged on this topic. While cooperation should always be done when possible, if somebody really feels there is value in having an alternative I really don't see the problem. The main concern I'd have is coordination with other packages - for example I'd hate to see the unit files going into different places since that would make it impossible for other packages to determine where the user wants them (units might be installed before either implementation is installed). If conflict between alternative implementations starts creating problems for the rest of the distro then it only makes sense for the council to step in. Rich
[gentoo-dev] [RFC] Cleaning up PMS to have ${D} not end with a slash
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 counter-intuitive and even PMS gets it
wrong in most of the time (see: einstall). I could sum up the issues
with it in three snippets:
1) ${D}usr/bin/foo
2) emake install DESTDIR=${D%/}
3) local foodir=/usr/share/foo
insinto ${foodir}
...
bar ${D}${foodir#/}
Ugly, isn't it? And since it's completely counter-intuitive, most
ebuilds and eclasses get it wrong. Either by appending a slash just to
be sure (and having double slashes) or even conditionally stripping one.
While we could keep 'fixing' the ebuilds to follow the weird PMS
requirement, I'd rather go the other way -- fixing PMS to reflect
common sense.
The plan would be to:
1) lift the requirement that ${D} needs to end with slash,
2) fix all the ebuilds and eclasses which rely on that to use explicit
slash -- resulting in double slashes in the transition period,
3) make portage not append the slash anymore,
4) update PMS to specify that all directory variables do not end with
a slash,
5) slowly update the remaining ebuilds and eclasses to remove
the conditional slash removal/appending code.
This is mostly possible since majority of systems supported by Gentoo
does work fine with double slashes in paths, and the custom Cygwin port
fails randomly anyway due to this specific issue. We'd break it
completely for the transition period but afterwards, it will all be
clean and sane again.
Your thoughts?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 systemd.eclass if there is an error with pkgconfig. Alternative? So now developers decide whether they want support systemd A or systemd B? And we fork packages so that users can have matching set of packages? If you listened, you would know that the only reason I didn't apply your patches to the eclass was that nothing used them. If you really want to commit your quasi-fork, I will update the eclass. You don't really have to play silly games like this. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 the directory paths. It returns the same default paths as systemd.eclass if there is an error with pkgconfig. Alternative? So now developers decide whether they want support systemd A or systemd B? And we fork packages so that users can have matching set of packages? If you listened, you would know that the only reason I didn't apply your patches to the eclass was that nothing used them. If you really want to commit your quasi-fork, I will update the eclass. You don't really have to play silly games like this. Ok, that is the better aproach anyway, go ahead and update the eclass. Thanks much. :-) William pgpk7plYswe1S.pgp Description: PGP signature
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 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. Alternative? So now developers decide whether they want support systemd A or systemd B? And we fork packages so that users can have matching set of packages? If you listened, you would know that the only reason I didn't apply your patches to the eclass was that nothing used them. If you really want to commit your quasi-fork, I will update the eclass. You don't really have to play silly games like this. Ok, that is the better aproach anyway, go ahead and update the eclass. Thanks much. :-) William Am I the only one wondering why you didn't discuss this before you submit a new eclass for review? -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] new eclass: systemd-next.eclass
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 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. Alternative? So now developers decide whether they want support systemd A or systemd B? And we fork packages so that users can have matching set of packages? If you listened, you would know that the only reason I didn't apply your patches to the eclass was that nothing used them. If you really want to commit your quasi-fork, I will update the eclass. You don't really have to play silly games like this. Ok, that is the better aproach anyway, go ahead and update the eclass. Thanks much. :-) William Am I the only one wondering why you didn't discuss this before you submit a new eclass for review? I'm answering this on the list here for completeness only. I feel like a question here calls for a response. This started with this thread [1], where I proposed a patch to the systemd eclass. That patch was rejected as you can see with no real explanation from mgorny. This lead to private discussions with him which did not go well. I have all of those emails still, so I will go back and see if I can find where he gave me the explanation he is claiming here, but I honestly do not remember any such explanation coming from him until now. My original patch has been accepted now, so that should take care of that part of the situation. Mgorny, thanks for working with me. :-) William [1] http://www.gossamer-threads.com/lists/gentoo/dev/269385?page=last pgp355RnZd_xK.pgp Description: PGP signature
[gentoo-dev] Re: rfc: toolchain-funcs: target-has-split-usr API?
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: Fri Apr 12 11:13:21 2013 -0700 eclass/toolchain-funcs: Add target-has-split-usr API Move the platform-filtering code from gen_usr_ldscript into its own API so that ebuilds can reliably test whether gen_usr_ldscript does something or not in the currently applicable environment. See in-source comments for more details. Signed-off-by: Gregory M. Turner gmturner...@ameritech.net File a bug with the maintainers of that eclass. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?
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 you might want to tell the user about during an upgrade. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
