| 1 |
On Sun, Sep 28, 2008 at 8:38 AM, David Relson <relson@×××××××××××××.com> wrote: |
| 2 |
> On Sat, 27 Sep 2008 12:58:40 -0400 |
| 3 |
> Kirk Lowery wrote: |
| 4 |
> |
| 5 |
>> On Fri, Sep 26, 2008 at 2:47 AM, Neil Bothwick <neil@××××××××××.uk> |
| 6 |
>> wrote: |
| 7 |
>> > On Thu, 25 Sep 2008 17:59:35 -0400, Kirk Lowery wrote: |
| 8 |
>> > |
| 9 |
>> >> During upgrading today, I inadvertently allowed 2.3 to be deleted. |
| 10 |
>> >> I looked in portage, but it is apparently gone. |
| 11 |
>> > |
| 12 |
>> > Nothing is ever truly gone from portage |
| 13 |
>> > |
| 14 |
>> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/python/?hideattic=0 |
| 15 |
>> > |
| 16 |
>> > goes back as far as python-1/5/2 |
| 17 |
>> |
| 18 |
>> Thanks for the answers. I thought I'd report my experience here for |
| 19 |
>> the knowledgebase: |
| 20 |
>> |
| 21 |
>> I went back and downloaded not only the latest 2.3.6 ebuild into my |
| 22 |
>> local overlay, and all the attendant files (including important |
| 23 |
>> patches) in the "files" directory. In order to be able to emerge the |
| 24 |
>> ebuild file, I had to recreate the digest and manifest files. Don't |
| 25 |
>> know why the checksums were off, but they were. The solution was |
| 26 |
>> simple: |
| 27 |
>> |
| 28 |
>> # ebuild python-2.3.6-r6.ebuild digest |
| 29 |
>> |
| 30 |
>> took care of it. When I tried to restart my legacy software I got a |
| 31 |
>> python error: "ImportError: No module named thread". Sure enough, the |
| 32 |
>> equery use feature told me "-threads". So I overrode that in |
| 33 |
>> package.use. Nope, no change. Looking at the compile log, I saw this: |
| 34 |
>> |
| 35 |
>> ./configure --prefix=/usr --host=x86_64-pc-linux-gnu |
| 36 |
>> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share |
| 37 |
>> --sysconfdir=/etc --localstatedir=/var/lib --with-fpectl |
| 38 |
>> --enable-shared --enable-ipv6 --infodir=${prefix}/share/info |
| 39 |
>> --mandir=${prefix}/share/man --with-libc= --enable-unicode=ucs4 |
| 40 |
>> --with-threads --without-threads --with-threads --libdir=/usr/lib64 |
| 41 |
>> --build=x86_64-pc-linux-gnu |
| 42 |
>> |
| 43 |
>> Configure has both --with- and --without-threads!!?? |
| 44 |
>> |
| 45 |
>> Nothing I did seemed to make a difference. So I traced where in the |
| 46 |
>> ebuild this might be coming from: |
| 47 |
>> |
| 48 |
>> use threads \ |
| 49 |
>> && myconf="${myconf} --with-threads" \ |
| 50 |
>> && myconf="${myconf} --without-threads" |
| 51 |
>> |
| 52 |
>> I still don't know why (and would appreciate any knowledgeable person |
| 53 |
>> commenting here), but I simply commented out the third line above, |
| 54 |
>> re-emerged, and viola! my legacy software is up and running. |
| 55 |
>> |
| 56 |
>> Kirk |
| 57 |
> |
| 58 |
> An interesting defect to find, and a good job of detective work! |
| 59 |
> |
| 60 |
> Out of curiosity, I looked at the python ebuilds on my workstation. |
| 61 |
> |
| 62 |
> Up through python-2.4.4-r6, they have: |
| 63 |
> |
| 64 |
> use nothreads \ |
| 65 |
> && myconf="${myconf} --without-threads" \ |
| 66 |
> || myconf="${myconf} --with-threads" |
| 67 |
> |
| 68 |
> From python-2.4.4-r14 onwards they have: |
| 69 |
> |
| 70 |
> use threads \ |
| 71 |
> && myconf="${myconf} --with-threads" \ |
| 72 |
> || myconf="${myconf} --without-threads" |
| 73 |
> |
| 74 |
> Evidently the 2.3.6-r6 ebuild has the newer "use threads" test, but |
| 75 |
> with the minor (but fatal) operator flaw you found -- "&&" which |
| 76 |
> should be "||". |
| 77 |
> |
| 78 |
> Hope this is of interest, |
| 79 |
|
| 80 |
Yes, indeed! I need to review my binary operators. ;-) |
| 81 |
|
| 82 |
It's too bad this is legacy stuff. We could file a patch and gain |
| 83 |
cyberspace kudo's and good karma! But I did learn a bit about ebuilds. |
| 84 |
And -- duh! -- comparing other similar ebuilds is an important |
| 85 |
strategy in tracing out these kinds of problems. |
| 86 |
|
| 87 |
Thanks for looking further into this. |
| 88 |
|
| 89 |
Kirk |
Archives