[00:00] <RAOF> Well, the alpha is specified in the Render types.
[00:01] <RAOF> But not for the core Visual.
[00:01] <robert_ancell> yeah
[00:01] <robert_ancell> I guess it just got implied to cover that
[00:01] <robert_ancell> There must have been a bunch of old X apps that suddenly went transparent when that was enabled
[00:05] <RAOF> I don't think so, no.
[00:05] <RAOF> They get depth=24.
[00:07] <robert_ancell> RAOF, right, by default. Probably not a lot of apps that explicitly chose 32
[00:07] <robert_ancell> RAOF, do you know much about the fb backend?
[00:08] <RAOF> Not particularly. From my vague wanderings in surrounding code I think it's just a fairly simple “here's a blob of memory, let me blit for you” thing.
[00:08] <robert_ancell> RAOF, it seems really keen to be 24bpp but advertise you can use depth=32 images. RENDER is not assuming this could be the case
[00:09] <robert_ancell> So I think I can tell RENDER to drop the alpha channel and that solves the assertion but means windows aren't transparent
[00:10] <RAOF> Well, if there's no Composite manager then the windows are going to be opaque anyway.
[00:10] <robert_ancell> Which should be possible if the in-between formats are 32bpp. So there must be a better way
[00:10] <robert_ancell> RAOF, there's compiz :)
[00:10] <RAOF> And if there *is* a Composite manager then it should have already taken the alpha into account before blitting anywhere.
[00:13] <RAOF> I think you can also explicitly tell fb to be 32bpp; IIRC you need to do that to make swrast GL work on xvfb anyway.
[00:13] <robert_ancell> RAOF, right, that would probably solve it too, but it still shouldn't hit this assertion in the default case
[02:01] <bregma> robert_ancell, a recent change to unity-system-compositor has rendered it unusable on the desktop, can I pick your brain briefly on how best to resolve this problem?
[02:20] <robert_ancell> bregma, sure
[02:22] <bregma> OK, the recent change assumes the display manager is running on top of the one single display server and that authentication is performed after the session has started ... which does not really work on the desktop
[02:23] <bregma> u-s-c now requires the next-session and active-session messages get send from lightdm before it will start renderinh surfaces
[02:23] <bregma> and that does not happen on the desktop
[02:24] <bregma> so, either u-s-c will need to be rewritten to handle convergence, or lightdm needs to do some magic with sending those messages from different code paths
[02:24] <bregma> and I got lost trying to figure out the latter, which is where you come in
[02:25] <bregma> so, um, any opinions or suggestions on how to get the unity 8 desktop session working again?
[02:34] <robert_ancell> bregma, this is the unity8 session from traditional unity-greeter?
[02:34] <bregma> yes
[02:35] <robert_ancell> bregma, right, I think we just need to call set_active_session from seat-xlocal.c. We were just relying on the first session being active
[02:36] <robert_ancell> I can whip up a branch
[02:36] <bregma> I am all in favour of a simple solution, especially if someone who knows what they're doing does it
[02:36] <robert_ancell> It shouldn't be too hard
[02:37] <robert_ancell> bregma, this is the utopic version in the main archive doing this?
[02:37] <bregma> yes, it's been broken since the split greeter went in
[02:38] <bregma> the current workaround is to revert u-s-c to the previous version
[02:40] <bregma> bug #1325995
[03:26] <robert_ancell> bregma, lp:~robert-ancell/lightdm/usc-set-active seems to do the trick
[03:27] <robert_ancell> u-s-c is now crashing since the dist-upgrade but I think that's unrelated
[03:28] <robert_ancell> I mean unity-settings-daemon
[03:47] <pitti> Good morning
[08:03] <Laney> hey hey
[08:04] <larsu> guten morgen Laney
[08:05] <didrocks> morning Laney, larsu!
[08:06] <Laney> hey larsu and didrocks
[08:06] <Laney> wie gehts?
[08:06] <didrocks> I'm great, thanks! Yourself?
[08:06] <Laney> doing alright
[08:06] <larsu> bonjour didrocks
[08:06] <Laney> wondering if it might stop raining ever though
[08:07] <didrocks> blue sky here
[08:07] <Laney> send it here please
[08:07]  * didrocks keeps it for him. "My precious"
[08:09] <Laney> :(
[08:10]  * didrocks will give some to Laney then, after the daily run :)
[08:12] <Laney> thanks!
[08:12] <Laney> looks like it'll get here at about 20:00 http://www.bbc.co.uk/weather/2641170
[08:13] <didrocks> Laney: hard to even imagine the difference at less than 800kms from there: http://www.meteofrance.com/previsions-meteo-france/lyon/69000
[08:13] <didrocks> (in temperature)
[08:16] <Laney> oh wow
[08:16] <Laney> I guess it is mostly going south though, which tends to help :P
[08:17] <didrocks> right ;)
[08:31] <seb128> good morning desktops
[08:32] <didrocks> bonjour seb128
[08:32] <Laney> hey seb128
[08:33] <Laney> pitti: do you know what these 'Broken pipe' adt failures are?
[08:33] <Laney> I was getting SSH connections into my utopic container terminated with that error yesterday
[08:53] <pitti> Laney: no, do you have a full log?
[08:53] <pitti> bonjour seb128
[08:54] <Laney> pitti: no, running with -vvv now incase it happens again today
[08:54] <pitti> Laney: you mean you ran a test and during that you ssh'ed into the container?
[08:55] <Laney> pitti: I mean I was seeing broken pipe myself yesterday and when I look at these random failures I also see broken pipe
[08:55] <seb128> pitti, salut, ça va bien ?
[08:55] <pitti> seb128: oui, merci
[08:55] <Laney> I wasn't using adt, just sshing normally
[08:55] <pitti> Laney: I sometimes see timeouts with the qemu runner in production (haven't yet been able to reproduce locally or understand these), but not SIGPIPEs
[08:56] <pitti> Laney: oh -- this is just lxc, not adt-virt-lxc; no, I've never had that
[08:56] <Laney> for example https://jenkins.qa.ubuntu.com/job/utopic-adt-glib2.0/27/ARCH=amd64,label=adt/console reminded me of it
[09:05] <Laney> oh
[09:05] <Laney> seb128: could you promote grilo please? https://bugs.launchpad.net/ubuntu/+source/grilo/+bug/1116098
[09:05] <seb128> Laney, do you want all binaries or a set?
[09:05] <Laney> hmm
[09:06] <Laney> lemme check
[09:06] <seb128> thanks
[09:06] <seb128> tseliot, hey
[09:07] <seb128> tseliot, your u-s-d changes have a segfault, see https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1326636
[09:08] <tseliot> seb128: looking
[09:08] <Laney> seb128: looks like src:grilo libgrilo-0.2-dev libgrilo-0.2-1
[09:08] <seb128> tseliot, thanks, I rejected the SRU upload meanwhile, we are going to need to fix that before SRUing
[09:08] <tseliot> seb128: sure
[09:16] <seb128> Laney, grilo promotion done
[09:16] <Laney> ta
[09:16] <Laney> Mirv will be happy
[09:16] <seb128> yw
[09:23] <tseliot> seb128: I have a two-line fix for that. I'll rebuild and test, although it's really a no brainer
[09:24] <seb128> tseliot, ok, thanks ... do you know in which cases/configs it happens?
[09:25] <tseliot> seb128: systems without a touchscreen. It was missing a check in one of the two points where the mapping is done. A silly mistake
[09:25] <seb128> ok
[09:39] <tseliot> seb128: ok, it work on systems with and without a touchscreen. How do I proceed? (another merge request?)
[09:39] <tseliot> *works
[09:39] <seb128> tseliot, yes, please
[09:40] <tseliot> ok
[09:40] <seb128> thanks
[09:44] <Mirv> seb128: thanks!
[09:44] <seb128> Mirv, thanks to Laney, he's the one who did the reviews/sponsoring
[09:44] <Mirv> yes, thanks to him also
[09:45] <Mirv> no more self-patched packages to play music
[09:49] <tseliot> seb128: here you go: https://code.launchpad.net/~albertomilone/unity-settings-daemon/1326636-14.10/+merge/222148
[09:50] <seb128> tseliot, thanks
[09:50] <tseliot> yw
[09:51] <tseliot> seb128: if the bumped revision is not needed, I'll get rid of that
[09:53] <seb128> tseliot, no, please don't change the changelog
[09:53] <seb128> the CI landing process generate that from the commit messages
[09:53] <tseliot> seb128: I'll revert that then
[09:53] <seb128> thanks
[09:54] <Sweet5hark> moin all.
[09:55] <Sweet5hark> seb128: so I disabled one test that only failed on the buildd but not in my local pbuilder, just to run into the next: https://launchpadlibrarian.net/176972865/buildlog_ubuntu-utopic-amd64.libreoffice_1%3A4.3.0~beta1-1ubuntu1~utopic2_FAILEDTOBUILD.txt.gz
[09:56] <seb128> Sweet5hark, hey! had good days off in Malta?
[09:56] <Cyberspirit> http://pastebin.com/qaEfUsYd
[09:56] <seb128> Sweet5hark, 3.0 ... aren't we on 4.2?
[09:57] <Sweet5hark> seb128: I could add more tests to disable at a rate of one per day -- or disable running tests during the build for now. Both feel like cheating ...
[09:58] <tseliot> seb128: ok, it's fixed now
[09:58] <Sweet5hark> seb128: Malta was nice, just the right amount of time for the island (and yeah, I visited Gozo for a day).
[09:59] <Sweet5hark> seb128: huh? its 4.3.0~beta1 to get that going for utopic ...
[09:59] <seb128> Sweet5hark, sorry, misparsed the url with the %3A in the middle
[09:59] <seb128> Sweet5hark, the test failing my be sign of a real issue?
[10:05] <Sweet5hark> seb128: currently it doesnt seem so, e.g. if services.rdb would be broken, nothing would be running as all UNO would be broken unless its a Heisenbug. But a Heisenbug wouldnt happen on amd64 and i386 the same way ...
[10:11] <Sweet5hark> seb128: fwiw, I just ran that test 10 times locally without an issue ...
[10:20] <seb128> Sweet5hark, weirdness ... I guess your call on what you want to do with those, if you feel like the issue is not showing a real problem feel free to skip those
[10:21] <Sweet5hark> seb128: k, will do.
[10:25] <seb128> Laney, https://code.launchpad.net/~brendan-donegan/ubuntu-system-settings/bug1319711/+merge/222141 seems to make CI happy ... I'm going to do a landing later today, if you want other stuff to be included let me know (I plan to try to review/land the pending wizard work as well)
[10:26] <Laney> seb128: we won't really know until there's been a few runs
[10:26] <Laney> but it's worth a go
[10:26] <Laney> I want to look at mterry's branch again
[10:26] <seb128> Laney, it seemed to be reliably red on jenkins CI runs to me
[10:26] <seb128> k
[11:02] <seb128> Laney, larsu, everyone interested: I've pushed the gtk 3.12 work in progress packaging on https://code.launchpad.net/~ubuntu-desktop/gtk/312
[11:03] <Laney> cool
[11:03] <Laney> going to do a ppa upload?
[11:04] <seb128> yes, after my local build/test
[11:06] <larsu> thanks!
[11:45] <seb128> tseliot, can you include your fix to https://code.launchpad.net/~albertomilone/unity-settings-daemon/lp1287341-14.10/+merge/222071 as well?
[11:49]  * seb128 hates GTK build
[11:49] <seb128> it fails on some refcount test for me and I can't resume build correctly
[11:51] <seb128> if I "debuild binary" in the builddir that fails on gtk-update-icon-cache hacks from rules
[11:52] <desrt> seb128: did you ever consider that the gtk build has gotten too complicated over time?
[11:52] <desrt> i mean... how many binary packages are coming out of there?   and how many times do you rebuild for each one?
[11:53] <seb128> it is, but that's not something I feel like is worth fighting over
[11:53] <desrt> you get to pay the cost every time you build gtk :)
[11:53] <seb128> yeah, which is not that often
[11:54] <seb128> and usually the another 10 minutes is not an issue, I just catchup on emails or do something else while it's building
[11:54] <seb128> but yeah, damn debian installer and udebs!
[11:56] <tseliot> seb128: done
[11:57] <seb128> tseliot, thanks
[12:03] <Laney> seb128: it failed for me on missing symbols
[12:03] <Laney> http://paste.ubuntu.com/7594368/
[12:11] <seb128> Laney, thanks, I'm going to fix that
[12:11] <seb128> the gnome3-staging ppa enable that backend without documenting it
[12:11] <Laney> I just build in sbuild, usually avoids weird test errors like that
[12:11] <seb128> so I dropped the change
[12:11] <seb128> yeah, I never bothered configuring a sbuild
[12:12] <seb128> one of the reasons being that my 80G disk doesn't have lot of spare capacity
[12:13] <Laney> yeah you need a local mirror or some kind of caching proxy
[15:37] <seb128> qengho, there?
[15:40] <Laney> http://pennystocks.la/internet-in-real-time/
[15:40] <Estilanda> hello
[16:15] <pitti> hm, unity-settings-daemon keeps crashing, also in a guest session
[16:15] <pitti> seems the recent updates didn't like me :/
[16:16] <pitti> does that happen to anyone else?
[16:16] <pitti> The error was 'XI_BadDevice (invalid Device parameter)'.
[16:16] <pitti>   (Details: serial 227 error_code 129 request_code 131 (XInputExtension) minor_code 48)
[16:17]  * pitti files to LP
[16:17] <Laney> pitti: the new version should fix that
[16:17] <Laney> do you have today's one?
[16:17] <pitti> Laney: ah, so it's known?
[16:17] <pitti> Laney: I have 14.04.0+14.10.20140604-0ubuntu1
[16:17] <Laney> yeah, tseliot fixed it today
[16:17] <seb128> pitti, upgrade
[16:17] <Laney> in 05
[16:17] <pitti> seb128: just tried, grabbing from LP now; the German mirror might be lagging
[16:18] <tseliot> my bad :)
[16:18] <tseliot> it should work now
[16:18] <Laney> it fixed it for me
[16:18] <seb128> well, I screwed as well, I tested it only on a touch screen device to see if the patch was working
[16:18] <pitti> trying, brb
[16:19] <pitti> \o/ sanity again! (and keyring daemon)
[16:19] <pitti> seb128, Laney: thanks for help
[16:19] <seb128> yw, sorry for the bug
[16:20] <seb128> nice to see e.u.c being useful btw
[16:20] <pitti> I was afraid I'd have to spend the long weekend and train ride with broken 'puter :)
[16:20] <seb128> that ranked as 1st report on the daily 14.10 view
[16:24]  * pitti waves good bye again then, see you on Tuesday!
[16:26] <seb128> pitti, enjoy the long w.e !
[16:29] <Laney> argh
[16:30] <Laney> firefox has crashed twice today and twice yesterday
[16:30]  * Laney looks around for attente
[16:30] <Laney> ;-)
[17:07]  * didrocks continues a little bit offline. See you tomorrow guys!
[21:24] <robert_ancell> bregma, lightdm 1.11.3 uploaded now - this should fix the Unity 8 session. I was waiting to confirm it would not break the phone with the other changes
[21:27] <bregma> nice
[21:49] <bschaefer> yay