If app-arch/pigz[symlink] has been emerged, then: Cracklib fails to update/generate cracklib_dict.{hmw,pwm,pwi} using the dict files : ---------------------------------------------------- root@host # /usr/sbin/create-cracklib-dict /usr/share/dict/* /usr/share/dict/connectives does not have compressed suffix -- skipping /usr/share/dict/cracklib-small does not have compressed suffix -- skipping /usr/share/dict/cracklib-words does not have compressed suffix -- skipping <snip> root@host # ls -1hs /usr/lib/cracklib_dict.* ls: cannot access /usr/lib/crack*: No such file or directory ---------------------------------------------------- Tracking this issue in the cracklib scripts chains leads to the shell script /usr/sbin/cracklib-format, which is (comments stripped) : ---------------------------------------------------- #!/bin/sh gzip -cdf "$@" | grep -v '^\(#\|$\)' | tr '[A-Z]' '[a-z]' | tr -cd '\012[a-z][0-9]' | sort -u ---------------------------------------------------- The symlink /usr/bin/gzip -> /usr/bin/pigz cause pigz to be called instead of /bin/gunzip. However pigz should not be called with "-d" in its arguments to decompress files from the command line. Then it doesn't extract anything and emit the warning "XYZ does not have compressed suffix -- skipping" This sounds pretty serious to me, as this bug may potentially render cracklib unusable, and thus (encountered on my system) make any password change impossible if sys-app/shadow has been emerged with USE=cracklib. As adapting cracklib to pigz doesn't sounds like a good option, I would suggest to simply sed 's:gzip:/bin/&:' in cracklib-format in the ebuild before installing it. Thus the user can have pigz[symlink] installed and still use cracklib. Reproducible: Always Steps to Reproduce: 1. USE="symlink" emerge pigz 2. USE="cracklib" emerge -1 shadow 3. /usr/sbin/create-cracklib-dict /usr/share/dict/* 4. ls -1hs /usr/lib/cracklib_dict.* Actual Results: See above Expected Results: 4,0K /usr/lib/cracklib_dict.hwm 7,7M /usr/lib/cracklib_dict.pwd 428K /usr/lib/cracklib_dict.pwi (size depending on actual size of installed word files)
Thanks for reporting this incompatibility. It seems to me that if pigz installs itself as a gzip replacement, it ought to be compatible with all the gzip options, and -d in particular is not even uncommon. So, I think this is a pigz bug, and will assign it accordingly...
Somehow the problem is in this seious: emerge pigz[symlink] emerge cracklib passwd foo But solved here: emerge cracklib emerge pigz[symlink] passwd foo
base-system, please prefix gzip with full path.
no idea wtf you're talking about
as the OP says, /usr/sbin/cracklib-format calls gzip without full path which breaks if pigz is emerge with USE=symlink. The best solution is calling gzip with full path. alternative is restricting the pigz to USE=-symlink during emerge of cracklib.
so you want cracklib to execute /bin/gzip because some random package installs itself as `gzip` and breaks other random packages ? that isnt going to happen. app-arch/pigz[symlink] doesnt make any sense. remove it.
Just came across this bug myself. Why is app-arch/pigz-2.16[symlink] still in stable when installing it breaks portage for any file where the source is *.gz (including itself and gzip)?
(In reply to comment #7) > Just came across this bug myself. Why is app-arch/pigz-2.16[symlink] still in > stable when installing it breaks portage for any file where the source is *.gz > (including itself and gzip)? > For me it woks well for nomal portage operations. Only the cracklib thiing is bad. This happens because during that operation gzip is take from /us/bin and not fom /bin, whihc results in the use of pigz and not gzip
(In reply to comment #8) > (In reply to comment #7) > > Just came across this bug myself. Why is app-arch/pigz-2.16[symlink] still in > > stable when installing it breaks portage for any file where the source is *.gz > > (including itself and gzip)? > > > > For me it woks well for nomal portage operations. Only the cracklib thiing is > bad. This happens because during that operation gzip is take from /us/bin and > not fom /bin, whihc results in the use of pigz and not gzip Again encoutered this bug with cracklib, without having any other problem with portage or other package. Is there any move gentoo side, or has pigz-mainstream been advised of this gzip compliance fail?
This is fixed in pigz-2.1.6-r1, see bug #335852. I suggest stabilizing pigz-2.1.6-r1, it has been a while since it was introduced. # echo aa | pigz -c > aa.gz # pigz -cd aa.gz aa
Although the issue here seems to be with the suffix - that's not fixed yet in unstable pigz (see my suggestion in the bug above).
This should be fixed with pigz-2.1.7. Please test and reopen if needed. Thanks.
