[00:12] <TheMuso> lol
[01:50] <RAOF> Am I not a member of ubuntu-sponsors anymore? Could someone please unsubscribe sponsors from https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153 ?
[01:50] <ubot2> Ubuntu bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,Triaged]
[02:16] <TheMuso> RAOF: I can re-add you, if you'd like.
[02:16] <RAOF> TheMuso: Yes, please.
[02:17] <TheMuso> RAOF: Done.
[02:19] <RAOF> TA
[03:00] <TheMuso> np
[04:20] <pitti> Good morning
[04:25] <RAOF> Good morning pitti!
[04:27] <pitti> hey RAOF, how are you?
[04:28] <RAOF> I be fine.
[04:29] <RAOF> Albeit a bit cold, because Hobart has finally realised that it's winter.
[06:56] <jibel> good morning
[06:58] <didrocks> salut jibel!
[07:01] <jibel> salut didrocks
[07:38] <seb128> good morning desktopers
[07:44] <didrocks> hey seb128!
[07:46] <seb128> didrocks, hey! happy summer day
[07:46] <didrocks> seb128: happy summer day to you too! :)
[07:47] <pitti> bonjour seb128
[07:47] <seb128> pitti, salut, ça va ?
[07:47] <didrocks> salut pitti!
[07:47] <pitti> seb128: ça va bien ! il ne fait plus chaude \o/
[07:48] <pitti> "chaud"
[07:53] <seb128> pitti, pareil ici, 19°C
[08:01] <Laney> hallo
[08:04] <seb128> Laney, good morning, happy summer day
[08:04]  * Laney looks outside
[08:04] <Laney> happy for you, maybe :P
[08:04] <seb128> better the 19°C we have today than the 35°C we had mid-week :p
[08:05] <seb128> Laney, let me fallback to "happy friday" ;-)
[08:05] <seb128> can't go wrong with friday :p
[08:05] <Laney> definitely not
[08:05] <Laney> to be fair it's not cold here, just super cloudy and grey
[08:05] <Laney> could be worse though ... was hearing about the smog in singapore on the news
[08:05] <Laney> hyperair: is it bad?
[08:06] <hyperair> ohoho
[08:06] <hyperair> hilariously so
[08:06] <hyperair> it's much better now though
[08:06] <hyperair> PSI's dropped to 168
[08:06] <hyperair> it was 400 earlier
[08:06] <hyperair> visibility at ~800 metres or so
[08:06] <hyperair> (based on staring out the window and looking at google maps)
[08:08] <hyperair> oh 145 now apparently.
[08:09] <hyperair> http://www.nea.gov.sg/psi/
[08:10] <Laney> wow
[08:11] <hyperair> it dropped very suddenly. i wonder what happened.
[08:11]  * hyperair looks for a window
[08:11] <Laney> well this news story was about indonesia sending helicopters up or something
[08:11] <Laney> maybe it's working ...
[08:12] <hyperair> oh they're finally doing that?
[08:13]  * hyperair heard they sent out about 100 firemen who weren't doing anything.
[08:14] <hyperair> i wouldn't be surprised if someone paid off some govt officials to stall for time until the wood's done burning so that they don't have to find some other means of clearing their greens.
[08:14] <Laney> heh
[08:14] <Laney> you old cynic
[08:15] <Laney> seb128: have you tried nautilus 3.8 and turning gsd's background plugin back on?
[08:15] <Laney> does not work for me - still black
[08:15] <seb128> Laney, no, on my list for today
[08:15] <seb128> oh :-(
[08:15] <seb128> does it work if nautilus --quit?
[08:15] <seb128> e.g is nautilus breaking it?
[08:15] <seb128> or g-s-d no working?
[08:15] <seb128> did you restart gsd?
[08:15] <Laney> but I can do that cool windows 95 thing where you drag a window over the desktop and get a trail
[08:16] <Laney> restarted the session
[08:16]  * hyperair lols
[08:16] <Laney> nautilus --quit fixes it yeah
[08:16] <seb128> crap
[08:16] <seb128> ooooh, I know
[08:16] <hyperair> doesn't that also happen when nautilus crashes?
[08:17] <Laney> not seen that before
[08:17] <Sweetshark> Bonjours a tous!
[08:17] <seb128> hey Bjoern!
[08:17] <hyperair> in 13.04 killing nautilus leaves a black desktop with artifacts
[08:17] <seb128> Laney, g-s-d source, plugins/background/gsd-background-manager.c
[08:18] <seb128>         if (nautilus_is_drawing_background (manager) ||
[08:18] <seb128>             dont_draw_background (manager)) {
[08:18] <seb128>                 return;
[08:18] <seb128>         }
[08:18] <seb128> l192
[08:18] <hyperair> no wait, it's just black now
[08:18] <seb128> you need to drop the nautilus_is_drawing_background()
[08:18] <hyperair> maybe it's some transient xorg-edgers thing.
[08:18] <seb128> no
[08:18] <seb128> that's expected
[08:18] <Sweetshark> seb128: the good news is LibreOffice 4.1.0~rc1 build on i386. The bad news is it failed on amd64 ... with a strange error that doesnt happen locally.
[08:18] <seb128> that's what happens when nothing draw on the root win
[08:18] <Laney> let me try that
[08:18] <hyperair> seb128: no, i mean i don't get window trails any more.
[08:18] <Laney> got to go out to a doctors appointment in 10 minutes though
[08:19] <Sweetshark> or maybe Im not awake enough to get it ...
[08:19] <seb128> Laney, well it's for sure an issue (maybe not the only one)
[08:19] <Laney> does new gsd drop this?
[08:19] <seb128> new g-s-d drops the plugin
[08:19] <seb128> gnome-shell render the background
[08:19] <Laney> well that'll solve it ...
[08:19] <seb128> unity8 should as well
[08:19] <seb128> but meanwhile...
[08:20] <hyperair> waait, does that mean nautilus doesn't draw icons on the desktop any more?
[08:20] <seb128> it does
[08:20] <Laney> it does that
[08:20] <seb128> but it doesn't draw the wallpaper
[08:20] <Laney> only that, not the background
[08:20] <hyperair> so it draws icons, but not the wallppaer?
[08:20] <hyperair> oh cool
[08:20] <seb128> it puts icons on a rgba win
[08:20] <Laney> but upstream was interested in keeping that functionality though
[08:20] <hyperair> so compiz's wallpaper plugin would work
[08:20] <hyperair> =O
[08:20] <Laney> don't know where that went
[08:20] <seb128> is there a such plugin?
[08:20] <hyperair> yes there is
[08:20] <seb128> Laney, you bet they are :p
[08:20] <Laney> hyperair: where?
[08:21] <seb128> Laney, RHEL7 will ship with classic mode by default
[08:21] <Laney> I don't see it in ccsm
[08:21] <hyperair> well, there waxs
[08:21] <hyperair> was*
[08:21] <hyperair> lemme check
[08:21] <Laney> might not have some extras package installed
[08:21] <hyperair> maybe
[08:21] <seb128> we looked for a compiz plugin for wallpaper previous cycle and didn't find one
[08:22] <hyperair> http://imgur.com/UUTW1Iv
[08:23] <seb128> dpkg -S wallpaper | grep compiz ?
[08:23] <hyperair> compiz-plugins: /usr/lib/compiz/libwallpaper.so
[08:23] <Laney> yes indeed
[08:23] <hyperair> Installed: 1:0.9.9~daily13.04.18.1~13.04-0ubuntu1
[08:23] <hyperair> so there we go
[08:24] <Laney> let me see if it works
[08:24] <hyperair> if unity renders the background, it would be good to drop or merge that functionality back to avoid nihing too much
[08:24] <Laney> enabling it made compiz crash
[08:24] <Laney> good start
[08:24] <hyperair> ugh
[08:24] <hyperair> lemme try
[08:24] <seb128> Laney, seems about right for compiz :p
[08:24] <Laney> heh
[08:24] <seb128> that's its way to reload config :p
[08:25] <Laney> still no bg ...
[08:25] <seb128> :-(
[08:25] <seb128> well in any case enabling compiz plugin on upgrade has proved not reliable
[08:25] <Laney> oh, ok
[08:25] <seb128> and I'm not sure it got well tested and include all the GNOME options
[08:25] <seb128> like solid color background, etc
[08:25] <Laney> seems you have to specify it in the compiz configuration, doesn't read from gsettings
[08:26] <hyperair> ugh, doesn't handle multihead.
[08:26] <seb128> need to reboot, be back in 30min
[08:27] <hyperair> Laney: it works here, but stretches my wallpaper across both heads.
[08:27] <Laney> did it pick up your gnome configured wallpaper?
[08:27] <hyperair> nope
[08:27] <hyperair> had to add it in via ccsm
[08:27] <Laney> well that's a bit of a problem
[08:27] <Laney> and it's what I said above
[08:27] <hyperair> that can be patched, can't it?
[08:27] <Laney> mayhap
[08:28] <Laney> might not be worth the effort though given its future (if gsd's background plugin works)
[08:28] <Laney> http://ubuntuone.com/5WoJAca0zI67a3PtTBAfKk
[08:30] <hyperair> heh yeah
[08:31] <hyperair> argle, FBO_ATTACHMENT_IS_INCOMPLETE
[08:32] <Laney> better go to this appointment
[08:32] <Laney> back shortly
[08:41] <didrocks> sil2100: hey, do you need anything from me? FYI, I'll be away in 30 minutes for ~2 hours
[08:42] <sil2100> didrocks: !
[08:42] <sil2100> Hi!
[08:42] <sil2100> Let me think quickly ;P
[08:44] <sil2100> didrocks: could you quickly ACK some packaging changes for daily-release? Those are mostly the symbols-file mods that have been done last time
[08:44] <sil2100> didrocks: let me paste those
[08:44] <didrocks> sil2100: excellent!
[08:45] <sil2100> Thanks ;)
[08:46] <didrocks> thank you! :)
[08:58] <seb128> back
[08:59] <didrocks> wb seb128
[08:59] <seb128> didrocks, thanks
[08:59] <seb128> having fun with Dell support ... they will call me back this afternoon when my computer is in sloooow mode
[09:00] <seb128> I need some heat and cpu use :p
[09:00] <didrocks> seb128: want to build a webkit? :p
[09:04] <seb128> didrocks, no, thanks, still debugging gtk ... though that's the n7 there
[09:05] <seb128> unity-greeter build failed yesterday because gtk was displaying the same warning
[09:05] <seb128> so it's a real bug in gtk, not a problem with the test
[09:20] <sil2100> charles, chrisccoulson: ping
[09:21] <seb128> sil2100, hey, what do you need from them?
[09:22] <seb128> it's a bit early for charles
[09:25] <sil2100> seb128: hi! One of the libdbusmenu unit tests fail for armhf, wanted to get some insight from someone that knows the code
[09:26] <seb128> sil2100, link?
[09:28] <darkxst> seb128, ok to cherry pick the 3 icon patches from here https://git.gnome.org/browse/gtk+/log/?h=gtk-3-8
[09:28] <darkxst> I suspect they will fix a few of the really annoying crashes we are seeing in nautilus and gnome-shell, but can't really verify that
[09:28] <seb128> darkxst, I did cherrypick the most common segfault one earlier in the week
[09:29] <darkxst> seb128, the nautilus one?
[09:29] <seb128> darkxst, after verifying it fixes the nautilus segfault
[09:29] <seb128> yes
[09:29] <seb128> the other ones are more intrusive, I would prefer have some upstream testing time before cherrypicking
[09:29] <darkxst> ok we are still getting some crashes in gnome-shell though
[09:29] <seb128> the new gtk is in the archive for less than a day
[09:29] <seb128> are you sure you still have issues and people upgraded and restarted their running instance of the shell?
[09:30] <seb128> they maybe still had gnome-shell running from before the update
[09:30] <seb128> sil2100, hello?
[09:30] <darkxst> yeh who knows, will leave it a couple of days and see
[09:30] <seb128> we will get the other fixes in anyway
[09:31] <seb128> just give them a few days of upstream testing, as said there are some non trivial changes there
[09:34] <sil2100> seb128: oh, sorry!
[09:34] <sil2100> One moment :)
[09:34] <sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4733356
[09:38] <darkxst> seb128, sure
[09:41] <seb128> Laney, hum, so that doesn't work, I wonder if there is a stacking there or something
[09:41] <Laney> that?
[09:41] <Laney> the gsd thing?
[09:41] <seb128> yes
[09:42] <Laney> yeah
[09:42] <seb128> I tried to enable the compiz plugin, that works
[09:42] <seb128> but the background goes over nautilus icons
[09:48] <seb128> Laney, https://bugs.launchpad.net/ubuntu-gnome/+bug/1159430 has quite some details from Adam Dingle on the issue
[09:48] <ubot2> Ubuntu bug 1159430 in Ubuntu GNOME "Nautilus 3.7.92 breaks desktop background on Unity" [Low,Confirmed]
[09:48] <seb128> he has a compiz patch on there
[09:48] <seb128> " The code there does check for desktop windows (i.e. of type _NET_WM_WINDOW_TYPE_DESKTOP) and prevents them from being transparent."
[09:48] <seb128> cf comment #15
[09:53] <Laney> mmm, he's done a fair bit of work there
[09:53] <seb128> yeah
[09:54] <seb128> but I don't like how flaky that is, and how many components it impacts on
[09:54] <seb128> we are up to 5 components to patch, including compiz
[09:56] <seb128> Laney, I'm pondering going with the patch from #21, aka revert the rgba changes
[10:01] <Laney> I found another place in the background plugin
[10:01] <Laney> see 521-ish
[10:01] <Laney> in plugins/background/gsd-background-manager.c
[10:06] <seb128> Laney, I'm asking sam on  #ubuntu-unity about compiz
[10:08] <Laney> ** (gnome-settings-daemon:28327): DEBUG: Draw background? no
[10:09] <Laney> getting further
[10:12] <Laney> hrm, gnome-session crashed
[10:15] <seb128> Laney, I got it working
[10:15] <seb128> Laney, by dropping that check as well
[10:15] <Laney> yeah?
[10:15] <Laney> it's all weird here
[10:15] <seb128> Laney, and by changing the nautilus wm hint to not be _DESKTOP (to workaround the compiz issue)
[10:16] <seb128> Laney, Sam is looking at compiz
[10:16] <Laney> 'it' = compiz?
[10:16] <seb128> 'it' being: nautilus 3.8 + gsd to display the background
[10:16] <Laney> aha
[10:18] <Laney> does sam think he can fix compiz for that?
[10:18] <seb128> Laney, so to get there I had to drop the 2 gsd checks, tweak the theme .css with the patch from the bug I pointed, change the nautilus hint to workaround compiz trying to be clever
[10:18] <seb128> enable back the g-s-d plugin
[10:18] <seb128> we are not quite there yet :/
[10:18] <seb128> Laney, he's looking at it
[10:18] <Laney> and it makes use of a gsd 3.6 only plugin
[10:20] <sil2100> mlankhorst: hi!
[10:20] <seb128> well, Sam is looking at making things work with compiz's wallpaper plugin
[10:20] <mlankhorst> g'day
[10:20] <seb128> unity8 will draw the background
[10:21] <Laney> right
[10:21] <seb128> and it's not hard to add the g-s-d plugin back meanwhile, it's not like it was a patch to rebase
[10:21] <seb128> it's just a dir to add back
[10:21] <sil2100> mlankhorst: I've been wondering - since the new X + unity needs a call for testing, right? Is that being prepared?
[10:21] <sil2100> For all drivers
[10:22] <mlankhorst> erm the drivers are fine, it's the same drivers with a bump to rebuild abi, and opengl doesn't change at all
[10:22] <sil2100> So no call for testing is necessary you think?
[10:22] <Laney> anyway, there's a kind of path here
[10:22] <Laney> seb128: care to summarise on the bug?
[10:22] <mlankhorst> indeed, but a newer fglrx is still needed atm
[10:23] <seb128> Laney, will do, I'm pondering patch back nautilus old desktop drawing back meanwhile so we can update to 3.8
[10:23] <seb128> then we can get compiz, the theme, etc fixed
[10:23] <seb128> and drop the patch when moons are aligned
[10:23] <sil2100> mlankhorst: so, are we blocked on something to get this released?
[10:24] <Laney> seb128: is that alright for shell?
[10:24] <seb128> Laney, it's not any different than keeping nautilus 3.6 as from today...
[10:27] <mlankhorst> sil2100: I think tseliot needs to push a newer fglrx, still, but that's about
[10:27] <mlankhorst> it
[10:27] <tseliot> mlankhorst: BTW problem solved with fglrx and 3.10 :)
[10:28] <mlankhorst> oh there we go, no blockers then?
[10:28] <sil2100> Excellent
[10:28] <tseliot> sil2100: what drivers do you need?
[10:28] <sil2100> Well, I would still feel a bit better if we had a call for testing though... I'm always worried, even with things that seem to 'not break anything'
[10:28] <mlankhorst> tseliot: we need it in the archive..
[10:29] <tseliot> mlankhorst: ok which one and what version?
[10:29] <Laney> seb128: yeah, true, just thought of that too
[10:29] <mlankhorst> tseliot: whichever works with x1.14 :-)
[10:29] <Laney> so yeah, go ahead in the strong hope that it's not something we keep until the end of unity 7 :-)
[10:29] <sil2100> tseliot: I meant it more like "let's have everyone test the new X + unity tested by a wide audience of all drivers to see if nothing got broken"
[10:29] <sil2100> ;)
[10:30] <mlankhorst> unity won't break from a new x, it will break from a new mesa..
[10:30] <tseliot> mlankhorst: so, I shouldn't even bother packaging the stable driver without ABI 14 support?
[10:30] <mlankhorst> probably not :-)
[10:31] <tseliot> sil2100, mlankhorst: as I can simply upload the latest beta of fglrx with ABI 14 support
[10:31] <tseliot> and then update it to stable when that is available
[10:32] <sil2100> tseliot: sounds fine with me
[10:32] <tseliot> ok then
[10:47] <sil2100> tseliot, mlankhorst: so, once fglrx is released, we'll be able to release the new X, yes? Since I need to coordinate the release of the new unity with the new xi
[10:48] <tseliot> sil2100: yes, that's correct. Both fglrx and nvidia will work with the new X
[10:58] <sil2100> cyphermox: arrgh, you still didn't push your changes to indicators-client? I'll modify those deps myself then
[11:27] <seb128> sil2100, libdbusmenu tests seem to be flacky in trunk
[11:29] <sil2100> seb128: I'm waiting for Ted to poke him about this anyway
[12:42]  * didrocks is ready to build whatever webkit version is needed, 35GB free now \o/
[12:51] <desrt> Laney: have you been following this ext4/glib/dconf data loss saga?
[12:51] <Laney> desrt: not so much, but I see Debian took a revert from walters
[12:51] <Laney> from yesterday
[12:51] <desrt> Laney: probably you should be aware of this.  we're reverting commits on master and i'm currently arguing with ted ts'o
[12:51] <desrt> i think ubuntu carries the change, so i recommend that you revert it asap
[12:52] <Laney> which is going to be in the package I'm currently building
[12:52] <desrt> oh.  great.
[12:52] <Laney> just the one though - anything else?
[12:52] <desrt> note also: mclasen backported the change into the stable branch (?!?)
[12:52] <desrt> so make sure you didn't SRU it and if you did, SRU a fix
[12:53] <Laney> we only have 2.36.0
[12:53] <desrt> cool
[12:53] <desrt> i have a sneaky suspicion that it's actually the fallocate() causing the problem, not the lack of fsync()
[12:53] <Laney> how's the argument going?
[12:54] <desrt> ....ted ts'o is.... an interesting individual
[12:55] <Laney> ho hum
[12:56] <desrt> his reply to my request for clarification turned into an impressive rant about an obsessive-compulsively-window-positioning woman who plays tuxracer all the time on proprietary drivers that crash her system
[12:56] <Laney> er, right, I'm sure that helped clarify the problem
[12:58] <didrocks> sil2100: hey, coming to the news! :)
[12:58] <didrocks> sil2100: so apps in manual publishing mode, is it wanted?
[12:58] <didrocks> (and you did look I guess on the other stacks failing?)
[12:59] <sil2100> didrocks: yes,
[13:00] <sil2100> didrocks: I mean:
[13:00] <sil2100> didrocks: apps failed during the check job last time (singular failure) but I re-ran it
[13:01] <didrocks> sil2100: ah, it's in manual publishing mode now :)
[13:01] <sil2100> didrocks: now I can publish it, thanks for pointing it out! Indicators is failind because of libdbusmenu failing unit test for armhf
[13:02] <Laney> mlankhorst: I think my SPDs are damaging one of my ankles :(
[13:02] <didrocks> sil2100: do you think it's a flacky thing?
[13:02] <Laney> One which has previously had surgery and contains metal
[13:02] <Laney> Started to get some weird aching in the last few days and I just realised it's probably because of this
[13:02] <sil2100> didrocks: looked like some introspection thing, so I was guessing just something got broken with autopilot
[13:03] <sil2100> didrocks: I also poked mlankhorst regarding the new X + unity
[13:03] <sil2100> didrocks: he said no call for testing is needed, and once tseliot releases the new fglrx it's all ready for release
[13:04] <tseliot> yes, hopefully my uploads will finish soon...
[13:04] <seb128> sil2100, mlankhorst: we told asac and olli we would give them advance warning with a ppa for testing
[13:04] <seb128> so call for testing is needed
[13:04] <seb128> mlankhorst, ^
[13:04] <seb128> that's not optional
[13:04] <didrocks> sil2100: ok, and unity/webcreds failing is under control?
[13:04] <sil2100> That's fine with me, since I wanted the call for testing anyway
[13:05] <seb128> mlankhorst, some people are concerned there might be issues with the new xorg stack and didn't want to upgrade at all to avoid taking risks, the tradeoff was that we do another call for testing so please do that
[13:05] <seb128> sil2100, ^
[13:05] <seb128> sil2100, mlankhorst: thanks ;-)
[13:05] <sil2100> didrocks: the unity failure was strange, but I thought that mhr3_ is in the middle of debugging
[13:07] <didrocks> sil2100: ok
[13:08] <sil2100> Will talk to him in a moment about it
[13:09] <mhr3_> sil2100, i didn't get a chance to connect to it, our meeting got prolonged
[13:09] <sil2100> Uh
[13:09] <sil2100> :)
[13:09] <sil2100> Ok
[13:09] <sil2100> ;p
[13:16] <seb128> Laney, can you push your UNRELEASED->saucy+tag revision to nautilus' vcs?
[13:39] <didrocks> sil2100: hum, so what are you doing for Unity? ;)
[13:39] <didrocks> and apps?
[13:39] <Laney> seb128: oh yes, that, ok
[13:39] <jbicha> seb128: you know that Classic Mode is just GNOME Shell with a lighter gray theme and a few extensions?
[13:39] <seb128> Laney, thanks
[13:39] <sil2100> didrocks: ah! I'll publish apps now, I'm busy with trying to unblock parts of webcreds
[13:39] <seb128> jbicha, yes, why?
[13:40] <didrocks> sil2100: kenvandine is online, he can maybe help :)
[13:40] <Laney> oh, whoops, I cleared that VCS out this morning
[13:40] <didrocks> sil2100: oh, well, if apps can be published without webcreds, sure :)
[13:40] <didrocks> sil2100: but I think nothing is preventing just to relaunch unity tests, right?
[13:40] <sil2100> didrocks: the packaging changes you ACK? :) http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_webbrowser-app_0.20daily13.06.21-0ubuntu1.diff
[13:40] <jbicha> seb128: nothing, just clarifying your earlier comment
[13:40] <seb128> Laney, can you copy back the diff and copy? I would do it by vcs is half merged with jbicha's 3.8 update at this point
[13:40] <seb128> jbicha, what did I say?
[13:40] <didrocks> sil2100: I merged it, so yeah ;)
[13:41] <Laney> easily rectified
[13:41] <Laney> done
[13:42] <jbicha> seb128: never mind, the conversation was just hard to follow at that point
[13:42] <seb128> jbicha, alright
[13:43] <seb128> jbicha, in any case I'm going to upload nautilus 3.8 with the background changes reverted today
[13:43] <kenvandine> sil2100, ah... do you know what is blocking webcred?
[13:43] <seb128> jbicha, sam has a fix for compiz already, so once we get that merged and in the archive we can drop the patch again and use g-s-d
[13:43] <sil2100> kenvandine: libsignon-glib is failing because of the linking issue
[13:43] <kenvandine> sil2100, i haven't looked yet... but so much is failing to build it must be somewhere else
[13:43] <sil2100> kenvandine: there's also one package that's failing because of an unit test on armhf
[13:44] <kenvandine> yesterday they were all failing on armhf because of held packages
[13:44] <kenvandine> gvfs or something
[13:44] <seb128> kenvandine, hey, the gtk arch mismatch is resolved
[13:44] <kenvandine> seb128, great
[13:44] <kenvandine> so today they are real failures :/
[13:44] <seb128> kenvandine, hey btw, happy friday ;-)
[13:45] <sil2100> kenvandine: it's an unit test failure, so I doubt it would be related ;)
[13:45] <Laney> but that test failure was because of a genuine bug
[13:45] <seb128> kenvandine, do you think you have some spare slot to review Laney's background plugin today? would be good to get that in
[13:45] <kenvandine> seb128, yes... i will do it right now :)
[13:46] <didrocks> seb128: but stacks being green is a priority! stealer of kenvandine's time :p
[13:46] <jbicha> seb128: Arch has a gnome-settings-daemon-compat package they pieced together from abandoned bits of g-s-d
[13:46] <jbicha> https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/gnome-settings-daemon-compat
[13:46] <jbicha> it was mentioned on https://mail.gnome.org/archives/gnome-flashback-list/2013-April/msg00001.html
[13:47] <kenvandine> yeah... i spent like half my day reviewing branches yesterday... and never got back to finishing laney's
[13:47] <kenvandine> sorry Laney, let me knock that out before i get distracted again
[13:47] <seb128> jbicha, I will just go for the easiest way and patch that back in g-s-d to start
[13:47] <Laney> /o\
[13:47] <Laney> np
[13:47] <seb128> jbicha, unity will take over rendering the background at some point anyway
[13:47] <seb128> jbicha, so I don't plan to invest effort in packaging code that will go away
[13:48] <jbicha> yeah, Unity or Compiz handling it would be best
[13:48] <jbicha> it would still be an issue for those trying to use Flashback with Metacity but there's like no developers supporting that currently
[13:50] <jbicha> stgraber: highvoltage: you're aware of the wallpaper difficulties, right? ^
[13:52] <asac> sil2100: seb128: call for testing: please CC olli and kgunn directly in your call
[13:52] <seb128> jbicha, well, the first step solution with g-s-d should make it a no issue for most flavors
[13:52] <seb128> asac, ok
[13:52] <asac> (and get their explicit ack :) ...)
[13:52] <asac> thx
[13:52] <highvoltage> jbicha: I remember reading about it but haven't checked it out yet
[13:53] <sil2100> asac: ACK
[13:53] <seb128> asac, yw, oh and enjoy your holidays!
[13:54] <asac> thanks!!
[13:59] <ogra_> huh ? didnt you just have a month off ?
[14:00] <seb128> Laney, is your recent nautilus fix needed for 3.8?
[14:00] <Laney> it's a different patch
[14:00] <Laney> I posted it to the upstream bug
[14:00] <seb128> Laney, do you have it somewhere?
[14:00] <seb128> oh ok
[14:00]  * seb128 goes to grab that
[14:03] <kenvandine> Laney, approved
[14:03] <Laney> kenvandine: \o/
[14:04] <Laney> thanks for looking
[14:04] <kenvandine> Laney, isn't SwappableImage and UbuntuSwappableImage redundant?
[14:04] <seb128> Laney, sil2100: https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1159430/+merge/170822
[14:04] <kenvandine> i think it would be cleaner to collapse that
[14:04] <kenvandine> but i don't feel strongly enough to reject it :)
[14:05] <mitya57> didrocks, mterry: I'm going to merge qtwebkit from debian at some point, which introduced a build-dep on qttools5-dev-tools, should I add a qttools task to bug 1192567?
[14:05] <ubot2> Launchpad bug 1192567 in qtsensors-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New] https://launchpad.net/bugs/1192567
[14:05] <Laney> kenvandine: yeah they could be, I was just trying to provide a UbuntuSwappableImage with some defaults
[14:05] <Laney> USI will hopefully go away anyway though
[14:05] <kenvandine> yeah
[14:05] <kenvandine> this is iterative development :)
[14:05] <didrocks> mitya57: do you mind waiting a little bit? I would hope that we can first get that main transition done, and then trying to merge to debian
[14:05] <didrocks> with*
[14:05] <didrocks> mitya57: if you don't mind :)
[14:05] <kenvandine> i don't want to slow down velocity :)
[14:06] <didrocks> kenvandine: ;)
[14:06] <mitya57> didrocks: OK, I'll wait, and then file a new MIR for qttools
[14:06] <kenvandine> hehe
[14:06] <Laney> good chap
[14:06] <didrocks> mitya57: thanks :)
[14:06] <Laney> that's why I didn't wait until that got in the toolkit
[14:06]  * mitya57 has done 4 Qt merges today, looks enough
[14:06] <Laney> that + I can't quite make the generic swappable image work yet :P
[14:06] <kenvandine> ah, so SwappableImage is going in the sdk?
[14:06] <kenvandine> cool!
[14:07] <Laney> well, I'm first proposing a generic CrossFadeImage which is split out of unity 8
[14:07] <Laney> but you can't put that into UbuntuShape just yet so I'll propose another component which can take it
[14:08] <Laney> hopefully the sdk guys will like it enough
[14:08] <kenvandine> very useful
[14:08] <sil2100> seb128: thanks, will look into that one! We're not doing daily-releases of compiz right now though, hm
[14:08] <seb128> sil2100, see #ubuntu-unity as well
[14:08] <kenvandine> Laney, i actually wanted something like that for my instagram app :)
[14:08] <seb128> sil2100, speaking fo compiz we will need a landing at some point, the current version ftfbs in saucy
[14:08] <Laney> I quite like the effect
[14:09] <mitya57> didrocks: do you want me to commit your today's upload to bzr?
[14:09] <seb128> sil2100, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130614-saucy.html
[14:09] <mterry> mitya57, ah sure
[14:09] <didrocks> mitya57: I'm unsure if this is still valid in 5.1
[14:09] <mterry> mitya57, oh, didrocks already answered
[14:09] <didrocks> mitya57: I wanted to discuss it with Mirv, but he's on holidays
[14:10] <mitya57> didrocks: at least adding a changelog entry can be helpful
[14:10] <didrocks> mitya57: sure, please feel free to do it ;)
[14:13] <mitya57> done
[14:15] <didrocks> thx!
[14:17] <mlankhorst> seb128: I'm going to need a compatible unity then :/
[14:17] <kenvandine> seb128, larsu: i uploaded gsettings-qt to ppa:ubuntu-desktop/ppa
[14:17] <seb128> mlankhorst, just rebase the patch on unity trunk and upload that to your ppa?
[14:17] <seb128> kenvandine, larsu: \o/
[14:18] <larsu> kenvandine: awesome! That was fast :)
[14:18] <kenvandine> and the patch to qtdeclarative is in saucy
[14:18] <kenvandine> so should be good for real use :)
[14:18] <kenvandine> larsu, get some tests and we'll start daily releasing it :)
[14:20] <larsu> kenvandine: planning to do that today, after finally reviewing some of desrt's patches
[14:21] <dobey> kenvandine: is there a problem with using qtwebkit with qt5 btw?
[14:21] <kenvandine> dobey, a few problems
[14:22] <kenvandine> it isn't in main yet... and we don't want to support it in main long term
[14:22] <kenvandine> we have a long term solution
[14:22] <dobey> which is?
[14:22] <kenvandine> consolidated webkit of sorts
[14:23] <kenvandine> so we only have one version of webkit to maintain
[14:23] <kenvandine> chrisccoulson is working on it
[14:23] <dobey> you mean, building all the binary packages from the one lp:webkit source, sort of thing?
[14:23] <kenvandine> yup
[14:23] <kenvandine> so instead of having a bunch of packages that bundle their own forks of different versions of webkit
[14:24] <kenvandine> so instead
[14:24] <kenvandine> so no... not one source package
[14:24] <dobey> except for all the ones that still will :)
[14:24] <kenvandine> but
[14:24] <kenvandine> stop using the bundled forks of webkit
[14:24] <Sarvatt> is there a newer unity snapshot planned for upload today?
[14:24] <Saviq> tedg, greyback had the idea that it's maybe upstart that should report app launched to zg
[14:24] <kenvandine> we'll rebuild webkitgtk, webkitqt, etc
[14:24] <Saviq> tedg, wtyt?
[14:24] <kenvandine> based on our webkit
[14:25] <tedg> Saviq, In the upstart job, yeah, we could do that.
[14:25] <Saviq> tedg, yeah, exactly
[14:25] <Sarvatt> I need to update https://launchpad.net/~canonical-x/+archive/x-staging but don't want to put 0619 and do a call for testing if there's going to be a 0621 that breaks the world because it doesn't support that xserver..
[14:26] <Saviq> tedg, would include jobs started from the console
[14:26] <tedg> Saviq, Yeah, I think that makes sense.
[14:27] <Saviq> tedg, cool, who could look at doing that?
[14:27] <tedg> Saviq, I think it's going to be me.  Do you guys know what schema you want it as?  (in zg)
[14:28] <Saviq> tedg, I think whatever schema it is currently there in
[14:28] <Saviq> tedg, only we might need to add stage and form factor hints
[14:28] <tedg> Saviq, Heh
[14:28] <tedg> Saviq, Where are we getting the formfactor from BTW.
[14:28] <tedg> I'd like to make that into an upstart event as well.
[14:28] <tedg> So that we can make indicators handle it correctly.
[14:29] <Saviq> tedg, for scopes it's the shell that "tells" the scope with each connection / search what form factor results it's interested in
[14:29] <Saviq> tedg, and I think we went for the same for indicators
[14:29] <greyback> tedg: can use notify_desktop_launch() in libglib as reference code, see gio/gdesktopappinfo.c
[14:30] <Saviq> tedg, i.e. https://code.launchpad.net/~nick-dedekind/unity/8.indicators-client/+merge/168022, line 4074
[14:31] <tedg> Saviq, We perhaps want to start different executables based on form factor though, so we could have a job "start on form-factor DEVICE=phone"
[14:31] <Saviq> tedg, for now we're hardcoding "phone"
[14:31] <tedg> greyback, Cool, thanks!
[14:31] <Saviq> tedg, that's too limited
[14:31] <tedg> Saviq, It's also encoded in the indicator files, for the more complex cases.
[14:31] <Saviq> tedg, we need to be able to have different form factors per screen
[14:31] <Saviq> on a single device
[14:31] <tedg> Ah, I see.
[14:32] <tseliot> sil2100: the drivers are in
[14:34] <sil2100> tseliot: excellent! Thanks for the info :)
[14:34] <tseliot> :)
[14:54] <didrocks> sil2100: on unity: I would say we can consider the number of tests passing right, the fact that the check job failed is due to the previous run timeouting I guess
[14:55] <didrocks> sil2100: FYI, just rerun publishing forcing forcing
[14:55] <sil2100> didrocks: I was looking at those, felt a bit strange indeed
[14:55] <didrocks> sil2100: yeah, it's a bad logic side effect I guess
[14:55] <sil2100> I saw some strangeness in the test results, but I guess we have those since a while
[14:55] <sil2100> Like the trash left open, some nautilus windows ;p
[14:55] <didrocks> sil2100: something we can fix with the dashboard having the logic :p
[14:55] <didrocks> yep :)
[14:56] <sil2100> didrocks: ACK, I think we also need to finally clean up this autopilot tests in unity one day ;)
[14:56] <didrocks> sil2100: so, we are in manual publishing mode before of indicators and webcred
[14:56] <didrocks> sil2100: that would be nice¿
[14:56] <didrocks> …
[14:57] <sil2100> In webcreds I unblocked libsignon-glib, not sure how's the status of the failing unit test
[14:57] <didrocks> sil2100: do you think you can force publication of unity or you are afraid of indicators and webcreds deps?
[14:58] <sil2100> didrocks: I think we can force publication, there wasn't much changes in indicators and webcreds I guess
[14:58] <sil2100> kenvandine: right?
[14:59] <didrocks> sil2100: you know, Friday evening is the perfect timing for this :p
[14:59] <sil2100> didrocks: I'll check the stack on my own body and force publication if all is ok - and if you ACK the diffs ;)
[14:59] <didrocks> sil2100: oh, there are some diffs?
[14:59]  * didrocks didn't notice
[15:00] <didrocks> oh right
[15:00] <sil2100> music and videoz
[15:01] <didrocks> sil2100: hum, does the unity-lens-video-remote doesn't need anymore unity-lens-video?
[15:01] <didrocks> (as the deps is removed)
[15:02] <kenvandine> nothing big has changed in webcred
[15:02] <sil2100> pstolowski: ^ ?
[15:02] <didrocks> mhr3_: you did that change ^
[15:02] <kenvandine> i'll get the build going
[15:02] <didrocks> and bind to a totally unrelated MP
[15:02] <kenvandine> but it's safe to publish the other stacks without it
[15:02] <didrocks> as for the other one :p
[15:03] <kenvandine> no API changes or anything like that
[15:03] <mhr3_> didrocks, yep
[15:03] <mhr3_> didrocks, same with music
[15:03] <didrocks> mhr3_: why is it in the same MP?
[15:03] <mhr3_> didrocks, scopes are independent these days
[15:04] <didrocks> mhr3_: that makes the changelog weird :p
[15:04] <mhr3_> didrocks, cause i'm lazy to create branches for 2line changes
[15:04] <didrocks> mhr3_: in that case, please inform debian/changelog manually
[15:04] <mhr3_> it's a separate rev though :P
[15:04] <didrocks> mhr3_: especially when doing packaging change
[15:04] <didrocks> mhr3_: well, it's one merge in trunk
[15:05] <mhr3_> didrocks, you mean to bump the debian version when doing changes to debian/*?
[15:05] <didrocks> sil2100: other than being disappointed from mhr3_, +1 on packaging changes then for the unity stack :p
[15:05] <didrocks> mhr3_: no, just tell "remove the dep on …" in debian/changelog
[15:06] <mhr3_> didrocks, noted, sorry
[15:06] <didrocks> mhr3_: no worry, I'm just so so so dissapointed :p
[15:06] <didrocks> I thought of a bug in my code first! :)
[15:06] <mhr3_> didrocks, "i'm not mad, i'm just disappointed" :)
[15:07] <didrocks> heh
[15:07] <mhr3_> but apparently today is the day when /me does things wrong
[15:07] <didrocks> mhr3_: unfortunately, the next run didn't block while doing tests…
[15:07] <didrocks> ah?
[15:08] <mhr3_> didrocks, let's just say it's not today's first screwup
[15:08] <mhr3_> didrocks, why didn't it block?
[15:09] <didrocks> mhr3_: well, we didn't get the "dbus/mem full" issue
[15:09] <didrocks> mhr3_: even if the rerun was without rebooting the machine
[15:09] <mhr3_> oh that kind of block
[15:09] <didrocks> jibel: FYI ^
[15:09] <sil2100> didrocks: tested just upgrading packages from the unity stack and all seems to work, so I publish!
[15:10] <didrocks> mhr3_: yeah, the one we don't want, but need to debug :p
[15:10] <didrocks> sil2100: \o/
[15:10] <sil2100> Friday releases are nice
[15:10] <didrocks> heh
[15:10] <mhr3_> didrocks, right, right
[15:10] <ogra_> sil2100, only the untested ones
[15:10] <ogra_> else it is less exciting
[15:10] <mhr3_> didrocks, any chance to add a hook to send a mail to me when it's running for >2 hours? :)
[15:11] <didrocks> ogra_: we can do that if needed! :)
[15:11] <ogra_> heh
[15:11] <didrocks> mhr3_: well, not that easy, I think I'll ping you as we did, hopefully, you won't be in meeting :p
[15:20]  * seb128 is away for ~1h
[15:25] <tedg> seb128, Do you know if anyone is preparing a g-s-d upload?  It seems the upstart job there is what's breaking the unity one.
[15:26] <Laney> tedg: what's wrong with it?
[15:27] <tedg> Laney, It's waiting on gnome-session or unity, but unity needs to start after g-s-d so that the XAtoms are set.
[15:27] <tedg> Laney, So we're setting up a circular dependency by fixing the Unity one.
[15:29] <tedg> Laney, https://code.launchpad.net/~ted/unity/upstart-job/+merge/170709
[15:30] <tedg> With that fix to the Unity side, and the g-s-d fix.  We get to a good place.
[15:33] <Laney> Hrm.
[15:33] <kenvandine> seb128, can you do a preNEW review of lp:gsettings-qt for me?
[15:33] <Laney> I'm not sure about this.
[15:33] <tedg> Laney, What's your concern?
[15:34] <Laney> I don't really get why what we have now is wrong
[15:34] <Laney> the manual starting of unity-panel-service is weird
[15:35] <tedg> It's a fallback case.  It'll go away once we migrate everyone over.
[15:36] <tedg> We don't want unity to start until after g-s-d
[15:36] <tedg> And we don't want two jobs emitting desktop-start
[15:36] <Laney> 'starting' is supposed to do that
[15:36] <Laney> http://manpages.ubuntu.com/manpages/raring/en/man7/starting.7.html
[15:36] <Laney> see the example
[15:37] <tedg> Laney, Sure, but we want started here.
[15:37] <Laney> it says 'if unity is starting, start this job (g-s-d)'
[15:38] <Laney> and blocks until it's finished
[15:38] <tedg> "started before and stopped after it"
[15:38] <tedg> We want started after it.
[15:38] <Laney> you want g-s-d started before
[15:38] <tedg> Yes
[15:39] <tedg> So unity should be "start on started g-s-d"
[15:40] <xnox> Laney: yeah, if unity is "start on started g-s-d" and gsd is "start on starting unity" neither will ever start.
[15:40] <Laney> unity isn't start on started gsd
[15:40] <Laney> it's start on xsession SESSION=ubuntu
[15:40] <xnox> Laney: the new one, is.
[15:40] <Laney> yes, but that's not what we have now
[15:40] <tedg> Laney, We don't want it to start then, we want it to start after g-s-d.
[15:41] <Laney> why?
[15:41] <tedg> Laney, The g-s-d job can't block the unity job.
[15:41] <xnox> Laney: but that's what's proposed for unity to be changed to. Thus, g-s-d needs a change as well.
[15:41] <Laney> the goal is to start unity
[15:41] <tedg> Laney, Because g-s-d sets XAtoms that we want set before unity runs.
[15:41] <Laney> and that should cause all of the other services to start
[15:41] <Laney> which 'starting unity' gets you
[15:41] <tedg> Starting unity doesn't cause the Unity start to block.
[15:41] <xnox> tedg: have you verified that XAtoms are not set, in the current configuration.
[15:41] <xnox> tedg: it should be block atm.
[15:41] <xnox> s/block/blocked/
[15:43] <xnox> Laney: g-s-d has on condition, thus only one of the gnome-session or unity are blocked. as per http://upstart.ubuntu.com/cookbook/#block-another-job-until-yours-has-started
[15:43] <xnox> Laney: tedg: when running unity, is gnome-session also spawned/started?
[15:43] <Laney> it's stopped by unity's pre-start script
[15:44] <Laney> tedg: how do I check this XAtoms thing?
[15:44] <Laney> in the current setup, in a saucy desktop VM I can comment out the starting condition for gnome-session and the pre-start script in unity and then I get a unity session
[15:44] <Laney> 'status unity' and 'status gnome-settings-daemon' show they are both upstart managed
[15:46] <tedg> I guess it's a matter of intent though, there's no dependency that g-s-d has on Unity, Unity has a dep on it.  So if we added a gnome-shell upstart job we wouldn't want to motify the g-s-d one.
[15:46] <tedg> modify
[15:46] <tedg> So then the gnome shell startup would be: "start on xsession SESSION=gnome and started gnome-settings-daemon"
[15:47] <tedg> And the Unity one would be: "start on xsession SESSION=ubuntu and started gnome-settings-daemon"
[15:53] <Laney> tedg: started doesn't work like that
[15:54] <Laney> It won't cause g-s-d to be started - its start on condition still has to be fulfilled
[15:54] <Laney> xnox: confirm
[15:54] <tedg> Yes, it won't cause it to be started.
[15:55] <Laney> so what then?
[15:55] <tedg> gsd needs to be: start on started dbus and starting gnome-session
[15:55] <tedg> So then it flows down: gnome-session -> g-s-d -> (unity | shell)
[15:55] <xnox> tedg: in above examples from :46 & :47, gsd will have to "start on xsession"
[15:56] <tedg> Why?
[15:56] <tedg> xnox, g-s-d probably should... but I don't think it'll *have to* as long as every session we care about uses it.
[15:56] <tedg> xnox, Which is the case today, but if, for instance, Kubuntu switched to upstart user session, we'd have to be more precise.
[15:57] <xnox> tedg: if g-s-d has no "start on" whats-so-ever, and unity has "and started g-s-d", then unity will never start as nothing triggers for g-s-d to start.
[15:57] <tedg> xnox, Yes, g-s-d would be: start on started dbus and starting gnome-session
[15:58] <Laney> no, that wouldn't work
[15:58] <xnox> tedg: that would work. as long as everyone who is "starting gnome-session" wants g-s-d, or otherwise stops g-s-d.
[15:58]  * xnox goes to look at the jobs.
[15:58] <Laney> it doesn't work for the unity.conf case
[15:58] <Laney> which skips gnome-session entirely
[15:59] <xnox> Laney: ah, that was my question from before - does or doesn't unity use gnome-session
[15:59] <tedg> Laney, Well, it would wait on g-s-d which waits on gnome-session.
[15:59] <Laney> and nothing starts gnome-session
[15:59] <tedg> gnome-session is: start on started dbus and xsession SESSIONTYPE=gnome-session
[15:59] <tedg> So dbus starting starts gnome-session.
[16:00] <tedg> gnome-session starting starts g-s-d
[16:00] <tedg> g-s-d having started starts unity
[16:00] <tedg> unity started start unity-panel-sevice
[16:00] <tedg> etc.
[16:01] <Laney> isn't the goal to stop using gnome-session?
[16:03] <tedg> Laney, In the Unity8 case.
[16:03] <tedg> Not the Unity7 case
[16:03] <tedg> But that'll be a different set of upstart jobs
[16:04] <Laney> why the unity job at all then?
[16:04] <tedg> To run Unity 7 in upstart.
[16:04] <Laney> but it doesn't do that
[16:04] <tedg> ?
[16:04] <Laney> because of the pre-start
[16:04] <Laney> it just quits out if you're using gnome-session ...
[16:05] <tedg> Yes, but that was a work around to make it so that we could get things working.
[16:05] <tedg> We'll drop it as soon as we update gnome-session to not start Compiz for the Ubuntu session.
[16:05] <tedg> But that way we could start working on it, without breaking the world.
[16:06] <xnox> Laney: realistically, i wouldn't expect to be able to stop using gnome-session, without also stopping to use g-s-d.
[16:07] <xnox> tedg: that also means you can use .override file to override start on conditions of the g-s-d.
[16:07] <tedg> Hmm, that sounds scary.
[16:08] <xnox> tedg: echo "start on started dbus" | sudo tee -a /etc/xdg/upstart/gnome-settings-daemon.override
[16:08] <Laney> seems wrong
[16:08] <tedg> Yeah, I don't think we want that.
[16:08] <xnox> tedg: you can drop .override file into any "higher-up" directory, e.g. /etc/xdg/xdg-ubuntu/upstart or /etc/xdg/upstart or ~/.conf/upstart/
[16:09] <tedg> At least in the base system.
[16:09] <tedg> Devs can do what they want to screw up their machines :-)
[16:09] <xnox> tedg: the beauty of "/etc/xdg/xdg-ubuntu/upstart" is that it _only_ takes effect for the ubuntu session, and none of the other sessions.
[16:09] <tedg> Sure, but let's get this right.
[16:10] <xnox> tedg: and we remap to call "Unity" "ubuntu" session somewhere in xsessions.....
[16:10] <tedg> What we want is to be able to tease the parts apart appropriately.
[16:10] <xnox> =)))))))))))))))
[16:10] <tedg> We don't wnat to make something like g-s-d dep on Unity, because, well, it doesn't.
[16:11] <Laney> That's not what it says currently, FWIW.
[16:12] <Laney> Anyway.
[16:12] <Laney> I can imagine taking something like your idea but without the start unity-panel-service hack. Just leave the conditions for that job how they are and it should work, no?
[16:13] <Laney> (g-session will still emit those events)
[16:15] <tedg> No, I don't think so.
[16:15] <tedg> We don't want the unity job emiting desktop-start and desktop-end
[16:15] <tedg> They are emitted by gnome-session
[16:16] <tedg> We don't want two jobs that are both expected to be running emiting the same events, else debugging will SUCK.
[16:16] <tedg> Also, we want the lifecycle of unity-panel-service to be closely tied to that of Unity itself.
[16:16] <tedg> Really, it doesn't exist, it's just a backing service for Unity.
[16:17] <tedg> The hack is just that, a hack, it'll go away when we change gnome-session to have everyone using the upstart jobs.
[16:17] <Laney> You won't have two.
[16:17] <Laney> You can still keep the bit to get rid of those..
[16:17] <Laney> I only added it there because I thought that gnome-session was going to go away.
[16:18] <tedg> We should probably change the name of this job to unity7...
[16:21] <tedg> Laney, So in distro today, the gnome-settings-daemon job has a start condition on Unity, do you agree that should go away?
[16:21] <Laney> So, add your starting conditions (doesn't matter if g-s-d gets uploaded right now or not since it's an 'or' condition). Get rid of the explicit start. Don't change unity-panel-service's conditions (or do it later once we're actually using the unity job). Sounds like a winning plan to me.
[16:22] <Laney> It should if it's unnecessary but you need to understand that it's g-s-d inserting itself before unity starts and not a dependency.
[16:22] <Laney> starting vs. started
[16:22] <tedg> Unfortunately the g-s-d "or" is causing a circular loop in Upstart.  We can argue whether that's a bug or not, but it is :-(
[16:22] <tedg> It's causing xsession-init to hang
[16:23] <Laney> Doesn't do that here
[16:24] <Laney> wait, I've still got pre-start commented out
[16:27] <Laney> Yeah. Still fine.
[16:28] <tedg> Hmm, it was happening for me Saviq and ChrisTownsend.
[16:28] <Laney> I'll give you my .conf files
[16:32] <Laney> http://people.canonical.com/~laney/temp/ think that's all the relevant ones
[16:33] <Laney> (still, have pushed g-s-d)
[16:33] <tedg> Laney, So the one that's different is that you don't have the upstream version of unity.conf
[16:33] <tedg> Laney, Though, the version you have is what I'm suggesting :-)
[16:33] <tedg> That seems to break the deadlock
[16:34] <tedg> So I guess I'm fine for doing the panel-service on desktop-start for now.
[16:34] <tedg> But I think we need to change it once we drop gnome-session starting compiz.
[16:35] <Laney> what I showed you is what I was suggestingn for you to have ;-)
[16:35] <Laney> but yes, changing unity-panel-service over would be fine if you want to
[16:35] <Laney> not now, but then
[16:36] <tedg> K, I'll put it in with a comment.
[16:37] <Laney> wunderbar
[16:41] <tedg> Laney, Updated diff: https://code.launchpad.net/~ted/unity/upstart-job/+merge/170709
[16:43] <Laney> tedg: LGTM
[16:47] <tedg> Laney, Can you say that on the MR?  :-)
[16:48] <Laney> sure
[16:53] <seb128> back
[16:53] <seb128> quite some backlog on that upstart discussion!
[16:53]  * seb128 decides to trust Laney on that one and skips reading
[16:54] <tedg> Oh!  Clearly continental bias there!
[16:55] <seb128> tedg, you are the one that tried to break our desktop and Laney stopped you from doing so, from what I can read ;-)
[16:55] <tedg> heh
[16:56] <Laney> we came to a noble understanding
[16:58] <Laney> seb128: did your gtk build finish? :P
[17:00] <seb128> Laney, yes, and my testing if correct blames gcc
[17:00] <seb128> I will redo a clean build with only gcc downgraded
[17:01] <seb128> something in that update it would be http://launchpadlibrarian.net/142260026/gcc-4.8_4.8.1-2ubuntu1_4.8.1-3ubuntu1.diff.gz
[17:01] <seb128> or http://launchpadlibrarian.net/142742772/gcc-4.8_4.8.1-3ubuntu1_4.8.1-3ubuntu2.diff.gz (less likely)
[17:02] <Laney> right then, i'll be off
[17:02] <Laney> have a good weekend everyone!
[17:03] <seb128> Laney, thanks, you too!
[17:07] <didrocks> see you Laney :)
[17:17] <Saviq> ooh, Enigmail asks whether to cipher an email before saving, interesting!
[17:26] <Saviq> or maybe that's because I enabled ciphering accidentally ;)
[17:32]  * didrocks waves good evening
[18:12] <ChrisTownsend> tedg: Laney: Hey guys, I just caught up on the whole Unity upstart stuff.  With the latest changes in the MP along with the g-s-d upstart change noted in the MP, it works now.  My question is, is there also going to be a new g-s-d package that changes the upstart job file?
[18:14] <tedg> ChrisTownsend, In the final version you shouldn't need it, but yes.
[18:14] <tedg> ChrisTownsend, So you should be twice as happy :-)
[18:15] <ChrisTownsend> tedg: Ok, sounds good.  As long as it all works out in the end, I'm satisified:)  I'll approve the MP from the Unity team's perspective.
[18:15] <tedg> Great, thanks ChrisTownsend!
[18:16] <ChrisTownsend> tedg: No problem!
[18:49] <tkamppeter> jasoncwarner_, hi
[19:31] <cjwatson> Hmm.  I want to order pizza, but my desktop won't start since today's upgrade.  This makes me sad. :-(
[19:32] <cjwatson> 'initctl emit xsession SESSION=ubuntu SESSIONTYPE=gnome-session' is just sitting there, which seems odd
[19:36] <jbicha> you're missing an upstart job for pizza?
[19:38] <cjwatson> http://paste.ubuntu.com/5787736/ - anything obviously missing here?
[19:40] <cjwatson> Fair bit of whining in .cache/upstart/unity-panel-service.log about being unable to talk to dbus in various ways, but it seems to have a DBUS_SESSION_BUS_ADDRESS env var
[19:50] <cjwatson> and strace indicates at least some successful communication with dbus
[19:51] <cjwatson> Hm, I can start terminals, I just have no panel or launcher or indicators
[19:56] <ChrisTownsend> cjwatson: The upstart jobs for unity & unity-panel-service are messed up.  Here is the MP to fix it: https://code.launchpad.net/~ted/unity/upstart-job/+merge/170709
[19:57] <ChrisTownsend> cjwatson: Also, notice this for the g-s-d job: https://code.launchpad.net/~ted/unity/upstart-job/+merge/170709/comments/380574
[19:58] <ChrisTownsend> I modified the unity.conf, unity-panel-service.conf, and g-s-d.conf by hand to get it working on my machine.
[20:02] <kenvandine> cyphermox, hey, did you have some build failures related to linking and pthread?
[20:06] <cjwatson> ChrisTownsend: Thanks.  I'm afraid that doesn't seem to be enough here.
[20:08] <ChrisTownsend> cjwatson: Hmm, that's not good:-(  So the xsession emit is still blocking for you?
[20:09] <cjwatson> No, that much has been fixed
[20:09] <cjwatson> unity7 is stop/waiting; compiz and unity-panel-service are running; still no visible launcher/panel/indicators
[20:10] <cjwatson> Removing "compiz;" from /usr/share/gnome-session/sessions/ubuntu.session results in unity7 being start/running but all other symptoms still the same
[20:11] <ChrisTownsend> cjwatson: Hmm, well, not sure off hand what that could be.  What happens if you type setsid unity in the terminal?
[20:12] <cjwatson> Everything flickers, the terminal moves down a row as if making way for a panel above it, I get a load of "compiz (core)" debug output
[20:13] <cjwatson> Still no furniture
[20:14] <cjwatson> Are you testing with "compiz;" still in ubuntu.session (which I understand to be the legacy case)?
[20:14] <ChrisTownsend> Sounds like a compiz plugin (perhaps opengl or unityshell) is not loading.
[20:15] <ChrisTownsend> No I don't have that.
[20:15] <cjwatson> http://paste.ubuntu.com/5787840/ is the debug spew
[20:15]  * ChrisTownsend Looks
[20:16] <cjwatson> I have used ccsm for various things in the past but I certainly never turned off unityshell
[20:16] <ChrisTownsend> Looks like unityshell somehow got turned off.
[20:16] <bschaefer> cjwatson, sometimes it turns it self off when it can't load it self :(
[20:16] <cjwatson> that said it appears to show as disabled in ccsm now
[20:17] <cjwatson> couple of keybinding compatibility complaints
[20:17] <ChrisTownsend> Hopefully enabling it will get it working.
[20:17] <cjwatson> ... and there we go, it's back
[20:17] <ChrisTownsend> Yea!
[20:20] <cjwatson> Thanks for the help
[20:20] <ChrisTownsend> cjwatson: My pleasure!
[20:23] <cjwatson> dinnertime at last
[20:26] <Sweetshark> the build "starts in X minutes" message on launchpad has a severe case of https://xkcd.com/612/
[20:27] <kenvandine> annoying... this is what's breaking the libsignon-glib builds
[20:27] <kenvandine> http://sourceforge.net/p/check/bugs/89/
[20:50] <Saviq> larsu, look what I found... http://bazaar.launchpad.net/~indicator-applet-developers/libusermetrics/trunk/view/head:/src/libusermetricsoutput/qvariantlistmodel.cpp
[20:50] <Saviq> this should really be submitted upstream
[20:50] <larsu> Saviq: neat! Thanks
[21:06] <larsu> Saviq: hm, can we use that in projects that require CLA?
[21:07] <Saviq> larsu, as long as it's licensed correctly, I think so (obviously if we'd like to re-license, we'd need to get rid of that, or obtain a license from digia)
[21:07] <Saviq> larsu, it's not really a copy, but a copy + s/StringList/VariantList/, more or less
[21:08] <Saviq> larsu, but we should definitely submit it upstream, or find out why it isn't there yet
[21:09] <larsu> Saviq: right, that seems to be the correct way to go
[21:09] <Saviq> larsu, but then, IANAL, so…
[21:12] <larsu> Saviq: me neither, but including a file with a non-canonical copyright in a project that is supposed to be (c) Canonical seems weird to me ...
[21:12] <Saviq> larsu, it's fine, the project is GPL, the file is GPL, so as long as the project is GPL, it's ok
[21:13]  * Saviq wanted to find a funny tweet about IANAL... note to self... don't ever google for "IANAL" again...
[21:13] <larsu> Saviq: LOL
[21:13] <Saviq> another thing to add to the list "you can't un-google..."
[21:14] <Saviq> and now my google history is... stained, for lack of a better word... forever
[23:43] <Laney> Trevinho: hey
[23:43] <Laney> oh, that was #-release
[23:43] <Laney> anyway, what's up?
[23:43] <Laney> is the upstart situation alright? I have a couple of minutes now.
[23:46] <Laney> Let me upload g-s-d if you are blocking on that.
[23:54] <Laney> (test building)
[23:59] <Laney> done