[01:18] <robru> Saviq, I got silo 2 for your split-greeter landing.
[01:18] <robru> Saviq, even hit build for you too: https://ci-train.ubuntu.com/job/landing-002-1-build/29/console
[01:37] <rsalveti> robru: mind getting me a silo for 58?
[01:37] <rsalveti> robru: need it via a silo as I want to build for all archs
[02:04] <imgbot> [03:24] <imgbot> [03:24] <imgbot> [04:15] <Mirv> rsalveti: assigning, might be late..
[04:15] <rsalveti> Mirv: still fine
[04:16] <Mirv> rsalveti: landing-004 after it refreshes
[04:16] <rsalveti> Mirv: great, thanks!
[05:18] <robru> rsalveti, sorry I was out at a movie. looks like Mirv got ya... next time!
[05:29] <Mirv> robru: I don't think there's anything wrong in spending an evening at a movie! :D
[05:29] <robru> ;-)
[06:21] <Mirv> morning didrocks
[06:22] <didrocks> hey Mirv
[06:26] <didrocks> Mirv: unity-webapps-qml seems to be stuck in proposed (robru seems to have used the override) for hours, mind looking why?
[06:30]  * Mirv looks
[06:31] <Mirv> why overriding :(
[06:34] <Mirv> hmm, why on earth does unity-webapps-qml build against qtwebkit and runtime depend on both qtwebkit and oxide..
[06:36] <Mirv> I think I may need osomon online to check some facts before contacting release team
[06:37] <didrocks> Mirv: right "why" :/
[06:37] <didrocks> Mirv: fowarding you the context
[06:40] <Mirv> thanks for the email
[06:40] <circ-user-kvQZy> imgbot, status 281 manta
[06:41] <imgbot> Image 281 test results on manta - Total: 655, Pass: 622, Crashes: 3, Rate: 93.5%
[06:43] <sil2100> didrocks, Mirv: are we in TRAINCON0 already? ;)
[06:44] <Mirv> sil2100: I guess we've sort of TRAINCON status override or such...
[06:45] <Mirv> sil2100: FYI I'm looking at the unity-webapps-qml migration problems, but now waiting for osomon to arrive online to ask some questions about the qtwebkit/oxide divide
[06:46] <Mirv> u-w-q has very "funny" b-d/deps
[06:48] <didrocks> sil2100: not yet, it's under discussion :p
[06:48] <didrocks> Mirv: ^
[06:48] <didrocks> so right now, we continue pushing changes
[06:48] <didrocks> Mirv: "funny"? I like fun! :p
[06:55] <sil2100> Mirv: ACK
[07:02] <dbarth> good morning
[07:02] <didrocks> hey dbarth!
[07:03] <dbarth> didrocks: hi
[07:03] <dbarth> all good with oxide?
[07:03] <dbarth> it got approved late last night
[07:03] <didrocks> dbarth: webapps-qml isn't out of -proposed though
[07:03] <didrocks> (see the emails)
[07:03] <didrocks> dbarth: I'm unsure about the impact and Mirv needs osomon to be around to understand some details
[07:03] <dbarth> however i need help for a reconfig on silo 8 cause i had forgotten a branch
[07:03] <dbarth> uh
[07:03] <dbarth> ok checking
[07:04] <didrocks> dbarth: just read emails, if you can assess the impact there, it will be nice :)
[07:06] <dbarth> didrocks: ok done
[07:06] <dbarth> didrocks: the impact is simple: desktop webapps don't start at least, because they want the newer 1.0 qml layer which is still 0.1 until the new webapps-qml is promoted
[07:07] <didrocks> dbarth: ok, so desktop only?
[07:07] <didrocks> nothing with touch?
[07:07] <dbarth> i suppose touch would be impacted, but in a lesser way
[07:08] <dbarth> so anyway, this unity-webapps-qml promotion needs to be solved
[07:08] <didrocks> dbarth: right, I'm trying to understand if we need to respawn then a Touch image, if you can grab more info on the Touch one
[07:09] <didrocks> dbarth: for solving it, Mirv is on that once osomon is around
[07:09] <Mirv> dbarth: the problem comes from the fact that webapps-qml builds against qtwebkit and depends from the binary package to both qtwebkit and oxide
[07:09] <didrocks> Mirv: we have some archs it's not available for?
[07:09] <Mirv> dbarth: if you happen to know the reason why it doesn't build against oxide instead, please tell (I thought oxide was about replacing qtwebkit)
[07:09] <dbarth> do you have a build log?
[07:09] <Mirv> didrocks: yes. it builds for all archs since it builds against qtwebkit, while it has a binary dependency against oide
[07:10] <dbarth> the latest unity-webapps-qml builds against oxide 1.0
[07:10] <Mirv> dbarth: webapps-qml builds against everything, since it uses qtwebkit instead of oxide for building
[07:10] <dbarth> it may have been build while oxide 1.0 was not yet in the archive
[07:10] <dbarth> ie, in unapproved
[07:10] <Mirv> dbarth: no, https://launchpadlibrarian.net/172041103/unity-webapps-qml_0.1%2B14.04.20140407-0ubuntu1.diff.gz - the one in proposed builds against qtwebkit
[07:10] <dbarth> besides, u-webapps-qml has code to fallback on qtwebkit if oxide is not there
[07:11] <dbarth> Mirv: ok checking
[07:11] <didrocks> Mirv: oxide is in main now, so it needs to build-deps on both to at least restrict the archs I think
[07:11] <Mirv> (in that diff it's possible to search for "control")
[07:11] <dbarth> right, so that looks like the correct release
[07:11] <Mirv> didrocks: yes, if it would build-dep on oxide then it would solve the problem of building but not being able to install
[07:11] <didrocks> Mirv: not fully, as then:
[07:11] <didrocks>  unity-webapps-qml | 0.1+14.04.20140401.1-0ubuntu1 | trusty          | source, amd64, arm64, armhf, i386, powerpc, ppc64el
[07:11] <didrocks> so we need to check if it can be removed on other archs
[07:12] <Mirv> didrocks: yes, then it would still need removal for the other archs, but as it is it builds but is uninstallable which is worse
[07:12] <didrocks> Mirv: if I'm reading reverse-depends right, it should be fine
[07:12] <didrocks> Mirv: nothing on the other archs are depending on it
[07:13] <didrocks> so yeah, the build-dep trick should be enough
[07:13] <Mirv> ok, so the problem is limited to webapps-qml at least
[07:13] <didrocks> right ;)
[07:13] <didrocks> dbarth: Mirv: can you handle a MP with that fix and release it?
[07:13] <didrocks> (oxide being in main, there is no issue)
[07:14] <Mirv> um, there is no oxide "dev" package in the first place
[07:14] <Mirv> to build against
[07:15] <dbarth> Mirv, didrocks: cjwatson had advised not to add arch-specific tricks though
[07:15] <didrocks> dbarth: hence the build-dep
[07:15] <didrocks> dbarth: it does avoid setting arch-specific metadata
[07:15] <dbarth> hmm ok, fine then
[07:15] <didrocks> Mirv: I would add the build-dep against liboxideqt-qmlplugin personnally
[07:15] <dbarth> so, it's really just a dependency issue that had it blocked?
[07:15] <didrocks> Mirv: with a comment on why
[07:15] <dbarth> cause i think we had it uploaded before
[07:16] <dbarth> the only thing that changed was the oxide 1.0 transition really
[07:16] <didrocks> dbarth: it's the fact that "it built on all archs, but you won't be able to install it on all archs"
[07:16] <didrocks> because of this new dep
[07:16] <dbarth> ok
[07:16] <didrocks> dbarth: then, now, because previous version was available on all archs, I'll need to remove some binary packages as well
[07:16] <dbarth> ok
[07:16] <didrocks> dbarth: however, please, can you really assess before 10am the consequence for the current touch image?
[07:17] <didrocks> dbarth: that would really speed us up
[07:17] <dbarth> i can review an MP, just not going to be fast at that
[07:17] <dbarth> and i can check the impact on phone in the meantime
[07:17] <didrocks> dbarth: I'm handling that with Mirv, just assess the impact :)
[07:17] <dbarth> ie, image #281
[07:17] <dbarth> ok
[07:17] <didrocks> yep
[07:17] <didrocks> thanks!
[07:17] <dbarth> cool
[07:17] <didrocks> Mirv: yeah, so the -qmlplugin seems the best to me, wdyt?
[07:18] <Mirv> didrocks: or the lib itself https://code.launchpad.net/~timo-jyrinki/unity-webapps-qml/build_dep_on_oxide/+merge/214673
[07:18] <didrocks> Mirv: as you feel more confortable with :)
[07:19] <didrocks> Mirv: please, add a comment :)
[07:19] <didrocks> or it will be dropped with a cleanswap without us remembering about it
[07:19] <Mirv> didrocks: I'm not totally comfortable with either, but either would work
[07:19] <Mirv> didrocks: is the commit message not enough?
[07:19] <Mirv> "to limit archs to be built to the set for which webapps-qml is installable for."
[07:19] <didrocks> Mirv: I would add it directly to debian/control
[07:20] <Mirv> right, doing
[07:20] <didrocks> Mirv: the same one than your commit message :)
[07:20] <Mirv> pushed
[07:21] <didrocks> Mirv: approved
[07:21] <didrocks> Mirv: you file the landing ticket and handle it?
[07:21] <didrocks> Mirv: just keep me posted one published so that I remove the binary packages on other archs
[07:21] <didrocks> once*
[07:21] <Mirv> yep, landing
[07:22] <didrocks> thanks ;)
[07:23] <Mirv> dbarth: this separate landing would mean you'd need to rebuild landing-008 after this has landed, is that ok?
[07:30] <sil2100> Mirv: I would say it's ok, let's leave a comment on the other silo with unity-webapps-qml and assign this one
[07:30] <sil2100> To get it landed quick
[07:30] <bzoltan> Mirv: sil2100: May I have a Silo for the line 60?
[07:31] <sil2100> bzoltan: sure! We're allowed to land stuff as goes so let me assign a silo for you ;)
[07:32] <sil2100> Mirv: thanks Timo \o/
[07:34] <Mirv> sil2100: yeah, I figured out it's probably ok and fired a build
[07:34] <bzoltan> sil2100: Thank you!
[07:35] <sil2100> yw o/
[07:44] <dbarth> Mirv: it's ok, i was prepared to rebuild 008 anyway
[07:47] <josharenson> fginther: can you shed any light on https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1252933 ?
[08:04] <dbarth> didrocks, Mirv: i tested image #281 and webapps and html5 apps are not affected luckily
[08:04] <didrocks> dbarth: thanks for confirming :)
[08:05] <dbarth> Mirv: do you have a branch i need to +1 to re-upload?
[08:05] <didrocks> dbarth: https://code.launchpad.net/~timo-jyrinki/unity-webapps-qml/build_dep_on_oxide/+merge/214673
[08:07] <Mirv> dbarth: there's a branch
[08:13] <dbarth> ok
[08:13] <dbarth> i can take this one in silo 008 since i need a valid unity-webapps-qml there as well
[08:14] <dbarth> Mirv ^^
[08:14] <didrocks> dbarth: no, we want to solve the situation ASAP, let's do 2 landings
[08:15] <dbarth> ok, so i'll remove the other branch from the silo and will build once you tell me the other one is landed
[08:17] <didrocks> it's building
[08:17] <didrocks> Mirv: it will deadlock on building btw
[08:17] <didrocks> Mirv: as it was available on more archs
[08:17] <didrocks> Mirv: so, actually, it's ready is seems :)
[08:20] <ogra_> imgbot, status 281
[08:20] <imgbot> Image 281 test results on mako - Total: 676, Pass: 661, Crashes: 5, Rate: 98.4%
[08:20] <ogra_> hmm, quite a few failures
[08:23] <Mirv> didrocks: yes, I'll smoke-test and publish afterwards
[08:23] <didrocks> Mirv: good!
[08:23] <didrocks> Mirv: binary removed FYI
[08:24] <didrocks> (after rechecking the rdepends)
[08:24] <Mirv> ok, great
[08:25] <didrocks> stopping the build job
[08:36] <Mirv> tested, and published as there was already a packaging ack from a certain core dev on the change
[08:37] <sil2100> 'A certain core dev' ;)
[08:51] <Laney> Is that a build-dep on a runtime library package?
[08:54] <cjwatson> Tolerable enough for this sort of purpose
[08:54] <cjwatson> Though I'd have used liboxideqt-qmlplugin to avoid the soname dependency
[08:55] <Laney> I get artifically causing dep waits, but there must be a better way than the library package
[08:55] <Laney> That's why I worded it like that.
[08:58] <davmor2> popey: python-statgrab - interface to the libstatgrab library for Python
[08:58] <popey> thanks davmor2
[09:04] <popey> ev: does whoopsie have smarts not to upload .crash files over 3g?
[09:04] <ev> popey: yeah, so long as network-manager is around
[09:04] <ev> it uses that API to make the determination
[09:04] <popey> ok
[09:06] <popey> davmor2: http://popey.com/~alan/phablet/device-2014-04-08-100638.png
[09:06] <popey> scopes look screwy there for me.
[09:07] <davmor2> popey: the images are missing I see them here
[09:07] <popey> i am on 3g and have run out of credit
[09:08] <popey> i dont think our UI should degrade badly when we have no internet connection
[09:08] <davmor2> popey: that'll be why then 3g seems to only display data
[09:08] <popey> the same would happen if i was out of range
[09:09] <davmor2> popey: need to reboot my server back in a tick
[09:13] <popey> also davmor2 http://popey.com/~alan/phablet/device-2014-04-08-101338.png
[09:15] <didrocks> cjwatson: ah, I was with you on that one ;) (but I guess the qmlplugin one will have version soon thinking about it)
[09:15] <sil2100> psivaa: could you give me a poke once the re-run of tests finishes?
[09:16] <psivaa> sil2100: sure
[09:16] <sil2100> bzoltan: so, we might have a small problem ;/
[09:18] <bzoltan> sil2100:  what is that?
[09:18] <didrocks> popey: they will tell you "waiting on design input"
[09:19] <didrocks> popey: what I got yesterday with the issue we had with the store being down
[09:20] <ogra_> i dont think caching icons locally is a design issue
[09:21] <didrocks> mhr3_: ^
[09:21] <ogra_> the scope should simply use a cache and only download diffs
[09:21] <sil2100> bzoltan: so, qtcreator-plugin-ubuntu is blocked in -proposed because I missed that unity-scope-tool is not available for ppc-like platforms
[09:21] <sil2100> bzoltan: because it's generated out of unity8 source, which has mir dependencies ;/
[09:21] <popey> didrocks: uh.
[09:21] <ogra_> (so that the UI can be decoupled from the server a bit)
[09:22] <mhr3_> didrocks, scope has nothing to do with icons
[09:22] <mhr3_> didrocks, also, that didn't change one bit compared to old scopes
[09:22] <ogra_> it displays them, no ?
[09:22] <mhr3_> no
[09:23] <didrocks> mhr3_: the scopes scope isn't the one giving the url to unity8,
[09:23] <didrocks> ?*
[09:23] <ogra_> so what drwas that rsater with icons in it ?
[09:23] <ogra_> *raster
[09:23] <mhr3_> didrocks, right, and unity can handle caching globally
[09:23] <mhr3_> at some point
[09:23] <ogra_> thgis is clearly a caching issue http://popey.com/~alan/phablet/device-2014-04-08-101338.png ... whatever part of the system is responsible for it
[09:23] <bzoltan> sil2100:  ohh... do not worry. Feel free to drop it now.
[09:24] <popey> i did scroll through all of those icons while on wifi
[09:24] <popey> then dropped wifi and see squares
[09:24] <ogra_> well, and even on wifi scrolling through them is awful depending on your wlan speed
[09:24] <sil2100> bzoltan: the package you mean?
[09:25] <sil2100> bzoltan: or support for ppc, ppc64 and amd64?
[09:25] <bzoltan> sil2100: either of them
[09:26] <popey> also... http://popey.com/~alan/phablet/device-2014-04-08-102620.png
[09:27] <popey> also http://popey.com/~alan/phablet/device-2014-04-08-102643.png
[09:32] <popey> mhr3_: do we have a bug for this already?
[09:32] <popey> i have a vauge recollection of one but cant find it
[09:32] <mhr3_> popey, the issue is there for over 6 months, i'm pretty sure we do
[09:33] <mhr3_> and the "not seeing anything" issue is already listed as blocker
[09:35] <cjwatson> didrocks: or oxideqmlscene ...
[09:35] <mhr3_> popey, https://bugs.launchpad.net/unity8/+bug/1224998
[09:35] <mhr3_> popey, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1271963
[09:35] <popey> thanks
[09:36] <psivaa> didrocks: bug #1304292 is reported for telepathy-ofono crash occurred today
[09:36] <didrocks> cjwatson: I was less thrilled by that one as I'm unsure unity-webapps-qml is going to use it directly, but it's posible
[09:36] <didrocks> psivaa: thanks!
[09:36] <cjwatson> sil2100: you could make the unity-scope-tool dependency architecture-specific, perhaps
[09:36] <mhr3_> popey, also, you opened the latter :)
[09:36] <popey> \o/
[09:37] <cjwatson> Hm.  I think this click change has exposed a pre-existing content-hub crash
[09:38] <cjwatson> Let's see if I can make it more obvious ...
[10:02] <Saviq> popey, but it might take some time
[10:02] <Saviq> popey, you can just Ctrl+C
[10:03] <Saviq> popey, and upload the .crash somewhere for us - whoopsie will upload nevertheless, and drop a corresponding, root-owned .uploaded file, which means the next time it crashes, it will overwrite the whole thing
[10:08] <popey> Saviq: http://chinstrap.canonical.com/~alan/_usr_bin_unity8.32011.crash
[10:09] <ogra_> awesome, finally a non corrupt one
[10:09] <ogra_> :)
[10:09] <popey> bug 1304315 is the bug to go with it Saviq
[10:09] <psivaa> didrocks: sil2100: the rerun is now complete, with gallery failing the same tests, sudoku passing, and telepathy-ofono not crashing during messaging-app test
[10:10] <Saviq> popey, thanks!
[10:10] <popey> np
[10:10] <didrocks> psivaa: thanks!
[10:10] <psivaa> yw :)
[10:10] <didrocks> sil2100: trying the sdk revert on gallery? ^
[10:10] <bzoltan> sil2100: didrocks: what is worng with the SDK?
[10:11] <didrocks> bzoltan: we are trying to understand the gallery issue on the dashboard
[10:11] <didrocks> bzoltan: trying to point what could have impacted that
[10:11] <ogra_> doe anyone know why silo-06 was flushed ?
[10:12] <ogra_> (that corresponds with line 12 on the pending sheet)
[10:13] <ogra_> didrocks, ^^^any idea ?
[10:13] <cjwatson> huh?  silo-006 is mine
[10:13] <ogra_> cjwatson, since when ?
[10:13] <cjwatson> yesterday
[10:13] <ogra_> well, it was the media-hub one before ...
[10:13] <cjwatson> ah, I guess line 12 was the previous occupier
[10:14] <ogra_> right
[10:14] <cjwatson> it's line 51 now :)
[10:14] <t1mp> didrocks, sil2100 gallery-app tests were already failing for me locally for a while because of broken imports
[10:14] <ogra_> and there is no explanation who flushed it and if that was agreed with the devs
[10:14] <t1mp> didrocks: I don't know why it used to work on jenkins. But elopio proposed a fix https://code.launchpad.net/~elopio/gallery-app/override_toolbar/+merge/213703
[10:14] <ogra_> (and i cant find anything in backlogs)
[10:14] <t1mp> didrocks: I don't know what changed where.. maybe a different python version?
[10:15] <sil2100> didrocks: reverting
[10:15] <didrocks> sil2100: or try elopio's fix
[10:15] <t1mp> sil2100: https://code.launchpad.net/~elopio/gallery-app/override_toolbar/+merge/213703
[10:15] <didrocks> ogra_: see what I told on the other channel, it's all info I have
[10:15] <sil2100> k, will try this and then a revert
[10:15] <cjwatson> t1mp: that looks like it was relying on relative imports, which you don't have in Python 3 (and which were madness anyway ...)
[10:15] <ogra_> didrocks, which other channel ?
[10:15] <didrocks> ogra_: #phablet?
[10:15] <didrocks> I wrote there
[10:16] <ogra_> oh, probably before i re-joined
[10:16] <didrocks> about the comment which was set, it's all the info I had
[10:16] <ogra_> ok
[10:16] <ogra_> would really help if people put their name on it if making such comments
[10:16] <cjwatson> t1mp: well, rather, you do have them, you just have to spell them differently (leading ".")
[10:16] <t1mp> cjwatson: did the image recently switch to python 3?
[10:16] <cjwatson> t1mp: I don't know the timing details
[10:16] <didrocks> ogra_: +1
[10:17] <cjwatson> but there was a big push to get autopilot onto python 3 yes
[10:17] <t1mp> the weird thing is that I have had tests failing on that for a while now, while they didn't seem to fail on jenkins. Jenkins caught up now ;)
[10:17] <t1mp> hmm.. maybe one of the packages that I installed for testing upgraded python on my device
[10:18] <cjwatson> rather, upgraded autopilot
[10:18] <cjwatson> (you don't upgrade from python 2 to 3 as such; they're installed in different paths, /usr/bin/python vs. /usr/bin/python3)
[10:19] <Mirv> dbarth: your unity-webapps-qml silo could now be rebuilt, the other one landed & merged to trunk
[10:19] <t1mp> I tried to run the tests the same way jenkins does it, but apparently there still were differences
[10:20] <mhr3_> sil2100, silo for 54 pls
[10:21] <sil2100> mhr3_: I can has low on silos, but let me see what we can do about that
[10:21] <davmor2> Morning all
[10:22] <mhr3_> sil2100, it's blocker fix
[10:22] <dbarth> Mirv: right, i just saw that
[10:22] <dbarth> Mirv: will proceed now
[10:22] <davmor2> didrocks: bug of the day Time set itself to 1 of Jan 1970 00:00  oops
[10:22] <kgunn> sil2100: morning...could you reconfig silo 005?
[10:23] <sil2100> kgunn: morning! Let me reconfig
[10:23] <sil2100> kgunn: btw. I'm publishing the other one you set to ready, thanks
[10:29] <sil2100> kgunn: ok, so, we need to wait for platform-api to appear in the archive from the other landing
[10:30] <sil2100> kgunn: I will ask you then to rebuild everything, ok? SInce I see that landing 005 has platform-api
[10:30] <Saviq> popey, can you please subscribe me to bug #1304315
[10:31] <popey> Saviq: done
[10:31] <Saviq> popey, o/
[10:32] <kgunn> sil2100: ack
[10:32] <Saviq> popey, can I make public?
[10:32] <popey> Saviq: if its got nothing sensitive in it, sure
[10:32] <Saviq> popey, core is gone already
[10:32] <popey> dunno if my Google passwords and stuff would be in the crashdump
[10:32] <popey> ok
[10:32] <cjwatson> I've lost my control instance - is anyone else seeing content-hub crashes in a current-ish proposed image?
[10:33] <popey> feel free
[10:33] <Saviq> tedg, bug #1304315
[10:33] <Saviq> tedg, looks like libUAL crashed in some string quoting
[10:34] <Saviq> popey, any idea which app you were launching?
[10:34] <popey> Saviq: yeah, G+ webapp, says in the bug
[10:34] <popey> net.launchpad.click-webapps.googleplus
[10:34] <popey> thats the last thing to be installed
[10:38] <Saviq> popey, can't repro, but trace is rather good, should point us at what happened
[10:38] <popey> yay
[10:40] <sil2100> bzoltan: what do you think about this? https://code.launchpad.net/~sil2100/qtcreator-plugin-ubuntu/arch_specific_scope_dep/+merge/214710
[10:40] <sil2100> bzoltan: can I add it to your landing, rebuild and try re-publishing?
[10:40] <bzoltan> sil2100:  ohh.. that is an elegant solution
[10:44] <ogra_> sigh
[10:44] <ogra_> my update manager UI vanished again during OTA
[10:44] <ogra_> popey, davmor2 ^^^^did i ask you about that before ? i'm seeing that since a few days
[10:45] <popey> nope, not heard that one
[10:45] <ogra_> the whole progressbar UI part just vanishes
[10:45] <popey> did you rotate?
[10:45] <ogra_> sometimes i can trigger it easily by scrolling upwards
[10:45] <popey> i have seen odd things happen in that app if you rotate it
[10:45] <ogra_> sometimes it just happens on its own (like it did now)
[10:45] <ogra_> nope
[10:45] <ogra_> it lies flat on its back
[10:46] <ogra_> it also gives you the restart screen after a while ... but until it does the screen is completely empty .. i only have the header
[10:47] <ogra_> hmm, still greyed out scopes on boot
[10:47]  * ogra_ has to swipe once from the right to get the screen even active)
[10:48] <ogra_> oh, g* now gets the scaling of the welcome screen right
[10:48] <ogra_> *G+
[10:53] <davmor2> ogra_: yeap and now when you follow a link that is scaled correctly too
[10:53] <ogra_> i dont want that to be scaled at all
[10:53] <ogra_> i want that to open in the browser :P
[10:54] <ogra_> (like the webapp-container commandline from teh .desktop file implies ... but that doesnt seem to work)
[10:56] <popey> i think i may have found my memory leak
[10:56] <popey> ps_2014-04-08-104122.txt: 18.3 MiB + 609.5 KiB =  18.9 MiB	ubuntu-location-serviced
[10:56]  * ogra_ hands popey a bucket
[10:56] <popey> ps_2014-04-08-104726.txt: 21.6 MiB + 483.5 KiB =  22.1 MiB	ubuntu-location-serviced
[10:56] <popey> ps_2014-04-08-105332.txt: 24.9 MiB + 486.0 KiB =  25.4 MiB	ubuntu-location-serviced
[10:56]  * popey passes the bucket to tvoss ☻
[10:56] <ogra_> what are oyu measuring there ?
[10:56] <ogra_> RES ?
[10:56] <popey> using a random python script i found online
[10:57] <ogra_> lol
[10:57] <popey> https://raw.github.com/pixelb/ps_mem/master/ps_mem.py
[10:57] <ogra_> so it randomly generates numbers it spits out ?
[10:57] <popey> heh
[10:57] <popey> it generates nice sane output
[10:58]  * ogra_ would just have used top 
[10:58] <popey> sure, this is pretty tho ☻
[10:58] <popey> pretty is a feature
[11:01] <bzoltan> sil2100: didrocks, Mirv: the silo15 is good to go
[11:03] <sil2100> bzoltan: \o/
[11:03] <sil2100> bzoltan: taking care of that one then
[11:05] <bzoltan> sil2100:  thank you
[11:05] <sil2100> didrocks, t1mp: so, I ran gallery-app with Leo's changes and got 12 failures
[11:05] <mhr3_> didrocks, there's a loose bot on the run! it's automerging approved branch for gsettings-qt!
[11:05] <mhr3_> didrocks, kill it now!
[11:06] <sil2100> mhr3_: uh oh!
[11:06] <didrocks> sil2100: can you try reverting sdk then and see?
[11:06] <sil2100> mhr3_: for what project is that?
[11:06] <didrocks> mhr3_: this is for cihelp ^
[11:06] <sil2100> mhr3_: I guess we need to disable it from cu2d
[11:06] <Mirv> mhr3_: nice approach! :D
[11:07] <mhr3_> didrocks, indeed, help the poor projects, ci people!
[11:08] <mhr3_> sil2100, try reading the last word ;)
[11:08] <mhr3_> in that sentence
[11:09] <psivaa> mhr3_: let me see, would help if you have a jenkins link by any chance
[11:09] <mhr3_> i do not
[11:11] <sil2100> mhr3_: hah, right ;)
[11:11] <didrocks> psivaa: nothing in cupstream2distro-config from what I see
[11:12] <didrocks> sil2100: you are trying the sdk revert first?
[11:12] <sil2100> didrocks: yes, just reverted it, running the tests again now
[11:12] <didrocks> sil2100: otherwise, maybe check with psivaa if we run the python2 or 3 flavors and if anything changed
[11:12]  * sil2100 does a few things at once
[11:12] <didrocks> ok
[11:18] <Mirv> sil2100: it's already disabled from cu2d (like everything else for that matter), it's the automergers that may be still lurking
[11:18] <Mirv> for some of the rarer updated projects
[11:20] <didrocks> but automerger is using cu2d-config and I don't find it there
[11:20] <sil2100> Was it redeployed?
[11:21] <psivaa> didrocks: would https://code.launchpad.net/~ken-vandine/cupstream2distro-config/gsettings-qt/+merge/171634 have anything to do with mhr3_ 's issue?
[11:22] <sil2100> psivaa: that's very very old, before CITrain was invented
[11:22] <sil2100> gsettings-qt was in cu2d, but Mirv says it got disabled
[11:22] <didrocks> psivaa: if you look at the config file
[11:22] <didrocks> it's set to     gsettings-qt:
[11:22] <didrocks>       daily_release: False
[11:22] <sil2100> I would say it wasn't redeployed with the new config
[11:22] <didrocks>       autolanding_template: False
[11:22] <didrocks>       use_stack_ppa: False
[11:22] <didrocks> which suppose to disabling upstream mergerd
[11:22] <didrocks> sil2100: the deployement is automated
[11:22] <didrocks> for upstream merger
[11:22] <sil2100> didrocks: ah, ok
[11:24] <sil2100> didrocks, bzoltan, t1mp: sadly, reverting the SDK helped :<
[11:24] <didrocks> sil2100: seems we have to back it out then?
[11:24] <sil2100> So the new SDK resulted in the broken tests
[11:25] <sil2100> Yeah, it would seem so - I'm re running the gallery-app tests again to make sure
[11:25] <didrocks> bzoltan: t1mp: we want to kick an image soon, I propose we revert your fix only in distro and then you can quitely work on it
[11:25] <didrocks> sil2100: yeah, please double run
[11:26] <kgunn> sil2100: just curious...silo7 package migration seems slow...am i just being impatient ? ...ijust in case there's a problem somewhere
[11:27] <sil2100> kgunn: ah, yeah... let's maybe ping the -release team about that, since they have to push it from the UNAPPROVED queue
[11:27] <t1mp> sil2100: did you try elopio's patch?
[11:27] <t1mp> ^of the gallery tests
[11:27] <sil2100> Usually I don't want to do that, since they're a bit unhappy we're poking about that, but this time it's a bit blocking
[11:27] <sil2100> t1mp: yes, it didn't help
[11:28] <sil2100> t1mp: got 12 failures with it
[11:30] <psivaa> didrocks: yea, i see. there is this http://s-jenkins:8080/job/gsettings-qt-autolanding/18/. looking at how to disable that
[11:31] <didrocks> psivaa: thanks!
[11:35] <didrocks> sil2100: second run results are around?
[11:35] <t1mp> sil2100: only gallery-app tests started failing? or something else also?
[11:35] <t1mp> sil2100: do you have the logs of the failures for me to have a look?
[11:35] <didrocks> t1mp: you have all those on the dashboard
[11:35] <sil2100> didrocks: still running, but I guess it's finishing
[11:35] <didrocks> t1mp: you don't look at it when comparing?
[11:36] <t1mp> didrocks: I do
[11:36] <sil2100> t1mp: these are the same as on the dashboard, I saw all those After 10.0 seconds test on QQuickLoader.loaded failed: True != dbus.Boolean(False, variant_level=1)
[11:36] <didrocks> t1mp: so, just look there :)
[11:37] <t1mp> sil2100:  to which version of UITK did you revert to fix it?
[11:39] <sil2100> t1mp: the previous one, 0.1.46+14.04.20140404-0ubuntu1
[11:39] <sil2100> didrocks: re-run has 0 failures
[11:39] <didrocks> sil2100: ok, reverting
[11:39] <didrocks> t1mp: bzoltan: FYI ^
[11:39] <sil2100> So the sdk revert helped indeed
[11:44] <t1mp> ok
[11:47] <t1mp> sil2100: did you revert only uitk, or also the unity changes that were in that silo?
[11:49] <popey> didrocks: rsalveti bug 1304362 - can someone try and confirm please - might be the cause of some of the issues I had at the weekend with apps being killed by OOM killer..
[11:49] <sil2100> t1mp: I only reverted UITK
[11:49] <popey> bot is MIA so https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1304362
[11:49] <sil2100> hmmm
[11:49] <t1mp> sil2100: it was landed together with https://code.launchpad.net/~aacid/unity8/new_tabbar/+merge/210453
[11:49] <sil2100> didrocks: ^
[11:50] <didrocks> sil2100: t1mp: urgh, what's the consequence?
[11:50] <sil2100> didrocks: well, we can revert unity8 as well
[11:50] <t1mp> I'm trying to figure out if unity with those changes and without the new uitk will break
[11:50] <sil2100> didrocks: since it's only that change that's in the latest version
[11:50] <sil2100> https://launchpad.net/ubuntu/+source/unity8/7.85+14.04.20140404-0ubuntu1
[11:51] <didrocks> sil2100: so reverting unity8 as well?
[11:51] <didrocks> can do
[11:51] <sil2100> didrocks: this is latest, so just revert this unity8 as well and we're safe
[11:51] <didrocks> Saviq: FYI, reverting one change ^
[11:51] <sil2100> Saviq: ^
[11:51] <didrocks> good :)
[11:51] <sil2100> Right ;)
[11:51] <sil2100> Phew
[11:51]  * sil2100 dodged a bullet
[11:51] <sil2100> t1mp: thanks for pointing it out!
[11:52] <psivaa> mhr3_: didrocks: i see lp:gsettings-qt being in the whitelist for autolanding. I think removing that will fix it. i'll double check with fginther before removing it.
[11:52] <didrocks> psivaa: thanks!
[11:52] <Mirv> psivaa: that sounds like correct one. is there any URL for reference?
[11:52] <didrocks> t1mp: thanks man :)
[11:53] <Mirv> I always tend to forget (if I've ever known) where the automerger "lives"
[11:53] <psivaa> Mirv: http://mayura:8080/job/trigger-autolanding-whitelist/
[11:54] <Mirv> psivaa: ok, so no I did not know :) seems mayura = s-jenkins
[11:54] <didrocks> sil2100: t1mp: unity8 revert uploaded
[11:55] <sil2100> didrocks: thank you!
[11:55] <didrocks> sil2100: thanks for testing!
[11:56] <psivaa> Mirv: yea, mayura is the name of the host and s-jenkins is the name for the jenkins instance. :)
[12:22] <sil2100> didrocks: can you look at this packaging change? It's o unblock the package from -proposed, as currently it's non-migratable: https://ci-train.ubuntu.com/job/landing-016-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.0.1+14.04.20140408-0ubuntu1.diff
[12:22] <didrocks> sil2100: hum, we do want to handle it that way?
[12:22] <Saviq> t1mp, you broke unity8 did ya?
[12:22] <didrocks> this is what you discussed with cjwatson, right?
[12:23] <sil2100> didrocks: yes
[12:23] <didrocks> Saviq: no, they did broke gallery, so we needed to revert sdk, which in turns, asked to revert the unity8 commit
[12:23] <Saviq> ok yeah
[12:23] <Saviq> didrocks, +1
[12:23] <sil2100> Saviq: ;)
[12:23] <didrocks> Saviq: if you have a landing for unity8 to do and this isn't fixed, please add a MP to revert in your trunk this commit
[12:23] <Saviq> didrocks, ok will do
[12:23] <didrocks> sil2100: ok then, +1 :)
[12:23] <didrocks> thanks Saviq
[12:26] <sil2100> didrocks: thanks :)
[12:27] <sil2100> didrocks: do you know if you pre-NEWed sync-monitor ?
[12:27] <didrocks> sil2100: I didn't
[12:28] <sil2100> didrocks: there's a landing ready-to-publish with sync-montior, which is a NEW package I think - the comments doesn't mention anything about it being reviewed by anyone
[12:29] <sil2100> Maybe I'll look into the packaging and then ask you to take a look for a preNEW
[12:29] <t1mp> Saviq: no I broke gallery-app
[12:30] <t1mp> Saviq: I'm gonna see what's wrong in gallery-app. Those tests failed for me already on a clean image, so I didn't notice new breakage with the MR
[12:30] <didrocks> sil2100: ok
[12:31] <t1mp> sil2100: thanks for figuring out where stuff broke
[12:31] <seb128> dbarth, you have a silo that is built, can you get it moving (e.g test->publish)? (the "drop libunity-webapps from bamf")
[12:32] <seb128> dbarth, one for webbrowser as well
[12:33] <seb128> sil2100, hum, silo 003 and 008 both have webbrowser, how does that work?
[12:33] <t1mp> didrocks: we have a UITK landing for UITK in silo (that doesn't depend on the now-reverted change). So we need to include an additional MR there that reverts the previous landing?
[12:34] <didrocks> t1mp: yeah, the MR with the revert + eventually the changlog
[12:34] <didrocks> changelog*
[12:35] <sil2100> seb128: so, I see robru set the 'ignore conflicts' flag for one of the silos
[12:35] <didrocks> t1mp: if you don't include the changelog, while building, you need to check "force rebuild" as it will yell
[12:35] <sil2100> seb128: and enabled two silos having the same component...
[12:35] <mhr3_> psivaa, cool, thanks
[12:35] <sil2100> seb128: too bad he didn't indicate that in the description ;/
[12:36] <sil2100> seb128: I'll update the information
[12:36] <seb128> sil2100, thanks, I get the second silo should be cleaned and the mp included in the first one?
[12:36] <sil2100> seb128: normally, yes, but I see it's from 2 different landers, so they need to coordinate it somehow
[12:37] <sil2100> seb128: we usually don't allow ignoring-conflicts, just in very important cases
[12:37] <seb128> sil2100, can you maybe ping them on a channel where they are on?
[12:37] <sil2100> Not sure what was the reason here ;/
[12:37] <t1mp> bzoltan: ^ we need to revert the previous landing in the current silo
[12:37] <sil2100> seb128: sure
[12:37] <didrocks> rather we need one silo to finish, m&c
[12:37] <seb128> sil2100, thanks
[12:37] <seb128> didrocks, or that
[12:37] <didrocks> the other just ned to rebuild the right component
[12:37] <didrocks> need*
[12:37] <didrocks> (and only that one)
[12:37] <seb128> they both only have 1 component
[12:37] <bzoltan> t1mp:  what should I do ... I mean in practice
[12:37] <seb128> webbrowser
[12:38] <t1mp> bzoltan: wait 5 minutes and then add an MR that I give you to revert the previous MR
[12:38] <didrocks> yeah, so one just need to rebuild once the first one m&c
[12:38] <didrocks> t1mp: bzoltan: and reconfigure after adding to the spreadsheet of course :)
[12:38]  * didrocks goes for a run
[12:38] <dbarth> seb128: i'm blocked on testing for all of them
[12:39] <seb128> dbarth, "blocked on testing"? just test and land :p
[12:39] <seb128> didrocks, enjoy!
[12:39] <didrocks> thanks seb128!
[12:40] <dbarth> seb128: i'm trying to make room now
[12:40] <seb128> dbarth, thanks, we are out of silos which means others can't land their work until some of you guys clean out things you queued
[12:41] <bzoltan> t1mp: sil2100: line number 63
[12:42] <sil2100> bzoltan: so, you want to revert it in trunk as well for now?
[12:42] <bzoltan> sil2100: t1mp: yes
[12:42] <didrocks> bzoltan: you should mix that with other changes to land
[12:42] <didrocks> bzoltan: no point of having one landing just for that (it will refuse by default anyway)
[12:43] <sil2100> bzoltan: could you include that in the line 59?
[12:43] <didrocks> t1mp: don't remove the changelog
[12:43] <sil2100> bzoltan: since we anyway can't release that right now anyway
[12:43] <didrocks> t1mp: please, just add the revert one
[12:43] <didrocks> bzoltan:  ^
[12:43] <t1mp> didrocks: oh I understood that I should revert the changelog
[12:43] <sil2100> bzoltan: by 'release that one now' I mean, can't release it without the revert or a real fix for the issue ;)
[12:44] <didrocks> t1mp: no, either don't touch it or add my revert changelog
[12:44] <sil2100> bzoltan: so if you could include that in the landing, rebuild then it would be sweet
[12:44] <bzoltan> sil2100: didrocks: t1mp: OK
[12:44] <sil2100> bzoltan: thanks!
[12:44] <didrocks> bzoltan: add that in the landing, reconfigure and then rebuild
[12:44] <didrocks> sil2100: ^
[12:44] <didrocks> don't forget to reconfigure :p
[12:44] <sil2100> Right ;D
[12:47] <t1mp> didrocks: sorry I don't understand what you mean with your revert changelog.
[12:47] <t1mp> didrocks: I undid he changelog revert
[12:47] <sil2100> seb128: I'll assign a silo for you now since one will be released in a moment anyway
[12:47] <seb128> sil2100, thanks
[13:04] <seb128> sil2100, still working on assigning that silo?
[13:06] <mhr3_> Mirv, sil2100, so what's up with 53, i want that silo
[13:07] <seb128> mhr3_, find somebody to clean a silo for you
[13:07] <sil2100> seb128: argh, sorry, a race happened and it didn't get assigned
[13:07] <seb128> like bfiller has some for days
[13:07] <sil2100> Wait, retrying
[13:07] <kgunn> landing packages from silo007.....anyone ?
[13:07] <bfiller> sil2100: we're ready to release silo 9
[13:08] <sil2100> kgunn: yeah, it's in -proposed now
[13:08] <sil2100> kgunn: I poked the release team and cjwatson moved it to proposed, now it needs to migrate
[13:08] <bfiller> seb128: sorry seb, we've been testing it and finding issues
[13:08] <kgunn> sil2100: awesome thanks you
[13:08] <seb128> sil2100, kgunn gave you an ack for publishing one ;-)
[13:08] <sil2100> bfiller: I know, saw that, but we need to do a preNEW of the NEW package first
[13:09] <sil2100> bfiller: I'm doing a packaging review right now, already talked to didrocks about that ^
[13:09] <bfiller> sil2100: what does that mean?
[13:09] <seb128> bfiller, no worry, sorry for pointing you, I'm just looking at the list since yesterday, it's pretty packed and blocked us to get slots for landing our stuff, not easy to find candidates to clear
[13:09] <sil2100> bfiller: there is a new package in the MRs, one that's still not in the archive
[13:09] <bfiller> sil2100: oh ok
[13:09] <bfiller> seb128: no worries
[13:10] <sil2100> bfiller: this one needs to be approved by an archive admin, so Didier will do that once he's back and I have the packaging review done
[13:10] <bfiller> sil2100: thanks sil
[13:18] <sil2100> bfiller: ok, so the packaging needs some work sadly
[13:19] <sil2100> bfiller: I have some changes already, will push a branch and add it to the MR list
[13:19] <sil2100> We'll have to rebuild sync-monitor then
[13:19] <bfiller> sil2100: np, thanks for checking the packaging.
[13:31] <sil2100> kgunn: m&c'ing silo 7! :)
[13:31] <sil2100> seb128: soon another free silo \o/
[13:31] <seb128> sil2100, \o/
[13:32] <sil2100> mhr3_: I'll assign you a silo soon, since your request is a bit older than seb128's
[13:32] <seb128> sil2100, that's fair enough ;-)
[13:32] <sil2100> seb128: so you'll still have to wait a little bit... although, I'll try doing something
[13:33] <seb128> sil2100, landing 015 is red, maybe reassign to somebody else until they sort out their issues?
[13:40] <dbarth> sil2100: o/ silo 011 ready to publish; just be aware that it drops a dependency (considered harmfull) between bamf and libunitywebapps, so that may influence image tools
[13:40] <dbarth> sil2100: but the runtime and apt-get operations were fine during our testing
[13:41] <sil2100> dbarth: ok, I'll deal with that after lunch
[13:41] <sil2100> bzoltan: m&c silo 16
[13:41] <sil2100> seb128: I'll assign you that silo now ;)
[13:41] <seb128> sil2100, thanks!
[13:42] <sil2100> And off to lunch I go o/
[13:44] <seb128> sil2100, enjoy
[13:45] <bzoltan> sil2100:  what does that mean? https://ci-train.ubuntu.com/job/landing-015-1-build/26/console
[13:47] <seb128> cjwatson, stgraber: you are working on testing the click update which is in silo 006? (sorry for naging, trying to find potential candidate to land stuff so we can get silo backs for things waiting)
[13:47] <renato> sil2100, hi
[13:55] <rsalveti> popey: that's a huge mem leak for a service
[13:55] <fginther> psivaa, I disabled the autolanding job for gsettings-qt. It was just an oversight that it was still there.
[13:56] <rsalveti> ogra_: can't we add something in our dashboard that could look for 'send sigkill to' ?
[13:56] <psivaa> fginther: ack, thanks
[13:56] <rsalveti> to know if the low memory killer killed someone
[13:57] <rsalveti> as we don't get any crash file when that happens
[13:57] <ogra_> rsalveti, ask CI ... psivaa, doanac, plars ^^^^
[13:57] <rsalveti> basically just looking for 'send sigkill to' in dmesg, after the test is completed
[13:57] <ogra_> rather in syslog
[13:58] <ogra_> thats not a ringbuffer :)
[13:58] <rsalveti> yeah
[13:59] <psivaa> rsalveti: curious after which test?
[14:00] <rsalveti> psivaa: all of them
[14:00] <rsalveti> just an additional sanity check after running a test
[14:03] <cjwatson> seb128: Yeah, I'm working on it, at this point I'm waiting for feedback from kenvandine on a content-hub problem it exposes
[14:04] <seb128> cjwatson, ok, thanks
[14:04] <kenvandine> cjwatson, i saw your email, i'll look at it in a few
[14:06] <cjwatson> yup, ta
[14:10] <didrocks> t1mp: see latest upload
[14:10] <didrocks> t1mp: there is a new changelog entry
[14:10] <didrocks> t1mp: you need to stich that in your request
[14:10] <didrocks> bzoltan: it means that you haven't done that
[14:10] <didrocks> bzoltan: as told: 2014-04-08 13:28:17,346 WARNING A version (0.1.46+14.04.20140404.1.is.0.1.46+14.04.20140404-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 0.1.46+14.04.20140404.1-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
[14:11] <didrocks> so put the 0.1.46+14.04.20140404.1.is.0.1.46+14.04.20140404-0ubuntu1 changelog as part of your revert MP
[14:13] <t1mp> didrocks: it seems like I am slow today (or in general), but I don't get it yet. What is the upload I should look at? A commit on UITK trunk?
[14:13] <t1mp> and what do I do exactly with the change log? normally that happens automatically for me
[14:14] <didrocks> t1mp: hum, you don't know how to see what changed in the distro?
[14:14] <didrocks> t1mp: you can see it in launchpad: https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit
[14:14] <didrocks> if you expand the latest version in trusty
[14:14] <didrocks> you can find a diff
[14:14] <didrocks> t1mp: https://launchpadlibrarian.net/172227701/ubuntu-ui-toolkit_0.1.46%2B14.04.20140404.1-0ubuntu1_0.1.46%2B14.04.20140404.1.is.0.1.46%2B14.04.20140404-0ubuntu1.diff.gz
[14:15] <didrocks> t1mp: you need to take the change in debian/changelog
[14:15] <didrocks> t1mp: and put that into your revert MP
[14:15] <t1mp> didrocks: no, I don't. So far I was always working on the https://code.launchpad.net/ubuntu-ui-toolkit project and somehow magically it ended up in the distro
[14:15] <t1mp> let me see
[14:15] <didrocks> t1mp: we clearly have too much disconnection on how things work downstream from our internal upstream
[14:16] <popey> rsalveti: yeah, 4 hours it's gone from 21MiB to 134MiB..
[14:16] <didrocks> t1mp: so upstreams complain, but it's somewhat nice you could have landed so many things without even knowing how it goes to distro :)
[14:19] <t1mp> didrocks: so if I understand it well, I should add this to the changelog: http://bazaar.launchpad.net/~tpeeters/ubuntu-ui-toolkit/revert-tabsModelIndex/revision/1002
[14:19] <t1mp> didrocks: I am not at all complaining when stuff works automatically for me :)
[14:19] <t1mp> just some times, like now, it means I don't know how everything works
[14:19] <didrocks> t1mp: "this" being the entry part of the diff.gz I pointed at?
[14:19] <popey> rsalveti: can you confirm?
[14:19] <didrocks> (the one with my name)
[14:20] <rsalveti> popey: I'll try to reproduce and confirm
[14:20] <popey> thanks
[14:20] <dbarth> o/ sil2100: you can flush silo 003, we're releasing it for other teams
[14:20] <sil2100> dbarth: ok, sure!
[14:21] <dbarth> now i can't go saying "all you silos are belong to us", but that sounded like it a few hours ago
[14:23] <t1mp> didrocks: yes, http://bazaar.launchpad.net/~tpeeters/ubuntu-ui-toolkit/revert-tabsModelIndex/revision/1003 (I pasted the wrong link before) is the entry part of the diff.gz you pointed at
[14:28] <didrocks> t1mp: hum, the formatting is wrong
[14:28] <didrocks> t1mp: really apply the patch in the diff.gz
[14:28] <psivaa> rsalveti: reported bug 1304461 for your req. would help if you could add more background/ info as appt.
[14:28] <didrocks> t1mp: not what launchpad is showing to you
[14:28] <rsalveti> psivaa: sure, thanks
[14:32] <t1mp> didrocks: ok, I did that now
[14:33] <t1mp> didrocks: http://bazaar.launchpad.net/~tpeeters/ubuntu-ui-toolkit/revert-tabsModelIndex/revision/1004
[14:34] <didrocks> t1mp: looking good, you can hit "rebuild" now in the silo :)
[14:34] <cwayne> cjohnston, hi, im having some issues with the savilerow-trusty job again :/
[14:35] <cwayne> i think it's because bzr is set to ignore .so files (which we need for our preinstalled custom scopes)
[14:35] <cjohnston> cwayne: itll be a few
[14:35] <t1mp> bzoltan: ^ you can hit rebuild now in the silo
[14:36] <t1mp> didrocks: okay, let's see how it goes. thanks for the patience :)
[14:36] <cwayne> cjohnston, ack
[14:38] <t1mp> didrocks: are there online docs explaining this part of the landing in distro?
[14:43] <didrocks> t1mp: the daily release one does
[14:44] <didrocks> t1mp: https://wiki.ubuntu.com/DailyRelease
[14:47] <t1mp> didrocks: thanks, I'll read it.
[14:47] <didrocks>  t1mp: yw, most of things here (apart from the release cadence) still applies
[14:55] <cjwatson> seb128: ok, resolved my one doubt, publishing 006 now
[14:56] <seb128> cjwatson, great, thanks!
[14:56] <sil2100> renato, didrocks: https://code.launchpad.net/~sil2100/sync-monitor/packaging_review/+merge/214781
[14:57] <sil2100> bfiller: ^
[14:57] <sil2100> didrocks: these were the issues I saw from the first glimpse
[14:58] <renato> sil2100, could you request the MR with the inital-release branch?
[14:58] <renato> sil2100, or we should ignore the other MR?
[15:00] <sil2100> renato: we'll just attach this MR to the end of the list
[15:00] <sil2100> This way both your changelog and mine will be there
[15:01] <renato> sil2100, I have changed "debian/copyright" probably we will get a conflict
[15:02] <sil2100> renato: my branch is based on your initial-release branch
[15:02] <sil2100> So it should all be ok
[15:02] <renato> sil2100, I changed that earlier today,
[15:03] <renato> sil2100, could you at least add the initial-relase as pre-requisite branch?
[15:03] <sil2100> renato: uh, it's not wise to modify this branch when the lander already set the landing to 'ready for release'
[15:03] <cjohnston> cwayne: what's up?
[15:04] <sil2100> renato: once it's set up in a landing, it shouldn't be moved - since you need to rebuild it in the silo with every modification
[15:04] <sil2100> I'll merge in your latest changes
[15:04] <renato> sil2100, bfiller asked me to fix the package otherwise this was not going to land
[15:04] <cwayne> cjohnston, so the last merge to lp:savilerow was a bunch of new compiled .so's, and it looks like its not getting updated in jenkins
[15:04] <sil2100> renato: I told you on PM that I have a branch for that already
[15:05] <renato> I did not get the message
[15:05] <sil2100> renato: you probably got disconnected then...
[15:05] <sil2100> renato: bfiller was also aware of that, as I mentioned it on this channel
[15:05] <sil2100> When pointing out that there is an issue
[15:06] <sil2100> Nevermind that though, let me try to update my branch ;)
[15:06] <bfiller> sil2100, renato: I let renato know there were packaing issues and to talk to you. if you have a branch already great, lets us it
[15:06] <renato> what he told me is to check with you which files I should fix before land this
[15:07] <sil2100> renato: my branch *should* be now mergable with yours ;)
[15:07] <sil2100> We anyway need to have an archive admin ACK it, like didrocks
[15:08] <cjohnston> cwayne: link please?
[15:08] <renato> sil2100, ok thanks
[15:08] <sil2100> renato: I'll add it to the landing anyway right now
[15:10] <cjohnston> cwayne: job 32 passed..
[15:12] <cwayne> cjohnston, right it's passing, but it's not actually pulling the latest .so's
[15:21] <sil2100> renato: oh, and one more thing - in my branch I changed the install path to /usr/lib/<arch>/sync-monitor/ for the binaries, since /usr/libexec is not valid for Ubuntu
[15:21] <sil2100> At least not recommended ;)
[15:21] <renato> sil2100, yes I saw that
[15:22] <sil2100> renato: hope you won't have to change any paths in other projects
[15:24] <renato> sil2100, you will need to update "com.canonical.SyncMonitor.service.in" with the new patch
[15:31] <cjohnston> cwayne: can you check it again? I ran a new job
[15:32] <cwayne> cjohnston, did you change anything or just build? cus i've done that twice already
[15:32] <cjohnston> cwayne: wiped the workspace
[15:32] <cjohnston> cwayne: it appears as though after the files are being changed to root they aren't being changed back so bzr can't update them next time
[15:33] <cwayne> ah, let me check it out then
[15:37] <cwayne> cjohnston, that one seems to work
[15:37] <cjohnston> cool
[15:39] <cwayne> cjohnston, so is it possible to just clear out the workspace each run?
[15:39] <cjohnston> cwayne: I'm investigating
[15:45] <cjohnston> cwayne: fginther thinks that future jobs will be ok based on changes he made
[15:46] <mandel> fginther, example of a tests blocking until a signal is emitted on armhf that never is https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+build/5889264
[15:46] <cwayne> cjohnston, but those changes existed for the last build
[15:46] <thostr_> didrocks: the scopes privacy flag patch is in silo 18, under testing. so, WIP if you summarize for the daily landing mail
[15:46] <fginther> cwayne, but the workspace was in a bad state from run 28
[15:46] <mandel> fginther, while it does work in the other archs and on a nexus phone
[15:46] <didrocks> thostr_: thanks!
[15:46] <cwayne> ah
[15:46] <cwayne> so now that there's been a clean one we should be good
[15:46] <fginther> cwayne, I didn't recognize this until you mentioned the old files
[15:47] <fginther> cwayne, yep, it should be good now. there
[15:48] <fginther> there's a cleanup step that puts the files back in a good state
[15:49] <fginther> mandel, it's also stuck on powerpc
[15:50] <mandel> fginther, yes, while in adm64 and i386 works
[15:51] <mandel> fginther, same code, same flags, same tests.. only diff is the arch
[15:52] <mandel> fginther, and I must say that in a mako tests pass with no problems
[15:52] <fginther> mandel, This is strange, but not the first time I've seen something work on x86, but fail on some other arch
[15:53] <fginther> mandel, this smells of a broken API, but that doesn't sync with it working on the mako
[15:54] <mandel> fginther, the fact that it could go nuts in an diff arch is ok (in a sense) but that in works on mako is what is driving me nuts
[15:54] <mandel> fginther, I have a strong feeling that is related with the new signals connection style added in qt 5 with cpp11
[15:54] <fginther> mandel, how are you testing on the mako? are you doing a 'make check'?
[15:54] <mandel> fginther, yes, just a simple make test (not check)
[15:55] <mandel> fginther, nothing else
[15:58] <didrocks> ogra_: kicking an image, agreed?
[15:58] <ogra_> yeah, go ahead
[15:58]  * didrocks *clicks*
[15:58] <fginther> mandel, I would say your feeling is right.  Any chance that the qt libs and dependencies used on you rmako are the same as what is being used in the ppa build?
[16:02] <mandel> fginther, from https://ci-train.ubuntu.com/job/landing-019-1-build/9/console libqt5core5a:amd64 (5.2.1+dfsg-1ubuntu11) while on my device I have 5.2.1+dfsg-1ubuntu11
[16:02] <mandel> fginther, so they seem to be the exact same
[16:02] <didrocks> cyphermox: Mirv: robru: coming?
[16:04] <seb128> sil2100, silo 007 has issues, I marked it "ready: no", can you reset it and give it back to me for l64? ;-)
[16:05] <imgbot> [16:06] <seb128> cyphermox, Mirv, robru: ^
[16:06] <robru> seb128, ok
[16:07] <seb128> thanks
[16:07] <fginther> mandel, hmmm... I'm all out of ideas here.
[16:08] <mandel> fginther, I'm going to do a dirty trick (more work on my side) where I try to use the new connection, get the result, if the signals is not connected use the old style and log everything
[16:08] <mandel> fginther, that is what fixed the issue in the unity-click-scope
[16:09] <robru> seb128, ok your new silo is #3
[16:09] <mandel> fginther, but I'm more interested, not only in fixing my project, but to find a reason so that other can know about it
[16:09] <seb128> robru, thanks
[16:09] <robru> seb128, youre welcome
[16:12] <mandel> fginther, AFAIK the following can be used as a workaround => http://paste.ubuntu.com/7222220/
[16:15] <fginther> mandel, thanks
[16:15] <mandel> fginther, if that does fix the issue as I expect we/I should send an email to see if brighter minds can take a look :)
[16:16] <fginther> mandel, I wonder if the sdk team has a take on this
[16:17] <fginther> mandel, but yes, broadcasting to ubuntu-phone would be a good move
[16:17] <mandel> fginther, in a sense, if the signal connection is not reliable and now one is checking the result of QObject::connect we might (might with a very low possibility) point to a possible reason of why some tests based on signals are not working
[16:17] <mandel> fginther, I don't know the nature of the tests that are flacky in the apps, but would be nice to take a lool
[16:17] <mandel> look*
[16:19] <fginther> mandel, qa might be able to connect some dots if that is the case.
[16:19] <fginther> elopio, is anyone on the QA team working with the SDK team or with QT itself?
[16:20] <mandel> fginther, but AFAIK the use real phones for those.. well, I'll walk the dog and will do the test/changes
[16:23] <elopio> fginther: I'm working with the SDK team.
[16:23] <elopio> not going deep into qt yet, though.
[16:24] <seb128> hum
[16:24] <seb128> something seems wrong on the CI train table
[16:24] <seb128> the main table doesn't have correct/detailled status
[16:24] <seb128> eg l62 or 64
[16:25] <seb128> the status is "in silo landing-nnn" but no "building"
[16:25] <fginther> elopio, ok. mandel has been debugging a problem with qt signals (in which they only work correctly on x86) and the thought was that maybe this is causing problems in other projects
[16:26] <robru> seb128, there was a hiccup with the spreadsheet. should be fine now. it doesn't hurt the builds if the spreadsheet doesn't have the right status
[16:26] <robru> seb128, or, it should correct itself shortly
[16:26] <fginther> elopio, I mainly just want to raise awareness that there could be a problem
[16:26] <seb128> robru, yeah, I'm not paying much attention to the status, they are correct in the individual tabs
[16:26] <fginther> a problem in the API or something lower level
[16:26] <seb128> I was mostly pointing it out as a fyi
[16:27] <robru> seb128, yeah, I saw for a few minutes it was totally unresponsive, so now it's back with stale status, that's an improvement ;-)
[16:28] <Mirv> sorry, I missed my alarm
[16:29] <Mirv> it seems the meeting is done. sorry didrocks & co :(
[16:29] <didrocks> Mirv: yeah, done
[16:29] <didrocks> Mirv: no worry, read the emails
[16:29]  * Mirv reads
[16:33] <Mirv> there's no shortage of blockers to look at
[16:35] <bfiller> sil2100: is silo9 ready to retest with your changes?
[16:41] <mhr3_> sil2100, 018 rdy to land
[17:02] <elopio> fginther, mandel: sounds important to discuss about it with bzoltan1, to make sure that it's not affecting the toolkit.
[17:02] <elopio> mandel: do you have a test that exposes the problem?
[17:08] <bregma> sil2100, robru, cyphermox whoever is in the zone at this point in time, I'm looking for a silo assignment for line 65 please and thank you
[17:08] <robru> bregma, sure
[17:09] <robru> bregma, ok, you got silo 6
[17:11] <mandel> elopio, I do have tests that have the problem but I'll be doing a small app to show the issue
[17:13] <mhr3_> robru, 018 rdy to publish
[17:14] <robru> mhr3_, ah sorry. just saw your previous message now.
[17:14] <bzoltan1> elopio: what is the topic?
[17:14] <robru> mhr3_, just need a core dev ack. cyphermox? https://ci-train.ubuntu.com/job/landing-018-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-shell_0.4.0+14.04.20140408-0ubuntu1.diff
[17:14] <elopio> bzoltan1: mandel found that some signals work only on x86.
[17:14] <cyphermox> hold on
[17:14] <bzoltan1> sil2100: are you still here?
[17:15] <mandel> bzoltan1, well, is a little more complicated, it appears to be that the new connection style of qt signals on arm is not reliable (at least on the tests because I have not manage to see problems in production code)
[17:16] <cyphermox> robru: ack
[17:16] <cjwatson> It doesn't hugely surprise me that it isn't reliable, given that it depends on a sketchy C++ feature
[17:16] <mandel> bzoltan1, I have some tests that expect some signals to be raised, initially I used QTRY_COMPARE(QSignalSpy::count) but it fails on arm and other archs
[17:16] <bzoltan1> mandel:  would you please fire a bug report with all the details you know and assign it to me?
[17:17] <bzoltan1> mandel:  I am close to EOD... so can not jump on it right away
[17:17] <mandel> bzoltan1, sure, I'll also add a small test case that exposes it
[17:17] <mandel> bzoltan1, no problem
[17:17] <cjwatson> specifically http://yosefk.com/c++fqa/function.html :-)
[17:17] <robru> cyphermox, thanks
[17:18] <mandel> cjwatson, if that is the casel, we should tell people not to use the new style, although is sooo nice to be able to have the compiler tell me I'm stupid when a signal or slot does not exist
[17:18] <cjwatson> Or indeed http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible
[17:18] <elopio> thanks mandel.
[17:18] <robru> mhr3_, ok, published
[17:19] <bregma> that hack relies on undefined behaviour and the nanoseconds it saves is a premature optimization that does not belong in UI code
[17:20] <imgbot> [17:20] <imgbot> [17:20] <mandel> cjwatson, the fact that it may not work in other archs is something we should mention, specially when we are targeting armhf for the phone
[17:20] <mandel> bzoltan1, what project should I add the bug to?
[17:21] <cjwatson> mandel: I believe we've previously seen that PMFs don't work properly on ppc64el (er, I think, maybe it was powerpc or maybe both), although I hadn't been regarding that as anything to panic about particularly
[17:21] <cjwatson> mandel: where's the code in question in ubuntu-download-manager?
[17:22] <cjwatson> bregma: I can see why people want it for type-safety or at least existence-safety rather than optimisation
[17:22] <mandel> cjwatson, well, I cannot point to an specific line just yet, I know that my tests wait for the signal to me raised and never do. Atm I'm adding logs to try to be more specific
[17:23] <cjwatson> https://launchpadlibrarian.net/172235576/ubuntu-download-manager_0.3%2B14.04.20140407-0ubuntu1_0.3%2B14.04.20140408-0ubuntu1.diff.gz seems to be using the old style "SIGNAL()" everywhere?
[17:23] <bzoltan1> mandel: lp:ubuntu-ui-toolkit
[17:24] <mandel> bzoltan1, sure? 'cause I don't think it is related to the ui toolkit but with qt
[17:25] <mandel> cjwatson, in the tests I do, not in the code being tested (and is because QSignalSpy and QTimer do not accept function pointers)
[17:25] <cjwatson> mandel: I was hoping for a reference because I couldn't see it
[17:26] <cjwatson> Even the tests seem to be using SIGNAL() everywhere
[17:26] <mandel> cjwatson, I'm trying to narrow things down
[17:27] <mandel> cjwatson, for example => http://bazaar.launchpad.net/~mandel/ubuntu-download-manager/set-download-dir/view/head:/src/common/priv/ubuntu/transfers/queue.cpp#L46
[17:28] <mandel> cjwatson, I need to narrow down what signals are the ones that are not emitted
[17:28] <mandel> cjwatson, unity-scope-click also has a similar issue where they use the old connection syntax due to this (grep flaky)
[17:30] <mandel> cjwatson, if you look at their code the check the result of QObject::connect to test that the connection was successful, I'll be doing the same
[17:33] <cjwatson> mandel: Given that you're using the old syntax almost everywhere else, avoiding the utter terror entirely might be a plan ...
[17:34] <cjwatson> I wonder under what circumstances QObject::connect(..., PMF) only gives you warnings at run-time rather than compile-time diagnostics
[17:35] <mandel> cjwatson, yes, atm I'm not worried about udm, is no problem, I'm worried about other projects usign this or possible bugs due to this
[17:35] <seb128> cyphermox, robru: who can upload to landing ppas?
[17:35] <robru> seb128, anybody in the team that owns them? I can.
[17:37] <cyphermox> seb128: yeah, we can
[17:38] <seb128> cyphermox, robru: can you upload lp:~ubuntu-desktop/gnome-screensaver/ubuntu to ppa:ci-train-ppa-service/landing-006
[17:39] <robru> seb128, on it
[17:40] <seb128> thanks
[17:42] <renato> sil2100, ping
[17:43] <robru> seb128, erm, sorry, I'm not super familiar with these packaging-only branches. how do I build an uploadable package from that? (I was expecting a complete project branch and just 'bzr bd -S')
[17:44] <seb128> robru, same, bzr bd -S
[17:44] <seb128> it downloads the tarball from the archive for you, unpack and build
[17:45] <robru> seb128, ah ok, nice
[17:48] <robru> seb128, ok, uploaded. you might need to trigger a watch_only build before citrain realizes what's going on, but don't cancel the existing build job for now
[17:50] <seb128> ok, thanks
[17:50] <seb128> bregma, ^
[17:54] <bzoltan1> mandel:  fire it to us :) i will take care of it
[18:08] <bregma> watch-only build queued
[18:14] <bzoltan1> sil2100:  we got our FFe granted \o/ https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620
[18:16] <boiko> robru: landing-001 tested and ready to go
[18:17] <robru> boiko, thanks
[18:17] <robru> just needs packaging ack from a core dev. cyphermox? https://ci-train.ubuntu.com/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_telephony-service_0.1+14.04.20140407-0ubuntu1.diff
[18:24] <cyphermox> sure
[18:31] <cyphermox> ack
[18:31] <cyphermox> I feel it could get painful though, having history-service and telephony-service interdependent :/
[18:33] <boiko> cyphermox: so, the thing is: class0 sms should not be stored automatically according to GSM, so we just show them, and if the user decides he wants to save, then we manually save that to the history-service
[18:33] <boiko> cyphermox: history-service doesn't have a dependency on telephony-service
[18:33] <boiko> it works on its own as a standard telepathy client
[18:36] <seb128> robru, what you did for the gnome-screensaver upload was not right, why did you change the name/steal credit?
[18:39] <robru> seb128, because I dont' have Marco's private key to sign the upload?
[18:39] <robru> seb128, oops, I forgot to mmove Marco's name up in the changelog, sorry
[18:39] <seb128> robru, that's why the -k<yourkeynumber> has been invented
[18:39] <robru> seb128, well i didn't know about that, sorry
[18:39] <seb128> robru, bzr bd -S -- -k<keyid>
[18:40] <seb128> robru, or at least dch -r (which puts the original name under [ ] at the top of the entry)
[18:40] <robru> seb128, didn't mean to steal credit for the whole thing, it just made sense that my name would be on the *upload* since I uploaded it
[18:40] <seb128> robru, no worry, but those are handy options, note them down for next time ;-)
[18:40] <robru> seb128, ok
[18:41] <seb128> robru, yeah, changing the name is fine, you should have added [ Marco ] in the entry then though (or use dch to do it for you)
[18:41] <robru> seb128, yeah, I forgot, sorry
[18:45] <seb128> robru, no worry, that happens
[18:46] <dbarth> robru: o/ hi
[18:46] <dbarth> robru: can you help me reconfig silo 8? we've merged 2 branches that were not working well together (mardy and alex-abreu)
[18:46] <robru> dbarth, sure
[18:47] <dbarth> robru: and thanks for the bamf webapps branch yesterday, it's landed now
[18:47] <robru> dbarth, hmm, your MPs are targetting wrong branches: https://ci-train.ubuntu.com/job/prepare-silo/126/console you need all MPs to target trunk
[18:48] <dbarth> oh my
[18:48] <robru> dbarth, heh, thank alex! I just silo'd it
[18:49] <dbarth> robru: we're adjusting silo 8 branches; getting back to you in a few minutes
[18:49] <robru> dbarth, sure
[18:52] <sergiusens> robru: cyphermox any way to stop this? https://ci-train.ubuntu.com/job/landing-019-1-build/9/console
[18:53] <robru> sergiusens, want me to cancel the job?
[18:57] <sergiusens> robru: yes, well mandel does
[18:57] <robru> sergiusens, ok, stopped
[18:58] <robru> sergiusens, feel free to rebuild when you have some new commits or whatever
[18:58] <sergiusens> robru: rebuilding requires reconfigure; right?
[18:58] <robru> sergiusens, only if you add new MPs
[18:58] <sergiusens> but I can do that myself
[18:58] <robru> sergiusens, yes, if you add new MPs for the same project, you can reconfigure. if you just add new commits to the same MPs, you only need to rebuild, not reconfigure.
[18:58] <sergiusens> robru: right; if I try to rebuild I always get an error saying it has already been built
[18:59] <robru> sergiusens, there's a 'force rebuild' option for that
[18:59] <sergiusens> robru: yeah, but then I get an ugly 'rebuilt' message in the changelog :-)
[19:00] <robru> sergiusens, hum, then I guess you can reconfigure every time :-P
[19:00] <sergiusens> robru: there's no side effect, right?
[19:01] <robru> sergiusens, nope
[19:01] <robru> sergiusens, just slower having to run two jobs
[19:01] <sergiusens> ack
[19:01] <sergiusens> then I'm good
[19:03] <mhr3_> robru, am i reading this right? unity-scopes-shell got released but gsettings-qt is unapproved?
[19:03] <mhr3_> that means the former will be crashing
[19:03] <dbarth> robru: back with 2 branches with a revenge
[19:03] <dbarth> robru: ie, silo 8 should be reconfigurable now
[19:04] <robru> mhr3_, that's correct. better ask #ubuntu-release to approve gsettings-qt then ;-)
[19:04] <robru> dbarth, success!
[19:05] <dbarth> cool
[19:05] <mhr3_> robru, who's got the approval powers?
[19:06] <cjwatson> mhr3_: hm, this is new public API, no symbols file changes?
[19:06] <mhr3_> cjwatson, i don't think it maintains a symbol file
[19:07] <cjwatson> mhr3_: so how do we maintain proper partial upgrade handling?
[19:07] <mhr3_> cjwatson, beats me, i just patched it, not a maintainer
[19:07] <cjwatson> ah, apparently we don't
[19:08] <cjwatson> mhr3_: it's too late for this upload, but can you find a maintainer to fix this going forward?  if this had been done right then the new unity-scopes-shell would just have been held in -proposed, rather than being installable but crashing
[19:09] <mhr3_> cjwatson, yea, opening a bug
[19:09] <cjwatson> mhr3_: I've accepted gsettings-qt as the least bad answer now that unity-scopes-shell is in anyway (if I'd had the opportunity I'd probably have rejected both)
[19:09] <cjwatson> fortunately unity-scopes-shell is only on touch for now so partial upgrades aren't so critical
[19:09] <cjwatson> well, the unity8 preview desktop maybe
[19:10] <cjwatson> mhr3_: thanks
[19:43] <bfiller> robru: silo14 ready to land
[19:46] <robru> bfiller, done!
[19:46]  * robru -> lunch
[21:19]  * ogra_ wonders why all the network-manager tests fail in unity8 on all devices
[21:31] <cyphermox> ogra_: which tests are those?
[21:34] <bfiller> robru: silo 9 ready to be released. sil2100 did the packaging review on sync-monitor (which is a new package) and we incorporated his branch
[21:34] <bfiller> robru: he said something about needing a preNEW review, but don't know what that means exactly
[21:35] <robru> bfiller, hmmm basically it means didrocks needs to ack it
[21:35] <bfiller> robru: anyone else capable of doing that?
[21:36] <robru> bfiller, well theoretically any archive admin can do it, but it's unfortunately not well understood beyond didrocks
[21:36] <robru> (didrocks invented it)
[21:39] <bfiller> robru: does it make sense to release the other things in the silo and wait only on sync-monitor until tomorrow? don't want to get caught by freeze
[21:39] <robru> bfiller, well you tell me ;-) will the other stuff break without it?
[21:40] <bfiller> robru: the folks and syncevo can certainly go in, probably best to wait on the address-book-* though to go together with sync-monitor
[21:41] <robru> bfiller, I can't really publish half a silo, best to wait for all of it then ;-)
[21:42] <bfiller> robru: that's fine
[21:42] <robru> I'll email didrocks so he can preNEW it first hing
[21:42] <bfiller> robru: sounds good, cc me too if you don't mind
[21:43] <robru> bfiller, oops, just hit send. I'll fwd to you
[21:43] <bfiller> thanks
[21:44] <robru> bfiller, you're welcome
[21:45] <mandel> cjwatson, following or conversation, more info => https://launchpadlibrarian.net/172280588/buildlog_ubuntu-trusty-powerpc.ubuntu-download-manager_0.3%2B14.04.20140408.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[21:47] <thomi> robru: silo 10 (line 41) is ready to land at your convenience
[21:48] <robru> thomi, done!
[21:49] <thomi> wow, that was fast, thanks :)
[21:49] <robru> thomi, well fortunately you didn't change any packaging, so no core dev ack required. one-click publish job ;-)
[21:49] <thomi> heh, cool
[21:49] <robru> thomi, although it might get held up in -proposed, that's out of my hands
[21:50] <thomi> d'awwwww
[21:50] <thomi> if it does, who should I bug about that?
[21:50] <davmor2> popey: just for you bud http://bazaar.launchpad.net/~davmor2/+junk/phone-transfer/view/head:/transfer.py  it's ugly but works :)
[21:50] <cyphermox> thomi: we'll look into it
[21:50] <thomi> cool, thanks cyphermox
[21:50] <cyphermox> robru: what package was that, autopilot?
[21:51] <robru> cyphermox, yeah ;-)
[21:51] <popey> davmor2: ☻
[21:51] <cyphermox> ok
[21:51] <popey> davmor2: feature request - add sync-evolution calls to that script
[21:52] <popey> oh you have ☻
[21:52] <davmor2> popey: :)
[21:52] <robru> popey, you still around? I've been having fun with bug 1304362 all day
[21:53] <popey> robru: ☻
[21:53] <popey> robru: good isnt it?
[21:53] <davmor2> popey: there is no calendar sync cause I've never done that, but that should be contacts, music, images and videos
[21:53] <popey> mhall119 has cal sync ... one mo
[21:54] <popey> hmmm
[21:54] <popey> cant find it now
[21:55] <bfiller> popey: if you want to test calendar sync it's ready in silo 9. will be released tomorrow
[21:55] <popey> *BOOM*
[21:55]  * popey hugs bfiller 
[21:55] <bfiller> lol
[21:55] <popey> ☻
[21:55] <bfiller> I thought you might be excited :)
[21:56] <popey> Just a *bit*
[21:56] <pmcgowan> popey, and did alarms MR land?
[21:56] <pmcgowan> speaking of excitement
[21:56] <robru> alright, I'm off to run a couple errands. back in 2 hours!
[21:56] <bfiller> popey: works pretty nicely, just not a way to add a new calendar event onto google yet. but mods work
[21:57] <bfiller> heard it's in the works for calendar app to add that though
[21:57] <davmor2> bfiller: nice but a bit harder to do via adb I guess :)
[21:58] <bfiller> inded
[21:58] <davmor2> bfiller: on a plus side you might not need to if it is easy enough to setup \o/
[22:00] <davmor2> popey: you can probably tuple multiple Matches together but I didn't try that being as I was only interested in the mp3/4's I had on the system
[22:01] <popey> davmor2: thanks, I'll play with it tomorrow
[22:31] <mandel> elopio, better over here, are you around?
[23:00] <elopio> mandel: I am. Too late?
[23:24] <mandel> elopio, nop
[23:24] <mandel> elopio, I sent a small report about the issues I found to the ubuntu-phone list
[23:24] <mandel> elopio, I'll take a look at it with zoltan tom
[23:26] <elopio> mandel: I saw the bug, thanks. It seems that we should have signal tests in every project.
[23:26] <mandel> elopio, at least to assert they are raised.. yes it might be a good idea :)