14:00:57 <el_cubano> #startmeeting
14:00:57 <MeetBot> Meeting started Thu May 23 14:00:57 2024 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:57 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:04 <el_cubano> #topic Roll call
14:01:06 <spwhitton> Sean Whitton
14:01:07 <utkarsh2102> hello o/
14:01:11 <ta> hi
14:01:13 <bwh> hi
14:01:14 <el_cubano> Hi everyone. Please announce yourself
14:01:14 <guilhem> hi
14:01:17 <Beuc> o/
14:01:24 <bhe[m]> Hi
14:01:38 <kkremitzki[m]> Hello all, Kurt Kremitzki here as an observer intereested in Debian LTS
14:01:54 <jochensp> hi
14:02:19 <tobi_m> hi
14:02:28 <pochu[m]> hi
14:02:34 <buxy> hi
14:02:36 <lamby> hi
14:03:22 <tumbleweed> hi
14:04:13 <el_cubano> We'll wait another minute or two and then we'll get started
14:04:51 <lamby> Thanks for running the meeting 👍
14:05:27 <el_cubano> #topic Agenda
14:05:48 <el_cubano> As is customary, our agenda for the meeting (and for past meetings) is available here: https://pad.riseup.net/p/lts-meeting-agenda
14:06:33 <el_cubano> We only have one real item on the agenda, so I anticipate a short meeting
14:06:58 <el_cubano> #topic ELTS upload migrations
14:07:22 <el_cubano> At Helmut's request I am bringing up this reminder concerning ELTS upload migrations
14:07:25 <spwhitton> I think this is prompted by me and some Emacs uploads.
14:07:52 <el_cubano> There was at least one other instance, so you can share the "blame" with somone else :-)
14:08:01 <spwhitton> oh!
14:08:18 <el_cubano> As to the issue itself ...
14:09:09 <el_cubano> Recall that we recently changed the ELTS upload workflow so that uploads are first staged (they are built, and then CI is executed) and the successfully built packages must be migrated via a dcut command
14:09:13 * petn-randall waves.
14:09:37 <el_cubano> it is necessary to check that packages were succesfully built for all architectures prior to migrating the upload
14:10:07 <pochu[m]> Maybe the dcut command can call the equivalent of grep-excuses and ask for confirmation?
14:10:23 <spwhitton> britney tells you if they were not built, but there doesn't seem to be a good wya to check they *were* built
14:10:31 <pochu[m]> Maybe it can be added as a hook
14:10:43 <el_cubano> Also, please remember that even if a particular package doesn't have an autopkgtest suite, you should still check the test results, as those might reveal a problem with installing deps/rdeps
14:10:56 <spwhitton> except: wait 10 hours and assume if they're not in britney output then, there are fine
14:12:20 <pochu[m]> I used to check the ELTS buildd pages, just like I do for LTS before sending the DLA
14:12:40 <spwhitton> pochu[m]: do you mean looking through the logs?  or is there a buildd.d.o equivalent I have missed?
14:12:46 <el_cubano> When I would suggest is that proposed improvements be discussed on the ELTS list, as that way we have a discussion thread associated with the topic and Helmut then has the opportunity to participate (as he is not present in this meeting)
14:12:53 <el_cubano> s/When/What/
14:12:59 <spwhitton> el_cubano: good.  thanks.
14:14:04 <el_cubano> pochu[m]: Are the logs still visible for builds before they are migrated?
14:14:07 <Beuc> spwhitton, you mean the build logs dirs referenced at https://freexian.gitlab.io/services/deblts-team/documentation/elts/how-to-release-an-update.html
14:14:28 <pochu[m]> I think they are
14:14:30 <spwhitton> Beuc: yeah.  that's quite cumbersome as you have to download and decompress the files one-by-one.
14:14:31 <Beuc> buildd*.freexian.com
14:14:54 <Beuc> spwhitton, no they are available in-browser
14:15:16 <Beuc> http://buildd-amd64.freexian.com/build-logs/?C=M;O=D -> http://buildd-amd64.freexian.com/build-logs/php8.0_1:8.0.30-5+freexian24.04.1+php+1-php-noble-next-amd64-20240523-075231.11534.log
14:15:31 <spwhitton> ah, yes, I was thinking about mirror files.  but anyway I will take this to the ML.
14:15:38 <buxy> Another point might be that for a critical CVE, we might want to release what we have immediately and not wait until the completion of other builds, and still be able to migrate the missing builds in a second step? (not sure, but wondering)
14:16:29 <helmut> spwhitton: britney tells you that "it would attempt to migrate" your package. if it doesn't, something is wrong.
14:16:55 <spwhitton> helmut: how do we know the package has been ACCEPT'd and thus seen by britney at all, though?
14:17:04 <pochu[m]> Yes, that's a possible use case buxy. Would be nice if that was supported, though it's probably not very common as many packages don't take that long to build
14:17:24 <helmut> el_cubano: yes, logs remain where they are. just the distribution field has changed there
14:17:33 <pochu[m]> Could matter for e.g. linux
14:17:53 <helmut> el_cubano: though that will change as we move from rebuildd to debusine $soon
14:18:20 <helmut> spwhitton: arguably, you should only migrate a package after britney tells you that it would attempt migration
14:18:48 <helmut> spwhitton: barring cases where britney would reject your package for autopkgtest regressions that you are willing to accept
14:18:59 <spwhitton> oh, I see what you mean.  I'm sorry I'm being so slow about this.
14:20:07 <helmut> I now better see the confusion and shall update the elts docs
14:21:14 <helmut> conversely, I think we can skip checking logs on buildds when britney says "attempt to migrate" (unless you want to check results of a non-fatal test suite such as glibc used to be)
14:23:46 <spwhitton> right.
14:24:29 <helmut> buxy: migrating an incomplete build is possible at this time, but completing it currently requires a new version. is that good enough?
14:24:46 <pochu[m]> I think a grep-elts-excuses script would be useful, it'd be easy to add it to one finger-memory before issuing a dcut migrate
14:25:05 <Beuc> Is there a rough idea on when we want to use debusine for elts? (like Q3/Q4 2024?)
14:25:29 <helmut> Beuc: in theory, when we move buster to elts
14:26:06 <buxy> helmut: I think it's good enough for now... in particular since we will have validation workflows in milestone 4 in debusine.
14:27:31 <tumbleweed> Beuc: I think it'll come in phases. First debusine can schedule builds and QA, later package signing, later it can produce the apt repository
14:28:22 <tumbleweed> at some point in there, it can schedule reverse package tests and take on migration
14:28:56 <el_cubano> #action helmut to update the ELTS upload/migration docs for better clarity
14:29:12 <el_cubano> Are there any other action items from this discussion?
14:31:38 <el_cubano> OK. Since there are no other concrete action items we will move on
14:32:16 <el_cubano> Keep in mind that proposals and ideas can be discussed on the mailing list
14:32:29 <el_cubano> #topic AOB
14:32:40 <el_cubano> I have one thing...
14:33:27 <el_cubano> Recently, as I have been preparing the weekly report, we have had some weeks were all of the package updates were complete (DLA/ELA properly announced, VCS link in package DB, tags pushed)
14:34:37 <el_cubano> I want to thank everyone for continued improvement in this area. I know sometimes it can't be perfect (e.g., sometimes the tags are blocked on a maintainer accepting a MR), but I very much appreciate the effort being put in to make sure that package updates are complete with all the associated administrative actions
14:34:54 <spwhitton> nice.
14:35:12 <petn-randall> yay \o/
14:36:28 <el_cubano> Does anyone else have anything to bring up under AOB?
14:37:16 <lamby> not here
14:37:18 <petn-randall> Yes
14:37:30 <el_cubano> petn-randall: you have the floor
14:37:56 <petn-randall> I have two s-p-u for ansible/ansible-core: #1069891 #1070193
14:38:31 <petn-randall> It's been about 4 weeks I didn't get a response yet, any idea who I could poke about this?
14:38:48 <petn-randall> Or do I just need to be more patient?
14:39:16 <pochu[m]> The latter
14:39:42 <petn-randall> Alright, thanks.
14:39:47 <pochu[m]> You could also nicely ask on #-release
14:40:46 <helmut> petn-randall: 8395 files changed, 1625325 insertions(+), 132266 deletions(-), 307873 modifications(!) <- might be a reason...
14:42:22 <petn-randall> The ansible (not core) is a big update, but it's just a push to the latest of that series. IMHO suitable for s-p-u. I'm also open to explain the rationale.
14:43:59 <petn-randall> ansible-core should be not that controversial; it's a strict bugfix only update.
14:44:36 <el_cubano> So, it seems like asking in #d-r "is there a specific obstacle, or is it necessary to just wait longer?"
14:44:46 <el_cubano> might be helpful
14:44:48 <petn-randall> Will do, thanks.
14:45:21 <el_cubano> Considering that we are nearing a point release, that seems like a reasonable thing (to ensure the opportunity isn't missed unnecessarily)
14:45:30 <el_cubano> Anyone else with AOB?
14:45:48 <helmut> petn-randall: I think the release team has a different idea of what "*all* changes are documented in the d/changelog" means (and sure enough, it is impractical to do that for bumping up a maintenance release, but then I'd uncheck that box and explain why)
14:48:52 <el_cubano> OK. So it seems like we might be done w/ AOB.
14:49:07 <el_cubano> Last call
14:49:31 <petn-randall> helmut: Maybe, haven't done any s-p-u yet.
14:51:35 <el_cubano> Alright, so it looks that might be everything (though the s-p-u discussion can certainly continue outside of the meeting)
14:51:47 <el_cubano> #topic Next meeting
14:51:50 <el_cubano> Next meeting: 2024-06-27 14:00 UTC [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting]
14:52:32 <el_cubano> For those of you who may not know/remember, jitsi.debian.social was offline for a while due to abuse, but it came back online last month
14:52:46 <lamby> 👍
14:52:55 <guilhem> thx
14:53:05 <el_cubano> It now requires authentication via Salsa, so take that into account when deciding what device you will use to participate (I know not everyone likes having their passwords everywhere)
14:53:24 <pochu[m]> thanks!
14:54:11 <el_cubano> You're welcome!
14:54:28 <el_cubano> Alright, it looks like we are finished.
14:54:35 <el_cubano> Thanks to everyone for participating today.
14:54:37 <lamby> thank you all o/
14:54:42 <spwhitton> thanks all.
14:54:47 <ta> bye bye
14:54:49 <el_cubano> #endmeeting