[03:14] <veebers> trainguards: anyone around perchance?
[04:53] <Mirv> veebers: now there is
[04:54] <veebers> Hi Mirv o/ :-)
[04:54] <veebers> Mirv: I'm wondering 2 things, one why did using the silo process to release a branch add a bunch of details to the changelog: http://bazaar.launchpad.net/~canonical-platform-qa/autopilot/overlay/view/head:/debian/changelog
[04:55] <veebers> secondly is there a way to rectify that or is changing that in the next release bad-form
[04:55] <Mirv> veebers: o/
[04:55] <Mirv> veebers: 1. autopilot fills in the changelog automatically always from the commit messages, although potentially if you edited changelog yourself it shouldn't have done that (I'm not sure about the current implementation)
[04:56] <Mirv> veebers: I don't think it's a bad thing if you manually edit the changelog for the next release
[04:56] <veebers> Mirv: this is the MP that was used for that silo release
[04:56] <veebers> err, this one: https://code.launchpad.net/~canonical-platform-qa/autopilot/overlay_fix-touch-device/+merge/264092
[04:56] <veebers> I'm not sure where all the other details came from.
[04:57] <veebers> Mirv: at any rate, I can change the changelog to make more sense for the next release (will probably be tomorrow now)
[04:58] <Mirv> veebers: it's possible it wouldn't have change the changelog if you would have set the last release to UNRELEASED instead of wily in the changelog. now it added its own. but it think it's adding all the commit messages for commits that were in that branch but were not yet at lp:autopilot/overlay before the branch
[04:59] <veebers> Mirv: ugh, so it's totally my fault then, that should have been UNRELEASED somehow (probably me screwing up a merge) broke that
[05:00] <Mirv> veebers: this probably wouldn't happen with a normal release process, ie if lp:autopilot/overlay actually matched what is in archives. since you have a custom process (you had your own autopilot (1.5.0) UNRELEASED; urgency=medium in the branch so the branch was not handled only by the train before), it's always a bit more fragile/delicate on how train needs to be guided in that case.
[05:00] <Mirv> veebers: ok, that's probably it then especially if your previous releases have gone according to the planning :)
[05:01] <veebers> Mirv: ah right, makes sense. Annoying that I almost made a 'normal' release, and I'm about to do that again.
[05:01] <Mirv> hehe :)
[05:01] <veebers> I'll fix up the changelog log details for that though. Thanks for clarifying that
[05:02] <Mirv> I'm happy you feel clarified, I'm myself always a bit puzzled with these changelog things ;)
[05:03] <robru> veebers: yeah this is a known train bug, don't have the number handy. It happens because you guys pre-merge your merges into one big mega-merge which has commits from your whole team. Train will generate sensible changelogs if you put individual merges into the silo without pre-merging
[05:05] <robru> veebers: it's on the radar to be fixed, for now i recommend writing your own changelogs
[05:06] <veebers> robru: ack, I understand that it was triggered this time because there wasn't a 'UNRELEASED' stanza in the log?
[05:07] <robru> veebers: yeah that to, when you write your own you need to mark the entry UNRELEASED or the train will make a new entry for you.
[05:12] <veebers> robru: ah ok, right so as Mirv mentioned had it been 'UNRELEASED' I wouldn't have seen this. I'll keep that in mind. Cheers all
[05:13] <robru> veebers: yeah the unreleased thing isn't a bug, you need to do that. But i mean the terribleness if the generated changelog is a bug that I'll work on after the spreadsheet replacement goes live, so you won't need to generate your own changelog at all.
[05:15] <veebers> robru: ack thanks for clarification
[05:16] <robru> veebers: you're welcome!
[05:23] <Mirv> robru o/
[05:23] <robru> Mirv: how's it going? I'm winding down
[05:28] <Mirv> robru: very well, ~well slept nights here nowadays so it's pretty good. good night!
[05:30] <robru> Mirv: Ooooooooooh yeah i forgot you have a newborn! Crazy. Goodnight!
[05:35] <Mirv> :)
[05:36] <Mirv> GCC5 transition of Qt nearing completion probably today
[06:30] <AmyQuan> +
[08:19] <sil2100> davmor2: hey, did you fill in a bug for the missing icons after OTA upgrade?
[08:20] <davmor2> sil2100: nope but I can I was still trying to figure out what exactly the problem was when everything I could dig into registered correctly
[08:20] <davmor2> sil2100: was it the delta?
[08:20] <davmor2> sil2100: and I'll file one now
[08:29] <sil2100> davmor2: I want to dig deeper, but I would say it's the delta's fault
[08:29] <sil2100> I'm feeling a bit under the weather today, but I'll try digging into that if I have the chance
[08:30] <davmor2> sil2100: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1474739
[08:30] <sil2100> davmor2: thanks!
[08:30] <Mirv> sil2100: FYI I start to be ready with Qt GCC5 transition.. it seems Steve is handling at least some of the other touch stack transition?
[08:31] <sil2100> Mirv: I talked with Steve and he was supposed to send me a list of packages he wants me to help out with
[08:31] <sil2100> But my mailbox is empty!
[08:31] <Mirv> sil2100: :)
[08:32] <Mirv> sil2100: maybe he's building first batch now at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages as it looks and then asks for help for fixing those that don't build without changes
[08:38] <sil2100> davmor2: hm, could you try something? I just want to confirm something - could you flash your arale to '2' and then OTA to '3'? Can you do that somehow?
[08:40] <davmor2> sil2100: not that I am aware of I think it only does latest let me have a look at the system-image-cli options
[08:45] <sil2100> davmor2: ok, well, I'm pretty sure it would be broken anyway... checking the custom tarball delta now
[08:46] <sil2100> hmmmm
[08:48] <sil2100> davmor2: now this is interesting, I would really like to know if OTAing to 3 results with the same problem
[08:48] <sil2100> As the delta for 3 from 2 has the correct custom.key
[08:49] <davmor2> sil2100: trying out --build to see if taht will update me to 3
[08:49] <sil2100> So either something in the upgrader is busted and it doesn't apply this at all, or maybe there's a breakage that causes the custom delta not being properly applied for the case of an upgrade from 2 to 4, where the 3rd upgrade is missing
[08:49] <sil2100> davmor2: thanks!
[08:53] <sil2100> davmor2: do you know if we have any upgrade logs?
[08:54] <davmor2> sil2100: no idea
[08:56] <sil2100> davmor2: did the --build parameter work?
[08:59] <davmor2> sil2100: I think it conflicted with image 4 that had downloaded in the background I have a cunning plan though https://www.youtube.com/watch?v=pKRxX3s3JlM
[09:01] <sil2100> hoho, nice one
[09:01] <sil2100> ;)
[09:01] <sil2100> I just hope your cunning plan is better!
[09:12] <davmor2> sil2100: nope I just get a black screen so that didn't go so well :(
[09:12] <sil2100> :<
[09:13] <davmor2> sil2100: cunning plan number 2
[09:14] <sil2100> I'm checking the code in the meantime
[09:19] <sil2100> davmor2: hmmm, once you try your cunning plan, could you maybe run system-image-cli upgrade from 2 to 4 with --dry-run and -vvvv ?
[11:58] <mzanetti> sil2100, hey, please drop unity-api from the ppa of silo 48
[11:58] <sil2100> mzanetti: on it
[11:58] <mzanetti> thanks mate
[11:59] <sil2100> mzanetti: done
[12:02] <mzanetti> sil2100, I've read a mail somewhere that you're in charge of the phone image seed now
[12:03] <mzanetti> sil2100, I've a project here for receiving/sending files via bluetooth
[12:03] <mzanetti> can we add qml-module-qtbluetooth to the seed?
[12:04] <mzanetti> I'll do some more evaluation, but at least for allowing an app to search for devices it's working fine already
[12:05] <sil2100> mzanetti: hm, ok, makes sense
[12:06] <sil2100> Let me add that to my TODO list for today
[12:06]  * sil2100 goes prepare lunch
[12:34] <Mirv_> mzanetti: sil2100: yeah I've been waiting on someone to request it but so far no-one really has. but it's a stable upstream module nowadays. my only thought at some point was if we want to restrict Bluetooth usage to some hub or such.
[12:35] <Mirv_> mzanetti: sil2100: but all of our current Bluetooth code (obviously) uses bluez directly, I wonder if some would then want to migrate using Qt Bluetooth...
[12:37] <mzanetti> Mirv_, not sure what you mean with restricting it to the hub
[12:38] <mzanetti> Mirv_, so my project actually is a content hub plugin to share files via BT
[12:38] <mzanetti> Mirv_, however, for things like SPP that won't work
[12:38] <mzanetti> it's used for multiplayer games etc
[12:38] <mzanetti> needs direct access to the stack... we still need an apparmor profile tho to enable it
[12:39] <mzanetti> for now I plan to publish my stuff unconfined in OpenStore, and then check out what needs to be done to either move it into the image or the official store
[12:41] <Mirv_> mzanetti: I was thinking about something like "share files only via content-hub" or such
[12:41] <Mirv_> but then again, many kinds of BT apps are possible so that'd be quite limiting
[12:42] <mzanetti> Mirv_, yeah well... I guess you can do this:
[12:42] <mzanetti> either you request BT apparmor permissions and can connect to other devices,
[12:42] <mzanetti> or you don't do that and just invoke contenthub with the preexisting BT plugin
[12:42] <Mirv_> mzanetti: yep, makes sense. I'm absolutely for adding it, I was just curious why no-one had requested it yet. (also, we had stuff like "we want Qt 5.4 because it supports Bluetooth LE" even though we didn't have Qt Bluetooth in use in the first place :D)
[12:43] <mzanetti> Mirv_, the BT LE discussion got quiet when it turned out we won't move to bluez5
[12:43] <mzanetti> but I've been talking to seb128 about that... we agreed that this discussion needs to get rolling again
[12:43] <mzanetti> at least the discussion :D not sure who will do it in the end :D
[12:46] <Mirv_> mzanetti: ouch, yes bluez5... long overdue, no-one to work on it
[12:48] <Mirv_> mzanetti: let's found a committee on discussing how someone would really need to ship bluez5
[13:08] <boiko> sil2100: hi, so, silo 8 is ready for QA to test, but because of the manual upload of telepathy-qt5, its status is shown as Failed to build
[13:16] <pmcgowan> sil2100, what was the conclusion on the update issue
[13:18] <Mirv> boiko: I'll run watch_only build job, maybe that's only thing that's needed
[13:21] <pmcgowan> or jibel ^^
[13:22] <Laney> psivaa / cihelp: hi, do you have anywhere I can file bugs on iso smoke testing?
[13:25] <jibel> pmcgowan, sil2100 was looking at the delta generation code, davmor2_ filed bug 1474739 but I don't have more info for the moment
[13:29] <pmcgowan> jibel, I think that should be "does not"
[13:29] <pmcgowan> davmor2_, did you check if any other elements get updated from the custom ball, like today scope?
[13:29] <jibel> indeed, fixed
[13:35] <fginther> Laney, psivaa stepped out for a bit, hopefully he has the answer when he's back online
[13:35] <Mirv> boiko: so the telepathy-qt5 was manually uploaded, not a sync? in that case the silo needs to be reconfigured
[13:36] <Mirv> looks so, uploaded by sil
[13:36] <Mirv> fixing
[13:38] <boiko> Mirv: yep, sorry, OTP, talk to you in a minute
[13:42] <psivaa> Laney: fginther: We have no project specifically for iso smoke testing, but ubuntu-ci-services is the general project we used to accept bugs
[13:42] <seb128> shrug
[13:43] <psivaa> there could be an option to select utah or anything else you're intending for
[13:43] <Mirv> boiko: ^ seems ok now
[13:43] <Mirv> or ^
[13:47] <boiko> Mirv: so, to explain the whole situation: a new telepathy-qt5 landed on wily, and we need to sync it back to vivid, but in order to do that we need to get the dependent packages updated too
[13:48] <boiko> Mirv: telepathy-qt5 is not a package we are upstream for, so it was a source landing (or a direct landing without even going through the citrain)
[13:54] <pmcgowan> sil2100, jibel so I am a little unclear if we released the ota or are waiting on something wrt the update glitch
[13:55] <sil2100> pmcgowan: BQ got the update, we'll release it to users on Monday
[13:55] <sil2100> As that was Alex's request
[13:55] <ogra_> what about meizu ? did that go out already ?
[13:55] <sil2100> Since BQ needs time to test, but they don't want to have a Friday release
[13:55] <sil2100> ogra_: no, we'll release both at once
[13:55] <ogra_> good
[13:56] <pmcgowan> sil2100, what about the custom tarball update bug
[13:56] <sil2100> pmcgowan: looking into that right now... looks like the files on system-image are fine, something probably goes wrong during update
[13:56] <pmcgowan> hmmm
[13:56] <sil2100> A Monday release gives us time to find the source of that too
[13:57] <pmcgowan> sil2100, do we need anyone else for that? barry?
[13:57] <sil2100> pmcgowan: I'll probably poke barry for that too
[13:58] <sil2100> Doing it now actually
[13:58] <barry> sil2100, pmcgowan hi
[14:05] <sil2100> davmor2_: you around?
[14:07] <AlbertA> fginther:  sorry missed your Q yesterday,  yes mir-clang-ts-wily-amd64-build should be enabled for lp:mir/ubuntu as well, thanks!
[14:13] <Mirv> boiko: ok!
[14:14] <boiko> rvr: so for silo 30, sorry for the unapproved MRs, I reviewed the code and tested from the silo, forgot to approve them, all approved now
[14:15] <rvr> boiko: Ack
[14:20] <sil2100> rvr: hey! You have an arale, right?
[14:20] <rvr> sil2100: Right
[14:21] <sil2100> rvr: you busy with silos now?
[14:21] <rvr> sil2100: What do you want me to check?
[14:21] <sil2100> rvr: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1474739
[14:21] <sil2100> rvr: I just tried reproducing this and couldn't
[14:21] <rvr> Checking
[14:21] <sil2100> davmor2_: ^
[14:23] <rvr> sil2100: I'm installing build 4 to check it
[14:24] <sil2100> rvr: you need to upgrade from 2 to 4
[14:25] <rvr> sil2100: Oops, ok
[14:27] <seb128> is publishing photos from gallery to facebook working for anyone?
[14:32] <rvr> seb128: I think I saw a bug this morning about that
[14:33] <seb128> rvr, yeah, which is why I'm asking if others can confirm it
[14:33] <seb128> rvr, before trying to escalate that said bug
[14:45] <sil2100> rvr: were you able to find a moment to do this upgrade path?
[14:48] <mandel> sil2100, so, I'm utter crap with this errors => https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/292/console
[14:48] <mandel> sil2100, any idea
[14:48] <mandel> ??
[14:48] <sil2100> Looking
[14:49] <sil2100> mandel: yeah... so the silo is a vivid-overlay silo, where you're trying to release from a trunk that was used to release wily packages
[14:50] <mandel> sil2100, me swears.. how can I fix that?
[14:50] <mandel> sil2100, I guess I need some sudo powers, right?
[14:50] <sil2100> mandel: the train does not allow that, as the trunk has wily version numbers in it 1.234+15.10.blabla - while you suddenly want to release something that has 1.234+15.04.blabla
[14:51] <sil2100> We don't allow that... you either should have a separate trunk for 15.04 landings, or dual-land everything
[14:51] <sil2100> Or use syncs
[14:51] <rvr> sil2100: Phone is flashing
[14:51] <mandel> sil2100, but the complain is about content-hub, which I dod not control, I just want to make it recompile with the version of udm in that silo
[14:52] <sil2100> hmmm
[14:53] <sil2100> kenvandine: pong ^
[14:53] <sil2100> mandel: btw. why is it an overlay-only silo?
[14:53] <sil2100> Why not a dual? Is it already landed in wily?
[14:53] <mandel> sil2100, honestly, I have not touch that in aaaaaaages I was distracted by other urgent things and I have been an asshole
[14:53] <mandel> kenvandine, sorry!
[14:54] <sil2100> mandel: maybe we should turn this to a dual landing silo?
[14:54] <sil2100> mandel: then it would just all work fine, we'd release it both for wily and vivid
[14:54] <mandel> sil2100, sounds good, is a recompilation that is needed in both AFAIK
[14:56] <sil2100> mandel: ok, we'll have to rebuild the silo then... would that be fine?
[14:56] <mandel> sil2100, sure, no problem
[14:56] <mandel> sil2100, I want to land this :)
[14:59] <sil2100> mandel: ok, reconfigured... we need to rebuild it - do we need it to be rebuilt in a specific order?
[14:59] <mandel> sil2100, yes, udm first, then the others
[14:59] <mandel> sil2100, since they depend on udm
[14:59] <sil2100> ok, let's do it like that then
[15:00] <kenvandine> mandel, we should make that a dual silo
[15:00] <mandel> kenvandine, done already :)
[15:00] <mandel> kenvandine, landing this asap, sorry I have been a mess lately
[15:00] <kenvandine> awesome
[15:00] <sil2100> Building the u-d-m there
[15:00] <mandel> kenvandine, getting back on track
[15:00] <rvr> seb128: On krillin, "Your photo was uploaded successfully"
[15:01] <seb128> rvr, do you see it on facebook?
[15:01] <seb128> e.g is that true? ;-)
[15:02] <seb128> rvr, what image version as well?
[15:04] <rvr> sil2100: Which apps are the ones favourited?
[15:04] <sil2100> rvr: do you see 8 favourited apps?
[15:05] <sil2100> rvr: check the file /custom/etc/dconf_source/db/custom.d/custom.key if it has an override list of apps
[15:05] <rvr> seb128: ubuntu-touch/rc-proposed/bq-aquaris.en #67
[15:06] <sil2100> rvr: (you can simply pastebinit for us after the upgrade)
[15:06] <rvr> sil2100: I dont understand what "favourited" mean. Where? In the launcher?
[15:06] <sil2100> rvr: it's the 2 first rows of apps in the apps scope
[15:06] <seb128> rvr, k, weird
[15:07] <rvr> sil2100: Phone, Messaging, Contacts, Camera, Browser, Click
[15:07] <sil2100> rvr: on krillin there are 6 apps, 2 rows of 3 apps - on arale we increased that to 4 apps per row
[15:07] <sil2100> rvr: so after upgrade you have 6?
[15:07] <sil2100> Not good...
[15:08] <rvr> sil2100: No, this is image 4
[15:08] <rvr> err 2
[15:08] <sil2100> Ah, ok, good
[15:08] <sil2100> Now, OTA to image number 4 :)
[15:08] <sil2100> The expectation would be that there's 8 apps, so additionally Music and Gallery
[15:09] <rvr> sil2100: Restarting
[15:09] <sil2100> But Dave said that after update there's still 6 there, meaning the override from the custom update didn't work
[15:09] <sil2100> Or didn't get copied
[15:09] <rvr> sil2100: I see. I didn't understand what favorite meant.
[15:11] <jibel> yeah, they are not favorites since you cannot change them and it is not necessarily your favorite apps
[15:12] <ogra_> i thought they are supposed to become favorites and editable one day
[15:12] <rvr> sil2100: davmor2_: Only 6 after upgrade. Gallery and Music not in "favorite"
[15:13] <jibel> sil2100, is there any other bits of the custom tarball that we could check if they have been updated or not?
[15:13] <pmcgowan> jibel, yes the scopes, today scope
[15:14] <jibel> sil2100, could we diff the unpacked custom tarball with the content of the upgraded device?
[15:16] <sil2100> jibel: I checked the generated delta of the custom tarball and it had the override file in place
[15:16] <jibel> argh, I cannot flash my arale :(
[15:16] <sil2100> So it's not a bug on s-i
[15:17] <sil2100> The delta from 2 -> 3 has the override, and system-image-cli tool said that the upgrade path was 3 and then 4, so correct
[15:17] <sil2100> rvr: :<
[15:17] <sil2100> rvr: I couldn't reproduce the bug...
[15:17] <sil2100> But I didn't flash image no. 2 with wipe
[15:18] <sil2100> ALthough I confirmed that after flashing to #2 the custom.key file had no override and after upgrading to #4 the override was in place
[15:19] <kenvandine> alesage, i just replied about silo 39, what you're seeing is a separate ofono bug 1455574
[15:20] <alesage> kenvandine, super thanks
[15:20] <kenvandine> thank you!
[15:21] <rvr> sil2100: Let me check that file in #2
[15:25] <sil2100> This makes me worry
[15:25] <jibel> sil2100, I'm flashing 2
[15:26] <sil2100> kenvandine: whoops! Wanted to re-publish your package ;)
[15:26] <sil2100> Forgot it was your silo
[15:27] <sil2100> jibel, rvr: it seems the problem might be somewhere in the recovery upgrader, since as barry mentioned s-i client only downloads all the files and reboots
[15:27] <sil2100> jibel: but yeah, would be good if you guys see if other things from the custom got upgraded or not
[15:27] <jibel> sil2100, I'll upgrade and diff the device with the tarball
[15:28] <barry> sil2100: i think the upgrader leaves a log file
[15:28] <sil2100> barry: do you know where?
[15:28] <jibel> barry, where is the log file?
[15:28] <jibel> somewhere in recovery?
[15:29] <barry> jibel, sil2100 /android/cache/recovery
[15:29] <sil2100> Ooooh
[15:30]  * sil2100 looks
[15:30] <sil2100> barry: thanks!
[15:30] <barry> i see 3 files there, but i'm not entirely sure what the differences are
[15:30] <sil2100> jibel, rvr: after upgrading, could you pastebin your logs from there? I would compare those with what I got
[15:31] <sil2100> Applying update: custom-3a6411261d5e2fc1a158bf7f1937fb2f54aa639effc765306fbd06a5b0ab84ca.delta-custom-aa22aaea5347f22e04123aa6689ef07ba6c774c68c1b1dc3e58f3de40c7c6e2d.tar.xz <- so at least I know it's applying the custom update here
[15:32] <rvr> sil2100: Before upgrade, image #2 http://paste.ubuntu.com/11883173/
[15:33] <kenvandine> sil2100, sorry :)
[15:33] <kenvandine> i try to be self service :)
[15:34] <sil2100> kenvandine: apologies from my side ;p
[15:34] <sil2100> I never publish your silos since I know you do that yourself
[15:35] <sil2100> I simply, hm, didn't check ;p
[15:38] <sil2100> rvr: could you also pastebin the /android/cache/recovery/log file after upgrading to #4?
[15:38] <jibel> sil2100, I confirm I've 6 apps, checking the logs
[15:38] <sil2100> jibel: could you pastebin?
[15:38] <jibel> sure, when it lets me in
[15:39] <sil2100> LET HIM IN!
[15:39]  * sil2100 shouts on jibel's arale
[15:39] <jibel> permission denied :(
[15:39] <sil2100> sudo!
[15:39] <rvr> sil2100: Yes, upgrading
[15:40] <jibel> sil2100, I mean when I try to log into the phone
[15:40] <sil2100> uh
[15:42] <jibel> sil2100, barry http://paste.ubuntu.com/11883237/
[15:43] <sil2100> jibel: ok, so it's applying it... and still 6 icons only?
[15:43] <sil2100> jibel: can you confirm that /custom/etc/dconf_source/db/custom.d/custom.key doesn't have the override?
[15:43] <jibel> sil2100, yes
[15:43] <jibel> checking
[15:44] <rvr> sil2100: http://paste.ubuntu.com/11883245/
[15:44] <sil2100> Since on Dave's machine it wasn't set, but it doesn't make sense...
[15:44] <rvr> sil2100: After upgrade http://paste.ubuntu.com/11883247/
[15:45] <sil2100> rvr: oh! So the override is there!
[15:45] <sil2100> rvr: and still only 6 apps?
[15:45] <rvr> sil2100: Right, still only 6 apps
[15:45] <sil2100> Maybe the dconf database needs to be rebuilt
[15:45] <sil2100> mzanetti: ping
[15:45] <mzanetti> sil2100, hey ho
[15:45] <jibel> sil2100, http://paste.ubuntu.com/11883261/ thre are 8 apps in the list
[15:46] <sil2100> mzanetti: hey! Do you know how the /custom/etc/dconf_source/db/custom.d/custom.key file is used? When is it recompiled to the dconf database?
[15:46] <mzanetti> I don't :/
[15:47]  * mzanetti does some reading
[15:47] <mzanetti> sil2100, looks like when "glib-compile-schemas" is called
[15:48] <sil2100> hmmm, so probably it's not called during update
[15:48] <sil2100> cwayne_: ping
[15:48] <cwayne_> sil2100, yo
[15:49] <sil2100> cwayne_: hey! We're investigating a bug in custom-tarball custom.key overrides
[15:49] <kenvandine> sil2100, since citrain can't dual land regular dput packages, once it's built for wily i can create a 2nd vivid + overlay landing with sync:22 right?
[15:49] <kenvandine> to sync from silo 22?
[15:49] <sil2100> cwayne_: so there's that file in the custom tarball /custom/etc/dconf_source/db/custom.d/custom.key
[15:50] <sil2100> cwayne_: an override for the 8 apps instead of 6 was written there... but it seems the dconf database wasn't rebuilt during the upgrade
[15:50] <sil2100> cwayne_: do you know anything about this there? Is there a plan that the db should be recompiled during upgrade?
[15:51] <cwayne_> sil2100, it should be updated based on the build_id
[15:51] <cwayne_> there's an upstart job that checks if the build_id is old, and if so, run dconf update
[15:52] <sil2100> cwayne_: hmmm
[15:52] <sil2100> cwayne_: where is that upstart job? Can we find some logs for that?
[15:53] <cwayne_> sil2100, i think it's /etc/init/custom-dconf.conf
[15:53] <cwayne_> it's in package ubuntu-touch-customization-hooks
[15:54] <mandel> sil2100, I though the changelog should not be touched => https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/294/console
[15:55] <sil2100> hmmmm
[15:55] <sil2100> cwayne_: something is not right, checking /var/log/upstart/custom-dconf-update.log and I see: skipping dconf update
[15:55] <sil2100> Even though the custom got updated
[15:55] <sil2100> jibel: could you check /var/log/upstart/custom-dconf-update.log if you also have skipping dconf update
[15:56] <mandel> sil2100, any idea? for me all this ci is close to magic :-
[15:56] <mandel> :-/
[15:56] <sil2100> mandel: could you poke kenvandine? Since he's working on u-s-s so he should know more about what that version means
[15:56] <sil2100> And where it's coming from
[15:57] <mandel> kenvandine, any idea => https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/294/console
[15:57] <mandel> ??
[15:57] <sil2100> kenvandine: let me get to you in a moment ;)
[15:57] <jibel> sil2100, the only difference between the tarball and the upgraded device is the dconf db http://paste.ubuntu.com/11883304/
[15:57] <sil2100> cwayne_: hm, maybe it's caused by the invalid custom tarball build ID?
[15:57] <cwayne_> sil2100, what's /custom/build_id
[15:57] <kenvandine> could it be because we have a version in proposed that isn't merged into trunk yet?
[15:57] <sil2100> jibel, cwayne_, ogra_, pmcgowan: I'm worried that the problem is the reported by ogra_ custom tarbal build ID change...
[15:58] <kenvandine> still waiting to be promoted to release
[15:58] <sil2100> cwayne_: 1436463722
[15:58] <sil2100> cwayne_: shouldn't it be the ID that we see in system-image instead?
[15:58] <jibel> sil2100, cwayne_ apparently dconf update failed http://paste.ubuntu.com/11883310/
[15:58] <sil2100> jibel: uh?
[15:59] <cwayne_> sil2100, no that's a proper build_id
[15:59] <mandel> kenvandine, oh, that could be it, can you ping me when it is there so that I can retry?
[16:00] <mandel> kenvandine, I'll take the dog for a walk to waste some time :)
[16:00] <kenvandine> mandel, will do!
[16:00] <sil2100> jibel: that's strange, it implies the custom db wasn't generated yet
[16:00] <mandel> kenvandine, perfect, thx!
[16:00] <kenvandine> probably an hour or so
[16:00] <sil2100> cwayne_: could you check the pastebin jibel posted? It looks strange that this directory doesn't exist
[16:01] <jibel> sil2100, it's skipped because build time < timestamp of /custom/etc/dconf/db/custom
[16:01] <pmcgowan> aha
[16:01] <sil2100> jibel: well, stat can't find stat: cannot stat '/custom/etc/dconf/db/custom': No such file or directory
[16:02] <sil2100> And this file should be there
[16:02] <sil2100> As that's the compiled dconf database
[16:02] <jibel> right in that case dconf_mtime is 0
[16:03] <cwayne_> that doesn't make sense.. since the scope favorites are properly set, which is also in that dconf db
[16:04] <sil2100> jibel: could you check if you have /custom/etc/dconf/db/custom on your device now?
[16:04] <sil2100> I'm sure you do tho...
[16:05] <jibel> sil2100, it's there
[16:05] <jibel> sil2100, why is the upstart job executed twice?
[16:05] <jibel> sil2100, you cannot have both updating and skipping
[16:06] <jibel> sil2100, I removed the file and ran the job and the apps are there
[16:06] <jibel> sil2100, is it running too early
[16:06] <jibel> ?
[16:07] <sil2100> hm, maybe, but I thought it was actually ran after the upgrade finished, on first boot after upgrade
[16:07] <sil2100> cwayne_: ^ ?
[16:07] <sil2100> cwayne_: (sorry for taking your time, but you're the most experienced custom tarball guy around ;) )
[16:09] <cwayne_> sil2100, no worries :)  it should run on boot after the upgrade, let me try and poke around and figure out why its not
[16:09] <cwayne_> what's even weirder is that my arale seems to have worked perfectly btw...
[16:10] <jibel> cwayne_, yeah if you upgraded in rc-proposed it works fine but not on rc
[16:10] <sil2100> Mine seemed to work fine on rc-proposed
[16:10] <cwayne_> hm
[16:10] <sil2100> Maybe some race condition when trying to rebuild the dconf database?
[16:11] <sil2100> Doesnt' look like it
[16:12] <cwayne_> it almost seems to me like the build_id wasn't copied right or something
[16:13] <sil2100> cwayne_: to the custom tarball, or during upgrade?
[16:17] <sil2100> jibel: actually, maybe the first line is from your fresh flash to #2, and the second one (the skipped part) is for the upgrade to #4
[16:17] <jibel> sil2100, yes, that's what I'm checking
[16:17] <sil2100> jibel: then it would indeed make sense that the file was not there... and maybe cwayne is right saying that there's something wrong with the build_id
[16:17] <sil2100> And it skipped the upgrade
[16:17] <jibel> exactly, that's my guess
[16:18] <jibel> I'll confirm in a minute if the tarball ever transfers
[16:20] <kgunn> trainguards not sure what's happening, but seeing an issue with citrain tool on mx4 wily
[16:20] <kgunn> https://pastebin.canonical.com/135360/
[16:20] <kgunn> it adds the ppa, does the apt update, but seems to fail the install part
[16:21] <sil2100> kgunn: hm, a downgrade? Maybe it's indeed missing the right --force-yes flags now, not sure if it's written to handle this case wll
[16:21] <sil2100> *well
[16:21] <sil2100> robru: &
[16:21] <sil2100> robru: ^
[16:22] <sil2100> (ugh)
[16:22]  * kgunn asks mir guys why u-s-c is a downgrade in //
[16:29] <cwayne_> sorry, think i got booted from irc for awhile
[16:30] <sil2100> uh
[16:30] <sil2100> :)
[16:30] <sil2100> cwayne_: http://paste.ubuntu.com/11883467/ <- in case you missed those
[16:32] <fginther> AlbertA, thanks for getting back to me, the jobs have been updated.
[16:32] <jibel> sil2100, so when I flash 2 dconf db is created, I saved the build_id and will upgrade
[16:33] <sil2100> jibel: ok! Thanks, let's see what'll happen with the build_id...
[16:33] <cwayne_> sil2100, ah yes, I did miss all that :)
[16:33] <cwayne_> stupid xchat
[16:33] <kenvandine> sil2100, don't forget my question :)
[16:34] <sil2100> kenvandine: ok, reading up now! :)
[16:34] <kenvandine> mandel, merged, rebuild away!
[16:34] <rvr> jamesh: Hi
[16:35] <sil2100> kenvandine: ok, the answer is yes :) That's the only way to go with dputs
[16:35] <rvr> jamesh: I'm failing silo 10. With 250 png's, I see no thumbnails in gallery-app.
[16:35] <sil2100> kenvandine: wait, actually...
[16:35] <kenvandine> cool, just making sure i didn't have to wait for it to land in wily
[16:35] <sil2100> kenvandine: depends on what kind of package we're talking about, since synces work only for CI Train versioned packages
[16:36] <kenvandine> sync of libqofono
[16:36] <sil2100> kenvandine: for others you'd have to do a manual upload yourself, as we can't guess the version format
[16:36] <kenvandine> in silo 22 for wily
[16:36] <kenvandine> ok
[16:36] <kenvandine> so i should upload like 0ubuntu0.1 ?
[16:36] <kenvandine> so it's less than wily?
[16:37] <sil2100> kenvandine: yeah, you'll have to figure out some versioning... I usually append something 'overlayish' there, since I'm worried that I'll get in conflict with SRUs
[16:37] <sil2100> But 0ubuntu0.1 sounds fineish
[16:37] <kenvandine> like?
[16:37] <kenvandine> ok
[16:42] <jibel> sil2100, does it fail because #2 has been flashed after the timestamp in build_id?
[16:42] <jibel> sil2100, so the dconf db is newer than build_id?
[16:43] <jibel> and not updated
[16:44] <sil2100> jibel: hah, it makes sense... this would be a big bug in the custom dconf updater then
[16:44] <jibel> sil2100, it probably never worked
[16:44] <sil2100> jibel: I suppose that explains why it worked for us on rc-proposed
[16:44] <sil2100> Yeah
[16:44] <sil2100> It works if you don't go back in history
[16:44] <sil2100> cwayne_: ^
[16:44] <sil2100> jibel: good catch
[16:45] <jibel> sil2100, it won't work for someone who buy a retail phone with factory image lets say OTA1 and upgrade
[16:47] <jibel> sil2100, however next ota would fix it because the build_id would become newer than the dconf db
[16:48] <sil2100> The sad thing is... it's a bug on the rootfs, as the upstart job is not part of the custom tarball
[16:48] <jibel> sil2100, , instead of doing a stat on the dconf db maybe a flag with a copy of the build id corresponding to when the db has been updated would fix the problem.
[16:49] <sil2100> So if we want to fix this, we need to make a snapshot of the old OTA-5 image candidate
[16:49] <jibel> nice
[16:50] <sil2100> pmcgowan: ^
[16:50] <jibel> pmcgowan,
[16:50] <jibel> :)
[16:50] <sil2100> It's an old problem, but this time it might cause trouble
[16:50] <robru> kgunn: what version of the citrain tool are you using? vivid version, wily version?
[16:51] <sil2100> robru: kgunn said it was the wily version
[16:52] <robru> sil2100: kgunn: looks like he said his phone was wily, I mean is he running wily or vivid on his host machine
[16:54] <pmcgowan> sil2100, jibel so whats the fix exactly change the logic on when to update?
[16:58] <jibel> pmcgowan, yes it's comparing the build_id to the last access time of the dconf db, so if the db is created after build_id it will not be updated on next upgrade
[17:02] <pmcgowan> jibel, so why is the current db later than the build_id
[17:03] <sil2100> pmcgowan: since the db is generated after flashing
[17:03] <pmcgowan> ah so never worked
[17:03] <sil2100> So it has the image flash date timestamp...
[17:03] <sil2100> It works in the theoretical case where someone had OTA-4 from the beginning and now upgrades to OTA-5
[17:04] <sil2100> Since then the db is generated in the OTA time, so earlier than the new custom tarball
[17:04] <pmcgowan> sil2100, so if I updated to ota4, I update to ota5 ok
[17:05] <pmcgowan> but if I flash ota4, I cannot update to oat5 ok
[17:05] <pmcgowan> ?
[17:05] <sil2100> pmcgowan: it depends when you got ota4
[17:05] <pmcgowan> still confused then
[17:05] <pmcgowan> oh I see
[17:05] <pmcgowan> if I get ota4 after ota5 build
[17:05] <pmcgowan> thats busted
[17:05] <sil2100> pmcgowan: if you got ota4 at least 2 weeks ago, it's fine... but if you upgraded/flashed to ota4 in the last 1-2 weeks, you're broken
[17:05] <jibel> exactly
[17:05] <pmcgowan> why check at all
[17:05] <sil2100> Yes
[17:06] <pmcgowan> should it just update always?
[17:06] <sil2100> pmcgowan: well, it's an upstart job that's running on every boot
[17:06] <sil2100> pmcgowan: so it can't update the db on every boot as it's not required... in the best case it should only update when there's smoething to update
[17:06] <jibel> pmcgowan, a solution would be to save the buildid against which the db was rebuilt
[17:07] <pmcgowan> ok
[17:07] <jibel> instead of comparing it to the timestamp of a file dynamically created
[17:07] <pmcgowan> right
[17:07] <pmcgowan> and thats in the upstart stuff in rootfs
[17:07] <sil2100> We need ubuntu-touch-customization-hooks upgraded in this case...
[17:08] <pmcgowan> sil2100, so we need to snapshot and poke
[17:08] <sil2100> Yeah, I'll prepare the snapshot
[17:08] <sil2100> The problem was... davmor2_ had a different case in his logs
[17:08] <sil2100> And this wasted some of my time, as he didn't have the override in place
[17:08] <sil2100> For unknown reasons
[17:09] <jibel> sil2100, I verified if I force the execution of the job the missing favorite apps appear
[17:09] <sil2100> Since this was his custom.key after 2 -> 4 upgrade:
[17:09] <sil2100> http://paste.ubuntu.com/11878074/
[17:10] <sil2100> jibel: you mean, force the dconf update in custom-dconf-update.conf and then upgrade?
[17:10] <jibel> sil2100, true, I've the same problem now
[17:11] <jibel> sil2100, during previous test the dconf keys were ok
[17:11] <jibel> and now it's like davmor2_
[17:11] <jibel> ????
[17:11] <sil2100> huh?
[17:11] <sil2100> WTH
[17:11] <sil2100> jibel: could you pastebin the logs? Both the system-image ones and the one from recovery
[17:12] <jibel> sil2100, http://paste.ubuntu.com/11883663/ the keys
[17:14] <jibel> sil2100, that's ok, it's the wrong file in the pastebin
[17:14] <sil2100> Aah!
[17:14] <sil2100> dconf instead of dconf_source
[17:14] <sil2100> Yeah, ok, missed that when I checked logs from davmor2_
[17:15] <sil2100> Ok, so it was a red herring
[17:15] <jibel> phew, don't do that again, it's sunny nearly 7:30 and I'd like to go swimming :)
[17:16] <sil2100> Go go ;)
[17:16] <sil2100> I need to finish up some other things and then prepare the snapshot PPA
[17:18] <jibel> bbl
[17:19] <kenvandine> mandel, i went ahead and kicked a rebuild of silo 9
[17:24] <sil2100> pmcgowan: preparing the snapshot
[17:27] <pmcgowan> sil2100, cwayne who can we assign that bug to
[17:28] <sil2100> Not sure who is the current maintainer of ubuntu-touch-customization-hooks - is that penk?
[17:33] <sil2100> Looks like another longer work day for me ;)
[17:44] <mandel> kenvandine, great
[18:05] <sil2100> kenvandine, robru, Mirv: could you not publish anything for a moment?
[18:05] <sil2100> I don't want to confuse LP during the copy
[18:05] <kenvandine> sure
[18:05] <sil2100> Thanks
[18:05] <cwayne> sil2100: i guess its penk now, yeah
[18:09] <robru> sil2100: alright
[18:11] <sil2100> pmcgowan: copying to the snapshot now...
[18:23] <pmcgowan> sil2100, didnt seb128 log a bug about the Display results string not being translated? I cannot find it now
[18:30] <kgunn> robru: sil2100 actually, my mistake at least on ppa with phone...i flashed rc-proposed, meant to flash devel
[18:30] <kgunn> so i think nvmd
[18:31] <robru> kgunn: if you have problems, best to try the version of citrain tool in lp:phablet-tools, it has some fixes that aren't released in vivid.
[18:31] <kgunn> ack
[18:31] <kgunn> i think it was me for the moment
[18:42] <davmor2> sil2100: just got back from the hospital did you sort it all out in the end?
[18:51] <pmcgowan> davmor2, the update thing? yes just working out the best fix
[18:52] <robru> sil2100: just noticed silo 45 waiting to publish, let me know when it's safe
[18:52] <davmor2> pmcgowan: yeah just caught up on the bug email from it just a database timestamp that is mad
[19:01] <sil2100> robru: one more minute :)
[19:02] <robru> boiko: remember you can assign your own silos now ;-)
[19:02] <boiko> robru: oh, I totally forgot, I thought it was only for reconfiguring, cool! :)
[19:03] <robru> boiko: yeah there's a buffer at 5 silos, if there's only 5 free silos then you need a trainguard to greenlight it but generally it's open season on silos.
[19:04] <boiko> robru: nice!
[19:04] <robru> boiko: there'll be a more formal announcement about this when the spreadsheet replacement goes live, Real Soon Now
[19:04] <boiko> robru: and I still didn't get the time to test it, shame on me :-S
[19:05] <robru> boiko: no worries, I got some great feedback already and I think we're coming in for a strong finish here.
[19:06] <boiko> great!
[19:06] <sil2100> robru, kenvandine, Mirv: ok, things seem to look fine
[19:07] <sil2100> robru, kenvandine, Mirv: you can land now
[19:07] <kenvandine> cool, thx
[19:08] <robru> sil2100: thanks
[19:09] <robru> bah
[19:20] <pmcgowan> jibel, , didnt someone log a bug about the "Display results for X" string not being translated for scopes? I cannot find it now
[19:22] <jibel> pmcgowan, I remember seb128 mentioned it.
[19:22] <jibel> I am not sure there is a bug, let me check
[19:23] <pmcgowan> jibel, kyle entered one but i thought it was already in
[19:26] <jibel> I cannot find anything from seb
[19:31] <jibel> pmcgowan, nope, all I found are the bugs the testers reported yesterday and that kyle marked as duplicates.
[19:31] <pmcgowan> jibel, ok thanks, will use that one then
[19:36] <seb128> jibel, pmcgowan, the one I mentioned was https://translations.launchpad.net/unity-scopes-shell/trunk/+pots/unity-plugin-scopes/es/1/+translate
[19:37] <seb128> that was not advertized to translators, nobody knows it's to translate I think
[19:37] <pmcgowan> seb128, what do we do to trigger that?
[19:37] <seb128> pmcgowan, "that"?
[19:38] <seb128> let people know it's to translate
[19:38] <seb128> usually email ubuntu-translators@ with a pointer to the new string
[19:38] <seb128> also check with dpm that that template priority is high enough that it's listed as an important templates for translators
[19:40] <pmcgowan> seb128, how do I check that priority
[19:40] <seb128> pmcgowan, it's in https://translations.launchpad.net/unity-scopes-shell/trunk/+pots/unity-plugin-scopes/+edit
[19:41] <seb128> that one apparently has 0
[19:41] <pmcgowan> heh so no wonder
[19:41] <pmcgowan> lets bump it
[19:42] <seb128> pmcgowan, also not that dialer-app's template was not update so the new "flight mode" dialog added for ota5 is not translated/translatable...
[19:42] <seb128> yet another translation fail :-/
[19:42] <pmcgowan> it is also prioirty 0
[19:42] <pmcgowan> since I just checked it
[19:42] <seb128> yeah, I'm unsure if that's where dpm change those
[19:43] <pmcgowan> ok will wait for him to weigh in
[19:44] <seb128> pmcgowan, there is https://wiki.ubuntu.com/Translations/Phone which lists other scope sources but not the shell one
[19:53] <seb128> pmcgowan, jibel, I think the string in the video/music is another issue, that's coming from the media scope
[19:53] <seb128> bug #1472236 which has a merge request to update the template for a week
[19:54] <seb128> pmcgowan, jibel ^
[19:54] <kyrofa> cihelp: I have a package that's running in jenkins and autolanding. I need the configuration changed so that I can land it in the archives. What do I do?
[19:55] <fginther> kyrofa, is this to move a package into the ci-train world?
[19:55] <fginther> kyrofa, and what package is it?
[19:56] <kyrofa> fginther, I'm a bit new to it, but yes I believe so (that's only way to get it into the archives, no?)
[19:56] <kyrofa> fginther, unity-scope-snappy
[19:56] <kyrofa> fginther, ci-train is the silos and whatnot?
[19:57] <fginther> kyrofa, yes. ci-train == silos and path to the archive
[19:58] <fginther> kyrofa, on our end, we need to make a config change to stop autolanding of MPs into trunk, the rest is up to you to work with the train folks
[19:59] <kyrofa> fginther, very good. Would you like that request via email, or is it an easy change to make?
[20:00] <fginther> kyrofa, I have all I need from this conversation, should have it ready by EOD
[20:00] <kyrofa> fginther, awesome, thanks!
[20:27] <slangasek> sil2100: hey, so regarding the gcc5 silo; I understood from our discussion that you told me I could fill out the spreadsheet with just some representative packages listed in 'additional source packages to land', but not have to list all of them, is that right?
[20:27] <slangasek> sil2100: robru is telling me that large parts of the train are going to be uncooperative with this
[20:28] <sil2100> slangasek: all the list is needed to publish it, but to assign the silo only a few were necessary
[20:28] <sil2100> It was for silo assignment
[20:29] <slangasek> sil2100: ah, I see.  So is there any reason that we as core-devs couldn't/shouldn't bypass the publish job and just use copy-package directly?  which is going to be simpler than adding 1000 package names to the spreadsheet box
[20:29] <sil2100> slangasek: no reason, I guess that's much saner that way
[20:29] <slangasek> ok
[20:29] <sil2100> e.g. copy-package
[20:34] <robru> slangasek: well if you bypass the publish job, other silos won't be marked dirty
[20:36] <robru> sil2100: slangasek anyway i approve of the idea of making the train infer packages based on ppa contents, but that'll take some work and other things are priorities now
[20:54] <slangasek> robru: isn't the train supposed to figure out on its own when someone has done a direct upload to the archive?
[20:55] <slangasek> sorry that's a rhetorical question.  it is supposed to figure out on its own ;)
[20:55] <slangasek> but does that not have the effect of marking silos as dirty?
[21:02] <robru> slangasek: i don't know what train you've been using all this time. Our train is a dog that requires constant manual prodding and babysitting. Nothing is ever automatic
[21:02] <robru> slangasek: oh you said archive
[21:02] <robru> slangasek: yeah at publish time it'll complain
[21:03] <slangasek> s/complain/fail/, I hope
[21:03] <robru> slangasek: the point of marking dirty is that silo owners get warned before publishing
[21:03] <slangasek> yes
[21:03] <robru> slangasek: yeah fail
[21:04] <robru> slangasek: are you planning on merging everything back to trunks manually, too?
[21:04] <slangasek> robru: um, no, that's the thing that the train is supposed to have been taking care of automatically for us
[21:05] <slangasek> robru: direct uploads to the archive by core-devs are supposed to be automatically picked up by the train
[21:05] <robru> slangasek: on what planet?
[21:05] <robru> Surely not this one
[21:05] <slangasek> now, maybe "by the train" is actually "by the next lander who tries to publish the package and gets told to go merge the thing"
[21:06] <robru> slangasek: yeah, that. The train offers no help there, landers get to keep the pieces
[21:06] <slangasek> ok
[21:07] <robru> slangasek: please file some bugs. I'd love to streamline these pain points after I'm done with bileto
[21:07] <slangasek> robru: well, most of this is half-formed impressions I have of how things were supposed to work, not actionable bugs
[21:08] <slangasek> but I'll try to correct that
[21:08] <robru> slangasek: well "train should resync trunk for you" is an actionable feature request i agree with
[21:08] <robru> slangasek: also "train should infer ppa contents" is another good one
[21:09] <robru> slangasek: i mean, that would be an amazing world to live in. I'm shocked you thought those things existed already
[21:09] <slangasek> haha