[01:05] <StevenK> rbasak: If it was just me, then sure -- but there a whole bunch of posts about this, not to mention that other people might have hit this and then go "oh well, time to install Fedora"
[01:12] <rbasak> StevenK: I understand it's frustrating, but without concrete steps to reproduce, and assuming it works for the majority of people, saying "we should do better" didn't seem constructive; that's all.
[07:53] <mwhudson> that is a strange bug, in that it certainly isn't happening to everyone
[07:54] <mwhudson> oh it's a grub issue really?
[08:08] <StevenK> Possibly http://savannah.gnu.org/bugs/?61058 , but that hasn't had much traction either
=== cpaelzer_ is now known as cpaelzer
[13:51] <sergiodj> tjaalton: hi, do you plan to upload sssd 2.7.2-2 (with https://salsa.debian.org/sssd-team/sssd/-/commit/a64db42fba29b4c7ddbe0050f27b9e378d975b43) soon?  I'd like to start working on merging it before the end of the week
[13:51] <ubottu> Commit a64db42 in sssd-team/sssd "rules: Fix python install directory. (LP: #1979453)"
[13:54] <tjaalton> sergiodj: yup
[13:54] <sergiodj> tjaalton: thanks
[14:12] <enr0n> Can a core dev please trigger these two PPA autopkgtests? TIA.
[14:12] <enr0n> https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=amd64&package=systemd&ppa=enr0n/systemd-251&trigger=systemd/251.2-2ubuntu1~ppa13
[14:12] <enr0n> https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=ppc64el&package=systemd&ppa=enr0n/systemd-251&trigger=systemd/251.2-2ubuntu1~ppa13
[14:23] <jawn-smith> enr0n: on it
[14:24] <enr0n> jawn-smith: thanks!
[14:53] <sergiodj> tjaalton: before you upload, there's another bug with "sssctl analyze".  /usr/libexec/sssd/sss_analyze has the wrong shebang
[14:53] <sergiodj> I'm going to submit a Merge Request soon
[14:55] <tjaalton> sergiodj: uploaded already :)
[14:55] <sergiodj> hah
[14:56] <sergiodj> tjaalton: you can either upload -3 now or I can patch sssd in Ubuntu meanwhile
[14:56] <sergiodj> up to you
[14:57] <tjaalton> I can wait
[15:06] <slyon> cpaelzer: didrocks: I have a question about symbols tracking for senior MIR team members: https://bugs.launchpad.net/ubuntu/+source/lerc/+bug/1977551/comments/4 – this is not urgent and we can also discuss it during the next meeting, but maybe you find some time in-between and could have a brief look.
[15:06] <ubottu> Launchpad bug 1977551 in lerc (Ubuntu) "[MIR] lerc" [Undecided, New]
[15:29] <didrocks> slyon: is there anything like DPKG_GENSYMBOLS_CHECK_LEVEL set to 4 or any other value?
[15:30] <didrocks> it seems default is 1, so "Level 1 fails if some symbols have disappeared."
[15:30]  * didrocks likes to use 4 to ensure the symbols file is always updated
[15:30] <slyon> didrocks: yes, the package sets it to "-c0" in d/rules (i.e. ignoring any failures)
[15:30] <didrocks> ah, here we go :)
[15:31] <slyon> but they are doing on purpose and don't want to change (see debian bug report)
[15:32] <didrocks> I don’t know, I feel the warning is not enough, and then, if there is a change that isn’t an ABI/API breakage (and yes, C++ is a nightmare in this regard), IMHO, this is up to the maintainer to do the check and update the symbols files accordingly
[15:33] <didrocks> but at least, we know the symbols file (even if not perfect) is really tracking what’s in it
[15:33] <didrocks> I meant, we were able to handle unity/nux as big C++ projects and still track symbols there
[15:33] <didrocks> it wasn’t an everyday joy, especially with the amount of changes when a new g++ is introduced, but it’s doable
[15:34] <didrocks> so if we want to ignore the error/mismatch why having a symbol file in first place?
[15:35] <didrocks> I’m happy to read other MIR team member opinions
[16:06] <slyon> didrocks: I totally agree with your stance on it! (sorry, I was stuck in a meeting)
[16:06] <sergiodj> tjaalton: in case you haven't received a notification: https://salsa.debian.org/sssd-team/sssd/-/merge_requests/13/diffs
[16:06] <ubottu> Merge 13 in sssd-team/sssd "Fix shebang on sss_analyze" [Opened]
[16:07] <slyon> If the Debian Maintainer doesn't want to track those symbols properly, we might want to introduce an Ubuntu delta to increase the DPKG_GENSYMBOLS_CHECK_LEVEL to something like -c4 ourselves.
[18:25] <tjaalton> sergiodj: thanks, merged and uploaded
[19:05] <sergiodj> tjaalton: thanks
[19:33] <ahasenack> lvoytek: approved, shall I upload?
[19:41] <lvoytek> sure, thanks!
[20:52]  * tarzeau was wondering why ubuntu doesn't get uftrace updated? https://launchpad.net/ubuntu/+source/uftrace
[21:03] <ginggs> tarzeau: uftrace has an ubuntu delta so it will not autosync, try https://wiki.ubuntu.com/SyncRequestProcess
[21:03] <tarzeau> ginggs: thanks for the hint. will consider when uftrace is synced with the latest upstream release
[21:05] <ahasenack> and looks like that delta was added in debian
[21:06] <ahasenack> uftrace (0.10-1) UNRELEASED; urgency=medium
[21:06] <ahasenack> ...
[21:06] <ahasenack>     - Fixes FTBFS from spurious test failures (closes: 966988). Thanks
[21:06] <ahasenack>       to Logan Rosen for identifying the issue and submitting a patch,
[21:06] <ahasenack>       although I failed to address it in the 0.9.4 series.
[21:06] <ahasenack> so it *sounds* like it can become a sync (judging just by the d/changelog updates)
[21:07] <ahasenack> Logan_: are you that Logan Rosen? :)
[21:09] <sarnold> heh
[21:13]  * tsimonq2 waves in this channel for the first time in a while
[21:13] <tsimonq2> no I'm not Logan ;)
[22:39] <Logan_> ahasenack:  I am indeed that Logan
[22:41] <Logan_> feel free to sync if it seems safe. Otherwise I can take a look later
[23:49] <mwhudson> paride: does lxd launch --vm work on armhf? i didn't think we published images that would work for that