=== chihchun_afk is now known as chihchun
=== _morphis is now known as morphis
[08:42] <mandel> sil2100 Good morning!! sooo.. I'm a major pain in the ass, but silo 17, seems to be having issues, it is supposed to be a sync, any idea
[08:48] <anpok> hi trainguards - sili011 needs a manual sync of glmark2 and xorg-server
[08:48] <anpok> it seems I cannot rebuild those with through the silo ci jenkins!?
[09:01] <sil2100> anpok: hey! I can do those :) It was EOD already when mir finished on Friday for me
[09:02] <sil2100> anpok: those are not CI Train released projects so they need a manual intervention
[09:02] <anpok> sil2100: ha - it never ends
[09:02] <sil2100> mandel: hey!
[09:02] <sil2100> mandel: give me 5 minutes and I'll look into that :)
[09:03] <mandel> sil2100, super, thx
[09:03] <sil2100> anpok: yeah, big releaes are always filled with sweat, tears and blood
[09:10] <jamesh> cihelp: did anything weird happen with the ARM builders over the weekend?  I'm seeing weird ARM-only failures for my branch: https://code.launchpad.net/~jamesh/thumbnailer/devel-sync-20150725/+merge/265888
[09:11] <psivaa> jamesh: let me take a look
[09:12] <jamesh> It took an unusually long period of time for the autolanding job to pick up the branch too.
[09:12] <jamesh> psivaa: thanks.
[09:19] <sil2100> anpok: uploading the packages
[09:20] <sil2100> anpok: can I just upload both at the same time, or xorg-server is needed to be built first?
[09:22] <psivaa> jamesh: i see test failures in the likes of 'Error creating thumbnail: ThumbnailExtractor: change_state(): reading async messages: Could not decode stream.'
[09:22] <sil2100> mandel: ok, see the problem
[09:22] <marcustomlinson> sil2100: could you please reconsider silo 30, it no longer removes symbols
[09:23] <sil2100> marcustomlinson: oh! Of course, could you again re-trigger it as testing pass? :)
[09:23] <marcustomlinson> sil2100: ok :)
[09:23] <sil2100> mandel: so, the silo was a PPA sync silo, and now the PPA is empty
[09:23] <mandel> sil2100, oh, can we change it to sync from wily?
[09:23] <mandel> sil2100, everything is there
[09:23] <sil2100> mandel: someone that prepared this request didn't use the 'sync from silo' notation - that one would auto-switch to the main archive if the silo is freed
[09:23] <sil2100> mandel: yep
[09:23] <anpok> sil2100: no dependencies between those two
[09:24] <sil2100> I'll do that quick
[09:24] <psivaa> jamesh: that 'Could not decode stream.' error appears to be the cause for most of the failures
[09:24] <mandel> sil2100, AWESOME, thx
[09:25] <jamesh> psivaa: yep.  It is constructing a GStreamer pipeline to read a vorbis or theora file.  There are no code changes in that branch that'd cause this.
[09:26] <sil2100> marcustomlinson: perfect for archive release, publishing!
[09:26] <marcustomlinson> sil2100: thanks!
[09:26] <sil2100> mandel: reconfigured, you can try re-building content-hub
[09:27] <sil2100> mandel: I hope it'll work as I saw the sync code malfunctioning after recent changes ;/
[09:27] <mandel> sil2100, ok, I'll let you know
[09:28] <popey> sil2100: jibel added music app to bottom of citrain spreadsheet, could someone test pls?
[09:29] <sil2100> popey: thanks! Approved request
[09:30] <popey> ta
[09:33] <psivaa> jamesh: there was a new libgstreamer1.0-0:armhf (v 1.5.2-1) released last night,
[09:34] <psivaa> https://launchpad.net/ubuntu/+source/gstreamer1.0/1.5.2-1
[09:35] <jamesh> psivaa: thanks.  I'll see if there's any clues there.
[09:36] <psivaa> jamesh: ack, thanks. I dont think if we have any control over those failures
[09:37]  * jamesh hates platform dependent failures like this.
[09:38] <rvr> popey: Is there a changelog for music-app?
[09:46] <mandel> sil2100, so far so good :)
[10:03] <popey> rvr: yes, its in the linked readme
[10:03] <popey> rvr: http://pad.ubuntu.com/MusicAppReadMe
[10:05] <rvr> popey: I see, thanks
[10:05] <popey> np 🙂
=== psivaa_ is now known as psivaa
=== cprov_ is now known as cprov
=== alecu_ is now known as alecu
=== alan_g is now known as alan_g|lunch
[11:36]  * sil2100 off to lunch
[13:14] <davidbarth> o/ trainguards, you can also unload silo 040, as oxide 1.8 is released as a stable update using the regular channels this week
[13:14] <sil2100> o/
[13:14] <sil2100> davidbarth: ok!
=== tedg is now known as ted
=== _salem is now known as salem_
[14:08] <sil2100> Ok guys, I'm building an OTA-5+ hotfix re-spin for mako - the rc-proposed channel should stay intact
[14:16] <mzanetti> jibel, hey, I just realized that my silo 35 has an already merged branch
[14:16] <mzanetti> jibel, looking at the build-log that doesn't seem to be a problem, the merge ends up being a no-op
[14:17] <mzanetti> so I'd suggest to leave it as it is. does that work for you?
[14:17] <jibel> mzanetti, which branch is it?
[14:17] <mzanetti> https://code.launchpad.net/~mzanetti/unity8/unity8-clickable-bottom-edge-hint/+merge/265019
=== alan_g|lunch is now known as alan_g
[14:18] <jibel> mzanetti, works for me
[14:18] <mzanetti> jibel, thanks
[14:33] <bregma> trainsguards, is there some kind of black preventing me from getting silos for lines 76, 77, and 78?
[14:42] <rvr> boiko: Silo 39 approved
[14:43] <boiko> rvr: thanks, I will just ask robru to hold the publishing a bit, salem_ thinks one of the changes in there is causing a regression, we are just validating if it is the case
[14:44] <boiko> tranguards: can you please just hold the publication of silo 39 while salem_ and I confirm if one of the changes in there is causing a regression?
[14:45] <boiko> rvr: according to salem_'s tests, if you boot the device without any network connectivity (no wifi and no mobile data), the telepathy accounts are kept offline
[14:45] <boiko> rvr: he will confirm if the silo has anything to do with that
=== chihchun is now known as chihchun_afk
[14:52] <rvr> boiko: Ack
[14:54] <rvr> boiko: What do you mean by telepathy accounts?
[15:35] <sil2100> wgrant: hey! Did you get my e-mail about translations by any chance? :)
[15:47] <slangasek> charles: hi, can we expect silo 55 to land soon?  (g++4.9 build-deps)  this seems to be a prereq for flipping the switch on Friday
[15:47] <slangasek> charles: looks like the silo is dirty and needs a rebuild at the moment
[15:49] <slangasek> sil2100, robru: hmmm I can't find a spreadsheet line for landing-055, does that imply spreadsheet problems again?
[15:53] <robru> slangasek: could be, or could be somebody deleted the row
[15:57]  * sil2100 checks for errors
[15:58] <sil2100> hm, no new errors
[15:58] <sil2100> slangasek: I would suppose someone erased the row by accident
[15:58] <sil2100> Or removed the UID field
[15:59] <slangasek> "could be someone deleted the row" - how's that bileto transition looking, robru? ;)
[15:59] <sil2100> slangasek: looks like it got removed somehow indeed
[15:59] <slangasek> sil2100: how can we restore it?  I should be able to tell you the list of mps
[15:59] <sil2100> No logging or version control on the spreadsheet tho ;p
[15:59] <robru> slangasek: ugh, still some problems with https, needs a few more iterations
[16:00] <slangasek> robru: ok
[16:00] <sil2100> slangasek: let me check the backups
[16:00] <sil2100> hmmm
[16:00] <sil2100> Actually, we have no backups, my backups didn't get switched to the new spreadsheet
[16:00] <sil2100> I think ;/
[16:13] <slangasek> sil2100: I know the lander, I know the mps and I know the silo name (in fact, this information is all still available in the dashboard, even though not in the spreadsheet).  can I manually recreate the spreadsheet line with this?
[16:14] <boiko> rvr: sorry, I went for lunch, so, we expose the ofono modems via accounts on the telepathy framework
[16:14] <rvr> boiko: I see
[16:18] <boiko> rvr: salem_ just checked and the problem is there even without the silo (bug reported already), so the silo is good to go
[16:18] <boiko> trainguards: all the verifications were done, silo 39 is good to go
[16:18] <robru> slangasek: yes
[16:18] <robru> slangasek: well, you'd be missing the landing description only
[17:06] <sil2100> jibel, ToyKeeper, davmor2: I have the image
[17:06] <sil2100> jibel, ToyKeeper, davmor2: image #4 on ubuntu-touch/ubuntu-rtm/14.09-factory-proposed (mako)
[17:07] <sil2100> jibel, ToyKeeper, davmor2: please flash to this particular image as I will be adding a new one that has the here tarball on top of it
[17:11] <kenvandine> i can assign those
[17:16] <robru> kenvandine: ^^ same request assigned in both 6 and 8?
[17:16] <kenvandine> robru, wily and vivid
[17:16] <kenvandine> not dual
[17:17] <robru> kenvandine: ah ok. manual uploads
[17:17] <kenvandine> yeah
[17:19] <kenvandine> i was to speedy with the sync from 6 to 8 :)
[17:19]  * kenvandine works on patience
[17:21] <sil2100> kenvandine: you could have used the sync:silo_number,series notation
[17:21] <kenvandine> i thought i should be able to go ahead and sync from 6 to 8 since the source is there
[17:21] <sil2100> kenvandine: it works better for these cases as once you land the source silo, it re-targets to the main archive
[17:21] <kenvandine> sil2100, i thought so... but last time i tried that i got an exception and was told to do this... :)
[17:21] <kenvandine> which was ages ago
[17:22] <sil2100> kenvandine: https://wiki.ubuntu.com/citrain/SyncSilos <- should work now
[17:24] <kenvandine> sil2100, do i need to wait for silo 6 to finish building before syncing it?
[17:26] <sil2100> kenvandine: probably... it might need to wait until it's fully published
[17:26] <kenvandine> ok
[17:30] <ogra_> sil2100, hmm, just looking at my ubuntu-touch-meta upload, why was qml-module-qtbluetooth added to touch, ad not to the framework (sdk-libs) ?
[17:31] <sil2100> ogra_: slangasek merged it in, but said he won't release it - so I thought it wasn't released
[17:32] <ogra_> sil2100, it caame in with the last metapackage update (that i had to do for snappy personal)
[17:32] <sil2100> ugh
[17:32] <ogra_> if it shouldnt be released, it shouldne be merged in the seed ;)
[17:32] <ogra_> *shouldnt
[17:37] <slangasek> sil2100: what won't I release?
[17:37] <ogra_> slangasek, qml-module-qtbluetooth
[17:37] <slangasek> sil2100: ah.  yes, I merged it in the seed, and was waiting for the discussion to finalize before I uploaded the package
[17:38] <slangasek> because I had already merged the seed before ogra_ raised his objection
[17:38] <ogra_> i just noted post-upload that it landed in teeh wrong seed (qml modules usually go into the framework (sdk-libs) )
[17:38] <ogra_> *the
[17:39] <jibel> sil2100, you mean #4 is what we have to test or we must wait for #5?
[17:39] <sil2100> jibel: test #4 - #4 is the community image
[17:39] <jibel> sil2100, ok
[17:39] <sil2100> jibel: #5 is the same image with the HERE tarball
[17:40] <sil2100> jibel: in other words, #4 is like ubuntu-touch/stable/ubuntu, while #5 is like ubuntu-touch/stable/bq-aquaris.en (for mako of course)
[17:40] <sil2100> E-mail sent
[17:40] <slangasek> sil2100: looks like I need to add more lines to the spreadsheet in order to resurrect silo 55, because the spreadsheet is full?  how many lines is it reasonable to add?
[17:40] <davmor2> jibel: sil2100 I'm firing up 4 now
[17:40] <jibel> sil2100, yeah but as soon as you'll publish #5 there'll be an update notification and I'm sure a tester will upgrade
[17:41] <boiko> kenvandine: I think you need to change the series to vivid before uploading to silo 8
[17:41] <kenvandine> the train should mangle the version in the sync
[17:42] <kenvandine> sil2100, ^^ right?
[17:42] <boiko> kenvandine: only for train-generated release schemas
[17:42] <kenvandine> i can manually upload to the vivid silo too
[17:42] <boiko> kenvandine: if I remember correctly from the telepathy-qt landings I did
[17:42] <kenvandine> ok
[17:42] <sil2100> jibel: #5 is already present, that's why I said to explicitly use #4
[17:43] <sil2100> jibel: I can't keep normal rc-proposed builds waiting forever, so I had to creat both
[17:43] <sil2100> slangasek: uuh, I usually add 20
[17:43] <slangasek> sil2100: not 1000, which it defaults to? ;)
[17:43] <jibel> sil2100, understood, we'll be careful to test the right thing
[17:43] <slangasek> (done)
[17:44] <sil2100> slangasek: no, worried that the spreadsheet would die afterwards ;p
[17:44] <kenvandine> sil2100, since this is essentially a sync from mako, even though i have to manually upload it, what should i do with the version?
[17:44] <kenvandine> should i do an sru style version even though this isn't an sru?
[17:44] <sil2100> kenvandine: syncs work only for CI Train released packages, so depends what you're syncing
[17:45] <kenvandine> i wouldn't want an SRU in vivid to be a higher version than what's in the overlay ppa
[17:45] <sil2100> kenvandine: in case you need to do it manually, I usually version it like an SRU but then append ~overlay1 if I know this won't be SRUed in the nearest time
[17:46] <kenvandine> this is a package also used on the desktop
[17:46] <kenvandine> so i wouldn't want an sru for the desktop to stomp on the version in the overlay
[17:46] <kenvandine> and the source package i'm upload is identical to what's in wily
[17:48] <slangasek> charles: I've resurrected the spreadsheet line for silo 55 onto line 83; maybe you can help fill out the rest of the fields that I can't reverse-engineer from the dashboard
[17:48] <slangasek> sil2100: ^^ and should the rest of the automatic fields update on their own at some point, or is there something I should do to trigger a refresh?
[17:48] <charles> slangasek, looking
[17:49] <sil2100> slangasek: hmmm, might be that this part of the spreadsheet got broken, let me look at that
[17:56] <kenvandine> boiko, it's building now in silo 8
[17:56] <boiko> kenvandine: thanks!
[17:56] <charles> slangasek, I've resynced indicator-datetime and platform-api with changes in their trunks, will rebuild the silo & resinstall to confirm nothing crazy happened
[17:57] <slangasek> charles: cheers!
[18:04] <sil2100> robru: meeting!
=== karni is now known as karni-away
[19:12] <robru> sil2100: yep it is working: https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/lastSuccessfulBuild/artifact/pay-service_packaging_changes.diff/*view*/ ;-)
[19:30] <slangasek> sil2100, robru: so not to worry you or anything, but I've just noticed that silo 13 is also not in the spreadsheet
[19:31] <robru> slangasek: naturally
[19:31] <robru> slangasek: "stuff missing from the spreadsheet" is not a scenario capable of surprising me.
[19:31] <slangasek> this means that of two silos I've looked at, both have been missing from the spreadsheet
[19:32] <slangasek> robru: can you audit it, to figure out what all is missing from the spreadsheet and what we need to do about it?
[19:32] <robru> slangasek: there's an easy way to tell what's missing from the spreadsheet. if the dashboard doesn't have a description in tiny text at the bottom of the silo's card, then the row couldn't be found in the spreadsheet
[19:32]  * slangasek nods
[19:33] <slangasek> silos 13, 14, 26, 27, 29 appear to be affected
[19:33] <robru> slangasek: looks like 13, 14, 26, 27, 29
[19:33] <robru> yep
[19:34] <robru> slangasek: there's no automated way to restore it, just have to copy & paste really
[19:41] <slangasek> mzanetti: I see that silo 18 is dirty wrt unity8, which we still need for the g++ transition; can you fix that up please?
[19:42] <mzanetti> slangasek, check out silo 35
[19:42] <slangasek> mzanetti: ok, then can you please take care of cleaning up silo 18 :)
[19:42] <mzanetti> slangasek, had to do some reshuffling and moved it over, will drop it from 18 when I touch that next time
[19:42] <slangasek> ok
[19:43] <mzanetti> slangasek, yeah... will need that as soon 35 has landed to prepare the next one
[19:46] <boiko> cihelp: hi, I have a telepathy-ofono package showing as "Regression" in the excuses page, is that for real or a false positive?
[19:47] <fginther> boiko, It was a false failure. It should show up on the excuses page with the updated results in a few minutes.
[19:48] <boiko> fginther: nice! thanks!
[19:49] <boiko> fginther: so, are you guys always monitoring those failures, or do you think it is a good idea that I ping you when I see a failure in a landing I am dealing with?
[19:50] <fginther> boiko, No, we don't always monitor them. so please ping us if there is unexpected failure.
[19:51] <boiko> fginther: ok, thanks
[19:52] <slangasek> greyback__: is silo 7 really meant to be a dual-landing?  qtmir isn't currently in sync between vivid overlay (0.4.5+15.04.20150617-0ubuntu1) and wily (0.4.5+15.10.20150722-0ubuntu1).  (Question prompted by trying to track down all the outstanding g++-4.9 build-dep bugs, which need to get landed asap this week)
[19:53] <greyback__> slangasek: I'm waiting for silo11 to land, which lands qtmir to sync between wily & vivid+overlay
[19:53] <greyback__> I hope that won't be long
[19:54] <robru> greyback__: well the silo is sitting in an error state, are you waiting for somebody to do something about that?
[19:56] <greyback__> robru: I'm waiting for silo11 to land, so the dual landing will work again
[19:56] <robru> greyback__: ok but like... it's not on anybody's radar to QA or publish it, so unless somebody is actively working on that silo, it's just sitting there.
[19:56] <slangasek> robru: are you referring to the error state of silo 7 (which requires silo 11 to land so the build-deps are satisfied), or silo 11 (which has a lovely error message I don't know)?
[19:57] <robru> slangasek: I'm talking about the error in silo 11.
[19:57] <slangasek> ok
[19:57] <robru> slangasek: greyback__: this error appears to be because the train doesn't support syncing packages it doesn't own, in this case xorg-server.
[19:58] <robru> slangasek: greyback__: but it looks like lukasz copied that package manually, so this could probably be kicked along by poking the train config
[19:58] <greyback__> robru: silo11 not my thing, I just want mir0.14 in vivid+overlay before I start with silo7 again
[19:58] <robru> anpok: are you working on silo 11? how's it going?
[19:58] <greyback__> robru: do you think I should do something else?
[19:59] <robru> greyback__: well I just have no idea if anybody is even looking at that silo, the error message sure doesn't make it sound like it's on the verge of being published.
[20:00] <greyback__> robru: I am maintaining that silo, and it fails to build right now. I believe that is because the qtmir versions in wily & vivid+overlay are currently different
[20:00] <slangasek> greyback__: IMHO this is a dependency on another silo that's going to take a while to figure out; we need the g++-4.9 build-dep dropped ASAP, because /after/ it's dropped we still need to try to build these packages with gcc 5 in the other silo, and deal with any failures
[20:00] <slangasek> greyback__: so we would appreciate getting the g++-4.9 b-d fix landed without it getting tangled in mir 0.14 / vivid
[20:01] <robru> greyback__: I mean silo 11. as far as I can tell it's just sitting there. I wouldn't hold my breath for it
[20:01] <greyback__> slangasek: alright, will take it on tomoorow am
[20:01] <slangasek> robru: looking at the config for silo 11, how would we fix that?  The 'sync:ubuntu,wily' applies to all the package names there, right?
[20:01] <slangasek> greyback__: ta
[20:01] <greyback__> robru: anpok was at it today afaik
[20:01] <greyback__> robru: was running AP tests
[20:02] <robru> slangasek: yeah but a sync is barely distinguishable from all manual sources, assuming all the other packages are copied correctly and working correctly we can just take out the sync, reconfigure, and WATCH_ONLY build and it should be good to go for QA.
[20:02] <robru> slangasek: but I need confirmation from the silo owner that he's tested it and it's actually good to go for QA before I bother reconfiguring it for him
[20:02] <slangasek> robru: gotcha
[20:12] <robru> anpok: why do we even need xorg in vivid-overlay anyway? is that used on the phones?
=== salem_ is now known as _salem