Computers are like Old Testament gods; lots of rules and no mercy.
09-27-2008, 04:58 PM
"Kirk Lowery"
Getting python-2.3 back
On Fri, Sep 26, 2008 at 2:47 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 25 Sep 2008 17:59:35 -0400, Kirk Lowery wrote:
>
>> During upgrading today, I inadvertently allowed 2.3 to be deleted. I
>> looked in portage, but it is apparently gone.
>
> Nothing is ever truly gone from portage
>
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/python/?hideattic=0
>
> goes back as far as python-1/5/2
Thanks for the answers. I thought I'd report my experience here for
the knowledgebase:
I went back and downloaded not only the latest 2.3.6 ebuild into my
local overlay, and all the attendant files (including important
patches) in the "files" directory. In order to be able to emerge the
ebuild file, I had to recreate the digest and manifest files. Don't
know why the checksums were off, but they were. The solution was
simple:
# ebuild python-2.3.6-r6.ebuild digest
took care of it. When I tried to restart my legacy software I got a
python error: "ImportError: No module named thread". Sure enough, the
equery use feature told me "-threads". So I overrode that in
package.use. Nope, no change. Looking at the compile log, I saw this:
Configure has both --with- and --without-threads!!??
Nothing I did seemed to make a difference. So I traced where in the
ebuild this might be coming from:
use threads
&& myconf="${myconf} --with-threads"
&& myconf="${myconf} --without-threads"
I still don't know why (and would appreciate any knowledgeable person
commenting here), but I simply commented out the third line above,
re-emerged, and viola! my legacy software is up and running.
Kirk
09-28-2008, 12:38 PM
David Relson
Getting python-2.3 back
On Sat, 27 Sep 2008 12:58:40 -0400
Kirk Lowery wrote:
> On Fri, Sep 26, 2008 at 2:47 AM, Neil Bothwick <neil@digimed.co.uk>
> wrote:
> > On Thu, 25 Sep 2008 17:59:35 -0400, Kirk Lowery wrote:
> >
> >> During upgrading today, I inadvertently allowed 2.3 to be deleted.
> >> I looked in portage, but it is apparently gone.
> >
> > Nothing is ever truly gone from portage
> >
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/python/?hideattic=0
> >
> > goes back as far as python-1/5/2
>
> Thanks for the answers. I thought I'd report my experience here for
> the knowledgebase:
>
> I went back and downloaded not only the latest 2.3.6 ebuild into my
> local overlay, and all the attendant files (including important
> patches) in the "files" directory. In order to be able to emerge the
> ebuild file, I had to recreate the digest and manifest files. Don't
> know why the checksums were off, but they were. The solution was
> simple:
>
> # ebuild python-2.3.6-r6.ebuild digest
>
> took care of it. When I tried to restart my legacy software I got a
> python error: "ImportError: No module named thread". Sure enough, the
> equery use feature told me "-threads". So I overrode that in
> package.use. Nope, no change. Looking at the compile log, I saw this:
>
> ./configure --prefix=/usr --host=x86_64-pc-linux-gnu
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
> --sysconfdir=/etc --localstatedir=/var/lib --with-fpectl
> --enable-shared --enable-ipv6 --infodir=${prefix}/share/info
> --mandir=${prefix}/share/man --with-libc= --enable-unicode=ucs4
> --with-threads --without-threads --with-threads --libdir=/usr/lib64
> --build=x86_64-pc-linux-gnu
>
> Configure has both --with- and --without-threads!!??
>
> Nothing I did seemed to make a difference. So I traced where in the
> ebuild this might be coming from:
>
> use threads
> && myconf="${myconf} --with-threads"
> && myconf="${myconf} --without-threads"
>
> I still don't know why (and would appreciate any knowledgeable person
> commenting here), but I simply commented out the third line above,
> re-emerged, and viola! my legacy software is up and running.
>
> Kirk
An interesting defect to find, and a good job of detective work!
Out of curiosity, I looked at the python ebuilds on my workstation.
Up through python-2.4.4-r6, they have:
use nothreads
&& myconf="${myconf} --without-threads"
|| myconf="${myconf} --with-threads"
From python-2.4.4-r14 onwards they have:
use threads
&& myconf="${myconf} --with-threads"
|| myconf="${myconf} --without-threads"
Evidently the 2.3.6-r6 ebuild has the newer "use threads" test, but
with the minor (but fatal) operator flaw you found -- "&&" which
should be "||".
Hope this is of interest,
David
09-28-2008, 01:02 PM
"Kirk Lowery"
Getting python-2.3 back
On Sun, Sep 28, 2008 at 8:38 AM, David Relson <relson@osagesoftware.com> wrote:
> On Sat, 27 Sep 2008 12:58:40 -0400
> Kirk Lowery wrote:
>
>> On Fri, Sep 26, 2008 at 2:47 AM, Neil Bothwick <neil@digimed.co.uk>
>> wrote:
>> > On Thu, 25 Sep 2008 17:59:35 -0400, Kirk Lowery wrote:
>> >
>> >> During upgrading today, I inadvertently allowed 2.3 to be deleted.
>> >> I looked in portage, but it is apparently gone.
>> >
>> > Nothing is ever truly gone from portage
>> >
>> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/python/?hideattic=0
>> >
>> > goes back as far as python-1/5/2
>>
>> Thanks for the answers. I thought I'd report my experience here for
>> the knowledgebase:
>>
>> I went back and downloaded not only the latest 2.3.6 ebuild into my
>> local overlay, and all the attendant files (including important
>> patches) in the "files" directory. In order to be able to emerge the
>> ebuild file, I had to recreate the digest and manifest files. Don't
>> know why the checksums were off, but they were. The solution was
>> simple:
>>
>> # ebuild python-2.3.6-r6.ebuild digest
>>
>> took care of it. When I tried to restart my legacy software I got a
>> python error: "ImportError: No module named thread". Sure enough, the
>> equery use feature told me "-threads". So I overrode that in
>> package.use. Nope, no change. Looking at the compile log, I saw this:
>>
>> ./configure --prefix=/usr --host=x86_64-pc-linux-gnu
>> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
>> --sysconfdir=/etc --localstatedir=/var/lib --with-fpectl
>> --enable-shared --enable-ipv6 --infodir=${prefix}/share/info
>> --mandir=${prefix}/share/man --with-libc= --enable-unicode=ucs4
>> --with-threads --without-threads --with-threads --libdir=/usr/lib64
>> --build=x86_64-pc-linux-gnu
>>
>> Configure has both --with- and --without-threads!!??
>>
>> Nothing I did seemed to make a difference. So I traced where in the
>> ebuild this might be coming from:
>>
>> use threads
>> && myconf="${myconf} --with-threads"
>> && myconf="${myconf} --without-threads"
>>
>> I still don't know why (and would appreciate any knowledgeable person
>> commenting here), but I simply commented out the third line above,
>> re-emerged, and viola! my legacy software is up and running.
>>
>> Kirk
>
> An interesting defect to find, and a good job of detective work!
>
> Out of curiosity, I looked at the python ebuilds on my workstation.
>
> Up through python-2.4.4-r6, they have:
>
> use nothreads
> && myconf="${myconf} --without-threads"
> || myconf="${myconf} --with-threads"
>
> From python-2.4.4-r14 onwards they have:
>
> use threads
> && myconf="${myconf} --with-threads"
> || myconf="${myconf} --without-threads"
>
> Evidently the 2.3.6-r6 ebuild has the newer "use threads" test, but
> with the minor (but fatal) operator flaw you found -- "&&" which
> should be "||".
>
> Hope this is of interest,
Yes, indeed! I need to review my binary operators. ;-)
It's too bad this is legacy stuff. We could file a patch and gain
cyberspace kudo's and good karma! But I did learn a bit about ebuilds.
And -- duh! -- comparing other similar ebuilds is an important
strategy in tracing out these kinds of problems.
Getting python-2.3 back
