After upgrading udev to version 114, I wasn't able to compile HAL because during econf, it misses VOLUME-ID. I re-emerged udev, and noticed that the compiler output shows this: !!! dolib: extras/volume_id/lib/*.so* does not exist !!! dolib: extras/volume_id/lib/*.a does not exist Downgrading udev to 104-r3 solved the problem. Reproducible: Always Steps to Reproduce: 1.emerge =udev-114 2.emerge hal 3.
You are/were using broken, hardmasked bash *** This bug has been marked as a duplicate of bug 182860 ***
Created attachment 129787 [details] emerge --info -v
Since when is bash-3.2_p17 is buggy????
MAKEOPTS="-j1" emerge =udev-114 &> emerge.log Attach it here.
Created attachment 129799 [details] emerge output of "MAKEOPTS="-j1" emerge =udev-114 &> emerge.log" Here you go.
Well, there's something seriously broken with your system, not udev...
Created attachment 129802 [details] proper emerge =udev114 output This is what it should look like - you are missing about half of the udev stuff.
Now udev-114 and udev-115 ebuilds will abort if installation of libvolume_id fails. This does not get us further to a soltion, but just prevents broken udev installs.
*** Bug 191249 has been marked as a duplicate of this bug. ***
Blowing up doesn't solve the problem. Please just DEPEND="dev-libs/volume_id" ... this seems to fix everything from a user perspective. udev and hal both merge fine afterwards..
(In reply to comment #10) > Blowing up doesn't solve the problem. Please just DEPEND="dev-libs/volume_id" Uh; dev-libs/volume_id is for BSD *only*, udev provides this on GNU userland. Unmerge the package and don't install nonsensical stuff.
people installing libvolume_id is what's causing the second hand bug of udev not installing libvolume_id because now there's a file collision.
@base-system - if you have any ideas why make screws here... Not udev-114 specific either, see bug 182860 and the duplicates there.
make isnt some mysterious thing ... if you fail to set EXTRAS in the make, you'd obviously get the behavior seen by Pablo
(In reply to comment #14) > make isnt some mysterious thing ... if you fail to set EXTRAS in the make, > you'd obviously get the behavior seen by Pablo Huh? Fail to set exactly how?
No idea why this should fail. The code has no conditional pathes that could fail setting EXTRAS for make. Relevant parts of ebuild: pkg_setup() { extras="... extras/volume_id \ ..." } src_compile() { emake \ EXTRAS="${extras}" \ libudevdir=${udev_helper_dir} \ CROSS_COMPILE=${mycross} \ OPTFLAGS="" \ ${myconf} || die } src_install() { emake \ DESTDIR="${D}" \ libudevdir=${udev_helper_dir} \ EXTRAS="${extras}" \ ${myconf} \ install || die }
(In reply to comment #14) > make isnt some mysterious thing ... if you fail to set EXTRAS in the make, > you'd obviously get the behavior seen by Pablo > Why would that be so? Downgrading udev to 104-r13 solved my problems. I've now masked udev-114 for the time being.
*** Bug 191945 has been marked as a duplicate of this bug. ***
CCing base-system back; would really love to see some real answer to Comment #13, Comment #15 and Comment #16. What exactly does the ebuild "fail to set" and why just a couple of users are affected by this weird behaviour, if it's not a make fault?
i imagine getting an affected user to simply run `emerge --debug udev` and posting the output should illustrate the problem
Downgrading to app-shells/bash-3.2_p17-r1 (from the now hardmasked _p25 version) solved my problem. Now, udev builds fine, and libvolume_id is generated. Happiness. :-)
(In reply to comment #20) > i imagine getting an affected user to simply run `emerge --debug udev` and > posting the output should illustrate the problem I really love other devs wasting other people's time with their stupid riddles. :X
Created attachment 130565 [details] emerge --debug -1 udev .. as requested in comment #20
Having another look at the ebuild it could work better if we move the variable-setting of myconf and extras to src_compile where it is needed. But this is only a workaround then. Shouldn't it work to set a variable in pkg_setup and use it in later phases?
(In reply to comment #24) > Shouldn't it work to set a variable in pkg_setup and use it in later phases? Yeah, sure it should. If it doesn't, lots of things will get broken.
(In reply to comment #25) > (In reply to comment #24) > > Shouldn't it work to set a variable in pkg_setup and use it in later phases? > > Yeah, sure it should. If it doesn't, lots of things will get broken. > Maybe it's a duplicate of bug 190128. What version of bash is it (post `emerge --info`)?
(In reply to comment #26) > Maybe it's a duplicate of bug 190128. What version of bash is it (post `emerge > --info`)? No, see Comment #3.
(In reply to comment #20) > i imagine getting an affected user to simply run `emerge --debug udev` and > posting the output should illustrate the problem I still have no clue how the "extras" value is getting lost. Somebody please add 'set -x' underneath the header of /usr/lib/portage/bin/ebuild.sh and run `emerge -B udev &> debug.log` and post the log.
trapni reproduced with www-servers/apache as well, certainly not an udev bug.
This one remains a mystery until somebody who can reproduce it gives us some more debugging information. Please attach a build log created with 'set -x' added to the top of /usr/lib/portage/bin/ebuild.sh.
Created attachment 131564 [details] emerge --debug -1 udev with 'set -x' With bash-3.2_p17-r1 everything worked fine (I downgraded bash and then installing udev went fine). Now I updated to bash-3.2_p25, added 'set -x' to ebuild.sh and tried emerging udev.
(In reply to comment #31) > Created an attachment (id=131564) [edit] > emerge --debug -1 udev > > With bash-3.2_p17-r1 everything worked fine (I downgraded bash and then > installing udev went fine). Now I updated to bash-3.2_p25, added 'set -x' to > ebuild.sh and tried emerging udev. As mentioned in comment #1 bash-3.2_p25 is known to be broken (bug #190128).
(In reply to comment #32) > As mentioned in comment #1 bash-3.2_p25 is known to be broken (bug #190128). > Why isn't it marked as a duplicate then?
Because the reporter said that he's using bash-3.2_p17-r1
(In reply to comment #30) > This one remains a mystery until somebody who can reproduce it gives us some > more debugging information. Please attach a build log created with 'set -x' > added to the top of /usr/lib/portage/bin/ebuild.sh. Closing as NEEDINFO wrt the above comment. Pretty disappointing to see the total lack of response here from reporters. We cannot fix something we can't reproduce, reopen with the requested info attached.
my logs were made with bash-3.2_p25, but the results were the same, the very same error message was printed. See comment #29, it's not only udev but also other ebuilds, so it's either not a bash problem or both bash p17 and p25 are affected.
(In reply to comment #36) > my logs were made with bash-3.2_p25, but the results were the same, the very > same error message was printed. We don't want any logs with bash-3.2_p25, that version is plain broken.
Created attachment 133587 [details] emerge -B =udev-114 &> debug.log I am sorry for not responding. This is the output of the emerge with 'set -x' as requested. I hope it helps to figure out what is broken. As recently udev-115-r1 was marked stable I gave it a try and bumped into the same compile error.
I reopen the bug given that info was submitted. I hope it's not against the netiquette.
please post your `emerge --info` run the same system you just ran `emerge -B`
Created attachment 133638 [details] emerge --info -v Output of emerge --info -v
(In reply to comment #38) > Created an attachment (id=133587) [edit] > emerge -B =udev-114 &> debug.log Comparing this log of a malfunctioning build to a log from one that behaves correctly, I don't see any explanation for the loss of the extras variable setting. I think it would help if the trace showed all of the variable settings that are loaded by each `source /var/tmp/portage/sys-fs/udev-114/temp/environment` command. I don't understand why the trace shows these in some cases and not others (this happens in traces that I create locally as well as in the malfunctioning build). For example, take this test case: #!/usr/bin/env bash set -x source /etc/profile.env The above script will show a trace of all the variable being set in the `source /etc/profile.env` command. Can someone explain why the `source /var/tmp/portage/sys-fs/udev-114/temp/environment` doesn't produce a similar trace when it happens inside ebuild.sh?
(In reply to comment #42) > (In reply to comment #38) > > Created an attachment (id=133587) [edit] > > emerge -B =udev-114 &> debug.log > > Comparing this log of a malfunctioning build to a log from one that behaves > correctly, I don't see any explanation for the loss of the extras variable > setting. I think it would help if the trace showed all of the variable settings > that are loaded by each `source > /var/tmp/portage/sys-fs/udev-114/temp/environment` command. I don't understand > why the trace shows these in some cases and not others (this happens in traces > that I create locally as well as in the malfunctioning build). For example, > take this test case: > > #!/usr/bin/env bash > set -x > source /etc/profile.env > > The above script will show a trace of all the variable being set in the `source > /etc/profile.env` command. Can someone explain why the `source > /var/tmp/portage/sys-fs/udev-114/temp/environment` doesn't produce a similar > trace when it happens inside ebuild.sh? > So... what should I do? I am sick of this. I can't compile many packages. I've revdep-rebuilt everything. I even did a "emerge -e world" once (a couple of months ago, shortly after the dramatic expat update). I'll probably end up re-installing gentoo (or migrating to another distro). Could this have anything to do with this other bug I submitted? http://bugs.gentoo.org/show_bug.cgi?id=189192 It also involves a variable not being detected during an emerge.
Anybody who still has this problem, please try with portage-2.1.4_rc since it has improved environment handling.
Someone get back to us if you still can reproduce this.
With the latest portage in the tree and the latest udev & hal problem was solved. Thank you very much.
