| === JanC is now known as Guest15321 | ||
| === JanC_ is now known as JanC | ||
| sergiusens | slangasek how do I get autopackage tests running for a bileto ticket? | 02:59 |
|---|---|---|
| sergiusens | cjwatson: hey, sorry to bother about click, but does "E: 10mount: mount: unknown filesystem type 'overlayfs'" ring a bell? (from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/c/click/20170607_053103_91658@/log.gz) | 10:06 |
| cjwatson | sergiusens: A new and exciting failure mode I haven't seen before! | 10:06 |
| cjwatson | sergiusens: Might just be that the armhf autopkgtest nodes don't support that; possibly worth checking with Laney regarding what's sensible there | 10:07 |
| sergiusens | great, I haven't checked the armhf logs yet, this is amd64, but thanks for the pointer | 10:08 |
| cjwatson | err | 10:08 |
| cjwatson | yes, that one | 10:08 |
| cjwatson | if necessary we could disable the click chroot tests | 10:08 |
| sergiusens | cjwatson: that sounds good as regression testing of click for perl seems to have the same failures | 10:09 |
| cjwatson | or check whether overlayfs is available before running them, perhaps | 10:09 |
| Laney | Huh | 10:09 |
| cjwatson | overlayfs is probably needed by the schroot tests too though? | 10:09 |
| cjwatson | or sbuild or something like that | 10:09 |
| sergiusens | under perl on update_excuses -> autopkgtest for click/0.4.45.1+16.10.20160916-0ubuntu1: amd64: Ignored failure, armhf: Always failed, i386: Ignored failure, ppc64el: Ignored failure, s390x: Pass | 10:11 |
| cjwatson | or possibly it should just be "modprobe overlayfs" or whatever at the start of the test ... | 10:24 |
| sergiusens | cjwatson: sorry for being obtuse, but modprobe overlay or overlayfs; also after that maybe an equivalent in the test code to `grep -qw overlay /proc/filesystems` ? | 10:26 |
| Laney | I don't have a thing called overlayfs in /proc/filesystems, or a module called overlayfs on my 17.04 laptop here | 10:26 |
| Laney | do have 'overlay' though | 10:26 |
| Laney | didn't get renamed, did it? | 10:26 |
| sergiusens | which is why I ask -> /lib/modules/4.11.0-3-generic/kernel/fs/overlayfs/overlay.ko | 10:27 |
| cjwatson | click.chroot has union-type=overlayfs in schroot | 10:28 |
| cjwatson | so if there's a compat problem here then it's surely also a compat problem for some real users | 10:28 |
| sergiusens | cjwatson: so what would your suggestion be then? | 10:34 |
| cjwatson | I don't have one, just trying to bound the problem | 10:37 |
| sergiusens | cjwatson: seems stgraber already ran into this (2 years ago) https://github.com/lxc/lxc/issues/389 and they treat it as just a name change | 10:52 |
| cjwatson | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808387 is loosely related | 10:55 |
| ubottu | Debian bug 808387 in src:schroot "[schroot] Add support for overlay mounts." [Wishlist,Open] | 10:55 |
| cjwatson | suggests there's some extra work needed in schroot | 10:56 |
| cjwatson | hmm, sbuild-createchroot just does union-type=overlay though | 10:57 |
| cjwatson | sergiusens: maybe just try http://paste.ubuntu.com/24800036/ ? | 11:01 |
| cjwatson | sergiusens: (will at best only work for >= yakkety, so probably don't SRU that bit if you can avoid it) | 11:02 |
| sergiusens | cjwatson: are you ok with something like http://paste.ubuntu.com/24800080/ + the debian/control change? | 11:18 |
| cjwatson | sergiusens: yeah, I guess so | 11:34 |
| sergiusens | cjwatson: I created https://code.launchpad.net/~sergiusens/click/schroot_configuration_overlay_detection/+merge/325234 | 11:39 |
| cjwatson | sergiusens: approved. fix your bzr configuration :) | 11:41 |
| sergiusens | oh, not again... | 11:41 |
| sergiusens | I have a darn test that break my bzr config | 11:41 |
| cjwatson | you want that fixture that sets a separate bzr home | 11:42 |
| cjwatson | actually even just something like this should work fine: | 11:43 |
| cjwatson | bzr_home = self.useFixture(TempDir()).path | 11:43 |
| cjwatson | self.useFixture(EnvironmentVariable('BZR_HOME', bzr_home)) | 11:43 |
| cjwatson | self.useFixture(EnvironmentVariable('BZR_EMAIL')) | 11:43 |
| cjwatson | self.useFixture(EnvironmentVariable('EMAIL')) | 11:43 |
| cjwatson | (from launchpad-buildd) | 11:43 |
| sergiusens | oh, thanks, will bring that in | 11:44 |
| === juergh_ is now known as juergh | ||
| gQuigs | vtapia: can we get sssd back to phasing of 0 so no one else gets it? (re: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508) | 16:02 |
| ubottu | Launchpad bug 1566508 in sssd (Ubuntu Trusty) "autofs races with sssd on startup" [Medium,In progress] | 16:02 |
| gQuigs | (regression bug: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1695870) | 16:03 |
| ubottu | Launchpad bug 1695870 in sssd (Ubuntu) "[regression] sssd won't start if autofs is not installed" [Undecided,Confirmed] | 16:03 |
| sergiusens | slangasek: any idea who can help me with https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/c/click/20170607_145035_9dff8@/log.gz ? is overlay loaded at all in the testbed and should I just modprobe it in? This has been failing since zesty closed/artful opened | 16:08 |
| vtapia | gQuigs: yes. The fix is in verified in -proposed, but it still has to wait 6 more days | 16:25 |
| gQuigs | vtapia: don't we usually pull the previous update when it's a clear regression? | 16:31 |
| gQuigs | (and critical..) | 16:32 |
| vtapia | gQuigs: first regression I had to deal with, so I just created a patch thinking it would bypass the 7 days wait | 16:32 |
| jbicha | vtapia: you can ask in #ubuntu-release for an exception, the 7-day rule is a guideline not a mandatory rule | 16:36 |
| vtapia | ah, ok, thanks jbicha | 16:36 |
| === JanC_ is now known as JanC | ||
| mwhudson | jbicha: congrats | 17:55 |
| jbicha | thank you | 17:56 |
| nacc | xnox: if you have some cycles, could you look at the journal just posted at LP: #1569925 -- it feels like open-iscsi.service After=iscsid.service is not resulting in open-iscsi.service being shutdown before iscsid.service? | 18:08 |
| ubottu | Launchpad bug 1569925 in systemd (Ubuntu) "Shutdown hang on 16.04 with iscsi targets" [High,Confirmed] https://launchpad.net/bugs/1569925 | 18:08 |
| === nelhage_ is now known as nelhage | ||
| === tvoss_ is now known as tvoss | ||
| === ulkesh_ is now known as ulkesh | ||
| xnox | nacc, *sigh* | 21:35 |
| xnox | nacc, i claim there are ordering bugs in systemd in xenial. | 21:36 |
| ginggs | any ideas why gcc would recently start warning about stuff changing in GCC 7.1 on armhf only? it trips up autopkgtests that don't expect output on stderr. e.g. glbinding, ciftilib, fast5 | 21:39 |
| infinity | ginggs: I assume because that incoming change is only on ARM. | 21:41 |
| nacc | xnox: yeah :) | 21:41 |
| ginggs | infinity: ah, so what's the solution here? ignore the test failures, or patch the packages to allow output on stderr? | 21:42 |
| ginggs | or shut gcc up? | 21:42 |
| infinity | ginggs: I imagine the right answer is to not produce the warning, or rebuilds with gcc 7.1 will fail. But doko's looking into it right now. | 21:44 |
| infinity | doko: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/fast5/20170603_001528_9d44b@/log.gz | 21:44 |
| infinity | ginggs: Not looking into fixing the packages, but what the warning is all about. :P | 21:44 |
| ginggs | infinity: thanks. doko: o/ | 21:45 |
| doko | ginggs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 | 21:47 |
| ubottu | gcc.gnu.org bug 77728 in target "[5 Regression] Miscompilation multiple vector iteration on ARM" [Normal,New] | 21:47 |
| doko | ginggs: it's an architecture specific warning | 21:52 |
| ginggs | doko: so the actual issue is fixed in 7.1 and the gcc 6 just prints the warning? | 21:55 |
| doko | yes | 21:56 |
| infinity | Which means the code needs to be fixed to not throw the warning before we switch to gcc-7. | 21:57 |
| ginggs | infinity: i thought it was warning of an abi change | 21:58 |
| ginggs | the bug was in gcc | 21:58 |
| infinity | Oh, perhaps just that. Yes. | 22:00 |
| infinity | Well, "just". | 22:00 |
| ginggs | ok, so what can we do about packages built with gcc 6 that are failing tests now because of the warning? can we make gcc not warn about that? | 22:01 |
| infinity | -Wno-psabi | 22:02 |
| infinity | Or we can skip the tests for now, if that's the only failure. | 22:02 |
| infinity | Which might be preferable to reuploading to ignore warnings. | 22:02 |
| ginggs | could we pass -Wno-psabi from dpkg? | 22:03 |
| infinity | ginggs: A) Ick, B) It wouldn't fix the one I'm looking at, which doesn't use dpkg-buildflags. | 22:04 |
| doko | -Wno-psabi covers more than that | 22:04 |
| infinity | Yeah. | 22:04 |
| infinity | I think identifying the failing tests and skipping them for now is the answer for today. | 22:04 |
| infinity | As in hinting them, not uploading changes. | 22:05 |
| infinity | Well, or fix the code in question to not trip the warning in the first place, so it won't have an ABI change between 6 and 7. But that would likely just change its ABI today instead. :P | 22:06 |
| ginggs | infinity: ack. p.s. have you looked at my mail about archive admin, do you need me to send it again? | 22:08 |
| ginggs | infinity: i still don't see that the packages need to be fixed. i read it that the caller and the callee both need to be compiled with 7.1 | 22:12 |
| infinity | ginggs: Not saying they need to be "fixed", just that if they were changed, they could avoid the issue. | 22:13 |
| infinity | ginggs: But indeed, the sanest plan of action is to find all of the packages in this state, record them, and make sure we do ABI transitions for them when 7 is the default. | 22:14 |
| infinity | ginggs: As for the AA thing, I've spent a long time waffling on it. | 22:15 |
| ginggs | but as you say, they can avoid an ABI change with gcc 7.1, by having an ABI change now | 22:15 |
| infinity | ginggs: For now, I think if you've spotted packages with this issue, I should just hint some badtests and move on. | 22:16 |
| ginggs | is there a good place on the wiki to record these packages? | 22:19 |
| infinity | ginggs: Not currently. Could create an ArmGcc7AbiTransition page or something if you want. | 22:33 |
| nacc | xnox: do you have any hints of where to look? I'd be happy to help try and resolve it -- and also in that bug, we have two people hitting (at least related issues), and are very responsive to test | 23:01 |
| xnox | nacc, does it work in artful correctly? | 23:02 |
| nacc | xnox: i'm not sure -- i'll ask if they can test | 23:25 |
| === blahdeblah_ is now known as blahdeblah | ||
| sergiusens | slangasek: if you have a minute I need someone with access to click here: https://bileto.ubuntu.com/log/2790/finalize/ | 23:56 |
| slangasek | sergiusens: clicked | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!