[00:26] New bug: #176809 in xserver-xorg-video-intel (main) "X crashes when starting any 3D app with 965GM" [Undecided,New] https://launchpad.net/bugs/176809 [07:06] New bug: #165253 in xserver-xorg-video-openchrome (main) "cannot select via or openchrome driver in screens & graphics dialog" [Undecided,Incomplete] https://launchpad.net/bugs/165253 === seb128_ is now known as seb128 === mvo_ is now known as mvo [18:45] New bug: #116919 in xserver-xorg-input-synaptics (main) "The Synaptic Touchpad is not disabled automatically when an external mouse is attached." [Undecided,New] https://launchpad.net/bugs/116919 [21:06] bryce: can I nag about the file overwrite problem in libx11-data <-> libx11-6 for dapper->hardy upgrades again? [21:06] sure, what's the bug id? [21:08] its launchpad bug #176555 [21:08] Launchpad bug 176555 in libx11 "libx11-6 / libx11-data conflict during upgrade from Dapper" [Medium,Confirmed] https://launchpad.net/bugs/176555 [21:09] ok, were there any issues found with adding that conflicts? [21:12] bryce: the patch is wrong (sorry, haven't looked at it) [21:12] bryce: it should be a replaces instead of a conflict [21:12] sorry, I haven't looked at the patch, just at the bug (I got it in my auto-upgrade-tester script) [21:12] aha [21:14] ok, rolling patch [21:14] cool, thanks [21:19] uh, it used to have that.. but then I filed a sync request [21:19] tjaalton: hrm, sounds like something to push upstream? [21:19] or something like that, and it got dropped [21:20] perhaps, it's simple [21:20] heh :) I remember that we fixed this but then I wasn't sure anymore [21:21] in any case, if you want to reupload the change, I've stuck it here: http://people.ubuntu.com/~bryce/Uploads/ [21:21] sounds like the priority would be to get this into debian though [21:21] oh wait, it's committed already, but -2 is not released yet :) [21:22] +Replaces: libx11-6 (<= 2:1.0.0-1) [21:23] bryce: I've got the xorg merge ready, xresprobe is now gone [21:23] awesome [21:24] tjaalton: hold off on that until after alpha-2 is out (later this week) [21:24] why? [21:24] we need testers, no? [21:24] well... [21:25] ok if you're confident it's not going to break things too badly for people, it can go in [21:25] it's not that much different compared to alpha1 ("no xorg.conf") :) [21:25] heh, true [21:25] speaking of which, what needs done to fix that? I should put some time into that bug [21:26] (btw, deb of the libx11 change is up - http://people.ubuntu.com/~bryce/Uploads/) [21:26] and that's simple to fix in livecd-rootfs (create a new file after it removes the existing one) [21:26] then the situation would be the same as after preinst [21:27] =empty file, and a md5sum that matches it [21:27] how do you mean? [21:27] like add a call to dexconf in one of the livecd scripts? [21:27] no, the session runs reconfigure already, but currently that fails [21:27] so we don't need to touch anything in addition to livecd-rootfs [21:28] I'm not sure what actually broke this in hardy, but it's a lot more complicated to fix in xserver-xorg [21:32] l-r removes the file because it needs to have a clean start (=dpkg-reconfigure xserver-xorg), but that fails because the postinst notices that there is no xorg.conf, and thinks that's how the user wants [21:35] hrm [21:35] heya tormod [21:35] heya bryce [21:38] hmm [21:39] so, is the right fix to make livecd-rootfs not remove that file to begin with, or to add a control for the dpkg-reconfigure xserver-xorg call to make it generate the xorg.conf even if it's missing, or...? [21:40] I'm thinking that let it remove the file, then touch a new one (=md5sum matches since it's empty as the one created on preinst) :) [21:40] and do that in livecd-rootfs [21:41] will that fix the issue though? [21:41] it should [21:42] since that's pretty much how the preinst would have done [21:42] although I'm not sure if the md5sum should be recreated also [21:42] probably [21:43] look at livecd.sh from livecd-rootfs [21:43] it does all sort of cleaning on the chroot [21:44] ok [21:47] bryce: for me xserver-xorg postinst hangs on dapper->hardy in noninteractive mode, it seems like something is trying to read from stdin, could you think of anything that might cause this? it may well be a artifact, I'm digging into it currently [21:48] probably a bug in the debconf code in the postinst? [21:48] its not reading from stdin, its something with debconf [21:49] 0 is connected to a debconf pipe [21:49] right [21:50] * mvo looks closer [21:53] hmm, if postinst doesn't know how to configure the hardware I guess it might prompt for the device or something, however wouldn't running in non-interactive mode prevent that? [21:54] debconf won't prompt if DEBIAN_FRONTEND=noninteractive [21:54] http://paste.ubuntu.com/2819/ has the debug log [21:54] I killed it at this point via ctrl-c, it seems to hang forever [21:56] hmm, I'm not too familiar with the cirrus driver [21:56] bryce: it has nothing to do with the driver [21:57] jcristau: is it quitting when it doesn't find valid modes? [21:57] the postinst calls db_stop, and hangs there [21:57] before that there's a modes call, and it looks like it returned an empty string [22:00] well, that part of the postinst is now gone anyway ;) [22:00] right, which is why I'm wondering if the cirrus driver lacks xrandr support or something [22:01] the debug log is from an older version which still used xresprobe.. [22:01] ahh [22:02] is it? it should be the latest available one in hardy [22:03] 1:7.3+7ubuntu3 unless I'm very mistaken [22:03] mvo: it is, I haven't uploaded +8ubuntu1 yet [22:03] actually s/the postinst/dexconf/ [22:03] ah ok, but still? [22:04] should I wait for this upload instead of poking it some more? [22:04] i don't think it's related to choosing modes. that part doesn't hang. [22:05] dexconf calls db_get xserver-$SERVER/config/display/modes, writes the screen section, then calls db_stop, and hangs there [22:06] i have no clue about debconf though :/ [22:08] hmm, if it's dexconf failing, the only noteworthy error exit after db_stop, is this: [22:08] # Ensure we can write to our destination if it already exits. [22:08] if [ -e "$XF86CONFIG" ]; then [22:08] if [ ! -w "$XF86CONFIG" ]; then [22:08] bomb "unable to write to \"$XF86CONFIG\"" [22:08] fi [22:08] fi [22:08] it's hanging at db_stop [22:09] not after that, i think [22:10] hmm, well all that does is this: [22:10] db_stop () { [22:10] echo STOP >&3 [22:10] } [22:10] hrm. [22:11] i think i hit something like that a while ago, and didn't manage to understand what went wrong [22:12] I think I have a better trace, give me a sec [22:13] http://paste.ubuntu.com/2822/ <- that include ctrl-c bits at the end, it hangs at "read -r _db_internal_line" [22:14] I suspect the earlier db_stop and then a db_unregister might be the problem? [22:14] yeah [22:15] right, so postinst calls dexconf, which calls db_stop, and the postinst tries to use debconf after that -> fail [22:17] mvo: try moving the if block around db_unregister before "if [ -z "$UPGRADE" ] || dpkg --compare-versions "$2" le "1:7.0.14"; then" [22:20] jcristau: yeah, that fixes it [22:20] mvo: thanks [22:20] thanks for looking into it with me :) [22:22] so should I change that for this upload? [22:23] if you have a upload pending, it would definitely be nice to have it [22:23] ok will do [22:23] tjaalton: i'll push a fix to the debian-unstable branch [22:23] I can run another upgrade test tomorrow to check if all is good, its 100% reproducable here in my VM [22:24] jcristau: ok, I'll pull from you then :) [22:25] maybe a comment somewhere that explains that dexconf can run db_stop would be good as well so that its easier to find this kind of error in the future (or to avoid it entirely :) [22:26] mvo: indeed [22:29] tjaalton: i'll test a lenny -> sid upgrade before i push the change [22:30] jcristau: ok, cool [22:30] brb (lunch) [22:59] for some reason, a lenny -> sid upgrade works fine. [23:00] i'd have thought it would hit the same bug [23:02] jcristau: lenny has newer xserver-xorg than 7.0.14, right? Doesn't it in that case skip the dexconf-phase completely? [23:03] ah. hum. true [23:16] pushed [23:16] mvo: thanks again [23:21] btw, I get a lintian warning: 'xorg source: stronger-dependency-implies-weaker depends -> recommends ${F:XServer-Xorg-Detect-Depends}' [23:22] any idea why? this was not the case with +7ubuntu* [23:24] the Detect stuff is only in Recommends afaics? [23:25] yes [23:26] i suspect a lintian bug [23:26] cheers, happy to help [23:26] * mvo waves [23:26] tjaalton: how's this look? http://people.ubuntu.com/~bryce/Testing/livecd-rootfs/ [23:27] bryce: I think that should do [23:28] think we should check with cjwatson first, or just upload? [23:28] bryce: nah, he already said that it's fine to commit to bzr and upload [23:29] is there an easy way we could test this out to make sure it solves it? [23:29] create the rootfs and reconfigure xserver-xorg on it [23:30] maybe that would do [23:31] ok, uploading xorg merge with the debconf-fix [23:34] I can test the livecd stuff tomorrow [23:34] cool, thanks [23:35] I'm committing the change to bzr now [23:35] great [23:35] looks like the last change was UNRELEASED; I don't know what that means [23:36] oh, I think I understand [23:36] it's also used by the debian git [23:36] to accumulate changes before an upload [23:39] ok here we go - http://people.ubuntu.com/~bryce/Testing/livecd-rootfs/ [23:40] that's generated against hardy and includes colin's unreleased change [23:40] so tomorrow, if it tests out ok, I think it can be uploaded [23:41] hmm, the release should probably be hardy :) [23:41] or do you mean that change it when it works [23:41] right [23:41] ? [23:41] ok [23:43] hmm, I can't push to bzr [23:43] maybe it needs core-dev powers? [23:43] probably [23:44] damn, I need to learn bzr then :) [23:44] anyway, that should be good for testing [23:44] sure [23:44] heh, this is all I did: [23:44] 622 bzr clone https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk livecd-rootfs [23:44] 623 cd livecd-rootfs [23:44] work work work [23:44] 638 bzr diff > leave_token_xorg.patch [23:44] 641 bzr commit [23:44] edit edit [23:45] 644 bzr push https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk [23:45] sounds git enough :) [23:45] yup [23:46] ok, I'll push that tomorrow when (!) it works [23:46] kewl [23:46] time to go to bed now, night! [23:46] my goal for today is to finally get this xserver git-head built [23:47] so I'm keeping fussing with it - now need to get mesa git-head built... *sigh* [23:47] anyway, night, cya tmrrw