[gentoo-dev] Lastrites: app-portage/udept, media-libs/libj2k, media-gfx/cfe, media-gfx/yablex, app-admin/osiris, sys-power/cpufreqd, net-irc/ctrlproxy, x11-misc/pogo, sci-geosciences/openstreetmap-ico
# Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Masked since: # Paul Varner fuzzy...@gentoo.org (06 Apr 2009) # Dead upstream and has issues with newer portages. # Still nobody stepped to maintain it and it's now # completely broken (bug #172611). Removal in a month. app-portage/udept # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Upstream dead since 2004, nothing needs it (#284421) # Removal in a month. media-libs/libj2k # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # No upstream for a long time, better alternatives would # be gbdfed or vim (#286314). Removal in a month. media-gfx/cfe # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Masked since: # Julian Ospald hasuf...@gentoo.org (10 Mar 2013) # Unsupported and full of bundled libs. Only left # for people who don't have python-3.3 yet. # Will be removed once python-3.3 and =blender-2.66 enter ~arch. # # As it's the case now, will be removed in a month (#286758) =media-gfx/blender-2.64a media-gfx/yablex # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Bundles internal copy of berkdb, upstream dead for ages # (#319683). Removal in a month. app-admin/osiris # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Multiple issues and dead for ages (#327735). # You can use cpupower (from sys-power/cpupower or # sys-apps/linux-misc-apps). Removal in a month. sys-power/cpufreqd # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Not compatible with gnutls-3 (#421405), multiple issues # and dead since 2008. Removal in a month. net-irc/ctrlproxy # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Crashes at start, no fix (#394063). Removal in a month. x11-misc/pogo # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Cannot be compiled for a long time (#405649). # Removal in a month. sci-geosciences/openstreetmap-icons # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Runtime failures (#305019), cannot be recompiled # (#352003, #369539, #425484), nobody is taking care of it. # Removal in a month. media-gfx/k3d # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # No longer supported by upstream and nothing needs it # (#489628). Removal in a month. dev-python/telepathy-python # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # No longer works and upstream killed it (#493188). # Removal in a month. media-tv/huludesktop # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # Dead since 2008 and doesn't work with current kernels # (#504168). Removal in a month. app-admin/lcap # Pacho Ramos pa...@gentoo.org (06 Apr 2014) # No needed as its functionality was included to apache # (#504596). Removal in a month. www-apache/mod_chroot
Re: [gentoo-dev] virtual/sctp to choose the right SCTP lib for Linux/FreeBSD?
On Sat, 05 Apr 2014, Joshua Kinard wrote: I've attached a first draft of virtual/sctp/sctp-0.ebuild, which passes repoman checks, but I think it needs to be made multilib-aware. Additionally, that means lksctp-tools probably needs some multilib-magic applied. I am not finding a solid guide on properly upgrading an ebuild to become multilib-aware. Can one of the multilib experts check things and let me know what is needed if people agree this is a good way to go down? This doesn't answer your multilib question, but I believe that kernel_* is not needed in IUSE: IUSE=kernel_linux kernel_FreeBSD static-libs KERNEL is both in USE_EXPAND and USE_EXPAND_IMPLICIT of profiles/base/make.defaults, therefore it's implicit in EAPI 5. I'd also omit all empty variable assignments (like HOMEPAGE=), they are no longer necessary. Ulrich pgpJRbnVdaO97.pgp Description: PGP signature
[gentoo-dev] [PATCH] waf-utils.eclass: respect CFLAGS in linking command
respect CFLAGS in linking command
https://bugs.gentoo.org/show_bug.cgi?id=506956
--- eclass/waf-utils.eclass
+++ eclass/waf-utils.eclass
@@ -56,18 +56,18 @@
[[ -z ${NO_WAF_LIBDIR} ]]
libdir=--libdir=${EPREFIX}/usr/$(get_libdir)
tc-export AR CC CPP CXX RANLIB
- echo CCFLAGS=\${CFLAGS}\ LINKFLAGS=\${LDFLAGS}\ \${WAF_BINARY}\
--prefix=${EPREFIX}/usr ${libdir} $@ configure
+ echo CCFLAGS=\${CFLAGS}\ LINKFLAGS=\${CFLAGS} ${LDFLAGS}\
\${WAF_BINARY}\ --prefix=${EPREFIX}/usr ${libdir} $@ configure
# This condition is required because waf takes even whitespace as
function
# calls, awesome isn't it?
if [[ -z ${NO_WAF_LIBDIR} ]]; then
- CCFLAGS=${CFLAGS} LINKFLAGS=${LDFLAGS} ${WAF_BINARY} \
+ CCFLAGS=${CFLAGS} LINKFLAGS=${CFLAGS} ${LDFLAGS}
${WAF_BINARY} \
--prefix=${EPREFIX}/usr \
${libdir} \
$@ \
configure || die configure failed
else
- CCFLAGS=${CFLAGS} LINKFLAGS=${LDFLAGS} ${WAF_BINARY} \
+ CCFLAGS=${CFLAGS} LINKFLAGS=${CFLAGS} ${LDFLAGS}
${WAF_BINARY} \
--prefix=${EPREFIX}/usr \
$@ \
configure || die configure failed
Re: [gentoo-dev] virtual/sctp to choose the right SCTP lib for Linux/FreeBSD?
On 04/06/2014 04:49, Ulrich Mueller wrote: On Sat, 05 Apr 2014, Joshua Kinard wrote: I've attached a first draft of virtual/sctp/sctp-0.ebuild, which passes repoman checks, but I think it needs to be made multilib-aware. Additionally, that means lksctp-tools probably needs some multilib-magic applied. I am not finding a solid guide on properly upgrading an ebuild to become multilib-aware. Can one of the multilib experts check things and let me know what is needed if people agree this is a good way to go down? This doesn't answer your multilib question, but I believe that kernel_* is not needed in IUSE: IUSE=kernel_linux kernel_FreeBSD static-libs KERNEL is both in USE_EXPAND and USE_EXPAND_IMPLICIT of profiles/base/make.defaults, therefore it's implicit in EAPI 5. Thanks, I removed those and IUSE as well, since it's empty. I'd also omit all empty variable assignments (like HOMEPAGE=), they are no longer necessary. I derived this ebuild from virtual/udev's (as the leftover comment implied). Someone might want to remove the empty vars there as well. Perhaps repoman should check for empty vars like HOMEPAGE/SRC_URI/IUSE and flag as a warning? -- 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 # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ EAPI=5 DESCRIPTION=Virtual to select net-misc/lksctp-tools or sys-freebsd/freebsd-lib for userland SCTP lib support SLOT=0 KEYWORDS=~alpha ~amd64 ~mips ~ppc ~ppc64 ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd RDEPEND=|| ( kernel_linux? ( net-misc/lksctp-tools ) kernel_FreeBSD? ( sys-freebsd/freebsd-lib ) )
Re: [gentoo-dev] virtual/sctp to choose the right SCTP lib for Linux/FreeBSD?
On 04/06/2014 16:06, Joshua Kinard wrote:
On 04/06/2014 04:49, Ulrich Mueller wrote:
On Sat, 05 Apr 2014, Joshua Kinard wrote:
I've attached a first draft of virtual/sctp/sctp-0.ebuild, which
passes repoman checks, but I think it needs to be made
multilib-aware. Additionally, that means lksctp-tools probably needs
some multilib-magic applied. I am not finding a solid guide on
properly upgrading an ebuild to become multilib-aware. Can one of
the multilib experts check things and let me know what is needed if
people agree this is a good way to go down?
This doesn't answer your multilib question, but I believe that
kernel_* is not needed in IUSE:
IUSE=kernel_linux kernel_FreeBSD static-libs
KERNEL is both in USE_EXPAND and USE_EXPAND_IMPLICIT of
profiles/base/make.defaults, therefore it's implicit in EAPI 5.
Thanks, I removed those and IUSE as well, since it's empty.
I'd also omit all empty variable assignments (like HOMEPAGE=),
they are no longer necessary.
I derived this ebuild from virtual/udev's (as the leftover comment implied).
Someone might want to remove the empty vars there as well. Perhaps repoman
should check for empty vars like HOMEPAGE/SRC_URI/IUSE and flag as a warning?
Derp, since this is a virtual for a linkable library, set DEPEND first, then
RDEPEND to ${DEPEND}.
While FBSD is the only other official non-Linux port (I think OBSD/NBSD are
still only in Prefix?), should REQUIRED_USE be set to limit this virtual to
kernel_linux and kernel_FreeBSD?
Hmm, and further thinking, if we had a kFreeBSD variant, things would get
more interesting. Someone would probably have to abstract the SCTP lib code
out of freebsd-lib to work in that environment, since everything would be
running on top of a glibc userland. I wonder if Debian's run into that yet...
--
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
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=5
DESCRIPTION=Virtual to select net-misc/lksctp-tools or sys-freebsd/freebsd-lib
for userland SCTP lib support
SLOT=0
KEYWORDS=~alpha ~amd64 ~mips ~ppc ~ppc64 ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd
~x86-fbsd
DEPEND=|| (
kernel_linux? ( net-misc/lksctp-tools )
kernel_FreeBSD? ( sys-freebsd/freebsd-lib )
)
RDEPEND=${DEPEND}
Re: [gentoo-dev] virtual/sctp to choose the right SCTP lib for Linux/FreeBSD?
On Sun, 06 Apr 2014, Joshua Kinard wrote: I derived this ebuild from virtual/udev's (as the leftover comment implied). Someone might want to remove the empty vars there as well. Perhaps repoman should check for empty vars like HOMEPAGE/SRC_URI/IUSE and flag as a warning? For virtuals, this should be considered indeed. Ulrich pgpO6zfxw260x.pgp Description: PGP signature
Re: [gentoo-dev] virtual/sctp to choose the right SCTP lib for Linux/FreeBSD?
On Sun, 06 Apr 2014, Joshua Kinard wrote:
Derp, since this is a virtual for a linkable library, set DEPEND
first, then RDEPEND to ${DEPEND}.
No, setting RDEPEND (as it was in your previous version) in the
virtual is enough.
The package depending on a virtual for a library must have it in
DEPEND, though.
Ulrich
pgpUvQ8mTqqVG.pgp
Description: PGP signature
Re: [gentoo-dev] Change or revert the 30 days maintainer timeout stabilization policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2014 02:22 PM, Mike Gilbert wrote: On Wed, Apr 2, 2014 at 12:52 PM, Samuli Suominen ssuomi...@gentoo.org wrote: The 30 days maintainer time out stabilization policy isn't working when package has multiple SLOTs, because the bugs are filed for only latest SLOT, where as some packages require stabilization in sync at both SLOTs Option 1: Either revert the whole policy, and never CC arches on unanswered bugs when the package has a maintainer, and let him do it when he finds the time himself, and if that doesn't happen, wait until it's dropped to maintainer-needed@ Option 2: Or, the person who is CCing the arches in 30 days timeout, needs to make sure the bug covers all SLOT at the same time The status quo no longer allows me to maintain stable version of dev-libs/girara, app-text/zathura*, and the issue needs to be addressed, see http://bugs.gentoo.org/502714 for what inspired this mail - Samuli If you want to prevent packages from being timed out, just leave a comment on the bug saying so. If you don't even have time to do that within a 30 day window, why are you the maintainer? Another option would be to add some kind of notation to metadata.xml. I've long been a proponent of freeform notes in the metadata. I think leaving a note in there is very helpful for developers, however, in this case unless the note is standardized and the auto-stable script is updated I fear this won't help anyone. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQdvPAAoJEKXdFCfdEflKbdkQAIrG0LFuOMvmqopjGoAJcg4W 0YFqVl8uvKCokFfM3SxEkBoxK4R3Omi0YX2Gb0KKQR16+awKbqdwBlW6moilR8Ys jIqzMBFEK7G+XQZEHaiui0nLgBfJLqvXx/r+7Mz5hOogSqRi+/TAo9C6IqW4njXU YcC7KotCIRMCtwaqWCXq9F3nRY6LzRRaw6ADO7fLdJbkA2/hw2jdz+24QNz7NdfT trqLn/f6CXllMt3XQA9ZeX6Q9I8g8ojnjosn4LoGHKObQaImUa5HMT+0HKY5ySh4 AlaSFm5ZTyqn8vodrXGGFGQuaR1HGMFUkLqE8Wdd8XGfmbxKI5if3dRjV0a8vDiF nqS5CBFs9ssyDqMlWnDYwPRwDarULyvRSx5RTE63pTnm2A/ks3qr7wD5Z0ZYpKzZ Y7j63rXnVkGi/3gUgxJU1uJ552JuitYs/KNet8xMOXpytAkgK0SzQnEiHH/fXaPY oS0wASImAfNQc3dvGPithFlx4Su7vxqOB81Vs3dZIRSyNtQlEgnJ6oZCxH1UpUq5 agam16R2OpZ3JnlMkSV5jdh8RqZ9iCoyum2VzUJXGqMRlZ0l7gG8lwqRqa4z7brn CocnpCeJAecAdFYCSy0PIc0vfdb0K6f74Gkm7joM6tl5JFX3bbUJWVq/Pouf0BAg GBeKrQteNK13J5yF9BvE =k60D -END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH] waf-utils.eclass: respect CFLAGS in linking command
On Sun, 06 Apr 2014 15:45:34 +
hasufell hasuf...@gentoo.org wrote:
respect CFLAGS in linking command
https://bugs.gentoo.org/show_bug.cgi?id=506956
--- eclass/waf-utils.eclass
+++ eclass/waf-utils.eclass
@@ -56,18 +56,18 @@
[[ -z ${NO_WAF_LIBDIR} ]]
libdir=--libdir=${EPREFIX}/usr/$(get_libdir)
tc-export AR CC CPP CXX RANLIB
- echo CCFLAGS=\${CFLAGS}\ LINKFLAGS=\${LDFLAGS}\
\${WAF_BINARY}\ --prefix=${EPREFIX}/usr ${libdir} $@ configure
+ echo CCFLAGS=\${CFLAGS}\ LINKFLAGS=\${CFLAGS} ${LDFLAGS}\
\${WAF_BINARY}\ --prefix=${EPREFIX}/usr ${libdir} $@ configure
# This condition is required because waf takes even whitespace as
function # calls, awesome isn't it?
if [[ -z ${NO_WAF_LIBDIR} ]]; then
- CCFLAGS=${CFLAGS} LINKFLAGS=${LDFLAGS} ${WAF_BINARY} \
+ CCFLAGS=${CFLAGS} LINKFLAGS=${CFLAGS} ${LDFLAGS}
${WAF_BINARY} \ --prefix=${EPREFIX}/usr \
${libdir} \
$@ \
configure || die configure failed
else
- CCFLAGS=${CFLAGS} LINKFLAGS=${LDFLAGS} ${WAF_BINARY} \
+ CCFLAGS=${CFLAGS} LINKFLAGS=${CFLAGS} ${LDFLAGS}
${WAF_BINARY} \ --prefix=${EPREFIX}/usr \
$@ \
configure || die configure failed
Good.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-04-06 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-04-06 23h59 UTC. Removals: app-i18n/prime 2014-04-02 09:38:01 naota app-i18n/gtkimprime 2014-04-02 09:38:02 naota app-i18n/scim-prime 2014-04-02 09:38:02 naota app-emacs/prime-el 2014-04-02 09:38:02 naota dev-libs/suikyo 2014-04-02 09:38:02 naota app-emacs/mell 2014-04-02 17:16:37 ulm dev-ruby/locale_rails 2014-04-05 12:08:37 mrueg dev-ruby/parsetree 2014-04-05 12:09:04 mrueg dev-ruby/rubymail 2014-04-05 12:09:41 mrueg net-proxy/swiftiply 2014-04-05 12:18:25 mrueg www-servers/mongrel 2014-04-05 12:18:55 mrueg profiles/eapi-5-files 2014-04-05 21:36:31 dilfridge app-pda/libopensync-plugin-evolution2 2014-04-06 07:02:35 ssuominen Additions: dev-python/python-stdnum2014-03-31 21:16:47 cedk sys-apps/toybox 2014-04-01 04:09:36 patrick kde-base/zeroconf-ioslave 2014-04-01 18:09:12 johu dev-python/kivy-garden 2014-04-02 07:23:20 slis dev-python/Kivy 2014-04-02 07:25:23 slis dev-ruby/combustion 2014-04-02 14:27:24 mrueg dev-libs/double-conversion 2014-04-02 22:54:52 bicatali sci-libs/openlibm 2014-04-02 22:56:28 bicatali dev-python/cryptography-vectors 2014-04-03 01:40:51 radhermit media-libs/gstreamer-editing-services 2014-04-06 11:54:10 eva -- 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-i18n/prime,removed,naota,2014-04-02 09:38:01 app-i18n/gtkimprime,removed,naota,2014-04-02 09:38:02 app-i18n/scim-prime,removed,naota,2014-04-02 09:38:02 app-emacs/prime-el,removed,naota,2014-04-02 09:38:02 dev-libs/suikyo,removed,naota,2014-04-02 09:38:02 app-emacs/mell,removed,ulm,2014-04-02 17:16:37 dev-ruby/locale_rails,removed,mrueg,2014-04-05 12:08:37 dev-ruby/parsetree,removed,mrueg,2014-04-05 12:09:04 dev-ruby/rubymail,removed,mrueg,2014-04-05 12:09:41 net-proxy/swiftiply,removed,mrueg,2014-04-05 12:18:25 www-servers/mongrel,removed,mrueg,2014-04-05 12:18:55 profiles/eapi-5-files,removed,dilfridge,2014-04-05 21:36:31 app-pda/libopensync-plugin-evolution2,removed,ssuominen,2014-04-06 07:02:35 Added Packages: dev-python/python-stdnum,added,cedk,2014-03-31 21:16:47 sys-apps/toybox,added,patrick,2014-04-01 04:09:36 kde-base/zeroconf-ioslave,added,johu,2014-04-01 18:09:12 dev-python/kivy-garden,added,slis,2014-04-02 07:23:20 dev-python/Kivy,added,slis,2014-04-02 07:25:23 dev-ruby/combustion,added,mrueg,2014-04-02 14:27:24 dev-libs/double-conversion,added,bicatali,2014-04-02 22:54:52 sci-libs/openlibm,added,bicatali,2014-04-02 22:56:28 dev-python/cryptography-vectors,added,radhermit,2014-04-03 01:40:51 media-libs/gstreamer-editing-services,added,eva,2014-04-06 11:54:10 Done.
Re: [gentoo-dev] Change or revert the 30 days maintainer timeout stabilization policy
On 07/04/14 01:57, Rick Zero_Chaos Farina wrote: On 04/02/2014 02:22 PM, Mike Gilbert wrote: On Wed, Apr 2, 2014 at 12:52 PM, Samuli Suominen ssuomi...@gentoo.org wrote: The 30 days maintainer time out stabilization policy isn't working when package has multiple SLOTs, because the bugs are filed for only latest SLOT, where as some packages require stabilization in sync at both SLOTs Option 1: Either revert the whole policy, and never CC arches on unanswered bugs when the package has a maintainer, and let him do it when he finds the time himself, and if that doesn't happen, wait until it's dropped to maintainer-needed@ Option 2: Or, the person who is CCing the arches in 30 days timeout, needs to make sure the bug covers all SLOT at the same time The status quo no longer allows me to maintain stable version of dev-libs/girara, app-text/zathura*, and the issue needs to be addressed, see http://bugs.gentoo.org/502714 for what inspired this mail - Samuli If you want to prevent packages from being timed out, just leave a comment on the bug saying so. If you don't even have time to do that within a 30 day window, why are you the maintainer? Another option would be to add some kind of notation to metadata.xml. I've long been a proponent of freeform notes in the metadata. Like you said, doesn't suit this case. I think leaving a note in there is very helpful for developers, however, in this case unless the note is standardized and the auto-stable script is updated I fear this won't help anyone. I agree, this is the best solution, something like automaticstableno/automaticstable that can then be parsed by whatever scripts. I could work with that, and to ease that, I believe it should be part of the default metadata.xml template in a way of 'yes', so it can then be easily changed to 'no' I'd just add it to dev-libs/girara, app-text/zathura, app-text/zathura-meta, and everything it deps on, the plugins. Also, to every package that has herdxfce/herd And to every package I maintain that's important for core system, say, eg. libffi (albeit I've tried to push that particular package to toolchain@ for a while now, but ChangeLog speaks for itself) - Samuli
[gentoo-portage-dev] [PATCH] emerge/actions: Add python version to portage version line
Adds the currently running python version to the portage version line, so that it's immediately obvious what version of python is being used to run portage --- pym/_emerge/actions.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py index 2a1354b..9bc6ed1 100644 --- a/pym/_emerge/actions.py +++ b/pym/_emerge/actions.py @@ -2996,6 +2996,7 @@ def relative_profile_path(portdir, abs_profile): return profilever def getportageversion(portdir, _unused, profile, chost, vardb): + pythonver = 'python %d.%d.%d-%s-%d' % sys.version_info profilever = None repositories = vardb.settings.repositories if profile: @@ -3051,8 +3052,8 @@ def getportageversion(portdir, _unused, profile, chost, vardb): gccver = getgccversion(chost) unameout=platform.release()+ +platform.machine() - return Portage %s (%s, %s, %s, %s) % \ - (portage.VERSION, profilever, gccver, ,.join(libcver), unameout) + return Portage %s (%s, %s, %s, %s, %s) % \ + (portage.VERSION, pythonver, profilever, gccver, ,.join(libcver), unameout) def git_sync_timestamps(portdb, portdir): -- 1.9.1
Re: [gentoo-portage-dev] [PATCH v2] emerge/actions: Add python version to portage version line
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/14 11:09, Douglas Freed wrote: Adds the currently running python version to the portage version line, so that it's immediately obvious what version of python is being used to run portage. Is this useful? The patch itself looks OK though. I tested it briefly with HEAD and a couple of python versions. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNBYpsACgkQRtClrXBQc7XgFwD+LSILTSjYCR2D5Z6IFbIEwAiK Hi+kp+X0zWN7MwimUdMBAIuVnutZ8zb0VBCdgF/zANV/SEZ4Y60mcLzDMNK1pJxT =eA08 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH v2] emerge/actions: Add python version to portage version line
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 06 Apr 2014 16:20:12 +0200 Alexander Berntsen berna...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/14 11:09, Douglas Freed wrote: Adds the currently running python version to the portage version line, so that it's immediately obvious what version of python is being used to run portage. Is this useful? YES, there can be problems associated with certain python versions, like the recent bug 506870. It turned out to be a pypy compatibility bug. The patch itself looks OK though. I tested it briefly with HEAD and a couple of python versions. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNBYpsACgkQRtClrXBQc7XgFwD+LSILTSjYCR2D5Z6IFbIEwAiK Hi+kp+X0zWN7MwimUdMBAIuVnutZ8zb0VBCdgF/zANV/SEZ4Y60mcLzDMNK1pJxT =eA08 -END PGP SIGNATURE- - -- Brian Dolbec dolsen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQF8BAEBCgBmBQJTQg2GXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4Njg4RkQxQ0M3MUMxQzA0RUFFQTQyMzcy MjE0RDkwQTAxNEYxN0NCAAoJECIU2QoBTxfLrYcIAMwK3Zij/OgF4mnsoV39YlHZ nqfk3KfP6uBwAejprkeNPGcNmuC3CvnscfEyyTmgH2o6kgg7QZe46POGiBv4ftJB Ipq1dOZJrde2Ww9LJiHc89mGmdVN1jwG8hhKlQtOzKBqFGBlxTN4Sa63LsUUz1jW L3I51l3uyb1Xu+Y87gxj+obvWv+81cCb1aMmkUuA9P5UrRsBQm0fjBOP1cufkbsP etvkrraD32grEhoKUXjsstB1cLSYKGS9gVQLeII4z/TAq4DjbNwcYs+IRfrovaKM MIKS/qcQfw3yPLBkI7v6dLzChxvBWpgACtE93xkK/o7gQKW+ntH6JUqERVVCwA4= =Mjmg -END PGP SIGNATURE-
