[00:53] <jasoncwarner_> TheMuso, I mentioned to bryceh in a dm...sure, go ahead and get the case. I don't know where to get it, but get it somewhere and make sure the ARM desktop is working ;)
[00:56] <TheMuso> Yup, just trying to nut out some way that I can test audio functionality on the board without having to disconnect and reconnect stuff to my speakers all the time. :)
[01:03] <RAOF> HDMI audio!
[01:03] <TheMuso> Yeah, thats one of the dilemmas. My monitor has speakers, buyt only stereo. I'd like to make sure 5.1 works at least.
[01:04] <RAOF> Ah.
[01:55] <TheMuso> Oh wow unity/compiz from the unity team staging PPA starts up sooooo much faster now.
[01:55] <TheMuso> But I have no window decoration and no keyboard shortcut to get to a window menu to maximise etc.
[02:22] <robert_ancell> RAOF, any idea on why my wayland listeners don't seem to be working?  I'm connecting up the key bindings and I can see the events being generate in the weston log but my listeners for them don't work either
[02:22] <RAOF> In lp:~robert-ancell/.../weston-compositor?
[02:23] <robert_ancell> y
[02:24] <robert_ancell> RAOF, oh duh. It was my fault
[02:27] <RAOF> Heh
[02:30] <robert_ancell> RAOF, so, how do I control which VT weston runs on?
[02:31] <RAOF> Hm. I think the current answer is ‘you don't’.
[02:32] <robert_ancell> RAOF, is it weston or wayland (or drm) that is picking the VT?
[02:33] <RAOF> Weston
[02:35] <RAOF> Specifically, it'll call VT_OPENQRY on /dev/tty0, which I think will return the first available VT?
[02:36] <robert_ancell> RAOF, ok, so we just need to be able to override that like X does
[02:36] <robert_ancell> yes it does
[02:36] <RAOF> Oh, there we go.
[02:38] <RAOF> You could, if you so chose, open a tty connection yourself, allocate the VT, and then pass the fd of that tty via the WESTON_TTY_FD environment.
[02:39] <robert_ancell> RAOF, uh, can I just pass a --tty to weston?  It seems that's what weston-launch does
[02:39] <RAOF> That'll change which /dev/tty? it's opening, which is not necessarily the same as the VT, right?
[02:40] <RAOF> If my understanding of VT/tty mapping is incorrect, you could certainly just pass --tty to weston.
[03:14] <robert_ancell> RAOF, hmm, I wonder if ConsoleKit is going to freak out having multiple sessions on the same VT
[03:14] <RAOF> Probably.
[03:14] <RAOF> Let's see if it notices!
[03:14] <TheMuso> I thought we were moving away from consolekit.
[03:14] <robert_ancell> TheMuso, if we can
[03:15] <TheMuso> Right.
[03:15] <robert_ancell> I need to check what logind does.  When I raised it with Lennart a while ago he didn't seem convinced but the recent stuff on the list suggest he might be more convinced now
[03:20] <RAOF> robert_ancell: You might also be interested in the systemd-devel/wayland-dev crossover discussion about VTs and systemd and system-compositors.
[03:20] <robert_ancell> RAOF, yeah, that's what I was referring to
[03:20] <robert_ancell> is it on wayland-dev as well?
[03:21] <RAOF> Yeah.
[03:23] <RAOF> Well, most of it (grr)
[03:38] <robert_ancell> RAOF, so you were right about the messed up video being a CK issue.  I have it working now, BUT I need to know what VT weston is runing on, idealy by me setting it
[03:43] <RAOF> Actually, do you really want to be the one setting the VT? What if it's already in use?
[03:43] <robert_ancell> RAOF, I've already picked on
[03:43] <robert_ancell> one
[03:44] <RAOF> How do you do that?
[03:44] <robert_ancell> RAOF, and I need to tell it to run on the same VT as Plymouth
[03:44] <RAOF> Ah, fair point.
[03:45] <robert_ancell> RAOF, but yes, it is an ugly mess and basically relies on the DM being in control of the VTs
[03:47] <RAOF> Perhaps you *do* want --tty 7
[03:47] <robert_ancell> RAOF, that only appears to be on weston-launch, which we don't use right?
[03:47] <RAOF> No; that's a compositor-drm option.
[03:47]  * RAOF again sees the need for --help to work :)
[03:50] <robert_ancell> RAOF, yay! works great - on the correct VT now and CK all happy
[03:50] <RAOF> Woot!
[03:50] <RAOF> Now with sound and GL?
[03:50] <robert_ancell> for me, but not for the second user it seems
[03:51] <RAOF> The second user runs on the same VT, I take it?
[03:51] <robert_ancell> RAOF, yes, by definition
[03:51] <robert_ancell> ck-list-sessions shows both entries but the first user is active and the second one is not
[03:51] <RAOF> And thus the confusion of ConsoleKit begins :)
[03:52] <robert_ancell> I think it needs the VT switch event for it to realise the user has changed
[03:52] <pitti> Good morning
[03:52] <pitti> cyphermox: still here?
[03:53] <pitti> cyphermox: for a start you can run "sudo adt-run --built-tree=. --no-built-binaries --- adt-virt-null"
[03:53] <pitti> cyphermox: unless your test actually has the "build-needed" restriction, then --built-tree -> --unbuilt-tree
[03:53] <pitti> cyphermox: I have a rather small ubuntu server VM where I test what jenkins does
[03:54] <pitti> cyphermox: sudo adt-run --no-built-binaries foo.dsc --- adt-virt-null"
[03:54] <RAOF> robert_ancell: I suspect that lightdm is going to end up subsuming consolekit.
[03:55] <robert_ancell> RAOF, that was an idea I had a long time ago, It pretty much has all the information require
[03:55] <robert_ancell> d
[03:56] <RAOF> It's what spawns the user sessions, it's what the DE talks to to switch user, it's what the DE talks to to log out...
[03:56] <robert_ancell> RAOF, the issue is it only handles graphical sessions, but it could of course handle text ones with a few small changes
[03:57] <robert_ancell> or perhaps the text consoles will dissapear altogether
[03:57] <RAOF> Or be full-screen weston terminals.
[03:57] <robert_ancell> then you have ssh logins
[03:57] <RAOF> Which don't actually *need* access to /dev/dri, or /dev/sound, etc?
[03:57] <robert_ancell> practically, no
[03:58] <RAOF> Likewise, kernel VTs.
[03:58] <robert_ancell> definitely not
[03:58] <RAOF> So I'm not sure if we'd actually lose anything by not tracking non-graphical sessions.
[03:59] <robert_ancell> in the future the kernel could drop support for VTs entirely, which could simplify things quite nicely
[03:59] <RAOF> You could just not hook up Ctrl-Alt-F* to switch_vt; it'd have much the same effect :)
[04:00] <robert_ancell> RAOF, yeah, but I imagine VTs add some complexity into the kernel for video drivers etc
[04:01] <RAOF> Probably a bit, yeah. I'm not very familiar with that.
[04:02] <robert_ancell> RAOF, my composited desktop is sooo blueee.  Need some color management working!
[04:02] <RAOF> You should be able to calibrate it :)
[04:03] <robert_ancell> RAOF, I'm guessing xwayland doesn't support it?
[04:03] <RAOF> ...
[04:03] <RAOF> I'm actually not sure.
[04:03] <RAOF> I think it should.
[04:04] <ceti331> textmode should always remain
[04:04] <RAOF> But it won't recognise your *existing* profile, because weston doesn't pass that info down properly.
[04:04] <robert_ancell> RAOF, oh, I will have to try recalibrating then
[04:04] <RAOF> So I think you should be able to load a profile, but it'll be against the "xwayland-1" display.
[04:04] <ceti331> is there a decent website on wayland
[04:05] <ceti331> i heard it was going to combine compositor and windowmanager, which sounds like a shame because i like the variety of windowmanagers in linux
[04:05] <robert_ancell> ceti331, It depends on how you put it together.  wayland is quite generic
[04:05] <ceti331> is it a library rather than an executable perhaps
[04:05] <robert_ancell> ceti331, yes
[04:06] <ceti331> i mean as you can see from mac OSX (mission control).. and windows 8 - desktop/window managers are hardly a "solved problem"
[04:06] <ceti331> (and see the reaction to unity & gnome3)
[04:06] <ceti331> there are so many ways to do it... and the great thing about linux is you ahve the option to change it
[04:07] <robert_ancell> ceti331, in a wayland system a display manager is a type of compositor.  So you will be able to switch compositors.  For applications to work with multiple compositors there will need to be a common protocol
[04:07] <robert_ancell> this is a similar problem to the current X window manager protocol issues
[04:08] <ceti331> not sure i undertsand all the jargon
[04:08] <robert_ancell> weston is the first compositor/wm that has been implemented, but it's still early days yet
[04:08] <ceti331> i know theres's X which is the low level windowing 'protocol', then the window manager, then desktop-environment... 3 seperate layers
[04:08] <ceti331> oh so "Wayland" is a library used in "weston" ?
[04:09] <robert_ancell> ceti331, right, in weston it's a tree of compositors that take the images from their children and paint that upwards.  The topmost compositor draws to the screen
[04:09] <ceti331> i have to ask, is anyone working on a windowmanager for wayland called "Yutani" ?
[04:09] <robert_ancell> ceti331, no idea
[04:09] <RAOF> Not that I'm aware, no.
[04:09] <ceti331> so thats a tree of texture generators ? .. all textures being painted by opengl?
[04:10] <ceti331> its an obvious name :)
[04:10] <RAOF> It is indeed.
[04:10] <robert_ancell> ceti331, so in the obvious weston system there is a toplevel compositor that switches between user sessions, each session has a compositor that draws windows, and each application is a compositor
[04:10] <ceti331> "each application is a compositor" ... does this run existing applications
[04:10] <RAOF> Well, each application would only want to be a compositor if it needs to embed other windows. Unless you count cairo as a compositor :)
[04:11] <ceti331> or is it a very different model
[04:11] <RAOF> It's a different model.
[04:11] <ceti331> so will it need new GUI toolkits
[04:11] <robert_ancell> RAOF, I have a package for lightdm that has the compositor.  I'd like to put it in your PPA.  Should we make a LP group and start a new PPA?
[04:11] <ceti331> or will GUI toolkits just have a "Wayland" back end
[04:11] <RAOF> The latter.
[04:11] <RAOF> robert_ancell: Sure!
[04:11] <ceti331> e.g. GTK -> (x11,  windows, osx, Wayland..)
[04:12] <robert_ancell> ceti331, that already exists
[04:12] <ceti331> aah o
[04:12] <ceti331> ok
[04:12] <RAOF> Both GTK and Qt have a wayland backend (they might be a bit out of date); EFL *also* has such a backend.
[04:12] <ceti331> Does that require app-recompile
[04:12] <robert_ancell> RAOF, btw I think the weston screensaver turned on and I can't seem to turn it off...
[04:12] <RAOF> robert_ancell: Yeah, I should fix that :)
[04:12] <ceti331> does wayland have a low level drawing api... framebuffer access for cpu even
[04:12] <RAOF> NO.
[04:12] <RAOF> Sorry, no.
[04:12] <RAOF> Wayland has no drawing API.
[04:12] <ceti331> framebuffer or backbuffer
[04:13] <ceti331> whats the interaction between opengl and wayland
[04:13] <robert_ancell> RAOF, can't you just get a memory buffer and fill it in?
[04:13] <ceti331> i've liked using the GLUT library for quick graphical programs
[04:13] <RAOF> You allocate buffers and hand them to the compositor.
[04:13] <RAOF> robert_ancell: Yeah, you can certainly do that.
[04:13] <robert_ancell> I think that's what ceti331 was asking
[04:13] <RAOF> robert_ancell: But that's not actually a drawing API :)
[04:13] <ceti331> yes
[04:14] <ceti331> 'allocate buffers', that answers my question
[04:14] <ceti331> presumably you can 'allocatebuffers' that the CPU can modify or poopulate
[04:14] <ceti331> still curious to know how openGL will interact with wayland
[04:15] <RAOF> The GL implementation will allocate buffers, and hand them to the compositor.
[04:15] <RAOF> Pretty much the same way it works now, really.
[04:15] <ceti331> so its GL implementations that need to be re-coded in a wayland friendly manner
[04:15] <ceti331> whereas at presetnt they are X11 friendly
[04:15] <RAOF> Well, you do need a wayland GL implementation, yes.
[04:15] <ceti331> that level of change does sound a big scary
[04:15] <RAOF> You can't use GLX, obviously, because it's an X11 protocol.
[04:16] <RAOF> Eh, EGL already works.
[04:16] <ceti331> bit scary, e.g. updating driver support etc
[04:16] <RAOF> All the free drivers work now.
[04:16] <ceti331> ok
[04:16] <RAOF> And it's not particularly difficult to add that support.
[04:16] <ceti331> so is wayland something that will streamline some layers
[04:17] <RAOF> Yes.
[04:17] <robert_ancell> ceti331, remember wayland wasn't redesigned from scratch - it's built from the components that X was already using
[04:17] <ceti331> and perhaps make future maintainance easier
[04:17] <RAOF> Also yes.
[04:17] <robert_ancell> understatement of the year
[04:17] <RAOF> It'll make developing window managers and compositors *substantially* easier.
[04:17] <ceti331> ok, cool.
[04:17] <robert_ancell> second understatement of the year
[04:18] <ceti331> i recall apple saying X11 was retarted which is why they did quartz compositor
[04:18] <RAOF> It's got some terrible parts, yes.
[04:18] <ceti331> so actually having the drawing API built into X is a pain ?
[04:18] <ceti331> too much legacy
[04:18] <ceti331> obselete primatives
[04:20] <ceti331> i was interested in modifying compiz plugins - but haven't as yet managed to run what i've compiled .. just compiling compiz from launchpad, something is broke
[04:20] <ceti331> the desktop experience i'm after is: Mountain Lion (apples' expose back to normal, but with horiz row of desktop thumbnails)
[04:21] <robert_ancell> RAOF, hmm, so it seems we don't have administration rights for a PPA in ~ubuntu-desktop
[04:21] <ceti331> X11 goes back to mid 1980s ?
[04:22] <RAOF> Earlier than that, I think.
[04:22] <RAOF> robert_ancell: Yeah, that seems to be my experience too.
[04:23] <robert_ancell> RAOF, that does seem like the right place for it though..
[04:23] <RAOF> Eh, we can just make a new team.
[04:23] <RAOF> Although it would be nice to do it under ~ubuntu-desktop.
[04:23] <ceti331> wayland uses GLES2.0 ? lovely!
[04:23] <robert_ancell> RAOF, we could put it in lightdm-team.  Or an X team?
[04:23] <RAOF> pitti: Yo! Would you be so kind as to create a system-compositor PPA under ~ubuntu-desktop?
[04:24] <robert_ancell> RAOF, can we upload to it?
[04:24] <RAOF> I don't see why we wouldn't be able to; we're members of ~ubuntu-desktop. We just can't create one, because we're not admins (unlike seb & pitti)
[04:25] <robert_ancell_> go pitti!
[04:25] <pitti> looking
[04:25] <ceti331> what can you run with wayland at the moment
[04:26] <robert_ancell> heading out, be back in 45mins or so
[04:27] <pitti> Let there be https://launchpad.net/~ubuntu-desktop/+archive/system-compositor !
[04:27] <pitti> RAOF, robert_ancell ^
[04:27] <RAOF> pitti: Ta muchly!
[04:32] <ceti331> anyone got any ideas what can break a compiz install
[04:32] <ceti331> i set out to build a compiz plugin ... originally tried from compiz.org but, being on ubuntu, i figured I should be building compiz from launchpad instead
[04:33] <ceti331> since doing that compiz has ceased working... I can't fix it by apt-get re-install.
[04:33] <ceti331> I thought i had files left over /usr/local/bin vs /usr/bin - but deleted these and it still doesn't work
[04:33] <thumper> ceti331: do you have a ~/.compiz-1 directory
[04:33] <ceti331> ah let me check
[04:33] <thumper> where did you build it to?
[04:34] <ceti331> ls ~/.compiz-l   ... no
[04:34] <thumper> one not L
[04:34] <ceti331> yes that is there
[04:34] <ceti331> damn my xchat font
[04:35] <thumper> so if there is something in there, it will be attempted to be loaded by compiz at startup
[04:35] <thumper> if it has a different ABI
[04:35] <thumper> it may crash compiz
[04:35] <ceti331> thanks
[04:35] <thumper> anything in the ~/.compiz-1/plugins directory
[04:36] <ceti331> oh its only got "sesson"
[04:36] <ceti331> but i presume taht is settings taht could break it
[04:36] <thumper> ok, won't be that then
[04:36] <thumper> maybe
[04:36] <thumper> try moving it out of the way
[04:36] <ceti331> i'm pretty sure i compiled into "/usr/local/bin
[04:36] <ceti331> but compiz installs by default in /usr/bin ?
[04:37] <ceti331> my /usr/local/bin is now empty
[04:37] <ceti331> i'lll try what you advised..
[04:45] <ceti331> ok removal of ~/.compiz-1 didn't help
[04:45] <ceti331> i give in , I will re-install
[04:45] <ceti331> re-install distro
[04:48] <ceti331> wayland will allow switching between different user sessions more easily?
[04:48] <ceti331> I gather Android differs from desktop linux in that every app is a user
[04:49] <ceti331> i read that weyland would allow effects/compositing when switching user sessions
[05:09] <RAOF> The system-compositor will, yes.
[05:16] <ceti331> android makes a user per app for sandboxing i guess
[05:30] <robert_ancell> RAOF, is there a wiki page anywhere with system compositor stuff?  If not, I plan on doing something like https://wiki.ubuntu.com/Wayland/SystemCompositor
[05:31] <RAOF> robert_ancell: There is not, no. Not as far as I'm aware.
[05:44] <RAOF> Gah. Evolution, stop losing my mail server settings!
[05:55] <robert_ancell> RAOF, I've updated https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-system-compositor.  There's some spaces where we should file bugs (e.g. the washed out login screen)
[05:55] <RAOF> Did I not already file that bug and associate it with the blueprint? Bah.
[06:09] <didrocks> good morning
[06:19] <pitti> bonjour didrocks
[06:19] <didrocks> hey pitti
[06:24] <pitti> urgh, I have to turn the light on in my working room -- outside it looks like the world is officially going to end now
[06:24] <pitti> haven't needed light for months
[06:36] <pitti> RAOF: "The Unity panel can't be accessed with the mouse when set to autohide"
[06:36] <pitti> RAOF: is that really a compositor problem?
[06:36] <pitti> starting from today, I cannot access the launcher/dash at all
[06:37] <pitti> they are painted behind all other windows
[06:37] <didrocks> pitti: quantal?
[06:37] <pitti> RAOF: and do you really mean "panel" here or "launcher"?
[06:37] <pitti> didrocks: yes, du jour
[06:37] <didrocks> pitti: yeah, there is a stacking issue that can happen sometimes, it's not from latest release
[06:37] <RAOF> pitti: Yup, it's a compositor problem; specifically, it's because X is receiving it's input from weston, which is clipping it to the visible display, but Unity requires that X get out-of-range inputs.
[06:37] <tkamppeter> pitti, can you upload CUPS to Debian and Ubuntu? Thanks.
[06:38] <pitti> tkamppeter: can do
[06:38] <didrocks> RAOF: ah, so it's an underlying change? For me, it started some days ago, with the previous release
[06:38] <RAOF> didrocks: No, unless you're running from ppa:~ubuntu-desktop/system-compositor this is nothing to do with whatever crack Unity bug you're running into :P
[06:38] <pitti> RAOF: how bad is the incorrect screen resolution? I'm pondering trying this, but not if I end up with an 1024x768 screen
[06:40] <RAOF> pitti: It depends on your display and drm driver, I think. On *my* 1366x768 display weston incorrectly reports 1360x768, so X has left 6 pixels down the right side.
[06:42] <pitti> ah, I can spare 6 pixels :)
[06:42] <RAOF> That PPA also won't work until I upload a mesa that'll build to it.
[06:44] <pitti> tkamppeter: reverting the tiff build dep, FYI
[06:44] <pitti> tkamppeter: it's not yet our preferred libtiff, and not appropriate yet for Debian either
[06:44] <tkamppeter> pitti, OK, so the change of -3ubuntu1 is undone?
[06:45] <pitti> argh
[06:45] <pitti> tkamppeter: yes, it will be
[06:45] <pitti> the correct way to switch ubuntu to libtiff5 is to move the "Provides: libtiff-dev" from libtiff4 to libtiff5
[06:46] <pitti> instead of changing a gazillion source packages
[06:46] <pitti> tkamppeter: also, please don't commit the XSBC-Original-maintainer: bits to Debian
[06:46] <pitti> tkamppeter: I'm looking at the two RC bugs in Debian and the hurd patch, and will upload then
[06:49] <tkamppeter> pitti, the XSBC-Original-maintainer seems to have got in by someone else, I did not do that intendedly. Probably it came in from merging in the changes of -3ubuntu1 from the diff linked in the changelog in Launchpad.
[06:49] <pitti> tkamppeter: right, it did come from the merge; it's correct for Ubuntu uploads, but not for Debian
[07:06] <pitti> tkamppeter: uploaded
[07:09] <pitti> RAOF: taking the plunge then; I'll blame you if my workstation gets broken :)
[07:10] <RAOF> ♪ There's room for your dog ♫
[07:11] <pitti> RAOF: OOI, why do I need to start lightdm once wtih type=weston and then remove it again?
[07:11] <pitti> RAOF: or is that just the step to disable the compositor again?
[07:12] <pitti> (but still running with the new libraries)
[07:12] <tkamppeter> pitti, thanks.
[07:12] <RAOF> Robert wrote those instructions; I believe the answer is so that you get standard X next time.
[07:12] <pitti> ah, ok
[07:12] <pitti> so, reboot, brb (hopefully)
[07:12] <RAOF> It'll not work yet
[07:13] <RAOF> Still no functioning mesa!
[07:13] <RAOF> pitti: Ah, I see what's confusing.  “When done” means “Once you're done testing”
[07:13] <RAOF> I see that we've not got appropriate version dependencies on the packages ;)
[07:26] <chrisccoulson> hey desktoppers
[07:26] <pitti> RAOF: hm, no joy here
[07:27] <pitti> RAOF: after stopping/starting lightdm, my external TFT went black with "frequency not supported", and the internal one showed the "x failed to start" dialog
[07:27] <pitti> RAOF: after reboot, everything went completely black
[07:27] <RAOF> You clearly missed the bit where I said “this is not actually going to work yet, until I fix mesa”
[07:27] <pitti> I disabled the "weston" seat type again
[07:27] <RAOF> Sorry about that.
[07:27] <pitti> RAOF: oh :)
[07:28] <pitti> RAOF: robert sent out a call for testing a little too early then
[07:28] <RAOF> Oh. He sent a call for testing out to the mailing list?
[07:28] <RAOF> Ooops.
[07:29] <pitti> RAOF: https://lists.ubuntu.com/archives/ubuntu-desktop/2012-July/003890.html
[07:29] <pitti> RAOF: well, he did say to contact you first
[07:30] <RAOF> Time to reply to that and say "not just yet, mesa's not built!"
[07:40] <mlankhorst> RAOF: but did you build libdrm yet?
[07:40] <RAOF> mlankhorst: No, but I've got a snapshot in the PPA too.
[07:41] <mlankhorst> oh I already did for precise
[07:45] <mlankhorst> been using it for testing mesa, that's why i wanted it to  be uploaded to quantal
[08:05] <seb128> hey
[08:05] <RAOF> Hey, yo!
[08:06] <mvo> hey seb128
[08:06] <seb128> hey RAOF, mvo
[08:07] <seb128> mvo, weirdly you start saying hello again today ... less scarred to be pinged back with nagging? ;-)
[08:07] <seb128> mvo, thanks for getting that SRU tested!
[08:07] <mvo> seb128: exactly ;)
[08:07] <mvo> seb128: not feeling like I need to hide in shame today
[08:08] <mvo> seb128: thanks for the constant reminder, it wsa important
[08:09]  * seb128 hugs mvo
[08:09]  * mvo hugs seb128
[08:09] <pitti> bonjour seb128
[08:09] <pitti> hallo mvo, wie gehts?
[08:09] <seb128> pitti, hey, wie gehts?
[08:09] <mvo> hey pitti, good, thanks! how are you?
[08:09] <pitti> seb128: je vais bien, merci!
[08:10] <pitti> trying to get my kernel and udev patches upstream, and writing autopkgtests like mad :)
[08:11] <seb128> pitti, what do you need to patch the kernel for?
[08:11] <seb128> just curious ;-)
[08:11] <pitti> seb128: for making scsi_debug fake removable devices
[08:11] <seb128> pitti, btw please keep posting your progresses on google+, I like to read those ;-)
[08:11] <pitti> it's a silly and simple patch, but would help a bit to test udisks and gvfs
[08:11] <pitti> seb128: ah, I moved some of them to my Canonical me
[08:11] <pitti> as I thought they were too much detail/too uninteresting for the general public
[08:11] <mvo> pitti: autopkgtest is something I need to investigate for s-c too!
[08:12] <pitti> mvo: didn't we already have s-c being tested in jenkins?
[08:12] <pitti> and mterry needs to fix the autopkgtest for update-maanger and release-upgrader
[08:12] <mvo> pitti: yeah, but I'm not sure its using autokgtest for this
[08:12] <pitti> nasty red dots on https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/
[08:13] <pitti> mvo: I don't think it's still being tested at all
[08:13] <mvo> oh, ok
[08:13] <pitti> mvo: but yes, with dep-8 it's a lot easier; zero changes necessary in jenkins
[08:13] <pitti> it just picks up new packages automatically
[08:13] <pitti> and there's a standard way to test them locally
[08:13] <mvo> its a pre-upload hook, so its tested locally here, but getting it there is much better
[08:13] <mvo> cool
[08:13] <pitti> I guess update-manager mostly needs a python-mock dep in debian/tests/control
[08:14] <mvo> pitti: it has a python3-mock one there
[08:15] <pitti> https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-update-manager/ARCH=i386,label=albali/9/console
[08:15] <pitti> nose.plugins.cover: ERROR: Coverage not available: unable to import coverage module
[08:15] <pitti> ah, so it was that one, not mock
[08:16] <mvo> aha, cool
[08:17] <pitti> probably best to test that in a server VM/pbuilder etc. first, it's rather common for them to break on missing deps
[08:33] <BigWhale> Good Morning.
[08:40] <pitti> seb128: do you have anything for gtk+? if not, I'd do an upload now to get the new autopkgtest into jenkins
[08:41] <seb128> pitti, hum, maybe, wait a minute please ;-)
[08:44] <pitti> seb128: sure, no prob; stashed in bzr, and I tested locally; it's not actually that urgent
[08:46] <seb128> pitti, I'm pondering turning on the wayland backend, we had a request for that before precise, I think now would be a good time for it
[08:47] <seb128> pitti, hum, that's going to take me a while to test though, I'm still on precise on my main box ... so please just go ahead with the upload, I can do another one tomorrow if needed, there is no hurry there
[08:47] <pitti> seb128: as you wish; likewise it's not urgent to upload the autopkgtest either
[08:48] <pitti> is there any way to start wayland on a headless VM?
[08:48] <seb128> pitti, no please upload, looking on my todo it's likely the wayland stuff will slip back for a day or two
[08:48] <pitti> would be interesting to add an autopkgtest for that then, similar to the two I added with xvfb-run
[08:48] <pitti> seb128: ack
[08:48] <seb128> pitti, I don't know, a question for RAOF I guess
[09:00] <xclaesse> does ubuntu installer support partitions on encrypted LVM nowadays? or should I still use the text-based installer?
[09:04] <chrisccoulson> hey seb128, how are you?
[09:08] <seb128> chrisccoulson, hey, I'm good, how are you?
[09:08] <chrisccoulson> tired :)
[09:09] <seb128> xclaesse, you should probably ask on #ubuntu-devel but I guess it's going to be the second one, there is work to bring the missing features to the desktop installer but I don't think it has been finished yet, maybe this cycle
[09:14] <didrocks> hey chrisccoulson ;)
[09:14] <seb128> chrisccoulson, how is Maisie doing?
[09:14] <seb128> chrisccoulson, waking you up every hour at night? ;-)
[09:15] <xclaesse> seb128, ok thanks :)
[09:15] <seb128> chrisccoulson, lol, just reading your new tweet, Ruby learnt to like thunderstorm from you? ;-)
[09:15] <chrisccoulson> hey didrocks :)
[09:16] <chrisccoulson> seb128, yeah, we didn't get much sleep last night. maisie is nocturnal ;)
[10:16] <jasoncwarner_> hey chrisccoulson how are things?
[10:27] <chrisccoulson> hi jasoncwarner_. things are good thanks! how are you?
[10:34] <RAOF> pitti: Yes, you could do a headless wayland; if nothing else, you should be able to run weston with the x11 compositor under xvfb.
[10:35] <pitti> RAOF: that might be a workable thing to do for a smoketest of the gtk wayland backend in autopkgtest then?
[10:35] <RAOF> Yeah, I think so.
[10:35] <RAOF> You'd start xvfb, start weston under xvfb, and then profit.\
[10:35] <pitti> nice
[10:36]  * pitti off for ~ 3 hours, bbl
[10:43] <seb128> Laney, hey, there?
[10:43] <Laney> seb128: yeah, a bit.
[10:44] <Laney> thanks for looking at gsd!
[10:44] <seb128> Laney, yw
[10:44] <seb128> Laney, I'm starting pondering if we should stay on g-s-d g-c-c 3.4 this cycle
[10:44] <Laney> It might be easier, yeah.
[10:45] <Laney> as long as other components aren't going to rely on the new versions?
[10:45] <seb128> no, g-s-d g-c-c are pretty separate from everything else
[10:45] <Laney> and what's the plan with that ubuntu-control-center fork?
[10:45] <seb128> (out of maybe gnome-shell)
[10:45] <seb128> Laney, #ps is just overworked I doubt they will get to it this cycle
[10:45] <Laney> ok
[10:45] <seb128> and our design delta is starting to be lower
[10:46] <Laney> so we'll still need to work out a plan for dealing with the patches there
[10:46] <seb128> GNOME took some of our changes and is going to take our sound panel redesign
[10:46] <seb128> and our designer are working upstream
[10:46] <seb128> and we will be able to drop the gsettings revert patches soon
[10:46] <seb128> so we should be back to a reasonable delta
[10:46] <Laney> like the big one we're having trouble with now
[10:46] <Laney> i guess it will basically be a rewrite
[10:47] <seb128> which one?
[10:47] <Laney> the indicator one
[10:47] <seb128> right
[10:47] <seb128> well we need a proper keyboard-indicator
[10:47] <Laney> ya
[10:47] <seb128> i.e a standalone source like the indicator-{session,messages,sound,...}
[10:48] <Laney> it still needs to be done though
[10:48] <Laney> will ps work on that?
[10:48] <seb128> Laney, how likely is the "replace language-selector by region panel" likely to happen this cycle in your opinion?
[10:49] <seb128> Laney, I'm think we should maybe stay on 3.4 and postpone that one to next cycle and focus on other stuff
[10:49] <Laney> I think that it doesn't make sense to do that if we're staying on 3.4 indeed
[10:49] <seb128> well, #ps said they were looking at hiring somebody to do the keyboard stuff properly but they have difficulties to file the position, no good candidate so far it seems
[10:49] <seb128> I wouldn't count on it for this cycle
[10:50] <Laney> it's probably a good candidate to defer
[10:50] <seb128> ok
[10:50] <seb128> Laney, I will look a bit into details and start a discussion about staying on 3.4 for those for this cycle
[10:50] <Laney> also gives them a cycle to fill that position
[10:50] <seb128> on ubuntu-desktop@l.u.c
[10:50] <Laney> should confirm with gnome 3 guys too
[10:50] <seb128> right, that's why I want a list discussion in any case
[10:51] <seb128> but I'm really not confident with the keyboard stuff
[10:51] <Laney> I would be dubious about doing any big reverts
[10:51] <seb128> it's turning into a big discussion on desktop-devel-list upstream
[10:51] <Laney> well, I think upstream are clear on what they want to do
[10:51] <Laney> there are just some other objectors but I don't see them stopping progress
[10:52] <seb128> right, I'm just not very confident that will turn out to be something working fine without regression in the half of the cycle remaining
[10:52] <Laney> well it still hasn't landed, so yeah.
[10:52] <seb128> that, and it might not cover some usecases that were covered before
[10:52] <seb128> or hit some missing features in the first iteration
[10:52] <Laney> I think we could put something in a ppa
[10:52] <seb128> which might be fine for us but not acceptable regression from our point of view
[10:52] <seb128> yes, for sure
[10:52] <Laney> and ask people to report what doesn't work for feedback
[10:53] <seb128> added that once they do it we need to deal with the indicator-keyboard on our side
[10:53] <seb128> since they basically threw away the status icon we patched
[10:53] <Laney> yes I think that is a real blocker for us
[10:53] <seb128> ok
[10:53] <Laney> it's something that should be fed back to ps I suppose
[10:53] <seb128> I'm postponing the language-selector->region capplet work items then
[10:53] <Laney> ok
[10:53] <seb128> and I will start a discussion about gsd gcc versions on the list
[10:54] <Laney> maybe the font stuff pitti mentioned is still in scope, will look into that
[10:54] <Laney> I think it's a bit separate anyway
[10:54] <seb128> Laney, can you still try to look at "Move fontconfig-voodoo hacks into individual font packages: TODO"?
[10:54] <Laney> hah
[10:54] <seb128> ;-)
[10:54] <seb128> Laney, it's separated, those are purely distro and packaging stuff
[10:55] <Laney> seems nobody really knows what it's about, so I'll do some digging
[10:57] <seb128> Laney, thanks, pitti probably knows a bit of the details if anyone around does
[12:49] <didrocks> pitti: when you are back, I would have some small questions about testing the user session migration script program. Basically I'll to end to end tests, checking the output under some conditions of the process and the file results
[12:50] <didrocks> pitti: I was wondering as it's a c program if doing some test in python (which would be the easier) is suitable? for both package build and then test in our infra on a real system (I would need some pointer as well about the new debian/control tag)
[13:02] <dobey> mlankhorst: did you see my last comment on bug #1021924 ?
[13:02] <ubot2> Launchpad bug 1021924 in xorg "Multiple Displays not working on Core i7 3770S + Intel DQ77MK motherboard" [Wishlist,New] https://launchpad.net/bugs/1021924
[13:06] <mlankhorst> dobey: you have 2 2048x1152 screens on hdmi?
[13:08] <dobey> mlankhorst: on dvi. don't have hdmi at all
[13:08] <gareththered> I'm trying to have a patch to libgphoto2 merged as a SRU.  Does anyone know what LP branch I should send the merge request to?  There is no 'proposed' in libgphoto2 for Precise!
[13:09] <mlankhorst> dobey: just for testing what if you lower the resolution on both?
[13:10] <dobey> mlankhorst: how low? second screen still red with 1920x1200
[13:10] <seb128> gareththered, just add the patch (or better a debdiff) to the bug and subscribe ubuntu-sponsors
[13:11] <mlankhorst> dobey: just try 2x 1024x768 i guess
[13:11] <seb128> gareththered, the -updates -proposed serie are just created when something is uploaded there, which is not the case of libghoto2 yet, it's just easier to go the debdiff way for a SRU
[13:12] <gareththered> OK.  I can do that.  And subscribe ubunutu-sru to the bug?
[13:13] <desrt> hi hackers
[13:15] <seb128> gareththered, no, ubuntu-sru will be subscribed by the sponsor on upload (I will likely to that today)
[13:15] <seb128> desrt, good morning
[13:15] <seb128> desrt, now I can properly complain about you being behind trend :p
[13:15] <seb128> desrt, http://status.ubuntu.com/ubuntu-quantal/u/desrt.html
[13:15] <desrt> blah blah
[13:16] <seb128> desrt, I postponed the "look at making the gsettings to gconf parse the xmls directly" it's not important and I doubt you will get to it this cycle
[13:16] <desrt> good!
[13:16] <seb128> desrt, should I postpone the gtk patches one as well?
[13:16] <seb128> "reduce the number of gtk patches"
[13:16] <gareththered> seb128: Oops! I've just undone that second bit then!  Thanks for your help.
[13:16] <desrt> no
[13:16] <desrt> i may get to that
[13:16] <seb128> desrt, ok
[13:16] <desrt> or maybe not
[13:16] <desrt> we can postpone it later if needed
[13:16] <seb128> we have time to postpone at the end of the cycle
[13:17] <seb128> right
[13:17] <pitti> seb128, didrocks: back
[13:17] <didrocks> hey ;)
[13:17] <seb128> pitti, ola ;-)
[13:18] <pitti> didrocks: it does not matter much whether you write the DEP-8 tests in C, Python, shell, or something else
[13:18] <pitti> didrocks: it's slightly less convenient in C as you'd have to build the package first (Restrictions: needs-build)
[13:18] <didrocks> pitti: yeah, what is your personal advice, going with python or shell?
[13:18] <dobey> mlankhorst: oops, i apparently screwed up my display. both screens are black now. had done 2048x1152 + 1280x800; first screen went black, and second screen showed the background wallpaper, and after the "keep these settings?" timeout went black
[13:18] <pitti> Laney: the -voodoo stuff is part of language-selector ATM (a script and some data files)
[13:19] <pitti> Laney: if you change your locale to e. g. zh_CN, it drops some fontconfig.d snippets into /etc
[13:19] <pitti> didrocks: I'd try to use a non-compiled program; easier to test and faster to run
[13:19] <mlankhorst> dobey: you can use xrandr next time
[13:19] <pitti> didrocks: you can also run snippets of python from shell, or vice versa, doesn't matter much
[13:20] <didrocks> pitti: ok, will do that then! and look then at DEP-8 once I get them running during build :)
[13:20] <pitti> Laney: which is rather evil, and breaks if you then switch your locale to something else (e. g. another user)
[13:20] <mlankhorst> dobey: xrandr -q (look for names) xrandr --output name1 --mode 1024x768 --output name2 --mode 1024x768
[13:20] <pitti> Laney: it'd be much better to ship those fontconfig snippets in the corresponding fonts-* pacakges, and change them to be locale specific (fontconfig can do that AFAIK, some <locale> tags)
[13:20] <pitti> Laney: that's pretty much everything I know about it, though :/
[13:21] <Laney> pitti: ok right, so basically now they are somewhat more unconditional than they should be
[13:21] <pitti> right, and they require you to run language-selector first, too
[13:22] <Laney> right, thanks
[13:23] <seb128> pitti, http://cgit.freedesktop.org/udisks/commit/?id=3fbd4dc4 was fine to SRU for you? did you plan an udisk SRU yourself or it's good to be picked by any sponsor (it's in the sponsoring queue)
[13:24] <seb128> pitti, same question for https://launchpadlibrarian.net/107860536/fix-race-condition-of-serio-driver-module-not-loading.patch
[13:25] <pitti> seb128: the rts5229 patch is fine for any sponsor
[13:25] <seb128> pitti, danke
[13:25] <pitti> seb128: the second one is a bit more debatable, but for SRU it's the right thing
[13:25] <pitti> it's not applied upstream, though, as it's a bit of a hack
[13:25] <seb128> pitti, well, the hwcert guys seem to care so I think it's better than nothing for precise
[13:26] <pitti> yes, absolutely
[13:26] <pitti> it's better than a "real" fix for an SRU, as it's quite safe
[13:26] <seb128> pitti, thanks! ;-)
[13:26] <pitti> and we don't really know what a real fix would look like yet, anyway
[13:27] <dobey> mlankhorst: ok, they both seem to display "properly" at 1280x80 for both, but above that only the primary seems to display
[13:28] <mlankhorst> what chip was it again?
[13:28] <mlankhorst> oh ivb
[13:28] <dobey> yeah, ivybridge
[13:29] <dobey> i7 3770S
[13:34] <mlankhorst> dobey: if you do xrandr --output name1 --off and --output name2 --mode (whatever it was) the second screen works correctly right?
[13:34] <dobey> mlankhorst: yeah
[13:36] <dobey> but mirroring the displays or trying to use both unmirrored, the secondary screen doesn't display properly.
[13:36] <dobey> and xrander also shows this:
[13:36] <dobey> Screen 0: minimum 320 x 200, current 2048 x 1152, maximum 8192 x 8192
[13:36] <dobey> so the virtual size is smaller than the max still
[13:36] <mlankhorst> and both screens in 2048x1152 regardless of mirrored fails :s
[13:37] <dobey> yeah
[13:37] <dobey> except for the fact that taking a screenshot does include the full set of screens
[13:44] <mlankhorst> ok created an upstream bug for it :)
[13:46] <dobey> thanks
[13:46] <mlankhorst> dobey: they want you to install intel_reg_dumper from intel-gpu-tools, reboot with drm.debug=0xe added to cmdline, and have the syslog output and output from intel_reg_dumper after red screen
[13:46] <mlankhorst> 15:45 < danvet> also, does crtc switching change anything? (xrandr --output HDMI1 --auto --crtc 1)
[13:46] <mlankhorst> 15:46 < danvet> maybe it's only an issue on one crtc, debug crap left behind by the bios
[13:46] <mlankhorst> 15:46 < danvet> also, does switching output ports between displays change anything?
[13:49] <dobey> switching output ports == swap dvi plugs at the card?
[13:49] <mlankhorst> I'd guess so
[13:50] <mlankhorst> 15:50 < danvet> plug the red display into the DVI port that works, the working display into the DVI port that shows the red display
[13:50] <mlankhorst> #intel-gfx
[13:52] <mlankhorst> dobey: http://paste.debian.net/178619/
[13:56] <dobey> mlankhorst: hrmm, freenode won't let me send to that channel for some reason
[13:56] <mlankhorst> dobey: need to be identified with nickserv
[13:57] <dobey> :-/
[13:57] <dobey> anyway
[13:57] <mlankhorst> but yeah basically they're trying to find out what part is going wrong so just add it to the bug because we're both busy with other things atm :)
[13:57] <dobey> mirroring is working now, having specified --crtc 1 for the primary, and --crtc 2 for the secondary
[13:58] <mlankhorst> what about the failure, can you reproduce it at least?
[14:00] <dobey> well, the secondary screen is no longer red right now, after all this debugging. it's just black now. but if i change anything in the display preferences to disable mirroring and such, it goes back to being a blank second screen. and i have to do the --crtc to xrandr again to get mirroring to display on both
[14:01] <mlankhorst> dobey: can you add the things to the bug report that were asked? :-)
[14:02] <dobey> yes
[14:05] <mlankhorst> preferably on the fd.org bug
[14:09] <dobey> ok
[14:20] <bcurtiswx> good morning
[14:20] <seb128> desrt, btw, you will probably not like it but I will suggest we stay on g-s-d,g-c-c 3.4 for quantal
[14:22] <Laney>   * debian/patches/05_keyboard_indicator.patch:
[14:22] <Laney>     - Backported patch from trunk to fix various keyboard layout issues
[14:22] <Laney>       preventing greeter keyboard indicators from working.
[14:22] <Laney> oops
[14:25] <desrt> seb128: why is that?
[14:26] <seb128> desrt, cf #gnome-hackers backlog
[14:26] <seb128> desrt, basically the ibus stuff is scary, has regression which might be or not be fixed for 3.6 depending on timeframes, and depends on ibus changes that ibus upstream doesn't really agree with yet
[14:27] <seb128> desrt, it seems like a recipe for getting screwed
[14:27] <desrt> seb128: i think you are being a bit dramatic at this point
[14:27] <seb128> desrt, well, paranoid rather
[14:27] <desrt> there are a couple of months for this to get resolved
[14:28] <seb128> desrt, but I take into account that it means we might need to write an indicator-keyboard, and we have neither available resources nor people who have the knowledge about ibus and input methods
[14:30] <desrt> seb128: i think you need a vacation :)
[14:30] <seb128> desrt, lol
[14:51] <tkamppeter> pitti, should we not close bug 1008837 as Invalid? We do not support systemd.
[14:51] <ubot2> Launchpad bug 1008837 in cups "cups fails to install/upgrade with systemd" [Wishlist,Triaged] https://launchpad.net/bugs/1008837
[14:52] <tkamppeter> pitti, why do you consider it "Wishlist"?
[14:56] <ogra_> hmm, i have an intresting theme error in rhythmbox on precise ... using the radiance theme and hovering over the back button in the UI makes the button bar jump (feels like the hovered button is smaller than the unhovered and the toolbar follows suit in resizing)
[15:01] <seb128> ogra_, in what mode is your toolbar?
[15:01] <seb128> ogra_, does it happen every time?
[15:01] <ogra_> uhm, mode ? i didnt change anything
[15:01] <seb128> ogra_, doesn't seem to happen here
[15:02] <ogra_> hmm, no, it stopped here too after i closed RB and re-opened
[15:02] <ogra_> weird
[15:03] <ogra_> just ignore me then :)
[15:10] <pitti> tkamppeter: fine for me to just close it, if you prefer
[15:52] <tkamppeter> pitti, I will do so, as a "Wishlist" is a Feature Request and this should not be titled "Package xyz does not install ...".
[16:21] <mdeslaur> @pilot out
[16:21] <mdeslaur> gah
[16:29] <bcurtiswx> how do I disable all window effects
[16:32] <seb128> bcurtiswx, you mean? select gnome classic (no effects) on the login screen?
[16:33] <bcurtiswx> that may be it, im having too many window freezing issues, i am getting annoyed
[16:41] <bcurtiswx> ubuntu and ubuntu 2d were my options, and it seems 2d (so far) doesn't freeze my any window
[16:41] <bcurtiswx> mabe NVIDIA and 3d still don' get along ?
[16:42] <mlankhorst> nouveau?
[16:42] <bcurtiswx> mlankhorst, yes
[16:42] <mlankhorst> might have to run updates
[16:43] <bcurtiswx> mlankhorst, you mean apt-get update/upgrade ?
[16:43] <bcurtiswx> with the precise-updates
[16:44] <bcurtiswx> i have all updates, they still did not behave well (saw a compiz revert with this AM's install)
[16:47] <bcurtiswx> does 2d allow dragging windows to the side and taking up half screen still? i seem to have lost that ability.
[16:48] <desrt> seb128: so what do the options look like with respect to a test build of my new dconf branch?
[16:48] <seb128> desrt, what do you mean by test build? getting it in hands of users? or getting it in jenkins or automatically tested?
[16:48] <desrt> the first
[16:49] <seb128> bcurtiswx, no it doesn't
[16:49] <seb128> desrt, ubuntu-desktop ppa?
[16:49] <desrt> just to scare you a bit:  105 files changed, 6789 insertions(+), 3153 deletions(-)
[16:49] <desrt> there's almost definitely gonna be some bugs lurking in there somewhere :)
[16:49] <seb128> desrt, the ppa on quantal serie seems fine for that
[16:49] <desrt> ah
[16:50] <bcurtiswx> seb128, thx
[16:50] <desrt> i guess that means i should upgrade to quantal :)
[16:50] <seb128> it's still early in the unstable cycle and it's a ppa so...
[16:50] <seb128> desrt, well does the rewrite depends on new glib or something?
[16:50] <desrt> yes
[16:50] <seb128> desrt, so yes ;-)
[16:50] <desrt> actually it doesn't yet
[16:50] <desrt> but it should :)
[16:51]  * desrt fixes that
[16:54] <desrt> blah.  the glib depend isn't the problem
[16:54] <desrt> the editor already depends on vala 0.17, though
[17:00] <seb128> desrt, well, vala would not reflect on the depends
[17:00] <seb128> desrt, i.e I was wondering if the quantal binaries would install on precise
[17:00] <desrt> well, sort of
[17:00] <desrt> it's that stupid situation where you have to uninstall vala in order to get the build to be successful :)
[17:01] <desrt> seb128: so there is actually only one library call that would prevent it from working
[17:03]  * desrt will just go to quantal
[17:24] <dobey> mterry: ping
[17:24] <mterry> dobey, hello
[17:25] <dobey> mterry: hey, can you update your branch at https://code.launchpad.net/~mterry/ubuntuone-couch/auth-fixes/+merge/111459 to fix the test_auth.py as well? looks like it has the same import so the branch failed to land :)
[17:27] <mterry> dobey, sure
[17:29] <dobey> thanks
[17:33]  * didrocks waves good evening
[17:34] <mterry> dobey, why did the import from a couple days ago fail?  That should have been the right import
[17:37] <dobey> mterry: because the packages weren't updated in the instance where tarmac is running.
[17:37] <dobey> mterry: but i fixed that :)
[17:37] <mterry> dobey, k
[17:37] <mterry> so a false negative
[17:38] <dobey> yeah
[17:39] <mterry> dobey, ok, branch updated
[18:03] <mterry> dobey, that didn't work
[18:05] <dobey> mterry: rather, it did work, but exposed a new/different set of issues in ubuntuone-couch itself
[18:06] <mterry> right :)
[18:06] <mterry> you say potato, I saw potahto
[18:07] <dobey> we really need to get rid of ubuntuone-couch anyway, and move that auth stuff somewhere else, more reliable
[21:14] <robert_ancell> RAOF, which video card is the next candidate for system compositing?
[21:30] <ceti331>  /join ubuntu
[21:44] <dobey> robert_ancell: ivybridge! ;)
[21:45] <robert_ancell> dobey, oh, did you see https://code.launchpad.net/~robert-ancell/intltool/remove-am-gnu-gettext btw?
[21:46] <dobey> robert_ancell: i haven't yet. does this fix a bug or something?
[21:46] <robert_ancell> dobey, docs say to use AM_GNU_GETTEXT which isn't helping convincing people to drop it
[21:47] <dobey> oh. hmm
[21:49] <dobey> i'll look at it. i don't remember if IT_PROG_INTLTOOL is enough on its own yet
[22:53] <RAOF> robert_ancell: I'll upload nouveau and radeon shortly.
[22:54] <RAOF> They're both done (nouveau more than radeon), I just haven't folded the patches into the packaging.
[23:03]  * TheMuso will gladly test radeon when available, I have a couple of systems here with 48xx cards, and access to a notebook with a 6xxxm chip.
[23:24] <thumper> morning
[23:25] <RAOF> Yo yo!