[01:23] <RAOF> So, uh, does anyone else have an encrypted rootfs and have run into LP #1958806?
[01:36] <RAOF> (Bug 1958806)
[01:36] <RAOF> This has been a bad reboot for my laptop, also hitting bug 1958620 :)
[02:12] <blahdeblah> RAOF: I think I have seen that, and I can't remember what the solution was. ;-(
[02:12] <blahdeblah> RAOF: Also, howdy, and hope you're doing well. :-)
[02:13] <RAOF> blahdeblah: The solution is to have a livecd you can recover from, and update the initramfs after adding a hook to force it to include libgcc ;)
[02:13] <RAOF> And a fine hello to you, too!@
[02:15] <blahdeblah> I'm pretty sure I just rebooted from the previous kernel, and on the next kernel update everything worked.
[02:15] <blahdeblah> It didn't slow me down much, and I'm pretty sure I didn't need a live CD to recover.
[02:15] <blahdeblah> (Hence why I can't remember exactly what I did.)
[02:17] <RAOF> Ah, yeah. If you didn't update the previous initramfs that would work.
[02:17] <RAOF> It's possible that a 5.15 kernel initramfs wouldn't suffer the same problem (but I can't see how that would change things), but 5.15 can't bring up graphics on my laptop 😬
[02:17] <blahdeblah> I nearly always update only the running kernel's initramfs.
[02:27] <RAOF> Yeah, I'm not entirely sure what caused the previous initramfs to get rebuilt.
[10:41] <eoli3n> Hi
[10:59] <cjwatson> Laibsch: virtualenv is widely used on Python 3 too, despite the built-in stuff
[11:01] <Laibsch> cjwatson: Yeah, thank you for pointing that out.  I also later learned that some of my assumptions about virtual environments in python were incorrect.  Most importantly, that there are a crapton of them out there. https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe
[11:12] <eoli3n> i need to know which shell uses ubiquity from in-target command ?
[11:12] <eoli3n> even if i for in-target /bin/bash something.sh, it seems to run as sh
[11:12] <eoli3n> force
[11:56] <eoli3n> Why is #ubuntu-installer empty ?
[11:57] <eoli3n> where can I find the code of ubiquity ?
[11:58] <eoli3n> i need to know how 'in-target' work
[11:58] <eoli3n> the online documentation is ... a mess
[11:59] <schopin> eoli3n: I'm guessing https://code.launchpad.net/ubiquity for the code.
[11:59] <eoli3n> thanks
[12:02] <eoli3n> huhu more than 500Mo source
[12:02] <eoli3n> is that a new kernel ? or systemd ?
[12:02] <eoli3n> 590Mo, fiou... hard work
[12:06] <ogra> note that ubiquity is a dead project ... mostly in maintenance mode ...
[12:07] <ogra> https://discourse.ubuntu.com/t/new-desktop-installer-preview-build/24765 ...
[12:08] <schopin> athos: hi! is https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/65 still actively worked on? I'm looking into merging python-debian
[12:13] <eoli3n> ogra so what should I use to automate a desktop install ?
[12:21] <ogra> eoli3n, good question 🙂 i think 22.04 still uses ubiquity as is ... not sure though ...
[13:36] <eoli3n> in-target keeps running /bin/sh
[13:37] <eoli3n> ubiquity ubiquity/success_command string in-target chmod 755 /tmp/post.sh; in-target /tmp/post.sh;
[13:37] <eoli3n> it doesn't respect the shebang
[13:38] <eoli3n> ubiquity ubiquity/success_command string in-target bash /tmp/post.sh;
[13:38] <eoli3n> it also run post.sh with /bin/sh
[13:38] <eoli3n> it drives me crazy
[13:47] <ogayot> eoli3n: IIRC, in-target is just a wrapper for chroot "$target" [...]
[13:48] <eoli3n> yes it is
[13:48] <eoli3n> but a shitty one
[13:48] <eoli3n> can I use directly chroot /target /bin/bash script.sh ?
[13:50] <eoli3n> where is it documented ?
[14:13] <eoli3n> that's magic
[14:13] <eoli3n> i'm running chroot /target bash /tmp/script.sh
[14:14] <eoli3n> in /tmp/script.sh i check $0
[14:14] <eoli3n> i get sh
[14:42] <cpaelzer> slyon: any ETA for a new systemd in jammy-proposed (I want to close the tab with bug 1946854)?
[14:44] <slyon> cpaelzer: I just started working on it an hour ago (I'm going to merge systemd-stable v249.9 and also include some other requested changes). so most probably within the next couple of days.
[14:48] <cpaelzer> \o/
[14:48] <cpaelzer> all I wanted to know slyon, thanks
[14:49] <rbasak> xnox: I don't follow. What NO_PKG_MANGLE=1 delta?
[14:52] <schopin> jawn-smith: to ease into your work week, would you mind looking at https://bugs.launchpad.net/ubuntu/+source/erlang/+bug/1958881 ? :-D
[14:52] <jawn-smith> schopin: Sure thing, I'm on it
[14:53] <schopin> \o/ thanks
[15:07] <xnox> rbasak:  hmmmmm
[15:08] <xnox> rbasak:  in http://launchpadlibrarian.net/571550055/debianutils_5.5-1_5.5-1ubuntu1.diff.gz in debian/rules i see that gunnar added "export NO_PKG_MANGLE=1" and i don't see that in debian, or before.
[15:09] <xnox> which i think is related to creating/extracting/stripping/uploading translations into language pack
[15:09] <jawn-smith> schopin: done!
[15:09] <jawn-smith> and I used the -b flag so it should close the bug
[15:11] <xnox> rbasak:  it may not be needed once again now, given that debian has fixed the tarball / translations in their NMU upload
[15:21] <schopin> jawn-smith: thanks! For future sync sponsorships, would you mind also using the -u option? Spread the blame and all that ;)
[15:22] <jawn-smith> oops, should have thought of that. Sorry!
[15:23] <rbasak> xnox: ah, OK, thanks.
[15:24] <schopin> jawn-smith: no worries, I actually learned of the option about 10mn ago :P
[15:41] <bdmurray> schopin, jawn-smith: isn't it -s / --sponsor for syncpackage?
[15:41] <jawn-smith> bdmurray: it is, yes
[15:41] <schopin> Indeed.
[15:42] <schopin> The good news is that -u doesn't exist :D
[17:54] <santa_> doko: hi there, not sure if you are aware of this, but since some time ago we are getting a couple of FTBFSes in kde packages, I suspect it's binutils what is triggering it
[17:55] <santa_> (I don't have solid evidence anyway, but I couldn't figure it out yet)
[17:55] <santa_> let me show the build logs...
[17:55] <santa_> http://tritemio-groomlake.duckdns.org/logs/kdepim-addons_21.12.1-0ubuntu2+tritemio2_amd64-2022-01-24T01:04:44Z
[17:56] <santa_> http://tritemio-groomlake.duckdns.org/logs/kmail_21.12.1-0ubuntu2+tritemio2_amd64-2022-01-24T02:12:36Z
[17:59] <santa_> from kdepimaddons log: /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libKF5PimTextEdit.so.5.19.1.abi3: unexpected redefinition of indirect versioned symbol `_ZNK12KConfigGroup9readEntryI5QSizeEET_PKcRKS2_@ABI_5_3'
[18:00] <santa_> from kmail log:
[18:00] <santa_> /usr/bin/ld: /lib/x86_64-linux-gnu/libKF5WebEngineViewer.so.5abi3: unexpected redefinition of indirect versioned symbol `_ZNK12KConfigGroup9readEntryI5QSizeEET_PKcRKS2_@ABI_5_3'
[18:00] <santa_> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libKF5AkonadiWidgets.so.5.19.1.abi1: unexpected redefinition of indirect versioned symbol `_ZNK12KConfigGroup9readEntryI5QSizeEET_PKcRKS2_@ABI_5_1'
[18:01] <santa_> I don't know yet how to fix this, any help from anyone will be very appreciated
[18:24] <RikMills> santa_: I hit that and doko suggested it was LTO related
[18:25] <RikMills> I have not had time to test that theory
[18:25] <santa_> I know you hit that, thanks for the workaround :)
[18:25] <santa_> feeling better alreaady?
[18:48] <RikMills> santa_: still not hugely great
[18:50] <santa_> RikMills: well, if you are in a slow recovery, I'm glad you are recovering :)
[19:00] <ddstreet> !dmb-ping
[20:51] <Laibsch> what is the meaning of the tag rls-jj-incoming?  I guess rls=release jj=jammy. I guess my question is what kind of bugs are tagged this way?
[20:59] <vorlon> Laibsch: it's a tag used to flag a bug for consideration of the Canonical engineering team responsible for a particular package in main
[22:25] <santa_> doko, RikMills fixed the thing in git, it was just adding:
[22:26] <santa_> export DEB_CXXFLAGS_MAINT_STRIP=-flto=auto
[22:26] <santa_> to debian/rules
[22:26] <santa_> simple workaround for the meantime
[22:36] <vorlon> santa_: a more idiomatic way to write this is DEB_BUILD_MAINT_OPTIONS = optimize=-lto
[22:37] <sarnold> vorlon: is that more idiomatic method written down somewhere?
[22:38] <vorlon> sarnold: <gesticulates in doko's direction>
[22:38] <sarnold> vorlon: hmm I was thinking more like a wiki than a guru.. :)
[22:38] <vorlon> https://lists.ubuntu.com/archives/ubuntu-devel/2021-March/041421.html
[22:38] <vorlon> https://wiki.ubuntu.com/ToolChain/LTO
[22:38] <sarnold> oh nice, thanks
[22:39] <vorlon> so turns out yes, it's in a wiki
[22:42] <santa_> vorlon: ah! nice! I tried to find something like that reading the man page of dpkg-buildflags from jammy, which imho could be improved a bit

[22:43] <santa_> --query
[22:44] <santa_> sorry, let me try again:

[22:44] <santa_> --query-features area
[22:44] <santa_> Print the features enabled for a given area (since dpkg 1.16.2).  The only currently recognized areas on Debian and derivatives are future, qa, reproducible, sanitize and
[22:44] <santa_> hardening, see the FEATURE AREAS section for more details.  Exits with 0 if the area is known otherwise exits with 1.

[22:45] <santa_> ↑ the list seems incomplete
[22:46] <santa_> and of course I didn't scroll down to the "FEATURE AREAS", that was my mistake :)