[00:58] doko, i see the transition of doom has not migrated; i see libreoffice is building, so i guess we are waiting for that; anything more to do with qt? [01:00] mdeslaur, why are you uploading postgresql-9.6 into bionic? given we have a temporary upload freeze to sort out postgresql transition to postgresql 10? [01:00] mdeslaur, my understanding we don't need 9.6 in bionic, or do we? [01:01] it's being removed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878852 [01:01] Debian bug 878852 in postgresql-9.6 "Remove postgresql-9.6 from testing" [Serious,Open] [01:02] doko, gvfs failures apppear to be holding up samba/ldb migration [08:48] good morning, can we please have systemd hinted on s390x? https://autopkgtest.ubuntu.com/packages/systemd/bionic/s390x [08:48] seems regressed in release, and blocks the big one [08:51] LocutusOfBorg, no. [08:52] LocutusOfBorg, something is wrong. Ah! it's running on kvm, and the tests need fixing, as they think grub is a thing on s390x. Let me fix that and upload a fix for that. [08:53] thanks xnox! [08:53] kopanocore is blocking icu :( testsuite failures [09:16] tsimonq2: please don't start new transitions! with your vlc upload you successfully connected the samba transiton with all our other transitions [09:17] seb128, Laney, didrocks: ^^^ now the gvfs issues need to be fixed [09:20] hmm, it's just libgcrypt20 [09:24] yes doko [09:24] already fine gvfs there, systemd is worked on by xnox [09:27] ginggs, is working on r-* [09:27] I hinted the python3-pyqt4 test, should pass now, and with libreoffice/systemd we will have a better update_output page [09:28] doko, i think this transition has got so out of hand we almost want to close the archive to sort it out :) [09:29] apw, we are mostly ready to be honest [09:29] LocutusOfBorg, this would be the 3rd or 4th time we have thought that :) [09:29] and then someone throws something in which breaks it [09:30] nah, this is fine, after the autosync has stopped things are getting better [09:30] it's not fine. [09:30] maybe a new perl upload will make things funny again :p [09:31] we have had a growing number of packages which are not considered for more than two weeks now. [09:31] now they are mostly all considered from what I can see [09:32] python-qt4 is now candidate too [09:34] now we need libreoffice and systemd :/ [09:36] libreoffice builds on arm* just got started from scratch it seems :/ I guess since the seemed hung at 19hrs [09:45] yes, I cancelled it and gave it back [09:49] doko: I looked at it and wondered to if mention it looked hung, so :) [10:23] apw, can we please hint kopanocore regressed in release? http://autopkgtest.ubuntu.com/packages/k/kopanocore/bionic/amd64 [11:18] LocutusOfBorg: why? did nish have a look at that one? [11:21] who knows? :) [11:22] installation works locally [11:25] oops reproducible locally the issue [11:45] LocutusOfBorg: are you looking into the kopano-core issue then? [11:46] as doko pinged us in another channel [11:52] RIP autopkgtest-cloud-worker/0 [11:52] ye served us well [11:54] cpaelzer, nope [11:54] I tried to look at the code, and I failed [11:56] ok [11:56] I found this along the way - bug 1733572 but can't reproduce the error in the dep8 test so far [11:56] bug 1733572 in kopanocore (Ubuntu) "php-mapi conflicts with other version" [Undecided,New] https://launchpad.net/bugs/1733572 [11:58] ok in autopkgtest the error reproduces on amd64 as well as i386 [12:03] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/r/r-cran-openssl/20171118_082449_e7d37@/log.gz [12:03] missing proxy settings? [12:04] xnox: I didn't realize there was a migration going on to a newer version [12:09] apw, Laney, infinity: I see a few badhints for r-cran-* and r-bioc-* packages. How do you want to handle those? [12:11] hints that need removal ? [12:14] apw: no, see update_output.txt for the packages that are blocking our transitions [12:15] I'm not going to fix all autopkg tests for the Debian Med Team [12:17] they might make you a Dr. H.C. for it though ... [12:18] docta ogra ... [12:19] :) [12:28] ginggs: http://launchpadlibrarian.net/346150058/r-cran-tibble_1.3.4-1_1.3.4-1ubuntu1.diff.gz is not forwarded [12:36] doko: https://anonscm.debian.org/git/debian-med/r-cran-tibble.git [12:39] ahh, ok, also debian med member? ;p [12:40] doko: yeah, it's easier that way :) [12:40] if you can't beat em... [12:43] xnox: ^^^ something to join ... [13:23] -queuebot:#ubuntu-release- Unapproved: libinput (artful-proposed/main) [1.8.2-1ubuntu2 => 1.8.4-0ubuntu0.17.10.1] (desktop-core) [14:17] uploading r-cran-dplyr now, it should unblock r-cran-stringi -> icu [14:25] <3 [14:29] -queuebot:#ubuntu-release- Unapproved: linux-firmware-snapdragon (artful-proposed/multiverse) [1.2-0ubuntu1 => 1.3-0ubuntu3~17.10.1] (kernel) (sync) [14:29] -queuebot:#ubuntu-release- Unapproved: linux-firmware (artful-proposed/main) [1.169 => 1.169.1] (core, kernel) (sync) [14:30] err, i mean r-cran-tidyr, whateva [14:30] -queuebot:#ubuntu-release- Unapproved: linux-firmware-snapdragon (xenial-proposed/multiverse) [1.2-0ubuntu1 => 1.3-0ubuntu3~16.04.1] (kernel) (sync) [14:30] -queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.13 => 1.157.14] (core, kernel) (sync) [14:31] -queuebot:#ubuntu-release- Unapproved: linux-firmware (zesty-proposed/main) [1.164.1 => 1.164.2] (core, kernel) (sync) [14:31] -queuebot:#ubuntu-release- Unapproved: linux-firmware (trusty-proposed/main) [1.127.23 => 1.127.24] (core, kernel) (sync) [14:36] could someone approve juju-core 2.2.6-0ubuntu0.16.04.3 in the zesty and xenial queue? It merely contains a fix for adt proxy failures [14:39] libreoffice seems mostly built on armhf [14:50] balloons, i assume that would replace the one in -proposed then ? [14:51] balloons, the code delta looks a little odd, in the sense the code it is removing has a /16 in it [14:53] balloons, which may well imply the fix in later releases is wonky not necessarily the change as applied [15:10] LocutusOfBorg: you know you can add extra triggers instead of using all-proposed, right? [15:10] also what are those arm64 requests about? [15:11] I did try some changes in scripts, and I probably issued some arm64 stuff too [15:11] doko, so i use R a little. the type system is completely nuts. more ambigious than javascript. or maybe it's me. and i'm not even sure where to start with all the current r blockage in proposed. [15:11] Laney, have you done coding in R, perhaps? i'm just not sure if I don't get something about R, or its type system is really really odd. [15:11] xnox: never [15:12] don't know if I would even recognise R code [15:12] Laney, keep it that way =) [15:13] order of imports, changes coalensence rules; and things tend to morph to the type one last stored in a variable. mophing upon value assignment is imho bad. [15:20] I ran into http://www.burns-stat.com/pages/Tutor/R_inferno.pdf some time ago which looked useful for some of this kind of thing [15:20] (though I know no R myself) [15:31] xnox, your systemd upload didn't fix s390x? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/s/systemd/20171121_152138_374c2@/log.gz [15:32] LocutusOfBorg, yes, i have noticed that.... got carried away fixing all the other things. and i was like "i'm sure there was something else" [15:32] apw, what do you mean the diff is odd? and yes, to replace what's in proposed [15:32] apw, the issue we have is with the autopkgtest failing because it's trying to proxy to a local container. [15:33] balloons, you are clearly installing a 10.0.8.0/24 equivalent with the new code, the old is a 10.0.8.0/16 ... though that makes little sense as a construct [15:33] apw, ahh, right. That is true. But this is the second attempt, and we only need a /24 [15:34] I suppose the diff makes it look more confusing [15:34] balloons, that was what i wanted to check, as there no commentary to say a /24 is preferable [15:36] apw, ack, thank you for mentioning it [15:37] cjwatson, that's a lovely PDF! sums up R nicely =) [15:39] "R_inferno" sums it up nicely, the other 126 pages are just useless :) [15:40] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (zesty-proposed) [2.2.6-0ubuntu0.17.04.3] [15:53] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (xenial-proposed) [2.2.6-0ubuntu0.16.04.3] [15:59] can any AA please process this NBS? missing build on amd64: python-daiquiri (from 1.3.0-1ubuntu1) [15:59] it now provides python3-daiquiri only [15:59] I don't know why coreycb didn't ask that [16:01] LocutusOfBorg: sorry about that [16:02] LocutusOfBorg, looking [16:03] LocutusOfBorg, coreycb, gone [16:04] apw: LocutusOfBorg: thanks [16:07] <3 thanks to you two! [16:09] doko, why uploading r-base for useless changes? they trigger a ton of autopkgtests :/ [16:15] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.23 => 2.408.24] (desktop-core) [16:15] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.9 => 2.441.10] (desktop-core) [16:23] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (artful-proposed) [17.03.2-0ubuntu1~17.10.1] [16:24] slangasek, infinity, apw: Could somebody do some -proposed cleanup? [16:29] bdmurray: for the stable series? I can do that [16:29] bdmurray: I though any SRU member can do that [16:29] sil2100: Yeah the one from the report - https://people.canonical.com/~ubuntu-archive/pending-sru.html [16:29] sil2100: I think you need to be an AA to use remove-package [16:30] hm, ok, I though on the sprint someone said it's also an ACL of SRU guys - anyway, running those [16:30] sil2100: well I could try one [16:31] I'm running the ones from the top now [16:31] So zesty [16:31] Try running one of the xenial ones [16:32] HTTP Error 401: Unauthorized [16:34] heh, ok, so it is AA-only, at least now I know [16:35] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (zesty-proposed) [17.03.2-0ubuntu1~17.04.1] [16:35] bdmurray: in case you plan doing any SRU reviewing today, I had to re-upload livecd-rootfs for both zesty and xenial as there was one thing missing in the old branches I was backporting the change to [16:35] Would welcome a re-review [16:37] noted [16:40] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [17.03.2-0ubuntu1~16.04.1] [16:56] hurray, lets delay another day the transition [17:02] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.10] [17:03] -queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.2.2-6099-g8751f91-0ubuntu1~16.04.1 => 2.3.0-6434-gd354690-0ubuntu1~16.04.1] (ubuntu-server) [17:06] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.24] [17:06] -queuebot:#ubuntu-release- Unapproved: maas (zesty-proposed/main) [2.2.2-6099-g8751f91-0ubuntu1~17.04.1 => 2.3.0-6434-gd354690-0ubuntu1~17.04.1] (ubuntu-server) [17:08] -queuebot:#ubuntu-release- Unapproved: maas (artful-proposed/main) [2.3.0~beta2-6327-gdd05aa2-0ubuntu1 => 2.3.0-6434-gd354690-0ubuntu1~17.10.1] (ubuntu-server) [17:10] slangasek: thank you for approving livecd-rootfs! [17:12] sil2100: yep [17:17] oooo libreoffice has built \o/ [17:25] Yaay [17:29] * Laney wonders how update_output_notest is going to look once p-m sees it [17:33] oh someone ran all the r-cran-tidyr tests, thanks! [17:37] would some kind soul please 'force bad-test r-bioc-ensembldb/2.2.0-1' ? all of the autopkgtests now need https://bioconductor.org/packages/release/data/annotation/html/EnsDb.Hsapiens.v75.html which is 75MB in size and no plans to package it in debian [17:39] see https://sources.debian.net/src/r-bioc-ensembldb/1.6.2-1/debian/README.test/ [17:40] s/force bad-test/force-badtest/ [17:49] ginggs: shouldn't the testsuite be dropped then? [17:50] Laney: yes, how can that be done? [17:50] git rm -r debian/tests [17:50] i've seen another package from debain drop its tests and it still requires hinting [17:51] I think we fixed that, and if not we should do [17:51] (https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/britney2/policies/autopkgtest.py?id=41d51369f54d695153fcd71043b511883392a5bf) [17:57] is this channel for Ubuntu 18? [17:58] Laney: ok, thanks - i'll try it [17:59] yes hello i have recently installed Ubuntu 18 but before I invest any more time in setting up I would like you guys opinion on whether I should continue or revert back to 17 and wait [18:00] QRM: technically this is for release coordination. for discussion, try #ubuntu+1 [18:00] re: it usually takes me about 6 hours to properly configure and harden [18:00] oh ok thanks ! [18:01] ginggs: I can badtest this one if it's more convenient to not upload [18:01] or you can try it [18:01] as you wish [18:02] Laney: please badbest, i'll remove the tests in debian and we'll see when it syncs [18:02] k [18:03] Laney: ta! (badbest, wtf) [18:03] besttest [18:10] stoken seems to be one of the things that would be broken by the 'BIG' transition? and the latest rebuild FTBFS https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878883 [18:10] Debian bug 878883 in src:stoken "stoken FTBFS with libtomcrypt 1.18" [Serious,Open] [18:22] acheronuk, just upload? [18:22] actually it seems to be not a problem for the big transition, but it should end a smaller one anyway [18:24] Laney, can you please hint systemd test on s390x? AFAIK it is a testsuite issue, the new upload didn't fix it, and it is holding vlc+libgcrypt20, making update_output look worse [18:25] xnox, ^^ [18:25] it was on my list of stuff the big one would break if it migrated, so that led me to it [18:25] * acheronuk shrugs [18:26] the patch is trivial, why not upload it? [18:27] LocutusOfBorg, libreoffice is still not in, and systemd fix is in flight, why rush, if it's not your thing? [18:28] it's in my set, but via other stuff. I try not to mess with things like that unless no option [18:28] I probably parsed wrongly your sentence of some hours ago "I moved to something else" :) [18:29] anyhow, I don't see how hinting a bad test can hurt, and I don't see a big point in uploading systemd that runs a lot of tests right now [18:30] isn't it better to badtest it, lets stuff migrate and remove the block? [18:34] LocutusOfBorg, i care about least total human effort; and majority of things is still not ready to migrate, because we still do not have libreoffice on arm64. It's still publishing. [18:34] LocutusOfBorg, and hints/unblocks/blocks is human time. [18:36] LocutusOfBorg, you do see how not having libreoffice as a valid candidate, results in half of the archive to not be installable and like all of kubuntu and qt? [18:36] LocutusOfBorg, and it looks like r is now entagled in the mess with half of it not installable. [18:36] i mean half of uninstallable packages being r [18:38] yes, but lo is publishing *now*, and r-* is fine in one hour or two maximum [18:39] so, if you upload systemd, we have to delay it by some more hours, and I don't know what else, but it is fine your opinion, I understand it [18:39] and I probably agree with you [18:39] just I would like to wake up tomorrow without 10MB of excuses page :) [18:41] tomorrow we have 9MB! [18:41] * acheronuk hides [18:42] my mobile phone will appreciate 1 less MB in size :p [18:42] so would my browser [18:58] * sil2100 is getting impatient waiting for the publisher to publish his new package [19:09] RAOF can you accept snapcraft into xenial- and zesty-proposed? [19:28] any chance someone can review that LXD 2.0.11 SRU in xenial-proposed? been sitting there a while and would unblock a few things (kernel adt failure and a heap of bugfixes) if it was let in [19:31] stgraber: I can look at it now [19:37] sil2100: I don't see livecd-rootfs in the zesty queue [19:38] bdmurray: Steve already approved it, thanks! [19:38] well fine then [19:40] sil2100: thanks! [19:42] Large backport diffs hurt my eyes! But that's fine [19:44] yeah, we didn't get to release a bugfix release in quite a few months so it's a rather long diff :) [19:45] all commits are listed in the changelog though and we don't backport new features to our stable branches [19:45] bah, now r-bioc-biocparallel/1.10.1-1build1/s390x has become flaky [19:50] stgraber: approved o/ [19:50] thanks [19:50] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.11-0ubuntu1~16.04.1] [20:02] LocutusOfBorg: [20:02] - debian/control: Drop libanthy0's dependency to anthy-common. anthy [20:02] should pull in -common, not the library. This reclaims 3.4 MB of CD [20:02] space. (Debian #582830, #582942) [20:02] Debian bug 582830 in libm17n-0 "libanthy0: The dependency on anthy-common pulls in 13 MB" [Wishlist,Fixed] http://bugs.debian.org/582830 [20:02] Debian bug 582942 in cups "cups stops printing. too restricted permissions /usr/lib/cups/backend - permission denied" [Grave,Fixed] http://bugs.debian.org/582942 [20:02] - This is not relevant anymore, we don't use cdimages [20:02] LocutusOfBorg: How does "we use bigger ISOs" justify dropping that change? [20:02] LocutusOfBorg: The change was correct, regardless of media size. [20:03] -queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-27-geb292c18-0ubuntu1~17.10.1 => 17.1-41-g76243487-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server) [20:08] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [17.1-27-geb292c18-0ubuntu1~17.04.1 => 17.1-41-g76243487-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server) [20:11] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.1-27-geb292c18-0ubuntu1~16.04.1 => 17.1-41-g76243487-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server) [20:12] infinity: (sorry if this seems like excessive poking) Now that we confirmed the tooling change works on Bionic, could we get new 17.10 ISOs pretty please? :) [20:12] tsimonq2: That's not something we generally do. I'm thinking about it. [20:13] infinity: Alright. [20:15] tsimonq2: I mean, we've done special exceptional respins in the days after a release (though, usually that means that flavour released late, we're not replacing ISOs), but this is a month later. At this point, all the keeners who really wanted lubuntu 17.10 already have it. [20:16] infinity: apparently not as a user brought this up to us a couple days ago [20:17] wxl: s/all/almost all/ :P [20:17] :/ [20:21] infinity: Well, another thing to consider is that we have to support 17.10 for the next eight months. [20:22] tsimonq2: Support the packages, not the installer. I mean, the day bionic releases, you can tell people who are *installing* 17.10 that they're probably doing it wrong. :P [20:22] But yes, there's a 5mo gap before that happens. [20:22] I assume this is only an issue for offline installs? [20:22] infinity, ok will reapply after the big transition? [20:22] Since I'd expect online ones to be able to find the bits they need. [20:22] LocutusOfBorg: Sure. [20:23] sil2100 if still around, mind looking at snapcraft for xenial- and zesty-proposed ? [20:23] infinity: Let me get back to you on that because I want to be 100% sure but iirc, correct. [20:24] LocutusOfBorg: Actually, anthy triggers no tests (ew, but also handy in this case), just reapply it now? [20:24] LocutusOfBorg: Triggers no tests and builds in 3m on armhf. [20:24] ack [20:26] I though about this change, the debian packaging was somewhat different, and the debian bug is closed [20:26] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582830 [20:26] Debian bug 582830 in libm17n-0 "libanthy0: The dependency on anthy-common pulls in 13 MB" [Wishlist,Fixed] [20:26] you sure it is still a problem? [20:26] infinity, the change was fixed in debian elsehow [20:26] infinity, specifically we no longer have emacs -> something -> libanthy0 dependency chain anymore. [20:26] And was emacs literally the only reason we cared? [20:27] infinity, one sec, i did look through this. [20:27] Oh, hrm. anthy is only in supported now. [20:27] So, maybe I care a bit less. [20:28] infinity, yeah it dropped off all cdimages, that's what i meant. something rather used to pull it in. [20:28] Eh. [20:28] because like we switched input methods; and emacs-common no longer pulls it in. [20:28] Alright, I still think the packaging is whack, but "it's whack" isn't quite enough justification to carry a delta forever. [20:28] oh yeah, it's whack-a-mole all around. [20:29] so, no actions needed? I'm happy the first time I looked at it I got it right :) [20:29] LocutusOfBorg: Okay, you win. :P [20:29] <3 [20:29] I'm pretty sure I asked somewhat here or in #ubuntu-devel for help while doing anthy :) so my "win" is probably because somebody else helped [20:30] Heh. [20:30] I continue to vomit in my mouth slightly when I see how that whole packageset it put together. anthy, uim, scim, it's all a mess. [20:30] But yeah, it's not on any media, not installed by any desktops, etc. [20:31] So, meh. [20:37] would someone please 'force-badtest r-bioc-biocparallel/1.10.1-1build1/s390x' - it's become flaky (and has been in the past) - nothing in d-oko's r-base upload should have affected it [20:43] ginggs: I find it entertaining that it only seems to pass on armhf. [20:43] Quality test. [20:44] And it *consistently* passes on armhf. Even weirder. [20:44] infinity, because xenial kernel? [20:45] xnox: s390x is also a xenial kernel, though? [20:45] infinity, armhf is the last one to run on xenial kernel, inside lxd. everything else is on kvm now. [20:45] infinity, let's check top of the log, it was switched recently to openstack nova. [20:45] Oh, did we switch s390x to bos02? [20:45] That would explain the change. [20:45] Though, weird that this stuff is kernel-sensitive. [20:46] -- ssh -s /home/ubuntu/autopkgtest/ssh-setup/nova -> yeap it's running in s390x openstack [20:46] xnox: More funny, it consistently failed in armhf/xenial, didn't start passing until yakkety. :P [20:46] Ditto for s390x. [20:46] ginggs: I'll badtest it for now, but any chance you could poke people to fix their effin' tests in Debian for this? [20:47] well, we don't have host cotrol. so maybe hosts' kernel something got fixed to make things tick. [20:48] ginggs: Also, I'm going to version the force, so we're forced (hah) to revisit it. [20:48] ginggs: Ahh, which you asked for. [20:58] infinity: thanks, i'll poke em [21:00] ginggs: If it helps any, the tests appear to be pretty unreliable on debian/amd64 too (though, at least they pass sometimes, unlike here) [21:09] -queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu4.1 => 2:13.1.4-0ubuntu4.3] (openstack, ubuntu-server) [21:12] infinity: #882371 [21:13] for the bot: debian #882371 [21:13] Debian bug 882371 in src:r-bioc-biocparallel "r-bioc-biocparallel: flaky autopkgtests" [Normal,Open] http://bugs.debian.org/882371 [21:13] ubot5: thank you [21:13] You're welcome! But keep in mind I'm just a bot ;-) [21:16] ginggs: Where did you get that whacky version number from for reportbug? :P [21:16] ginggs: (But thanks for filing) [21:18] infinity: i scrolled down the ci.debian.net page until i found where it started being flaky [21:18] got: 8441+0: a-1:a-8437:a-1:i-1:p-1:s-0 [21:18] oww [21:18] ginggs: Ahh. So, some actual method to the madness. Kay. [21:22] why not both? [21:28] -queuebot:#ubuntu-release- Unapproved: lxcfs (trusty-backports/universe) [2.0.7-0ubuntu1~14.04.1 => 2.0.8-0ubuntu1~14.04.1] (no packageset) [21:32] -queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (trusty-backports) [2.0.8-0ubuntu1~14.04.1] [21:32] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (trusty-backports) [2.0.10-0ubuntu1~14.04.2] [21:37] Trying easy from autohinter: chrony/3.2-1build1 dropbear/2017.75-3 libtomcrypt/1.18.0-1 stoken/0.92-1~build1 stormlib/9.21-1build1 [21:37] * arm64: dropbear-bin [21:37] what does it mean? [21:38] it means that making that set of changes to the target suite results in dropbear-bin becoming newly-uninstallable on arm64 [21:38] (but not other architectures. or possibly just no other architectures earlier in alphabetical order, I forget.) [21:38] but I tried and they seems to be installable... [21:39] you have to take some care to include only that set of changes, and to avoid anything that was built by older versions of those sources but not the newer versions [21:40] I'll check again later :) thanks [21:43] ah, how did chrony become migratable? did someone fix its atrocious autopkgtests? [21:44] LocutusOfBorg: It's because dropbear-bin Depends: libtomcrypt0 on all architectures except amd64, but libtomcrypt1 on amd64 [21:44] possibly behind the scenes by fixing the tests in the upstream github repo that is being cloned at test time? :P [21:44] LocutusOfBorg: and the new version of libtomcrypt builds libtomcrypt1 [21:44] LocutusOfBorg: i.e. partial transition, probably fixable by rebuilding dropbear [21:45] LocutusOfBorg: ("chdist apt-get bionic-proposed-arm64 install dropbear-bin libtomcrypt0-" reveals the problem - include a "foo-" argument for any binaries present in the old sources but not the new sources) [21:48] LocutusOfBorg: I'll do a dropbear rebuild [21:51] thanks! [22:23] SUCCESS (1193/0) [22:23] oh gosh, the notest is *ready* [22:28] cyphermox: was the isc-dhcp part of bug 1713747 also verified? [22:28] bug 1713747 in isc-dhcp (Ubuntu Xenial) "missing DOMAINSEARCH in initramfs output files if the DHCP server doesn't provide one" [High,Triaged] https://launchpad.net/bugs/1713747 [22:29] it was, is some comment missing? [22:29] hrm, wait a second [22:30] bdmurray, it was, let me capture that in a comment [22:32] bdmurray: to be extra safe I'll re-do the steps right now [22:33] cool [22:40] Laney, slangasek - arm64 will be done soon; can we redo baseline for s390x given it uses nova-kvm now? [22:54] Ok. Libvirt in zesty-proposed causes a Cockpit autopkgtest regression on s390x because it now tries to run the test on s390x rather than skipping it. Where's the autopkgtest overrides branch again? [22:59] xnox: shouldn't relate to the arm64 queue now that the runners are restructured; but I would be wary of doing a full retest on s390x while it might interfere with the current mega-transition [23:21] Ah, there it is; ~ubuntu-release/britney/hints-ubuntu [23:31] RAOF: rather, ~ubuntu-sru/britney/hints-ubuntu-zesty [23:32] Aha! Thus neatly answering my next question :) [23:34] slangasek: I don't suppose there's any easy way to validate my change before pushing it? [23:34] (Adding “force-badtest cockpit/all/s390x” to my file there) [23:35] RAOF: nope - you could run britney locally but that's not quick or easy or a worthwhile use of your time [23:35] Good, good. [23:36] what are the open issues for the transition now? [23:37] I know about kopano, and libgcrypt