[08:26] <jibel> davmor2, can you take silo 28? it's rather urgent
[08:26] <davmor2> jibel: sure
[08:26] <jibel> davmor2, thanks:
[08:26] <jibel> !
[08:29] <sil2100> THanks guys!
[08:29] <sil2100> Still not known if and when we'll do the OTA-4.5, but we need to be ready
[08:52] <sil2100> Hey guys, I'll use rc-proposed channel for a bit
[08:52] <sil2100> (I'll break it)
[08:52] <sil2100> kk thx bye
[08:52] <Mirv> sil2100: nice!
[08:53] <sil2100> The cat is really interested in how I work, he's helping out with code and other duties
[08:53] <sil2100> By, for instance, blocking my view of the screen, trying to catch the mouse cursor and pressing random buttons
[08:56] <sil2100> Anyway, expect a strange image in the rc-proposed channel soon
[09:07] <Mirv> sil2100: really strange from the sounds of it :)
[09:07] <Mirv> catimage
[09:22] <sil2100> jibel, davmor2: I have a ubuntu community image for you guys to test
[09:24] <sil2100> jibel, davmor2: so, latest image in the rc-proposed/ubuntu channel is what you want
[09:25] <davmor2> sil2100: in a meeting get back to you after
[09:25] <sil2100> jibel, davmor2: mako 163, krillin 197 etc.
[09:49] <davmor2> sil2100, barry: silo 028 is broken.  On a production-reset the product turns itself off on or around wifi password
[10:09] <sil2100> davmor2: uh
[10:10] <sil2100> davmor2: not sure I understand, but I never used the production-reset function
[10:11] <davmor2> sil2100: it's the new function added to system-image in the silo
[10:19] <sil2100> I wonder why it's broken
[10:23] <ogra_> davmor2, its the old function that was used in rtm ... not new at all :)
[10:23] <ogra_> (there are new bugs around it perhaps though)
[10:23] <davmor2> ogra_: there are 2  --factory-reset       Perform a destructive factory reset and reboot.
[10:23] <davmor2>                         WARNING: this will wipe all user data on the device!
[10:23] <davmor2>   --production-reset    Perform a destructive production reset (similar to
[10:23] <davmor2>                         factory reset) and reboot. WARNING: this will wipe all
[10:23] <davmor2>                         user data on the device!
[10:24] <ogra_> davmor2, right, --production-reset was implemented before the device went into production
[10:24] <ogra_> factory reset is a bit older and foor endusers
[10:25] <davmor2> ogra_:   * LP: #1419027: Adding D-Bus method for production line reset    - Used by the advanced factory reset use case
[10:25] <ogra_> yeah
[10:26] <davmor2> ogra_: so apparently it is all rsalveti 's fault :)
[10:26] <ogra_> "...reset the phone and perform a delayed power off."
[10:26]  * rsalveti runs
[10:26] <john-mcaleely> as I recall, production reset turns the phone 'off' after a certain time
[10:27] <john-mcaleely> so it can go in a box with confidence
[10:27] <ogra_> yeah
[10:27] <davmor2> ah okay might not be an issue then
[10:27] <ogra_> thats what the bug says
[10:27] <rsalveti> oh, right
[10:27] <rsalveti> that is old
[10:27] <john-mcaleely> you're not expected to use the phone after the reset, just observe that it boots to the welcome page of the wizard
[10:28] <rsalveti> what is the issue?
[10:29] <davmor2> yeap got it. thanks  I think that thing that confused is it started the welcome wizard
[10:30] <davmor2> so I just need to confirm that it doesn't happen with factory-reset then
[10:32] <davmor2> rsalveti: none now :)
[10:32] <ogra_> davmor2, well, it boots normally and starts the wizard ... and at some point it does what you told it to (delayed power off)
[10:33] <davmor2> rsalveti: I missed the delayed shutdown
[10:35] <rsalveti> cool
[10:35] <sil2100> \o/
[11:01] <nik90> sil2100, davmor2: I fear something is wrong with mako image r163 on channel ubuntu-touch/rc-proposed/ubuntu. http://paste.ubuntu.com/11729906/
[11:01] <nik90> sil2100, davmor2: I just reflashed using u-d-f and still get the same...the unity8 version in this image comes with no shell rotation!
[11:01] <nik90> this is on a Mako Nexus 4
[11:03] <nik90> Mirv: ^^
[11:04] <Mirv> nik90: hmm. I can't test right now since my mako is running autopilot tests, but on the #162 I do have unity8 8.10+15.04.20150612-0ubuntu1 which should be new enough version.
[11:04] <davmor2> nik90: how are you testing it?
[11:04] <ogra_> nik90, shell rotation was landed after the OTA
[11:04] <ogra_> oh
[11:04] <nik90> Mirv: indeed I had shell rotation on image r162. Hell I even posted pictures of it on g+ ;)
[11:04] <nik90> it broke after I upgraded to r163
[11:04]  * ogra_ missed the -proposed in the channel name, ignore me 
[11:05] <nik90> davmor2: tested by upgrading from r162->r163 and also a normal u-d-f flash to r163 on my N4. Opened system-settings-app and no shell rotation
[11:05] <Mirv> nik90: oh! :)
[11:06] <Mirv> nik90: can you check what dpkg -s unity8 says there?
[11:06] <Mirv> the version, mostly
[11:06] <sil2100> nik90: yes
[11:07] <sil2100> Mirv: no worries, that's the strange image I mentioned :)
[11:07] <Mirv> sil2100: ah...
[11:07] <nik90> Mirv: Version: 8.02+15.04.20150603.1-0ubuntu1
[11:07] <Mirv> nik90: right, then that's older
[11:07] <sil2100> nik90, davmor2, Mirv: the latest rc-proposed image is now a snapshot image ;) With OTA-4 stuff in it
[11:07] <nik90> sil2100: oh
[11:07] <davmor2> sil2100: yeah that's what I was just thinking
[11:07] <sil2100> Remember! rc-proposed is meant to be full of strange stuff, it's never guaranteed to be reliable and working - next image will be with rotation again
[11:08] <sil2100> nik90: you should have your shell rotation in a few hours
[11:08] <sil2100> :)
[11:08] <nik90> sil2100: well so how I do get the latest stuff to develop on? which channel is recommened?
[11:08] <nik90> sil2100: I see rc-proposed/ubuntu-developer has not been updated for a long time either
[11:08] <nik90> just a bit confused
[11:08] <nik90> I need shell-rotation to test clock-app portrait lock and stuff
[11:12] <davmor2> nik90: rc-proprosed and just back it up a revision.
[11:13] <nik90> davmor2: how do I specify the revision?
[11:15] <mzanetti> sil2100, hey ho :) ^
[11:15] <mzanetti> I know there's another one with unity in it
[11:15] <mzanetti> I'd like to get started with testing the next one nevertheless. Will rebuild when the previous lands
[11:16] <davmor2> nik90: ubuntu-device-flash --revision -1 touch --channel <channel>
[11:16] <davmor2> nik90: or you can add a specific number ie 162
[11:16] <sil2100> mzanetti: on it
[11:16] <mzanetti> thanks :)
[11:16] <sil2100> nik90: are you developing apps?
[11:17] <mzanetti> he is :)
[11:17] <nik90> sil2100: hmm yes...clock-app dev ;)
[11:17] <mzanetti> nik90, btw, will you make fahrplan rotation-ready?
[11:18] <nik90> mzanetti: you want it to rotate? I will see how it looks in landscape
[11:18] <sil2100> nik90: then it's best to use stable ;)
[11:18] <nik90> sil2100: not when I am getting bug reports about clock app looking bad when running it on rc-proposed ;) in landscape form
[11:19] <sil2100> nik90: rc-proposed is not a channel for app developers, as it can have broken features...
[11:19] <sil2100> Well, for shell rotation, please wait a bit and it'll be back ;p
[11:19] <sil2100> Or quickly revert to the previous image ;)
[11:20] <nik90> sil2100: yeah I am reverting to r162..I was just surprised to experience this with r163..figured rc-proposed just mean latest development stuff..not OTA images ;)
[11:21] <ogra_> -proposed always means automatic daily builds and no QA
[11:21] <ogra_> or "mild" QA
[11:24] <sil2100> nik90: no no ;) rc-proposed is a transient channel that, indeed it has the latest development, but in theory should be only used by people working on core system components etc.
[11:24] <sil2100> Of course, we don't want to scare away people from using it
[11:25] <sil2100> But it's just good to know that we don't guarantee anything in that channel ;)
[11:25] <nik90> understood
[12:19] <ogra_> jibel, i just upgraded to 27 on my arale and see the SIM PIN disalog for the first time !
[12:20] <ogra_> (did we get any fixes or am i just lucky ?)
[12:20] <jibel> ogra_, take a screenshot, it's racy and maybe the only time you'll see it
[12:20] <ogra_> ha, to late
[12:21] <jibel> ogra_, there is no fix yet, I still reproduce on 27, but just adding debug code makes it much more difficult to reproduce
[12:21] <ogra_> yeah, timing issues are hard to catch
[12:33] <sil2100>  hmmm
[12:34] <sil2100> mzanetti: looking at the unity8 packaging diff right now
[12:35] <mzanetti> sil2100, anything wrong?
[12:35] <sil2100> mzanetti: I'm a bit worried by the versioned-dep
[12:36] <mzanetti> sil2100, this one? https://code.launchpad.net/~canonical-platform-qa/unity8/click_item_with_swipe/+merge/256961
[12:37] <sil2100> mzanetti: ...scratch that, it looks fine :)
[12:38] <mzanetti> ack :)
[12:38] <brendand> sil2100, i was *just* going to ask you about that :)
[12:38] <mzanetti> brendand, so... finally your branch landed :)
[12:38] <mzanetti> thanks for the patience
[12:38] <brendand> so patience, such waiting :P
[12:39] <brendand> mzanetti, thanks :) !
[12:48] <bfiller> sil2100: I want to switch sillo 7 from vivid to dual. can I do this myself with reconfigure?
[12:55] <mzanetti> cihelp: seems our jenkins jobs started failing because of a license check, but we didn't change those files in years: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/104/console
[12:56] <t1mp> was there a lp project that has all the scripts that are executed by jenkins?
[12:56] <mzanetti> bfiller, you can update the spreadsheet bug ci people need to wipe and reconfig
[12:57] <mzanetti> t1mp, this maybe: http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/files
[12:57] <bfiller> mzanetti: sorry, update what?
[12:57] <mzanetti> bfiller, the google doc :)
[12:57] <t1mp> zbenjamin, bzoltan: ^
[12:57] <bfiller> mzanetti: oh for the dual landing you mean?
[12:57] <t1mp> mzanetti: thanks
[12:57] <sil2100> bfiller: sadly no, series reconfiguration usually requires re-assigning silos
[12:58] <mzanetti> bfiller, yes
[12:58] <bfiller> mzanetti: thanks
[12:58] <bfiller> sil2100: ack, mind reconfiguring silo 7 then?
[12:58] <sil2100> bfiller: will have to re-assign (e.g. wipe existing packages), you fine with that?
[12:59] <bfiller> sil2100: yes
[12:59] <sil2100> On it then
[13:00] <fginther> mzanetti, looking
[13:03] <fginther> mzanetti, There was an update to the devscripts package and the licensecheck tool along with it on June 11 (which is when these errors started)
[13:03] <sil2100> bfiller: done
[13:03] <bfiller> sil2100: thank you!
[13:04] <mzanetti> fginther,  yeah, sounds reasonable. What would you suggest?
[13:04] <mzanetti> I guess the checklicenseheaders.sh needs to be updated
[13:04] <fginther> mzanetti, looks like a number of bugs were actually fixed in it (http://changelogs.ubuntu.com/changelogs/pool/main/d/devscripts/devscripts_2.15.5/changelog). Do these files actually need to be patched?
[13:04] <mzanetti> fginther, those files have the upstream Qt copyright header
[13:05] <fginther> mzanetti, ohhh, that sucks then :-/
[13:05] <fginther> mzanetti, well, sucks for me I guess
[13:05] <mzanetti> heh
[13:05] <mzanetti> fginther, let me try running things manually on them
[13:05] <mzanetti> maybe we can find a solution that doesn't such for you
[13:06] <fginther> mzanetti, looks like they are all in a plugins dir, should be possible to exclude that
[13:06] <mzanetti> hmm... not a big fan of that... lots of our code is the plugin dir
[13:06] <sil2100> bfiller: yw!
[13:07] <fginther> mzanetti, ok, let me look at some other options too
[13:09] <sil2100> Ok
[13:09]  * sil2100 switches to maintenance mode now
[13:10] <sil2100> I should be around on IRC but not all the time
[13:15] <mzanetti> fginther, ok... still passing here on my vivid+overlay, seems wily only problem
[13:16] <fginther> mzanetti, yeah, the regression appears to have been introduced in 2.15.5 which is still only in wily
[13:16] <fginther> mzanetti, the only solution I have so far is to exclude those specific files
[13:16] <greyback> trainguards: hey, could I get a silo for spreadsheet line 60 please
[13:18] <mzanetti> fginther, sounds ok for a temporary measure... but not feeling really comfy with that in the long run
[13:19] <sil2100> greyback: ok
[13:19] <barry> davmor2: afaik, it isn't si 3.0's fault.  all production-reset does is write the following to ubuntu_command and then reboot: format data; enable factory_wipe
[13:20] <davmor2> barry: it's okay it was meant to happen
[13:20] <barry> davmor2: cool
[13:21] <sil2100> greyback: assigning, I added qtubuntu-gles and qtmir-gles
[13:21] <fginther> mzanetti, another option is to remove the check completely
[13:21] <sil2100> greyback: this should make the -gles bits easier, as you won't need a trainguard for the reconfigure
[13:21] <greyback> sil2100: thanks. I tend to add those after once the non-gles ones build
[13:22] <mzanetti> fginther, let me check if I can update that header to a slightly different format to make it pass or so
[13:22] <greyback> sil2100: ah cool, I'll do that in future
[13:22] <sil2100> greyback: yeah, you still need to do this, but without those pre-defined you would need us for the reconfigure, now you can reconfigure it yourself :)
[13:22] <greyback> yay!
[13:37] <mzanetti> fginther, this fails: ** Copyright (C) 2014 Canonical, Ltd. and/or its subsidiary(-ies).
[13:38] <mzanetti> this passes: ** Copyright (C) 2014 Canonical.
[13:38] <mzanetti> this does look like a bug in the tool to me
[13:38] <rvr> sil2100: My personal krillin still hasn't got any update notification
[13:39] <sil2100> rvr: strange, you're on the right channel, right?
[13:39] <rvr> sil2100:  channel: ubuntu-touch/stable/bq-aquaris.es
[13:40] <mzanetti> fginther, actually it's only the "/" in the and/or line. I'll work around it in our repo
[13:40] <sil2100> rvr: might be somehow related to the fact it's .es, but in theory it should be a redirect to .en
[13:40] <fginther> mzanetti, Are those files regularly updated from upstream?
[13:41] <mzanetti> fginther, no
[13:41] <mzanetti> only when we copy the file we keep the header intact
[13:41] <fginther> mzanetti, ack, this doesn't sound like that gross of a workaround then
[13:42] <mzanetti> no... seems ok if I don't hit other headers that fail for different reasons. I'll let you know
[13:42] <fginther> mzanetti, thanks
[13:43] <jibel> rvr, if you adb shell what is the output of sudo system-image-cli -vn
[13:45] <rvr> jibel: sil2100: Yeah, it redirects to bq-aquaris.en http://paste.ubuntu.com/11730546/
[13:45] <rvr> Upgrade path is 23 Target phase: 5%
[13:45] <rvr> What is target phase?
[13:46] <jibel> sil2100, ^ do you know?
[13:46] <sil2100> No idea
[13:47] <sil2100> I checked and on s-i the phasing percentage it 100%
[13:47] <davmor2> barry: ^
[13:48] <barry> sil2100, davmor2 what's the problem?
[13:48] <davmor2> barry: rvr has a real device it hasn't upgraded yet
[13:48] <ogra_> was the .es channel actually relesed ?
[13:48] <ogra_> i thought we dropped that one
[13:49] <jibel> ogra_, this device has been purchased from BQ
[13:49] <barry> rvr: what does `system-image-cli --version` say?
[13:49] <rvr> balloons: http://paste.ubuntu.com/11730579/
[13:49] <rvr> Ooops
[13:49] <rvr> barry: ^
[13:50] <ogra_> jibel, sure, i just remember talk that we wouldnt do .es anymore
[13:50] <barry> rvr: --version not --info :)
[13:50] <jibel> ogra_, it's an alias to .en
[13:50] <rvr> barry: system-image-cli 2.5.1
[13:50] <barry> rvr: okay, that's good at least
[13:50] <ogra_> jibel, aha, so i remembered right ...
[13:51] <ogra_> so it is probably the following of aliases thats not correct
[13:52] <barry> rvr: and if you remove the -n, does it upgrade?  or what do the logs say?
[13:52] <rvr> barry: system-image-cli -v ?
[13:53] <barry> rvr: yes
[13:53] <rvr> It downloads something
[13:53] <barry> it should upgrade because there is apparently no phase for image 23
[13:53] <barry> (target phase is the phase of the device)
[13:54] <jibel> rvr, and from the UI there was no notification and nothing in 'software updates'?
[13:55] <rvr> jibel: Nope
[13:55] <jibel> rvr, can you interrupt the download and check again?
[13:55] <rvr> jibel: Yeah, that's what I did
[13:55] <rvr> I'm stuck here:
[13:55] <rvr> [systemimage] Jun 17 14:53:37 2015 (7473) [0xb63aabb0] Running group download reactor
[13:55] <barry> rvr: you might want to kill system-image-dbus and let it get reactivated
[13:55] <barry> rvr: you could tell more status with more -v's
[13:56] <barry> (generally, we don't bombard the console with udm's chatty progresses)
[13:56] <rvr> barry: Ok
[13:57] <ogra_> just add -vvvvvvvvvvvvvvvv
[13:57] <ogra_> ;)
[13:57] <ogra_> (then it will probably print machine code)
[13:57] <barry> ogra_: or --veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeewheeeeeeeeeeeeeeeekhaaaaaaaaaaaaaaaaaaaaaaaaaaaaan
[13:58] <ogra_> haha
[13:58] <rvr> lol
[13:59] <barry> sil2100: while we're here, we're going to have to rethink how to do the si client branches.  upstream branch is in git now so the merge-upstream recipe is different... and not working :(   is it possible to drive the train with git branches?
[13:59] <sil2100> barry: uuuu, currently no, I think robru wanted to add that once but he's busy with bileto, the spreadsheet replacement
[13:59] <sil2100> ;/
[14:00] <barry> sil2100: the problem i'm having is that after doing `bzr merge-upstream <path-to-.tar.gz>` and then `bzr bd -S` fails with unexpected changes to upstream source.  even reverting the change to the file that it claims to be changed, bzr bd -S still fails
[14:00] <barry> sil2100: that's probably higher priority ;)
[14:01] <barry> sil2100: well, i guess i know what i'm doing for the rest of this week :(
[14:04] <rvr> barry: http://paste.ubuntu.com/11730629/
[14:04] <rvr> barry: After that I think it beings to download something, I cancelled
[14:04] <barry> rvr: okay, you should kill that and then use ps to find the ubuntu-download-manager, and kill that
[14:05] <barry> rvr: start fresh, and then do the command again.  sometimes udm gets confused
[14:05] <barry> rvr: you're on wifi right?
[14:05] <rvr> barry: Right
[14:05] <barry> yeah, so it should work, unless you're having other network problems.  basically that paste is telling me that udm is stuck
[14:08] <rvr> barry: Stuck, but downloading
[14:08] <barry> rvr: at the point where the log ends, we are at the mercy of udm
[14:09] <rvr> barry: So, if this is downloading, then it knows there is an image available
[14:09] <rvr> But there is no notification
[14:09] <barry> rvr: correct
[14:09] <barry> rvr: notification?  through the cli, it's the console output.
[14:10] <rvr> barry: My "complain" is that I haven't got any system update notification, and the update screen is System Settings don't show it as available neither
[14:11] <barry> rvr: okay, so let's do this...
[14:11] <barry> rvr: first, kill system-image-cli
[14:11] <rvr> Done
[14:11] <barry> rvr: next, kill any ubuntu-download-manager process that might still be running
[14:11] <rvr> Done
[14:11] <barry> rvr: next, kill any system-image-dbus process that might still be running
[14:11] <barry> rvr: kill any system-settings process (i.e. the ui)
[14:11] <rvr> Done
[14:12] <davmor2> jibel, sil2100: Finally silo028 is done
[14:12] <barry> rvr: cool, now, in a separate shell, do this: `tail -f /var/log/system-image/client.log`
[14:12] <rvr> Application closed
[14:12] <barry> rvr: and then fire up the system-settings ui and start a check for upgrade.  watch the log tail.  you should see something very similar to your previous console output
[14:13] <rvr> barry: Now it is there o_O
[14:13] <rvr> barry: It's downloading now
[14:14] <barry> rvr: cool.  sometimes when udm gets confuzzled, it confuzzles the whole stack upwards :/
[14:15] <barry> rvr: if you really want some sneaky, once/if si 3.0 is landed you can bypass udm and use the built-in curl based downloader.  we use that on snappy and it avoids the problems of udm
[14:16] <rvr> barry: I worry more about users having this problem
[14:17] <barry> rvr: i'm not sure what to do about it.  i've been asking for udm to get some love for a *long* time
[14:17] <rvr> I don't know which magic you used, but after canceling and rebooting again, System Settings > Update shows and downloads the image.
[14:18] <barry> rvr: killing all those processes usually gets things back into a usable state.
[14:18] <rvr> barry: Does system-image-cli cache requests somehow?
[14:19] <barry> rvr: it does cache full downloads so that updates can be resumed more quickly, but the checksums and signatures must still be valid, or it will ignore any cached data files
[14:20] <rvr> barry: I see
[14:30] <popey> sil2100: I added a line to ci spreadsheet for clock r280 as requested by rvr and nik90. can you please check it and press whatever button is needed to make it go to trello?
[14:31] <rvr> popey: It's automatic, there is a bot for that :)
[14:31] <popey> \o/ bots
[14:32] <rvr> popey: Although I don't know how the status field is managed by CI
[14:36] <jhodapp> sil2100, can I get a silo for line 61 please?
[14:38] <oSoMoN> trainguards: I added a merge request to silo 16, can I reconfigure the silo myself, or do you have to do it?
[14:51] <jhodapp> oSoMoN, they'll most likely have to do the reconfigure
[14:54] <mzanetti> fginther, status update: https://bugs.launchpad.net/ubuntu/+source/devscripts/+bug/1466098
[14:56] <fginther> mzanetti, thanks
[15:04] <mzanetti> fginther, this seems a good idea in any case: https://code.launchpad.net/~mzanetti/pbuilderjenkins/dont-check-generated/+merge/262235
[15:04] <mzanetti> I can work around the other's in the unity code base for now
[15:07] <fginther> mzanetti, cool, if you can add a changelog update to that MP, we can get that updated
[15:11] <mzanetti> fginther, done
[15:12] <fginther> mzanetti, can you change UNRELEASED to wily?
[15:12] <fginther> mzanetti, That's caused problems for me in the past
[15:12] <mzanetti> yes
[15:13] <mzanetti> fginther, done
[15:13] <fginther> mzanetti, thank you sir!
[15:14] <mzanetti> :)
[15:15] <jhodapp> robru, ping
[15:51] <oSoMoN> trainguards: I need silo 16 to be reconfigured, can someone please take care of this?
[16:23] <davmor2> sil2100, jibel: image 163 tested on mako looks good here
[16:35] <robru> oSoMoN: you can reconfigure that yourself. you only need trainguards when you're adding new packages, not adding new MPs for existing packages.
[16:35] <robru> jhodapp: hi
[16:36] <oSoMoN> robru, ah, thanks, sorry I never remember that right
[16:36] <jhodapp> robru, oh good to know, I didn't realize that either
[16:36] <jhodapp> robru, just need a silo for line 61 please
[16:37] <robru> jhodapp: oSoMoN: yeah one of our goals is to expand user empowerment so that you guys aren't waiting for me all day long, but spreadsheet replacement is the number one priority right now
[16:38] <robru> jhodapp: silo 38
[16:38] <jhodapp> thanks robru
[16:38] <robru> you're welcome
[16:38] <oSoMoN> robru, that makes sense. how is the spreadsheet replacement coming along, btw?
[16:39] <robru> oSoMoN: http://requests.ci-train.staging.ubuntu.com/ it's a thing that exists ;-) I'd say 90% done, but there's lots of fiddly integration bits that still need to be done.
[16:39] <oSoMoN> neat. I can’t wait for it to be live (and I know I’m not alone :))
[16:39] <robru> oSoMoN: yeah you and everybody else ;-) l0(
[16:39] <robru> ;-)
[16:41] <jhodapp> robru, so I've not built qtmultimedia-opensource-src before...this MR is a diff to the package branch...it is complaining that it's missing the package qtmultimedia-opensource-src-gles
[16:41] <jhodapp> robru, do I need to add that to the addition source packages column?
[16:41] <jhodapp> *additional
[16:42] <robru> jhodapp: well you probably want a second MP for the -gles branch as well, those need to be kept in sync.
[16:42] <jhodapp> robru, but nothing changed in that branch
[16:43] <robru> jhodapp: doesn't matter, there's rules in place enforcing -gles variants always have matching version numbers. if you're releasing one you need to release the other
[16:44] <jhodapp> robru, hmm interesting...so basically a no-change MR and then the silo will bump the release version numbers?
[16:44] <jhodapp> robru, or I guess it'd be Jenkins that would do the version bump
[16:44] <robru> jhodapp: errr, no. the branch should have a debian/watch that scans for the non-gles and rebuilds that package with the same changes.
[16:45] <robru> jhodapp: -gles is a special rebuild of the same package, it needs to have the same contents as what you're releasing for non-gles.
[16:45] <jhodapp> robru, oh interesting
[16:46] <robru> I wonder if Mirv is around to explain how he manages his -gles packages
[16:46] <robru> I know how kgunn does it...
[16:46] <jhodapp> robru, line 60 has some from greyback, like 58 from Mirv
[16:48] <robru> jhodapp: I was thinking more like this: https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_12-6-2015-gles/+merge/261832 (but ignore the merge conflict and just look at debian/watch)
[16:49] <greyback> I usually check out the -gles branch, update the changelog to have matching debian version string to the non-gles packages, update the watch file to suit the landing PPA, and create a MP. Then add that MP to the silo
[16:49] <robru> jhodapp: but I'm not sure if qtmultimedia-opensource-src-gles is set up to use debian/watch or not, you'd have to figure that out
[16:49] <bzoltan> robru: ehh... mergeconflict? I need to fix that too
[16:49] <jhodapp> robru, ok thanks man
[16:49] <robru> jhodapp: youre welceme ;-)
[16:49] <robru> wow fat fingers today lol
[16:49] <jhodapp> greyback, so one MP only right?
[16:50] <greyback> jhodapp: one MP for non-gles, one for -gles
[16:50] <jhodapp> greyback, ok...so those two MP's are identical?
[16:51] <jhodapp> greyback, or where do they differ (if they do)?
[16:51] <greyback> jhodapp: no, the -gles one is only a fancy debian packaging branch, which imports the code from the non-gles branch
[16:51] <greyback> jhodapp: what project, qtubuntu?
[16:51] <jhodapp> greyback, qtmultimedia-opensource-src
[16:52] <greyback> jhodapp: hmm, I don't know how that one is done, sorry. I had thought they were uploaded manually
[16:52] <greyback> Mirc would know more
[16:52] <greyback> Mirv
[16:53] <robru> jhodapp: yeah I'm not sure exactly how mirv does his because he usually does source uploads, which are a little bit opaque from the train perspective
[16:54] <jhodapp> robru, greyback ok, I'll sync up with Mirv and see if I can't learn how to do this
[16:55] <jhodapp> thanks for the assistance
[16:56] <robru> jhodapp: you're welcome
[16:57] <robru> boiko: https://code.launchpad.net/~tiagosh/ubuntu/wily/telepathy-qt5/update-0.9.6.1/+merge/262167 this branch is an UDD branch which is not supported by the train. you'll need to push that somewhere else and propose a new merge in order to get a silo.
[17:00] <boiko> robru: ah yes, sorry, that package (telepathy-qt5) should be a source upload, let me remove from the list of MPs
[17:02] <boiko> robru: what do you need for the source upload? the .dsc, .changes and the tarball itself?
[17:04] <robru> boiko: the easiest thing is if you just upload it into a PPA you own and then I'll copy it into the silo PPA.
[17:05] <boiko> robru: yep, ok
[17:10] <robru> boiko: oh hrm what are you expecting to happen with a manual source upload in a dual silo?
[17:11] <boiko> robru: I really don't know :D
[17:11] <robru> boiko: I think that behavior is undefined. let me just read the source real quick to figure out what'll happen...
[17:11] <boiko> robru: well, we want to land this new telepathy in wily and on the vivid overlay too
[17:13] <robru> boiko: yeah, I think this isn't going to work. the "secondary" build will try to copy the source from the primary build but the primary build doesn't exist because only MPs have that.
[17:13] <boiko> robru: so what would you suggest then? we land in wily first and then sync to vivid overlay?
[17:13] <robru> boiko: so if you want to keep it a dual silo you'll have to figure out a way to do an MP for telepathy-qt5, or you'll have to release one silo to wily and then do a second silo to sync wily back to vivid
[17:14] <boiko> robru: maybe the sync silo approach will be easier for this case
[17:14] <robru> boiko: alright I'll make it a wily silo for now
[17:14] <robru> boiko: sorry about that, didn't anticipate this use case.
[17:14] <boiko> robru: nice! thanks!
[17:15] <boiko> robru: no worries
[17:15] <greyback> where has the silo reconfigure button gone?
[17:15] <robru> greyback: to a menu at the top
[17:16] <greyback> robru: of the CI dashboard?
[17:16] <robru> greyback: of the spreadsheet.
[17:18] <greyback> perhaps I'm not allowed to
[17:18] <greyback> I simply cannot find it
[17:18] <robru> boiko: ok let me know when you've got that -qt5 package prepped and I'll copy it in
[17:18] <robru> greyback: are you logged in?
[17:18] <greyback> robru: would you please reconfigure silo36 for me, added the -gles twins
[17:18] <greyback> robru: yeah
[17:19] <boiko> robru: sure, working on it
[17:19] <robru> greyback: do you see the menubar that's like "File Edit View ... Addons Help Landing Tools"?
[17:19] <greyback> robru: omg up there
[17:19] <greyback> I didn't know we could stuff up there
[17:19] <robru> greyback: welcome to google spreadsheets ;-)
[17:20] <robru> greyback: don't worry, in a month this'll all be gone and you'll have to relearn the new thing
[17:20] <robru> greyback: oh but if you added a package I have to do it for you anyway, hang on
[17:20] <greyback> robru: no, sil already added them
[17:21] <greyback> as additional source packages to land - exactly so I could recofigure myself, and wouldn't have to bother you
[17:21] <robru> greyback: oh great
[17:21] <robru> greyback: make sure you delete the source packages from the source package column then, that'll screw things up
[17:21] <greyback> robru: ah ok
[17:23] <slangasek> who owns the platform-api?   The branch is owned by 'phablet-team'
[17:23] <slangasek> (I need someone to own bug #1465958)
[17:23] <slangasek> hmm maybe I should just submit a branch and see what happens :)
[17:24] <greyback> slangasek: no clear maintainer afaik, people only touch it when they have to.
[17:24] <slangasek> well that's suboptimal!
[17:26] <slangasek> ogra_: ^^ see, if we had all these packages through the MIR process, nobody would be allowed to drop them on the floor ;)
[17:27] <greyback> slangasek: this wouldn't happen to help you, would it: https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170
[17:28] <robru> boiko: lol, so while we were talking, greyback went ahead and discovered on his own what happens when you have a manual source upload configured in a dual silo: https://ci-train.ubuntu.com/job/ubuntu-landing-036-1-build/22/console
[17:28] <slangasek> greyback: I'm happy to point at the mir team, sure :)
[17:29] <boiko> robru: yeah, we better do it in two steps then
[17:29] <robru> boiko: yeah I think that'll work best
[17:38] <ogra_> slangasek, yes, i'm fully with you, it wasnt me who decided to stop nagging about MIRs
[17:42] <robru> brb
[18:04] <robru> barry: I think you put columns I and J on the wrong row there
[18:05] <robru> barry: kenvandine: I gotta step out for a longer lunch, can somebody cover trainguard duty for an hour or two? shouldn't be too busy
[18:09] <Mirv> robru: jhodapp greyback: qt*-opensource-src-gles is different from qtmir-gles & co since Qt doesn't have source branches (only packaging), the -gles are not handled via branches, and the packages are actually different and contain only portions of the non-gles packages.
[18:10] <mzanetti> trainguards, hey, any reason why silo 41 seems stuck?
[18:10] <barry> robru: dang.  very hard to parse the spreadsheet, but that's nothing you don't already know ;)
[18:10] <barry> robru: sure, i can
[18:11] <Mirv> robru: jhodapp greyback: my method is about the following: dget latest -gles.dsc , quilt pop all patches, bzr init, bzr add * .qmake.conf .tag, apply bzr diff from the non-gles branch's changes _as far as they apply to gles, including to different package names like libfoo-gles.install_, add a simple "sync with ..." changelog entry, double-check all the changes are correct and upload
[18:11] <boiko> robru: https://launchpad.net/~boiko/+archive/ubuntu/source-uploads/+packages
[18:11] <boiko> robru: telepathy-qt5 to copy to silo 39
[18:12] <jhodapp> Mirv, upload to where?
[18:12] <robru> barry: can you copy that package for boiko? I'm afk sorry
[18:13] <Mirv> jhodapp: to the PPA, you need a trainguard for that. you also need to a trainguard to upload the normal package, branch cannot be used since it's only a packaging branch
[18:13] <boiko> robru: barry: it is not super urgent though, it can wait a bit if you guys need time, that's fine
[18:13] <jhodapp> Mirv, hmm interesting
[18:14] <robru> mzanetti: https://jenkins.qa.ubuntu.com/job/wily-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/console autopkgtest regression, you'll need to investigate
[18:14] <barry> boiko: sorry, what do you need?
[18:15] <jhodapp> Mirv, I'll give that a try and let you know if I have questions, thanks
[18:17] <mzanetti> robru, interesting. how would I get to this log from the dashboard?
[18:17] <mzanetti> ah... just found it
[18:19] <Mirv> jhodapp: I can also handle both for you, but I'd prefer that loicm gets to submit the branches upstream so I can get the patches with proper headers from upstream code tracker
[18:20] <jhodapp> Mirv, sure that'd be fine and much appreciated. loicm isn't quite ready to submit it upstream as he still needs to write unittests for it
[18:20] <Mirv> jhodapp: but since I'm away after tomorrow for two weeks you may need to handle it with sil2100/robru, doing manual uploads to the PPA (bzr bd -S will just work and fetch the orig tarball, and the -gles as guided above)
[18:20] <jhodapp> Mirv, how long would it take you to get into a silo?
[18:22] <Mirv> jhodapp: 1 mins for the normal package it seems, I just uploaded the normal package to the PPA. you need need the -gles until it's ready and patches are finalized.
[18:23] <Mirv> the package has a test version 5.4.2-1ubuntu2~wily1~test1 which can be incremented for iterations
[18:23] <Mirv> jhodapp: so it's building now https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-038/+packages
[18:23] <jhodapp> Mirv, oh awesome, thanks for doing that
[18:23] <Mirv> np
[18:24] <Mirv> "you need need the -gles" == "you don't need the -gles"
[18:24]  * Mirv time to get some sleep :)
[18:24] <jhodapp> Mirv, have a good one
[18:25] <Mirv> robru: so the silo should actually be configured with manual uploads of qtmultimedia-opensource-src and qtmultimedia-opensource-src-gles, not a MP
[18:25] <Mirv> thanks!
[18:35] <boiko> barry: sorry, got a phone call here, I just need telepathy-qt5 copied from here: https://launchpad.net/~boiko/+archive/ubuntu/source-uploads/+packages to silo 39
[18:36] <barry> boiko: okay.  not sure i know how to do that but i'll try ;)
[18:37] <boiko> barry: thanks :)
[18:45] <barry> boiko: okay, sorry i don't know how to do that.  let's wait for robru to return and then he can tell both of us ;)
[18:45] <boiko> barry: no problems, thanks for trying :)
[18:49] <barry> why train, why?
[18:50] <ogra_> did you pay your ticket ?
[18:50] <barry> apparently not.  is casey jones driving this thing?
[18:52] <barry> console says it successfully uploaded the packages, but the ppa is empty
[19:15] <robru> barry: can you use the ppa page to copy packages? It's nothing train specific, just needs a regular copy-package
[19:16] <barry> robru: i tried copy-package but it failed
[19:17] <robru> barry: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-040 there's nothing in your ppa. Upload is being rejected. Most likely the version number is invalid. Ensure the version number is higher than any previous uploads.
[19:18] <robru> barry: for boiko 's request, if you go to the page for his ppa, click package details, there's a button "copy packages", then you can pick the silo ppa s destination.
[19:19] <robru> barry: I'm still afk sorry, family visiting
[19:19] <boiko> robru: maybe at some poit it would be easier if landers had the ability to do that themselves?
[19:19] <barry> robru: ah, cool.  i guess you can't copy-package from one ppa to another from a local machine
[19:20] <barry> robru, boiko anyway, trying to copy package via the web page to Landing PPA 039 (RTM) -- correct destination boiko?
[19:20] <barry> robru: 3.0.1-0ubuntu1 should be higher than any previous upload, but i guess i'll bump it to 3.0.1-0ubuntu2 for grins and giggles
[19:20] <boiko> barry: it is this ppa: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039, not sure if it is the Landing PPA 039 (RTM)
[19:21] <robru> barry: not rtm
[19:21] <barry> boiko: got it.  question: same destination series? (i.e. wily).  rebuild copied source or copy existing binaries?
[19:22] <boiko> barry: too many questions :D
[19:22] <robru> barry: if version bump fails, ping an lp person to get the upload failure message. Train doesn't get them
[19:22] <robru> barry: rebuild
[19:22] <barry> robru: ack
[19:22] <barry> robru: ack
[19:22] <boiko> barry: so, wily, I think rebuild is better because my private ppa has only x86 builds, I need the armhf one too
[19:22]  * barry is a good button pushing monkey 
[19:23] <barry> boiko: done.  let's see what happens!
[19:23] <boiko> barry: thanks a lot!
[19:23] <boiko> robru: thanks for the help
[19:23] <robru> barry: thanks a bunch, in still an hour away from a keyboard
[19:23] <barry> yeppers
[19:24] <robru> boiko: you're welcome
[19:24] <barry> robru: so. after version bump and push to branch, just reconfigure my silo?
[19:35] <robru> barry: no reconfigure, just build
[19:36] <barry> robru: okay.  ppa still looks empty anyway, but i'll let this definitively fail before i proceed
[19:37] <bfiller> rvr: thanks for testing silo 8, saw you marked it passed. can you update the spreadsheet so it gets published?
[19:43] <robru> barry: check with lp admin, they have access to the rejection emails
[19:46] <barry> robru: ack
[19:51] <barry> robru: not sure any lp admins are around.  i'm thinking about just force cleaning the silo, deleting the row and starting over.  is that insane?
[19:56] <AlbertA> trainguards: can I get a silo for line 64?
[19:56] <barry> AlbertA: now that i think i can do ;)
[20:10] <slangasek> so according to https://jenkins.qa.ubuntu.com/job/platform-api-ci/421/console, platform-api is FTBFS on vivid/armhf and vivid/i386.  But this is not a regression introduced by my MP.  Why was this not caught as part of the testing of the mir landing?
[20:13] <AlbertA> camako: ^
[20:13] <AlbertA> slangasek: vivid + overlay?
[20:14] <AlbertA> or just vivid?
[20:14] <slangasek> AlbertA: it's vivid+overlay, based on the version numbers
[20:14] <slangasek> the bug in question would also affect wily, so it's apparently landed there too
[20:15] <slangasek> so it seems platform-api lacks any autopkgtests that would catch this, for one thing
[20:15] <slangasek> and from the other direction, mir is having api changes that land without coordinated reverse-dep rebuild testing?
[20:17] <robru> AlbertA: tossing a silo and starting over isn't inherently insane, but what problem are you facing that you want to do that? starting a fresh silo with same old MPs probably won't fix anything. unless you mean throwing branches away and starting those over too
[20:18] <robru> barry: back now, thanks a bunch
[20:18] <barry> robru: np.  cjwatson is going to look into the issue i'm having in a few hours or tomorrow morning.  i'll just do other things in the meantime
[20:19] <AlbertA> robru: ?
[20:21] <AlbertA> slangasek: camako: we typically don't rebuild rdeps if we don't break ABI
[20:22] <AlbertA> slangasek: but I'm unsure on what happened this time
[20:23] <robru> AlbertA: oh sorry, that was supposed to be barry
[20:23] <robru> barry: so tossing the silo and starting over isn't inherently insane...
[20:24] <robru> barry: but I mean, it's unclear to me whether that would actually work, since we don't know the nature of the upload failure.
[20:25] <robru> jhodapp: so I configured the silo the right way around but it's up to you to get those packages prepared manually, which I'm largely unfamiliar with. easiest thing for me is if you upload them to a PPA that you own and then I can copy them into the PPA.
[20:26] <barry> robru: right.  i think i'll wait to see if cjwatson can reveal anything, and if not (or even if so) will just redo it
[20:26] <jhodapp> robru, I thought Mirv had prepared it already, maybe I misunderstood what exactly he did
[20:28] <robru> jhodapp: I'm just rereading it now, my understanding is that he was explaining what to do. I just configured the silo the way he recommended.
[20:28] <jhodapp> robru, alright, but he kicked off a build of it
[20:28] <jhodapp> robru, in that silo
[20:29] <robru> jhodapp: oh he did, excellent
[20:30] <jhodapp> robru, indeed, so I think we're good for now
[20:30] <robru> jhodapp: ok, so that package is built, nevermind the silo status "silo ready to build", you can start testing that if you want
[20:30] <jhodapp> robru, awesome, thanks for looking into this though
[20:30] <robru> jhodapp: at some point between now and publication time you'll have to figure out the -gles half, which is still missing though
[20:30] <jhodapp> robru, alright
[20:31] <robru> jhodapp: -gles is only used in the emulator, so basically "make sure current silo works on device, then fix up -gles to match so the emulator doesn't bit-rot"
[20:31] <camako> AlbertA, "@but I'm unsure on what happened this time"... A bunch of event structures have now been hidden in a private header.
[20:32] <robru> barry: so I just checked, system-image was never in that silo before, so versioning isn't the issue. yeah we'll have to wait for somebody to get the exact rejection reason
[20:32] <robru> barry: or I suppose you could try uploading it yourself outside the train and then you'd get the rejection email
[20:33] <AlbertA> camako: ok which is taken care of by https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170  I see
[20:35] <robru> mzanetti: sorry I was afk earlier, did you need any more help with silo 41?
[20:35] <bfiller> robru: mind reconfiguring silo 20? added a new package
[20:37] <robru> bfiller: dobe
[20:37] <robru> done
[20:37] <bfiller> robru: thanks
[20:37] <robru> bfiller: you're welcome
[20:38] <mzanetti> robru, should be fine. dobey is landing a fix for that soon
[20:39] <robru> great
[20:40] <dobey> robru, mzanetti: fix is in silo 22 which is "testing pass. ready to publish" now
[20:41] <robru> dobey: ah, publishing, thanks
[21:23] <boiko> robru: could you please trigger a rebuild of latest vivid build of telephony-service on ppc64el on silo 20?
[21:24] <robru> boiko: done
[21:25] <boiko> robru: thanks!
[21:26] <robru> boiko: you're welcome
[21:27] <rvr> bfiller: Sorry, done!
[21:29] <robru> bfiller: renatu: https://code.launchpad.net/~renatofilho/address-book-app/fix-share/+merge/261651 need this MP approved to publish
[21:31] <renatu> robru, ok I will ask boiko or bill to appove it
[21:32] <boiko> renatu: I can review it
[21:33] <renatu> boiko, please, bfiller already tested it just need a code review
[22:14] <cjwatson> 2015-06-17 17:57:13 DEBUG   Rejected:
[22:14] <cjwatson> 2015-06-17 17:57:13 DEBUG   Unable to find system-image_3.0.1.orig.tar.gz in upload or distribution.
[22:14] <cjwatson> 2015-06-17 17:57:13 DEBUG   Files specified in DSC are broken or missing, skipping package unpack verification.
[22:14] <cjwatson> barry: ^-
[22:15] <cjwatson> missing -sa in the train's build for this package I guess
[22:16] <cjwatson> barry: if it were me, I'd probably just build it myself and upload manually, but up to you to work out how to otherwise match what the train's doing, make sure the spreadsheet is happy, etc.; that's outside my competence
[22:18] <robru> cjwatson: thanks
[22:19] <cjwatson> I really must sort things out so that something trainy gets rejection mails.  I had plans for that at one point
[22:19] <cjwatson> anyway, bedtime
[22:21] <robru> cjwatson: I think all that needs to happen is for ~ci-train-bot to have it's email address changed to a team mailing list
[22:21] <robru> cjwatson: but #is owns the account, i can't do that myself
[22:21] <robru> barry: so basically I guess this comes down to your packaging being goofy.
[22:21] <robru> barry: debian/watch isn't supported, only split packaging is supported. at least for MPs
[22:23] <robru> barry: https://wiki.ubuntu.com/DailyRelease/InlinePackaging this is the documentation for making packages that the train is capable of managing. if you object to any of it you have to resign yourself to manual uploads.
[22:23] <robru> barry: sorry i should have checked the packaging sooner, wasn'tthinking
[22:24] <slangasek> AlbertA: camako: ok, can we get https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170 landed asap to wily?  this is blocking a base library transition
[22:24] <slangasek> I'll fix up my MP to declare the branch dep
[22:46] <barry> cjwatson: thanks!  robru how odd, given that 3.0-0ubuntu1 worked just a few days ago and none of this changed since then
[22:47] <robru> barry: i don't even? Did you do a manual source upload?
[22:47] <barry> robru: nope, choo choo all the way
[22:48] <robru> barry: i find it funny you say that "it worked just a few days ago" because the only time i ever hear about s-i is when it totally fails to be handled sensibly by the train. Long history of problems from my perspective.
[22:49] <barry> robru: yeah, what can i say?  i don't bug you when Everything Just Works ;)
[22:49] <robru> barry: what silo was it in before?
[22:49] <barry> robru: gosh, i don't remember.  some wily silo
[22:50] <robru> barry: you were talking about a new workflow with git, i blame that.
[22:50] <barry> robru: maybe that's it.  i think it was the only thing i changed after 3.0.  damn, that's a shame
[22:51] <robru> barry: well, try putting that .bzr-builddeb dir in there and see if that fixes it
[22:52] <barry> robru: with a shot i s'pose
[22:52] <robru> barry: LOL https://code.launchpad.net/~ubuntu-managed-branches/ubuntu-system-image/system-image most recent commit is a manual commit due to train breakage, so much for "Everything Just Works" ;-)
[22:53] <robru> barry: follow the wiki I linked though, try to get it as close as you can to train standards, there's really no reason for it not to work if the packaging is in line with expectations
[22:53] <barry> robru: maybe i should just take a taxi instead and do "normal" uploads until we want to copy the packages into some funky fone channel
[22:54] <robru> barry: well that's fine by *me*, but the train is there to automate things if you can manage to conform to it's expectations
[22:55]  * barry is obviously a nonconformist
[22:56] <barry> robru: well, i'll do a quick hack and see if that works, and if not i'll futz with it more tomorrow
[22:56] <robru> barry: ok, sorry it's been a hassle, once the spreadsheet is dead I can look at making the train support more use cases
[22:57] <barry> robru: kill it, kill it good
[23:17] <bfiller> robru: silo 8 ready for publish now
[23:19] <robru> bfiller: thanks, published