[12:24] <kjerome1> Hi all,
[12:24] <kjerome1> I'm a bit frustrated - I have a simple bugfix pending for the cups-browsed package.
[12:24] <kjerome1> I uploaded a patch about two months ago and opened a merge request, yet they don't seem to get the maintainer's attention.
[12:24] <kjerome1> Is there anything you people could do to help me merge it? Should I email the maintainer?
[12:45] <seb128> kjerome1, hey, do you have the bug/mp reference? it's not showing on http://reports.qa.ubuntu.com/reports/sponsoring/index.html
[12:45] <sudip> for reference to others, its LP: #2028172
[12:45] -ubottu:#ubuntu-devel- Launchpad bug 2028172 in cups-browsed (Ubuntu) "Cups-browsed cannot bind to port 631 as non-root user on Ubuntu 23.04" [Undecided, Confirmed] https://launchpad.net/bugs/2028172
[12:45]  * sudip just added a comment there now
[12:48] <seb128> seems a bit of a complicate case, I will nudge Till to have him to review again
[13:31] <bluca> seb128: do you happen to know what's the status of apparmor patches needed in the upstream kernel for dbus-broker support?
[13:32] <bluca> it would be good if the package could be common between debian/ubuntu and I'd be happy to merge the backport in Salsa, as long as it doesn't break on Debian kernels with apparmor
[13:57] <seb128> bluca, hey, I don't know what's the status of upstreaming of the kernel changes but maybe sforshee can help there?
[14:00] <seb128> bluca, https://forum.snapcraft.io/t/snapd-still-requires-out-of-tree-apparmor-patches-for-strict-confinement/19632/20 suggests the remaining patch might land in linux 6.8
[14:01] <seb128> or jjohansen probably knows the current status better
[14:21] <jjohansen> bluca: they should land for the 6.9 kernel, they unfortunately are missing the 6.8 kernel due to a couple of issues
[14:21] <jjohansen> seb128: ^
[14:21] <seb128> jjohansen, thanks
[14:21] <bluca> ah nice
[14:22] <bluca> you'll probably want to mention it here: https://github.com/bus1/dbus-broker/pull/286
[14:22] -ubottu:#ubuntu-devel- Pull 286 in bus1/dbus-broker "Apparmor support" [Open]
[14:24] <paride> @pilot in
[14:26] <bluca> if you rub dbus-broker with the changes in that PR, but without kernel changes, do bad things happen?
[14:34] <seb128> I haven't tried ... jjohansen do you know?
[14:43] <bluca> if it doesn't have any adverse effects, then I can just backport it to Debian too
[14:54] <jjohansen> bluca: I am willing to help with that, depending on target version it will have some dependencies and won't be a single patch
[15:03] <bluca> sure that would be ok - I'd really like to see noble ship with dbus-broker v35 as it enables some new pidfd related features we need in systemd
[16:44] <paride> @pilot off
[16:44] <paride> heh, again
[16:44] <paride> @pilot out
[16:44] <tsimonq2> <3
[16:45] <tsimonq2> @pilot in
[16:45] <tsimonq2> Starting with golang-entgo-ent.
[16:56] <tsimonq2> Re-visiting bluez with a local build, Lintian, and testing round...
[16:57] <schopin> My eyes are tired: is there anything wrong with this version number for a Mantic SRU? 0.7.3-6.1ubuntu6.23.10.1
[16:57] <schopin> Lintian has a strange complaint that I don't remember seeing before: source: binary-nmu-debian-revision-in-source 0.7.3-6.1ubuntu6.23.10.1
[16:58] <tsimonq2> schopin: IME Lintian hates that combination for no good reason.
[16:59] <tsimonq2> 0.7.3 (upstream) -6.1 (Debian revision) ubuntu6 (revision in the release pocket) .23.10.1 (SRU version, could be .1, this one is personal pref, I like what you have)
[16:59] <tsimonq2> So, I think you're good :)
[17:01] <schopin> In this precise case, couldn't be .1 since we have the same version in Jammy and it'll need SRUing too.
[17:01] <schopin> Thanks for the second opinion!
[17:02] <tsimonq2> Perfectly rational; you're welcome :)
[17:04] <dbungert> @pilot in
[17:05] <tsimonq2> dbungert: golang-entgo-ent is done, bluez is in progress, you're welcome to take anything else, as I think bluez will take up the rest of my sponsorship time today. :)
[17:05] <dbungert> tsimonq2: awesome, thank you
[17:21] <tsimonq2> of course :)
[17:21] <tsimonq2> Bluez 5.72 tests well on my end. Was just missing a build dependency, but I've uploaded it now.
[17:21] <tsimonq2> @pilot out
[21:02] <dbungert> @pilot out
[22:46] <liushuyu> Hi ubuntu-devel, I discovered an incorrect upload https://launchpad.net/ubuntu/+source/rustc-1.68/1.68.2+dfsg0ubuntu1-0ubuntu5 where the package rebuilds against libgit2 1.7 but the uploader failed to update `Build-Depends`. I have prepared a fix in https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-vvv-1.68/+packages.
[22:47] <tsimonq2> @pilot in
[22:47] <tsimonq2> liushuyu: Looking :)
[22:47] <liushuyu> Since I have prepared the fix before that problematic upload, the release version was not fit for upload
[22:48] <tsimonq2> Knowing LocutusOfBorg, he likely did that NCR from a machine-generated list during a transition.
[22:56] <tsimonq2> liushuyu: Given that Steve was your last sponsor, I don't feel as if I need to review the package much further. I see your upload built successfully in a PPA, it's also on level one of the appropriate transition tracker entry ( https://ubuntu-archive-team.ubuntu.com/transitions/html/html/rust.html ), and Debian has this dependency set as such as well, so if there are issues I have confidence those
[22:56] <tsimonq2> patches can be backported ( https://salsa.debian.org/rust-team/cargo/-/blob/debian/sid/debian/control?ref_type=heads#L22 ). That all being said, not blocking, but I'll be following up on this tomorrow morning to see if there's any other action required according to Britney.
[22:58] <liushuyu> tsimonq2:  Debian's Rust toolchain packaging is currently very different than Ubuntu. However, Debian is also now transitioning to use Ubuntu's Rust toolchain packaging
[22:58] <liushuyu> (which is merging cargo source package into rust source package)
[22:59] <tsimonq2> Thanks for that info, that helps :) I've heard rumblings about more toolchain work in Foundations recently, figured this was a side effect of that.
[23:02] <tsimonq2> liushuyu: https://launchpad.net/ubuntu/+source/rustc-1.68/1.68.2+dfsg0ubuntu1-0ubuntu6 :)
[23:02] <liushuyu> tsimonq2: Yes. There were some resistence from Debian previously regarding the merge. But I believe the Debian Rust Team saw the issue with maintaining Cargo separately (Rust upstream does not intend you to build Cargo outside the `rustc` tree)
[23:03] <liushuyu> One of the issue was Cargo when building outside of the `rustc` tree will behave differently than when it is built in-tree
[23:03] <tsimonq2> Looking at the last successful buildset, we'll know if amd64 and friends are successful in ~< 2 hours, we'll know if riscv64 builds in about 12 hours ;) which means starting now it'll be about 14 hours (very roughly speaking) until Britney will tell us about any next steps.
[23:04] <liushuyu> ... because when being built in-tree, Cargo will know which version of `rustc` it is working with
[23:04] <tsimonq2> liushuyu: Sound logic. I'm glad Debian is being more cooperative, and I look forward to the day where these are mostly syncable. :D
[23:05] <tsimonq2> (Collaborative is the right word, not cooperative. :P)
[23:05] <liushuyu> tsimonq2: Thank you! The RISC-V 64 build times are very unpredictable, it could be ranging from 9 hours to 30 hours if building rustc
[23:06] <tsimonq2> (And that's partly because it's being emulated on amd64. ;))
[23:06] <liushuyu> tsimonq2: Hopefully we will have KVM-capable (while being faster than Intel 80486) RISC-V hardware this year
[23:07] <tsimonq2> That's what I keep hearing rumblings about, it would be nice to hear that definitively at some point. ;)
[23:07] <tsimonq2> liushuyu: Anyway, generally speaking I'm happy to help if you have anything further for me, but as for right this second, I'm going to grab some dinner.
[23:07] <tsimonq2> I'll check back on these two uploads (the one from -release and the one in here) in the morning to see how they went.
[23:07] <liushuyu> tsimonq2: Thank you! I think the current situation is just waiting on the builds
[23:08] <tsimonq2> @pilot out