[00:35] <tsimonq2_ephemer> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A
[00:35] <tsimonq2_ephemer> I'm always happy to help with sponsoring. :)
[00:35]  * tsimonq2_ephemer will be back to @pilot in later
[00:36] <tsimonq2_ephemer> (I might not be the only one experiencing Matrix interruptions Soon; worth looking into if you depend on that platform.)
[01:15] <mdeslaur> tsimonq2_ephemer: nope! you didn't drop the patch, that's the important part :)
=== sammy12 is now known as bomtom
[10:49] <bluca> did something change in jammy tonight w.r.t. llvm? on github actions jammy images, installing lldb-15 started failing in the systemd CI with:
[10:50] <bluca> The following packages have unmet dependencies:
[10:50] <bluca> python3-lldb-14 : Conflicts: python3-lldb-x.y
[10:50] <bluca> python3-lldb-15 : Conflicts: python3-lldb-x.y
[10:50] <bluca> nothing is pulling in python3-lldb-x.y, it doesn't even exist, as far as I can tell
[10:58] <bluca> https://github.com/systemd/systemd/actions/runs/5678852202/job/15391861406#step:3:490
[11:24] <bdrung> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: bdrung
[12:34] <rbasak> bdrung: o/ I've been looking at apport dep8 failures
[12:34] <rbasak> But now I see that it FTBFS with a pylint problem. pylint has been updated since it last built on Mantic so that might be the reason.
[12:35] <rbasak> Can we just stop running pylint as part of the package build? It's inappropriate as it causes regressions in the archive when pylint implements new checks, for no benefit to the distribution. Linting belongs in development workflow, not in production builds.
[12:37] <rbasak> Same for black --check, etc.
[12:38] <bdrung> rbasak, but then security updates are not checked
[12:38] <bdrung> we have the linters run on every upstream commit
[12:39] <rbasak> That's up to the security team's development workflow. The downside is that if there's been a pylint update since the last build, causing an unrelated lint regression it's going to _slow down_ issuing security updates while it's worked around.
[12:40] <rbasak> By all means have a mechanism in there to run linting, but in production it should be informative only, and not cause a failure.
[12:41] <bdrung> pylint and mypy found issues in the past. could we tone down pylint during the package build to maybe only errors?
[12:42] <bdrung> can you open a bug against apport?
[12:42] <rbasak> Maybe this should have a wider discussion
[12:42] <rbasak> IMHO the same applies to things like -Werror but I don't know what we do there.
[12:43] <bdrung> for -Werror the consensus is that we do not want it
[12:43] <rbasak> Ah OK. So yeah, I think the same principle applies here.
[12:43] <bdrung> move the linter to an autopkgtest instead?
[12:43] <rbasak> No, not even autopkgtest.
[12:44] <rbasak> Again, we'd get regressions in the archive as pylint moves
[12:44] <rbasak> (or black, etc)
[12:44] <rbasak> It should be something to check before upload, and then not blocked on again in archive workflow following upload.
[12:45] <rbasak> I don't know of a good tooling solution for that.
[12:45] <rbasak> It'd be nice if DEB_BUILD_OPTIONS had some defined parameter for this purpose but I don't think it does.
[12:46] <bdrung> DEB_BUILD_OPTIONS would be a good idea. i.e. having a strict mode that enables -Werror and all the linters
[12:46] <bdrung> then you can build with strict mode before upload
[12:46] <rbasak> Strict mode is a good term
[12:47] <rbasak> The usefulness of that might be limited to native and native-type packages though. Where there's an out-of-distro upstream, the packager would never want strict mode.
[13:03] <ahasenack_> jbicha: regarding mutter and gnome-shell 44.3 in lunar, first mutter, let it phase?
[13:08] <ginggs> ahasenack_: from # ubuntu-release
[13:08] <ginggs> <jbicha> rbasak: mutter and gnome-shell at once is fine since there isn't a phasing issue with this update
[13:08] <ahasenack_> I saw the note in the bug even, but it also said it was ok to wait for phasing
[13:09] <ahasenack_> hm, I must have been offline when jbicha answered
[13:09] <ahasenack_> and my nick is wrong
=== ahasenack_ is now known as ahasenack
[13:15] <jbicha> ahasenack: yes, you could let mutter phase first but it's not necessary
[13:17] <ahasenack> ok
[13:22] <cjwatson> IME https://pre-commit.com/ is a better way to handle linting for anything maintained in git - that way you can control what versions of linters you're using, and you aren't at the mercy of distribution-wide changes
[13:22] <cjwatson> And it's hooked in at a much more appropriate stage of development
[14:08] <mitchdz> Anyone know what's going on with livecd-rootfs in Mantic? autopkgtests are failing and it's keeping my package (multipath-tools) in -proposed
[14:23] <rbasak> pre-commit> oooh, nice!
[14:23] <rbasak> I see it's packaged in Debian, too.
[15:00] <bdrung> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A
[15:19] <enr0n> bluca: there were security updates for llvm-toolchain-14 and llvm-toolchain-15 (at least). Not sure if those caused it. But python3-lldb-{14,15} both Provides:/Conflicts:/Replaces: Provides: python3-lldb-x.y
[15:22] <bluca> our ci is installing clang-15 lldb-15 lld-15 clangd-15, and somehow that started pulling in both python3-lld-14 and -15
[15:22] <bluca> we solved it by explicitly pulling in python3-lld-15
[15:24] <bluca> it has been running jammy with that same configuration for over a year, this issue appeared this morning
[15:29] <enr0n> bluca: okay. Not sure what happened there. I tried to reproduce it quickly in a new jammy container, but I didn't hit the issue.
[15:39] <bluca> very weird
[15:49] <rbasak> https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-racb-experimental/?format=plain
[15:49] <rbasak> This server could not verify that you are authorized to access the document you requested.
[15:49] <rbasak> What am I missing?
[15:50] <rbasak> I saw the test appear in /running and it's gone now, so presumably it finished
[15:50] <rbasak> Is there a delay expected?
[15:56] <cjwatson> rbasak: pre-commit> yeah, we use it extensively in Launchpad, for instance - https://git.launchpad.net/launchpad/tree/.pre-commit-config.yaml
[15:56] <xnox> mwhudson: yes.... i got scared to upload  2.900
=== rharper_ is now known as rharper
[16:04] <bdmurray> the autopkgtest-cloud code is also using pre-commit.
[16:18] <ahasenack> bdmurray: up for a quick verification for lunar on https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/1971984? Then I could release it
[16:18] -ubottu:#ubuntu-devel- Launchpad bug 1971984 in pcsc-lite (Ubuntu Lunar) "pcscd.socket is disabled after installation" [High, Fix Committed]
[16:18] <ahasenack> it's install + systemctl status
[16:18] <ahasenack> and install old, upgrade, systemctl status
[16:28] <rbasak> Is there a delay expected> apparently so
[16:28] <rbasak> I have results available now.
[16:37] <bdmurray> ahasenack: I can fit that verification in
[16:37] <ahasenack> thx
[16:37] <shadeslayer> Hi, I'm trying to build perf for my devel machine that's running the mainline 6.5-rc3 kernel, but I'm confused between all the different instructions on the wiki, the existence of a git bundle and not being able to clone the git repo mentioned on the web page. Could someone point me towards how I can obtain the source for the mainline debs? thanks!
[16:50] <shadeslayer> ahhh ... I guess it's just git bundle unbundle
[17:02] <kanashiro[m]> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: kanashiro[m]
=== orndorffgrant5 is now known as orndorffgrant
[18:53] <ahasenack> coreycb: hi, do you think for future openstack-component SRUs, for the verification step, you could add something that shows that the package from proposed was used?
[18:54] <ahasenack> coreycb: perhaps like peter sabaini did for ceph in https://bugs.launchpad.net/cloud-archive/+bug/2018929/comments/13
[18:55] -ubottu:#ubuntu-devel- Launchpad bug 2018929 in Ubuntu Cloud Archive "[SRU] ceph 17.2.6" [Undecided, New]
[19:33] <rbasak> bdrung: I filed bug 2028879 and bug 2028881 rather than uploading since both of my proposed fixes are a bit questionable. Would you be happy with me dropping the lint tests from debian/rules, and to add vim to the autopkgtest dependencies for now?
[19:33] -ubottu:#ubuntu-devel- Bug 2028879 in apport (Ubuntu) "Lack of default dpkg diverts causes autopkgtest failure" [High, Triaged] https://launchpad.net/bugs/2028879
[19:33] -ubottu:#ubuntu-devel- Bug 2028881 in apport (Ubuntu) "apport FTBFS" [High, Triaged] https://launchpad.net/bugs/2028881
[19:40] <bdmurray> ahasenack: I've verified bug 1971984 for Lunar
[19:40] -ubottu:#ubuntu-devel- Bug 1971984 in pcsc-lite (Ubuntu Lunar) "pcscd.socket is disabled after installation" [High, Fix Committed] https://launchpad.net/bugs/1971984
[20:09] <ahasenack> bdmurray: thanks
[21:07] <kanashiro[m]> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A
[21:40] <tsimonq2_> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: tsimonq2_
[21:57] <bdrung> rbasak, i would be fine with adding "|| true" to the lint call (to still have the output) and to add vim. for the upstream fix i have to have a deeper look into the test to make it more robust.
[22:05] <rbasak> OK thanks. I'll do it tomorrow.