=== phunyguy is now known as phunyguys
=== phunyguys is now known as phunyguy
=== mwsb is now known as chu
[07:33] <pitti> xnox: hmm, systemd's new "root-unittest" fails on armhf in test-copy; it works on s390x in lxc, so I wonder if that's an artifact of lxd or an actual bug on armhf; perhaps you can have a quick look what's going wrong, otherwise I'm happy enough to blacklist the test on armhf or lxd (whichever is right) for now
=== maclin1 is now known as maclin
[09:14] <cpaelzer> pitti: hi, I see in the autopkgtest history of systemd that the "storage" test failed rather often on ppc64el
[09:15] <cpaelzer> pitti: I' currently ran into the same as well, since it failed/worked so often without any visible difference - are these just "retried until passing"
[09:15] <cpaelzer> pitti: or is there some background to learn?
[09:15] <cpaelzer> FYI - issues like in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/ppc64el/s/systemd/20170306_005811_4a060@/log.gz
[09:16] <pitti> cpaelzer: indeed, "reload ioctl on temporary-cryptsetup-5254 failed" -- that ioctl seems to be unreliable in cryptsetup somehow
[09:16] <pitti> that should be easy enough to reproduce outside the systemd test suite too, for a kernel bug report
[09:17] <pitti> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/tests/storage#n74 is the cryptsetup luksFormat call
[09:17] <cpaelzer> pitti: ok, so in proposed retrying til pass and in a test env trying to debug and understand
[09:17] <cpaelzer> pitti: thanks
[09:18] <cpaelzer> depending which of both is faster the debugging might resolve the retrying :-)
[09:18] <pitti> the test uses scsi_debug as a drive, I suggest to try with both that and a simple loop device to see whether that makes a difference
[09:18] <cpaelzer> thank you, I will do so
[09:19] <pitti> cpaelzer: y and x seem fine, so might be a regression of linux 4.11?
[09:20] <pitti> actually it started failing with trigger linux-meta/4.10.0.8.10
[09:20] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/ppc64el/s/systemd/20170217_024850_73931@/log.gz was the last successful one, with autopkgtest [01:48:28]: testbed running kernel: Linux 4.9.0-15-generic #16-Ubuntu SMP Fri Jan 20 15:28:49 UTC 2017
[09:20] <cpaelzer> yeah I see that this was the "date" it started
[09:20] <pitti> i. e. 4.9 → 4.10
[09:20] <cpaelzer> former fails had other errors
[09:21] <pitti> so apparently 4.10 got promoted with ignoring that regression :(
[09:22] <cpaelzer> smb: ^^ did you hear (or could you ask around in the kernel team) anything about this?
[09:23] <smb> cpaelzer, a) no b) might do
[09:24] <cpaelzer> smb: ok, once (if) I have found a bit more debug data I'll show up in the kernel Teams chan as well then
=== shadeslayer_ is now known as shadeslayer
[10:30] <bdrung_work> hi, since a recent ubuntu 16.10 package update, the mod4 keyboard layer does not work any more for numbers. e.g. when i press mod4+j, it should result in number 4, but the mouse moves instead. do you have any hint at which package i should look at for this behaviour?
[10:30] <bdrung_work> mod4 works correctly on the lightdm
[10:31] <xnox> pitti, we have started to whitelist systemd/armhf failures which are only seen during adt tests but not during package build time
[10:31] <bdrung_work> (i am using the german neo2 layout)
[10:32] <xnox> pitti, i have not debugged it yet, and my wild guess that it has something to do with the fact that we run those on arm64 hardware
[10:32] <xnox> (arm64 kernel)
[10:33] <pitti> xnox: more interestingly, we run the unittests as root during that autopkgtest but as user during package build, so they skip a lot of stuff
[10:37] <pitti> xnox: armhf buildds are the same: armhf chroots on the exact same kind of arm64 cloud instances
[10:38] <xnox> pitti, aha, so that test has never run (on builders); and always failed (during adt); hence steve considered it as a non-regression
[10:38] <pitti> right, that's plausible
[10:38] <xnox> so it can be treated as "you shall never pass" unit test. Should be digged into why not, though.
[10:38] <pitti> but would still be interesting to see what fails, to make sure it's just an lxd limitation and not an actual bug somewhere
[10:39] <xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1670313
[10:39] <ubottu> Launchpad bug 1670313 in systemd (Ubuntu) "armhf unit tests as root fail on adt tests, never run on builders" [Medium,Confirmed]
[10:52] <cpaelzer> pitti: for the systemd ppc test error after some debugging I can confirm a kernel bug which I reported in bug 1670311
[10:52] <ubottu> bug 1670311 in linux (Ubuntu) "aes-xts and aes-cbc failing to initialize on power since 4.10" [Undecided,New] https://launchpad.net/bugs/1670311
[10:54] <pitti> cpaelzer: nice work!
[11:16] <cpaelzer> tyhicks: FYI bug 1670311 also blocks your latest apparmor in zesty-proposed
[11:16] <ubottu> bug 1670311 in linux (Ubuntu) "aes-xts and aes-cbc failing to initialize on power since 4.10" [Critical,Confirmed] https://launchpad.net/bugs/1670311
=== hikiko is now known as hikiko|ln
=== freyes__ is now known as freyes
=== _salem is now known as salem_
=== hikiko|ln is now known as hikiko
=== maclin1 is now known as maclin
[13:41] <coreycb> rbasak, hi, I responded to bug 1645772
[13:41] <ubottu> bug 1645772 in ironic (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Incomplete] https://launchpad.net/bugs/1645772
[13:47] <rbasak> coreycb: you still haven't reported the package versions you tested?
[13:48] <rbasak> coreycb: doing it automatically is fine, but surely that automation provides that information in its output?
[13:49] <rbasak> "If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested..."
[13:49] <coreycb> rbasak, thanks i've tested sru's before :) i'll add the versions tested.
[13:50] <rbasak> coreycb: thanks. I'm not asking just for the sake of it. I have been involved in at least one severe stable release regression in the past when the package version tested wasn't the one released. I don't want to be responsible for causing that kind of thing.
[13:50] <rbasak> coreycb: and I figure that our process is good enough to detect that, if only we all followed the process. So I insist on it.
[13:53] <coreycb> rbasak, ok i've added the versions tested
[13:53] <rbasak> Thanks I'll take a look.
[13:54] <coreycb> rbasak, thanks
[14:11] <rbasak> coreycb: there are some autopkgtest failures in pending-sru on s390x - please could you check? http://autopkgtest.ubuntu.com/packages/n/neutron/yakkety/s390x
[14:11] <rbasak> Only for neutron.
[14:12] <coreycb> rbasak, sure
[14:18] <rbasak> coreycb: I'm happy to release the others now if you would like.
[14:18] <rbasak> (or I can wait until you've checked/fixed neutron)
[14:18] <coreycb> rbasak, sure that'd be fine.  I'll let you know when neutron is fixed.
[14:18] <rbasak> OK
[14:20] <rbasak> Done
[14:23] <coreycb> rbasak, thanks.  if i upload a new version of neutron with a dep8 test fix, should i use a new bug # or use the sru bug #?
[14:26] <rbasak> coreycb: no need for a bug and paperwork for a dep8 fix. So don't refer to a bug at all in your new changelog message (unless there is one already). But do use -v when uploading the replacement, so that the new upload still lists the previous bug as fixed.
[14:27] <rbasak> coreycb: so I think you'll be uploading a  2:9.1.1-0ubuntu2, source built with -v2:9.0.0-0ubuntu1.16.10.2, with one changelog entry added over  2:9.1.1-0ubuntu1 and no new bug references. Does that make sense?
[14:30] <coreycb> rbasak, ok yes that makes sense. thanks.
[15:44] <tyhicks> cpaelzer: thanks for the headsup on that bug
[15:46] <xnox> rbasak, coreycb: is this not one more ordering bug of the units; where incorrect dependency/ordering is specified, and things do come up if one simply waits?
[15:47] <xnox> but we have also been fixing the tests to come up the right way around.
[15:47] <xnox> (in other openstack components)
[15:52] <cpaelzer> tyhicks: yw
[15:52] <cpaelzer> tyhicks: I see you have other  blockers as well still
[15:52] <cpaelzer> tyhicks: but at least one less to debug
[15:53] <cpaelzer> tyhicks: fyi the fix is enqueued for the next kernel upload already
[15:54] <tyhicks> cool, that is helpful
=== maclin1 is now known as maclin
[17:09] <smoser> Laney, you tyhere?
=== dosaboy_ is now known as dosaboy
[17:09] <Laney> hey smoser
[17:09] <Laney> for you, always!
[17:10] <smoser> your changtes are good.
[17:11] <smoser> https://code.launchpad.net/~smoser/software-properties/trunk.lp1670399/
[17:11] <smoser> i just did those same changes
[17:11] <smoser> https://code.launchpad.net/~smoser/software-properties/trunk.lp1670399/+merge/319105
[17:11] <smoser> but showed a bit more context. and i like my changesn to run-tests better .
[17:11] <smoser> but lets get this fixed.
[17:12] <Laney> smoser: ok, as you prefer
[17:12] <Laney> MP mail sucks, eh?
[17:14] <smoser> just slow.
[17:14] <smoser> i didnt see yours
[17:15] <Laney> bit of a shame that we both spent time debugging it, but eh
[17:15] <Laney> you go ahead
[17:16] <smoser> yeah
[17:16] <smoser> i open3d a bug.
[17:16] <smoser> did you see that/
[17:16] <Laney> nope
[17:16] <Laney> I don't think it existed on Thursday when I submitted the patch
[17:16] <smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1670399
[17:16] <ubottu> Launchpad bug 1670399 in software-properties (Ubuntu) "dep8 tests are failing in zesty" [High,In progress]
[17:17] <smoser> sorry. slow. i wish i'd seen your mp
[17:17] <Laney> s'ok
[17:17] <caribou> would someone have time to have a look at a small config change to the tftpd-hpa package I'm preparing ? http://paste.ubuntu.com/24125880/
[17:17] <caribou> I haven't done much manging with upgrades of config params
[17:18] <caribou> s/manging/mangling/
[17:19] <caribou> I stripped the modification of the i18n .po files out of the debdiff btw
[17:20] <smoser> Laney, http://paste.ubuntu.com/24125897/
[17:20] <smoser> look goood ?
[17:20] <Laney> smoser: sure, but spell my name right please :P
[17:20] <smoser> no deal
[17:20] <smoser> doh!
[17:23] <smoser> Laney, uploaded. thanks.
[17:23] <seb128> smoser, "This (lp...)"?
[17:23] <seb128> was that missing some text?
[17:23] <seb128> oh well, if it's uploaded
[17:25] <coreycb> rbasak, zul has a new version of neutron in the review queue for yakkety, so if you don't mind rejecting that, i'll upload it again with the dep8 fix.
[17:25] <Laney> yeah it said "fixes a testsuite failure."
[17:25] <Laney> oh well
[17:25] <smoser> seb128, yeah. :-(
[17:25] <smoser> fail smoser
[17:26] <coreycb> xnox, rbasak: i think we need to use needs-recommends in debian/tests/control to ensure neutron-plugin-ml2 is installed.
[17:26] <smoser> i noticed that too
[17:26] <smoser> after dput
[17:30] <rbasak> ddebs missing for some packages on Trusty. IIRC this is a known thing? I have a bug report about it, not sure what to tell the reporter.
[17:30] <rbasak> bug 1668299
[17:30] <ubottu> bug 1668299 in php-json (Ubuntu) "missing debug symbols" [Undecided,Confirmed] https://launchpad.net/bugs/1668299
[17:31] <rbasak> Ah, I found 1465777
[17:31] <rbasak> bug 1465777
[17:31] <ubottu> bug 1465777 in freetype (Ubuntu) "No ddeb for current Trusty updates." [Undecided,Won't fix] https://launchpad.net/bugs/1465777
[18:11] <nacc> sarnold: is LP: #1582990 still an issue for you?
[18:11] <ubottu> Launchpad bug 1582990 in libvirt (Ubuntu) "internal error: End of file from monitor" [Medium,Confirmed] https://launchpad.net/bugs/1582990
[18:12] <sarnold> nacc: good question
[18:12] <sarnold> nacc: yes
[18:13] <nacc> sarnold: ok, thanks -- the debian report seems for an older version, so just wanted to double-check
[19:09] <cpaelzer> nacc: are you working on the bug you asked sarnold about?
[19:09] <cpaelzer> nacc: or were you only cleaning up and I shall put it on my list?
[19:10] <nacc> cpaelzer: was only asking
[19:10] <nacc> cpaelzer: triage duty
[19:10] <nacc> cpaelzer: i figured i'd ping you about it at somep oint
[19:18] <cpaelzer> nacc: ok, I put it on my list
[19:18] <nacc> cpaelzer: thanks!
=== circ-user-GR6Me is now known as stryderc
[19:34] <stryderc> anybody here able to point me on the path to discerning the logic behind the Dash type down filtering?
[19:41] <rharper> jgrimm: slangasek:  In attempting to verify resolvconf for yakkety; ran into an issue; I've updated the comments, looking for agreement on how to resolve; https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649931
[19:41] <ubottu> Launchpad bug 1649931 in resolvconf (Ubuntu Yakkety) "systemd-networkd needs to ensure DNS is up before network-online.target" [Medium,Fix committed]
[20:02] <slangasek> rharper: isn't systemd-resolved entirely an optimization of the DNS config?  Before systemd-resolved comes up, any DNS servers received should just be added to /etc/resolv.conf directly, and DNS resolution should proceed normally
[20:02] <slangasek> systemd-resolved integrates with resolvconf, it doesn't supplant it
[20:03] <rharper> slangasek: I don't know for certain; let me read a bit more
[20:04] <slangasek> rharper: ok.  As far as I'm concerned systemd-resolved should not have to be running before network-online.target
[20:04] <slangasek> i.e. it's not a requirement for DNS resolution - but we might choose to enforce this to work around some issue somewhere
[20:12] <rharper> slangasek: going to confirm but my understanding for yak/zesty is that resolvconf is hook only;  it runs under ifupdown hook, and dhclient (which is for networking/ifupdown services);  in a networkd space, those (ifupdown) hooks don't matter; and systemd-resolved is decorated with pre/post execs to point to systemd-resolved caching namesever (127.0.0.53);
[20:13] <rharper> we'll have nothing in /etc/resolv.conf prior to systemd-networkd coming up; and if that includes DNS settings, I believe those should be applied via having systemd-resolved unit run before we get to network-online.target;
[20:14] <slangasek> rharper: ah.  that's an unfortunate outcome of the lack of support for hooks, yes
[20:14] <slangasek> rharper: in that case, +1 for changing the ordering constraints on systemd-resolved, though I would argue it shouldn't need to hold up the resolvconf change
[20:15] <rharper> slangasek: agreed;  it's been a bit sticky to separate the networking/ifupdown path vs. systemd path since we don't have a non-ifupdown path by default
[20:16] <rharper> the verification has been a matrix of xenial, yakkety * ifupdown/networking,networkd
[20:16] <rharper>  * the two packages involved (systemd and resolvconf)
[20:16] <rharper> and forgetting all of those parts from time to time
[20:17]  * slangasek nods
=== mwsb is now known as chu
[20:58] <nacc> slangasek: Just to confirm, I need a FFe for the fix for LP: #1668940, where we are not b-d on a library that provides the headers needed to build the .so in question -- even though we ship a manpage documenting the feature? That is, it's a feature introduction in practice?
[20:58] <ubottu> Launchpad bug 1668940 in samba (Ubuntu) "samba-vfs-modules misses ceph vfs module" [Medium,Triaged] https://launchpad.net/bugs/1668940
[21:08] <slangasek> nacc: yeah, I would say that should get a look-sie for an FFe
[21:16] <smoser> hey. in zesty, the libc6-x32 is supposed to "just work" for 32 bit libc stuff ?
[21:17] <smoser> i have a executable that works on 32 bit.
[21:17] <smoser>  $ ldd /usr/bin/brprintconf_mfc9125cn	linux-gate.so.1 =>  (0xb770d000)
[21:17] <smoser> 	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7548000)
[21:17] <smoser> 	/lib/ld-linux.so.2 (0x8006d000)
[21:17] <slangasek> smoser: libc6-x32 is for x32 binaries, of which there are approximately zero in the wild
[21:17] <smoser> oh. well, yeah. that'd do it.
[21:18] <slangasek> you preferably want to install libc6:i386 (multiarch cross-install of the i386-arch package)
[21:18] <smoser> i was hoping to avoid i386 packages. and i thiought that might e what that was.
[21:19] <smoser> i just dont want to add the 32 bit arch to dpkg.
=== cpu1_ is now known as cpu1
[21:23] <smoser> well, libc6-i386 worked for me.
[21:24] <smoser> and didn't need foreign arch
[21:41] <smoser> slangasek, my cloud-init uploads are back in the xenial and yakkety queue now.
[21:47] <jgrimm> \o/
[21:55] <nacc> slangasek: ack, thank you!
[23:10] <nacc> rbasak: would you be able to review: LP: #1669831 ?
[23:10] <ubottu> Launchpad bug 1669831 in mysql-5.7 (Ubuntu) "package mysql-server 5.7.17-0ubuntu0.16.04.1 failed to install/upgrade: проблемы зависимостей — оставляем не настроенным" [Undecided,New] https://launchpad.net/bugs/1669831
[23:13] <sarnold> rbasak: <3 1610765 :)
[23:16] <nacc> sarnold: ah thanks!