| === chihchun_afk is now known as chihchun | ||
| robru | oh lol | 03:06 |
|---|---|---|
| robru | that should have been in staging... | 03:06 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| koza | sil2100, good morning | 09:21 |
| 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:22 |
| 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:25 |
| koza | sil2100, thanks | 09:26 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| 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:05 |
| 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:07 |
| jamesh | jibel: I was just surprised, since I didn't think the thumbnailer silo had been explicitly targeted at OTA10 either | 10:10 |
| 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:12 |
| ubot5 | Error: launchpad bug 1554867 not found | 10:12 |
| jibel | jamesh, silo 3? right, it's a critical issue for turbo | 10:13 |
| 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:16 |
| jibel | or link the MP to the bug report | 10:17 |
| === chihchun is now known as chihchun_afk | ||
| Saviq | robru, erm, sleep? | 10:20 |
| === dpm_ is now known as dpm | ||
| oSoMoN | trainguards: can someone help me understand why the automated signoff failed on https://requests.ci-train.ubuntu.com/#/ticket/1122 ? | 11:24 |
| 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:25 |
| Mirv | oSoMoN: fixed, now we just wait for the next update which maybe unfortunately only in 50mins or so | 11:26 |
| oSoMoN | Mirv, ok, thanks | 11:30 |
| 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:31 |
| Mirv | it doesn't restart them in any way | 11:32 |
| 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:47 |
| === chihchun_afk is now known as chihchun | ||
| 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:49 |
| 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:50 |
| 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 | 11:51 |
| sil2100 | abeato: ;) | 12:00 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| 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:15 |
| jibel | jgdx, I'm confused too. Apparently the silo has been rebuilt before being published | 12:21 |
| 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:23 |
| Saviq | jgdx, jibel, I'm afraid it was two concurrent landings of ubuntu-settings-components | 12:24 |
| 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:25 |
| jgdx | jibel, Saviq: should that impact its merge/publish though? | 12:55 |
| Saviq | jgdx, if another one landed before it - yes | 12:55 |
| 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:56 |
| 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:57 |
| Saviq | just a minute after it got QA Ack, it needed a rebuild | 12:58 |
| jgdx | Saviq, kay, that's unfortunate. | 12:58 |
| === _salem is now known as salem_ | ||
| 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:00 |
| === alan_g is now known as alan_g|lunch | ||
| === chihchun is now known as chihchun_afk | ||
| jibel | jgdx, reapproved | 13:04 |
| jgdx | jibel, thx | 13:04 |
| Mirv | publishing, too | 13:06 |
| jgdx | Mirv, hey, did silo61 publishing fail or get stuck? | 14:36 |
| Mirv | jgdx: seems to have worked fine? | 14:37 |
| jgdx | Mirv, i thought it would automagically merge as well. | 14:38 |
| Mirv | jgdx: it never does before it migrates from proposed to release pocket in xenial | 14:41 |
| Mirv | jgdx: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-settings-components | 14:42 |
| jgdx | Mirv, okay, thanks. | 14:42 |
| sil2100 | It should migrate soon, it's not seeded in any desktop images so it shouldn't be affected by the archive freeze | 14:47 |
| salem_ | trainguards hi, can anyone trigger a rebuild of telepathy-ofono/xenial/arm64 on silo 42? | 14:58 |
| sil2100 | salem_: on it | 14:59 |
| salem_ | sil2100, thank you! | 14:59 |
| 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:34 |
| sil2100 | hmmm | 15:47 |
| oSoMoN | sil2100, seen my request for help earlier? | 15:59 |
| sil2100 | Yeah, looking at it, can't see any reason for that | 15:59 |
| 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:00 |
| 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:23 |
| === dpm is now known as dpm-afk | ||
| 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. | 16:54 |
| 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:33 |
| fginther | salem_, pbuildjenkins has some options for specifying a custom hook directory which can be used for one-offs | 17:34 |
| oSoMoN | trainguards: has the failing autopkgtests been re-triggered for silo 21? If not, can you please do that for me? | 17:42 |
| salem_ | fginther, thank you! | 17:43 |
| robru | oSoMoN: I actually can't, sorry, you need somebody with upload rights on the package | 17:51 |
| 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:01 |
| 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:02 |
| 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:04 |
| robru | heh | 18:05 |
| 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:35 |
| oSoMoN | nevermind, I reset the status of lander signoff, hopefully this will trigger a full autopkgtests run (and hopefully this one will pass) | 18:53 |
| 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:03 |
| robru | oSoMoN: just ask jibel to add it to the queue I guess? | 19:20 |
| 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:21 |
| robru | oSoMoN: current britney run time is 45 minutes. | 19:22 |
| 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:42 |
| 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 |
| ubot5 | bug 1544917 in Auto Package Testing "Retry says "does not have any test results" on reported Regressions" [Low,Triaged] https://launchpad.net/bugs/1544917 | 19:49 |
| Mirv | but asking qa nicely tends to work for ota critical silos. | 19:49 |
| 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:03 |
| robru | Saviq: what? "burned version number" means the version number in the silo already exists in xenial but the packages have different contents. | 20:04 |
| 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:05 |
| robru | hmmm but the diff is empty | 20:06 |
| Saviq | robru, yeah, and it was copied from another silo is all | 20:07 |
| Saviq | except it's not there ¿? | 20:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| Saviq | :) | 20:23 |
| robru | dobey: do you need help with a silo or are you just "huh"ing at this conversation? | 20:24 |
| 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:26 |
| 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:27 |
| dobey | anyway, enjoy your lunch :) | 20:28 |
| robru | thanks, bbl | 20:28 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!