pigz is not threating the -c option as gzip, whenever it fails to create the archive in non-interactive shell. bluefish is using gzip in some makefiles, so if pigz is used as replacement for gzip (symlink), the ebuild can't compile. To fix the ebuild just add: > src_prepare() { > sed -i 's:gzip:/bin/gzip:' data/bflib/Makefile.* || die "Cannot fix makefile" > } Thus won't use anymore the "symlink" to gzip, but /bin/gzip. >>> Source configured. >>> Compiling source in /var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2 ... make -j3 Making all in data make[1]: Entering directory `/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2/data' Making all in bflang make[2]: Entering directory `/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2/data/bflang' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2/data/bflang' Making all in bflib make[2]: Entering directory `/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2/data/bflib' gzip bflib_css2.xml -c > bflib_css2.xml.gz gzip bflib_dom.xml -c > bflib_dom.xml.gz gzip bflib_php4.xml -c > bflib_php4.xml.gz gzip: gzip: abort: write error on bflib_dom.xml.gz make[2]: *** [bflib_dom.xml.gz] Error 1 make[2]: *** Waiting for unfinished jobs.... abort: write error on bflib_css2.xml.gz make[2]: *** [bflib_css2.xml.gz] Error 1 gzip: abort: write error on bflib_php4.xml.gz make[2]: *** [bflib_php4.xml.gz] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2/data/bflib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2/data' make: *** [all-recursive] Error 1 * ERROR: app-editors/bluefish-2.2.2 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=app-editors/bluefish-2.2.2'`, * the complete build log and the output of `emerge -pqv '=app-editors/bluefish-2.2.2'`. * The complete build log is located at '/var/tmp/portage/app-editors/bluefish-2.2.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-editors/bluefish-2.2.2/temp/environment'. * Working directory: '/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2' * S: '/var/tmp/portage/app-editors/bluefish-2.2.2/work/bluefish-2.2.2' >>> Failed to emerge app-editors/bluefish-2.2.2, Log file: >>> '/var/tmp/portage/app-editors/bluefish-2.2.2/temp/build.log'
Is this still needed for app-editors/bluefish-2.2.6 and app-arch/pigz-2.3.3?
Created attachment 396154 [details] build.log Yes it is, as pigz -c option is still not acting as its gzip counterpart # /bin/gzip -c test.txt a lot of noisy char in the current terminal # /usr/bin/pigz -c test.txt pigz: abort: trying to write compressed data to a terminal (use -f to force) # used as this it works # /usr/bin/pigz -c test.txt > test.txt.gz # -c option should be before filename else it is skipped # rm test.txt.gz # /usr/bin/pigz test.txt -c > test.txt.gz test.txt.gz exists -- overwrite (y/n)? When closing stdin as in portage # /usr/bin/pigz test.txt -c > test.txt.gz 0<&- pigz: abort: write error on bflib_css2.xml.gz Until here tests done with pigz 2.3.1-r1, now 2.3.3 # /usr/bin/pigz test.txt -c > test.txt.gz 0<&- pigz: abort: write error on bflib_css2.xml.gz (Inappropriate ioctl for device) Just an option parsing bug.
src_prepare() { sed -i 's:gzip $< -c:gzip -c $<:' data/bflib/Makefile.* || die "Cannot fix makefile" } this way it works using pigz
Is pigz upstream aware of this different behavior? Per http://zlib.net/pigz/ it should be a full replacement for gzip... while this shows it's not the case :(
Sorry, I thought I already relayed pigz dev comment about this behavior. I just wrote him yesterday as I forgot this bug since opened this thread. He already replied: > Thank you for your report. > > I consider this to be a feature, not a bug, and so I don't plan to "fix" it. > pigz arguments are processed in order with earlier options applied to later > files, in the manner of a series of instructions. This is more intuitive and > permits finer control of what pigz is to do with each file on the command > line. > Mark For two years now gzip is a symlink to pigz on my pc, this is the single behavior divergence I yet encountered.
I've posted an updated ebuild for version 2.2.7 of bluefish. This bug is addressed in it. One minor note is version 2.2.7 adds the "-n" flag to gzip, so the fix for that version is: src_prepare() { sed -i 's:gzip -n $< -c:gzip -n -c $<:' data/bflib/Makefile.* || die "Cannot fix makefile" } (I confirmed -n provides identical functionality in gzip & pigz.
Whoops, should add the bug number; fixed in: 555414
@amy, are you taking this package? In that case please update metadata as it still points to maintainer-needed Thanks
