Re: [gentoo-dev] Python 2.7 status check?
On 11/30/10 03:24, Zac Medico wrote:
Yes, hopefully something like this will do it:
pkg_preinst() {
main_active_python=$(eselect python show)
}
pkg_postinst() {
if [[ -n $main_active_python
$main_active_python != $(eselect python show) ]] ; then
einfo restoring active python interpreter
eselect python set $main_active_python
fi
}
Intersting approach.
My debugging ebuild (attached) confirms a fitting order of invocations:
# sudo EMERGE_DEFAULT_OPTS= emerge -1 =virtual/debug-2.7.1 \
| fgrep STAGE
* STAGE pkg_setup (slot 2.7, version 2.7.1)
* STAGE src_unpack (slot 2.7, version 2.7.1)
* STAGE src_prepare (slot 2.7, version 2.7.1)
* STAGE src_configure (slot 2.7, version 2.7.1)
* STAGE src_compile (slot 2.7, version 2.7.1)
* STAGE src_install (slot 2.7, version 2.7.1)
* STAGE pkg_preinst (slot 2.7, version 2.7.1)
* STAGE pkg_prerm (version 2.7, slot 2.7)
* STAGE pkg_postrm (version 2.7, slot 2.7)
* STAGE pkg_postinst (slot 2.7, version 2.7.1)
Shall we give that approach a try?
One case it doesn't seem to catch though is when you just run
emerge -C dev-lang/python:X.Y
on a machine where Python X.Y was installed with eselect_python_update()
still in place. Correct?
Sebastian
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=2
inherit versionator
SLOT=$(get_version_component_range 1-2)
KEYWORDS=amd64
for stage in src_{unpack,prepare,configure,compile,install}
pkg_{config,setup,{pre,post}{inst,rm}} ; do
eval ${stage}'() {ewarn STAGE ${FUNCNAME} (slot ${SLOT}, version
${PV}) ; }'
done
Re: [gentoo-dev] Python 2.7 status check?
On 11/30/2010 08:26 AM, Sebastian Pipping wrote: * STAGE pkg_preinst (slot 2.7, version 2.7.1) * STAGE pkg_prerm (version 2.7, slot 2.7) * STAGE pkg_postrm (version 2.7, slot 2.7) * STAGE pkg_postinst (slot 2.7, version 2.7.1) Shall we give that approach a try? It seems like a reasonable approach. One case it doesn't seem to catch though is when you just run emerge -C dev-lang/python:X.Y on a machine where Python X.Y was installed with eselect_python_update() still in place. Correct? True, but that's not nearly as annoying as when it happens during a series of updates. -- Thanks, Zac
[gentoo-dev] RFC gcc vs icc/ifc
Hi all, gcc is in CAT sys-devel, where icc/ifc are in dev-lang. They are both c/fortran compilers. Shouldn't we move icc/ifc to sys-devel? cheers justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC gcc vs icc/ifc
Il giorno mar, 30/11/2010 alle 17.43 +0100, justin ha scritto: gcc is in CAT sys-devel, where icc/ifc are in dev-lang. They are both c/fortran compilers. Shouldn't we move icc/ifc to sys-devel? No, it's not a system package. You don't need icc/ifc, you do need gcc (for how Gentoo is structured). Please let's not keep adding stuff to sys-* when it's not really required for the system. FWIW personally I'm not happy with having llvm there either. But I'd also avoid pointless pkgmoves… -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Python 2.7 status check?
On Tue, 30 Nov 2010 17:26:44 +0100 Sebastian Pipping sp...@gentoo.org wrote: My debugging ebuild (attached) confirms a fitting order of invocations: Careful with that. The order of pre/post stuff is package manager and EAPI dependent, thanks to Portage sneakily changing the order without telling anyone (and without checking existing ebuilds for breakage). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
pkg_preinst() {
main_active_python=$(eselect python show)
}
pkg_postinst() {
if [[ -n $main_active_python
$main_active_python != $(eselect python show) ]] ; then
einfo restoring active python interpreter
eselect python set $main_active_python
fi
}
I have combined your idea with Arfever's no-active-version-prevention
into the patch attached.
Anyone, please let me know if you consider it sane enough for applying
to all dev-lang/python ebuilds in Gentoo. Thanks!
Sebastian
From 8a6e0f532e469d851777c98a92fa09c2ae59489f Mon Sep 17 00:00:00 2001
From: Sebastian Pipping sebast...@pipping.org
Date: Tue, 30 Nov 2010 17:52:55 +0100
Subject: [PATCH] dev-lang/python: Apply combined restoring (zmedico) and repair
(arfrever) of active python version
---
dev-lang/python/Manifest|2 +-
dev-lang/python/python-2.7.1.ebuild | 38 +++
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/dev-lang/python/Manifest b/dev-lang/python/Manifest
index 9baa821..a068c28 100644
--- a/dev-lang/python/Manifest
+++ b/dev-lang/python/Manifest
@@ -25,7 +25,7 @@ EBUILD python-2.4.6.ebuild 8977 RMD160
38f346fc41002623b3b2b0a2b0b711bb7db7dd4e
EBUILD python-2.5.4-r4.ebuild 9327 RMD160
a6457b0ff606f4049cadeb9884cb4fe957b9958c SHA1
e747734e97cb520fb39f320f2c455b14b3ea0e6e SHA256
3bf309b7d68e56c45ace9d6967df8b534775593730ae5be67ce155f6b33d2bb0
EBUILD python-2.6.5-r3.ebuild 9122 RMD160
27044cab65202cfadfb8499b8a772fbfa52b1fc2 SHA1
ca3bdf0cf333de4d51fd7ac8a624ea97bf0cd00b SHA256
80c0fb7445edd89b371380f9aefdaeb4f4951aa5a534250e0ebbf8080dbba9d4
EBUILD python-2.6.6-r1.ebuild 9315 RMD160
35f711a57bb4947d791d7702097e907817d3d3cf SHA1
01bac9a202d9cde208c6812b3238c8e1cf4e8a02 SHA256
0920fb7e34be6cec6e0f7dc7bf1d63f9312293a95b6f1f74accdd443053c60ef
-EBUILD python-2.7.1.ebuild 10966 RMD160
7594d04f91503a6ae99cf4e6f322706f90dee217 SHA1
ed45a2db66c88b76c2b8cba260dc05fe91d2a2fb SHA256
3901a104673f155f4e35d9fee6f006d4655c688cfa7595aac83950b3d67446c0
+EBUILD python-2.7.1.ebuild 12114 RMD160
b53e6cfe32cfea5ed7f74183e4c66725284f8206 SHA1
a95c77665111d59d7dae83ae557d3966fcf3b42d SHA256
4fb4e52af3f2bc9a0a00d73fe922e92d32e071fce9228424ecc014cbd1d7de05
EBUILD python-2.7.ebuild 9425 RMD160 243ca80a7c4099fb0c06ababc461ef8bd1ad8417
SHA1 720f41cffb98b733fe242a415f43e575eb865a1f SHA256
dbb329d402907253537750ad2fa9c133037c9f4c28aa70c3720f5d21b2fdb3f1
EBUILD python-3.1.2-r4.ebuild 9215 RMD160
36e9ddbf18008b63653a3704c20e64e9f321c092 SHA1
33cb0ab09dd085b3a7724e9cc07ee630e13b6e6d SHA256
598c9199129f5b6efa9dc283f8d3de89428f034591365180f7a266fe2cce3d89
EBUILD python-3.1.3.ebuild 10398 RMD160
30ce48f92bf7796074e6410deca31ce9cc48e94a SHA1
4b68dbf85eb41c09e050c0f9ab54614ad43fa240 SHA256
2ed7457384281b818bacc6c904ccc24c032b0b7438ae7d625eb2c5f3c727bdec
diff --git a/dev-lang/python/python-2.7.1.ebuild
b/dev-lang/python/python-2.7.1.ebuild
index 4b8c34c..3d5a1fe 100644
--- a/dev-lang/python/python-2.7.1.ebuild
+++ b/dev-lang/python/python-2.7.1.ebuild
@@ -331,13 +331,49 @@ src_install() {
rmdir ${ED}$(python_get_libdir)/test/data
}
+save_active_python_version() {
+ active_python_2=$(eselect python show --python2)
+ active_python_3=$(eselect python show --python3)
+ active_python_main=$(eselect python show)
+}
+
pkg_preinst() {
+ save_active_python_version
+
if has_version ${CATEGORY}/${PN}-${SLOT} ! has_version
${CATEGORY}/${PN}:2.7; then
python_updater_warning=1
fi
}
+ensure_python_symlink() {
+ if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
+ eselect python update --python${PV%%.*}
+ fi
+}
+
+restore_active_python_version() {
+ if [[ -n ${active_python_2}
+ ${active_python_2} != $(eselect python show
--python2) ]] ; then
+ einfo Restoring active Python 2.x interpreter:
${active_python_2}
+ eselect python set ${active_python_2} --python2
+ fi
+ if [[ -n ${active_python_3}
+ ${active_python_3} != $(eselect python show
--python3) ]] ; then
+ einfo Restoring main active Python 3.x interpreter:
${active_python_3}
+ eselect python set ${active_python_3} --python3
+ fi
+
+ if [[ -n ${active_python_main}
+ ${active_python_main} != $(eselect python show) ]] ;
then
+ einfo Restoring main active Python interpreter:
${active_python_main}
+ eselect python set ${active_python_main}
+ fi
+}
+
pkg_postinst() {
+ restore_active_python_version
+ ensure_python_symlink
+
python_mod_optimize -f -x /(site-packages|test|tests)/
$(python_get_libdir)
if [[ ${python_updater_warning} == 1 ]]; then
@@ -354,5 +390,7 @@ pkg_postinst() {
}
pkg_postrm() {
+ ensure_python_symlink
+
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 16:47, Arfrever Frehtes Taifersar Arahesis wrote:
It wasn't any mistake. Please actually read that code:
eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}
${PV%%.*} == 2
'eselect python update --python2' would be called only if output of
'eselect python show --python2' was empty, which would occur when
there was no active version of Python 2 set (no /usr/bin/python2
symlink).
Thanks for that code. I apologize.
Sebastian
[gentoo-dev] Maintainer notes in metadata.xml?
Hi all, I was wondering if we have space already, or if others would feel strongly about making space for, maintainer notes in packages' metadata.xml. I ask this because I was looking through some crypto based packages that require specific hardware that seems to have been maintained at eye level for quite a while, such as pcsc-lite. In this case, pcsc-lite has changed more than a few times its API, since it tries to follow what Microsoft implements in Windows, and as such the packages depending on it needed to actually follow closely. So for instance, for pcsc-lite 1.6.1 you need ccid 1.3.1, while for pcsc-lite 1.6.4 you need ccid 1.4.0 – older versions of ccid will fail with modern versions of pcsc-lite – but both eye-maintainers and arch teams didn't know that and while we _had_ a broken stable tree for x86 and amd64, we _still_ have broken stable trees for ppc/ppc64. What I'm thinking of is having some sort of maintainernotes element, but not a passive one that has to be tested for, rather something that repoman would spit out on the terminal when doing a scan/full. Comments? -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Maintainer notes in metadata.xml?
On Wed, Dec 1, 2010 at 6:30 AM, Diego Elio Pettenò flamee...@gmail.com wrote: Hi all, I was wondering if we have space already, or if others would feel strongly about making space for, maintainer notes in packages' metadata.xml. [snip] What I'm thinking of is having some sort of maintainernotes element, but not a passive one that has to be tested for, rather something that repoman would spit out on the terminal when doing a scan/full. Comments? Why don't we just encourage maintainers to add !-- -- comments to metadata.xml? I'd love to have a new element if the data to be stored in that element would need to be parsed/categorized by external programs, but otherwise xml comments would work just fine. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Maintainer notes in metadata.xml?
On Wed, Dec 1, 2010 at 1:25 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Wed, Dec 1, 2010 at 6:30 AM, Diego Elio Pettenò flamee...@gmail.com wrote: Hi all, I was wondering if we have space already, or if others would feel strongly about making space for, maintainer notes in packages' metadata.xml. [snip] What I'm thinking of is having some sort of maintainernotes element, but not a passive one that has to be tested for, rather something that repoman would spit out on the terminal when doing a scan/full. Comments? Why don't we just encourage maintainers to add !-- -- comments to metadata.xml? I'd love to have a new element if the data to be stored in that element would need to be parsed/categorized by external programs, but otherwise xml comments would work just fine. And have repoman scan/full print out all !-- -- comments? I think that's why Diego is suggesting a new XML tag. Matt
Re: [gentoo-dev] Maintainer notes in metadata.xml?
On Wed, Dec 1, 2010 at 7:16 AM, Matt Turner matts...@gentoo.org wrote: On Wed, Dec 1, 2010 at 1:25 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Wed, Dec 1, 2010 at 6:30 AM, Diego Elio Pettenò flamee...@gmail.com wrote: Hi all, I was wondering if we have space already, or if others would feel strongly about making space for, maintainer notes in packages' metadata.xml. [snip] What I'm thinking of is having some sort of maintainernotes element, but not a passive one that has to be tested for, rather something that repoman would spit out on the terminal when doing a scan/full. Comments? Why don't we just encourage maintainers to add !-- -- comments to metadata.xml? I'd love to have a new element if the data to be stored in that element would need to be parsed/categorized by external programs, but otherwise xml comments would work just fine. And have repoman scan/full print out all !-- -- comments? I think that's why Diego is suggesting a new XML tag. That's just the DTD not getting validated. We can just change the DTD and repoman won't complain about the XML being invalid. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Please test what you bump
Hi guys, Since I just committed a rewritten ebuild for a package that was absolutely broken in tree, I'm going to ask this nicely. Please test what you bump. If you cannot test it entirely because you lack the hardware, track down somebody who does, or simply leave it alone until somebody actually asks you about it because they care, in that case they are likely to have the hardware to test. When I find a package bumped in 2009 by random developers, after two years without a dedicated maintainer, and I find no dependency info, non-bound USE flags, and an init script with a need dependency not to be found in the (well, missing) dependencies, it really doesn't make me feel tremendously happy. Thank you very much, -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Disabling auto-bumping of active Python version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-11-2010 10:34, Sebastian Pipping wrote: On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrote: There will probably be no active version of Python set. You had two weeks to come up with this. Please find my on IRC to team up on an agreed fix. As Arfrever noted, this is likely the cause of the broken automated weekly stages for this past week. By not having a python symlink / wrapper, stages generation failed on stage2 run. I'd like to take this chance to recall this is the 2nd time on the last few months where stage generation was broken by python changes. Also, we've been unable to create hardened stages for over 8 weeks because of a sandbox issue. The weekly stages generation depends on the quality and stability of the stable tree. Therefore, the RelEng team kindly asks all maintainers to pay attention to the stable ebuilds in the system set and to please fix any failures asap as they may / can prevent stage generation. Be sure to think carefully about changes that can impact the stage generation, in particular when they involve python. Sebastian - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM9cjoAAoJEC8ZTXQF1qEPdC0QAK0HLSse/T3XUL9+vjp3VHro xXED/VsiXLlJtwlEsfWLf5kkMhejEXTO5gbLWZmqaJynOCFBk55eqQz04YXZQqWv XmtEnXzaf+394chTaWV3hPIzuVayZzJRtVJhEj1imbgLIa3Qyx7XJjpC4NwH2MVo 1Odef7Eh8vhpE2bD48BxJfp9KGIf+MQf0TPex/4TACirYzJ60J4aGZ627gbzyaym 3o9DoLD1DRRrURO66buLyV2eXvnMrNrO3UYKPP1M93uW1hq4RXZRGJ4oGePbBfwQ JuoGNc227lixeaivlLA83AOQbfYM3OW8zuM1l2kVMNSvzeVyh/wEx9U9ptvLhhLR nd0FJNt8RsIH8Yzi5NUfv4JMJoAQK5km2kNVFH1bE8vVp+RwyTVFPnuCtdNL1uLJ rVl+ptrF/Aiey5u/gVXpYSZGjU/lYtp73EebZhO+Bn1mymGMNVr2/UU9HWgCowmN so0AIcKa5NkT5L4Y3kI+bSokcrm/5bLbjZQ5MayWsRuEwJkWyt1vxfW2B2DaQbjQ +hRezNy/GwnfLM21yEYn46h5RnArdtV3vT6J6vksG+4aepa6WNAFnw47ABJW63z0 jAL8n/qjrsi2PJlUdrbZ230iqIFV1RmPtP5Z7M9gAM4VAtb8dNPWxB2ooEYOqg6u 8yAYnSVjKv/dTK7nPhSk =gX34 -END PGP SIGNATURE-
Re: [gentoo-dev] Disabling auto-bumping of active Python version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-12-2010 03:02, Jorge Manuel B. S. Vicetto wrote: On 29-11-2010 10:34, Sebastian Pipping wrote: As Arfrever noted, this is likely the cause of the broken automated weekly stages for this past week. By not having a python symlink / wrapper, stages generation failed on stage2 run. I just tested the stages creation locally and as expected this must be the source of the failure has there's no python symlink when building stage2: atlan...@atl4core /home/release $ ls -la buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/py* - -rwxr-xr-x 1 root root78 Dez 1 02:57 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/pydoc2.6 - -rwxr-xr-x 1 root root78 Dez 1 02:59 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/pydoc3.1 - -rwxr-xr-x 1 root root 6104 Dez 1 02:58 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python2.6 - -rwxr-xr-x 1 root root 10272 Dez 1 03:00 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python3.1 - -rwxr-xr-x 1 root root 1200 Dez 1 02:57 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python-config-2.6 - -rwxr-xr-x 1 root root 1177 Dez 1 02:59 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python-config-3.1 - -rwxr-xr-x 1 root root 10328 Dez 1 02:52 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python-wrapper As such the RelEng team would appreciate a quick fix of the broken python stable ebuilds. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM9c1rAAoJEC8ZTXQF1qEPlygP/2wib7n4YOXvXRfBCrYoKuDi VTHLPpXHIhOxqWvAqIczyHfJhsIwAzeVm5wehmj+NDUSs7HXeO4Why4H6X9FY530 0KQqAsnjBQJU4xqfE8kofcRt8TUY7jmToObmEnGDM8raqouvpHjUlpp/2CC/eNCz xOVuJ66+DJC3LIjmCcMQIAhbrhZZ63s/3J9O3D7XHJtLGdWBmNvAfRELTdxNM+Zw UZRntctOWaPnyB6aSTvfK3SvC8cgPyBwvQFGWioZozWn9W+0J97/aux+aJRSCKJy f+BzqVCGfeEq8j4yUzyQUzkXRV7fbIXMHhbGq6wUuMgMvZo/tAa64x77nebPBtCm ZH49HAnKRRzy8O72AE3BVKVT3hCAxEBU/len309Dc2Cbwznb17WYm18Ihl5ShACG /UZ+TkYwyctuh/ICmtFE0DsUIgcXHsMaCllpLF1iNxIEX6yOaxWvPoE1Pv4cnyIv BWGHHL4sHsybyRNkiGYbeQQarYaXKS78N6wOeBhjXMi+T7QqanrJ76897l7LsRr2 3+RaPA0KHCvexixI7EuEUjfrIcYNFpZJoLLGci8ZxtjDe9MRRpnY1J6540B1sTi9 1Amb8ZwrXib4ngId7oZPN//E9umbB1FFOixGRNGfn9E2Ovmc9D+BFm5/+xCxr2/0 B6bpK4SXkB5tedu+D4a6 =uqe1 -END PGP SIGNATURE-
