[00:35] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [17.1-46-g7acc9e68-0ubuntu1~16.04.1] [02:02] Anyone know offhand how often Launchpad syncs its Debian archive mirror? [06:06] LocutusOfBorg: +1 as well. keep seeing test fails on armhf particularly which are just the device running out of space [07:02] LocutusOfBorg, acheronuk: yeah, looks like, possibly during an upgrade, /var/lib/lxd stopped being pointed at the 72G disk and started being pointed at the 7.6G disk. looking. [07:33] LocutusOfBorg, acheronuk: fixed for 10.43.42.186 (the host listed in the libdata-perl-perl log). If you see more of these going forward, please let me know [07:37] slangasek: thanks. quickly checking a couple of logs on the ones I saw, that seems to be the same host. but yes, I'll let you know if any more occur [10:01] tsimonq2: 25 4,10,16,22 * * * [10:02] thanks slangasek for being helpful once again! [10:02] tsimonq2: (UTC) [10:02] I'll keep you informed [10:03] slangasek, on a similar issue, in the last two days I saw some s390x strange failures with "can't acquire dpkg log" [10:03] an example is here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/n/node-module-deps/20171202_091629_916ef@/log.gz [10:03] maybe related? [10:04] https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#ktextwidgets search for "/unknown" and you get 5 s390x failures [10:06] this happens also later in the autopkgtestsuite, so they don't fall into the "unknown state", but a general "failed" e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/libc/libconstant-generate-perl/20171202_085435_718f2@/log.gz [16:39] if anyone is about, could kate4/4:4.14.3-4ubuntu2 be badtested please? that is not buildable any more and needs to be removed from bionic soon, but can only get that done once latest kde4libs that it's test fail will block gets into -release [18:44] LocutusOfBorg: s390x failures are certainly not related to a misconfigured filesystem on one of the armhf host nodes, no. We've noticed the dpkg lock problem, I'm currently unsure what is causing it but we need to make sure unattended-upgrades is disabled/removed from the autopkgtest cloud images; https://git.launchpad.net/autopkgtest-cloud tools/build-adt-image-all-clouds if someone wanted to [18:45] dig into this [19:21] Thanks cjwatson and slangasek :) [22:07] cjwatson: Out of curiosity, what's the reasoning behind every 6 hours at those times? [22:30] tsimonq2: Debian itself publishes every 6h (last I checked), I believe the times are selected to try to maximize the chances of Debian's publisher having completed first before LP tries to import [22:31] slangasek: ohhh dinstall didn't even cross my mind? [22:31] s/?// [22:31] Makes sense. [22:32] slangasek: Yep, #debian-ftp topic says "dinstall starts at 0152,0752,1352,1952 UTC" [22:32] slangasek: That is quite a gap though, shouldn't dinstall not take that long? [22:32] * tsimonq2 doesn't really know [22:37] forget what I asked about kate4 for today. uploaded a possible fix [22:40] tsimonq2: I don't know how long it normally takes; I guess the LP team have looked at this more closely than I have and the importer cronjob is empirically informed [22:41] slangasek: Alright, interesting though :) [23:26] tsimonq2: dinstall takes a while, and then it needs to propagate to the appropriate mirror [23:27] cjwatson: ah ok [23:27] tsimonq2: slangasek is correct that it's empirically informed; the last change to those times was in July of this year, when we moved it 20 minutes later because it was routinely overlapping Debian mirror pushes [23:28] Gotha [23:28] *gotcha [23:32] Question about the autopkgtester test request formatting... https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Test_request_format says that "all-proposed" just has to be a non-empty value, and from (albeit limited) testing it seems to only accept 1 and not a boolean [23:32] What's up with that? :) [23:32] Doesn't even accept 0 or 2, just 1 [23:34] If anything I'd at *least* expect it to take a boolean, even if it's redundantly called (like if false is passed) [23:35] 0 and 1 are booleans, 'false' is text ;) [23:36] (I've always seen booleans in the sense of "true" or "false" when programming, albeit I've only used them in a limited sense) [23:36] I'd say the documentation should be updated. I don't think it's worth changing the code to be permissive [23:36] slangasek: But it doesn't accept 0, is that because it's redundant? [23:37] if you're in a programming language that recognizes true and false as booleans, sure. In url variables, anything goes [23:37] (if that's the case, the message should probably explain that instead of just "invalid format") [23:37] Ah, gotcha [23:37] TIL [23:37] I think it doesn't allow it because no one bothers trying to pass the extra variable when it's not explicitly needed [23:39] Hm, ok [23:39] slangasek: You plan on updating the documentation or should I? [23:39] tsimonq2: feel free [23:41] slangasek: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure?action=diff&rev1=87&rev2=88 [23:42] lgtm [23:42] cool [23:51] slangasek: Do you use some sort of tool to queue tests, or do you just edit the URL? [23:51] Because I'm thinking of hacking up a tool that I'll just put in ~/bin for myself but I don't know if there's already something...