Summary: | sys-apps/grep 2.13 reports non-binary files as binary files | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mads <mads> |
Component: | [OLD] Core system | Assignee: | Richard Yao (RETIRED) <ryao> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | bug, carlphilippreh, Dessa, jcallen, kernel, matrix47, prefix |
Priority: | Low | Keywords: | Bug, Goal |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/zfsonlinux/zfs/issues/829 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 436692 | ||
Attachments: |
ebuild /usr/portage/sys-devel/gcc/gcc-4.7.1.ebuild unpack --debug
Patch that reverts the new behaviour in grep that makes spares file be parsed as binary |
Description
Mads
2012-07-10 13:11:32 UTC
Created attachment 317782 [details]
ebuild /usr/portage/sys-devel/gcc/gcc-4.7.1.ebuild unpack --debug
You can see an example of this message in this emerge log in line 39332-39335:
+++ grep -e '^[[:space:]]*VERSION=' /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/ltmain.sh
++ eval Binary file /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/ltmain.sh matches
+++ Binary file /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/ltmain.sh matches
/var/tmp/portage/sys-devel/gcc-4.7.1/temp/environment: line 238: Binary: command not found
Workaround is to downgrade to grep-2.12. Could you attach i.e. that /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/ltmain.sh from the *failed* build ? grep -e '^[[:space:]]*VERSION=' /usr/share/libtool/config/ltmain.sh seems to work correctly with grep 2.13. I think I tested that too, running that command standalone and getting it to work. I think it might be related to environment variables or maybe some weird race condition.... I'll recreate the environment tomorrow to see what happens both standalone and in the build. Installed grep 2.13 again: # locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=nb_NO.UTF-8 LC_TIME=nb_NO.UTF-8 LC_COLLATE=nb_NO.UTF-8 LC_MONETARY=nb_NO.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=nb_NO.UTF-8 LC_NAME=nb_NO.UTF-8 LC_ADDRESS=nb_NO.UTF-8 LC_TELEPHONE=nb_NO.UTF-8 LC_MEASUREMENT=nb_NO.UTF-8 LC_IDENTIFICATION=nb_NO.UTF-8 LC_ALL= # grep -e '^[[:space:]]*VERSION=' /usr/share/libtool/config/ltmain.sh VERSION=2.4.2 # LC_ALL=C grep -e '^[[:space:]]*VERSION=' /usr/share/libtool/config/ltmain.sh VERSION=2.4.2 ebuild /usr/portage/sys-devel/gcc/gcc-4.7.1.ebuild unpack ... output ... * updating multilib directories to be: ../lib64 ../lib32 * Running elibtoolize in: gcc-4.7.1/ * Applying portage/2.2 patch ... /var/tmp/portage/sys-devel/gcc-4.7.1/temp/environment: line 221: Binary: command not found * Applying sed/1.5.6 patch ... * Applying as-needed/2.2.6 patch ... * Using GNU config files from /usr/share/gnuconfig So it only happens during special circumstances. This is the same error appearing in that long debug-log I pasted earlier. Any chance it's a filesystem issue ? That is in regard of what filesystem your WORKDIR uses (or perhaps sparse files). That might be a valid hypothesis, yes.. It happened on a zfs file system. Though, it is consistent that it happens with 2.13 and not with 2.12... Could try it with tmpfs later today and see what happens. I was bitten by this today too. I have just started to install a server with ZFS and glib was refusing to compile because the version script had been garbled by grep. I put /var/tmp/portage on a tmpfs and all of a sudden it worked again. So, the change http://git.savannah.gnu.org/cgit/grep.git/commit/?id=582cdfacf297181c2c5ffec83fd8a3c0f6562fc6 seems to be not quite correct for zfs. Does anyone see why ? Would you try reverting the following commit when building grep? It looks like it might cause this. http://git.savannah.gnu.org/cgit/grep.git/commit/?id=582cdfacf297181c2c5ffec83fd8a3c0f6562fc6(In reply to comment #9) > So, the change > http://git.savannah.gnu.org/cgit/grep.git/commit/ > ?id=582cdfacf297181c2c5ffec83fd8a3c0f6562fc6 seems to be not quite correct > for zfs. > > Does anyone see why ? Have you confirmed that reverting that change makes this problem go away? I can confirm that reverting that change makes the problem go away. I tried it today and glib that before failed for me due to grep worked without any problems. Created attachment 318106 [details, diff]
Patch that reverts the new behaviour in grep that makes spares file be parsed as binary
This patch reverts the commit that added the new behaviour for grep. However the issue seem to lie in how ZFS reports it's metadata or something because as far as I know this issue doesn't come up with other filesystems like ext*, xfs or tmpfs
This is a bug in the ZFS POSIX Layer. I have filed an upstream bug and I am reassigning it to myself, with base-system on CC. that seems to apply to older btrfs implementations as well, kernel 3.4 works fine, 3.1 does not, didn't test intermediate versions, though. (In reply to comment #14) > that seems to apply to older btrfs implementations as well, kernel 3.4 works > fine, 3.1 does not, didn't test intermediate versions, though. What are the exact version numbers that you tested? (In reply to comment #15) > What are the exact version numbers that you tested? 3.1.5-gentoo and 3.4.4-gentoo (In reply to comment #16) > (In reply to comment #15) > > What are the exact version numbers that you tested? > > 3.1.5-gentoo and 3.4.4-gentoo My time to work on this is currently rather limited. It would help me greatly if someone would test sys-kernel/gentoo-sources-3.2.1-r2 and sys-kernel/gentoo-sources-3.2.21 to see if btrfs is affected there. The btrfs fix will need to be backported once it is identified, so I am CCing the kernel team on this. unless i missed something, this isn't a bug in grep ... *** Bug 428000 has been marked as a duplicate of this bug. *** (In reply to comment #19) > unless i missed something, this isn't a bug in grep ... This one bites me too. http://lists.gnu.org/archive/html/bug-grep/2012-07/msg00016.html http://git.savannah.gnu.org/cgit/grep.git/commit/?id=2f0255e9f4cc5cc8bd619d1f217902eb29b30bc2 Can we get a backport, please? I have been hit by this when installing dev-texlive/texlive-fontsextra. My filesystem is btrfs, running on vanilla-sources-3.5.0. *** Bug 429924 has been marked as a duplicate of this bug. *** (In reply to comment #22) > I have been hit by this when installing dev-texlive/texlive-fontsextra. > My filesystem is btrfs, running on vanilla-sources-3.5.0. Does the following patch fix it for you? http://git.savannah.gnu.org/cgit/grep.git/commit/?id=2f0255e9f4cc5cc8bd619d1f217902eb29b30bc2 (In reply to comment #24) > (In reply to comment #22) > > I have been hit by this when installing dev-texlive/texlive-fontsextra. > > My filesystem is btrfs, running on vanilla-sources-3.5.0. > > Does the following patch fix it for you? > > http://git.savannah.gnu.org/cgit/grep.git/commit/ > ?id=2f0255e9f4cc5cc8bd619d1f217902eb29b30bc2 I applied the patch on top of grep-2.13, but it didn't fix the problem. grep-2.12 is fine. (In reply to comment #25) grep-2.14 is in the tree. please verify that fixes things. (In reply to comment #26) > (In reply to comment #25) > > grep-2.14 is in the tree. please verify that fixes things. Thanks for posting in the bug. I had some fairly high priority things to do offline that caused me to neglect this until now. With that said, ZFSOnLinux upstream and numerous people in IRC have verified that grep 2.14 fixes this issue. That implies that this is a regression in sys-apps/grep-2.13. https://github.com/zfsonlinux/zfs/issues/829 =sys-apps/grep-2.13 is now masked in tree. |