=== `rand` is now known as `rand`-AFK
[05:35] <mlankhorst> morning
[06:31] <mlankhorst> RAOF: could you upload libdrm to debian experimental and then sync to ubuntu?
[06:33] <RAOF> No, because I can't upload to Debian; tjaalton could though :)
[06:33] <mlankhorst> tjaalton?
[06:34] <RAOF> Who happens to be on holiday
[06:34] <mlankhorst> aww
[06:34]  * RAOF should really become a DD
[06:34] <mlankhorst> same
[06:34] <RAOF> I *could* take what's in git/debian-experimental and upload it to Ubuntu, though :)
[06:34] <mlankhorst> yeah but was hoping to have the automagic sync magic do its job after that
[06:35] <RAOF> Well, Debian Import Freeze is in effect, so the autosync is no longer going to be running.
[06:35] <mlankhorst> ah sure then just upload to ubuntu
[06:35] <RAOF> We'll need to manually sync anyway :)
[06:36] <mlankhorst> 2.4.37 has both libdrm_nouveau's and with a small patch mesa will build again
[06:36] <RAOF> *and* new mesa will build!
[06:37] <mlankhorst> quantally
[06:38] <mlankhorst> (and probably a 2 liner patch would allow old xf86-video-nouveau to build)
[06:56] <mlankhorst> RAOF: ok pushed changes for mesa.git too
[07:00] <RAOF> Does xf86-video-nouveau also build correctly? Your changes wrangle the old libdrm into the source tree, right?
[07:01] <mlankhorst> yeah the trick is that only old libdrm_nouveau dependent packages require changes
[07:01] <mlankhorst> and that I didn't change soname
[07:01] <mlankhorst> libdrm_nouveau1.so links to libdrm_nouveau.so.1
[07:02] <mlankhorst> libdrm_nouveau.so to libdrm_nouveau.so.2
[07:02] <mlankhorst> same for libdrm_nouveau(1,).pc
[07:02] <RAOF> So our existing xf86-video-nouveau package will build happily against libdrm_nouveau.so.2, right?
[07:02] <mlankhorst> yep
[07:03] <mlankhorst> oh that would require an upload to kill the drm patch
[07:03] <mlankhorst> you're right
[07:03] <RAOF> Heh
[07:03] <RAOF> But it's not going to break at runtime; the existing package will *work*, it's just that rebuilds will require a little finangling.
[07:04] <mlankhorst> yeah
[07:04] <mlankhorst> that was my whole goal
[07:05] <mlankhorst> I wanted to be able to compile upstream without any changes to source to make it easier for users
[07:06] <RAOF> A noble goal.
[07:06] <mlankhorst> fedora renamed libdrm_nouveau.so.2 to libdrm_nouveau2.so.2 but since upstream didn't recognise it and no headers conflict it was ok not to do that
[07:07] <RAOF> I wonder why they did that?
[07:07] <mlankhorst> was done by their nouveau maintainer, probably less concern about compatability :)
[07:08] <RAOF> Yeah :)
[09:04] <mlankhorst> time to figure out git-send-email from canonical address and submit for review
[10:58] <mlankhorst> and submitted for review :)
[11:57] <mlankhorst> RAOF: can you look at the patches I posted on ml?
[11:58] <mlankhorst> lkml or dri-devel
[12:01] <RAOF> mlankhorst: I'll take a look at them tomorrow
[13:54] <mlankhorst> oh great x1.13 has all the prime bits :)
[16:26] <mlankhorst> hey bryceh 
[16:33] <bryceh> hey
[16:58]  * bryceh hehs the ubuntu wayland brouhaha on slashdot
[18:32] <mlankhorst> bryceh: you know I should propose something outrageous but with enough insanity that it sounds plausible next uds
[18:32] <mlankhorst> and then laugh at the press it generates
[18:53] <bryceh> mlankhorst, totally.  I scheme up ideas all the time :-)
[18:54] <bryceh> mlankhorst, only problem is that then when you *don't* deliver the crazy thing, then they just gloat that you "failed"
[18:55] <mlankhorst> The only way the MS Surface will kill the iPad is if it drops on one!
[18:55] <mlankhorst> :D
[19:01] <mlankhorst> bryceh: and nah i don't get the blame then
[19:06] <seb128> bryceh, hey
[19:06] <seb128> bryceh, do you think that getting libxrandr-utils ready and porting the GNOME stuff this cycle seems realistic?
[19:07] <seb128> bryceh, I'm wondering if we should postpone the GNOME porting part, it seems like to me that if we get the lib ready this cycle it would already be good, then we can port next cycle?
[19:13] <bryceh> seb128, ok that sounds good
[21:42] <bryceh> if I have a package 1.0.2-0ubuntu2 in precise, and am SRUing a new upstream release 1.0.3, would the numbering for the precise-proposed upload be just 1.0.3-0ubuntu1 or should it be something like 1.0.2*really1.0.3-ubuntu-1? 
[21:46] <maxb> Well, no 'really' - that's only when the upstream version needs to be reduced
[21:47] <maxb> SRUs don't generally get new upstream releases at all, so I'm not sure there's a solid convention
[21:48] <maxb> 1.0.3-0ubuntu1 would collide with the normal versioning of an upload to quantal
[21:49] <maxb> So my guess would be something like 1.0.3-0ubuntu0.1 or -0ubuntu0precise1
[21:50] <seb128> bryceh, what maxb wrote
[21:50] <seb128> usually people use 1.0.3-0ubuntu0.1
[21:53] <bryceh> seb128, great thanks
[21:53] <bryceh> maxb, right, thanks.