Bugzilla Bug 71603

just wanted to have loop-aes in portage... here's an abuild and patch for
util-linux, which allow user to chose between cryptoapi and loop-aes support.
note, that util-linux depends on sys-fs/loop-aes - i'm not sure if it's the
best location for it (if you want - change it). also - note that i've added
'loop-aes' into USE flags

Created an attachment (id=44187) [details]
loop-aes-2.2d.ebuild

Created an attachment (id=44188) [details]
patch for util-linux ebuild

Don't know if it's worth it, having dm-crypt in mind. Since you need to agree
for the patch, it's your bug base-system herd.

actually i don't like dm-crypt. i've tried it some time ago and it crashed
after about month of using;/ besides - it was damm slow (comparing to
loop-aes). i'm not sure if that issues aren't fixed now (i've tried it in 2.6.2
or 2.6.3 kernel as far as i remember), but anyway many people still uses
cryptoloop and loop-aes and it's often not so easy to move all data to new
crypting system

loop-aes would be useful in portage IMHO

I'm agree with cpu, it should be added to portage.

Created an attachment (id=44937) [details]
ebuild for new version

Created an attachment (id=44939) [details]
patch for util-linux to compile with loop-aes-3.0a

i've added ebuilds for loop-aes-3.0a above (hope someone'll add it to portage
at last;/)

And the current util-linux also supports only loop-aes instead of the
kernel-based cryptoloop.

Created an attachment (id=49733) [details]
loop-aes-3.0b.ebuild

New ebuild, please test and comment

It would be nice if there was a way to use the loop-AES kernel patch without
having to manually patch my sources.  I'd rather build this into my kernel
instead of as a module.

Quoting loop-AES.README
"
kernel-2.[46].*.diff        Kernel patch for those people who prefer not to
                            use modules. Before this patch can be applied to
                            your kernel, drivers/block/loop.c and
                            include/linux/loop.h source files must be
                            removed using 'rm' command. Obviously applying
                            this patch changes your kernel sources, so this
                            is not entirely hassle free. This patch is
                            against recent mainline kernel. If this patch
                            doesn't apply cleanly to your kernel, I don't
                            want to know about it. Note: you only need to
                            build loop.o module or apply this patch but not
                            both.
"

Our gentoo-dev-sources patchset is feature-frozen, so I dont think we have any
chance to get it in there. Any specific reason why external modules are not so
good for you?

hmm - IMO there's nothing wrong in external module, however i do not understand
why you guyz don't want it in official portage tree... this bug is the only
source of new loop-aes ebuilds..

because none of the developers here added it and took up maintainance, also no
one volunteered to maintain this pkg

I added it to portage now, thank you

nice to hear;>
there's one imperfection in that ebuild. loop-aes offers 'make tests', which should be done if one has 'maketest' in FEATURES. this ebuild skip that part, becouse those test needs loop module to be loaded. i didn't know what to do if user has already older version loaded. should portage try to unload it first? (well - but what if module is in use?) or maybe tests should fail in such situations? (but then they'll almost always fails, which certainly isn't good solution). 
if you got any idea how to fix that, let me know and i'll add tests (or do it by your own if you like)