emerge --emptytree failed and now I have broken system. I tryed 0.9.7j, 0.9.8b. Results are identical. I tryed to set MAKEOPTS to -j1 and result is the same. root # emerge -av openssl These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-libs/openssl-0.9.7j USE="zlib -bindist* -emacs -test" 0 kB Total size of downloads: 0 kB Would you like to merge these packages? [Yes/No] y >>> Emerging (1 of 1) dev-libs/openssl-0.9.7j to / >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking openssl-0.9.7j.tar.gz ;-) >>> Unpacking source... >>> Unpacking openssl-0.9.7j.tar.gz to /var/tmp/portage/openssl-0.9.7j/work * Applying openssl-0.9.7g-ppc64.patch ... [ ok ] * Applying openssl-0.9.7e-gentoo.patch ... [ ok ] * Applying openssl-0.9.7-hppa-fix-detection.patch ...[ ok ] * Applying openssl-0.9.7-alpha-default-gcc.patch ... [ ok ] * Applying openssl-0.9.7g-mem-clr-ptr-cast.patch ... [ ok ] * Applying openssl-0.9.7h-ABI-compat.patch ... [ ok ] * Applying openssl-0.9.7g-superh.patch ... [ ok ] * Applying openssl-0.9.7i-m68k.patch ... [ ok ] * Applying openssl-0.9.7g-amd64-fbsd.patch ... [ ok ] * Applying openssl-0.9.7j-doc-updates.patch ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j ... * Use configuration linux-pentium Reading /var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure: [======================> ] 56% done. (/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1): 1: : bashdb<0> quit Makefile is older than Makefile.org. Reconfigure the source tree (via './config' or 'perl Configure'), please. make: *** [Makefile] Error 1 !!! ERROR: dev-libs/openssl-0.9.7j failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile openssl-0.9.7j.ebuild, line 113: Called die !!! make all failed !!! If you need support, post the topmost build error, and the call stack if relevant.
Uhm, fix your system clock?
It seems to be (In reply to comment #1) > Uhm, fix your system clock? > It seems to be fine antonio ~ $ date Thu Jul 27 21:03:38 EEST 2006 Make file really was not touched (I checked it manually)
bug-wranglers@gentoo.org
(In reply to comment #3) > bug-wranglers@gentoo.org > Sorry, I do not understand.
you forgot `emerge info` do you use tmpfs or anything for your portage tempdir ? also, post the full log as an attachment, not just a snippet: emerge openssl >& log
Created attachment 93104 [details] emerge --info
(In reply to comment #5) > you forgot `emerge info` > Sorry :) > do you use tmpfs or anything for your portage tempdir ? > antonio ~ $ mount /dev/sda6 on / type reiserfs (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw) /dev/sda7 on /var type reiserfs (rw,noatime) /dev/sda8 on /tmp type reiserfs (rw,noatime,notail) /dev/sda9 on /home type reiserfs (rw) none on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw,devmode=0664,devgid=85) avfsd on /home/antonio/.avfs type fuse (rw,nosuid,nodev,user=antonio) > also, post the full log as an attachment, not just a snippet: > emerge openssl >& log > antonio # emerge -v openssl >& emerge-openssl.txt Reading /var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure: [======================> ] 56% done. (/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1): 1: : bashdb<0> quit I attached file emerge-openssl.txt
Created attachment 93105 [details] emerge-openssl.txt
you have something screwing up your bash: done. (/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1): 1: : bashdb<0> quit
(In reply to comment #9) > you have something screwing up your bash: > > done. > (/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1): > 1: : > bashdb<0> quit > You are right :) But my bash is ok. I attached Configure script. It contains some garbage in the beginning. It seems to me that this script was not generated correctly.
the Configure script is not generated, it's part of the tarball
Sorry for a long break. I was on vacation. You are right: Configure is a part of source tarball. Here is the beginning of this script: : eval 'exec perl -S $0 ${1+"$@"}' if $running_under_some_shell; ## ## Configure -- OpenSSL source tree configuration script ## ... and so on ... than I see to ebuild: ... <skip> ... src_compile() { ... <skip> ... local sslout=$(./gentoo.config) einfo "Use configuration ${sslout}" local config="Configure" [[ -z ${sslout} ]] && config="config" ./${config} \ ${sslout} \ ${confopts} \ --prefix=/usr \ --openssldir=/etc/ssl \ shared threads \ || die "Configure failed" ... <skip> ... I mean that ebuild executes perl script as bash script. IMHO this behaviour is unexpected because if I run gentoo.config from comand prompt it outputs nothing. But when emerge runs it, gentoo.config outputs linux-pentium. This is why I think that ebuild contains a bug.
yes, the script is funky, but it is correct the reason ./gentoo.config outputs stuff in the ebuild is it uses the CHOST env i'm telling you your bash is screwed up and you need to figure out why ... i dont know what this 'bashdb' stuff is, but it's a local problem on your machine
*** Bug 196156 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > i'm telling you your bash is screwed up and you need to figure out why ... i > dont know what this 'bashdb' stuff is, but it's a local problem on your machine Do `strings /bin/bash |grep bashdb' and you'll see _your_ machine knows about it something, too ;-) OK, so there are several bugs/problems: 1a. The bash ebuild is wrong, pointing to /usr/local/share/bashdb/bashdb-main.inc for the debugging stuff. 1b. The support for bash debugging is broken, since /usr/share/bashdb/* is not installed. 2. On my system (and apparently, on Antonio's), a standalone bashdb script (together with the /usr/local/share/bashdb/* files) was installed, which enabled the debugging support. 3. Portage (specifically, ebuild.sh) enables the debugging: $ grep extdebug /usr/lib/portage/bin/ebuild.sh shopt -s extdebug &> /dev/null No idea why the hell it's doing so (especially since, due to (1b), it wouldn't work on a pure Gentoo system); commenting it out lets the openssl ebuild proceed nicely here. 4. The openssl "Configure" script is broken. It's actually a perl script, but the perl interpreter is invoked in a non-standard way, trap'ping bash to the debug prompt. I don't understand what's wrong with the recommended by perldoc #!/usr/bin/env perl ??? Mind you, (1a), especially together with (3), makes a security issue, since files under /usr/local are typically paid less security attention to.
there is no security issue. if your system has problems with /usr/local, it's already screwed. blaming others for admin incompetence is incorrect. might as well claim /usr/local/bin being in default PATH is a security issue (spoiler alert: it isnt). if you read the man page for bash, you'll see clearly why the extdebug shell option is turned on and why it's a good thing. the openssl Configure script is not broken. it may be weird, sure, but it is perfectly valid. the bash ebuild does not do anything about bashdb. that is why the default bash configure script selects /usr/local/... i'll fix that. bash is not broken by not installing the bashdb stuff. bash itself includes no bashdb that is meant to be used as you're supposed to use bashdb.sf.net instead. optionally. tar the files you have in /usr/local/share/bashdb/ and post it as an attachment
(In reply to comment #16) > there is no security issue. if your system has problems with /usr/local, it's > already screwed. If nothing is screwed for sure, things like firewall are not needed. I have a couple systems with / and /usr mounted RO, while /usr/local - not. So an idea that emerge, running as the root user, may run something off /usr/local behind my back is not especially exciting. > blaming others for admin incompetence is incorrect. might as > well claim /usr/local/bin being in default PATH is a security issue (spoiler > alert: it isnt). I don't mind default settings. PATH is something which each one can define to his pleasure (and indeed, restricting it to /*bin/ and /usr/*bin/ for the root user is not unseen in the wild). However, when /usr/local/bin is forcefully added by a system-level script (emerge), this is an issue - so why it's there?! > if you read the man page for bash, you'll see clearly why the extdebug shell > option is turned on and why it's a good thing. I don't see which place in the bash man page you refer to. Please specify. All I can tell, however, it is OFF by default - on all Linux distributions I have access to: $ shopt extdebug extdebug off Again, it is ebuild.sh that sets it ON - and for no apparent reason. > the openssl Configure script is not broken. it may be weird, sure, but it is > perfectly valid. The fact is it's single one (out of thousands of other ebuilds) which causes this problem. Changing the perl invocation to #!/usr/bin/env perl fixes the problem. Do you have an explanation why the way it's done is needed? > the bash ebuild does not do anything about bashdb. that is why the default > bash configure script selects /usr/local/... i'll fix that. > > bash is not broken by not installing the bashdb stuff. bash itself includes no > bashdb that is meant to be used You're right. I stand corrected. > as you're supposed to use bashdb.sf.net > instead. optionally. Well, a bashdb ebuild (putting stuff under /usr/, of course) might be a good thing to add then. I recall installing bashdb manually because portage didn't have one... > tar the files you have in /usr/local/share/bashdb/ and post it as an attachment Hmm. Do you say if you install from bashdb.sf.net you cannot reproduce the bug?!
we're not talking about the default bash environment, so the settings there are not relevant. turning it on inside of the ebuild environment is needed even if it isnt apparent to you. read the section about what extdebug actually turns on under the shopt section and you'll see that the ebuild code takes advantage of the extra information that bash tracks. while on Gentoo systems env lives at /usr/bin/env, there is no requirement that every single system out there be this way. openssl is a cross-platform system and the people who wrote the build system deemed that the current trick of letting the active shell find perl via $PATH is more portable. personally i think using perl in a build system at all is stupid. perl blows. i just made a bashdb ebuild and added it to the tree and can reproduce the failure here. not sure why it's failing as the debug stuff should be be inherited by children processes, only subshells. this will fail as well: echo ':' > foo chmod a+rx foo ./foo
erm, that last statement should of course read "should not be inherited" ...
(In reply to comment #18) > turning it on inside of the ebuild environment is needed even if > it isnt apparent to you. I'll take your word for it ;-). Still, the other shopt call in ebuild.sh is documented, so this might be as well. My initial understanding was that all the debugging stuff is enabled only if the bashdb support files are in the place. > while on Gentoo systems env lives at /usr/bin/env, there is no requirement that > every single system out there be this way. openssl is a cross-platform system > and the people who wrote the build system deemed that the current trick of > letting the active shell find perl via $PATH is more portable. Perhaps. But why not patch it in the Gentoo ebuild? - given that extdebug is important for portage, is there another solution? > personally i > think using perl in a build system at all is stupid. Agreed ;-). > i just made a bashdb ebuild and added it to the tree Thanks! > and can reproduce the > failure here. not sure why it's failing as the debug stuff should not be > inherited by children processes, only subshells. this will fail as well: > echo ':' > foo > chmod a+rx foo > ./foo Well, isn't it the point - since the script does NOT begin with #!/bin/bash (or any other interpreter), it inherits the flag.
needs some more fiddling
*** Bug 224065 has been marked as a duplicate of this bug. ***
Arg i spend hours on a so old bug! On my system Configure just warn with a message like "can't open /dev/pty/8", openssl compiles, but install mess with directory (because of Configure) and crashes with: "cd: /var/tmp/portage/dev-libs/openssl-0.9.8g-r2/image//usr/share/man: no such file or directory" Is it possible to add at least a warning if bashdb is installed: "You should first unmerge bashdb before updating openssl" ???
(In reply to comment #23) > Is it possible to add at least a warning if bashdb is installed: > "You should first unmerge bashdb before updating openssl" ??? > That would be nice. I unmerged bashdb and the problem went away and I could continue with my update of world... This was with openssl-0.9.7g Ricky
*** Bug 254297 has been marked as a duplicate of this bug. ***
Problem still persists with openssl-0.9.8j and bashdb-4.0.0.2 on ~amd64. Unmerging bashdb allows openssl to emerge. Is this an issue with openssl or with bashdb? How can this issue be fixed? Only openssl exhibits this problem, so I am inclined to blame openssl, but then the question of whether this a Gentoo-only issue arises. Google implies Gentoo-only. Unfortunately openssl is updated fairly often, so unmerging bashdb each time is a bit painful.
*** Bug 264102 has been marked as a duplicate of this bug. ***
=dev-scheme/slib-3.1.5-r1 seems to be triggering this as well. I think I reproduced it twice here. >>> Installing (57 of 1788) dev-scheme/slib-3.1.5-r1 * bigloo not installed, not registering... * drscheme not installed, not registering... * elk not installed, not registering... * gambit not installed, not registering... * Registering slib with guile... debugger, release Copyright 2002, 2003, 2004, 2006, 2007, 2008 Rocky Bernstein This is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Bourne-Again Shell Debugger, release Copyright 2002, 2003, 2004, 2006, 2007, 2008 Rocky Bernstein This is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. debugger, release Copyright 2002, 2003, 2004, 2006, 2007, 2008 Rocky Bernstein This is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. (/usr/sbin/install_slib_for_guile:1): 1: guile -c "(use-modules (ice-9 slib)) (require 'new-catalog) (slib:report-version)" bashdb<(0)> bashdb<(1)> bashdb<(2)> bashdb<(3)> bashdb<(4)> bashdb<(5)> bashdb<(6)> bashdb<(7)> bashdb<(8)> bashdb<(9)> bashdb<(10)> bashdb<(11)> emerge -C app-shells/bashdb(-4.0.0.3) allows emerging slib without interaction.
then file a bug for dev-scheme/slib to have it use a proper shebang
*** Bug 239432 has been marked as a duplicate of this bug. ***
*** Bug 294817 has been marked as a duplicate of this bug. ***
