[06:13] <jibel> karni, Ok, rvr will do the verification
[08:20] <sil2100> alecu: hey!
[08:21] <sil2100> alecu: I forgot to ping you yesterday with the bug number of the unity-notifications regression
[08:21] <sil2100> alecu: https://bugs.launchpad.net/ubuntu-rtm/+source/unity-notifications/+bug/1470031
[08:54] <davmor2> bfiller I don't see an update to the testplan https://wiki.ubuntu.com/Process/Merges/TestPlan/address-book-app for the new code I assume it is just testing that I can search for unicode characters right or is it a Chinese specific fix silo18 I'll carry on with the rest of the plan while I wait.
[09:07] <abeato> trainguards, can I have a silo for line 66?
[09:21] <ogra_> bah, i got a duplicated update notification again ... second day in a row :/
[09:22] <ogra_> http://i.imgur.com/B1bX5SO.png
[09:30] <sil2100> abeato: on it
[09:30] <abeato> sil2100, ogra_ I want to land lxc-android-config syncing it from a ppa for vivid&wily, is that possible? what would be the right thing to put on the spreadsheet cell?
[09:31] <sil2100> abeato: synces and dual landings do not really go in pair sadly
[09:31] <abeato> sil2100, hmm, I feared that
[09:31] <abeato> sil2100, ok, I would change the landing to do it just for vivid
[09:31] <abeato> for the moment
[09:31] <sil2100> Well, I would prefer it first to happen for wily and then vivid
[09:32] <sil2100> Or two landings at once
[09:32] <abeato> sil2100, ok, changing to wily
[09:32] <sil2100> Like, two requests with the same sync line, but one for wily and one for vivid
[09:32] <sil2100> Since too many times we then had landings that we forgot to release to the devel release
[09:32] <abeato> sil2100, wily for the moment, I'll sync later
[09:33] <abeato> I need to do some testing
[09:33] <sil2100> ACK, assigning
[09:33] <abeato> sil2100, great, thanks
[09:46] <Laney> AlbertA: hi, what's the status of silo 013?
[10:30] <abeato> sil2100, any idea how can I fix that ? ^^
[10:31] <abeato> sil2100, should I keep version as 226? or is it because I used wily instead of UNRELEASED in the changelog?
[10:31] <sil2100> abeato: ah, uh, we'll have to do it manually - the sync that is
[10:32] <sil2100> abeato: syncing only works for CI Train packages, as we need to mangle the version number
[10:32] <sil2100> abeato: let me prepare that for you in a minute
[10:32] <abeato> sil2100, ok, I see, thanks
[10:33] <abeato> sil2100, how can I know which packages are from the CI train?
[10:33] <ogra_> hey, you guys removed my manually installed calendar with the last update !
[10:34] <ogra_> sil2100, popey, jibel ^^
[10:34] <popey> not me :)
[10:34]  * ogra_ checks the krillin 
[10:34] <popey> my calendar is still installed
[10:34] <popey> on both
[10:35] <ogra_> also gone on krillin
[10:35] <sil2100> abeato: by the package version usually :)
[10:36] <sil2100> abeato: CI Train packages follow a specific versioning, upstream+series.date-0ubuntu1
[10:37] <sil2100> ogra_: uh, that was not intended, but we removed it from the images, yes
[10:37] <abeato> sil2100, ah, interesting, good to know that :) ... is there around any good read on that stuff?
[10:37] <sil2100> abeato: https://wiki.ubuntu.com/citrain/LandingProcess#Syncing_from_and_to_the_Stable_Overlay_PPA
[10:37] <sil2100> And the SyncSilo related stuff too
[10:37] <ogra_> sil2100, right .. i wonder if i uninstalled the manually installed version at some point or if the switching to the rc-proposed channel automatically gave me the version from the custom tarball
[10:38] <abeato> sil2100, cool, thx
[10:39] <ogra_> hmm, i cant search for it in german in the click scope
[10:39] <ogra_> dont we have localized search keywoards ?
[10:39] <ogra_> *words
[10:46] <sil2100> abeato: hm, thinking how to deal with lxc-android-config
[10:47] <sil2100> abeato: I think I'll simply do a binary copy
[10:47] <sil2100> abeato: since otherwise I would have to change the version number, while I see it's the same for overlay and wily already
[10:47] <sil2100> So it seems it has been binary synced
[10:47] <abeato> sil2100, it's all configuration files so that should be fine
[10:47] <sil2100> And it's just a config, I suppose it's safe
[10:47] <abeato> yep
[10:51] <sil2100> abeato: hm, let me change your silo to a dual silo then
[10:51] <sil2100> abeato: since lxc-android-config is the only thing you wanted to sync, right?
[10:51] <sil2100> The rest were merges
[10:52] <abeato> sil2100, correct
[10:52] <sil2100> So I'll simply copy lxc-android-config for both vivid and wily and the rest you'll build as a dual landing
[10:52] <abeato> sil2100, nice, that will make things easier :)
[10:57] <sil2100> Grrr, Robert added some stupid checks
[10:59] <sil2100> abeato: ok, it seems due to dual-landing implementation issues I can't do it this way ;/
[11:00] <sil2100> eh
[11:00] <abeato> sil2100, oh...
[11:00] <sil2100> abeato: let's do it traditionally... wily then vivid
[11:00] <abeato> sil2100, ack
[11:03] <sil2100> abeato: ok, copied the lxc-android-config package
[11:04] <sil2100> abeato: I'll also assign a silo for the sync from wily once you release silo 006
[11:04] <abeato> sil2100, great
[11:04] <sil2100> abeato: once 006 lands in the archive, you'll have to press build on it
[11:12]  * sil2100 stares on ogra_, pressuring him on you-know-what
[11:23] <Laney> Is there a standard version suffix for the overlay?
[11:24] <rvr> karni: ping
[11:25] <rvr> karni: "Could not retrieve your telegram data" Did you update the scope? com.canonical.scopes.dashboard_1.8.1_armhf.click
[11:25] <rvr> karni: That message is not shown in Spanish
[11:32] <sil2100> Off to prepare lunch
[11:33] <sil2100> Laney: hey, no... we're using vivid versioning
[11:33] <sil2100> Laney: as the idea is to SRU each of those packages to the main archive (as a binary copy)
[11:34] <Laney> sil2100: and just fix it if there is a collision?
[11:34] <Laney> sil2100: Not sure that mir 0.14 is going to ever be SRUed, is it?
[11:48] <davmor2> rvr: is the scope not cwaynes team? or does it get the text from telegram itself?  karni  do you happen to know
[11:49] <rvr> davmor2: Not sure. It appears in Today's scope, but the text comes from the Telegram scope.
[12:06] <abeato> sil2100, silo 6 shows status "Silo ready to build" although all packages are there, should I take any action?
[12:06] <sil2100> abeato: I think a watch_only build would do the job
[12:07] <abeato> sil2100, ok
[12:29] <abeato> sil2100, yet another issue with silo 6... we have a new dependency for ofono on package libc-ares2 , I guess I need to add that to "additional source packages"?
[12:36] <jibel> bzoltan_, Hey, when do you plan to land silo 3?
[12:42] <sil2100> abeato: is libc-ares2 missing in wily?
[12:42] <abeato> sil2100, yes
[12:43] <abeato> sil2100, it's in the archive
[12:44] <sil2100> You need a new version in silo 006 or something?
[12:45] <abeato> sil2100, no, should it be installed automatically? citrain did not install ofono, just nuntium
[12:46] <sil2100> abeato: by citrain you mean the citrain console tool?
[12:46] <abeato> sil2100, yes
[12:47] <sil2100> abeato: hm, don't know much about that tool, I don't use it or maintain it, but I suppose it should install everything from the silo PPA
[12:47] <sil2100> If it's a dependency of ofono it should auto-install it along with it
[12:47] <sil2100> (if it's available in the archive)
[12:47] <abeato> sil2100, right
[12:48] <abeato> sil2100, ok, I guess is some bug in citrain, nm
[12:49] <sil2100> I hope that's the case ;)
[12:50] <abeato> sil2100, :)
[13:11] <mzanetti> trainguards, please reconfig 17. I had to restructure it
[13:25] <jgdx> jibel, Victor not on irc?
[13:26] <brendand> jgdx, he's rvr here
[13:26] <rvr> jgdx: Me or victorp? :)
[13:27] <jgdx> rvr, vrruiz :)
[13:27] <jgdx> rvr, so that wpa2-ep silo, are you close to such a network?
[13:27] <rvr> jgdx: I just moved silo 40 card to ready for testing, but I don't have a WPA2 Enterprise network
[13:28] <jgdx> brendand, thanks!
[13:28] <rvr> jgdx: I've asked who has in the team, to test it
[13:29] <jgdx> rvr, thanks. I just tested the silo today with and without a certificate to connect to eduroam. Joerg has tested eduroam as well, and Pete Woods has tested his own wpa-ep network. All good.
[13:29] <rvr> jgdx: Ack
[13:30] <jgdx> rvr, I've raised concerns about getting this testes to my manager, maybe your team could do this as well? :) It's a serious problem.
[13:30] <jgdx> s/testes/tested
[13:30] <rvr> jgdx: Surely we want it tested, davmor2 may be doing it
[13:31] <kenvandine> jgdx, one of many things that's tricky to get tested
[13:31] <kenvandine> similar to all the things that may be carrier specific
[13:32] <jgdx> kenvandine, yup.
[13:33] <kenvandine> jgdx, my head is still spinning over your call forwarding branch passing CI... without the fix for the search tests
[13:33] <kenvandine> it's actually got me a little freaked out... how could that have possibly only returned 1 result, unless there is a bug in the code that provides the dynamic keywords
[13:34] <kenvandine> and sometimes it takes to long or something
[13:35] <sil2100> mzanetti: on it
[13:37] <mzanetti> sil2100, thanks
[13:41] <jgdx> kenvandine, I willed it.. :s
[13:41] <kenvandine> :)
[13:44] <jgdx> kenvandine, I don't really know, but let me know if you need an extra pair of test devices
[13:48] <kenvandine> jgdx, nah... i tried it a few times without my fix on mako and it did fail each time
[13:56] <mzanetti> sil2100, can you drop unity-api from the ppa for silo 17 please
[13:57] <sil2100> mzanetti: from the PPA? On it
[13:59] <mzanetti> ta
[13:59] <sil2100> Should be done
[13:59] <mzanetti> perfect
[13:59] <boiko> trainguards: could someone please remove telepathy-qt5 from silo 39's ppa and get the silo reconfigured?
[14:00] <boiko> the source landing of telepathy-qt5 was already done somewhere else and now only the other packages are needed
[14:00] <sil2100> boiko: on it!
[14:00] <boiko> sil2100: thanks!
[14:06] <sil2100> boiko: reconfigured, package deleted
[14:07] <boiko> sil2100: great! thanks!
[14:07] <jgdx> davmor2, for silo 40, please note that the way to connect to a wpa2 enteprise network is by going to System Settings -> Wifi -> Connect to hidden network.
[14:08] <jgdx> rvr, ^
[14:09] <pmcgowan> jgdx, is that required or just a temporary thing
[14:11] <jgdx> pmcgowan, that's temporary
[14:11] <pmcgowan> ok
[14:12] <pmcgowan> jgdx, whats left to do then?
[14:15] <jgdx> pmcgowan, when the user clicks a new WPA-EP network in the indicator, the indicator will spawn a dialog coming from System Settings.
[14:15] <sil2100> alecu, davmor2: hey guys, did Pete pick up the laptop already?
[14:15] <pmcgowan> jgdx, so we need code to display that network type and settings shares that code?
[14:16] <sil2100> alecu: did you have a moment to check that unity-notification regression we had to revert?
[14:17] <jgdx> pmcgowan, we need code in the indicator redirecting to settings and code for settings that handles the redirect. No sharing at this time..
[14:17] <jgdx> s/code for settings/code in settings
[14:17] <pmcgowan> jgdx, my question really is why doesnt a wpa network show up in the list in settings today
[14:17] <alecu> sil2100: I've not seen pete yet, I guess he might be setting it up now
[14:17] <pmcgowan> in silo 40
[14:17] <jgdx> pmcgowan, it does?
[14:17] <alecu> sil2100: I'll take a look now
[14:17] <jgdx> pmcgowan, I'm pretty sure
[14:17] <jgdx> pmcgowan, but you can't configure it
[14:18] <pmcgowan> jgdx, sorry, I am butting in based on your comment above that hidden network must be used, not understanding why
[14:21] <jgdx> pmcgowan, oh right. System Settings is the only program that can configure WPAEnterprise networks right now, and that's the way to do it. System settings has no other Wifi dialog, except the "Connect to hidden network" one
[14:22] <jgdx> pmcgowan, a silo coming shortly (as soon as indicator network stuffs is done, should be trivial) that will allow the user to configure WPAEnterprise networks tapping networks in the indicator, or System Settings network list.
[14:22] <pmcgowan> jgdx, ok, and what needs configuring
[14:22] <pmcgowan> I never used that tye of AP
[14:22] <jgdx> tons of things :)
[14:22] <sil2100> alecu: thanks!
[14:22] <jgdx> pmcgowan, outer auth, inner auth, certs, auth versions, private keys, user name, passwords...
[14:22] <kenvandine> pmcgowan, of which the settings provides a UI for, so the indicator will take you right to the interface
[14:23] <jgdx> list goes on
[14:23] <dbarth> sil2100: hiya; quick question, is there still an overlay ppa for vivid?
[14:23] <kenvandine> so the settings landing is still useful, you just have to access it through connect to hidden
[14:23] <kenvandine> until the indicator end lands
[14:24] <sil2100> dbarth: hey! Yes, it's possible we'll stay with the overlay even
[14:24] <sil2100> dbarth: anyway, for OTA-5 we stick to the overlay
[14:24] <sil2100> And the discussion and analysis continues ;)
[14:24] <dbarth> sil2100: i'm wondering if we could have oxide 1.8 a bit before it's in the security pocket for regular vivid
[14:24] <dbarth> having it in the overlay ppa
[14:24] <sil2100> hm
[14:25] <sil2100> dbarth: when is the planned security release? Do you know/
[14:25] <dbarth> to test something before rolling that out to actual vivid users, when it becomes an official stable update
[14:25] <dbarth> around 2nd week of july
[14:25] <dbarth> so a bit short for ota-5
[14:25] <sil2100> Does it fix any of the targeted OTA-5 bugs?
[14:25] <dbarth> wily should be fine already, but since we're trying to stay in sync
[14:26] <dbarth> good question; i don't think there are any criticals there mostly extra features
[14:26] <dbarth> find in page, in the browser, for example
[14:26] <jibel> sil2100, dbarth it's needed for the find in page feature
[14:26] <dbarth> right
[14:27] <sil2100> hm, ok
[14:27] <sil2100> dbarth: anyway, would be nice to have it in a silo first
[14:27] <dbarth> ah well, bugs - features; sorry, there are some on the ota-5 list actually
[14:27] <dbarth> not just issues
[14:27] <sil2100> Then QA can sign it off (and make sure that the security upload won't break anything) - and also consider landing it for OTA-5
[14:27] <dbarth> ok, with that path mapped out, we can start doing some uploads and test
[14:28] <dbarth> sounds good
[14:28] <sil2100> Excellent then :)
[14:47] <AlbertA> Laney: I have to rebuild qtubuntu camera....yesterday the silo was approved by QA but I have to rebuild now....I hate it when that happens
[14:47] <AlbertA> Laney: in regards to landing-013 I mean
[14:49] <Laney> AlbertA: I don't see gst in there though?
[14:49] <Laney> and does that mean it has to be re-QAed
[14:53] <AlbertA> Laney: gst is out of tree isn't it?
[14:53] <Laney> AlbertA: It's not train managed but you can land it in sync via the silo
[14:54] <AlbertA> And the branch that is there is out of sync with the source package
[14:54] <AlbertA> so I'm not sure what I'm supposed to do there
[14:56] <davmor2> jgdx: I'll come back to you in a minute once I setup this router
[15:01] <jgdx> davmor2, I'm eod, but will check in in about 6 hours.
[15:02] <davmor2> jgdx: no worries I think I have everything I need anyway
[15:03] <jgdx> davmor2, wonderschön. Just wanna stress that tapping a WPA Enterprise network in either the indicator list or System Settings list will not work right now. _just_ the "Connect to hidden network…" :))
[15:06] <davmor2> jgdx: Yeap I got that one earlier fingers crossed I hit no issues :)
[15:24] <anpok_> trainguards: ping
[15:24] <sil2100> anpok_: pong
[15:25] <anpok_> in silo-004 .. the vivid version of gtk+3.0 still fails to buil
[15:25] <anpok_> d
[15:25] <anpok_> not sure whats wrong
[15:26] <Laney> anpok_: looks built to me... what are you seeing?
[15:26] <anpok_> https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/240/console
[15:27] <anpok_> ah
[15:27] <anpok_> Laney: I thought you only uploaded a source package - and it still needs building
[15:27] <Laney> did you reconfigure the silo after you removed the MP from it?
[15:27] <anpok_> yes
[15:27] <Laney> it shouldn't try to build it
[15:28] <anpok_> so for those packages I cannot rebuild them within the silo?
[15:28] <Laney> sil2100: can you help please?
[15:28] <sil2100> On it
[15:28] <Laney> thanks!
[15:29] <Laney> AlbertA: should I upload a gst-bad package to the silo?
[15:29] <Laney> the MP was probably made before I hacked around it in the archive
[15:29] <Laney> (can you link me to it?)
[15:31] <sil2100> btw. I don't see glmark in the silo, was it already uploaded?
[15:31] <anpok_> sil2100: not yet..
[15:31] <sil2100> Ok
[15:32] <anpok_> it only needs rebuilding
[15:32] <anpok_> (glmark2 - no source changes are needed for 0.14.0)
[15:32] <AlbertA> Laney: I'll prepare one... so I just base it on top of this branch? https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/gst-plugins-bad1.0/wily
[15:35] <Laney> AlbertA: No need to use bzr, I think that you should be able to download gst-plugins-bad1.0 and revert my changes from ubuntu6 (except the changelog), then get it uploaded to the silo.
[15:35] <sil2100> anpok_, Laney: we should be good once this watch_only build finishes, had to change some parameters
[15:35] <Laney> nice, thanks
[15:36] <anpok_> great
[15:40] <sil2100> Ouch
[15:40] <sil2100> Ok, on it again
[15:42] <sil2100> anpok_: you know that qtmir and platform-api fail to build on the PPA currently?
[15:42] <anpok_> sil2100: I wam waiting for silo-13 with platform-api
[15:43] <anpok_> hm qtmir should build
[15:43] <sil2100> anpok_: ok, anyway, the silo is good, it just will fail since there are failed packages in it
[15:44] <sil2100> And qtmir-gles didn't get built (which makes sense as qtmir didn't build)
[15:44] <anpok_> ok .. will after qtmir
[16:00] <Laney> AlbertA: Ah, just tried that - it needs code changes too. Over to you, then. A debdiff will be fine at the end. :)
[16:00] <Laney> AlbertA: If you want to file a bug and subscribe me I'll put it in the silo when you come up with it.
[16:01] <Laney> (or if that's the branch you were referring to then give it to me once it's rebased on wily)
[16:02] <AlbertA> Laney: ok will do
[16:02] <Laney> thanks!
[16:09] <sil2100> ^ silo 002 needs QA sign-off still
[16:09] <dbarth> yes, for the vivid leg
[16:19] <mzanetti> traiguards, can I please get a silo for request 5 (in the new tool)
[16:21] <mzanetti> meh... typo. trainguards ^
[16:21] <sil2100> mzanetti: wow
[16:21] <mzanetti> ?
[16:22] <sil2100> mzanetti: ok, so try maybe assigning it by your own :)
[16:22] <mzanetti> ah ok.
[16:22] <mzanetti> wasn't sure if I should...
[16:22] <sil2100> mzanetti: one of the recent changes was that if there's a lot of free silos, you can assign yourself
[16:22] <mzanetti> just figured I should read the whole mail
[16:22] <mzanetti> ah
[16:23] <mzanetti> sil2100, sorry for the noise :/
[16:23] <sil2100> No worries ;)
[16:23] <sil2100> By the 'wow' I meant 'wow, someone is testing the new thing!'
[16:23] <mzanetti> ah :) totally
[16:32] <Laney> AlbertA: ^^^ published, so I'll just upload to wily-proposed direct once ready
[16:33] <AlbertA> Laney: awesome thanks...
[16:50] <ogra_> did we have a new oxide in one of the recent images ?
[16:51] <ogra_> G+ is so slow for me on arale that it sites there with a half drawn screen for 1-2 seconds when scrolling
[16:51] <ogra_> (other webapps too)
[16:57] <sil2100> hm, no, we shouldn't have
[16:57] <sil2100> We'll have one soon though
[16:58] <ogra_> hmm, then it si perhaps something else
[16:58] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/vivid/20150701.changes
[16:58] <ogra_> hmm, looks like oxide though
[17:00] <sil2100> huh?
[17:00] <sil2100> Had to go through security then
[17:00] <sil2100> Yeah, security indeed
[17:00] <ogra_> yeah, i remember brendand asking for it
[17:01] <ogra_> now that i talk about it :P
[17:01] <ogra_> well, it seems a lot slower on arale to me
[17:45] <bzoltan_> jibel:  kalikiana needs to fix the API checker for the i386 gles package and then after it should be OK. This week, I would say.
[18:01] <AlbertA> Laney: I attached the debdiff to https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1465958
[18:09] <mzanetti> oSoMoN, seems our silos are cuddling :)
[18:09] <mzanetti> https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-003
[18:09] <mzanetti> get out of here! :D
[18:14] <mzanetti> trainguards, please assigne me a silo for row 67
[18:15] <robru> mzanetti: hey, I changed things up so you can assign yourself. try it out ;-)
[18:15] <mzanetti> for that too
[18:15] <mzanetti> I thought only for staging. will try :)
[18:15] <mzanetti> robru, btw, I tried that silo in the staging... seems it didn't build
[18:15] <mzanetti> robru, other then that, seems fine (after you fix the copy/paste things in the form)
[18:16] <robru> mzanetti: staging as the spreadsheet replacement but production already has the "users can assign their own silos" now
[18:16] <mzanetti> also, it doesn't fit on my screen :)
[18:16] <mzanetti> would be nice if that webform would elide labels
[18:16] <robru> mzanetti: what doesn't fit? can you send me a screenshot?
[18:16] <robru> mzanetti: it fits on my screen but then i have ultra-wide hd screen
[18:17] <robru> mzanetti: the only time I've seen it not fit on my screen is when the list of manual sources is huge, makes the page super wide.
[18:17] <mzanetti> robru, http://i.imgur.com/7L6kRVR.png
[18:18] <robru> mzanetti: oh, that status message is really long, I see
[18:19] <robru> mzanetti: yeah for some reason the second row of info I set to forcibly never wrap text. I can't remember why I thought that was a good idea. If I take that out it should fit way better on screen.
[18:20] <mzanetti> robru, not sure if the staging silos are meant to produce proper results... but seems it doesn't build unity. haven't investigated though after I found out it wouldn't give me arm packages anyways
[18:20] <mzanetti> just as feedback for testing that thing
[18:20] <AlbertA> cihelp: looks like landing-013 is stuck in migration. I just see testbed failures on some platform-api rdeps (powerd, qtubuntu-sensors, qtubuntu-gles, location-service2)
[18:21] <AlbertA> cihelp: any ideas?
[18:21] <mzanetti> robru, also, distribution, series etc could perhaps be drop down lists :) I was unsure what to put there tbh
[18:22] <josepht> AlbertA: is that a ci-train silo?
[18:22] <robru> mzanetti: yeah I wouldn't worry about the build to much, the staging ppas are indeed limited compared to production
[18:22] <mzanetti> I figured, but would be nice to minimize room for mistakes
[18:22] <robru> mzanetti: there is a drop-down if you click a second time.
[18:22] <mzanetti> indeed :D
[18:22] <mzanetti> anyhow. the self assigning silos works fine
[18:22] <mzanetti> thanks for that
[18:22] <mzanetti> will be afk for a bit now
[18:22] <robru> mzanetti: thanks for the feedback, I'll be incorporating this & others this week.
[18:23] <mzanetti> yw
[18:23] <AlbertA> josepht: yeah silo 013, published, stuck in migration
[18:23] <josepht> robru: is AlbertA's query above a trainguard thing?
[18:24] <AlbertA> josepht: boottest failures
[18:24] <robru> josepht: nope, it's boottest: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#location-service
[18:24] <josepht> AlbertA: ah, boottest is us
[18:24] <AlbertA> josepht: I'm not exactly sure what is failing (for example: https://jenkins.qa.ubuntu.com/job/wily-boottest-powerd/lastBuild/)
[18:25] <renatu> hey guys I got this error on jenkins: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2794/console
[18:25] <renatu> Ursinha, ^^
[18:26] <josepht> AlbertA: I've re-kicked the boottest job
[18:29] <fginther> renatu, Ursinha, looking
[18:29] <renatu> fginther, thanks
[18:31] <dobey> trainguards: ^^ please :)
[18:31] <robru> dobey: try assigning yourself ;-)
[18:31] <dobey> robru: i can do that?
[18:32] <robru> dobey: yeah I made some changes recently, still a little experimental
[18:32] <fginther> josepht, there are a few other boottests for packages in that silo that might need a re-run. Also qtubuntu-gles needs to be manually passed as it's uninstallable on the phone (it produces no armhf binaries, see https://wiki.canonical.com/UbuntuEngineering/CI/Playbook#Boottest:_Generating_a_passing_.result_file)
[18:32] <dobey> robru: what do i need to type into DEST?
[18:32] <robru> dobey: it's ci-train-ppa-service/ubuntu/stable-phone-overlay for the overlay ppa
[18:33] <dobey> ok
[18:34] <dobey> neat it worked
[18:34] <josepht> fginther: is that done on the jenkins slave?
[18:34] <fginther> renatu, the mako that test executed on was in a bad state. I've off-lined the device to recover it and will restart your test request
[18:34] <dobey> thanks robru
[18:35] <fginther> josepht, generating the passing .result file is done from d-jenkins
[18:37] <renatu> fginther, thanks
[18:37] <robru> dobey: you're welcome!
[18:50] <jgdx> davmor2, how's it going?
[18:50] <josepht> AlbertA: the boottest passed on the second run
[18:56] <AlbertA> josepht: ack, though the excuses pages still shows powerd, qtubuntu-sensors, qtubuntu-gles, location-service2 as having failed the boottest
[18:56] <josepht> AlbertA: yeah, we're working through the rest now
[18:56] <AlbertA> josepht: ack thanks!
[19:01] <davmor2> jgdx: meh so I tested a basic setup and that was okay be now I really need to test against a key authenticated system and setting that up has been less than enjoyable but I think I'm getting there now
[19:01] <jgdx> davmor2, key as in private key or cert?
[19:02] <davmor2> jgdx: setting up freeradius for the authentication server and key system so it is like it would be at the unis etc
[19:03] <jgdx> davmor2, righto, thanks.
[21:12] <dobey> trainguards: uhm, why is the changelog message here so messed up? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021/+sourcepub/5179892/+listing-archive-extra
[21:13] <robru> dobey: uh
[21:13] <dobey> trainguards: do i need to manually tweak debian/changelog to work around some bug?
[21:14] <robru> dobey: yes if you write your own debian/changelog the train will honor it
[21:14] <dobey> robru: right, i'm just wondering if i *need* to do that here, or what
[21:15] <dobey> i guess "yes, and file a bug somewhere" ?
[21:15] <robru> dobey: yeah I'm not going to be able to fix that soon, that's a giant mess. wow
[21:15] <robru> dobey: two things going on there
[21:16] <robru> dobey: the diff goes all the way back to the beginning because it's the first release targetting stable overlay ppa, that's a known bug
[21:16] <robru> dobey: as for the changelog entry being a giant paragraph of gibberish in a single bullet point, holy crap, I have no idea
[21:16] <dobey> sure i'm not worried about the huge diff
[21:16] <dobey> i'm worried about the bzr info in the one entry
[21:17] <robru> dobey: yeah unfortunately the changelog generation code is some of the least-tested code in the train (part of the last 1% that doesn't have test coverage)
[21:17] <dobey> robru: ok, i'll twaek the changelog manually and rebuild and hopefully that will work around whatever bug this is hitting
[21:18] <robru> dobey: yeah should do. just put the series as UNRELEASED and then the train can still mangle your version numbers (otherwise you're likely to hit the opposite bug where it adds a new changelog entry which is an empty bullet point)
[21:18] <dobey> ok
[21:26] <dobey> robru: btw, does publishing happen automatically when a silo is ready to land, or do i need to run a jenkins job for that?
[21:27] <robru> dobey: no you need me to publish, and it has to go through qa before hitting overlay ppa
[21:27] <dobey> ok
[21:27] <dobey> yeah i know it needs qa. i meant after that stage obviously :)
[21:32] <dobey> robru: ok, the huge diff is annoying, but it looks like tweaking the changelog manually got around the weirdness thankfully.
[21:39] <robru> dobey: yeah that's to do with the overlay ppa. next time you do a release there that'll fix itself.
[21:56] <boiko> robru: couldn't find time today to check the spreadsheet replacement, sorry, I might have some time tomorrow  to check it out
[21:57] <robru> boiko: no worries, I've got lots of feedback already, will be glad to hear yours when you're ready
[21:58] <boiko> robru: in any case, I am glad we are closer to get rid of the spreadsheet already :D
[21:58] <robru> boiko: sooooooo cloooooooose
[21:58] <robru> ;-)
[21:58] <boiko> hehe
[22:07] <boiko> robru: I need your help with vivid silo 44: I did a dual landing of telephony-service already, so the changelog in bzr already has 15.10 stuff
[22:08] <robru> boiko: yeah you can't take something that was landed to wily (either just wily or as a dual) and then land it to vivid.
[22:08] <robru> boiko: you need to either do another dual landing, or do a sync from wily to vivid, or branch trunk for vivid and start a new landing from there
[22:08] <boiko> robru: point is: telephony-service building is currently broken on wily due to a new telepathy-qt5 that has landed there
[22:10] <boiko> robru: but we need to land those critical bugfixes ASAP, even before landing silol 39 (which fixes telephony-service building on wily)
[22:11] <boiko> robru: maybe do a source-only land on vivid and then when telephony-service fixed on wily land the fix on wily too and sync everything back to vivid?
[22:12] <robru> boiko: I don't really understand what the problem is. if your last landing was a dual why not just do another dual? that's the easiest way to get your fix in both places.
[22:12] <boiko> robru: because telephony-service building is broken on wily until silo 39 lands
[22:12] <boiko> robru: but that requires quite some testing time (which we can't afford right now as we need to land the critical fixes for OTA5)
[22:13] <robru> boiko: well if you're really in a hurry, the fastest thing you can do is just do another dual, let the wily build fail, but then you'll have a silo with vivid packages that can be released.
[22:13] <boiko> robru: if we had enough time, I would land silo 39, sync everything back to vivid (including the latest telepathy-qt5), and only then land the critical bugfixes
[22:13] <boiko> robru: oh, can it be done this way?
[22:14] <boiko> robru: question: would the changes be merged back to trunk once the vivid packages get published?
[22:14] <robru> boiko: well yeah we'd have to fudge the silo a bit and delete the wily packages, but it's the only way to trick the train into building vivid packages. it won't let you build vivid packages from a wily trunk, on purpose.
[22:14] <robru> boiko: then once 39 lands properly you can do another dual again to make sure the trunk fixes get to wily.
[22:15] <boiko> robru: well, if changes get merged to trunk, silo 29 will already make sure everything from trunk is on wily
[22:15] <robru> boiko: yep, sounds good
[22:15] <boiko> robru: ok, so could you please change silo 44 to be a dual landing one?
[22:16] <robru> boiko: ok
[22:16] <boiko> robru: thanks :)
[22:17] <robru> boiko: you're welcome, should be ready
[22:22] <jgdx> davmor2, hi, saw you were blocked on config
[22:23] <jgdx> robru, hey, you on duty? :)
[22:23] <jgdx> it's train related
[22:23] <robru> jgdx: yeah officially it's a holiday but I'm around for train stuff
[22:25] <jgdx> robru, okay, so a quick question. davmor2 is testing silo 40, but deferred it to tomorrow to get something set up in the mean time. Silo 40 is a branch from a community member, and he just pushed a couple of trivial fixes.
[22:26] <jgdx> question: is it okay to do another approve and rebuild the silo for dave tomorrow, or should I ask him to uncommit?
[22:26] <robru> jgdx: yeah absolutely you can rebuild...
[22:26] <jgdx> robru, great stuff, thank you.
[22:26] <robru> jgdx: it's entirely up to you, if you want those new commits or not. if they're good fixes then rebuild.
[22:26] <robru> jgdx: you're welcome
[22:33] <jgdx> davmor2, ^ sorry for the noise, but if you upgrade silo 40 on your device tomorrow morning, that'll fix a translation issue in the dialog. :)
[23:24] <greyback> trainguards: could someone please hit reconfigure on vivid+overlay silo0, I needed to change the qtmir branch there
[23:26] <robru> greyback: should work if you do it.
[23:27] <greyback> trying...
[23:29] <robru> greyback: let me know how it goes. I made some changes to the train recently
[23:30] <greyback> robru: worked a treat, nice :)
[23:31] <robru> greyback: you're welcome!
[23:32] <robru> Hmmm
[23:32] <greyback> robru: that error my bad. All is good :)
[23:32] <greyback> or is it
[23:32] <greyback> New version specified (0.4.5+15.04.20150701-0ubuntu1) is less than
[23:32] <greyback> the current version number (0.4.5+15.10.20150617-0ubuntu1)!  Use -b to force.
[23:33] <greyback> think the comparison is the wrong way around
[23:33] <robru> greyback: nope, that error happens when you try to release a wily trunk to vivid.
[23:34] <greyback> robru: aha
[23:34] <greyback> thanks
[23:34] <robru> greyback: you need to either do a dual, or sync from wily to vivid
[23:34] <robru> greyback: you're welcome.
[23:34] <robru> greyback: or branch for vivid
[23:35] <greyback> robru: will keep it vivid only for now. That silo more a demo silo atm