The patch util-linux-2.20-20110905.diff does not appear to belong in sys-apps/util-linux-2.21. The package does not build with it present, and the patch is for a completely different file layout. It tries to patch files in util-linux-2.20-AES/mount that are actually located in util-linux-2.21/sys-utils for example, as well as trying to patch files that don't exist anywhere in the source at all. Even after correcting 2.20-AES to 2.21, not a single file altered by this patch exists in the location specified by the patch. grep '+++' /var/tmp/portage/sys-apps/util-linux-2.21/work/*diff | awk '{print $2}' util-linux-2.20-AES/mount/Makefile.am util-linux-2.20-AES/mount/Makefile.in util-linux-2.20-AES/mount/aes.c util-linux-2.20-AES/mount/aes.h util-linux-2.20-AES/mount/lomount.c util-linux-2.20-AES/mount/lomount.h util-linux-2.20-AES/mount/loop.c util-linux-2.20-AES/mount/loop.h util-linux-2.20-AES/mount/losetup.8 util-linux-2.20-AES/mount/loumount.c util-linux-2.20-AES/mount/loumount2.c util-linux-2.20-AES/mount/mount.8 util-linux-2.20-AES/mount/mount.c util-linux-2.20-AES/mount/rmd160.c util-linux-2.20-AES/mount/rmd160.h util-linux-2.20-AES/mount/sha512.c util-linux-2.20-AES/mount/sha512.h util-linux-2.20-AES/mount/swapon.8 util-linux-2.20-AES/mount/swapon.c util-linux-2.20-AES/mount/umount.c for f in $(grep '+++' /var/tmp/portage/sys-apps/util-linux-2.21/work/*diff | awk '{print $2}') ; do if [ -f $f ] ; then echo $f exists ; else echo $f does not exist; fi ; done util-linux-2.20-AES/mount/Makefile.am does not exist util-linux-2.20-AES/mount/Makefile.in does not exist util-linux-2.20-AES/mount/aes.c does not exist util-linux-2.20-AES/mount/aes.h does not exist util-linux-2.20-AES/mount/lomount.c does not exist util-linux-2.20-AES/mount/lomount.h does not exist util-linux-2.20-AES/mount/loop.c does not exist util-linux-2.20-AES/mount/loop.h does not exist util-linux-2.20-AES/mount/losetup.8 does not exist util-linux-2.20-AES/mount/loumount.c does not exist util-linux-2.20-AES/mount/loumount2.c does not exist util-linux-2.20-AES/mount/mount.8 does not exist util-linux-2.20-AES/mount/mount.c does not exist util-linux-2.20-AES/mount/rmd160.c does not exist util-linux-2.20-AES/mount/rmd160.h does not exist util-linux-2.20-AES/mount/sha512.c does not exist util-linux-2.20-AES/mount/sha512.h does not exist util-linux-2.20-AES/mount/swapon.8 does not exist util-linux-2.20-AES/mount/swapon.c does not exist util-linux-2.20-AES/mount/umount.c does not exist Package appears to build correctly with this patch skipped.
confirmed. Package builds when replacing the patch with an empty dummy file
Also just confirming that the package builds when skipping diff.
i dont know what this patch is for, but i can also confirm that it works without =)
I am also having the same issue. It appears the reason for the patch is to build losetup with support for AES. http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS / http://en.gentoo-wiki.com/wiki/AES-encrypted_root_partition_using_LVM2 / sys-fs/loop-aes kernel module package. I'm using an encrypted disk, but doubt that this is necessary for just LUKS on root, but will try testing without the use flag.
Created attachment 305247 [details] util-linux-2.21.ebuild.patch pointed to proper patch
New patchset available on http://loop-aes.sourceforge.net/updates/ With new patchset loop-aes enabled util-linux-2.21 seems builds correctly, please test. Ebuild patch attached.
*** Bug 408539 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > New patchset available on http://loop-aes.sourceforge.net/updates/ > With new patchset loop-aes enabled util-linux-2.21 seems builds correctly, > please test. Ebuild patch attached. Applied the patch and it worked marvelous. Thanx for sharing.
(In reply to comment #8) > (In reply to comment #6) > > New patchset available on http://loop-aes.sourceforge.net/updates/ > > With new patchset loop-aes enabled util-linux-2.21 seems builds correctly, > > please test. Ebuild patch attached. > > Applied the patch and it worked marvelous. Thanx for sharing. glad to help =) 2maintainer: Please, update util-linux-2.21.ebuild in portage tree =)
Now we have the same in 2.21.1: >>> Preparing source in /var/tmp/portage/sys-apps/util-linux-2.21.1/work/util-linux-2.21.1 ... * Applying util-linux-2.20-20110905.diff ... * Failed Patch: util-linux-2.20-20110905.diff ! * ( /var/tmp/portage/sys-apps/util-linux-2.21.1/work/util-linux-2.20-20110905.diff ) * thats quality, in 2 releases the same silly bug
Created attachment 307349 [details] util-linux-2.21.1.ebuild.patch
(In reply to comment #10) > Now we have the same in 2.21.1: > > >>> Preparing source in /var/tmp/portage/sys-apps/util-linux-2.21.1/work/util-linux-2.21.1 ... > * Applying util-linux-2.20-20110905.diff ... > > * Failed Patch: util-linux-2.20-20110905.diff ! > * ( > /var/tmp/portage/sys-apps/util-linux-2.21.1/work/util-linux-2.20-20110905. > diff ) > * > > thats quality, in 2 releases the same silly bug Sorry for late answer, just trying to migrate my own overlay from subversion to git. Got a little problems with it, but i'll fix them =)) I know, for this must be opened absolutely new bug, but quick and dirty patch attached here, sorry. jospezial or someone else, can you test patch and please and give your feedback? also, if you really use loop-aes, please, give us feedback, how it works, it's stable or not etc. thank you. Mr. Dane Smith, please, please and please once again. Can you review this thread and fix >=util-linux-2.21.ebuilds if present fixes is sufficient to work? Thank you vey much =)
(In reply to comment #11) > Created attachment 307349 [details] > util-linux-2.21.1.ebuild.patch Your patch uses util-linux-2.21-20120228.diff.bz2. That does not work with 2.21.1 , tried it already before by my self. It doesn't find the files to patch because it looks for 2.21 and not 2.21.1. So all path and filenames have to be changed to 2.21.1 or we have to wait until on http://loop-aes.sourceforge.net/updates comes a fitting patch.
thank you, will try to fix =)
(In reply to comment #13) > Your patch uses util-linux-2.21-20120228.diff.bz2. > That does not work with 2.21.1 , tried it already before by my self. > It doesn't find the files to patch because it looks for 2.21 and not 2.21.1. > So all path and filenames have to be changed to 2.21.1 or we have to wait > until on http://loop-aes.sourceforge.net/updates comes a fitting patch. Well, problem lies not only in pathes. I've tryed own so called util-linux-2.21.1-20120228.diff with corrected path, some patches applied, but most of them failed.
*** Bug 410995 has been marked as a duplicate of this bug. ***
*** Bug 418101 has been marked as a duplicate of this bug. ***
Dane, this is getting bad. You can't get a system package to fail even with a non-default configuration for three months...
(In reply to comment #18) > Dane, this is getting bad. You can't get a system package to fail even with > a non-default configuration for three months... lemme please correct four months... and its getting more annoying, every time you hit this bug
Maybe until this is fixed the USE-Flag should just get keyworded?
more than 5 months <sing>how far can we get, how far can we get</sing> sorry but recently just run again into this bug, gets annoying more and more every day.
This error is also in sys-apps/util-linux-2.21.
should be all set now in the tree; thanks for the report! Commit message: Punt USE=loop-aes again due to lack of interest http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.21.1.ebuild?r1=1.8&r2=1.9 http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.21.2.ebuild?r1=1.3&r2=1.4 http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.21.ebuild?r1=1.4&r2=1.5 http://sources.gentoo.org/sys-apps/util-linux/util-linux-9999.ebuild?r1=1.33&r2=1.34
I might be wrong but wont that allow users with loop-aes enable to upgrade their package? That will be quite a surprise when you reboot but can't mount your envrypted partition anymore... Is it possible to prevent the upgrade is loop-aes is enable?
Yes, this change will destroy some systems that use loop-aes. There's a few ways to use it: - to encrypt / - in this case you likely have an losetup binary in /boot/ (or on alternate media) that is used during the boot process, and this will not be changed just by emerge -u'ing util-linux. So the system will continue to work. (Unless you make a habit of keeping the /boot/ binaries current, in which case you're dead.) - to encrypt swap, non-essential filesystems - in this case accessing those will fail after this change. But enough of the system will probably remain working that you can figure out what happened, and roll back to an older util-linux (and dependencies, like sysvinit... not fun but survivable). - to encrypt essential partitions other than (or in addition to) / - in this case, you are hosed. You can't get the system up far enough to downgrade; maybe you can copy over working binaries from another system. Thank you and please drive through. I can understand util-linux maintainers getting tired of complaints from people when there's no current loop-aes patch available. Leaving a reference to a known-unworking, old patch in the .ebuild just invites those users to complain that the ebuild is broken. But is silently breaking lots of[*] systems really the best answer? Why not update the ebuild to fail when USE="loop-aes" is set, with a message as to _why_, and what to do (mask the newer version and/or ping the loop-aes maintainer for newer diffs)? Wouldn't that avoid (most of the) complaints, but also not break lots of servers for no reason? [*]citation needed.
Created attachment 325068 [details, diff] loop-aes patch for util-linux-2.21.2 I found this bug after I wanted to upgrade util-linux today and I really don't understand why we have to wait for the loop-aes maintainers to upload a new patch instead of only adjusting the latest one. There is only an error when patching the man-page of losetup and even the official patch states a possible solution for this problem in it's header. I have fixed the patch so that it works with util-linux-2.21.2 (and also 2.21.1). Maybe there is no interest in adding loop-aes support again to the official util-linux ebuild. But in case someone wants to use it, then he can use the diff that I have added to this bug.