[01:44] <veebers> robru: hey you around still perchance? Silly question incoming :-)
[01:49] <robru> veebers: yep, sorry I missed you yesterday
[01:56] <veebers> robru: no worries it would have been late for you. Hey I see my previous train request is gone, I imagine from lack of use?
[01:57] <robru> veebers: err, gone? i might have freed the silo back when we had a crunch but nothing's ever "gone" unless there's a glitch
[01:58] <veebers> robru: right, you may have freed it (which is fine at this point). I understand that there is an argument you can give it to force the build/upload? i.e. a package has been released outside of the normal train process and I want to use the train process to get everything back in order
[01:59] <veebers> (it was released into xenial, I want it both in xenial + vivid-overlay)
[02:00] <robru> veebers: oh, no. if there was a manual upload to xenial you need to manually push that to your trunk.
[02:00] <robru> veebers: the "force" option ignores the manual distro upload, effectively reverting it
[02:01] <veebers> robru: I'm not sure I fully understand. What if what was manually uploaded is the same as the MP that I'm trying to force through?
[02:01] <robru> veebers: what package are we talking about?
[02:01] <veebers> robru: autopilot
[02:04] <robru> veebers: how would that even happen? I'm talking about the common case of a core dev hacking on your packaging and uploading direct to distro, bypassing the entire silo process
[02:04] <robru> veebers: you're saying somebody took the package in the ppa that I deleted and uploaded it to distro anyway?
[02:06] <veebers> robru: right, a MP was proposed against autopilot but that change was uploaded at the same time (to unblock things) I then merged the MP into trunk and went to release it using the train but as it's already uploaded it errors
[02:06] <veebers> robru: sorry, this is unrelated to the wiped silo
[02:06] <robru> veebers: what I'm seeing is there's this manual upload: http://launchpadlibrarian.net/234931830/autopilot_1.5.1+16.04.20151209-0ubuntu1_1.5.1+16.04.20151209-0ubuntu2.diff.gz
[02:06] <veebers> the wiped silo was when I understooed what happened (i.e. had already been uploaded) so I followed it up.
[02:07] <veebers> robru: right, that's the change that I'm trying to release using the train (but to both X and V+p) as it was uploaded by someone else
[02:07] <robru> what you need to do is branch your trunk, apply the above patch, commit the result (which I guess will just be the changelog if you already merged the other part), and then commit that directly to trunk. no mp, no silo.
[02:08] <veebers> so now I'm trying to sync things by using the train so both X & V+p are the same and what's released is the same in the release branch
[02:08] <veebers> robru: well almost, I want to release that into V+p too. Will there be complexity if I do it that way??
[02:08] <robru> veebers: so for that you'd want a sync silo to copy xenial into vivid. or you can just wait until your next change and do a regular dual silo and the new release will pick everything up from trunk.
[02:08] <veebers> Up untill now we've release into both X & V+p at the same time
[02:09] <robru> veebers: you don't want to do this with a dual silo because you'll end up with a weird null upload to xenial that will be totally pointless.
[02:09] <veebers> robru: ok one option is to sync silo to copy x to v, and manually commit the changelog fixes to the releae branch?
[02:09] <veebers> yeah right
[02:10] <robru> yeah
[02:13] <robru> veebers: the way to think of it is that the train does trunk -> distro. if you have something in distro and you're trying to get it into trunk, the train is exactly the opposite of what you want. but you can also do a sync silo which is distro -> distro
[02:16] <robru> veebers: I gotta run in 15, let me know if you need help configuring the sync request
[02:16] <veebers> robru: ack, thanks
[02:16] <robru> yw
[02:28] <robru> will be back in 2hrs if you need me for anything
[10:09] <xavigarcia> trainguards: Hi there. could somebody take a look to https://requests.ci-train.ubuntu.com/#/ticket/1008 ?
[10:09] <xavigarcia> trainguards: I get the following error: https://requests.ci-train.ubuntu.com/#/ticket/1008
[10:09] <xavigarcia> trainguards: sorry: Needs rebuild due to burned version number (mir/vivid, mir/xenial)
[10:12] <Mirv> xavigarcia: it means that mir was released meanwhile from another silo, you need to hit Build again so it merges the branches again with latest mir trunk
[10:12] <Mirv> xavigarcia: or... is it that you shouldn't be having mir in the silo in the first place?
[10:13] <Mirv> xavigarcia: for some reason there is mir in the silo https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-025/+packages - if that's an error like it probably is, I can remove it
[10:14] <Mirv> xavigarcia: ok, wait 10-15 mins from now, the train should fix its status
[10:17] <xavigarcia> Mirv: Okay, waiting then... thanks!
[10:38] <Saviq> sil2100, you pulled out framework 15.04.4 from rc-proposed, right?
[10:39] <sil2100> Saviq: yes, at least I thought I did!
[10:39] <sil2100> I didn't?
[10:40] <Saviq> sil2100, you did, but people already depended on it
[10:40] <Saviq> nerochiaro, zbenjamin ↑
[10:41] <sil2100> hm, what parts of it did people depend there? I thought there was no reason for its existance
[10:41] <nerochiaro> Saviq: we don't really depend on it, it's just our staging branch tha tdoes
[10:41] <nerochiaro> Saviq: i think we can roll that back
[10:41] <Saviq> sil2100, it's still in the store
[10:41] <nerochiaro> Saviq: as long as it does not make it in trunk
[10:41] <Saviq> according to zbenjamin
[10:41] <Saviq> nerochiaro, yup
[10:43] <sil2100> Yeah, it's in the store still, didn't remove it from there as I hope we'll be re-introducing it soon
[10:43] <sil2100> It's a virtual framework right now
[10:43] <sil2100> ;p
[11:48] <Mirv> oh, I had dropped from freenode (but not OFTC/IRCnet)
[12:45] <boiko> rvr: in dual panel mode, we are just hiding the label now (to avoid having to deal with translations until design comes with the correct text)
[12:45] <boiko> rvr: that's for silo 30
[12:46] <boiko> rvr: rebuilding it right now
[12:46] <rvr> boiko: Are you rebuilding the silo?
[12:46] <rvr> boiko: Ack
[12:46] <boiko> rvr: other than that, how is the test going?
[12:46] <rvr> boiko: Fine so far
[12:46] <boiko> great!
[12:47] <rvr> boiko: UX wise there are some problems with this side panel model, but it's not exactly your problem
[12:47] <boiko> rvr: like what?
[12:47] <rvr> boiko: So, if I create a new message, and then go to settings, there is no way to recover the message
[12:48] <rvr> boiko: Clicking again on "+" will create a new message
[12:48] <boiko> rvr: ah yeah, state saving will need a revamp
[12:49] <boiko> rvr: we need designers to come up with the full UX spec for that (so far we just had drafts of how basic things should work)
[12:49] <rvr> boiko: Ack
[13:26] <jibel> kenvandine, I failed silo 34 (apport upstart jobs) With the silo core_pattern is not set and apport doesn't work, enabled or not in system-settings
[13:38] <bzoltan> Mirv: https://ci-train.ubuntu.com/job/ubuntu-landing-050-1-build/39/consoleFull
[13:40] <Mirv> bzoltan: it says what's the issue - you possibly added stuff to debian/rules with space characters instead of a real tab?
[13:40] <Mirv> "debian/rules:40: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop."
[13:58] <kenvandine> jibel, hummm... worked for me
[13:59] <jibel> kenvandine, on a freshly flashed device?
[13:59] <kenvandine> no...
[13:59] <kenvandine> but i removed the files created by the job and rebooted
[14:00] <kenvandine> i also changed the channel in channels.ini and removed the files created by the job and rebooted
[14:00] <kenvandine> to verify it did the right thing for both stable and rc-proposed
[14:00] <kenvandine> jibel, actually i did notice the core_pattern didn't update immediately
[14:00] <jibel> kenvandine, I can retry to make sure I didn't do anything wrong, but with the silo enabling/disabling apport didn't change the core pattern
[14:01] <jibel> and it was disabled on boot
[14:01] <kenvandine> i thought it was broken too, but after a couple minutes i noticed it was set
[14:01] <kenvandine> it's like the apport job didn't get triggered immediately
[14:02] <kenvandine> i didn't test toggling it in system-settings, the upstart job is unrelated to that
[14:02] <kenvandine> it should only effect what the default is
[14:02] <kenvandine> what i noticed on boot with rc-proposed the core_pattern wasn't set right away
[14:02] <kenvandine> but shortly after boot it was
[14:03] <jibel> kenvandine, okay, I'll reverify if it's set after a delay
[14:03] <kenvandine> like there was some delay in running the job
[14:04] <pete-woods> trainguards: hi guys, could I get my silo published now that QA has approved it? (https://requests.ci-train.ubuntu.com/#/ticket/978)
[14:04] <pete-woods> I haven't got the right superpowers to do the publish myself
[14:07] <sil2100> o/
[14:07] <sil2100> Ok, on it
[14:08] <pete-woods> (the changes are adding a distro-patch that ditches the broken ARM assembler for AES)
[14:09] <sil2100> pete-woods: ok, looks goodish now - for packages like these we usually prefer the SRU version notation (so appending .1 then .2 etc.) but in this case it's all cool as vivid is EOL now anyway :)
[14:10] <pete-woods> sil2100: okay, will try and remember that I need to ask someone about the version numbering in future
[14:10] <pete-woods> I guess I didn't really see it as an "SRU", so my "make everything super strict" mode didn't get switched on
[14:10] <sil2100> hmmm
[14:12] <sil2100> An ugly patch but yeah, works ;) Publishing!
[14:13] <pete-woods> I just did whatever I could to make the patch minimal
[14:13] <pete-woods> the bug is supposedly fixed in the xenial version (which is now synced straight from debian)
[14:14] <sil2100> hm, interesting publishing error, looks like the packages got copied though so good
[14:24] <Mirv> dbarth_: https://code.launchpad.net/~charlesk/indicator-datetime/lp-1474078-notification-blacklist-apps/+merge/284927 not top approved
[14:33] <jibel> kenvandine, so without the silo, freshly flashed krillin, core_pattern is set immediately. I tried several reboots. I'm trying with the silo now.
[14:42] <pete-woods> trainguards: hi folks, do you guys have a recommendation for who could review this seed addition for vivid (I guess a similar one for xenial will also be required) https://code.launchpad.net/~pete-woods/ubuntu-seeds/ubuntu-touch.vivid-gnome-keyring/+merge/286332
[14:42] <jibel> kenvandine, how long was the delay?
[14:42] <sil2100> pete-woods: hey! Let me take a look, but generally this branch is locked since vivid's release ;)
[14:42] <sil2100> pete-woods: we manage overlay-seeds through manual packages
[14:42] <jibel> kenvandine, with the silo, /var/lib/apport/autoreport is present, but the pattern is not set
[14:42] <sil2100> But I can forward your change there
[14:42] <pete-woods> sil2100: ah, maybe I picked the wrong branch then :)
[14:43] <pete-woods> thanks!
[14:43] <sil2100> pete-woods: possibly target this change to xenial (since I suppose it should be valid there as well?) - we'll carry it over to the vivid-overlay :)
[14:43] <sil2100> If, of course, it makes sense for xenial
[14:44] <pete-woods> sil2100: yep, definitely makes sense for xenial
[14:44] <dbarth_> Mirv: ack
[14:44] <jibel> kenvandine, also if in u-s-s I disable/enable apport the pattern is not set
[14:44] <dbarth_> and done
[14:44] <sil2100> pete-woods: then file in a similar merge for the .xenial one and I'll review it :)
[14:45] <jibel> ah it is now
[14:45] <pete-woods> sil2100: I'm being a bit dense, and can't spot the correct branch..
[14:45] <pete-woods> ubuntu.xenial doesn't seem to have anything about touch in it.
[14:47] <pete-woods> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.xenial
[14:47] <pete-woods> found it!
[14:47] <jibel> kenvandine, and gone again after reboot
[14:48] <sil2100> pete-woods: yep :)
[14:49] <Mirv> dbarth_: and https://code.launchpad.net/~dbarth/ubuntu-calendar-app/push-helper/+merge/280697
[14:50] <pete-woods> sil2100: right, got my act together now (https://code.launchpad.net/~pete-woods/ubuntu-seeds/ubuntu-touch.xenial-gnome-keyring/+merge/286335)
[14:50] <dbarth_> Mirv: ah that one i can't help; popey could though
[14:51] <sil2100> pete-woods: do you have a handy list of additional packages and their sizes pulled in by this new package?
[14:51] <popey> dbarth_: when is that (the 003) landing happening? cc Mirv
[14:52] <Mirv> popey: dbarth_: it's "upstream approved" and in QA queue but QA won't consider it until all branches are top-approved
[14:53] <popey> ah, okay
[14:54] <popey> i tested earlier in the week, but didn't approve it, so now have
[14:54] <pete-woods> sil2100: I can generate one
[14:54] <pete-woods> sil2100: but I don't have it to hand
[14:55] <pete-woods> it's not big, from what I remember
[14:56] <kenvandine> jibel, indeed you are right, toggling it in settings isn't triggering the job
[14:56] <boiko> rvr: silo 30 built
[14:57] <jibel> kenvandine, IIRC the pile of upstart jobs was here for a reason, I don't remember the details though
[14:57] <kenvandine> jibel, on rc-proposed i deleted /var/lib/apport/.apport-config-has-run and reboot /var/lib/apport/autoreport and rebooted
[14:58] <kenvandine> after booting autoreport was enabled and the core_pattern was set
[14:58] <sil2100> pete-woods: ok, if you didn't start yet then I'll just quickly gather the info :)
[14:58] <kenvandine> but toggling it in settings isn't changing core_pattern
[14:58] <rvr> boiko: Yeah, already testing it
[14:58] <pete-woods> sil2100: http://paste.ubuntu.com/15100434/
[14:58] <pete-woods> if that helps?
[14:58] <kenvandine> jibel, yeah, those old jobs were by me, this silo is landing an improvement from slangasek
[14:58] <boiko> rvr: nice! thanks!
[14:58] <kenvandine> improvement as in less delta to maintain :)
[14:59] <sil2100> pete-woods: thanks :)
[14:59] <kenvandine> jibel, apport-config should be getting triggered when /var/lib/apport/autoreport is created or removed
[14:59] <kenvandine> and at the end of that job it either starts or stops apport
[14:59] <kenvandine> which is what should be changing core_patter
[14:59] <kenvandine> +n
[14:59] <pete-woods> sil2100: the seed will pull in the recommends, right? (libpam-gnome-keyring and libp11-kit-gnome-keyring are vital)
[14:59] <kenvandine> that must not be happening
[14:59] <kenvandine> i
[14:59] <kenvandine> jibel, i'll comment on the merge proposal, thanks
[15:00] <pete-woods> it kinda looks like they don't from my apt command there
[15:00] <pete-woods> is apt configured differently on the phone, maybe?
[15:01] <pete-woods> I always thought you needed to do --no-install-recommends
[15:01] <pete-woods> to avoid them
[15:01] <sil2100> pete-woods: hm, yeah, not sure now if the seed pulls those in then
[15:02] <pete-woods> sil2100: http://paste.ubuntu.com/15100445/
[15:02] <pete-woods> at any rate there's a bigger install
[15:02] <pete-woods> but would have to revise the MR
[15:02] <sil2100> pete-woods: just in case add those to the seed change as well
[15:02] <pete-woods> sil2100: will do
[15:03] <sil2100> We'll need to bring this up through pmcgowan though
[15:03] <sil2100> pmcgowan: hey! Would you be ok with 4MB of disk-space eaten for gnome-keyring?
[15:04] <pmcgowan> sil2100, sure and lets find 4MB to save elsewhere :)
[15:04] <sil2100> pete-woods: I suppose it will be required by the creds storage in convergence?
[15:04] <pete-woods> sil2100: yep
[15:04] <pete-woods> sil2100: that's the main reason I want to use gnome-keyring, rather than my own db, so that convergence works more nicely
[15:05] <pete-woods> sil2100: I've updated the MR now (https://code.launchpad.net/~pete-woods/ubuntu-seeds/ubuntu-touch.xenial-gnome-keyring/+merge/286335)
[15:06] <pete-woods> for some reason it's not showing in the diff, though
[15:06] <pete-woods> but you can see the changes in r334
[15:06] <pete-woods> http://bazaar.launchpad.net/~pete-woods/ubuntu-seeds/ubuntu-touch.xenial-gnome-keyring/revision/334
[15:07] <sil2100> The diff has updated now, thanks
[15:07] <pete-woods> ah good, the diff has updated now
[15:13] <sil2100> pete-woods: hmm, so now I'm thinking (out loud) - I know that sooner or later we want all touch devices to be convergent, but will those packages be used on non-convergence-enabled devices?
[15:13] <sil2100> pete-woods: like, does it make sense to have on a device that doesn't have libertine?
[15:14] <pete-woods> sil2100: definitely does. the phone as it stands right now can still be used to connect to VPNs
[15:15] <sil2100> pete-woods: ok, makes sense - so only one cosmetic change request: could you move those packages from touch to touch-core? (the Core section there as well)
[15:15] <pete-woods> sil2100: of course
[15:16] <sil2100> pete-woods: it's more a structure thing nothing more, as we basically could just get rid of touch-core right now and just jam everything to touch
[15:16] <sil2100> But it's a nice touch to have those both detached for now in case we need to
[15:16] <sil2100> pete-woods: thanks!
[15:16] <rvr> boiko: Please, mark the silo ready for QA ... when ready :)
[15:16] <boiko> rvr: ouch, sorry, I forgot it resets the flag
[15:17] <boiko> rvr: done
[15:17] <pete-woods> sil2100: okay, the MR is updated again :)
[15:17] <rvr> boiko: Thanks
[15:18] <sil2100> pete-woods: excellent :)
[15:20] <sil2100> pete-woods: ok, will merge it in shortly and release with some other changes for both xenial and vivid-overlay
[15:22] <pete-woods> sil2100: awesome, thanks!
[15:43] <dobey> jibel: hey. can we get the IAP silo tested now please? :)
[15:43] <jibel> dobey, 41 ?
[15:45] <boiko> rvr: hi, the card moving to failed is just because it was rebuilt, right?
[15:45] <jibel> dobey, sure, it's been languishing in the ready queue long enough I guess, moved to the top.
[15:46] <rvr> boiko: Yes
[15:46] <jibel> boiko, yes, because a new one will be created once it's ready again
[15:46] <boiko> jibel: rvr: ok, thanks
[15:46] <rvr> I'm testing, anyway
[15:47] <boiko> rvr: if you find anything, you can ping me right away, this is my highest priority currently
[15:47] <dobey> jibel: great, thanks
[15:47] <rvr> boiko: Ok
[15:53] <dobey> with string/feature freeze on tuesday, we do need to get it landed asap :)
[16:31] <jibel> jhodapp, I'm rejecting silo 21, if there is a track with a # in the name, it works find in the music app but when played from the scope the client dies and then no track can be played anymore from the music scope
[16:32] <jhodapp> jibel, yeah it's not ready yet...it got labeled as being ready accidentally and apparently when you change the status in Bileto back to it not being ready it doesn't update the QA Trello board
[16:33] <jhodapp> jibel, apologies for you having to test it before it's fully ready
[16:33] <jibel> jhodapp, so just tell us and we remove the card
[16:34] <jhodapp> jibel, alright
[16:50] <sil2100> pete-woods: seed changes uploaded to both overlay and xenial
[16:50] <sil2100> Thanks!
[16:52] <pete-woods> sil2100: woot!
[17:41] <Saviq> robru, are you ever planning to parallelize source builds? must say waiting for them all to complete in sequence is meh
[17:43] <dobey> Saviq: eh? in the silo PPA?
[17:43] <Saviq> dobey, no, source *package* builds, in citrain jenkins
[17:43] <dobey> oh
[17:44] <dobey> yeah that is annoying
[17:44] <dobey> is there a bug for it?
[17:55] <Saviq> dobey, there is now, bug #1546661
[18:13] <rvr> boiko: Silo 30 approved
[18:23] <boiko> rvr: cool! thanks!
[19:54] <Saviq> trainguards, rebuild https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019/+build/9025867 please, thanks!
[20:03] <robru> Saviq: done
[20:03] <Saviq> robru, thank you
[20:04] <robru> yw
[21:08] <Saviq> robru, seems the same happened here https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/9026454
[21:08] <robru> Saviq: BLAM
[21:08] <robru> i killed it
[22:08] <Saviq> robru, would you be so kind as to upload oxide to silo 10 with this patch https://code.launchpad.net/~loic.molinari/oxide/oxide-ubuntu-scale-factor/+merge/286109
[22:08] <Saviq> oh uh, we should make that silo vivid-only then, shouldn't we...
[22:08] <robru> Saviq: unless you want the patch in both
[22:09] <robru> Saviq: i don't generally build source packages myself, usually somebody else does that then i just copy the package in
[22:09] <Saviq> robru, does train allow manual uploads for dual silos? thought it didn't
[22:09] <Saviq> robru, oh sure, lemme get you a source pkg then
[22:10] <robru> Saviq: it has for a while but it enforces the manual source being present in both series.
[22:10] <robru> Saviq: wait, if you have an mp why doesn't the train just build that?
[22:10] <Saviq> robru, oh cool, two ½GB source packages coming right up :D
[22:10] <Saviq> robru, oxide not train-released yet I think
[22:11] <robru> Saviq: why not get it ready? Would save a lot of hassle
[22:11] <Saviq> robru, looking at https://code.launchpad.net/~oxide-developers/oxide/oxide.trunk they commit to trunk
[22:11] <Saviq> and have separate packaging
[22:12] <robru> Saviq: so? Train can do null merges to release trunk
[22:12] <robru> Saviq: oh yeah you'd need the packaging inlined
[22:12] <Saviq> robru, so maybe not right now :)
[22:12] <robru> Saviq: somebody should do this soon though
[22:12] <Saviq> chrisccoulson, ↑↑
[22:58] <Saviq> robru, as you were, it's a bigger topic apparently
[22:59] <Saviq> (re: oxide)
[22:59] <robru> Oh heh
[23:05] <Saviq> robru, something's gone wrong with the s390x builders, stuck again https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/9027352
[23:08] <robru> Saviq: cancelled!
[23:09] <robru> Saviq: I'm heading out in a bit, let me know if you need anything
[23:09] <Saviq> robru, think I'm good now, thanks o/
[23:09] <robru> Probably be gone a few hours at least
[23:09] <robru> You're welcome