[10:03] somebody aware of the hal install failure on armel? causes build failures on the buildds (openjdk-6) [10:05] install failure ? [10:05] it installed fine yesterday here in a local bootstrap [10:08] ogra: https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b14-0ubuntu10/+build/848818 [10:11] thats udev, no ? [10:11] cat: /sys/kernel/uevent_seqnum: No such file or directory [10:11] invoke-rc.d: initscript udev, action "restart" failed. [10:11] dpkg: error processing udev (--configure): [10:11] subprocess post-installation script returned error exit status 1 [10:15] maybe [10:15] well, i pinged keybuk ... [14:50] ogra: that'n nutty, buildd's shouldn't be installing hal/udev to the build chroot. [14:50] ogra: check which package is pulling them in [14:51] suihkulokki, its already fixed in udev [14:51] udev shouldnt start if installed in a chroot [14:51] there are packages that depend on stuff that in turn depends on hal [14:51] so you cant really avoid things like that [14:52] packages like hal, dbus and udev need special casing [14:52] no [14:52] shouldn't they "just" fake invoke-rc.d and start-stop-daemon? :P [14:52] all of xorg depends on hal [14:52] you build-depend on libhal-dev libdus-dev etc [14:53] Stskeeps, thats what they do, but udev had a bad grep in the posinst before [14:53] and none of those -dev packages should pull their respective daemon in [14:53] feel free to look at the build log [14:53] but i know the fix got into udev already so that might be moot [14:53] http://launchpadlibrarian.net/21658731/buildlog_ubuntu-jaunty-armel.openjdk-6_6b14-0ubuntu10_FAILEDTOBUILD.txt.gz [14:55] https://lists.ubuntu.com/archives/jaunty-changes/2009-January/003929.html is the fix [14:57] ogra: that's fixing the symptom, not fixing the root of the problem - ie. "why is udev getting installed in the first place" [14:59] probably becuse the package needs a running X env ... we have a bunch of packages that need xvfb for example ... [14:59] dont ask me, i'm neither maintaining the buildds, nor maintain the openjdk package nor am i resonsible for udev :) [14:59] and the udev maintainer obviously considered that fis as appropriate [15:00] suihkulokki, Probably a side effect of recommends-by-default [15:00] persia: ...which is why recommends-by-default is not used on buildd's ;) [15:00] at least, on debian that is [15:00] beyond fixing that particular buildd issue it will also fix chroot building in general (in case you dont have sysfs mounted in your chroot during bootstrapping) [15:01] well, ubuntu doesnt use dak :) [15:01] suihkulokki, Heh. Well, that's one way to fix it. [15:01] Personally, I'd rather it did, because many maintainers seem to build packages on their personal local systems, with all sorts of random stuff installed, and certainly recommends. [15:02] Mind you, this is getting *lots* better, but still. [15:04] ogra: I don't claim that udev bug was not worth fixing - merely that there is most likely still a unnecessary depends somewhere [15:04] but if you don't care, whatever. [15:04] suihkulokki, well, ask doko_ about it ... :) [15:04] he was bringing it up since he tried to build openjdk [15:04] no idea what pulls it in [15:05] suihkulokki: pulseaudio sucks it in [15:06] And pulse needs to do device analysis if the daemon is running. [15:07] doko_, Why does OpenJDK need both libpulse-dev and pulseaudio to build? Would libpulse-dev itself not be sufficient? [15:07] Is this for the test suite? [15:09] AC_DEFUN([FIND_PULSEAUDIO], [15:09] [ [15:09] AC_PATH_PROG(PULSEAUDIO_BIN, "pulseaudio") [15:09] if test -z "${PULSEAUDIO_BIN}"; then [15:09] AC_MSG_ERROR("pulseaudio was not found.") [15:09] fi [15:09] AC_SUBST(PULSEAUDIO_BIN) [15:09] ]) [15:11] Blech. No helping it then, really. [15:11] * suihkulokki grumbles [15:15] 1) i would still check if that configure check can be fixed [15:15] 2) if pulseaudio does really need to depend on hal [15:15] then again, if the build system is pulling in recommends, this ranting is completly moot [15:15] there are more packages like that [15:16] all the stuff that uses xvfb for their test suites will run into the same now that xorg hard depends on hal [15:17] i think you should start to consider it a common case that udev *might* show up in buildd chroots [15:18] that depends on how much you care about quality and bloat [15:18] well, self tests can improve the quality ... so i'D rather call it a philosophical thing :) [15:19] I doubt even with current xorg xvfb would really hard-depend on hal [15:19] so in other words, someone took the lazy route [15:19] xvbf runs X [15:19] and X needs hal to run [15:20] *vfb [15:21] * ogra humms "times are changin ..." [15:21] * suihkulokki humms unverified bullshit [15:22] heh [15:23] well, fix X to not use hal ... but i doubt upstream will accept any patches that revert this behavior ... they made quite a hard cut and dropped much backwards compatibility with this release [15:28] you are confusing the dependency on libhal and dependency on hald [15:33] xorg moaning loudly if hald doesnt run doesnt help though :) but right, it doesnt have a dep on hal itself [16:15] hola [21:17] NCommander: hi [23:15] hey ScriptRipper [23:15] Did you think about the e-mail for the apt repo layout? [23:17] NCommander: your last comment was: i think about it under the shower, if i remeber correctly :) [23:18] NCommander: what did your shower say :) [23:23] ScriptRipper, "ack, it burns"