Using of stable cryptsetup-luks-1.0.1-r1 with stable device-mapper-1.02.02 causes the following: $cryptsetup create crypt_N /dev/hdaN Command failed: Invalid argument while cryptsetup-luks-1.0.3 (~amd64) works properly. $emerge --info Portage 2.0.54-r2 (default-linux/amd64/2005.1, gcc-3.4.5, glibc-2.3.6-r3, 2.6.16-gentoo-r7 x86_64) ================================================================= System uname: 2.6.16-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O3 -fomit-frame-pointer -fforce-addr -ftracer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O3 -fomit-frame-pointer -fforce-addr -ftracer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa arts audiofile avi berkdb bitmap-fonts bzip2 cdr cli crypt cups curl dga doc dri dvd dvdr eds emboss encode esd ethereal expat fam foomaticdb fortran gd gdbm gif gpm gstreamer gtk2 guile hal idn imagemagick imlib ipv6 isdnlog java jpeg kde kdeenablefinal lcms ldap libwww lzw lzw-tiff mad mhash mng motif mp3 mpeg ncurses nls nvidia ogg opengl pam pcre pdf pdflib perl png pppd python qt quicktime readline reflection ruby scanner sdl session spell spl ssl tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis xml2 xorg xpm xv zlib userland_GNU kernel_linux elibc_glibc" Unset: CTARGET, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS, PORTDIR_OVERLAY
This is more a question of stabilization then anything else. Both the newer version of cryptsetup-luks (1.0.3) and the revised older one (1.0.1-r2) have solved this problem but some arches didn't stabilize it. The problem is fixed though.
*** Bug 134729 has been marked as a duplicate of this bug. ***
The current stable version doesn't seem much useful; I'm recycling this bug to request stabilization of a newer version as I didn't find any keywording bug open for this. Not sure if you prefer 1.0.1-r2 or 1.0.3, so please change the summary accordingly and CC arches then. Thanks.
I'm going to close this one again sorry. The "latest" version of cryptsetup-luks has an issue with selinux (hopefully will have a new one in the tree today) and the one prior to that is quite outdated. As it stands I hope to have a new and completely bug free 1.0,.3-r1 into the tree today, but then in theory it should sit for 4 weeks before I file for stabilization. Realistically I'm not sure whats best here, though I personally tend towards a quick stabilization for the new 1.0.3-r1, but in any case I'll open a new bug for it.
(In reply to comment #4) > As it stands I hope to > have a new and completely bug free 1.0,.3-r1 into the tree today, but then in > theory it should sit for 4 weeks before I file for stabilization. Realistically > I'm not sure whats best here, though I personally tend towards a quick > stabilization for the new 1.0.3-r1, but in any case I'll open a new bug for it. Well, the selinux stuff really affects a very small minority of users, so... I'd rather see this stabilized sooner than later, keeping the breakage for one more month is not so optimal solution, IMHO. :) Thanks anyway.
Reopening this per Halcy0n's request... We really need something actually working marked stable, selinux or not. IMHO, the current stable can't work on selinux either.
well since my last comment i have a new version in the tree that should be fine for selinux users as well. look to stabilise cryptsetup-luks-1.0.3-r2.ebuild
cryptsetup-luks-1.0.3-r2 stable on ppc64
works fine on x86 w/ gcc-4.1.1/glibc-2.4/portage-2.1/baselayout-1.12.1
Stable on ppc.
(In reply to comment #9) > works fine on x86 w/ gcc-4.1.1/glibc-2.4/portage-2.1/baselayout-1.12.1 > This information isn't of much use as we are talking about stabilization here that has to be done on a all stable system.
mmh but we are still missing the x86 stable the last 4 weeks
point us out why don't you ^.^;; x86 stable.
(In reply to comment #11) > (In reply to comment #9) > > works fine on x86 w/ gcc-4.1.1/glibc-2.4/portage-2.1/baselayout-1.12.1 > > > > This information isn't of much use as we are talking about stabilization here > that has to be done on a all stable system. It is very useful to release engineering... ;]
sparc stable.
stable on amd64 finally... we rock you this time!
