[00:30] <slangasek> 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] <ypwong> cyphermox, we found a serious issue in grub that worth a look: https://bugs.launchpad.net/ubuntukylin/+bug/1559933
[02:22] <ubot5`> 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] <tyhicks> 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] <tyhicks> pitti, stgraber: I see the same failure when running the lxc tests locally without a the new apparmor
[03:31] <stgraber> hmm, so something happened with simplestreams over the last few days which broke that test
[03:31] <stgraber> but indeed, unlikely to have been caused by the apparmor upload
[03:33] <tyhicks> thanks for the confirmation
[03:34] <stgraber> I'm assuming you attempted a retry of the test already?
[03:34] <tyhicks> yes
[03:34] <tyhicks> twice on amd64 and i386
[03:34] <tyhicks> both sets of retries failed
[03:40] <stgraber> doing a local adt run here as a simple lxc-create does work fine for me
[03:45] <stgraber> well, adt is crashing here (as in the tool) so not much luck with it, will let pitti figure it out
[04:30] <stgraber> 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] <tyhicks> stgraber: ok, thanks for looking into that - I don't guess there's anything that I can do on my end
[04:32] <stgraber> 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] <stgraber> might have been a firewall or proxy change in scalingstack, I'm sure pitti will take a look once he's around
[04:33] <tyhicks> stgraber: I did do a local adt-run and saw the same failure
[04:33] <stgraber> oh, odd
[04:33] <stgraber> PASS: lxc-tests: /usr/bin/lxc-test-ubuntu
[04:33] <stgraber> just got that 5min ago
[04:34] <tyhicks> my run was ~2 hours ago (without the new apparmor)
[04:34] <stgraber> adt-run -U --apt-pocket=proposed lxc --- adt-virt-qemu adt-xenial-amd64-cloud.img
[04:34] <stgraber> that's what I ran here
[04:35] <tyhicks> I'll give that a try in a bit
[04:37] <stgraber> also odd that it doesn't affect ppc64el
[04:40] <tyhicks> agreed
[05:15] <stgraber> pitti: looks like ppc64el adt is kinda stuck, had a lxd adt stuck on nova create for a while now
[05:46] <stgraber> tyhicks: btw, another adt retry for lxc just passed, so if that was the only blocker, apparmor will migrate very soon
[05:55] <pitti> 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] <pitti> lxc seems happy again
[05:56] <stgraber> pitti: looks like ppc64el adt for lxd also got unblocked, package just migrated now
[05:57] <pitti> yeah, but that looks relatively stable (http://autopkgtest.ubuntu.com/packages/l/lxd/xenial/ppc64el/)
[05:58] <stgraber> yeah, just not sure why it was seemingly stuck for over half an hour on nova create
[05:58] <tyhicks> 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] <pitti> stgraber: pretty much everything has a timeout, I guess it timed out, and auto-retried
[05:59] <pitti> tyhicks: yes, that's the thing I meant above 4 mins ago
[05:59]  * pitti shakes fists at lcy01
[05:59] <tyhicks> pitti: ah, I missed that message, sorry!
[06:03] <pitti> tyhicks: I hinted apparmor for now to unblock this
[06:03] <tyhicks> pitti: thank you!
[07:51] <lordievader> Good morning.
[08:11] <davmor2> jibel, cyphermox, slangasek, seb128: hmmm no image today?
[08:12] <infinity> davmor2: Need a bit more verbosity.
[08:13] <davmor2> 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] <davmor2> infinity: current image is based on the 8th
[08:15] <rbasak> Launchpad was down briefly last night. Related?
[08:16] <infinity> No.  Today's just exploded too.
[08:16] <rbasak> 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] <davmor2> infinity: you understand my asking now right :)
[08:16] <ubot5`> Debian bug 811068 in libgda5 "FTBFS: FAIL: check_vcnc: ../../test-driver: line 107: 77018 Aborted" [Serious,Open]
[08:17] <rbasak> Old libgda5 was building against an older sqlite. Rebuilding it even with my patch may regress it.
[08:17] <rbasak> The source would only be made better, but the binary may regress from the perspective of a user.
[11:28] <jamespage> ^^ that swift upload should resolved the autopkgtest failure that's blocking 2.7.0 from the release pocket...
[14:28] <rbasak> ^ will (should?) dep-wait without mysql-connector-c++
[14:28] <rbasak> (he says to the mystery person accepting his stuff)
[14:37] <rbasak> Oh, the mystery person being the unseeded auto-accept.
[14:39] <teward> heheh, rbasak
[15:16] <cyphermox> stgraber: since you cared about it before to review: ^
[15:17] <cyphermox> 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] <cyphermox> infinity: remember my cpc merge for ubuntu-cdimage?
[15:31] <stgraber> cyphermox: looking
[16:06] <Mirv> ^ 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] <Mirv> 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] <xnox> infinity, cjwatson - why you hate UTF-8 on s390x? Looking at buildds, all arches are now on UTF-8, apart from s390x
[16:09] <xnox> cause on s390x in addition to LANG=C.UTF-8, there is also LC_ALL=POSIX which trumps the UTF-9-ness
[16:09] <xnox> cause on s390x in addition to LANG=C.UTF-8, there is also LC_ALL=POSIX which trumps the UTF-8-ness
[16:11] <cjwatson> bluff
[16:11] <cjwatson> sbuild-package:export LANG=C.UTF-8 LC_ALL=C.UTF-8 LANGUAGE=
[16:13] <cjwatson> unless sbuild hates us lots, which is possible
[16:13] <cjwatson>     $host_defaults->{'ENV'}->{'LC_ALL'} = 'POSIX';
[16:14] <cjwatson> that line dates from 2010 though
[16:15] <cjwatson> oh I don't know, please puzzle something out, I need to think about SSO stuff
[16:15] <xnox> =)
[16:15] <xnox> cjwatson, https://youtu.be/IXmF4GbA86E
[16:16] <xnox> oh wait you said SSO, not SOS =) oh well.
[16:17] <xnox> 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] <xnox> 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] <cjwatson> can't be the host
[16:18] <cjwatson> I mean except for xenial's sbuild
[16:19] <cjwatson> and "grep -rs POSIX /etc" has nothing of interest
[16:21] <cjwatson> I strongly suspect xenial's sbuild, just can't easily prove it right now
[16:24] <xnox> ack.
[18:53] <cpaelzer> 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] <cpaelzer> in particular all of dpdk and openvswitch-switch-dpdk
[18:53] <cpaelzer> what would be the appropriate way to address that?
[19:02] <infinity> cpaelzer: openvswitch-switch-dpdk was never in main...
[19:04] <cpaelzer> infinity: I'll have to clarify that with jamespage tomorrow then
[19:05] <cpaelzer> the changes made by doko back then wehn bug 1492186 was closed seem to be lost
[19:05] <jamespage> cpaelzer, infinity: I'm still here
[19:05] <ubot5`> bug 1492186 in dpdk (Ubuntu) "[MIR] dpdk" [High,Fix released] https://launchpad.net/bugs/1492186
[19:05] <jamespage> and it was never in main - that's quite correct
[19:05] <cpaelzer> but dpdk was, the bug even holds the "override component to main"
[19:05] <cpaelzer> I wonder what was lost
[19:05] <jamespage> cpaelzer, infinity: that said it is build from a main source package, so I can seed if if thats OK
[19:06] <jamespage> that would pull the runtime dpdk bits back into main
[19:06] <cpaelzer> jamespage: IIRC you intended bring in openvswitch-switch-dpdk anyway
[19:06] <cpaelzer> yet I wonder why dpdk itself was "lost"
[19:06] <jamespage> cpaelzer, its only a build-time depends atm
[19:07] <infinity> Right, it's not a runtime dep of anything in main, nor is it seeded, so universe is correct.
[19:07] <jamespage> it was pulled into main by the ovs source package, but only used by the -dpdk binary package
[19:07] <infinity> jamespage: If the intent is to support ovs-dpdk, seeding that is your path of least resistance.
[19:07] <cpaelzer> so was I right to assume that it was lost due to the changes to the archive regarding build dependencies?
[19:07] <jamespage> infinity, that is the intent yes - I'll add it to the supported seed now
[19:08] <cpaelzer> the intend was to support that
[19:08] <cpaelzer> thank you jamespage
[19:08] <cpaelzer> and thanks infinity for clarifying
[19:10] <jamespage> cpaelzer, infinity: done
[19:10] <cpaelzer> jamespage: thanks
[19:12] <davmor2> infinity: did you figure out what was up with the images or is that a job for today?
[19:14] <infinity> davmor2: cjwatson sorted it out, a fresh batch is being attempted right now.
[19:14] <davmor2> infinity: nice one so hopefully in the morning we should have new images then?
[19:15] <infinity> davmor2: Or right now.
[19:15] <infinity> davmor2: I see 20160411.2
[19:16] <davmor2> infinity: yeah but I finish now so I don't care till the morning ;)
[19:16] <infinity> davmor2: Well, they'll still be there in the morning. :P
[19:16] <davmor2> infinity: just happy to have images again \o/ good work everyone :)
[19:44] <stgraber> final 2.0 release ^
[21:55] <slangasek> so someone appears to have bulk-downgraded the packages that were in components-mismatches
[21:55] <cjwatson> wat
[21:55] <cjwatson> example?
[21:55] <slangasek> doko: was this you?
[21:56] <cjwatson> should be visible in publishinghistory
[21:56] <slangasek> cjwatson: libiberty would be an example
[21:56] <cjwatson> https://launchpad.net/ubuntu/+source/libiberty/+publishinghistory doesn't show a downgrade
[21:57] <cjwatson> better example? :)
[21:57] <slangasek> cjwatson: it doesn't?  main->universe?
[21:57] <cjwatson> oh that sort of downgrade!
[21:57] <cjwatson> I thought you meant version
[21:57] <slangasek> ah no
[21:57] <slangasek> sorry, 'demotion'
[21:57] <slangasek> but it doesn't tell me who did it
[21:59] <slangasek> and at least the discussion we had here concluded we wanted two sets of eyeballs to sanity check before demoting
[21:59] <slangasek> 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] <slangasek> 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] <stgraber> wasn't me
[22:01] <stgraber> I did see the discussion last week and agree that we need to take a close look before demoting stuff :)
[22:11] <slangasek> ok looks like it was pitti :)
[23:04] <lamont> slangasek: I'm preparing to rage-upload for bugs 1569077 and 1528710, fyi...
[23:04] <ubot5`> bug 1528710 in python-django (Ubuntu) "overly agressive URLField validation causes failures" [Medium,Confirmed] https://launchpad.net/bugs/1528710
[23:04] <ubot5`> 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] <mwhudson> just in case the archive team did not have enough to do
[23:20] <slangasek> lamont: well I assume that's bugfix, or else you would have asked for an FFe
[23:30] <lamont> slangasek: yes.  silly upstreams keep breaking my entire environment
[23:30] <lamont> 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] <lamont> 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] <lamont> but I need to re-review the list before I so assert