Bugzilla Bug 190994

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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=131564) [details]
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.

(In reply to comment #31)
> Created an attachment (id=131564) [edit] [details]
> 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 an attachment (id=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 an attachment (id=133638) [details]
emerge --info -v

Output of emerge --info -v

(In reply to comment #38)
> Created an attachment (id=133587) [edit] [details]
> 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] [details]
> > 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.