[03:06] <robru> oh lol
[03:06] <robru> that should have been in staging...
[09:21] <koza> sil2100, good morning
[09:22] <koza> sil2100, I need your [core dev] help in publishing https://requests.ci-train.ubuntu.com/#/ticket/1124
[09:22] <sil2100> koza: on it!
[09:22] <koza> sil2100, thank you!
[09:25] <sil2100> koza: approved, +1 for the patch description
[09:25] <sil2100> :)
[09:25] <jamesh> Is there any reason my mediascanner2 silo (ticket 1120) isn't moving to the "ready for testing" column?  I just noticed that the thumbnailer silo that was added yesterday got moved up ahead of it.
[09:26] <koza> sil2100, thanks
[10:05] <robru> jamesh: dunno about the trello board (ask jibel) but on the bileto side it's been marked ready for QA since the 17th.
[10:07] <jibel> jamesh, it is not targeted to OTA10. We are landing OTA10 bug fixes in priority
[10:07] <jibel> jamesh, please escalate the bug if it has to be fixed in this release
[10:10] <jamesh> jibel: I was just surprised, since I didn't think the thumbnailer silo had been explicitly targeted at OTA10 either
[10:12] <jamesh> If you targeted it to OTA10 because of https://bugs.launchpad.net/zhongshan/+bug/1554867, then it'd probably make sense to do the mediascanner silo too, since it is also mentioned there.
[10:13] <jibel> jamesh, silo 3? right, it's a critical issue for turbo
[10:16] <jibel> jamesh, all right, it is not obvious from the changelog or the bug attached. Please next time add a reference to the bug it fixes in the changelog.
[10:17] <jibel> or link the MP to the bug report
[10:20] <Saviq> robru, erm, sleep?
[11:24] <oSoMoN> trainguards: can someone help me understand why the automated signoff failed on https://requests.ci-train.ubuntu.com/#/ticket/1122 ?
[11:25] <oSoMoN> according to https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-021/excuses.html there’s an issue with "old binaries", I’m guessing that’s because the silo originally contained a merge request that changed the packaging, but I removed it and rebuilt it since then
[11:25] <Mirv> oSoMoN: probably undeleted superseded sources in the PPA, looking
[11:25] <Mirv> oSoMoN: yep, that was it, changed packages between builds in which case that happens
[11:26] <Mirv> oSoMoN: fixed, now we just wait for the next update which maybe unfortunately only in 50mins or so
[11:30] <oSoMoN> Mirv, ok, thanks
[11:31] <oSoMoN> Mirv, so the automated signoff tests are going to be re-run, right? no need for me to change the lander signoff status again?
[11:31] <Mirv> oSoMoN: yes. switching the switch doesn't help anything.
[11:31] <Mirv> I think people tend to do that even though it actually changes nothing except possibly causes more delays.
[11:32] <Mirv> it doesn't restart them in any way
[11:47] <sil2100> abeato: hey! I just commented on https://code.launchpad.net/~phablet-team/ubuntu/vivid/initramfs-tools-ubuntu-touch/support-adb-lollipop/+merge/288917
[11:49] <abeato> sil2100, hi, actually I had some discussion with ogra_ and ondra about this, the conclusion was that we should actually remove that panic script from the ramdisk and create a special ramdisk for development purposes
[11:50] <abeato> sil2100, I just forgot about the MP, should have removed it :)
[11:50] <ogra_> abeato, well, actually i would turn the panic script into an "echo .... sleep ... reboot recovery" sequence
[11:51] <abeato> well, that
[11:51] <ogra_> i.e. ecvho the reason why we fail, show that for a few seconds and reboot into a safe state
[12:00] <sil2100> abeato: ;)
[12:15] <jgdx> jibel, silo 61 is in two columns on the board (ready and passed), and the ticket says "qa ready". I'm a bit confused—is there anything I need do?
[12:21] <jibel> jgdx, I'm confused too. Apparently the silo has been rebuilt before being published
[12:23] <jgdx> jibel, seems Saviq built it yesterday at 4, but it hasn't been built today according to https://ci-train.ubuntu.com/job/ubuntu-landing-061-1-build/build
[12:24] <Saviq> jgdx, jibel, I'm afraid it was two concurrent landings of ubuntu-settings-components
[12:25] <Saviq> https://requests.ci-train.ubuntu.com/#/ticket/1115 landed yesterday and we had to rebuild https://requests.ci-train.ubuntu.com/#/ticket/1143
[12:55] <jgdx> jibel, Saviq: should that impact its merge/publish though?
[12:55] <Saviq> jgdx, if another one landed before it - yes
[12:56] <jgdx> Saviq, just a rebuild or more things?
[12:56] <Saviq> jgdx, since that went onto trunk, so yours needed a rebuild, and that means QA needs to re-ack
[12:57] <jgdx> Saviq, but they acked today I thought
[12:57] <jgdx> post build
[12:57] <Saviq> jgdx, a rebuild + sanity check usually enough
[12:57] <Saviq> jgdx, no, look at audit logs
[12:57] <Saviq> 2016-03-21 17:46:31 +0100 (ci-train-bot) Needs rebuild due to new commits (ubuntu-settings-components/xenial).
[12:57] <Saviq> Successfully built (ubuntu-settings-components/vivid).
[12:57] <Saviq> 2016-03-21 17:45:42 +0100 (jibel) qa_signoff: Approved
[12:58] <Saviq> just a minute after it got QA Ack, it needed a rebuild
[12:58] <jgdx> Saviq, kay, that's unfortunate.
[13:00] <jgdx> jibel, so it needs a re-ack from QA. I wonder if you could sort out the cards, i.e. move [1] to "Needs qa signoff" or just delete it in favor of [2]? [1] https://trello.com/c/RZOqXJzt/2946-1143-ubuntu-landing-061-ubuntu-settings-components-jgdx-dednick [2] https://trello.com/c/ulzB1yx7/2954-1143-ubuntu-landing-061-ubuntu-settings-components-jgdx-dednick
[13:04] <jibel> jgdx, reapproved
[13:04] <jgdx> jibel, thx
[13:06] <Mirv> publishing, too
[14:36] <jgdx> Mirv, hey, did silo61 publishing fail or get stuck?
[14:37] <Mirv> jgdx: seems to have worked fine?
[14:38] <jgdx> Mirv, i thought it would automagically merge as well.
[14:41] <Mirv> jgdx: it never does before it migrates from proposed to release pocket in xenial
[14:42] <Mirv> jgdx: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-settings-components
[14:42] <jgdx> Mirv, okay, thanks.
[14:47] <sil2100> It should migrate soon, it's not seeded in any desktop images so it shouldn't be affected by the archive freeze
[14:58] <salem_> trainguards hi, can anyone trigger a rebuild of telepathy-ofono/xenial/arm64 on silo 42?
[14:59] <sil2100> salem_: on it
[14:59] <salem_> sil2100, thank you!
[15:34] <oSoMoN> trainguards: can someone help me understand https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-021/excuses.html ? those tests have been running for 3 hours just to end in a timeout (apparently), it’s getting incredibly complicated to just land a silo
[15:47] <sil2100> hmmm
[15:59] <oSoMoN> sil2100, seen my request for help earlier?
[15:59] <sil2100> Yeah, looking at it, can't see any reason for that
[16:00] <sil2100> Did you try running those locally somewhere against the new webbrowser-app?
[16:00] <sil2100> Not much I can do besides re-running sadly, don't have enough knowledge/permissions I suppose
[16:23] <oSoMoN> sil2100, ok, can only the failing architecture be re-run? I’ve tried to do that myself, but I get an error message: "You submitted an invalid request: Package unity8 does not have any test results"
[16:54] <salem_> fginther, hi, do you know how to add an external repository to sources.list on jenkins? Or do you know where to get this info? I tried to search for some sort of parameter to do that but no luck so far.
[17:33] <fginther> salem_, if you're using chroots or pbuilderjenkins, you can create a hook script to add the repository prior to the build stage
[17:34] <fginther> salem_, pbuildjenkins has some options for specifying a custom hook directory which can be used for one-offs
[17:42] <oSoMoN> trainguards: has the failing autopkgtests been re-triggered for silo 21? If not, can you please do that for me?
[17:43] <salem_> fginther, thank you!
[17:51] <robru> oSoMoN: I actually can't, sorry, you need somebody with upload rights on the package
[18:01] <john-mcaleely> jibel, so, i don't see how to mark this request 'ready for qa'
[18:01] <john-mcaleely> https://requests.ci-train.ubuntu.com/#/ticket/1165
[18:01] <john-mcaleely> help welcome
[18:02] <john-mcaleely> robru, ^ it seems I'm expected to 'assign' this request to a silo next
[18:02] <jibel> john-mcaleely, done
[18:02] <john-mcaleely> jibel, robru thank you
[18:02] <jibel> john-mcaleely, no it's fine like this
[18:02] <john-mcaleely> cool
[18:04] <robru> john-mcaleely: assigning is for people who need a PPA to build debs in. I haven't had time to make a sensible workflow for you non-PPA weirdos.
[18:04] <john-mcaleely> robru, understood. long may I remain a weirdo :-)
[18:05] <robru> heh
[18:35] <oSoMoN> sil2100, can you help me re-trigger the tests for the regression at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-021/excuses.html ?
[18:53] <oSoMoN> nevermind, I reset the status of lander signoff, hopefully this will trigger a full autopkgtests run (and hopefully this one will pass)
[19:03] <oSoMoN> trainguards: I can’t figure out for the life of me how to get the automated signoff to re-run on silo 21, can you please help me? clicking the little re-run icon on https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-021/excuses.html gets me an error message ("You submitted an invalid request: Package unity8 does not have any test results"), and resetting the lander signoff status in bileto doesn’t work either
[19:03] <oSoMoN> I’d really like to hand that silo off to QA
[19:20] <robru> oSoMoN: just ask jibel to add it to the queue I guess?
[19:21] <robru> oSoMoN: britney runs on average every hour. if you "reset the lander signoff" all you're doing is creating a race condition in which if britney runs at the exact second you disable your lander signoff, you delay the run by a further hour.
[19:22] <robru> oSoMoN: current britney run time is 45 minutes.
[19:42] <oSoMoN> jibel, can silo 21 be added to the "Need QA signoff queue" ? there’s one autopkgtest failure (see https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-021/excuses.html) but it seems unrelated, the tests timed out
[19:49] <Mirv> oSoMoN: yeah it's bug #1544917. I'd welcome a true "reset britney results" emergency button for that and other problem cases, forcing qa to manually override is not nice either.
[19:49] <Mirv> but asking qa nicely tends to work for ota critical silos.
[20:03] <Saviq> robru, hey, is there anything we can do about the train complaining about the shadow package being in xenial already https://requests.ci-train.ubuntu.com/#/ticket/1138 ?
[20:04] <robru> Saviq: what? "burned version number" means the version number in the silo already exists in xenial but the packages have different contents.
[20:05] <Saviq> robru, I'm afraid that's possible, mterry, I think, srccopied it instead of bincopy
[20:05] <Saviq> robru, anything can be done, other than going to a different silo and bincopying?
[20:05] <robru> Saviq: no, that test is explicitely a source check. they have different SOURCE contents.
[20:05] <Saviq> that'd be very weird...
[20:06] <robru> hmmm but the diff is empty
[20:07] <Saviq> robru, yeah, and it was copied from another silo is all
[20:07] <Saviq> except it's not there ¿?
[20:08] <robru> Saviq: not sure what to tell you: http://bazaar.launchpad.net/+branch/cupstream2distro/view/head:/cupstream2distro/archive.py#L217 either one of them is missing a .changes file or they have different changelog contents
[20:09] <Saviq> robru, and the PPA won't accept the same version with different contents, right?
[20:09] <Saviq> if you bincopied from archive
[20:09] <Saviq> and if you delete, train will complain ;P
[20:10] <robru> Saviq: why is it needed in the silo if it's already in xenial? just delete it?
[20:10] <Saviq> robru, it's not in vivid yet
[20:10] <Saviq> robru, the silo us dual, so I thought there had to be packages for both?
[20:10] <Saviq> robru, if it can be deleted and train will be happy, all the better
[20:11] <robru> Saviq: you're right that dual requires both. I guess I can copy the vivid one to vivid overlay ppa directly and then delete both
[20:12] <robru> Saviq: indeed the changes don't match: http://launchpadlibrarian.net/245141347/shadow_4.2-3.1ubuntu4_source.changes https://launchpadlibrarian.net/247561703/shadow_4.2-3.1ubuntu4_source.changes
[20:12] <Saviq> robru, ok, we'll do that when it's time for publishing, thanks
[20:12] <robru> I'm not sure why the diff is null
[20:13] <Saviq> robru, interesting, mterry must've rebuilt the source and uploaded to the silo
[20:13] <Saviq> it might just be that it compressed differently
[20:13] <robru> Saviq: I guess so, even the debian.tar has a different size
[20:13] <Saviq> yeah exactly
[20:14] <robru> Saviq: lol are you saying .xz is not a deterministic compression algorithm?
[20:14] <Saviq> robru, is any compression algorithm deterministic?
[20:14] <Saviq> I mean, on purpose?
[20:15] <robru> Saviq: I would hope that the lossless ones are!
[20:15] <Saviq> otoh it might just be as little as file props that results in the archive actually having different contents, but not when you compare the file contents
[20:15] <robru> Saviq: that sounds more realistic.
[20:15] <Saviq> robru, but why, you care about the uncompressed data to be the same, not about the compressed stream
[20:16] <Saviq> robru, I would be surprised if compressing the same file twice gives you the same compressed stream every time
[20:16] <Saviq> it's not a hashing algorithm :)
[20:16] <robru> Saviq: if you compress the same file twice and get two different results, how can you be sure they'll decompress into the same original? differences make sense in something lossy like a jpeg but not in something lossless like a tarball.
[20:17] <Saviq> robru, disagree, compression algos adapt to what they encounter, I don't think there's a guarantee they'll take the same path every time :)
[20:18] <Saviq> I mean, it might be the case by chance, but there's no point in guaranteeing that IMO
[20:18] <robru> Saviq: but if they produce different outputs based on identical inputs that means there's some sort of random nondeterministic element going on
[20:19] <Saviq> robru, and?
[20:19] <Saviq> as long as when you decompress again you get the same result, I see no problem
[20:19] <robru> Saviq: I just don't see how you can guarantee different compressed data sets decompressing to the same original. it's weird.
[20:20] <Saviq> robru, the compressed file has info on how it was compressed, so decomp follows that
[20:20] <robru> Saviq: I also don't understand why the algo wouldn't be deterministic. I mean, how did they write xz? "we'll compress at level 9 on tuesdays and level 8 on other days of the week"
[20:21] <robru> Saviq: I don't understand what factors other than the input data could impact the output
[20:21] <Saviq> robru, I don't know enough about those algos, but say it does things in parallel
[20:21] <Saviq> robru, it might depend on available resources
[20:22] <Saviq> I just mean I don't think they're designed to be deterministic "one way", because why
[20:22] <Saviq> easy to check ;)
[20:22] <dobey>  huh
[20:22] <robru> Saviq: ok anyway. we'll never know what mterry did there. it's a mystery for the ages... ;-)
[20:23] <Saviq> :)
[20:24] <robru> dobey: do you need help with a silo or are you just "huh"ing at this conversation?
[20:26] <robru> because I'm about to run for lunch...
[20:26] <dobey> robru: the conversation
[20:26] <robru> heh, ok
[20:26] <dobey> because we obviously need the hash to be equal every time, otherwise the build system will think the contents are different, and fail
[20:27] <robru> dobey: normally it is, but mterry did something funny when he copied it, so the hashes don't match despite the debdiff being empty.
[20:27] <dobey> weird
[20:27] <robru> dobey: like instead of using copy-package I guess he downloaded it and reuploaded it, recompressing in-between.
[20:28] <dobey> anyway, enjoy your lunch :)
[20:28] <robru> thanks, bbl