[03:49] <Mirv> morning
[05:30] <didrocks> hello guys
[05:41] <Mirv> hello
[05:42] <Mirv> didrocks: indicators + qa packaging changes http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ido_13.10.0+13.10.20130814-0ubuntu1.diff http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_autopilot-qt_1.3+13.10.20130814-0ubuntu1.diff http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job
[05:44] <didrocks> Mirv: +1 for both
[05:49] <Mirv> didrocks: qtubuntu-android has received a lot of new dependencies from mir (libmirserver1) now that it builds mirserver and mirclient backends https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/platform_qtubuntu_new_deps/+merge/180036
[05:49] <Mirv> QA and Indicators published
[05:49] <didrocks> sweet!
[05:49] <didrocks> Mirv: re qtubuntu-android: the new gl* things are transient?
[05:49] <didrocks> Mirv: like, should we just run with "check with whole ppa"
[05:50] <didrocks> or you think they will be used everytime
[05:50] <didrocks> (the mir part seems long term)
[05:50] <Mirv> didrocks: it seems mirserver has stared depending on them
[05:50] <Mirv> so not temporary
[05:51] <Mirv> or not started, but qtubuntu started depending on mirserver
[05:51] <didrocks> Mirv: interesting, so we don't install those by default?
[05:51] <didrocks> Mirv: if they will be seeded on the CD, we can maybe live until we take a snapshot with check with whole ppa?
[05:51] <didrocks> (not the mir dependens, we need to add them)
[05:51] <didrocks> depends*
[05:53] <Mirv> didrocks: hmm weird that they wouldn't be already there via mir. so to be exact since it's been a bit mystery to me, are the 'default' talking about default desktop seed?
[05:54] <didrocks> Mirv: right
[05:54] <didrocks> Mirv: I would suggest, let's add Mir
[05:54] <didrocks> and then, run with "check with whole ppa"
[05:55] <didrocks> once in distro, we'll retake a snapshot
[05:55] <didrocks> and see how it goes
[05:55] <didrocks> sounds good?
[05:55] <Mirv> didrocks: sounds good, what about the boost lib?
[05:56] <didrocks> let's see what pulls it in
[05:56] <Mirv> libmirserver1
[05:57] <didrocks> Mirv: ok, and libmirserver1 isn't installed on the desktop by default, right?
[05:57] <didrocks> (as long as we don't have unity-system-compositor)
[05:57] <Mirv> didrocks: yep
[05:57] <didrocks> so let's add it I would say
[05:57] <Mirv> ok
[05:58] <didrocks> Mirv: I think what we can envision for the future is that we don't block on those additional packages and so on
[05:58] <didrocks> but it needs to turn the publication to manual
[05:59] <Mirv> didrocks: removed the opengl ones https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/platform_qtubuntu_new_deps/+merge/180036
[06:00] <didrocks> Mirv: approved
[06:00] <didrocks> Mirv: you can quiclky deploy it before this tick :)
[06:00] <Mirv> ok deploying and running with check-whole-ppa
[06:00] <didrocks> (2 minutes)
[06:00] <didrocks> Mirv: no need for rerun, the tick is coming :)
[06:00] <Mirv> ah right
[06:00] <didrocks> so after that, rerun with check-whole-ppa
[06:00] <didrocks>  but let's have one run first
[06:00] <Mirv> my clock says :00:41 already
[06:00] <didrocks> it's :02 in fact
[06:01] <didrocks> but shhh, don't tell anyone :p
[06:01] <Mirv> :)
[06:01] <didrocks> (and it's :53 in fact for raring)
[06:02] <Mirv> deployed, with 6,5s extra seconds left
[06:06] <didrocks> phew ;)
[06:53] <didrocks> Mirv: I relaunched with check with whole ppa now that all the rest is finished
[06:53] <Mirv> didrocks: hah, was just writing about that to you
[06:53] <Mirv> thanks
[06:53] <didrocks> ;)
[06:53] <didrocks> yw
[06:54] <Mirv> indicators prepare-ido failed because the merge request from the previous publishing wasn't ready yet
[06:54] <Mirv> now it's merged
[06:56] <didrocks> Mirv: great! you can relaunch the stack if you want all green, but not a biggie :)
[07:00] <Mirv> didrocks: yeah, that's the only reason as such, but maybe it's again worth it :)
[07:01] <Mirv> didrocks: ok now there'd be the platform packaging change http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_qtubuntu_0.52+13.10.20130814.1-0ubuntu1.diff
[07:02] <Mirv> mir emits xkbcommon keysyms, so that's why the libxkbcommon-dev dependency
[07:03] <didrocks> Mirv: do you know why we have this second dh_auto_configure ?
[07:04] <Mirv> didrocks: it probably does not hurt but let me check why it's being used in the first place
[07:04] <didrocks> Mirv: thanks :)
[07:05] <didrocks> Mirv: anyway, if it doesn't hurt +1 for publishing, just follow up on that to get it fixed if this is a typo :)
[07:06] <Mirv> ok, I'll check it up and mark to the sheet
[07:06] <sil2100> Morning!
[07:09] <Mirv> sil2100: morning! daily stack all handled now (soon all green), feel free to start your day with other stuff :)
[07:10] <didrocks> Mirv: thanks!
[07:10] <didrocks> sil2100: good morning :)
[07:10] <seb128> good morning desktopers
[07:10] <didrocks> \o/
[07:10] <didrocks> salut seb128
[07:10] <seb128> hey Mirv sil2100 didrocks
[07:10] <Mirv> hey seb
[07:11] <sil2100> Mirv: awesooome ;)
[07:17] <didrocks> hey sil2100!
[07:18] <Mirv> didrocks: oh right, lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src_5.0.2 would be now ready (enough). there's an upstream bug report with the patch attached, and I linked it to the patch in bzr.
[07:18] <didrocks> Mirv: excellent, will do it in 5 minutes!
[07:18] <didrocks> (well, rebuilding as well, so will take time :p)
[07:35] <sil2100> didrocks: quick packaging question - if I'm doing a review of a package that has never ever been released to Ubuntu, and the changelog entry has like many entries stating that it has been released, should I remove those or leave them as they were?
[07:35] <didrocks> sil2100: no, don't worry about it
[07:36] <sil2100> Ok, thanks ;)
[07:45] <Mirv> ok, all green, just made triple sure the new qtubuntu-android works fine on device as well
[07:48]  * didrocks likes green :)
[07:49] <didrocks> thanks Mirv for the careful reviews :)
[07:49] <sil2100> Yay for green
[07:53] <sil2100> Mirv: ok then, I'm picking up the next release tick if you don't mind ;)
[07:53] <didrocks> sil2100: tick's stealer! :)
[07:54] <sil2100> Tricky ticky
[07:54] <Mirv> sil2100: sure
[07:54] <didrocks> :)
[08:15] <sil2100> didrocks: when adding a completely new project to the cu2d-config, do I need Francis to enable the CI and autolanding bits? Or does a redeploy do all the stuff automatically?
[08:16] <didrocks> sil2100: you need Francis to do the upstream merger part, yeah
[08:19] <didrocks> sil2100: should it be in platform? shouldn't we have a service stack?
[08:19] <didrocks> sil2100: like, will the people maintaining platform will be the same maintaining the services?
[08:23] <Mirv> FYI if anyone else is having slow saucy shutdown, I filed bug #1212142
[08:23] <ubot2`> Launchpad bug 1212142 in sysvinit (Ubuntu) "Slow shutdown on saucy with sendsigs waiting 10 seconds" [Undecided,New] https://launchpad.net/bugs/1212142
[08:23] <Mirv> I eventually became annoyed enough to look at it a bit, now happy that I found a "kill em all!" workaround :)
[08:25] <sil2100> didrocks: hm, we might do that now yes, since we could move the location-service to that new stack then too
[08:25] <sil2100> didrocks: for me platform seemed ok for now
[08:25] <sil2100> didrocks: but if you don't mind spawning a new stack, then I'm ok with that ;)
[08:26] <sil2100> didrocks: so, creating the service stack
[08:32] <sil2100> didrocks: I wonder if the D09add_ppa~phablet-team~ppa D09add_ppa~canonical-qt5-edgers~qt5-proper hooks are still needed
[08:34] <didrocks> tvoss_: do you have any idea who will consume that and be upstream for all services like that? ^
[08:35] <didrocks> sil2100: also, for adding to daily release, we are asked to check that there are AP tests again
[08:36] <tvoss_> didrocks, the services will be consumed indirectly by apps, upstream is "us"
[08:36] <tvoss_> didrocks, @AP tests: I think apps should check for that
[08:36] <didrocks> tvoss_: "us" is vague
[08:36] <didrocks> tvoss_: is it the same team than the platform api team?
[08:36] <didrocks> or another one?
[08:37] <tvoss_> didrocks, phonedations might be the team you are after
[08:37] <sil2100> didrocks: of course, for now we want CI and autolanding only - the rest is added in the spreadsheet as TODO
[08:37] <didrocks> tvoss_: ok, so platform stack sounds good then
[08:37] <didrocks> sil2100: ^
[08:37] <Mirv> didrocks: there'd be the Qt Creator common files split + upgrade to saucy needing review/sponsoring
[08:37] <didrocks> thanks tvoss_, as soon as we have apps consuming then, we need to have those running the same tests
[08:37] <Mirv> I updated the doc with the new project place I did for those
[08:37] <didrocks> Mirv: ah excellent! qtbase is still building
[08:37] <sil2100> didrocks: ok then, sticking with platform then - no change in the MR ;)
[08:37] <tvoss_> didrocks, ack
[08:38] <sil2100> tvoss_: but still, we'll need Francis to fetch our config code once he's up so that the upstream mergers are set-up
[08:38] <tvoss_> sil2100, ack
[08:39] <tvoss_> sil2100, anything you need from my side right now?
[08:40] <sil2100> tvoss_: I have all I need, thanks :) Will get back to you once Francis sets everything up
[08:40] <tvoss_> sil2100, thanks
[08:52] <sil2100> Mirv: I don't want to bother didrocks, so if you have a moment, could you review and approve https://code.launchpad.net/~sil2100/cupstream2distro-config/add_content-hub/+merge/180058 ? We just had a discussion and this seems to be the right place for the new component
[08:52] <sil2100> Eeek, typo!
[08:53] <sil2100> Mirv: wait, need to fix it
[08:54] <sil2100> Mirv: ok, fixed, now the MR is ready
[08:55] <didrocks> Mirv: can you prepare qtcreator-plugin-ubuntu for dailies (if it's not already?)
[08:55] <didrocks> I'll have a look afterwards
[08:55] <didrocks> I need to concentrate on system updates now
[08:57] <sil2100> didrocks: aaah! I noticed something really bad! The nux part of the unity-support-test change didn't get merged ;/
[08:57] <didrocks> sil2100: why wasn't it merged?
[08:58] <sil2100> didrocks: merge failed, *** No rule to make target `check-headless'.  Stop. make[2]: *** [check-headless] Error 2  <- huh
[08:58] <didrocks> can you please check with upstream
[08:59] <sil2100> Doing that, but still ;/ DAMN
[09:07] <didrocks> mpt: hey! on https://wiki.ubuntu.com/SoftwareUpdates#Phone, prompting section
[09:07] <didrocks> Whenever an update is downloaded and ready to install, or an update download has failed repeatedly, or “Download future updates automatically” is set to “Never” and an update is available for download:
[09:07] <didrocks> you just explained the label to show in the first case
[09:07] <didrocks> not if download repeatedly
[09:08] <Mirv> didrocks: added a couple last tweaks now, it should be ready for dailies
[09:08] <mpt> didrocks, good point, I'll fix that now
[09:09] <didrocks> thanks mpt
[09:09] <didrocks> Mirv: ok, is it urgent or can that wait a little bit (later today or next Monday?)
[09:09] <didrocks> I really try to get the system update straight first :)
[09:10] <mpt> didrocks, https://wiki.ubuntu.com/SoftwareUpdates?action=diff&rev2=127&rev1=126
[09:10] <Mirv> didrocks: can wait. today would be preferred to next Monday, though, the P/Q/R users are already using this update.
[09:12] <didrocks> Mirv: if I can't do it today, mind asking Ken?
[09:12] <Mirv> but if it gets complicated (the common packages need to get to archives and then qtcreator sponsoring) then we'll move it to Monday
[09:12] <Mirv> didrocks: sure, that's fine
[09:12] <didrocks> mpt: perfect, thanks!
[09:12] <didrocks> Mirv: thanks
[09:13] <Mirv> sil2100: approved
[09:14] <sil2100> Mirv: thanks!
[09:27] <sil2100> didrocks: did we drop the rule that projects in a stack should be ordered alphabetically?
[09:27] <didrocks> sil2100: no, we didn't
[09:27] <sil2100> didrocks: the platform stack is awefully ordered then - I'll fix that in some merge
[09:30] <didrocks> sil2100: thanks
[09:47] <sil2100> didrocks, Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/cleanup_and_add_unity-mir/+merge/180077 <- the description states some overview of why to platform, but it's an open discussion as it's not really a 100% fit
[10:17] <didrocks> mpt: when pressing "Install & Restart", should we have a countdown to cancel?
[10:17] <didrocks> like 5s
[11:12] <ogra_> could someone fix cups ? it breaks alll images
[11:12] <ogra_> The following packages have unmet dependencies:
[11:12] <ogra_>  cups-filters : Conflicts: ghostscript-cups
[11:12] <ogra_> E: Unable to correct problems, you have held broken packages.
[11:12] <ogra_> (all except touch :) )
[11:13] <seb128> tkamppeter, ^
[11:14] <seb128> ogra_, how did it go out of proposed if it breaks stuff?
[11:14] <ogra_> seb128, i have no idea, i just get spammed with image build errors  the whole morning :)
[11:14] <ogra_> so i thought i should mention it ...
[11:15] <seb128> ogra_, yeah, thanks
[11:15] <seb128> seems an issue with https://launchpad.net/ubuntu/saucy/+source/gutenprint/5.2.9-1ubuntu2
[11:15] <ogra_> yeah
[11:19] <tkamppeter> seb128: I have moved Ghostscript's CUPS filters from ghostscript-cups to cups-filters, making ghostscript-cups go away. According to didrocks I have added Conflicts/Provides/Replaces: ghostscript-cups to cups-filters and when I tested with "dpkg -i *.deb" ghostscript-cups got uninstalled, why does this not work with the images. What keeps ghostscript-cups on the system.
[11:20] <tkamppeter> seb128, didrocks, I have even updated several printer driver packages satisfying their dependencies with cups-filters.
[11:21] <seb128> tkamppeter, hum, I'm not sure either
[11:21] <seb128> ogra_, do you know what package the builder tries to install? installing ubuntu-desktop in a pbuilder works
[11:22] <tkamppeter> seb128, Gutenprint (the version you mention) is also updated to not require ghostscript-cups and accept cups-filters 1.0.36 instead.
[11:24] <ogra_> here is one of the breaking build logs http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/ubuntu/20130814/livecd-20130814-i386.out
[11:25] <seb128> ogra_, not very helpful :/
[11:26] <ogra_> yeah
[11:26] <seb128> apt-get install printer-driver-splix printer-driver-hpcups printer-driver-gutenprint lsb-printing ghostscript foomatic-db-compressed-ppds cups-filters cups-daemon cups ubuntu-desktop
[11:26] <ogra_> seb128, did you install the metapackage or the task ?
[11:26] <seb128> that works in a pbuilder
[11:26] <ogra_> images use tasks
[11:26] <seb128> is that with ^?
[11:26] <ogra_> yeah
[11:26] <seb128> ubuntu-desktop^?
[11:26] <ogra_> for ubuntu-desktop
[11:26] <ogra_> righgt
[11:26] <seb128> ok, that reproduces
[11:28] <tkamppeter> seb128, only package which I know depends on ghostscript-cups is lsb-printing, but for that I have reported bug 1212012.
[11:28] <ubot2`> Launchpad bug 1212012 in lsb (Ubuntu) "ghostscript-cups got removed and the content moved to cups-filters 1.0.36, let lsb-printing depend on cups-filters (>= 1.0.36) | ghostscript-cups" [High,New] https://launchpad.net/bugs/1212012
[11:29] <tkamppeter> seb128, ogra_: I have ubuntu-desktop installed and it causes no problem.
[11:30] <ogra_> tkamppeter, you need to install the task, not the meta packge ... thats what happens during image build
[11:30] <seb128> ogra_, do you know how tasks are defined?
[11:30] <ogra_> (task dependency resolution is slightly different from metapackage resolution)
[11:30] <ogra_> seb128, by germinate via the sseeds
[11:35] <tkamppeter> seb128, ogra_: How does one install a task, where is it defined (which package), and how does one report a bug against it?
[11:35] <seb128> tkamppeter, sudo apt-get install ubuntu-desktop^
[11:36] <tkamppeter> seb128, this I did and it does not cause any problem. ubuntu-desktop was all the time installed even.
[11:37] <seb128> tkamppeter, I get the error in a pbuilder, not sure why though
[11:38] <seb128> ogra_, it looks like a cjwatson sort of issue, neither the seed nor the seeded packages depends on it
[11:38] <ogra_> well, something pull sit in
[11:39] <seb128> ogra_, I don't see anything in the seeds and rdepends is fine
[11:39] <seb128> ogra_, it seems like the tasks didn't get updated ... is that happening automatically on every image build or...?
[11:40] <ogra_> iirc the issue with meta vs task is that the "or deps i.e. | " are resolved in the opposite order
[11:40] <ogra_> it should happen on every publisher run
[11:41] <ogra_> (meta takes the first option, task takes the last one in such a case)
[11:41] <seb128> hum, maybe that's the issue then
[11:42] <seb128> but I don't understand that enough to have a clue what to change/what source is the problem then
[11:45] <tkamppeter> seb128, ogra_: I consider that as a bug. First it is more intuitive if the first item gets priority, second, different programs should not use different priority orders on the same data.
[11:45] <didrocks> \o/ running for making an API clear in one's mind -> success!
[11:45] <didrocks> getting down from 20 calls to 6 ;)
[11:45] <seb128> didrocks, yeah, exercice is good to get ideas in shape ;-)
[11:46] <tkamppeter> seb128, ogra_ I vote for the first item being prioritized, not only more intuitive but also packages probably think that way as package installation/update after install behaves that way.
[11:47] <tkamppeter> seb128, ogra_, and if this leads to failure, the program should try whether it succeeds using the second item.
[11:47] <ogra_> tkamppeter, heh, thats not a voting matter i fear ... its a technological difference in both installation variant
[11:48] <ogra_> *variants
[11:48] <ogra_> iirc cjwatson knows about it, probably talk to him about a work around
[11:48] <seb128> tkamppeter, the CD building stuff is that way for years, I don't think either of us know enough about the problem space to redesign things, we don't have resources for that sort of work anyway atm
[11:48] <seb128> it's probably the way it is for good reasons
[11:49]  * ogra_ thinks its a bug ... but one thats not easy to fix
[12:33] <sil2100> fginther: hello!
[12:33] <sil2100> Good morning!
[12:34] <fginther> sil2100, good morning indeed!
[12:34] <sil2100> fginther: I have some business for you, sadly ;)
[12:35] <fginther> sil2100, if it's your business, then it's good business :-)
[12:36] <sil2100> fginther: ok, so maybe first thing first ;p I need to rename the LP project for lp:hollywood to lp:mediascanner
[12:36] <sil2100> fginther: I would need you to switch the merger/CI bits to that when that happens
[12:38] <fginther> sil2100, no problem, just ping me and I'll do an MP
[12:47] <sil2100> didrocks: sorry to disturb you, but you think the https://code.launchpad.net/~sil2100/cupstream2distro-config/cleanup_and_add_unity-mir/+merge/180077 is ok? Since if on first glance unity-mir fits to platform stack, then cool ;)
[12:47] <sil2100> (no one else is around to approve :<)
[12:48] <didrocks> sil2100: I saw a MP with unity-mir in the unity8 stack
[12:48] <didrocks> can you check?
[12:49] <sil2100> Checking
[12:51] <sil2100> didrocks: right, Sergio added that - it's hard to say which place is a better fit
[12:51] <sil2100> didrocks: even if we decide on unity8, I'll change my MR to at least fix the ordering in the platform stack
[12:52] <didrocks> sil2100: depends who is upstream and if the ABI is stable
[12:53] <sil2100> didrocks: I know the platform guys had some commits, but true, the unity8 guys have the most input there... so I guess unity8 it is then
[12:54] <sil2100> Although to me it fits better in platform, as it's more low-level
[12:55] <sil2100> didrocks: I'm approving Sergio's branch and changing mine to simply a cleanup one
[12:55] <didrocks> ok
[12:56] <didrocks> sil2100: we need to ensure unity8 is depending on platform then
[13:19] <sil2100> kenvandine: morning!
[13:19] <sil2100> kenvandine: are you ready for some MR reviews ;) ?
[13:19] <kenvandine> sil2100, good morning
[13:19] <kenvandine> sure
[13:21] <sil2100> kenvandine: https://code.launchpad.net/~sil2100/cupstream2distro-config/cleanup_and_add_unity-mir/+merge/180077 <- this one, the name is misleading - it only sorts the platform stack here
[13:22] <sil2100> kenvandine: and this one to unblock unity8 stack https://code.launchpad.net/~sil2100/cupstream2distro-config/add_extra_libupstart1/+merge/180131
[13:22] <sil2100> kenvandine: thanks!
[13:23] <robru> sil2100, kenvandine:  good morning!
[13:24] <sil2100> robru: morning! Woha, that's EARLY
[13:24] <robru> sil2100, yes, i am still quite jetlagged from GUADEC :-/
[13:25] <robru> sil2100, kenvandine: do either of you know what's happening in jenkins? I saw a couple yellows due to packaging changes; I reviewed them and published them, but the red ones are baffling to me. one looks like the test environment itself is broken.
[13:26] <sil2100> robru: you mean, the current state of the stacks?
[13:26] <sil2100> robru: one red is because of this: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_extra_libupstart1/+merge/180131
[13:26] <sil2100> robru: HUD is yellow and let's keep it this way for now, since the diff had an invalid changelog (which I fixed in a MR), but still need unity-lens-apps checking
[13:27] <robru> sil2100, oh, I thought I saw your fix landed in trunk?
[13:27] <sil2100> robru: SDK is red because... well, flacky test, but not re-running it now since the next release will start soon
[13:28] <robru> sil2100, bad news, I already published hud. I'm a bit confused -- I thought I saw your changelog fix had landed, so it was ok to publish? or did I just make a huge mistake?
[13:28] <kenvandine> sil2100, approved
[13:28] <sil2100> robru: ouuuch
[13:29] <sil2100> robru: so, what happened is:
[13:29] <sil2100> robru: when it's in manual publishing, you would have to re-run the whole stack to get this change in - did you just publish or run the whole stack?
[13:29] <robru> just publish
[13:30] <sil2100> robru: besides, remember that we should always consult people with upload rights before we publish things with packaging changes
[13:30] <sil2100> robru: so either kenvandine or didrocks should give it a big ACK
[13:30] <sil2100> didrocks: ^
[13:30] <sil2100> didrocks: I hope it didn't break anything now?
[13:31] <sil2100> robru: also, remember to consult with the currently working vanguard of the release process as per the schedule ;) Since this way we won't conflict
[13:32] <sil2100> I'm usually taking care of this release as it's in my main work hours
[13:32] <robru> sil2100, ok
[13:32] <robru> sil2100, sorry. i don't understand the process very well yet
[13:33] <sil2100> didrocks: so, the thing is, robru published a libcolumbus version that had a bad looking changelog entry - I fixed that in a merge, but it got then published manually, which causes jenkins to not being able to commit the 'releasing' changelog modification to trunk...
[13:33] <robru> sil2100, oh, does it make a merge conflict on the changelog? ahhhh
[13:34] <sil2100> robru: yes! Sadly ;) https://code.launchpad.net/~ps-jenkins/libcolumbus/latestsnapshot-1.0.0+13.10.20130814-0ubuntu1/+merge/180127
[13:34] <sil2100> fginther: hi! lp:hollywood got renamed to lp:mediascanner \o/
[13:34] <robru> sil2100, how can I fix this? can I make a separate branch with a better changelog or does somebody need to fuss around inside jenkins to fix it?
[13:35] <sil2100> fginther: can you also switch it in the configs when you have a moment?
[13:35] <fginther> sil2100, no problemo
[13:35] <sil2100> robru: I think we'll need some help from didrocks on how to proceed here, since now the version with the no-good changelog went into distro
[13:36] <sil2100> robru: so we need to wait, since our possible options are:
[13:36] <sil2100> 1) drop the published version from distro, getting the right 'good-looking' changelog into trunk and re-publishing
[13:36] <sil2100> 2) leave the published version in distro with the not-so-good changelog and revert my fix for trunk, therefore unblocking jenkins merger
[13:37] <sil2100> robru: which still leaves some questions, such as what to do then with the rev number... ;/
[13:37] <sil2100> fginther: thank you!
[13:38] <robru> sil2100, wow, I really cocked things up. maybe I should just go back to bed :-/
[13:41]  * didrocks in a meeting, soon back :p
[13:41] <cyphermox> oh boy
[13:44] <tkamppeter> seb128, ogra_ psivaa, see bug 1212239
[13:44] <ubot2`> Launchpad bug 1212239 in cups-filters (Ubuntu) "cups-filters is reported to have unmet dependencies with the latest saucy server installations" [Undecided,New] https://launchpad.net/bugs/1212239
[13:44] <didrocks> sil2100: please write down SDK flacky tests
[13:45] <didrocks> sil2100: dropping a version from distro is hard
[13:45] <cyphermox> if nobody has done it yet, I'll add libupstart1 to the packages for unity8 stack, since it seems to be a depends on unity8-private
[13:45] <cyphermox> didrocks: there shouldn't be a need to drop anything, really
[13:46] <cyphermox> the upload looks sane, we just need to bump the version
[13:46] <didrocks> sil2100: so better to "fix" trunk with the right changelog
[13:46] <didrocks> cyphermox: drop?
[13:46] <didrocks> cyphermox: it's a check for new deps that aren't on the CD
[13:46] <didrocks> it's harder now that there is touch
[13:46] <didrocks> but when I'll have time, I'll try to make it easier
[13:46] <rickspencer3> didrocks, so ... thanks for making me try to think of a word for "six times per day"
[13:46] <rickspencer3> maybe there is a French one?
[13:46] <sil2100> didrocks: will do
[13:47] <sil2100> cyphermox: did that
[13:47] <sil2100> cyphermox: it's already approved by kenvandine I think
[13:47] <sil2100> cyphermox: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_extra_libupstart1/+merge/180131 <- merged
[13:47] <sil2100> I'll redeploy the stack
[13:47] <didrocks> rickspencer3: I have one which corresponds to 12 but I doubt we want to use it :p
[13:48] <rickspencer3> seisfoisparjour?
[13:48] <rickspencer3> chaqueqautheur?
[13:49] <sil2100> didrocks: as for fixing the changelog... won't there be any problems with the rev number in the merged in (by jenkins) release changelog?
[13:49] <rickspencer3> maybe German can help here?
[13:49] <sil2100> didrocks: once I revert my fix
[13:49] <sil2100> didrocks: since there will be one additional commit ;)
[13:49] <didrocks> sil2100: it's only used for collecting the changelog, so if it's not more than what was released, it's fine (you put the changelog generated by dailies)
[13:49] <didrocks> rickspencer3: http://fr.wiktionary.org/wiki/chi%C3%A9e is 12 ;)
[13:51] <rickspencer3> uh
[13:51] <didrocks> (don't use it next time your are in France ;))
[13:51] <rickspencer3> didrocks, I don't think that will work, no
[13:51] <didrocks> told you ;)
[13:51] <cyphermox> haha
[13:51] <cyphermox> quad-hourly?
[13:52] <sil2100> didrocks: ok, so I'll remove my changelog entry (leaving the released empty changelog), commit the jenkins release changelog change and reject jenkins's original merge (since I'll merge it in myself
[13:52] <sil2100> )
[13:53] <didrocks> sil2100: sounds good to me
[13:59] <robru> rickspencer3, quaternourly is the only thing I can come up with that sounds reasonably sane in english.
[13:59] <rickspencer3> robru, wfm
[13:59] <sil2100> didrocks: https://code.launchpad.net/~sil2100/libcolumbus/fix_madness/+merge/180144 <- does this make sense?
[13:59] <rickspencer3> alternatively, didrocks can make it every hour so we can just say "hourly"
[13:59] <rickspencer3> :)
[14:00] <robru> nooooooooooo
[14:00] <didrocks> rickspencer3: we need to have everyone looking at that results every hours as well ;) and really fast builders!
[14:00] <didrocks> (and really fast tests: unity 7 ones are taking 2h)
[14:00] <didrocks> sil2100: you can fix the changelog with the right infos
[14:00] <didrocks> sil2100: if you prefer
[14:01] <robru> rickspencer3, my vote would be to run them every 6 hours. Then we can call it "sexa-hourly"!
[14:01] <didrocks> ahah
[14:01] <didrocks> rickspencer3: then, you will ask for minutely! I know you! ;)
[14:03] <robru> "octourly" has a nice ring to it if we want to run just 3 times per day.
[14:03] <rickspencer3> didrocks, I don't know "minutely" doesn't role off the tongue
[14:03] <rickspencer3> I think rather, we do it "continuously" ;)
[14:05] <didrocks> rickspencer3: can't on every commit with the current distro layout though (and current non ABI stability), but if we fix both, that's something which will be possible
[14:05] <rickspencer3> :)
[14:10] <didrocks> sil2100: did you see my answer?
[14:15] <sil2100> Ok
[14:16] <sil2100> didrocks: by the right infos you mean the right commit rev?
[14:16] <didrocks> sil2100: no, I meant a meaning changelog
[14:16] <sil2100> Ah, ok ;)
[14:17] <didrocks> if there is a diff with distro though, it will get rereleased
[14:17] <didrocks> which is not a biggie IMHO
[14:17] <didrocks> (at least apt-get changelog will have a meaningful changelog)
[14:17] <sil2100> didrocks: what about the 'Automatic snapshot from revision 452' ? Should I also bump it to 453 or leave as it was released?
[14:18] <didrocks> sil2100: it's just telling to "collect commits message which have no debian/changelog change in the diff from rev <x>+1"
[14:18] <didrocks> sil2100: so based on that, make your call :)
[14:18] <sil2100> didrocks: ok, fixed the changelog to have the meaningful one ;)
[14:19] <didrocks> sil2100: approved (revert jussi approval which was on the previous commit)
[14:19] <didrocks> sil2100: on unity-mir
[14:19] <didrocks> did you see what I told?
[14:19] <didrocks> is the unity-mir ABI stable?
[14:20] <didrocks> does it linked against the server or client Mir API?
[14:20] <didrocks> that will help in setting it up
[14:20] <didrocks> if it links against the server one
[14:20] <didrocks> you need something similar to unity-system-compositor
[14:20] <didrocks> with force_rebuild and the condition
[14:20] <sil2100> Let me poke greyback about that
[14:20] <didrocks> + the stack needs to dep on the Mir one
[14:20] <didrocks> thanks
[14:21] <sil2100> greyback: is unity-mir API-stable? :)
[14:21] <greyback> sil2100: it links against both server & client. So not stable
[14:21] <fginther> sil2100, which stack for mediascanner?
[14:22] <mpt> didrocks, why would we have a countdown?
[14:22] <mpt> (And that isn't really a desktop question:-)
[14:22] <fginther> sil2100, media.cfg?
[14:22] <didrocks> mpt: we can move to #ubuntu-touch if you prefer :)
[14:23] <didrocks> mpt: basically if a user spaw the ui and misclick
[14:23] <didrocks> mpt: he didn't want to apply the update
[14:23] <didrocks> you can have a 5s grace period
[14:23] <didrocks> before the phone reboot
[14:24] <sil2100> fginther: hm, we didn't add it to the stacks yet, let me think for a moment
[14:24] <mpt> didrocks, there's nothing nearby you might have been aiming for instead
[14:24] <didrocks> mpt: if you click "show" on the unity8 ui, you have system-settings with the button available
[14:25] <mpt> yep
[14:25] <didrocks> mpt: just telling you about it. I saw that google is doing that for important updates that will destroy your state
[14:26] <mpt> didrocks, in most cases, destroyed state would be a bug in the app ... But in any case, this whole screen *is* the confirmation step. You get here after expressing initial interest in installing the update.
[14:26] <didrocks> mpt: ok, fine by me :)
[14:32] <sil2100> fginther: I think media might make sense
[14:32] <fginther> sil2100, ack
[14:36] <sil2100> fginther: thanks again!
[14:37] <didrocks> mpt: we don't have the number of downloads, there is just "one" download
[14:37] <didrocks> mpt: as long as we don't do apps updates, just system ones
[14:37] <mpt> didrocks, yep, so for now it'll always be 1. :-)
[14:37] <didrocks> ok :)
[14:37] <mpt> didrocks, apparently non-numeric badges are verboten.
[14:38] <didrocks> mpt: thanks for refreshing my poor german :)
[14:38] <didrocks> (was still in my scope of knowledge, phew!)
[14:38] <seb128> mpt, are click packages/apps updates going to be in system settings as well?
[14:39] <mpt> seb128, not decided yet
[14:40] <seb128> mpt, are you the one looking at those as well? do you know when that's going to be decided?
[14:40] <mpt> seb128, yes I am
[14:44] <dholbach> hey mpt, hey seb128
[14:44] <seb128> dholbach, hey
[14:44] <dholbach> how are you guys doing?
[14:45] <dholbach> mpt, so regarding the app updates thing? what's your gut feeling about it? will it rather live in the system settings or when/how will this be decided?
[14:46] <mpt> dholbach, same as usual. I'll sketch as many possibilities as I can think of and list pros and cons for each.
[14:47] <dholbach> mpt, ok - I'm just asking because the time might get a bit tight for ralsina's team to implement this :/
[14:48] <mpt> dholbach, really? I had no idea it was for version 1.
[14:48] <dholbach> mpt, well it's going to be important to update apps
[14:49] <dholbach> the security team have a quite a bit of interest in doing this :)
[14:53] <ralsina> mpt: we have been saying "october" which means not 1.0 but right after
[14:53] <ralsina> mpt: OTOH security team is really interested in it, like dholbach said
[15:04] <sil2100> fginther: how's the setup going? unity-mir, content-hub and mediascanner now CI'd and auto-merger'ed? ;)
[15:05] <fginther> sil2100, yes, the new jobs are deployed
[15:05] <fginther> sil2100, I'm testing with mediascanner
[15:07] <sil2100> Excellence
[15:11] <sil2100> fginther: I will ask for changing the accessability of mediascanner to public in a moment
[15:12] <fginther> sil2100, it already is public
[15:12] <sil2100> fginther: sadly, the branch is still not...
[15:12] <sil2100> fginther: https://code.launchpad.net/~hollywood-team/mediascanner/trunk
[15:12] <fginther> sil2100, wtf
[15:13] <sil2100> Maybe because of the hollywood-team?
[15:13] <fginther> sil2100, yeah, thanks for chasing that
[15:25] <sil2100> fginther: trunk is now public \o/
[15:26] <fginther> sil2100, \o/
[16:02] <mhr3> larsu, ping?
[16:02] <mhr3> how was travelling back?
[16:04] <seb128> mhr3, he's on holidays for a week
[16:04] <seb128> mhr3, can we help you?
[16:04] <seb128> mhr3, he made it back safely to Berlin
[16:05] <mhr3> seb128, aaah, right, i remember him mentioning that
[16:05] <seb128> mhr3, how, how are you btw? ;-)
[16:05] <seb128> how->hey
[16:05] <mhr3> seb128, i'm good, thx, the conf was nice, back at *my* university :)
[16:05] <mhr3> seb128, what about you?
[16:06] <seb128> I'm good thanks
[16:06] <seb128> I'm in Berlin for a week
[16:06] <seb128> hangout out with the cool guys ;-)
[16:07] <mhr3> yea, too many people in berlin
[16:07] <mhr3> don't make me want to move there
[16:07] <seb128> haha
[16:07] <seb128> shame you are not here!
[16:07] <seb128> we are going for beers with dholbach larsu greyback desrt etc tonight
[16:08] <mhr3> are you trying to make me envy you?
[16:08] <dholbach> mhr3, what? you're not in Berlin? :)
[16:08] <greyback> mhr3: beeer!
[16:08] <mhr3> cause you're succeeding :)
[16:08]  * larsu might go for less beer tonight. Was a bit too much last night
[16:08] <larsu> mhr3: hi!
[16:08] <seb128> mhr3, ;-)
[16:08] <seb128> larsu, add some °C and we can go for ice cream
[16:08] <mhr3> of course, seb128 mentions beer, now everyone wakes up :D
[16:09] <larsu> seb128: I already went for ice cream ;)
[16:09] <seb128> lol
[16:09] <larsu> seb128: which doesn't mean I can't have another one....
[16:09] <seb128> it was nice out there at lunch time, I would have done with an icre cream as well
[16:09] <larsu> mhr3: my client notifies me when someone mentions 'beer', not 'larsu'
[16:10] <seb128> mhr3, so ... when do you move to Berlin? ;-)
[16:10] <mhr3> larsu, i knew it!
[16:10] <mhr3> seb128, meh, too much beer there, not my thing
[16:10] <larsu> :)
[16:11] <larsu> mhr3: we have club mate, too
[16:11] <mhr3> larsu, what about ciders?
[16:12] <larsu> mhr3: we're not exactly known for those :) (but you can get them)
[16:12] <mhr3> hmm, maybe i'll reconsider at some point then :)
[16:12] <larsu> mhr3: are you back in London?
[16:12] <mhr3> not yet, flying there over the weekend
[16:13] <larsu> if not, you should come by this week... everyone's here this week
[16:14] <mhr3> i see we all miss uds :)
[16:14] <seb128> yep...
[16:14] <larsu> :'(
[16:24] <mhr3> larsu, anyway, i just wanted to ask if your icon provider branch was merged yet
[16:24] <sil2100> kenvandine: could you take a look here? https://code.launchpad.net/~sil2100/mediascanner/packaging_review_second/+merge/180185
[16:25] <mhr3> perhaps drop me a link so i can subscribe
[16:25] <sil2100> didrocks: hm, till when you stick-around today? ;)
[16:25] <didrocks> sil2100: ~20 minutes
[16:25] <didrocks> sil2100: need anything to unblock the stacks?
[16:26] <sil2100> didrocks: since I was thinking about maybe finishing unity-mir and pre-NEWing it so that we can daily it? Or should we wait for some integration tests here too?
[16:26]  * didrocks sees some stacks in manual publishing
[16:26] <didrocks> sil2100: that won't be for me today I think ;)
[16:27] <sil2100> didrocks: ok ;) Then I look at the stacks, having mediascanner out of the way (just need someone to sponsor it later, but will find a patch pilot ;p)
[16:27] <larsu> mhr3: Wellark wanted to write tests for it (they won't approve without tests)
[16:27] <larsu> mhr3: https://code.launchpad.net/~larsu/ubuntu-ui-toolkit/add-unity-theme-icon-provider/+merge/179011
[16:28] <sil2100> didrocks: looks sane to me: http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_powerd_0.13+13.10.20130814-0ubuntu1.diff
[16:28] <didrocks> sil2100: +1 on powerd
[16:30] <robru> mhall119, ping
[16:30] <sil2100> didrocks: looking at the packaging parts, it seems ok - new deps are in main: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity8/job/cu2d-unity8-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity8_7.81.3+13.10.20130814.3-0ubuntu1.diff
[16:31] <didrocks> sil2100: agreed, +1
[16:32] <didrocks> sil2100: for the stacks in failures, think about editing the spreadsheet ;)
[16:32] <sil2100> didrocks: aye ;) HUD had some singular failure, but I'll note that down as well
[16:32] <didrocks> sil2100: yeah, please do, we shouldn't have to rerun if upstream have flacky tests
[16:32] <sil2100> kenvandine, cyphermox: publishing unity8 and platform if anything
[16:33] <cyphermox> cool
[16:33] <sil2100> cyphermox: agreed on the noise level ;)
[17:08] <didrocks> ok, time for a long week-end!
[17:08] <didrocks> good luck and enjoy everyone ;)
[17:35] <sil2100> Stack green! (not counting unity, uuuh)
[17:35] <sil2100> Time to finish, see you on Friday everyone!
[18:01] <rickspencer3> yikes
[18:01] <rickspencer3> no RB for rickspencer3 today :(
[18:05] <mhall119> robru: pong
[18:05] <robru> mhall119, oh hey. I wrote you an email. please respond ;-)
[18:07] <mhall119> ok
[18:09] <rickspencer3> jasoncwarner__, not sure if anyone else is seeing this:
[18:09] <rickspencer3> https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/1212378
[18:09] <ubot2`> Launchpad bug 1212378 in rhythmbox (Ubuntu) "RB crashes every time I try to play a song" [Undecided,New]
[18:10] <robru> rickspencer3, weird... i can play songs in rb just fine
[18:10] <rickspencer3> robru, I presume it's a weird upgrade problem
[18:10] <rickspencer3> I'll try it at home since I have the same music collection there
[18:10] <jasoncwarner> rickspencer3 not sure. I'll check it out, though I haven't personally experienced it on a few machines
[18:11] <jasoncwarner> rickspencer3 I think RB just not like your celine dion collection :/
[18:11] <robru> ol
[18:11] <robru> lol
[18:11] <rickspencer3> jasoncwarner, but, in my defense, it was all Taylor Swift
[18:11] <robru> rickspencer3, I have the same rb version as you. maybe the issue exists in the U1 plugin or something? I'm playing songs locally.
[18:11] <rickspencer3> which I assume RB loves as much as everyone
[18:12] <rickspencer3> robru, mplayer is working just fine, btw
[18:12] <jasoncwarner> DANGIT! I had a chance to use taylor swift and I didn't ... opportunity missed!
[18:12] <robru> jasoncwarner, yeah, but you're canadian now... it's your duty to hate on celine dion
[18:12] <rickspencer3> wow
[18:12] <rickspencer3> it's really easy
[18:12] <rickspencer3> double click a song, RB goes away
[18:13] <rickspencer3> at least mplayer works ;)
[18:14] <robru> rickspencer3, weird, I just got an apport dialog about rb, but the music kept playing! I'm not sure what it was exactly that crashed...
[18:15] <rickspencer3> robru, hop onboard http://vwkombi.com/photos/vanfest-2005/Images/4.jpg
[18:16] <robru> lol
[18:16] <robru> rickspencer3, what format are your files? mp3?
[18:16] <rickspencer3> robru, mostly, yeah
[18:17] <rickspencer3> because, you know, I use the Internet
[18:17] <rickspencer3> :)
[18:17] <robru> rickspencer3, darn, I was hoping maybe you had exclusively oggs and only oggs caused crashes, that would have explained it ;-)
[18:17] <rickspencer3> no easy answers
[18:17] <robru> (I mean, if you ripped all your songs from legitimately purchased CDs, it's entirely reasonable to suspect that you might have chosen to rip them into oggs)
[18:17]  * rickspencer3 tries unloading plugins
[18:17] <rickspencer3> robru, uh, right
[18:18] <rickspencer3> yes, all 100% legit, I'm not sure what you are implying
[18:18]  * rickspencer3 backpedals furiously
[18:18] <robru> lol
[18:18] <rickspencer3> robru, tbh, I am a pretty big jam band fan, and these bands distribute tons of free music via mp3 format
[18:19] <robru> cool
[18:19]  * rickspencer3 tries unloading all service
[18:21] <rickspencer3> still crashes
[18:22] <rickspencer3> robru, check the bug again, looks like it's gstreamer
[18:22] <rickspencer3> shocker, I know
[18:22] <rickspencer3> well, looks like RB is not playing nice with gstreamer
[18:24] <rickspencer3> robru, jasoncwarner I added the crash file to the bug report
[18:25] <jasoncwarner> thanks, rickspencer3
[18:26] <jasoncwarner> I just tried it on my machine and no problem.
[18:26] <rickspencer3> jasoncwarner, as you know ...
[18:26] <rickspencer3> any bug that interferes with Taylor Swift
[18:26] <jasoncwarner> installing new build in a VM to give it a go as well
[18:26] <rickspencer3> automatic Critical
[18:26] <rickspencer3> stop the line
[18:26] <jasoncwarner> rickspencer3 lol...totally understandable!
[18:30] <robru> rickspencer3, thanks a lot! I had a kernel oops while trying to reproduce your bug!
[18:30] <rickspencer3> robru, wow
[18:30] <robru> first one in about 10 years, too
[18:35] <rickspencer3> it seems like RB shouldn't really be able to trigger a kernel panic, tbh ;)
[18:35] <rickspencer3> don't know what you're doing there :)
[18:36] <robru> yeah, dunno. probably just did one too many dist-upgrades without rebooting
[18:37] <sarnold> KVM's been causing oopses lately.. were you testing in a VM?
[18:39] <mhall119> robru: about a month ago, right after saucy got a new kernel, I was getting panics every other day
[18:40] <mhall119> loads of fun
[18:40] <robru> yikes
[18:40] <robru> sarnold, nope, right on the host system
[19:27] <mdeslaur> mterry: what sets $XDG_CURRENT_DESKTOP?
[19:30] <mdeslaur> ah, gnome-session
[19:30] <mdeslaur> hrm, upstart needs to set it to now I guess
[19:31] <ogra_> lightdm should
[19:31] <ogra_> since it has the session selector
[19:31] <mdeslaur> ogra_: it doesn't seem to be...gnome-screensaver is starting without $XDG_CURRENT_DESKTOP being set
[19:31] <mdeslaur> ogra_: oh, you mean it should currently, or it should be the one setting it?
[19:32] <ogra_> it should currently and in the future
[19:32] <ogra_> you can select the session in the greeter ... so some part of lightdm needs to set that var
[19:33] <ogra_> since thats the place where you can change it
[19:33] <mdeslaur> ogra_: ok, I'll file a bug against lightdm, thanks
[19:33] <jbicha> ogra_: but what about other dm's?
[19:33] <ogra_> jbicha, i would expect them to set it too indeed
[19:33] <ogra_> $XDG_CURRENT_DESKTOP holds info about yoour current session
[19:33] <jbicha> I don't think other dm's are going to do something just for Ubuntu
[19:34] <jbicha> until 13.04 it was set by gnome-session
[19:34] <mterry> ogra_, it would need a special .desktop key for that, which is currently put inside the gnome-session .desktop files, instead of the lightdm .desktop files
[19:34] <ogra_> so wherever you can select the sessiion there it needs to be set
[19:34] <ogra_> ah
[19:34] <mterry> jbicha, I really think that var is useful for any distro.  it's the only way to generically implement the desktop ShowIn spec
[19:35] <mdeslaur> mterry: so currently processes that get started by init instead of gnome-session aren't getting it, which is causing a bunch of screen locking issues
[19:35] <jbicha> but why can't it be done by either upstart or gnome-session?
[19:35] <mdeslaur> mterry: what do you think I should file the bug against?
[19:36] <mterry> mdeslaur, it would make sense to move the .desktop key into lightdm's files, so I'd go with lightdm.
[19:36] <jbicha> I don't want things to be broken because someone uses Unity with gdm or kdm or whatever
[19:36] <mterry> mdeslaur, and until we use lightdm on the touch device, ubuntu-session-touch can set it
[19:37] <mterry> jbicha, how is upstart going to know which key to use?
[19:38] <jbicha> hmm, well why aren't we using gnome-session any more?
[19:40] <mterry> jbicha, I guess we felt we didn't need it?  And/or because it would pull in all the g* stack on the shiny touch platform
[19:40] <jbicha> maybe gsettings org.gnome.desktop.session session-name
[19:40] <mterry> jbicha, mdeslaur: really, I think each DM should set the value themselves.  Doing it in gnome-session was just the easiest way for us as a distro
[19:41] <mterry> mdeslaur, maybe ubuntu-touch-session can set the var in its scripts
[19:41] <mterry> jbicha, a gsetting would be user-wide, eh?  but if they log in with a different DM...
[19:42] <jbicha> the dm should set that value
[19:43] <jbicha> I don't know if they do except for gdm and lightdm though
[19:43] <mdeslaur> mterry: ok, I've filed bug 1212408
[19:43] <ubot2`> Launchpad bug 1212408 in lightdm (Ubuntu) "lightdm needs to set $XDG_CURRENT_DESKTOP" [Undecided,New] https://launchpad.net/bugs/1212408
[19:43] <mterry> jbicha, sorry, I might have used DM where I meant DE.  I figure the DE should set the value.
[19:43] <mdeslaur> mterry: anyone in particular I should assign it to?
[19:43] <mterry> ideally
[19:44] <mterry> jbicha, no reason to prefer a gsetting key over an env var, especially for something intended for the widest possible spread of DEs
[19:44] <mterry> mdeslaur, either robert_ancell or me
[19:45] <mterry> mdeslaur, so....  robert_ancell  :)  Which may just reassign to me
[19:45] <mdeslaur> mterry: thanks :)
[19:45] <mterry> mdeslaur, is this just for touch?  or a generic problem?
[19:46] <mdeslaur> mterry: I just notice on the desktop, haven't looked at touch
[19:46] <mterry> mdeslaur, because maybe the better solution would be to just get ubuntu-session-touch to do it.  Robert and I can discuss
[19:46] <mterry> mdeslaur, desktop?  Are we not using gnome-session with unity7 anymore?
[19:46] <mdeslaur> mterry: init is starting a bunch of processes itself, including gnome-screensaver
[19:47] <mdeslaur> and the indicators
[19:47] <mterry> mdeslaur, ah...  so gnome-screensaver is now a sibling of gnome-session rather than a child?
[19:47] <mdeslaur> mterry: exactly
[19:49] <mterry> mdeslaur, yeah, looks like it has to be done by the DM (lightdm) then
[19:50] <jbicha> then it will have to be done by all dm's
[19:51] <mdeslaur> jbicha: there's no reason it can't be done in two places
[19:51] <mdeslaur> gnome-session can continue doing it
[19:51] <mterry> jbicha, I'm not sure of a better way.  The DE can't do it, because it's parallel to user-upstart.  system-upstart doesn't seem like the right place (too low, doesn't have info).  DM seems right
[21:58] <cyphermox> robru: I'll release platform-api changes
[22:07] <cyphermox> dah, everything just started on me
[23:21] <JohnX> I have a quick question about a package in the gonme3-team PPA, is this the right place to ask?
[23:22] <JohnX> It looks like something went wrong with the latest build of their build of webkitgtk 2.0.4 causing the libwebkitgtk .so file to be 600+ MB