| === Conan_Kudo is now known as Pharaoh_Atem | ||
| === paride0 is now known as paride | ||
| sahid | sil2100: o/ | 09:20 |
|---|---|---|
| sahid | verification done https://bugs.launchpad.net/nova/+bug/1808951, if you can have a look when you have a moment | 09:21 |
| ubottu | Launchpad bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged] | 09:21 |
| sahid | then we should be able to unblock for testing https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1831754 | 09:22 |
| ubottu | Launchpad bug 1831754 in nova (Ubuntu Disco) "[SRU] stein stable releases" [Undecided,New] | 09:22 |
| sil2100 | sahid: hey! Thanks! Let me try looking at that, but if I don't find time today I'll do it for sure tomorrow during my SRU shift | 09:25 |
| sahid | sil2100: ok thank you, feel free to ping when i can start testing the SRU | 09:25 |
| LocutusOfBorg | Unit193, hello, can you please forward the patch to this bug report? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904660 | 10:36 |
| ubottu | Debian bug 904660 in src:opensips "opensips FTBFS with json-c 0.13.1" [Important,Open] | 10:36 |
| LocutusOfBorg | btw, the real last blocker is syslog-ng, and there is an open Debian RC bug | 10:37 |
| LocutusOfBorg | maintainer should deal with it soon(TM) | 10:37 |
| Unit193 | Well, the Debian maintainer is an upstream maintainer, seems there's new versions too...Also I'd kind of prefer to test a patch more before forwarding to Debian, but I guess I could.. | 10:40 |
| === ricab is now known as ricab|ricab | ||
| === ricab|ricab is now known as ricab | ||
| doko | tkamppeter: re cups ftbfs. of course this is still relevant. the test rebuild was done *after* the build in the archive | 13:35 |
| doko | so citing the archive build doesn't help | 13:36 |
| cking | any idea why autopkgtest is failing with 'Can't exec "gcc": No such file or directory at /usr/share/perl5/Dpkg/Arch.pm line 126.' , see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/z/zfs-linux/20190703_123021_5234a@/log.gz | 14:08 |
| seb128 | juliank, hey, could you look if we can maybe sync lz4 from Debian? It's unclear if the O3/s390x changes are still needed (and if they are, could we sent that to Debian?) | 14:16 |
| juliank | seb128: I'd be more concerned with the other changes | 14:21 |
| juliank | Not sure what V=1 does, it seems useless | 14:22 |
| seb128 | juliank, building with V=1? (why does that need to be an Ubuntu delta?) | 14:22 |
| juliank | But the patch to the examples Makefile is not in Debian | 14:22 |
| seb128 | shouldn't it be upstreamed/sent to Debian? | 14:22 |
| juliank | I'm very confused | 14:22 |
| seb128 | so we can get back in sync | 14:23 |
| juliank | seb128: Well, we can just sync it, and if it FTBFS, we'll see what changes are still needed :) | 14:24 |
| juliank | or rather, if changes are still needed | 14:24 |
| seb128 | that's one way indeed :) | 14:24 |
| seb128 | I prefer to ping before doing that though | 14:25 |
| seb128 | in case you wanted to have a look | 14:25 |
| juliank | I synced, let's see what happens :) | 14:25 |
| seb128 | thx | 14:25 |
| didrocks | cking: hey! thanks for following up on zfs 0.8 upload btw ;) | 14:26 |
| juliank | I mean, with gcc 9 coming soon, things will probably break again anyway | 14:26 |
| cking | didrocks, it would be even better if I can figure out why it's no passing the autopkgtests | 14:26 |
| didrocks | cking: yeah, the error is puzzling, with your second upload, it should have been ok… | 14:27 |
| cking | didrocks, exactly. and it works fine when I run the tests locally | 14:27 |
| didrocks | ofc :/ | 14:27 |
| seb128 | juliank, gcc9 is coming? good to know :) | 14:28 |
| didrocks | maybe modifying the postinst to cat make.log, but an upload for this if it can't be reproduced (even in an autopkgtests vm) | 14:28 |
| juliank | s390x built successfully, woohoo | 14:33 |
| juliank | the arms are still testing, but hopefully succeed as well | 14:34 |
| Laney | cking: This failure happens for me locally | 14:47 |
| Laney | I don't think it's that 'Can't exec "gcc"' thing - that was present in the successful runs too. | 14:47 |
| Laney | ...but rather zfs-dkms not being installable | 14:48 |
| cking | Laney, message that concerns me is "configure: error: C compiler cannot create executables" - not sure if that's a tool chain thing or not | 14:49 |
| Laney | I dunno, but for me the make.log contains: | 14:50 |
| Laney | ubuntu@autopkgtest:/tmp/autopkgtest.4RB7XA/build.QMj/src/debian/tests$ more /var/lib/dkms/zfs/0.8.1/build/make.log | 14:50 |
| Laney | DKMS make.log for zfs-0.8.1 for kernel 5.0.0-17-generic (x86_64) | 14:50 |
| Laney | Wed 03 Jul 2019 03:46:22 PM BST | 14:50 |
| Laney | make: *** No targets specified and no makefile found. Stop. | 14:50 |
| cking | ah, ok, that's useful | 14:50 |
| Laney | autopkgtest-buildvm-ubuntu-cloud and the qemu runner should get you here | 14:50 |
| cking | Laney, any hint on how you use that? | 14:51 |
| Laney | http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test | 14:51 |
| cking | ta | 14:52 |
| Laney | the second to last example, but replace all package names with zfs-linux | 14:52 |
| Laney | and add --shell-fail probably | 14:52 |
| === Wryhder is now known as Lucas_Gray | ||
| cking | Laney, so inside my autopkgtest environment, when I compile "int main(void) { return 0; }" - gcc x.c I get: /usr/bin/ld: cannot find Scrt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory - this is on Eoan with the gcc 8.3 compiler | 16:31 |
| cking | doko, any ideas why gcc 8.3 on amd64 is failing like that? ^^ | 16:32 |
| doko | cking: which binutils is this, the one from -proposed? | 16:35 |
| cking | it was from the daily autopkgtest eoan cloud image, so I guess it may be old, not sure what to check | 16:37 |
| cking | 2.32.51.20190614-0ubuntu1 | 16:37 |
| doko | that one should be fine. 20190701 was bad | 16:39 |
| cking | hrm,ok, let me dig deeper | 16:40 |
| Laney | cking: missing libc6-dev? | 16:42 |
| doko | of course! | 16:42 |
| cking | yep indeed | 16:43 |
| Laney | surely something should have pulled that in | 16:43 |
| cking | one would have thought so, but apparently not | 16:44 |
| Laney | ok, I'll leave it up to you to work out where the right place to insert that is ... | 16:45 |
| rbasak | vorlon: opinion on bug 1595358 please? I don't see any dep8 tests, so does that disqualify me from approving the SRU without a TB member's approval? | 16:45 |
| doko | it's intended that gcc doesn't depend on libc6-dev, because you don't need it to build the kernel ... | 16:45 |
| ubottu | bug 1595358 in lyx (Ubuntu Xenial) "[SRU] Update to maintenance release 2.1.5 in Xenial" [Low,New] https://launchpad.net/bugs/1595358 | 16:45 |
| rbasak | vorlon: on balance it seems reasonable to me (subject to review) | 16:46 |
| cking | doko, so i need to explicitly require it for building a dkms module now? the dkms build does some autotool sanity checks, so it needs libc6-dev | 16:47 |
| Laney | maybe dkms ought to have it? | 16:47 |
| cjwatson | It has Depends: make | build-essential which is a bit WTF | 16:48 |
| Laney | Yeah. | 16:48 |
| * cking blinks | 16:48 | |
| cjwatson | I can't follow the chain of reasoning that would lead to doing that | 16:48 |
| rbasak | Make has Build-Essential: yes. | 16:49 |
| rbasak | Not that it makes a difference, but perhaps there's some inverted reasoning there? | 16:49 |
| cjwatson | Not using build-essential is fair enough but what's the point of the alternative? Should be make, libc6-dev | libc-dev anyway. | 16:49 |
| cjwatson | (It shouldn't have build-essential since it doesn't need g++, and build-essential isn't really a good thing to depend on anyway. | 16:50 |
| cjwatson | ) | 16:50 |
| doko | yep, make, libc6-dev | libc-dev looks like the right thing | 16:51 |
| vorlon | rbasak: I don't think you need a separate TB approval to approve that SRU. I do know that I looked at that SRU in the queue briefly and punted on it because it looked like a lot of work | 16:54 |
| rbasak | vorlon: I mean the "For upstreams who have...it is also acceptable to upload new microreleases with many bug fixes without individual Launchpad bugs..." part of the policy. What would you expect to review in this case? That it all seems sensible, maybe the upstream notes of the changes, but not the code changes themselves, presumably? | 17:03 |
| rbasak | (I'd also check the upstream tarball matches upstream's published one) | 17:03 |
| vorlon | shrug, again, when I peeked at it it looked like too much work | 17:03 |
| vorlon | to my understanding the TB has blanket delegated these questions to the SRU team | 17:04 |
| rbasak | That's not how I read the policy | 17:04 |
| rbasak | " In other cases where such upstream automatic testing is not available, exceptions must still be approved by at least one member of the Ubuntu Technical Board" | 17:04 |
| rbasak | Where "such upstream automatic testing" is the bulleted list of four items. | 17:05 |
| rbasak | Which I see as "and"-ed. | 17:05 |
| vorlon | I'm not sure the delegation got captured on the wiki page when it was done | 17:05 |
| rbasak | However as you are a TB member, I consider this conversation good enough :) | 17:05 |
| vorlon | ok | 17:05 |
| infinity | cjwatson, doko, Laney, cking: There's no reason dkms should depend on build-essential *or* on libc6-dev. Kernel modules don't need libc6-dev to compile. If zfs-dkms needs it, it should depend on it, but that's unique to that build system, not generic for all dkms modules. | 17:17 |
| infinity | (agreed that the dkms alternat dep makes no sense, but it just shouldn't be there) | 17:18 |
| cking | infinity, sounds fair to me | 17:19 |
| infinity | cking: Though, I will say that autotools tests that rely on libc6 when setting up a kernel module build which will ultimately use kernel headers that are subtly different from userspace headers sounds daft. :) | 17:22 |
| infinity | cking: (Or maybe the problem is just that they're using a few of the "does the compiler work" type tests and they should remove those and make it kernel only?) | 17:22 |
| infinity | cking: Anyhow, simple downstream solution is to depend on libc6-dev. A more comprehensive upstream solution to not actually need libc headers might be nice though, cause it clearly doesn't (or better not) need them to build the kernel module. | 17:23 |
| cking | infinity, i believe it's a "is the compiler sane for this build" kind of check that is required because the driver is build on lots of diverse systems | 17:23 |
| cking | *built | 17:23 |
| infinity | cking: A third (again, downstream) option would be to preseed the autoconf values for any userspace tests because we know our compiler works and don't want to force everyone to install libc6-dev, but that point's vaguely moot since we ship zfs pre-built anyway and don't expect people to use the dkms package. | 17:30 |
| infinity | cking: Which leads to the fourth option of not producing the dkms package at all on Ubuntu. | 17:30 |
| infinity | cking: Pick one. :) | 17:31 |
| cking | infinity, the dkms package is kinda useful for users to use their own kernels | 17:31 |
| infinity | cking: Though, in Debian, it definitely looks like it should have the libc-dev dep. | 17:31 |
| infinity | cking: Fair enough on the custom kernel thing. So the dep it likely the path of least resistance, unless you feel like preseeding the poop out of autoconf or rewriting upstream's stuff to use kernel headers and -nostdlib | 17:32 |
| cking | it's just easier if i add the deb, it's an explicit no-brainer | 17:33 |
| infinity | cking: If you're pushing this back to Debian, remember that "libc6-dev" is spelled "libc6-dev | libc-dev" because it's not libc6 on all arches, irritatingly. | 17:33 |
| infinity | It is on all of ours, though. | 17:34 |
| cking | nice to know, thanks | 17:34 |
| vorlon | I thought all the archs that were libc-dev instead of libc6-dev were also non-Linux | 17:35 |
| vorlon | ... not counting those Linux archs that were libc6.1-dev | 17:35 |
| mithrison | hi, I want to customize ubuntu server packages and create a bootable image for rasberry pi that includes those custom added packages in it | 19:19 |
| CarlFK | mithrison: /j #timvideos and I'll point you to something that may be what you are looking for | 19:20 |
| teward | Laney: alive? | 22:00 |
| === Wryhder is now known as Lucas_Gray | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!