Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/13/2013 04:59 AM, Pacho Ramos wrote:
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
Here are a few problems I see with readme.gentoo_print_elog:
1) contains duplication of code
2) [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]] condition seems
wrong, shouldn't it just use [[ -f ${T}/README.gentoo ]] since the
file was copied to ${T}/README.gentoo iby readme.gentoo_create_doc?
3) [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.
--
Thanks,
Zac
[gentoo-dev] Clarify log message?
I've seen this pop up a lot recently: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run * This might just be me being dense, but this doesn't seem very actionable to me. Who should replace the given symlink with the directory that it points to, the user or the package maintainer? And where should it be replaced? In ebuild code? Cheers, Dirkjan
Re: [gentoo-dev] Clarify log message?
On 01/14/2013 01:33 AM, Dirkjan Ochtman wrote:
I've seen this pop up a lot recently:
* One or more symlinks to directories have been preserved in order to
* ensure that files installed via these symlinks remain accessible. This
* indicates that the mentioned symlink(s) may be obsolete remnants of an
* old install, and it may be appropriate to replace a given symlink with
* the directory that it points to.
*
* /var/run
*
This might just be me being dense, but this doesn't seem very
actionable to me. Who should replace the given symlink with the
directory that it points to, the user or the package maintainer?
It depends on who created the symlink in the first place, and whether or
not the symlink is still desirable. Unfortunately, there are a number of
possible scenarios.
You probably want to keep that /var/run symlink, at least until all of
your installed packages have been fixed to use /run directly. You can
suppress the warning by putting a setting like this in make.conf:
UNINSTALL_IGNORE=${UNINSTALL_IGNORE} /var/run
That will prevent portage from trying to uninstall that symlink.
And where should it be replaced? In ebuild code?
It's possible for ebuild code to do it, if appropriate for the given
scenario. For example, the skype ebuild removes an obsolete
${EROOT}/usr/share/${PN} symlink in pkg_preinst.
--
Thanks,
Zac
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On 13 January 2013 18:06, hasufell hasuf...@gentoo.org wrote: On 01/13/2013 07:03 PM, Zac Medico wrote: On 01/13/2013 09:43 AM, hasufell wrote: On 01/13/2013 03:24 PM, Michał Górny wrote: Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? That is already lifted: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2 seems to be a repoman bug or just not yet implemented repoman is intended to enforce policies, which can be stricter than pms. So, the question is, what is our policy going to be? +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious An empty homepage usually means the package is dead. I'd rather see the cvs/git/svn url being used as HOMEPAGE in case your tiny little script has no proj page at all. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
Steven J. Long wrote: What I'm not in favour of is making the simple cases more difficult, to deal with the complex ones. It's completely brain-dead thinking. This is exactly what some people think or say when they learn that I use Gentoo. I appreciate Gentoo because I am able and willing to control my system. Users of other distributions are either not able or not willing or both, and thus they find Gentoo completely brain-dead. That's fine. I don't have to care about them when deciding what I will run. I hope the analogy is clear. If the kernel changes it's network device naming policy, please talk to the kernel developers - it seems counterproductive to expect that some distribution will bend far f-ing backwards in order to provide you the same experience that you were used to with the old kernel. It seems equally counterproductive to expect or demand that udev will change (or not change) the way you want it to, if you are not one of the core developers. William is packaging upstream udev for Gentoo. You are shooting the messenger. If you do not like what udev is doing, then step in and PARTICIPATE in that project, or in one of the competing projects. (I wish there wouldn't be so much fragmentation, but the NIH syndrome is mighty.) The task of distributions is to deliver a composite of upstreams. The task of distributions is NOT to deliver an immutable system where internals are magically updated with all the latest developments and fixes, except for all the latest developments that make any sort of visible change because those require an administrator to work. I think that if you have a requirement for an extremely stable environment, to the point where network interface names matter, then you need to take significant responsibility to *create* that environment *yourself*. You can't really rely on distributions to do that for you - that's not part of their value proposition. I would suggest to leverage the fantastic Gentoo tools and portage, in order to create your own distribution which suits your needs. Open source is only ever successful when you own your problems. //Peter
Re: [gentoo-dev] Clarify log message?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/01/13 04:44 AM, Zac Medico wrote:
On 01/14/2013 01:33 AM, Dirkjan Ochtman wrote:
I've seen this pop up a lot recently:
* One or more symlinks to directories have been preserved in
order to * ensure that files installed via these symlinks remain
accessible. This * indicates that the mentioned symlink(s) may be
obsolete remnants of an * old install, and it may be appropriate
to replace a given symlink with * the directory that it points
to. * * /var/run *
This might just be me being dense, but this doesn't seem very
actionable to me. Who should replace the given symlink with the
directory that it points to, the user or the package maintainer?
It depends on who created the symlink in the first place, and
whether or not the symlink is still desirable. Unfortunately, there
are a number of possible scenarios.
You probably want to keep that /var/run symlink, at least until all
of your installed packages have been fixed to use /run directly.
You can suppress the warning by putting a setting like this in
make.conf:
UNINSTALL_IGNORE=${UNINSTALL_IGNORE} /var/run
That will prevent portage from trying to uninstall that symlink.
And where should it be replaced? In ebuild code?
It's possible for ebuild code to do it, if appropriate for the
given scenario. For example, the skype ebuild removes an obsolete
${EROOT}/usr/share/${PN} symlink in pkg_preinst.
This particular symlink was put there by openrc though, wasn't it? So
I'd expect that on the whole this should be left for openrc to deal
with or otherwise left to the user...?
[tangent]
it's a bit late for /var/run , but i wonder if, for the next path
migration, there might be some way to account for which packages use
the old path, say, make a list somewhere, and have the ebuilds remove
their atom from that list as they migrate to the new path.. Then once
the list is empty the compatibility symlink could be cleaned up
automatically or the user notified.. Probably this would need to be
handled via an eclass and specific function calls in all relevant
ebuilds, as i doubt there would be a way to do this generically in
portage itself.
[/tangent]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlD0GjkACgkQ2ugaI38ACPD5rwD/f4MkzFrlSShRWt/9WB12kybX
uY0uzf5SFmfihzNthOABALr6bT3bB7PAr4eh4tmQH+jH9Z635OD5/BcdJBYw7tLl
=S5ML
-END PGP SIGNATURE-
Re: [gentoo-dev] Clarify log message?
On 01/14/2013 06:46 AM, Ian Stakenvicius wrote: This particular symlink was put there by openrc though, wasn't it? Yeah, openrc uses the migrate_to_run function from /etc/init.d/bootmisc. So I'd expect that on the whole this should be left for openrc to deal with or otherwise left to the user...? As things are now, the symlink is an orphan, and emerge will automatically remove the symlink when the last package that installed something under /var/run/ is uninstalled. [tangent] it's a bit late for /var/run , but i wonder if, for the next path migration, there might be some way to account for which packages use the old path, say, make a list somewhere, and have the ebuilds remove their atom from that list as they migrate to the new path.. Then once the list is empty the compatibility symlink could be cleaned up automatically or the user notified.. Probably this would need to be handled via an eclass and specific function calls in all relevant ebuilds, as i doubt there would be a way to do this generically in portage itself. [/tangent] That sounds a lot like the existing behavior (automatic symlink removal by emerge). -- Thanks, Zac
Re: [gentoo-dev] Clarify log message?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/01/13 09:57 AM, Zac Medico wrote: On 01/14/2013 06:46 AM, Ian Stakenvicius wrote: This particular symlink was put there by openrc though, wasn't it? Yeah, openrc uses the migrate_to_run function from /etc/init.d/bootmisc. So I'd expect that on the whole this should be left for openrc to deal with or otherwise left to the user...? As things are now, the symlink is an orphan, and emerge will automatically remove the symlink when the last package that installed something under /var/run/ is uninstalled. ...that doesn't sound good ; /var/run traditionally isn't a path used solely via src_install() but rather a path used by packages at runtime, no? If that's the case, that symlink probably should've been set up to remain until user intervention removes it.. [tangent] it's a bit late for /var/run , but i wonder if, for the next path migration, there might be some way to account for which packages use the old path, say, make a list somewhere, and have the ebuilds remove their atom from that list as they migrate to the new path.. Then once the list is empty the compatibility symlink could be cleaned up automatically or the user notified.. Probably this would need to be handled via an eclass and specific function calls in all relevant ebuilds, as i doubt there would be a way to do this generically in portage itself. [/tangent] That sounds a lot like the existing behavior (automatic symlink removal by emerge). OK i'm a little confused. Putting my earlier note aside, if the symlink will be auto-cleaned after no packages use it, what's the point/need for the original message from portage then?? Is it just QA for the ebuild maintainer? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD0H68ACgkQ2ugaI38ACPC+vAEAhGHZMfN2/dY+SXHFBStbckkH 9geiYEJAOEa6kcbOS28A/2hUq67WlVRiRP0vqW1WdeTod7aHhvc//q2TH994BWaI =pWiP -END PGP SIGNATURE-
Re: [gentoo-dev] Clarify log message?
On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
On 14/01/13 09:57 AM, Zac Medico wrote:
On 01/14/2013 06:46 AM, Ian Stakenvicius wrote:
This particular symlink was put there by openrc though, wasn't
it?
Yeah, openrc uses the migrate_to_run function from
/etc/init.d/bootmisc.
So I'd expect that on the whole this should be left for openrc to
deal with or otherwise left to the user...?
As things are now, the symlink is an orphan, and emerge will
automatically remove the symlink when the last package that
installed something under /var/run/ is uninstalled.
...that doesn't sound good ; /var/run traditionally isn't a path used
solely via src_install() but rather a path used by packages at
runtime, no? If that's the case, that symlink probably should've been
set up to remain until user intervention removes it..
It would be possible would be possible to protect the symlink by having
openrc or baselayout install the symlink, so that it's not an orphan.
Alternatively, users could manually protect it, by adding this setting
to make.conf:
UNINSTALL_IGNORE=${UNINSTALL_IGNORE} /var/run
[tangent] it's a bit late for /var/run , but i wonder if, for the
next path migration, there might be some way to account for which
packages use the old path, say, make a list somewhere, and have
the ebuilds remove their atom from that list as they migrate to
the new path.. Then once the list is empty the compatibility
symlink could be cleaned up automatically or the user notified..
Probably this would need to be handled via an eclass and specific
function calls in all relevant ebuilds, as i doubt there would be
a way to do this generically in portage itself. [/tangent]
That sounds a lot like the existing behavior (automatic symlink
removal by emerge).
OK i'm a little confused. Putting my earlier note aside, if the
symlink will be auto-cleaned after no packages use it, what's the
point/need for the original message from portage then?? Is it just QA
for the ebuild maintainer?
Unfortunately, there are a number of different possible scenarios. It
may serve as QA for the ebuild maintainer. It may be triggered by a
symlink that the sysadmin has manually created. In any case, there's a
performance penalty, since portage has to search for other packages that
installed files underneath the symlink. The performance penalty can be
avoided for a given symlink by adding it to UNINSTALL_IGNORE (which
makes the message useful, regardless of where the symlink originated from).
--
Thanks,
Zac
Re: [gentoo-dev] Clarify log message?
On 01/14/2013 07:44 AM, Zac Medico wrote: On 01/14/2013 07:09 AM, Ian Stakenvicius wrote: OK i'm a little confused. Putting my earlier note aside, if the symlink will be auto-cleaned after no packages use it, what's the point/need for the original message from portage then?? Is it just QA for the ebuild maintainer? Unfortunately, there are a number of different possible scenarios. It may serve as QA for the ebuild maintainer. It may be triggered by a symlink that the sysadmin has manually created. In any case, there's a performance penalty, since portage has to search for other packages that installed files underneath the symlink. The performance penalty can be avoided for a given symlink by adding it to UNINSTALL_IGNORE (which makes the message useful, regardless of where the symlink originated from). You can measure the performance penalty for the /var/run symlink by running this command: time portageq owners / /var/run -- Thanks, Zac
Re: [gentoo-dev] Clarify log message?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/01/13 10:53 AM, Zac Medico wrote: On 01/14/2013 07:44 AM, Zac Medico wrote: On 01/14/2013 07:09 AM, Ian Stakenvicius wrote: OK i'm a little confused. Putting my earlier note aside, if the symlink will be auto-cleaned after no packages use it, what's the point/need for the original message from portage then?? Is it just QA for the ebuild maintainer? Unfortunately, there are a number of different possible scenarios. It may serve as QA for the ebuild maintainer. It may be triggered by a symlink that the sysadmin has manually created. In any case, there's a performance penalty, since portage has to search for other packages that installed files underneath the symlink. The performance penalty can be avoided for a given symlink by adding it to UNINSTALL_IGNORE (which makes the message useful, regardless of where the symlink originated from). You can measure the performance penalty for the /var/run symlink by running this command: time portageq owners / /var/run Based on the performance penalty, would it make sense then for system-managed symlinks like /var/run that it would be automatically added to UNINSTALL_IGNORE and its removal managed separately by whatever put it there in the first place?? (and additionally, that the warning wouldn't be presented to end-users because of it being a system-managed migration symlink instead of a end-user-managed one)? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD0McYACgkQ2ugaI38ACPADjgD8D1nRkHqYNQLwtfb43X5QwAFI V9EM0yqdOWX9zI98+tABAJS5KTiZkejCVwK9Ord0VRtkyGVkGgZ+HDBvuOJHsIUA =3+S4 -END PGP SIGNATURE-
Re: [gentoo-dev] Clarify log message?
On 01/14/2013 08:26 AM, Ian Stakenvicius wrote: On 14/01/13 10:53 AM, Zac Medico wrote: On 01/14/2013 07:44 AM, Zac Medico wrote: On 01/14/2013 07:09 AM, Ian Stakenvicius wrote: OK i'm a little confused. Putting my earlier note aside, if the symlink will be auto-cleaned after no packages use it, what's the point/need for the original message from portage then?? Is it just QA for the ebuild maintainer? Unfortunately, there are a number of different possible scenarios. It may serve as QA for the ebuild maintainer. It may be triggered by a symlink that the sysadmin has manually created. In any case, there's a performance penalty, since portage has to search for other packages that installed files underneath the symlink. The performance penalty can be avoided for a given symlink by adding it to UNINSTALL_IGNORE (which makes the message useful, regardless of where the symlink originated from). You can measure the performance penalty for the /var/run symlink by running this command: time portageq owners / /var/run Based on the performance penalty, would it make sense then for system-managed symlinks like /var/run that it would be automatically added to UNINSTALL_IGNORE and its removal managed separately by whatever put it there in the first place?? There's currently no way for ebuilds to add things to UNINSTALL_IGNORE though (aside from having them edit make.conf). And how is openrc going to know when to remove it? (and additionally, that the warning wouldn't be presented to end-users because of it being a system-managed migration symlink instead of a end-user-managed one)? Do you want to introduce a new variable for this purpose, and allow ebuilds to modify it via /etc/env.d or something? -- Thanks, Zac
Re: [gentoo-dev] Clarify log message?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/01/13 11:36 AM, Zac Medico wrote:
On 01/14/2013 08:26 AM, Ian Stakenvicius wrote:
On 14/01/13 10:53 AM, Zac Medico wrote:
On 01/14/2013 07:44 AM, Zac Medico wrote:
On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
OK i'm a little confused. Putting my earlier note aside,
if the symlink will be auto-cleaned after no packages use
it, what's the point/need for the original message from
portage then?? Is it just QA for the ebuild maintainer?
Unfortunately, there are a number of different possible
scenarios. It may serve as QA for the ebuild maintainer. It
may be triggered by a symlink that the sysadmin has manually
created. In any case, there's a performance penalty, since
portage has to search for other packages that installed files
underneath the symlink. The performance penalty can be
avoided for a given symlink by adding it to UNINSTALL_IGNORE
(which makes the message useful, regardless of where the
symlink originated from).
You can measure the performance penalty for the /var/run
symlink by running this command:
time portageq owners / /var/run
Based on the performance penalty, would it make sense then for
system-managed symlinks like /var/run that it would be
automatically added to UNINSTALL_IGNORE and its removal managed
separately by whatever put it there in the first place??
There's currently no way for ebuilds to add things to
UNINSTALL_IGNORE though (aside from having them edit make.conf).
And how is openrc going to know when to remove it?
That would be where some sort of external tracking would need to
occur, which could be triggered via pkg_postinst and/or
pkg_{pre,post}rm in the eclass
(and additionally, that the warning wouldn't be presented to
end-users because of it being a system-managed migration symlink
instead of a end-user-managed one)?
Do you want to introduce a new variable for this purpose, and
allow ebuilds to modify it via /etc/env.d or something?
Possibly...
For the proof-of-concept phase I'm thinking of doing it via an eclass,
a file that'd be managed by that eclass, an external tool if required
to manage said file and/or process removal of the symlink (for cases
when the symlink isn't put in place by an ebuild during pkg_postinst,
ie if an init script should clean it up), and either source that file
or a separate file in make.conf.
At least then we can see if there really is a benefit to changing how
it is now. I can probably hack an install so that the /var/run
migration can be redone, for testing..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlD0OcAACgkQ2ugaI38ACPDkEgD/XYba0NejxqOPv41EsNa8U7tr
rm4vanPJubJCBX+rsrwA+wUKW3w9nOEkXw87AYJmq0/QFx0vFVfKJLUsrcF168gk
=imL1
-END PGP SIGNATURE-
Re: [gentoo-dev] app-emulation/qemu-user mask
On Mon, Jan 14, 2013 at 1:47 AM, Alexey Shvetsov ale...@gentoo.org wrote: В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал: On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote: Hi! For cross-chroots its needed to have static qemu-$arch user translators. May be you can introduce user-static use flag for them? Also it will be cool to have init script for kvm USE=static is available for app-emulation/qemu. I'll get a chroot for arm setup soon and test everything to make sure its working well. It doesnt allow to build dynamik qemu-system* and static user targets That can be fixed. File a bug. With regards to the KVM init script, I'm uninterested in maintaining it and it doesn't belong in the package as it is. There's a number of submitted init scripts that are attempting to create init scripts but really they're re-inventing libvirt and ganeti, but instead poorly. Ones I know about are: https://bugs.gentoo.org/show_bug.cgi?id=321517 https://bugs.gentoo.org/show_bug.cgi?id=406043 Ghm.. Its some kind of overkill to install libvirt or gannety just for 1-2 vms -- Doug Goldstein
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On 01/14/2013 11:06 AM, Markos Chandras wrote: On 13 January 2013 18:06, hasufell hasuf...@gentoo.org wrote: On 01/13/2013 07:03 PM, Zac Medico wrote: On 01/13/2013 09:43 AM, hasufell wrote: On 01/13/2013 03:24 PM, Michał Górny wrote: Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? That is already lifted: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2 seems to be a repoman bug or just not yet implemented repoman is intended to enforce policies, which can be stricter than pms. So, the question is, what is our policy going to be? +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious An empty homepage usually means the package is dead. I'd rather see the cvs/git/svn url being used as HOMEPAGE in case your tiny little script has no proj page at all. No, an empty homepage just means upstream is dead. There are numerous examples of years old packages still working fine without a single update.
Re: [gentoo-dev] Clarify log message?
On 14/01/2013 18:14, Zac Medico wrote: It might be a lot simpler to just go and patch all the ebuilds that installed stuff in /var/run with a one-liner like this at the end of src_install: It's a good idea to do so to avoid the check coming from portage to happena nd waste time, but ... Once all the ebuilds are fixed, emerge will automatically remove the /var/run symlink, and it's history. That should not happen. Ever. Because if it did we'd be in deep shit. The fact that /var/run is a symlink is what saves us from having to convert everything to actually use /run, and instead we still refer to /var/run in most places _but_ we use checkpath for it. If /var/run symlink was killed, we'd end up with a ton of services creating a (now permanent) /var/run directory structure, with even more trouble. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sunday, January 13, 2013 06:02:26 PM Michał Górny wrote: On Sun, 13 Jan 2013 07:36:59 -0800 Alec Warner anta...@gentoo.org wrote: local -i ret ? Looks good. I didn't even know bash has something like that. Useless use of -i is usually unhelpful. In Bash (but not all shells), it's slower, because it's still just storing the value as a string and marking the variable with the integer attribute which modifies the way certain assignments behave. It doesn't do any harm in this specific case, but there are a lot of gotchas with -i to be aware of if you're going to use it. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Clarify log message?
On 01/14/2013 09:23 AM, Diego Elio Pettenò wrote: On 14/01/2013 18:14, Zac Medico wrote: It might be a lot simpler to just go and patch all the ebuilds that installed stuff in /var/run with a one-liner like this at the end of src_install: It's a good idea to do so to avoid the check coming from portage to happena nd waste time, but ... Once all the ebuilds are fixed, emerge will automatically remove the /var/run symlink, and it's history. That should not happen. Ever. Because if it did we'd be in deep shit. The fact that /var/run is a symlink is what saves us from having to convert everything to actually use /run, and instead we still refer to /var/run in most places _but_ we use checkpath for it. If /var/run symlink was killed, we'd end up with a ton of services creating a (now permanent) /var/run directory structure, with even more trouble. Ah, right! So, those packages also need to be patched to use /run directly, instead of relying on the symlink. -- Thanks, Zac
Re: [gentoo-dev] Clarify log message?
On 14/01/2013 18:32, Zac Medico wrote: Ah, right! So, those packages also need to be patched to use /run directly, instead of relying on the symlink. Or the symlink should just stay for however long that's going to take, which is probably a good idea, as it does not bother anyone. I don't think that's going to be a problem for running systems though: the symlink will never be entirely empty. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sunday, January 13, 2013 01:28:42 PM Mike Frysinger wrote:
On Sunday 13 January 2013 08:29:43 Michał Górny wrote:
+ [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
really should use -n there
Doesn't matter. Only zsh requires it (and pointlessly disagrees with every
other implementation).
There are many possibilities.
${BUILD_DIR:+:} die ${FUNCNAME}: BUILD_DIR unset or empty.
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Thu, 03 Jan 2013 11:44:58 +0100
Thomas Sachau to...@gentoo.org wrote:
Pacho Ramos schrieb:
El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
On Sun, 23 Sep 2012 16:49:13 +0200
Thomas Sachau to...@gentoo.org wrote:
It is not hard by itself to inherit an eclass. There is just the
limitation, that occurs with an eclass, e.g.:
-the one from mgorny only does it for autotools based ebuilds
only and even there only for libraries, headers and binaries are
not done. While one may create the same for cmake based ones,
those are still only for a subset of packages, since not all do
use autotools/cmake or are satisfied with a libs only solution
-the multilib-native eclass does extend it way more, but still
has its limitations, e.g. what happens with a new target ABI
(like x32 on the amd64 profile) or how are dependencies handled?
multilib-portage is the answer to those limitations, since it does
work for any target with multilib cross-compile support, can
handle things like the dependencies internally and can even work
on not prepared/modified ebuilds.
So before i invest even more time in getting this official, we
should better get to some conclusion, if we either go the route
with eclass based multilib cross-compile support with its
limitations or if we move this up to the package manager level.
Can't we get something in between ?
Unless I'm mistaken, portage-multilib has its limitations also:
- I have package foo and package bar, both depending on ffmpeg and
canditates for a multilib build. However, package foo does not
link to ffmpeg but simply spawns the 'ffmpeg' binary to process
some files, package bar links to libavcodec. You need
ffmpeg[multilib] for a multilib build of bar but not for foo. How
do you distinguish between the two ?
I dont really understand your question here. So do you:
- simply have 2 64bit apps wanting to use ffmpeg?
- have 2 32bit binary packages wanting to use ffmpeg?
- want to build foo and bar on a 64bit platform for a 32bit platform?
- want a 64bit or a 32bit version of ffmpeg or both?
- if you want a 32bit version of ffmpeg, do you only want 32bit libs
or also a 32bit binary?
it depends on what you are building; let's say we want all abi flavors
for foo and bar.
in the above example, package foo uses fork/exec so needs a libc
compatible with its abis and that's all; it doesn't care if ffmpeg is
an elf executable, a bash script, or running through an emulator.
package bar needs ffmpeg libraries for every abi it installs.
portage multilib doesn't seem to distinguish between the two cases.
- When an out-of-tree build is possible, it is more efficient to
do it that way while multilib-portage will probably run the full
src_* phases twice. mgorny's eclass is a solution to this for
autotools-utils based ebuilds. I have added basic support for
this in freebsd-lib some time ago also.
Isnt out-of-tree build just building in a seperate location, so in
the end doing one unpack instead of 2, while everything else still
needs to be done for each target?
yes, so?
(unpack in the EAPI0 sense btw, prepare shouldn't need to be done twice
either)
However, it is clear that USE=multilib is limited too. What we
probably need, as I read in the draft you posted some time ago, is
a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in
an eclass, add them to IUSE of multilib-enabled packages and then
you can use the USE-deps. When a new ABI gets added, add it to the
list in the eclass and be done. You already have PM support for
this :)
Please keep in mind, that the USE flags are different, depending on
your arch. E.g. on amd64, you may additionally have x86 and x32,
while on ppc64, you may have ppc64 and ppc. You dont want the later
on amd64 nor the first on ppc. So how do you want to add different
(use-expanded) USE flags based on the arch the user is running?
no, the useflags are not different:
coma=
for i in $MULTILIB_ABIS ; do
multilib_use_deps+=${coma}multilib_abi_${i}?
coma=,
done
deps like foo[multilib?] becomes foo[${multilib_use_deps}]
and voila, you are not anymore limited to multilib or not multilib but
really control the abis.
You can leverage the generic multilib building code you have to an
eclass, so that you don't need to spec it; spec-ing it has its
problems too: what happens if next year pkg-config is deprecated
and now we shall all use foo-config ? your spec adjusts
PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small
EAPI change to be able to implement sanely a generic solution into
an eclass though.
My question to you would be: what are we missing from current
EAPIs to be able to perfectly support multilib builds ?
While the variable export, the build for each target and the merge of
the results should also be possible inside an eclass, the dependency
and USE flag parts seems more
[gentoo-dev] systemd/udev split
Hi list! After introducing eudev, is there any reason to do systemd/udev split?
Re: [gentoo-dev] systemd/udev split
Yes. I don't want systemd and I don't want eudev. And I'm not alone I'm sure.
Re: [gentoo-dev] systemd/udev split
2013/1/14 Diego Elio Pettenò flamee...@flameeyes.eu: I don't want systemd and I don't want eudev. And I'm not alone I'm sure. You are definitely not alone (though I'm not a gentoo dev). I think it makes sense to keep it split as long as udev is buildable without systemd and until eudev proves to be stable enough. After all, sadly, upstream udev has much larger userbase than eudev. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] systemd/udev split
On Mon, Jan 14, 2013 at 1:21 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: I don't want systemd and I don't want eudev. And I'm not alone I'm sure. ++ If it costs me 1200 seconds of CPU time and 40 millicents in electricity twice I year I can live with that... Rich
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
William is packaging upstream udev for Gentoo. You are shooting the messenger. I expect there is 0 blame meant for William. P.s. Is it William that Lennart dished some blame in the direction of. I completely disagree. It's not the job of every distro to look for all build flags to fix some software's defaults because other software has some small issues. That's simply ludicrous and my best guess is it being a feeble attempt at reasoning an excuse. At the very least and like in many release notes, it should have been made clear that distros may wish to consider using that flag to keep the current behaviour whether any reason to do was understood or not. The thought strikes me now that in the reverse case their likely wouldn't be any justification for having a build flag? Debian having to patch KDE to use /etc for configs is simply wrong too. You are right though, I don't suppose it helps much airing any of it here. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 14 Jan 2013 15:04:45 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Thu, 03 Jan 2013 11:44:58 +0100
Thomas Sachau to...@gentoo.org wrote:
Please keep in mind, that the USE flags are different, depending on
your arch. E.g. on amd64, you may additionally have x86 and x32,
while on ppc64, you may have ppc64 and ppc. You dont want the later
on amd64 nor the first on ppc. So how do you want to add different
(use-expanded) USE flags based on the arch the user is running?
no, the useflags are not different:
coma=
for i in $MULTILIB_ABIS ; do
multilib_use_deps+=${coma}multilib_abi_${i}?
coma=,
done
deps like foo[multilib?] becomes foo[${multilib_use_deps}]
and voila, you are not anymore limited to multilib or not multilib but
really control the abis.
Hmm, it may be a good idea to introduce such a variable already.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] systemd/udev split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/01/13 01:06 PM, Oleksii Shevchuk wrote: Hi list! After introducing eudev, is there any reason to do systemd/udev split? Ask in 6 months to a year, after eudev is fully established and has a solid track record. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD0VYIACgkQ2ugaI38ACPDYXQD/eHTwH7TzoSHhA2bkt7BUpIC1 Oi2Na7R+T5ptZ5c0AAQA/1NkdatkFy84LKDuA6HHBfLg5dIHnKTSf7N06aahQaBi =2RL4 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
On Mon, Jan 14, 2013 at 06:04:01AM +, Steven J. Long wrote: On Sat, Jan 12, 2013 William Hubbs wrote: Steven J. Long wrote: If you're certain that every user with a current simple setup, who uses the kernel default names, and has such a firewall setup isn't going to suddenly find their interface name changed when they reboot, fair play to you. If not, allow the admin to opt-in, rather than force them to opt-out when something breaks. The following is taken from the wiki: You basically have three options: 3 options that all require an admin opt-in to keep their existing config running There you go: the exact wrong way to do it. As Poettering might say: C'mon man, seriously? (whiny voice and pleading looks) If you have read this thread at all, you see that when you upgrade to udev-197, I create a file, /etc/udev/rules.d/80-net-name-slot.rules on your system. Now, go and compare that fact to the wiki page and tell me if I'm not setting you up to be opted out of this by default. There is a separate issue, which is new installs. I have a bug opened with the docs team and release engineering to discuss whether we want the new names for new installs. William pgpvRLLiLgugN.pgp Description: PGP signature
Re: [gentoo-dev] systemd/udev split
On Mon, Jan 14, 2013 at 01:59:14PM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/01/13 01:06 PM, Oleksii Shevchuk wrote: Hi list! After introducing eudev, is there any reason to do systemd/udev split? Ask in 6 months to a year, after eudev is fully established and has a solid track record. The only time I see eudev replacing udev as our default is if the systemd guys actually kill udev on non-systemd systems. William pgpmBdABOFaJp.pgp Description: PGP signature
Re: [gentoo-dev] systemd/udev split
On Mon, Jan 14, 2013 at 2:28 PM, William Hubbs willi...@gentoo.org wrote: The only time I see eudev replacing udev as our default is if the systemd guys actually kill udev on non-systemd systems. Seems likely to me, but anticipating about 300 replies to your post, I think we're all agreed that we'll do what makes sense when it makes sense to do it. Really no value in another thread speculating about the future of udev - bottom line is that we're prepared any which way. Rich
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Mon, Jan 14, 2013 at 9:30 AM, Dan Douglas orm...@gmail.com wrote: On Sunday, January 13, 2013 06:02:26 PM Michał Górny wrote: On Sun, 13 Jan 2013 07:36:59 -0800 Alec Warner anta...@gentoo.org wrote: local -i ret ? Looks good. I didn't even know bash has something like that. Useless use of -i is usually unhelpful. In Bash (but not all shells), it's slower, because it's still just storing the value as a string and marking the variable with the integer attribute which modifies the way certain assignments behave. It doesn't do any harm in this specific case, but there are a lot of gotchas with -i to be aware of if you're going to use it. -- Dan Douglas It is bash...there are lots of gotchas with almost *all* of bash's features ;) -A
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió: [...] +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious An empty homepage usually means the package is dead. I'd rather see the cvs/git/svn url being used as HOMEPAGE in case your tiny little script has no proj page at all. No, an empty homepage just means upstream is dead. There are numerous examples of years old packages still working fine without a single update. Other option is to use gentoo.org as HOMEPAGE for that packages (as some of them are already doing). But, since people think it's useless, why not use as HOMEPAGE http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/... ? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
[CC'ing this to core so noone can complain afterwards.]
Since 48h did not lead to any responses positive or negative, I'll start
implementing the procedure as given in the original e-mail (quoted below).
As also said below, each arch will get a mail before I touch their profile
tree and after I've finished.
Cheers, Andreas
Am Samstag, 12. Januar 2013, 21:47:18 schrieb Andreas K. Huettel:
Hi everyone,
since Council has approved the creation of a fresh set of EAPI=5 13.0
profiles, I would like to volunteer for creating them. The proposed
procedure is outlined below in detail, and I'd be happy for comments.
[If anything below deviates from Council decision, please tell me- not my
intention.]
One general question comes first, though: Right now, the releases/10.0
profile directory does the following things:
* mask too-old portage
* set eapi
* add USE=bzip2
Is there anything unrelated to EAPI=5 that absolutely must be added to the
new releases/13.0 directory in addition in your opinion? (Whether this is
the right place and was the right place in the beginning for USE=bzip2 is
another question.)
###
The procedure (all paths relative to profiles):
1) create directory eapi-5-files, with eapi (containing 5), skeletons for
package.stable.mask etc and a readme
2) copy releases/10.0 to releases/13.0, in releases/13.0:
* increase required portage version
* additionally inherit ../../eapi-5-files
* other changes as per question above?
3) for each arch in default/linux,
* announce on arch alias (to prevent overlapping commits)
* copy default/linux/${arch}/10.0 to default/linux/${arch}/13.0 and
* change inheritance in the new copy to inherit ../../../../releases/13.0
instead of ../../../../releases/10.0
* announce on arch alias (so future changes go into 13.0 tree)
[This describes the simple case. I realize that there are differences in
the directory structure, e.g. powerpc/ppc64/10.0, which is why this step
needs extra care.]
4) edit profiles.desc and copy all 10.0 lines to 13.0 lines, with an
initial setting dev (if dev or stable before) or exp (if exp before)
This makes repoman check against the new profiles when using developer
profiles.
5) announce the state on the dev list, urging devs to update their symlink
manually and !test!
6) wait one / two weeks
7) in profiles.desc, mark all 13.0 profiles stable that were stable in
10.0, and remove the lines for the 10.0 profiles. This makes eselect
profile now only offer the new ones, and repoman test by default against
13.0 profiles.
8) mark all 10.0 profiles as deprecated by creating a deprecated file
(containing the replacement suggestion) in the directory. This makes
portage warn users to upgrade (suggesting a new profile for them), and
repoman ignore the 10.0 profiles.
9) long waiting time as decided by Council
###
Everything that does NOT use/inherit 10.0 will remain unaffected, and
whoever responsible may have to take care of that some time before (in
step 10) the main profile directory becomes EAPI=5. This means e.g.
hardened, ulibc, prefix or bsd.
Cheers,
Andreas
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/01/13 03:15 PM, Pacho Ramos wrote: El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió: [...] +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious An empty homepage usually means the package is dead. I'd rather see the cvs/git/svn url being used as HOMEPAGE in case your tiny little script has no proj page at all. No, an empty homepage just means upstream is dead. There are numerous examples of years old packages still working fine without a single update. Other option is to use gentoo.org as HOMEPAGE for that packages (as some of them are already doing). But, since people think it's useless, why not use as HOMEPAGE http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/... ? Or what about a URL to a wiki.gentoo.org page for dead upstream packages? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD0b2YACgkQ2ugaI38ACPANAgD+IqKtIy4+UN/nanB20V5Hm99E 8FGmxroCAzpEGGikZb4A/Rj3nOYX3ZXFksojiAhbtcmwQ13Kg+I26MHwtxRhreUE =6T1r -END PGP SIGNATURE-
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
El lun, 14-01-2013 a las 15:49 -0500, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/01/13 03:15 PM, Pacho Ramos wrote: El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió: [...] +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious An empty homepage usually means the package is dead. I'd rather see the cvs/git/svn url being used as HOMEPAGE in case your tiny little script has no proj page at all. No, an empty homepage just means upstream is dead. There are numerous examples of years old packages still working fine without a single update. Other option is to use gentoo.org as HOMEPAGE for that packages (as some of them are already doing). But, since people think it's useless, why not use as HOMEPAGE http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/... ? Or what about a URL to a wiki.gentoo.org page for dead upstream packages? Well, the advantage of using sources.gentoo.org is that people will find there patches and stuff related with the package :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On Monday 14 January 2013 15:15:03 Pacho Ramos wrote:
El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió:
[...]
+1 to allow empty/missing HOMEPAGE variable
dead homepage = useless
http://gentoo.org = useless
https://bugs.gentoo.org = too obvious
An empty homepage usually means the package is dead. I'd rather see
the cvs/git/svn url being used as HOMEPAGE in case your tiny little
script has no proj page at all.
No, an empty homepage just means upstream is dead. There are numerous
examples of years old packages still working fine without a single
update.
Other option is to use gentoo.org as HOMEPAGE for that packages (as
some of them are already doing). But, since people think it's useless,
why not use as HOMEPAGE
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/...
?
semi-related, drop that intermediate noise.
http://sources.gentoo.org/${CATEGORY}/${PN}/
it'll redirect to the right place
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Monday 14 January 2013 12:55:29 Dan Douglas wrote:
On Sunday, January 13, 2013 01:28:42 PM Mike Frysinger wrote:
On Sunday 13 January 2013 08:29:43 Michał Górny wrote:
+ [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
really should use -n there
Doesn't matter. Only zsh requires it (and pointlessly disagrees with every
other implementation).
the point wasn't will it work. it's more how easy is it to glance at code
and know what it is doing.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
William Hubbs wrote: I have a bug opened with the docs team and release engineering to discuss whether we want the new names for new installs. IMO yes we do. What's that bug - or what is the good way to thumbs up/down? //Peter pgpswXbIiseJI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
On Tue, Jan 15, 2013 at 01:25:01AM +0100, Peter Stuge wrote: William Hubbs wrote: I have a bug opened with the docs team and release engineering to discuss whether we want the new names for new installs. IMO yes we do. What's that bug - or what is the good way to thumbs up/down? https://bugs.gentoo.org/show_bug.cgi?id=451950 The focus of this bug really is how to document the new names in the handbook if they decide to go that way. The problem we will have is we don't know the names of the interfaces a user will see. William pgpOr7kUoyxc4.pgp Description: PGP signature
[gentoo-dev] Re: [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
Mike Frysinger posted on Mon, 14 Jan 2013 17:09:51 -0500 as excerpted:
+ [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
really should use -n there
Doesn't matter.
the point wasn't will it work. it's more how easy is it to glance at
code and know what it is doing.
Indeed. But arguably standalone [[ ${var} ]] tests ARE easier to know
what it doing.
Consider:
1) The [[ $var ]] case is exactly one of one. There's no misinterpreting
it. Even if you don't know the rule by rote, given that it's a boolean
test on a string, there's logically only one way to parse it. No
mistakes to make.
2) By contrast, -n is only one of a whole list of -X style tests, and one
must stop and think, Let's see... Oh, yes, -n was non-null.
3) The situation in #2 is even worse than it might be due to the
standalone alternative, making -n (and -z, #4) far less common than they
would be otherwise.
4) You are arguing the at a glance position, but didn't even MENTION
the needlessly negated logic of [[ -n $string ]] || ... , which could be
rewritten to avoid the || negation as [[ -z $string ]] ...
5) [[ ]] is already a bashism while the standalone string test is common
shell. Surely you're not arguing that people familiar enough with the
[[ ]] || construct to parse it at a glance can't equally capably parse
the a standalone string test, given its use in non-bash shell context as
well.
6) If you're arguing for explicit, be consistent, with explicit
if/then, test, positive -z instead of negated -n logic... ::
if test -z ${BUILD_DIR}; then die ${FUNCTNAME}: BUILD_DIR not set.
Obviously the example in #6 is taking it a bit far, but my point is, an
explicit (if one-of-many) -z/-n test vs. the standalone (single-case)
$string test really is personal preference. You obviously prefer it one
way, others (including me) prefer the other... for the very same reason,
to us, our preferred way is instantly parsable, while the other way
triggers extra processing.
As such, IMO, He who codes, decides. =:^)
(IIRC I did bring up the same thing, naturally arguing my standalone
string test preference, in an earlier eclass proposal thread. However, I
believe I explicitly mentioned that I considered it a purely personal
style thing and that others had the opposite preference, with to my
knowledge no official gentoo coding style position taken on it. Given
that I had seen, I think you, bring up the point before, I was hoping
someone would post the gentoo style-guide link proving me wrong, if there
was one. Given that nobody did so, I still believe it to be he who
codes, decides territory.)
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Chromium system ffmpeg
I'm trying to make Chromium be more compatible with more versions of ffmpeg: https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion (although not stated there, that includes libav). Now the initial response there is not enthusiastic (which doesn't surprise me), but do you think there are some points useful for the discussion I'm not aware of? What are the main challenges of keeping up-to-date with latest ffmpeg API changes? How do other projects deal with that? If there is anything else you want to share/say about this, please do. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Tuesday, January 15, 2013 03:20:20 AM Duncan wrote:
Mike Frysinger posted on Mon, 14 Jan 2013 17:09:51 -0500 as excerpted:
+ [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
really should use -n there
Doesn't matter.
the point wasn't will it work. it's more how easy is it to glance at
code and know what it is doing.
Indeed. But arguably standalone [[ ${var} ]] tests ARE easier to know
what it doing.
While I agree, I wouldn't lose sleep over it. Both are perfectly acceptable
and nearly equal in clarity. [[ $x ]] is probably most common.
Consider:
...
4) You are arguing the at a glance position, but didn't even MENTION
the needlessly negated logic of [[ -n $string ]] || ... , which could be
rewritten to avoid the || negation as [[ -z $string ]] ...
-z is the negation. -n is the default. [[ $x ]] is rewritten internally as [[
-n $x ]]. [[ ! $x ]] == [[ ! -n $x ]] == [[ -z $x ]]. It's perfectly logical
that this expression evaluates true when given a non-empty value. As ''expr ||
die'' is the most expected form for error-checking, negating this with ''-z''
or otherwise makes little sense.
Empty == False is not an uncommon concept. e.g. python -c 'print(bool())'
5) [[ ]] is already a bashism while the standalone string test is common
shell. Surely you're not arguing that people familiar enough with the
[[ ]] || construct to parse it at a glance can't equally capably parse
the a standalone string test, given its use in non-bash shell context as
well.
I wish people would stop referring to features that predate both Bash and
POSIX as Bashisms. ''[['' is superior to and easier to understand than
''[''. Everyone should be familiar with both. As only Bash is relevant here,
''test'' and ''['' are mostly irrelevant. With few exceptions, ''[['' should
be preferred when available (and in this case, guaranteed available).
Obviously the example in #6 is taking it a bit far, but my point is, an
explicit (if one-of-many) -z/-n test vs. the standalone (single-case)
$string test really is personal preference.
The performance difference is considerable.
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass
Hi folks,
this commit changes the set of USE flags on the just stabled gcc-4.6,
running a huge number into an rebuild of an freshly updated package.
(emerge --newuse recaclulates from go disabled to go missing)
Wouldn't it be possible to
a) refrain from this change (really, who has USE=go turned on?)
b) handle this with package.use.mask,
c) figure it out before stabilization
I see the point in nobody beeing perfect, but these recurring
effect-less rebuilds of widespread base packages set me up.
Imho, editing /var/db/pkg/sys-devel/gcc-4.6.3/USE is not a recipe to be
carried out to the user. But can we do stuff like this in profile
updates? Without hurting system with USE=go activated, which need
actually need the recompile.
my 2 cents
Michael
Original Message
Subject: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog
toolchain.eclass
Date: Tue, 15 Jan 2013 02:30:53 + (UTC)
From: Ryan Hill (dirtyepic) dirtye...@gentoo.org
Reply-To: gentoo-dev@lists.gentoo.org, dirtye...@gentoo.org
To: gentoo-comm...@lists.gentoo.org
dirtyepic13/01/15 02:30:53
Modified: ChangeLog toolchain.eclass
Log:
Drop go support for 4.6 - broken by newer glibc versions and upstream
recommends it not be used.
Revision ChangesPath
1.615eclass/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?r1=1.614r2=1.615
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v
retrieving revision 1.614
retrieving revision 1.615
diff -u -r1.614 -r1.615
--- ChangeLog 13 Jan 2013 22:35:28 - 1.614
+++ ChangeLog 15 Jan 2013 02:30:53 - 1.615
@@ -1,6 +1,10 @@
# ChangeLog for eclass directory
# Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.614 2013/01/13
22:35:28 eva Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.615 2013/01/15
02:30:53 dirtyepic Exp $
+
+ 15 Jan 2013; Ryan Hill dirtye...@gentoo.org toolchain.eclass:
+ Drop go support for 4.6 - broken by newer glibc versions and upstream
+ recommends it not be used.
13 Jan 2013; Gilles Dartiguelongue e...@gentoo.org gnome2.eclass:
Allow ebuild override of eclass generated econf.
1.567eclass/toolchain.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.566r2=1.567
Index: toolchain.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v
retrieving revision 1.566
retrieving revision 1.567
diff -u -r1.566 -r1.567
--- toolchain.eclass29 Dec 2012 06:45:06 - 1.566
+++ toolchain.eclass15 Jan 2013 02:30:53 - 1.567
@@ -1,6 +1,6 @@
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.566
2012/12/29 06:45:06 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.567
2013/01/15 02:30:53 dirtyepic Exp $
#
# Maintainer: Toolchain Ninjas toolch...@gentoo.org
@@ -115,7 +115,7 @@
tc_version_is_at_least 4.3 IUSE+= fixed-point
tc_version_is_at_least 4.4 IUSE+= graphite
[[ ${GCC_BRANCH_VER} == 4.5 ]] IUSE+= lto
- tc_version_is_at_least 4.6 IUSE+= go
+ tc_version_is_at_least 4.7 IUSE+= go
fi
fi
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
[gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.
Although the eclass does 'multilib?' only now, in the future it is
likely to use more fine-tuned ABI flags.
---
gx86/eclass/autotools-multilib.eclass | 12
1 file changed, 12 insertions(+)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index fe6372d..d4e0f77 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -34,6 +34,18 @@ EXPORT_FUNCTIONS src_configure src_compile src_test
src_install
IUSE=multilib
+# @ECLASS-VARIABLE: MULTILIB_USEDEP
+# @DESCRIPTION:
+# The USE-dependency to be used on dependencies (libraries) needing
+# to support multilib as well.
+#
+# Example use:
+# @CODE
+# RDEPEND=dev-libs/libfoo[${MULTILIB_USEDEP}]
+# net-libs/libbar[ssl,${MULTILIB_USEDEP}]
+# @CODE
+MULTILIB_USEDEP=multilib?
+
# @FUNCTION: autotools-multilib_foreach_abi
# @USAGE: argv...
# @DESCRIPTION:
--
1.8.1
