=== chihchun_afk is now known as chihchun
[06:40] <morphis> robru: ping
[06:40] <robru> morphis: hola
[06:40] <morphis> robru: using 5.36.1 would be against what the core devs want
[06:40] <morphis> as that is touch the upstream version
[06:41] <morphis> so when I do that I can't use that silo anymore
[06:41] <robru> morphis: when you changed it to 0ubuntu2, did you change anything else outside debian? As changes outside debian/ modify the orig.tar, and having different orig.tars is not allowed with different -0ubuntuX versions
[06:42] <morphis> no, I didn't
[06:42] <morphis> robru: https://bazaar.launchpad.net/~morphis/bluez/vivid-5.36-upgrade/revision/10 is the only thing I did
[06:42] <robru> morphis: oh, weird, I would have expected that to work as long as the orig.tar stayed the same there.
[06:43] <morphis> from https://code.launchpad.net/~morphis/bluez/vivid-5.36-upgrade/+merge/278302 rev 9 is what I uploaded first and 10 is the second
[06:43] <robru> morphis: ok well I guess that PPA is burned, you should abandon the request then reassign the same request (silos are assigned at random so you should get a different one), then try rebuilding
[06:43] <morphis> robru: however updating the MP would work then still, right?
[06:44] <robru> morphis: yeah if you get a new PPA you get to start over with a new orig.tar so it should work. also change it back to 0ubuntu1
[06:45] <morphis> even if I updated the MP then to have 0ubuntu2 after I did some additional changes?
[06:46] <robru> morphis: huh? if you start over in a new PPA you should use 0ubuntu1. Don't make too many mistakes though or you'll run out of PPAs
[06:46] <robru> morphis: currently 10 available silos, so you get 10 tries to build a working package I guess.
[06:46] <morphis> robru: hm, so basically everytime I change the MP I have to use a new silo, right?
[06:47] <robru> morphis: that's what it sounds like. I don't understand why the PPA didn't accept the upload though, it should have if the orig.tar was the same
[06:47] <robru> morphis: maybe poke a launchpad-y person about the upload failure
[06:48] <morphis> robru: let me do that
[06:50] <Mirv> morphis: it's useful to use the ~ character in version number for test builds (~ == lower than without), for example I always have 1.0-0ubuntu1~test1 etc
[06:51] <Mirv> if the build is not massively big one, it's pretty cheap then to do the final build when everything's confirmed
[06:51] <Mirv> but it does not matter that much, mainly if it takes tens of tries to get it correct it'd be a bit funny to ship ubuntu23 or something :)
[06:54] <mardy> robru: hi! Still there?
[06:54] <morphis> Mirv: yeah that would be thing to do but lets say I hand this over to QA and then QA finds a bug which I fix then I have to get a new silo etc. to get a new package version and using ~test1 isn't an option for that
[06:54] <robru> mardy: yeah
[06:54] <Mirv> morphis: sure
[06:54] <mardy> robru: I saw your comment about https://code.launchpad.net/~online-accounts/signon-plugin-sasl/packaging/+merge/274568
[06:54] <morphis> Mirv, robru: asked over in #launchpad about this
[06:55] <mardy> robru: so, this is a completely new package, it's not in the archives
[06:55] <robru> mardy: yes
[06:55] <mardy> robru: is the ci-train the correct way of landing it, or should we land it in some other way?
[06:55] <robru> mardy: you can use the train but there are some rough edges.
[06:55] <mardy> robru: like MIR
[06:56] <robru> mardy: MIR is not a way of getting a package in the archive, it's a way of getting a universe package into main. totally different thing. you might also need that later
[06:56] <mardy> robru: ah, ok, two different steps then
[06:57] <robru> mardy: if your plan is to ship this on desktops/servers then you'll want MIR for sure, if the plan is for touch then it's less important (ideally touch stuff would be MIR'd but much of it hasn't been)
[06:57] <robru> mardy: but yeah use the train first
[06:57] <robru> mardy: but the thing is the train cannot handle this package because *trunk* doesn't have a debian/changelog
[06:58] <mardy> robru: ok, so if I merge the changes into trunk and then prepare an empty MP, the package should end up in the universe? or will there be some other step to be done?
[06:58] <mardy> (I mean, after the CI train lands it)
[06:58] <robru> mardy: yes, if you go through the train the very first upload will be in universe by default
[06:58] <mardy> robru: excellent, thanks; we'll do it thiw way then
[06:58] <robru> mardy: well, that's not a train detail, first upload of anything is universe by default
[06:58] <robru> mardy: you're welcome
=== robru is now known as robru_
=== robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
[08:27] <robru> Sure is quiet
[08:59] <jamesh> sil2100: you were trying to ping me late last night about mediascanner2?
[09:00] <jamesh> sil2100: currently mediascanner2 trunk is configured for dual landings, so it won't be possible to do a vivid only landing.
[09:02] <sil2100> jamesh: hey! Yes, we would like to release it without a merge, just a no change rebuild by bumping the ubuntu version
[09:02] <sil2100> jamesh: you would then just overwrite that change with your next landing
[09:02] <sil2100> jamesh: would that be ok?
[09:02] <jamesh> sil2100: would it be possible to do tvoss's landing in two silos though?  First build the vivid only bits in one silo, copy packages to a second where you do a vivid+xenial build?
=== dpm is now known as dpm-afk
[09:31] <sil2100> pstolowski: hey! Does the licensecheck breakage have a bug?
[09:32] <sil2100> pstolowski: the one from xenial
[09:33] <pstolowski> sil2100, probably not.. michi? ^
[09:34] <michi> No bug that I know of. What’s the problem?
[09:35] <michi> All I did was to turn off the licensecheck unity test when running on xenial.
[09:37] <tvoss> sil2100, o/
[09:41] <robru> oh goodie
[09:42] <sil2100> michi: but the change mentioned that it had to be disabled because of some issues with licensecheck
[09:42] <sil2100> michi: what are those issues?
[09:42] <sil2100> tvoss: o/
[09:42] <michi> sil2100, tvoss: I’m in two conversations simultaneiously...
[09:42] <tvoss> sil2100, did you see my question for https://requests.ci-train.ubuntu.com/#/ticket/635
[09:42] <michi> licensecheck behaves differently on xenial.
[09:42] <michi> It outputs a whole lot of crap it didn’t use to produce.
[09:43] <michi> And it fails on files it used to succeed on.
[09:43] <michi> So, rather than fixing an SEP, I decided to turn off the unit test for the license preamble on xenial.
[09:43] <michi> I don’t see how that could break anything though.
[09:44] <sil2100> michi: I agree that turning it off right now is a good workaround, but would be nice if you could fill in a bug against licensecheck to mention that such issues exist
[09:44] <michi> Yes, that’s still on my todo list.
[09:44] <michi> I haven’t forgotten, just haven’t managed to find the time yet.
[09:45] <sil2100> This way, when disabling licensecheck in another project, we can give a bug number in the comments that would make life easier for others to see if the licensecheck issues are fixed already or not
[09:45] <michi> So, did I break something by doing that?
[09:45] <sil2100> No, but I would like to have a bug number before I publish pstolowski's unity-api silo ;)
[09:46] <michi> Ah, I see :)
[09:46] <michi> It’s sort of late here. Can I file a bug tomorrow?
[09:46] <sil2100> Since it's good practice to have each disablement documented with a bug
[09:46] <michi> Yes, agree.
[09:46] <michi> It’s just that, sometimes, it feel like pushing lots of **it uphill.
[09:47] <michi> Someone gratuitously makes a bunch of changes that break our tests.
[09:47] <michi> Serves us right for having tests in the first place :-(
[09:47] <sil2100> michi: sounds ok, I might fill in a 'dummy' bug for licensecheck to not block pstolowski - I would then send you the bug link for you to fill in all the nice details
[09:47] <sil2100> hah
[09:47] <sil2100> ;)
[09:47] <sil2100> If that's fine with you
[09:47] <michi> OK, that sound good, thank you!
[09:47] <michi> I should get the bug notification email.
[09:48] <michi> Just in case, please add me explicitly to the subscription for the bug.
[09:48] <michi> I’ve had problems recently with notifications from launchpad.
[09:48] <michi> New bugs appear without any email ever arriving...
[09:48] <pstolowski> sil2100, yes, you're absolutely right!
[09:49] <robru> well, this is excelletn
[09:49] <michi> robru: What’s excellent?
[09:49] <robru> sil2100: I started migrating some silos to the new file format, but I'm getting permission denied errors when trying to copy. don't worry I'm working on it
[09:49] <robru> michi ^
[09:51] <mardy> trainguards: I cannot understand what is wrong here: https://ci-train.ubuntu.com/job/ubuntu-landing-060-1-build/34/console
[09:52] <sil2100> mardy: hey!
[09:52] <sil2100> mardy: it looks like your debian/source/format file has 3.0 (native), while for the train packages (and train versioning) this should be quilt
[09:53] <sil2100> So, either change it to 3.0 (quilt) or 1.0 simply
[09:54] <sil2100> mardy: ...or even remove the source/format file completely
[10:04] <robru> mardy: your version number is goofed up somewhere
[10:05] <robru> mardy yeah I recommend removing source/format as per https://wiki.ubuntu.com/DailyRelease/InlinePackaging
[10:05] <robru> oh god
[10:06] <sil2100> tvoss: hey! What question? I think I might have missed it...
[10:07] <tvoss> sil2100, I updated MPs for that request, but obsolete source packages still show up
[10:14] <sil2100> tvoss: let me take a look now
[10:15] <sil2100> tvoss: ah, yeah, in this case a trainguard needs to remove the old binaries - let me do that now
[10:16] <sil2100> tvoss: with next rebuild it should be good again
[10:25] <sil2100> pstolowski: hey! Could you modify your https://code.launchpad.net/~stolowski/unity-api/license-check/+merge/277544 MP and include the bug number LP: #1519292 in the comment of the temporary hack?
[10:25] <ubot5> Launchpad bug 1519292 in devscripts (Ubuntu) "licensecheck on xenial fails on files it used to succeed on" [Undecided,Incomplete] https://launchpad.net/bugs/1519292
[10:25] <sil2100> pstolowski: thanks :)
[10:25] <pstolowski> sil2100, sure, doing
[10:27] <pstolowski> sil2100, pushed, shall i kick the build?
[10:31] <jibel> trainguards: silo 57 shows this error: Uncaught exception: FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/jenkins/silos/ubuntu/landing-057/xenial/content-hub/content-hub'
[10:31] <jibel> what is it?
[10:31] <jibel> https://requests.ci-train.ubuntu.com/#/ticket/675
[10:32] <sil2100> jibel: there's a transition ongoing in the train
[10:33] <jibel> sil2100, which means?
[10:37] <Mirv> jibel: paths are changing, but all should be fixable
[10:40] <Mirv> well, it does not seem to fix by itself
[10:40] <Mirv> I think I'll rather publish manually
[10:44] <sil2100> Mirv: robru is working on getting things fixed
[10:44] <robru> guys I am so sorry for botching this transition so badly
[10:44] <Mirv> sil2100: yeah I'm sure he knows about the issues so meanwhile copy-package is friend among else
[10:44] <robru> I thought I had the migration script tested quite well
[10:45] <Mirv> robru: we manage :)
=== _salem is now known as salem_
[11:20] <morphis> rvr: ping
[11:22] <robru> ok apologies again everybody
[11:22] <robru> I triggered a few rebuilds to fix the worst ones I botched. but most I was able to save
=== salem_ is now known as _salem
=== dpm-afk is now known as dpm
[11:52] <robru> Mirv unfortunately i rebuilt silo 57 so you'll need to republish after it builds
=== _salem is now known as salem_
[12:04] <tvoss> sil2100, https://requests.ci-train.ubuntu.com/#/ticket/635 is good to go from my pov
=== xavigarcia is now known as xavigarcia_lunch
[12:18] <sil2100> tvoss: will be publishing in a minute
[12:18] <sil2100> Thanks
[12:18] <tvoss> sil2100, thank you
[12:18] <tvoss> greyback_, we can land to vivid and xenial again for platform api
[12:19] <greyback_> tvoss: sweet
[12:24] <dbarth_> quick heads up for QA: silo 60 has a proper test plan now; also silo 58 MP's are approved now, ie should be unblocked in Trello
[12:25] <sil2100> tvoss: eh, ok, had to rebuild platform-api in the silo again to make the train happy, no worries will publish instantly once it finishes
[12:25] <jibel> dbarth_, 58 unblocked and you can mark 60 ready for qa if it is
[12:27] <Mirv> robru: oh no :( I wonder if QA will want to retest then.
[12:27] <Mirv> jibel: 057 was rebuilt, do you want to retest it?
[12:28] <Mirv> content-hub/ubuntu-system-settings
[12:28] <Mirv> robru: on the other hand, nice to use the train for publishing it
[12:30] <jibel> Mirv, rebuilt with same MPs?
[12:30] <robru> Mirv jibel: it would only need the quickest of smoketests
[12:31] <robru> jibel, yes
[12:31] <jibel> robru, Mirv , k, I'll make sure it is still working
[12:31] <jibel> moving back to ready for qa
[12:32] <sil2100> brb
[12:36] <Mirv> jibel: thanks
[12:39] <jibel> Mirv, silo 57 has been published already?
[12:42] <Mirv> jibel: once, yes, manually, but robru rebuilt it after that
[12:42] <Mirv> jibel: so the merges wouldn't merge correct things anymore
=== boiko_ is now known as boiko
[12:45] <boiko> Mirv: I am trying to install messaging-app-autopilot on the device, but it says some of the dependencies can't be installed, did something change wrt apt-get on the device?
[12:45] <boiko> Mirv: for instance, there was a new address-book-app version available in the overlay ppa, but apt-get dist-upgrade won't pick it for upgrading
[12:46] <Mirv> boiko: no, there shouldn't be a problem installing messaging-app-autopilot. but if you're testing a silo you need to pin it higher than overlay
[12:46] <Mirv> boiko: https://wiki.ubuntu.com/LandingTeam/SiloTestingGuidelines#Install_silos_with_overlay_PPA_enabled
[12:46] <boiko> Mirv: right, but citrain device-upgrade does that already, right?
[12:47] <Mirv> boiko: yes, it should do that, you can check by looking at the contents of /etc/apt/preferences.d
[12:47] <boiko> Mirv: any idea why apt-get dist-upgrade is not picking up newer versions of some packages?
[12:51] <jibel> Mirv, 57 is definitely fine
[12:52] <Mirv> jibel: thanks!
[12:53] <Mirv> I'll wait for the delayed arm64 builds to finish, then it's again ready
[12:53] <Mirv> boiko: not really, but better double-check the contents of those pinning files and see that the silo pin number is higher than the overlay's
[12:54] <jibel> boiko, apt-cache policy <package> can give you a clue about the pin priority and why some versions are preferred
=== pstolowski is now known as pstolowski|lunch
=== alan_g is now known as alan_g|lunch
[13:03] <tvoss> sil2100, thx
[13:04] <boiko> jibel: right, I was using silo 52 (which only contains messaging-app), and it was not picking up a newer address-book-app (needed for the autopilot package), but now I am doing the opposite: installing first all autopilot packages, then running device-upgrade
=== xavigarcia_lunch is now known as xavigarcia
[13:22] <abeato> sil2100, hey, have you noticed that /etc/apt/sources.list.d/extra-ppas.list does not include a "deb-src" line?
[13:22] <abeato> sil2100, that creates confusion when doing build-deps for packages in the overlay
[13:22] <abeato> jhodapp, ^^
[13:25] <jhodapp> sil2100, indeed, we reached an instance with media-hub where we added a build-dep, but each time you do an apt-get build-dep media-hub, this latest dep doesn't get installed because of what abeato mentioned
[13:45] <Mirv> tvoss: silo 21 has also code changes compared to vivid overlay: https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/267/artifact/platform-api_vivid_content.diff
[13:46] <Mirv> a couple of ? true : false + a couple of const additions
=== alan_g|lunch is now known as alan_g
=== pstolowski|lunch is now known as pstolowski
=== chihchun is now known as chihchun_afk
[14:28] <dobey> trainguards: hi, can someone hit retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+build/8337847 please?
[14:29] <Mirv> dobey: done
[14:29] <dobey> Mirv: thanks
=== charles_ is now known as charles
[15:33] <tvoss> Mirv, I'm confused :)
[15:40] <dobey> Mirv: still here?
[15:45] <rvr> renatu: Mirv: Approving silo 39
[15:47] <renatu> rvr, nice, thanks
[15:49] <Saviq> robru, uh oh? https://requests.ci-train.ubuntu.com/#/ticket/690
[15:49] <Saviq> or maybe that error is just misleading...
[16:39] <camako_> fginther, any plans to convert 'wily' jobs for mir to 'xenial' in CI?
[17:21] <fginther> camako_, There was no mass conversion of projects from wily to xenial for this cycle as it no longer makes sense for many projects. If you have projects that you would like to be updated to xenial, please just send cihelp a notification or email as you've done.
[17:22] <fginther> camako_, is this for lp:mir only?
[17:22] <fginther> camako_, I need to step out, but will follow up if necessary when I return
[17:46] <camako_> fginther, Thanks. I saw your email and made a request to the list. Yes this is for lp:mir.
[17:49] <dobey> trainguards: hi, can we land silo 15 without waiting for a successful ppc64el build? it's phone only for now, and golang is still not nice on that arch
[18:00] <robru> dobey: fine by me but i can't publish, you'll need a core dev to copy the packages manually. Maybe sil2100
[18:02] <robru> dobey, actually that'll just get stuck in proposed, you'll need a release team member to help you
[18:06] <dobey> robru: i guess we can get Mirv to do it in the morning, since he's the qt person? or it'll still need a release team member for some reason?
[18:06] <dobey> i guess it'll just need someone to ack the NEWs?
[18:14] <jibel> and with these the queue is almost empty
[18:14] <jibel> thanks alesage rvr
[18:14] <robru> dobey, is this package never released before? If so is fine, if not you need release team to ack the arch regression
[18:15] <alesage> jibel but of course
[18:16] <dobey> robru: the qtpurchasing was only released in the stable-phone-ovleray ppa for vivid so far, not in the ubuntu archive
[18:20] <robru> dobey, silo 15 appears to be targeted at xenial, vivid has nothing to do with that
[18:24] <robru> dobey, indeed pay-service has been released in xenial and has packages built for ppc64el so this represents a regression and will need release team to ack, it's out of my hands
[18:24] <dobey> ok
[18:25] <robru> dobey, at purchasing is fine to publish though
[18:25] <dobey> right, i was just saying that qtpurchasing is new here, and onl exists in the overlay ppa for vivid. i wasn't saying this is meant to go into vivid
[18:26] <robru> dobey but your silo targets xenial?
[18:26] <dobey> robru: yes, this is to get the changes into xenial that we've already landed in vivid overlay
[18:26] <robru> Right
[18:28] <dobey> kenvandine: hey, ^^ can you do what is necessary to get silo 15 published to xenial? and i guess we can ping slangasek maybe to ack the 'regression' of ppc64el not building for pay-service there?
[18:30] <kenvandine> dobey, sure, but if you are getting an ack from slangasek might be best just to have him publish it
[18:30]  * kenvandine doesn't want to get hunted down over that next week :)
[18:30] <dobey> true i guess
[18:30] <dobey> slangasek: can you do that please? :)
=== joc_ is now known as joc|away
[18:42] <robru> Saviq, the "not in ppa" error? that means there was a local build that failed to upload, silo is in a bad state and needs rebuild
=== plars is now known as plars-holiday
[18:56] <Saviq> robru, no, it was a File not found exception, with two qtmir-gles bits in its path
[18:56] <Saviq> robru, I've seen it again when there were conflicts, it was complaining about a file not found .../qtmir-gles/qtmir-gles
[18:56] <robru> Saviq, I just pushed a fix for that in one spot, can you link me to the error? I didn't see it
[18:57] <Saviq> robru, it's gone by now, it got cleared when another build job ran
[18:57] <robru> Saviq, yeah but which silo? i can dig up the log and confirm my fix in another silo also fixes this
[18:57] <Saviq> robru, silo 5
[18:57] <Saviq> req 690
[18:58] <Saviq> robru, at least the build job logs don't show that err
[18:58] <robru> Saviq, oh yeah, that's the same one I fixed. fix should hit production in 20
[18:58] <Saviq> ack
[18:59] <robru> Saviq in this case it came from the status updater job, if you click 'show audit log' you can scroll through and see the error and get a link to the log
[18:59] <Saviq> robru, the build job finishes now as soon as the packages are uploaded, right? so it doesn't wait for the builds?
[18:59] <robru> Saviq, correct, the build job recently changed to not watch the PPA, diff immediately after uploads are successful. there's now a new job that watches the PPA and updates the status, it runs automatically every 10 minutes, forever (so basically now train is *always* watching
[19:00] <Saviq> ack
[19:00] <robru> Saviq, this change helps catch things like new commits on MPs or new uploads in the archive, etc. so problems are discovered sooner rather than being surprises at publish time.
[19:01] <Saviq> that's nice also because now I don't need to cancel jobs in case I need to run the build jobs in quick succession (for different packages, when waiting for some changes)
[19:01] <Saviq> robru, ack, perfect
[19:01] <robru> Saviq, oh cool, I hadn't even thought of that benefit, nice ;-)
[19:02] <robru> Saviq, only problem is that now the status job pings all status changes every 10 minutes, so if your build takes a long time you'll get pinged about it every 10 minutes. I should fix that to only ping if there's a failure or something
[19:04] <Saviq> robru, I don't get pings from queuebot for some reason anyway (I mean I don't get highlights), so meh ;)
[19:04] <Saviq> gtg
[19:35] <dobey> what's the best way to get QA to test a click package these days, since bileto doesn't have a way to make such things be "landed" when they're done?
[19:36] <salem_> rvr, hey, when you have some time, could you check if the following MR fixes the ringtone issue with your bluetooth speaker? https://code.launchpad.net/~tiagosh/telepathy-ofono/fix-1519007/+merge/278451
[19:36] <salem_> rvr, you just need to install the package that jenkins built and reboot.
[19:53] <robru> dobey, i believe QA likes to find them in bileto. marking non-silo things as 'landed' is on my todo list
[19:53] <dobey> ok
=== dpm is now known as dpm-afk
[20:43] <slangasek> dobey: unless this regression in pay-service is a deliberate disabling of the package on this architecture, I would not sign off on this.  If it is a deliberate disabling, then someone needs to start at the top of the stack and disable packages for ppc64el first, otherwise you're just creating an uninstallable/unbuildable pile on ppc64el
[20:47] <slangasek> dobey: and has this ppc64el build failure been reported as a bug against binutils?
=== salem_ is now known as _salem
[21:00] <slangasek> dobey: actually, I guess this may be a golang issue rather than a binutils one;
[21:00] <slangasek> dobey: so mwhudson (and a bug against golang) would be a good idea here
[21:01] <dobey> slangasek: yeah, i pinged mwhdson about it. it's a bug already reported/fixed upstream apparently. he's saying we should use gccgo on ppc64el, or not build at all there.
[21:01] <dobey> slangasek: i'd more likely say that previous builds on ppc64el of pay-service were not intentional. :)
[21:02] <slangasek> dobey: unity8 and unity-scope-click both build-depend on libpay2-dev; you don't get to say that's "unintentional" without taking responsibility for unwinding it
[21:02] <slangasek> dobey: it looks like the go code is only in pay-service; does it make sense to build libpay2 on architectures that don't have pay-service? or should the reverse-dependencies have their libpay2-dev build-dep architecture-qualified?
[21:03] <dobey> no, libpay2 is just a client lib to talk to pay-service
[21:03] <slangasek> and pay-service is always a local service?
[21:04] <dobey> yes, pay-service is a dbus service which talks to the remote servers
[21:05] <dobey> hmm, i'll make a quick branch to build with gccgo on ppc64el then
[21:05] <dobey> since that's what mwhudson is saying to do
[21:06] <slangasek> dobey: ok. lxd should be a good example of this.  I think it's equally valid to drop the build-dep on ppc64el fwiw, but of course that means you get to make a unity8 landing your problem
[21:25] <cyphermox> ^ wow, it now detects the state from the PPA build records? :)
[21:26] <robru> cyphermox: Big Train is always watching ;-)
[21:27] <cyphermox> that's pretty cool, less clickety-clicking.
[21:28] <robru> cyphermox, you still need to run the build job to generate the diff, but at least only once at the end instead of every upload
[21:28] <cyphermox> right
[21:37] <slangasek> dobey: fwiw a quick test with substituting gccgo in for golang got me a successful pay-service package build on ppc64el/xenial
[21:38] <dobey> slangasek: yeah, it's already built in the silo
[21:38] <dobey> someone needs to hit retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+build/8271662 now
[21:38] <slangasek> dobey: ok.  and btw, lintian points out a few problems with this package...
[21:38] <slangasek> E: pay-service: depends-on-essential-package-without-using-version depends: sysvinit-utils
[21:38] <slangasek> E: pay-service: depends-on-essential-package-without-using-version recommends: perl-base
[21:38] <slangasek> dobey: done
[21:40] <dobey> depending on essential packages without a version requirement is an error?
[21:42] <dobey> oh right, have to way for stuff to get fully published before rebuilding
[21:45] <slangasek> dobey: yes, it is; because the essential functionality is guaranteed to be present, but the package names may change, so a dependency is both unnecessary and potentially harmful to future upgrade calculation
[21:47] <dobey> slangasek: how should one depend on a binary that's shipped in those packages then? i don't want stuff to stop working because the package name changed, and the binary we need is no longer in the essential packages
[21:47] <slangasek> dobey: we never remove binaries from Essential
[21:48] <slangasek> dobey: although - sysvinit-utils is not essential in Ubuntu, so that's a buggy lintian warning.  But perl will always be in essential
[21:56] <dobey> slangasek: so drop the perl and ignore the sysvinit-utils lintian?
[22:03] <robru> Oh god why
[22:06] <robru> kenvandine, do you know what caused that error? New one on me
[22:06] <kenvandine> i canceled a build
[22:07] <josepht> nuclearbob, jibel: are you guys still converned with bootspeed testing?
[22:07] <kenvandine> because i pushed a new revision
[22:07] <robru> Surprised to see oserror in python3 code
[22:07] <kenvandine> robru, then i started another build quickly
[22:07] <kenvandine> i think it hadn't finished cleaning up from the previous job
[22:07] <kenvandine> i waited a minute and it worked
[22:07] <robru> kenvandine huh buy there a signal handler to exit cleanly when jobs are cancelled
[22:08] <robru> Ooooh
[22:08] <kenvandine> i was just to fast :)
[22:10] <robru> kenvandine, really bizarre because the cleanup doesn't delete that dir, no idea why it would error like that
[22:10] <kenvandine> ah... well i dunno then
[22:10] <robru> A mystery for the ages
[22:16] <slangasek> dobey: yeah - drop perl-base, ignore sysvinit-utils
[22:25] <robru> cyphermox, ^ 'Diff missing' implies 'Successfully built', just run the build job to make the diff when you're ready
[23:26] <nuclearbob> josepht: it's on the list of things to get re-enabled this cycle so we can have good data for the lts
[23:33] <dobey> slangasek: ok, i added an MP for dropping perl-base, and it's rebuilding now. will have to chase down reviews for the two new MPs in the morning though, since it's past my EOD and everyone else too that was working on these bits
[23:33] <dobey> slangasek: thanks for the help
[23:34] <dobey> and have a good evening :)