[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass
ChangeLog?
On 05/20/2012 01:26 PM, Mike Frysinger (vapier) wrote:
vapier 12/05/20 10:26:05
Modified: autotools.eclass
Log:
automatically create AC_CONFIG_MACRO_DIR dir too
Revision ChangesPath
1.131eclass/autotools.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.131view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.131content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.130r2=1.131
Index: autotools.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -r1.130 -r1.131
--- autotools.eclass22 Mar 2012 19:16:22 - 1.130
+++ autotools.eclass20 May 2012 10:26:05 - 1.131
@@ -1,6 +1,6 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.130 2012/03/22
19:16:22 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.131 2012/05/20
10:26:05 vapier Exp $
# @ECLASS: autotools.eclass
# @MAINTAINER:
@@ -143,7 +143,7 @@
# Should do a full autoreconf - normally what most people will be interested
in.
# Also should handle additional directories specified by AC_CONFIG_SUBDIRS.
eautoreconf() {
- local x auxdir g
+ local x g
if [[ -z ${AT_NO_RECURSIVE} ]]; then
# Take care of subdirs
@@ -156,10 +156,11 @@
done
fi
- auxdir=$(autotools_get_auxdir)
+ local auxdir=$(autotools_get_auxdir)
+ local macdir=$(autotools_get_macrodir)
einfo Running eautoreconf in '${PWD}' ...
- [[ -n ${auxdir} ]] mkdir -p ${auxdir}
+ [[ -n ${auxdir}${macdir} ]] mkdir -p ${auxdir} ${macdir}
eaclocal
[[ ${CHOST} == *-darwin* ]] g=g
if ${LIBTOOLIZE:-${g}libtoolize} -n --install /dev/null ; then
@@ -428,6 +429,7 @@
# Internal function to get additional subdirs to configure
autotools_get_subdirs() { autotools_check_macro_val AC_CONFIG_SUBDIRS ; }
autotools_get_auxdir() { autotools_check_macro_val AC_CONFIG_AUX_DIR ; }
+autotools_get_macrodir() { autotools_check_macro_val AC_CONFIG_MACRO_DIR ; }
_autotools_m4dir_include() {
local x include_opts
[gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you
i've extended eautoreconf to automatically call autopoint when the package
uses gettext. the configure check might seem naïve, but this is how autoreconf
itself does it. this hopefully shouldn't break any packages (at least, none
that weren't already broken), but if you guys start seeing eautoreconf
failures where there were none before, feel free to cc base-system.
-mike
--- autotools.eclass
+++ autotools.eclass
@@ -162,6 +162,9 @@ eautoreconf() {
einfo Running eautoreconf in '${PWD}' ...
[[ -n ${auxdir}${macdir} ]] mkdir -p ${auxdir} ${macdir}
eaclocal
+ if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then
+ eautopoint --force
+ fi
[[ ${CHOST} == *-darwin* ]] g=g
if ${LIBTOOLIZE:-${g}libtoolize} -n --install /dev/null ; then
_elibtoolize --copy --force --install
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass
ChangeLog again.
On 05/20/2012 01:39 PM, Mike Frysinger (vapier) wrote:
vapier 12/05/20 10:39:45
Modified: autotools.eclass
Log:
always depend on automake even when WANT_AUTOMAKE=none #401605
Revision ChangesPath
1.133eclass/autotools.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.133view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.133content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.132r2=1.133
Index: autotools.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- autotools.eclass20 May 2012 10:32:05 - 1.132
+++ autotools.eclass20 May 2012 10:39:45 - 1.133
@@ -1,6 +1,6 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.132 2012/05/20
10:32:05 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.133 2012/05/20
10:39:45 vapier Exp $
# @ECLASS: autotools.eclass
# @MAINTAINER:
@@ -49,9 +49,10 @@
_autoconf_atom=sys-devel/autoconf
if [[ -n ${WANT_AUTOMAKE} ]]; then
case ${WANT_AUTOMAKE} in
- none) _automake_atom= ;; # some packages don't require
automake at all
- # if you change the latest version here, change also
autotools_run_tool
- # this MUST reflect the latest stable major version for each
arch!
+ # Even if the package doesn't use automake, we still need to
depend
+ # on it because we run aclocal to process m4 macros. This
matches
+ # the autoreconf tool, so this requirement is correct. #401605
+ none) ;;
latest)
# Use SLOT deps if we can. For EAPI=0, we get pretty
close.
if [[ ${EAPI:-0} != 0 ]] ; then
[gentoo-dev] Re: RFC: git-2.eclass fetching from multiple repos
Michał Górny wrote: Sometimes it is necessary for a single package to pull from multiple remote repositories. snip Another question is how to implement it API-wide. The main problem here is that we already use multiple values for EGIT_REPO_URI to support fallback URIs, and I'd prefer supporting that for the additional repos as well. So currently: EGIT_REPO_URI=uri fallbackA fallbackB fallbackC ..where A, B and C are all fallbacks for uri. EGIT_REPO_URI=( repo1 fallback1 repo2 fallback2 ) Would require you to support both the above, and the new syntax if it's an array. Since this is new functionality, it seems wiser to prevent confusion between: EGIT_REPO_URI=(uri fallbackA fallbackB fallbackC) and: EGIT_REPO_URI=(repo1 repo2 repo3 repo4) ..and also make the implementation simpler (ie quicker for metadata), by using a new variable. Semantically as well, it's the git repo for the package: in most cases that's all that's required, so keep it simple for the majority usage (ie separate.) 2/ Exherbo way would be doing something like: EGIT_SECONDARY_REPOS='foo bar' EGIT_foo_REPO_URI='repo1 fallback1' EGIT_bar_REPO_URI='repo2 fallback2a fallback2b' .. if use baz; then EGIT_SECONDARY_REPOS+=' baz' EGIT_baz_REPO_URI='repo3 fallback3' fi but that would be real PITA for smart-live-rebuild, and I really hate dynamically named variables. It's amateurishly-done as well, but there's no fixing the ugliness, nor a requirement for duplication, even if you fix the fail. I'd go into it, but technical posts I make, discussing implementation, seem to get taken as political, so I'll stop here, given the provenance, and stick to the RFC. 3/ I'm wondering about something in-between those two, supposedly: EGIT_SECONDARY_REPO_URIS=( repo2 fallback2 ... ) Still painful for s-l-r but could be implemented without eclass-specific hacks as array support. Of course, if we support this not only for fetching but for checkouts as well, it's likely to get unreadable as well... What are your ideas? Assuming an identifier/ tag as above is useful, since you can then clone to a named subdirectory, or fetch from a specific repo, as directed by the ebuild, or fetch all except the named ones, which might be fetched into a different base-directory when the caller has cd'ed there, etc, extend your last one with optional tags: EGIT_SECONDARY=(foo@ repo1 fallback1 repo2 fallback2a fallback2b) .. use baz EGIT_SECONDARY+=(baz@ repo3 fallback3) So, fake associative arrays in a less cluttered fashion than 2/, that are simple to lex in-script, and don't lead to visual or mental overload. Since tags are optional, this accepts the same format, and extends it only when the ebuild needs a tag, so simple builds stay simple. The @ symbol is not valid in url's iirc, leave alone git uris, and draws attention to the named items. It preserves ordering, which an associative array won't, and you only ever have to worry about one variable name. Nor is there any issue with making sure tags and variables are in sync. (DRY.) The simple tag enables all the stuff I mentioned above, and by giving the ebuild author a symbolic reference which can be passed around, it can be extended ad-hoc. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you
On Sun, May 20, 2012 at 4:02 PM, Mike Frysinger vap...@gentoo.org wrote: i've extended eautoreconf to automatically call autopoint when the package uses gettext. the configure check might seem naïve, but this is how autoreconf itself does it. this hopefully shouldn't break any packages (at least, none that weren't already broken), but if you guys start seeing eautoreconf failures where there were none before, feel free to cc base-system. We went through this cycle in the GNOME team while working on live ebuilds. http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=eclass/gnome2-live.eclass;h=897adf863cb3f653ed96f45b14b637f7af651b1a;hb=HEAD#l110 You might want to cherry-pick some of those? Cheers, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)
ChangeLog entries missing for every autotools.eclass modification today.
On 05/20/2012 03:31 PM, Mike Frysinger (vapier) wrote:
vapier 12/05/20 12:31:33
Modified: autotools.eclass
Log:
we don't use anything from eutils eclass now, so drop the inherit
Revision ChangesPath
1.134eclass/autotools.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.134view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.134content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Index: autotools.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v
retrieving revision 1.133
retrieving revision 1.134
diff -u -r1.133 -r1.134
--- autotools.eclass20 May 2012 10:39:45 - 1.133
+++ autotools.eclass20 May 2012 12:31:32 - 1.134
@@ -1,6 +1,6 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.133 2012/05/20
10:39:45 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.134 2012/05/20
12:31:32 vapier Exp $
# @ECLASS: autotools.eclass
# @MAINTAINER:
@@ -16,7 +16,7 @@
if [[ ${___ECLASS_ONCE_AUTOTOOLS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_AUTOTOOLS=recur -_+^+_- spank
-inherit eutils libtool
+inherit libtool
# @ECLASS-VARIABLE: WANT_AUTOCONF
# @DESCRIPTION:
Re: [gentoo-dev] Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)
On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. I will repeat once again: autogenerate them. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)
On Sun, May 20, 2012 at 6:55 PM, Michał Górny mgo...@gentoo.org wrote: On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. I will repeat once again: autogenerate them. +1 for this, seriously. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)
Am Sonntag 20 Mai 2012, 15:30:45 schrieb Nirbheek Chauhan: On Sun, May 20, 2012 at 6:55 PM, Michał Górny mgo...@gentoo.org wrote: On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. I will repeat once again: autogenerate them. +1 for this, seriously. Yes please. And forget about the difference between user-oriented and dev-oriented. That's only an issue for people with too much time (also for debating). -- 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] Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)
On Sun, May 20, 2012 at 2:33 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
ChangeLog entries missing for every autotools.eclass modification today.
I'm sure spankman would make them if his tools did it for him, RIGHT SPANK?
-A
On 05/20/2012 03:31 PM, Mike Frysinger (vapier) wrote:
vapier 12/05/20 12:31:33
Modified: autotools.eclass
Log:
we don't use anything from eutils eclass now, so drop the inherit
Revision Changes Path
1.134 eclass/autotools.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.134view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?rev=1.134content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Index: autotools.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v
retrieving revision 1.133
retrieving revision 1.134
diff -u -r1.133 -r1.134
--- autotools.eclass 20 May 2012 10:39:45 - 1.133
+++ autotools.eclass 20 May 2012 12:31:32 - 1.134
@@ -1,6 +1,6 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.133
2012/05/20 10:39:45 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.134
2012/05/20 12:31:32 vapier Exp $
# @ECLASS: autotools.eclass
# @MAINTAINER:
@@ -16,7 +16,7 @@
if [[ ${___ECLASS_ONCE_AUTOTOOLS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_AUTOTOOLS=recur -_+^+_- spank
-inherit eutils libtool
+inherit libtool
# @ECLASS-VARIABLE: WANT_AUTOCONF
# @DESCRIPTION:
[gentoo-dev] Do we need games group and all that game prefixes?
Hello, In today's MythBusters™: do we actually need the whole ugly-awful mangling games.eclass does for games? By that I mean: - installing games in random pre-/postfixes rather than standard FHS-y locations, - changing ownership and permissions of all the files. Do we really need all of this poor man's 'you shall not play our games'? I don't think we're using anything like /usr/office office group, or /usr/random-programs-i-dont-like. Random obscurity only makes things harder. And proves no point unless we're going to ensure that all web browsers, ssh clients and other applications in danger of being used to play games. And while we're at it, why don't we just take the computer away and work on paper sheets? Oh wait, someone could play tic-tac-toe on it... So, my proposition is: finally drop that. Install games in regular prefixes, like all other apps. Don't pollute systems with unnecessary security perimeters which don't provide any real benefit. Any comments? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Do we need games group and all that game prefixes?
I second that. simplicity = win. -- Fabio Erculiani
Re: [gentoo-dev] Do we need games group and all that game prefixes?
On Sun, May 20, 2012 at 7:26 PM, Michał Górny mgo...@gentoo.org wrote: - changing ownership and permissions of all the files. As a side note: why is /usr/games owned by uid games? Does games_pkg_setup() in games.eclass do that? What's the point of user games (as opposed to group with same name)? Do we really need all of this poor man's 'you shall not play our games'? I don't think we're using anything like /usr/office office group, or /usr/random-programs-i-dont-like. Games are rather unique in that they sometimes keep scores across multiple users. Random obscurity only makes things harder. And proves no point unless we're going to ensure that all web browsers, ssh clients and other applications in danger of being used to play games. Sometimes users do not have Internet access or even ability to connect removable media. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Do we need games group and all that game prefixes?
On Sunday, May 20, 2012 06:26:17 PM Michał Górny wrote: Do we really need all of this poor man's 'you shall not play our games'? I don't think we're using anything like /usr/office office group, or /usr/random-programs-i-dont-like. I'd put money on there not being a single admin who has ever used the games group to control access to games. Games really have no business being on a system where anything like that is a requirement to begin with. So, my proposition is: finally drop that. Install games in regular prefixes, like all other apps. Don't pollute systems with unnecessary security perimeters which don't provide any real benefit. Any comments? Is there any way to keep the games group around while not doing the weird intrusive installation prefix? I have always disliked the prefix and don't see the point of it. However, requiring a special group for games restricts access by certain unprivileged programs which run as their own user/group for security reasons, thus providing a very slight security benefit. Or someone may have a user they use which doesn't require access to nonessential programs like games, which tend to be big complex programs less well-audited for security bugs. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Do we need games group and all that game prefixes?
+1 on getting rid of the munging. In my opinion games aren't nearly special enough to get this kind of special treatment. On zo, 2012-05-20 at 20:16 +0300, Maxim Kammerer wrote: Games are rather unique in that they sometimes keep scores across multiple users. Yes, and that's frequently handled by making them setgid to some group that actual user accounts are not in, allowing the games to write to their own statedir without allowing users to mess with those files by hand. Gentoo's approach actually breaks this, as it's already using the group the game executables are in for access control (so actual user accounts *are* in the group the game executables are in). This leads to bug 125902, which contains a lengthy discussion on this same subject. My personal opinion is that Gentoo's games setup only helps on systems that have no or heavily restricted network access, no or heavily restricted access to external media, has actual games installed system-wide, and needs access to those restricted to some accounts through technical means. I think such a setup is sufficiently uncommon we shouldn't specialcase games this heavily to support them. I don't think restricting games for resource consumption reasons makes sense, as people will virtually always be able to uselessly consume resources some other way. And I don't think restricting access to games because they're offensive/a waste of time/etc makes sense on the majority of systems, as people will be able to access similar content through other means, or will be able to install games into their homedir. However, when this came up in the past Gentoo's games project (which does an outstanding job maintaining a *lot* of games ebuilds) was opposed to changing this as the current setup isn't actually *broken* (for the majority of games), and changing things around a lot of work. So I'd like to request they reconsider (and start installing new/updated games in a more normal way), but as they're the ones doing most of the work here I think it makes sense to leave the decision with them. -- Marien Zwart
Re: [gentoo-dev] Do we need games group and all that game prefixes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2012 07:22 PM, Dan Douglas wrote: I'd put money on there not being a single admin who has ever used the games group to control access to games. Games really have no business being on a system where anything like that is a requirement to begin with. We (students council) use pam_ldap for users and primary groups and pam_group w/ /etc/security/group.conf for secondary groups like video,sound,games. We actually considered restricting the games group to certain login times (i.e. after 18 pm ) to prevent our fellow students from gaming during office hours, but that just lead to long time sessions over-night. Since group memberships are evaluated on session creation. I can imagine some multi-user setups (parents/children) were some user shouldn't play games-fps/* at all. But who actually shares a computer these days. One real benefit of extra groups is some chmod g+s hack for e.g. skype in combination with firewall rules restricting outbound connections. http://soup.xmw.de/post/151673185/Restricting-Skype-on-Gentoo Have a nice day ... - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+5VCgACgkQknrdDGLu8JB8SwD+JARCPBmK13Sl2/n3dsWWx/8p LBH6j18YbfD1+IWpXaUA/iWCgTS3TI78kSTwe0hnASc+7wTygiWvIcxlPmcv9LtQ =XXxi -END PGP SIGNATURE-
[gentoo-dev] Lastrite ~app-text/kiwix-0.9_beta5 (for using vulnerable copy of net-libs/xulrunner)
# Samuli Suominen ssuomi...@gentoo.org (20 May 2012) # Still using vulnerable net-libs/xulrunner wrt bug 412341 # Build problems wrt bug 390325 # Version 0.9_beta5 will be removed in approx. 30 days ~app-text/kiwix-0.9_beta5
Re: [gentoo-dev] Do we need games group and all that game prefixes?
On Sunday, May 20, 2012 10:29:28 PM Michael Weber wrote: On 05/20/2012 07:22 PM, Dan Douglas wrote: I'd put money on there not being a single admin who has ever used the games group to control access to games. Games really have no business being on a system where anything like that is a requirement to begin with. We (students council) use pam_ldap for users and primary groups and pam_group w/ /etc/security/group.conf for secondary groups like video,sound,games. We actually considered restricting the games group to certain login times (i.e. after 18 pm ) to prevent our fellow students from gaming during office hours, but that just lead to long time sessions over-night. Since group memberships are evaluated on session creation. Yes, that's essentially what I was thinking would be the most likely scenario. Still, as marienz pointed out, having workstations where access to games is undesired, yet where they're installed nevertheless, isn't the most common. I'm in favor of the games group (per the second half of my last message and for other reasons), just not extra unnecessary installation steps that complicate the directory structure unless there's some real benefit to someone (e.g. NFS). -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Remove eclass/ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/20/2012 02:30 PM, Nirbheek Chauhan wrote: On Sun, May 20, 2012 at 6:55 PM, Michał Górny mgo...@gentoo.org wrote: On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. I will repeat once again: autogenerate them. +1 for this, seriously. Who will do it? Infra? Maybe we should ask them first? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPuV3LAAoJEPqDWhW0r/LC1oEQAJmoSSWRnVysFmj6mknwSEoc GsIxnB6igUdHPFpnxrJXsKzmUvPcRPTboL9H7IOFTBr6lSP8lgEZCaPzpvQQLnTE cvKvOjmjh/5bhAPz8zu6ZRo+XvF9hFhBLyY//G/ljwnijwx5gSpyKMi4hiPg0Rb5 sl6gUaRepess8F1bqZZ7DeR1/IA1hyw2GlJ99F76opKa/uc7RVAUJClZTfjep8An 9khfIGCwSjC8f86qRWwTTu7qePk969gSoFcDpxEEn94gQpNPqRlX3jqEPJgh64fQ nYVl/0Lao/u0XAqNmTkbfu7ebf4WHfbbtzPrpzpQvsfb/F376nn5UFpRPhyYAIcE cmyGuuWzGbgSr88HilzyAkHGXZW9Q6qy5B6y4wqSLxJD4/BLMnH3rXceIrHlpfpG yHsPurgiHa2VZ5AE9n8IvH74Nf4fDS6JpLsdzJWH6jFhUaanxY6i5hg1ixdPJ1p1 0+3xFBepa0Wm7NNy/JpSbv4NWAqrrUFwdJJO2XczIgYUnJgqwMDExtM3/15LEJVh aRSnC3Zq9EIBN0NNW6U3QFYigL/j93XONr4j9eU2BrrbaTuavXebljNQuUt6WVvY lTtEAlTmXOPrizRsI+rfeCd27VrDHjHadGPt9wSZi7hYyhWGnRRepOJKvyhO6yP1 0GiA450pJcbI0mNEYzJq =QHna -END PGP SIGNATURE-
[gentoo-dev] enhancement for doicon/newicon in eutils.eclass
I want support for installing icons into the appropriate directories
which are under /usr/share/icons/... and not just pixmaps.
proposal attached + diff
This should not break existing ebuilds. Tested a bit and open for review
now.
# @FUNCTION: doicon
# @USAGE: doicon [options] icons
# @DESCRIPTION:
# Install icon into the icon directory /usr/share/icons or into
# /usr/share/pixmaps if --size is not set.
# This is useful in conjunction with creating desktop/menu files.
#
# @CODE
# options:
# -s, --size
#!!! must specify to install into /usr/share/icons/... !!!
#size of the icon, like 48 or 48x48
#supported icon sizes are:
#16 22 24 32 36 48 64 72 96 128 192 256 scalable
# -c, --context
#defaults to apps
# -t, --theme
#defaults to hicolor
#
# icons: list of icons
# @CODE
#
# example 1:
#doicon foobar.png fuqbar.svg
#results in: insinto /usr/share/pixmaps ; doins foobar.png fuqbar.svg
#
# example 2:
#doicon -s 48 foobar.png fuqbar.svg
#results in: insinto /usr/share/icons/hicolor/48x48/apps ; doins foobar.png
fuqbar.svg
#
doicon() {
(
# wrap the env here so that the 'insinto' call
# doesn't corrupt the env of the caller
local size dir i ret
local context=apps
local theme=hicolor
while [[ $# -gt 0 ]] ; do
case ${1} in
-s|--size)
case ${2} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${2}x${2};;
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|128x128|192x192|256x256)
size=${2};;
scalable)
size=scalable;;
*)
eqawarn ${2} is an unsupported icon size!
((++ret));;
esac
shift 2;;
-t|--theme)
theme=${2}
shift 2;;
-c|--context)
context=${2}
shift 2;;
*)
if [[ -z ${size} ]] ; then
dir=/usr/share/pixmaps
else
dir=/usr/share/icons/${theme}/${size}/${context}
fi
insinto ${dir}
if [[ -f ${1} ]] ; then
doins ${1}
((ret+=$?))
elif [[ -d ${1} ]] ; then
for i in ${1}/*.{png,svg} ; do
doins ${i}
((ret+=$?))
done
else
eqawarn ${1} is not a valid file/directory!
((++ret))
fi
shift 1 ;;
esac
done
exit ${ret}
)
}
# @FUNCTION: newicon
# @USAGE: newicon [options] icon newname
# @DESCRIPTION:
# Like doicon, install the specified icon as newname.
#
# example 1:
#newicon foobar.png NEWNAME.png
#results in: insinto /usr/share/pixmaps ; newins foobar.png NEWNAME.png
#
# example 2:
#newicon -s 48 foobar.png NEWNAME.png
#results in: insinto /usr/share/icons/hicolor/48x48/apps ; newins
foobar.png NEWNAME.png
#
newicon() {
(
# wrap the env here so that the 'insinto' call
# doesn't corrupt the env of the caller
local size dir ret
local context=apps
local theme=hicolor
while [[ $# -gt 0 ]] ; do
case ${1} in
-s|--size)
case ${2} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${2}x${2};;
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|128x128|192x192|256x256)
size=${2};;
scalable)
size=scalable;;
*)
eqawarn ${2} is an unsupported icon size!
((++ret));;
esac
shift 2;;
-t|--theme)
theme=${2}
shift 2;;
-c|--context)
context=${2}
shift 2;;
*)
break ;;
esac
done
if [[ -z ${size} ]] ; then
dir=/usr/share/pixmaps
else
dir=/usr/share/icons/${theme}/${size}/${context}
fi
insinto ${dir}
newins $@
((ret+=$?))
exit ${ret}
)
}
--- eclass/eutils.eclass
+++ eclass/eutils.eclass
@@ -945,43 +945,150 @@
}
# @FUNCTION: doicon
-# @USAGE: list of icons
+# @USAGE: doicon [options] icons
# @DESCRIPTION:
-#
Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass
On 05/21/2012 01:36 AM, Alexis Ballier wrote: On Mon, 21 May 2012 01:24:13 +0200 hasufell hasuf...@gentoo.org wrote: I want support for installing icons into the appropriate directories which are under /usr/share/icons/... and not just pixmaps. proposal attached + diff This should not break existing ebuilds. Tested a bit and open for review now. maybe i missed something but cant you just make doicon a newicon wrapper and remove all that code duplication ? I don't see how. doicon supports installing multiple icons with one command, as well as directories. That does not work for newicon.
[gentoo-dev] Re: enhancement for doicon/newicon in eutils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/20/2012 07:49 PM, hasufell wrote:
On 05/21/2012 01:36 AM, Alexis Ballier wrote:
On Mon, 21 May 2012 01:24:13 +0200 hasufell hasuf...@gentoo.org
wrote:
I want support for installing icons into the appropriate
directories which are under /usr/share/icons/... and not just
pixmaps.
proposal attached + diff
This should not break existing ebuilds. Tested a bit and open
for review now.
maybe i missed something but cant you just make doicon a newicon
wrapper and remove all that code duplication ?
I don't see how. doicon supports installing multiple icons with
one command, as well as directories. That does not work for
newicon.
Normally, new* is a wrapper for do* that does something like:
newfoo() {
# argument checking omitted...
cp -P ${1} ${T}/${2}
dofoo ${T}/${2}
}
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPuYXpAAoJELHSF2kinlg4C7kP/1tNBut+o5s0ScBt/SREjrQr
Oy1Q4iRk1hV5NqY0ve4Cx1LqT3LKFWGCUkUY9pY4YoacG5Pbt4FKebqHqBjNASbg
FIwA2BNGZ5VKW2uwfqpTcc2lp6VRAfA3IxqkO3mlKy/zwk96G3jeoU+2sLSRatRn
ZiXsuCQ6DxrBRp8Jtjc5X9lIvbfBNoDIC7uXtW8fOuFBILYT/oSDPwUdT9r3ppNR
nfEuB3AsjPEyxuSd0R7QNYXexwDwVyp4JlpqFAQGH/+xUR4Nsy4Cw5jVwOr6Ip+3
afDVC4NNkFBUf+8qQ/Rd6Fdch3RVLeGtdIfhHbYgSbmUGFjIOWQ/+kEy6yp8jNlp
2nkA29Y9eEmRYSwwfQR4xzTcWnuPyK9cNKuK2L5LTUN143rHJdQ85lzkhNPIAYJO
jQVPWZh966tQrjkLB9sfW14mkCcvkK5q9F4re5Z44R1RHfdnl+Npe7uts17dQSCg
61sdTQ4Q7r81SyqSgsf2g+QaaLQ+d7+HrZvEJ+N8xhDOwX06CZVjvNWnwewbHBUT
jWHkilE9wKJcliaAwK6wqCMNw0LZnvQJHWUKm+vNKcl1PSg51VeQrjEldPDix5cS
WVCjsFjzo4pLzID19pI1z3Yx7NIJJTbqfKw1Oju+Bv3JGAzz12RCX8XV4t9BCp7r
tPk3xzb4gsxPDqROppVh
=D2sX
-END PGP SIGNATURE-
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-05-20 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-05-20 23h59 UTC. Removals: app-pda/libopensync-plugin-google-calendar 2012-05-16 01:19:15 ssuominen x11-misc/see2012-05-16 06:36:39 dev-zero app-arch/hardlink-fedora2012-05-19 17:27:09 ssuominen app-text/chmsee 2012-05-20 20:31:43 ssuominen Additions: media-gfx/postr 2012-05-14 04:19:43 tetromino media-gfx/eog-plugins 2012-05-14 04:21:49 tetromino media-libs/libpostproc 2012-05-14 19:12:12 lu_zero dev-python/embedly 2012-05-15 01:20:59 rafaelmartins sci-geosciences/geocode-glib2012-05-15 05:57:42 tetromino x11-misc/tinymount 2012-05-15 10:44:10 ssuominen dev-python/cssselect2012-05-15 15:35:33 xarthisius dev-lang/go 2012-05-15 18:11:26 williamh net-wireless/reaver 2012-05-15 19:39:11 maksbotan x11-misc/seetxt 2012-05-16 06:34:17 dev-zero sys-cluster/libqb 2012-05-16 10:29:46 xarthisius games-arcade/opensonic 2012-05-16 18:42:50 hasufell dev-perl/User-Identity 2012-05-16 18:55:15 tove dev-perl/Object-Realize-Later 2012-05-16 19:03:20 tove dev-perl/Mail-Box 2012-05-16 20:49:46 tove dev-cpp/ETL 2012-05-17 03:20:30 lu_zero games-arcade/mari0 2012-05-17 15:22:25 hasufell kde-misc/ktouchpadenabler 2012-05-17 21:22:11 johu app-i18n/fcitx-cloudpinyin 2012-05-18 02:00:49 qiaomuf dev-python/gevent 2012-05-18 10:59:04 xarthisius dev-python/qserve 2012-05-18 11:39:35 xarthisius dev-python/roman2012-05-18 12:01:47 xarthisius dev-python/testify 2012-05-18 13:37:40 xarthisius dev-python/sqlite3dbm 2012-05-18 13:46:11 xarthisius dev-ruby/pdf-inspector 2012-05-19 06:05:24 graaff dev-python/bottle 2012-05-19 10:53:54 xarthisius app-arch/hardlink-fedora2012-05-19 12:21:57 ssuominen sci-visualization/gcalc 2012-05-19 13:21:41 sera sys-freebsd/virtio-kmod 2012-05-19 20:47:29 ryao sci-physics/geant-python2012-05-20 03:11:24 heroxbd dev-python/django-evolution 2012-05-20 10:34:08 tampakrap gnome-extra/nautilus-share 2012-05-20 11:54:23 maksbotan dev-python/django-pipeline 2012-05-20 12:15:46 tampakrap app-emulation/emul-linux-x86-jna2012-05-20 13:05:35 pacho dev-python/testfixtures 2012-05-20 13:56:48 tampakrap dev-python/xlutils 2012-05-20 14:53:23 tampakrap app-portage/epkg2012-05-20 18:40:07 jdhore media-libs/icclib 2012-05-20 19:48:33 dilfridge -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-pda/libopensync-plugin-google-calendar,removed,ssuominen,2012-05-16 01:19:15 x11-misc/see,removed,dev-zero,2012-05-16 06:36:39 app-arch/hardlink-fedora,removed,ssuominen,2012-05-19 17:27:09 app-text/chmsee,removed,ssuominen,2012-05-20 20:31:43 Added Packages: media-gfx/postr,added,tetromino,2012-05-14 04:19:43 media-gfx/eog-plugins,added,tetromino,2012-05-14 04:21:49 media-libs/libpostproc,added,lu_zero,2012-05-14 19:12:12 dev-python/embedly,added,rafaelmartins,2012-05-15 01:20:59 sci-geosciences/geocode-glib,added,tetromino,2012-05-15 05:57:42 x11-misc/tinymount,added,ssuominen,2012-05-15 10:44:10 dev-python/cssselect,added,xarthisius,2012-05-15 15:35:33 dev-lang/go,added,williamh,2012-05-15 18:11:26 net-wireless/reaver,added,maksbotan,2012-05-15 19:39:11 x11-misc/seetxt,added,dev-zero,2012-05-16 06:34:17 sys-cluster/libqb,added,xarthisius,2012-05-16 10:29:46 games-arcade/opensonic,added,hasufell,2012-05-16 18:42:50 dev-perl/User-Identity,added,tove,2012-05-16 18:55:15 dev-perl/Object-Realize-Later,added,tove,2012-05-16 19:03:20 dev-perl/Mail-Box,added,tove,2012-05-16 20:49:46 dev-cpp/ETL,added,lu_zero,2012-05-17 03:20:30 games-arcade/mari0,added,hasufell,2012-05-17 15:22:25 kde-misc/ktouchpadenabler,added,johu,2012-05-17 21:22:11
Re: [gentoo-dev] Re: enhancement for doicon/newicon in eutils.eclass
On 05/21/2012 02:01 AM, Jonathan Callen wrote:
On 05/20/2012 07:49 PM, hasufell wrote:
On 05/21/2012 01:36 AM, Alexis Ballier wrote:
On Mon, 21 May 2012 01:24:13 +0200 hasufell
hasuf...@gentoo.org wrote:
I want support for installing icons into the appropriate
directories which are under /usr/share/icons/... and not
just pixmaps.
proposal attached + diff
This should not break existing ebuilds. Tested a bit and
open for review now.
maybe i missed something but cant you just make doicon a
newicon wrapper and remove all that code duplication ?
I don't see how. doicon supports installing multiple icons
with one command, as well as directories. That does not work for
newicon.
Normally, new* is a wrapper for do* that does something like:
newfoo() { # argument checking omitted... cp -P ${1} ${T}/${2}
dofoo ${T}/${2} }
That does not use newins like the old function. Why would I want to
change that?
