| 1 |
Duncan posted <pan.2004.10.20.21.36.50.96533@×××.net>, excerpted below, |
| 2 |
on Wed, 20 Oct 2004 14:36:50 -0700: |
| 3 |
|
| 4 |
> Further, I mentioned I hadn't seen it with rc9, but that could be because |
| 5 |
> I've adjusted my behavior slightly to avoid it. Later today, I'll try to |
| 6 |
> deliberately trigger the problem, and see if I can get it to reoccur with |
| 7 |
> now rc10 (or release, if it's out by then). |
| 8 |
|
| 9 |
OK, didn't get to it "today", but finally got to it today. <g> |
| 10 |
|
| 11 |
Actually, between updates of portage, I /did/ manage a couple small |
| 12 |
earlier tests but didn't get anything conclusive. I just tried |
| 13 |
re-emerging xorg-x11-6.8.0-r1 (I wanted to try some different cflags -- |
| 14 |
yes, that means I'm using an overlay copy of the ebuild, to comment out |
| 15 |
strip-flags, yes I DID diff a current ebuild with my old overlay ebuild |
| 16 |
and update as appropriate), and I'm still having the problem, now with |
| 17 |
portage-2.0.51-r2. |
| 18 |
|
| 19 |
To wit: |
| 20 |
|
| 21 |
1 Emerge xorg-x11 and had it crash partway thru the compile step (my bad |
| 22 |
hardware). |
| 23 |
|
| 24 |
2 CD to the workdir and complete the make manually. |
| 25 |
|
| 26 |
3 Examine the ebuild to ensure that was all that was needed to complete |
| 27 |
the compile step, so I could... |
| 28 |
|
| 29 |
4 Manually touch .compiled |
| 30 |
|
| 31 |
5 ebuild /path/to/overlay/x11-base/xorg-x11-6.8.0-r1.ebuild package |
| 32 |
|
| 33 |
6 ebuild detects a completed compile and does the install and package |
| 34 |
|
| 35 |
7 Attempt to emerge -aK the new package. |
| 36 |
|
| 37 |
8 Package is STILL invalid. |
| 38 |
|
| 39 |
9 Go back to plan B and ebuild /path/to/ebuild qmerge the still-existing |
| 40 |
portage tempdir image. |
| 41 |
|
| 42 |
10 Since it was a re-merge of a previously merged package, emerge -c finds |
| 43 |
no old package to clean |
| 44 |
|
| 45 |
11 qmerged image works JUST FINE, as expected. |
| 46 |
|
| 47 |
12 Try quickpkg xorg-x11: |
| 48 |
|
| 49 |
* Building package for xorg-x11-6.8.0-r1... [ ok ] |
| 50 |
|
| 51 |
* Packages now in /mnt/p/pkg: |
| 52 |
* xorg-x11-6.8.0-r1: 50M |
| 53 |
|
| 54 |
(completes without error) |
| 55 |
|
| 56 |
13 Try emerge -aK xorg-x11 again: |
| 57 |
|
| 58 |
These are the packages that I would merge, in order: |
| 59 |
|
| 60 |
!!! Invalid binary package: xorg-x11-6.8.0-r1.tbz2 |
| 61 |
!!! Invalid binary package: kdelibs-3.3.1.tbz2 |
| 62 |
Calculating dependencies |
| 63 |
!!! There are no packages available to satisfy: "xorg-x11" |
| 64 |
!!! Either add a suitable binary package or compile from an ebuild. |
| 65 |
|
| 66 |
The package is *STILL* invalid! |
| 67 |
|
| 68 |
14 An ls -l of the package file confirms by timestamp that it is |
| 69 |
indeed the quickpkg package, so /that's/ working, only it's STILL an |
| 70 |
invalid package. |
| 71 |
|
| 72 |
############## |
| 73 |
|
| 74 |
What causes the package step to include invalid category and etc data? |
| 75 |
|
| 76 |
Checking the portage log, I see this at the beginning of the install step, |
| 77 |
so it /does/ seem to know the category there. |
| 78 |
|
| 79 |
>>> Install xorg-x11-6.8.0-r1 into /tmp/portage/xorg-x11-6.8.0-r1/image/ category x11-base |
| 80 |
|
| 81 |
Yet: |
| 82 |
python -c 'import xpak; tbz2=xpak.tbz2("xorg-x11-6.8.0-r1.tbz2"); print tbz2.getelements("CATEGORY")' |
| 83 |
[] |
| 84 |
|
| 85 |
|
| 86 |
Perhaps it happens with the overlay only? Don't think so, because I |
| 87 |
hadn't touched the kdelibs-3.3.1.ebuild and it did the same thing (with an |
| 88 |
earlier .51 portage). |
| 89 |
|
| 90 |
FWIW, it worked in portage 2.0.50 just fine. |
| 91 |
|
| 92 |
-- |
| 93 |
Duncan - List replies preferred. No HTML msgs. |
| 94 |
"They that can give up essential liberty to obtain a little |
| 95 |
temporary safety, deserve neither liberty nor safety." -- |
| 96 |
Benjamin Franklin |
| 97 |
|
| 98 |
|
| 99 |
|
| 100 |
-- |
| 101 |
gentoo-dev@g.o mailing list |
Archives