[00:02] <johanbr> still the same hard lockup
[00:02] <johanbr> no visible difference with nouveau.modeset=1
[00:03] <Sarvatt> yeah its not working here either http://sarvatt.com/downloads/gallium.txt
[00:03] <Sarvatt> gdm stuck on a garbled screen
[00:03] <Sarvatt> i'm trying with noagp=1 now too
[00:05] <Sarvatt> oh wait a sec, old xorg.conf... sheesh
[00:06] <RAOF> Sarvatt: Yeah, I broke xserver-xorg-video-nouveau in xorg-edgers; I was updating the archive package, and forgot that the PPA nouveau-kernel-source had dropped the linux-nouveau-modules Provides:
[00:10] <Sarvatt> Xorg.0.log looks fine but i'm stuck on a blinking cursor screen
[00:10] <Sarvatt> no errors in dmesg either
[00:12] <Sarvatt> http://sarvatt.com/downloads/nouveau.txt
[00:12] <johanbr> can you do anything at that point?
[00:12] <johanbr> switch tty etc?
[00:12] <RAOF> Does the console work?
[00:14] <Sarvatt> no go on vt's or anything, sysrq keys work
[00:14] <Sarvatt> networks up, i can ssh in fine
[00:14] <RAOF> Try rebooting, disabling boot splash?  I seem to recall running into strangeness where nouveau fights with usplash before.
[00:16] <Sarvatt> you know i had that problem too before on that livecd i made, didnt used to have usplash installed even back then
[00:16] <Sarvatt> that worked, removed quiet splash and now i'm in gnome
[00:17] <johanbr> it worked for me just a week ago, with the X server from karmic
[00:18] <johanbr> I upgraded the X server bits to get working xv, but everything stopped working instead
[00:18] <Sarvatt> galliums alot better now on nouveau too, nice
[00:18] <RAOF> johanbr: You could probably have got working xv by running the metacity compositor, too :)
[00:18] <johanbr> I know :)
[00:19] <johanbr> Sarvatt, you're saying the hang disappeared when you removed "quiet splash" ?
[00:19] <Sarvatt> yeah
[00:19] <Sarvatt> usplash definitely doesnt cooperate with nouveau
[00:20] <johanbr> weird... I removed splash, but not quiet, and still got the hang
[00:20] <johanbr> I don't even have usplash installed
[00:20] <RAOF> Actually, it plays nicely with my nv4b; it's obviously not quite so deterministic.
[00:20] <Sarvatt> you have nouveau.modeset=1 too? i have it in a /etc/modprobe.d/nouveau.conf too
[00:20] <Sarvatt> options nouveau modeset=1
[00:20] <Sarvatt> we have the same exact video card
[00:21] <johanbr> which kernel are you running?
[00:22] <RAOF> And which nouveau-kernel-source?  The latest nouveau-kernel-source should (a) enable kms by default, anb (b) add nouveau to the initramfs.
[00:22] <Sarvatt> yours is a dell and mine is a HP going by the subvendor though :D
[00:22] <Sarvatt> 2.6.32-6
[00:22] <Sarvatt> edgers
[00:22] <johanbr> I've mostly tried 2.6.32-7-generic (64-bit)
[00:23] <johanbr> and same n-k-s, 0.0.15+git20091204-0~10.04~ppa1
[00:23] <johanbr> anything special in xorg.conf ?
[00:23] <Sarvatt> phew darn thing is gonna catch on fire trying to play neverball :D
[00:23] <Sarvatt> Section "Device"
[00:23] <Sarvatt>         Identifier "nouveau"
[00:23] <Sarvatt>         Driver "nouveau"
[00:23] <Sarvatt> EndSection
[00:23] <Sarvatt> thats it
[00:24] <johanbr> that's a bit less than mine - I'll try that
[00:24] <Sarvatt> http://sarvatt.com/downloads/nouveau.txt
[00:25] <Sarvatt> thats the working logs
[00:26] <johanbr> alright, one more try...
[00:32] <Sarvatt> yeah nouveau gallium is still pretty much unusable, i915 is almost the same speed as classic mesa
[00:32] <johanbr> whaddayaknow, it works!
[00:33] <johanbr> I think it had issues with something in my old xorg.conf
[00:35] <johanbr> and xv works too :)
[00:35] <Sarvatt> if you want to play with gallium for some 3D ya can just check out mesa git and run ./autogen.sh then ./configure --enable-glx-tls --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests then run any 3D app with something like LD_LIBRARY_PATH="/opt/mesa/lib/" LIBGL_DRIVERS_PATH="/opt/mesa/lib/gallium" glxinfo
[00:35] <Sarvatt> i just made a bash alias for that called gallium so i run "gallium openarena"
[00:36] <RAOF> Sarvatt: How does nouveau gallium fare with, say, gnome-shell?  It's kinda-sorta-almost working on my nv4x.
[00:37] <Sarvatt> hmm cant start gnome shell
[00:37] <Sarvatt> Typelib filoe for namespace Clutter not found hmm
[00:38] <RAOF> Heh.
[00:38] <Sarvatt> can't run it in xephyr either, i think its screwed up in the repos
[00:39] <Sarvatt> or i need aiglx...
[00:39] <johanbr> can you run compiz?
[00:40] <Sarvatt> software rendering detected, falling back even though i ran it with the gallium env variables
[00:40] <Sarvatt> not trying to install gallium dri system wide to get it working :D
[00:44] <Sarvatt> seems exactly the same as it was 6 months ago at any rate, same bugs too.. lol
[00:46] <Sarvatt> maybe the plymouth thats coming in a few days will fix that though
[01:04] <Sarvatt> opened the lid 30 minutes later and its frozen with a blinking cursor again :D
[01:07] <johanbr> so the machine was suspended?
[01:09] <Sarvatt> guess i rebooted it after i shut it and forgot to remove quiet splash from /etc/default/grub
[01:09] <Sarvatt> ...and i forgot a / in my gallium env variables on that machine and was using swrast, no wonder it was slow
[01:11] <Sarvatt> thats more like it! OpenGL renderer string: Gallium 0.3 on NV86
[01:11] <Sarvatt> OpenGL version string: 2.1 Mesa 7.8-devel
[01:11] <Sarvatt> OpenGL shading language version string: 1.20
[01:13] <Sarvatt> compiz is working but slow
[01:18] <johanbr> cool :)
[01:18] <Sarvatt> openarena is great, over 100 fps at 1280x800
[01:21] <RAOF> How nicely is xorg-edgers playing on Lucid's intel right now?
[01:23] <Sarvatt> we really need to package gallium if we're going to use nouveau, this works great
[01:23] <Sarvatt> intel's got alot of problems on 2.6.32 for me
[01:24] <RAOF> Sarvatt: Feel free to --enable-gallium-nouveau on your next mesa upload to xorg-edgers :)
[01:24] <Sarvatt> if only it was that easy! lol
[01:26] <RAOF> It builds a totally different mesa? :)
[01:27] <Sarvatt> gonna have to have alternatives for the main libgl i guess
[01:29] <RAOF> Or just overwrite the existing libgl, and get people to not install it on !nouveau :)
[01:29] <Sarvatt> heck, I would probably stick to nouveau fulltime if gallium was packaged, this is fast enough
[01:33] <Sarvatt> glxgears caused a gpu freeze
[01:52] <Sarvatt> hmm guess i should be compiling in the mesa state tracker too?
[01:52] <RAOF> Probably a winner.
[01:53] <RAOF> I just pull in all the trackers.  Gets you bonus xvmc acceleration!
[02:00] <RAOF> Ok.  I think I've ballsed up xserver-xorg-video-nouveau git sufficiently that I can now re-do the pristine-tar stuff cleanly.
[02:19] <RAOF> Hm.  Darktama thinks that nouveau.ko should work with an unmodified drm from 2.6.32.  That would make nouveau inclusion substantially simpler!
[02:57] <RAOF> I think it's time to play "what happens if I drop drivers/gpu/drm/nouveau into lucid's kernel tree"
[03:00] <johanbr> hmm... X restarts when I resume from suspend
[03:00] <RAOF> Avec nouveau?
[03:01] <johanbr> oui
[03:01] <johanbr> actually, it restarts with the nvidia 195 driver too
[03:01] <johanbr> so it might not be nouveau-specific
[03:01] <RAOF> That seems like a safe call, yes.
[03:01] <johanbr> :)
[03:02] <johanbr> it did resume just fine in karmic
[03:02] <RAOF> Maybe it's an xserver 1.7 issue?
[03:05] <johanbr> could well be
[03:05] <johanbr> apparently X segfaults on resume: http://pastebin.com/f49fbee3c
[03:07] <RAOF> And it doesn't seem to be anywhere near nouveau; maybe it's a synaptics issue?
[03:09] <johanbr> quite possibly
[03:09] <johanbr> I'll try downgrading the synaptics package
[03:12] <johanbr> there was also libpthread in there... I just upgraded that
[03:16] <RAOF> Man, "git add -i" has to be one of the least intuitive interfaces in the whole of the git suite.
[03:22] <RAOF> ARGH!  "git add -p" -- it's like "bzr shelve" except _totally inscrutable_.
[03:39] <Sarvatt> you cant really downgrade synaptics, distro stuff wont work in xserver 1.7+
[03:39] <Sarvatt> wonder if it has anything to do with the new pm-utils 1.30rc that was just uploaded
[03:41] <Sarvatt> or is that just video quirks..
[03:41] <johanbr> yes, I noticed
[03:41] <Sarvatt> whats your /var/log/pm-suspend.log look like?
[03:42] <johanbr> http://pastebin.com/f238ce745
[03:43] <johanbr> don't see any problems there
[03:43] <RAOF> Ok.  Anyone know how to update the kernel configs?
[03:43] <johanbr> but this in the X log makes me wonder: "[    0.000666] (II) Cannot locate a core pointer device."
[03:44] <johanbr> RAOF, update kernel configs how?
[03:45] <RAOF> As in: take the ubuntu kernel, add drivers/gpu/drm/nouveau, and update the build config to enable the build.
[03:45] <RAOF> Never mind, it seems I've found the kernel team wiki.
[03:46] <johanbr> depends on whether nouveau drm is built in-tree or out-of-tree
[03:47] <RAOF> I'm building it in-tree.
[03:47] <RAOF> The idea is to work out whether or not we can just drop drivers/gpu/drm/nouveau into the current kernel build & expect it to work.
[03:47] <johanbr> in that case, I guess the nouveau drm patch itself should add a kernel Kconfig option
[03:47] <RAOF> Because _that_ would mean that it'd be actually possible to ship nouveau by default without killing the other drm drivers.
[03:48] <RAOF> johanbr: It does; I'm trying to find out how the kernel team runs "make silentoldconfig", because it's special.  It occurs to me that perhaps #ubuntu-kernel is going to be more helpful, though :)
[03:49] <johanbr> :)
[03:51] <johanbr> can't you just check out the kernel source package, patch with the nouveau patch, enable the nouveau Kconfig option and then build the deb as usual?
[03:51] <RAOF> No, because the kernel build system copies a stored kernel config on build.
[03:51] <johanbr> oh
[03:51] <RAOF> (Because it wants to build a hojilion different configs)
[04:08] <RAOF> Kernel build timer started: 3:06 pm
[04:11] <johanbr> are you building all the possible flavours?
[04:12] <RAOF> No.
[04:12] <RAOF> Kernel build timer stopped: Error at 3:12 pm :)
[04:12] <johanbr> oh :(
[04:12] <johanbr> well, at least it was quick :)
[04:13] <johanbr> in the nouveau part or somewhere else?
[04:13] <RAOF> In the nouveau part, where I forgot to copy over the i2c directory :(
[04:13] <RAOF> New start: 3:13 pm :)
[04:33] <Sarvatt> how long have you been using edgers on lucid johanbr? just wondering if you had that crash on resume before the switch from hal to udev around december 2nd or so
[04:33] <johanbr> that sounds about right for when the crash started appearing
[04:41] <RAOF> Balls.  Things build better when you include the include files.
[04:47] <johanbr> oh... another restart?
[04:47] <RAOF> Yup.  3:47pm
[04:47] <RAOF> :)
[04:47] <johanbr> :)
[04:47] <johanbr> updated a few things... off to see if resuming works better now
[05:09] <johanbr> hmm... no luck... X still restarts on resume
[05:35] <RAOF> 4:32pm - /home runs out of space :(
[05:39] <johanbr> just no end of troubles today
[09:51] <tjaalton> "Your branch is ahead of 'origin/ubuntu' by 3293 commits."
[09:51] <tjaalton> merging mesa is fun
[09:54] <jcristau> moving to 7.7?
[09:54] <tjaalton> nah, merging with unstable
[09:54] <jcristau> heh
[09:54] <tjaalton> but git was neglected for a number of months
[09:54] <jcristau> ok
[09:55] <tjaalton> it was actually quite easy, the diff is quite manageable
[10:06] <tjaalton> ok, maybe it's time to push all this crap to lucid ;)
[10:27] <RAOF> Cool.  nouveau actually builds against (very nearly) stock lucid drm.  Lets see how well it works.
[10:29] <tjaalton> RAOF: we need a new patch for libdrm 2.4.15
[10:29] <tjaalton> or .16
[10:40] <jcristau> tjaalton: lolz. even the diffstat is above the limit for commit mails.
[10:44] <RAOF> tjaalton: Yeah, that's right.  I was thinking of the kernel component; I was assuming libdrm 2.4.16 would be ambling into lucid sometime in the not-too-distant future.
[11:05] <tjaalton> jcristau: heh, so it seems
[11:05] <tjaalton> RAOF: it should yes
[11:38] <tjaalton> jcristau: there's a request to include the synaptics headers (bug 340340), fedora does it too. what should it be called, x-x-i-synaptics-dev?
[11:39] <jcristau> yeah probably
[11:41] <jcristau> are you uploading the new server today?
[11:41] <tjaalton> yes
[11:41] <tjaalton> though the build seems to have failed..
[11:42] <tjaalton> had to try it first
[11:42] <tjaalton> seems like patch 177 broke it
[11:42] <tjaalton> struct _DeviceIntRec has no member named 'isMaster'
[11:44] <tjaalton> well, should be fixed anyway
[11:44] <tormod> tjaalton, re mesa merge, do you remember I retro-pushed ubuntu releases to git (see ML)?
[11:45] <tjaalton> tormod: when was that?
[11:45] <tjaalton> ah, found it
[11:48] <tormod> so I guess that was wasted time
[11:48] <tjaalton> I was abroad when you sent that, sorry :)
[11:52] <tjaalton> but it's nice that all the changes are there as separate commits.. maybe it could be force-pushed
[11:52] <tjaalton> I'll check the script
[11:54] <tjaalton> you should apply for pkg-xorg :)
[11:55] <tjaalton> maybe the script could be used with synaptics..
[11:56] <tormod> well I think Bryce reviewed it half way but did not push it
[12:01] <tjaalton> though most of the changes between the previous git push and now were just added patches from upstream. the diff is almost identical
[12:05] <tjaalton> pushing your repo would also add the tags?
[12:10] <tormod> yes, I made tags also
[12:12] <tjaalton> we haven't tagged the releases from ubuntu branches, to avoid cluttering up the list. don't know if it matters much, but
[12:13] <tormod> isn't that useful, to easily git-diff between versions?
[12:13] <tjaalton> normally I just diff the head of ubuntu
[12:14] <tjaalton> but yes, it's useful to have the debian releases tagged ;)
[12:15] <tormod> I understand, the tag list is global, so we can not "hide" ubuntu tags, they will uglify the gitweb list
[12:16] <tjaalton> and tab-completion with zsh ;)
[12:17] <tormod> with bash also I think
[12:27] <tjaalton> tseliot: what's the status with synaptics? not maintained in git anymore it seems, but are you going to merge it or should I? (for xserver 1.7)
[12:27] <tseliot> tjaalton: in the debian git, do you mean?
[12:28] <tjaalton> yes
[12:28] <tseliot> aah
[12:29] <tseliot> tjaalton: feel free to merge it. I have a lot of things to deal with right now
[12:29] <tjaalton> ok
[12:29] <tseliot> and thanks
[12:29] <tseliot> :-)
[12:29] <tjaalton> np
[12:35] <tjaalton> xserver build failed again, now due to patch 135
[12:37] <jcristau> that patch seems to make the server do some things from the signal handler which i'm not sure are safe
[12:38] <tjaalton> error: 'signo' undeclared
[12:38] <tjaalton> well, apport isn't run anyway yet, so I'll just disable it for now
[12:48] <tjaalton> yes, built without it
[13:26] <tseliot> tjaalton: let me know if my patches for synaptics fail to apply and I'll adapt them for you
[13:28] <tjaalton> tseliot: ok, thanks. fixing the server one more time..
[13:28] <tseliot> :-)
[13:53] <tjaalton> sigh.. what to do with -ati..
[13:53] <tjaalton> the version is bigger than in debian, so can't be synced. maybe just a rebuild then
[13:53] <tjaalton> don't feel like pulling in a random snapshot
[13:56] <tseliot> a rebuild should be enough then
[14:02] <tjaalton> there, pitti synced these http://pastebin.ubuntu.com/336548/
[14:03] <tjaalton> apart from the xcb stuff which is in quilt3.0 format and soyuz can't handle it yet
[14:04] <jcristau> nothing needs it yet so that should be fine
[14:04] <tjaalton> yep, figured as much
[14:05] <jcristau> new intel will, but...
[14:46] <tjaalton> openchrome failed to build
[14:46] <tjaalton> http://launchpadlibrarian.net/36533009/buildlog_ubuntu-lucid-i386.xserver-xorg-video-openchrome_1%3A0.2.904%2Bsvn812-1_FAILEDTOBUILD.txt.gz
[14:46] <tjaalton> against the old server, but anyway
[14:50] <jcristau> old xserver + new proto
[14:50] <jcristau> that's expected to break
[14:50] <tjaalton> ah, ok
[14:50] <tjaalton> it should be the only driver without the bumped build-dep
[14:55] <tjaalton> looks like fedora has had fixes for ABI_INPUT_VERSION 7 for the drivers that haven't seen releases for 7.5
[14:55] <tjaalton> wonder why they haven't been pushed upstream
[14:56] <tjaalton> oops
[14:57] <tjaalton> correction, they are upstream but no release has been made
[14:58] <jcristau> oh, i guess i forgot those had been pushed
[15:00] <jcristau> maybe you can do the releases then :)
[15:01] <tjaalton> heh, maybe later :)
[15:03] <tjaalton> tseliot: the jumpy cursors patches don't work, since there will be no fdi file anymore
[15:04] <tjaalton> and I don't know how it works in the udev world. But I guess it can be disabled for now
[15:05] <tseliot> tjaalton: but the udev rule that pitti wrote makes use of it and it works
[15:05]  * jcristau would like to not put any options in the udev rules
[15:06] <tjaalton> tseliot: oh right, they are there
[15:07]  * tseliot would like to live in a world in which quirks are not required...
[15:07] <tjaalton> it's just a matter of where they should live..
[15:07] <jcristau> tseliot: if quirks are required, they should not live in udev rules.
[15:07] <tseliot> give me another sensible place for the quirks and I'll change my patch ;)
[15:07] <jcristau> your kernel
[15:08] <jcristau> or the X driver, maybe
[15:10] <tseliot> jcristau: I discussed this with whot but he doesn't seem to want it in the X driver and I'm not really sure about how I could translate my patch into a kernel patch (because of what it does)
[15:12] <jcristau> what it does is detect what machine it's running on and set different default values for some options?
[15:16] <tjaalton> tseliot: the first part of the jumpy patch fails to apply
[15:17] <tseliot> tjaalton: can you upload the synaptics source somewhere, please?
[15:17] <tjaalton> I'll push it to git, clone from there
[15:19] <tseliot> tjaalton: can you give me the link to the branch, please?
[15:21] <tjaalton> git clone git://git.debian.org/pkg-xorg/driver/xserver-xorg-input-synaptics.git
[15:21] <tjaalton> git checkout -b ubuntu origin/ubuntu
[15:23] <tjaalton> guess I have to drop wacom from input-all until it works
[15:30] <tseliot> tjaalton: ok, thanks I'll update the patch ASAP
[15:31] <Sarvatt> we need a 190.xx or newer nvidia blob to work with xserver 1.7 too
[15:32] <tjaalton> tseliot: thanks
[15:33] <tseliot> Sarvatt: right. It's on my TODO list
[15:33] <tseliot> tjaalton:  np
[15:35] <Sarvatt> openchrome should build against xserver 1.7, i pushed a patch for it upstream like 6 months ago
[15:35] <Sarvatt> oh sorry misread, old server new libs
[15:36] <tjaalton> yep
[16:01] <tjaalton> xserver failed to build on sparc, powerpc:
[16:01] <tjaalton> /xi2/eventconvert/XIDeviceChangedEvent: **
[16:01] <tjaalton> ERROR:../../../test/xi2/protocol-eventconvert.c:714:test_values_XIDeviceChangedEvent: assertion failed: (k->length == bytes_to_int32(sizeof(xXIKeyInfo)) + k->num_keycodes)
[16:01] <tjaalton> /bin/bash: line 5: 13949 Aborted                 ${dir}$tst
[16:01] <tjaalton> FAIL: protocol-eventconvert
[16:01] <jcristau> fun.
[16:02] <jcristau> endianness bug?
[16:05] <tjaalton> probably something like that..
[16:05] <tjaalton> shouldn't matter though
[16:05] <tjaalton> at least not for a1
[16:08] <tjaalton> mesa built fine.. I'll upload it and take a break
[16:19] <Sarvatt> where can you see the buildlogs for debian experimental powerpc xserver?
[16:21] <jcristau> you can't
[16:21] <jcristau> experimental autobuilding is fucked up atm
[16:22] <jcristau> http://lists.debian.org/debian-wb-team/2009/12/msg00002.html
[16:33] <Sarvatt> ahh darn
[16:35] <jcristau> looks like the sparc x tinderbox machine is b0rked as well.  yay.
[16:37] <Sarvatt> doesnt look like they're even building xserver on powerpc either
[16:37] <Sarvatt> oh sheesh i'm blind this morning
[16:38] <jcristau> yeah both are failing on libs earlier
[17:55] <ScislaC> I recall seeing discussion about HAL going away for 10.04, is that still planned?
[17:55] <jcristau> see https://lists.ubuntu.com/archives/lucid-changes/2009-December/001427.html
[17:56] <jcristau> and friends
[17:58] <ScislaC> jcristau: Thanks! Is it known yet if the udev stuff is playing nicely with drawing tablets?
[19:15] <tjaalton> ScislaC: 0.10.2 should work, but it's not packaged yet
[19:16] <tjaalton> so wacom on alpha1 doesn't work at all
[19:16] <ScislaC> tjaalton: excellent, I will hold off for now then
[19:28] <tjaalton> duh, somehow missed -ark, -apm, -neomagic when requested pitti to sync the drivers
[20:58] <tjaalton> ok, video drivers should be good now (apart from blobs)
[20:58] <jcristau> and sparc :)
[20:59] <tjaalton> obviously :)
[20:59] <tjaalton> I guess only i386 and amd64 matter at this point
[20:59] <tjaalton> and armel
[21:35] <johanbr> is 2:1.7.99.2~git20091207.fd867387-0ubuntu0sarvatt a real, existing version of xserver-common?
[21:35] <johanbr> xserver-common depends on that package
[21:35] <johanbr> sorry, I mean xserver-xephyr depends on that package
[21:36] <tjaalton> if you run xorg-edgers, yes
[21:36] <tjaalton> or should be anyway
[21:37] <johanbr> xorg-server - 2:1.7.99.2~git20091207.fd867387-0ubuntu0sarvatt exists as a source package
[21:37] <johanbr> but didn't produce an xserver-common package at all
[21:38] <johanbr> oh, maybe that's because the 386 build isn't finished yet
[22:16] <RAOF> Sweet.  With a simple patch to export a couple more ttm symbols, nouveau build & runs against lucid's kernel drm.
[22:20] <johanbr> cool
[22:20] <johanbr> you cleaned out your /home ? :)
[22:20] <RAOF> Indeed.
[22:21] <RAOF> Why are all the git defaults exactly backwards? :(
[22:28] <tormod> RAOF, I will keep on updating the -nouveau in xorg-edgers. was there something special about your upload?
[22:28] <tormod> apart the broken parts :p
[22:28] <RAOF> tormod: It was basiacally testing for an upload to Lucid; feel free to keep updating it in edgers.
[22:29] <tormod> RAOF, okdok
[22:29] <RAOF> That's also why it was broken; it was based on Karmic's package, which the PPA packages have diverged from :)
[22:54] <johanbr> hmmm... just did a complete dist-upgrade to Lucid, and X still segfaults on resume: http://pastebin.com/f48826e90
[23:22] <johanbr> apparently, it's probably this (just fixed) bug: https://bugs.freedesktop.org/show_bug.cgi?id=25339