[00:00] <RAOF> Hm.  Maybe it's libdrm conspiring with firefox that's at fault.
[00:10] <RAOF> Yes, that seems like it may well be it.
[00:11] <RAOF> Has anyone else seen problems with libdrm 2.4.23 & firefox?
[00:11] <RAOF> (On intel)
[00:29]  * RAOF starts a quick libdrm bisect.
[01:03] <RAOF> Nope, not libdrm.  And it's no longer reproducible.  GAH!
[01:26] <bryceh> RAOF, Sarvatt:  x11proto-randr, x11proto-xext, and -wacom now uploaded to natty
[01:26] <RAOF> Funky!
[01:27] <RAOF> Test-building the mesa merge with kibi's redone experimental mesa-7.10.
[01:36] <bryceh> -siliconmotion abi patch uploaded
[01:40] <Sarvatt> doh
[01:41] <RAOF> ?
[01:41] <Sarvatt> x11proto-randr (1.4.0+git20101207.0d32bb07-0ubuntu1) natty; urgency=low
[01:41] <Sarvatt> sorry if I did that + :(
[01:42] <bryceh> Sarvatt, what?
[01:42] <RAOF> It's 1.3.2+git... the release will be 1.4.0
[01:42] <Sarvatt> there hasn't been a 1.4.0 release yet
[01:42] <bryceh> ah rats, didn't doublecheck that, just reused the -edgers version number
[01:42]  * RAOF should have picked that up when auditing the xorg-edgers packages before saying “yes”
[01:43] <bryceh> maybe there'll be a 1.4.1 ;-)
[01:43] <Sarvatt> I use + more than I should in there because ~ is hell for versioned deps and it's automated, if you have 1.4.0~git build deps on 1.4.0 dont get fufilled
[01:44] <RAOF> Sarvatt: That's why you have build-deps on 1.4.0~
[01:44] <RAOF> bryceh: Worst case we have 1.4.0+really1.4.0 :)
[01:44] <Sarvatt> yeah but then 10 packages build dep on 1.4.0 and need manual adjustment to 1.4.0~git every day
[01:44] <Sarvatt> gets out of control fast
[01:45] <Sarvatt> will be more careful about it
[03:07] <bryceh> Sarvatt, aha, bug #557023 fixed and sru'd... one more down for solving the usb livecd issues
[03:07] <ubot4> Launchpad bug 557023 in usb-creator (Ubuntu Natty) (and 7 other projects) "update-initramfs: deferring update (trigger activated) / cp: cannot stat `/vmlinuz': No such file or directory (affects: 479) (dups: 391) (heat: 3161)" [High,Invalid] https://launchpad.net/bugs/557023
[04:40] <Sarvatt> sweet! and holy crap look at the dupe list
[04:41] <RAOF> Ah, that's the proprietary-drivers on livecd bug?
[04:43] <RAOF> bryceh: libdrm is ready in git and on http://cooperteam.net/Packages
[04:54] <Sarvatt> Amaranth: so it looks like vesafb + macbook = massive fail? color me surprised :)
[04:55] <Sarvatt> Amaranth: tried booting with vesafb.sucks=1?
[04:58] <Sarvatt> \o/ the same gcc bug that was making plymouth look like crap when compiled with -O2 was what was making the pixman test suite fail on natty!
[04:58] <RAOF> :)
[04:59] <RAOF> Shouldn't the macbook be using efifb anyway?
[05:00] <Sarvatt> i think we're unconditionally using vesafb now but yeah
[05:33] <RAOF> And there's mesa done.
[06:11] <bryceh> dpkg-source: info: extracting libdrm in libdrm-2.4.23
[06:11] <bryceh> dpkg-source: info: unpacking libdrm_2.4.23.orig.tar.gz
[06:11] <bryceh> dpkg-source: info: applying libdrm_2.4.23-1ubuntu1.diff.gz
[06:11] <bryceh> dpkg-source: info: upstream files that have been modified: 
[06:11] <bryceh>  libdrm-2.4.23/ChangeLog
[06:11] <bryceh>  libdrm-2.4.23/RELEASING
[06:11] <bryceh>  libdrm-2.4.23/autogen.sh
[06:11] <bryceh>  libdrm-2.4.23/tests/auth.c
[06:11] <bryceh>  libdrm-2.4.23/tests/lock.c
[06:11] <bryceh>  libdrm-2.4.23/xf86mm.h
[06:11] <bryceh> RAOF, those supposed to be changed?
[06:26] <bryceh> hmm, appears those were changed by debian
[07:24] <tjaalton> bryceh: yeah I should have a crude script that downloads the drivers that have no ubuntu changes, increments the changelog with 'buildN' and then uploads it
[07:24] <tjaalton> ..without any fault tolerance ;)
[07:25] <tjaalton> speaking of which; when do we start dropping drivers that are essentially unmaintained? (10.10?)
[07:25] <tjaalton> there are a number of them that don't even have any bugs filed, which is a good indication that no-one uses them :)
[07:26] <tjaalton> the first step would be to not include them in video/input-all
[07:27] <tjaalton> that would also save some cd space
[07:29] <bryceh> tjaalton, re:script - awesome!
[07:29] <bryceh> re: dropping drivers, I'm all for being aggressive
[07:29] <bryceh> fewer drivers == less space on cd, fewer bugs to have to worry about, etc.
[07:30] <tjaalton> and I meant 11.10 of course
[07:30] <tjaalton> (still living the 10.04 bliss :)
[07:31] <tjaalton> but for natty we could drop them from video-all
[07:31] <tjaalton> and input-all, they'd still be available from the archive
[07:31] <tjaalton> but for 11.10 (and wheezy?) we could discuss about dropping them completely
[07:31] <bryceh> tjaalton, yeah dropping them to universe is a suitable first step
[07:32] <bryceh> tjaalton, do you have a list of drivers you're thinking we should look at leaving behind?
[07:32] <tjaalton> the old cra^H^H^Hgreat hardware would then get vesa, and be basically just as fast in 2d as with the native driver & xaa
[07:32] <bryceh> heh, true dat
[07:33] <tjaalton> yeah I had a look at the driver list the other day..
[07:33] <RAOF> Although with possibly worse modesetting.  Although given the hardware is ancient, they may even have cared about VESA modes.
[07:33] <tjaalton> (and filed archive removal bugs for -sun*, which are sparc only=
[07:33] <tjaalton> )
[07:33] <tjaalton> RAOF: right, some might still have used weird panels on laptops etc
[07:33] <tjaalton> but.. we'll ses
[07:33] <tjaalton> see
[07:35] <bryceh> and people can rely on Debian if they really have to run that hardware (assuming the drivers don't bitrot away entirely)
[07:36] <RAOF> Or we could have the drivers in Universe; the livecd would get vesa.
[07:36] <tjaalton> well I think debian(-x) wants those removed as well
[07:36] <RAOF> Man.  Hardware so ancient even *Debian* doesn't support it :)
[07:36] <tjaalton> and upstream is mulling over it as well
[07:37] <bryceh> well, if debian plans to drop them too, then that makes the decision pretty obvious
[07:37] <RAOF> Yes.
[07:37] <tjaalton> right
[07:37] <tjaalton> but dropping from the metapackages is 'cheap'
[07:37] <bryceh> *nod*
[07:40] <tjaalton> so.. video drivers that have no bugs are: apm, ark, chips, (dummy), glide, i740, tseng, voodoo
[07:40] <tjaalton> voodoo has seen some kms love lately, and dummy could be useful for other purposes (servers?)
[07:41] <RAOF> Is chips used in virtualised enviromnents?
[07:41] <RAOF> i740 can DIAF, though
[07:41] <tjaalton> cirrus IIRC
[07:41] <tjaalton> kvm uses that
[07:41] <RAOF> Oh, yeah.  The other "c" driver.
[07:42] <tjaalton> cirrus I mean
[07:42] <RAOF> You know, if we were really hurting for CD space we could get away with just -intel, -ati-, -nouveau, and -vesa.
[07:43] <tjaalton> hmm a bunch of input drivers were purged when xserver 1.5(ish) was released
[07:43] <tjaalton> right
[07:44] <RAOF> The other drivers aren't particularly big, especially with dricore, so they're cheap to keep on there, but we could probably save a couple of MB.
[07:45] <Amaranth> Sarvatt: disabling vesafb got rid of the hang
[07:45] <RAOF> Well, there's a surprise :)
[07:45] <Amaranth> Now if only I knew how to make it use efifb instead
[07:46] <RAOF> video=efifb:something?
[07:53] <bryceh> tjaalton, yeah none of those drivers seem to come up much.
[07:54] <bryceh> tjaalton, shall we remove them from -video-all for a2 and see if anyone complains?
[07:54] <tjaalton> and then there are drivers like i128, glint, neomagic, s3* that are pretty rare
[07:55] <tjaalton> bryceh: that would be one way to find out :)
[07:58] <bryceh> one of the s3 variants is used as a virtualized driver for something
[07:59] <tjaalton> ah, right
[08:21] <bryceh> libdrm 2.4.23 uploaded
[08:25] <bryceh> I'll tackle the mesa upload in the morning when I'm fresh
[08:29] <RAOF> Oh.  It's a public holiday tomorrow in .au.  Is the Eastern Edition actually going to take place, I wonder?
[08:31] <bryceh> oh wow
[08:31] <bryceh> if y'all are out, and jason's out, it's just gonna be me!
[08:31] <bryceh> could be short!
[11:50] <RAOF> Ok.  Synaptics is done locally.  I can't push to git yet because I've made a bit of a mess of the history.
[11:54] <RAOF> bryceh, Sarvatt: I'll push a 1.10-buildable synaptics to git sometime tomorrow, or Thursday if the public holiday goes well :)
[14:22] <Sarvatt> libdrm got uploaded before mesa/nouveau/etc were ready and RAOF is on holiday now??
[14:42] <tseliot> Sarvatt: need a hand with uploads or what?
[14:42] <Sarvatt> tseliot: looks like RAOF got a mesa ready before he left that needs an upload http://cooperteam.net/Packages/
[14:43] <Sarvatt> its in git too http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu
[14:44] <tseliot> Sarvatt: ok, I can upload that. Have you tried to build it?
[14:46] <Sarvatt> nope I haven't, need to fix up my schroot since libdrm-dev isn't installable with xserver-xorg-video-all at the moment. he said he did before he uploaded it there last night looking at the log
[14:47] <tseliot> ok, I'll see if it builds in my chroot, just in case
[14:52] <Sarvatt> great, libdrm-dev depends not satisfiable in pbuilder
[14:52] <Sarvatt> The following packages have unmet dependencies:
[14:52] <Sarvatt>   libdrm-nouveau1a: Conflicts: libdrm-nouveau1 but 2.4.22-2ubuntu1 is installed.
[14:59] <Sarvatt> hmm, what am I missing here, this supposedly works in debian :)
[15:00] <jcristau> you have packages depending on libdrm-nouveau1?
[15:00] <jcristau> like plymouth and nouveau and stuff
[15:00] <Sarvatt> its a brand new buildd variant pbuilder
[15:00] <Sarvatt> ahh yeah plymouth is the problem
[15:01] <jcristau> pbuilder shouldn't have plymouth installed
[15:06] <tseliot> Sarvatt: I was about to mention this little problem when doing a build-dep in my pbuilder chroot: libdrm-dev : Depends: libdrm-nouveau1a (= 2.4.23-1ubuntu1) but it is not going to be installed
[15:06] <Sarvatt> it's installed in there, and fun it reqires libdrm-dev to install which wont upgrade :)
[15:06] <Sarvatt> err libdrm-dev to build I Meant
[15:08]  * tseliot is wondering what's the difference between libdrm-nouveau1a and  libdrm-nouveau1...
[15:09] <jcristau> tseliot: incompatible ABI
[15:10] <tseliot> hmm...
[15:11] <jcristau> but plymouth in a build chroot makes no sense to me
[15:11] <tseliot> +1000
[15:12] <tseliot> Sarvatt: we should rebuild plymouth against the new libdrm anyway
[15:15] <Sarvatt> yeah, but it still works without a rebuild and how do we do it with libdrm-dev not being installable? I've got a libdrm-nouveau1a rename back to libdrm-nouveau1 ready if nothing else
[15:16] <tseliot> Sarvatt: is that because the binaries ended up in NEW?
[15:16] <jcristau> Sarvatt: what's pulling plymouth in your build env?
[15:17] <tseliot> I guess not, otherwise they wouldn't show up in my chroot
[15:17]  * tseliot is sleep deprived...
[15:18] <Sarvatt> i   mountall Depends plymouth
[15:18] <jcristau> lolz.
[15:18] <tseliot> yes, to show fsck checks in plymouth
[15:18] <tseliot> :/
[15:19] <jcristau> so libdrm-nouveau1 is essential?  well played there.
[15:23] <Sarvatt> tseliot: http://sarvatt.com/downloads/merges/libdrm-natty/
[15:23]  * tseliot has a look
[15:24] <jcristau> Sarvatt: that's a bad idea.
[15:25] <tseliot> how so?
[15:25] <jcristau> there's a reason the package was renamed.
[15:26] <Sarvatt> we can make sure everything is rebuilt the way we have been and dont have 2 pockets to support with different abi's, struggling to see another way around this mess
[15:30] <Sarvatt> transitional libdrm-nouveau1 package maybe?
[15:53] <Sarvatt> <cjwatson> ok, using Conflicts for this is against current policy, which may be part of why it broke
[15:53] <Sarvatt> <cjwatson> the correct package relationships would have been:
[15:53] <Sarvatt> <cjwatson> Breaks: libdrm-nouveau1
[15:53] <Sarvatt> <cjwatson> Replaces: libdrm-nouveau1
[15:53] <Sarvatt> <cjwatson> I suspect that if you do that then it will be happier
[15:53] <Sarvatt> jcristau: ^
[15:53] <jcristau> can't see how that would help, seeing how plymouth is still essential and depends on libdrm-nouveau1
[15:54] <Sarvatt> looks like we're going to end up temporarily removing the breaks to bootstrap a plymouth build
[16:06] <Sarvatt> tseliot: so new libdrm upload just changing Conflicts: libdrm-nouveau1 to Replaces: libdrm-nouveau1 until plymouth is rebuilt sounds like the plan then, would ya be willing to upload that?
[16:06] <jcristau> yeah that sounds like easiest way out
[16:09] <Sarvatt> got it prepared here if ya want, http://sarvatt.com/downloads/merges/libdrm-natty-2/
[16:16] <tseliot> Sarvatt: sure, let me have a look
[16:16] <Sarvatt> tseliot: pitti already got it
[16:16] <Sarvatt> sorry about that
[16:17] <tseliot> Sarvatt: no, that's better, I can't think think clearly today ;)
[16:17] <tseliot> Sarvatt: I'll hold the upload of mesa (which I can probably do tomorrow)
[16:18] <tseliot> or whoever can upload it first
[16:18] <tseliot> can do it tomorrow
[16:30] <Sarvatt> argh, I forgot -dbg but thats ok since its just temporary for the rebuild, fixing it up for the real release in git
[16:37] <Sarvatt> ok new upload ready in git for whenever plymouth is done http://git.debian.org/?p=pkg-xorg/lib/libdrm.git;a=shortlog;h=refs/heads/ubuntu
[16:54] <tseliot> good
[16:54] <killtill> Anyone had problems after Friday updates ? -killed my gdm 
[16:55] <tseliot> Sarvatt: if needed, you can remind me tomorrow about the upload
[16:55] <Sarvatt> mesa needs to go in ASAP after plymouth is done because the archive is still busted until then, bryce should be around by then though
[16:55] <tseliot> oh
[16:55] <Sarvatt> plymouth hasnt been uploaded yet
[16:56] <tseliot> Sarvatt: who is supposed to upload plymouth?
[16:56] <Sarvatt> cjwatson said he'd get it, libdrm just finished a few minutes ago
[16:56] <tseliot> ok
[16:57] <Sarvatt> we need a new nouveau too, guess its time to figure out how the heck raof does it in git
[17:11] <shadeslayer> ok so drm is now fixed and uploaded?
[17:13] <Sarvatt> not exactly, the libdrm uploaded now will allow plymouth to be rebuilt
[17:13] <Sarvatt> plymouth needs to be rebuilt for mesa to be uploaded and built
[17:13] <shadeslayer> ah ok :)
[17:13] <Sarvatt> lots of things that need libdrm-dev also need mesa dev packages and are waiting for that
[17:13] <shadeslayer> Sarvatt: kipi-plugins in KDE too
[17:14] <Sarvatt> sorry for the trouble shadeslayer, I'm guessing it'll be ~2 hours or so until its fixed in the archive depending on when plymouth gets uploaded
[17:14] <shadeslayer> Sarvatt: sure no problem :)
[17:36] <Sarvatt> looks like the switch to keyboard-config screwed up my keyboard :) XKBMODEL="a4techKB21" XKBLAYOUT="us,af"
=== yofel_ is now known as yofel
[19:47] <tormod> anyone willing to wave bug 675622 through?
[19:47] <ubot4> Launchpad bug 675622 in glew (Ubuntu) "Merge sync glew 1.5.7-1 from Debian experimental (main) (affects: 5) (dups: 1) (heat: 36)" [Undecided,New] https://launchpad.net/bugs/675622
[19:47] <Sarvatt> hey tormod! how the heck have ya been man?
[19:48] <tormod> hi sarvatt!
[19:54] <bryceh> heya tormod
[19:57] <bryceh> tormod, I generally don't process sync requests but I've added my +1 in case that helps move it along
[20:07] <tormod> bryceh, thanks, also for correcting the title :)
[20:08] <Sarvatt> sync requests are processed amazingly fast these days
[20:09] <Sarvatt> oh bryce acked it, theres something else to do after that, looking it up
[20:10] <Sarvatt> set it to triaged and subscribe someone else and unsub review team
[20:11] <Sarvatt> darn where's that wiki
[20:13] <Sarvatt> ah there it is, https://wiki.ubuntu.com/SyncRequestProcess -- looks like subscribing ubuntu-archive is the next step
[20:33] <kva> hello, anyone here?
[21:11] <Sarvatt> RAOF: if you happen to pop on can you update nouveau? I'm not sure how you do it with gbp
[21:13] <Sarvatt> if anyone's using edgers on natty, I apologize in advance that things are going to be broken a bit with libdrm-nouveau1a, got some super important work that needs my attention and not sure how to fix it best in there yet
[21:26] <bryceh> I've subbed ubuntu-archive
[21:27] <bryceh> Sarvatt, I'll pop a note to ubuntu-x
[21:38] <bryceh> popped
[23:27] <Sarvatt> bryceh: thank you so much for that
[23:54] <Sarvatt> bryceh: ugh, I see what you're talking about now, inbox full of bugzilla status update spam