[09:15] hw-detect: cjwatson * r1479 ubuntu/ (debian/changelog hw-detect.sh): [09:15] hw-detect: Redirect update-dev output to /dev/null, as it is in principle possible [09:15] hw-detect: for it to write to stdout and that would interfere with debconf. [09:24] hw-detect: cjwatson * r1480 ubuntu/debian/changelog: releasing version 1.89ubuntu1 [09:25] ubiquity: cjwatson * r5549 trunk/ (compat/udpkg debian/changelog): [09:25] ubiquity: compat/udpkg: Handle 'udpkg -c' from udpkg 1.14, required by hw-detect [09:25] ubiquity: 1.89. [09:26] ubiquity: cjwatson * r5550 trunk/ (d-i/manifest debian/changelog): Automatic update of included source packages: hw-detect 1.89ubuntu1. [09:30] ubiquity: cjwatson * r5551 trunk/debian/changelog: releasing version 2.11.14 [14:24] cjwatson: bug 987050 is targeted to 12.04.1 and is marked as "fix commited" though the ubiquity currently in proposed doesn't list that bug so I'm a bit confused about its actual state [14:24] Launchpad bug 987050 in ubiquity "No "Prepare for shipping ..." option after OEM install from D-I" [Medium,Fix committed] https://launchpad.net/bugs/987050 [14:26] stgraber: I marked it fix committed before quantal was created [14:26] but it was nevertheless on the quantal branch [14:28] cjwatson: ok, so I'll mark in progress for precise then [14:31] cjwatson: I cherry picked the fix from trunk and pushed to the proposed branch, so we'll have it in the next upload [14:32] thanks [14:32] though not totally sure how to verify it given the workaround being in place [14:32] I guess check the logs or something [14:34] the easiest way to check would be to install kubuntu OEM and check whether oem-config-slideshow-ubuntu is there post-install [14:34] with current precise it should (because of the workaround), with the SRU it shouldn't (as it'll only be installed if oem-config-udeb/frontend == gtk) [14:34] hm, ok [14:43] https://launchpadlibrarian.net/110034400/UbiquitySyslog.txt is intresting, why are all the traceback lines doubled up there ? [14:43] Jul 12 18:59:40 ubuntu plugininstall.py: ubiquity.install_misc.InstallStepError: HwDetect failed with code 10 [14:43] Jul 12 18:59:40 ubuntu plugininstall.py: ubiquity.install_misc.InstallStepError: HwDetect failed with code 10 [14:43] etc [14:44] hm,m, looks like all lines are duplicated ... [14:48] what bug is that from? [14:48] bug 1024406 [14:48] Launchpad bug 1024406 in ubiquity "installer crashed on preseeded install from daily quantal desktop i386 iso" [Undecided,New] https://launchpad.net/bugs/1024406 [14:49] just jumped into my bugmail box [14:50] right, well, whatever it is I'm banging my head against the same thing in any event [14:50] I mean the same underlying bug, not the doubling up [14:52] looks like maybe stuff has been redirected from installer/debug to syslog for some reason *shrug* [14:52] anyway, duped [14:53] oh, i thought i saw an upload relating it... just thought it was leftover fallout for the images that dont have the fix yet [14:53] *relating to [14:53] those were uploads trying to extract more debugging information [14:53] ah [14:53] in desperation [14:53] I've figured out how to more or less reliably reproduce it locally though [14:54] as long as I *don't* use --debug :-( [14:54] i was wondering if bug 1024356 could be related [14:54] Launchpad bug 1024356 in ubiquity "quantal armhf+omap4 daily live 2012-07-12 crashed during install (debconf.DebconfError: (10, "oem-config/enable doesn't exist"))" [Undecided,New] https://launchpad.net/bugs/1024356 [14:54] and i too have issues with ubiquity -d here [14:54] (apparently that bug doesnt show up then, tryinbg to reproduce it here) [14:55] not clear [14:56] right, thats why i try to get debug info out :) [14:56] its very unlikely it is oem-config related indeed [14:56] actually, yes, it is the same thing [14:56] the debconf protocol is out of sync so the error comes back at a point when ubiquity isn't prepared to catch it [14:56] aha ! [14:57] notice how you're getting that error on a totally unrelated debconf command [14:57] exactly why this is happening is an unsolved mystery [14:58] but it is my #1 focus of attention [14:58] well, it seems to happen pretty reliable if you dont use -d [14:58] on the pandas [14:58] with always the same erros msg ... [14:58] in my VM too. I was just put off for some time because I use -d by default when debugging anything at all in ubiquity. [14:59] ah, k, oi tought the x86 errors were all hw-detect [14:59] unfortunately the debconf debug output is unhelpful because it reflects what debconf thinks is happening, which doesn't match the view of the world from stuff interacting with it [14:59] yes, but it's the same underlying problem [14:59] right, i was just wondring if the slower speed of the panda coudl help nailing it down or so [14:59] just depends what happens to first issue a debconf command and care deeply about what comes back. [15:00] nah, if anything I could use something faster at this point [15:00] seems it is speed related which error gets spit out [15:00] no, hw-detect takes a different code path on x86 [15:00] that part is not speed-related [15:00] ah, k [15:01] there does seem to be something a bit racy in that jenkins doesn't show it every time; but regardless, I seem to be seeing it reliably now so I'm not going to rock the boat [15:01] I'm just doing as close as possible to the same things each run right now [15:01] and trying to insert fairly surgical debugging [15:02] it's possible that it's related to the fix xnox and I did last week; but if so, reverting that won't help since that was also causing autotest failures [15:02] so I'll have to debug directly rather than following the revert religion [15:02] lol [15:02] revert religion [15:03] spencerism :) [15:14] * cjwatson has an idea [15:15] in install_misc, "Reap the status-to-debconf subprocess" [15:15] the new select approach meant I needed some way to make that process go away [15:15] so I used kill(SIGTERM) [15:15] But it now occurs to me that that might kill it between sending a command to debconf and reading the reply [15:16] So I think I need a control pipe instead [15:20] * cjwatson tries something along the lines of http://paste.ubuntu.com/1090040/ === allee_ is now known as allee [15:46] ubiquity: cjwatson * r5552 trunk/ (4 files in 2 dirs): Drop hw-detect debugging attempts. [16:03] ubiquity: cjwatson * r5553 trunk/ (debian/changelog ubiquity/install_misc.py): [16:03] ubiquity: Terminate status-to-debconf subprocess in DebconfInstallProgress more [16:03] ubiquity: gracefully to avoid desynchronising the debconf protocol if the [16:03] ubiquity: subprocess is killed between sending a command and receiving the [16:03] ubiquity: response (LP: #1023036). [23:02] ubiquity: cjwatson * r5554 trunk/ (4 files in 3 dirs): [23:02] ubiquity: Make user-setup-encrypted-swap wait until partitioning has finished [23:02] ubiquity: before attempting to adjust /target/etc/fstab (LP: #1024343). [23:15] ubiquity: cjwatson * r5555 trunk/ (debian/changelog scripts/user-setup-encrypted-swap): [23:15] ubiquity: Don't try and fail to set up encrypted swap if no swap partitions are [23:15] ubiquity: configured (LP: #989279). [23:16] ubiquity: cjwatson * r5402 precise-proposed/ (debian/changelog scripts/user-setup-encrypted-swap): [23:16] ubiquity: Don't try and fail to set up encrypted swap if no swap partitions are [23:16] ubiquity: configured (LP: #989279). [23:17] ubiquity: cjwatson * r5556 trunk/ubiquity/install_misc.py: pacify pyflakes [23:24] ubiquity: cjwatson * r5557 trunk/debian/changelog: releasing version 2.11.15