| xnox | mwhudson: somewhat, yes. | 00:27 |
|---|---|---|
| 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:28 |
| * xnox is not even sure why one would have multiple controllers, maybe passthrough to a VM?! | 00:29 | |
| sarnold | lots of disks? | 00:31 |
| sarnold | multipath? | 00:31 |
| xnox | sarnold: in the context of Intel VROC raid, it would not be multipath, but actual disks. | 00:47 |
| 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:48 |
| sarnold | xnox: well, that certainly confused me :) | 00:51 |
| mwhudson | even better if the exported wwn is 0x0000000 | 01:10 |
| mantas-baltix | Hi | 08:10 |
| 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:12 |
| mantas-baltix | for about 60 minutes I see info "Start in 7 minutes (2610)" or something, like "Start in 11 minutes (2610)" ;) | 08:13 |
| 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:23 |
| mitya57 | mantas-baltix: maybe better to ask on #launchpad | 08:28 |
| 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:31 |
| === acheronuk is now known as RikMills | ||
| mantas-baltix | cjwatson, thanks | 08:32 |
| 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:19 |
| seb128 | errors like that and the initramfs updates failing | 10:20 |
| 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 | 10:23 |
| rbalint | seb128, not ye, looking at it | 13:36 |
| seb128 | rbalint, thanks | 13:36 |
| rbalint | seb128, could you please drop libselinux from proposed? | 13:50 |
| rbalint | seb128, breaks glibc autopkgtest as well and the switch to versioned symbols did not fully work out breaking systemd :-\ | 13:51 |
| 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:54 |
| rbalint | seb128, it breaks glibc autopkgtest and waiting just lets it breaking other packages | 13:55 |
| rbalint | seb128, i don't see Debian's systemd affected yet because it FTBFS :-\ | 13:56 |
| 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? | 13:57 |
| ebarretto | seb128, rbalint, this might help https://github.com/SELinuxProject/selinux/commit/9eb9c9327563014ad6a807814e7975424642d5b9 | 14:12 |
| rbalint | seb128, https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/3 ? | 14:18 |
| rbalint | seb128, also filing a bug referencing this mr | 14:21 |
| seb128 | rbalint, thx | 14:22 |
| 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:31 |
| 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:32 |
| seb128 | rbalint, removed from proposed now, thanks for the details | 14:36 |
| xnox | rbalint: well, i mean libselinux1 & soname must change. | 14:45 |
| xnox | rbalint: cause old binaries are installable with new libselinux1, yet don't work?! | 14:46 |
| rbalint | xnox, they seem to work, but checking that | 14:56 |
| rbalint | xnox, bumping so version and renaming the package would be cleaner, i agree | 14:57 |
| xnox | rbalint: i think it does | 15:00 |
| rafaeldtinoco | @pilot in | 15:00 |
| === 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 | ||
| 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:02 |
| xnox | rbalint: but yeah, old binaries will work with new library that ships versioned symbols | 15:03 |
| 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:37 |
| 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:55 |
| 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:56 |
| xnox | juliank: on groovy manpage says that, yet pip is python3 | 15:58 |
| 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 | 15:59 |
| 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:00 |
| 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:06 |
| rbalint | bigon, #965136 | 16:07 |
| bigon | mmmh | 16:10 |
| 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:11 |
| bigon | (but obviously not the opposite) | 16:13 |
| juliank | that matches my understanding | 16:15 |
| rbalint | bigon, yes, but looking for the versioned symbol in older libselinux does not work :-( | 16:17 |
| rbalint | bigon, so packages built with 3.1-1 need to be rebuilt | 16:18 |
| bigon | because the application asks for symbol@version1 and the libs only provides symbol@base | 16:19 |
| bigon | right | 16:20 |
| bigon | rbalint: uploaded | 16:34 |
| bigon | thx | 16:34 |
| 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:36 |
| bigon | scratch what I said.. | 16:37 |
| mwhudson | vorlon: did you ever get to the bottom of why grub-efi-amd64 was getting seeded? | 20:38 |
| mwhudson | cpaelzer: ah hah so it really is a qemu regression | 20:47 |
| === ijohnson is now known as ijohnson|EOD | ||
| 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:08 |
| rafaeldtinoco | @pilot out | 21:53 |
| === 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: | ||
| vorlon | mwhudson: ish; we made some seed changes on kubuntu and those seemed to dtrt | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!