[00:30] darkxst: debug messages> many modules include a 'debug' option which will increase verbosity to syslog, provided you're logging syslog debug messages somewhere [02:22] cyphermox, we found a serious issue in grub that worth a look: https://bugs.launchpad.net/ubuntukylin/+bug/1559933 [02:22] Launchpad bug 1559933 in Ubuntu Kylin "[Grub] There are messy codes on displaying Chinese characters in grub after install xenial-desktop_0320." [High,Triaged] [03:30] pitti, stgraber: hi - I believe that the failing lxc test that's preventing the apparmor migration is a bad lxc test: "There is no download available for release=xenial, stream=daily, arch=amd64" [03:31] pitti, stgraber: I see the same failure when running the lxc tests locally without a the new apparmor [03:31] hmm, so something happened with simplestreams over the last few days which broke that test [03:31] but indeed, unlikely to have been caused by the apparmor upload [03:33] thanks for the confirmation [03:34] I'm assuming you attempted a retry of the test already? [03:34] yes [03:34] twice on amd64 and i386 [03:34] both sets of retries failed [03:40] doing a local adt run here as a simple lxc-create does work fine for me [03:45] well, adt is crashing here (as in the tool) so not much luck with it, will let pitti figure it out [04:30] tyhicks: just got adt to run properly here and it passed fine, so looks like it's something in the adt environment which changed [04:31] stgraber: ok, thanks for looking into that - I don't guess there's anything that I can do on my end [04:32] nah, though it means that if you ever run into that problem again, you can run adt-run locally and it should avoid that particular failure [04:32] might have been a firewall or proxy change in scalingstack, I'm sure pitti will take a look once he's around [04:33] stgraber: I did do a local adt-run and saw the same failure [04:33] oh, odd [04:33] PASS: lxc-tests: /usr/bin/lxc-test-ubuntu [04:33] just got that 5min ago [04:34] my run was ~2 hours ago (without the new apparmor) [04:34] adt-run -U --apt-pocket=proposed lxc --- adt-virt-qemu adt-xenial-amd64-cloud.img [04:34] that's what I ran here [04:35] I'll give that a try in a bit [04:37] also odd that it doesn't affect ppc64el [04:40] agreed [05:15] pitti: looks like ppc64el adt is kinda stuck, had a lxd adt stuck on nova create for a while now [05:46] tyhicks: btw, another adt retry for lxc just passed, so if that was the only blocker, apparmor will migrate very soon [05:55] tyhicks: apparmor is held back by regressing systemd; that and the regressing udisks2 are because "scsi_debug" is missing, it seems that linux-image-extra does not get installed any more all of a sudden; investigating [05:56] lxc seems happy again [05:56] pitti: looks like ppc64el adt for lxd also got unblocked, package just migrated now [05:57] yeah, but that looks relatively stable (http://autopkgtest.ubuntu.com/packages/l/lxd/xenial/ppc64el/) [05:58] yeah, just not sure why it was seemingly stuck for over half an hour on nova create [05:58] pitti: I also can't locally reproduce the systemd "storage" test failure that is preventing the apparmor migration: "modprobe: FATAL: Module scsi_debug not found in directory /lib/modules/4.4.0-18-generic" [05:59] stgraber: pretty much everything has a timeout, I guess it timed out, and auto-retried [05:59] tyhicks: yes, that's the thing I meant above 4 mins ago [05:59] * pitti shakes fists at lcy01 [05:59] pitti: ah, I missed that message, sorry! [06:03] tyhicks: I hinted apparmor for now to unblock this [06:03] pitti: thank you! [07:51] Good morning. [08:11] jibel, cyphermox, slangasek, seb128: hmmm no image today? [08:12] davmor2: Need a bit more verbosity. [08:13] infinity: no xenial images build today the page is missing from the cdimages http://cdimages.ubuntu.com/daily-live/20160409/ [08:13] * infinity raises his brow at the empty directories. [08:13] infinity: current image is based on the 8th [08:15] Launchpad was down briefly last night. Related? [08:16] No. Today's just exploded too. [08:16] I fixed the libgda5 FTBFS yesterday, but am not sure whether to upload: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811068 [08:16] infinity: you understand my asking now right :) [08:16] Debian bug 811068 in libgda5 "FTBFS: FAIL: check_vcnc: ../../test-driver: line 107: 77018 Aborted" [Serious,Open] [08:17] Old libgda5 was building against an older sqlite. Rebuilding it even with my patch may regress it. [08:17] The source would only be made better, but the binary may regress from the perspective of a user. [11:28] ^^ that swift upload should resolved the autopkgtest failure that's blocking 2.7.0 from the release pocket... [14:28] ^ will (should?) dep-wait without mysql-connector-c++ [14:28] (he says to the mystery person accepting his stuff) [14:37] Oh, the mystery person being the unseeded auto-accept. [14:39] heheh, rbasak [15:16] stgraber: since you cared about it before to review: ^ [15:17] this fixes the current autopkgtest failure, which was due to a changed default I didn't notice, because I was testing with my own existing connections. [15:20] infinity: remember my cpc merge for ubuntu-cdimage? [15:31] cyphermox: looking [16:06] ^ you can reject ubuntu2, which only contains a partial fix to the emulator image building (or ubuntu-touch installation). ubuntu3 handles all upgrade situations. sorry for the hassle. [16:07] the gles packaging is in the middle of migrating to completely new system as mandated by CI Train changes, but I'm going to keep everything in sync now. [16:08] infinity, cjwatson - why you hate UTF-8 on s390x? Looking at buildds, all arches are now on UTF-8, apart from s390x [16:09] cause on s390x in addition to LANG=C.UTF-8, there is also LC_ALL=POSIX which trumps the UTF-9-ness [16:09] cause on s390x in addition to LANG=C.UTF-8, there is also LC_ALL=POSIX which trumps the UTF-8-ness [16:11] bluff [16:11] sbuild-package:export LANG=C.UTF-8 LC_ALL=C.UTF-8 LANGUAGE= [16:13] unless sbuild hates us lots, which is possible [16:13] $host_defaults->{'ENV'}->{'LC_ALL'} = 'POSIX'; [16:14] that line dates from 2010 though [16:15] oh I don't know, please puzzle something out, I need to think about SSO stuff [16:15] =) [16:15] cjwatson, https://youtu.be/IXmF4GbA86E [16:16] oh wait you said SSO, not SOS =) oh well. [16:17] i guess POSIX is coming from the host itself, rather than the chroot, which is coming from debian, because our hosts got cross-graded _from_ debian rather than being ubuntu installs. [16:17] infinity, could you ssh and fiddle with builders? [16:17] * xnox is not going to fiddle with them via HMC console, because i shouldn't. [16:18] can't be the host [16:18] I mean except for xenial's sbuild [16:19] and "grep -rs POSIX /etc" has nothing of interest [16:21] I strongly suspect xenial's sbuild, just can't easily prove it right now [16:24] ack. [18:53] Hi, we just realized that likely due to the reorg regarding build-dependencies we had a few packages falling out of main the last days [18:53] in particular all of dpdk and openvswitch-switch-dpdk [18:53] what would be the appropriate way to address that? [19:02] cpaelzer: openvswitch-switch-dpdk was never in main... [19:04] infinity: I'll have to clarify that with jamespage tomorrow then [19:05] the changes made by doko back then wehn bug 1492186 was closed seem to be lost [19:05] cpaelzer, infinity: I'm still here [19:05] bug 1492186 in dpdk (Ubuntu) "[MIR] dpdk" [High,Fix released] https://launchpad.net/bugs/1492186 [19:05] and it was never in main - that's quite correct [19:05] but dpdk was, the bug even holds the "override component to main" [19:05] I wonder what was lost [19:05] cpaelzer, infinity: that said it is build from a main source package, so I can seed if if thats OK [19:06] that would pull the runtime dpdk bits back into main [19:06] jamespage: IIRC you intended bring in openvswitch-switch-dpdk anyway [19:06] yet I wonder why dpdk itself was "lost" [19:06] cpaelzer, its only a build-time depends atm [19:07] Right, it's not a runtime dep of anything in main, nor is it seeded, so universe is correct. [19:07] it was pulled into main by the ovs source package, but only used by the -dpdk binary package [19:07] jamespage: If the intent is to support ovs-dpdk, seeding that is your path of least resistance. [19:07] so was I right to assume that it was lost due to the changes to the archive regarding build dependencies? [19:07] infinity, that is the intent yes - I'll add it to the supported seed now [19:08] the intend was to support that [19:08] thank you jamespage [19:08] and thanks infinity for clarifying [19:10] cpaelzer, infinity: done [19:10] jamespage: thanks [19:12] infinity: did you figure out what was up with the images or is that a job for today? [19:14] davmor2: cjwatson sorted it out, a fresh batch is being attempted right now. [19:14] infinity: nice one so hopefully in the morning we should have new images then? [19:15] davmor2: Or right now. [19:15] davmor2: I see 20160411.2 [19:16] infinity: yeah but I finish now so I don't care till the morning ;) [19:16] davmor2: Well, they'll still be there in the morning. :P [19:16] infinity: just happy to have images again \o/ good work everyone :) [19:44] final 2.0 release ^ [21:55] so someone appears to have bulk-downgraded the packages that were in components-mismatches [21:55] wat [21:55] example? [21:55] doko: was this you? [21:56] should be visible in publishinghistory [21:56] cjwatson: libiberty would be an example [21:56] https://launchpad.net/ubuntu/+source/libiberty/+publishinghistory doesn't show a downgrade [21:57] better example? :) [21:57] cjwatson: it doesn't? main->universe? [21:57] oh that sort of downgrade! [21:57] I thought you meant version [21:57] ah no [21:57] sorry, 'demotion' [21:57] but it doesn't tell me who did it [21:59] and at least the discussion we had here concluded we wanted two sets of eyeballs to sanity check before demoting [21:59] and libiberty is one I know it *wasn't* sane to demote, because it only builds a static lib and needs to be in Built-Using [22:01] apw, infinity, RAOF, arges, Daviey, jdstrand, pitti, doko, stgraber, wgrant: did any of you mass-demote the packages that were listed on component-mismatches? [22:01] wasn't me [22:01] I did see the discussion last week and agree that we need to take a close look before demoting stuff :) [22:11] ok looks like it was pitti :) [23:04] slangasek: I'm preparing to rage-upload for bugs 1569077 and 1528710, fyi... [23:04] bug 1528710 in python-django (Ubuntu) "overly agressive URLField validation causes failures" [Medium,Confirmed] https://launchpad.net/bugs/1528710 [23:04] bug 1569077 in python-formencode (Ubuntu) "Incorrect regex for TLDs causes locally defined TLDs to be rejected" [Critical,New] https://launchpad.net/bugs/1569077 [23:18] just in case the archive team did not have enough to do [23:20] lamont: well I assume that's bugfix, or else you would have asked for an FFe [23:30] slangasek: yes. silly upstreams keep breaking my entire environment [23:30] kindly, django already called it a regression and fixed it in 1.8.10, so I'm just backporting that fix to 1.8.7 [23:33] slangasek: the one I already discussed with infinity is the postfix 3.1.0-2 upload that I will do in a (today). Upstream is far more pedantic than I, and everything in 3.1.0 (vs 3.0.4) is either a bugfix we'd want to backport, or a bugfix that we need to backport [23:34] but I need to re-review the list before I so assert