Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 190994 - variables getting unset between ebuild phases (udev + $extras, apache + $mpm)
Summary: variables getting unset between ebuild phases (udev + $extras, apache + $mpm)
Status: VERIFIED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 191249 191945 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-09-01 19:03 UTC by Pablo Montepagano
Modified: 2013-03-13 22:33 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info -v (emerge infov.txt,8.02 KB, text/plain)
2007-09-01 19:06 UTC, Pablo Montepagano
Details
emerge output of "MAKEOPTS="-j1" emerge =udev-114 &> emerge.log" (emerge.log,10.78 KB, text/plain)
2007-09-01 20:04 UTC, Pablo Montepagano
Details
proper emerge =udev114 output (sys-fs:udev-114:20070901-201213.log,24.02 KB, text/plain)
2007-09-01 20:19 UTC, Jakub Moc (RETIRED)
Details
emerge --debug -1 udev (udev-debug-log,70.52 KB, text/plain)
2007-09-11 07:43 UTC, Tomas Carnecky
Details
emerge --debug -1 udev with 'set -x' (udev-log,570.11 KB, text/plain)
2007-09-21 22:40 UTC, Tomas Carnecky
Details
emerge -B =udev-114 &> debug.log (debug.log,484.66 KB, text/plain)
2007-10-16 01:47 UTC, Pablo Montepagano
Details
emerge --info -v (emergeinfo,8.03 KB, text/plain)
2007-10-16 18:21 UTC, Pablo Montepagano
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo Montepagano 2007-09-01 19:03:28 UTC
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.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-09-01 19:06:14 UTC
You are/were using broken, hardmasked bash

*** This bug has been marked as a duplicate of bug 182860 ***
Comment 2 Pablo Montepagano 2007-09-01 19:06:24 UTC
Created attachment 129787 [details]
emerge --info -v
Comment 3 Pablo Montepagano 2007-09-01 19:41:06 UTC
Since when is bash-3.2_p17 is buggy????
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2007-09-01 19:44:35 UTC
MAKEOPTS="-j1" emerge =udev-114 &> emerge.log

Attach it here.
Comment 5 Pablo Montepagano 2007-09-01 20:04:28 UTC
Created attachment 129799 [details]
emerge output of "MAKEOPTS="-j1" emerge =udev-114 &> emerge.log"

Here you go.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2007-09-01 20:15:58 UTC
Well, there's something seriously broken with your system, not udev...
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2007-09-01 20:19:07 UTC
Created attachment 129802 [details]
proper emerge =udev114 output

This is what it should look like - you are missing about half of the udev stuff.
Comment 8 Matthias Schwarzott gentoo-dev 2007-09-02 10:25:56 UTC
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.
Comment 9 Jakub Moc (RETIRED) gentoo-dev 2007-09-04 15:08:53 UTC
*** Bug 191249 has been marked as a duplicate of this bug. ***
Comment 10 jieryn 2007-09-04 16:05:25 UTC
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..
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2007-09-04 17:07:26 UTC
(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.

Comment 12 Doug Goldstein gentoo-dev 2007-09-04 17:10:48 UTC
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.
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2007-09-05 09:01:16 UTC
@base-system - if you have any ideas why make screws here... Not udev-114 specific either, see bug 182860 and the duplicates there.
Comment 14 SpanKY gentoo-dev 2007-09-05 14:22:55 UTC
make isnt some mysterious thing ... if you fail to set EXTRAS in the make, you'd obviously get the behavior seen by Pablo
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2007-09-05 14:27:16 UTC
(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? 

Comment 16 Matthias Schwarzott gentoo-dev 2007-09-05 15:04:45 UTC
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
}
Comment 17 Pablo Montepagano 2007-09-05 15:15:54 UTC
(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.
Comment 18 Jakub Moc (RETIRED) gentoo-dev 2007-09-10 07:33:01 UTC
*** Bug 191945 has been marked as a duplicate of this bug. ***
Comment 19 Jakub Moc (RETIRED) gentoo-dev 2007-09-10 13:51:32 UTC
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?
Comment 20 SpanKY gentoo-dev 2007-09-10 15:43:10 UTC
i imagine getting an affected user to simply run `emerge --debug udev` and posting the output should illustrate the problem
Comment 21 jieryn 2007-09-10 17:03:56 UTC
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. :-)
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2007-09-10 19:08:14 UTC
(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
 

Comment 23 Tomas Carnecky 2007-09-11 07:43:20 UTC
Created attachment 130565 [details]
emerge --debug -1 udev

.. as requested in comment #20
Comment 24 Matthias Schwarzott gentoo-dev 2007-09-11 07:55:30 UTC
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?
Comment 25 Jakub Moc (RETIRED) gentoo-dev 2007-09-11 08:26:42 UTC
(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. 
Comment 26 Zac Medico gentoo-dev 2007-09-13 18:28:08 UTC
(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`)?
Comment 27 Jakub Moc (RETIRED) gentoo-dev 2007-09-13 18:46:18 UTC
(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.
Comment 28 Zac Medico gentoo-dev 2007-09-13 20:16:24 UTC
(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.
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2007-09-21 09:28:53 UTC
trapni reproduced with www-servers/apache as well, certainly not an udev bug.
Comment 30 Zac Medico gentoo-dev 2007-09-21 16:37:39 UTC
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.
Comment 31 Tomas Carnecky 2007-09-21 22:40:25 UTC
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.
Comment 32 Marius Mauch (RETIRED) gentoo-dev 2007-09-22 00:01:10 UTC
(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).
Comment 33 Tomas Carnecky 2007-09-22 07:41:50 UTC
(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?
Comment 34 Marius Mauch (RETIRED) gentoo-dev 2007-09-22 08:09:44 UTC
Because the reporter said that he's using bash-3.2_p17-r1
Comment 35 Jakub Moc (RETIRED) gentoo-dev 2007-10-03 10:38:02 UTC
(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.
 
Comment 36 Tomas Carnecky 2007-10-03 10:59:21 UTC
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.
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2007-10-03 11:04:47 UTC
(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.
Comment 38 Pablo Montepagano 2007-10-16 01:47:10 UTC
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.
Comment 39 Pablo Montepagano 2007-10-16 01:49:51 UTC
I reopen the bug given that info was submitted. I hope it's not against the netiquette.
Comment 40 SpanKY gentoo-dev 2007-10-16 05:33:24 UTC
please post your `emerge --info` run the same system you just ran `emerge -B`
Comment 41 Pablo Montepagano 2007-10-16 18:21:52 UTC
Created attachment 133638 [details]
emerge --info -v

Output of emerge --info -v
Comment 42 Zac Medico gentoo-dev 2007-10-18 18:22:34 UTC
(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?
Comment 43 Pablo Montepagano 2007-11-02 23:13:40 UTC
(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.
Comment 44 Zac Medico gentoo-dev 2007-11-25 23:14:05 UTC
Anybody who still has this problem, please try with portage-2.1.4_rc since it has improved environment handling.
Comment 45 Jakub Moc (RETIRED) gentoo-dev 2008-02-17 20:35:48 UTC
Someone get back to us if you still can reproduce this.
Comment 46 Pablo Montepagano 2008-02-19 14:58:42 UTC
With the latest portage in the tree and the latest udev & hal problem was solved.

Thank you very much.