16:00:08 <werdahias> #startmeeting
16:00:08 <MeetBot> Meeting started Sun Jun 30 16:00:08 2024 UTC.  The chair is werdahias. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:50 <weepingclown[m]1> o/
16:01:16 <siretart> \o
16:01:17 <federico3> are we doing the meeting only here then?
16:01:22 <werdahias> #topic rollcall
16:01:30 * maytham lurks
16:01:32 <werdahias> yes
16:01:48 * efraim lurks
16:01:55 * siretart waves into the round, excited for my first rust team meeting :-)
16:02:00 * weepingclown[m]1 waves again
16:02:03 <ncts[m]> yes, since some are worried about logging
16:03:06 <werdahias> imo we can discuss that $later, but  today I'd keep it as-is
16:03:35 <weepingclown[m]1> do we have an agenda or is it going to be ad-hoc?
16:03:40 <werdahias> ad-hoc
16:03:53 <werdahias> #topic status updates
16:04:24 <werdahias> #info thanks to the amazing work of f_g rustc is current with the stable release upstream
16:04:42 <weepingclown[m]1> https://lists.debian.org/debian-rust/2024/06/msg00018.html - update from f_g
16:05:10 <werdahias> yes
16:05:24 <ncts[m]> (should add the from header to the message, it seems)
16:05:39 <werdahias> #info event-listener 5.x transition underway in experimental
16:06:01 <werdahias> #info zbus transition to 4.x starting in experimental
16:06:26 <werdahias> #info f_g would appericate help wrt debcargo triaging
16:06:50 <weepingclown[m]1> I think async-lock transition is also underway in experimental? I might be wrong
16:07:19 <werdahias> weepingclown[m]1: entangled with event-listener
16:07:42 <weepingclown[m]1> it is, but is has enough rdeps of its own :p
16:08:20 <werdahias> #info eventlistener almost done, werdahias would appreciate some help with sluice
16:08:50 <ncts[m]> maytham mentioned a http transition, which fg seconds
16:09:03 <maytham> yup
16:09:23 <werdahias> #action maytham and f_g look into http
16:09:55 <ncts[m]> I have a smaller scale transition for zip ##65
16:10:03 <weepingclown[m]1> anything more related to transitions?
16:10:47 <werdahias> #action ncts looks at zip
16:11:17 <ncts[m]> there were a nix by you and a clap v3 phase out by plugwash
16:11:29 <werdahias> ah
16:11:42 <ncts[m]> but I'm just scraping salsa issues :P
16:11:54 <werdahias> #info nix transition to 0.27 happened, thanks to plugwash
16:12:15 <siretart> I think https://salsa.debian.org/rust-team/debcargo-conf/-/issues/61 can be closed now, both rust-nix as well as rust-laurel reached testing, not sure what's left to do. Big kudos to plugwash and everyone who helped!
16:12:36 <werdahias> #info ncts and me removed rust-instant and patched rdeps
16:14:21 <werdahias> ok, I'd move to packaging efforts / blockers then unless there is anything related to transitions ?
16:14:53 <werdahias> ok, moving on
16:15:01 <werdahias> #topic packaging efforts / blockers
16:15:58 * weepingclown[m]1 hopes more active sponsoring from rust team DDs since rust team has its very specific workflow and it is hard to bring in others
16:16:28 <werdahias> I can 100% relate
16:16:42 <ncts[m]> now that you are yourself a DD :P
16:17:12 <werdahias> maybe we need to improve the sponsor process somehow ?
16:17:28 <weepingclown[m]1> uploads are one thing, reviews are very rare as well
16:17:56 <federico3> yes, e.g. have a sponsor roster and ping people specifically - otherwise sponsors should read the channel all day :)
16:18:00 <weepingclown[m]1> I get that not everyone might be interested, but know that we have nowhere else to go
16:18:49 <werdahias> weepingclown[m]1: agreed. reviews can take a lot of time, too
16:18:58 <ncts[m]> there is a RFS mechanism, and dev/list-rfs.sh, but that's not very helpful without documentation
16:19:17 <werdahias> #action werdahias
16:19:20 <werdahias> whoops
16:19:40 <werdahias> #action werdahias tries to work on the RFS pile in August
16:19:54 <ncts[m]> a (better) documentation for (outside) sponsors, perhaps?
16:20:12 <werdahias> ncts[m]: do you want to work on that ?
16:20:41 <weepingclown[m]1> we also have race conditions for RFS in MR going unreviewed and then other pushing directly, resulting in wasted time and effort from at least one person
16:20:44 <ncts[m]> I'm not sure if I qualify ;) but to try it, sure can I
16:20:52 <siretart> so, as a DD who participates in the rust team, but hasn't been doing too much sponsorships, I'd like to bringup two pain points for me as (potential) sponsor: a) the process and tools, such as dev/list-rfs.sh could use better documentation. b) the things that are being asked to sponsor often would benefit from more context to why they need to be sponsored, so that I as a DD can prioritze better what to look at next
16:21:01 <weepingclown[m]1> does having a place to mark what everyone is working on help?
16:21:21 <siretart> for instance, if I know that a package upgrade is needed for a particular package/goal, then I can make better decisions on what to focus on
16:21:22 <federico3> +1 to what siretart wrote
16:21:25 <werdahias> ncts[m]: Can the issueboards do that ?
16:21:42 <ncts[m]> siretart: for b), sometimes the RFS file has that info, but unfortunately sometimes not
16:22:17 <ncts[m]> it's largely due to an unclear packaging process, probably
16:22:18 <werdahias> having a place where everyone documents their work would be good imo
16:22:18 <weepingclown[m]1> siretart: src/$package/debian/RFS typically has some info on what the dependency is for
16:22:22 <siretart> indeed. and even if it has, it is too easy to overlook for me as a sponsor without it being used consistently
16:22:25 <weepingclown[m]1> but yes, agreeing with you
16:22:42 <ncts[m]> werdahias: IIRC we talked about that, and tried something with the labels, but that largely got abandoned
16:22:50 <weepingclown[m]1> so I believe everyone agrees on improving the docs
16:23:01 <weepingclown[m]1> we can have that as an action and everyone can contribute
16:23:03 <werdahias> hm, I use the lables for issue tracking
16:23:29 <siretart> May I suggest to have those RFS files refer to ITP bugs of software (or in case they are needed for new upstream versions of something else, those bugs), so that I as (potential) sponsor can get that context?
16:23:30 <werdahias> #action everyone improve the docs
16:23:55 <werdahias> siretart: valid point
16:23:55 <federico3> improving the docs or making the tooling more helpful/intuitive so that the tools guide you
16:23:58 <ncts[m]> now we have quite some sources of truth: salsa issues, bugs, ad-hoc notes in dc-c source, and the wiki could potentially be used
16:24:10 <siretart> issues in salsa would work as well, I'm harping on debbugs because the salsa issues seem quite rust specific to me, and I'm active in other teams as well
16:24:17 <weepingclown[m]1> siretart: rust team only files ITP for packages involving binaries, but in such cases it's good
16:24:51 <werdahias> back then we discussed filing ITPs for all crates but we never reached a consensus
16:25:00 <weepingclown[m]1> that as well
16:25:09 <siretart> yeah, I'm not suggesting or even advocating to file ITPs for every rust source package. Those that package software with binary crates benefit from those ITPs much more
16:25:14 <werdahias> I kinda did that for some but not thouroughly
16:25:23 <weepingclown[m]1> the caveat is hundreds of ITP, but everyone does that
16:25:48 <werdahias> the main argument was preventing duplicated work
16:26:14 <weepingclown[m]1> that still happens thanks to the race condition I mentioned
16:26:25 <werdahias> like I'm fine either way; I wrote a draft for an ITP shell script
16:26:31 <weepingclown[m]1> so a board where everyone can document their work would be nice
16:26:32 <ncts[m]> so we need a single source of truth
16:27:23 <federico3> we might never achieve a single source of truth - a good starting point would be have a diagram of what the SoT are and what race conditions exist
16:27:41 <siretart> the nice thing about ITP bugs is that you can a) capture a conversation why it is needed and b) you can put them in relationship with other packages, such as "this ITP blocks moving foo to a newer version". As a (potential) sponsor, that is really helpful information for prioritizing how to spend my time best
16:28:35 <werdahias> #1 for ITPs; though that would need automation
16:28:40 <werdahias> eh +1
16:29:00 <federico3> it feels like it's once again a tooling issue
16:29:15 <ncts[m]> bts could use some modernization lol
16:29:21 <weepingclown[m]1> another possibility is that, perhaps we can setup specific pages for huge ongoing works going on
16:29:24 <siretart> I think it's both. The best tools are of no use if they are not used (consistently)
16:29:27 <ncts[m]> a UI/UX problem
16:29:42 <werdahias> well you can use ./update.sh 's functionality and pass that to reportbug
16:30:06 <werdahias> like "foo is a NEW crate, file ITP ?"
16:30:17 <federico3> werdahias: of course
16:30:19 <weepingclown[m]1> which brings us to a tooling question we have discussed before
16:30:34 <weepingclown[m]1> that we should have one tool instead of hundred shell scripts
16:30:57 <siretart> then you end up with something like git? ;-)
16:30:59 <federico3> +1, and I've started implementing build.sh in Python
16:31:02 <werdahias> but those shell scripts do different things
16:31:20 <ncts[m]> it's largely a UI problem, IMO
16:31:41 <ncts[m]> a bunch of shell scripts is bad at discoverability, unless you write some really good docs
16:31:43 <weepingclown[m]1> werdahias: that's what subcommands are for aren't they?
16:31:53 <weepingclown[m]1> foo create creates and foo update updates]
16:32:13 <werdahias> fair point
16:32:27 <ncts[m]> or just expose them as subcommands like that
16:32:37 <werdahias> weepingclown[m]1: , ncts[m] do you want to look into that ?
16:32:54 <ncts[m]> it doesn't really matter if it's written in shell or python or rust, like siretart said no one cares what podman was written in
16:32:56 <federico3> that's a minor aspect as long as there's a unified frontend
16:32:56 <weepingclown[m]1> werdahias: I believe federico already started the effort
16:33:02 <weepingclown[m]1> definitely happy to help
16:33:05 <werdahias> ah
16:33:09 <ncts[m]> weepingclown: yeah I started, kind of
16:33:16 <federico3> yep
16:33:22 <ncts[m]> can join forces with federico I suppose
16:33:26 <werdahias> #action federico3 ncts[m] weepingclown[m]1 look into improving the tooling
16:33:27 <weepingclown[m]1> yes ncts as well
16:33:28 <federico3> sure
16:33:37 <werdahias> thanks :)
16:34:32 <werdahias> ok, anything else we want to discuss under blockers before we move to misc ?
16:34:58 <ncts[m]> nothing here
16:35:07 <werdahias> ok, moving on then
16:35:19 <werdahias> #topic miscellaneous
16:35:55 <weepingclown[m]1> any rust team activities for debconf24?
16:36:03 * weepingclown[m]1 will be down for it
16:36:17 * werdahias does not have the time to attend, sadly
16:36:30 <weepingclown[m]1> we can also do remote ;p
16:37:15 * ncts[m] is trying but probably couldn't get the visa
16:37:56 * siretart won't make it in person, the timing is very inconvenient. I might be able to participate remotely in some limited capacity
16:38:40 <weepingclown[m]1> :(
16:38:52 <weepingclown[m]1> do we have any specific plans regarding trixie?
16:39:17 <werdahias> #info I wrote a draft for a cdylibs wiki page
16:39:23 <ncts[m]> other than keeping up with upstream rustc?
16:39:28 <werdahias> weepingclown[m]1: not really
16:39:51 <werdahias> I hope to unbreak rust-gtk4, but that needs src:gtk4 4.14
16:40:18 <weepingclown[m]1> we should also come up with some real backportability
16:40:32 <siretart> what's our story for security updates? How do we track what needs to be rebuilt when we update some library crate, in particular when the binary is not in our team?
16:40:51 <werdahias> good question
16:41:09 <maytham> Static-Built-Using?
16:41:18 <werdahias> +1 for small, targeted backports
16:41:58 <werdahias> #action discuss backports at next meet
16:42:09 <werdahias> #action werdahias
16:42:13 <werdahias> eh
16:42:30 <werdahias> #action werdahias organize next meet
16:42:36 <siretart> maytham (IRC): okay, that's a nice field. Do we have some documented process on what tools to use that use that field for that purpose?
16:42:58 <werdahias> siretart:  no, maytham wrote a policy addition
16:43:04 <maytham> debcargo already uses it afaik
16:43:13 <werdahias> that reminds me, now I can second it
16:43:19 <siretart> I think that's tracked in #1069256
16:43:22 <weepingclown[m]1> I came across a case with regards to Static-Built-Using which kept failing and I could not move forward at all because there was, well, no docs
16:43:29 <weepingclown[m]1> in the end I hacked around it
16:43:37 <weepingclown[m]1> but that's not the nicer way
16:43:49 <ncts[m]> it still amuses me that Built-Using is for license purpose, and we need a new field for programmatic use
16:44:17 <werdahias> afaik no binary rust packages not packaged by us (i.e gtk apps) emit that field
16:44:46 <ncts[m]> fwiw https://wiki.debian.org/Static-Built-Using
16:45:07 <maytham> I can look into filing bugs/patches for packages outside of the team w/out this field
16:45:31 <weepingclown[m]1> ncts[m]: yes but that says barely anything
16:45:38 <werdahias> maytham: would be much appreciated
16:46:43 <ncts[m]> weepingclown: yeah but everything has a start ;)
16:47:26 <weepingclown[m]1> also fwiw, I think our documentations should move away from salsa READMEs to wiki.d.o
16:47:51 <weepingclown[m]1> which will also make organizing our docs smoother
16:47:55 <federico3> +1
16:49:09 <ncts[m]> away from READMEs yes, wiki, don't really fancy that :/
16:49:22 <jamessan> It's nice having everything in the repo, IMO
16:49:40 <ncts[m]> uh but never mind, it's the best we have before someone invests in a doc building setup
16:49:43 <weepingclown[m]1> well, we don't need to remove them from the repo
16:50:06 <werdahias> ok
16:50:08 <weepingclown[m]1> but wiki is the first place people look at, usually
16:50:09 <siretart> I think having the wiki page point to the README in salsa would be a great start
16:50:29 <weepingclown[m]1> that works as the bare minimum
16:50:49 * werdahias is reminded that the wiki does not use mediawiki :(
16:51:27 <weepingclown[m]1> or we can buiild our own site to host the repos and make the wiki point to that, which should not be all that huge an effort
16:51:35 <weepingclown[m]1> but it is not the priority
16:51:59 <weepingclown[m]1> https://go-team.pages.debian.net/ is a good example
16:52:10 <werdahias> ok, I'd end the meeting then unless there is anything else you want to discuss ?
16:52:11 <ncts[m]> we have cargo doc, remember?
16:52:20 <ncts[m]> yes yes! team logos! :P
16:52:29 <weepingclown[m]1> yaay!
16:52:30 <werdahias> ah :)
16:52:45 * maytham thinks about bumping debcargo to Standards-Version: 4.7.0
16:52:47 <weepingclown[m]1> and one t shirt with the logo for every member, but ofc
16:52:53 <werdahias> ncts[m]:  that last image looked pretty good imo
16:52:53 <weepingclown[m]1> :P
16:52:59 <werdahias> lol
16:52:59 <federico3> building docs from the salsa repo using CI and publishing it on "pages" should be easy
16:53:21 <weepingclown[m]1> maytham: thanks, that was in my agenda but forgot!!
16:53:30 <werdahias> Does anyone object a having a team logo ?
16:53:38 <ncts[m]> as said yesterday (or today?), I had a word with an artist, and they sent that draft (wait where's the link)
16:53:44 <weepingclown[m]1> bumping standards version to 4.7.0 as well as bumping dh-compat version
16:54:09 <werdahias> please keep it at one topic at a time
16:54:33 <werdahias> #info ncts[m] looked into having a team logo
16:54:33 <ncts[m]> sure, go ahead with yours, the logo can be the last
16:54:36 <weepingclown[m]1> yeah sorry, but I had to say it before forgetting again
16:54:40 <weepingclown[m]1> we can discuss later
16:55:18 <weepingclown[m]1> ncts[m]: we should go in order, I guess
16:55:25 <weepingclown[m]1> the logo you showed last time was nice
16:55:44 <federico3> can you show it again please?
16:55:53 <ncts[m]> here you go https://0x0.st/XaiB.webp
16:57:08 <werdahias> minor critique: maybe move the cog a bit to the left + down so it doesn't overlay the debian logo
16:57:46 <siretart> love the idea. Looks "rusty" :-)
16:58:02 <ncts[m]> sure, will pass on to the artist ;)
16:58:04 <werdahias> :D
16:58:55 <werdahias> #action ncts[m] will work on logo, maybe vote on it in the next meet ?
16:59:17 <werdahias> #info policy /dh-compat bump
16:59:23 <federico3> if we have at least some alternatives
17:00:07 <werdahias> federico3: do you want to do like an offical contest ?
17:00:29 <weepingclown[m]1> I am not sure if there is any blockers with regarding to just bumping the versions outright
17:00:43 <weepingclown[m]1> like, do we need to write extra checks in any of the scripts?
17:00:57 <werdahias> weepingclown[m]1:  S-V is "easy"
17:01:02 <ncts[m]> there's definitely the upgrade checklist https://www.debian.org/doc/debian-policy/upgrading-checklist.html
17:01:15 <federico3> werdahias: well, without alternatives what would people be voting on? :)
17:01:21 <werdahias> fair
17:01:32 <weepingclown[m]1> there is checklist but I am not sure how it works when the tooling does it
17:01:35 <mjt> yes or no :)
17:02:13 <werdahias> for compat: basicially all crates with custom d/control files will need an upload first
17:02:21 <werdahias> then my MR can be merged
17:02:57 <werdahias> that's the gist basically
17:02:59 <jamessan> Why does there need to be specific ordering?
17:03:12 <jamessan> They already have a custom control which can be updated whenever
17:03:19 <werdahias> to test if anything breaks
17:03:34 <jamessan> Ah, for compat
17:03:40 <jamessan> I thought you were talking about S-V
17:03:47 <jamessan> Sorry :)
17:03:47 <werdahias> and the MR needs to be included in a debcargo release
17:03:52 <werdahias> yeah
17:04:03 <jamessan> Yeah, we've been waiting on a debcargo release for Static-Built-Using, too
17:04:40 <werdahias> #action werdahias will upload all custom crates with control files in august for dh-compat bump
17:05:05 <weepingclown[m]1> awesome :)
17:05:25 <weepingclown[m]1> I believe most of them are just stripping the number of provides
17:05:49 <werdahias> anyone can do a MR for the S-V bump; should be straightforward
17:06:28 <werdahias> ok, anything else ?
17:06:58 <ncts[m]> I should probably start a vote after the meeting ;P
17:07:12 <federico3> yes: the ideas around new tooling are being collected at  https://pad.riseup.net/p/DebianRustNewToolingIdeas-keep and it could make sense to schedule a discussion for this maybe in a week
17:07:20 <werdahias> ok
17:07:36 <werdahias> I'll write a mail to the list too
17:07:42 <werdahias> #endmeeting