[03:57] <Mirv> good morning
[05:59] <Mirv> ogra_: somehow #15 is there and tested but no changes etc
[07:14] <ToyKeeper> Putting out fires all day (well, 13 hours) is not conducive to getting any testing done.
[07:33] <ogra_> Mirv, sorry, fixed
[07:33] <ogra_> seems the bot disconnected
[07:34] <ogra_> imgbot, stunt
[07:34]  * imgbot rolls on its back and purrs
[07:35] <ogra_> good
[07:38] <Mirv> ogra_: great!
[07:55] <sil2100> didrocks, ogra_: should we wait with promoting #14 till the meeting, or do you think it's ok to do it now? Since there's a +1 from davmor2 and the smoketesting looks the same as #13
[07:56] <popey> sil2100: can packages be updated?
[07:56] <didrocks> sil2100: yeah, let's just all sync up on test results during the meeting maybe?
[07:56]  * popey updates to 14 to test
[07:56] <sil2100> popey: what do you mean?
[07:56] <didrocks> popey: 15, you meant?
[07:57]  * didrocks would hope to get a double promotion for his last day as landing team leader :p
[07:57] <didrocks> give me that! ;)
[07:57] <popey> didrocks: did you see I approved about a bazillion french webapps last night?
[07:57] <didrocks> popey: oh, no, who did those?
[07:57] <popey> s/bazillion/6/
[07:58]  * didrocks notes that a bazillion is 6 for popey ;)
[07:58] <didrocks> what websites?
[07:58] <popey> no idea ☻
[07:58] <popey> cadremploi, francebillet, commentcemarche laconjugaison, lequipe, corsematin
[07:58] <sil2100> ;p
[07:59] <didrocks> choix intéressant… :p
[07:59] <sil2100> Just hope none of them use caca... ;p
[08:00] <didrocks> well, I wouldn't start to troll on corsica :p
[08:01]  * didrocks wonders if we will end up in the store with a webapps for each bookmark :p
[08:02] <popey> looks like it
[08:03] <popey> I was at a conference a year ago, and was in a talk given by a ffos guy. He handed out phones for people to play with, I'd not played with a FF phone before...
[08:03] <popey> i opened the store, and picked a random app, the first reviews were all bad, and basically said "This is just a crappy webapp"
[08:03] <popey> I expect us to get similar reviews, downvoting the webapps into oblivion
[08:04] <popey> Except mine, mine are awesome ☻
[08:04] <didrocks> popey: sure sure ;-)
[08:15] <Saviq> didrocks, hey, so... I wanted to get back to removing the HUD from the bottom edge finally, any pointers on how we should make it happen?
[08:15] <ogra_> rm -rf hud
[08:16] <didrocks> Saviq: getting a silo ready for that, and running all AP tests
[08:16] <Saviq> didrocks, ok, think we could use http://q-jenkins:8080/job/autopilot-release-gatekeeper/ ?
[08:16] <didrocks> Saviq: yeah, I was going to suggest that
[08:16] <Saviq> k
[08:16] <didrocks> but that's something to check with the CI team
[08:17] <Saviq> ok, /me gets a silo ready
[08:35] <popey> vila: s-jenkins:8080/job/terminal-app-click/ terminal is failing to build in jenkins but I can't see any logs
[08:37] <vila> popey: http://s-jenkins.ubuntu-ci:8080/job/terminal-app-click/55/console => mv: cannot move 'x/usr/lib/arm-linux-gnueabihf/qt5/qml/org' to '../install_dir/lib/arm-linux-gnueabihf/org': Directory not empty
[08:38] <vila> popey: doesn't look good, let me see
[08:38] <sil2100> Saviq: assigned! Just remember that it's 'ignore conflicts' again due to the greeter-splitter
[08:38] <Saviq> sil2100, of course
[08:38] <Saviq> sil2100, thanks
[08:39] <sil2100> yw!
[08:40] <popey> vila: thanks
[08:41] <vila> popey: I can't access that node anymore :-/ I know it's in the process of being updated but neither your error nor my lack of access are expected :-/
[08:42] <Saviq> vila, hey, could we use the autopilot gatekeeper job to verify a unity8 change (dropping the hud from bottom edge)?
[08:43] <vila> Saviq: ECONTEXT, why couldn't you ?
[08:46] <Saviq> vila, just asking :)
[08:46] <Saviq> vila, <didrocks> but that's something to check with the CI team
[08:48] <vila> Saviq: I don't know the specifics here but given the history of the job (plenty of ci-train references there), I don't see why not
[08:50] <Saviq> vila, ok :)
[08:51] <mandel> didrocks, the silo 001 was approved a while ago, do you know if thereis is a reason why it was not published?
[08:51] <mandel> sil2100, ^^
[08:51] <sil2100> mandel: let me check
[08:52] <mandel> sil2100, thx, appreciate it
[08:53] <sil2100> mandel: I'm confused by this thing, give me a moment ;)
[08:55] <vila> popey: ok, I got access
[08:55] <vila> popey: but I can't make sense of:
[08:55] <vila> + mkdir -p ../install_dir/lib/arm-linux-gnueabihf/
[08:55] <vila> + mv x/usr/lib/arm-linux-gnueabihf/qt5/qml/org ../install_dir/lib/arm-linux-gnueabihf/
[08:56] <sil2100> mandel: ah ha! Ok, so it's indeed stuck in -proposed because of failing autopkgtests
[08:56] <vila> how can that dir not be empty when it was just created ?
[08:56] <sil2100> hmm, strangeness
[08:57] <Saviq> vila, do you know if the gatekeeper job can deal with utopic?
[08:58] <vila> Saviq: good question, I don't know the answer, I know fginther has worked on that topic but I'm not aware of the fine details, you want to check with him
[08:58] <vila> Saviq: (or just be brave and try to see ;)
[08:58] <Saviq> vila, ok thanks
[08:58] <Saviq> vila, yeah, will do that ;)
[08:58] <cjwatson> vila: mkdir -p doesn't fail on a directory that already exists ...
[08:58] <cjwatson> (I haven't looked at the context, but that at least is a hole in your logic :-) )
[08:59] <vila> cjwatson: yeah, sorry, lack of coffee, I thought about that after typing enter ;)
[08:59] <vila> cjwatson: thanks for the heads-up anyway ;)
[08:59] <cjwatson> heh, I was waiting for slow tests so reading IRC ..
[09:00] <sil2100> PermissionError: [Errno 1] Operation not permitted: '/autopkgtest/tmp/apt0t-smoketest-artifacts/client.log' <- this seems to be from the log of the autopkgtest failure
[09:01] <Saviq> vila, looking at the job output http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/label=mako-07/112/consoleFull
[09:01] <Saviq> vila, "ubuntu-device-flash ubuntu-system --channel ubuntu-touch/trusty-proposed"
[09:01] <Mirv> sil2100: mandel: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2014-May/001098.html might be relevant
[09:01]  * mandel looks
[09:01] <Saviq> vila, I don't think that's a parameter :|
[09:02] <mandel> sil2100, did you take a look at what _Mirv posted? it might be due to that
[09:03] <popey> dpm: seems terminal is failing to build in jenkins.. see above comments from vila... https://code.launchpad.net/~dpm/ubuntu-terminal-app/merge-plugin/+merge/217380 possibly to blame?
[09:05] <ogra_> [09:06] <Mirv> \o/
[09:06] <popey> yay
[09:06] <vila> popey, dpm: not sure what is going on there the jenkins job shell script has "HACK BEGIN' 'HACK END' comments just before the failing commands: https://pastebin.canonical.com/109711/
[09:07] <vila> popey, dpm: and looking locally the 'out' dir is empty, there is no 'build' not 'install_dir' dirs either...
[09:07] <popey> aha, i dont think dpm took account of that hack script when he made that above merge
[09:08] <popey> it will likely need fixing
[09:11] <dpm> vila, I had no idea that that existed. The package that that hack installs is no longer required
[09:12] <dpm> the plugin is now already in the click package
[09:12] <vila> dpm: do you how is responsible for that job ? Or can we just comment out that hack to test and wait for someone in the know to fix properly ?
[09:13] <sergiusens> vila: feel free to remove it if you have access; I'm responsible
[09:13] <dpm> ah, cool, thanks sergiusens
[09:13] <sergiusens> vila: dpm fwiw, music and filemanager also have something similar
[09:13] <sergiusens> so keep that in mind when updating those
[09:14] <vila> sergiusens: cool, thanks, removed
[09:14] <dpm> sergiusens, filemanager was already updated. Not sure if the hack was removed though
[09:15] <sergiusens> dpm: vila hmmm, I'll take a look and do some cleansing
[09:16] <dpm> sounds good, thanks
[09:16] <vila> Saviq: back to you, what is not a parameter ?
[09:16] <Saviq> vila, the channel from which the phone is flashed
[09:17] <vila> Saviq: --channel ? There a re bunch of uses in that log
[09:17] <Saviq> vila, I mean not a parameter of the job
[09:18] <vila> Saviq: doh, ok wrong tree ;)
[09:18] <sergiusens> cjwatson: wrt the click ppa I've been hearing about; are you contemplating fat packages? Today I have a specific armhf pbuilder in jenkins assigned but I want to move it to an x86 one and cross build properly for i386 and armhf
[09:19] <vila> Saviq: multiple discussions in fly ;) So, you're blocked as I don't know enough about who need this job, we need plars
[09:19] <Saviq> vila, ok, thanks
[09:19] <Saviq> vila, will ping him later
[09:24] <cjwatson> sergiusens: I wasn't aware anyone was working on that, nor that it had even been designed; I'm certainly not
[09:25] <sergiusens> cjwatson: so my hearing is just wrong then :-)
[09:25] <cjwatson> possibly some telephone game going on
[09:25] <ricmm> vila: hey there, can you help me with removing/adding some MRs to a silo and then issuing a reconf/rebuild?
[09:25] <cjwatson> sergiusens: the thing I'm working on is live filesystem builds in LP
[09:26] <sergiusens> ricmm: vila I'll take care of that
[09:26] <ricmm> thx
[09:26] <vila> ricmm: hmm, no, I think you want one CI Train support... or sergiusens ;)
[09:43] <sergiusens> sil2100 Mirv didrocks https://ci-train.ubuntu.com/job/landing-006-1-build/36/console says it's out of sync with the archive; rsalveti resynced the archive into trunk yesterday (and ricmm merged trunk into his MR) so I'm not sure why this error shows up
[09:43] <ricmm> archive is at 0ubuntu2
[09:44] <ricmm> trunk seems to be at 0ubuntu1
[09:44] <ricmm> ?
[09:44] <didrocks> 2014-05-07 09:38:35,565 WARNING A version (2.0.0+14.04.20140326-0ubuntu2) is available at the destination archive for that component but is not in the destination branch which is still at 3.0.0-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
[09:44] <sergiusens> oh... then it wasn't synced
[09:46] <sergiusens> didrocks: yeah, this is dbus-cpp, not location-service (which was synced yesterday)
[09:46] <ricmm> is it hard to sync?
[09:46] <ricmm> or is it automatic
[09:47] <sergiusens> ricmm: you need to do something similar to what rsalveti did with location-service http://bazaar.launchpad.net/~phablet-team/location-service/trunk/revision/61 ... AFAIK it's manual
[09:48] <ricmm> sergiusens: manual push to trunk?
[09:48] <sergiusens> ricmm: I've never done a sync before; didrocks what's the procedure?
[09:50] <didrocks> sergiusens: just take the changes from the distro (the debdiff)
[09:50] <didrocks> sergiusens: get that to a MP and add it, or push it directly to trunk
[09:50] <didrocks> if the diff doesn't have any meaning, you can use the force rebuild button
[09:51] <didrocks> (and so, it will discare this version check)
[09:51] <ricmm> the diff is a no-change rebuild
[09:51] <sergiusens> didrocks: that seems reasonable for the no change rebuilds
[09:51] <ricmm> https://launchpadlibrarian.net/173932108/dbus-cpp_2.0.0%2B14.04.20140326-0ubuntu2.diff.gz
[09:51] <didrocks> so you can use the flag :)
[09:51] <ricmm> so I think a force rebuild is ok today
[09:51] <didrocks> yeah
[09:51] <ricmm> now my question is, how do this no-change rebuilds get through to trunk
[09:51] <sergiusens> didrocks: how do I affect that flag to only one package? multiple build calls?
[09:52] <ricmm> as in how did xnox commit it to trunk
[09:52] <didrocks> sergiusens: the rest was built and sent, right?
[09:52] <ricmm> I mean, not to trunk, to archive
[09:52] <ricmm> he literally did a dput?
[09:52] <didrocks> ricmm: he did a dput I guess
[09:52] <ricmm> :)
[09:52] <didrocks> sergiusens: you can restrict the build to the list of packages with rebuild package only
[09:52] <didrocks> and use that flag
[09:53] <sergiusens> didrocks: it stopped midway so not all; I'll do multiple builds I guess
[09:53] <didrocks> sergiusens: yeah, two builds then
[09:56] <xnox> didrocks: ricmm: typically no change rebuilds are versioned such that the next upload can blindly override previous upload. That is the case for e.g. debian imports (it ignored "buildX" version numbers) it would be nice if landings did have an option to blindly override no change rebuilds.
[09:56] <xnox> ricmm: alternatively i do try to propose back a branch merge proposal with just the changelog entry, but for something the size of boost transition that doesn't quite scale / keep up.
[09:56] <didrocks> xnox: I don't see you using Xbuild1 though
[09:57] <sergiusens> ricmm: https://ci-train.ubuntu.com/job/landing-006-1-build/
[09:58] <ricmm> sergiusens: thanks!
[09:58] <didrocks> sergiusens: once it's starting to scan the ppa, you can cancel the job so that the other uploads happens
[09:58] <sergiusens> ricmm: you are going to need rsalveti to upload the latest android package too
[09:58] <sergiusens> didrocks: right, good idea
[09:59] <ricmm> sergiusens: theres one in the silo from the day before yesterday
[09:59] <ricmm> sergiusens: you mean a new update? dbus-cpp and location-service dont add anything to the android side
[09:59] <sergiusens> ricmm: just because android is listed in the silo
[10:01] <ricmm> ok
[10:01] <ricmm> well that sucks, he wont be up for a while
[10:02] <xnox> didrocks: Xbuild1 are used on top of debian version numbers, but ci/autolanded components use -0ubuntu1 by default.
[10:02] <xnox> didrocks: maybe we need to agree on a common version numbers that can be overriden. Cause -0ubuntu2 can be "change-full" upload, instead of a 'no-change-rebuild' upload.
[10:03] <xnox> hence a rebuild of -0ubuntu1 gets -0ubuntu2 version number from (dch --rebuild)
[10:03] <cjwatson> Once again I wish we had binNMUs
[10:03] <xnox> yeah or htat.
[10:03] <xnox> cjwatson: is this the time when you ask me for lp dev time again =)
[10:04] <cjwatson> Heh, this would be fairly serious Soyuz work, unlike the other
[10:04] <wgrant> what what
[10:04] <wgrant> Oh, binNMUs. yeah, maybe in a decade :)
[10:04] <didrocks> xnox: I guess it's easy to implement anyway if people agree on a standard for all rebuilds (even after getting an -0ubuntu1 for instance)
[10:05] <ogra_> wgrant, in a decade we will have moved the world to click packages :P
[10:05] <didrocks> xnox: for now, there is a manual override possible anyway
[10:05] <wgrant> We should probably vaguely consider binNMUs as part of the Soyuz redesign eventually.
[10:05] <wgrant> ogra_: And system-image on desktops? I'll believe it when I see it :)
[10:05] <cjwatson> I know it was a joke, but I'm not intending click packages to take over everything; they have a scope
[10:06] <ogra_> well, system-image desktops will happen :)
[10:06] <ogra_> i guess click only for graphical apps
[10:06] <cjwatson> click packages aren't intended for platform development
[10:06] <cjwatson> And I expect never will be
[10:06] <ogra_> yeah
[10:07] <cjwatson> Even if they were, they'd end up needing to grow many of the same features debs have (which is one reason it would be a stupid exercise) and we'd end up having essentially the same problems
[10:18] <dbarth> didrocks: hi, i have silo 018 ready for landing at last
[10:19] <didrocks> dbarth: no need to ping, people on duty have an hilight on trainguards
[10:19] <didrocks> and #ubuntu-ci-choo-choo told:
[10:19] <didrocks> 12:18:35  CI-SNCF | trainguards (landing-018): Ready to publish
[10:19] <didrocks> :)
[10:19] <dbarth> so much automation
[10:19] <dbarth> :)
[10:19] <didrocks> heh ;)
[10:20]  * dbarth feels like a small cog in the gigantic didrock-o-tron
[10:20] <dbarth> ;)
[10:21] <didrocks> ahah
[10:21] <didrocks> you will even get pinged automatically on the choo-choo channel once it's published!
[10:21] <dbarth> btw cjwatson: hi, i have this new livemail package (hopefully with a correct changelog)
[10:21] <dbarth> i know
[10:21] <dbarth> i'm used to that ping now
[10:24] <Mirv> seems didier is on it
[10:24] <Mirv> and yes we have highlights
[10:27] <cjwatson> dbarth: Oh, right, moment
[10:29] <cjwatson> dbarth: accepted
[10:33] <silDroid> Hi guys!
[10:33] <silDroid> Power outage at my place
[10:33] <silDroid> Theyvsay it will be back in ETA 2h
[10:45] <dbarth> cjwatson: thanks
[10:45] <dbarth> that's cool, now all my silo lines are clean
[10:51] <popey> didrocks: i still can't update apps on #15
[10:52] <popey> 2014-05-07 10:50:56,524 - CRITICAL - ../../../../lib/SignOn/connection-manager.cpp 106 setupSocketConnection p2p error: QDBusError("org.freedesktop.DBus.Error.FileNotFound", "Failed to connect to socket /run/user/32011/signond/socket: No such file or directory") 1
[10:52] <popey> looks bad
[10:53] <ogra_> works on 14 for me
[10:54]  * ogra_ is just getting 5 updates 
[10:54] <popey> so some kind of single sign on error I imagine
[10:55] <ogra_> are you online at all ?
[10:55] <ogra_> oh, didnt you test the NM fix ?
[10:56] <popey> must be, i just signed out and signed back in
[10:56] <popey> of u1
[10:56] <popey> 2014-05-07 11:56:08 (50.9 MB/s) - ‘index.html’ saved [1630/1630]
[10:56] <ogra_> make sure the 02_i_hate_you_ril file is gone
[10:56] <popey> where was that?
[10:56] <ogra_> system-image upgrades dont remove files ...
[10:57] <popey> 2014-05-07 11:55:36,101 - WARNING - QDBusObjectPath: invalid path "https://public.apps.ubuntu.com/download/com.ubuntu/music/com.ubuntu.music_1.3.453_armhf.click"
[10:57] <popey> can you update music?
[10:58] <ogra_> it is downloading, yeah
[10:58] <ogra_> hmm
[10:58] <ogra_> or not
[10:58]  * ogra_ notes everything sits at 0%
[10:58] <popey> same
[10:58] <popey> check your .cache/upstart/application-legacy-ubuntu-system-settings-.log
[10:58] <popey> paste.ubuntu.com/7409741/
[10:59] <bzoltan1> Mirv:I have alanding inthe line 26, may I ask for a Silo?
[11:00] <Mirv> bzoltan1: you have it already
[11:01] <Mirv> bzoltan1: I got pinged on #ubuntu-ci-choo-choo
[11:05] <ogra_> popey, yup ... i see the same error
[11:12] <bzoltan1> Mirv:  that is a cool channel :D
[11:13] <popey> didrocks: ^^ can't update apps in #15
[11:14] <Saviq> aargh why doesn't jenkins log you in straight away...
[11:17] <Saviq> didrocks, I think that's my biggest beef with the train currently ↑ is there anyone looking at it?
[11:52] <silDroid> Hi guys
[11:53] <silDroid> So, the power company informed me that it will be fixed till 15
[11:53] <silDroid> So in max an hour from now ;/
[11:57] <ogra_> til 15 ?
[11:58] <ogra_> should i promote 15 now so they are faster ? ;)
[11:58] <cyphermox> ogra_: file in gone?
[11:58] <ogra_> cyphermox, gone in you mean ? yeah :)
[11:59] <ogra_> 14 has it
[11:59] <cyphermox> oh, right
[12:05] <popey> ogra_: you promoting 15 even though we can't update apps?
[12:06] <popey> or is this isolated to us?
[12:06] <ogra_> popey, only promooting if you tell me as i said in the meeting
[12:06] <ogra_> i wont go that path alone without anyone else to blame for it :P
[12:06] <popey> Well, I'm -1 until I know more about why this is failing to update.
[12:06] <ogra_> popey, i'm on 14 here btw
[12:07] <ogra_> so we already promoted the breakage ... but i agree we shouldnt promote until we know whats up ... did you ask the signon guys ?
[12:08] <popey> looking for an existing bug
[12:08] <popey> i thought pat may have filed one
[12:08] <ogra_> lets wait and ask then :)
[12:08] <popey> ok
[12:08] <Mirv> thostr_: is there something that could be done about the old landing lines 1+2 (normalize indicator startup, add public alarm API) which are 2+ months old? clean up, land?
[12:08] <popey> i cant see one from him, maybe his was only crashing of u-s-s
[12:09] <popey> ogra_: who are the signon guys?
[12:09] <ogra_> no idea :)
[12:09] <ogra_> mardy perhaps
[12:10] <ogra_> i see a lot of MPs come from him
[12:13] <didrocks> Saviq: it's on the umbrella of your RT ticket
[12:13] <didrocks> Saviq: there is an issue with the sso integration
[12:14] <didrocks> popey: nothing new, right? or is it,
[12:15] <Saviq> didrocks, k thanks
[12:15] <didrocks> Saviq: I've pushed and complained multiple times about it, not sure what else I can do
[12:15] <didrocks> Saviq: you can follow up on the RT maybe?
[12:15] <Saviq> didrocks, doing
[12:15] <popey> didrocks: dunno, not been dogfooding for a while.
[12:17] <didrocks> popey: there has been absolutely no change related to that
[12:17] <didrocks> in #15
[12:17] <thostr_> Mirv: I'll clean those up
[12:17] <popey> didrocks: ok, so it's pre-existing, has someone filed a bug for it? where's it tracked?
[12:18] <ogra_> didrocks, it is broken in 14 too
[12:18] <popey> ☹
[12:18] <Mirv> thostr_: thanks!
[12:18] <didrocks> popey: so, I guess time to open one and get some bisecting :/
[12:18]  * popey opens one
[12:20] <didrocks> popey: seems to be the download-manager, right?
[12:20] <didrocks> from your warning
[12:20] <Saviq> didrocks, truth be told if we want to allow unauth access to jenkins, I'm not sure how this could be solved - we'd need jenkins to 401 when going to the "build" page, because now it just displays it and when you press "build" you get looped back to the same page, just logged in
[12:20] <popey> not sure
[12:20] <didrocks> Saviq: already, if the cookie was working for a longer time, that would be of some help
[12:21] <Saviq> which actually makes sense... why would jenkins display you the fields/buttons when you can't press it...
[12:21] <didrocks> Saviq: it does actually
[12:21] <didrocks> popey: I would open against it, seb128, what do you think?
[12:21] <Saviq> didrocks, how do we end up at the page with fields and buttons and a "log in" button
[12:21] <ogra_> mandel, ^^^
[12:21] <popey> well, opened already at https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1317067
[12:21] <popey> can be re-assigned
[12:22] <didrocks> seb128: ^
[12:22] <Saviq> didrocks, that should be impossible... same as when you try to go to the "rebuild" link on s-jenkins, if you're not logged in, it redirects you to the main job page
[12:22] <didrocks> Saviq: I really guess your biggest issue is that the cookie life is too short
[12:23] <didrocks> if you were logged in for 2 weeks, that wouldn't be a biggie
[12:23] <Saviq> didrocks, it wouldn't be an issue if jenkins would request a login ;)
[12:23] <Saviq> didrocks, most of the time it'd just get looped straight through SSO
[12:24] <didrocks> Saviq: that's true
[12:24] <Saviq> didrocks, but yeah, both solutions would reduce the impact (but the shorter cookie would also reduce security in case of someone having their rights revoked)
[12:24] <Saviq> s/shorter/longer/
[12:26] <didrocks> popey: anything else from your dogfooding apart that?
[12:27] <popey> didrocks: no. all looks good aside from that
[12:29] <didrocks> ok, thanks
[12:29] <didrocks> ogra_: ready for repromoting?
[12:30] <ogra_> didrocks, so we dont want to find a fix first ?
[12:30] <ogra_> (or at least a cause)
[12:31] <didrocks> ogra_: well, is it new since #14?
[12:31] <didrocks> seems not
[12:31] <didrocks> so let's separate concerns
[12:31] <didrocks> and nor seb128 or mandel are around
[12:31] <ogra_> i see it in 14 ... but i havent updated any apps in 3
[12:31] <didrocks> (seb will be back soon)
[12:31] <ogra_> so i cant say if it was in 3
[12:31] <didrocks> ogra_: but it was in 14…
[12:31] <didrocks> and we promoted it
[12:31] <ogra_> yes
[12:31] <didrocks> so that's a different topic
[12:31] <ogra_> k
[12:32] <didrocks> then, would be nice to have someone trying 3
[12:32] <popey> i am on 2 now
[12:32] <popey> will do 3 next
[12:32] <didrocks> popey: working on 2?
[12:32] <ogra_> as i said above, as long as i have someone else to blame for it i will happily promote :)
[12:32] <popey> dunno yet, signing in
[12:33] <popey> didrocks: yes, works in #2
[12:33] <popey> shall I try #3?
[12:34] <didrocks> popey: let's try to target so that you don't have to try every images
[12:34]  * didrocks looks for signon or u-s-s updates
[12:34] <popey> ok
[12:34] <didrocks> or download-manager
[12:34] <popey> 5
[12:35] <popey> and 6
[12:35] <ogra_> u-d-m landed in 6
[12:35] <didrocks> popey: yeah, seems that one of them, maybe start with 6?
[12:35] <ogra_> oh, in 5 too
[12:35]  * didrocks downloads 5
[12:35] <popey> I'll do 6 then
[12:35] <seb128> back
[12:35] <popey> 2014/05/07 13:35:44 Failed to locate image 6
[12:35] <seb128> didrocks, reading backlog
[12:35] <popey> bah!
[12:36] <ogra_> yeah, these rushed landings ... u-d-m only matured for 8 weeks in its silo ...
[12:36] <didrocks> popey: ubuntu-touch/devel-proposed?
[12:36] <popey> ah
[12:36] <popey> duh
[12:36] <popey> ok, got it
[12:36] <didrocks> phew :)
[12:36] <popey> ☻
[12:36] <popey> keeping you on your toes ㋛
[12:36] <didrocks> heh ;)
[12:37] <didrocks> 5 downloading, taking a shower meanwhile :)
[12:37] <seb128> didrocks, we didn't have any settings landing in ages
[12:37] <ogra_> yeah, we just need to prove that he cant move !
[12:37] <didrocks> seb128: agreed, think it's u-s-s :)
[12:37] <seb128> gatox is working on some fixes for the updates panel
[12:37] <seb128> he submitted like 3 or 4 mps yesterday
[12:38] <seb128> it's on my list for today, review/test/organize a landing
[12:38] <ogra_> its not the panel i think
[12:38] <didrocks> seb128: you think those changes are to work with latest u-d-m?
[12:38] <didrocks> like, they changed some protocol?
[12:38] <ogra_> unless that gives the wrong path to the download-manager
[12:38] <seb128> didrocks, no, I'm unsure what the issue you guys are discussing is
[12:38] <gatox> seb128, yes... i'm reviewing the fail you mentioned... i'm building it on the phone without any problem, so it's weird
[12:39] <seb128> gatox, that's a build on my desktop, I didn't try on the phone
[12:39] <seb128> gatox, let me know if you need debug info from me
[12:40] <gatox> seb128, ahh.. i can't test it on the desktop... bzr bd has NEVER worked for me in the desktop :S i'll check what might be wrong anyway
[12:40] <seb128> gatox, what is not working under bzr bd?
[12:40] <gatox> seb128, it always gave me a timeout error from launchpad...
[12:40] <seb128> ?!
[12:40] <gatox> yap
[12:41] <seb128> what has bzr bd to do with launchpad
[12:41] <seb128> can you pastebin the error/log?
[12:41] <gatox> seb128, ok... let me do it again
[12:43] <gatox> seb128, ok.... my bad totally.... i've always used with bzr bd lp:..... everywhere.... not with a local branch, with a local branch it works in the desktop.... with a remote branch fails with timeout (not in the phone though)
[12:43] <seb128> gatox, ok, good ;-)
[12:44] <didrocks> seb128: we are discussing about https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1317067
[12:44] <seb128> gatox, ^ do you have any idea on that one?
[12:45] <seb128> didrocks, popey, ogra_: do we have new clicks on the new image?
[12:45] <seb128> ** (process:2946): WARNING **: Couldn't parse desktop file /opt/click.ubuntu.com/com.po\x99
[12:45] <seb128> that's weird
[12:46] <didrocks> seb128: on #15?
[12:46] <seb128> I wonder if one of the clicks is buggy and that creates confusion
[12:46] <didrocks> or 14?
[12:46] <seb128> on images where the issue happen
[12:46] <ogra_> we only dropped one ... no new ones in a while
[12:46] <seb128> no update in the image that introduced the bug?
[12:46] <didrocks> seb128: ah, we still don't know where it started to happen
[12:46] <seb128> k
[12:46] <gatox> seb128, didrocks we should check if it is related to this: QQmlExpression: Expression file:///usr/share/ubuntu/settings/system/qml-plugins/system-update/PageComponent.qml:396:38 depends on non-NOTIFYable properties: (although it says warning).... anyway, i proposed a branch for that yesterday .... or the other dbus problems that seems to be from signon
[12:46] <didrocks> gatox: can you check with latest image?
[12:47] <popey> didrocks: #6 is broken too
[12:47] <popey> didrocks: updated the bug
[12:47] <didrocks> popey: I'm ssoing
[12:47] <didrocks> in #5
[12:47] <seb128> gatox, QDBusObjectPath: invalid path "https://public.apps.ubuntu.com/download/com.ubuntu/music/com.ubuntu.music_1.3.453_armhf.click"
[12:47] <seb128> that's weird as well
[12:47] <didrocks> popey: mind just downloading #4?
[12:47] <didrocks> in case ;)
[12:47] <popey> sure
[12:47] <gatox> right... QDBusObjectPath: invalid path "https://public.apps.ubuntu.com/download/com.ubuntu/music/com.ubuntu.music_1.3.453_armhf.click"
[12:48] <gatox> seb128, the build was successful on my desktop too
[12:49] <seb128> :/
[12:49] <seb128> could it be a server issue?
[12:49] <didrocks> seb128: no, working on #2
[12:49] <seb128> weird
[12:50] <gatox> seb128, it seems that maybe i forgot to push last changes
[12:50] <didrocks> popey: music stays at 0% on 5
[12:50] <didrocks> gatox: ^
[12:50] <seb128> gatox, what changes?
[12:50] <gatox> seb128, mmm although last changes are not related to that
[12:51] <didrocks> I would say that it will pass on #4
[12:51] <gatox> seb128, in the branch
[12:51] <didrocks> and it's the first u-d-m update
[12:51] <seb128> gatox, oh
[12:51] <didrocks> if so, it means that u-d-m doesn't test click app update on their test plan
[12:52] <gatox> didrocks, i'm updating the image and will try that
[12:52] <didrocks> gatox: let's say what popey says on 4…
[12:52] <didrocks> see*
[12:52] <gatox> seb128, but jenking for i386 is failing in the same way... let's see if it works with the last push
[12:53] <seb128> gatox, ok
[12:54] <sil2100> \o/
[12:55] <popey> didrocks: #4 on flo works.
[12:56] <popey> so it's between #4 and #5
[12:56] <didrocks> here we go…
[12:56] <didrocks> popey: can you try to update:
[12:56] <didrocks> (one sec)
[12:56] <popey> i need RW for this don't I?
[12:56] <didrocks> popey: yeah, RW
[12:56] <popey> k
[12:56] <didrocks> popey: ubuntu-download-manager libubuntu-download-manager-client0 libubuntu-download-manager-common0
[12:57] <popey> k
[12:57] <didrocks> popey: and reboot then for safety
[12:57] <didrocks> in case there is a daemon…
[12:57] <popey> k
[12:57] <didrocks> thanks!
[12:57] <popey> np
[12:57] <ogra_> there were a lot of package renames in that u-d-m upload
[12:57] <didrocks> oh
[12:57] <ogra_> libubuntu-download-manager-priv0
[12:57] <didrocks> popey: it will drop libubuntu-download-manager-priv0, don't be surprised
[12:57] <ogra_> and drop libudm-common0 libudm-priv-common0
[12:57] <didrocks> but you need to add:
[12:57] <didrocks> libudm-common0 libudm-priv-common0
[12:57] <didrocks> ogra_: the other way around :p
[12:58] <didrocks> ogra_: he's on #4
[12:58] <ogra_> oh
[12:58] <ogra_> yeah
[12:58] <didrocks> we want to upgrade to newest u-d-m
[12:58] <popey> so, apt-get install ubuntu-download-manager libubuntu-download-manager-client0 libubuntu-download-manager-common0 libudm-common0 libudm-priv-common0  ?
[12:58] <didrocks> popey: apt-ge tinstall ubuntu-download-manager libubuntu-download-manager-client0 libubuntu-download-manager-common0 libudm-common0 libudm-priv-common0
[12:58] <didrocks> \o/
[12:58] <popey> \o/
[12:58] <popey> haha
[12:58] <didrocks> ahah
[12:58] <didrocks> :p
[12:58] <popey> IRC TWINS!
[12:58] <sil2100> ;p
[12:59] <didrocks> (I'm the evil twin, the ahah is reversed!)
[12:59] <popey> paste.ubuntu.com/7410286/
[12:59] <popey> look good?
[12:59] <didrocks> yeah
[13:01] <popey> yup, reboot, and that broke it
[13:01] <didrocks> mandel: !!!
[13:01] <didrocks> thanks popey
[13:01] <didrocks> popey: mind updating the bug?
[13:01] <popey> MAN-DELLLLLL!
[13:01] <popey> sure
[13:01] <didrocks> thanks man
[13:01] <popey> np
[13:01] <ogra_> as i said ... rushed landing
[13:01] <seb128> yet another example of people wrongly blaming our settings!
[13:01] <gatox> didrocks, seb128 i updated the image in the phone using u-s-s... and now i see the apps stuck trying to update
[13:01] <ogra_> only took 8 weeks ...
[13:02] <ogra_> we need to make that 16 next time :P
[13:02] <didrocks> gatox: right :)
[13:02] <didrocks> ogra_: agreed ;)
[13:02] <didrocks> seb128: who were people? I protected you from the start! :p
[13:02] <gatox> didrocks, while i was trying did you find out what's wrong?
[13:02] <didrocks> 14:20:06   didrocks | popey: seems to be the download-manager, right?
[13:02] <didrocks> see, proof! ^
[13:02] <popey> ☻
[13:03] <gatox> ah
[13:03] <didrocks> gatox: it's the first u-d-m landing
[13:03] <didrocks> gatox: ubuntu-download-manager from 0.3+14.04.20140321-0ubuntu1 to 0.3+14.10.20140430-0ubuntu1
[13:03] <seb128> didrocks, right, I blame popey, he opened his bug on u-s-s
[13:03] <didrocks> seb128: it's just because he doesn't like you :)
[13:03] <popey> ☹
[13:04] <popey> the thing looking at me was u-s-s, the log file containing the error was u-s-s.
[13:04] <popey> next time I'll file against other random apps so as not to offend anyone
[13:04]  * didrocks creates the random-app project on LP
[13:04]  * popey files a bug
[13:05] <didrocks> ;)
[13:05] <gatox> didrocks, seb128 should we close the bug?
[13:05] <didrocks> seb128: I'm sure you are happy to see corsematin or l'équipe on touch now :p
[13:05] <didrocks> gatox: closing?
[13:05] <didrocks> is it fixed?
[13:05] <didrocks> when/how?
[13:05] <seb128> didrocks, l'equipe!
[13:06] <didrocks> seb128: yeah, I was sure that had to happen at some point… :p
[13:06] <gatox> didrocks, assign it to somewhere else i mean
[13:06] <seb128> gatox, reassing to u-d-m rather (or keep it on u-s-s if the interface changed and we need to adapt u-s-s)
[13:06] <didrocks> gatox: popey is doing that (but on the same bug)
[13:06] <gatox> ack
[13:07] <didrocks> so cadremploi et boom, proposal of installing the android app
[13:11] <popey> bug 1317067 reassigned to u-d-m so as not to offend the frenchys
[13:11] <plars> vila: that's not one of mine, I can take a look though if you haven't sorted it already
[13:12] <didrocks> popey: take care, we do have an highlight on french* :)
[13:12] <popey> haha
[13:13] <vila> plars: ha, sry then, yeah, please do
[13:13] <plars> vila: where's the actual job? I saw the pastebin but I haven't caught up yet on what the problem was, or which job this was?
[13:14]  * didrocks played the assigning and priority game + add more info
[13:16] <vila> plars: the pastebin was a different issue I think (and it's solved)
[13:17] <plars> vila: ok, so is there something I need to look at?
 vila, looking at the job output http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/label=mako-07/112/consoleFull
[13:18] <vila> plars: Saviq wanted to use that for utopic but the channel is not a job parameter
[13:20] <plars> Saviq: I can just change it to use utopic, or make it configurable but default to ubuntu-touch/utopic-proposed if you prefer? I'm not sure I know the history of this job, but I've seen it pop up a few times. Is it normally something you are manually triggering?
[13:20] <plars> it seems to be a bit of a one-off
[13:30] <sil2100> didrocks: packaging ACKs needed! Both look good, a new package and the dependency added, no file conflicts seem to be happening: https://ci-train.ubuntu.com/job/landing-004-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+14.10.20140506.1-0ubuntu1.diff and https://ci-train.ubuntu.com/job/landing-004-2-publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-app_0.2+14.10.20140
[13:32] <didrocks> sil2100: +1
[13:34] <sergiusens> seb128: UIs get to be blamed first and you walk down that path; this seems like a simple case for an autopackage test; didrocks do silos run autopackage tests?
[13:35] <didrocks> sergiusens: they don't, it's being worked on from the CI Team though AFAIK
[13:35] <didrocks> sergiusens: but it's ran when going from -proposed -> release pocket
[13:38] <didrocks> no more spreadsheet issues :)
[13:41] <sil2100> didrocks: who has the power to edit the topic? Anyone?
[13:41] <didrocks> sil2100: yeah, the chan isn't in -v
[13:42] <seb128> didrocks, did they resolve by themself?
[13:43] <sil2100> seb128: the spreadsheet issues?
[13:43] <didrocks> seb128: we did copy the spreadsheet
[13:44] <didrocks> to another url
[13:44] <seb128> sil2100, yes
[13:44] <seb128> and that fixed it?
[13:44] <didrocks> seb128: there was a fix to do less writings
[13:44] <sil2100> seb128: we migrated the spreadsheet to a different one as mentioned, and fixed a bug that was probably causing the issue to happen
[13:44] <seb128> k
[13:44] <didrocks> (the regression started in a corner case and nothing was archived for a long time)
[13:45] <didrocks> well s/causing the issue/triggering the google issue/
[13:45] <didrocks> rather :p
[13:45] <sil2100> Right ;)
[13:50] <rsalveti> ricmm: sergiusens: I don't think we need a new android upload in there
[13:56] <rsalveti> didrocks: hey, are you able to give me a hand reviewing and accepting a few packages today still?
[13:56] <rsalveti> https://launchpad.net/ubuntu/utopic/+queue, the qt -gles ones
[13:56] <rsalveti> so I can try to spin an android x86 emulator image
[13:56] <didrocks> rsalveti: there are quite a lot and I have a meeting now. I can do some, but not all
[13:57] <rsalveti> didrocks: yeah, they are 5 packages
[13:57] <didrocks> rsalveti: + the binary ones
[13:57] <rsalveti> didrocks: sure, no worries
[13:58] <didrocks> rsalveti: let me review the binaries before the meeting
[13:58] <didrocks> so that at least, qtbase is unblocked
[13:58] <didrocks> for the rest
[14:00] <rsalveti> right, thanks
[14:00] <mhr3> didrocks, ping?
[14:04] <mandel> didrocks, popey wait what?
[14:05] <ricmm> rsalveti: oh, here
[14:05] <didrocks> mandel: bug #1317067
[14:05] <ricmm> rsalveti: right, so I told sergio we didnt need one either
[14:05] <ricmm> rsalveti: but he said it was required on every rebuild?
[14:06] <rsalveti> ricmm: it's not
[14:06] <ricmm> even better
[14:06] <rsalveti> as long you configured the silo with the src package included, you're fine
[14:06] <rsalveti> otherwise we'd bump the changelog for no reason
[14:06] <mandel> didrocks, looking at that bug, the error says => /lib/SignOn/connection-manager.cpp
[14:06] <mandel> ogra_, popey, didrocks why would have that anything to do with downloading?
[14:07] <popey> mandel: see last comment - i updated u-d-m packages which broke it
[14:07] <ogra_> mandel, no idea, all i see if that it seems to try a wrong path
[14:08] <ogra_> s/if/is/
[14:08] <pmcgowan> mandel, I attached a download log to this bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1316794
[14:08] <ogra_> mandel, and popey tried with old and new udm ...
[14:08] <pmcgowan> but that only shows the download times out
[14:09] <mandel> ogra_, and with the old one works?
[14:09] <ogra_> seems so
[14:09] <ogra_> popey tested it
[14:09] <ogra_> he can give you details
[14:09] <mandel> pmcgowan, where did you grab those logs from? it they are from syslog you are looking at system image upgrades
[14:09] <pmcgowan> mandel, /var/log/ubuntu-download-manager
[14:10] <ogra_> adb shell cat /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings-.lo
[14:10] <ogra_> g
[14:10] <pmcgowan> I tailed them while asking for an app update
[14:10] <ogra_> thats the log we started from
[14:10] <ogra_> which has thinngs like "2014-05-07 12:58:05,467 - WARNING - QDBusObjectPath: invalid path "https://public.apps.ubuntu.com/download/com.ubuntu.developer.bobo1993324/qmltextreader/com.ubuntu.developer.bobo1993324.qmltextreader_0.1.2-c_armhf.click""
[14:10] <popey> mandel: i flashed flo with various different versions, went to image #4 and it worked, image #5 doesn't. we noted the difference and I manually upgraded _only_ u-d-m packages, which broke it.
[14:10] <ogra_> here at least
[14:11] <mandel> popey, hm.. funny, cause looking at the crash it has nothing to do with the downloader.. it does not even get called!
[14:12] <mandel> coño...
[14:12] <mandel> popey, let me dig and see what might be the cause
[14:12]  * mandel smells a problem in that qml code
[14:16] <mandel> popey, can you please grab the logs from the ,cache dir?
[14:16] <popey> mandel: which logs?
[14:17] <mandel> popey, the download manager ones
[14:17] <mandel> popey, let me point you to the full path, one sec
[14:17] <popey> ya
[14:17] <popey> got it
[14:18] <popey> mandel: http://paste.ubuntu.com/7410680/ http://paste.ubuntu.com/7410682/
[14:20] <mandel> popey, perfect, what app where you trying, the  "https://public.apps.ubuntu.com/download/com.ubuntu/filemanager/com.ubuntu.filemanager_0.3.169_armhf.click"
[14:20] <mandel> popey, right?
[14:20] <didrocks> rsalveti: so, I'm BINnewing the packaging. However, I wasn't in the discussion for duplicating those Qt source packaging for building the gles version and so, don't feel confortable reviewing and source NEW the other one without having a clear +1 from the security team
[14:20] <popey> thats the one that failed, yes, most recent comment
[14:20] <didrocks> rsalveti: or from other archive admins
[14:20] <rsalveti> didrocks: sure, the idea was to duplicate the src packages, there's no other way to support both qt stacks this way
[14:21] <mandel> popey, well, it is clear that it never gets to the download manager and that it is trying to use the app url in the server as the dbus path
[14:21] <didrocks> rsalveti: was the security team involved?
[14:21] <rsalveti> and we don't need them in main for now, it's better to wait qt 5.4 for something that would be compatible with main
[14:21] <didrocks> ok, anyway, BINNew what's in already
[14:21] <mandel> seb128, may I know the name of the project for system settings?
[14:21] <didrocks> as it was source NEWed
[14:21] <rsalveti> sure, I can ping the folks that were involved in this
[14:22] <seb128> mandel, ubuntu-system-settings
[14:22] <didrocks> rsalveti: should I reject -1ubnutu15?
[14:22] <mandel> seb128, thx
[14:22] <didrocks> ubuntu* even
[14:22] <seb128> mandel, do you want to reassign back there?
[14:22] <rsalveti> didrocks: yes, as I uploaded ubuntu16 with a minor fix
[14:22] <seb128> mandel, if so please talk to gatox_lunch to tell him what the settings are doing wrong, it worked before that udm update
[14:22] <didrocks> ok, doing :)
[14:22] <mandel> seb128, I want to grab the code, looks at what is going on and the talk with gatox
[14:23] <seb128> k
[14:23] <rsalveti> didrocks: thanks
[14:23] <didrocks> yw
[14:23] <seb128> mandel, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/files/head:/plugins/system-update/
[14:23] <mandel> seb128, I know that is no using the client application but going straight to dbus and that is trying to use the app url in the server as a dbus path
[14:23] <seb128> mandel, that's the directory you want to look at
[14:23] <seb128> mandel, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/view/head:/plugins/system-update/download_tracker.cpp
[14:25] <mandel> seb128, looking, thx for the info
[14:25] <seb128> yw!
[14:28] <mardy> jfunk: hi! about the decoupling of trunk from what's in the archive, is there a way I can opt-in for being a pilot in the experiment?
[14:28] <mandel> seb128, didrocks, popey ok, super quick plan, I did not know that system setting was already using the client library for udm, we need to rebuild because there was an ABI change, I have a very strong feeling that the issue is there
[14:28] <mandel> seb128, didrocks the ABI changed and breaks in a funny way (and logs are useless)
[14:29] <mandel> a rebuild will fix the issue
[14:29] <sergiusens> rsalveti: ricmm what I said is that the android package is listed in the silo so if it was there, given the latest uploads; it would be out of date
[14:29] <rsalveti> sergiusens: right, but I did another upload in there after updating the one from the archive
[14:29] <rsalveti> so it's not out of date
[14:30] <didrocks> mandel: can you try that locally and confirm?
[14:30] <didrocks> mandel: I guess as part of your u-d-m landing plan, you need to test the u-s-s UI
[14:30] <seb128> mandel, when ABI change it would be nice to change the soname next time, to avoid such issues
[14:30] <didrocks> and yeah, what seb128 told on ABI change
[14:31] <mandel> seb128, didrocks I would if I had known that it was using the lib and not the dbus methods as it was, it is not part of the test plan in the download manager
[14:31] <mandel> seb128, didrocks we, for example, landed click-scope with udm because that abi change
[14:32] <mandel> popey, by the way, if the click scope broke during your tests, it is expected due to that ^
[14:32] <popey> didnt see that, but noted
[14:32] <didrocks> mandel: I guess you need to coordinate with gatox, he did the client-side work
[14:32] <mandel> seb128, didrocks I'll add it to the test plan, at that point in time there was nothing I could do due to lack of knowledge
[14:32] <sergiusens> rsalveti: then we are good
[14:32] <seb128> mandel, thanks
[14:32] <sergiusens> rsalveti: ricmm build still failed for media-hub though
[14:33] <jfunk> mardy: best thing is to talk with the landing team, asac may be able to give you more information they are starting with a very limited number of projects to do a proof of concept
[14:33] <didrocks> mandel: thanks
[14:33] <mandel> seb128, does make & make install work with system settings?
[14:33] <mardy> jfunk: IIRC asac told me to talk to you :-)
[14:33] <mandel> seb128, so that I can test locally in my phone with a simple rebuild
[14:33] <seb128> mandel, I guess so, I use bzr bd; dpkg -i usually
[14:33] <jfunk> mardy: lol
[14:34] <jfunk> mardy: ok let me talk with the AP team and get back to you
[14:34] <mardy> jfunk: thanks :-)
[14:34] <mandel> seb128, good, I since udm is there correctly and there is no need for a ppa
[14:34] <seb128> mandel, maybe easier to take the debs from a recent jenkins build
[14:34] <seb128> e.g https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/ignore-updates-autopilot/+merge/218481
[14:35] <mandel> seb128, I need to rebuild, remember, abi changes (and cpp does funny things when you change the headers)
[14:35] <seb128> popey, ^ you might want to test that as well, if the deb from there fix u-s-s on the current image
[14:35] <seb128> mandel, well, that jenkins build is from 18 hours ago, I guess it used the current u-d-m version/abi?
[14:36] <mandel> seb128, oh, sorry, it is build agains the current then it will ok, sorry, mis understood
[14:36] <seb128> that's assuming that builds in jenkins happen on utopic
[14:36] <seb128> I didn't check
[14:36] <sergiusens> didrocks: does the choochoo bot need to be restarted? not seeing any updates for a while now
[14:36] <seb128> sil2100, ^ do you know for my question?
[14:36] <sil2100> seb128: let me backlog
[14:37] <seb128> sil2100, well, it's one line
[14:37] <didrocks> sergiusens: where there any?
[14:37] <seb128> sil2100, are jenkins builds on mps using utopic by default?
[14:37] <sergiusens> didrocks: I set testing to yes 5 minutes ago to a silo
[14:37] <didrocks> sergiusens: which one?
[14:37] <sil2100> seb128: from what I remember, fginther was switching those to utopic by default now, so they should IIRC
[14:37] <sergiusens> didrocks: 008
[14:38] <seb128> sil2100, ok, good, thanks
[14:39] <didrocks> sergiusens: see the spreadsheet
[14:39] <didrocks> sergiusens: it's written QA needs to sign off
[14:39] <didrocks> because someone set QA needed to yes
[14:39] <sergiusens> didrocks: it's actually blank
[14:39] <fginther> seb128, sil2100, yes they are using utopic now
[14:39] <seb128> fginther, thanks
[14:39] <didrocks> sergiusens: it's not blank?
[14:39] <popey> seb128 / mandel sure, I can test a deb on my flo device, if there is one.
[14:39] <ogra_> didrocks, thats a leftover  from pre-release
[14:39] <didrocks> sergiusens: column H
[14:40] <didrocks> ogra_: I guess so
[14:40] <mandel> popey, will do the same in mako
[14:40] <seb128> popey, see the armhf zip on the current comment of https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/ignore-updates-autopilot/+merge/218481
[14:40] <didrocks> seb128: set it to no and it will be fine
[14:40] <ogra_> given we are not in traincon-red we should just switch it off
[14:40] <ogra_> done
[14:40] <sergiusens> didrocks: ah, it's blank here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=26
[14:40]  * seb128 hands didrocks an xchat-gnome
[14:40] <ogra_> sergiusens, wrong sheet
[14:40] <popey> thanks seb128
[14:40]  * didrocks doesn't take it just to keep pinging seb128 :p
[14:40] <seb128> popey, thank you for testing ;-)
[14:40] <sil2100> fginther: thanks :)
[14:40] <ogra_> ah, no, right sheet
[14:40] <sergiusens> ogra_: it says "new spreadsheet", is there a "new new spreadsheet"?
[14:41] <ogra_> sergiusens, the Qa stuff is set on the pending page
[14:41] <ogra_> i unset it
[14:41] <ogra_> should be fine now
[14:41] <sergiusens> ogra_: how much more time until we get a non scm style naming file.c.the_one_that_works file.c.use_this_one_now file.c.latest :-P
[14:42] <ogra_> heh
[14:42] <didrocks> sergiusens: until everyone see that the previous spreadsheet is dead, I'll keep the "new" in title
[14:42] <sergiusens> didrocks: that's fine; just making fun as ogra_ was telling me I was using the wrong one ;-)
[14:42] <didrocks> :p
[14:43] <ogra_> sergiusens, yeah, sorry ... just the wrong page, not the wrong sheet :)
[14:44] <mandel> seb128, didrocks, popey if this is the issue and since the qml for the download manager is seeded the best option will be to move system settings to use it, that way the abi problem will never happen again
[14:45] <didrocks> mandel: let's fix it first, please confirm that rebuilding is enough :)
[14:45] <didrocks> then, we can see what to do
[14:45] <popey> uh
[14:45] <popey>  ubuntu-system-settings : Depends: libtimezonemap1 (>= 0.4.3) but 0.4.1 is to be installed
[14:45] <didrocks> (but yeah, if the lib isn't private, breaking ABI == bumping soname)
[14:46] <popey> guessing because my flo is on #4 which is old... should I update to most recent before trying these debs seb128 mandel ?
[14:46] <seb128> popey, that would be best
[14:46] <didrocks> ogra_: yeah, I'm afraid you have to do that
[14:46] <seb128> if that's not an issue
[14:46] <ogra_> popey, yeah, we got that lib in a recent onr
[14:46] <ogra_> *one
[14:46] <popey> ok, will do
[14:46] <mandel> popey, yes, else you will have the wrong libs
[14:46] <didrocks> popey: why the hell are you on image #4?
[14:46]  * didrocks now runs very fast :p
[14:46] <ogra_> didrocks, what do i have to do ?
[14:47] <popey> hehe
[14:47] <popey> you guys
[14:47] <didrocks> ogra_: sorry, s/ogra_/popey/
[14:47] <didrocks> ogra_: but while you are here
[14:47] <mandel> popey, where can I grab the logs from system settings?
[14:47] <didrocks> ogra_: did you promote #15?
[14:47] <didrocks> (not remember seeing the marker)
[14:47] <ogra_> didrocks, not yet ... popey didnt give his ok yet :O
[14:47] <didrocks> popey: ? ^
[14:48] <popey> well, I'm not happy that users cant update apps
[14:48] <popey> but we already promoted 14
[14:48] <popey> ☹
[14:48] <didrocks> yeah, even 13 :p
[14:48] <popey> so yeah, 15 is no worse than 14
[14:48] <popey> IMO
[14:48] <popey> +1
[14:48] <didrocks> popey: maybe you should get that on dave's dogfooding plan?
[14:48] <ogra_> ok
[14:49] <popey> yeah, needs a bit of thought because we don't always have apps to update when dogfooding, probably needs us to roll an app or two back
[14:50] <didrocks> yeah
[14:50] <sil2100> sergiusens, mandel: so, I wanted to publish 008 - but it seems that the landing says it should have a ofono-phonesim should be dputted to the PPA, but I don't see it there
[14:51] <sil2100> sergiusens, mandel: is an ofono-phonesim upload required?
[14:51] <sergiusens> sil2100: yeah, noted; already told the right people about it
[14:51]  * ogra_ isnt sure you did :P 
[14:52] <sil2100> sergiusens: ok, thanks ;) Once it's dputted (or removed from the sources list), then we need to run build with 'watch only' - and probably retesting if a new source is added ;/
[14:53] <sergiusens> sil2100: the phonesim this is just for the dialer app tests
[14:53] <sergiusens> thing
[14:54] <sil2100> So at least re-running dialer-app/etc tests to make sure they still work
[14:59] <mandel> didrocks, seb128, popey lost connetion, so in case you did not get it, a simple rebuild is ok
[14:59] <didrocks> sweet!
[14:59] <popey> I'm still updating my flo
[14:59] <didrocks> sil2100: handling a landing for that? ^
[14:59] <popey> taking longer than expected
[14:59] <popey> oh, there we go
[14:59] <didrocks> seb128: finally, the bug should be opened against u-s-s :p
[15:00] <popey> BOOM!
[15:00] <mandel> popey, BOOM??
[15:00] <sil2100> didrocks, mandel: what is it about exactly? Too many topics moved at the same time ;)
[15:00] <popey> mandel: nvm ☻
[15:00] <mandel> popey, => https://plus.google.com/u/0/+ManueldelaPe%C3%B1a/posts?authkey=CIOk74Kq8-6HPA
[15:00] <seb128> mandel, thanks
[15:01] <mandel> popey, and sent it too you over g+
[15:01] <seb128> didrocks, I'm going to land some pending fix for landing
[15:01] <didrocks> seb128: ok, good :)
[15:01]  * seb128 does reviews
[15:01] <mandel> seb128, there is a link with a video with it working ^
[15:01] <seb128> mandel, I trust you ;-)
[15:03] <mandel> seb128, how do we deal with the bug?
[15:03] <seb128> mandel, I've some other changes to land, I'm working on that
[15:04] <seb128> mandel, I'm handling the bug
[15:04] <seb128> mandel, thanks for the help!
[15:04] <mandel> seb128, ok, sweet, anything else let me know :)
[15:04] <seb128> sure
[15:04] <didrocks> mandel: please update your testing plan :)
[15:04] <mandel> seb128, I'll make sure that this never happens again, will update the testing plan
[15:04] <mandel> didrocks, ^^ hehe
[15:04] <didrocks> mandel: great minds! :)
[15:04] <didrocks> thanks man
[15:05] <seb128> thanks again!
[15:06] <balloons> davmor2, do you notice if you let your device sit for several days it takes a long time to open after you turn it back on?
[15:09] <didrocks> ogra_: so promoting? :p
[15:09] <ogra_> [15:09] <didrocks> \o/
[15:09] <didrocks> \o/
[15:09] <didrocks> \o/
[15:09] <ogra_> (sorry, started it on another machine before going to meeting)
[15:09] <didrocks> ;)
[15:09] <didrocks> no worry, thanks!
[15:10] <popey> "yay"
[15:10] <popey> ☻
[15:12] <popey> mandel: seb128 tested those debs and they work. thank you
[15:12] <seb128> popey, great, thanks for confirming!
[15:12] <mandel> popey, yes, ABI bugs make logs very mysterious but are easy to fix :)
[15:13] <sil2100> \p/
[15:14] <sil2100> hm, a 'p' with hands in the air, that's something you don't see too often
[15:14] <sergiusens> sil2100: seems we don't need the phonesim upload, that's already in https://code.launchpad.net/~tiagosh/ubuntu/trusty/ofono-phonesim/fix_ofonod_crash/+merge/215002
[15:15] <sil2100> sergiusens: \o/ awesome news then
[15:15] <sil2100> sergiusens: let me reconfigure, run a watch only build and publish
[15:15] <didrocks> sil2100: you don't need that
[15:16] <didrocks> sil2100: if you force the publication, it will unsuscbribe ofono-phonesim for you
[15:16] <didrocks> it's an ignore option
[15:16] <sil2100> didrocks: you think a force will be better? Ok ;)
[15:16] <didrocks> yeah, it's doing it for you
[15:16] <didrocks> I handled that case so that we don't have the rest to do ;)
[15:17] <sergiusens> didrocks: sil2100 fwiw; the archive has the change as well https://launchpad.net/ubuntu/+source/ofono-phonesim
[15:17] <sil2100> didrocks: well, I think I'll prefer doing a watch only build, as from what I see in the logs, I'm not sure if he'll catch the other 2 source uploads then, as citrain says: "Some projects (lxc-android-config, network-manager, ofono-phonesim) that were (...)", so it might not upload the 2 others
[15:18] <didrocks> sil2100: ah yeah, for the other, you need :)
[15:18] <sil2100> By a reconfigure + watchonly I'll be at least sure we're fine ;)
[15:19] <seb128> gatox, can I do anything to help with the ~diegosarmentero/ubuntu-system-settings/duplicate-and-credentials build issue? I still have it with your recent commit (on i386)
[15:21] <gatox> seb128, :S i don't know... i can't reproduce it neither on the desktop or the phone
[15:21] <plars> sergiusens: where's the right place to get click from for precise? phablet-tools in the phablet-team ppa depends on it, but it's not in the archive or the phablet-team ppa
[15:25] <seb128> gatox, :/
[15:25] <seb128> gatox, is there any info I can provide that would be useful?
[15:26] <gatox> seb128, no... i would need to debug it... let me try something and i'll ping you later so you can try again, ok?
[15:26] <seb128> gatox, ok
[15:26] <sergiusens> plars: the sdk ppa
[15:27] <sergiusens> plars: fwiw, I'm waiting on a packaging review from rsalveti to sort that :-)
[15:27] <rsalveti> sergiusens: the split?
[15:27] <rsalveti> need to get to that
[15:27] <sergiusens> rsalveti: yeah
[15:27] <plars> sergiusens: awesome :)
[15:29] <seb128> gatox, if I comment the line where it fails, it fails on the next one
[15:29] <seb128>    Actual   (manager.get_model().size()): 0
[15:29] <seb128>    Expected (1)                         : 1
[15:29] <plars> sergiusens, rsalveti, ogra_: you all might be interested in this... wgrant sort out our odd problem with those 4 devices
[15:29] <rsalveti> plars: what was it?
[15:29] <plars> something was wrong with userdata
[15:29] <plars> rsalveti: it just needed to be reformatted
[15:29] <seb128> gatox, it's like the getCredentials was buggy
[15:29] <rsalveti> plars: ouch
[15:29] <sergiusens> plars: yeah, I suspected that; but fastboot -w does reformat the userdata part
[15:30] <plars> theory is that the same thing could happen if you started out with android and had turned on encryption, but I haven't tried this
[15:30] <sergiusens> so I wonder why it didn't work then
[15:30] <plars> sergiusens: apparently not
[15:30] <plars> sergiusens: I tried fastboot -w
[15:30] <plars> sergiusens: but it didn't help
[15:30] <plars> sergiusens: fastboot format userdata on the other hand, fixed them all right up
[15:30] <sergiusens> so how was it reformatted?
[15:30] <sergiusens> ok
[15:30] <gatox> seb128, no, i think it's something else
[15:30] <sergiusens> sorry about that; need to check the help in detail
[15:30] <plars> sergiusens: this might be something we should do in u-d-f if calling --bootstrap or --wipe, do you think?
[15:31] <sergiusens> plars: yeah, that's what I told you I had in before and caused 'soft' bricks for some people with old bootloaders
[15:31] <plars> sergiusens: ouch :(
[15:31] <sergiusens> plars: but I'll add it anyways
[15:32] <sergiusens> as I prefer that anyways
[15:32] <plars> sergiusens: cool, thanks
[15:35] <seb128> gatox, is that normal that m_validCredentials is never set anywhere?
[15:35] <seb128> gatox, if I drop the if(m_validCredentials) in FakeSsoService::getCredentials() then the tests is ok
[15:36] <gatox> seb128, which file?
[15:36] <seb128> gatox, tests/plugins/system-update/fakessoservice.cpp
[15:36] <seb128> gatox, or diff on https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/duplicate-and-credentials/+merge/218414
[15:37] <seb128> gatox, you define it as a private variable, have a setter but nothing is setting it/calling the setter
[15:37] <gatox> seb128, ah right... that should be true by default... adding that change..... funny thing it didn't fail on 64 or arm
[15:37] <seb128> gatox, great, I think that's enough to fix it ;-)
[15:38] <gatox> seb128, pushed
[15:38] <gatox> seb128, try now please
[15:43] <seb128> gatox, works \o/
[15:43] <gatox> seb128, awesome
[15:58] <popey> can someone scroll down on a device on the app lens and see if you see all expected apps?
[15:58] <popey> I cannot see my own webapps in the "Available" category.
[15:59] <popey> I see it in the search, but they dont appear when scrolling
[15:59] <ogra_> popey, only a very limited set
[15:59] <popey> yeah.
[15:59] <ogra_> i cant scroll very far
[16:00] <ogra_> two pages perhaps ...
[16:00] <ogra_> where it was five to ten before
[16:00] <popey> same
[16:00] <ogra_> ARGH !"!!
[16:00] <ogra_> why does the screen not switch on when we get alarms
[16:00] <ogra_> thats really annoying
[16:01] <popey> https://code.launchpad.net/~thomas-voss/platform-api/hw-alarms-api/+merge/210592
[16:01] <popey> I believe that's what you're after
[16:01] <ogra_> aha, tvoss is holding it back :P
[16:02] <didrocks> popey: c o m i n g ?
[16:02] <popey> yeah
[16:11] <ogra_> popey, i wonder if lool dropped the 13.10 api when he added the new -dev one
[16:11] <ogra_> looks like its all old apps that are missing
[16:12] <ogra_> (and i have a good bunch i cant port to the new one)
[16:12] <popey> i still see them in /usr/share/click/frameworks
[16:12] <ogra_> hmm, k
[16:13] <ogra_> probably a ser4ver side issue
[16:14] <popey> ogra_: yes, this is a backend issue IMO
[16:15] <popey> my script which pulls every single click only returned 100 clicks yesterday
[16:15] <popey> 281 the day before
[16:15] <popey> 100 seems too round
[16:15] <ogra_> oh, yeah
[16:16]  * popey pokes bueno
[16:17] <ogra_> http://www.zucker-baron.ch/images/product_images/original_images/kinder_bueno.jpg might help :)
[16:26] <ogra_> didrocks, before you leave for new duties you need to teach sil2100 about the G+ thing so i have something to share each evening ;)
[16:26] <sil2100> uh oh
[16:26] <didrocks> ogra_: ahah, I'm sure he can discover ;)
[16:26] <ogra_> :)
[16:26] <sil2100> Eeeek!
[16:26] <sil2100> ;p
[16:27]  * ogra_ has 400 follower waiting for it every evening ... (well 30 of them wiat perhaps :P )
[16:30] <didrocks> :)
[16:32] <sil2100> Oh my ;p
[16:42] <Saviq> plars, I'm not, ap folks are, pre-release
[16:43] <Saviq> plars, I think it best to default, not hardcode, if not overly complex
[16:43] <plars> Saviq: sure, do you know who set up that job originally?
[16:43] <Saviq> plars, nope :|
[16:44] <plars> Saviq: np, I'll fix it and check around on that to make sure it's not going to revert back
[16:45] <Saviq> plars, thanks
[16:47] <balloons> fginther, re: https://code.launchpad.net/~fginther/cupstream2distro-config/coreapps-utopic/+merge/218653. So the *-al.cfg file is just for the mako enabled jobs? hence why clock is the only one?
[16:49] <balloons> fginther, I think we should also consider cleaning up the projects
[16:51] <fginther> balloons, yes on the -al.cfg is to perform testing no the makos
[16:52] <fginther> balloons, and clock was the first one setup for that
[16:52] <fginther> balloons, if there are projects to purge, now would be a good time
[16:52] <balloons> yep, makes sense. So for cleanup, I can list them in a comment on the merge I guess
[16:52] <fginther> balloons, that will work
[16:55] <balloons> fginther, done
[16:56] <fginther> balloons, thx
[16:56] <balloons> fginther, I'm also quasi considering putting pep8 and pyflakes hooks on everything, but it's likely to be a little painful ;-)
[17:11] <balloons> fginther, I created a bug instead to track the apps that need it (pep8 and pyflakes)
[17:11] <balloons> https://bugs.launchpad.net/dropping-letters/+bug/1317198
[17:13] <lool> ogra_: I did not drop any API
[17:13] <lool> popey: ^
[17:13] <ogra_> lool, yeah, seems to be a server side issue
[17:14] <ogra_> only returns 100 entries
[17:14] <lool> ogra_, popey: So FYI, the new frameworks are in utopic and were uploaded to trusty-proposed; I think there might be a PPA I have to push to for the SDK to pick them up
[17:14] <popey> ok
[17:14] <lool> but waiting for the trusty-updates transition before I put it there
[17:14] <ogra_> yeah
[17:15] <popey> so at least a week while they bake in proposed
[17:15] <lool> popey, ogra_: We can add the 14.10-dev1 frameworks any time you guys like
[17:15] <lool> perhaps for new scopes
[17:15] <ogra_> popey mentioned today that there are apps already ready for using it
[17:16] <ogra_> so yeah, would make sense
[17:19] <popey> yeah, makes sense to get them in as soon as possible
[17:20] <popey> ogra_: where do you think this 100 clicks bug should go?
[17:20] <ogra_> dunno, either the click scope or ask beuno ... no idea where server bugs go
[17:21] <popey> its not click scope, but backend
[17:22] <ogra_> right
[17:23] <seb128> ogra_, popey: want to test the u-s-s on https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+packages to confirm it's working for updates?
[17:27] <popey> seb128: ogra_ yes, I'll test it after dinner
[17:28] <ogra_> ah, thanks ...
[17:28] <seb128> popey, thanks, enjoy dinner!
[17:28] <ogra_> popey, your seed merge will be in by then :)
[17:28]  * ogra_ is just doing it 
[17:28] <ogra_> sorry that it took so long
[17:49] <gatox> seb128, are you still around?
[17:55] <popey> seb128: ogra_ confirmed after clean-wipe flashing flo and adding the two debs from that ppa, i can now update. silo 009 looks good.
[17:56] <ogra_> yay
[18:05] <popey> do i need to ping robru to let him know silo 009 is good?
[18:06] <robru> popey, well you just did ;-)
[18:06] <popey> \o/
[18:06] <robru> popey, ideally you'd mark 'tested: yes' in the spreadhseet though
[18:06] <popey> i have no idea what spreadsheet that might be
[18:07] <popey> gimmie a link and I will
[18:07] <robru> popey, really? you don't follow the landing spreadsheet? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=0
[18:07] <popey> no, i do not
[18:07] <robru> there's a tab for every silo
[18:07] <popey> i have no edit rights \o/
[18:08] <robru> popey, alright don't worry about it then.
[18:08] <popey> thanks
[18:08] <robru> seb128, what's the deal with silo 9? popey says it's good. you ready to publish or are you still working on it?
[18:09] <ogra_> it is just a rebuild anyway
[18:09] <ogra_> no changes
[18:09] <robru> oh right
[18:09] <robru> ok, will publish
[18:10] <Laney> is it?
[18:11] <Laney> Looks like it included a couple of merge proposals to me
[18:12] <fginther> balloons, I've removed the requested builds from the core-apps config file.
[18:17] <balloons> fginther, ohh right stock-ticker..
[18:18] <balloons> I guess we just leave it for now, I'm not really sure.
[18:22] <ogra_> Laney, oh, bah ... i thought it was solely for the updater fix
[18:37] <seb128> gatox, yes
[18:37] <seb128> popey, thanks
[18:37] <seb128> ogra_, Laney, robru: indeed, it includes some bugfixes and changes as well, I'm going to publish it
[18:38] <ogra_> seb128, already happened
[18:38] <gatox> seb128, do you know which is the proper way to push a page into the main area of system settings?? i was doing this: pageStack.push(pluginManager.getByName("system-update").pageComponent); and i want to be sure, that is not the problem
[18:38] <seb128> saw that
[18:38] <seb128> great, it means I don't take responsibility for pressing the button ;-)
[18:39] <ogra_> haha
[18:39] <ogra_> blame me if something goes wrong ... i claimed it is ready
[18:39] <seb128> gatox, that seems right to me as well
[18:40] <gatox> seb128, ok... just wanted to be sure
[18:56] <boiko> bfiller: fginther: hi, would it be possible to get CI and autolanding configured for this branch: https://code.launchpad.net/~phablet-team/dialer-app/staging ?
[18:56] <fginther> boiko, yes, I'll let you know when it's ready
[19:00] <cyphermox> Wellark: when do you do your connectivity/flight mode landing?
[19:01] <Wellark> cyphermox: should get a silo tomorrow morning
[19:01] <cyphermox> oh
[19:01] <cyphermox> well if you don't even have a silo...
[19:01] <Wellark> then based on testing I would say on Friday night
[19:01] <Wellark> well, was waiting on silo8
[19:01] <Wellark> but that landed now
[19:01] <cyphermox> we're close enough with MMS that I think we could do flight mode in parallel tomorrow, maybe?
[19:02] <Wellark> that could  work
[19:02] <Wellark> but it's not a big deal for me to temporarily disable the flightmode bits from my code either
[19:02] <cyphermox> I'll ask for a silo and pester tiago for the telepathy-ofono changes
[19:02] <cyphermox> Wellark: it's taken long enough anyway, I need to land this soon too, if it works
[19:03] <cyphermox> disable your flight mode parts for now, but I'll still try to land that this week
[19:03] <Wellark> I don't want to rush, I just want to have a clear idea on what needs to happen for urfkill and when it could land
[19:03] <Wellark> sweet :)
[19:03] <cyphermox> that way then just the SDK flight mode bits are easy to add and land afterwards
[19:04] <Wellark> yep. works for me
[19:04] <cyphermox> good
[19:05] <Wellark> I only need to add two #if 0 blocks to my code for now
[19:08] <popey> robru: were you planning on kicking an image today or leaving it for the 3am cron job?
[19:08] <robru> popey, oh yes, thanks
[19:09] <robru> ogra_, cyphermox: can we get an image kicked? didrocks asked for one after system settings landed, and it's landed
[19:09] <ogra_> yup. on it
[19:09] <robru> ogra_, thanks
[19:09] <ogra_> triggered ..
[19:10] <cyphermox> ah, thanks ogra
[19:13] <cyphermox> awe_: if you don't object I'd ask for a silo for flight mode now
[19:13] <cyphermox> and we can upload a telepathy-ofono tomorrow morning
[19:13] <awe_> cyphermox, let me give you an ack on this bug fix first
[19:14] <awe_> gimme 1/2h
[19:14] <cyphermox> ok
[19:14] <awe_> just downloading now
[19:14] <cyphermox> we'll ask tiago for the telepathy-ofono change, my attempt failed in my ppa (tests don't pass)
[19:14] <imgbot> [19:21] <robru> bregma, for line 23, is all that stuff fixed in utopic already?
[19:22] <bregma> robru, nope, we haven't branched, we're still just doing SRUs (which should land in both)
[19:22] <bregma> they're all SRU-ready, though
[19:23] <robru> bregma, k, because now that utopic is open, SRUs have to land in utopic before being SRU'd. so I'll assign your silo for utopic, ok?
[19:23] <bregma> that would be my preferred modus operandi
[19:23] <robru> bregma, excellent, thanks
[19:24] <bregma> land in utopic, pocket copy after SRUs are acked
[19:25] <robru> bregma, yeah
[19:39] <awe_> cyphermox, looks like you nailed it
[19:40] <awe_> cyphermox, that said.. you mentioned that the package doesn't currently create /var/lib/urfkill.  Do you need to fix that before creating the silo?
[19:41] <cyphermox> already fixed
[19:41] <cyphermox> let me double-check
[19:42] <cyphermox> yeah it's already there
[19:45] <balloons> fginther, can I get access to the debs built by jenkins as part of http://91.189.93.70:8080/job/generic-mediumtests-trusty/2485/?
[19:56] <fginther> balloons, I can add them to the artifacts collected
[19:57] <balloons> fginther, well I'm really trying to figure out what's going on with reminders in jenkins, and I noticed it's using the plugin it builds, while locally I'm using the installed version of the plugin. So it might be nice for sanity sake. Although, I'm curious now to try reminders via click testing
[19:58] <balloons> I'm trying to emulate the one-off runs you did to see if it will work or not
[20:00] <fginther> balloons, I should have them for you in a few minutes
[20:01] <balloons> :-) awesome
[20:06] <fginther> balloons,tThe artifacts from that MP are here: http://91.189.93.70:8080/job/generic-mediumtests-trusty-fjg/1/. Now that I know it works, I'll get the artifacts added to the main jobs
[20:07] <balloons> fginther, cool.. Now interestingly, will we still be building these after we migrate to click?
[20:08]  * balloons notes we should also seek to provide the click package in those cases
[20:09] <fginther> balloons, what is the support case for deb packages for the apps? If that needs to continue to be supported, then yes, I'd like to keep this around in jenkins
[20:10] <fginther> balloons, the building testing of click packages needs to be added, that would allow jenkins to then provide the click package
[20:11] <balloons> fginther, seems like the core apps ppa which I thought was going to languish is going to continue.. if as popey mentioned, there are folks using the apps on the desktop, they will be doing so via deb packages for the forseeable future
[20:29] <imgbot> [20:29] <imgbot> [20:31] <kgunn> robru: so just a question about packages and series transitions....does it ever happen where a new package could have been going through the process of being added to the archive, but then got stuck in proposed ?
[20:31] <kgunn> we thot glmark2-es2-mir would be in universe, but seems its still inthe proposed pocket of trusty ?
[20:31] <kgunn> josharenson: ^ this is how we check :P
[20:31] <robru> kgunn, oh yes, absolutely... stuff gets stuck there all the time for various reasons.
[20:31] <josharenson> kgunn, ha alright
[20:32] <kgunn> robru: what's your suggested course of action? ...should we do a rebuild MP to get it into utopic ? or ?
[20:32] <robru> kgunn, the silos will tell you after the publish job has been run, but here's the page that shows all the stuff currently in proposed: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[20:32] <robru> kgunn, the first step is to figure out why it's blocked ;-)
[20:33] <robru> kgunn, so I dont actually see that in the list... what's the source package name?
[20:35] <kgunn> robru: i think the package name is glmark2
[20:35] <kgunn> which has been in universe
[20:36] <kgunn> but we were updating to include a new exe...glmark2
[20:36] <kgunn> sorry glmark2-es2-mir
[20:36] <robru> kgunn, so nothing is in proposed: https://launchpad.net/ubuntu/+source/glmark2 what gave you that idea?
[20:37] <kgunn> josharenson gave me that idea.... josh ?
[20:38] <josharenson> kgunn, robru looking...
[20:39] <robru> kgunn, it doesn't look like there's ever been a train landing for that package... not judging by the version number anyway
[20:40] <kgunn> josharenson: robru is right, unless someone else helped you try to "land it"....
[20:40] <kgunn> robru: thanks...we'll go do some digging
[20:40] <robru> josharenson, kgunn last upload was by rsalveti, maybe he was working with you on that?
[20:40] <robru> kgunn, no worries, I'm around to help if you need a landing done...
[20:41] <josharenson> doesn't sound familiar... I figured that since it was in staging, it was proposed
[20:42] <robru> josharenson, what's staging? is that a PPA? -proposed is a real place that's kind of like a PPA but has it's own special meaning.
[20:43] <josharenson> https://launchpad.net/~mir-team/+archive/staging
[20:44] <josharenson> robru, yes its in trusty but not utopic... How can I move to proposed?
[20:44] <kgunn> josharenson: ok...i think i got it figured...give me some moments
[20:47] <robru> josharenson, if you want to rebuild the package for utopic within staging PPA, you can pocket copy from the PPA into itself (there's an option to rebuild for a different series). if you want to release to distro then you either need a silo (from me) or a direct upload from somebody with upload rights (some core dev, not me)
[20:47] <boiko> robru: not important, but I just noticed that the landing-003 page on the spreadsheet doesn't have the PPA link at the top
[20:48] <robru> hm
[20:48] <josharenson> robru ack
[20:51] <popey> can anyone reproduce https://bugs.launchpad.net/ubuntu/+source/mtp/+bug/1317263 please?
[20:51] <popey> its easy ☻
[20:52] <robru> boiko, fixed the PPA link
[20:55] <boiko> robru: nice! thanks
[20:59] <robru> you're welcome
[21:01] <pmcgowan> popey, but I dont have any Amy Winehouse
[21:01] <popey> hah
[21:03] <cjwatson> easy to fix, just buy some from Ubuntu O...oh wait
[21:04] <pmcgowan> heh
[21:07] <boiko> robru: landing-003 tested and ready to go
[21:13] <robru> boiko, excellent, publishing
[21:17] <bregma> I'm getting an ICE compiling for arm64 ...  is the tool chain known to be unstable on that arch?
[21:31] <xnox> bregma: please file bug report with pre-processed source file, recent gcc with split out a paragraph of text with path to that tmp file.
[21:31] <xnox> s/with/will/
[21:31] <xnox> s/split/spit/
[21:32]  * xnox should go to sleep, typing like that.
[21:33] <bregma> xnox, it's in a PPA builder, all I have is a build log
[21:34] <bregma> https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+build/5987360 if it makes any difference
[21:36] <xnox> bregma: fun, can you open a bug about it, against unity package, and assign to me with that url?
[21:37] <xnox> bregma: i'll see if i can get into our arm64 builders and reproduce the ice, if i can, i will then forward it to doko.
[21:38] <bregma> my experience with ICEs is half of them are elusive ghosts
[21:39] <rsalveti> robotfuel: kgunn: last time I uploaded it I was still in linaro :P
[21:39] <rsalveti> so yeah, we never had a landing for it
[21:46] <bregma> xnox, https://bugs.launchpad.net/unity/+bug/1317276
[21:57] <xnox> bregma: thanks.
[22:01] <cjwatson> bregma: The ones that are completely elusive are flagged as such; these days gcc tries the compile backend again if it hits an ICE so that it can tell you whether it's an unreproducible failure
[22:02] <cjwatson> which it hasn't done here AFAICS
[22:02] <cjwatson> I wouldn't in general say the toolchain is unstable given that it compiled most of Ubunt u:)
[22:02] <cjwatson> s/ u:/u :/
[22:03] <bregma> I'm just thinking back to the EGCS ICE that happened when your RAM got warm and the solution was to power down for half an hour then retry your compile
[22:03] <bregma> but perhaps I date myself
[22:08] <bschaefer> haha that sounds horrible
[22:11] <cjwatson> bregma: just a bit :-)  but that kind of thing is why gcc tries twice now, so that it can report that more accurately
[22:12] <cjwatson> bregma: failures that happen twice in a row (like this one apparently did) are probably not hardware glitches like that
[22:46] <thomi> robru: I wonder if I could get a silo for row 24 please?
[22:47] <robru> thomi, hm, it's not marked as 'ready' ;-)
[22:47] <thomi> robru: 'MP Ready?' is set to 'No' because there's a small flake8 issue that we're fixing
[22:47] <thomi> robru: but that shouldn't stop us from building & testing
[22:47] <thomi> I can set it to 'Yes', if it'll make you feel better :)
[22:47] <robru> the 'ready?' column specifically means "are you ready for us to give you a silo?"
[22:47] <thomi> oh
[22:48] <robru> the bot even pings me when you mark it as 'yes' ;_)
[22:48] <thomi> the column header says 'MP following guidelines'
[22:48] <thomi> maybe that should be renamed then :)
[22:48] <thomi> there you go :)
[22:48] <robru> thomi, I guess we have different guidelines ;-)
[22:48] <robru> thomi, ok you got silo 3
[22:48] <thomi> thanks!
[22:49] <robru> you're welcome!
[23:27] <robru> I'm off to the doctor, will be back to handle any landing requests in ~2hrs