Summary: | quickpkg turns hard linked files into empty files | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hodur <coil93> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | adam.walker, defuebr, frank.wegener, gentoo, jer, monkeh, remy, rogerx.oss, youshisan |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 185305, 359193 | ||
Bug Blocks: | 349307 | ||
Attachments: | Checks for zero byte files and attempts to lists or reinstalls as requested. |
Description
Hodur
2010-09-23 23:13:58 UTC
And what if you ran `gcc-config 1' after merging it? (In reply to comment #1) > And what if you ran `gcc-config 1' after merging it? > > g++ gcc-config: error: could not run/locate 'g++' > gcc-config 1 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.4 ... [ ok ] > g++ gcc-config: error: could not run/locate 'g++' You forgot to source /etc/profile. astrid ~ # gcc-config 2
* Switching cross-compiler to hppa2.0-unknown-linux-gnu-4.4.3 ...
>>> Regenerating /etc/ld.so.cache... [ ok ]
* If you intend to use the gcc from the new profile in an already
* running shell, please remember to do:
* # source /etc/profile
Using the same version of gcc-config, I get the above output. How come yours didn't show up?
This is pretty useless IMHO, because /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.4/x86_64-pc-linux-gnu-g++ is just empty file in gcc package > gcc-config 1 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.4 ... [ ok ] > source /etc/profile > g++ gcc-config: error: could not run/locate 'g++' > file /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.4/x86_64-pc-linux-gnu-g++ /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.4/x86_64-pc-linux-gnu-g++: empty ive seen this on my systems before too. but i dont see how it's a gcc problem. maybe a tar issue, but probably a quickpkg. probably related to the fact that the g++ binary is a hardlink to the c++ binary. $ PKGDIR=$PWD/pkg quickpkg sys-devel/gcc $ tar tvf pkg/sys-devel/gcc-4.4.3-r2.tbz2 | grep 'gnu-[gc]++$' | grep -v ^l -rwxr-xr-x root/root 246944 2010-05-26 15:14 usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/x86_64-pc-linux-gnu-c++ -rwxr-xr-x root/root 0 2010-05-26 15:14 usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/x86_64-pc-linux-gnu-g++ I wasn't able to reproduce this using either python-2.6.5-r2 or python-3.1.2-r3, and using tar-1.23-r2 for extraction. We do have a workaround for bug #185305 which breaks hardlinks, so hardlinks are supposed to be treated like any other files. I've run into this exact problem as well where quickpkg created the file "x86_64-pc-linux-gnu-g++" as zero bytes long. I recently took the list of packages created by executing: emerge -pet @world > world.text and manipulated it in to a final list where I could execute: cat final_list.text | xargs quickpkg --include-config=y I create 1891 packages this way. I'm currently looking for other files which were created at zero bytes. If I find any, I will report them. Not understanding that the zero length byte file was my problem in gcc, I requested some help here: http://forums.gentoo.org/viewtopic-t-850342-highlight-.html. With the number of things I tried conbined with google, I managed to finally find this reported bug. Thanks all. This is just a guess based upon ancient behavioral experience with 'tar'. Someone {definitely not me} may want to check the treatment of files which end in '++' when 'tar' is invoked through python in the quickpkg script. Depending on the shell and python interactions and the meta-character expansion of tar, the actual behavior may not be the expected behavior. I _know_ this is way over my head. Just saying. same with sys-apps/util-linux: -rwxr-xr-x 1 root root 0 Oct 20 17:57 /sbin/fsck.ext2 -rwxr-xr-x 1 root root 0 Oct 20 17:57 /sbin/fsck.ext3 -rwxr-xr-x 1 root root 0 Oct 20 17:57 /sbin/fsck.ext4 -rwxr-xr-x 1 root root 0 Oct 20 17:57 /sbin/fsck.ext4dev *** Bug 347778 has been marked as a duplicate of this bug. *** i doubt the file name is relevant. the c++ binary works fine. the e2fsprogs package is much nicer to test with considering gcc-4.5.1-r1 turns into a 150MiB bz2 file ;). looking at `quickpkg`, it doesnt execute `tar` anywhere. it uses the tarfile module (for both tar and bzip2). so version of `tar` on host when creating doesnt matter. as for extraction, just view the contents: tar tvvf e2fsprogs-1.41.12-r1.tbz2 | awk '$1 ~ /^-/ && $3 == "0"' e2fsprogs shows a bunch of errors all centering around files with hardlinks. reverting the workaround for Bug 185305 unbreaks quickpkg for me. i suspect this workaround was merely masking an error that existing in older python's tarfile.py implementations, so i wonder why it wasnt reported to the python people instead of hacking up quickpkg. the reporter at that time was using python-2.4.4 and the version of portage that he downgraded to was using the shell quickpkg which executed `tar | bzip2`. if you add debugging to tar_contents(), you'll see that tar.gettarinfo is returning an object which says size == 0 (with linkname set to the file the thing is hardlinked to). so i wouldnt be surprised if the following call to tar.addfile() with the type forced to REGTYPE causes the tarfile.py module to not output anything. thus i suggest we revert the change added to Bug 185305 and if/when that issue comes up again, it can be researched properly and the actual bug located/fixed. (In reply to comment #12) > thus i suggest we revert the change added to Bug 185305 and if/when that issue > comes up again, it can be researched properly and the actual bug located/fixed. Done: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4c47e5857515ea69150fb1d7731e4a6c88b4476e This is fixed in 2.2.0_alpha8, but I'll leave this bug open until it's in an unmasked release. This is fixed in 2.1.9.6. (In reply to comment #15) > This is fixed in 2.1.9.6. I meant 2.1.9.26. Created attachment 259662 [details]
Checks for zero byte files and attempts to lists or reinstalls as requested.
Checks for zero byte files and attempts to lists or reinstalls as requested.
Don't know if anybody else has scripted anything as of yet for this bug, but feel free to suit this sh/bash script for your needs.
*** Bug 354697 has been marked as a duplicate of this bug. *** *** Bug 354697 has been marked as a duplicate of this bug. *** |