[00:27] mwhudson: somewhat, yes. [00:28] mwhudson: i think firmware ui hides that. As it simply goes "create raid volume" and it only lets you pick disks from same controller, if there are multiple. [00:28] mwhudson: and i have never actually used a system with more than one controller. so it's theoretical i think. [00:29] * xnox is not even sure why one would have multiple controllers, maybe passthrough to a VM?! [00:31] lots of disks? [00:31] multipath? [00:47] sarnold: in the context of Intel VROC raid, it would not be multipath, but actual disks. [00:48] sarnold: i mean the disks could be nvme, and pretend that they do multipath, and confuse multipath -ll by saying that they all have WWID, and they are multipath devices with # of paths being One. [00:48] but that's separate. [00:51] xnox: well, that certainly confused me :) [01:10] even better if the exported wwn is 0x0000000 [08:10] Hi [08:12] Could someone tell why packaging recipe builds doesn't start today? Yesterday builds were started after few minutes, but this morning I'm waiting more than hour, see https://code.launchpad.net/~baltix/+archive/ubuntu/ppa/+recipebuild/2608185 [08:13] for about 60 minutes I see info "Start in 7 minutes (2610)" or something, like "Start in 11 minutes (2610)" ;) [08:23] https://lists.ubuntu.com/archives/ubuntu-devel/2020-July/041089.html There's a bug, I've pinged people multiple times including the person that made the bad merge, all to be ignored. \o/ [08:28] mantas-baltix: maybe better to ask on #launchpad [08:31] mantas-baltix: build farm trouble after a network outage; being investigated [08:31] (and yes, this is more of a #launchpad thing) === acheronuk is now known as RikMills [08:32] cjwatson, thanks [10:19] rbalint, hey, do you know what's going on with the systemd autopkgtests? [10:19] /bin/systemctl: /lib/s390x-linux-gnu/libselinux.so.1: no version information available (required by /bin/systemctl) [10:20] errors like that and the initramfs updates failing [10:23] bdmurray, hey, could you review again the wslu/focal SRU, you had some comments about the bug descriptions and those have been updated I think it's ready for review again [13:36] seb128, not ye, looking at it [13:36] rbalint, thanks [13:50] seb128, could you please drop libselinux from proposed? [13:51] seb128, breaks glibc autopkgtest as well and the switch to versioned symbols did not fully work out breaking systemd :-\ [13:54] bigon, ^ do you know about those issues with the libselinux update? [13:54] rbalint, is that issue existing in Debian? it doesn't seem reported in the BTS yet [13:55] seb128, it breaks glibc autopkgtest and waiting just lets it breaking other packages [13:56] seb128, i don't see Debian's systemd affected yet because it FTBFS :-\ [13:57] rbalint, [13:57] makedb.c:849:3: error: ‘security_context_t’ is deprecated [-Werror=deprecated-declarations] [13:57] the glibc errors do sound like something that should be easy to fix though, wouldn't that be a better step forward to fix it rather than rollback libselinux? [14:12] seb128, rbalint, this might help https://github.com/SELinuxProject/selinux/commit/9eb9c9327563014ad6a807814e7975424642d5b9 [14:18] seb128, https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/3 ? [14:21] seb128, also filing a bug referencing this mr [14:22] rbalint, thx [14:31] seb128: rbalint: imho, libselinux broke all symbols [14:31] they used to be @Base but now they are @LIBSELINUX_1.0 [14:31] no? [14:32] comparing 3.0 & 3.1 [14:32] * xnox goes to run abi check on them. [14:32] xnox, yes, see the mr [14:36] rbalint, removed from proposed now, thanks for the details [14:45] rbalint: well, i mean libselinux1 & soname must change. [14:46] rbalint: cause old binaries are installable with new libselinux1, yet don't work?! [14:56] xnox, they seem to work, but checking that [14:57] xnox, bumping so version and renaming the package would be cleaner, i agree [15:00] rbalint: i think it does [15:00] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco [15:02] rbalint: previously it was without a version, so i think any versioned symbol satisfies that. [15:02] rbalint: so yes merge is good enough, to set minimum version, as new binaries will pick versioned symbol and will not work with old lib. [15:03] rbalint: but yeah, old binaries will work with new library that ships versioned symbols [15:37] xnox, doko back on the pip thing, we could ship /usr/bin/pip in python3-pip as a symlink, and divert it in postinst and use trigger to undivert it on pip3 install. That way, we don't create an unowned file in /usr/bin at least [15:55] juliank: simply shipping pip in python3-pip package in focal sounds fine. [15:55] juliank: does it break anything if it's python3 version? [15:55] xnox: Well I feel like if you install python-is-python2 it gets confusing? [15:56] On Debian, pip is the command to use when installing packages for [15:56] Python 2, while pip3 is the command to use when installing packages [15:56] for Python 3. [15:56] in the manpage [15:56] but i'm not too sure that is actually true [15:56] it was true [15:56] Not sure we had a pip2? [15:58] juliank: on groovy manpage says that, yet pip is python3 [15:59] yes, on groovy pip became pip3 but nobody updated mnapage [15:59] juliank: take groovy python3-pip and put it into focal-backports?! [15:59] possible [15:59] easiest option [16:00] 15:54 < seb128> bigon, ^ do you know about those issues with the libselinux update? << glibc tests seems to fail because a type(?) is deprecated and that warnings are somehow threated as errors [16:00] (like you said just bellow) [16:00] for systemd, no I don't know [16:06] bigon, i just file a bug to BTS which will show up soon, but the failure at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/systemd/20200716_044131_250e2@/log.gz [16:07] bigon, #965136 [16:10] mmmh [16:11] IIRC adding a version to symbol was OK and @base (the default) was supposed to match all the version (or something like that) [16:13] (but obviously not the opposite) [16:15] that matches my understanding [16:17] bigon, yes, but looking for the versioned symbol in older libselinux does not work :-( [16:18] bigon, so packages built with 3.1-1 need to be rebuilt [16:19] because the application asks for symbol@version1 and the libs only provides symbol@base [16:20] right [16:34] rbalint: uploaded [16:34] thx [16:36] but thinking about this I'm a bit surprised, shouldn't dpkg-shlibdeps see that symbol@version1 is not in the .symbols file and fall back to the version from the shlibs file? [16:36] which is not the upstream version if I'm not wrong [16:36] libselinux 1 libselinux1 (>= 3.1) [16:37] scratch what I said.. [20:38] vorlon: did you ever get to the bottom of why grub-efi-amd64 was getting seeded? [20:47] cpaelzer: ah hah so it really is a qemu regression === ijohnson is now known as ijohnson|EOD [21:08] sqlite3 was blocked because of seqtools, seqtools had an issue on armhf -> fixed, new seqtools version uploaded, will try to address some of the python3 issues for sqlite3 [21:53] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: [22:36] mwhudson: ish; we made some seed changes on kubuntu and those seemed to dtrt