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 attachment 44187 [details] loop-aes-2.2d.ebuild
Created attachment 44188 [details, diff] 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 attachment 44937 [details] ebuild for new version
Created attachment 44939 [details, diff] 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 attachment 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)
