14:00:28 <el_cubano> #startmeeting
14:00:28 <MeetBot> Meeting started Thu Jan 23 14:00:28 2025 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:28 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:48 <el_cubano> Hello to everyone and welcome to the first monthly LTS contributor meeting of 2025!
14:01:01 <el_cubano> #topic Roll Call
14:01:12 <helmut> hello
14:01:18 <ta> hi everybody
14:01:21 <santiago> hi there!
14:01:24 <el_cubano> I know some of you have already said 'hi', but please do so again so have a record of your attendance in the meeting notes
14:01:25 <kanashiro> o/
14:01:25 <jochensp> moin
14:01:26 <paride> o/
14:01:31 <lamby> Hello
14:01:38 <guilhem> hello
14:01:53 <petn-randall> hi
14:03:48 <el_cubano> OK. It looks like that is everyone who is going to join for today.
14:04:01 <el_cubano> Let's get started
14:04:21 <el_cubano> First, the agenda is here: https://pad.riseup.net/p/lts-meeting-agenda
14:04:35 <el_cubano> Next up ....
14:04:44 <el_cubano> #topic dput-ng for ELTS uploads
14:05:17 <el_cubano> This is meant simply as a brief FYI. I have already announced it via email, but I want to ensure maximum visibility
14:05:39 <el_cubano> The target host of ELTS uploads (and only ELTS uploads, not LTS) has changed: https://freexian.gitlab.io/services/deblts-team/documentation/elts/information-for-extended-lts-contributors.html
14:05:57 <el_cubano> Please double-check your dput-ng configurations and compare against the updated documentation
14:06:24 <el_cubano> If, like me, you often work from more than one machine, make sure to check your configurations for each place you use to build/sign/upload packages
14:06:47 <santiago> ACK!
14:07:00 <helmut> if you failed to update your dput conf, you likely see a changed ssh fingerprint
14:07:18 <helmut> the ssh fingerprint stays the same, but the hostname changed
14:07:44 <el_cubano> I have also heard a rumor that helmut will suddenly appear next to you and smack your hand with a ruler
14:08:00 <el_cubano> But I wasn't brave enough to try it and find out
14:09:09 <el_cubano> OK. Any questions on this item?
14:09:30 <santiago> not here. thanks
14:09:58 <el_cubano> Moving on, then ...
14:10:08 <el_cubano> #topic ICYMI: DEP-14 branches explained visually
14:10:40 <el_cubano> I'm not sure if everyone reads debian-devel closely, so I thought I'd highlight a recent post by Otto where he shared a blog article he wrote
14:10:50 <el_cubano> Article -> https://optimizedbyotto.com/post/debian-source-package-git/
14:11:25 <el_cubano> Otto is well-known for advocating for standardized packaging workflows in Debian (and this is something which benefits the sort of work we do)
14:12:07 <el_cubano> If you didn't read the article yet, I would encourage you to do so (even if you think you've got a solid grasp of Debian packaging workflows). He provides some nice tips and I even found a few things I didn't already know.
14:13:28 <el_cubano> I do not expect that there are any questions or discussion on this (unless someone has read the article previously and has comments to share)
14:13:47 <andrewsh> el_cubano: oh, I also made something similar in the past
14:14:08 <el_cubano> andrewsh: Oh yeah? Feel free to share (here and/or on the ML)
14:14:19 <andrewsh> https://shadura.me/talks/debconf/2019/distro-in-git/#slide:17
14:14:57 <andrewsh> el_cubano: it wasn’t a blog post, you see, but a talk where this was a subtopic
14:15:31 <rouca> sorry being late
14:15:31 <el_cubano> Nice. Like "DEP-14 in a single picture"
14:15:50 <rouca> oh nice also
14:16:15 <el_cubano> rouca: np on being late
14:16:25 <andrewsh> see also one of the previous slides
14:16:27 <petn-randall> I'd be happy if dep-14 became more common, there's seldomly a good reason to diverge from that.
14:16:28 <andrewsh> Debian: 17351 Git workflows and counting[citation needed]
14:16:32 <andrewsh> Each one is the correct one!
14:17:02 <el_cubano> I now feel obligated to share this https://xkcd.com/927/
14:18:21 <el_cubano> petn-randall: Agreed. It would also be really good if maintainers who do diverge (for good reasons) would document those reasons and the peculiarities of the actual branch structure in a given package in README.source (I think that would be the right place)
14:18:41 <santiago> so, for LTS(/ELTS) packages, we keep forking maintainer's repo when they follow DEP-14, and create an independent repo otherwise?
14:19:15 <rouca> about legacy repo ?
14:19:49 <el_cubano> My understanding is that our preference is: (1st) work in maintainer repo, if permitted, (2nd) fork repo, if the branch structure is sensible, (3rd) create new repo with gbp-import
14:20:00 <andrewsh> what about situations when the maintainer’s repo needs special access?
14:20:23 <andrewsh> e.g. with 389-ds-base, I had to ask Timo to get access
14:20:24 <santiago> el_cubano, correct
14:20:29 <andrewsh> so I can push there, but others can’t
14:20:37 <el_cubano> andrewsh: make a request. IME, they have all been very responsive (either granting access or saying "no thanks, we'd rather not have LTS work done in here")
14:21:19 <andrewsh> el_cubano: so I did, but, say, you want to fix somethign there tomorrow and you don’t have access
14:21:27 <andrewsh> so in the end I ended up keeping the lts fork
14:21:38 <andrewsh> but also pushing tags and branches to both
14:22:18 <el_cubano> I suppose if it is a fork, that's not terrible. However, if the maintainer is open to us working directly in the same repo, then we're probably better not also keeping a fork
14:22:35 <el_cubano> It seems like this might be something that needs to be documented more clearly
14:22:42 <andrewsh> I also think maybe the guidance re CI could be reworded: if the maintainer uses keeps the YAML file at a different location, it makes sense to use that instead of the standard LTS location
14:22:59 <andrewsh> s/keeps //
14:23:10 <el_cubano> That said, I don't see a problem with maintainers selectively allowing devs direct push access
14:23:15 <andrewsh> ack
14:23:34 <petn-randall> andrewsh: which yaml specifically? debian/salsa-ci.yml?
14:23:37 <andrewsh> OTOH once the branch is there, MR workflows work
14:23:38 <andrewsh> petn-randall: yes
14:23:47 <el_cubano> In the 389-ds-base case I don't think there would be an emergency of such proportions that my inability to push directly to the maintainer repo at a moment's notice is the big part of the problem
14:23:55 <andrewsh> el_cubano: indeed
14:24:05 <andrewsh> btw what a package name that is :)
14:24:13 <el_cubano> I can still clone and work, build, sign, push, etc, without that access and then request access and push everything after
14:24:18 <andrewsh> the upstream should have thought of something more sensible
14:24:31 <petn-randall> You can always publish the package before getting access to the repo and pushing, though it leaves an annoying room for human error.
14:24:33 <el_cubano> And if the maintainer doesn't want to grant access, I can just send a debdiff, MR, or some other thing
14:24:36 <guilhem> won't maintainers get annoyed with too many granting request if the LTS contributor varies over time?  or is the request for the entire (current and future) team?
14:24:54 <helmut> if maintainers get annoyed, you can fork at any time
14:24:58 <el_cubano> I haven't seen any maintainer get annoyed with it.
14:25:07 <el_cubano> And there is that as well
14:25:26 <petn-randall> dnsmasq has a very peculiar packaging style, and they haven't been reluctant to change to dep-14.
14:25:48 <el_cubano> #action el_cubano clearly document our preferences/understandings for when to work in maintainer repo, when to fork, and when to start a repo from scratch
14:25:49 <petn-randall> it's basically upstream git repo and a git submodule for /debian/.
14:26:26 <el_cubano> petn-randall: have been reluctant or haven't been?
14:27:02 <petn-randall> have been
14:27:08 <el_cubano> Ah, OK
14:27:42 <el_cubano> And that would be an instance where "create a repo from scratch and send debdiffs to the maintainer (only if they are wanted)" is probably the right approach
14:28:00 <jochensp> why not just fork in that case?
14:28:15 <el_cubano> Probably because of the odd branch structure
14:28:25 <el_cubano> In any event, I wasn't expecting all this discussion on this item and I'm fairly certain that the next one will generate some discussion, so we need to move on
14:28:34 <el_cubano> Up next ...
14:28:43 <el_cubano> #topic Discussion: Expectation of concurrent LTS+ELTS work
14:29:28 <santiago> (this is debian. any topic could bring *some* discussion)
14:29:59 <el_cubano> I suppose I should be grateful that I didn't ask people whether we should prefer tabs or spaces :-p
14:30:14 <andrewsh> el_cubano: :D
14:30:22 <el_cubano> I gave a fair amount of detail on this in the agenda itself. However, the brief one sentence version is "I am thinking of formally articulating a policy that contributors are expected to handle both the LTS and ELTS instances of a package (when they both exist and when both need work)"
14:30:57 <petn-randall> el_cubano: Why not both like in dnsmasq? ;)
14:31:41 <el_cubano> petn-randall: Considuer yourself your lucky that I don't have the ability to kick you out of this channel for suggesting such an abomination as both tabs and spaces together
14:31:57 <petn-randall> heh :)
14:32:05 <el_cubano> Back to the business at hand ...
14:32:33 <el_cubano> I expect that most contributors already look for a package in both places and claim/work on it (simultaneously or consecutively)
14:33:21 <el_cubano> However, there have been several instances over the past year or so of someone claiming one but not the other. I'd like to reduce the occurences of this sort of thing, and so proposed formalization of the LTS+ELTS concurrent work policy.
14:33:56 <rouca> nice
14:33:58 <el_cubano> As noted in the agenda summary, I will send out an official email announcing this, and I will document this as well. However, I will wait a few days for comments and feedback.
14:35:05 <el_cubano> OK. Any questions or comments at this point?
14:35:43 <santiago> not here
14:35:47 <petn-randall> yes
14:36:10 <ta> el_cubano: don't you plan to merge LTS and ELTS anyway? So maybe this can be done already with tha *la-needed files?
14:36:19 <rouca> not here
14:36:25 <kanashiro> none
14:36:27 <petn-randall> IIRC it happened between me and rouca regarding dnsmasq. In this case I claimed dnsmasq, but it was unclaimed after two weeks. Is there any way to prevent that?
14:36:43 <santiago> ta, we are not aiming to merge the LTS and ELTS **work**, but the teams
14:36:50 <rouca> el_cubano: do not forget case for package with vesion like ruby2.7 ruby2.5
14:36:53 <el_cubano> ta: The teams will merge, but we will need to retain the two distinct trackers
14:37:05 <ta> ah, ok
14:37:09 <el_cubano> So, there will continue to be both dla-needed and ela-needed
14:37:18 <santiago> LTS remains a project inside debian, while ELTS is purely freexian's
14:37:19 <el_cubano> This policy is actually a step in the direction of merging the teams
14:38:02 <el_cubano> rouca: Yes, I mention that specifically in my summary. In essence, there is room for judgment precisely for the case where you have "these packages seem like they should be very similar, but they really are not"
14:38:27 <el_cubano> petn-randall: I am open to discussing the usefulness of the automatica two week unclaim
14:38:32 <rouca> and also embded copy like javascript stuff
14:39:16 <el_cubano> When it was implemented we had few packages, many people, and it was a problem with people claiming lots of packages and then not making progress on them.
14:39:34 <petn-randall> el_cubano: It makes sense for smaller packages, but for dnsmasq and samba I noticed that's quite short unless you're working fulltime on it.
14:39:40 <santiago> any DD (outside freexian) can contribute to LTS, as it was made with the debootstrap fix last month (thanks bluca!)
14:39:44 <el_cubano> It was a bit haphazard to have FD manually ping people, especially since FD changes each week, and memory of thise sort of thing is difficult to retain
14:40:01 <rouca> can we have a FD wiki ?
14:40:44 <el_cubano> #action el_cubano investigate the possobility of a wiki for FD
14:40:55 <petn-randall> What about a machine-readable field that claimants set to tell when they're expecting to fix the package?
14:41:12 <petn-randall> e.g. until: 2025-01-30
14:41:21 <el_cubano> petn-randall: That's a good idea
14:41:36 <santiago> petn-randall, that could be part of a new {d,e}la-needed format
14:41:58 <jochensp> maybe make it optional for a longer claim and keep the two weeks as a default
14:42:05 <petn-randall> It would also allow one to extend it if it turns out more time is needed.
14:42:12 <petn-randall> jochensp++
14:42:56 <el_cubano> It could also trigger a ping/reminder to the claimant X days before the 'until'
14:43:22 <el_cubano> OK. I have made a comment on the issue in GitLab to capture this suggestion.
14:43:29 <jochensp> and maybe the unclaim tool could check if the timeframe is sensible, i.e. no one should claim for some years or somelthing
14:44:42 <el_cubano> Returning to the main point of this agenda item for a moment, I want to emphasize that there is certainly room for deliberately choosing to have two (or more) people work on the same package in LTS and ELTS.
14:45:10 <el_cubano> There have been instances where the changes and required testing are so extensive (and the commonality between versions low enough) that we have made this choice on purpose
14:45:12 <rouca> agreed
14:45:14 <el_cubano> and that is OK
14:45:17 <rouca> like apache
14:45:27 <el_cubano> rouca: Yes, like that
14:45:36 <el_cubano> And I think bind9 several years ago
14:46:16 <el_cubano> OK. Any questions and/or discussion on this item?
14:47:46 <el_cubano> It appears that we have concluded this item
14:47:48 <el_cubano> Up next ...
14:47:54 <el_cubano> #topic Using debusine for LTS testing
14:48:00 <helmut> Last meeting, I was tasked with writing a tutorial for using debusine as a QA tool for LTS uploads. In doing so, I figured that there still are a lot of rough edges and the lack of identifying autopkgtest regressions significantly limits its utility at present. We're working on that.
14:48:00 <el_cubano> helmut: Was this your addition?
14:48:37 <helmut> Example of a pipeline https://debusine.debian.net/debusine/System/work-request/70667/
14:49:26 <helmut> if you have any questions or feedback regarding this, you may direct them at me or #debusine.
14:49:58 <kanashiro> looking forward to use that :)
14:50:09 <rouca> nice
14:51:28 <el_cubano> Yes, that is very nice.
14:51:46 <el_cubano> OK. Any questions or comments for helmut on this?
14:52:14 <santiago> so "debusine" should run a pipeline for the package currently in the archive for being able to identify regressions?
14:52:32 <santiago> that is a question for after the meeting :-) I am being just too curious
14:53:33 <helmut> santiago: ideally, the pipeline runs a reference test when the test fails and produces a suitable report. that's not implemented yet
14:54:00 <helmut> the goal is that lts contributors simply run 1 pipeline and get what they need
14:54:38 <santiago> awesome
14:55:06 <el_cubano> helmut: Presumably, the goal is that this eventually becomes the way all Debian uploads are handled (e.g., including to unstable, experimental, and so on)?
14:55:26 <el_cubano> Assuming project-wide adoption, that is
14:55:44 <helmut> no clue, it's more like opt-in
14:55:53 <el_cubano> Ah, OK
14:56:40 <helmut> it totally is a plausible use case that you send your signed .changes (for the debian archive) to debusine and have it forward the upload if it passes ci and not otherwise
14:56:57 <el_cubano> Neat!
14:57:03 <tobi_m> sorry for being late, had a meeting...
14:57:26 <el_cubano> tobi_m: Welcome just the same
14:57:41 <el_cubano> OK. Any other comments or discussion on debusine?
14:58:08 <helmut> any early adopters I should pester with drafts?
14:59:43 <kanashiro> I can be an early adopter :)
15:00:00 <el_cubano> OK. So, if you are interested in being an early adopter, get in touch with helmut
15:00:29 <el_cubano> We've just crossed the 1 hour mark, so I'd like to see if we can wrap this up quickly
15:00:32 <el_cubano> Up next ...
15:00:35 <el_cubano> #topic Any Other Business
15:00:45 <el_cubano> Does anyone have anything for AOB?
15:01:35 <ta> I would like to remind everybody that the DLA/ELA email should only be sent if the package could have been build and not just after the upload
15:01:53 <petn-randall> o/
15:01:54 <ta> this is especially valid for packages that use Built-Using:
15:02:19 <petn-randall> Yeah, I think I ran into that mistake in one of my uploads.
15:02:26 <el_cubano> helmut: Actually, that would be a handy debusine feature. Allow uploading an email announcement text that could be signed and sent when certain conditions are met
15:02:45 <petn-randall> Oh, indeed!
15:03:29 <santiago> and debusine could also check for the existence of the git tag and related some time after the announcement has been published  ;-)
15:03:43 <el_cubano> Yes, that would be good too
15:04:28 <helmut> the mail sending part should be done at migration time, no?
15:04:42 <jochensp> I think that would better fit in some tool using the debusine API
15:05:26 <el_cubano> helmut: Is it OK if I assign you the action to at least capture these two general concepts in some way (whether issues or items on the roadmap, or whatever)?
15:05:46 <el_cubano> I don't think that they need to be engineered in detail right this moment
15:05:59 <helmut> el_cubano: I don't think they're a good fit for debusine, tbh
15:06:16 <petn-randall> helmut: Shall I file some well-defined bug reports for that?
15:06:33 <el_cubano> Hmm
15:07:02 <el_cubano> helmut: Would these be implementable by an external tool via some API? (As jochen suggests)
15:07:25 <helmut> Let me suggest that we get started with debusine and then when we run out of bugs and issues ask for more features. My experience is that running out of issues is not going to happen quickly.
15:07:44 <helmut> el_cubano: debusine can be driven using an api, yes.
15:08:36 <el_cubano> Ack
15:08:38 <helmut> for email and git automations, consider using servertasks and we're getting off topic I think
15:08:49 <el_cubano> petn-randall: Can I invite you create a couple of issues in the debian-lts project, so that we don't forget about these?
15:08:59 <petn-randall> sure
15:09:07 <el_cubano> Then later when a call goes out for feature requests we can look at whether these are still suitable
15:09:46 <el_cubano> #action petn-randall create issues in the debian-lts project to capture the ideas of "send this message after migration" and "check for the existence of the git tag and related"
15:10:06 <el_cubano> petn-randall: Thanks!
15:10:14 <el_cubano> OK. Anyone else? Anything else?
15:10:37 <santiago> nope
15:11:47 <rouca> yes
15:11:54 <rouca> js triagging
15:11:55 <el_cubano> rouca: go ahead
15:12:12 <rouca> js package are complicated
15:12:38 <santiago> my gut feeling is that we would need a one-hour meeting for that single topic. I hope I am wrong :-)
15:13:03 <rouca> for instance if you have a main package that have a stuff.js
15:13:11 <rouca> pleae use apt-file seach stuff.
15:13:13 <rouca> and cry
15:13:30 <rouca> and use also sources.debian.org to search CDN use
15:13:50 <helmut> .oO(and then you notice that the embedded ones are minified missing source)
15:13:59 <rouca> helmut: yes
15:14:01 <rouca> and you cry
15:14:30 <rouca> remember the apocalypse painting at toulouse main conf
15:14:49 <rouca> and remeber to do the work for every release
15:15:02 <rouca> so one CVE about 20 packages to fix
15:15:44 <rouca> el_cubano: I have finished
15:17:26 <santiago> unfortunately, codesearch.debian.net doesn't index releases other than unstable, so its usefulness for our work is limited
15:18:02 <el_cubano> I think at one point we discussed a codesearch.debian.net-like tool/service for stable/oldstable/and so on.
15:18:06 <el_cubano> Or did I imagine that?
15:18:43 <rouca> yes we discussed
15:18:48 <rouca> so we have case here
15:19:47 <el_cubano> #action el_cubano document or create issue for "a codesearch.debian.net-like tool/service for stable/oldstable/and so on"
15:20:04 <el_cubano> OK. I'll create an issue or something so we can have a record of this idea
15:20:14 <el_cubano> Anyone else or anything else?
15:20:43 <santiago> it is also to note that some packages may Depend: on the concerned packages, instead of the embedded copy
15:20:56 <rouca> el_cubano: i send you the example
15:21:02 <santiago> nothing more to say here
15:21:03 <el_cubano> rouca: Thanks!
15:21:45 <el_cubano> santiago: True. I maintain some packages that embedd some JS in the source, but I ignore it or remove it during build and then depend on the relevant libfoo-js package instead.
15:22:09 <rouca> yes but should be added to embded code and noted ignred in cve triage
15:22:25 <el_cubano> good point
15:22:36 <rouca> data/embedded-code-copies
15:22:44 <el_cubano> OK. I think that's everything.
15:22:49 <el_cubano> Ah, wait
15:22:54 <el_cubano> #topic Next meeting
15:23:00 <el_cubano> Next meeting: 2025-02-27 14:00 UTC [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting]
15:23:05 <lamby> Thanks folks.
15:23:11 <jochensp> thanks :)
15:23:24 <petn-randall> thanks everyone o/
15:23:34 <ta> ok, byebye
15:23:35 <el_cubano> Goodbye everyone, and we'll see each other next time
15:23:39 <santiago> thankyou all!
15:23:48 <kanashiro> thank you all o/
15:24:12 <petn-randall> el_cubano: those feature requests should go to https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues ?
15:25:09 <el_cubano> petn-randall: I was actually thinking of gitlab.com:freexian/services/deblts-team/debian-lts.git
15:25:43 <el_cubano> Since they are not actually strictly LTS tasks, per se. However, I suppose that the benefit of lts-extra-tasks is that it is public
15:26:45 <el_cubano> So, unless there is a good reason that they shouldn't be public (and I can't think of one), then they can go in lts-extra-tasks (with an appopriate note that these are placeholders and not meant to be actively in work at any point in the near future)
15:26:51 <el_cubano> Ah, forgot to end the meeting
15:26:55 <el_cubano> #endmeeting