$ ebuild util-linux-2.19.1-r1.ebuild prepare * util-linux-2.19.1.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * util-linux-2.19.1-20110510.diff.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking util-linux-2.19.1.tar.bz2 ;-) ... [ ok ] * checking util-linux-2.19.1-20110510.diff.bz2 ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking util-linux-2.19.1.tar.bz2 to /var/tmp/portage/sys-apps/util-linux-2.19.1-r1/work >>> Unpacking util-linux-2.19.1-20110510.diff.bz2 to /var/tmp/portage/sys-apps/util-linux-2.19.1-r1/work >>> Source unpacked in /var/tmp/portage/sys-apps/util-linux-2.19.1-r1/work >>> Preparing source in /var/tmp/portage/sys-apps/util-linux-2.19.1-r1/work/util-linux-2.19.1 ... * Applying util-linux-2.19.1-20110510.diff ... [ ok ] * Applying util-linux-2.19.1-mount-a-segv.patch ... [ ok ] * Applying util-linux-2.19.1-umount-l-nfs.patch ... * Failed Patch: util-linux-2.19.1-umount-l-nfs.patch ! * ( /opt32/portage/ebuilds/sys-apps/util-linux/files/util-linux-2.19.1-umount-l-nfs.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-apps/util-linux-2.19.1-r1/temp/util-linux-2.19.1-umount-l-nfs.patch.out * ERROR: sys-apps/util-linux-2.19.1-r1 failed (prepare phase): * Failed Patch: util-linux-2.19.1-umount-l-nfs.patch! * * Call stack: * ebuild.sh, line 56: Called src_prepare * environment, line 2927: Called epatch '/opt32/portage/ebuilds/sys-apps/util-linux/files/util-linux-2.19.1-umount-l-nfs.patch' * environment, line 1590: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * * If you need support, post the output of 'emerge --info =sys-apps/util-linux-2.19.1-r1', * the complete build log and the output of 'emerge -pqv =sys-apps/util-linux-2.19.1-r1'. * The complete build log is located at '/var/tmp/portage/sys-apps/util-linux-2.19.1-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/util-linux-2.19.1-r1/temp/environment'. * S: '/var/tmp/portage/sys-apps/util-linux-2.19.1-r1/work/util-linux-2.19.1' Patch 'util-linux-2.19.1-umount-l-nfs.patch' can't be applied cleanly. And what is more important when I modified that patch, result was compilation failure because that patch is using function 'find_loopdev_by_backing_file' which was removed by 'util-linux-2.19.1-20110510.diff'! How could this get through QA??? SHA256: cfb2cbafb2dbb359e5bfddd5554a2463fe62f50f3ec4f639d2512c2554f2376a util-linux-2.19.1-20110510.diff f889de8dba4cb412ec0afcd2605c4f97e0870c6325dd0200e8c8c06794b4bf64 util-linux-2.19.1-umount-l-nfs.patch Reproducible: Always Steps to Reproduce: 1.ebuild sys-apps/util-linux-2.19.1-r1 prepare compile 2. 3. Actual Results: Successful emerge Expected Results: Ebuild 'prepare' and with modified patch even 'compile' failure
works for me: amd64box util-linux # ebuild util-linux-2.19.1-r1.ebuild prepare * util-linux-2.19.1.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking util-linux-2.19.1.tar.bz2 ;-) ... [ ok ] * Package: sys-apps/util-linux-2.19.1-r1 * Repository: gentoo * Maintainer: c1pher@gentoo.org base-system@gentoo.org * USE: amd64 cramfs crypt elibc_glibc kernel_linux multilib ncurses nls perl test unicode userland_GNU * FEATURES: sandbox test >>> Unpacking source... >>> Unpacking util-linux-2.19.1.tar.bz2 to /tmp/portage/sys-apps/util-linux-2.19.1-r1/work >>> Source unpacked in /tmp/portage/sys-apps/util-linux-2.19.1-r1/work >>> Preparing source in /tmp/portage/sys-apps/util-linux-2.19.1-r1/work/util-linux-2.19.1 ... * Applying util-linux-2.19.1-mount-a-segv.patch ... [ ok ] * Applying util-linux-2.19.1-umount-l-nfs.patch ... [ ok ] * Running elibtoolize in: util-linux-2.19.1/config/ * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... >>> Source prepared.
(In reply to comment #1) Try USE="loop-aes".
Created attachment 280047 [details, diff] Temporary workaround for current (2011.07.14) incompatibility between loop-aes and bug #370051.
(In reply to comment #2) > (In reply to comment #1) > > Try USE="loop-aes". You probably wanted to suggest USE="-loop-aes"...
(In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > > Try USE="loop-aes". > > You probably wanted to suggest USE="-loop-aes"... Nope. With USE="-loop-aes" everything is fine as Agostino Sarubbo wrote. Problem is with USE="loop-aes" because you can't apply both util-linux-2.19.1-umount-l-nfs.patch and util-linux-2.19.1-20110510.diff patches so they are mutually exclusive. Just now you can have loop-aes support in util-linux with bug #370051 open or bug #370051 closed but no loop-aes support at all. Loop-aes support without bug #370051 vulnerability is Mission Impossible (TM) right now. My patch is just only workaround with warnings for user but no solution of that incompatibility. Maybe only chance is just waiting for incorporation of util-linux-2.19.1-umount-l-nfs.patch to mainline and new version of loop-aes patch.
*** Bug 375391 has been marked as a duplicate of this bug. ***
I am waiting for new loop-aes patch
It would appear that, among other things, the loop-aes patch removes (with #if 0) the very same bit of code that the l-nfs patch wants to relocate. Are the two patches trying to fix the same bug in different ways (by omitting the troublesome code in the loop-aes case, and by deferring it until later in the l-nfs case)? If so, then somebody needs to decide which solution to use, as it would be impossible to do both at once. The easiest way to get it compiling may be to only apply the l-nfs patch when not using loop-aes. That approach builds ok, but I've not tested whether it ends up behaving correctly.
I have masked util-linux-2.19.1-r1 to use util-linux-2.19.1 instead. But now I cannot compile any recent version of loop-aes. I tried : loop-aes-3.6b, loop-aes-3.6b-r1 and loop-aes-3.6c. Anybody could tell me how I could compile loop-aes ? I need it to read an encrypted partition I mount with loop-aes. My emerge --info is at [url]http://pastebin.com/JjHXjHc6[/url] My compilation log of loop-aes-3.6b-r1 is at [url]http://pastebin.com/YQ0gjpwV[/url] My emerge --info =loop-aes-3.6b-r1 is at [url]http://pastebin.com/sDK5Kvg8[/url] Regards, Bernard :=)
Is there any way that more priority be given to resolve this bug. I can't read anymore my encrypted loop aes partition since that bug... It now block upgrade to sys-apps/sysvinit-2.88-r3 wich pulls other stuff, and so on. This is a very irritating bug and it's been there for a while. And it starting to have collateral damages. So please help!
Any news about this one ?
Hi, changing the loop-aes patch to http://loop-aes.sourceforge.net/updates/util-linux-2.20-20110905.diff.bz2 worked well for me. Perhaps the ebuild should be fixed to use this patch rather than the 2.19 patch ...
changing the patch to scr4tch's worked on my system
+ 12 Nov 2011; Lars Wendler <polynomial-c@gentoo.org> + util-linux-2.19.1-r1.ebuild, + +files/util-linux-2.19.1-remove-useless-if-stuff-from-loopaes-patchset.diff: + non-maintainer commit: Fixed application of umount-l patch in combination + with loop-aes patch. This fixes bug #375165. + Should be fixed now: >>> Preparing source in /var/tmp/portage/sys-apps/util-linux-2.19.1-r1/work/util-linux-2.19.1 ... * Applying util-linux-2.19.1-20110510.diff ... [ ok ] * Applying util-linux-2.19.1-remove-useless-if-stuff-from-loopaes-patchset.diff ... [ ok ] * Applying util-linux-2.19.1-mount-a-segv.patch ... [ ok ] * Applying util-linux-2.19.1-umount-l-nfs.patch ... [ ok ] * Running elibtoolize in: util-linux-2.19.1/config/ * Applying portage/2.2 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.2.6 patch ... >>> Source prepared. Please re-sync portage in a while and try again.
