[05:13] <pitti> Good morning
[05:18] <Mirv> morning pitti
[05:20] <didrocks> hey Mirv!
[05:20] <didrocks> Mirv: so, no more intel?
[05:21] <Mirv> didrocks: yep, disappeared
[05:21] <Mirv> already last evening actually, we just didn't noticed since we finished our meeting before the next cycle
[05:21] <Mirv> didrocks: so maybe taking ati back and deprovisioning intel machine from tests?
[05:22] <Mirv> since you're still here, I thought to wait
[05:22] <didrocks> Mirv: right, I was going to propose that
[05:23] <didrocks> "Empty_Port10"
[05:23] <didrocks> did you try to reboot still, even with that ^
[05:24] <didrocks> Mirv: ^
[05:25] <Mirv> didrocks: I did try, even that..
[05:25] <Mirv> no help
[05:25] <didrocks> ok, thanks :)
[05:25] <didrocks> let me reprovision ati
[05:25] <didrocks> and remove intel
[05:25] <didrocks> enabling mir at the same time
[05:26] <Mirv> ideally the right folks could have been on site last night / US day
[05:28] <didrocks> right, when were they pinged?
[05:28] <didrocks> do you know more from cyphermox_ as it happened at that time?
[05:29] <Mirv> didrocks: well I hailed this morning, cyphermox had hailed generally around 7.5h ago on qa channel, with no response (but it was quite late already of course)
[05:29] <Mirv> I don't know anything more
[05:29] <didrocks> well, as long as QA was pinged, that's enough
[05:30] <Mirv> yeah they've said that a message on their IRC channel is the best contact method
[05:31] <didrocks> right
[05:43] <didrocks> Mirv: reenable ati, removed intel from the matrix
[05:43] <didrocks> reenabled Mir stack as well
[05:44] <didrocks> let's wait for the run in 15 minutes?
[05:44] <Mirv> didrocks: ok, sounds good
[07:19] <xclaesse> when computer needs to be rebooted after installing updates there is only a "reboot" button... it really should have a "later" button IMO
[07:20] <xclaesse> and not a "later" like windows which means "I'll annoy you all the time", but later as in "ok thanks I'll take care of it when I want"
[07:24] <sil2100> Morning!
[07:26] <didrocks> hey sil2100
[07:28] <Mirv> hello sil2100
[07:53] <attente> seb128, hey
[07:53] <seb128> good morning desktopers
[07:53] <seb128> attente, hey, how are you?
[07:53] <attente> seb128, good, you?
[07:53] <seb128> attente, I just read the email about your mp to increase the timeout
[07:53] <seb128> I'm good thanks!
[07:53] <seb128> so the new issue is a timeout issue?
[07:53] <attente> it seems to be the case
[07:54] <seb128> great
[07:54] <attente> i ran the tests on porter
[07:54] <seb128> I see that CI is happy
[08:02] <Laney> hey
[08:11] <didrocks> sil2100: Mirv: ok, so I deprovisionned the ati machine and restarted the platform stack check
[08:12] <didrocks> sil2100: mirv: please handle all the stacks but mirslaves, I'm looking with tvoss_ on the u-s-c issue
[08:13] <Sweetshark> good morning seb128, good morning desktoppers!
[08:13] <sil2100> didrocks: what happened?
[08:13] <sil2100> btw. funny: ERROR Projectbranch doesn't specify the same source name than the packaging itself for source: ubuntu-ui-extras, branch: lp:ubuntu-ui-extras, series: saucy
[08:13] <sil2100> To me source and branch look the same
[08:13] <seb128> hey Sweetshark
[08:13]  * Sweetshark is fixing dependencies in the libreoffice build that should never have worked for the last 6 month at least ;)
[08:13] <seb128> hey sil2100
[08:13] <sil2100> Ah, I see now the problem, nevermind what I said
[08:14] <seb128> sil2100, is there any reason indicators are not published?
[08:14] <sil2100> didrocks: ok
[08:15] <seb128> Laney, good morning, how are you?
[08:15] <sil2100> Mirv was taking care of the morning stack, but I see he's still not back after the netsplit
[08:15] <sil2100> seb128: I'll look in a moment
[08:15] <seb128> sil2100, thanks
[08:16] <Laney> seb128: pretty good thanks, last night I was weirdly wiped out after being back at work so went to bed super early and am now refreshed :P
[08:16] <Laney> you?
[08:16] <seb128> great
[08:16] <seb128> I'm good thanks ;-)
[08:16] <Laney> like 9pm early
[08:16] <seb128> that's early indeed!
[08:16] <Laney> hopefully be more balanced today ;-)
[08:17] <sil2100> didrocks: https://code.launchpad.net/~sil2100/ubuntu-ui-extras/rename_source_name/+merge/181213 <- somehow missed this
[08:18] <didrocks> sil2100: can you get anyone else looking at that? I can't now :/
[08:18] <sil2100> didrocks: sure, Mirv is back up!
[08:18] <sil2100> Mirv: hi! Can you: https://code.launchpad.net/~sil2100/ubuntu-ui-extras/rename_source_name/+merge/181213 ?
[08:18] <seb128> sil2100, let me review that
[08:18] <sil2100> seb128: oh, and we need an ACK on the indicators stack:
[08:18] <sil2100> http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-power_12.10.6+13.10.20130821-0ubuntu1.diff
[08:18] <seb128> sil2100, +1 for the indicator-power changes
[08:19] <sil2100> Too bad no mentioning in the changelog about the dep-bumps ;/
[08:19] <Mirv> sil2100: ok. it seems my Freenode node went down
[08:19] <sil2100> Mirv: I publish indicators in the meantime, ok?
[08:19] <Mirv> sil2100: go ahead
[08:19] <seb128> sil2100, we didn't have qtdeclarative5-ubuntu-ui-extras-plugin in Ubuntu yet, right?
[08:19] <sil2100> seb128: no, not yet
[08:20] <Mirv> sil2100: needs fixing, change also the changelog
[08:20] <sil2100> Mirv: eek! Right
[08:20]  * sil2100 was too fast
[08:20] <sil2100> Mirv: pushing
[08:22] <sil2100> Mirv: pushed
[08:22] <Mirv> sil2100: maybe add upstream name and url to copyright as well?
[08:24] <seb128> sil2100, Mirv: can you please rename the binary qtdeclarative5-ubuntu-ui-extras0.1
[08:24] <sil2100> Not that important, but ok
[08:24] <seb128> the new naming scheme is to have the version number
[08:24] <seb128> not -plugin
[08:24] <seb128> so we can deal with abi transitions
[08:24] <sil2100> seb128: ah, hm, ok
[08:26] <sil2100> seb128: Mirv: done
[08:26] <seb128> sil2100, was that package available in any ppa before?
[08:27] <seb128> sil2100, if so you might want to make qtdeclarative5-ubuntu-ui-extras0.1 Replaces/Conflicts/Provides qtdeclarative5-ubuntu-ui-extras-plugin for easier upgrades
[08:27] <sil2100> hm, I don't think it was, the upstream guys are not around
[08:28] <seb128> ok, don't bother then, I don't seem to find it in any ppa either
[08:28] <seb128> sil2100, the depends on libnotify4 seems buggy
[08:29] <seb128> sil2100, it already got that lib through shlibs, it doesn't make sense to hardcode the lib and the soname as written depends
[08:30] <sil2100> seb128: I'll do a test build and check if it's added by shlibs, and remove it if yes
[08:32] <sil2100> seb128: done
[08:32] <seb128> sil2100, thanks
[08:33] <seb128> looks fine to me
[08:33] <seb128> Mirv, should I approve or do you have other comments?
[08:33] <seb128> sil2100, note that I added a review comment saying it would be nice to improve the descriptions to detail the reason why those can't be the in UI toolkit
[08:33] <seb128> sil2100, if the reasons are licenses or quality, users might want to know
[08:34] <sil2100> seb128: I'll let upstream know ;)
[08:34] <seb128> thanks
[08:34] <sil2100> Thanks for the comments!
[08:34] <seb128> sil2100, I'm doing a preNEW review while I'm at it
[08:34] <seb128> sil2100, README has
[08:35] <seb128> "Ubuntu exta components are a collection of components that does not have the necessary
[08:35] <seb128> level of quality for inclusion in the toolkit (https://launchpad.net/ubuntu-ui-toolkit):
[08:35] <seb128> - lack of documentation
[08:35] <seb128> - lack of automated tests
[08:35] <seb128> "
[08:35] <seb128> sil2100, maybe you can just copy those in the description?
[08:36] <Mirv> seb128: go ahead
[08:36] <seb128> sil2100, otherwise, preNEW seems fine
[08:37] <sil2100> seb128: already modified it a bit with upstream help
[08:37] <seb128> sil2100, excellent
[08:37] <seb128> sil2100, once you push that I can approve it
[08:38] <sil2100> seb128: pushed, take a look if it's better now :)
[08:38] <Mirv> seb128: there's qtconnectivity sponsored by Ken in the saucy queue, can you check that out? (it has the ordinary style QML plugin naming, he did mention the version number transitioning to be done later)
[08:38] <seb128> Mirv, ok
[08:39] <Mirv> those unofficial modules have a warning text in their descriptions, as upstream makes no guarantess until they are released
[08:39] <seb128> sil2100, approved, I can't change the mp though, please do it
[08:40] <sil2100> seb128: thanks!
[08:52] <seb128> Mirv, did somebody preNEW qtlocation?
[08:54] <Mirv> seb128: qtconnectivity, no, Ken just reviewed it with only core-dev hat on
[08:55] <seb128> Mirv, I'm a bit annoyed at landing it with the wrong name, what's the rational to not just rename those now? it's a 15 min job and it would be done/avoid a transition later on
[08:56] <Mirv> seb128: more like just timezone difference, Ken starts looking at stuff after I've finished, so I guess he decided to let it go
[08:56] <Mirv> I can do the change now if someone can upload it
[08:56] <seb128> I can upload
[08:56] <seb128> that would be good, thanks
[08:57] <seb128> Mirv, or don't bother, I'm just going to approve this one and Ken can fix for the new upload
[08:58] <seb128> Mirv, I'm not sure if he already has any rdepends on the name
[08:58] <seb128> Mirv, better to check with him when he comes online
[08:59] <Mirv> seb128: ok. no rdepends yet, but PPA users are using it.
[08:59] <seb128> Mirv, let's just check with him, we are going the C,R,P anyway so we can do that for the next upload, I'm accepting that one so we have things moving meanwhile
[09:00] <Mirv> ok, thanks. and true, C/R/P would have been needed anyway.
[09:00] <Mirv> I'll check with him
[09:01] <seb128> Mirv, bah, copyright needs fixing
[09:01] <seb128> examples/bluetooth/bttennis/tennisclient.h:** $QT_BEGIN_LICENSE:LGPL$
[09:01] <seb128> examples/bluetooth/bttennis/tennisserver.h:** $QT_BEGIN_LICENSE:LGPL$
[09:01] <seb128> examples/bluetooth/bttennis/tennisserver.cpp:** $QT_BEGIN_LICENSE:LGPL$
[09:01] <seb128> etc
[09:01] <seb128> but
[09:01] <seb128> Files: examples/* src/nfc/doc/snippets/* src/bluetooth/doc/snippets/*
[09:01] <seb128> License: BSD-3-clause
[09:02] <Mirv> seb128: aha, more exceptions :(
[09:03] <sil2100> Mirv: restarting SDK so I can publish settings ;)
[09:04] <seb128> Mirv, why is the GPL-3 text listed in debian/copyright?
[09:04] <seb128> Mirv, seems there is no GPL-3 sources in there
[09:05] <seb128> Mirv, out of those small comments, seems good
[09:05] <seb128> Mirv, I'm going to approve it, please fix those in the vcs for the next upload
[09:05] <Mirv> seb128: all the LGPL stuff is dual-licensed under LGPL and GPL
[09:05] <Mirv> seb128: yes, fixing already
[09:06] <seb128> Mirv, ok, when dual licensed you can pick the license that's you want to use, in this case LGPL, so I don't think you need the GPL3 text ... but it's a detail
[09:14] <seb128> Mirv, dholbach just pinged me about reviewing qtcreator-plugin-ubuntu in NEW ... that's ready to go in as far as your know?
[09:17] <Mirv> seb128: yes, I've been trying to get didier and ken to sponsor it but dholbach now jumped in. it's ready.
[09:18] <seb128> great
[09:18] <seb128> Mirv, next time just subscribe sponsors, or at least try to ping some extra people
[09:18] <Mirv> seb128: it was "soon" all that time, but yes I should've filed a bug and go beyond my team
[09:18] <seb128> Laney, do you know how what script/process checks /etc/upstart-xsessions and what "ubuntu" is supposed to match?
[09:19] <asac> seb128: help :)
[09:19] <seb128> asac, hey, what do you need? ;-)
[09:19] <asac> gnome-terminal is busted
[09:19] <seb128> oh, how busted?
[09:19] <seb128> it didn't change in a while
[09:19] <asac> whenever i click a url in my irc and use "open URL"
[09:19] <asac> right click
[09:19] <asac> it freezes for at least 50 seconds
[09:20] <asac> then it unfreezes and runs the firefox command
[09:20] <asac> the firefox command clearly does not block if i run it on cmdline
[09:20] <asac> so its a bit unproductive :)
[09:20] <seb128> I had some of those in the past
[09:20] <asac> 100% reproducible
[09:20] <seb128> advice: reboot
[09:20] <asac> hjavent restarted gnome-terminal
[09:20] <asac> you think i should try?
[09:20] <asac> or rather extract something?
[09:20] <seb128> I think you should reboot
[09:21] <seb128> I'm pretty sure it's something in the gvfs/dbus stack busted which leads to sync calls to timeout
[09:22] <didrocks> sil2100: Mirv: so, the intel machine is now back
[09:22] <didrocks> sil2100: Mirv: it has been moved to another CDU port, jibel found it
[09:22] <didrocks> (wiki updated)
[09:22] <didrocks> now
[09:22] <didrocks> I'm waiting for this run to finish
[09:22] <didrocks> then, I'll redeploy the intel machine
[09:22] <Laney> seb128: /etc/X11/Xsession.d/00upstart
[09:22] <didrocks> so we'll have:
[09:22] <didrocks> intel + nvidia
[09:23] <didrocks> we'll probably miss next tick
[09:23] <didrocks> so I advise just getting the current tick on shape
[09:23] <sil2100> Ok
[09:23] <sil2100> I see that there are many jobs queued up indeed...
[09:24] <Mirv> ok... I tried browsing the CDU:s as well, did not find. good to have the wiki updated.
[09:24] <seb128> Laney, hum k, I don't see the overall picture good enough there to figure out what's wrong
[09:25] <seb128> Laney, I'm trying to figure out why guest session are not upstart session
[09:25] <seb128> Laney, that leads to e.g https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1214504 (though that's a bug, unity should work without upstart)
[09:25] <ubot2`> Launchpad bug 1214504 in unity (Ubuntu) "unity-panel-service not running in non-upstart-sessions on Saucy (including guest session)" [High,New]
[09:25] <Laney> seb128: I don't know, ted has been converting things to start on jobs only
[09:26] <seb128> Laney, well, then the guest session should be an upstart session
[09:26] <Laney> yes
[09:26] <seb128> I guess /etc/lightdm/Xsession is somewhat different from /etc/X11/Xsession
[09:26] <Laney> what's that?
[09:26] <Laney> I don't have it here
[09:27] <seb128> oh, maybe a leftover then
[09:27] <seb128> and ignore that, if that was the issue it would impact normal session as well
[09:27] <seb128> I wonder if guest session are labelled differently from "ubuntu"
[09:28] <Laney> i'm not sure how they work, but seems likely
[09:28] <Laney> put some echo statements in there
[09:33] <seb128> Laney, the issue is that DESKTOP_SESSION is not set for guest sessions
[09:38] <Laney> seb128: ah OK, looks like maybe it only does that for normal user logins
[09:39] <seb128> right, I've too much to do to debug lightdm, I made the bug also affect it and I'm going to ping robert_ancell later when he's online
[09:59] <seb128> attente, the CI/merger seems happy, was that the case before?
[09:59] <seb128> attente, let's see when cyphermox_ gets online if he's fine with enabling the daily release then
[10:02] <didrocks> sil2100: around?
[10:04] <Mirv> didrocks: can you ack http://10.97.0.1:8080/view/cu2d/view/Head/view/MirSlave/job/cu2d-mirslave-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-system-compositor_0.0.1+13.10.20130821-0ubuntu1.diff ?
[10:04] <Mirv> adding of an apport hook
[10:05] <didrocks> Mirv: sounds legit +1!
[10:05] <didrocks> Mirv: so, once sdk finishes
[10:05] <didrocks> let's reprovision intel
[10:05] <didrocks> and rerun all the ones with failing tests with "foo"
[10:05] <didrocks> so that we can get a stable base from the previous run
[10:06] <didrocks> Mirv: I can handle it if you wish (the rerun)
[10:07] <attente> seb128, i think it should be good now
[10:07] <Mirv> didrocks: yes, please, I'm starting to be slightly worried about not eating anything :)
[10:07] <attente> it was failing before both in CI and porter-armhf, but now both seem ok
[10:07] <attente> i think cyphermox_ said he wanted to do some packaging cleanup
[10:08] <didrocks> Mirv: I'll do the rerun, you can go eating, then, can you handling the publishing when I'm eating? :)
[10:09] <Mirv> didrocks: sounds like a plan :)
[10:09] <didrocks> deal ;)
[10:09] <seb128> attente, he had https://code.launchpad.net/~mathieu-tl/indicator-keyboard/packaging-review/+merge/178621 up for review which I approved, let's see if that's enough
[10:17] <didrocks> Mirv: ok, intel is now back (so tests are running on intel and nvidia)
[10:17] <didrocks> Mirv: I've restarted with "foo" all stacks
[10:17] <didrocks> unity8 seems to FTBFS on one arch though
[10:20] <didrocks> Mirv: I've published platform at the same time (packaging change)
[10:20] <didrocks> need to hop for lunch as well
[10:22] <didrocks> Mirv: approved your branch as well
[10:32] <tjaalton> is it a known bug that suspending saucy with two accounts logged on takes quite a while, and the non-active user gets an auth popup about 'not able to suspend while other users logged on'
[10:35] <sil2100> didrocks: yes, missed the ping
[10:35]  * sil2100 in code
[10:36] <sil2100> Oh, see some things finished
[10:36] <sil2100> seb128: did you pre-NEW ubuntu-ui-extras? With updating the whitelist?
[10:37] <seb128> sil2100, I preNEW reviewed, didn't update the whitelist
[10:38] <seb128> tjaalton, not known no
[10:38] <tjaalton> seb128: ok, i'll fiile it
[10:38] <tjaalton> -i
[10:39] <sil2100> didrocks: hi! Could you update the whitelist so we can publish ubuntu-ui-extras when you have a moment? We'll publish SDK and settings then
[10:48] <Mirv> the same thoughts from me
[10:48] <Mirv> sil2100: so seb preNEWed it?
[10:48] <Mirv> ah, like there, it reads so
[10:48] <sil2100> ;)
[10:48] <Mirv> we could like get someone else to whitelist it, as practice
[10:49] <Mirv> seb128: could you perhaps update it? https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack
[10:49] <seb128> Mirv, sil2100: did you guys commit the changes?
[10:50] <sil2100> seb128: you mean from the review you made? Yes ;)
[10:50] <Mirv> seb128: I've understood the whitelisting means simply pulling the same version as is deployed already
[10:50] <seb128> Mirv, sil2100: done
[10:50] <sil2100> THank you!
[10:50] <sil2100> Mirv: I'll publish ;)
[10:50] <seb128> up to r671
[10:50] <Mirv> let's see!
[10:50] <seb128> yw
[10:50] <Mirv> sil2100: will you?
[10:50] <Mirv> (publish)
[10:51] <Mirv> now if also seb would be unavailable next week, we can point to this discussion and say "seb did it too, you can as well"
[10:52] <Mirv> success!
[10:52] <sil2100> \o/
[10:53] <Mirv> apps, settings too
[10:54] <didrocks> back
[10:54] <Mirv> sil2100: adding the media dep
[10:56] <Mirv> sil2100: https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/media_add_libqt5organizer5/+merge/181257
[10:59] <Mirv> unity8 (unity-mir) sounds like it would have been fixed in trunk, but pinging upstream since we just tried a build
[10:59] <didrocks> Mirv: I did rerun with "foo"
[11:00] <didrocks> Mirv: so, it's the 6am build still
[11:00] <didrocks> (if you didn't retry a build in between)
[11:00] <Mirv> didrocks: right. rerunning the unity-mir then
[11:03] <didrocks> Mirv: rerunning the tests for the service stack as well
[11:12] <sil2100> Mirv: approved, will you redeploy media or you want me to do it?
[11:13] <seb128> Mirv, qtconnectivity5-dev should Depends on qtbase5-dev
[11:13] <seb128> Mirv, since it's .pc has "Requires: Qt5Core"
[11:14] <seb128> Mirv, can you please fix in the vcs/for the next upload
[11:15] <seb128> Mirv, the nfc plugin lacks a qmltypes, but I guess that's an upstream issue? (would be nice to have since otherwise qtcreator doesn't know about the objects)
[11:16] <didrocks> Mirv: sil2100: ok, services released, do not forget to go to that view: http://10.97.0.1:8080/view/cu2d/view/Head/view/All/ to see services as long as the new view isn't created
[11:16]  * didrocks ack the packagng changes there
[11:17] <sil2100> \o/
[11:17] <didrocks> sil2100: so you deal with unity8 and media?
[11:18] <sil2100> didrocks: media is dealt with, needs a redeploy - will redeploy now since Mirv seems to be busy
[11:18] <sil2100> didrocks: and then move onto unity8
[11:19] <didrocks> ok, thanks sil2100
[11:22] <sil2100> Mirv: redeploying and re-running with foo
[11:22] <Mirv> seb128: thank you, committed and pushed, I'll contact Ken to sponsor. qmltypes missing is an upstream issues, yes.
[11:23] <Mirv> sil2100: thanks
[11:23] <Mirv> I was in telco
[11:23] <Mirv> sdk always around this time
[11:24] <sil2100> didrocks: btw. when a package in -proposed is on a dependency wait, does it block it from migrating further?
[11:25] <seb128> sil2100, things need to build to migrate, yes
[11:25] <seb128> sil2100, why?
[11:25] <seb128> sil2100, seems like a weird question :p
[11:25] <didrocks> sil2100: define dependency wait? (we don't build-dep wait)
[11:25] <didrocks> for dailies
[11:25] <sil2100> https://launchpad.net/ubuntu/+source/ubuntu-ui-extras <- like, you know
[11:25] <didrocks> but yeah, as seb128 told, everything needs to be in
[11:25] <seb128> sil2100, or do you ask for ppc? it migrates if the binary never existed for the arch
[11:25] <sil2100> seb128: yes, ppc
[11:26] <sil2100> Ok
[11:26] <sil2100> ;)
[11:26]  * sil2100 knows all now
[11:30] <sil2100> didrocks, seb128: 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.20130821-0ubuntu1.diff
[11:30] <didrocks> sil2100: +1
[11:30] <seb128> sil2100, +1
[11:31] <seb128> ok, going for lunch
[11:31] <sil2100> seb128: bon appetit
[11:31] <didrocks> so, we media is the latest and greatest?
[11:31] <sil2100> didrocks: it's running now, should pass once this finished
[11:31] <sil2100> *finishes
[11:31] <seb128> didrocks, can you need qtcreator-plugin-ubuntu once dholbach re-upload? there is a one liner to change and it's good to ack
[11:31] <didrocks> seb128: ok, will do
[11:31] <seb128> didrocks, so we can upload qtcreator once I'm back from lunch
[11:31] <seb128> didrocks, thanks
[11:38] <cyphermox_> seb128: attente: so yeah things seem to be passing so let's add indicator-keyboard to daily-release
[11:38] <cyphermox_> just need the bootstrap commit now
[11:47] <cyphermox> didrocks: https://code.launchpad.net/~mathieu-tl/indicator-keyboard/bootstrap/+merge/181270
[11:47] <didrocks> approved
[11:48] <didrocks> sil2100: ok, media was done for quite some time, I did the packaging ack
[11:49]  * didrocks can now switch context to system update
[11:51] <sil2100> \o/
[11:51] <sil2100> Ok
[11:51] <sil2100> Thanks!
[11:56] <cyphermox> didrocks: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/indicator-keyboard-daily/+merge/181275
[11:57] <didrocks> cyphermox: oh, before approving
[11:57] <didrocks> cyphermox: did someone preNEW it?
[11:57] <Mirv> seb128: I just found a note about talking to you on "Monday" (I believe 1.5 weeks ago) about upstreaming qtsystems change http://paste.ubuntu.com/5965634/
[11:57] <cyphermox> didrocks: no
[11:57] <didrocks> cyphermox: can you have slangasek preNEWing it? he told that he would give a hand
[11:57] <cyphermox> isn't this preNewing your whitelist changes?
[11:57] <cyphermox> alright
[11:57] <didrocks> cyphermox: also, we need the whitelist refreshed, but that's easy (and in the FAQ, even if we are not here)
[11:57] <cyphermox> right
[11:58] <didrocks> cyphermox: well, if an AA reject, the stack will be stuck
[11:58] <seb128> didrocks, cyphermox: I preNEW it
[11:58] <didrocks> so better doing the preNEWing before adding the component to the stack
[11:58] <didrocks> ah great :)
[11:58] <cyphermox> yeah
[11:58] <seb128> well I NEW reviewed it when jbicha manually uploaded
[11:58] <seb128> there were some issues, that got fixed in trunk then
[11:58] <didrocks> cyphermox: once merged, can you ping me so that I refresh the whitelist?
[11:58] <didrocks> seb128: thanks!
[11:58] <seb128> yw
[11:58] <Josh015> Hello, I'm new. I was directed here to ask a question about the new Friends API.
[11:58] <didrocks> seb128: it wasn't in the archive, hence my question
[11:59] <didrocks> (so you rejected it at the time, and didn't get any other upload)
[11:59] <Josh015> I wanted to ask someone about how I would go about adding Pocket support to the new Share feature?
[11:59] <seb128> didrocks, right, you couldn't know ;-)
[11:59] <seb128> didrocks, correct
[11:59] <seb128> didrocks, we said the next upload would be a daily one
[11:59] <cyphermox> didrocks: ack
[11:59] <didrocks> seb128: good strategy :)
[11:59] <seb128> Josh015, try asking kenvandine when he's around
[11:59] <seb128> should be there in the next hour or so
[11:59] <Josh015> Thanks.
[12:00] <cyphermox> ok, so seb128 you were fine with indicator-keyboard?
[12:00] <seb128> cyphermox, yes
[12:00] <cyphermox> alright
[12:01] <cyphermox> in the meantime let's rebuild what needs rebuilding for libcolumbus
[12:01] <asac> seb128: so now i tried running firefox URL ... that was snappy and then xdg-open URL ... and that one hung
[12:01] <asac> so its xdg-open
[12:02] <seb128> asac, right, as I said before, I'm pretty sure it's gvfs/dbus
[12:02] <asac> kk
[12:02] <seb128> asac, if you get a gdb bt you are going to see it's blocked in a sync dbus call
[12:02] <seb128> I had that 2-3 years over the last year
[12:02] <seb128> but I never figured out what was breaking dbus/gvfs
[12:02] <seb128> if you reboot it's going to be fixed
[12:03] <asac> seb128: what is xdg-open roughly doing?
[12:03] <asac> asking gnome-settings-daemon through dbus for the default ahndler?
[12:03] <seb128> asac, no, it's more dumb than that, it's basically as script doing
[12:03] <seb128> if GNOME then use gvfs-open
[12:03] <seb128> if XFCE then use ...
[12:03] <seb128> if KDE then use ...
[12:04] <asac> ok so we are GNOME? then same questionm about gvfs-open :)
[12:04] <seb128> we are GNOME yes
[12:04] <asac> ack i can confirm that tool hangs too
[12:04] <seb128> asac, and yes, gvfs-open does "open that url through gio" which does the "give it to the default handler for that URL type"
[12:06] <asac> seb128: ok and that queries which dbus service for getting that info?
[12:07] <seb128> asac, I'm not sure why that is using dbus ... can you install gvfs-dbg and "gdb -p $(pidof gvfs-open)" "t a a bt" on the hanging process?
[12:07] <seb128> asac, the stacktrace should tell us what methods it call
[12:09] <asac> http://paste.ubuntu.com/6010060/
[12:09] <asac> yeah
[12:10] <asac> its interesting... if i continue
[12:10] <asac> it seems to wake up and continue
[12:11] <seb128> asac, no, it timeouts
[12:11] <seb128> you said earlier, things are stucked for like 45 seconds
[12:11] <seb128> same there
[12:11] <cyphermox> didrocks: so the indicator-keyboard stuff is merged now
[12:11] <cyphermox> I'll start deploying
[12:12] <seb128> asac, in any case same problem I was saying, the app launcher app does get infos on the local fs and hit dbus to talk to gvfs daemon for that
[12:12] <didrocks> cyphermox: ok thanks! whitelist refreshed!
[12:13] <asac> seb128: is the gmounttracker in the same gvfsd process?
[12:13] <cyphermox> all done
[12:14] <cyphermox> didrocks: so next run we'll have indicator-keyboard in the queue if all goes well
[12:15] <seb128> asac, yes
[12:15] <seb128> asac, what are you trying to do exactly? fix gvfs?
[12:15] <asac> no clue :)
[12:15] <asac> guess stop :)
[12:15] <asac> thx
[12:15] <seb128> yw
[12:16] <seb128> asac, you can try to kill gvfsd-* and see if that fixes things for you without having to reboot
[12:17] <didrocks> cyphermox: exactly :)
[12:17] <didrocks> cyphermox: we'll need someone to NEW it in the archive (and it will be in manual publishing because of the new package)
[12:18] <didrocks> (just push the button)
[12:18] <didrocks> but I guess we'll be around, so just ask
[12:18] <seb128> didrocks, cyphermox: I'm going to do the NEWing
[12:20] <didrocks> thx
[12:33] <tedg> seb128, Morning, have you had a chance to look at the indicator-messages branch?
[12:33] <seb128> tedg, hey, just quickly, it's one of the next items on my list
[12:34] <seb128> tedg, the alphabetic order thing is still a bit buggy I think, the spec says it should be default im and email first
[12:34] <tedg> seb128, Cool, making sure you guys didn't discuss it on IRC during European time again ;-)
[12:34] <seb128> tedg, not this time, but we landed indicator-keyboard ;-)
[12:34] <tedg> seb128, Yeah, I was trying for something that was reasonable and quick.
[12:35] <tedg> seb128, I realize it's not fully up to spec.
[12:35] <tedg> attente, congrats!
[13:04] <pitti> seb128: g-control-center piled up quite a bunch of commits in bzr; is something blocking the upload of this, or is it just waiting for someone with the permissions?
[13:04] <seb128> pitti, I think it's blocking on indicator-keyboard to land, which is happening today
[13:04] <pitti> ah, good; the ibus stuff is ok?
[13:04] <pitti> seb128: nothign indicator related in the changelog, though
[13:05] <seb128> pitti, let me check
[13:07] <seb128> pitti, debian/patches/input-sources-text-entry.patch:+#define INDICATOR_KEYBOARD_SCHEMA_ID "com.canonical.indicator.keyboard"
[13:07] <pitti> ah, ok
[13:07] <seb128> pitti, it should probably depends on indicator-keyboard
[13:07] <seb128> attente, ^ right?
[13:21] <cyphermox> sil2100: what do you know of these recurring unity test failures? http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1154/testReport/
[13:22] <cyphermox> seb128: indicator-keyboard build will start in 40 minutes
[13:22] <seb128> cyphermox, excellent
[13:23] <seb128> pitti, do you know if upower's GetHistory() return ordonned values?
[13:23] <sil2100> cyphermox: the ibus ones happen from time to time due to ibus being flacky
[13:24] <cyphermox> :(
[13:24] <cyphermox> brb
[13:33] <pitti> seb128: ordonned?
[13:33] <seb128> pitti,     values = up_device_get_history_sync(m_device, "charge", 86400, 150, NULL, NULL);
[13:33] <seb128> pitti, is that giving me a sorted-by-timestamp list?
[13:33] <seb128> or a random order list?
[13:33] <pitti> seb128: oh, "ordered"?
[13:33] <seb128> ups
[13:34] <seb128> yes ;-)
[13:34] <seb128> I'm getting crazy
[13:34] <seb128> it seems in some cases [0] is the most recent point and some other the older
[13:34] <pitti> not sure, reading code
[13:35] <pitti> it's at least not using set operations or anything like that, everything is a GPtrArray
[13:35] <pitti> i. e. it should maintain order
[13:37] <pitti> seb128: so AFAICS the last objejct (i. e. array[length-1]) shoudl be the most recent one
[13:38] <pitti> seb128: my /var/lib/upower/history-charge-42T4694-93-1460.dat is also oldest (line 1) to newest (last line)
[13:39] <pitti> that's how upower reads and writes them, and that's how get_data etc. work, too
[13:40] <seb128> pitti, hum, that's what I though, I must have a stupid error in my code, thanks
[13:42] <seb128> pitti, http://paste.ubuntu.com/6010312/
[13:42] <seb128> pitti, do you see anything stupid in there?
[13:42] <pitti> seb128: ne t'en fais pas -- c'est presque l'heure pour la glace ! :-)
[13:43] <attente> seb128, right, i guess it should
[13:43] <seb128> attente, thanks, I'm going to add that before upload then
[13:43] <attente> seb128, thanks
[13:46] <pitti> seb128: you call that with resolution==10 and which timespan?
[13:46] <seb128> pitti,                     var chargeDatas = batteryBackend.getHistory(batteryBackend.deviceString, 86400, 150)
[13:47] <seb128> pitti, 1 week, 150 (basically what gpm is doing)
[13:47] <pitti> ITYM 1 day; ok
[13:48] <seb128> ups
[13:48] <seb128> sorry, yes ;-)
[13:48] <pitti> seb128: so what's actually unexpected at the output?
[13:48] <pitti> oh, I see, it seems backwards
[13:49] <seb128> pitti, I'm going fro 0 to len, should start with the oldest timestamp (e.g bigger value)
[13:51] <pitti> seb128: my gut feeling is that you misinterpret up_history_item_get_time() somehow
[13:52] <chrisccoulson> qengho, are you following the chromium dev channel? not sure if you noticed that they removed the ability to override the path for the suid sandbox at build time (it's hard-coded to "chrome-sandbox" now")
[13:52] <pitti> seb128: i. e. that it isn't the seconds between that item and the time when you queried, but actually an increasing clock
[13:53] <qengho> chrisccoulson: I haven't seen that, no.  I can patch, but maybe I don't need to.  It's not like that file name faces users.
[13:53] <pitti> seb128: so that the array times will go from 0 upwards
[13:53] <seb128> pitti, well, what I'm doing is what gpm does, and I get the same charge history they do
[13:53] <qengho> chrisccoulson: thanks for the note.
[13:53] <chrisccoulson> qengho, indeed, i don't think there's any harm in not renaming it
[13:53] <chrisccoulson> qengho, http://src.chromium.org/viewvc/chrome?view=revision&revision=216746 is the change
[13:53] <seb128> pitti, e.g my graph is exactly the same, it just seems my datas come in reverse order
[13:55] <pitti> seb128: I'm trying to understand up_history_array_limit_resolution()
[13:55] <pitti> seb128: that starts "time" at 0 and increments it with each array element according to the resolution
[13:56] <pitti> seb128: so from that POV it's correct that the time values increase, I'm just not sure what unit it has
[13:57] <seb128> pitti, I don't care much about the value, just about the order
[13:57] <seb128> pitti, I want to determine the most recent full charge
[13:57] <pitti> that should still be the value of list[len-1]
[13:58] <pitti> seb128: I suppose you truncated the output in the pastebin as you used a resolution of 150; what's the last line in the output?
[13:58] <seb128> pitti, http://paste.ubuntu.com/6010381/
[13:59] <seb128> pitti, that's "        qDebug() << i << "hours back" << (offset - (gint32) up_history_item_get_time(item))/3600.0;
[13:59] <seb128> "
[14:01] <pitti> seb128: could you perhaps temporarily replace that arithmetic with just printing the up_history_item_get_time(item), to make thinking about it easier?
[14:01] <pitti> in the qdebug
[14:02] <seb128> pitti, http://paste.ubuntu.com/6010394/
[14:02] <seb128> ups
[14:03] <seb128> pitti, http://paste.ubuntu.com/6010395/
[14:04] <pitti> bummer
[14:06] <pitti> seb128: oh, wait; I see this comment in the test suite
[14:06] <pitti>         /* get the first item, which should be the most recent */
[14:06] <pitti>         item = g_ptr_array_index (array, 0);
[14:09] <pitti> seb128: ah, I see why
[14:09] <pitti> seb128: upower's conversion function up_history_array_limit_resolution() indeed does reverse the array
[14:09] <pitti>         for (i=length-1; i>=0; i--) {
[14:09] <pitti>                 item = (UpHistoryItem *) g_ptr_array_index (array, i);
[14:09] <seb128> pitti, that's crazyn I've another function doing something similar on another timestamp/number of points and it seems to iterate in the other direction
[14:09] <pitti> [...]
[14:09] <pitti>                         g_ptr_array_add (new, item_new);
[14:10] <pitti> the problem seems to be if the original data has *fewer* points than the number you requested
[14:10] <pitti> then it simply copies the original array
[14:10] <pitti> i. e. doesn't reverse it
[14:10] <seb128> oh, that would explain
[14:10] <seb128> I'm doing a query on 10 days with 1500 points
[14:10] <seb128> and one on 1 day with 150
[14:10] <pitti> i. e. if you request a large number of data, then you get oldest-to-newest
[14:10] <seb128> and they go reverse
[14:11] <pitti> and if you request a smaller number (less than data points your history has) it'll be newest-to-oldest
[14:11] <pitti> that's a bug in upower
[14:11]  * seb128 hugs pitti
[14:11] <seb128> pitti, thanks for figuring that out, it was driving me over crazy for some hours
[14:12] <seb128> pitti, do you want me to open an upstream bug about it?
[14:12] <pitti> seb128: that would be nice, then we can discuss with hughsie
[14:12] <pitti> we need to figure out what the intended order ought to be (presumably oldest-to-newest) and then fix up_history_array_limit_resolution() one way or another
[14:17] <mterry_> tedg, what's the plan for pushing unity-greeter-session-broadcast into saucy?
[14:17] <mterry_> tedg, still just waiting on upstart?
[14:17] <mterry_> But is it ready for daily-release and such besides?  (seems like sil2100 fixed packaging up)
[14:18] <tedg> mterry_, Yeah, that's the big dep.  Needs 1.9.2.  But it could go in.
[14:18] <seb128> pitti, https://bugs.freedesktop.org/show_bug.cgi?id=68384
[14:18] <ubot2`> Freedesktop bug 68384 in general "the "history of charge" order is changing, depending on the resolution" [Normal,New]
[14:18] <tedg> mterry_, I'm not 100% sure why we didn't just finish that.
[14:19] <mterry_> tedg, do you know the ETA for upstart?  Do I need to go poke people?
[14:19] <tedg> mterry_, I asked last week, but everyone was a debconf, so yeah, we need to poke.
[14:26] <pitti> seb128: followed up, pinged hughsie
[14:26] <pitti> seb128: he said he got the flu the other day on G+, so he might not be online ATM
[14:26] <seb128> pitti, danke
[14:26] <seb128> pitti, that's fine, no hurry to get that fixed, at least I know what's going on, not a bug in my code, I can move on to another topic
[14:26] <seb128> pitti, you made my afternoon ;-)
[14:27]  * pitti tu donne une accolade
[14:27] <pitti> "te", argh
[14:27] <pitti> seb128: so, just use "10" for now if you don't need much of the history, and it should mostly work
[14:28] <seb128> pitti, what's the "resolution" exactly there? the highest resolution, the more point you get?
[14:28] <pitti> seb128: it's the (max) number of points you want to get
[14:28] <seb128> pitti, 10 seems low
[14:29] <pitti> seb128: I mean if you are only interested in the current charge
[14:29] <pitti> for actually doing a plot, you'll need 100 or so
[14:29] <seb128> well, 10 points for a day charge graph is going to not be great
[14:29] <seb128> well, I'm doing 2 things
[14:29] <seb128> - a day plot
[14:29] <seb128> - looking on a week back when was the last full charge
[14:29] <pitti> seb128: ah, ok
[14:30] <seb128> for both I need "enough" datas
[14:30] <pitti> seb128: so let's just get this fixed, currently talking to hughsie
[14:30] <seb128> ok
[14:30] <seb128> is there an upower channel?
[14:31] <pitti> seb128: I used to discuss in #udev, but now I'm just /querying
[14:33] <pitti> seb128: ok, settled; I updated the bug, will do this evening or tomorrow morning
[14:34] <pitti> maintenant, c'est l'heure pour la glace !
[14:35]  * seb128 donne une accolade à pitti
[14:35] <seb128> pitti, bonne glace !
[14:42] <seb128> Laney, what are you working on this week/next week? some system settings on your schedule? ;-)
[14:43] <Laney> seb128: yes, just wranging gstreamer atm
[14:43] <Laney> wrangling
[14:44] <Laney> i'll do some of security and privacy
[14:44] <seb128> Laney, thanks
[14:44] <Laney> do we have backends for those?
[14:45] <seb128> for some of the things yes
[14:45] <seb128> not everything
[14:46] <Laney> ok
[14:47] <seb128> cyphermox, still no indicator-keyboard in the queue?
[14:47] <cyphermox> just a second
[14:49] <cyphermox> seb128: should be there incessantly
[14:49] <seb128> cyphermox, thanks
[15:06] <mterry_> tedg, did you rename to url-dispatcher, or is that something else?
[15:08] <tedg> mterry_, Something else
[15:08] <tedg> mterry_, Helper for apps so that they can start apps without having the new app in their apparmor container.
[15:09] <seb128> jbicha_, hey, indicator-keyboard is in saucy ;-)
[15:09] <mterry_> tedg, k, makes sense.  Will look at the MIR today I hope
[15:09] <tedg> mterry_, Cool, thanks!
[15:12] <sil2100> didrocks: did I break something that suddenly some of the prepare jobs in the unity stack fail this way: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-1.1prepare-unity-scope-openweathermap/232/console ?
[15:14] <didrocks> sil2100: seems a temporary network outage in the lab?
[15:14] <didrocks> you should retry the stack IMHO
[15:14] <sil2100> But even good, since I need to check the compiz changelog
[15:16] <sil2100> didrocks: just to make sure, getting an error: "A version (1:0.9.9~daily13.04.18.1~13.04-0ubuntu4) is available at the destination for that component but is not in trunk which is still at 1:0.9.10-0ubuntu1. Ignoring that component for source: compiz, branch: lp:compiz, series: saucy." is normal for compiz right now? Since I don't understand the problem, as we were bumping the upstream version and 1:0.9.10-0ubuntu1 > 1:0.9.9~daily
[15:17] <didrocks> sil2100: is there 1:0.9.9~daily13.04.18.1~13.04-0ubuntu4 in the changelog?
[15:17] <sil2100> 1:0.9.9~daily13.04.18.1~13.04-0ubuntu4 is in the changelog right below the upstream version bump
[15:17] <sil2100> Yes
[15:20] <didrocks> sil2100: do you have the branch?
[15:21] <sil2100> https://code.launchpad.net/~compiz-team/compiz/0.9.10
[15:21] <didrocks> branch: lp:compiz
[15:21] <didrocks> lp:compiz is ~compiz-team/compiz/0.9.10?
[15:22] <sil2100> Shit
[15:22] <sil2100> Ok, that answers all the questions
[15:22] <didrocks> the error message has all the infos…
[15:22]  * didrocks back on system settings
[15:23] <sil2100> Damn, missed it completely, geh
[15:29] <jbicha_> seb128: yay! I'm uploading g-c-c and g-s-d now, can you take care of having ubuntu-desktop depend on indicator-keyboard?
[15:29] <seb128> sil2100, ^ can you make unity depends on indicator-keyboard?
[15:30] <sil2100> seb128, jbicha_: you mean lp:unity? What's this new dependency?
[15:32] <seb128> sil2100, yes, indicator-keyboard
[15:32] <seb128> sil2100, well, as a recommends
[15:32] <seb128> sil2100, it already recommends all the other indicators we use
[15:33] <sil2100> seb128: MR coming up in a moment
[15:33] <seb128> sil2100, thanks
[15:36] <seb128> jbicha_, did you plan to upload the new webkit as well?
[15:39] <sil2100> seb128, jbicha_: I see indicator-keyboard just popped up 40 seconds ago, so here's the merge https://code.launchpad.net/~sil2100/unity/indicator_keyboard_recommends/+merge/181332
[15:40] <seb128> sil2100, thanks, approved
[15:41] <pitti> seb128: merci, c'était délicieuse, comme toujours :)
[15:41] <seb128> mterry_, we finally got indicator-keyboard in the archive, can you comment on https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1205995 ?
[15:41] <ubot2`> Launchpad bug 1205995 in indicator-keyboard (Ubuntu) "[MIR] indicator-keyboard" [Undecided,New]
[15:41] <seb128> pitti, c'est bon les glaces ;-)
[15:41] <mterry_> seb128, will look
[15:41] <seb128> mterry_, thanks
[15:41] <seb128> mterry_, we got ride of the extra vapis, tests are reliable and we have a bug subscriber
[15:48] <jbicha_> seb128: sure I can upload webkit but.... bug 1163886 is nasty
[15:48] <ubot2`> Launchpad bug 1163886 in software-center (Ubuntu) "software-center crashed with signal 5 with WebKit 2.0+" [High,Confirmed] https://launchpad.net/bugs/1163886
[15:48] <seb128> ok, if there is a known issue, maybe not
[15:49] <jbicha_> on the other hand, if we upload the new webkit it should speed up fixing the bug
[15:49] <jbicha_> affects 386 people with dozens of duplicates
[15:49] <seb128> jbicha_, things don't work this way, everybody is stretched out working 10 hours a day, adding pressures doesn't help
[15:49] <seb128> jbicha_, btw just as a fyi, I'm likely going to upload eds soon to turn goa off, we need uoa to work and the gtk depends to be dropped
[15:49] <jbicha_> right, that's why I didn't upload it :)
[15:50] <seb128> and I'm not going to have time to fix stuff properly
[15:50] <jbicha_> didn't you just say we don't break things?
[15:50] <seb128> things are just crazy
[15:50] <seb128> well, the choose is breaking Ubuntu and Ubuntu touch
[15:50] <seb128> or breaking Ubuntu GNOME
[15:50] <jbicha_> UOA in EDS is a new feature, GOA in EDS has worked for years
[15:50] <seb128> I think we should go for what the majority of users run
[15:52] <seb128> jbicha_, so you advocate for turning off uoa and not having eds integration working on Ubuntu/unity
[15:53] <seb128> jbicha_, I don't think it's a reasonable stance
[15:53] <jbicha_> Ubuntu GNOME had to deal with an unwanted dependency on Qt for a year
[15:53] <seb128> right, that's unfortunate
[15:54] <seb128> but Ubuntu touch aims at being on real devices shipped by early next year
[15:54] <seb128> and we can't carry a broken GTK stack on the image
[15:54] <seb128> that would have an high cost in footprint/installation time/etc
[15:55] <seb128> jbicha_, I still suggest we dual build eds, once with uoa, once with goa and make different binaries conflicting
[15:56] <seb128> jbicha_, that just requires somebody to look at it, and I'm not going to have the time before FF
[15:57] <jbicha_> well if you're going to break things you at least don't have to get advance permission if you do it before the freezes :|
[15:57] <seb128> I would prefer to not break things
[15:57] <seb128> that's why I pointing it, if somebody has time to look at that, it would be great
[15:58] <seb128> otherwise it's going to end up of "need to fix that, let's disable goa" next week
[16:00] <Laney> I don't know how well the eds-uoa stuff works
[16:00] <Laney> there's some weird bugs that people said were fixed by installing goa
[16:01] <seb128> right
[16:01] <seb128> Laney, we also need to get ride of the gtk depends on touch
[16:01] <seb128> that's bringing in webkitgtk and tons of stuff
[16:01] <seb128> and every mb is costly on device images
[16:02] <jbicha_> Laney: I believe the issue you saw was because the calendar pieces need to be available for both uoa and goa
[16:02] <Laney> something like that
[16:03] <Laney> where does the gtk depends come from?
[16:03] <jbicha_> the other issue is bug 1193018
[16:03] <ubot2`> Launchpad bug 1193018 in evolution-data-server (Ubuntu) "GOA support not completely split" [High,Confirmed] https://launchpad.net/bugs/1193018
[16:03] <Laney> does having goa link gtk into some eds libraries?
[16:03] <jbicha_> and https://bugzilla.gnome.org/show_bug.cgi?id=703290
[16:03] <ubot2`> Gnome bug 703290 in General "Split goa parts of libgdata into a separate .so" [Normal,New]
[16:04] <Laney> ah I kind of remember this
[16:04] <Laney> there were ifdefs in the code
[16:05] <seb128> Laney, are you interested in having a look to the whole issue?
[16:05] <Laney> I doubt I'll be able to do it, at least not in a reasonable time
[16:05] <seb128> same here :/
[16:05] <Laney> it was quite entangled in the code
[16:05] <Laney> you'll need to tease all of the goa stuff out into its own library
[16:06] <seb128> do we know what binaries end up using goa?
[16:06] <Laney> have you confirmed that it's true that disabling goa gets rid of the gtk depends and also makes calendars work properly?
[16:06] <seb128> could we dual build those?
[16:06] <seb128> no, I didn't yet, but I'm pretty sure it does
[16:07] <seb128> I'm going to test build that in the next days
[16:08] <jbicha_> your previous suggestion was to only disable goa on arm since the Ubuntu GNOME on ARM community is very small and Ubuntu Mobile is currently arm-only, right?
[16:08] <jbicha_> and desktop will need gtk anyway
[16:11] <seb128> jbicha_, right, but that was before I knew that uoa was broken by the goa split
[16:12] <sil2100> seb128: https://code.launchpad.net/~sil2100/cupstream2distro-config/mirclient_abi_break/+merge/181345 <- could you take a look? Quickie to unblock mirslave stack
[16:13] <seb128> sil2100, acked
[16:13] <sil2100> Thanks!
[16:17] <sil2100> didrocks, kenvandine, cyphermox: all components that failed are re-running now, some failed because of some network issue, others needed intervention such as the libmirclient ABI/soname change, but now all is set up for a re-run
[16:17] <didrocks> ok, great!
[16:17] <sil2100> didrocks, kenvandine, cyphermox: publishing needs to be done when most things finish, since for instance mirslave needs to be released along with mir because of the ABI break
[16:18] <didrocks> kgunn: we are already jungling a lot because of Mir those days, can your team tells us when you bump the package names? ^
[16:18] <didrocks> kgunn: I would as well think we shouldn't play it risky those days if we want to land first versions
[16:18] <didrocks> olli: FYI as well ^
[16:18] <pstolowski> didrocks: ping
[16:18] <kgunn> didrocks: ack
[16:18] <didrocks> (libmirclient1 -> libmirclient2 in that case)
[16:18] <didrocks> thanks
[16:18] <didrocks> pstolowski: pong
[16:19] <didrocks> sil2100: you will handle those?
[16:20] <pstolowski> didrocks: just to clarify the removal of scopes; so the client-scopes.json is updated and has landed; and you will remove affected scopes from the distro before FF?
[16:22] <didrocks> pstolowski: not sure I'll have time before FF, or please ping other AA on #ubuntu-release with the list of sources to remove
[16:22] <didrocks> sil2100: you did remove those from dailies, right? ^
[16:23] <sil2100> didrocks: which ones? I'll have to refresh my memory, let me check that
[16:23] <mterry_> tedg, can you subscribe a relevant team to bugmail for url-dispatcher?
[16:23] <didrocks> sil2100:  https://code.launchpad.net/~stolowski/libunity/update-client-scopes/+merge/180182
[16:24] <tedg> mterry_, Done
[16:24] <mterry_> tedg, thanks
[16:25] <pitti> seb128: d'accord, Je crois que j'ai le reparé
[16:25] <seb128> pitti, tu veux que j'essaye le patch ?
[16:25] <pitti> seb128: I attached a patch to the bug, but I'd like hughsie to confirm before I push it upstream
[16:25] <pitti> seb128: si tu veux
[16:26] <seb128> pitti, let me local build
[16:26] <pstolowski> sil2100: see https://code.launchpad.net/~stolowski/libunity/update-client-scopes/+merge/180182
[16:26] <seb128> upower is small
[16:26] <pitti> seb128: mais il s'en va pour aujourd'hui
[16:26] <pitti> seb128: (s/pour// ? )
[16:27] <seb128> pitti, "pour aujourd'hui" works
[16:28] <sil2100> pstolowski: in a minute will check it and get back to you ;)
[16:28] <ogra_> pitti, oh ...
[16:28]  * pitti runs like hell
[16:28] <pstolowski> sil2100: great
[16:29] <ogra_> pitti, did you notice the upower patch i uploaded for sfoshee ? he said he contacted upstream but did not get any feedback for it ... probably you could back his request
[16:29] <pitti> ogra_: I pinged sfoshee about them yesterday and asked him to attach them to bug(s); he didn't subscribe to the ML and there's currently no moderation
[16:30] <ogra_> ah
[16:30] <ogra_> great, so thats sorted
[16:30] <olli> didrocks, ffs, can you tell who did it?
[16:30]  * ogra_ srikes from his TODO
[16:30] <ogra_> *strikes too
[16:30] <didrocks> olli: want me to dive in trunk?
[16:30] <pitti> ogra: well, not quite yet; still need to be forwarded/applied
[16:30] <olli> didrocks, if you can't tell from top of your head, nevermind
[16:31] <ogra_> pitti, right, but there was an apparent blocker i wanted to have removed :)
[16:31] <olli> just thought it was obvious
[16:31] <didrocks> olli: seems to be that commit: http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/991
[16:31] <pitti> olli: ah, he did send them, good
[16:32] <olli> I guess this was for ogra_^
[16:32] <pitti> olli: sorry, yes
[16:32] <olli> .oO(there is not enough space for 2 Olli's in this channel ;)
[16:32] <pitti> olli: sorry for my tab laziness
[16:32] <pitti> o<tab> worked until you spoke up :)
[16:32] <olli> pitti, oh no worries
[16:32] <didrocks> pitti: ah, I will blame weechat as well! ;)
[16:33]  * didrocks keeps doing that o<tab>, relying on the smart completion of weechat
[16:33] <pitti> I think weechat always expands to the nick who spoke most recently, in general that makes sense
[16:33] <didrocks> yeah, and so you become lazy and just type a letter
[16:33] <didrocks> "known issue here"
[16:33] <pitti> bonne nuit tout le monde !
[16:33] <didrocks> bonsoir pitti!
[16:35] <ogra_> olli, well, thats easy, i'm oli with one l anyway ... easy to tell us apart :)
[16:36] <olli> :)
[16:36] <olli> didrocks, will fwd your input to the team
[16:36] <didrocks> olli: thanks ;)
[16:41] <didrocks> sil2100: they were not removed? the item was marked as DONE AFAIK last week
[16:43] <sil2100> didrocks: I see them daily releasing, as well as apt-cache show unity as recommending those scopes
[16:44] <sil2100> didrocks: at least from daily-release we need those removed
[16:44] <sil2100> didrocks: and making sure that they are removed if installed
[16:44] <didrocks> sil2100: thanks!
[16:44] <sil2100> didrocks: (I was wrong with the recommends part, as I have an older unity installed here)
[16:44] <didrocks> ah ok :)
[16:45] <didrocks> I saw them removed from my system :p
[16:45] <didrocks> sil2100: ok, did you see what I added? do you think it's feasable between you and Mirv before EOW?
[16:45] <didrocks> Mirv: sil2100: 5 phone components on the bottom of the spreasheet to bootstrap, 4 for dailies and 1 for direct sponsor in the archive
[16:45] <sil2100> didrocks: sure
[16:46]  * sil2100 gathers karma
[16:46] <didrocks> will need preNEWing as well, I think it will be again seb128 and I, but let's try to have slangasek on board
[16:46] <didrocks> sil2100: heh, indeed ;)
[16:46] <didrocks> then, it's a step closer to no ppa and make asac happier
[16:46] <didrocks> and that's priceless
[16:49] <Laney> seb128: I just found out that i18n.tr has a plural argument
[16:49] <seb128> Laney, I saw that in other projects, but it seems to conflict with how I set up the translations to be able to specify a domain...
[16:49] <Laney> how's that?
[16:50] <Laney> i18n.tr(singular, plural, n)
[16:50] <seb128> how is the plural working?
[16:50] <seb128> I made i18n.tr(string, [domain])
[16:50] <seb128> can you have a i18n.tr(singular, plural, n, domain)
[16:50] <seb128> ?
[16:50] <Laney> that's called dtr
[16:50] <seb128> I didn't find how to make xgettext dtrt
[16:51] <seb128> i18n.dtr?
[16:51] <seb128> what's the syntax?
[16:51] <Laney> http://developer.ubuntu.com/api/devel/ubuntu-13.10/qml/ui-toolkit/qml-ubuntu-components0-i18n.html
[16:51] <seb128> can I do i18n.dtr(domain, singular, plural, n)?
[16:52] <seb128> great
[16:52] <Laney> didn't know you override the domain though
[16:52] <Laney> where is that?
[16:52] <seb128> we need to, the plugins might have their own translations
[16:52] <seb128> e.g online accounts
[16:52] <Laney> that's done in the .settings file though
[16:53] <Laney> i think
[16:53] <seb128> Laney, well, what reads the .settings? ;-)
[16:53] <Laney> yes but I don't understand why the qml side has to know about this
[16:53] <seb128> about what?
[16:53] <Laney> the domain
[16:54] <Laney> we haven't used dtr anywhere else
[16:54] <seb128> see r52
[16:54] <seb128> Laney, the issue is to have those strings properly listed in the pot
[16:55] <seb128> hum
[16:55] <seb128> that might be the wrong commit
[16:56] <Laney> I see why you might have to use that the way things are if you want to use a non-default domain
[16:56] <Laney> not sure why it matters for your use in battery though
[16:57] <seb128> oh, I don't need it that in battery
[16:57] <seb128> I'm just thinking loud, sorryu
[16:57] <seb128> there was a gotcha with the po/po.pro last time I looked at that
[16:57] <seb128> like the resulting .pot was buggy
[16:57] <Laney> i'll find out in a minute
[16:57] <seb128> xgettext didn't understand the dtr format
[16:57] <seb128> k
[16:57] <Laney> oh crap it's 17:57, how did that happen?
[16:58] <Laney> need to go out in 20 minutes arghghghg
[16:58] <seb128> need to go our for exercice
[16:58] <seb128> bbl
[16:59] <didrocks> olli: kgunn: so sil2100 is going to coordinate the transition, but this will take more time has it wasn't warned. We will need someone with upload right as well or everything (even touch) will be blocked in proposed
[17:00] <didrocks> because of this transition
[17:00] <didrocks> when you are on top of you stack, you have more responsabilities :)
[17:00] <kgunn> didrocks: ack...its a pain, but it it good to see the catches working for api right ?
[17:01] <kgunn> silver lining
[17:01] <didrocks> kgunn: right ;) the issue there is that on the client, we have a consumer outside of dailies (xmir)
[17:01] <didrocks> kgunn: otherwise, it would have been easier to do that in a more transparent fashion
[17:03] <didrocks> on that, after again 12 crazy hours… /me waves good evening!
[17:07] <Laney> seb128: hmm, it doesn't work for me
[17:07] <Laney> seb128: I see "%n minutes" literally
[17:07] <Laney> got to go, will push but not MP what I have
[17:07]  * Laney waves
[17:31] <sil2100> seb128: hi! still around?
[17:32] <sil2100> seb128: need a quick ACK https://code.launchpad.net/~sil2100/cupstream2distro-config/libmirclient2_platform/+merge/181357
[17:33] <sil2100> fginther: ^ could you ACK?
[17:33] <sil2100> ;)
[17:33] <fginther> sil2100, np
[17:34]  * sil2100 needs anyone to approve, since otherwise he'll have to self-approve
[17:34] <sil2100> Which is bad
[17:34] <sil2100> fginther: thank you!
[17:34] <fginther> sil2100, done. Depends on what you mean by 'bad'
[17:34] <fginther> :-)
[17:35]  * fginther self approves just to avoid direct pushes sometimes
[17:35] <sil2100> True, that's better indeed ;)
[17:36] <sil2100> Safer
[17:44] <sil2100> Tragedy, the intel machine got offline again
[17:44] <sil2100> geh, I'll never finish for today ;/
[18:07] <robru> good morning desktoppers!
[18:15] <sil2100> robru: morning!
[18:15] <robru> sil2100, hey, how's it going? I just got in to vancouver!
[18:15] <sil2100> robru: ok, just in case you want to do some daily-business - one tick has been missed
[18:15] <sil2100> robru: it's really REALLY busy ;)
[18:15] <sil2100> robru: we missed one tick since Mir introduced an ABI break, and all hell went loose
[18:16] <sil2100> robru: so just so you know - mir related stuff might get stuck in -proposed until RAOF uploads the dep-bumped xorg-server
[18:16] <sil2100> robru: oh, and the intel AP machine is going all crazy, dying for no reason
[18:16] <sil2100> But now... I need to rest, 12 hours of work is a bit too much
[18:16] <sil2100> See you tomorrow everyone
[19:20] <robru> kenvandine, https://code.launchpad.net/~robru/friends/disable-contacts-sync/+merge/181386 trivial diff if you get a sec please.
[20:04] <robru> cyphermox, ping
[20:05] <cyphermox> pong
[20:05] <robru> cyphermox, hey. just curious if you are looking at the daily release stuff right now? I think you are the 'vanguard' for the most recent run
[20:06] <robru> weird issue with the sdk stack, looks like it needs to be republished? not sure though, and didn't want to do it in case you're working on it
[20:10] <cyphermox> yes
[20:10] <cyphermox> well, it doesn't need to be republished
[20:10] <cyphermox> it says failed, but seems to me like it was all good
[20:10] <cyphermox> the package is in the archive and the commit was merged
[20:12] <cyphermox> robru: same for unity8
[20:12] <cyphermox> there's just the tests for unity that failed
[20:12] <robru> cyphermox, can you explain to me why it's red? the failure message makes no sense.
[20:12] <robru> to me
[20:13] <cyphermox> well it's red because there was an error
[20:13] <cyphermox> http://10.97.0.1:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/195/console
[20:13] <cyphermox> the return code was something evil
[20:14] <cyphermox> so it becomes red, but either it passed anyway, or someone else touched it and didn't tell me
[20:15] <robru> cyphermox, yeah, that URL exactly. that error message means nothing to me. "lock exists"? that makes it sounds like it tried to run twice at once. and this one failed. so where's the other one that passed?
[20:15] <cyphermox> robru: no idea
[20:15] <robru> what I mean is this error has nothing to do with the sdk stack itself, it looks like an error inside jenkins or inside the daily infrastructure itself
[20:15] <cyphermox> yes
[20:16] <robru> ok then
[20:16] <robru> cyphermox, http://10.97.0.1:8080/view/cu2d/view/Head/view/All/job/cu2d-sdk-head/ actually #260 and #261 both ran at the same time, and #260 is green. so I guess it's fine?
[20:18] <cyphermox> ah, nice catch
[20:18] <cyphermox> how did this happen though?
[20:22] <robru> no idea.
[20:22] <robru> cyphermox, exact same thing on unity8, the previous job ran within 30s of the most recent run and is green.
[20:22] <cyphermox> yep
[20:23] <robru> cyphermox, unity7 stack is the only one with a real failure, and it was simply aborted by lukasz. so I guess we just have to wait for that one to run again? I don't see anything actionable among these failures.
[20:23] <cyphermox> yep
[20:23] <cyphermox> we'll just watch the next run carefully
[20:24] <robru> alright then, I vanguard the next run. might ping you for help depending on what the errors look like ;-)
[20:24] <robru> gonna be around in a couple hours?
[20:26] <cyphermox> yeah I'll be sticking around way late, most likely
[20:26] <cyphermox> I try to watch the orphan run late at night too ;)