Some people already know what I’m talking about but I’m pretty sure most won’t. But trust me first, and go sync or mask patch-2.6 locally and downgrade it as soon as you can.
The new version of the utility messes up when using -p0 and the fuzz factor, and that breaks the epatch function that almost every ebuild uses, one way or another. The result is that patches will silently fail to happen. For more specifics see bug #293570 which was reported already in mid-November but just didn’t cause enough uproar.
Now, I did see the bug before on the base-layout queue, but I thought it was such a minor issue that I just didn’t care enough. I came to look at it again today because I found three packages in the tinderbox failing to build because patches were skipped. At first, still no problem: that’s the task of the tinderbox, I would let the tinderbox run with it and see what also failed.
But then I could see the big problem of this: patches are dropped silently; all kinds of patches. But what I could tell was just if the patch solved a build failure. Oops! Patches failing crashers, security issues and similar will also fail silently, and those wouldn’t get patched. In the best case scenario, they would cause some QA warnings that were fixed already to reappear, and make the developers notice the missing patch. In the worst case, you’d get security fixes to not be applied any longer, which is tremendously bad.
If you want to be on the safe side, after downgrading you should rebuild everything you built with patch-2.6 installed; the following script will give you the package names (not perfect, let met tell you that already, if somebody can improve it in the comments it’d be even better):
qlop -Cl | tail -n +$(qlop -l | grep -n patch-2.6 | head -1 | cut -d: -f1) |
sed -e 's:.* >>> ::' | xargs -r -n1 qatom |
awk '{ printf "%s/%sn", $1, $2 }' | sort -u | join - <(qlist -IC | sort -u)
Update: thanks to O Andarilho for pointing out a flaw in the old script in case patch-2.6 was not merged at all, this is now fixed in the script above (by using xargs -r).
Update 2: also thanks to Nick Bowler for cleaning away the packages that aren’t currently merged. _Note: slots aren’t considered so the script is still a bit rough but should cover most issues.
Well, the output for your quick script:<typo:code>tail: +: invalid number of lines/Options:/-[cvqChV]Usage:/qatom-c,/–compare-C,/–nocolor-h,/–help-q,/–quiet-v,/–verbose-V,/–version</typo:code>qatom needs arguments (you surely know, but others may not..)
I moved recently and got behind on updates -I was just contemplating the chore of catching up. Saw this right on time.
The posted script lists packages which were installed and then subsequently removed. Add | join – <(qlist -IC)to the end.
This is worth adding to eselect news
Argh. I knew I’d regret deleting my emerge.log some day.
Here is another take on rebuilding packages:
emerge -va1 $(for i in $(genlop -nl --date "$(genlop -n sys-devel/patch-2.6|tail -n+3|head -n1|cut -d> -f1)"|cut -d> -f4|tail -n+4);do if [ -d /var/db/pkg/$i ] && grep -q inherit $(equery which $i)then echo $i;fi;done|sort|uniq|sed 's/^/=/')It skips ebuilds with no inherits, so you don’t have to rebuild any packages that for sure doesn’t call epatch. Well, maybe some scripts inside package’s building system call patch, so if you’re paranoid, it’s not for you. But it gives me 56 packages opposed to 70 if I remove check for epatch.It occured to me that only ebuilds using EPATCH_OPTS with fuzz factor should be rebuilt. So here is modified version:
emerge -va1 $(for i in $(genlop -nl --date "$(genlop -n sys-devel/patch-2.6|tail -n+3|head -n1|cut -d> -f1)"|cut -d> -f4|tail -n+4);do if [ -d /var/db/pkg/$i ] && egrep -q 'inherit.*(rpm|nxserver)|EPATCH_OPTS.*-F' $(equery which $i)then echo $i;fi;done|sort|uniq|sed 's/^/=/')(rpm eclass calls patch with unknown arguments and nxserver eclass inherits rpm so I added check for them).Now it gives me no packages at all, so problem may be overblown.@parafin no unfortunately there are things breaking a part even when fuzz factor is not used directly, so the problem is *not* that overblown.
ok then,/me runs first version of his command:)
If you have not yet downgraded patch, you can also use the installation date to find out which packages to reemerge. With >=eix-0.18.2 the following should work and output the slots properly where necessary:eix -‘*I’ –format ‘<installedversions:datesort>’ |sort|cut -f3|sed -ne ‘//patch$/,$p’
Sorry, I forgot to quote the code. Here it is hopefully correctly displayed:
eix -'*I' --format '<installedversions:datesort>' |sort|cut -f3|sed -ne '//patch$/,$p'The qlop call in my script uses the sequence, rather than just the date, of the first patch-2.6 installation.I’m not sure if your trick works fine if you ever reinstalled patch after the first 2.6 upgrade.
You are right, of course, that’s why I said what the thing does: It relies (only) on the installation date. For this reason, the trick will also not find e.g. binary packages you built without merging them.
For paludis users that’d be:awk ‘/finished install of package sys-devel/patch-2.6:0::gentoo/ { s=”t” } /finished install of/ && $6 ~ /// { if (s == “t”) { sub(/-[0-9].*/, “”, $6) print $6 } }’ /var/log/paludis.logThanks to arachnist for that script.
More easily …$ emerge -auvb =sys-devel/patch-2.5.9-r1$ genlop sys-devel/patch-2.6 | grep ‘>>>’ | head -n 1Sun Nov 15 15:56:38 2009 >>> sys-devel/patch-2.6$ genlop sys-devel/patch-2.5.9-r1 | tail -n 2Tue Dec 1 20:19:51 2009 >>> sys-devel/patch-2.5.9-r1$ genlop -l –date Sun Nov 15 15:56:38 2009 –date Tue Dec 1 20:19:51 2009 | sed “s/^[^>]* >>> /=/”Also add possible unwanted packages placed in an other $ROOT directory as ‘/’
And what’s wrong with simple emerge -va1 $(qlop -Cl |awk ‘{print “>=”$7}’ | grep -A 9999 patch-2.6 | grep -v patch-2.6)? 😛
Shouldn’t epatch check the return code from running patch? In both 2.59 and 2.6, the output from running patch -p0 is 1 if the patch fails to apply. So from that POV it is not a silent fail.The other differences are in 2.6 the output from the failed patch is stored in a .rej file in a sub directory, and in 2.59 the text message contains the string “can’t find file to patch”.The post sounds a bit like “patch 2.6 is broken”, which is not strictly true. If epatch solely relies on parsing the output of patch’s stderr, than that is arguably a bit flaky.
Adding the “–posix” flag gives the same behaviour in 2.6 as 2.59.
Richard, the problem is that the patches “fail silently” in the sense that they fail to work as intended. In patch 2.6 by default, the presence or otherwise of a file is no longer a failure condition: if the context is smaller than the fuzz factor (which, by default, it’s 2) then it’s going to be considered “applied” anyway. And that’s a problem, because some files *have* fewer lines of context.@epatch@ is not looking at the stderr alone and it *is* checking the return code, it’s just that 2.6 changed what they considered a failure, and that is breaking our code.
So how did this manage to get through Gentoo’s QA testing? Another case of more broken packages…. Diego, do you get the feeling you’re trying to empty a lake with a teaspoon?I did an emerge -auDN world a couple of weeks ago, and yet again it broke my X – no keyboard, no mouse. By this point, I’d had enough of broken emerges, broken packages and other issues. I wiped the OS and put on F12. Fedora has come on a long way in the past few years and, even with the bloat they have, I think it’s faster than Gentoo is. Certainly transferring to/from USB Hard Drive is much, much quicker. Right now, after reading posts like this, I don’t think I’ll be going back to Gentoo anytime soon – which is a real shame for me, I’ve used it for 4 years and not touched anything else. But the past couple of months have seen too many breakages and wackyness for me to continue with it.Diego, I know it’s not your fault – you’re fixing, not breaking – you do an awesome job and I personally salute you. I just wish the other devs took it as seriously as you do.
Diego, once again thanks for another heads up 🙂