The sandbox package is no longer present on my system. I installed sandbox-2.2 before as required by libtool (see bug http://bugs.gentoo.org/show_bug.cgi?id=293758) glibc requires sandbox-1.6-r2. portage complained about a version clash. I removed sandbox-2.2 manually and I am not able to remerge sandbox-1.6-r2 since. I do not know whats wrong. But I already complained about the "test"-suite! Just problems with it. I have removed all CFLAG-options, I have issued "FEATURE=-sandbox emerge sandbox" I have issued "RESTRICT=test FEATURE=-sandbox emerge sandbox" No change. Reproducible: Always Steps to Reproduce: emerge sandbox Actual Results: Failed to emerge sys-apps/sandbox-1.6-r2, Log file: >>> '/var/tmp/portage/sys-apps/sandbox-1.6-r2/temp/build.log' * Messages for package sys-apps/sandbox-1.6-r2: * ERROR: sys-apps/sandbox-1.6-r2 failed: * make check failed for x86 * * Call stack: * ebuild.sh, line 54: Called src_test * environment, line 2728: Called die * The specific snippet of code: * emake check || die "make check failed for ${ABI}"; Expected Results: installation of sandbox emerge --info =sys-apps/sandbox-1.6-r2 Portage 2.1.7.16 (default/linux/amd64/10.0/developer, gcc-4.3.4, glibc-2.9_p20081201-r2, 2.6.31-gentoo-r6 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.31-gentoo-r6-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_3800+-with-gentoo-1.12.13 Timestamp of tree: Thu, 25 Feb 2010 19:30:01 +0000 app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.5.4-r3, 2.6.4 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.1.2, 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests collision-protect cvs digest distlocks fixpackages multilib-strict news parallel-fetch protect-owned sfperms sign splitdebug strict test unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 apache2 avi berkdb bluetooth bzip2 cairo cdr cli consolekit cracklib crypt cups cxx dbus dlloader dri dts dv dvb dvd dvdr eds emboss encode evo fam firefox flac fortran gdbm gif gnome gpm gstreamer gtk gtk2 hal iconv ieee1394 input_device_evdev input_device_keyboard input_device_mouse ipv6 jpeg jpeg2k kde ldap libnotify live mad matroska midi mikmod mmx mng modules mp3 mp4 mpeg mudflap multilib mysql ncurses nls nptl nptlonly nvidia ogg oggvorbis opengl openmp pam pcre pdf perl png ppds pppd python qt qt3support qt4 quicktime readline reflection sdl session snmp spell spl sse sse2 ssl startup-notification svg sysfs tcpd theora thunar tiff truetype truetype-fonts unicode usb vorbis x264 xanim xml xorg xulrunner xv xvid yv12 zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" FOO2ZJS_DEVICES="hp2600n" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeonhd" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
You need to attach this... /var/tmp/portage/sys-apps/sandbox-1.6-r2/temp/build.log as told by the error message (which you have stripped of all important parts when pasting here)
(And when it fails on tests then you need to do USE="-test" FEATURES="-test", not to mess with RESTRICT.
(In reply to comment #2) > (And when it fails on tests then you need to do USE="-test" FEATURES="-test", > not to mess with RESTRICT. > The FEATURES="-test" command did the trick. However, I consider this bug not as resolved, as it is not clear why it happened. As soon as I have glibc recompiled, I shall recompile sandbox again and I shall post the build log. It would be good, if there would be fields in the bug-report form that encourage to post all that stuff. Where do I report this request to? Anyway. Thank you for your quick answer.
(In reply to comment #3) > It would be good, if there would be fields in the bug-report form that > encourage to post all that stuff. Where do I report this request to? Well, please read the *entire* message that you get on failed emerge. It does encourage you to post that stuff and even point to exact locations of the files in question. You have just snipped it, as already noted. Sure, the failing test are not resolved :)
I have read the entire message. In many cases build-logs are not included and I presumed (wrongly) that someone would have immediately a clue. Nevertheless, there are no fields in the bug report where build-logs and other lengthy system messages are orderly entered and stored. Back to the important stuff. I had to uninstall sandbox before getting the error-message again. > (In reply to comment #3) > > It would be good, if there would be fields in the bug-report form that > > encourage to post all that stuff. Where do I report this request to? > > Well, please read the *entire* message that you get on failed emerge. It does > encourage you to post that stuff and even point to exact locations of the files > in question. You have just snipped it, as already noted. > > Sure, the failing test are not resolved :) >
Created attachment 221877 [details] The build-log
Created attachment 221879 [details] The environment file
So it mentions something about makedir. There is enough space... no reason to fail makedir. # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 155737320 141426648 14310672 91% / udev 10240 152 10088 2% /dev shm 512616 0 512616 0% /dev/shm (In reply to comment #6) > Created an attachment (id=221877) [details] > The build-log >
(In reply to comment #5) > I have read the entire message. In many cases build-logs are not included and I > presumed (wrongly) that someone would have immediately a clue. Nevertheless, > there are no fields in the bug report where build-logs and other lengthy system > messages are orderly entered and stored. What stops you from creating attachments after creating the bug? And your build.log clearly talks about tests/testsuite.log, so please attach that one too
> What stops you from creating attachments after creating the bug? Flooding the bug-report and digging up files from deep in my var directory. As a constructive suggestion, in case of a bug, a "bug" directory should be created where all messages are orderly stored. At the moment messages are stored in obscure places, so that developers can bash users if they file a bug report, for being dumb in one or the other way. Especially the hidden allegation: You haven't even read the bug report: > And your build.log clearly talks about tests/testsuite.log, so please attach > that one too No it does not! It sais Please send `tests/testsuite.log' and all information you think might help: To: <sandbox@gentoo.org> Subject: [sandbox 1.6] testsuite: 8 11 failed I am clearly not sending any message to sandbox@gentoo.org. On the contrary: It merely states * If you need support, post the output of 'emerge --info =sys-apps/sandbox-1.6-r2', * the complete build log and the output of 'emerge -pqv =sys-apps/sandbox-1.6-r2'. So you kindly ask me to additionally send the testsuite.log. Here it comes.
Created attachment 223411 [details] testsuite.log
your removal of sandbox is what is screwing things up. no bug has ever said you should remove this package. install sandbox w/FEATURES=-test and then it should work fine the second time.
(In reply to comment #12) > your removal of sandbox is what is screwing things up. no bug has ever said > you should remove this package. install sandbox w/FEATURES=-test and then it > should work fine the second time Thank you for your comment. The test-suite did not report any sandbox features missing. How do you infer your opinion?
(In reply to comment #13) > (In reply to comment #12) > > your removal of sandbox is what is screwing things up. no bug has ever said > > you should remove this package. install sandbox w/FEATURES=-test and then it > > should work fine the second time > > Thank you for your comment. The test-suite did not report any sandbox features > missing. How do you infer your opinion? > I correct myself. The test-suite did report sandbox features missing, but said, it would ignore it. One error was: PASS: mkdir("root/aksdfjasdfjaskdfjasdfla", 777) = -1 (wanted -1); errno = 13 [Permission denied] (wanted 0 [Success]) ../../sandbox-1.6/tests/mkdir.at:3: exit code was 1, expected 0 11. mkdir.at:3: 11. mkdir/3 (mkdir.at:3): FAILED (mkdir.at:3) In this case, the permission was denied. I wonder where "root/aksdfjasdfjaskdfjasdfla" is to be located; hopefully not in my "root"-home directory. (I always name temporary directories like asdjfkasdjkfdjfk ;) But you might be right: Self-reference is a point that is commonly overlooked. If the reason is, that sandbox needs to be installed to install sandbox then this is a circular reference and should not occur. I am afraid that turning off tests, is against the spirit for what these tests are.
why do you think the bug is still open ? it'll be fixed at some point, but removing sandbox from your system is still an error on your part.
(In reply to comment #15) > why do you think the bug is still open ? it'll be fixed at some point, but > removing sandbox from your system is still an error on your part. > Because it has not been fixed. Your suggestion, installing sandbox with FEATURES=-test is a makeshift, not a solution. I have the feeling, that you are very concerned with, whose error this bug is. Gentoo has a very messed up package tree --- and not only sometimes and not only on amd64 architecture. It is fair to blame people, if gentoo's dependency tree would be in order, but on the contrary, it forces users to manually delete system-packages to get their system back on track. I have been using gentoo for a long time now and I am a devoted user, but at some point enough is enough. This testing business brings up even more errors and those people responsible for testing, dismiss a failed test by trying to put the blame on the bearer of the bad news, instead of setting things right.
no one said that was a solution. i gave you a simple workaround so you could continue on your way and not be blocked in general, and so you could give feedback that the hypothesis was correct. i dont think you ever actually said what the result was, you just made an obvious point that no one was contesting. further, you're the one closing the bug here, not i. i'm leaving it open so that when i get around to it, it can be fixed properly. so unless you have something useful to contribute, take your complaining elsewhere and wait for the bug to be fixed properly.
(In reply to comment #17) > why do you think the bug is still open ? it'll be fixed at some point, Oh I took it that you will deal with it at a later point. I hought that this is what LATER stands for: > LATER The bug will be dealt with at a later date. > i dont think you ever actually said what the result was, I quote Comment #3: > The FEATURES="-test" command did the trick. Which was acknowledged in Comment #4 > Sure, the failing test are not resolved :) > so unless you have something useful to contribute, take your complaining elsewhere and wait for the bug to be fixed properly. I have to contribute something useful and this is how bugs are dealt with: Take your blaming elsewhere and get professional!
some people may want to use LATER, but i'm not inclined to as it's a synonymous with "i'm going to ignore it forever" read the comments again. you screwed up your system when you removed sandbox. that is a simple fact. i never "blamed" you for anything else.
sandbox-2.3 passes tests even if sandbox isnt installed, or if and older sandbox (like 1.6) is installed. no plans on fixing older versions as we'll just stabilize a newer one.
