14:00:16 <el_cubano> #startmeeting
14:00:16 <MeetBot> Meeting started Thu Sep 25 14:00:16 2025 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:16 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:29 <el_cubano> #topic Roll call
14:00:32 <jochensp> hi
14:00:33 <tobi> \o
14:00:38 <ta> hi
14:00:40 <el_cubano> Please announce yourself so we have a record of your attendance.
14:00:40 <helmut> o/
14:00:41 * LucasKanashiro[m] waves
14:00:43 <guilhem> hello
14:00:58 <santiago> hello!
14:01:13 <charles> o/
14:01:38 <Beuc> o/
14:01:47 <paravoid> ο/
14:02:44 <el_cubano> Also, the agenda is located here: https://pad.riseup.net/p/lts-meeting-agenda
14:03:04 <el_cubano> If there are any last minute additions, please place them just before AOB
14:03:21 <utkarsh2102> \o
14:03:42 <petn-randall> o/
14:05:20 <el_cubano> OK. That looks like everyone for Roll Call.
14:05:28 <el_cubano> #topic New team members
14:05:37 <el_cubano> There are no new team members this month.
14:05:53 <el_cubano> #topic Action item review
14:06:30 <el_cubano> guilhem: Do you have anything to report on "Propose an MR with detailed guidance on data/next-point-update.txt" ?
14:06:42 <guilhem> no, still working on it :-( didn't submit anything yet
14:06:51 <el_cubano> OK. No worries there.
14:07:15 <el_cubano> Next item is "Request Ubuntu PPA for debusine-client package installation"
14:07:28 <el_cubano> helmut: I see that you noted the result of this was that it was turned down.
14:07:43 <el_cubano> And also "Freexian may host a Debusine repository on Debusine eventually
14:07:46 <el_cubano> "
14:07:57 <helmut> We kinda expect ELTS people to work with Debian >= bookworm.
14:08:12 * el_cubano nods
14:08:20 <helmut> You might use a podman container for uploading
14:08:22 <utkarsh2102> also,  I could install the backports and configured debusine from there. \o/
14:08:40 <el_cubano> utkarsh2102: ack
14:09:28 <helmut> It is not clear whether there will be bookworm-backports-sloppy packages, but there have not yet happened any changes that would require contributors to use a debusine-client >> trixie.
14:10:11 <santiago> +1 to "we expect people to work with Debian >= bookworm" anyway
14:10:44 <el_cubano> OK. So, this item seems to have been fully resolved.
14:11:00 <el_cubano> Next action item is: "Document the preferred way to build source packages and upload them to Debusine"
14:11:25 <el_cubano> jochensp has documented this in the internal ELTS documentation (since this is ELTS specific).
14:11:35 <el_cubano> Are there any questions or follow-ups on this item?
14:12:13 <ah[m]> Hi (a bit later).
14:12:33 <jochensp> I have also added some documentation on how to set up sbuild and debvm in case someone missed it
14:12:46 <santiago> thanks for that!
14:13:26 <el_cubano> jochensp: was that in the same commit referenced in the resolution of the action item?
14:13:37 <jochensp> no, separate: 57a2875d299bbaff97bc9a0ee36c5e4243ac1fa0
14:14:00 <el_cubano> Ah, OK. Thanks for that.
14:14:24 <el_cubano> Alright. If there is nothing else on action item review, we'll move on.
14:14:43 <el_cubano> #topic Difficult technical questions/issues (including reviews) for discussion at the end of the meeting
14:15:23 <el_cubano> For now I just want to remind everyone to go have a look at this agenda item, as once the main part of the meeting concludes, we will spend a bit of time going through this and either reviewing in detail or making decisions.
14:15:38 * santiago nods
14:15:46 <el_cubano> That part of the meeting will only be for people who want to stay and be involved in those discussions.
14:16:11 <el_cubano> That is, we aren't expecting that everyone will be interested, but if you are and have something to say, please feel free to participate.
14:16:20 <el_cubano> OK. Moving on.
14:16:28 <el_cubano> #topic Reminder: last call to give feedback about introducing support for severity and additional data
14:16:36 <el_cubano> santiago: Did you want to add anything related to this?
14:16:43 <santiago> not really
14:16:48 <santiago> just a reminder:
14:16:53 * el_cubano nods
14:17:21 <santiago> if you have anything to say about introducing support for handling severities and other related data in our vulnerability information, please do so now
14:17:31 <el_cubano> Please provide feedback be responding to the ML thread. If you don't say anything, you aren't allowed to complain later if you don't like how turns out :-p
14:17:38 <el_cubano> santiago: Does that sound about right?
14:18:26 <Beuc> I wasn't around for the initial exchanges but I sent some feedback an hour ago.
14:18:41 <santiago> you'll be allowed to complain later, but you will be forced to fix anything that happen to be wrong :-P
14:18:54 <el_cubano> That seems like a fair trade
14:19:24 <santiago> Beuc, thanks. I'll read your feedback ASAP
14:19:38 <el_cubano> OK. Moving on.
14:19:47 <el_cubano> #topic Featured issue(s) of the month
14:20:09 <el_cubano> None for this month (I've had reduced availability and I didn't get a chance to dig through our open issues)
14:20:56 <el_cubano> That said, if you happen to be aware of a specific issue (especially if it is documented in lts-extra-tasks or one of the related internal projects), please do take some time to work on it (if circumstances allow).
14:21:23 <el_cubano> We want to continue making improvements in documentation, tooling, etc.
14:21:50 <el_cubano> OK. Moving on once again.
14:21:53 <el_cubano> #topic AOB
14:22:10 <el_cubano> helmut: The first item sounds like it was written by you.
14:22:38 <helmut> Well, yeah Debusine status updates :)
14:23:10 <helmut> We're still waiting for regression tracking (of autopkgtests and otherwise) even though foundational work has happened there
14:23:45 <helmut> Repository publishing has landed in unstable recently and we should start experimenting. That should help us prepare something like stable point releases eventually
14:23:57 <el_cubano> ack and thanks
14:24:03 <el_cubano> anything else on this?
14:24:05 <helmut> Or doing the clamav update that required a gcc or similar
14:24:27 <LucasKanashiro[m]> good news :)
14:24:53 <ta> is there any docu on how to use own repositories with debusine?
14:24:55 <charles> very good news indeed!
14:25:26 <helmut> ta: not really, that's part of the difficulty. I haven't successfully published a repo yet. I guess I'll work from the unit tests
14:25:48 <ta> ah, ok
14:26:25 <helmut> The debusine documentation is quite comprehensive so it might actually cover this already though it usually does so on a fairly low level. We need workflow templates to make it easy for you.
14:26:42 <helmut> So far you need an experiment workspace to do any of this yourself.
14:27:26 <ta> yes, I miss examples in the docu ...
14:27:47 <el_cubano> So is it safe to say that we should expect more to come related to this feature in the future?
14:27:55 <ta> are experiments on debusine.freexian.com possible now?
14:28:34 <guilhem> about debusine, and particulary d.d.n for lts and (o)spu uploads, would it be possible to have autopkgtest reference results (using the package version currently in the archive, like britney2 does) too in the QA section?  would be easier to identify regressions, as many autopkgtests to older suites are broken in the first place
14:29:10 <jochensp> guilhem: there are issues for that, afair
14:29:15 <helmut> ta: good question. I guess we might be missing a workflow template enabling you to use them there.
14:29:37 <helmut> guilhem: that is WIP and no, we cannot do that yet.
14:29:37 <guilhem> jochensp: ah nice, thx
14:29:41 <jochensp> guilhem: https://salsa.debian.org/freexian-team/debusine/-/issues/920
14:29:56 <jochensp> and https://salsa.debian.org/freexian-team/debusine/-/issues/291
14:29:56 <guilhem> thx!
14:30:28 <ta> helmut: ok, are you able to install this template?
14:30:29 <jochensp> I just uploaded the original package and switched browser tabs to compare for now
14:30:45 <el_cubano> OK. Anything else on this?
14:30:50 <charles> I do the same as jochensp :)
14:31:25 <guilhem> fair
14:31:46 <helmut> ta: let's turn this into an action item. technically, I can, but I would coordinate with raphael first
14:32:18 <ta> ok
14:32:29 <helmut> #action helmut to figure out whether we can have experiment workspaces on debusine.f.c
14:32:53 <Beuc> Last month's meeting says "+ No more ARM* autopkgtest" -> is there a bit of context for me to understand? That's on the britney2/autopkgtest infrastructure? What happened? :)
14:33:03 <helmut> I guess el_cubano needs to do the action.
14:33:27 <el_cubano> #action helmut to figure out whether we can have experiment workspaces on debusine.f.c
14:33:32 <helmut> Beuc: The arm machine doing the tests was sponsored by worksonarm. Their sponsorship has been discontinued.
14:33:59 <Beuc> Ah :/ on Salsa too then?
14:34:04 <helmut> Beuc: We have not looked into replacing it, because we hope that Debusine can take over this task $soon.
14:34:13 <santiago> WRT this, the Salsa CI ARM runner was also shut down, and it's in the process of being replaced
14:34:13 <el_cubano> helmut: Weird. I would have expected some output from Meetbot. It might be that the action action is available to everyone in the meeting. I guess we'll see when the summary is produced at the end of the meeting.
14:35:11 <charles> el_cubano: helmut: I think meetbot doesn't reply #action, it just computes it and put in the meeting log/summary
14:35:33 * el_cubano nods
14:35:41 <el_cubano> OK. Let's move on to the next item.
14:36:10 <el_cubano> LucasKanashiro[m] and charles
14:36:27 <el_cubano> Did either of you want to add anything beyond what was noted in the agenda?
14:36:54 <jochensp> out of interest: why do you use Incus?
14:37:04 <LucasKanashiro[m]> that's all, but in short, this week we were discussing about incus VM images for ELTS releases
14:37:09 <charles> I guess both of us are heavy users of incus and were missing some elts images for it
14:37:16 <LucasKanashiro[m]> charles offered some help with documentation
14:37:52 <helmut> jochensp: because the Debusine team has expertize in incus and settled on it as primary containerization technology early (about two years ago). The unshare executor shall also be replaces with incus.
14:37:52 <LucasKanashiro[m]> jochensp: the user experience of using incus is way better than using debvm IMHO
14:38:47 <charles> and it can handle VMs, system containers and OCI containers so it's pretty neat to have one tool to manage it all
14:39:01 <LucasKanashiro[m]> +1
14:39:11 <helmut> also incus makes your normal user effectively be root
14:39:15 <charles> but I had one extra question for all of you in there: Would be feasible and/or desired for freexian to host incus images of elts?
14:39:29 <helmut> charles: I think we already do.
14:39:51 <LucasKanashiro[m]> are they public?
14:39:59 <LucasKanashiro[m]> if yes, we should document that
14:40:01 <charles> do we?! Please just give me pointers where to find them and I'll be very happy
14:40:08 <helmut> charles: https://debusine.freexian.com/freexian/base/work-request/25408/
14:40:10 <charles> (and also add to documentation :-)
14:40:16 <helmut> charles: "Build image ..."
14:41:17 <LucasKanashiro[m]> is this something that I can easily point incus to that?
14:41:50 <helmut> those images are tailored to running autopkgtests in incus vms
14:42:04 <helmut> we might also publish generic base images
14:43:02 <helmut> LucasKanashiro[m]: can incus consume a qcow2 file?
14:43:22 <Beuc> I have ideas on moving some of the technical VM/build-related LTS/ELTS instructions to a separate page where we could expand on different workflows and tooling, mainly full VMs vs. on-demand light containers/VMs; there's more than one way to do it, apparently :)
14:43:52 <charles> generic base images would be nice. I don't think we can add that as a remote image server and incus launch freexian:buster, but it's already a very good start
14:43:58 <charles> Beuc: +1
14:44:04 <LucasKanashiro[m]> helmut: it seems so
14:44:50 <LucasKanashiro[m]> charles: that would be neat :)
14:45:45 <el_cubano> Anything else on this item?
14:45:52 <helmut> #action helmut to create generic VM base images for ELTS
14:45:57 <petn-randall> On a slightly related note, I'd like to have a hands-on video call some time where we'd exchange our workflows. I'm always interested in increasing productivity by taking viable shortcuts.
14:46:37 <el_cubano> petn-randall: Depending on how quickly you would that to happen, we can add it to the end of next month's meeting (which will be via Jitsi)
14:47:33 <petn-randall> Yeah, let's have that after the meeting next month then?
14:47:59 <el_cubano> OK. After today's meeting when I prepare the agenda for the next meeting, I'll go ahead and it.
14:48:24 <petn-randall> Anyone interested can then stay. And we'll demo 2-3 minutes each other's workflows and allow asking questions.
14:48:36 * el_cubano nods
14:48:47 <petn-randall> Sounds good, sorry for throwing that it on a different agenda item.
14:48:47 <charles> cool, I'll be there!
14:49:05 <el_cubano> petn-randall: no worries
14:49:07 <el_cubano> Alright, last call on this discussion item.
14:49:07 <santiago> it would be a good idea to list those workflows in advance
14:49:20 <santiago> (to avoid double-work)
14:50:08 <el_cubano> I'll incorporate that into the agenda item when I draft it
14:50:27 <el_cubano> OK. So that's all for AOB.
14:50:43 <el_cubano> #topic Next meeting
14:50:49 <el_cubano> Next meeting: 2025-10-23 14:00 UTC [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting]
14:51:03 <el_cubano> #topic Conclusion
14:51:16 <el_cubano> This concludes the main/official/obligatory part of the meeting.
14:51:51 <el_cubano> Next, we will move into the "appendix" where we will discuss the "difficult technical issues".
14:52:14 <el_cubano> However, I'm not going to invoke the command to end the meeting, as we want these discussions to be captured by Meetbot
14:52:34 <el_cubano> So, thank you all for participating, and goodbye to those of you who are dropping out of the meeting at this point.
14:52:52 <el_cubano> We'll see everyone at next month's meeting o/
14:53:08 <el_cubano> OK. Moving on.
14:53:21 <el_cubano> #topic MEETING APPENDIX: Discussion of technical questions/issues and reviews
14:53:36 <el_cubano> utkarsh2102: Your items are up first.
14:54:13 <utkarsh2102> hi! yeah, just wanted to close the thread about fixing or deferring packages that aren't fixed for bullseye (but fixed for buster AND bookworm) there with a conclusive decision. i'm happy to keep discussing on the ML itself if that's better and convenient (esp when we have only 7 minutes left).
14:55:25 <el_cubano> Oh, right. The appendix discussion is not constrained to the 1 hour meeting time.
14:55:34 <utkarsh2102> ah, cool beans.
14:55:37 <utkarsh2102> my tl;dr was that we should perhaps think a bit more with what our intent is. perfectly fine if there's strong reasons to just not fix it (because they're not sponsored by our customers).
14:56:09 <Beuc> I'm checking the thread but overall I don't see the point of prioritizing low-pri + non-sponsored work over our actual backlog.
14:56:25 <el_cubano> So, in general, the idea is that we want to avoid upgrade regressions. So, if an issue is fixed in buster and remains open in bullseye, we should be fixing it in bullseye. Even moreso if that issue was fixed in bookworm.
14:56:50 <utkarsh2102> that's fair - so we do concur (accidental) regression is fine if it's not touching the packages that are sponsored?
14:57:21 <el_cubano> And, as Beuc just pointed out, this needs to be balanced against package/CVE priority and what else we have in the backlog
14:57:22 <utkarsh2102> el_cubano: exactly^
14:57:51 <santiago> I wouldn't say "it's fine to keep regression updates open"
14:58:08 <utkarsh2102> to which i proposed plausible options - put it in our backlog (extra issue or something for when there's less work) or just have 1 or few people work on that.
14:58:11 <santiago> but we need to prioritize our resources
14:58:25 <utkarsh2102> or if you think just deferring it is better, that's also fine, i guess.
14:59:01 <santiago> and we need to avoid those regressions updates (which is something el_cubano and I have to work on)
14:59:13 <el_cubano> I need to go back and read the entire thread (which appears to span several months)
14:59:26 <LucasKanashiro[m]> in general, for customers of ELTS releases, we want to keep the upgrade to LTS without regressions. If there are regressions out of the way of the customers, I'd say the priority is lower
14:59:59 <el_cubano> What I would say for now is that if we have low priority packages which fall into this bucket (i.e., they would be susceptible to upgrade regression) then we should have a list of them.
15:00:31 <utkarsh2102> yep, we do
15:00:41 <el_cubano> Note that given the way we've started to prefer landing fixes in order (unstable, stable, oldstable, etc) that this sort of thing should be only a past problem.
15:00:43 <utkarsh2102> thanks to Beuc who worked on that bit of the reporting :D
15:00:54 <el_cubano> That is, we shouldn't be finding new instances of this.
15:00:58 <utkarsh2102> indeed - very happy about it.
15:01:06 <el_cubano> If we are, then we are definitely doing something wrong now.
15:01:37 <el_cubano> utkarsh2102: Is the list of pacakges that you are thinking of limited to the output of the lts-cve-triage.py script?
15:01:55 <utkarsh2102> well, that's what my discussion was based on.
15:02:03 <utkarsh2102> i've not tried to manually go through things.
15:02:04 <santiago> varnish comes to my mind as a package not being worked on by the sec team, but that is found in dla-needed
15:02:32 <el_cubano> OK. And that list is "new" in the sense that the specific report section in question was just implemented recently during the security tracker sprint.
15:02:41 <utkarsh2102> indeed!
15:02:59 <utkarsh2102> but it does give you the right output - at least for a few things that I did check manually to be sure.
15:03:25 <el_cubano> OK. So, at the moment we aren't asking FD to add packages to the queue en masse.
15:03:36 <utkarsh2102> yes!
15:03:44 <utkarsh2102> i don't think we should do that.
15:03:53 <el_cubano> We are aware that several packages fall into this bucket, and santiago and I need to work out a way to handle them without disrupting the other work that we have to get done.
15:04:12 <utkarsh2102> great - as long as someone is looking after this!
15:04:50 <Beuc> I noticed some contributors (mostly 1) were confused by these packages and worked consistently on them asap even though they were low-pri and/or non-sponsored, that's also why I'm wary about adding them blindly.
15:04:50 <el_cubano> #action el_cubano santiago to review packages which may be subject to upgrade regressions, close the associated ML thread, and create a plan for dealing with the packages that have been identified
15:05:13 <utkarsh2102> i mean, simply put, at one point we released a DLA (for buster) so we did think of it as important back then. so it shouldn't regress now. 😅
15:05:13 <el_cubano> Beuc: ack
15:05:27 <el_cubano> utkarsh2102: we're in agreement there
15:05:41 <el_cubano> OK. Let's move on to the next item.
15:05:43 <utkarsh2102> yep, great! thanks, let's move on o/
15:06:12 <Beuc> utkarsh2102, as I mentioned we were also zealous for some ELTS updates in the past.
15:06:41 <el_cubano> utkarsh2102: The hand-off you are looking for from Daniel is something to be discussed via the internal ML.
15:06:54 <utkarsh2102> got it, will do that!
15:06:58 <el_cubano> Thanks!
15:07:24 <el_cubano> santiago: The next item (nonfree-firmware) is yours
15:08:15 <santiago> I'd also like to conclude a bout nonfree-firmware support
15:08:48 <santiago> and I believe that there is a pending action item, which mostly relates to documenting how we can support it, IIRC. Is that correct?
15:09:21 <santiago> if that is correct, any volunteers to handle it?
15:10:31 <tobi> not sure (as in I should re-read the thread) if we had a conclusoin yet
15:11:07 <santiago> should we try to have a conclusion for next meeting then?
15:11:32 <santiago> el_cubano, would you mind adding an action item?
15:11:36 <tobi> I guess it makes sense.
15:12:13 <el_cubano> santiago: Is the action to conclude the ML thread?
15:12:43 <santiago> kind of yes
15:12:58 <tobi> yes, kind of yes and see if there are gaps to be filled
15:13:49 <el_cubano> #action santiago tobi conclude the ML thread related to nonfree-firmware handling
15:13:49 <santiago> IIRC, it would be impossible to provide regular support for it, and the gaps have to be propoerly documented.
15:14:02 <santiago> sounds good
15:14:30 <el_cubano> tobi: Is the amd64 microcode discussion part of the nonfree-firmware discussion, or is it something separate?
15:14:40 <tobi> separate
15:15:01 <el_cubano> OK. Then are we ready to move from the nonfree-firmware discussion to the amd64 microcode discussion?
15:15:43 <tobi> fine for me
15:15:53 <el_cubano> Then please proceed.
15:16:44 <tobi> I was working on ams64-firmware and there is currently a nasty CVE. It needs kernel and bios support. if kernel tries to load the new microcode on old BIOS, we get an GP
15:17:07 <tobi> and if the bios is updated and the kernel tries to load the old one, same thing.
15:17:26 <tobi> (IIRC, see dla-needed.txt; don't have it in front of me atm)
15:18:08 <tobi> AMD is currently working on $something to make this better, but no information beside that what hmh wrote in the bug.
15:18:30 <tobi> so, basically just a FYI to be aware.
15:20:09 <tobi> my proposal is to wait for AMD's idea how to fix it and then see what needs to be done for LTS/ELTS in the microcode package and in the kernel pacakge.
15:20:56 <santiago> sounds that waiting makes sense
15:21:35 <charles> yeah
15:21:53 <tobi> dla-needed.txt : https://paste.debian.net/hidden/363820d4/
15:22:02 <el_cubano> tobi: Is that suggestion noted in [de]la-needed.txt?
15:22:25 <el_cubano> Ah, it appears so.
15:22:37 <santiago> (people, I'll have to leave soon)
15:22:39 <tobi> el_cubano: not explicitly, but I can add something more explict
15:22:47 <el_cubano> tobi: Yes, that would be excellent.
15:22:59 <el_cubano> OK. Let's move on to the nvidia-graphics-drivers
15:23:12 <el_cubano> santiago: Please go ahead (I hope you have enough time for this before you have to go)
15:23:21 <tobi> #action tobi make amd64-microcode notes more explicit in dla-needed.txt
15:24:01 <tobi> we can move on to nvidia if everyone is fine with it ;-)
15:24:11 <santiago> nvidia-graphics-drivers is complex because we need HW to make sure the updates will work correctly. Thanks a lot to tobi for the help on that!
15:24:29 <charles> tobu: should people be advised to not update their bios? Because they have the old microcode and might get in GP (sorry to drag this further)
15:24:34 <santiago> and to Andreas for preparing the updates
15:24:39 <charles> s/tobu/tobi/
15:24:54 <santiago> my question is: is there anything else that we need to move forward with the upload?
15:25:02 <carnil> tobi: for older releases I believe it is less nasty, or let's say if you run a newe rkernel. the current issues are mainly relevant for AMD Fam19h CPUs (Zen3/4) so the olde rreleases you go with the kernel they might not even yet support those. if you use a newer kernel, etc ... but I stay quiet now again. In the end all the microcode update needs to be taken with caution, we take quite a slow path
15:25:08 <carnil> here in most cases (we = sec-team) and collaborate/coordinate with the maintier. Now reall ystainig quiet and not disturbing the meeting further.
15:25:36 <tobi> charles: there is an kernel cmd line option to skip mircocode updates, so there is a way around for affected people
15:25:46 <charles> ack
15:28:00 <tobi> santiago: (nvidia) I think we can prepare the upload. There is also a debconf question that will pop up when your GPU isn't supported anymore.
15:28:36 <tobi> there was only some more minor polishing required for the packages, iirc it mentions non-free-firmware
15:29:01 <santiago> ok, we need to coordinate with Andreas then. Let's follow-up on the mailing list
15:29:21 <el_cubano> Do we need to capture and action for that?
15:29:24 <tobi> ack!
15:29:24 <santiago> another action tiem?
15:29:43 * tobi will follow up with Andreas
15:30:08 <el_cubano> #action santiago tobi follow-up to ML and Andreas concerning upload of nvidia-graphics-drivers
15:30:20 <el_cubano> OK. Anything else on this item?
15:30:38 <el_cubano> carnil: BTW, your input is always most welcome :-)
15:31:06 <el_cubano> Alright, so let's move to the last item in the list.
15:31:17 <el_cubano> Beuc: Your turn
15:31:24 <tobi> are there some customers to be informed, maybe $customers listing nvidia and nvidia-tesla-470 as want to be supported?
15:31:37 <tobi> (those might be interested in the change)
15:31:46 <Beuc> On other ARM* news, I added https://lts-team.pages.debian.net/howtos/arm-debug.html . That's a simple physical setup for ARM build & testing, especially since Salsa's and Freexian's ARM autopkgtest are unavailable. I'm pleased with the result so far :) Comments welcome.
15:31:53 <el_cubano> tobi: We can discuss that in the internal ML
15:34:40 <charles> Beuc: cool! I saw you added for rpi4, for rpi5, there is a annoying problem to run armhf binaries with raspbberry pi OS related to memory page size
15:35:30 <charles> I don't think it's necessary to document this problem since rpi5 is out of scope (right?)
15:36:11 <Beuc> charles, ack good to know. The Debian Wiki currently warns against the Raspberry Pi 5 so I didn't try, but we can add a reference ("Other models" paragraph).
15:36:31 <jochensp> (mainline kernel support for the pi5 is still missing)
15:37:19 <charles> ack, I will hunt down the option that needs to be set so it uses 4K pages and works with armhf bookworm binaries
15:39:49 <charles> el_cubano: I think we can wrap up, unless someone else wants to add more to the topic
15:40:00 <el_cubano> ack
15:40:29 <el_cubano> OK. Thanks again everyone for participating and for those who stuck around for this last part of the meeting.
15:40:35 <el_cubano> Bye bye o/
15:40:40 <charles> o/
15:40:41 <Beuc> bye!
15:40:48 <ah[m]> Bye!
15:41:19 <santiago> cheers!!
15:41:28 <santiago> thank you, everybody!
15:41:34 <tobi> bye, have a nice day everyone :)
15:41:42 <el_cubano> #endmeeting