[00:27] <xnox> mwhudson:  somewhat, yes.
[00:28] <xnox> 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] <xnox> 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] <sarnold> lots of disks?
[00:31] <sarnold> multipath?
[00:47] <xnox> sarnold:  in the context of Intel VROC raid, it would not be multipath, but actual disks.
[00:48] <xnox> 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] <xnox> but that's separate.
[00:51] <sarnold> xnox: well, that certainly confused me :)
[01:10] <mwhudson> even better if the exported wwn is 0x0000000
[08:10] <mantas-baltix> Hi
[08:12] <mantas-baltix> 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] <mantas-baltix> for about 60 minutes I see info "Start in 7 minutes (2610)" or something, like "Start in 11 minutes (2610)" ;)
[08:23] <Unit193> 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] <mitya57> mantas-baltix: maybe better to ask on #launchpad
[08:31] <cjwatson> mantas-baltix: build farm trouble after a network outage; being investigated
[08:31] <cjwatson> (and yes, this is more of a #launchpad thing)
[08:32] <mantas-baltix> cjwatson, thanks
[10:19] <seb128> rbalint, hey, do you know what's going on with the systemd autopkgtests?
[10:19] <seb128>  /bin/systemctl: /lib/s390x-linux-gnu/libselinux.so.1: no version information available (required by /bin/systemctl)
[10:20] <seb128> errors like that and the initramfs updates failing
[10:23] <seb128> 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] <rbalint> seb128, not ye, looking at it
[13:36] <seb128> rbalint, thanks
[13:50] <rbalint> seb128, could you please drop libselinux from proposed?
[13:51] <rbalint> seb128, breaks glibc autopkgtest as well and the switch to versioned symbols did not fully work out breaking systemd :-\
[13:54] <seb128> bigon, ^ do you know about those issues with the libselinux update?
[13:54] <seb128> rbalint, is that issue existing in Debian? it doesn't seem reported in the BTS yet
[13:55] <rbalint> seb128, it breaks glibc autopkgtest and waiting just lets it breaking other packages
[13:56] <rbalint> seb128, i don't see Debian's systemd affected yet because it FTBFS :-\
[13:57] <seb128> rbalint,
[13:57] <seb128> makedb.c:849:3: error: ‘security_context_t’ is deprecated [-Werror=deprecated-declarations]
[13:57] <seb128> 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] <ebarretto> seb128, rbalint, this might help https://github.com/SELinuxProject/selinux/commit/9eb9c9327563014ad6a807814e7975424642d5b9
[14:18] <rbalint> seb128, https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/3 ?
[14:21] <rbalint> seb128, also filing a bug referencing this mr
[14:22] <seb128> rbalint, thx
[14:31] <xnox> seb128:  rbalint: imho, libselinux broke all symbols
[14:31] <xnox> they used to be @Base but now they are @LIBSELINUX_1.0
[14:31] <xnox> no?
[14:32] <xnox> comparing 3.0 & 3.1
[14:32]  * xnox goes to run abi check on them.
[14:32] <rbalint> xnox, yes, see the mr
[14:36] <seb128> rbalint, removed from proposed now, thanks for the details
[14:45] <xnox> rbalint:  well, i mean libselinux1 & soname must change.
[14:46] <xnox> rbalint:  cause old binaries are installable with new libselinux1, yet don't work?!
[14:56] <rbalint> xnox, they seem to work, but checking that
[14:57] <rbalint> xnox, bumping so version and renaming the package would be cleaner, i agree
[15:00] <xnox> rbalint:  i think it does
[15:00] <rafaeldtinoco> @pilot in
[15:02] <xnox> rbalint:  previously it was without a version, so i think any versioned symbol satisfies that.
[15:02] <xnox> 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] <xnox> rbalint:  but yeah, old binaries will work with new library that ships versioned symbols
[15:37] <juliank> 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] <xnox> juliank: simply shipping pip in python3-pip package in focal sounds fine.
[15:55] <xnox> juliank:  does it break anything if it's python3 version?
[15:55] <juliank> xnox: Well I feel like if you install python-is-python2 it gets confusing?
[15:56] <xnox> On  Debian,  pip  is  the  command to use when installing packages for
[15:56] <xnox>        Python 2, while pip3 is the command to use  when  installing  packages
[15:56] <xnox>        for Python 3.
[15:56] <xnox> in the manpage
[15:56] <xnox> but i'm not too sure that is actually true
[15:56] <juliank> it was true
[15:56] <juliank> Not sure we had a pip2?
[15:58] <xnox> juliank:  on groovy manpage says that, yet pip is python3
[15:59] <juliank> yes, on groovy pip became pip3 but nobody updated mnapage
[15:59] <xnox> juliank:  take groovy python3-pip and put it into focal-backports?!
[15:59] <juliank> possible
[15:59] <juliank> easiest option
[16:00] <bigon> 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] <bigon> (like you said just bellow)
[16:00] <bigon> for systemd, no I don't know
[16:06] <rbalint> 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] <rbalint> bigon, #965136
[16:10] <bigon> mmmh
[16:11] <bigon> 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] <bigon> (but obviously not the opposite)
[16:15] <juliank> that matches my understanding
[16:17] <rbalint> bigon, yes, but looking for the versioned symbol in older libselinux does not work :-(
[16:18] <rbalint> bigon, so packages built with 3.1-1 need to be rebuilt
[16:19] <bigon> because the application asks for symbol@version1 and the libs only provides symbol@base
[16:20] <bigon> right
[16:34] <bigon> rbalint: uploaded
[16:34] <bigon> thx
[16:36] <bigon> 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] <bigon> which is not the upstream version if I'm not wrong
[16:36] <bigon> libselinux 1 libselinux1 (>= 3.1)
[16:37] <bigon> scratch what I said..
[20:38] <mwhudson> vorlon: did you ever get to the bottom of why grub-efi-amd64 was getting seeded?
[20:47] <mwhudson> cpaelzer: ah hah so it really is a qemu regression
[21:08] <rafaeldtinoco> 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] <rafaeldtinoco> @pilot out
[22:36] <vorlon> mwhudson: ish; we made some seed changes on kubuntu and those seemed to dtrt