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