Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 02:35, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. But we still upgrade from 2.7 to 2.7.1 automatically, right? Cheers, Dirkjan
Re: [gentoo-dev] Python 2.7 status check?
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org writes: 2010-11-29 01:26:19 Robin H. Johnson napisał(a): Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. Worse than that, now python-updater is running it is removing all of the usr/lib/python-2.6/site-packages/ files and for multi-version aware packages only building for python-2.7 3.1, it is NOT building for python-2.6.
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 10:30, Graham Murray wrote: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org writes: 2010-11-29 01:26:19 Robin H. Johnson napisał(a): Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. I can confirm that unexpected behaviour. Just updating to 2.7.1 (and simultaneously 3.1.3, although that should be unrelated) switched to 2.7 as default, which I definitely did not ask for.
Re: [gentoo-dev] Python 2.7 status check?
On 29/11/10 10:36, Patrick Lauer wrote: On 11/29/10 10:30, Graham Murray wrote: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org writes: 2010-11-29 01:26:19 Robin H. Johnson napisał(a): Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. I can confirm that unexpected behaviour. +1 and I don't like that! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Disabling auto-bumping of active Python version
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. Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. The ebuilds you just added for 2.7.1 and 3.1.3 do contain eselect_python_update() and calls to it. I suppose that happened by mistake and removed eselect_python_update() on these ebuilds, too. They are in CVS now, mirrors take extra time. Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 10:07, Dirkjan Ochtman wrote: On Mon, Nov 29, 2010 at 02:35, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. But we still upgrade from 2.7 to 2.7.1 automatically, right? Yes, because that's the same slot (slot 2.7). Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 10:30, Graham Murray wrote: Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. Worse than that, now python-updater is running it is removing all of the usr/lib/python-2.6/site-packages/ files and for multi-version aware packages only building for python-2.7 3.1, it is NOT building for python-2.6. Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Best, Sebastian
[gentoo-dev] Re: Disabling auto-bumping of active Python version
Hi, Sebastian Pipping sp...@gentoo.org: 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. $ eselect python --help Manage Python symlinks Usage: eselect python action options [...] updateSwitch to the most recent CPython interpreter --if-unsetDo not override existing implementation --ignore SLOT Ignore SLOT when setting symlinks --python2 Set active Python 2 interpreter without setting of main active Python interpreter if it is not set to Python 2 --python3 Set active Python 3 interpreter without setting of main active Python interpreter if it is not set to Python 3 See the --if-unset option. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Disabling auto-bumping of active Python version
On 11/29/10 13:10, Christian Faulhammer wrote:
$ eselect python --help
Manage Python symlinks
Usage: eselect python action options
[...]
updateSwitch to the most recent CPython interpreter
--if-unsetDo not override existing implementation
--ignore SLOT Ignore SLOT when setting symlinks
--python2 Set active Python 2 interpreter without
setting of main active Python interpreter if it is not set to Python 2
--python3 Set active Python 3 interpreter without
setting of main active Python interpreter if it is not set to Python 3
See the --if-unset option.
I see, thanks.
What I would now like to call from the ebuild is
eselect python set --if-unset ${SLOT}
Problem is ..
* action set wants and index, not a slot
* --if-unset works with update only
If there's a cleaner way than duplicating an ugly (and probably
error-prone) future wrapper to all ebuilds of dev-lang/python, I would
rather try that.
Any ideas?
Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 13:24, Paweł Hajdan, Jr. wrote: On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. Not that I knew. That's why I posted on Planet Gentoo recently: USE_PYTHON in /etc/make.conf http://blog.hartwork.org/?p=972 I'm aware it's no substitute. Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 01:38:11PM +0100, Sebastian Pipping wrote: On 11/29/10 13:24, Paweł Hajdan, Jr. wrote: On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. Not that I knew. That's why I posted on Planet Gentoo recently: USE_PYTHON in /etc/make.conf http://blog.hartwork.org/?p=972 I'm aware it's no substitute. Sebastian *sigh*, Planet is not a place to inform users about these things. How about a -dev-announce or even better a news item. Do you expect everyone to read planet or ML? News item is such a wonderful feature. Please please please use it. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpSFE5rsdRsO.pgp Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 1:42 PM, Markos Chandras wrote: *sigh*, Planet is not a place to inform users about these things. How about a -dev-announce or even better a news item. IMHO a news item is not much better. All users who install later than some date will not see the news item (by design). USE_PYTHON seems to be an important /etc/make.conf setting that is not documented. I think it should be added somewhere under http://www.gentoo.org/doc/en/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010 13:24:40 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. It shouldn't exist... The *correct* fix is to do it in a package manager aware way, for example by using slot operator dependencies that were supposed to be in EAPI 4. Horribly convoluted hacks and huge eclasses that exist primarily to bypass or reimplement things from the package manager cause more pain than they're worth. Does anyone remember the early days of webapp-config? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 13:42, Markos Chandras wrote: *sigh*, Planet is not a place to inform users about these things. How about a -dev-announce or even better a news item. Do you expect everyone to read planet or ML? News item is such a wonderful feature. Please please please use it. I did not invent it. I was pointed to it just a few weeks ago, noticed that it's little known and did a quick blog post about it. Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 12:43:40PM +0100, Sebastian Pipping wrote: On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. The ebuilds you just added for 2.7.1 and 3.1.3 do contain eselect_python_update() and calls to it. I suppose that happened by mistake and removed eselect_python_update() on these ebuilds, too. They are in CVS now, mirrors take extra time. Sebastian Revbump otherwise get ready for a series of bug reports from frustrated users -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpLYqhox42pZ.pgp Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
2010-11-29 12:43 Sebastian Pipping sp...@gentoo.org napisał(a):
On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote:
Sebastian Pipping recently removed automatic upgrade of active version of
Python, so
python-2.7.1.ebuild does not upgrade active version of Python.
The ebuilds you just added for 2.7.1 and 3.1.3 do contain
eselect_python_update() and calls to it.
I suppose that happened by mistake and removed eselect_python_update()
on these ebuilds, too. They are in CVS now, mirrors take extra time.
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).
--
Arfrever Frehtes Taifersar Arahesis
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 04:47:36PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
2010-11-29 12:43 Sebastian Pipping sp...@gentoo.org napisał(a):
On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote:
Sebastian Pipping recently removed automatic upgrade of active version of
Python, so
python-2.7.1.ebuild does not upgrade active version of Python.
The ebuilds you just added for 2.7.1 and 3.1.3 do contain
eselect_python_update() and calls to it.
I suppose that happened by mistake and removed eselect_python_update()
on these ebuilds, too. They are in CVS now, mirrors take extra time.
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).
--
Arfrever Frehtes Taifersar Arahesis
I updated two systems and they both switched to 2.7.1 automatically.
They were working fine with 2.6 before the update.
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpiaF7y7PtID.pgp
Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 16:37, Markos Chandras wrote: Revbump otherwise get ready for a series of bug reports from frustrated users I don't think this case qualifies for a revbump. The set of files produced is the same. The new revision offers nothing new to anyone having installed the previous revision. I intentionally did not bump the revision here. Am I missing something? Sebastian
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).
Sounds logical. Any ideas how it bumped to 2.7.1 then? It seems it
happened to a few people.
Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 05:20:00PM +0100, Sebastian Pipping wrote: On 11/29/10 16:37, Markos Chandras wrote: Revbump otherwise get ready for a series of bug reports from frustrated users I don't think this case qualifies for a revbump. The set of files produced is the same. The new revision offers nothing new to anyone having installed the previous revision. I intentionally did not bump the revision here. Am I missing something? Sebastian The behavior of the package has changed though. Do not expect anyone who uses ~testing to know about eselect python module. If you are lucky enough, you will received just a few bug reports about this from those users who updated their packages before you fix the ebuilds. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgprzljF4mH72.pgp Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010, Alex Alexander wrote:
On Mon, Nov 29, 2010 at 04:47:36PM +0100, 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
}
Unfortunately, that doesn't help at all. See below.
I updated two systems and they both switched to 2.7.1 automatically.
I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which
until two days ago unconditionally called the following eselect
action:
eselect python update --python2
So unless you had updated your python-2.6 during the last two days,
the installed version in your VDB would still contain the above line.
They were working fine with 2.6 before the update.
If it ain't broke, don't fix it? ;-)
Ulrich
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010, Markos Chandras wrote: Revbump otherwise get ready for a series of bug reports from frustrated users I don't think this case qualifies for a revbump. [...] The behavior of the package has changed though. Do not expect anyone who uses ~testing to know about eselect python module. If you are lucky enough, you will received just a few bug reports about this from those users who updated their packages before you fix the ebuilds. Also a revbump doesn't help if the bad code is in the old version's pkg_postrm(), which is installed on users' systems. Ulrich
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 17:31, Ulrich Mueller wrote: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: eselect python update --python2 So unless you had updated your python-2.6 during the last two days, the installed version in your VDB would still contain the above line. So a working fix would be to ripp out the update action? Do we still need that? Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/2010 08:43 AM, Sebastian Pipping wrote: On 11/29/10 17:31, Ulrich Mueller wrote: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: eselect python update --python2 So unless you had updated your python-2.6 during the last two days, the installed version in your VDB would still contain the above line. So a working fix would be to ripp out the update action? Do we still need that? You could also cancel it out, by checking the state in pkg_preinst and saving it in an environment variable so that you can restore it in pkg_postinst. -- Thanks, Zac
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller u...@gentoo.org writes: On Mon, 29 Nov 2010, Alex Alexander wrote: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: But as python-2.7 is installed into a new slot, python-2.6.x is kept, so python-2.6.6-r1's pkg_postrm() should not be called.
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller u...@gentoo.org writes: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: But python-2.7 is installed in a new slot and python-2.6.x is not removed. So. surely python-2.6.6-r1's pkg_postrm() should not be called during the installation of python-2.7.1.
[gentoo-dev] last rites: games-sports/race
# Michael Sterrett mr_bon...@gentoo.org (29 Nov 2010) # No upstream, no real gameplay, crashes (bug #347199) # Masked for removal on 20101229 games-sports/race
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010, Graham Murray wrote:
I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which
until two days ago unconditionally called the following eselect
action:
But python-2.7 is installed in a new slot and python-2.6.x is not
removed. So. surely python-2.6.6-r1's pkg_postrm() should not be
called during the installation of python-2.7.1.
You are right, this cannot be the reason then.
But could pkg_postrm() of python-3.1.2-r4 have caused the update?
It essentially executed the following code:
[[ $(eselect python show) == python2.* ]]
eselect_python_options=--python2
eselect python update --python3 /dev/null
eselect python update ${eselect_python_options}
Ebuilds for 2.7.1 and 3.1.3 were committed together, and 3.1.2-r4 and
3.1.3 are in the same slot.
Ulrich
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller u...@gentoo.org writes: But could pkg_postrm() of python-3.1.2-r4 have caused the update? It essentially executed the following code: Yes, that is what is doing it. I am in the middle of an emerge -uD world and I ran 'eselect python list' after 2.7.1 had been emerged and it still showed 2.6 as being the active. But after 3.1.3 had been installed, it shows 2.7 as being the active version.
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 07:36:45PM +0100, Ulrich Mueller wrote:
On Mon, 29 Nov 2010, Graham Murray wrote:
I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which
until two days ago unconditionally called the following eselect
action:
But python-2.7 is installed in a new slot and python-2.6.x is not
removed. So. surely python-2.6.6-r1's pkg_postrm() should not be
called during the installation of python-2.7.1.
You are right, this cannot be the reason then.
But could pkg_postrm() of python-3.1.2-r4 have caused the update?
It essentially executed the following code:
[[ $(eselect python show) == python2.* ]]
eselect_python_options=--python2
eselect python update --python3 /dev/null
eselect python update ${eselect_python_options}
Ebuilds for 2.7.1 and 3.1.3 were committed together, and 3.1.2-r4 and
3.1.3 are in the same slot.
That's it. I ran those commands manually and the third one,
which evaluates to
eselect python update --python2
switched my python to 2.7.
On Mon, Nov 29, 2010 at 05:31:29PM +0100, Ulrich Mueller wrote:
On Mon, 29 Nov 2010, Alex Alexander wrote:
They were working fine with 2.6 before the update.
If it ain't broke, don't fix it? ;-)
I lol'd hard with this, thanks! :p
So, no updates at all? :D
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpittushruqq.pgp
Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
Which basically means, it's time to simplify the eclass and start thinking how the abi details could be handled language-independent by portage. On Monday 29 November 2010 19:54:11 Graham Murray wrote: Ulrich Mueller u...@gentoo.org writes: But could pkg_postrm() of python-3.1.2-r4 have caused the update? It essentially executed the following code: Yes, that is what is doing it. I am in the middle of an emerge -uD world and I ran 'eselect python list' after 2.7.1 had been emerged and it still showed 2.6 as being the active. But after 3.1.3 had been installed, it shows 2.7 as being the active version. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, sunrise dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: games-simulation/secondlife-bin
# Michael Sterrett mr_bon...@gentoo.org (29 Nov 2010) # Non-games-team addition that is too painful to maintain. # Masked for removal on 20101229 games-simulation/secondlife-bin
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 18:33, Zac Medico wrote: You could also cancel it out, by checking the state in pkg_preinst and saving it in an environment variable so that you can restore it in pkg_postinst. Could you show a mockup of that? I'm not really sure how that would work. Would it work for pkg_postrm code of already installed packages? That would great to have. Thanks, Sebastian
[gentoo-dev] cmake, ELF DT_NEEDED, sonames, and libcblas... Help!!!
Howdy, I'm trying to fix the clapack ebuild so it links against _c_blas, not blas. (Which, as soon as it works, will remove the fortran dependency for e.g. digikam...) I have a 99.99% working ebuild [*]. It generates a perfectly fine libclapack, with one small problem: the libclapack is missing a NEEDED entry for libcblas. $ scanelf -n libclapack.so.3.2.1 TYPE NEEDED FILE ET_DYN libf2c.so.2,libc.so.6 libclapack.so.3.2.1 Obviously this is a problem, because as soon as another application wants to link against libclapack, it does not know that it also needs libcblas, and ends up with unresolved symbols. If I tell cmake to link against blas, this looks fine: $ scanelf -n /usr/lib64/libclapack.so.3.2.1 TYPE NEEDED FILE ET_DYN libblas.so.0,libf2c.so.2,libc.so.6 /usr/lib64/libclapack.so.3.2.1 The relevant cmake code is for cblas (bad): target_link_libraries(clapack cblas f2c) and for blas (good): target_link_libraries(clapack blas f2c) (one byte difference). Any clue what is going on here? I have a personal suspicion, namely that libcblas.so is (on my system) actually (symlinked to) libgslcblas.so.0, and that maybe cmake reacts because the library filename is not equal its SONAME. Does this make sense? And if yes, what can I do about it? Thanks a lot in advance for your help... Cheers, Andreas [*] http://git.overlays.gentoo.org/gitweb/?p=user/dilfridge.git;a=blob;f=sci- libs/clapack/clapack-3.2.1-r4.ebuild;hb=HEAD -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: cmake, ELF DT_NEEDED, sonames, and libcblas... Help!!!
Il giorno lun, 29/11/2010 alle 22.57 +0100, Andreas K. Huettel ha scritto: I have a personal suspicion, namely that libcblas.so is (on my system) actually (symlinked to) libgslcblas.so.0, and that maybe cmake reacts because the library filename is not equal its SONAME. Does this make sense? And if yes, what can I do about it? No. As I have written already [1] [2], there is no need for the filename and the soname to be related at all What I think the problem could be here is that libblas and libcblas/libgslcblas provide two different interfaces; clapack finds itself fine with libblas, but it doesn't find the required symbols in libcblas, so --as-needed discards the linking. I don't think I have the libraries around, maybe the tinderbox. Otherwise prod me on IRC/Jabber, it's faster, then we can post the results. [1] http://blog.flameeyes.eu/2010/10/08/linkers-and-names [2] http://blog.flameeyes.eu/2009/10/27/a-shared-library-by-any-other-name -- 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 11/29/2010 01:14 PM, Sebastian Pipping wrote:
On 11/29/10 18:33, Zac Medico wrote:
You could also cancel it out, by checking the state in pkg_preinst and
saving it in an environment variable so that you can restore it in
pkg_postinst.
Could you show a mockup of that?
I'm not really sure how that would work.
Would it work for pkg_postrm code of already installed packages?
That would great to have.
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
}
--
Thanks,
Zac
