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