14:00:23 #startmeeting 14:00:23 Meeting started Thu Nov 25 14:00:23 2021 UTC. The chair is jeremiah. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:23 I'm a bit unconventional like that. And usually, my family does a pig roast, pig being more common for big family meals in the Caribbean than turkey. 14:00:49 * ta is getting hungry now 14:01:04 Me as well. ;) 14:01:11 it's just a rainy, grey day here in Germany, but Happy Thanksgiving to you folks :) 14:01:32 It is also a rainy, grey day here in the midwestern US 14:01:33 A rainy day in Northern Europe? How unusual. 14:01:43 ^^ :) 14:02:29 #topic Greetings and welcome 14:02:55 Thanks everyone for coming to the meeting. 14:03:40 o/ 14:03:51 hi everybody 14:03:51 . 14:03:52 hiho 14:03:56 We'll get off to a rolling start as it is harder to determine if everyone is "present". 14:04:09 0/ 14:05:07 Those who are late to arrive have the benefit of the logs 14:05:27 Since we have a large agenda, I figure we'll get started. 14:05:36 yup 14:05:47 Just a reminder that the agenda is here: https://pad.riseup.net/p/lts-meeting-agenda 14:06:05 #topic How to avoid having different people working on the same package in LTS and ELTS? 14:06:25 This topic seem fairly straight forward to me 14:06:32 It's an old problem of which I saw an example again this month: 14:07:06 Someone (who also has hours in LTS) took samba in ELTS, and 1 day later someone else took samba in LTS. 14:07:39 It would be more efficient if packages that get updated in both LTS and ELTS would be handled by the same person. 14:07:43 Question: How? 14:08:30 Is it possible to use a single entry to "take" a package for both LTS & ELTS? 14:08:56 bunk: Usually, but not always. I worked on Samba either last year or early this year. The differences between the LTS and ELTS versions were considerable. That said, I think in principle your concern is sensible and we should generally try to make sure the same person has the package in both projects, but especially when the versions are very close/identical. 14:09:08 so why not claim both packages immediately? 14:10:45 right, but sometimes the two frontdesks don't act at the same time. I can see an outcry again, if someone "circumvents" frontdesk 14:11:07 I'm totally in favor of letting the same person handle the package for LTS and ELTS 14:11:15 if this happens just once a month, people could talk to each other ... 14:11:23 exactly 14:11:41 talking to each other is my solution to this problem too 14:11:47 and one can talk to frontdesks as well 14:12:32 I don't think OCOCOCOCOCOCOCOCOCOCOCOCwe need to think about some procedure here ... just talk to eachother 14:12:37 I have taken that approach and it seems to work very well (just communicating that is). 14:12:59 Adding more procedure will likely just bog things down with minimal (if any) additional benefit 14:13:14 What type of communication do we advise? Is it a note? Drop a message in IRC? An email? 14:13:31 I'm more concerned about the current practice of claiming too many packages for ELTS. While it is usually ok for LTS, ELTS is different because the scope is much more limited. For instance I could have fixed ntfs-3g by now, and I wanted to talk to utkarsh about it but he seems to be absent 14:13:49 an email should be fine 14:14:25 apo: I've had trouble reaching him recently as well. 14:14:54 yes, if there is no reaction on irc, email would be find 14:14:57 fine 14:16:52 #info Greater communication around packages in both LTS and ELTS is wanted. A note on IRC and/or email is helpful to make the claiming of packages more effecient. 14:16:57 efficient. 14:17:53 #info claiming too many packages and being incommunicado can delay package fixes from others 14:18:33 I feel that this transitions well into our next topic; 14:18:41 #topic Review of unclaimed packages in dla-needed 14:18:57 There are 3 unclaimed packages in dla-needed: 14:19:20 1. ansible: The notes read as if apo wanted to take it again after the last buster release? 14:19:54 * petn-randall waves. 14:19:57 2. debian-archive-keyring: neverending(?) story by utkarsh 14:20:06 no, the maintainer talked to me and wanted to finish the update 14:20:56 3. nvidia-graphics-drivers: I think (to be confirmed) that all 5 CVEs are fixed in the (renamed) package in buster/bullseye/bookworm. Does anyone have supported hardware and does not fear non-free? 14:21:15 Lee Garrett is the maintainer of ansible, I don't know why he didn't finish it yet 14:21:38 he is also a LTS team member so it seemed sensible to me to let him handle it 14:22:29 petn-randall: ^^^ 14:24:14 I will try to reach out to him and clarify the status of ansible 14:24:37 I will reach out to Utkarsh and try and clarify the status of debian-archive-keyring. 14:24:57 ah ok 14:25:19 petn-randall: so what's up with ansible ? :) 14:26:25 The Nvidia issue seems a little harder given the requirements. I'm afraid I don't have any Nvidia hardware at hand except for a Trimslice which is Tegra 2 and quite old. 14:28:07 bunk: Is there another forum we can raise the issue of the unclaimed Nvidia drivers to get more attention? 14:28:15 same here, but we could ask for testers on the lts mailinglist or maybe -backports? There are usually more people who use Nvidia and request backports of the drivers regularly 14:28:51 That sounds good 14:28:51 This would still need someone to take the package and prepare an update 14:28:52 * el_cubano wonders if there might be an arrangement that could be formed with an individual or a company similar to what we previously had with credativ for Xen support 14:29:35 There are SMBCs that often are useful in a situation like this. 14:29:36 We are looking for one piece of old graphics card from a dumpster... 14:29:53 Oh. 14:30:39 can't we just backport the package from Buster and be done with it? 14:31:18 It's a different src-package name in buster. Likely still straightforward. 14:32:32 I would investigate this solution. I can do it after I have finished roundcoube and firmware-nonfree, if nobody else beats me to it, which would be fine too 14:32:56 Thanks apo 14:33:30 #action apo to follow up re: Ansible 14:33:47 #action jeremiah to follow up re: debian-archive-keyring 14:34:17 #action apo to investigate nvidia drivers backport 14:35:05 I'll move on to another topic now 14:35:21 #topic Dispatch change: Feedback/Questions? 14:35:46 Is this about the dispatch of hours or of front desk weeks? 14:35:57 dispatch of hours 14:36:09 Thanks for confirming 14:36:48 From my perspective it's gone smoothly. 14:37:07 The big change will be in doing the monthly report, but I expect that to be significantly easier. 14:37:48 I intend to start working on the monthly report automation improvement next week. Though, I doubt I will finish before the next time it will beed to beused. 14:38:00 That's totally fine. 14:38:03 One thing missing is that pinging people happened manually this month, this should either be documented for the 2nd day of the month at 12:00 UTC to be done manually by the coordinator, or someone (preferably not me) should implement a cron job somewhere. 14:38:19 bunk: yes, that was my miss. 14:38:52 #action jeremiah to set a reminder that _emails_ need to go out reminding folks to send reports on the 2nd of the month. 14:40:15 by the way, regarding DLA 2785-1, which hasn't been published yet. I would contact Ben Hutchings directly. 14:40:39 Ah, okay. 14:40:44 he probably misses the weekly semi-automatic unclaim emails 14:41:08 Oh, okay. I've sent a few so you're likely right. 14:41:34 #action jeremiah to contact Ben directly re: DLA 2785-1 still unpublished. 14:43:03 #topic Status update: enterprise gradle project 14:43:22 I'll jump to the work being done on the gradle project 14:43:41 (We can come back to any topic if we're not completely finished) 14:44:15 In that project, a lot of investigation has been done and there's good communication between the reviewer and bidder, so we're on a good path. 14:44:48 That's great news! I briefly looked into it as I considered submitting a bid. That project is quite a beast. 14:45:22 It does look somewhat convoluted with lots of patches, missing pieces, etc. 14:45:46 yes, it took a while to get a general overview. It's not just about removing the plugin feature, it is also about Kotlin build-depending on openjdk-8 and a lot of patches that may be missing to get an actualy working gradle package 14:47:50 Folks can follow along in Gitlab on this topic as there is good communication. 14:48:01 #topic Resolution of CVE assignment tooling for related packages 14:48:19 This topic came up recently, but it is an older one. 14:48:38 Beuc: Would you like to add a word or two about this? 14:48:52 I can 14:49:01 Thank you 14:49:21 The main issue IMHO is exchanging with the security team 14:49:47 There is usually a lot of time when expecting an answer (up to weeks), 14:50:24 and lot of unanswered proposal, meaning we don't know if they are understaffed, uninterested, consider that this doesn't warrant an answer, etc. 14:50:53 I contacted jeremiah to check if there's a way to make cooperation more efficient 14:51:15 they receive a lot of emails every day and Moritz is currently travelling, so this might explain some of the delays 14:51:40 Is email the main form of communication and discussion on security topics? 14:51:53 I see that the IRC channel mostly has KGB communication. 14:53:05 yes, email is the main form of communication. 14:53:26 apo, this is an on-going topic since February, and the MR is open since september 14:53:26 I have found that generally, yes, email is the main form. Different members of the team evlauate different requests and using IRC it isn't guaranteed that the correct person will be available to reply on the spot 14:54:10 If you don't get a timely response I can bring this discussion up in our security-team IRC chat, I can't promise anything, just joined the team :) 14:54:48 I'm happy to try to get a response, but it may be better for a team member to address this. 14:55:00 So thanks apo for volunteering. 14:55:20 I'm hesitant to insert myself into the communications as I don't want to add to the noise. 14:55:35 But it seems important to have an answer for buec and others. 14:55:46 s/buec/Beuc/ 14:56:27 jeremiah, sure I didn't expect you to do any direct communication, but possibly advice on better way to handle communication, or possibly contact sectean on behalf of the team to identify communication issues 14:57:18 Thanks, that's helpful clarification. And something that I feel the administrator ought to do. 14:58:04 So I propose to try to craft a careful email to the security-team list and ask if there's ways I can help facilitate communication on topics? 14:58:42 If there's no response, I'll follow up with apo to discuss next steps. 14:58:54 yes, that's a good plan 14:59:11 #action jeremiah craft a careful email to the security-team list and ask if there's ways I can help facilitate communication on topics 15:00:01 #topic Documentation for Debian Appliance vendors 15:00:22 There's been good discussion on this topic in email - thanks! 15:00:32 oops, it looks like I missed that we have another time for the meeting :) 15:00:54 gladk: it's winter now :p 15:01:06 really? 15:01:14 Here at least. 15:01:31 The time changed a couple weeks ago. 15:02:04 yes, I know. My google calendar did not make a change there 15:02:10 but OK, I will reed the notes there 15:02:29 I'll send out minutes as well. 15:02:44 (BTW: Europe and the US are not changing on the same day) 15:03:14 If there's more to discuss regarding the package selection for long term support customers, we can continue in the email thread. 15:03:45 bunk: That's a result of the US stupidly moving the date around 15:03:50 I reading some of the LTS emails that buxy sends to customers I see that this type of question occurs a lot though. 15:04:16 And it seems that many folks might benefit from having clearer advice on what to use, what not to use. 15:05:10 Someone(tm) has to properly write down the tribal knowledge into policies what is or can be supported. 15:05:17 +1 15:05:51 duh, I missed the meeting, I still have 4pm local time, and Meetbot didn't ping participants here 15:07:18 I'm happy to continue, in fact we have some more agenda and the backlog holds some good info. 15:07:28 buxy: We are currently at the first topic that involves you... 15:08:52 (BTW: no, I do not know how Canonical generates Supported in Packages) 15:10:13 I looked at some scripts they have, namely ubuntu-security-status 15:10:43 bunk: Is that what you're referring to? 15:10:54 we discussed last time fd-weeks-dispatch. Was it discussed today? If we want to change it for 2022, it should be done ASAP. Who decides it? 15:10:57 No, that is the client side. 15:11:35 gladk: No, this was not (yet?) discussed today. 15:11:49 gladk: I am actually working on it and should have it ready this weekend. The llvm-toolchain-11 and rustc updates that I have been working on took more time than expected and I should have them completed today. 15:13:05 buxy: I think the Documentation for Debian Appliance vendors needs names of one or few people working on it (and a hours budget). 15:13:17 el_cubano: thanks! The problem is what I see not too much people expressed their opinions on that 15:13:42 gladk: Ask in AOB whether there are objections? 15:14:03 For the first run it could be done even manually, but we need an agreement on that 15:14:20 bunk: what is AOB? 15:14:28 Any Other Business 15:14:43 I see. I took the discussion in the last meeting and the follow-up discussion to jeremiah's email to mean that we have a general consensus as captured in the Gitlab issue. 15:14:48 gladk: ^^ 15:15:30 AoB: The part of the meeting where we've gone through our agenda topics and other questions can be brought up. 15:16:14 jeremiah: As far as the documenation issue, what is it that appliance vendors are currenly lacking from us? 15:16:58 Well, I'll quote a bit from the email thread; 15:17:27 "What customers should pay attention to if they want to ensure that our ELTS offer properly address their needs in terms of security support: when they select the software that they are embeddeding in their product, what should they pay attention to?" 15:17:51 Ah OK. I didn't connect this topic with that email discussion. Thanks. 15:18:14 In my experience, commercial support for free software is something that a lot of folks are looking for. 15:19:10 If we had more advice like to those who use Debian in products, it would be a huge help I feel. 15:19:47 In the automotive industry commercial support was a blocker to adoption of Debian, even though Debian fit the software architecture quite well. 15:20:54 So, the documenation would be primarily intended to address the concerns that an integrator might have with regards to certifying compliance to corporate policies or other policies. (Or something along those lines?) 15:21:16 I don't know if it would be as strong as compliance 15:21:32 bunk: I'm happy if ELTS contributors that volunteer to work on this topic spend their regular ELTS hours to address this, and if needed we can grant additionnal hours from the ELTS project funding pool 15:22:08 el_cubano: I think it would be more about how to get the most out of Debian LTS 15:22:08 This seems interesting to me (I have a lot of experience for writing documentation in highly regulated environments). 15:22:24 Is there a Gitlab issue for this yet? 15:22:33 el_cubano: Let me dig it up . . . 15:23:00 My understanding is that what is wanted is documentation (and ideally also tooling) what packages we are able to support in ELTS if there is customer demand. 15:23:07 el_cubano: well, when you design a product that is connected to internet and is supposted to run for X years, you want to make sure that you get the corresponding security support. We are doing our best but we are not making any promise. The documentation intends to help them minimize the risk that they are using something we will not be able to support. 15:23:42 el_cubano: https://salsa.debian.org/freexian-team/extended-lts/website/-/issues/1 15:23:46 And help them make smart choices (for example with CIP for the kernel) 15:23:50 buxy: OK. And the risk is minimized by explaining whet we support, how support it, and so on? 15:25:26 If that information lets you avoid some traps, I'd say yes. We can probably do better than that but it's a start in the right direction. 15:25:40 What would that choice be when a customer is evaluating bullseye today for a product? 15:25:56 jeremiah: I've subscribed to the issue. Once I finish the FD dispatch script I'll take a look at this issue. 15:26:50 IMHO we can document the (few) packages we cannot support (and their many rdeps) 15:27:42 el_cubano: Terrific - there's also a thread on deblts-team@feexian.com with good info. 15:28:40 bunk: That seems like it would be a useful start. 15:28:59 It sounds like the documentation needs at least two sections. One is the "what we are doing today for jessie (and wheezy?)" and the other is "here is how ELTS support works and how packages are included/excluded (so that integrators can plan for so many years down the road what additional investment they might need to make in ELTS to ensure the things important to them remain supported)" 15:29:36 apo: I'll work on ansible security fixes on Friday/Saturday. I was hoping that my DD key gets added first, so I can also fix the current CVEs in unstable before I do it for stable/oldstable/oldoldstable. 15:30:08 petn-randall: ok, great, thanks for your reply! 15:30:52 el_cubano: I think you'll want a section on the kernel as well. 15:31:07 definitely 15:31:22 * el_cubano nods 15:31:39 https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance 15:32:53 Kernel selection might be tricky because vendors often offer support, but it is costly. And often the support is insufficient, so companies switch from vendor support to the LF or support in-house. 15:33:48 This means that choosing a Linux Foundation LTS kernel is non-trivial and then aligning that with Debian LTS in turn can be challenging. 15:34:27 I imagine that advice and documentation on that process would help lots of people. 15:35:21 OK. I see the mentions of the kernel part in the Salsa issue 15:36:25 If I'm not mistaken Ben is also involved in the LF's LTS kernel and CIP project, he may have more info. 15:36:46 He used to be, he no longer is. 15:37:05 Ah. 15:37:43 I have to contact him regarding an outstanding DLA, perhaps I'll ask him for any tribal knowledge he may have. 15:38:10 We're at that point in the meeting where any other business can be taken up. 15:38:22 #topic Any other business 15:38:22 I would be glad if we could find someone to have a try at packaging their SLTS kernel with the usual Debian packaging (.config and patches from the standard Debian kernel) so that we can submit the .config that we want to see suppported from CIP. 15:39:21 jeremiah: You intentionally skipped one of your items? 15:40:01 Not intentionally . . . 15:40:06 * jeremiah reviews agenda 15:40:30 Excuse me - I missed an important topic 15:41:06 #topic enforce the use of Git as the DVCS tool for ELTS packages 15:41:37 I think there's consensus on using git in ELTS packages but perhaps not clear consensus on how we enforce this 15:41:42 Suggestions? 15:42:10 Why? And what git workflow? 15:42:32 I'm worried that this is going to be a hassle especially with large packages (firefox, libreoffice), 15:42:41 I wonder if that could be automated somehow 15:43:04 I'd prefer a simple gbp-import dsc 15:43:08 either by /not/ removing previous uploads, or auto-committing uploaded packages to some repositories 15:43:23 (server-side) 15:43:28 Agreed. In my experience, firefox-esr, thunderbird, libreoffice, and openjdk-* do not lend themselves well to being git-ified with a typical 'gbp import-dsc' invocation 15:43:29 and for large packages just push the debian directories 15:43:52 Hm, so this isn't the default yet? I'm suprised. What packages are not in git currently? 15:44:03 petn-randall: Pretty much all of them 15:44:06 * ta agrees with apo 15:44:19 What do we gain compared to just having the Debian packages as tarballs? 15:44:22 are not in Git, that is (except for some where the maintainer or team has them in Salsa and we know about it) 15:44:55 bunk: we get some history that we are lacking currently 15:45:07 bunk: we don't have history for our ELTS packages right now. There is no way to download previous ELTS versions 15:45:15 like with snapshot.debian.org 15:45:27 Wouldn't it be easier to fix that? 15:45:40 yeah, either that or doing both :) 15:46:02 It's not easier as long as it relies on me only. 15:46:23 If you have only debian/ in git, the upstream sources are archived nowhere. 15:46:45 Is there a way to just keep past uploads (e.g. keep +deb8u2 when uploading +deb8u3) ? That would allow easy revert from clients and maintain history, at some additional storage cost 15:47:28 Or even just have a huge partition where everything source or binary that gets installed into ELTS gets copied. 15:47:32 (I mean easier rollback for clients who experience a regression, I think that was one of the goals) 15:47:39 s/partition/directory/ 15:48:11 Beuc: For that usecase git would not even help... 15:48:49 The only easy way to achieve this would be to create daily snapshots with reprepro but it's not going to scale well IMO. Anything else will requires development and planning and tests. 15:50:01 buxy: What are the usecases? If a usecase involves preserving old binaries, then git does not even help. 15:50:01 buxy: Does the hosting provider of the ELTS archive server provide a block storage with snapshot capability (I'm thinking something like Amazon EBS)? 15:50:44 I'm not opposed to it, but I don't want to do it, I merely want to apply the required changes to the production server. 15:51:22 And ledger says 500 project hours available in ELTS, so budget should be available for a proper solution . 15:51:45 bunk: I didn't start that discussion, it was Neil IIRC and he wanted to get some history about former changes while responding to a customer IIRC. So it's more the "git side" that he was interested in. 15:52:22 This usecase feels like more like dgit than manually updating git trees. 15:53:02 One very simply solution could be to update the archive server to take a debdiff between the incoming package and its predecessor and then store that. 15:53:41 It would then be straightforward to reconstruct the history if needed. Dropping it into a git repo can be done trivially on demand by whomever needs to work with that package 15:53:42 At the same time, using git brings benefits like the CI and gladk is already importing all packages into git when he works on package so it didn't seem out of touch to harmonize the workflow. 15:54:06 there is a discussion about keeping multiple version of a package in reprepro bug #570623 ... maybe it would be enough to only keep the files? 15:55:44 sure, but reprepro is not really maintained wrt to new features, I have a couple of open requests where I offered to pay to get them... 15:55:57 You are getting CI if you are using the Debian maintainer git tree (if it exists) and follow whatever workflow is used there. 15:57:20 I'm sorry but I have to go grab my son, I can't continue the discussion right now. Talk to you later. 15:57:41 buxy: as far as I understood keeping files is already possible but not putting all of them in the index files 15:58:50 jeremiah: Can we discuss the topic broader as "ELTS archive, usecases and solutions" in a future meeting? 15:58:57 Yes 15:59:37 jeremiah: It might also help to kick off a discussion on the mailing list in a week or two, to make the discussion in the meeting go a bit more smoothly 15:59:57 Many of us have been here for two hours - thanks to everyone for the good discussion! 16:00:05 el_cubano: Yes, you're right 16:00:18 FWIW we did this for this month's meeting as well. 16:00:31 Yes. I think it was quite helpful 16:00:58 In general my goal is to have discussions during the month and then have the meeting be a place where we try and hammer out actions. 16:01:06 I put all my work here, with CI, and it works fine 16:01:06 https://salsa.debian.org/lts-team/packages 16:01:19 I think we're getting there, of course there's load of info to coordinate from other teams as well 16:01:29 One more thing: Can we add the meeting time to the channel /topic? 16:01:46 petn-randall: Yes -- good idea 16:01:52 * bunk hopes jeremiah won't get cold turkey 16:01:56 heh 16:02:16 That's what we eat all the rest of the week. :-) 16:02:40 Although el_cubano will be eating venison this year. 16:03:14 If we there is nothing else super urgent I suggest we end for today. 16:03:32 I'll create minutes from the meeting and start some threads about the topics. 16:03:49 thanks! 16:03:55 thanks! 16:03:57 So it's last Thursday 14:00 UTC? 16:04:02 Thanks everyone! 16:04:04 petn-randall: Yes, exactly 16:04:10 thanks, cu around 16:04:11 petn-randall, https://wiki.debian.org/LTS/Meetings 16:04:16 ok, have a nice day everybody 16:04:22 #action create minutes from the meeting and start some threads about the topics 16:05:13 Thanks again everyone. 16:05:19 #endmeeting