[00:04] <RAOF> bryceh: We wanted the original X stack to be available on the CD.  The .3 point release will have Q's X stack on the CD.
[00:05] <bryceh> RAOF, ah so the task isn't worded correctly
[00:05] <RAOF> So, if someone has some hardware that doesn't work with Q's X stack, the .3 LiveCD will be useless for them, but they could install from .1 or .2, not pull in the Q stack, and happily use Precise for the full support period.
[00:09] <bryceh> RAOF, since the P and Q stacks can co-exist in the archive, should they both be included in the .3 LiveCD?  
[00:10] <bryceh> hmm, I suppose that may not help if the LiveCD doesn't boot to begin with
[00:10] <RAOF> bryceh: Possibly; there are two obvious problems - (a) cd space, (b) how do you select which X stack?
[00:11] <bryceh> (a) is probably irrelevant; (b) is a good point.  Presumably it'd need some sort of hook in grub or something.
[00:12] <bryceh> RAOF, anyway ok thanks, I'll ping the archive guys
[00:35] <Sarvatt> err, having all stacks coinstallable?
[00:35] <bryceh> Sarvatt, ?
[00:36] <Sarvatt> that sounds a bit scary, i was going under the assumption one would replace the other, namespacing the actual binaries isn't gonna happen, alternatives for the whole stack sonds like a nightmare, not going to be able to do anything from grub if its not all coinstallable
[00:37] <RAOF> Yeah, they're not going to be coinstallable.
[00:38] <RAOF> But you'd be able to have them all on the CD, at the cost of a little bit of boot-time madness.
[00:38] <RAOF> I do not suggest that we implement that madness, but it wouldn't be *too* hard.
[00:39] <RAOF> It would just be utterly untested until we tried to roll out the .3 point release, which doesn't sound like the right time for boot time madness testing :)
[00:41] <bryceh> well by hook in grub I meant more along the lines of a script that would do the X stack reinstall
[00:44] <bryceh> but regarding binary package names, I had assumed we *would* need to rename them all.  Can two versions of a binary package exist in the archive with the same name?
[00:44] <Sarvatt> so just an upstart script querying the dpkg database that adds 1 second to the boot time noone will accept? :P
[00:44] <Sarvatt> package name differences are a pain in the ass but fine, i was saying renaming the actual binaries isn't going to happen
[00:45] <Sarvatt> like /usr/lib/x86_64-linux-gnu/dri/i915_dri-q.so or whatever
[00:46] <Sarvatt> too much stuff depends on exact names
[00:46] <bryceh> ah right
[00:47] <bryceh> yeah, agree that'd be too much insanity for too little gain; it's hopefully just a corner case where people will want the older point releases
[00:48] <Sarvatt> it's already going to be a nightmare making sure the entire stack upgrades right, the breaks: in xserver really screw up apt and no clue why it happens
[00:49] <Sarvatt> like if one package isn't available or installed outside of the archive (vbox providing an abi virtual package) it tries to remove a ton of X crap and install all the proprietary drivers
[00:52] <Sarvatt> then we get bugs about inverted screens when booting with compiz after that happens because they are using nvidia libglx
[00:52] <bryceh> that was an awesome bug
[00:52] <Sarvatt> i still see that bug on the debian-x mailing lists all the time :(
[00:52] <bryceh> USB boot sticks with persistence, yay!
[11:28] <LetoThe2nd> howdy! today's xorg-edgers updates seem to break some things on my box in funny ways ... :)
[11:29] <LetoThe2nd> first observation: running terminator after the update breaks with: You need to install the python bindings for gobject, gtk and pango to run Terminator.
[11:30] <LetoThe2nd> second observation: running virtualbox fails with: VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBox.so",) failed: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: undefined symbol: xcb_glx_set_client_info_2arb
[11:30] <LetoThe2nd> what might be of interest here? configuration is triple head on 2x ati hd5450
[11:51] <LetoThe2nd> re-installing the stuff out of the ppa didn't fix things... any ideas how to proceed? what might be the source, or where to poke for additional relevant details?
[12:00]  * LetoThe2nd guesses the channel might be more alive durig US office times :/
[12:01] <tjaalton> well don't run edgers if you don't know how to handle the downfall
[12:02] <tjaalton> it's git snaphots from upstream code, anything can go wrong
[12:02] <LetoThe2nd> tjaalton: i'm not complaining, just trying to report issues. i would do on launchpad if i knew the relevant package.
[12:02] <tjaalton> report upstream
[12:03] <ricotz> what is the issue?
[12:04] <LetoThe2nd> ricotz: todays edgers updates broke things in a way that i don't understand yet.
[12:04] <ricotz> mesa is currently quite broken
[12:04] <LetoThe2nd> first observation: running terminator after the update breaks with: You need to install the python bindings for gobject, gtk and pango to run Terminator.
[12:04] <LetoThe2nd> second observation: running virtualbox fails with: VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBox.so",) failed: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: undefined symbol: xcb_glx_set_client_info_2arb
[12:04] <tjaalton> don't expect virtualbox to work with unstable upstream code
[12:04] <ricotz> yes that is known
[12:04] <LetoThe2nd> tjaalton: until this morning it worked quite well.
[12:05] <ricotz> this the mesa problem which hopefully resolves itself with the next update
[12:05] <ricotz> LetoThe2nd, you can revert to the last snapshot and everything should be fine again
[12:06] <LetoThe2nd> ricotz: have a link to relevant documentation, maybe?
[12:06] <LetoThe2nd> ricotz: and then just stick with the installed version? or what do you suggest?
[12:07] <ricotz> LetoThe2nd, you can install the old deb package which might be in your apt cache or you can get it from the ppa page
[12:07] <LetoThe2nd> ricotz: ah ok, the manual way.
[12:07] <ricotz> yes
[12:08] <LetoThe2nd> ricotz: and then just deactivate the updates for now?
[12:10] <ricotz> yeah, just dont update mesa the other things should be fine 
[12:10] <LetoThe2nd> ricotz: will give it a try, thanks.
[12:11] <LetoThe2nd> ricotz: if it's known, i guess nobody cares about reporting somewhere?
[12:12] <ricotz> LetoThe2nd, this is probably reported already
[12:13] <LetoThe2nd> ok
[12:13] <ricotz> like https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/911611
[12:13] <ubot4> Launchpad bug 911611 in mesa (Ubuntu) "ubuntuone-control-panel-gtk crashed with ImportError in /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py: /usr/lib/i386-linux-gnu/mesa/libGL.so.1: undefined symbol: xcb_glx_set_client_info_2arb (affects: 1) (dups: 1) (heat: 16)" [Undecided,Incomplete]
[12:15] <ricotz> tjaalton, ^ this is using edgers ppa for sure
[12:16] <tjaalton> ricotz: ok
[12:18] <ricotz> Sarvatt, ^ more trouble than i expected ;)
[12:42] <ricotz> tjaalton, http://sourceforge.net/projects/linuxwacom/files/xf86-input-wacom/ ;)
[12:49] <tjaalton> ricotz: maybe together with xserver 1.11
[12:51] <ricotz> tjaalton, you might want to put it in ubuntu-x-swat/x-staging
[12:51] <tjaalton> yeah, why not
[12:51] <ricotz> so it is ready for the pocket copy
[12:53] <tjaalton> right
[13:40] <LetoThe2nd> ricotz: manually downgrading seems to have fixed it, thanks.
[16:32] <Sarvatt> LetoThe2nd: yeah I'm trying to get it fixed up but its still broken on mesa master and running into problems with the fix on the lists, will let ya know when its safe to upgrade again
[16:51] <Sarvatt> looks like idr's latest fix is just broken on osmesa and swx11 mesa build targets, dri builds fine
[18:45] <ricotz> Sarvatt, hi
[18:46] <Sarvatt> ricotz: heya
[18:46] <Sarvatt> v2: Move the AM_CONDIATION outside the case-statement so that it is
[18:46] <Sarvatt> invoked even for non-GLX builds.  This prevents build failures with
[18:46] <Sarvatt> osmesa, for example.
[18:46] <Sarvatt> \o/
[18:47] <ricotz> Sarvatt, why did you remove the libxcb-glx0-dev build-dep?
[18:47] <Sarvatt> i did?
[18:47] <ricotz> the last diff says so :\
[18:47] <Sarvatt>  linux-libc-dev (>= 2.6.31) [linux-any],
[18:47] <Sarvatt>  libxcb-glx0-dev,
[18:48] <ricotz> https://launchpadlibrarian.net/89080372/mesa_7.12.0~git20120103.2ae591bd-0ubuntu0sarvatt4_7.12.0~git20120104.892a2542-0ubuntu0sarvatt.diff.gz
[18:48] <Sarvatt> it's there in the local checkout i uploaded..
[18:51] <ricotz> Sarvatt, it isnt in 7.12.0~git20120104.892a2542-0ubuntu0sarvatt 
[18:52] <ricotz> Sarvatt, havent built it here, just noticed this change
[18:53] <Sarvatt> ricotz: well its fixed up locally, sorry about that, idr posted a fixed patch to make it build 5 minutes ago so i'll reupload
[18:53] <ricotz> Sarvatt, nice, thanks
[18:53] <ricotz> Sarvatt, remember to push the packaging changes ;)
[18:54] <Sarvatt> yeah yeah
[18:54] <Sarvatt> i dont have any packaging changes thats why i didnt push
[18:54] <ricotz> i had a look at some drivers which failed on 1.12
[18:54] <Sarvatt> doing it by hand
[18:54] <ricotz> Sarvatt, oh, ok
[18:55] <ricotz> and you can add sis and cirrus to your script
[18:55] <Sarvatt> they arent there on purpose, mga too
[18:55] <Sarvatt> but yeah they can be added back in now
[18:55] <ricotz> this mean video-all and input-all working on 1.12 ;)
[18:56] <ricotz> Sarvatt, https://launchpad.net/~ricotz/+archive/unstable/+packages
[18:56] <Sarvatt> sis cirrus and vmwgfx weren't building against 1.11 at one point
[18:56] <ricotz> they built fine
[18:56] <ricotz> oh, vmwgfx i dont even have there
[18:56] <Sarvatt> cirrus is in there, was just sis missing
[18:56] <ricotz> openchrome got fixed too
[18:57] <ricotz> v4l havent seen any fix
[18:58] <ricotz> ark still used this obsolete/removed symbol
[18:58] <ricotz> xf86MapDomainMemory
[18:59] <tormod> hi guys :)
[18:59] <Sarvatt> heya tormod!!
[19:00] <Sarvatt> ricotz: yay fixed mesa uploaded now, it actually builds
[19:00] <Sarvatt> now to fix those hooks..
[19:00] <ricotz> Sarvatt, good ;), hopefully it works too
[19:01] <ricotz> even gnome-shell wouldnt built :\
[19:02]  * tormod is waiting impatiently for xserver 1.12 :)
[19:03] <ricotz> tormod, you can try it if you want ;)
[19:03] <tormod> ricotz, from your unstable ppa?
[19:03] <ricotz> yes
[19:03] <ricotz> i am running it on intel
[19:03] <Sarvatt> tormod: that'll be in next week for sure, gonna be locked away in a room in budapest doing it :P
[19:04] <tormod> it doesn't need updated evdev?
[19:04] <Sarvatt> if ricotz doesn't want to upload it sooner
[19:04] <ricotz> tormod, only synaptics making some velocity problems
[19:04] <ricotz> Sarvatt, i guess not ;)
[19:05] <Sarvatt> ricotz: we could just copy it out of your ppa..? :P
[19:05] <ricotz> tormod, you might want to wait for a working mesa :P
[19:05] <ricotz> Sarvatt, hmm, no, the driver versions are the same
[19:06] <Sarvatt> copy the server, i'll reupload all drivers
[19:06] <ricotz> i was copying them from edgers everytime
[19:06] <Sarvatt> i meant
[19:06] <ricotz> yeah, these packages would work
[19:06] <ricotz> and the input stuff
[19:08] <ricotz> Sarvatt, could upload a vmwgfx package?
[19:08] <Sarvatt> sorry I meant video-vmware
[19:09] <ricotz> oh, ok
[19:09] <ricotz> i guess this isnt even a driver
[19:10] <ricotz> Sarvatt, so there is no important driver missing then?
[19:10] <Sarvatt> nvidia/fglrx
[19:10] <Sarvatt> nope
[19:11] <Sarvatt> it will suck not having xf86-input-mtrack but might be able to fix that up
[19:11] <ricotz> openchrome should be update in ubuntu since there were 130 commits
[19:11] <Sarvatt> yep that just needs some cut and paste love
[19:12] <Sarvatt> ricotz: talk to the debian maintainer of the driver, i think bryce got crap for sponsoring an update of it for me in ubuntu a few years ago when i was thinking the same thing..
[19:13] <ricotz> hehe ;)
[19:15] <jcristau> eww via.
[19:17] <ricotz> jcristau, i guess you are not the maintainer then :P
[19:17] <tjaalton> Sarvatt: we're doing 1.11, not 1.12 :)
[19:18] <jcristau> ricotz: there isn't really a maintainer
[19:18] <Sarvatt> tjaalton: yeah but edgers wont even take a day and is mostly automated, doubt the 1.11 will take more than 4 :)
[19:19] <tjaalton> Sarvatt: ah you meant both
[19:27] <Sarvatt> bryceh_: did you see https://code.launchpad.net/~smspillaz/unity/unity.fix_864784_868120_872625v2 ?
[19:32] <Sarvatt> http://goo.gl/1e86V indeed
[19:32] <tjaalton> haha
[19:34] <bryceh_> Sarvatt, sweet!
[19:34] <bryceh_> working on http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/blueprint-desktop-p-multi-monitor.html
[19:34] <bryceh_> so I can keep track of all the mm bugs better
[19:35] <Sarvatt> oh https://code.launchpad.net/~smspillaz/unity/unity.oem-fixes is the real branch and it was approved \o/
[19:35] <Prf_Jakob> Sarvatt: hey
[19:36] <Sarvatt> hiya!
[19:36] <bryceh_> "oem-fixes"? huh
[19:38] <Sarvatt> that was a high priority oem bug, blocking release on all kinds of new machines since display switch hotkeys weren't working properly on any system
[19:38] <ricotz> http://lists.x.org/archives/xorg-devel/2011-December/028091.html -- will this still make it into 1.12 somehow?
[19:40] <jcristau> maybe
[19:42] <ricotz> ok
[19:42] <tjaalton> more stuff to backport then, if we hope to have full opengl-3.0 support for precise?
[19:43] <ricotz> tjaalton, was this actually targeted?
[19:43] <tjaalton> ricotz: we'll have mesa 8.0
[19:43] <jcristau> you'll have gl3 on nvidia and fglrx *hides*
[19:43] <tjaalton> heh, true
[19:43] <tjaalton> 4.x even
[19:44] <ricotz> 4.2 ;)
[19:44] <jcristau> wonder what's the point of not shipping 1.12 if you backport 80% of it though
[19:44] <jcristau> anyway...
[19:44] <tjaalton> beginning to feel the same way :)
[19:44] <jcristau> maybe input+glx doesn't quite make 80%
[19:44] <ricotz> nvidia/fglrx are the reasons
[19:45] <ricotz> and it will probably be released/finished quite late
[19:55] <bryceh_> 12.04.2 will have the newer X stack
[19:56] <bryceh_> can afford to be conservative with the 12.04.0 stack
[19:57] <ricotz> bryceh_, right ;)
[19:57] <bryceh_> well, more conservative than we'd otherwise need to be
[20:05] <Sarvatt> frankenserver is still going to need to be supported though, thats not gonna be fun
[20:08]  * bryceh_ nods
[20:09] <bryceh_> hey word from archive folks is a preference for making the 12.04.0 images more easily downloadable, so no boot mangling work needed
[20:35] <Sarvatt> LetoThe2nd: mesa's fixed, safe to update to 7.12.0~git20120104.892a2542-0ubuntu0sarvatt2
[21:00] <bryceh_> here's where the old point releases are kept - http://old-releases.ubuntu.com/releases/lucid/
[21:11] <tormod> bryce, are the sources (for e.g. Intrepid) available somewhere?
[21:13] <jcristau> i assume http://old-releases.ubuntu.com/ubuntu/pool/ has everything
[21:15] <tormod> jcristau, thanks, yes, looks like it
[21:17] <tormod> got a request for xorg-edgers packages for Intrepid today :) Some exotic hw that only runs Intrepid but with a xserver 1.5.2 bug. At least he can find the sources there and patch it.
[21:18] <jcristau> sounds fun.
[21:32] <bryceh_> tormod, also fairly sure you should be able to get the old versions off launchpad too, with sufficient clicking around
[21:32] <tormod> from the ppa?
[21:36] <bryceh_> tormod, no; from e.g. https://launchpad.net/ubuntu/+source/mesa/+publishinghistory
[21:36] <bryceh_> go to the source package page in launchpad, click 'View full publishing history' then pick out whatever version you want
[21:37] <bryceh_> should be able to get pretty much any source and binary .deb's you need
[21:41] <tormod> bryceh_, thanks, yes that works, binaries for those still "published", source even for those "superseded"
[21:58] <FernandoMiguel> evening
[22:57] <broder> is it possible to get 3d acceleration working inside vmware vms with precise right now? do i need edgers or something?
[23:27] <RAOF> broder: I believe you need edgers.  I'm also not sure that precise kernels build the vmware kernel module needed.
[23:35] <broder> hmm, i'll experiment. looks like vmhgfs (host-guest file system) and vmxnet (paravirtualized network driver) don't build on 3.2, but everything else seems good
[23:36] <tjaalton> is the drm driver yet out of staging
[23:36] <RAOF> I *think* it's out of staging?
[23:36] <RAOF> That should mean that it's enabled.
[23:36] <tjaalton> maybe i'm confusing it with another driver..
[23:37] <tjaalton> yeah so it should be.. I'll check
[23:37] <tjaalton> CONFIG_DRM_VMWGFX=m
[23:37] <tjaalton> yep
[23:37] <RAOF> modinfo vmwgfx says hi!
[23:38] <broder> hmm, didn't get loaded, though
[23:39] <broder> and unity-2d doesn't seem to launch
[23:39] <RAOF> On edgers?
[23:39] <broder> yeah. not sure why yet
[23:40] <tjaalton> needs multitouch
[23:40] <broder> :-/
[23:41] <RAOF> At least unity3D should soon work :)
[23:41] <broder> well, i need to convince mesa to not use software rendering before that's useful on my vm
[23:53] <Prf_Jakob> broder: I/We will be interested in hearing about any bugs you run it.
[23:53] <Prf_Jakob> RAOF: what are you currently packaging of mesa/video-vmware?
[23:54] <tjaalton> -vmware 11.0.99.901, mesa 7.11
[23:54] <broder> Prf_Jakob: what am i supposed to have to do to activate the vmwgfx?
[23:54] <RAOF> Prf_Jakob: In precise, currently nothing; we've got 7.11, and (a) I seem to recall you saying not to bother with that, and (b) the kernel module wasn't available until recently.
[23:54] <Prf_Jakob> Ok, mesa 7.11 wont work with kernel driver.
[23:54] <Prf_Jakob> broder: mesa git
[23:55] <Prf_Jakob> broder: tho glxgears seems to have broken over xmas, so I'm looking into that over right now.
[23:55] <RAOF> That'll be one of the things we'll enable when switching to the 7.12/8.0 branch.
[23:55] <broder> Prf_Jakob: xorg-edgers looks like it has a snapshot of 892a2542 - should that be new enough?
[23:55] <tjaalton> I see the drm driver was enabled already on oneiric
[23:57] <tjaalton> but doesn't matter since it needed newer mesa