[00:03] @pilot out [00:04] mwhudson: that didn't seem to take? :) === udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: [00:04] ah there it goes [00:04] yeah i was wondering [00:05] just slow it seems :) === jamesh_ is now known as jamesh === hikiko|off is now known as hikiko [05:56] good morning [07:28] Good morning [08:05] pitti, hey, can you please restart this with all proposed http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#ubuntu-settings-components [08:05] we're missing a Breaks: there [08:17] Saviq: done (you can't use request.cgi for unity?) [08:17] pitti, can I? [08:18] Saviq: it checks if you can upload the package -- then you can also retry its tests [08:19] pitti, I think I never had that right - and even if, would it accept all-proposed as a parameter? [08:19] Saviq: yes, &all-proposed=1 [08:19] pitti, ack, don't have the rights to upload anywy [08:20] should probably work on that [09:07] pitti, do you think indicator-location can use a newer llvm? I'm trying to remove llvm-toolchain-3.6 [09:08] LocutusOfBorg: no idea, I'm afraid [09:08] ack :) [09:12] https://bugs.launchpad.net/ubuntu/+source/indicator-location/+bug/1637128 [09:12] Launchpad bug 1637128 in indicator-location (Ubuntu) "please switch to clang-3.8 or newer" [High,New] [09:16] do you know where I can find Mirv? [09:20] LocutusOfBorg: normally here, but apparently out today [09:21] I asked a qtcreator merge from Debian with a private message, because I want to get rid of llvm-3.6 [09:22] caribou, hi, did you have time to look at clamav merge? === marcusto_ is now known as marcustomlinson === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko === Guest21645 is now known as ahasenack === ahasenack is now known as Guest91977 [13:25] oSoMoN: regarding webbrowser-app in the SRU queue for Yakkety, it seems that there are things in the diff not mentioned in the changelog with no bug reference. Is it bug 1599695 that is missing perhaps? [13:25] bug 1599695 in webbrowser-app (Ubuntu) "When running cmake from QtC on a webbrowser-app branch it fails" [High,Fix released] https://launchpad.net/bugs/1599695 [13:25] oSoMoN: it would be nice if your changelogs made it easier to locate which bits of diffs correspond to which fixes. It isn't at all clear. [13:48] pitti: ping [13:48] pitti: i have an interesting autopkgtest question for you [13:51] hey barry [13:53] barry, systemd package does boot VMs in the autopkgtest. [13:54] ok, so xnox knows the answer before barry even asked, well done :) [13:54] pitti, i am speculating =) [13:55] is the auto-import from debian working? [13:55] as for qemu-in-qemu, that works, yes [13:55] LocutusOfBorg: not yet enabled; I think it's better to land perl first, to not entangle it with even more transitions [13:56] pitti, I guess so, but I would write this in the -release topic [13:56] and probably I would transition xapian and boost before :) [13:56] xnox, can we have boost1.63 directly? or is it too much work? [13:57] they should have fixed openssl1.1, so we might save some time on the next transition [13:57] xnox: yeah, no, that's not my question :) [13:57] LocutusOfBorg, boost 1.63 is not released. [13:57] pitti: is it possible to have different restrictions for different distroseries? e.g. i needs-root for xenial but nothing newer [13:59] barry: no, sorry; a test doesn't actually have a concept of a "distro series" -- it runs in whatever apt config/environment you put it in [13:59] barry: you can emulate it by having two Test-Commands: with calling the same test script twice, and then the script runs/skips itself when it's (not) root [13:59] barry: but that does sound strange :) [14:00] barry: ISTM that this is a decision which should not be done by looking at the release, but at the actual property you need, so that it also works for backports and the like [14:00] barry, you can have multiple paragraphs in debian/tests/control. one with needs-root, the other one without. And in the test do a check on distro-series, and e.g. exit 0 if run as root..... [14:00] pitti: i guess the script could test `lsb_release -cs` or some such [14:00] barry: I'd strongly advise to not do that [14:01] xnox, interesting, the watch file from debian/ picks it up https://qa.debian.org/developer.php?login=smr@debian.org [14:01] barry, check for the version number of tools that you need to run with root/without root. [14:01] capabilities, etc. [14:01] barry: you can also always start as root, and drop privs to $AUTOPKGTEST_NORMAL_USER if you don't want them [14:01] xnox: that's what i was thinking but it might not be a good idea. i know the code is dtrt. iow, this is a fallback feature [14:02] LocutusOfBorg, up until two weeks ago, we did not have ability to look into subfolders with sourceforge uscan redirector. And hightly builds in boost, use next release final version number. [14:02] picked up by https://sourceforge.net/projects/boost/files/boost/snapshots/develop/ [14:02] yes indeed sorry for the noise [14:02] pitti: i really just want to emulate (or maybe actually execute) sudo when in xenial as normal user. does $AUTOPKGTEST_NORMAL_USER require a password to sudo? [14:03] LocutusOfBorg, read debian-devel =) [14:03] xnox, all that spam? :) [14:03] barry: that really depends on the testbed; you can of course drop something into sudoers.d/ yourself if you want to guarantee it (but then add breaks-testbed) [14:04] pitti: i mostly care about a.c.c, but that's not a bad idea [14:04] or maybe the least bad idea ;) [14:05] a.u.c [14:05] barry: in cloud instances you have passwordless sudo, in lxc you don't [14:05] barry: (that's just how it comes by default) [14:05] pitti: so something i have to arrange to be consistent [14:05] which is okay [14:06] barry: but e. g. I sometimes run tests in my sid VM which doesn't have sudo at all (not something you care about, but I don't want to make that kind of assumptions in autopkgtest) [14:06] pitti: yep, that's entirely reasonable [14:07] pitti: thanks, that gives me food for thought [14:49] Laney: in your nautilus SRU, AFAICT some UTF-8 in debian/patches/0003-nautilus-canvas-Don-t-lay-down-desktop-icons-if-we-h.patch is unintentionally clobbered. [14:51] “ In the ‘C’ locale, the value of decimal_point is ‘.’, and the value of mon_decimal_point is ‘’.” [14:51] That can’t be right, can it? [14:52] An empty string as a decimal point [14:52] (This from ) [14:55] rbasak: Shucks, I wonder how that happened as I didn't intentionally touch that file [14:56] rbasak: jbicha broke it [14:56] jbicha: I could have pushed my commit if you'd asked, probably just forgot [14:56] Laney: sorry, feel free to overwrite [14:57] That does look like a documentation bug to me. [14:57] I already pushed another revision [14:57] A documentation bug? [14:57] That was in response to mpt. [14:57] Sorry, I should give more context. [14:57] Oops. [14:57] Laney: sorry, I should give more context. :-) [14:57] heh [14:57] rbasak: I fixed it in bzr, can't be bothered to reupload though unless it gets rejected :-) [14:57] Thanks for noticing! [15:00] Laney: thank you for the excellent SRU paperwork :) [15:02] wow protoc is broken https://launchpadlibrarian.net/291064124/buildlog_ubuntu-zesty-amd64.gobgp_1.12-1_BUILDING.txt.gz [15:02] probably in yakkety too [15:03] I wonder if you can enforce quilt options in the source package [15:03] (-p ab reprezent) [15:19] Laney: just patch quilt to change the defaults for everything! ;) [15:20] the xnox method [15:20] I think it was him that was advocating this last week [15:20] yes [15:20] I would appreciate some way of developers using better quilt settings by default. [15:20] is launchpad having an issue generating diffs? [15:21] I would like if quilt's patches by default would look more like git's format [15:22] rbasak, yeah, looks like it [15:22] "-p ab --no-timestamps --no-index" is what I used, from https://wiki.debian.org/UsingQuilt [15:23] It's the extra diff noise created by no-op quilt refreshes with the default settings that bothers me the most. [15:23] jbicha, GNU patch knows how to apply a few git things; GNU diff does not generate git-format patches; however i wonder if there are low level commands that git exposes such that quilt could use git for diff generation. [15:23] Makes reviewing take longer because I keep having to look up and down past the noise. [15:26] yeah, the fact that Step 1 on the wiki is to set those options seems an argument that they should just be made the default [15:27] There are uses for quilt outside Debian packaging however. [15:27] We want them the default for packaging uses, but others may want other things for the default when not doing packaging, and they use the package too. [15:27] (presumably) [15:29] make those users set a ~/.quiltrc then! since quilt can't be all that popular outside packaging [15:30] rbasak, i'm all for shipping a sensible /etc/quiltrc or what not. [15:31] File a bug to change the default upstream? Or in Debian? [15:41] Is someone about to advise me on a grub configuration to boot an older kernel? http://pastebin.ubuntu.com/23388775/ [15:42] rbasak: xnox ^ [15:45] sinzui: sorry, all I know is that I've used http://askubuntu.com/a/216420/7808 in the past and it worked for me. You seem to have done it correctly, AFAICT. [15:45] rbasak: Small consolation that I read the docs right [15:46] sinzui: oh, is this on EC2 or something like that? [15:46] In that case, grub-legacy-ec2 is relevant. [15:46] If the host is using pygrub or similar. [15:46] rbasak: no, a ppc64el guest on a canonical network [15:47] I don't know if that's also special somehow. [15:48] smoser: ^ any advice on setting default kernel in a ppc64el guest? [15:49] Oh, I think I need to use the uuid version [15:49] i wrote this somewher.e.. [15:49] where did i write it [15:51] sinzui, ubuntu always boots last configured kernel, so you can reinstall/reconfigure the kernel you want to boot and it will boot that by default. [15:51] .... until next upgrade [15:52] sinzui, if you don't want to move kernel, and don't want to receive security updates; you can remove the metapackage linux-generic-image or whatever the metapackage you use. [15:52] xnox: yeah, that was the stragey chosen a few months ago. Then I got the problem and want to keep the machine relaibly running [15:53] i'm lokign, i wrote this dow. i sear. [16:02] pitti: (from #-meeting) b1 calls promote-to-release [16:03] Laney: thanks for the hint [16:04] Laney: so that's what we'll need to teach about/parameterize for landing to -updates instead of -release [16:04] Shouldn't be too hard to poke -updates in there [16:05] sinzui, https://gist.github.com/smoser/93ba44ed30481df12577#file-boot-kernel is what i have had. [16:07] and there is a link in that file to https://statusq.org/archives/2012/10/24/4584/ [16:07] oh, fudge. [16:07] sinzui, though, on power8, grub doesnt actually load the kernel [16:07] petitboot does [16:08] so i do not know if such mechanisms would work. [16:08] smoser: oh! that explains a lot [16:08] smoser: so i think at least some of the backoff you are doing would be specific to the environment; e.g., if `git fetch` fails, retry via a wrapper script to the importer? [16:08] it may be a bug in petitboot if it does not. [16:08] nacc, i'm not working on backoff, just suggested that we shoudl probably do that. [16:09] smoser: right, but i mean in at least some cases, it's not an importer issue, but a how-you-run-the-importer (or where) issue [16:10] smoser: should the grub package even be installed in that case? [16:10] Seems a bit misleading. [16:11] petitboot is only the bootloader in powernv mode [16:16] nacc, i'm not convinced that i have a flakey network [16:16] rbasak, sorry if it’s not clear. the changelog mentions two bugs, which correspond to the two revisions in the SRU branch: https://code.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/+merge/308487 [16:16] until someone shows me other wise. [16:16] ie, if reliability is an issue on the launchpad api side,then we shoudl fix better [16:16] rbasak, https://bazaar.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/revision/1543 fixes https://launchpad.net/bugs/1632620 and https://bazaar.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/revision/1544 fixes https://launchpad.net/bugs/1633439 [16:16] Launchpad bug 1632620 in webbrowser-app (Ubuntu Yakkety) "No audio from webbrowser-app in 16.10" [Undecided,Confirmed] [16:16] Launchpad bug 1633439 in webbrowser-app (Ubuntu Yakkety) "FTBFS on yakkety arm64: Invalid chromium version: ''" [Undecided,New] [16:16] rbasak, grub is installed because it is what writes the files that petitboot reads [16:17] petitboot parses grub2 config files [16:17] smoser: ah [16:17] to some extent. [16:17] smoser: i ran the exact command you ran on my machine at home and it worked without any exception [16:17] i'm not sure whether or not it works for the "set default" and stuff. [16:17] smoser: i'm not sure it's my responsibility to debug a bad network (given you've seen other network issues) [16:17] sinzui, so the best thing for you to do on that system that has to stick on a kernel is probably just to only install that kernel or remove the meta-packages tahtt woudl get you new ones. [16:17] oSoMoN: where, for example, do all the changes in ua-overrides-desktop.js.in come from? [16:18] smoser: what i'm asserting is that it's not appropriate for the improter to generically retry `git fetch` 3 times [16:18] nacc, no. i've not seen any other network issues. [16:18] i said the networking is not straight forward, we're using http proxy and such [16:18] but i've never seen other things error as a result [16:18] ok [16:18] smoser: yeah, I am doing that as xnox suggests. Not the best solutiuon, but it guarantees repeability [16:19] sinzui, you maybe shoudl file a bug against petitboot [16:19] https://github.com/open-power/petitboot [16:20] thank you for the pointer smoser [16:20] rbasak, that’s https://bazaar.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/revision/1544 [16:20] sinzui, 'grep -r grubenv' on that git checkout *does* show some hits [16:20] so maybe they're trying. [16:20] have you actually tried the grub-set-default path ? [16:21] oSoMoN: I don't understand why that fixes an FTBFS. [16:21] oSoMoN: and I feel that this should be explained somewhere, eg. in a commit message, or in the SRU paperwork. [16:22] rbasak, running qmlscene inside xvfb at build time to determine the chromium version oxide is built upon proved to be unreliable, this change dynamically replaces the chromium version at runtime instead [16:24] oSoMoN: so you're changing runtime behaviour? I feel that this should be called out in the "Regression Potential" section of the bug! [16:24] rbasak, bug #1633439 mentions the original issue which was bug #1599695. I filed a new bug report precisely to make it clearer in a SRU context [16:24] bug 1633439 in webbrowser-app (Ubuntu Yakkety) "FTBFS on yakkety arm64: Invalid chromium version: ''" [Undecided,New] https://launchpad.net/bugs/1633439 [16:24] bug 1599695 in webbrowser-app (Ubuntu) "When running cmake from QtC on a webbrowser-app branch it fails" [High,Fix released] https://launchpad.net/bugs/1599695 [16:25] oSoMoN: OK, so IMHO, that should be one bug with a task for each release. I think I follow now, thank you for the explanation. [16:25] bdmurray is sponsoring my SRU work so I'm not sure what exactly to ask for next. [16:26] I think I'd want clarity in the bug for whoever handles the SRU next. [16:26] rbasak, sorry for the confusion, I can see how it’s far from being obvious [16:26] rbasak, I’ll update the bug description to hopefully make it clearer [16:26] Perhaps dupe the bugs? I'm interested in bdmurray's opinion first though, before I ask you to make changes - since I won't be the one accepting it. [16:26] Thanks [16:29] smoser: is it easy for you to retry the failures with master? (has a more generic retry on pull failure) [16:30] oSoMoN: I think just using bug 1633439 is fine, but it'd be good to add test case information with sites to test that need the UA changes working. [16:30] bug 1633439 in webbrowser-app (Ubuntu Yakkety) "FTBFS on yakkety arm64: Invalid chromium version: ''" [Undecided,New] https://launchpad.net/bugs/1633439 [16:30] nacc, sure. i can just rm -Rf * and go again [16:31] smoser: ok, let me look at a few more of the cases here, but that should, i think, catch the OSError ones if they are transient [16:31] does master have my fix ? [16:31] for utf-8 [16:31] we could bump the retry limit, too [16:31] smoser: no, let me merge it if you've tested it now [16:31] definitely need *some* sort of backoff [16:31] what is there shoudl be good. i've tested it with 'gmp' which is what originally failed [16:32] ack [16:32] let me check though [16:32] that it has commit messages :) [16:32] rather than '' [16:32] our current 'retry' is just to try 3 times, do you want me to add a sleep in between each retry? [16:35] bdmurray, I’ve just done that, in the [Regression potential] section of the description I’ve explained how to verify [16:38] smoser: e.g., http://paste.ubuntu.com/23389014/ ? [16:38] nacc, looks fine. http://paste.ubuntu.com/23389019/ [16:39] nacc, how long is that sleeping ? [16:39] whats the range there [16:39] smoser: the iteration count (i in 0-2) [16:39] smoser: so a second to 4s, with fuzz [16:39] i dont thin it has to be random. but some sleep is important for sure. [16:40] we can start with this, let's see if it helps a bit [16:41] smoser: looks good, the MR is good to merge then? [16:41] yeah [16:42] nacc, one random feature i'd like.. [16:42] is for a download cache outside of the workign directory for the package [16:42] smoser: yes, that's one of the things we've talked about adding to the repository itself [16:42] so that i could have a directory full of the thign that got downloaded (.dsc and .tar.gz and such) elsewhere. [16:42] to the repository ? [16:42] i personally do *not* want pristine-tar [16:43] as i think that makes size of git repo go up dramitically [16:43] there are ways, i believe, of caching recent versions in .git [16:43] smoser: have you measured this? [16:43] pristine-tar should provide very small deltas vs. the branches [16:43] slangasek, no. [16:43] slangasek, thats possible. its also possible that it doesnt really work. [16:43] smoser: the other reason to go the pristine-tar route is compatibility with other tools [16:44] smoser: but i'd file a bug (agains the importer) :) [16:44] and i've pulled enough massive bzr trees to have non-scientific data making me think it sucks. [16:44] smoser: master updated [16:44] smoser: virsh is unhappy still on borbein: I see mesages about SMT. Do you have any insights http://pastebin.ubuntu.com/23389036/ [16:45] sinzui, http://bazaar.launchpad.net/~smoser/+junk/powerkvm-install/view/head:/setup-ubuntu [16:45] run that [16:45] smoser: bzr itself seems to have never been as tight as git; I wouldn't attribute this to pristine-tar [16:45] sinzui: smt needs to be off in the host to start the VMs [16:45] slangasek, i said non-scientific data. [16:45] :). [16:45] if we want to add support to the importer, i'll run a big batch of uploads and compare .git [16:45] yeah, which is why I'm pushing back against the pristine-tar hate ;-) [16:46] even if it were a small delta [16:46] i'd be bothered. [16:46] heh [16:46] i need to pull exactly one tarball, not the entire history of them [16:46] but yeah, i'd be happy to be shown wrong by data [16:46] pulling a tarball + pulling a git branch, vs. pulling a git branch + pulling a set of small deltas [16:47] theories are nice . you have one , i have one :) [16:47] thank you nacc I am setting it off [16:47] i very well could be wrong. [16:47] :-) [16:47] nacc, i committed 'returning ...' a debug message i think [16:47] did you pull that? [16:48] smoser: bah, can i elide that line? [16:50] smoser: master updated [16:51] nacc, you should print the error message at very least [16:51] and WARN it [16:51] so we can look for the actual error message even if we recover [16:52] smoser: so next time when i ask if your MR can be merged, just say no. [16:52] :) [16:52] slangasek: I thought pristine-tar was considered fundamentally broken and deprecated? [16:52] smoser: what error message are you referring to? that's just printingout the changelog entry extracted from the tree? [16:53] rbasak: it has fundamental limitations; joeyh "deprecated" it, but it still has a maintainer and is widely used and the limitations haven't been a problem yet in practice [16:56] nacc, sorry... in your 'except Exception' [16:56] shoudl warn that [16:56] on the retry [16:56] smoser: oh duh, yeah [16:57] * smoser notes how slangasek was quite on the whole "fundamentally broken" front when smoser was throwing hate [16:57] :) [16:57] smoser: what do you want me to warn? that we are retrying? so make that warn rather than print? [16:57] smoser: or do you want the actual exceptoin? [16:57] we'll raise it eventually if we can't recover [16:58] smoser: it's not fundamentally broken; it has a fundamental /limitation/ [16:59] nacc, 2 things [16:59] a.) you might catch different onces [16:59] b.) you might recover [16:59] in both cases i want to see all the possible failure paths, not just the last. [17:00] and i was going to say in b) i'd rather we didn't print anything :) [17:00] it's irrelevant to an end-user if we do recover [17:00] you can log.debug it if you want [17:00] so i'd say it should be debug , if that's good by you? [17:00] sure. [17:02] smoser: is logging.debug(e) sufficient (given Exception as e)? Or do i need to format a string? [17:03] smoser, nacc: that limitation is that to reconstitute the orig.tar.foo from the pristine-tar branch requires a version of tools (tar, xz, gzip, ...) whose output is byte-for-byte equivalent to the one that was used at the time the pristine-tar delta was generated. However, /in practice/, there haven't been any changes in any of the outputs since pristine-tar use began; and if there were, I [17:03] understand the pristine-tar maintainer is committed to providing the necessary glue (probably bundling older versions of the tools, or something) [17:04] nacc, logging.debug("Source Package Download Error: %r", e) [17:04] ? [17:04] slangasek: yeah that's what i've read as well (in learning about the debian tools) [17:04] smoser: ack on that [17:21] smoser: master pushed [17:30] nacc, i got to run for a bit. will try later. [17:31] smoser: ack [18:22] nacc, i thought you were saying you didnt want to print anything. [18:23] oh... i see you didnt print the error message. only logged that. you did print a 'Failed to pull'... i thought you were suggesting only do anything like that on failure (2 fails) [19:37] smoser: i see what you meant earlier, which was the reason for failure could vary [19:37] smoser: so i compromised :) [20:51] sinzui, just for completeness https://github.com/open-power/petitboot/issues/24 [20:51] that fix would have to get into our firmwares, so its not coming any time soon [20:51] thank you smoser [21:07] smoser: you should scalate that to push for a fix [21:09] roaksoax, i'll scalate that! [21:16] robru: did you change something in bileto wrt britney integration since yesterday or so? [21:17] pitti: maybe, why, what's up? [21:17] robru: the infra is getting bombarded with hundreds of identical content-hub and unity8 requests [21:17] pitti: for zesty? [21:17] I killed the content-hub ones this morning and just now the unity8 ones (both are very expensive and block the infra, and we need it for zesty) [21:17] robru: all releases [21:17] robru: e. g. look at http://autopkgtest.ubuntu.com/running#queue-ppa-zesty-i386 [21:18] and the following ppa xenial amd64 [21:18] pitti: I've been iterating at the db schema for the last few days, nothing that should really impact britney so much... [21:18] pitti: https://bileto.ubuntu.com/static/britney/last-run.txt one thing I noticed is that zesty results.cache 404s so maybe it's retriggering tests that it doesn't know already started? [21:18] pitti: should I turn on debug logging? [21:18] four identical ubuntu-settings-components requests, three content-hub on amd64 (the fourth has a different trigger) [21:19] robru: ok, that would explain zesty, but why v/x? [21:19] pitti: I dunno, did your autopkgtest-as-policy thing land yet? that would be my only guess, if there was a bug in that [21:19] robru: and that's not the state of "I already requested this test", that's pending.json and your britneys have their own [21:20] robru: it did land, yes; it didn't change the pending.json, but it could be the time when this started [21:20] robru: anyway, I'll symlink a zesty results.cache for now [21:22] slangasek, Could you take a look at a livecd-rootfs mp? https://code.launchpad.net/~rcj/livecd-rootfs/zesty_grub/+merge/309517 It resolves a cpc zesty images build breakage for amd64 [21:23] robru: so, too late to debug this now, but if you could turn on verbosity that'd be useful; I killed all PPA test requests for now, but I have a feeling they'll come back by tomorrow.. [21:23] so I could check in the morning [21:23] cyphermox, ^ in bug #1624096 it says you're backporting from zesty. Will the shim/shim-signed file names remain constant during the backport? Hoping so. [21:23] bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [High,Fix released] https://launchpad.net/bugs/1624096 [21:24] pitti: ok will do. I'm reviewing my recent changes in iterate.py and I don't see anything substantial (it's just changing what json dict key names it accesses) [21:24] Or maybe I got the root cause incorrect. [21:24] robru: ok, not that then I figure; it looks like britney would lose/not write her pending.josn [21:24] but verbose log should tell [21:25] pitti: ok, just turned it on. should see verbose logs in an hour or so. goodnight! [21:25] robru: cheers! [21:25] until then it hopefully chewed through the zesty queues [21:32] rcj: the filenames will change in the backport. maybe we should try to figure out how to make this hook use grub-install, instead of hard-coding the filenames? [21:34] robru: they come back faster than I can kill them; I temporarily disabled PPA queue consumption in the workers, this needs to be sorted out first [21:35] pitti: ok so no autopkgtests for bileto for today? [21:35] robru: it's zero or infinitely many :/ [21:35] no updated last-run.txt yet, need to wait for that [21:41] robru: actually the policy refactoring happened on Monday already [21:41] robru: what did change yesterday was the removal of the backwards compat "tests/autopkgtest/" in the JSON [21:41] pitti: ah ok, got busy with other stuff, I'll try to finish up sourceppa quick [21:42] but I thought that wouldn't have an effect on bileto as it was only grepping the .json for REGRESSION or RUNNING [21:42] and it shoudln't affect the pending.json handling anyway [21:42] pitti: well bileto only uses the json to summarize it, there's no code in lp:bileto that would trigger autopkgtests from the json [21:42] right [21:43] or yaml rather [21:43] so, anyway, let's wait for the log; I don't have an off-hand idea what's wrong [21:46] slangasek, I don't have history here. I thought we had issues doing that in the build environment for grub uefi? [21:46] pitti: ok it's starting: https://bileto.ubuntu.com/static/britney/log_2016-10-27_21:40:02.txt [21:48] pitti: indeed the log says pending.json doesn't exist, it doesn't indicate writing one though [21:48] rcj: grub-install --target=x86_64-efi --no-nvram and your uncle is your namesake [21:49] slangasek, I'll give that a go then. Thanks. [21:49] rcj: oh, --uefi-secure-boot in there also [21:50] slangasek, We do that not 10 lines later. Hmmm. [21:50] huh ;) [21:51] robru: hm, that's bad -- in e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/log/zesty/2016-10-27/21:12:07.log it does say that ("Updating pending requested tests in data/zesty-proposed/autopkgtest/pending.json") [21:51] robru: oh, maybe it calls save_state() in the second stage only, which gets shortcut in bileto? [21:52] pitti: second stage? [21:52] robru: that would make sense, given where it appears in ubuntu's logs [21:52] slangasek, Do you think we can just drop the cp's on lines 73-75 since we're running grub-install on line 85 http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-cpc/hooks/033-disk-image-uefi.binary#L64 [21:52] pitti: well I guess I configured britney wrong then? Can you find a problem here: https://git.launchpad.net/bileto/tree/britney/britney.conf.in [21:53] robru: no, you didn't configure it wrong, it's just that the save_state() policy isn't being called with your config [21:53] robru: but we actually want that to work (like before) to not run the seocnd-stage installability tester for you [21:53] rcj: yes, as that's exactly what grub-install is supposed to do for you [21:53] robru: (care to take the BOOTEST out of that :) ) [21:53] s/do for/encapsulate for/ [21:54] pitti: ok. not clear to me why save_state isn't being called [21:54] robru: so I think I know how to reproduce; setting UPGRADE_OUTPUT and HEIDI_OUTPUT to an empty value is how we agreed to disable those [21:54] robru: thanks for your help, I think I have enough info now [21:54] That's what I would think. So only explanation was that it wasn't odd in this env. Where did this cp come from? [21:54] rcj: NB the grub_modules line is also pointless for amd64, a secureboot install doesn't let you add extra modules [21:55] rcj: also that shim copy never worked right, /boot/efi/EFI/BOOT/shimx64.efi would never be used (the right filename is bootx64.efi) [21:55] hah [21:56] Enlightening. [21:56] I'll have a proper MP over tomorrow after running it through. And thank you slangasek. [22:01] robru: reproduced [22:01] yay [22:02] robru: i. e. you can flip off verbosity again (if you care about the space, etc.) [22:02] pitti: ok thanks, I may leave it for a bit. [22:02] robru: or you can as well halt the britneys for now, as they'll just wreak havoc [22:03] oh right [22:03] ok [22:03] robru: so at least we won't lose anything -- for rollout we: (1) clear all current test requests, (2) roll out new britney, (3) next run (without pending.json still) will regenerate all requests [22:04] I can do (1) easily, (2) happens automatically on your side [22:04] pitti: ok britney will be disabled shortly [22:06] I have a fix [22:15] rcj: sorry, I was distracted doing confusing work -- let me know when you have your livecd-rootfs change ready tomorrow and I'll be happy to review / merge it. [22:15] fwiw I'm very much considering installing shim to /boot/efi/EFI/BOOT/BOOX64.efi by default as well as to the standard path, so that most setups work; but it will need to be done carefully [22:15] (bootx64.efi and fbx64.efi along with a boot.csv in the right place will make fallback work correctly, but I'm worried about breaking Windows dual-boot) [22:16] robru: fix pushed; you can update britney (needs reset-hard, I force-pushed) and let it run [22:17] robru: sorry for the trouble [22:17] pitti: no worries, thanks for the fix [22:18] robru: queues are clear; are there any currently running britneys after which I'll need to clean up again? [22:19] robru: I also must remove the "ignore PPA queues" hack from the workers, once everything is in place [22:19] pitti: uh, yeah, https://bileto.ubuntu.com/static/britney/log_2016-10-27_21:40:02.txt is still going, not sure how many more it will trigger... === grumble is now known as zomble [22:23] robru: it now says "2016-10-27 22:21:08.969906 Completed in 0:41:06.929510." [22:23] ? [22:24]