13:58:12 <el_cubano> #startmeeting
13:58:12 <MeetBot> Meeting started Thu May 25 13:58:12 2023 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:12 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:58:25 <tumbleweed> o/
13:58:26 <el_cubano> Interesting.  Meetbot's clock is slow
13:58:28 <apo> hello
13:58:31 <el_cubano> Hello everyone!
13:59:08 <gladk_m> hi
13:59:15 <bwh> Hi
13:59:24 <buxy> hi
13:59:30 <el_cubano> we'll wait a few moments until we get more greetings to make sure everyone who intends to participate is here
13:59:38 <Beuc> o/
13:59:43 <Santiago[m]> o/
14:00:10 <bunk> hi
14:00:16 <rouca> hi
14:00:34 <helmut> \o/
14:00:40 <sgmoore[m]> hi
14:01:33 <tobi> hi
14:02:16 <el_cubano> That's 13 so far, so we are probably in good shape to get started.
14:02:36 <el_cubano> As a reminder, the agenda we are working from is here: https://pad.riseup.net/p/lts-meeting-agenda
14:02:45 <el_cubano> #topic FD discussion
14:03:40 <el_cubano> As I have been working to better understand the LTS coordinator role which Anton handed over to me some weeks ago, I have encountered some issues with the way FD is being handled
14:04:03 <el_cubano> The main thing is that on several occasions packages have been added to dla-needed.txt but no corresponding entry was found in packages.yml
14:04:23 <el_cubano> The guidelines for FD are documented here: https://lts-team.pages.debian.net/wiki/Development.html#id35
14:04:40 <el_cubano> I want to encourage everyone who is doing FD duty to make sure to remember to use the package-operations script
14:05:07 <el_cubano> The script will handle checkign packages.yml and will prompt for the necessary information if a package is not already listed in packages.yml
14:05:28 <helmut> I could be responsible for that in one or two occasions as I was never FD and still occasionally had to add packages
14:05:49 <el_cubano> This will greatly simplify the work of generating the weekly report that I send out and it will ensure that we continue moving toward a more consistent Git workflow
14:06:04 <el_cubano> helmut: That was going to be the next thing I was going to address :-)
14:06:36 <el_cubano> I also added to the FD guidelines a note to run package-operations with the --sanitize option a few times during the course of the week
14:06:38 <rouca> thanks for this work, can we run ourself the script in order to use it a as personnal remainder
14:07:11 <el_cubano> rouca: Yes, in fact it would be best if moved to all editing of dla-needed.txt being through the available scripts
14:07:51 <el_cubano> As we change the structure of dla-needed.txt (to include additional metadata and other things we need to support various goals), it will be easier to make a mistake when editing manually
14:08:51 <rouca> at least a syntaxt check hook before commit will be a first step
14:09:00 <el_cubano> Back to the --sanitize option for a moment, this will check the packages in dla-needed.txt and the corresponding entries in packages.yml, prompting for any missing or inconsistent information.  If FD could do this two or three times over the course of the week, then we should expect fewer issues with things not getting pushed to GIt, other inconsistencies, etc.
14:09:11 <el_cubano> rouca: That's a good suggestion
14:09:18 <Beuc> To avoid this desync between dla-needed.txt and packages.yml, we've talked (in March) about moving out from duplicating information to dla-needed.txt, and concentrate on ./find-work to display all information.
14:09:39 <gladk_m> basically we can run --sanitize on CI and fail, if something was not added properly
14:09:41 <Beuc> buxy started notably https://gitlab.com/freexian/services/deblts-team/debian-lts/-/issues/32
14:10:09 <el_cubano> #action el_cubano write an issue to add a commit hook for syntax checking dla-needed.txt (and perhaps other files where is would be beneficial)
14:10:41 <el_cubano> gladk_m: The issue with that is that if a package is added for which there is no VCS presently, then until the VCS is added there would be a failure
14:10:44 <Beuc> Personally I'd be in favor of concentrating on ./find-work rather than keeping what's IMHO a work-around for a DRY (Don't Repeat Yourself) issue in our workflow.
14:10:56 <helmut> More and more I start to wonder whether this should be a web interface (exclusively) as a means to enforce consistency.
14:11:23 <el_cubano> gladk_m: Sometimes we wait to add a VCS link because we might be trying to get the OK from the maintainer to do LTS work in their repo, for example
14:11:37 <helmut> The hook is probably cheaper, so economically that still probably makes sense.
14:12:24 <el_cubano> I agree that there are substantial improvements to be made.
14:12:54 <el_cubano> Beuc: Issue #32 is the one I had in mind earlier when I started this topic. Thanks for mentioning it specifically
14:12:57 <rouca> offer nevertheless a way to bypass the hook may be using an env variable. like LTS_FORCE_BYPASS. I triaged some bug, removing CVE from list (does not affect LTS) but find work list the package as work needed
14:13:45 <el_cubano> So, to recap:
14:14:01 <el_cubano> 1. FD to use package-operations more consistently and to run with --sanitize periodically
14:14:17 <el_cubano> 2. other contributors adding to dla-needed.txt are recommended to also use package-operations
14:14:44 <el_cubano> 3. consider the various improvements which can be made (both in the very near future and in a longer term more comprehensive fashion)
14:15:03 <el_cubano> Any other suggestions, comments, or anything on this topic?
14:15:13 <rouca> no thanks for the work
14:15:17 <helmut> +1
14:15:24 <Beuc> el_cubano, what's annoying me is that issue #32 requires issue #31 which requires redesigning everything, including coordinating with secteam, so it's probably won't be ready this year; meanwhile I'd rather we stop piling-up all these scripts to maintain an unnecessary copy of information in dla-needed.txt. I'd be ready to rework ./find-work right now to have a more dynamic approach and keep dla-needed.txt minimal for now.
14:16:19 <el_cubano> Beuc: When you say "I'd be ready to rework ..." do you mean that you would be ready to do the work yourself now, or that you'd be ready to see the work be done (by someone else)?
14:17:09 <Beuc> No I'd be ready to do the work; however last time we talked buxy told me to wait until he made #31/#32. Now he did, and I think we could use some intermediary work sooner.
14:18:11 <el_cubano> OK. Is this something you'd be interested in starting on in the near term?  Perhaps by analyzing what intermediate work could be done and starting to work towards protoptyping/implementing?
14:18:16 <Beuc> ("Re: Weekly information, 10/2023" 08/03/2023, for reference)
14:18:17 <buxy> Right now the package-operations step is a way to ensure that someone fills the VCS data and other required details in packages.yml. It's a bit orthogonal to the duplication that happens in dla-needed.txt. We can get rid of the duplication while keeping it in the workflow.
14:19:46 <sgmoore[m]> I have also been looking for things I can work on - but everything seems to depend on #31
14:20:30 <Beuc> buxy, I can create a PR to work on the duplication aspect, and possibly also work some more on ordering by priority
14:21:16 <buxy> So +1 from me if Beuc wants to improve find-work to display more information as some gradual improvement.
14:21:52 <el_cubano> I agree as well
14:22:19 <el_cubano> OK.  I don't want to spend much more time on this, unless there are still new items to discuss
14:22:31 <el_cubano> If not, I'd like to move to the next agenda item
14:22:41 <buxy> Beuc: Nice. Please coordinate next steps with Roberto.
14:22:49 <Beuc> noted
14:23:21 <el_cubano> #action Beuc to coordinate with el_cubano on incremental find-work improvements (and possible future improvements to follow)
14:23:43 <el_cubano> #topic Transition from email pings for missing announcements/tags to issues in Salsa
14:24:20 <el_cubano> Our workflow involves several different things for an update, including pushing Git tags, sending announcements to the mailing list, and also publishing the announcements to the website.
14:24:43 <el_cubano> When one or more of these are missing, the idea was that the coordinator would send an email to the contributor
14:25:02 <el_cubano> After a few weeks, I had much trouble tracking everything via email, so I decided to move to issues in Salsa
14:25:17 <el_cubano> I created a dedicated project in Salsa, lts-team/lts-updates-tasks
14:25:43 <el_cubano> Now, when I run the weekly report scripts, if a Git tag or DLA is missing, I will create an issue instead of sending an email
14:25:59 <el_cubano> The email will be assigned directly to the responsible contributor and will have an associated due date
14:26:17 <buxy> s/email/issue/
14:26:17 <Santiago[m]> s/email/issue, I suppose
14:26:25 <el_cubano> For ELTS-related issues, I am using the extended-lts project
14:26:37 <el_cubano> buxy, Santiago[m]: yes, quite right
14:27:24 <el_cubano> The only change this requires on the part of the contribitors is to hold any related discussion in the issue and close the issue once it has been resolved.
14:28:12 <el_cubano> That said, if you find this to be burdensome in some way or if you have any idea for further improvement, please let me know and I will endeavour to improve the process
14:28:39 <Beuc> el_cubano, I wonder if we can/should configure notifications so that e.g. I don't get notifications of these 1-person pings/tasks ?
14:29:05 <tobi> doesn't gitlab send mail when you've been assigned?
14:29:17 <buxy> Beuc: you are watching the whole lts-team group?
14:29:21 <el_cubano> Beuc: Are you receiving notifications for issues I created that aren't assigned to you?
14:29:36 <Beuc> The amount of salsa notifications has been steadily increasing over the months/years here.
14:29:51 <Beuc> I think I'm doing anything by default, but I may be wrong.
14:30:40 <Santiago[m]> by default, you shouldn't get notification for every issue in a group
14:30:50 <el_cubano> Keep in mind that you might be seeing some notifications from the extended-lts project as well (assuming you are subscribed to that one)
14:31:29 <Beuc> el_cubano, I got 2 notifications about missing tags this week
14:31:34 <Beuc> (and the follow-ups)
14:31:42 <Beuc> if this isn't defaut I can check that out later
14:31:55 <el_cubano> OK.  I'll PM you about it after this meeting
14:32:03 <el_cubano> Any other discussion on this topic?
14:32:24 <buxy> In theory, the default settings do not notify you unless you have participated in some way. But you can always override a notification setting at the group or project level.
14:33:06 <Beuc> buxy, I suppose it's good I receive notifications about on-going tasks in general; but those really don't concern me, maybe I can do something at the lts-update-tasks specific level
14:33:16 <buxy> Yup.
14:34:01 <buxy> Set that project notification level to "Participate".
14:34:26 <Beuc> will do
14:35:04 <el_cubano> OK. Let's go ahead and move on.
14:35:13 <el_cubano> #topic Make stable-security build logs public on package release
14:35:18 <el_cubano> Beuc: You have the floor
14:35:33 <tumbleweed> sounds like we should document some sensible gitlab usage settings
14:35:52 <Beuc> So about these logs: the issue is that I worked on multiple "first LTS uploads" recently
14:36:11 <Beuc> everytime I got weird failures on e.g. armhf architecture, and no access to the previous logs,
14:36:18 <buxy> +1 on tumbleweed's suggestion (as part of the "getting setup documentation")
14:36:41 <Beuc> since they were built from the LTS security suite with embargo settings (private build logs)
14:37:03 <Beuc> and I've been bugging people like carnil to get the previous logs to better understand the situation and fix the FTBFS
14:37:58 <Beuc> So we've been thinking and came to the conclusion we need to make those build logs public once the embargo is lifted (typically on package publication)
14:38:33 <Beuc> Now I'm bringing this to the meeting, to understand what teams / who we need to contact/help to make this happen.
14:38:49 <Beuc> Given there's contributors from various team I'd welcome some ideas/guidance.
14:39:07 <Beuc> The issue is https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51
14:40:23 <Beuc> So does anybody in the meeting have a global understanding of the situation and has an idea on where to go ? :)
14:41:10 <buxy> I assume you want to involve the wanna-build team, I expect them to be running the infra related to buildd logs. I don't exactly know what happens when a private security update is published but there's dak command involved here, so it's a likely place for the hook that should trigger something...
14:42:07 <buxy> But I'm not sure that the build log is available to the wanna-build team, it's likely only stored in a mailbox on the security team's side...
14:42:32 * helmut invites carnil
14:43:23 <Beuc> OK if I understand correctly the logs are never stored on disk in the first place and would need to get grabbed back to the buildds logdir somehow.
14:43:31 <Santiago[m]> "Service maintained by the wanna-build team <debian-wb-team@lists.debian.org>"
14:43:32 <helmut> carnil says (sitting next to him) that it needs help from the wana-build team, yes.
14:44:28 <Beuc> OK we can start there.
14:44:41 <helmut> carnil says mail both dsa and wanna-build to get it going
14:44:41 <buxy> Aurelien Jarno / Philipp Kern would be my goto persons in the wb-team but I have not had any contact in a long time so I don't know how accurate my assessment is
14:45:24 <helmut> s/dsa/security team/!
14:45:49 <carnil> to give a short summary: currently buildds are mailing a private list, archived on master where the buildd logs are archived
14:46:54 <el_cubano> Would be possible to make these available to any DD via SSO access?  Sort of like the full search capability of db.debian.org?
14:47:10 <el_cubano> Or would that be too wide of access?
14:47:28 <carnil> and it needs a mecahnism to decide which one could be published, and on buildd.d.o side (or wanna-build) how they can be published via https://buildd.debian.org/status/package.php?p=$sourcepackage
14:48:14 <buxy> I expect it to be too wide, build logs of not yet released embargoed DSA must not be available to all DD.
14:48:28 <carnil> I do not have (yet?) concrete ideas, as the way to publish right now the buildlogs after a suite was moved to LTS was to bounce the mails in, pkern I believe did that once, and Emilio has as well done recently for thunderbird/firefox buildlogs provided to him
14:49:01 <carnil> but we have to make sure only the buildlogs which can be public get public, what is still in emboargoed queues cannot go out, and only after a DSA release
14:50:10 <carnil> I currently have no idea how they re-injected the logs to make them public, which I think why help/insight is needed from wb-team people as well
14:51:10 <carnil> but this was really just the case for the suite where the suite was handed over already to LTS
14:51:23 <bwh> Uploading build logs is fairly simple. If they're only stored in a mail archive then picking them out of that would be the harder part.
14:51:26 <carnil> the new aspect is, that the logs get published immediately after DSA is out to the public
14:51:53 <carnil> bwh: yes all build logs for security builds are archived on master
14:52:44 <buxy> Thanks for the input carnil
14:53:24 <Beuc> I think we've got enough material to start a discussion with wb-team and secteam: contact them, get a clearer picture of the logs travel path, and design how to best get some published while maintaining confidentiality.
14:53:51 <el_cubano> Beuc: Excellent. Anything else on this item?
14:54:18 <Beuc> No. I'll try and recap in the issue #51.
14:54:27 <el_cubano> Thanks!
14:54:45 <el_cubano> Then, I won't note an action item for this.
14:54:50 <el_cubano> #topic Any other business
14:55:05 <el_cubano> Does anyone have anything else that they'd like to bring up?
14:55:11 <carnil> great thanks for working on it
14:55:50 <buxy> Nothing for me.
14:56:17 <Santiago[m]> me neither
14:56:49 <rouca> nothing thanks
14:56:57 <Beuc> Do recent new contributors (past 2 months) want to say a word about themselves? :)
14:57:52 <Santiago[m]> sure!
14:58:03 <Santiago[m]> well, I am not exactly a *new
14:58:05 <sgmoore[m]> Hi - still learning here. Like I mentioned - I would like some administrative tasks, but everything seem to depend on #31. If anyone has suggestions let me know
14:58:55 <Santiago[m]> * contributor. I have just rejoined the team. I used to work on LTS some years ago
15:00:06 <sgmoore[m]> Also - it states the FD does triage. What if I find a won't-fix hardening opportunity on a package while looking for something I can work on. Is it ok for me to put a note in dla-needed.txt or ?
15:00:13 <el_cubano> sgmoore[m]: I'll have a look at #31 and see if there might be one or more sub-tasks to break out from that
15:00:25 <sgmoore[m]> thanks 🙂
15:00:56 <Beuc> sgmoore[m], I'd recommend completing a few DLAs to understand the workflow, then check https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues for things to do :)
15:01:05 <Beuc> Santiago[m], welcome back ;)
15:01:21 <Santiago[m]> thank you! I am happy to be here again :-)
15:01:54 <el_cubano> sgmoore[m]: In general, if you start to look at a package and for some reason decide you aren't going to complete the work on it, then it makes sense to document anything interesting you find in a note in dla-needed.txt for the benefit of the next person to tackle the package
15:01:58 <Santiago[m]> the workflow has changed a little bit since I left, so I won't hesitate to ask (newbie) questions
15:02:49 <sgmoore[m]> el_cubano: Great, thanks, and will do
15:03:18 <el_cubano> OK. So, welcome to sgmoore[m] and welcome back to Santiago[m]
15:03:36 <el_cubano> Does anyone have any other business before we end the meeting?
15:05:28 <el_cubano> OK. It looks like there are no further discussion items.
15:05:33 <el_cubano> Thanks everyone for your participation!
15:05:41 <el_cubano> #endmeeting