18:00:56 <werdahias> #startmeeting 18:00:56 <MeetBot> Meeting started Sat Nov 9 18:00:56 2024 UTC. The chair is werdahias. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:56 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:07 <werdahias> #topic rollcall 18:01:15 * werdahias is here 18:01:28 <weepingclown> o/ 18:02:38 <f_g> \o 18:03:50 <werdahias> well, moving on for now 18:04:12 <werdahias> #topic toolchain updates 18:04:48 <werdahias> f_g: want to explain a bit what you worked on ? 18:05:13 <f_g> yep 18:05:34 <f_g> unstable/trixie are on the latest stable atm, debcargo and librust-cargo are still one behind, though I hope to catch up there tomorrow 18:05:54 <werdahias> \o/ 18:05:59 <f_g> the cdylib support stuff stalled a bit, though I hope to pick that up again as well 18:06:36 <f_g> the next version of debcargo will improve handling of quilt patches that need to be rebased, and allow arch-restricting autopkgtest 18:06:44 <weepingclown> great work with keeping the toolchain uptodate as always, thaks for all your hardwork :) 18:06:53 <weepingclown> s/thaks/thanks/ 18:07:05 <f_g> other than that, the biggest question is which version will end up in trixie when it gets frozen - but the ball is in RT's court, so to speak :) 18:07:33 * capitol reporing in 18:07:56 <f_g> I am not sure whether implementing the declarative trimming features that we want to see is feasible in time for the freeze, but we'll see - it mainly depends on how much spare cycles I find for that I guess, unless somebody else does most of the work :-P 18:08:02 <werdahias> great, also really appreciate the work. Anything else ? 18:08:09 <f_g> I think that's it :) 18:08:24 <werdahias> great :) 18:08:37 <werdahias> #topic transitions 18:09:28 <werdahias> plugwash did nix 0.29, thanks fot that 18:09:38 * f_g only has the cargo 0.83 one, and that's fairly small and basically done, just missing cutting the Debcargo release 18:09:55 <werdahias> s/fot/for 18:10:12 <weepingclown> there's image, http (which one idr) and lazy-regex in work, iirc ? 18:10:18 <weepingclown> and bindgen I suppose 18:10:36 <werdahias> I did a mini-heapless 0.7 -> 0.8 (done) and image 0.24>0.25 18:10:42 <werdahias> yes 18:10:46 <noisycoil> lazy-regex is almost ready, 10/13 packages can already be uploaded, the other 3 are blocked by packages in NEW 18:11:10 <weepingclown> great 18:11:55 <noisycoil> As for bindgen, I took care of 9 packages. Not sure I checked them off in the tracking issue though 18:11:58 <werdahias> bindgen is just a lot of work checking all rdeps; I uploaded noisycoils' work to exp for now 18:12:43 <noisycoil> Nope, I did not apparently. 18:12:46 <werdahias> noisycoil: Jonas also has some packages that require coordination, make sure to check those 18:13:49 <werdahias> env-logger 0.11 is also available in exp; I would appreciate help though since that has a ton of rdeps 18:14:36 <werdahias> bindgen and env-logger would be great to get in so trixie ships with those 18:15:11 <werdahias> anything else ? 18:16:09 <werdahias> moving on then 18:16:20 <werdahias> #topic misc 18:17:23 <weepingclown> the number of DDs in the team, as well as the sponsorship, has gone up a lot which is great 18:17:25 <werdahias> ncts[m] brought up those topics: team book, logo and patch style but they are not here so I would move this to the next meet 18:17:34 <werdahias> weepingclown: yeah 18:18:08 <werdahias> I have two items: MIA uploaders and semver tracking 18:18:22 <f_g> I'd also add meeting schedule to the agenda ;) 18:18:28 <werdahias> ah 18:18:32 <werdahias> indeed 18:18:48 <werdahias> let's do that one first then 18:19:19 <weepingclown> right, we should make some proper decisions regarding that 18:19:53 <werdahias> do we want a fixed date ? i.e. 3rd of month at $day 18:20:20 <weepingclown> that'd be better than the back and forth we are having each time 18:20:39 <weepingclown> since what we currently have isn't working out all that well anyway 18:21:09 <weepingclown> once there is a fixed date, at least people can have some plans 18:21:23 <f_g> I'd propose the following procedure: first a poll for 1 week regarding frequency - once a month, every two months, every 6 weeks (the last would align with rustc release schedule ;)) 18:21:59 <f_g> then a poll for a second week, depending on the outcome, with two alternating slots (time and weekday wise) chosen from the results 18:22:21 <f_g> unless we find a single slot where everybody can attend anyway ;) 18:23:09 <f_g> if nobody else wants to, I can do the polls :-P 18:23:23 <werdahias> f_g: SGTM 18:23:34 <weepingclown> +1 18:24:15 <weepingclown> werdahias: I suppose we could move on to your topics then 18:24:33 <werdahias> #action agree on meet frequency 18:24:47 <werdahias> #action agree on meet slots 18:25:19 <werdahias> I guess me and f_g will do the polls 18:25:28 <capitol> that sounds good to me 18:26:04 <werdahias> ok, moving on (unless someone objects ?) 18:26:08 <capitol> I don't have time to commit to do more admin stuff right now, maybe things will calm down after christmas for me 18:26:51 <werdahias> capitol: sure, thanks for taking care of the RFS pile :) 18:26:59 <capitol> :) 18:27:28 <werdahias> ok, MIA uploaders 18:27:59 <werdahias> as you all know we have a lot of crates where the uploaders are not present anymore 18:28:35 <werdahias> this causes issues insofar as said crates only get updated when they part of a transition 18:29:29 <werdahias> I would like to propose we reach out to all MIA uploaders by mail and then track all crates where they are listed as first step 18:30:14 <capitol> this sounds lika a graph problem, if we can color everything that doesn't touch the dep-tree of a binary, and is more than X months old 18:31:50 <werdahias> capitol: that is also a good idea; however this doesn't account for a crate that has been team-uploaded before but the actual uploader is not active in debian anymore 18:31:59 <an3as> Sorry, I'm late 18:32:10 * werdahias waves 18:32:10 <an3as> Is the meeting finished? 18:32:15 <capitol> I don't have a big problem with having some random libraries packaged also, but it might cause extra work if there is security problems published for those 18:32:28 <capitol> an3as: welcome, we are in the middle of it :) 18:32:39 <werdahias> an3as: just discussing the misc: topics 18:32:40 <an3as> Great. I'm just lurking and learning 18:32:56 <werdahias> capitol: yeah 18:33:22 <capitol> werdahias: what problem with MIA uploaders do you want to solve? Try to get them active again? 18:33:46 <weepingclown> it gets quite complicated when there are tons of packages who don't really have active uploaders anyway and is rotting away 18:34:01 <werdahias> well it's crates that in theory are team maintained but in fact there is no active maintainer 18:34:08 <f_g> I think writing a mail to see if they are still active, and then deciding on whether we still need those crates would be the way to go 18:34:18 <capitol> +1 18:34:21 <werdahias> yeah 18:34:31 <f_g> anything that isn't part of the dep tree of an executable needs someone to step up, else it gets an RC bug filed followed by removal after a period of inactivity 18:34:37 <weepingclown> identifying such packages and removing the unused/low popcorn/no rdeps ones amongst them might do good 18:35:03 <f_g> a crate that is packaged but not linked into any executable is only worth keeping around if it's to enable a future executable being packaged, IMHO 18:35:10 <weepingclown> f.g: yes, precisely 18:35:11 <werdahias> yes 18:35:33 <werdahias> ties into my next topic, removal of semver crates 18:35:36 <f_g> so the main question is - who does the initial email? :-P 18:36:10 * weepingclown ducks 18:36:14 <werdahias> I can do it if someone can point me to a way to grep those crates with no rdeps 18:36:18 <noisycoil> weepingclown: what you say would help filtering out MIA uploaders too, if done beforehand. No need to contact them if the package needs to be removed anyway 18:37:24 <weepingclown> werdahias: which is another problem. Do we really have a way to list rdeps other than our *slow* script? 18:37:47 <an3as> In Bug of the Day we use some UDD query: https://salsa.debian.org/tille/tiny_qa_tools/-/blob/master/botd/get-random-bug?ref_type=heads 18:38:02 <weepingclown> I think I have checked with apt rdepends and reverse-depends before which doesn't work iirc 18:38:03 <an3as> You might adapt it bit for your purpose. 18:38:09 <werdahias> weepingclown: for transitions I used codesearch.debian.net since I believe it's more reliable 18:38:24 <an3as> No maintainer upload >5 years is a good start for orphaned packages. 18:38:51 <capitol> f_g: linked into a binary, or used in the tests somehw 18:39:00 <an3as> Same for old Standards-Version 18:39:09 <f_g> capitol: yes, good point! 18:39:21 <weepingclown> noisycoil: you shouldn't exactly arbitrarily remove a package that's not entirely buggy without the maintainer ack tbh, so a mail would still be better 18:39:39 <werdahias> an3as: that gets updated dynamically by debcargo, but good point 18:40:06 <an3as> I guess debcargo is only updating Git, isn't it? 18:40:10 <f_g> yeah, also without a mail you won't find out if it's still needed for something wip 18:40:17 <an3as> UDD is featuring what is really uploaded. 18:41:21 <an3as> I agree with the email approach and using a 21 day waiting period like per ITS procedure might be a sensible time span 18:41:28 <noisycoil> weepingclown: ordinary packages, yes. packaged rust source code not so much probably. but yeah, there may still be reasons for wanting to have it around 18:42:41 <capitol> is this something we want to do before the freeze? 18:42:48 <f_g> it might make sense to also have some record for NEW things *why* it was packaged in the first place (to avoid the guesswork when we next do a cleanup like this ;)) 18:42:52 <capitol> or maybe as a part of it 18:42:54 <weepingclown> I'd still say the same, because there is no reason to remove a perfectly ok package maintained by someone. Unless it gets too buggy or the uplpader themselved gives ack that it's nerdrf anymore. 18:42:56 <f_g> capitol: doesn't have to be before, during is fine as well 18:43:03 <weepingclown> capitol: better if we could do that 18:43:14 <capitol> :) 18:43:15 <f_g> anything that leaves testing can't be reintroduced after some point of the freeze 18:43:21 <weepingclown> ah yes, actually removals could happen anytime 18:43:30 <weepingclown> I was thinking pre-trixie :p 18:44:22 <f_g> so any volunteers for collecting a list of uploaders with no activity for longer than $THRESHOLD and writing a mail to them? 18:44:34 <werdahias> well the release dates are not announced yet anyway 18:45:07 <f_g> yeah, I see this mostly as team housekeeping, it has the benefit of also removing cruft from trixie before its release if we don't take too long doing it 18:45:11 <werdahias> I can write a mail if someone helps me with the query 18:45:42 <weepingclown> Would like to help, but quite busy unfortunately. I plan to help with such things after I could find some breathing space. 18:46:20 <weepingclown> ergo, after zellij work is done probably 18:47:09 <werdahias> I mean this takes care of my next topic too: removing unneeded semver packages and tracking those 18:47:35 <werdahias> like clap-3; actively working to reduce the amount we have 18:47:43 <weepingclown> werdahias: could you give some examples? 18:47:53 <werdahias> clap3 :) 18:47:57 <weepingclown> I am not sure which packages you are referring to 18:48:07 <weepingclown> ah yes :p 18:49:07 <werdahias> #action werdahias looks into an SQL query for outdated packages 18:49:45 <f_g> werdahias: the debcargo release after this will also change how semver packages express their relationship to non-semver packages 18:50:03 <f_g> I will probably re-upload all existing semver packages with a no-change bump after that 18:50:08 <f_g> before the freeze 18:50:16 <f_g> so getting rid of unneeded ones before that would be great ;) 18:50:25 <f_g> debcargo!72 has the details 18:50:43 <werdahias> fixing the provides: syn for instance ? 18:51:18 <werdahias> saw that MR 18:51:49 <weepingclown> f_g: the output in the MR looks clean to me :) 18:51:52 <weepingclown> nice 18:52:19 <werdahias> ok, anything else related to cleaning up outdated / old packages ? 18:53:23 <weepingclown> can't say anything other than it'll be good without having some expertise on the subject :p 18:53:35 <werdahias> does anyone have any additional topic they want to discuss ? 18:54:34 <werdahias> if that's not the case then I would end the meet 18:55:13 <weepingclown> looks like you're good to go 18:55:16 <werdahias> #endmeeting