| === phunyguy is now known as phunyguys | ||
| === phunyguys is now known as phunyguy | ||
| === mwsb is now known as chu | ||
| 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 | 07:33 |
|---|---|---|
| === maclin1 is now known as maclin | ||
| cpaelzer | pitti: hi, I see in the autopkgtest history of systemd that the "storage" test failed rather often on ppc64el | 09:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| pitti | cpaelzer: y and x seem fine, so might be a regression of linux 4.11? | 09:19 |
| 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:20 |
| pitti | so apparently 4.10 got promoted with ignoring that regression :( | 09:21 |
| cpaelzer | smb: ^^ did you hear (or could you ask around in the kernel team) anything about this? | 09:22 |
| smb | cpaelzer, a) no b) might do | 09:23 |
| 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 | 09:24 |
| === shadeslayer_ is now known as shadeslayer | ||
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| pitti | xnox: armhf buildds are the same: armhf chroots on the exact same kind of arm64 cloud instances | 10:37 |
| 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:38 |
| 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:39 |
| 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:52 |
| pitti | cpaelzer: nice work! | 10:54 |
| 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 | 11:16 |
| === 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 | ||
| 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:41 |
| rbasak | coreycb: you still haven't reported the package versions you tested? | 13:47 |
| rbasak | coreycb: doing it automatically is fine, but surely that automation provides that information in its output? | 13:48 |
| 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:49 |
| 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:50 |
| coreycb | rbasak, ok i've added the versions tested | 13:53 |
| rbasak | Thanks I'll take a look. | 13:53 |
| coreycb | rbasak, thanks | 13:54 |
| 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:11 |
| coreycb | rbasak, sure | 14:12 |
| 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:18 |
| rbasak | Done | 14:20 |
| 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:23 |
| 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:26 |
| 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:27 |
| coreycb | rbasak, ok yes that makes sense. thanks. | 14:30 |
| tyhicks | cpaelzer: thanks for the headsup on that bug | 15:44 |
| 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:46 |
| xnox | but we have also been fixing the tests to come up the right way around. | 15:47 |
| xnox | (in other openstack components) | 15:47 |
| 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:52 |
| cpaelzer | tyhicks: fyi the fix is enqueued for the next kernel upload already | 15:53 |
| tyhicks | cool, that is helpful | 15:54 |
| === maclin1 is now known as maclin | ||
| smoser | Laney, you tyhere? | 17:09 |
| === dosaboy_ is now known as dosaboy | ||
| Laney | hey smoser | 17:09 |
| Laney | for you, always! | 17:09 |
| smoser | your changtes are good. | 17:10 |
| 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:11 |
| Laney | smoser: ok, as you prefer | 17:12 |
| Laney | MP mail sucks, eh? | 17:12 |
| smoser | just slow. | 17:14 |
| smoser | i didnt see yours | 17:14 |
| Laney | bit of a shame that we both spent time debugging it, but eh | 17:15 |
| Laney | you go ahead | 17:15 |
| 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:16 |
| 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:17 |
| caribou | s/manging/mangling/ | 17:18 |
| caribou | I stripped the modification of the i18n .po files out of the debdiff btw | 17:19 |
| 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:20 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:30 |
| 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 | 17:31 |
| 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:11 |
| sarnold | nacc: good question | 18:12 |
| sarnold | nacc: yes | 18:12 |
| nacc | sarnold: ok, thanks -- the debian report seems for an older version, so just wanted to double-check | 18:13 |
| 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:09 |
| 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:10 |
| cpaelzer | nacc: ok, I put it on my list | 19:18 |
| nacc | cpaelzer: thanks! | 19:18 |
| === circ-user-GR6Me is now known as stryderc | ||
| stryderc | anybody here able to point me on the path to discerning the logic behind the Dash type down filtering? | 19:34 |
| 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] | 19:41 |
| 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:02 |
| rharper | slangasek: I don't know for certain; let me read a bit more | 20:03 |
| 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:04 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| * slangasek nods | 20:17 | |
| === mwsb is now known as chu | ||
| 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 | 20:58 |
| slangasek | nacc: yeah, I would say that should get a look-sie for an FFe | 21:08 |
| smoser | hey. in zesty, the libc6-x32 is supposed to "just work" for 32 bit libc stuff ? | 21:16 |
| smoser | i have a executable that works on 32 bit. | 21:17 |
| smoser | $ ldd /usr/bin/brprintconf_mfc9125cnlinux-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:17 |
| 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:18 |
| smoser | i just dont want to add the 32 bit arch to dpkg. | 21:19 |
| === cpu1_ is now known as cpu1 | ||
| smoser | well, libc6-i386 worked for me. | 21:23 |
| smoser | and didn't need foreign arch | 21:24 |
| smoser | slangasek, my cloud-init uploads are back in the xenial and yakkety queue now. | 21:41 |
| jgrimm | \o/ | 21:47 |
| nacc | slangasek: ack, thank you! | 21:55 |
| 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:10 |
| sarnold | rbasak: <3 1610765 :) | 23:13 |
| nacc | sarnold: ah thanks! | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!