| rbasak | !dmb-ping | 15:59 |
|---|---|---|
| ubottu | bdmurray, kanashiro, rbasak, seb128, sil2100, teward, utkarsh2102: DMB ping | 15:59 |
| ahasenack_ | jbicha: I think you were involved in poppler's update, and dia. I'm on +1maint, and came across a dia ftbfs, filed this bug with the info I got: https://bugs.launchpad.net/ubuntu/+source/dia/+bug/2070284 | 17:00 |
| -ubottu:#ubuntu-devel- Launchpad bug 2070284 in dia (Ubuntu) "FTBFS: ‘starts_with’ has not been declared in ‘std::string’" [Undecided, New] | 17:00 | |
| ahasenack_ | I added a patch to the bug, but I'd be surprised if that were to be the real fix | 17:00 |
| ahasenack_ | adrien: around still? | 17:57 |
| adrien | ahasenack_: kind of right now, maybe a bit more in a few minutes | 18:23 |
| ahasenack_ | adrien: I'm noticing a pattern in some ftbfs, same error in dia (LP: #2070284) and now in gdcm (LP: #2070303) | 18:24 |
| -ubottu:#ubuntu-devel- Launchpad bug 2070284 in dia (Ubuntu) "FTBFS: ‘starts_with’ has not been declared in ‘std::string’" [Undecided, New] https://launchpad.net/bugs/2070284 | 18:24 | |
| -ubottu:#ubuntu-devel- Launchpad bug 2070303 in gdcm (Ubuntu) "FTBFS: ‘starts_with’ has not been declared in ‘std::string’" [Undecided, Confirmed] https://launchpad.net/bugs/2070303 | 18:24 | |
| ahasenack_ | was wondering if you investigated it from that angle, of c++ standards | 18:24 |
| ahasenack_ | that std::string::starts_with/ends_with is defined in c++20 according to https://en.cppreference.com/w/cpp/string/basic_string/starts_with | 18:25 |
| ahasenack_ | and in fact defining that standard made the build work for dia, but I still don't understand how it was building before, maybe something changed in our toolchain/gcc/g++? | 18:25 |
| adrien | ahasenack_: I hadn't seen it so I had no chance to investigate :) | 18:28 |
| ahasenack_ | adrien: I guess it only started appearing after the fixes you added to gdcm | 18:28 |
| ahasenack_ | before it didn't reach that far, pehaps | 18:28 |
| adrien | but there has been a GCC upload recently and that could be a reason I guess | 18:29 |
| adrien | (last friday) | 18:29 |
| ahasenack_ | adrien: do you know/remember what the source package is? | 18:29 |
| ahasenack_ | gcc-defaults perhaps | 18:29 |
| ahasenack_ | no | 18:30 |
| ahasenack_ | that just changes defaults | 18:30 |
| adrien | gcc-14 last friday | 18:30 |
| ahasenack_ | hm, but these builds are on gcc-13 still | 18:30 |
| adrien | afk | 18:30 |
| ahasenack_ | hm, there is a gcc 13.3.0-1ubuntu1 in proposed | 18:31 |
| ahasenack_ | before it was 13.2.0 | 18:31 |
| jbicha | ahasenack_: I replied to your dia bug. poppler is now built with C++20 so it's expected that some poppler c++ rdepends will need to build at least their poppler support with c++20 too | 18:33 |
| ahasenack_ | jbicha: so the patch makes sense? | 18:34 |
| ahasenack_ | I'm seeing the same in gdcm | 18:34 |
| ahasenack_ | ok, just read your reply | 18:34 |
| jbicha | ahasenack_: yes or tweaking debian/rules to get the same outcome. You're welcome to upload that if you like | 18:34 |
| ahasenack_ | I'm trying the same on gdcm | 18:35 |
| ahasenack_ | but these build systems, ugh | 18:35 |
| jbicha | https://gitlab.freedesktop.org/poppler/poppler/-/commit/d8ae3ba | 18:35 |
| ahasenack_ | CMakeFiles/rules.ninja | 18:35 |
| -ubottu:#ubuntu-devel- Commit d8ae3ba in poppler/poppler "Require C++20" | 18:35 | |
| ahasenack_ | thx | 18:35 |
| Eickmeyer | Question to anyone who might be able to answer, but requires packaging knowledge: in order to solve bug 2063899 more robustly, I'm thinking about dpkg-diverting and wrapping /usr/sbin/adduser with /usr/sbin/adduser-actual --ingroup audio $@ so that all users are automatically added to the audio group by default in Ubuntu Studio. Test have | 18:43 |
| -ubottu:#ubuntu-devel- Bug 2063899 in ubuntustudio-default-settings (Ubuntu Oracular) "[SRU] Users are not initially configured properly for audio in Ubuntu Studio" [High, Triaged] https://launchpad.net/bugs/2063899 | 18:43 | |
| Eickmeyer | been successful, and vorlon gave me the advice to make the wrapper. The question is, what could really go wrong? To me it seems like it might break something. | 18:43 |
| ahasenack_ | so I dist-upgrade oracular to oracular-proposed, and lose network :/ | 18:44 |
| ahasenack_ | Jun 24 18:43:02 o-plusone systemd[1]: systemd-networkd.service: Failed with result 'exit-code'. | 18:45 |
| enr0n | ahasenack_: is this in LXD by chance? | 18:46 |
| ahasenack_ | enr0n: yes, and I just found https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2046486 | 18:47 |
| -ubottu:#ubuntu-devel- Launchpad bug 2046486 in systemd (Ubuntu) "units with credentials fail in LXD containers" [High, Triaged] | 18:47 | |
| ahasenack_ | still looking what these "credentials" might be | 18:47 |
| enr0n | ahasenack_: ah I thought I had added more context to that bug already. I will do that now. But e.g. ImportCredential=<blah> in systemd-networkd.service does this | 18:48 |
| ahasenack_ | I see the apparmor denial on /dev/shm | 18:49 |
| enr0n | Many core services have some kind of credential-using setting specificed now | 18:49 |
| enr0n | The workaround is to set security.nesting=true for your container | 18:49 |
| enr0n | ahasenack_: the idea is that this will become the default in lxd soon, but it's an easy workaround for now | 19:01 |
| ahasenack_ | nesting true will be default? | 19:01 |
| ahasenack_ | does that relax some security features? | 19:01 |
| === ahasenack_ is now known as ahasenack | ||
| enr0n | ahasenack_: yes that's the idea, see https://github.com/canonical/lxd/issues/13631 | 19:04 |
| -ubottu:#ubuntu-devel- Issue 13631 in canonical/lxd "Enable `security.nesting` by default for unprivileged containers and modern enough images" [Open] | 19:04 | |
| enr0n | Well at least for unprivileged containers, but that itself is the default | 19:05 |
| ahasenack | schopin: around? | 20:57 |
| ahasenack | schopin: asking about the glibc-2.39-3.1ubuntu1 upload, which has a Breaks for base-files (<< 13.3ubuntu1~) | 20:57 |
| ahasenack | but no new base-files upload that I can see | 20:57 |
| ahasenack | this is breaking armhf and riscv64, because those are the only arches where this glibc built (see https://launchpad.net/ubuntu/+source/glibc/2.39-3.1ubuntu1) | 20:58 |
| ahasenack | I'm getting | 20:58 |
| ahasenack | libc6 : Breaks: base-files (< 13.3ubuntu1~) but 13.1ubuntu1 is to be installed | 20:58 |
| ahasenack | E: Unable to correct problems, you have held broken packages. | 20:58 |
| ahasenack | was that a typo, and you meant base-files 13.1ubuntu1~ instead in that breaks? | 20:58 |
| jbicha | ahasenack: we deleted base-files from -proposed earlier today (see #ubuntu-release backlog) so yeah some followup is needed | 21:02 |
| === dbungert1 is now known as dbungert | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!