[05:23] <Mirv> anpok: did you get what you needed to the 053?
[05:23] <Mirv> anpok: answer seems to be no, so copying. also, reconfiguring the silo the claim all of them are manual uploads, since it used to be dual landing for all and you want to continue doing dual landings (you can't now use the same MP:s for the vivid landing)
[05:24] <Mirv> anpok: or hmm, maybe that current line in there is good enough, but it was not reconfigured after the line was changed
[05:50] <Mirv> michi: hey! you could test on wily too, silo 021 has the same accessibility fix for wily. I think it'd be nice to see how it behaves in the exact thumbnailer scenario.
[05:50] <michi> Mirv: OK, I’ll have a look.
[05:50] <michi> Unfortunately, I don’t know how to install the new thumbnailer from a Jenkins build.
[05:51] <michi> Jenkins devel-ci still builds with the old version number.
[05:51] <michi> I’ll talk to James about it later today.
[05:53] <Mirv> michi: so the build from the silo 10 workarounds the issue ie is not good for testing it? can you give me the jenkins url? I believe if you can download the .deb:s from there and push them to device, you can dpkg -i *.deb them
[05:54] <Mirv> michi: I'm not otherwise in a hurry, but I'll be away for two weeks after today so if you want it in, I'd rather do it sooner than later today ;)
[05:54] <Mirv> I've already autopilot tested the vivid silo to have no regressions otherwise
[05:54] <michi> Mirv: No, I added our own work-around for the time being.
[05:54] <michi> To test whether it’ll work with the new network access manager, I need to build a new thumbnailer with the work-around removed and some extra trace.
[05:55] <Mirv> michi: ok
[05:55] <michi> But I can’t get the package that Jenkins builds for Arm onto the device right now because of the version going backwards.
[05:55] <Mirv> michi: dpkg -i forces even a downgrade
[05:56] <michi> Cool, I’ll try that, thanks!
[05:56] <Mirv> just adb push each .deb to the /home/phablet , then adb shell and dpkg -i *.deb
[05:58] <Mirv> you're welcome
[06:30] <anpok> Mirv: yeah I wasnt sure yesterday then ended my day..
[06:30] <anpok> Mirv: because of gtk+3.0
[06:31] <anpok> we are on 3.14 on vivd, and 3.16 on wily, I wasnt sure how to configure sync for all the others, but manual upload for gtk+3.14
[06:44] <Mirv> anpok: I'm actually not 100% sure either how it should be done :) but it's now all "manual" uploads, and the watch_only build is running so hopefully it should soon be ready to test
[07:08] <tsdgeos> Mirv: nice :)
[07:33] <Mirv> tsdgeos: you're welcome :)
[07:34] <Mirv> anpok: ah, 053 would need qtmir-gles and qtubuntu-gles still..
[07:34] <Mirv> anpok: I can handle those too
[07:35] <Mirv> anpok: or, hmm, they are outdated in 053, should they be the same version as wily has in 004? they don't seem to have vivid specific branches?
[07:36] <Mirv> anpok: correction, qtubuntu is up-to-date, qtmir in 004 only has your comment change so it does not matter
[07:38] <Mirv> anpok: -gles packages building for vivid now, watch https://ci-train.ubuntu.com/job/ubuntu-landing-053-1-build/11/console
[07:39] <seb128> hum
[07:41] <seb128> did people notice that the mir update is blocked in wily-proposed due to boottest regressions?
[07:41] <seb128> https://jenkins.qa.ubuntu.com/job/wily-boottest-mir/lastBuild/console
[07:41] <seb128> the logs don't have much details
[07:44] <Mirv> I'm not sure if the boottest is deemed to be trustworthy nowadays or not, but I can rerun it now to see if it persists
[07:45] <seb128> yeah
[07:46] <seb128> the thing is that it failed for all the packages in the set
[07:46] <seb128> e.g
[07:46] <seb128> https://jenkins.qa.ubuntu.com/job/wily-boottest-qtmir/lastBuild/console
[07:46] <seb128> that one has a "ERROR: timed out waiting for Unity greeter"
[07:47] <Mirv> anpok: ^ you should probably be interested in that wily mir problem, whether there's a real problem
[07:47] <Mirv> anpok: you could probably update to wily-proposed on device to see
[07:51] <jibel> seb128, actually there are lot of boottest failures http://paste.ubuntu.com/11891679/ is anyone looking at the results?
[07:52] <jibel> for exmaple lxc-android-config should be whitelisted, it cannot be installed directly
[07:53] <jibel> seb128, and when tests fail the log are not useful to do any diagnostics, eg. ubunut-system-settings-online-account ... Killed without further info
[07:54] <jibel> like mir
[07:57] <seb128> jibel, yeah, that's what I said "it failed for all the packages in the set"
[07:58] <seb128> that "lot" is just the new mir landing
[08:02] <anpok> Mirv: will have a look
[08:24] <jibel> Mirv, I re-ran all non-mir or qt boottest failures ie. pay-service platform-api thumbnailer trust-store ubuntu-app-launch ubuntu-system-settings-online-accounts
[08:24] <jibel> Mirv, lxc-android-config must be whitelisted, it  must be installed from recovery
[08:25] <jibel> Mirv, and the thumbnailer seems to be a real dependency issue in Wily
[08:25] <jibel> jamesh, ^
[08:28] <jamesh> jibel: what do you mean by "a real dependency"?
[08:28] <Mirv> jibel: ok
[08:28] <anpok> so the boot test fails because it attempts to upgrade lxc?
[08:28] <jamesh> real dependency issue.  Sorry
[08:29] <jamesh> if this is libleveldb1, won't that be fixed when the next image gets rolled?
[08:29] <anpok> jibel: btw pay-service ubuntu-app-launch ubuntu-system-settings-online-accounts are all part of the mir update.
[08:29] <jibel> jamesh, in the log of https://jenkins.qa.ubuntu.com/job/wily-boottest-thumbnailer/lastBuild/ there is this error at the end
[08:29] <jibel> The following packages have unmet dependencies:
[08:29] <jibel>  thumbnailer-service : Conflicts: libthumbnailer0 but 1.3+15.04.20150312-0ubuntu1 is to be installed
[08:29] <jibel> anpok, ok
[08:30] <jamesh> jibel: we shouldn't have any libthumbnailer0 now.  That package was removed
[08:31] <anpok> Mirv: just read the logs above.. thanks for cleaning up my mess.
[08:31] <Mirv> anpok: yes, the 053 seems to be intact for testing now. you're welcome.
[08:31] <jamesh> jibel: I believe the conflicts/replaces headers are correct (I applied the fixes infinity gave me)
[08:31] <Mirv> oh, I noticed only now that sil2100 had cancelled the hangou
[08:31] <Mirv> t
[08:31] <anpok> is there a way to manually upgrade without touching lxc-android-config?
[08:32] <sil2100> Mirv: yeah, not much to discuss
[08:32] <Mirv> anpok: what I do usually is just to dist-upgrade, then when it fails run sudo dpkg --configure -a
[08:36] <ogra_> hmpf
[08:37] <ogra_> none of the buttons in my indicators work on arale ...
[08:37] <ogra_> (i.e. tapping on battery settings in the indicator doesnt open anything)
[08:37] <ogra_> is anyone else seeing that ?
[08:38]  * ogra_ is on r52 on rc-proposed
[08:38] <ogra_> err
[08:38] <ogra_> r62
[08:38] <ogra_> updated 1h ago
[08:38] <jibel> ogra_, it works on r62
[08:38] <ogra_> hmpf
[08:39] <ogra_> i wonder whats wrong with my device then
[08:39] <jibel> they all work
[08:40] <anpok> Mirv: so it boots here after dist-upgrading.. so this was really just thumbnailer and lxc?
[08:41]  * ogra_ reboots, my spread also only shows shadows instead of app screenshots again 
[08:45] <jamesh> jibel: I'm still not sure what that build log is trying to do.
[08:45] <Mirv> anpok: well if you're dist-upgrading after flashing today morning's image, there's only so much new there is
[08:46] <jibel> Mirv, can you help on the thumbnailer boottest failure, I am not sure either how boottest installs packages.
[08:49] <jibel> cihelp ^
[08:49] <psivaa> jibel: let me take a look
[08:58] <ogra_> sil2100, seems i386 failed to build for the last vivid image build
[09:07]  * sil2100 checks the logs
[09:09] <sil2100> hm, dep issues, unity8 couldn't be installed
[09:19] <Mirv> jibel: I don't find anything that would depend on the libthumbnailer0 with the new packages
[09:23] <Mirv> but maybe psivaa can find something more out
[09:23] <psivaa> still digging, all devices being occupied does not help speed up :)
[09:30] <jibel> ogra_, how do you reproduce the "shadow effect"? I never saw it
[09:30] <ogra_> jibel, i simply use the device
[09:31] <ogra_> it starts happening after a few hours ... and gets worse over time
[09:31] <jibel> ogra_, me too :) any specific use of the device?
[09:31] <jibel> hm
[09:32] <ogra_> jibel, no, i have my usual 5 apps open, nothing fancy
[09:32] <ogra_> seems it is worse if the browser is open alongside
[09:44] <sil2100> Oh
[10:01] <psivaa> jibel: Mirv: i don't think we could make libthumbnailer0 work with boottest as it's currently setup,
[10:02] <psivaa> this is due to the fact that its  ubuntu-touch/devel-proposed/krillin.en vivid being the base image where the boottests are run
[10:03] <psivaa> and the fact that we're trying to install wily version of thumbnailer-service as part of the testrun, which conflicts with libthumbnailer0
[10:03] <psivaa> http://paste.ubuntu.com/11892053/
[10:04] <psivaa> So, thumbnailer(wily) -> installs thumbnailer-service(wily) on vivid base which already has thumbnailer0, which is conflicting
[10:05] <psivaa> s/thubnailer0/libthumbnailer0
[10:07] <jamesh> psivaa: thumbnailer-service should be replacing everything we had in libthumbnailer0, and there are no further dependencies
[10:07] <jamesh> further dependencies on that package
[10:11] <sil2100> Mirv: interesting... I'm looking into the reason why our last i386 image didn't build correctly
[10:11] <jamesh> psivaa: if the test is actively trying to install libthumbnailer0, then that sounds like a problem with the test.
[10:13] <sil2100> Mirv: and this might also be related to the thumbnailer landing, but hm, the error is a bit strange
[10:14] <sil2100> Mirv: the shlibs:Depends on thumbnailer generated something really strange
[10:15] <sil2100> Mirv: qtdeclarative5-ubuntu-thumbnailer0.1 has such a dep currently: libqt5quick5 (>= 5.4.1-1ubuntu7) | libqt5quick5-gles (>= 5.4.1-1ubuntu7) <- first, not sure why shlibs is suddenly depping on the exact version number, and why did it mark requiring 5.4.1-1ubuntu7 for -gles if gles is currently one rev behind (5.4.1-1ubuntu6)
[10:18] <sil2100> 5.4.1-1ubuntu7 does not and never existed for the -gles version
[10:25] <Mirv> sil2100: eh..
[10:26] <Mirv> sil2100: is the i386 image an emulator image? that could mean that we should not allow the versions to go out of sync, since the .symbols file might declare the dependency like that
[10:26] <sil2100> Ah... right, yeah
[10:26] <Mirv> sil2100: oh, oh... this is the first time ever this is happening, and the reason is that in ubuntu7 we added backported feature from Qt 5.6 which the new thumbnailer is using
[10:26] <sil2100> I thought we generally avioided depping on particular -0ubuntu versions
[10:27] <Mirv> sil2100: this is packaging automagically doing the correct thing... well, almost, the gles should not be like that
[10:27] <sil2100> Ok, that explains it
[10:27] <Mirv> sil2100: so I think we need to do no-op gles build bumping the version nuumber
[10:27] <Mirv> sil2100: siloing
[10:27] <sil2100> Mirv: yes, certainly
[10:27] <sil2100> Thanks :)
[10:27] <sil2100> Generally I hate depping on ubuntu versions, but in the case of Qt well... I guess there's nothing better one can do
[10:30] <cwayne> sil2100: heya
[10:30] <sil2100> cwayne: hey!
[10:30] <Mirv> sil2100: that's not happening in general - but here it is since ubuntu7 version specifically added new symbols that thumbnailer is now using
[10:31] <cwayne> sil2100: any idea whats going on with importing images? the last arale custom tar that was built still hasn't shown up in meizu.en-proposed
[10:31] <sil2100> cwayne: oh? Still? Let me check the config and the s-i server
[10:31] <sil2100> One moment
[10:32] <Mirv> sil2100: generally packages don't add new features in ubuntuX versions :)
[10:36] <sil2100> Mirv: yeah, that's what I expected and scratched my head about ;)
[10:37] <sil2100> But yeah, this is a special case
[10:45] <sil2100> hmmm
[10:45] <sil2100> Ah!
[10:45] <sil2100> I see a typo in the config
[10:45] <sil2100> cwayne: ^
[10:46] <cwayne> huh, how did it ever work then i wonder
[10:46] <sil2100> cwayne: not sure, it shouldn't have worked in the past, not for meizu.en-proposed
[10:48] <cwayne> lol
[10:49] <sil2100> Strange that the jenkins job urls are different there
[10:49] <sil2100> cwayne: anyway fixed now
[10:49] <sil2100> Let's wait for another importer run
[10:54] <Mirv> sil2100: ^ 008 built, is it possible to test it with the image similar to how you debugged it
[10:55] <sil2100> Mirv: I can try, I debugged it on my chroot, still have it open
[10:55] <sil2100> I'll just add your PPA to sources
[10:55] <Mirv> sil2100: hmm, the publisher didn't yet run though. build finished 6 minutes ago so 4-9 to go.
[10:55] <Mirv> sil2100: thanks
[10:56] <sil2100> Ok, I'll prepare everything in the meantime
[10:58] <Mirv> sil2100: ok now it should be done
[11:03] <sil2100> uh
[11:03] <sil2100> Mirv: still a problem
[11:03] <sil2100> Mirv: it needs to be 5.4.1-1ubuntu7 not 5.4.1-0ubuntu7
[11:04] <sil2100> It looks like the non-gles version was a debian -1, so the -gles one needs  that too
[11:04] <sil2100> So, not -0ubuntu7 but -1ubuntu7 (didn't notice that originally)
[11:08] <psivaa> jamesh: The test does try to install libthumbnailer0, qtdeclarative5-ubuntu-thumbnailer0.1, thumbnailer-common and thumbnailer-service
[11:08] <psivaa> jamesh: this is because libthumbnailer0 is already an installed package due to the base image being vivid
[11:09] <psivaa> jamesh: please take a look at lines 155,162 and 163 in http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/boottest.sh
[11:18] <sil2100> Mirv: regarding silo 006 - we need to make sure it's also released to wily
[11:20] <Mirv> sil2100: ouch... so I must lie about the package being in Debian while it isn't
[11:20] <sil2100> :<
[11:20] <Mirv> ok then
[11:23] <jamesh> psivaa: so that test has no chance of ever succeeding if we ever merge two binary packages (like we did for thumbnailer)
[11:24] <psivaa> jamesh: right, with this way we wont have thumbnailer passing :/
[11:37] <psivaa> Mirv: jibel: not sure if you noticed, the majority of the boottest failures (other than thumbnaier) are due to ''ERROR: timed out waiting for Unity greeter'
[11:38] <psivaa> one possible cause as pitti suspected could be the new Mir
[11:39] <Mirv> psivaa: I understood anpok tried testing it already (or well, at least he did test the silo that landed last night)
[11:40] <anpok> psivaa: I took todays devel-proposed image and upgrade to wily-proposed
[11:40] <anpok> *upgraded
[11:40] <anpok> boots fine
[11:42] <psivaa> anpok: is this the base image that you used, just to confirm, http://paste.ubuntu.com/11892361/
[11:43] <anpok> i used mako version 258
[11:44] <anpok> version_detail: ubuntu=20150717,device=20150708,custom=20150717,version=258
[11:47] <anpok> psivaa: ok comparing to boottest - I bootstrapped but then just I dist-upgraded
[11:47] <anpok> & updated..
[11:48] <sil2100> Mirv: testing!
[11:48] <Mirv> sil2100: ok, try again, silo is ready
[11:48] <Mirv> sil2100: heh
[11:48] <Mirv> good timing
[11:48] <karni> ping trainguards -- I wanted to make you aware that last thumbnailer changes have broken Telegram, and the app will not start in rc-proposed
[11:48] <karni> I've contacted #unity-api team
[11:48] <karni> We dynamically link with libthumbnailer.so, which seems to be gone from the system
[11:49] <Mirv> jamesh: ^
[11:49] <karni> http://paste.ubuntu.com/11892354/
[11:49] <sil2100> Mirv: works!
[11:49] <Mirv> sil2100: \o/
[11:49] <karni> yes, I've pinged jamesh about it
[11:49] <Mirv> sil2100: publishing
[11:49] <karni> waiting for his response
[11:50] <psivaa> anpok: ack, but i'd do a test on krillin to confirm, the fact that mako successfully booting does not confirm that it will boot with krillin
[11:50] <anpok> psivaa: yup switching devices now..
[11:51] <rvr> sil2100: Hi. In silo 7, dashboard says "caught signal 15, aborting". What does it mean?
[11:52] <greyback> rvr: it means I cancelled the build
[11:52] <rvr> greyback: So, is it ready for testing or not?
[11:52] <greyback> rvr: sadly no, I need to rebuild it and test it once mir in silo 4 lands
[11:53] <sil2100> greyback: uh, remember that cancelling a job before it finished preparing the packages is VERY risky
[11:53] <sil2100> By risky I mean in certain cases it can lead to the silo being broken
[11:53] <sil2100> Only abort when packages are prepared
[11:54] <rvr> greyback: Ok, removing the trello card
[11:54] <greyback> sil2100: it was a pretty quick cancel
[11:54] <greyback> *sigh* that has been sitting there for days
[11:55] <greyback> sil2100: but noted, I shall avoid doing so in future
[12:02] <seb128> hum
[12:02] <seb128> Mirv, jibel, so that mir update/boottest regression, I think it's real
[12:02] <seb128> I tried to install the new mir here on my n7 which is on wily
[12:03] <seb128> and it has the ubuntu log with 4 dots splash (new, looks nice!) but unity8 never shows and apport triggers on boot for unity8-dash
[12:05] <jibel> anpok, ^
[12:06] <anpok> yes seeing that.. do we have startup logs from unity8-dash/
[12:06] <jibel> seb128, good that boottest caught it. Thanks for the verification.
[12:06] <seb128> yw!
[12:06] <seb128> also the mir transition is incomplete
[12:07] <seb128>  url-dispatcher : Depends: libmirclient8 (>= 0.13.2+15.10.20150605) but it is not going to be installed
[12:08] <seb128> ubuntu-push-client as well
[12:09] <seb128> ciborium
[12:52] <kyrofa> trainguards: I just added another branch (same project) to my spreadsheet item. Do I need to do anything else to get that new branch into my silo?
[12:55] <Mirv> kyrofa: the silo needs to be reconfigured to include it
[12:56] <Mirv> kyrofa: since I'm not sure if you can do it, I just reconfigured it for you. now it should work/build fine.
[12:57] <anpok> seb128: there was an update to gtk-3.0 - in the mean time - do we have to upload a new source package to silo-004?
[12:57] <kyrofa> Okay, thanks Mirv!
[12:57] <seb128> anpok, no, the silo landed in wily-proposed it's not needed anymore, right?
[13:00] <anpok> seb128: ah ok so gtk+3.0 3.16.5.-1ubuntu2 was built again libmirclient9 and contains the deprecation free mir platform patches
[13:00] <anpok> +?
[13:01] <anpok> seb128: silo-004 now has url-dispatcher
[13:01] <seb128> anpok, updating the silo doesn't make sense since it landed to distro already, no?
[13:01] <seb128> anpok, and yes, the gtk upload was to fix an issue with the silo version
[13:04] <Mirv> seb128: the silo can be republished to fix proposed migrations, since it's only emptied if the migration succeeds
[13:04] <anpok> seb128: just thought we need a rebuilt url-dispatcher package to resolve the problem..
[13:04] <Mirv> but in this case one might to fix archives manually since the fixes are also manual uploads to the silo
[13:04] <seb128> Mirv, wouldn't it be more efficient to just upload the extra rebuild directly to the archive?
[13:04] <Mirv> seb128: yes, exactly
[13:05] <Mirv> but if they are built in the silo, one can also copy-package those to the archives
[13:05] <anpok> (and there is silo-053 which needs it too)
[13:30] <greyback> sil2100: heh you were right, I screwed up silo7 by cancelling a build. Do I need to clean & start again?
[13:31] <sil2100> greyback: might be the easiest way, if that's not a problem for you
[13:33] <greyback> sil2100: looks like nothing is easy https://ci-train.ubuntu.com/job/ubuntu-landing-007-3-merge-clean/42/console
[13:33] <sil2100> Yeah, that's normal... it's freed now, this is normal when the config file got erased/corrupted
[13:33] <sil2100> Re-assign and it should be good
[13:34] <greyback> sil2100: cool, ta
[13:48] <pmcgowan> can silo 2 be marked as passed
[13:48] <kyrofa> trainguards: dh-exec .install files aren't getting multiarch variables in my silo, but it works in my local pbuilder. What's wrong?
[13:48] <sil2100> pmcgowan: did QA sign it off?
[13:48] <pmcgowan> they did
[13:48] <pmcgowan> acc to trello yesterday
[13:49] <sil2100> hm, someone forgot to switch it then
[13:49] <sil2100> jibel, davmor2: setting the silo as passed
[13:59] <cwayne> sil2100: anyone in qa available to help test the latest arale custom + silo 35?
[13:59] <cwayne> i broke my arale at the worst possible time :(
[14:00] <sil2100> jibel, davmor2: ^ do you have anyone that could help? ^
[14:02] <davmor2> jibel: I can take it
[14:03] <davmor2> jibel: that way cwayne only owes one person drinks for the rest of their lives ;)
[14:03] <cwayne> :)
[14:05] <cwayne> davmor2: so, the steps to test: 1) install rc rev 2 on arale
[14:05] <cwayne> 2) favorite/unfavorite some scopes
[14:05] <cwayne> 3) switch channel to ubuntu-touch/rc-proposed/meizu.en-proposed
[14:05] <cwayne> 4) install ubuntu-touch-customization-hooks from silo 35
[14:06] <davmor2> cwayne: sure on it
[14:06] <cwayne> davmor2: <3
[14:07] <davmor2> cwayne: that's fine I never have to buy a drink again eva ;)
[14:07] <cwayne> davmor2: that is correct
[14:07] <cwayne> although penk will owe those to me since this isn't my tarball anymore :P
[14:08] <davmor2> cwayne: who requested the testing, Didn't see penk nick there once :P
[14:08] <cwayne> davmor2: lol
[14:10] <pmcgowan> sil2100, silo 6 can publish
[14:10] <sil2100> pmcgowan: I know, need to discuss that first
[14:10] <sil2100> pmcgowan: it's a direct upload to vivid, need to make sure those changes are staged for wily too
[14:10] <sil2100> It was a request from slangasek and awe_ mentioned he can start doing that post-OTA-5
[14:11] <pmcgowan> sil2100, ok
[14:11] <sil2100> Will publish once I have the situation cleared out
[14:12] <awe_> sil2100, I don't really see the context in the scrollback?
[14:13] <pmcgowan> awe_, silo 6 is network manager change
[14:14] <pmcgowan> but its vivid only?
[14:14] <sil2100> awe_: you weren't around when it got ready for publish - waiting for Steve's comment on if I can simply push it normally to vivid
[14:14] <awe_> because (a) we forked NM due to the desktop routing change which I didn't want to accept
[14:15] <sil2100> Since there's no silo/request with the same change in wily
[14:15] <awe_> and (b) I focused on getting everything landed for the phone first
[14:15] <awe_> pmcgowan, sil2100 and I discussed this.  I'm currently working on landing all of the changes in wily now
[14:15] <awe_> as separate landings
[14:15]  * awe_ is editing .patch files as we speak
[14:16] <sil2100> awe_: ok, so you want this to still go in and then you'll land it with all the others for wily, right?
[14:16] <awe_> yes
[14:16] <awe_> but go into the overlay PPA
[14:16] <awe_> not vivid itself
[14:16] <awe_> did I get the citrain fields wrong?
[14:17] <sil2100> awe_: I suppose it's fine, remember our kind request to at least get the silo for wily with each vivid-overlay landing once you sync it up
[14:17] <sil2100> The release team doesn't like when we land things in overlay first, it introduces the risk of the delta between devel and stable
[14:18] <awe_> sil2100, I don't like shipping phones with unstable code
[14:18] <awe_> I put my efforts on supporting devices we'd shipped, and explained myself in depth
[14:19] <awe_> this should have zero impact on desktop
[14:20] <sil2100> Right, and we're thankful for that, but we need to make sure that everything that lands to the stable devices also lands to the devel ones
[14:21] <sil2100> Otherwise, once we finally switch sometime in the future to the new series, we don't miss any fixes - and this already happened the last time for multiple projects
[14:21] <sil2100> So the release team is really cautious here
[14:25] <kyrofa> trainguards: I'm having some trouble in silo 11. My dh-exec .install files aren't getting $DEB_HOST_MULTIARCH defined... and I'm not sure why. It works locally
[14:26] <sil2100> awe_: did cyphermox take a look at those changes? Asking since this would mean it's already been reviewed from the packaging POV
[14:26] <sil2100> kyrofa: hm, let me take a look if it's something we can help with
[14:27] <kyrofa> sil2100, thanks. I can do it in override_dh_auto_install, but the debian wiki suggested dh-exec (https://wiki.debian.org/Multiarch/Implementation#Dynamic_debian.2F.2A_files)
[14:28] <awe_> sil2100, it was approved by abeato_ only
[14:30] <awe_> sil2100, as for the packaging, as NM is a packaging only branch, that's all I modified.  I added a new patch, and corresponding changelog entries
[14:30] <sil2100> awe_: yeah, thinking how to proceed with that, last time I just published it as it's nothing more than like publishing a code-only-change, but...
[14:30] <sil2100> Our agreement with the release team is strange
[14:31] <sil2100> Ok, I'll take it on me then
[14:32] <awe_> sil2100, what should I have done differently?
[14:32] <sil2100> awe_: everything fine from your side, although I would prefer cyphermox to be aware of the changes, it was more of if I should find a core-dev to approve it first or not...
[14:32] <awe_> if I always get a core-dev to review, would that smooth this out next time?  That seems odd, given that I'm landing in the overlay PPA, but if that's the requirement, so be it
[14:57] <davmor2> cwayne: should that of fixed the issues with only seeing 6 icons if so fail, Does it need to be installed during the install of the upgrade?
[14:58] <cwayne_> oh shit i think i forgot to rebuild the package with scott's latest fix
[15:00] <cwayne_> sorry davmor2, ill ping you once i get it rebuilt
[15:15] <kyrofa> sil2100, have you had a change to take a look at the dh-exec stuff in silo 11 yet?
[15:16] <sil2100> kyrofa: looking, but in a meeting still so it's hard to concentrate
[15:17] <sil2100> But I see what you mean
[15:17] <kyrofa> sil2100, heh, no problem :)
[15:18] <kyrofa> sil2100, it's not some sort of security thing, is it? Since the .install files are executable?
[15:30] <kgunn> robru: so, anpok (who's missing from irc atm) updated silo4 due to getting stuck in proposed....has now seemed to correct the silo, can you attempt to pub again?
[15:30] <kgunn> camako: ^
[15:31] <rvr> mzanetti: ping
[15:35] <mzanetti> hi victor
[15:35] <mzanetti> rvr, ^
[15:36] <rvr> mzanetti: Hey
[15:36] <rvr> mzanetti: I'm testing silo 48
[15:36] <rvr> mzanetti: I have a problem with the "start" gesture/Launcher button
[15:37] <mzanetti> hmm
[15:37] <mzanetti> what issue=
[15:37] <mzanetti> ?
[15:37] <rvr> mzanetti: Without the silo, when I'm on the news scope, pressing the "start" makes the Dash go back to the first scope
[15:37] <rvr> e.g. Today
[15:37] <rvr> mzanetti: With the silo, doesn't do anything
[15:38] <mzanetti> I did think there's something weird when I tested it... but tsdgeos convinced me it was good as it is :)
[15:38] <mzanetti> let me verify
[15:38] <tsdgeos> rvr: mzanetti: ok that's bad and should not have regressed
[15:38] <mzanetti> indeed
[15:39] <mzanetti> it seems to behave differently
[15:39] <mzanetti> yeah... bug... I guess that means failing the silo :/
[15:39] <rvr> Yup
[15:39] <tsdgeos> meh :/
[15:39] <mzanetti> sorry rvr
[15:39] <tsdgeos> throw away that branch
[15:39] <tsdgeos> and create unittest
[15:40] <popey> karni: is there a bug for broken telegram / thumbnailer wencan point people to?
[15:40] <karni> yes, 1 sec
[15:41] <karni> popey: https://bugs.launchpad.net/libqtelegram/+bug/1475691
[15:41] <mzanetti> rvr, I'll drop that branch from the silo and rebuild the rest as it is, ok?
[15:41] <rvr> mzanetti: Ok
[15:44] <popey> karni: thanks
[15:51] <davmor2> cwayne: relocating to the caravan back in 40 minutes-ish
[15:54] <cwayne_> davmor2, ack
[16:07] <sil2100> kyrofa: hm, I wouldn't do it in this way for sure
[16:09] <kyrofa> sil2100, how come?
[16:13] <sil2100> One moment
[16:17] <sil2100> kyrofa: so generally the recommended way is to make the build system take care of building/installing the binaries in the right multiarch directory and then just ask packaging to install them to their respective ones in the system
[16:19] <kyrofa> sil2100, dh-golang doesn't do that. The go idioms have no way to do that. I have to do it by hand, one way or another
[16:19] <sil2100> kyrofa: ouch, ok, this changes the situation - ok, we can do it differently
[16:20] <sil2100> Sadly I'm a bit overloaded with work right now
[16:20] <kyrofa> sil2100, I can add a Makefile rule to copy binaries around, but that's really the same thing
[16:20] <sil2100> Could you try poking some core-devs for advice here?
[16:20] <cwayne_> davmor2, so package should be ready whenever youre back
[16:20] <kyrofa> sil2100, I'd be happy to-- any recommendations?
[16:22] <sil2100> kyrofa: I would say poking slangasek, ogra_, seb128 or infinity - not sure which one of them would have some free cycles :)
[16:22] <kyrofa> sil2100, alright, thanks!
[16:32] <slangasek> sil2100, kyrofa: I would not expect there to be any multiarch directories that are relevant to golang.  this is silo 11?
[16:33]  * sil2100 has no experience with golang
[16:33] <kyrofa> slangasek, indeed it is. I'm just trying to place a unity scope in the right multiarch place
[16:34] <kyrofa> slangasek, but the go tools don't support installing anywhere other than $GOPATH/bin, and dh-golang straight-up copies binaries to /usr/bin, so I wrote .install files to move them to the right spot
[16:36] <slangasek> kyrofa: what's the right multiarch place, in this context?
[16:37] <kyrofa> slangasek, /usr/lib/${DEB_HOST_MULTIARCH}/unity-scopes
[16:37] <slangasek> ok
[16:38] <slangasek> so I think it's fine to use dh-exec for this, and move the file from /usr/bin to /usr/lib/${DEB_HOST_MULTIARCH}/unity-scopes in the .install
[16:38] <kyrofa> slangasek, it works fine on my local pbuilder, but in the silo it creates a directory named literally "${DEB_HOST_MULTIARCH}"
[16:39] <slangasek> ah
[16:39] <slangasek> kyrofa: is the executable bit of the .install file represented in your branch?
[16:39] <slangasek> or is this a source upload?
[16:41] <kyrofa> slangasek, indeed it is represented
[16:41] <kyrofa> slangasek, I was wondering if it was some kind of protection in the silo that disallowed execution
[16:42] <slangasek> not "protection", just "bug"
[16:42] <kyrofa> slangasek, if you're curious: lp:~kyrofa/unity-scope-snappy/improve_debs
[16:42] <kyrofa> slangasek, heh :)
[16:43] <kyrofa> slangasek, so I can obviously do this in debian/rules, just not nearly as slickly
[16:43] <slangasek> kyrofa: actually, the problem is that the package doesn't declare itself to be source format 3.0
[16:43] <slangasek> so there's no way to represent this executable bit on a round trip into a .dsc and back
[16:44] <kyrofa> slangasek, hmm. I was specifically asked to remove that :P
[16:44] <slangasek> by whom? :)
[16:45] <slangasek> kyrofa: you'll want to create debian/source/format with contents '3.0 (quilt)', build a source package, unpack it again, and test the build - that should let you verify that the source package is being generated correctly
[16:46] <kyrofa> slangasek, robru asked me to drop debian/source entirely
[16:47] <slangasek> kyrofa: ok; robru is mistaken on this :)
[16:47] <kyrofa> slangasek, okay, initially I had 3.0 (native) with a version number of 0.1.0 (no -0ubuntu1). I should do quilt instead?
[16:48] <slangasek> kyrofa: ah - yes, 3.0 (native) is wrong because this isn't a native package (native == no separate upstream and Ubuntu parts)
[16:48] <slangasek> kyrofa: 3.0 (quilt) is the right thing here
[16:49] <kyrofa> slangasek, alright. I'm a bit confused by that though. This is a Canonical project, for Ubuntu Personal. Can you explain how the upstream and Ubuntu parts are separate in this case?
[16:50] <slangasek> no but I can handwave furiously
[16:50] <kyrofa> slangasek, (I'm not a packaging pro, as you may have gathered :)
[16:51] <slangasek> kyrofa: the fact is, we use non-native version numbers for all of these packages, and the train autogenerates the upstream tarballs; so they're non-native packages in that sense, and also in the sense that any Ubuntu developer can upload a -0ubuntu2 revision to the archive using the same tarball
[16:51] <kyrofa> slangasek, ohhhh
[16:51] <kyrofa> slangasek, okay, I've gotcha :)
[16:51] <slangasek> so we just want to be consistent with that, even if the distinction between native and non-native is somewhat arbitrary
[16:52] <kyrofa> slangasek, fixing now!
[16:52] <kyrofa> slangasek, thank you very much
[16:53] <slangasek> kyrofa: no prob
[17:00] <kyrofa> slangasek, in order to test that out locally then, I'll need to create an upstream tarball?
[17:01] <slangasek> kyrofa: you should be able to download the existing one from the ppa
[17:01] <slangasek> (in order to not have to reproduce the train's own tarball synthesis)
[17:03] <dobey> hmm
[17:03] <dobey> kyrofa: if you use 3.0 (native) you don't need an upstream tarball
[17:04] <dobey> slangasek: my recommendation here is to use 3.0 (native) and a proper native version string in debian/changelog
[17:05] <dobey> slangasek: it is a native package, because there are no separate upstream and ubuntu parts
[17:05] <slangasek> dobey: that is an option, but I don't like native packages in general and I'm not sure how the train would handle that
[17:05] <slangasek> there certainly are
[17:05] <robru> slangasek: what? we have guidelines on this we've been using for a couple years now: https://wiki.ubuntu.com/DailyRelease/InlinePackaging (this is even since pre-train days)
[17:05] <dobey> what is the separate ubuntu part?
[17:05] <dobey> robru: those guidelines are ill-informed
[17:06] <slangasek> dobey: the debian/ directory is maintained by the Ubuntu developers, not by upstream
[17:06] <dobey> slangasek: it is maintained in the upstream source tree
[17:06] <slangasek> sometimes
[17:06] <dobey> in this specific case
[17:07] <dobey> (for most things landing via ci train, even)
[17:07] <slangasek> the packaging changes are owned by the Ubuntu developers, not by the upstream developers (thus Ubuntu dev sign-off is required for any changes); and sometimes Ubuntu changes land in the archive without being landed in the upstream trunk
[17:07] <slangasek> so no, not native
[17:07] <dobey> then someone needs to fix dpkg to support something that isn't native, but which isn't ubuntu either. because these things are somewhere in the middle, by that argument
[17:07] <slangasek> robru: well, inasmuch as those guidelines are incompatible with dh-exec, the guidelines are wrong.  Is there a reason that 3.0 (quilt) would be unsupported by the train?
[17:07] <robru> dobye: slangasek: train explicitely requires debian/ in the upstream trunk, we don't support anything else
[17:08] <slangasek> dobey: nope, this is non-native.
[17:08] <dobey> the upstream source tree is the canonical debian/ directory.
[17:08] <dobey> therefore it is native
[17:08] <slangasek> no, it's not
[17:08] <slangasek> it's not canonical, and it's not native
[17:08] <dobey> any changes uploaded directly to the archive, outside of that, would be non-native
[17:08] <slangasek> the canonical debian/ directory is whatever goes into the archive
[17:08] <robru> slangasek: the idea is that the train only works on canonical-owned projects so there just shouldn't be any quilt patches at all.. they should all be upstreamed
[17:08] <slangasek> yeah, we don't flip-flop packages between native and non-native on each upload
[17:08] <slangasek> robru: I'm not talking about quilt patches here
[17:09] <slangasek> that's the format name; it's not required that there be any quilt patches in the debian directory
[17:09] <dobey> it is native, but whatever
[17:11] <robru> slangasek: IIRC dobey hacked in support for native packages, but the version-generating feature doesn't work as well. definitely non-native is the way to go to be a first class citizen in train land.
[17:12] <dobey> yes, native packages work in the system
[17:12] <dobey> robru: version-generation works fine with native
[17:12] <slangasek> robru: I agree; which means in this case it needs to be 3.0 (quilt) because that's the non-native package format that allows representing executable bits in debian
[17:14] <robru> slangasek: alright
[17:15] <davmor2> cwayne: how we doing?
[17:15] <slangasek> robru: ok. so as long as the train isn't going to choke on 3.0 (quilt) at the source prep stage, I think that's the way forward
[17:18] <dobey> :/
[17:20] <robru> slangasek: sounds fine then. Indeed the 'delete debian/source' instruction is in the context of "now we're upstreaming all the patches"
[17:24] <kyrofa> trainguards: I'm getting a "dependency wait timeout" for arm64 and ppc in silo 11. How do I debug that?
[17:26] <robru> kgunn: anpok: need this top-approved: https://code.launchpad.net/~mir-team/url-dispatcher/mir-release-0.14.0/+merge/262953
[17:26] <davmor2> cwayne: just got the message thanks trying now
[17:26] <dobey> kyrofa: golang-go.tools isn't built on those platforms currently it seems
[17:26] <slangasek> kyrofa: not sure about the 'timeout', but dependency wait is expected here because the package build-depends on toolchain bits that don't exist on those architectures; the problem is ignorable
[17:27] <robru> slangasek: if it's ignorable then why did the train explode on it? that means there's a regression from distro.
[17:27] <kyrofa> slangasek, ah, okay. Yeah I'd expect a better error, haha :) . Okay, ignoring!
[17:28] <camako> robru, I top-approved it
[17:28] <camako> kgunn, anpok ^
[17:28] <dobey> hmm, so it failed to build on those archs in vivid
[17:28] <dobey> and it hasn't been updated in ubuntu since then
[17:28] <slangasek> robru: unity-scope-snappy isn't in the distro yet, so it can't be a regression
[17:28] <slangasek> robru: (I checked this before opening my mouth :)
[17:29] <dobey> hmm, and there's not a new version in debian either
[17:30] <robru> kyrofa: why are you rebuilding?
[17:30] <kyrofa> robru, I just pushed up the debian/source/format. I'd like real packages built :P
[17:31] <robru> kyrofa: ok sorry I'm just trying to catch up here
[17:32] <kyrofa> robru, oh you're good. Yeah, with the dh-exec files not being executed correctly I ended up with packages using variable names as directory names, haha
[17:33] <robru> kyrofa: slangasek: ok yes so in this case since there is no existing release in ubuntu, train default is to watch all arches, so that's why it's erroring on this ignorable problem. it'll keep happening every time you rebuild until finally there's a release, then the *next* silo you do for this package will watch the right arches correctly.
[17:33] <kyrofa> robru, good to know!
[17:33] <kyrofa> robru, thank you :)
[17:34] <robru> kyrofa: there may be other issues you run into, generally speaking the train isn't good at building brand-new packages, there's a bunch of code paths that check distro in order to know what to do/expect.
[17:34] <robru> kyrofa: you're welcome
[17:34] <kyrofa> robru, ah, happy to exercise them!
[17:35] <robru> kyrofa: but yeah once you get that first release out the door, all subsequent ones should go a lot smoother
[17:35] <robru> kyrofa: keep an eye on the PPA for now, the depwait timeout is something like 2 hours, so you can save yourself 2 hours of wait time by ignoring the train dashboard status and going right to the source.
[17:35] <kyrofa> robru, honestly everything I've hit so far has been my own lack of debian packaging knowledge
[17:35] <robru> kyrofa: and my bad advice ;-)
[17:36] <kyrofa> robru, had you not said anything I wouldn't have learned what I learned today :)
[17:36] <robru> kyrofa: ha, you're welcome then :-P
[17:37] <kyrofa> robru, ;)
[17:59] <cjwatson> robru: depwait timeout> one hour rather than two (and a cron job rather than a timeout)
[17:59] <robru> cjwatson: you're talking lp side. I'm talking in the train. When the train is polling the PPA build states, it gives up after 2 hours.
[17:59] <robru> 2 hours of depwait anyway. any other state it'll happily poll forever.
[17:59] <cjwatson> oh right, fair enough
[18:15] <cwayne_> davmor2, any luck?
[18:19] <davmor2> installing the silo now cwayne
[18:21] <cwayne_> kk
[18:26] <davmor2> cwayne: I haz 8 count them 8 Icons Woohoo!!!!!!!!
[18:28] <davmor2> cwayne_: 8 icons and the modifications are still in place too \o/
[18:29] <davmor2> jibel, robru: ^ do we need to retest or should we just push it through?
[18:29] <robru> davmor2: what silo? what's going on?
[18:30] <robru> davmor2: generally speaking a rebuild requires a retest, unless it's a totally trivial change, then a quick smoketest should suffice.
[18:30] <davmor2> robru: silo 35 and a custom tarball for the fix for the 8 icons on upgrade for ota5
[18:31] <robru> davmor2: custom tarball changes? that sounds risky ;-) I'd retest
[18:31] <robru> davmor2: maybe not the full test suite but make sure it's actually fixing the issue.
[18:31] <davmor2> robru: yeah I'm particularly concerned as cwayne forgot to build the image with the fix in D'oh :)
[18:32] <robru> davmor2: yeah I think a retest is in order ;-)
[18:34] <cwayne_> +1, because I'm an idiot :)
[18:35] <cwayne_> sorry, been like a year since i'd done an MP based landing instead of just a custom tar
[18:39] <davmor2> cwayne_: why the tail?
[18:39] <cwayne_> ?
[18:40] <davmor2> cwayne_: you have an _ and there is a cwayne too just wondered why ;)
[18:41] <cwayne_> davmor2, ah, cus im on my laptop downstairs but i left my desktop on upstairs
[18:41] <cwayne_> and i never setup an irc proxy
[18:42] <davmor2> cwayne: then set one up muppet boy you do nothing else with your day now you don't build the images ;)
[18:42] <davmor2> cwayne_: too^
[18:42] <cwayne_> lol
[18:46] <davmor2> cwayne_: so mark it passed I don't know what the plan is to get them into the staging image though we would need sil2100 for that I assume unless robru knows how to do it :)
[18:49] <robru> davmor2: well I can hit publish on the silo, but I'm not up to speed on custom tarballs or building images.
[18:49] <cwayne_> id say we should wait for sil then
[18:49] <robru> cwayne: that'll be, like 12ish hours...
[18:49] <robru> cwayne: I mean next week
[18:50] <cwayne_> well, we generally dont push custom tars without his +1, and this landing should go alongside a custom tar
[18:50] <cwayne_> so if we have to wait for monday, i guess it is what it is..
[18:50] <cwayne_> davmor2, thoughts?
[18:50] <davmor2> robru: this has to land in the image for ota 5 for arale so it's not a normal landing I don't think
[18:50] <robru> cwayne: ok, I'm going to mark it not tested so I don't forget and accidentally publish it then. follow up with sil on monday
[18:51] <cwayne_> robru, sounds reasonable, thanks
[18:51] <robru> davmor2: are you saying it's urgent then? I thought ota5 was just delayed
[18:51] <davmor2> robru: I think it needs some wrangling,  No urgent to test so it's ready for Monday that is achieved
[18:52] <cwayne_> yeap
[18:52] <cwayne_> so we should be all set
[18:52] <cwayne_> for today i mean
[18:52] <cwayne_> thanks a lot for testing davmor2
[18:53] <davmor2> cwayne: is there someone we can ping in EU timezone to push the button on the tarball?
[18:53] <robru> davmor2: ok great, sorry I don't know more about custom tarballs
[18:53] <cwayne_> davmor2, well penk could monday
[18:53] <robru> davmor2: sil is EU ;-)
[18:53] <cwayne_> since it is his now anyway :)
[18:53] <davmor2> robru: no worries I'll ping sil2100 after :)
[19:01] <robru> qbot no
[19:01] <kyrofa> trainguards: I just added a few new branches to line 74 of the spreadsheet (same project). Can I get silo 11 reconfigured to use them?
[19:02] <kyrofa> trainguards: I don't believe I can do this myself-- please correct me if that's wrong
[19:02] <robru> kyrofa: you can do it yourself. the rules on this have changed recently and probably haven't been updated yet
[19:03] <kyrofa> robru, ah, nice! How do I do that?
[19:03] <robru> kyrofa: first click on any cell in your row. then at the top there's a menu "Landing tools > Assign/Reconfigure"
[19:07] <davmor2> robru: sil2100 left you a cryptic note on the silo 20150717/robru: This is QA approved by davmor, but needs to land in coordination with a custom tarball, publish later so definitely over to silo2100 :)
[19:08] <robru> davmor2: no I just wrote that myself.
[19:08] <davmor2> robru: ah okay
[19:08] <robru> davmor2: the date/name at the start of those notes indicates who wrote it and when
[19:09] <robru> davmor2: that was just there to indicate it was testing pass, but I officially set the silo to not testing pass so that the dashboard wouldn't burn a hole in my eyes with a big temping "PUBLISH THIS" neon sign
[19:09] <davmor2> robru: oops
[19:10] <kyrofa> robru, awesome, thank you, it works! :)
[19:10] <robru> kyrofa: you're welcome!
[19:12] <taiebot> Fate as decided i will not buy an MX4 :'(. Wanted to top up my paypal account to pay for the new phone. Got the call for my bank to validate the transaction but my Nexus 4 running UT refused to take the call.
[19:12] <taiebot> Oups wrong channel
[19:14] <kyrofa> taiebot, yeah, I learned the "cihelp" doesn't get your questions answered in other channels, too
[19:20] <sil2100> davmor2, cwayne: I'll copy over the fix to the snapshot and try to kick an image
[19:20] <sil2100> davmor2, cwayne: from my POV the new custom tarball can be freely published to the rc-proposed channel
[19:20] <sil2100> davmor2, cwayne: are the krillin and vegetahd ones ready as well?
[19:20] <sil2100> I just need to finish something up and I'll get right to it
[19:21] <davmor2> sil2100: awesome dude, wasn't sure if there was anything special needed
[19:22] <salem_> robru, hey, as boiko is out, would you trigger a rebuild in silo 44 for me?
[19:23] <davmor2> mzanetti: what happened to greybacks silo 007?
[19:43] <robru> salem_: you should be able to trigger builds, can't you?
[19:43] <salem_> robru, I tried, but it seems I have no permission
[19:43] <salem_> robru, "tiagosh is missing the Job/Build permission"
[19:44] <robru> salem_: what's your launchpad id?
[19:45] <salem_> robru, tiagosh
[19:45] <robru> salem_: ok, I added you. if you log out of jenkins, log back in, make sure during SSO you check off the lp teams, then log back in and you should be able to build
[19:48] <salem_> robru, awesome, thank you!
[19:49] <robru> salem_: you're welcome
[19:54] <kyrofa> trainguards: My build logs suddenly look like this: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+build/7665329 . Is that normal?
[19:55] <kyrofa> trainguards: Meanwhile my silo just continually says "Currently building..."
[19:55] <robru> kyrofa: I've never seen this before
[19:56] <robru> maybe cjwatson knows ^^
[19:56] <kyrofa> robru, it's happened twice now-- I canceled the job and restarted it, and it happened again
[19:56] <robru> kyrofa: yeah don't do that
[19:57] <robru> kyrofa: "cancelling the job" doesn't have any effect on what's happening in the PPA.
[19:57] <kyrofa> robru, oops
[19:57] <robru> kyrofa: just let it sit for a bit. cjwatson mentioned the other day he was making some changes to the builders and there was a hiccup similar to this. this could be related.
[19:58] <robru> kyrofa: last time, the build log said finished while lp said it was still building. what I've never seen before is the weird unicode errors in the log
[19:59] <kyrofa> robru, yeah... suspicious indeed. Alright, I'll give it a breather
[20:11] <kgunn> camako: looks like we've still got an issue ?
[20:11] <kgunn> http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-004
[20:12] <kgunn> camako: ah...maybe just issue with device ?
[20:12] <kgunn> https://jenkins.qa.ubuntu.com/job/wily-boottest-mir/lastBuild/artifact/results/log/*view*/
[20:26] <camako> kgunn yea looks like it
[20:27] <kgunn> robru: ^ am i reading that correct ?
[20:29] <robru> kgunn: yeah boottest is known to be flaky
[20:29] <robru> cihelp: looks like almost all of these packages: http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-004 are stuck in proposed due to boottest, can somebody investigate?
[20:29] <robru> kgunn: actually something weird there, xorg-server doesn't look like it published, do you know what's up with that?
[20:29]  * kgunn looks
[20:31] <robru> kgunn: weird, the version from the PPA is in -proposed, but the train seems to be misreporting that it didn't publish. never seen that before
[20:32] <robru> kgunn: https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/71/artifact/packagelist_rsync_landing-004-wily/*view*/ here's the manifest even showing it publishing along with everything else
[20:33] <robru> kgunn: so I guess don't worry too much, but this will prevent the silo from auto-merging, we may have to manually poke the merge job once the migration completes. ping me if you notice the status change to only mention that xorg-server hasn't been published (and not mentioning anything else)
[20:33] <kgunn> robru: got it...
[20:52] <balloons> cihelp, can you disable utopic builds for sudoku app? sudoku-app-ci and sudoku-app-ci-autolanding
[20:55] <josepht> balloons: it looks like the utopic build is the only one, is that okay?
[20:55] <balloons> josepht, I see generic-mediumtests-utopic being run for it, as well as sudoku-app-utopic. You can keep sudoku-app-vivid
[20:56] <balloons> the framework requires vivid now essentially, so no more utopic can be run
[21:03] <josepht> balloons: I've pushed an MP for disabling the job in cu2d-config.  It will likely be Monday before it lands.
[21:19] <boiko> robru: could you please trigger an amd64 wily build of telephony-service on silo 43?
[21:19] <boiko> robru: trying to identify if the failure is a transient one or a real failure
[21:21] <robru> boiko: sure
[21:22] <boiko> robru: thanks
[21:23] <robru> boiko: you're welcome
[21:24] <cjwatson> robru: those are unicode but they aren't errors - that's just sbuild's box drawing, not rendered well here
[21:24] <cjwatson> kyrofa: almost certainly your build process has left something around on failure that for some reason we aren't managing to clean up correctly.  I've cancelled the build
[21:25] <cjwatson> (build, not job)
[21:25] <cjwatson> kyrofa: you should be able to see the full build log now
[21:26] <robru> cjwatson: ah, thanks for checking that
[21:26] <cjwatson> it's a bit odd that it didn't kill itself correctly, but I'm not investigating in that much detail on a Friday night :)
[21:27] <cjwatson> kyrofa: anyway there seems to be a missing Build-Depends: python3-requests or similar here, so maybe that will be enough to get things going properly
[22:18] <kyrofa> cjwatson, thanks for taking care of that! You're right, I forgot that dep
[23:35] <boiko> robru: coupd you please get libphonumber source package copied over from this ppa: https://launchpad.net/~boiko/+archive/ubuntu/source-uploads/+packages to silo 44?
[23:35] <robru> boiko: one sec
[23:36] <boiko> ah, source packages not supported in dual landings, hmm :/
[23:37] <robru> boiko: oh yeah right. you need to either do a wily landing and then later do a sync back to vivid landing, or make an MP for this package
[23:38] <boiko> robru: ok, I will check with _salem on monday how we want to do that, thanks anyway
[23:39] <robru> boiko: you're welcome!