root@vapier 0 linux-headers # emerge development-sources -pv These are the packages that I would merge, in order: Calculating dependencies ...done! Note: Nested use flags without parenthesis! (Deprecated) ppc? pcc64? sparc? ['mirror://gentoo/patches-2.6.5-sparc.tar.bz2'] Traceback (most recent call last): File "/usr/bin/emerge", line 2651, in ? mydepgraph.display(mydepgraph.altlist()) File "/usr/bin/emerge", line 1337, in display myfilesdict=portage.portdb.getfetchsizes(x[2], useflags=self.applied_useflags[x[2]], debug=edebug) File "/usr/lib/portage/pym/portage.py", line 4818, in getfetchsizes myuris, myfiles = self.getfetchlist(mypkg,useflags=useflags) File "/usr/lib/portage/pym/portage.py", line 4797, in getfetchlist myurilist = portage_dep.use_reduce(myurilist,useflags,matchall=all) File "/usr/lib/portage/pym/portage_dep.py", line 103, in use_reduce raise ValueError, "Conditional with no target." ValueError: Conditional with no target.
root@vapier 0 linux-headers # emerge info Portage 2.0.50-r4 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.5) System uname: 2.6.5 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz root@prophase 0 root # emerge info Portage 2.0.50-r4 (default-sparc64-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.4) System uname: 2.6.4 sparc64 sun4u
Created attachment 28928 [details, diff] Fixes handling of nested use without parenthesis can't reproduce this... looking at the code, i found that nested use without parenthesis are handled incorrectly, though. DEPEND="a? b? c? z" will match on a USE of "c", "b c", "a b c" or "". This patch fixes that.
Okay.. reproduced it and my other patch won't fix the bug because the bug is in kernel-2.eclass. The deplist before use_reduce (where the exception occurs) is: ['mirror://kernel/linux/kernel/v2.6/linux-2.6.5.tar.bz2', 'x86?', 'ppc?', 'pcc64?', 'sparc?', ['mirror://gentoo/patches-2.6.5-sparc.tar.bz2'], 'mips?', 'alpha?', 'arm?', 'hppa?', 'amd64?', 'ia64?', 'x86obsd?'] or in normal syntax: "mirror://kernel/linux/kernel/v2.6/linux-2.6.5.tar.bz2 x86? ppc? pcc64? sparc? (mirror://gentoo/patches-2.6.5-sparc.tar.bz2) mips? alpha? arm? hppa? amd64? ia64? x86obsd?" This is interpreted with the current (deprecated) rules as: Always mirror://kernel/linux/kernel/v2.6/linux-2.6.5.tar.bz2 If x86, ppc, ppc64 and sparc then mirror://gentoo/patches-2.6.5-sparc.tar.bz2 If mips, alpha, arm, hppa, amd64, ia64, x86obsd then ??? I'll fix my patch so that it actually reports the part of the dep string that causes the traceback. Spanky, portage dying in a friendly manner (for this and other problems) should be fixed in a couple of months.
Created attachment 29030 [details, diff] Non-nested use warning is always printed As per my previous comment, the second non-nested use string will be printed with a deprecation warning before raising the ValueError.
Created attachment 29031 [details, diff] Bug fix Was claiming valid dep strings were deprecated.
Created attachment 29033 [details, diff] diff -u (same as previous)
Created attachment 29035 [details, diff] another solution Hi jstubbs, I saw your patch. But I don't understand what you want to do.. I've think this problem is that empty parenthesis is gone. I made a patch. can you look at it?
Created attachment 29055 [details, diff] Fixed patch Something went wrong when I recreated the patch and there was a line in there that shouldn't have been. I don't think your patch is the correct solution. It essentially adds an empty list to the end of every dep list. This would prevent the traceback from occurring, but would hide the fact that the dep string (SRC_URI in this case) is broken. Also, it doesn't address the problem that my patch does. Here is some output to illustrate the problem: >>> from portage_dep import * >>> use_reduce(paren_reduce("abc? def? xyz"), []) ['xyz'] >>> use_reduce(paren_reduce("abc? def? xyz"), ["abc"]) Note: Nested use flags without parenthesis! (Deprecated) def? xyz [] >>> use_reduce(paren_reduce("abc? def? xyz"), ["def"]) ['xyz'] >>> use_reduce(paren_reduce("abc? def? xyz"), ["abc","def"]) Note: Nested use flags without parenthesis! (Deprecated) def? xyz ['xyz'] And with my patch: >>> from portage_dep import * >>> use_reduce(paren_reduce("abc? def? xyz"), []) Note: Nested use flags without parenthesis! (Deprecated) abc? def? xyz [] >>> use_reduce(paren_reduce("abc? def? xyz"), ["abc"]) Note: Nested use flags without parenthesis! (Deprecated) abc? def? xyz [] >>> use_reduce(paren_reduce("abc? def? xyz"), ["def"]) Note: Nested use flags without parenthesis! (Deprecated) abc? def? xyz [] >>> use_reduce(paren_reduce("abc? def? xyz"), ["abc","def"]) Note: Nested use flags without parenthesis! (Deprecated) abc? def? xyz ['xyz']
If there is "abc? def? xyz" in SRC_URI it's ebuild bug. But development-sources(kernel-2.eclass) has "abc? ( ) def? ( ) xyz". It's not ebuild bug. The ebuild is not broken.
Created attachment 29060 [details, diff] Fix for mishandling of "use? ()" I did notice the problem with "foo? () bar?" being reduced to ["foo?", "bar?"]. By comment about your solution, I meant that "foo? () bar?" is reduced to ["foo?", [], "bar?", []]. This patch will will reduce "foo? () bar?" to ["foo?", [], "bar?"]. The "Fixed patch" is still required to fix the other problem though.
OK. Your patch is better. And what is comment #8 patch for? It's just improving error handling?
As per comment #2 and examples in comment #8, the problem behaviour is that consecutive use flags are only checked if the first use condition matches as follows: is element use flag? is use flag enabled? are there more use flags? accumulate use flags are all use flags enabled? add next element giving: use_reduce(["abc?","def?","xyz"],[]) == ["xyz"] use_reduce(["abc?","def?","xyz"],["abc"]) == [] use_reduce(["abc?","def?","xyz"],["def"]) == ["xyz"] The patch's behaviour is: is element use flag? are there more use flags? accumulate use flags are all use flags enabled? add next element
Hmmm, my previous explanation was not entirely accurate. Look at it this way, "use1? use2? use3? use4? atom" If use1 is not set, use2 will be skipped and processing restarts at use3. If use3 is not set, use4 will be skipped and processing restarts at atom. If use1 or use3 is set, then the remaining elements are checked to see if they are conditions. Thus "atom" is returned if USE equals "", "use3 use4" or "use1 use2 use3 use4". My patch simply checks for extra use conditions before acting on the first one.
Fixed for a while...
