14:00:06 #startmeeting 14:00:06 Meeting started Thu Nov 28 14:00:06 2024 UTC. The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:20 Welcome to everyone. This is the monthly LTS team meeting. 14:00:32 #topic Roll Call 14:00:38 Hi! 14:00:41 hi 14:00:43 ahoy 14:00:44 hello 14:00:44 Please announce yourself so we have a record of your attendance 14:00:49 o/ 14:00:55 hi 14:01:11 * kanashiro waves 14:01:16 hello 14:01:26 And looking at the agenda, we have apologies from: bunk 14:01:44 hey 14:01:57 Also, I just realized that with all that has been going on, I forgot to send the meeting reminder. But, it looks like we have a good crowd here today. 14:02:08 Thanks to everyone for attending. 14:02:24 The agenda is light for today, so the meeting should not be overly long 14:02:35 #topic MiniDebConf aftershow 14:02:40 agenda: https://pad.riseup.net/p/lts-meeting-agenda 14:02:40 * el_cubano has the floor 14:02:47 jochensp: Thanks :-) 14:02:51 I forgot to post the link 14:03:32 So, earlier this month the Debian France organization put on a Mini-DebConf in Toulouse. Many of us attended and quite a few of us gfave talks. 14:04:08 Santiago and I, specifically, gave a talk over LTS and how our work as a team has been impacting (positively) Debian as a whole and the broader free software community 14:04:35 So, thanks very much to all of you who have contributed over the past year. And let's please continue with all of the good work. 14:05:16 Especially: helping maintainers with improving packages in unstable (e.g., autopkgtest, etc.), and collaborating with maintainers and upstreams on fixes, patches, testing, etc. 14:06:04 I sent an email to deblts-team with some additional details about what took place and some thoughts about possible sprints during DebCamp at DebConf25 14:06:29 I had proposed to Santiago a sprint to see if we could make some major progress on security tracker improvements. 14:06:46 It would be great if someone could help with preparations for that. 14:07:12 And if anyone has any suggestions for other sprints that the LTS Team might be able to help coordinate, please let's have them. 14:08:01 \o 14:08:03 Did anyone want to say anything about the Toulouse event and/or ask any questions? 14:08:22 it was great seeing you all there :) 14:08:32 that! 14:09:09 +1 14:09:49 +1 14:09:59 As an extra-curricular note, we have formed a small running group. For those who end up attending DC25, I'd love to grow the group, so bring your running shoes :-) 14:10:29 I'd be happy to show my favorite running paths next to the DC25 venue ;-) 14:11:09 yay :) 14:11:26 in-person meetings are great. But if someone is willing to have some on-line sprint before DC25, we could also discuss about that. Yeah, I know, it is less fun 14:11:46 OK. Last call on Toulouse and potential DC25 comments/questions 14:12:43 Ok. Then moving on 14:12:59 #topic E-mail policy question on CCing 14:13:05 Beuc: you have the floor 14:13:38 Hi. For LTS in particular we have 2 lists, debian-lts@l.d.o (public) and deblts-team@freexian.com (private) 14:14:22 I tend to use debian-lts for the reasons I mentioned at https://pad.riseup.net/p/lts-meeting-agenda (transparency + ability to link public archives in docs, or to point people to discussions) 14:14:58 I'm not sure that we have an official policy. However, the guidelines I personally use are these 14:15:28 debian-lts@lists.d.o: anything that does not have a good reason to be private (which should be most things) 14:15:38 Often I see posts that could have gone to debian-lts@l.d.o being sent to deblts-team@freexian.com; I often wonder if that's an oversight, or some other reason :) 14:16:19 are there some guidelines what should be private? 14:16:22 deblts-team@f.c: if the discussion involves sponsor/customer info, if it involves anything potentially non-public (e.g., links to private projects, internal docs, etc) 14:17:09 I was surprised to see an X-debbugs-cc to the private list, since the bug report is public anyway, but that was probably an oversight 14:17:13 The way I look at it: most everything discussed on debian-lts@lists.d.o should be accessible to any member of the public anonymously (with the possible exception of some things requiring Salsa auth) 14:17:41 for example I've started a few discussions like "should we still support $X?" -- its a bit customer related, so unsure if that is private or not 14:17:49 All of that said, I do occasionally send things to the private list because I didn't think about the recipient before sending 14:18:18 tobi: I am OK with discussions like that being on the private list 14:18:42 It is also a little fuzzy for things that touch both LTS and ELTS, especially since the sponsorship/support model for ELTS is rather different from that of LTS 14:18:59 thanks for clarifying that :) 14:19:22 sorry for the delay 14:19:29 That said, it seems like there is enough doubt floating around that this should be documented more clearly. 14:19:36 Questions of the form "should we support?" are resource questions and depend on whom you are asking. If it is a Freexian question, the internal list seems preferrable. If you instead ask "Does anybody want to support XX?" the public list seems better. 14:19:38 that's a bind for me, support decisions usually lead to a full LTS EOL, and public discussion explaining the choice could be public 14:20:03 s/public discussions/discussions/ 14:20:08 helmut: +1 14:20:14 +1 too 14:20:19 +1 14:20:45 #action el_cubano clearly document guidelines for which topics/discussion belong on the public list versus the private list 14:22:06 Any other questions or comments on the email policy? 14:22:20 not here 14:22:24 not here 14:22:44 nope 14:23:48 Ok. Moving on then 14:24:02 #topic Documentation update about contributions to unstable/testing 14:24:06 santiago: you have the floor 14:24:15 el_cubano, thanks 14:24:42 this is just a heads-up and follow-up of the discussion we started last month about contributions in unstable 14:25:11 thanks to el_cubano and Beuc, we have a brief documentation that can be found at: https://freexian.gitlab.io/services/deblts-team/documentation/lts/information-for-lts-contributors.html#what-can-should-be-done-during-assigned-work-hours 14:26:16 there are things to improve about this, e.g. having a list of potential packages requiring attention in unstable (and testing) 14:26:56 but I hope the brief documenation helps for now 14:27:12 if you have any comments or questions, please, don't hesitate to speak up 14:27:42 s,doesn’t look good for Debian when we have open issues in stable/oldstable, doesn’t look good for Debian when we have open issues in stable/oldstable and will break upgrade path by your custumers, 14:28:01 the main point is breaking secure upgrade 14:29:01 rouca, could you please explain a little bit more? 14:29:27 CVE-XXX is fixed in buster 14:29:49 custumer upgrade to bullseye (what ever reason) and is reaffeted by CVE 14:30:29 and I have another critical case, CVE-XXX is fixed in buster but need configuration change in buster (we had the case) 14:30:48 it upsgrade to bullseye and in this case upgrade is fully broken 14:30:59 (this case should be top priority I think) 14:31:35 sure, and our focus should remains the security updates in the LTS release 14:32:40 probably I need to be more clear. last month we briefly discussed about helping maintainers with complex packages that were lagging behind in unstable/testing wrt the latest upstream release 14:32:45 Discrepancies between lts & stable usually target (very-)low-priority CVEs though. 14:33:21 Beuc: usually but sometimes LTS team was faster then security team 14:33:49 rouca, we are doing our best to sync with stable to avoid upgrade regressions 14:34:11 I tend to believe the situations has improved, but I have not data to rely on 14:34:11 santiago: yes should be documenteed 14:34:21 rouca, same, we're rarely faster for medium/high CVEs 14:34:27 rouca: It is documented 14:34:42 for the case "fixed in oldstable, but not in stable", this is not always in our control. e.g smarty3 I reached out to the stable security team but did not get any response... 14:35:18 https://freexian.gitlab.io/services/deblts-team/documentation/lts/information-for-lts-contributors.html#id17 14:36:20 tobi: then do a PU upload? 14:36:44 That would be my recommendation as well. 14:37:53 ta: I've sent them a mail, because it is in dsa-needed.txt. I've got scoulted in the past for preparing a PU without secteam approval. 14:37:55 It seems safe to assume that if secteam doesn't respond they do not consider the issue especially important. The way I would do it is to coordinate w/ (O)SRM and the send a final follow-up to secteam saying something like "I have started coordinating w/ (O)SRM to upload for a point release, if you would prefer a -security update right away instead, please let me know" 14:38:38 tobi: I think "I attempted to contact them but received no response" counts as coordinating w/ secteam first. 14:39:07 tobi: I have done a few PUs and never got any negative feedback about not coordinating with sec team, but I only did it for no-dsa ones I guess. 14:39:08 I would summarize that as "needs coordination with both, the release and the security team" 14:39:15 they are also the case of ***censored*** upstream 14:39:25 I had the case this week 14:39:37 If you happen to encounter a situation where you attempt to contact secteam first and, after receiving no response, you start coordinating w/ (O)SRM and then receive negative feedback from secteam, please advise me and santiago 14:39:59 I get to the bug tracker trying to find the commit for a CVE and I get reading the CVE a huge problem 14:40:15 by default gid was setto 0 14:40:18 ok, will prepare than a PU 14:40:34 instead of whatever 14:40:49 tobi, have you sent a gentle ping to the sec team? 14:41:30 I'll do that too ;) 14:42:58 thank you 14:43:13 OK. Anything else on this topic? 14:43:34 so, this drifted a little bit from the original topic 14:43:47 I hope my initial comments were clear enough 14:45:36 +1 14:46:41 Alright, moving on 14:46:46 #topic AOB 14:46:50 just as an example of what I had in mind, I just did a MBF about the migration to bootstrap v5 14:46:57 Oups 14:46:59 but yeah, let's move on :-) 14:47:03 that was my last comment 14:47:15 OK. I was about to change the topic back :-) 14:47:27 Alright, since that is really done... 14:47:37 Does anyone have anything have any other business to bring up? 14:48:02 (None here.) 14:48:17 idem here 14:48:23 isem 14:49:04 may a minor elts update: arm64 autopkgtests should work. armhf are disabled again and need more work on the infra side. they'll run on incus rather than qemu eventually. 14:49:08 nothing here 14:49:36 nothing from me 14:50:06 OK. Last call for AOB 14:50:11 lts autpkgtests will target debusine infrastructure. all relevant (lts and elts) suites are available on debusine.debian.net accessible to all dds, so you can test your packages there now. 14:50:47 reverse dependency autopkgtests are being implemented in debusine and may work next year 14:52:02 I really like those tests btw, so thanks 14:52:26 +1 14:52:27 And for anyone who may be interested in learning more about debusine and how to use it with its currently available features, Stefano (and Enciro, Helmut, and Carles) gave a presentation about it in Toulouse 14:52:31 Video here: https://toulouse2024.mini.debconf.org/talks/3-using-debusine-to-automate-your-qa/ 14:53:03 and Colin 14:53:15 * el_cubano facepalms 14:53:16 s/Helmut/Colin/ (I didn't) 14:53:21 * el_cubano facepalms again 14:53:50 I'm just the one who complains all the time about how debusine doesn't work. 14:54:17 Lol 14:54:27 that's an importat role 14:54:34 Well, we all contribute according to our abilities :-p 14:54:50 that's call QA 14:55:30 Seriously, though, debusine is already quite capable, so it would possibly be beneficial to many of the things we do for LTS. Plus, the team would certainly appreciate the feedback from additional users 14:56:04 OK. Once again ... last call for AOB. Anything/anyone else? 14:57:23 Moving on, then 14:57:30 #topic Next meeting 14:57:41 Next meeting: 2024-12-19 14:00 UTC [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting] 14:57:48 (NOTE: this is the third Thursday, to avoid conflicting with Christmas) 14:58:51 And with that, I believe that we are done. 14:58:58 Thanks to everyone for participating 14:59:23 el_cubano: thanks :) 14:59:26 thank you el_cubano for chairing! 14:59:27 o/ 14:59:38 enjoy your party! 14:59:47 have a nice one! 15:00:03 thanks for chairing el_cubano o/ 15:00:14 #endmeeting