[00:45] <tsimonq2> I figured out that debhelper-compat is showing up in check-mir, which is a part of ubuntu-dev-tools. Doing an upload to Sid which just denylists that so nobody wastes time on it.
[01:02] <UnivrslSuprBox> tsimonq2: 2048953 re:grub-common and python3-apt
[01:03] <UnivrslSuprBox> *ahem* lp:2048953
[01:03] -ubottu:#ubuntu-devel- Launchpad bug 2048953 in grub2 (Ubuntu) "grub fails to add boot entries if python3-apt is missing" [Undecided, New] https://launchpad.net/bugs/2048953
[01:31] <UnivrslSuprBox> I wonder if a dependency from any version of grub to python3-apt is strictly desirable, though maybe it's not bothersome given ubuntu-advantage-tools and cloud-init depend on it too.
[02:06] <tsimonq2> juliank, mkukri, bdmurray: ^^^^^ :)
[02:06] <tsimonq2> In other news, https://git.launchpad.net/ubuntu-dev-tools/commit/?id=e90ceaf26b3ea2d0f4249d9b7dde8403bd8f4178 denylists debhelper-compat.
[02:06] -ubottu:#ubuntu-devel- Commit e90ceaf in ubuntu-dev-tools "In check-mir, ignore debhelper-compat when checking the build dependencies. This is expected to be a build dependency of all packages, so warning about it in any way is surely a red herring."
[02:06] <tsimonq2> I also added support for virtual packages in check-mir: https://git.launchpad.net/ubuntu-dev-tools/commit/?id=a5185e461226d671fe92744e6fe37f4239dd8149
[02:06] -ubottu:#ubuntu-devel- Commit a5185e4 in ubuntu-dev-tools "Add proper support for virtual packages in check-mir, basing the determination solely off of binary packages. This is not expected to be a typical case."
[02:07] <tsimonq2> That should be landing in Noble over the next 12-24.
[02:38] <tsimonq2> https://launchpad.net/ubuntu/+source/bluez/5.71-1ubuntu2
[03:31] <tsimonq2> I gave Ben a haircut: https://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/ben/revision/184
[03:46] <tsimonq2> Vim update building for Unstable which should fix this issue if anyone else has been annoyed like it like me: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/2047982
[03:46] -ubottu:#ubuntu-devel- Launchpad bug 2047982 in vim (Ubuntu) "Highlighting of patches offers insufficient contrast" [Medium, In Progress]
[08:01] <mkukri> tsimonq2: do you have a usecase for grub being installed without python3-apt? if not i think we'll just add it to "Depends" for grub-common
[12:00] <bdrung> @pilot in
[14:39] <adrien> I'm continuing on the path of disabling TLS <= 1.1 and I'm wondering if anyone is aware of similar things in Debian: I don't think I've read anything about doing that across the distribution and I expect I would have heard a lot about it if it was the case, but I'd prefer a confirmation
[14:40] <adrien> the reason I ask is to know whether I should push a corresponding change in rabbitmq through ubuntu or try to do it through debian
[15:21] <UnivrslSuprBox> adrien: Do you have a thread somewhere where the work to disable TLS 1.1 and below is discussed?
[15:23] <UnivrslSuprBox> mkukri: I don't have any specific need to have grub and not python3-apt. I can grumble about dependency creep, but pretty much everyone will have cloud-init or ubuntu-advantage-tools installed so it's no big deal. Adding python3-apt to grub-common's Depends is good.
[15:27] <mkukri> ack, ive put it in TODO. ive merged grub 2.12 (non-rc1) for Debian on salsa, and that's coming soon, and then there's gonna be a  erge and uploads for all grubs in Ubuntu, so unless this is urgent for some reason, ill include this in that
[15:27] <UnivrslSuprBox> Not urgent, I can install python3-apt manually and add a comment to the code to say why
[15:28] <mkukri> okay, ill try to remember putting your LP# in the changelog so youll get notified when it's out
[15:43] <adrien> UnivrslSuprBox: it's actually something fairly old by now but full implementation takes a lot of time; see https://discourse.ubuntu.com/t/default-to-tls-v1-2-in-all-tls-libraries-in-20-04-lts/12464
[15:51] <UnivrslSuprBox> adrien: Thanks. I haven't heard of a concerted effort within Debian, either.
[15:54] <adrien> OK; I would expect systemd-level drama on such a topic tbh
[16:04] <sudip> mkukri: you forgot to remove the maintainer change in d/control for the Debian debdiff for cunit :)
[16:05]  * sudip is removing that now
[16:05] <mkukri> woops, thank you
[16:10] <sudip> mkukri: have you seen the comment at https://bugs.debian.org/1057930 ? Specifically the line saying "Note that getmaxx(win) returns win->_maxx + 1, and similar for getmaxy.". if that is true then your patch will be adding 1 to all x and y.
[16:10] -ubottu:#ubuntu-devel- Debian bug 1057930 in src:cunit "cunit: FTBFS: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}" [Serious, Open]
[16:12] <mkukri> oh oh
[16:13] <sudip> https://sources.debian.org/src/ncurses/6.4+20231209-1/include/curses.h.in/?hl=1203#L1203
[16:15] <mkukri> ah that is rather annoying, i fixed up the same thing in multiple packages, so probably all need fixed
[16:18] <mkukri> sudip: im in a meeting now, but i can prepare updated patches later
[16:18] <sudip> mkukri: dont worry about cunit, I will fix it for you.
[16:20] <mkukri> ok thanks, but i think ncurses-hexedit and probably the already uploaded clog has the same issue as well
[16:20] <mkukri> (no clog was different, newer mind, but ncurses-hexedit defenitely has this)
[16:24] <sudip> getmaxx and getmaxy is not used in ncurses-hexedit debdiff
[16:24] <mkukri> ah if this is all, that is great
[16:24] <mkukri> i was just remembering ncurses
[16:46] <bdrung> @pilot out
[16:57] <kanashiro> @pilot in
[17:26] <tsimonq2> sudip: Thank you for helping mkukri with the NMUs, I appreciate it :)
[17:28] <tsimonq2> mkukri: grub2 cc UnivrslSuprBox> To my understanding, python3-apt is a part of the core Ubuntu platform. UnivrslSuprBox works on a project that essentially rebuilds the Ubuntu archive, so his dependencies are slightly more relaxed. I think it is reasonable (and in fact, important) to explicitly define that dependency if grub2 expects to use it.
[17:29] <UnivrslSuprBox> And I'm happy to put in effort to make my weird usecase work correctly! At the very least, you can expect high-quality bug reports from me :)
[17:47] <tsimonq2> ^^^^^ :)
[17:50] <tsimonq2> Looks like there's now eight source NEW packages in the queue.
[17:50] <tsimonq2> kanashiro: Do you plan on reviewing any of those? Any that I should avoid?
[17:50] <tsimonq2> Eickmeyer, arraybolt3: Great opportunity to get some practice patch piloting for source NEW ^^^^ :)
[17:51] <tsimonq2> jjohansen: https://code.launchpad.net/~enr0n/ubuntu/+source/apparmor/+git/apparmor/+merge/458453 may interest you
[17:53] <Eickmeyer> tsimonq2: Yeah, got my hands full cooking a Raspberry Pi at the moment. (pun intended)
[17:53] <tsimonq2> Eickmeyer: Save me a slice! :D
[18:01] <tsimonq2> In case anyone else is curious on where the .sbuildrc is for Launchpad builders: https://git.launchpad.net/launchpad-buildd/tree/sbuildrc
[18:04] <tsimonq2> Dear whoever wrote this comment: you may not have known how much sense it made then, but it makes tons of sense to me now, and it fixed an issue I had:
[18:04] <tsimonq2>     # It's not clear how much sense this makes, but sudo set this as a
[18:04] <tsimonq2>     # fallback default, so keep it for compatibility.
[18:04] <tsimonq2>     'TERM' => 'unknown',
[18:04] <tsimonq2> (I don't plan on making an LP to launchpad-buildd just to update a comment. :P)
[18:06]  * tsimonq2 really really wishes Launchpad's Git could do blame so I can thank them without cloning the repo...
[18:40] <kanashiro> tsimonq2 sorry, you can review whatever you prefer, just add a comment saying so and we avoid any double review
[20:10] <tsimonq2> kanashiro: Roger that :)
[20:45] <tsimonq2> Just verified that bug 2047982 is fixed in Debian via a new upstream release. Uploaded that to Sid, will upload to Noble shortly, should affect Vim syntax highlighting for all Noble users.
[20:45] -ubottu:#ubuntu-devel- Bug 2047982 in vim (Ubuntu) "Highlighting of patches offers insufficient contrast" [Medium, In Progress] https://launchpad.net/bugs/2047982
[20:58] <arraybolt3> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/2049104 New HWE kernel in Jammy breaks VBox for everyone.
[20:58] -ubottu:#ubuntu-devel- Launchpad bug 2049104 in virtualbox (Ubuntu) "Virtualbox 6.1.38 not compatible iwith kernel 6.5.0-14-generic" [Undecided, New]
[20:59] <arraybolt3> (not my bug report, but this looks pretty, uh, bad.)
[20:59] <tsimonq2> Sigh...
[21:00] <arraybolt3> looks like VBox 6.1.46 is the earliest one that fixes it.
[21:01] <arraybolt3> https://www.virtualbox.org/wiki/Changelog-6.1#v46
[21:01] <tsimonq2> arraybolt3: so uh, bug 2017101 has been ready to go for months now
[21:01] -ubottu:#ubuntu-devel- Bug 2017101 in virtualbox-hwe (Ubuntu Mantic) "[SRU] Virtualbox 7.0.12 and 6.1.48" [Undecided, In Progress] https://launchpad.net/bugs/2017101
[21:01] <arraybolt3> "Linux Host: Added initial support for kernel 6.5 (NOTE: Guest Additions do not support kernel 6.5 yet)"
[21:02] <arraybolt3> tsimonq2: hmm
[21:02] <tsimonq2> arraybolt3: I just pinged both the release team and SRU team very loudly (although the former is just to get more coverage).
[21:02] <tsimonq2> You all know how many people use VirtualBox, right?
[21:02] <tsimonq2> I mean, I'm not one of them :P but a lot
[21:02] <arraybolt3> thanks, I'll be happy to be the guinea pig for verifying.
[21:02] <arraybolt3> yeah I use it sometimes :P
[21:02] <tsimonq2> arraybolt3: please :)
[21:03] <tsimonq2> Currently, ALL this SRU is waiting on is for someone to review it.
[21:04] <tsimonq2> I *will* be poking until someone does now, given this is a regression in a stable release.
[21:05] <arraybolt3> +1
[21:09] <bdmurray> I seem to recall there being questions about the validity of the microrelease exception for virtualbox. https://lists.ubuntu.com/archives/ubuntu-release/2023-September/005787.html
[21:11] <tsimonq2> Well, now it's snowballed into something bigger.
[21:18] <Eickmeyer> Imagine how much work is being lost right now because of this.
[21:40] <kanashiro> @pilot out
[21:45] <kanashiro> is there any process to add a epoch to a version string of a package? For instance, in Debian, we need to mail debian-devel to discuss with other developers, but I did not find anything like that in Ubuntu
[21:45] <kanashiro> I am asking because of this: https://bugs.launchpad.net/ubuntu/+source/backport-iwlwifi-dkms/+bug/2046871
[21:45] -ubottu:#ubuntu-devel- Launchpad bug 2046871 in backport-iwlwifi-dkms (Ubuntu) "migrate to upstream release/coreNN branch" [High, In Progress]
[21:45] <tsimonq2> kanashiro: IME it's a bit more loose/consensus based.
[21:46] <tsimonq2> Please don't let this come across wrong but ABSOLUTELY ALWAYS 100% ALWAYS be sure an Epoch is ABSOLUTELY necessary.
[21:46] <tsimonq2> Otherwise IMO Ubuntu can move a bit faster than that :)
[21:49] <kanashiro> by default I always try to avoid that, but in this case might be the solution. Or maybe there is a better way out that I am not seeing it. More opinions are welcome
[21:50] <tsimonq2> I would triple-check that upstream's naming scheme is what the sponsoree is suggesting. Otherwise, this does seem like one of the rare times you'd use it.
[21:53] <jbicha> kanashiro: what about using 1:0~84 instead of 1:84 . That allows for further tweaks of the version system before needing another epoch bump
[21:56] <kanashiro> jbicha fair enough, good point
[21:57] <kanashiro> I'll add a comment to the bug with all those considerations, I am not so confident to upload this right away
[21:58] <tsimonq2> It's better to not upload than upload when you're unsure. :)
[23:09] <arraybolt3> can autopkgtest-buildvm-ubuntu-cloud actually specify how much RAM the VM is intended to have? Looking at the manpage it kind of looks like that, but it seems weird to me since I thought all it did was build the VM disk image.
[23:18] <bdmurray> arraybolt3: I don't think it can but when you load the built image with qemu you can adjust the amount of ram
[23:19] <bdmurray> something like `autopkgtest ... -- qemu --ram-size=8192 --cpus=4 /srv/vms/autopkgtest-lunar-amd64.img`
[23:19] <bdmurray> I use that for checking locally if big_packages will help
[23:25] <arraybolt3> nice