Re: [gentoo-dev] [PATCH] autotools-utils.eclass: punt unnecessary .la files even w/ USE=static-libs.
On Mon, 12 Sep 2011 17:10:49 -0500
Donnie Berkholz dberkh...@gentoo.org wrote:
On 23:58 Mon 12 Sep , Michał Górny wrote:
On Mon, 12 Sep 2011 16:00:20 -0500
Donnie Berkholz dberkh...@gentoo.org wrote:
local f
for f in $(find ${D} -type f -name '*.la'); do
# Keep only .la files with shouldnotlink=yes -
likely plugins local shouldnotlink=$(sed -ne
'/^shouldnotlink=yes$/p' ${f}) if [[ $1 == 'all' || -z
${shouldnotlink} ]]; then
+ if [[ $1 == 'only-not-required' ]];
then
Is there a case where one of those arguments might be $2 but you'd
still want to run this?
Er? What are you referring to?
Two things.
1. This is only reached if shouldnotlink is false. That means it's
only the things that you are already assuming are plugins, right? If
so, why is this even done?
That simply means that we're never removing .la files for plugins
(right now) because plugin loaders may need them with shared linking.
The other case are regular libraries where .la files are removed as
described above.
2. What happens if I call it with `remove_libtool_files all
only-not-required`? Nobody ever does any checking of the # of args.
Will add.
+ # remove .la files only
when .pc files provide the libs
+ # already or they don't give
any information
+ ! has $(basename ${f})
${pc_libs} \
+[[ -n
$(sed -n \
The comment says or but I see an and here.
Because everything's negated here. Boolean magic :D.
OK, got it. Stop writing confusing logic. =P
It's confusing because of that 'continue', I guess ;P.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1.4.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/09/2011 09:55 μμ, Peter Volkov (pva) wrote: pva 11/09/12 18:55:52 Modified: ChangeLog Added: wireshark-1.6.2.ebuild wireshark-1.4.9.ebuild Removed: wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1.4.4.ebuild wireshark-1.4.6-r1.ebuild Log: Version bump. Fixes security bug #381551, thank GLSAMaker/CVETool Bot. Added 1.6.2, bug #370683. 1.6.2 also fixes bug 373545 wrt Francesco Lamonica. Drop old. ... !!net-analyzer/wireshark-1.6.0_rc1 Why is wireshark blocking itself on DEPEND? is this a known bug that prevents normal update from old to new version? It is a bit odd to have to remove the existing installation in order to update to a new one - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJObxd4AAoJEPqDWhW0r/LC+KwP/jZqFJdVjpSbh7QQfyJWQBCY WL9wVwVBDgb+onb3yh1VzGMae8rdkqphmdpf2sQU1L/rhsyO1XCx++UN1Hng0Y7X j9RkNNMnKEue/aeBgqk5UOPUmuSOInzgdxcp5kio36MGM1DHIU1l4Usi+F9vwo5k 29XZzT3UT/kFuhXyOdHC0i5YCZMDfvCOea1bcG9P9zSk/jjXg3pRJLrZbu8vh6Pq zApTT5P/O19X+ms1oOuzBdOouMRYL4ZJgnXTertbJeBsYrHQEW7ah3Koucsf7k7V qdYMVPOqvdrICjQpLlqplzZDPzWn1L/S2Yqo+U3HAuuJFmX6fO9o0Ax752ptTkZj JoGP9qs73jE/ef9NMEmAEquMFbE+bJFhXJtTLaM+7xyd0y9LA+IigvZlt7WlwXJm IFSBdh3SziOGcZJzwuZlWvdB3pgx/U6292/d3J0l88nJWUw732OR2GW4w+VQnwL1 uoLUZTuFter2rY9OPJC6Rh7qWGCjMIf01JOzDCwimhoevjrFv+0QvxA+kY5cSIxh xdB93v6a0+IrnIV4M31mKeOKxkxm8oazS/qZ9HVox7zQVdaLpBLEQJwJJn0C8z5R +apunxwezD6nMahPZ5+iT49tmbtoT4GY5H4xRfJUWiFeZNhCXQV5ECLiC3AQ4h8c F1XxV5mvoZSDygbpR51+ =ZtnX -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1.4.4
Il giorno mar, 13/09/2011 alle 11.42 +0300, Markos Chandras ha scritto: Why is wireshark blocking itself on DEPEND? is this a known bug that prevents normal update from old to new version? It is a bit odd to have to remove the existing installation in order to update to a new one AFAICT it might be related to the fact that wireshark tends to link to its own installed libraries when being rebuilt. Yes that means that its build system is tfu. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1
On Tue, 13 Sep 2011 11:23:18 +0200 Diego Elio Pettenò flamee...@gentoo.org wrote: Il giorno mar, 13/09/2011 alle 11.42 +0300, Markos Chandras ha scritto: Why is wireshark blocking itself on DEPEND? is this a known bug that prevents normal update from old to new version? It is a bit odd to have to remove the existing installation in order to update to a new one AFAICT it might be related to the fact that wireshark tends to link to its own installed libraries when being rebuilt. Yes that means that its build system is tfu. In that case blocking just old versions is wrong, since if your installed version is broken and you try to reinstall, you'll need to uninstall first too. (Incidentally, there's a bug in libtool that causes it to randomly link to stuff on / if you try to create an executable that links to both a built library and an installed library. It's probably fairly common, but people won't necessarily notice.) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1
2011/9/13 Markos Chandras hwoar...@gentoo.org: On 12/09/2011 09:55 μμ, Peter Volkov (pva) wrote: pva 11/09/12 18:55:52 Modified: ChangeLog Added: wireshark-1.6.2.ebuild wireshark-1.4.9.ebuild Removed: wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1.4.4.ebuild wireshark-1.4.6-r1.ebuild Log: Version bump. Fixes security bug #381551, thank GLSAMaker/CVETool Bot. Added 1.6.2, bug #370683. 1.6.2 also fixes bug 373545 wrt Francesco Lamonica. Drop old. ... !!net-analyzer/wireshark-1.6.0_rc1 Why is wireshark blocking itself on DEPEND? is this a known bug that prevents normal update from old to new version? It is a bit odd to have to remove the existing installation in order to update to a new one - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 Actually this s**t happens a lot, due to broken build system the package links to the already in-system packages and use headers from system. So one has to block the major versions to avoid the breakages during the build Cheers Tom
[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1
Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto: In that case blocking just old versions is wrong, since if your installed version is broken and you try to reinstall, you'll need to uninstall first too. It doesn't matter as much when it's the same version because then it would have the same soversion and thus it wouldn't cause _visible_ trouble. It might be interesting to note that it seems like rc4-final also causes the same problem. (Incidentally, there's a bug in libtool that causes it to randomly link to stuff on / if you try to create an executable that links to both a built library and an installed library. It's probably fairly common, but people won't necessarily notice.) Just for completeness sake, this can usually be fixed/worked around by making sure to list just-built .la files _before_ the /usr libraries. I had to work that around on opensc before. PAM also suffers from the same issue _if_ the .la files are kept around. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
Such checks are used at least in autotools-utils kde* eclasses, and
are done wrong there. Thus, I've created a little reusable snippet
suitable for eutils.
---
eclass/eutils.eclass | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index cd1f9ff..3d99f92 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -2028,3 +2028,18 @@ path_exists() {
-o) return $(( r == $# )) ;;
esac
}
+
+# @FUNCTION: has_iuse
+# @USAGE: flag
+# @DESCRIPTION:
+# Determines whether the given flag is in IUSE. Strips IUSE default prefixes
+# as necessary.
+has_iuse() {
+ debug-print-function ${FUNCNAME} $@
+ [[ ${#} -eq 1 ]] || die 'Invalid args to has_iuse()'
+
+ local flag=${1}
+ local liuse=( ${IUSE} )
+
+ has ${flag} ${liuse[@]#[+-]}
+}
--
1.7.6.1
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. +# @USAGE: flag Ah, this should've been 'flag'; fixed already. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wiresha
On Tue, 13 Sep 2011 11:53:28 +0200 Diego Elio Pettenò flamee...@gentoo.org wrote: Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto: In that case blocking just old versions is wrong, since if your installed version is broken and you try to reinstall, you'll need to uninstall first too. It doesn't matter as much when it's the same version because then it would have the same soversion and thus it wouldn't cause _visible_ trouble. It would if the version on / is broken and you're reinstalling to try to fix it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: Such checks are used at least in autotools-utils kde* eclasses, and are done wrong there. Thus, I've created a little reusable snippet suitable for eutils. Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. In particular, what happens if you do something like this in an eclass: IUSE=foo has_iuse bar DEPEND=cat/bar and then inherit from an ebuild that sets IUSE=bar, possibly after the inherit? What about if the bar comes from another eclass? Or worse... has_iuse bar IUSE=bar Now what? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On 09/13/2011 06:29, Michał Górny wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. 'in_iuse' or 'iuse_contains'? if $(in_iuse foobar); do $(cake) fi or if $(iuse_contains foobar); do $(cake) fi Thinking from just a general pronunciation perspective, though. Assuming someone reads that as If in eye-use... or If eye-use contains 'has_iuse' Almost reads as has issues ..., hence, if has issues; then ($cake) $(grief_counseling) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 06:39:13 -0400 Joshua Kinard ku...@gentoo.org wrote: On 09/13/2011 06:29, Michał Górny wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. 'in_iuse' or 'iuse_contains'? if $(in_iuse foobar); do $(cake) fi or if $(iuse_contains foobar); do $(cake) fi Guess just a typo but for the record: if in_iuse foobar; then ... fi i.e. withou $(). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 11:32:40 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: Such checks are used at least in autotools-utils kde* eclasses, and are done wrong there. Thus, I've created a little reusable snippet suitable for eutils. Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. True. I guess there's no way to tell whether a particular IUSE is defined in the ebuild then? Hrm, I guess we'll need to break API compat (and a number of ebuilds then) to get rid of this. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 12:50:30 +0200 Michał Górny mgo...@gentoo.org wrote: Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. True. I guess there's no way to tell whether a particular IUSE is defined in the ebuild then? Hrm, I guess we'll need to break API compat (and a number of ebuilds then) to get rid of this. You don't do it by checking IUSE. You do it by having the ebuild define a variable like WANT_MONKEY_SUPPORT. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On 09/13/2011 06:46, Michał Górny wrote: Guess just a typo but for the record: No, just a Portal joke :) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] obs eclasses
Hi,
please take a look at attached eclasses. Purpose is to make installation
of obs services (plugins for osc) easier.
Comments and improvements are welcome.
Regards
--
Michal Hrusecky mi...@gentoo.org
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: obs-download.eclass
# @MAINTAINER:
# mi...@gentoo.org
# @BLURB: Reduces code duplication in the downloading from obs.
# @DESCRIPTION:
# This eclass constructs OBS_URI based on provided project in openSUSE Build
# Service and package name. It can be used later by packages/eclasses to
# download actual files.
#
# All you need to do in order to use it is set OBS_PROJECT and OBS_PACKAGE and
# inherit this eclass. It will provide OBS_URI in return which you will prepend
# to your files and use in SRC_URI. Alternatively you can just set
# OPENSUSE_RELEASE and OBS_PACKAGE and it will give you back OBS_URI for
# downloading files from obs projects corresponding to the specified openSUSE
# release.
# @ECLASS-VARIABLE: OPENSUSE_RELEASE
# @DEFAULT_UNSET
# @DESCRIPTION:
# From which stable openSUSE realease to take files.
# @ECLASS-VARIABLE: OBS_PROJECT
# @DEFAULT_UNSET
# @DESCRIPTION:
# In which obs project pakage is. This variable don't have to be set, if
# OPENSUSE_RELEASE is provided.
# @ECLASS-VARIABLE: OPENSUSE_PACKAGE
# @REQUIRED
# @DESCRIPTION:
# Name of the package we want to take files from.
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
OBS_URI=https://api.opensuse.org/public/source/${OBS_PROJECT}/${OBS_PACKAGE};
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: obs-service.eclass
# @MAINTAINER:
# mi...@gentoo.org
# @BLURB: Reduces code duplication in the obs services.
# @DESCRIPTION:
# This eclass makes it easier to package obs services. Based on provided
# information it will all neede variables and takes care of installation.
#
# @EXAMPLE:
# Typical ebuild using obs-service.eclass:
#
# @CODE
# EAPI=4
#
# inherit obs-service
#
# KEYWORDS=
#
# DEPEND=
# RDEPEND=${DEPEND}
#
# @CODE
# @ECLASS-VARIABLE: OBS_SERVICE_NAME
# @DESCRIPTION:
# Name of the service. If not set, it is taken from ${PN}.
# @ECLASS-VARIABLE: OPENSUSE_RELEASE
# @DESCRIPTION:
# From which stable openSUSE realease to take a package.
# @ECLASS-VARIABLE: ADDITIONAL_FILES
# @DEFAULT_UNSET
# @DESCRIPTION:
# If any additional files are needed.
case ${EAPI:-0} in
4) : ;;
*) die EAPI=${EAPI} is not supported ;;
esac
HOMEPAGE=http://en.opensuse.org/openSUSE:OSC;
LICENSE=GPL-2
SLOT=0
IUSE=
RDEPEND+=dev-util/osc
[[ -n ${OBS_SERVICE_NAME} ]] || OBS_SERVICE_NAME=${PN/obs-service-/}
[[ -n ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:Tools
DESCRIPTION=Open Build Service client module - ${OBS_SERVICE_NAME} service
OBS_PACKAGE=obs-service-${OBS_SERVICE_NAME}
inherit obs-download
SRC_URI=${OBS_URI}/${OBS_SERVICE_NAME}
SRC_URI+= ${OBS_URI}/${OBS_SERVICE_NAME}.service
for i in ${ADDITIONAL_FILES}; do
SRC_URI+= ${OBS_URI}/${i}
done
S=${WORKDIR}
# @FUNCTION: obs-service_src_configure
# @DESCRIPTION:
# Does nothing. Files are not compressed.
obs-service_src_unpack() {
debug-print-function ${FUNCNAME} $@
}
# @FUNCTION: obs-service_src_install
# @DESCRIPTION:
# Does the installation of the downloaded files.
obs-service_src_install() {
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
doexe ${DISTDIR}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
doexe ${DISTDIR}/$i
done
fi
}
EXPORT_FUNCTIONS src_install src_unpack
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] obs eclasses
Hi,
Excerpts from Michal Hrusecky's message of 2011-09-13 13:11:28 +0200:
Comments and improvements are welcome.
Just some minor remarks:
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
You don't need -n/-z with [[.
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
So:
[[ ${OPENSUSE_RELEASE} ]] OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
obs-service_src_install() {
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
doexe ${DISTDIR}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print ${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
doexe ${DISTDIR}/$i
just in case.
done
fi
}
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
[gentoo-dev] Lastrite: xdtv, video-entropyd, qutecom, vdr-pvr350, SDLcam, vdr-avards, vdr-atmo, and gnomeradio
https://bugs.gentoo.org/showdependencytree.cgi?id=359595hide_resolved=1 With these masked, only media-video/lives and old version of libdc1394 remain. That we know of. Old version of libdc1394 is still in tree for ptlib, and it's optional feature, thus not really an issue -- will remove the support since it seems maintainers are nowhere to be found? Feel free to rescue any package you want and unmask it when fixed, without prior notification. # Samuli Suominen ssuomi...@gentoo.org (13 Sep 2011) # Fails to build with linux-headers-2.6.38 and above, plus other issues # # xdtv, bugs 359791, 268800, 250879 # video-entropyd, bugs 360871, 334895 # qutecom, bugs 361181, 354803, 324627, 315051, 315045 # gnomeradio, bug 376443 # vdr-atmo, bug 370417 # vdr-avards, bug 368921 # SDLcam, bug 364821 # vdr-pvr350, bug 364669 # # Removal in 30 days media-tv/xdtv media-video/video-entropyd net-im/qutecom media-plugins/vdr-pvr350 media-video/SDLcam media-plugins/vdr-avards media-plugins/vdr-atmo media-sound/gnomeradio
Re: [gentoo-dev] [RFC] obs eclasses
On 09/13/2011 07:24, Amadeusz Żołnowski wrote:
Hi,
Excerpts from Michal Hrusecky's message of 2011-09-13 13:11:28 +0200:
Comments and improvements are welcome.
Just some minor remarks:
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
You don't need -n/-z with [[.
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
What about other comparisons, like -f, -e, or -d? Bash's manpage only says
[[ expression ]] -- it doesn't seem to go into the level of detail (at least
not in the section that I quickly perused) about what flag operators are
necessary or not.
Also, is this a bash4-only thing, or bash3 and/or bash2 as well?
If yes to above, we should get this edited and fixed up, then, because it
uses -z/-n inside [[ ]]:
http://devmanual.gentoo.org/tools-reference/bash/index.html
Oh, forgot, it won't break initscripts, will it?
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between.
--Emperor Turhan, Centauri Republic
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] obs eclasses
Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 15:02:43 +0200 Amadeusz Żołnowski aide...@gentoo.org wrote: OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? It was to prevent Arfrever from doing insane things :D. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wiresha
On Tuesday, September 13, 2011 06:24:51 Ciaran McCreesh wrote: On Tue, 13 Sep 2011 11:53:28 +0200 Diego Elio Pettenò wrote: Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto: In that case blocking just old versions is wrong, since if your installed version is broken and you try to reinstall, you'll need to uninstall first too. It doesn't matter as much when it's the same version because then it would have the same soversion and thus it wouldn't cause _visible_ trouble. It would if the version on / is broken and you're reinstalling to try to fix it. a largely irrelevant edge case that cases little to no harm -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wiresha
On Tuesday, September 13, 2011 05:53:28 Diego Elio Pettenò wrote: Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto: (Incidentally, there's a bug in libtool that causes it to randomly link to stuff on / if you try to create an executable that links to both a built library and an installed library. It's probably fairly common, but people won't necessarily notice.) Just for completeness sake, this can usually be fixed/worked around by making sure to list just-built .la files _before_ the /usr libraries. I had to work that around on opensc before. PAM also suffers from the same issue _if_ the .la files are kept around. that's part of the issue. the fix-relink patch that we carry in ELT-patches for ~8 years now is the other part. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On 06:39 Tue 13 Sep , Joshua Kinard wrote: On 09/13/2011 06:29, Michał Górny wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. 'in_iuse' or 'iuse_contains'? I'd prefer to keep consistency with the parent function has(), so it's obvious exactly how it will work. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpA9WTwC02k1.pgp Description: PGP signature
[gentoo-dev] [PATCH autotools-utils 3/9] For .la removal, look for static archives rather than USE=static-libs.
---
eclass/autotools-utils.eclass | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index 31d228b..ab8650f 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -132,13 +132,13 @@ _check_build_dir() {
}
# @FUNCTION: remove_libtool_files
-# @USAGE: [all|none]
+# @USAGE: [all]
# @DESCRIPTION:
# Determines unnecessary libtool files (.la) and libtool static archives (.a)
# and removes them from installation image.
+#
# To unconditionally remove all libtool files, pass 'all' as argument.
-# To leave all libtool files alone, pass 'none' as argument.
-# Unnecessary static archives are removed in any case.
+# Otherwise, libtool archives required for static linking will be preserved.
#
# In most cases it's not necessary to manually invoke this function.
# See autotools-utils_src_install for reference.
@@ -147,14 +147,17 @@ remove_libtool_files() {
local f
find ${D} -type f -name '*.la' -print0 | while read -r -d '' f; do
- # Keep only .la files with shouldnotlink=yes - likely plugins
local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
- if [[ $1 == 'all' || -z ${shouldnotlink} ]]; then
- if [[ $1 != 'none' ]]; then
- einfo Removing unnecessary ${f#${D%/}}
- rm -f ${f}
- fi
+ local archivefile=${f/%.la/.a}
+
+ # Keep .la files when:
+ # - they have shouldnotlink=yes - likely plugins,
+ # - respective static archive exists.
+ if [[ $1 == 'all' || ( -z ${shouldnotlink} ! -f
${archivefile} ) ]]; then
+ einfo Removing unnecessary ${f#${D%/}}
+ rm -f ${f}
fi
+
# Remove static libs we're not supposed to link against
if [[ -n ${shouldnotlink} ]]; then
local remove=${f/%.la/.a}
@@ -245,9 +248,7 @@ autotools-utils_src_install() {
popd /dev/null
# Remove libtool files and unnecessary static libs
- local args
- has static-libs ${IUSE//+} ! use static-libs || args='none'
- remove_libtool_files ${args}
+ remove_libtool_files
}
# @FUNCTION: autotools-utils_src_test
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 2/9] Strip ${D} from removal message to shorten it.
---
eclass/autotools-utils.eclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index 8bc365d..31d228b 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -151,7 +151,7 @@ remove_libtool_files() {
local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
if [[ $1 == 'all' || -z ${shouldnotlink} ]]; then
if [[ $1 != 'none' ]]; then
- einfo Removing unnecessary ${f}
+ einfo Removing unnecessary ${f#${D%/}}
rm -f ${f}
fi
fi
@@ -159,7 +159,7 @@ remove_libtool_files() {
if [[ -n ${shouldnotlink} ]]; then
local remove=${f/%.la/.a}
[[ ${f} != ${remove} ]] || die 'regex sanity check
failed'
- einfo Removing unnecessary ${remove}
+ einfo Removing unnecessary ${remove#${D%/}}
rm -f ${remove}
fi
done
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.
---
eclass/autotools-utils.eclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index ad5ffea..8bc365d 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -146,7 +146,7 @@ remove_libtool_files() {
debug-print-function ${FUNCNAME} $@
local f
- for f in $(find ${D} -type f -name '*.la'); do
+ find ${D} -type f -name '*.la' -print0 | while read -r -d '' f; do
# Keep only .la files with shouldnotlink=yes - likely plugins
local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
if [[ $1 == 'all' || -z ${shouldnotlink} ]]; then
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 5/9] Check command-line args completely in remove_libtool_files().
---
eclass/autotools-utils.eclass | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index fd644bb..84f6cb6 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -144,6 +144,17 @@ _check_build_dir() {
# See autotools-utils_src_install for reference.
remove_libtool_files() {
debug-print-function ${FUNCNAME} $@
+ local removing_all
+ [[ ${#} -le 1 ]] || die Invalid number of args to ${FUNCNAME}()
+ if [[ ${#} -eq 1 ]]; then
+ case ${1} in
+ all)
+ removing_all=1
+ ;;
+ *)
+ die Invalid argument to ${FUNCNAME}(): ${1}
+ esac
+ fi
local f
find ${D} -type f -name '*.la' -print0 | while read -r -d '' f; do
@@ -154,7 +165,7 @@ remove_libtool_files() {
# Keep .la files when:
# - they have shouldnotlink=yes - likely plugins,
# - respective static archive exists.
- if [[ $1 == 'all' || ( -z ${shouldnotlink} ! -f
${archivefile} ) ]]; then
+ if [[ ${removing_all} || ( -z ${shouldnotlink} ! -f
${archivefile} ) ]]; then
einfo Removing unnecessary ${f#${D%/}}
rm -f ${f} || die
fi
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 4/9] Clean up simplify la removal code a little.
---
eclass/autotools-utils.eclass | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index ab8650f..fd644bb 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -149,21 +149,20 @@ remove_libtool_files() {
find ${D} -type f -name '*.la' -print0 | while read -r -d '' f; do
local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
local archivefile=${f/%.la/.a}
+ [[ ${f} != ${archivefile} ]] || die 'regex sanity check
failed'
# Keep .la files when:
# - they have shouldnotlink=yes - likely plugins,
# - respective static archive exists.
if [[ $1 == 'all' || ( -z ${shouldnotlink} ! -f
${archivefile} ) ]]; then
einfo Removing unnecessary ${f#${D%/}}
- rm -f ${f}
+ rm -f ${f} || die
fi
# Remove static libs we're not supposed to link against
- if [[ -n ${shouldnotlink} ]]; then
- local remove=${f/%.la/.a}
- [[ ${f} != ${remove} ]] || die 'regex sanity check
failed'
- einfo Removing unnecessary ${remove#${D%/}}
- rm -f ${remove}
+ if [[ ${shouldnotlink} ]]; then
+ einfo Removing unnecessary ${archivefile#${D%/}}
+ rm -f ${archivefile} || die
fi
done
}
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 7/9] Drop 'empty' .la files as well (those lacking libs flags).
---
eclass/autotools-utils.eclass | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index 48b39cb..9d7e134 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -162,18 +162,28 @@ remove_libtool_files() {
local archivefile=${f/%.la/.a}
[[ ${f} != ${archivefile} ]] || die 'regex sanity check
failed'
- # Remove static libs we're not supposed to link against
+ # Remove static libs we're not supposed to link against.
if [[ ${shouldnotlink} ]]; then
einfo Removing unnecessary ${archivefile#${D%/}}
rm -f ${archivefile} || die
- # We're never going to remove the .la file.
+ # The .la file may be used by a module loader, so avoid
removing it
+ # unless explicitly requested.
[[ ${removing_all} ]] || continue
fi
- # Keep .la files when:
- # - they have shouldnotlink=yes - likely plugins (handled
above),
- # - respective static archive exists.
- if [[ ${removing_all} || ! -f ${archivefile} ]]; then
+ # Remove .la files when:
+ # - user explicitly wants us to remove all .la files,
+ # - respective static archive doesn't exist,
+ # - they don't provide any new information (no libs no flags).
+ local removing
+ if [[ ${removing_all} ]]; then removing=1
+ elif [[ ! -f ${archivefile} ]]; then removing=1
+ elif [[ ! $(sed -n -e \
+
s/^\(dependency_libs\|inherited_linker_flags\)='\(.*\)'$/\2/p \
+ ${f}) ]]; then removing=1
+ fi
+
+ if [[ ${removing} ]]; then
einfo Removing unnecessary ${f#${D%/}}
rm -f ${f} || die
fi
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 8/9] Remove static libs covered by .pc files as well.
---
eclass/autotools-utils.eclass | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index 9d7e134..2e01dcc 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -156,6 +156,15 @@ remove_libtool_files() {
esac
fi
+ local pc_libs=()
+ if [[ ! ${removing_all} ]]; then
+ local arg
+ for arg in $(find ${D} -name '*.pc' -exec \
+ sed -n -e 's;^Libs:;;p' {} +); do
+ [[ ${arg} == -l* ]] pc_libs+=(lib${arg#-l}.la)
+ done
+ fi
+
local f
find ${D} -type f -name '*.la' -print0 | while read -r -d '' f; do
local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
@@ -174,10 +183,12 @@ remove_libtool_files() {
# Remove .la files when:
# - user explicitly wants us to remove all .la files,
# - respective static archive doesn't exist,
+ # - they are covered by a .pc file already,
# - they don't provide any new information (no libs no flags).
local removing
if [[ ${removing_all} ]]; then removing=1
elif [[ ! -f ${archivefile} ]]; then removing=1
+ elif has $(basename ${f}) ${pc_libs[@]}; then removing=1
elif [[ ! $(sed -n -e \
s/^\(dependency_libs\|inherited_linker_flags\)='\(.*\)'$/\2/p \
${f}) ]]; then removing=1
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 9/9] Explain .la removal reasons in output.
---
eclass/autotools-utils.eclass | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index 2e01dcc..495244b 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -186,16 +186,17 @@ remove_libtool_files() {
# - they are covered by a .pc file already,
# - they don't provide any new information (no libs no flags).
local removing
- if [[ ${removing_all} ]]; then removing=1
- elif [[ ! -f ${archivefile} ]]; then removing=1
- elif has $(basename ${f}) ${pc_libs[@]}; then removing=1
+ if [[ ${removing_all} ]]; then removing='forced'
+ elif [[ ! -f ${archivefile} ]]; then removing='no static
archive'
+ elif has $(basename ${f}) ${pc_libs[@]}; then
+ removing='covered by .pc'
elif [[ ! $(sed -n -e \
s/^\(dependency_libs\|inherited_linker_flags\)='\(.*\)'$/\2/p \
- ${f}) ]]; then removing=1
+ ${f}) ]]; then removing='no libs flags'
fi
if [[ ${removing} ]]; then
- einfo Removing unnecessary ${f#${D%/}}
+ einfo Removing unnecessary ${f#${D%/}} (${removing})
rm -f ${f} || die
fi
done
--
1.7.6.1
[gentoo-dev] [PATCH autotools-utils 6/9] Refactor remove_libtool_files() to simplify conditions.
---
eclass/autotools-utils.eclass | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index 84f6cb6..48b39cb 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -162,18 +162,20 @@ remove_libtool_files() {
local archivefile=${f/%.la/.a}
[[ ${f} != ${archivefile} ]] || die 'regex sanity check
failed'
- # Keep .la files when:
- # - they have shouldnotlink=yes - likely plugins,
- # - respective static archive exists.
- if [[ ${removing_all} || ( -z ${shouldnotlink} ! -f
${archivefile} ) ]]; then
- einfo Removing unnecessary ${f#${D%/}}
- rm -f ${f} || die
- fi
-
# Remove static libs we're not supposed to link against
if [[ ${shouldnotlink} ]]; then
einfo Removing unnecessary ${archivefile#${D%/}}
rm -f ${archivefile} || die
+ # We're never going to remove the .la file.
+ [[ ${removing_all} ]] || continue
+ fi
+
+ # Keep .la files when:
+ # - they have shouldnotlink=yes - likely plugins (handled
above),
+ # - respective static archive exists.
+ if [[ ${removing_all} || ! -f ${archivefile} ]]; then
+ einfo Removing unnecessary ${f#${D%/}}
+ rm -f ${f} || die
fi
done
}
--
1.7.6.1
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tuesday, September 13, 2011 06:46:33 Ciaran McCreesh wrote: On Tue, 13 Sep 2011 12:50:30 +0200 Michał Górny wrote: Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. True. I guess there's no way to tell whether a particular IUSE is defined in the ebuild then? Hrm, I guess we'll need to break API compat (and a number of ebuilds then) to get rid of this. You don't do it by checking IUSE. You do it by having the ebuild define a variable like WANT_MONKEY_SUPPORT. it's a crap shoot. as long as Michał's proposed func doesnt attempt to make guarantees that don't exist now, i think it's fine. we have ebuilds/eclasses that are already using it, so unifying it purely for the [+-] cleanup makes sense to me. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] obs eclasses
Amadeusz Żołnowski - 13:24 13.09.11 wrote:
Hi,
Excerpts from Michal Hrusecky's message of 2011-09-13 13:11:28 +0200:
Comments and improvements are welcome.
Just some minor remarks:
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
You don't need -n/-z with [[.
But they don't do any harm either, right ;-)
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
So:
[[ ${OPENSUSE_RELEASE} ]] OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
obs-service_src_install() {
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
doexe ${DISTDIR}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print ${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
doexe ${DISTDIR}/$i
just in case.
Fixed.
--
Michal Hrusecky mi...@gentoo.org
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] obs eclasses
On 15:02 Tue 13 Sep , Amadeusz Żołnowski wrote: Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp6rUsNsnKPn.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On 13:11 Tue 13 Sep , Michal Hrusecky wrote: # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ # @ECLASS: obs-download.eclass Are there going to be lots of packages using this and not the other eclass? I wonder whether there really need to be two of them. # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the downloading from obs. Could you tell us what obs is in the blurb too? I had no clue what this email was about (obs, osc, etc are meaningless to me) until I got down to the eclass description. # @ECLASS: obs-service.eclass # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the obs services. # @DESCRIPTION: # This eclass makes it easier to package obs services. Based on provided # information it will all neede variables and takes care of installation. Lots of typos here. HOMEPAGE=http://en.opensuse.org/openSUSE:OSC; LICENSE=GPL-2 SLOT=0 IUSE= RDEPEND+=dev-util/osc You probably want a space here. RDEPEND+= dev-util/osc -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpkPf2od7LwK.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.
2011/9/13 Michał Górny mgo...@gentoo.org: --- eclass/autotools-utils.eclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I don't think sending 9 patches is very useful for this mailing list. Next time just sent a link to a git repo or something? Cheers, Dirkjan
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, Sep 13, 2011 at 8:29 PM, Donnie Berkholz dberkh...@gentoo.org wrote: HOMEPAGE=http://en.opensuse.org/openSUSE:OSC; LICENSE=GPL-2 SLOT=0 IUSE= RDEPEND+=dev-util/osc You probably want a space here. RDEPEND+= dev-util/osc Slightly bike-sheddy, but it's less error-prone to use: RDEPEND=dev-util/osc iirc, portage handles merging of the values of *DEPEND defined in eclasses and ebuilds. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] obs eclasses
On 09/13/11 16:44, Donnie Berkholz wrote: On 15:02 Tue 13 Sep , Amadeusz Żołnowski wrote: Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. Actually it's worse - PMS enforces this, and the only clean way out is to patch/fix/extend PMS to allow bash4 - but that breaks compatibility in silly ways. The proper way to handle that? I'm not sure, since we had a long fight to get PMS to acknowledge bash 3.2 instead of 3.0 I'm mostly ignoring PMS as it doesn't care about reality. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. That's not quite correct for this case, but it shows that we need to discuss destructive changes (in the sense that they are not backwards-compatible etc.) to have any decent progress
Re: [gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.
On Tue, Sep 13, 2011 at 8:43 PM, Dirkjan Ochtman d...@gentoo.org wrote: 2011/9/13 Michał Górny mgo...@gentoo.org: --- eclass/autotools-utils.eclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I don't think sending 9 patches is very useful for this mailing list. Next time just sent a link to a git repo or something? On the contrary, I like that mgorny sent separate completely independent patches for review to the list instead of either sending on huge chunk, or not sending patches at all. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] obs eclasses
On 17:58 Tue 13 Sep , Patrick Lauer wrote: On 09/13/11 16:44, Donnie Berkholz wrote: It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. Actually it's worse - PMS enforces this, and the only clean way out is to patch/fix/extend PMS to allow bash4 - but that breaks compatibility in silly ways. The proper way to handle that? I'm not sure, since we had a long fight to get PMS to acknowledge bash 3.2 instead of 3.0 I'm mostly ignoring PMS as it doesn't care about reality. Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. That's not quite correct for this case, but it shows that we need to discuss destructive changes (in the sense that they are not backwards-compatible etc.) to have any decent progress Maybe a way to set tree-level dependencies/EAPIs/features is something we seriously need to get going on. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpdqwj5WnNHA.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. Ulrich
Re: [gentoo-dev] [RFC] obs eclasses
2011/9/13 Ulrich Mueller u...@gentoo.org: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. I would really like if we do it properly this time. So it is done for goot and does not reappear from time to time. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. As is Ulrich saying, it was done because everyone at that point was using such features. Not because we wanted those features to be used. Cheers Tom
Re: [gentoo-dev] [RFC] obs eclasses
Excerpts from Ulrich Mueller's message of 2011-09-13 19:25:59 +0200: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. Ulrich So we need to do it “illegally” first to make it “legal”? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 19:25:59 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. The current situation is that you can't even install bash-3.2 systemwide because of the number of packages [ebuilds/eclasses] requiring on bash-4. I myself had to prefix-install bash to test my code against it. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Packages up for grabs due stefaan retirement
Due stefaan retirement the following packages need a new maintainer: media-libs/libdc1394 media-video/coriander net-misc/ng-utils Thanks for taking them signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due stefaan retirement
On 09/13/2011 08:57 PM, Pacho Ramos wrote: Due stefaan retirement the following packages need a new maintainer: media-libs/libdc1394 media-video will take this, i'm working on the single remaining open bug it has as we speak, as part of the = linux-headers-2.6.38 effort thanks - Samuli
[gentoo-dev] Packages up for grabs due tanderson retirement
Due tanderson retirement the following packages need a new maintainer: dev-libs/check dev-libs/stfl net-libs/udns Thanks for taking them signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.
On Tue, 13 Sep 2011 17:13:11 +0200 Dirkjan Ochtman d...@gentoo.org wrote: 2011/9/13 Michał Górny mgo...@gentoo.org: --- eclass/autotools-utils.eclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I don't think sending 9 patches is very useful for this mailing list. Next time just sent a link to a git repo or something? Erm, maybe I should've attached a complete diff as well, or complete updated eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011, Michał Górny wrote: The current situation is that you can't even install bash-3.2 systemwide because of the number of packages [ebuilds/eclasses] requiring on bash-4. Have you filed bug reports for these? Ulrich
Re: [gentoo-dev] Packages up for grabs due tanderson retirement
On 2011-09-13 Tue 11:31, Pacho Ramos wrote: Due tanderson retirement the following packages need a new maintainer: dev-libs/stfl I'll take this since newsbeuter depends on it. Tim pgpx5yj9g9A9m.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 20:40:12 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 13 Sep 2011, Michał Górny wrote: The current situation is that you can't even install bash-3.2 systemwide because of the number of packages [ebuilds/eclasses] requiring on bash-4. Have you filed bug reports for these? I mean having *DEPEND==bash-4. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Packages up for grabs due arfrever retirement
Due arfrever retirement the following packages need a new maintainer: dev-util/global net-irc/kvirc net-libs/neon net-libs/serf net-misc/cadaver Thanks for taking them signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due tanderson retirement
On Tue, Sep 13, 2011 at 08:31:33PM +0200, Pacho Ramos wrote: Due tanderson retirement the following packages need a new maintainer: dev-libs/check dev-libs/stfl net-libs/udns Thanks for taking them I'll take dev-libs/check. -- binki Look out for missing or extraneous apostrophes! pgpORS9uj637r.pgp Description: PGP signature
[gentoo-dev] Packages up for grabs due ayoy retirement
Due ayoy retirement the following packages need a new maintainer: dev-vcs/git-sh sci-libs/getdata Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due cbrannon retirement
Due cbrannon retirement the following packages need a new maintainer: dev-db/unixODBC net-misc/telnet-bsd Thanks for taking them signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due cbrannon retirement
* Pacho Ramos schrieb am 13.09.11 um 21:24 Uhr: Due cbrannon retirement the following packages need a new maintainer: net-misc/telnet-bsd I will take that one. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpYVzqWJeeUl.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due ayoy retirement
On 9/13/11 9:17 PM, Pacho Ramos wrote: Due ayoy retirement the following packages need a new maintainer: dev-vcs/git-sh I take this. sci-libs/getdata sci takes this Thanks for taking them signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due cbrannon retirement
On Tue, Sep 13, 2011 at 3:24 PM, Pacho Ramos pa...@gentoo.org wrote: Due cbrannon retirement the following packages need a new maintainer: dev-db/unixODBC I'll take dev-db/unixODBC Thanks, net-misc/telnet-bsd Thanks for taking them -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] Packages up for grabs due cbrannon retirement
On 09/13/2011 03:24 PM, Pacho Ramos wrote: Due cbrannon retirement the following packages need a new maintainer: dev-db/unixODBC I've use this and don't want to see it rot. If no one wants it, I'll give it love. I have no strong feelings about maintaining it, so if someone else wants to, fine by me, as long as it stays alive. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Packages up for grabs due cbrannon retirement
On Tue, Sep 13, 2011 at 4:39 PM, Anthony G. Basile bluen...@gentoo.org wrote: On 09/13/2011 03:24 PM, Pacho Ramos wrote: Due cbrannon retirement the following packages need a new maintainer: dev-db/unixODBC I've use this and don't want to see it rot. If no one wants it, I'll give it love. I have no strong feelings about maintaining it, so if someone else wants to, fine by me, as long as it stays alive. Hi Anthony, I'm actively using it, so I took it. Feel free to co-maintain if you want to. Best regards, -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535 -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] Packages up for grabs due cbrannon retirement
On 09/13/2011 11:39 PM, Anthony G. Basile wrote: On 09/13/2011 03:24 PM, Pacho Ramos wrote: Due cbrannon retirement the following packages need a new maintainer: dev-db/unixODBC I've use this and don't want to see it rot. If no one wants it, I'll give it love. I have no strong feelings about maintaining it, so if someone else wants to, fine by me, as long as it stays alive. I wouldn't worry too much, if noone else is intrested i'll keep it alive like before - Samuli
[gentoo-dev] new `usex` helper
i keep writing little helpers like this in ebuilds:
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
this is so i can do:
export some_var=$(usex some_flag)
and get it set to yes or no
or if i want something a little different, i can do:
export some_var=$(usex some_flag true false)
export some_var=$(usex some_flag y n)
useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR
BOTH !?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 2:56 PM, Mike Frysinger vap...@gentoo.org wrote:
i keep writing little helpers like this in ebuilds:
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
usex...you naughty boy.
this is so i can do:
export some_var=$(usex some_flag)
and get it set to yes or no
If the intent is to use it for logic:
export some_var=$(usex some_flag)
if [[ $some_var == yes ]]; then
# buttsex
fi
Then I recommend making true / false the default and then doing
if $some_var; then
# buttsex
fi
If you are using it more like use_enable then...thats ok I guess ;p
-A
or if i want something a little different, i can do:
export some_var=$(usex some_flag true false)
export some_var=$(usex some_flag y n)
useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR
BOTH !?
-mike
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 06:13:10PM -0400, Mike Frysinger wrote:
On Tuesday, September 13, 2011 18:01:25 Alec Warner wrote:
On Tue, Sep 13, 2011 at 2:56 PM, Mike Frysinger wrote:
this is so i can do:
export some_var=$(usex some_flag)
and get it set to yes or no
If the intent is to use it for logic:
export some_var=$(usex some_flag)
if [[ $some_var == yes ]]; then
# buttsex
fi
that is not the intent
Then I recommend making true / false the default and then doing
if $some_var; then
# buttsex
fi
the point is to use it to construct vars that get passed to scripts like
econf
or programs like emake
ac_cv_some_header=$(usex foo) \
econf ...
emake USE_POOP=$(usex poo)
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
While a bit longer, we likely can gut most of the use_* logic to
use that, and it makes it easier to deal w/ the situations where a
configure's options always assume --enable-blah thus don't export the
option, but *do* export a --disable-blah.
That way we can shift away from
$(use blah use_with blah)
to
$(usex blah --with-blah '')
Or that's the intent at least.
~brian
Re: [gentoo-dev] new `usex` helper
On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpi0BtNsnWIk.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Do both. Specifically, do it right- get it into the format (so it can be relied on and isn't adhoc BS that proceeded EAPI), then push a compat implementation into eclasses for usage by EAPI's less than 5. You get the feature now, and it's sorted properly for moving forward. Not that complex. And yes I'm tired of people bitching about compatibility. I recall a similar group of folk bitching about the lack of compatibility prior to EAPI... it's annoying. /rant ~brian
Re: [gentoo-dev] new `usex` helper
On Tuesday, September 13, 2011 19:08:09 Brian Harring wrote:
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
i dont get it. mine already does exactly this, just in one line.
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
While a bit longer, we likely can gut most of the use_* logic to
use that, and it makes it easier to deal w/ the situations where a
configure's options always assume --enable-blah thus don't export the
option, but *do* export a --disable-blah.
yeah, i thought about replacing use_{with,enable} with usex, but we'd have to
extend usex() a little bit more
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new `usex` helper
On Tuesday, September 13, 2011 22:02:28 Donnie Berkholz wrote:
On 17:56 Tue 13 Sep , Mike Frysinger wrote:
useful enough for EAPI ? or should i just stick it into eutils.eclass
? OR BOTH !?
I prefer to avoid EAPI whenever possible, as it just makes things slower
and more complex.
should be easy to do both:
[[ ${EAPI} == [01234] ]] usex() { ... }
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 10:45:27PM -0400, Mike Frysinger wrote:
On Tuesday, September 13, 2011 19:08:09 Brian Harring wrote:
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
i dont get it. mine already does exactly this, just in one line.
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
Err. Mines prettier?
*cough*
Only real difference is ${2:-yes} versus ${2-yes}; the latter should
be used so that `usex flag '' '--disable-some-feature'` is usable.
While a bit longer, we likely can gut most of the use_* logic to
use that, and it makes it easier to deal w/ the situations where a
configure's options always assume --enable-blah thus don't export the
option, but *do* export a --disable-blah.
yeah, i thought about replacing use_{with,enable} with usex, but we'd have to
extend usex() a little bit more
Only extension I can think of is adding a prefix/postfix... which
frankly seems a bit too much. Anything else you were looking for?
To be clear, I'm more interested in this from the standpoint of making
econf invocations simpler- simplifying use_enable/use_with in the PM
isn't a huge concern to me since they're already pretty bloody
straightforward at this point.
~brian
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 11:41:00 -0500 Donnie Berkholz dberkh...@gentoo.org wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. The last time this happened, the Council said we're doing this once because people have forced our hand, but we're never doing it again. That's not a precedent. Maybe a way to set tree-level dependencies/EAPIs/features is something we seriously need to get going on. No need. GLEP 55 solves it with a far lower impact. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: [gentoo-commits] proj/portage:master commit in: bin/
On 09/12/2011 09:38 PM, Robin H. Johnson wrote: On Tue, Sep 13, 2011 at 03:20:35AM +, Zac Medico wrote: commit: 677240f7b3db66bdcd403c214e5d3fa30e31a24a Author: Zac Medico zmedico AT gentoo DOT org AuthorDate: Tue Sep 13 03:20:00 2011 + Commit: Zac Medico zmedico AT gentoo DOT org CommitDate: Tue Sep 13 03:20:00 2011 + URL: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=677240f7 repoman: don't sign thin manifests Thin manifests imply reliance on the VCS for file integrity, which implies that manifest signatures are not needed. This is only true after the VCS has signed commits. If the VCS does not have signed commits, then we should have this signature. So, should we add the ability to set signed-manifests = false in metadata/layout.conf? I can imagine that people using thin-manifests typically don't want signed-manifests, since it tends the introduce merge conflicts like those that thin-manifests is supposed to avoid. -- Thanks, Zac
Re: [gentoo-portage-dev] Re: [gentoo-commits] proj/portage:master commit in: bin/
On Tue, Sep 13, 2011 at 04:38:35AM +, Robin H. Johnson wrote: On Tue, Sep 13, 2011 at 03:20:35AM +, Zac Medico wrote: commit: 677240f7b3db66bdcd403c214e5d3fa30e31a24a Author: Zac Medico zmedico AT gentoo DOT org AuthorDate: Tue Sep 13 03:20:00 2011 + Commit: Zac Medico zmedico AT gentoo DOT org CommitDate: Tue Sep 13 03:20:00 2011 + URL: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=677240f7 repoman: don't sign thin manifests Thin manifests imply reliance on the VCS for file integrity, which implies that manifest signatures are not needed. This is only true after the VCS has signed commits. If the VCS does not have signed commits, then we should have this signature. This really doesn't provide for much; without a chain of trust to the content of layout.conf, you can't toggle behaviour (making lack of signing a failure) for example. So the manager has to either trust the VCS validity, or require accept mixed signed/unsigned (which opens a new branch of attacks). Worse, what this tries to protect against is the VCS being screwed with- by definition, thin defers that to the VCS, instead providing the data of what the VCS cannot, the distfiles checksums. If an attack on the VCS can be done (whether SHA1 breakage, or just in the middle branch injection), an attacker can just as easily inject in a patch to files/ along w/ a modification to the ebuild to include that trojan. It's a bit harsher than I'd like, but signed thin manifests are security theater as best I can tell. While I grok your concerns, it would be *very* useful to know exactly what attacks a signed manifest precludes that a thin manifest doesn't; all I see is remote distfiles manipulation w/ a branch injection; that same injection can just as easily mangle profile.bashrc, the ebuild itself, or slip patches into files. If it doesn't actually do anything, it should be disabled. On the portage front, this just change portage behaviour to defaulting to signing, rather than configuration based- very least that deserves a PSA notice... ~brian
