Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
On 5/3/2013 16:08, René Neumann wrote: Am 03.05.2013 22:20, schrieb Zac Medico: Is it worth changing? Nope. What's worth changing is the excessive use of USE_EXPAND for no reason (your described usecase makes sense for reasonable USE_EXPAND stuff like VIDEO_CARDS). But seems like I'm the only one concerned by this, so I should probably rest my case and switch to silent sobbing instead ;-). - René I definitely agree with you. USE_EXPAND combined with nearly everything on-by-default (ENLIGHTENMENT_PLUGINS, for example) really annoys me. There are two ways to turn off USE_EXPADed flags: explicitly set everything but what you don't want in make.conf, or use the fully-qualified flag in make.conf:USE or package.use, which defeats the purpose entirely. Both of these are overly verbose, in my opinion. I don't know how the over-utilization of USE_EXPAND got started, but I would very much like to see it go away. -- ♫Dustin http://dustin.hatch.name/
Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
On Thu, 2 May 2013 14:26:11 +0200
Michał Górny mgo...@gentoo.org wrote:
I've thought for a bit and got the conclusion that the best solution
for quite an irritating syntax of autotools-multilib is to use
sub-phase functions. To increase consistency between ebuilds, the same
phases can be used in autotools-utils directly.
For example, the alsa-lib ebuild could be changed like the following:
Index: alsa-lib-1.0.27-r3.ebuild
===
RCS file:
/var/cvsroot/gentoo-x86/media-libs/alsa-lib/alsa-lib-1.0.27-r3.ebuild,v
retrieving revision 1.1
diff -u -B -r1.1 alsa-lib-1.0.27-r3.ebuild
--- alsa-lib-1.0.27-r3.ebuild 3 May 2013 14:38:28 - 1.1
+++ alsa-lib-1.0.27-r3.ebuild 4 May 2013 07:26:08 -
@@ -4,9 +4,11 @@
EAPI=5
+AUTOTOOLS_AUTORECONF=1
+AUTOTOOLS_PRUNE_LIBTOOL_FILES=all
PYTHON_COMPAT=( python2_7 )
-inherit autotools eutils multilib multilib-minimal python-single-r1
+inherit autotools-multilib multilib python-single-r1
DESCRIPTION=Advanced Linux Sound Architecture Library
HOMEPAGE=http://www.alsa-project.org/;
@@ -27,47 +29,47 @@
use python python-single-r1_pkg_setup
}
-src_prepare() {
+autotools_prepare_all() {
# dlclose, pcm, kernel, inline, inline-2 are all from upstream
- epatch \
+ local PATCHES=(
${FILESDIR}/1.0.25-extraneous-cflags.diff \
${FILESDIR}/${P}-{dlclose,pcm,kernel}.patch \
${FILESDIR}/${P}-inline{,-2}.patch
+ )
sed -i -e 's:AM_CONFIG_HEADER:AC_CONFIG_HEADERS:' configure.in || die
#466980
- epatch_user
-
- eautoreconf
# if eautoreconf'd with recent autoconf, then epunt_cxx is
# unncessary wrt #460974
# epunt_cxx
+
+ edefault
}
-multilib_src_configure() {
- local myconf
+autotools_configure() {
+ local myeconfargs=(
+ --enable-shared
+ --disable-resmgr
+ --enable-rawmidi
+ --enable-seq
+ --enable-aload
+ $(use_with debug)
+ $(use_enable alisp)
+ )
+
# enable Python only on final ABI
if [[ ${ABI} == ${DEFAULT_ABI} ]]; then
- myconf=$(use_enable python)
+ myeconfargs+=( $(use_enable python) )
else
- myconf=--disable-python
+ myeconfargs+=( --disable-python )
fi
- use elibc_uclibc myconf+= --without-versioned
+ use elibc_uclibc myeconfargs+=( --without-versioned )
- ECONF_SOURCE=${S} \
- econf \
- --enable-shared \
- --disable-resmgr \
- --enable-rawmidi \
- --enable-seq \
- --enable-aload \
- $(use_with debug) \
- $(use_enable alisp) \
- ${myconf}
+ edefault
}
-multilib_src_compile() {
- emake
+autotools_compile() {
+ edefault
if [[ ${ABI} == ${DEFAULT_ABI} ]] use doc; then
emake doc
@@ -76,15 +78,9 @@
fi
}
-multilib_src_install() {
- emake DESTDIR=${D} install
+autotools_install() {
+ edefault
if [[ ${ABI} == ${DEFAULT_ABI} ]] use doc; then
dohtml -r doc/doxygen/html/.
fi
}
-
-multilib_src_install_all() {
- prune_libtool_files --all
- find ${ED}/usr/$(get_libdir)/alsa-lib -name '*.a' -exec rm -f {} +
- dodoc ChangeLog TODO
-}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/01/2013 12:04 PM, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. Amen With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. [unrelated] Do you have more insights about this part? mdev MUST work, lots of thin recovery options are based on busybox. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. Would make sense merge init and settingsd in a single eselect or at least make so switching init would warn if the settingsd doesn't match? - genkernel should at least support plymouth (work in progress my side) Looking forward to it. - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). See above. The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. Exactly, which is the problem at hand? I'd like to be able to safely switch back and forth sysvinit and bb-init as well. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) Here! o/ Currently in my list are - bootchart2 (as an add-on to the other init systems) - bb-init (requires different custom inittab) - runit (openrc can use it instead thanks to benda xu past GSoC) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) Again it is something I consider an option for a GSoC project, we have already some openrc variant for other systemd-originated daemons in our git. - we put back some fun into Gentoo That's always good. If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. Thank you a lot for your positive attitude and the huge effort =) lu
Re: [gentoo-dev] Re: Packages using -Werror
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/04/2013 06:52 AM, Ryan Hill wrote: On Fri, 3 May 2013 16:41:33 +0200 Jeroen Roovers j...@gentoo.org wrote: On Fri, 03 May 2013 16:15:35 +0200 hasufell hasuf...@gentoo.org wrote: We already get QA warnings for severe compiler warnings with a note that it should be reported upstream. But not all of them. I'm not sure what these warnings accomplish really. They're nice to see if you're trying to debug something, but in that case you're probably already looking through the log. I don't think anyone actually reports them upstream, and if they do, if upstream actually finds them useful. I think they're just noise most of the time (and if I learned anything from the recent thread about displaying messages only on first install it's that people think we already output too much noise). Do others find them useful? I report them for my packages, but often upstream does not care. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRhOZqAAoJEFpvPKfnPDWziX8IAIUlHotHvIbYnpAImogN3Kdd f+NJ7xA5f+bFzoSWU5Oan099QNDltSk/a3DJUJp91blUD2l9kEhOTuBACw2WKlYu Shf4GGGWA7VFj01N6oZkefBRmlZbCHaizSFQKFelnNaJWOCs7hD3dJJZ9hD25Afy nDM2PLg+M5n0u31AuXTYoVuAB2Af9g6ElV6uTMmAjH+SBKPRBKUENEgUVmHxQBsE JWgy1T3IjHiOBvXi4PP4WzCMqysLyzEJH0nIju1VeMrWZ2hqXbu6xMhrwgsoylKT 2QvqH6qr106x43dMYZvEpIl3VnIXNgmGyWHTi8J6q8o8XIvpPib6MEhg2S5PGJA= =i5sL -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 6:42 AM, Luca Barbato lu_z...@gentoo.org wrote: Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. I'm skeptical that this will ever make sense - both init systems have features that it would make sense for units/scripts to make use of in a more tailored fashion. That said, if you really wanted to inter-convert, my gut feeling is that it would be easier to go from a systemd unit to an init.d script, and not the other way around. A systemd unit is more like a specification - it describes the end result of what systemd should do. An init.d script is an executable program - it can do virtually anything even if they usually start out with a common skeleton. I guess you could run the thing in a sandbox and carefully capture what happens, and look in particular for calls to start-stop-daemon and such, but it would be tricky. The reality is that systemd units are floating around all over the place - when I installed it on a Gentoo box I ended up just Googling for already-written units for daemons that lacked them in Gentoo and tweaked them. All that really need to happen is for those who use systemd to submit them as bug attachments and maintainers should commit them. Maybe a quick guide should be tossed together suggesting the best way to install them (they're just text files in the proper directory, but perhaps an eclass exists to take care of this). Systemd units are much easier to write (typically) than init.d scripts so this could be an area where end-users could contribute. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 12:42 PM, Luca Barbato lu_z...@gentoo.org wrote: On 05/01/2013 12:04 PM, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. Amen With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. [unrelated] Do you have more insights about this part? mdev MUST work, lots of thin recovery options are based on busybox. Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. Also, I forgot that I wrote a NetworkManager patch that makes it able to detect logind/consolekit at runtime. It works and is in the systemd-love overlay (it's a git format-patch patch). - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. Would make sense merge init and settingsd in a single eselect or at least make so switching init would warn if the settingsd doesn't match? They are really two separate things, even though I agree that it should be made even easier. I don't think it's hard though. - genkernel should at least support plymouth (work in progress my side) Looking forward to it. I should have something ready soon. - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). See above. The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 3:05 PM, Fabio Erculiani lx...@gentoo.org wrote: Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? I just forgot the tricky part. If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working by miracle for now. mdev is not future proof wrt lvm support. -- Fabio Erculiani -- Fabio Erculiani
Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
Il 04/05/2013 08:11, Dustin C. Hatch ha scritto: On 5/3/2013 16:08, René Neumann wrote: Am 03.05.2013 22:20, schrieb Zac Medico: Is it worth changing? Nope. What's worth changing is the excessive use of USE_EXPAND for no reason (your described usecase makes sense for reasonable USE_EXPAND stuff like VIDEO_CARDS). But seems like I'm the only one concerned by this, so I should probably rest my case and switch to silent sobbing instead ;-). - René I definitely agree with you. USE_EXPAND combined with nearly everything on-by-default (ENLIGHTENMENT_PLUGINS, for example) really annoys me. There are two ways to turn off USE_EXPADed flags: explicitly set everything but what you don't want in make.conf, or use the fully-qualified flag in make.conf:USE or package.use, which defeats the purpose entirely. Both of these are overly verbose, in my opinion. I don't know how the over-utilization of USE_EXPAND got started, but I would very much like to see it go away. Actually this would not be that bad if USE_EXPAND where immutable (fix it once and be ok) but they are not and as such suffer the same problem as USE=-*
Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
On 05/03/2013 11:11 PM, Dustin C. Hatch wrote: On 5/3/2013 16:08, René Neumann wrote: Am 03.05.2013 22:20, schrieb Zac Medico: Is it worth changing? Nope. What's worth changing is the excessive use of USE_EXPAND for no reason (your described usecase makes sense for reasonable USE_EXPAND stuff like VIDEO_CARDS). But seems like I'm the only one concerned by this, so I should probably rest my case and switch to silent sobbing instead ;-). - René I definitely agree with you. USE_EXPAND combined with nearly everything on-by-default (ENLIGHTENMENT_PLUGINS, for example) really annoys me. There are two ways to turn off USE_EXPADed flags: explicitly set everything but what you don't want in make.conf, or use the fully-qualified flag in make.conf:USE or package.use, which defeats the purpose entirely. FWIW, portage supports both positive and negative wildcard settings for USE_EXPAND flags like USE=video_cards_* -enlightenment_plugins_*. Both of these are overly verbose, in my opinion. I don't know how the over-utilization of USE_EXPAND got started, but I would very much like to see it go away. -- Thanks, Zac
Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 03 May 2013 22:58:57 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Note that PMS says USE_EXPAND variables are supposed to be treated as incremental. Also note that portage implements pseudo-increment behavior for settings of USE_EXPAND variables in profile make.defaults, but it only works for positive values (which are stacked incrementally only after they have been translated to the corresponding USE flags). That is a bit of an issue honestly, but a rare time when I'd say we should make PMS match portage behavior. Uhm, PMS governs how this works for profiles, not for user configuration or any crazy stuff you do on the command line. Portage is not required to use exactly the same code for both... - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGFKboACgkQ96zL6DUtXhHoEgCg27zs7DoujKY4jXkx4ZXv2j6X Qu4AoNrGtxLJbiNpCkwyd9J36kWGMf2S =MfPG -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
El sáb, 04-05-2013 a las 15:05 +0200, Fabio Erculiani escribió: [...] - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. Also, I forgot that I wrote a NetworkManager patch that makes it able to detect logind/consolekit at runtime. It works and is in the systemd-love overlay (it's a git format-patch patch). If you even has fixes... I would simply report a bug to bugs.gentoo.org :/
Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/04/2013 11:31 AM, Ciaran McCreesh wrote: On Fri, 03 May 2013 22:58:57 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Note that PMS says USE_EXPAND variables are supposed to be treated as incremental. Also note that portage implements pseudo-increment behavior for settings of USE_EXPAND variables in profile make.defaults, but it only works for positive values (which are stacked incrementally only after they have been translated to the corresponding USE flags). That is a bit of an issue honestly, but a rare time when I'd say we should make PMS match portage behavior. Uhm, PMS governs how this works for profiles, not for user configuration or any crazy stuff you do on the command line. Portage is not required to use exactly the same code for both... Thanks for clearing that up Ciaran. That certainly makes a difference. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRhTk1AAoJEKXdFCfdEflK2o4QAILB7VhsnktsW7KQC5Y7F/0q fyq1K9q5lg9Fz/2WWZ+yVsjE6XSzLAPjes6kJzez0wZ0BUaDuI7eQOefFFqZ5Lwq P0CdqXdnou3TfaSWmC8s3vVSDX1xV/O2y+9R/zd4YaVFa7vLzVAkFpNNRtzgwGcm o8w5L+Lso1odhLzhsz2Wql5F1L8mNPpV4bAa27XnENrx/BEkRuEJHoj90ZpqPTIv zxMircMWYSnfauhUV4KSe6ieOeUeY7rOKVPMgoqTF0hYR0Oox7Vg5HZx77yy4uQw fkczatmzIp6L/I/zQws7Gi9bgh9wsfwd/jscfH5+8bFTH914YPbs2BejC9HKrnUQ uNN2/jCwlrchlWKWkwxTW/ay2gufsymR8btR3099zupwjCgEpgRDYCkEGS5hqN0V It5Nm7QWHrtBAZJRg/U4Pe/zV8fwYCWKEgreXEZzB5lT+vFkgn7kf/cJkmpOBwvG QR1LAlvnWaRNV0fbaoZydcjDPVZc/yBs1h3J+YOKvKZtF+dkH5/uHbjJPydgtpl4 qG+r2KdtV9aOTbJuidTh97gzAOOkEEbLoKIyqwHvrEzzb93fawVj1IaowUwHBlTq Yutbcbw2W4po5tg1nDy416sZRD2pAgsut47vnRVMUhPlkZn4PBYFYkOVzYAOPwMu PFR2Za+sLwsMYnOshi5W =BkWW -END PGP SIGNATURE-
Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
On Fri, May 03, 2013 at 11:03:41PM -0400, Rick Zero_Chaos Farina wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2013 05:28 PM, Mike Gilbert wrote: On Fri, May 3, 2013 at 5:08 PM, René Neumann li...@necoro.eu wrote: Am 03.05.2013 22:20, schrieb Zac Medico: Is it worth changing? Nope. What's worth changing is the excessive use of USE_EXPAND for no reason (your described usecase makes sense for reasonable USE_EXPAND stuff like VIDEO_CARDS). But seems like I'm the only one concerned by this, so I should probably rest my case and switch to silent sobbing instead ;-). - René Well, I do agree that they are overused. For example, GRUB_PLATFORMS is used by only one package. I would convert it back into a normal set of use flags, but that would mean any users of sys-boot/grub:2 would have to update their configuration. I don't think it is worth it at this point. Considering grub:2 isn't really used by the majority of users I feel compelled to note that you could convert now and just pick a sane set of use defaults. I know it's been a while since EAPI2 was introduced but I do love that little feature... :-) I would also like to chime in here and point out that all grub:2 users are ~arch users. If we were going to break stable it would be more of a shake-up, but since it isn't happening that way, I would say go for it. ~arch users are expected to be able to handle things like this. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/id3lib: metadata.xml ChangeLog id3lib-3.8.3-r9.ebuild
On Fri, 03 May 2013 20:18:42 +0200 Justin j...@gentoo.org wrote: + 03 May 2013; Justin Lecher j...@gentoo.org +id3lib-3.8.3-r9.ebuild, + metadata.xml: + Fix obsolete macros to work with automake-1.13, #467704; bumped to EAPI=5 and + autotools-utils.eclass There was no reason to use autotools-utils.eclass in the ebuild. Any reason to not using it? I think he answered that already in his reply to self. It adds useless cruft and then doesn't use it. (Also, why do a revision bump and leave the stable revision unfixed?) jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/id3lib: metadata.xml ChangeLog id3lib-3.8.3-r9.ebuild
Il 04/05/2013 19:42, Jeroen Roovers ha scritto: On Fri, 03 May 2013 20:18:42 +0200 Justin j...@gentoo.org wrote: + 03 May 2013; Justin Lecher j...@gentoo.org +id3lib-3.8.3-r9.ebuild, + metadata.xml: + Fix obsolete macros to work with automake-1.13, #467704; bumped to EAPI=5 and + autotools-utils.eclass There was no reason to use autotools-utils.eclass in the ebuild. Any reason to not using it? I think he answered that already in his reply to self. It adds useless cruft and then doesn't use it. could not comment to this (Also, why do a revision bump and leave the stable revision unfixed?) but this: because automake-1.13 is _not_ stable an because there are enough changes to risk to break it? revision bump has been a good idea
