17:59:30 <f_g> #startmeeting
17:59:30 <MeetBot> Meeting started Sun Jul 30 17:59:30 2023 UTC.  The chair is f_g. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:44 <f_g> #topic roll call, collecting
18:00:11 <f_g> werdahias johfel capitol present - I guess ncts and kpcyrd will also join us soon? ;)
18:00:48 * ncts opens eyes
18:01:27 <f_g> I guess we have a few status updates from last time
18:01:38 <f_g> next meeting organization
18:01:51 <f_g> ongoing transitions/blockage
18:02:09 <f_g> I'd maybe also add a small point regarding Jonas' recent ITPs to the agenda
18:02:21 <werdahias> o.O
18:02:34 <kpcyrd> hi!
18:02:40 <f_g> anything else? :)
18:02:43 * f_g waves
18:02:57 * werdahias is fine with the tops
18:03:04 * capitol too
18:03:31 * johfel too
18:03:37 <f_g> (I also have to admit I'd like to keep it shortish today if possible ;))
18:03:54 * werdahias doesn't mind that :)
18:04:10 * ncts +1
18:04:28 <f_g> ack - I don't think we are missing anybody that said to be around? let's proceed then :)
18:04:38 <f_g> #topic status updates
18:05:02 <f_g> #info rustc upload happened
18:05:45 <f_g> we need a DD to upload the next one (wasi-libc and rustc are both prepared in git on salsa). ximin is travelling this week, so maybe Sylvestre could do the honors?
18:05:59 <f_g> #action f_g ping Sylvestre about rustc 1.67 upload
18:06:14 <f_g> #action f_g review 1.68 update which is prepared already as well
18:07:00 <johfel> #info Johann Felix is mainly working on packaging gitui. Most dependencies could already be uploaded, especially ratatui (a tui-rs fork) that might be helpful also for other packages. In case of spare time, he might help with e.g. sponsoring.
18:07:36 <f_g> great! and welcome! :) is there anything you are blocked on where team members could help?
18:08:29 <johfel> As far as I have seen, there is nothing yet, but in case I will write to the channel. Thanks!
18:08:37 <kpcyrd> #info kpcyrd has prepared dependencies for the repro-env package/crate and is looking for feedback/sponsoring
18:09:36 <kpcyrd> I hope I'm doing this right, I haven't been around in the previous meetings
18:09:40 <f_g> werdahias: you had a few items as well - release.sh/dput improvements, dh compat in debcargo, and wayland transition?
18:09:53 <capitol> #info capitol is working on packaging more of the sequoia crates, and cargo-auditable
18:10:10 <f_g> kpcyrd: yes, basically there are a few prefix commands/tags to make stuff show up more prominently in the logs - see https://wiki.debian.org/MeetBot
18:10:19 <werdahias> #info werdahias has uploaded gtk-rs 0.5, syn transition went fine, wayland trasition went fine
18:11:01 <werdahias> #action werdahias remove wayland-* 0.29 when all rdeps have switched to 0.30
18:11:16 <ncts> #info ncts has aes transition (dc-c !45) mostly done
18:11:38 <werdahias> f_g: didn't have time for the rest yet, should have now
18:12:09 <ncts> f_g: I take it 1.67 can be considered done? (at least for the first upload)
18:12:16 <werdahias> #info cargo-debstatus and gping made it into the archive
18:12:20 <f_g> #info cargo update is a bit stalled as I lack time - most (all?) NEW things should be uploaded, the rest is updating a lot of crates.
18:12:37 <f_g> ncts: yes, it just needs the uploads (wasi-libc to exp, rustc to bin-NEW experimental)
18:13:00 <f_g> and then once it is accepted and built, re-uploads to unstable
18:13:20 <f_g> #info debcargo integration tests are half-way fixed, see corresponding MR on salsa
18:13:50 <f_g> #info debcargo update to cargo 0.70 (and related deps) is also pretty much done, modulo review by ximin
18:14:38 <f_g> I won't be able to finish either this week before being away for three weeks, but *if* somebody wants to jump in and continue driving that, I am not opposed ;) some of the transitive deps of cargo got more updates in the meantime, so the info in the tracking issue might not be 100% up to date
18:14:52 <f_g> else I will rebase/pickup at the end of August
18:14:57 <kpcyrd> #info kpcyrd is interested in updating toml to 0.7, but we might need a toml-0.5 transitional package
18:15:15 <ncts> kpcyrd: we have a toml-0.5
18:15:38 <kpcyrd> oh nice!
18:15:40 <ncts> https://tracker.debian.org/pkg/rust-toml-0.5
18:15:43 <f_g> there was consensus that it seems reasonable, and it got uploaded and accepted in the meantime :)
18:16:05 * kpcyrd tries to check what's missing for 0.7
18:16:05 <f_g> either of you want to feel responsible for tracking rdep updates and removal once the transition is finished? ;)
18:16:26 <kpcyrd> ok can do
18:16:28 <f_g> kpcyrd: my cargo branch should have everything, at least for the version listed there
18:16:46 <f_g> #action kpcyrd keep track of toml-0.5 -> 0.7 transition
18:16:48 <ncts> I doubt the transition will end anytime soon, too many deps on 0.5
18:17:07 <f_g> #action kpcyrd update toml to 0.7
18:17:20 <f_g> ncts: the most important part is to finish it before trixie gets frozen ;)
18:18:07 <ncts> lib.rs/crates/toml/rev gives 425 on 0.7, 473 on 0.5
18:18:28 <f_g> #info ximin and me discussed a potential handover of debcargo and agreed on a way forward - I will see which "bigger" feature(s) I'll pick as "handover" assignment ;)
18:18:40 <kpcyrd> #info kpcyrd is looking for an upload of tokio-socks so we can enable the socks feature in reqwest
18:18:52 <f_g> anything else open w.r.t. last time?
18:19:35 <werdahias> not sure if relevant, my DD application is progessing slowly but surely
18:19:50 <werdahias> so I can sponsor stuff soon (tm)
18:20:10 <plugwash__> Someone who cares about sequoia needs to decide what to do about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038381#16, i've outlined the possibilities but I don't feel like deciding on which way to go.
18:20:15 <ncts> #info ncts asks for reviews and changes to https://salsa.debian.org/ncts/reports/-/blob/main/2023-07-rust-team-packaging-practices.adoc
18:20:50 * werdahias should take a look at the diesel mess now that I got more free time
18:22:07 <capitol> #action capitol will try to handle https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038381#16
18:22:30 <f_g> great :)
18:22:33 <werdahias> #action werdahias will try to fix the diesel mess
18:23:21 <ncts> #action ncts is on the way to package sqlx
18:23:39 <ncts> these two are the go-to crates for sql
18:23:42 <f_g> should we proceed to the next topic? transitions, packaging efforts and blockers? ;)
18:24:23 * werdahias has nothing to add
18:25:32 <f_g> #topic transitions / packaging efforts / blockers
18:25:53 <f_g> we already heard a few, some more from the back log - env_logger (werdahias)?
18:26:33 <f_g> another big packaging effort that will come up in the next months would be gitoxide for cargo - that one is rather tricky though
18:26:59 <werdahias> haven't looked into it yet. I ran /list-rdeps, I'll have to see if that needs patching or semvering
18:27:18 <kpcyrd> f_g: they use a very large number of crates unfortunately, I'm not sure why
18:27:38 <werdahias> I'm preparing gtk 0.6 atm, then I'll deal with the rest
18:27:53 <f_g> kpcyrd: yes, we've discussed it a bit already. if they weren't clearly planning on also versioning them separately down the line, I would be inclined to package them manually as a single source package..
18:28:54 <f_g> werdahias: AFAICT the only breaking change is renaming of features (env_logger), so this one should be do-able without introducing another version. but there sure are a lot of rdeps, so it will need a DD to upload them in one go I guess
18:29:37 <werdahias> #action werdahias look into env-logger update
18:30:43 <f_g> anything else that's currently going that might warrant the teams attention?
18:31:33 <kpcyrd> hashbrown 0.12 -> 0.14 maybe
18:32:38 <f_g> mhm
18:32:46 <f_g> that's probably hashbrown+indexmap, right?
18:32:58 <ncts> I'd even go further to one binary package for the gix swarm
18:33:13 <kpcyrd> #info dirs crate has been updated to 5.0.1, about to transition to testing in a few days (waiting for `webbrowser` crate)
18:33:19 <kpcyrd> f_g: yes
18:33:56 <f_g> do you want to take care of that? (again, ideally also with periodic checks what is still needed on the tail end to get rid of the old version ;))
18:34:35 <kpcyrd> hm with hashbrown I'm not sure how to port this, with toml I'm positive I can manage
18:34:59 <f_g> ncts: somebody would check it out more closely. I guess it could even be two binary packages - one for the lib(s), one for the binaries. lots of manualy work in all cases though, no matter which approach is taken
18:35:05 <f_g> would need to check it out*
18:35:34 <ncts> yeah I mean one binary for the libs. forgot it has a binary
18:36:01 <f_g> kpcyrd: you mean for submitting upgrade PRs upstream? if it's too complicated/involved, just asking them and pinging down the line before evaluating removal in Debian is also fine..
18:36:12 <ncts> otoh, the binary should now be provided by the gitoxide crate
18:36:19 <kpcyrd> f_g: ok, I can try that
18:37:10 <f_g> ncts: there's more than one, but I guess putting them into gitoxide-bin for now and seeing where it goes is an option. or even just shipping the lib for now for cargo, and ignoring the rest until somebody requests it ;)
18:37:32 <f_g> are you interested in evaluating packaging it?
18:37:44 <ncts> yeah, just a thought
18:37:48 <f_g> #action kpcyrd take a stab at hashbrown/indexmap transition
18:38:02 <ncts> mayyyyyyybe
18:38:33 <f_g> ncts: there's not much time pressure anyway, if we just update cargo to 0.70 as next step that's already a leap forward anyhow, and then the next upgrade will take a few months again for sure
18:38:59 <f_g> anything else for this part?
18:39:43 <ncts> #action ncts tries to package gix-* as single src:
18:40:43 <f_g> #topic ITPs / non-team-packages
18:41:12 <f_g> since there was again some collision (signature/signature-derive) with jonas, it would be great to make some progress here
18:41:28 <f_g> at the last meeting there was the idea of some sort of ITP script - I guess this could even be integrated into update/new.sh
18:41:52 <f_g> so that it generates an ITP template for submission, and adds a FIXME for the bug number to the changelog
18:41:52 * werdahias has cobbeled some basic shell script for that together, but not finished
18:42:10 <f_g> as long as its opt-out via an env variable, that should be doable
18:42:31 <werdahias> I though of using w3m to check wnpp.debian.net
18:42:32 <f_g> I also wonder whether we want to add special dummy entries in debcargo-conf/src for non-team crates
18:42:50 <f_g> werdahias: there is wnpp-check
18:42:51 <ncts> the integration would be constrained by b.d.o processing tho
18:42:52 <werdahias> would appreciate ideas/help/test
18:43:03 <werdahias> ah
18:43:09 <werdahias> TIL
18:43:22 <f_g> ncts: yes, you need to wait for the bug number, but that can be done as a follow-up before uploading as well
18:43:29 <ncts> true
18:43:34 <f_g> as long as there is a FIXME in the changelog the scripts will refuse uploading anyway
18:43:44 <werdahias> that would make things easier
18:43:52 <f_g> #action werdahias will show us the script ;)
18:44:31 <plugwash__> <ncts> #info ncts has aes transition (dc-c !45) mostly done <-- aes is done isn't it?
18:44:43 <f_g> what do you think about placeholders? it could also be a file with the crate names, essentially something that stops us from starting packaging work if it already exists outside of debcargo-conf
18:44:58 <f_g> it just needs to be known to update.sh I guess in some fashion
18:45:08 <ncts> plugwash: I'm not sure ;) goals I listed in !45 were done, but I'm afraid something would break
18:45:14 <ncts> wrt dummy entries, maybe add a no-list for new/update.sh
18:45:17 <werdahias> my thought process: query apt cache -> wnpp -> then file a new one
18:46:02 <f_g> werdahias: that does sound sensible (guarded by it being the intial creation in debcargo-conf, and with some way to skip it via env)
18:46:25 <ncts> there was some practice of adding non-toml text in debcargo.toml, but it's both troublesome and cumbersome
18:46:48 <werdahias> f_g: I will try to make time for it, will post updates here
18:46:52 <f_g> great
18:47:01 <werdahias> maybe I can do it at cccamp :)
18:47:16 <f_g> it does sound like a nice hackathon project :)
18:47:55 <f_g> maybe you could think about the placeholder issue as well and propose some kind of variant of that as second change, the two are quite related
18:47:58 <ncts> I actually tried to write a no-list thingy a while ago, maybe I can pick that up
18:48:04 <f_g> or you :)
18:48:22 * werdahias will focus on the itp thingy
18:48:38 <f_g> #action ncts implement proposal for block list of crates not to be packaged in debcargo-conf (e.g., because already package somewhere else)
18:48:51 <ncts> this ad-hoc build system grows even further
18:48:54 <werdahias> also: can I interface with reportbug directly ?
18:49:13 <f_g> werdahias: you could either create just the email, or call 'bts' with the right parameters
18:49:28 <werdahias> hm, thanks
18:49:33 * werdahias takes notes
18:49:44 <ncts> werdahias: it's python, so if you write the thingy in python you can even import it
18:49:44 <f_g> well, bts is for querying, reportbug is for filing
18:50:16 <werdahias> ncts: I wrote it in shell, not really fluent in python
18:50:32 <f_g> for me, just pre-generating the reportbug commandline and/or email template would be enough, but I guess it depends how you use email whether that works for everyone :)
18:50:49 <ncts> I can help with that, but anyway, here's the ITP template https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L806
18:50:56 <werdahias> k, thanks
18:51:22 <f_g> but that can be iterated upon, or even extended later if people want different levels of assistance
18:51:35 <f_g> #link https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L806 debian BTS details for ITP
18:51:41 <f_g> #topic next meeting
18:51:41 <werdahias> I even though of temporary wgeting the crate and extracting the metadata
18:51:48 <johfel> reportbug should provide enough options for everyone's email setup in its gui.
18:52:07 <werdahias> *thought
18:52:12 <f_g> werdahias: if you integrate it with update.sh, the metadata should already be there ;)
18:52:19 <jamessan> debcargo has enough metadata that it might be able to gain a command to spit out an ITP template
18:52:30 <werdahias> ah, indeed
18:52:30 <jamessan> dh-make-golang does something similar
18:52:34 <ncts> wrt metadata, debcargo already does that, data is at $HOME/.cargo/registry
18:52:58 <f_g> jamessan: that's true, but adapting things in debcargo has a higher bar w.r.t. stability IMHO.
18:53:47 <f_g> should we go back to that topic, or continue with the next meeting (and punt this discussion to a tracking issue/MR ;))
18:54:20 <jamessan> Keep going :) I just had a couple minutes and read through the backlog.  wanted to mention that before I forgot
18:54:45 <f_g> but yeah, maybe once the ITP flow has settled, we could think about just integrating it into `debcargo package` itself
18:54:54 <ncts> (I use thunderbird to send and reply to d.b.o, weirdest here I reckon)
18:55:04 <f_g> haha. there's always someone ;)
18:55:15 * werdahias got some pointers, will post updates
18:55:17 <jamessan> dh-make-golang does something similar -- spitting out a template as part of generating the packaging for a new package
18:55:39 <ncts> I've a question about the "stability" of debcargo, maybe save for after meeting
18:56:05 <f_g> like I said - I won't be around most of August, so if we want another meeting before September, somebody else would need to organize and facilitate it (not that I did such a good job about the first part so far ;))
18:56:14 <werdahias> jamessan: I though about that: generating a $crate-itp.txt and then (optionally) passing that to reportbug
18:56:23 <f_g> any takers? or are there too little people around anyway cause of holidays etc.?
18:57:02 <ncts> fairly confident I'm the least "holiday filled" :P
18:57:31 <f_g> or maybe, somebody just wants to try, and if too little people agree on a date, we try again in September?
18:57:39 * capitol will also be away
18:57:41 * werdahias +1
18:57:53 <ncts> seems a nice summer off
18:58:42 <f_g> ncts: do you want to try to organize another round? or should we skip? :)
18:59:10 <ncts> I'm ok with organizing, but there won't be many here based on replies
18:59:37 <f_g> ack. then let's do the next one in september
18:59:48 <f_g> #action next meeting in September, orga TBD
19:00:04 <f_g> #topic anything else
19:00:25 <f_g> does anybody want to add something that didn't fit the previous topics? else I'd close this meeting :)
19:00:51 <ncts> notmuch ™
19:01:27 * werdahias has nothing to add :)
19:01:41 <ncts> does the ITP autobot thing mean we are going to file for lib crates too?
19:02:04 <werdahias> as far as I understood, yeah
19:02:12 <f_g> if it's streamlined enough, I'd say yes
19:02:18 <f_g> less toe-stepping in either direction
19:02:34 <ncts> ha great, definitely love flooding debian-devel :P
19:03:13 <f_g> #endmeeting