14:00:05 <charles> #startmeeting
14:00:05 <MeetBot> Meeting started Thu Jul 16 14:00:05 2026 UTC.  The chair is charles. Information about MeetBot at https://wiki.debian.org/MeetBot.
14:00:05 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:18 <charles> #topic Roll Call
14:00:27 <charles> hi people o/
14:00:35 <eamanu> hola hola!
14:00:38 <santiago> hi!
14:00:38 <ta> hi
14:00:39 <charles> Please go ahead and announce your presence here
14:00:43 <helmut> hello
14:01:06 <guilhem> hi
14:01:55 <charles> our agenda can be found in https://pad.riseup.net/p/lts-meeting-agenda
14:02:21 <paride> o/
14:02:31 <Beuc> o/
14:03:18 <charles> #topic New team members
14:03:36 <utkarsh2102> hi! o/
14:03:41 <charles> (no new team members)
14:04:01 <charles> #topic Action item review
14:04:21 <charles> Action: Follow-up to ML and Andreas concerning upload of nvidia-graphics-drivers
14:04:48 <charles> there were some previous actions listed in the pad
14:04:56 <charles> do we have something new on this?
14:04:57 <jochensp> hi, sorry
14:05:05 <charles> tobi: are you around?
14:05:14 <santiago> no, tobi is on VAC
14:05:17 <utkarsh2102> sent apologies via pad
14:05:38 <santiago> but he said that he will tackle this update
14:05:46 <charles> ack
14:06:05 <charles> also saw the update on anbe, they're on vacation
14:06:13 <santiago> exactly
14:06:31 <charles> ack, so lets move on
14:06:58 <charles> #action tobi will handle the upload
14:07:09 <charles> #topic Bookworm 12 LTS handover status
14:07:49 <santiago> so, as you all may know, the bookworm-security upload queue is now open
14:08:29 <santiago> I still have a list of tasks to handle, let's say post-handover
14:08:56 <santiago> those (as well as Debian 11 ELTS-related) are on top of my ToDo list
14:09:13 <santiago> the handover announcement was released: https://www.debian.org/News/2026/20260712
14:10:15 <charles> santiago: you mean the lts queue where we can upload without secteam releasing the updates?
14:10:18 <santiago> and I think that's it, for now
14:10:22 <santiago> charles, indeed
14:10:27 <charles> cool!
14:11:03 <santiago> BTW, thanks to the sec team for their help during the "transition period"!
14:11:14 <santiago> any comments?
14:11:14 <utkarsh2102> yes, thank you! o/
14:11:17 <charles> thanks indeed!
14:11:22 <eamanu> thanks!
14:12:29 <santiago> shall we move on?
14:12:31 <charles> #topic Debian LTS BoF
14:12:34 <charles> yes
14:12:43 <charles> but it's you again :p
14:12:50 <santiago> thank you, charles
14:13:49 <santiago> DebCamp 26 is currently happening, and next week is DebConf
14:14:06 <santiago> we have a Debian LTS bof, scheduled on Friday
14:14:54 <charles> Jul 24 (Fri): 15:00 local time and 18:00 UTC
14:14:55 <santiago> if you're around and want to participate in the bof, please let me know
14:15:04 <santiago> so I can add you to the list of speakers :-)
14:15:16 <santiago> (and to do better than last year's)
14:15:35 <santiago> I still need to check with video team if remote participation will be possible
14:16:05 <santiago> I asked for that, but not sure yet if that would be feasible
14:16:32 <santiago> also, if you have any topics to be discussed during the BoF, please, let me know
14:16:34 <utkarsh2102> (won't join remotely; it'll be almost 12 AM my time :()
14:16:50 <santiago> utkarsh2102, no worries
14:17:40 <santiago> any questions about the BoF?
14:17:55 <charles> do we have a pad for it yet?
14:17:58 <santiago> URL: https://debconf26.debconf.org/talks/97-debian-lts-bof/
14:18:21 <Beuc> what format will it be?
14:18:21 <santiago> yes, but no content yet
14:18:29 <charles> https://pad.dc26.debconf.org/p/97-debian-lts-bof
14:18:40 <charles> ack
14:19:17 <santiago> Beuc, my plan is to review what we discussed last year, give an update about the different points that we discussed, and future plans
14:20:11 <santiago> but as any BoF, the discussion is open
14:20:15 <santiago> *as for
14:20:45 <charles> any more comments or questions?
14:21:37 <charles> so let's move on
14:21:44 <charles> #topic gen-DSA improvements and reviewing advisory text
14:22:02 <charles> I think it refers to salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/310
14:22:12 <charles> utkarsh2102 improvements on the script
14:22:49 <utkarsh2102> yes, removes unused variables so that it doesn't slip through and don't go in announcements
14:23:11 <charles> +1
14:23:44 <jochensp> +1
14:23:45 <guilhem> +1
14:23:53 <utkarsh2102> +1'ing on MR would help \o/
14:23:59 <santiago> yes, and the final word is on the sec team side
14:24:02 <utkarsh2102> so that i can get sec team to actually review.
14:24:52 <slyon> o/ (sorry, I'm delayed)
14:25:01 <santiago> but, the other point of this topic is proof-reading announcement texts
14:25:39 <santiago> *I* personally think it is a good idea to have somebody else that reads/review the announcements
14:26:18 <santiago> especially since, once a DLA is sent, the mail cannot be obviously modified
14:26:25 * LucasKanashiro[m] waves
14:26:48 * bhe[m] also waves..
14:27:38 <utkarsh2102> in theory, that's a good idea. in practice, that might cause a bit of friction in workflows. for instance - people who are not generally here on IRC? and what if i'm doing work in weird timezone and people aren't around? do we reserve the DLA and wait for the next day to send? (i think we should think about those cases)
14:28:39 <utkarsh2102> a good sacrifice could be to have a set of best practices (i think there's some doc already?) or add more on top of that (if it's not enough) and make sure people follow that.
14:28:50 <utkarsh2102> or something like: at least send your DLA text here and give it at least N minutes?
14:28:50 <santiago> IMO, having someone to proof-read would be idea, but should *not* be a blocker
14:28:53 <eamanu> imo it's good, and better for non-english speaker, but it could stuck a bit the dla release, maybe?
14:29:32 <Beuc> I tried for the last 2 DLAs by asking for a review/+1 on IRC, and this tended to work fine, especially if that's an understood procedure.  I believe we're more and more waiting for the various CI processes to finish (debusine/salsa/buildds install/etc.) so that's a good time frame to prepare the DLA text and ask for a review.
14:29:59 <santiago> we could share the text as soon as we trigger a debusine (or Salsa CI) pipeline ;-)
14:30:48 <charles> I don't have any strong opinions on the matter, so whatever is agreed and documented is fine for me
14:31:02 <utkarsh2102> same^
14:31:04 <LucasKanashiro[m]> How would be this review process? Add the text to a pad and ask for review here?
14:31:14 <guilhem> perhaps not a big deal, but assigning the DLA ID too early might lead to them being published off order on the mailing list
14:31:20 <utkarsh2102> or paste
14:31:26 <helmut> do you happen to have opinions on how useful ci.freexian.com still is now that we have reverse dependency autopkgtests on debusine?
14:31:57 <charles> but generally I search on the secteam or lts-announce mailing list for previous D{S,L}A on the package and copy, paste and adjust the text
14:32:28 <charles> helmut: could we discuss that next on a separate topic?
14:33:07 <jochensp> charles: copying the DSA text sounds like a good recommendation, could you add that to the docs?
14:33:18 <charles> jochensp: sure
14:33:41 <charles> #action charles to add recommendation to use previous DLA/DSA text as base
14:33:46 <santiago> thanks
14:34:06 <slyon> thx!
14:34:30 <charles> should we move this discussion on the workflow for reviewing the DLAs to the mailing list?
14:34:52 <slyon> and if noting is found, we could still paste here and give it at least som 30min for someone to proof-read
14:34:56 <charles> but I also would be ok to extend the discussion here a bit
14:35:49 <Beuc> well you just ask for somebody else to re-read, no need to over-procedurize :)
14:36:06 <santiago> .
14:36:40 <santiago> (I mean, I do agree with Beuc)
14:36:50 <charles> ack, so upload to debusine, prepare the DLA and send a message to irc asking for a review
14:37:15 <charles> if people review, awesome, if not just go ahead and publish after the update is installed
14:37:22 <charles> right? ^
14:38:05 <charles> s/prepare the DLA/prepare the DLA text/
14:38:12 <slyon> ack. with the hint to check previous D{S,L}A from the same package first and adopt the text.
14:39:38 <santiago> that sound simple enough :-)
14:39:43 <santiago> any other thoughts?
14:40:32 <charles> since I'm touching the docs, I can try to documente both things (the use of previous texts and the recommendation to send a message asking for review on irc)
14:41:14 <santiago> thank you, charles
14:41:43 <charles> #action charles will also document the part about sending the text for review on irc
14:42:21 <charles> #topic ci.freexian.com is still useful with debusine rdep testing?
14:42:32 <charles> helmut: feel free to chime in
14:43:26 <helmut> well. I'm not sure how you use those services. I just make them work
14:43:42 <helmut> how much do you rely on debusine and how much do you rely on debusine.freexian.com at this time?
14:43:55 <helmut> err ci.freexian.com aka the britney resulst
14:44:09 <charles> but I have something to add, I did upload nginx a couple months ago to elts and the set of rdeps autopkgtests differed from debusine to ci.freexian.com
14:44:15 <jochensp> I ignored ci.f.c a couple times when it was failing and it was surely the CI system not the package
14:44:37 <helmut> jochensp: was it failures or regressions there?
14:44:45 <charles> in the end, both passed so I did not care about the difference and moved on
14:44:57 <jochensp> helmut: not sure anymore, I think we discussed it and agreed to ignore it
14:45:50 <helmut> let's put this the other way round: what works on britney2+ci.freexian.com and doesn't yet work to your needs on debusine.freexian.com?
14:46:20 <helmut> it's also fine to schedule answering this for next meeting
14:46:21 <jochensp> afair the point was that ci.f.c uses a different autopkgtest virt-server and that could result in new failures
14:46:34 <slyon> is ci.f.c using VMs or containers as test runners? IIRC I saw a revdep test of dnsmasq (LXC) that was skipped on debusine but running ci.f.c
14:46:47 <Beuc> debusine is progressing nicely but there are still issues, including testing against very old reference versions (instead of the last security upload), and 'isolation-test' support is still being worked on.  ci.f.c is already degraded (no more arm64) but I'd say it would be worth keeping it around a bit longer.
14:46:49 <slyon> (because of isolation-machine)
14:46:57 <helmut> jochensp: yes, but we want to get rid of autopkgtest-virt-qemu and use autopkgtest-virt-incus (vm + lxc) for all
14:47:24 <helmut> slyon: ci.f.c uses vms for x86 and it used containers for everything else (but we no longer have arm workers)
14:47:31 <santiago> I need to configure the isolation-machine support for some packages / per architecture. that has been fixed
14:48:03 <helmut> the goal should be that debusine.f.c runs amd64 on incus-vm and everything else on incus-lxc (incus-vm does not support i386)
14:48:34 <jochensp> helmut: is getting rid of a-v-qemu independent of dropping ci.f.c?
14:48:38 <slyon> ok. isolation-machine would certainly be useful on debusine. But IIUC this migh tbe solved by autopkgtest-virt-incus.
14:49:20 <helmut> jochensp: no. it simply is that ci.d.n will use a-v-incus and debusine uses a-v-incus and the dropping is bound to dropping ci.f.c
14:49:47 <jochensp> ah
14:49:52 <slyon> other than that, Debusine is much nicer (and faster) than britney.
14:49:54 <helmut> afaiui, making isolation-machine work on debusine.f.c is a matter of task configuration
14:50:31 <helmut> so can you collect reasons to keep ci.f.c for next reason and we sort out that isolation-machine works on debusine.f.c
14:50:48 <helmut> s/next reason/next meeting/
14:50:56 <jochensp> (I don't have reasons to keep ci.f.c)
14:51:29 <Beuc> (FWIW we support i386 until at least 2031-06-30/bullseye)
14:51:29 <charles> #action collect any reasons to keep ci.freexian.com (britney) for next meeting
14:51:45 <charles> #action come back to this topic next meeting
14:51:51 <helmut> the transition would be done in two steps. 1. disable ci.f.c in britney but keep dcut migrate 2. remove britney and directly upload packages from debusine.f.c to the customer repo
14:52:03 <LucasKanashiro[m]> Maybe this works better in the mailing list (?)
14:52:09 <Beuc> helmut, I just gave 2, where do you want this, in the pad?
14:52:36 <jochensp> +1 for moving this to the mailing list
14:52:57 <ta> helmut: wouldn't be 2. enough to do?
14:53:16 <helmut> Beuc: yeah and then we move to the list
14:53:27 <helmut> ta: yes, but smaller steps mean it is easier to revert
14:53:38 <charles> #action discussion will move to mailing list
14:53:46 <ta> ok
14:54:23 <charles> #topic AOB
14:54:32 <jochensp> charles: maybe name someone who will take care of an action when recording it
14:55:00 <charles> helmut: can I put you as in charge of this one?
14:55:22 <charles> (the move to the mailing list)
14:55:48 <helmut> yes
14:56:10 <charles> #action helmut will move the ci.freexian.com EOL to the mailing list
14:56:24 <charles> thx
14:56:39 <charles> ok, so any other business to discuss?
14:56:54 <Beuc> I added one
14:57:28 <charles> AOB: issues with autopkgtest-virt-qemu
14:57:40 <Beuc> AOB: the dhcpcd5 maintainer and I both tried to run autopkgtest-virt-qemu yesterday locally, e.g. following https://lts-team.pages.debian.net/wiki/TestSuites/autopkgtest.html#full-vm-environment-isolation-machine  . Neither building nor running the VM appears to work.  e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077620   It seems to me that I had re-checked this last October on trixie (on which I'm still running), so I'm wondering if you saw
14:57:40 <Beuc> something similar.
14:58:16 <Beuc> This is annoying because I basically had to do without isolation-machine tests (given that debusine also had issues).
14:58:37 <Beuc> The maintainer managed to do something from bullseye IIUC.
14:58:39 <helmut> Beuc: what image generator did you use?
14:59:03 <charles> hmm it's been a while since I tried a-v-qemu and it worked, but as you, it was last year for sure
14:59:20 <Beuc> autopkgtest-build-qemu; trixie and trixie-backports. (following the above doc)
14:59:20 <jochensp> Beuc: is that about unstable or E/LTS?
14:59:27 <Beuc> target bullseye
15:00:12 <santiago> mmm, I also remember being hit by "<VirtSubproc>: failure: timed out waiting for 'login prompt on serial console'" errors, but not recently ...
15:00:26 <paride> Beuc and others, I can try having a closer look at that bug
15:00:45 <helmut> that's a very generic symptom, it happened just today for unstable as systemd dropped its mount dependency
15:00:57 <Beuc> https://lists.debian.org/debian-lts/2026/07/msg00055.html and https://lists.debian.org/debian-lts/2026/07/msg00056.html for yesterday's upload
15:01:36 <helmut> do you have a --show-boot log?
15:02:06 <Beuc> "not a bootable disk" for me
15:02:34 <Beuc> I can re-try everything e.g. next month in case this is transient, but this amount of brekage worried me. It seems this is not an obvious/known issue so we can continue the discussion off-meeting.
15:03:00 <jochensp> Beuc: mmdebstrap-autopkgtest-build-qemu --boot=efi bullseye bullseye-amd64.img; autopkgtest -BU hello -- qemu --boot=efi bullseye-amd64.img works here
15:03:16 <guilhem> i'm using a-v-qemu for everything that requires more isolation than schroot, works for me (last unstable and trixie images generated on jul 13 and jul 15 respectively)
15:04:21 <Beuc> Our procedure generates ext4 images (not full boot images), maybe something changed.
15:05:46 <paride> Beuc, so your reproducer is: `autopkgtest-build-qemu` for trixie, and then use that image with the qemu virt server, and that's it?
15:06:47 <helmut> Zugschluss reported a possibly related failure in #debian-qa today
15:06:58 <charles> maybe something to move to ML too with more details?
15:07:18 <Beuc> paride, https://lts-team.pages.debian.net/wiki/TestSuites/autopkgtest.html#full-vm-environment-isolation-machine both build and running a previous image I had from mid-October
15:07:24 <Beuc> charles, agreed
15:07:49 <charles> Beuc: can you do it?
15:08:42 <Beuc> you can assign to me, no promises before next month due to the reduced hours this month
15:08:49 <charles> #action Beuc will move the discussion about about autopkgtest-virt-qemu errors to the mailing list
15:08:51 <charles> ack
15:09:13 <charles> so, any other business?
15:09:17 <santiago> quickly:
15:09:25 <santiago> utkarsh2102 is preparing squid updates
15:09:47 <santiago> he would like to have some help to review and test them
15:09:55 <santiago> any volunteer please?
15:10:07 <paride> I can do that
15:10:19 <eamanu> I can help as well
15:10:22 <helmut> I am experimentally providing a sec-tracker mirror git://git.subdivi.de/~helmut/security-tracker.git. It is supposed to be faster. Anti-features: 1. May cease working at any time. 2. Unencrypted. Don't pull. Fetch it, then pull salsa (reusing) objects. If you try it, tell me about success and failure.
15:10:25 <santiago> great, thanks
15:10:32 <charles> #action paride and eamanu will take a look in squid update
15:10:49 <santiago> please utkarsh2102 sync with them
15:11:13 <paride> back on the qemu issue (sorry), I can take the action to do the investigation on the autopkgtest side, even without a thread in the lts mailing list
15:11:39 <charles> #action paride will take a look in the autopkgtest-virt-qemu problem
15:11:44 <charles> cool!
15:12:01 <helmut> my mirror should typically sync four times an hour.
15:13:04 <charles> #action for the brave souls around: helmut is experimentally providing a sec-tracker mirror git://git.subdivi.de/~helmut/security-tracker.git. It is supposed to be faster. Anti-features: 1. May cease working at any time. 2. Unencrypted. Don't pull. Fetch it, then pull salsa (reusing) objects. If you try it, tell me about success and failure.
15:13:47 <charles> so let's call it a day unless we have any other business that can't wait
15:14:06 <utkarsh2102> thank you o/
15:14:29 <santiago> nothing else from my side
15:14:48 <charles> #topic next meeting
15:14:52 <charles> 2026-08-27 14:00 UTC [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting]
15:15:19 <ta> thanks and byebye
15:15:23 <slyon> thanks charles, all! o/
15:15:29 <santiago> thanks charles, thank you all!
15:15:40 <jochensp> thanks!
15:15:46 <eamanu> thanks charles, and thanks to all!
15:15:47 <LucasKanashiro[m]> o/
15:15:52 <charles> #endmeeting