17:59:30 #startmeeting 17:59:30 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:44 #topic roll call, collecting 18:00:11 werdahias johfel capitol present - I guess ncts and kpcyrd will also join us soon? ;) 18:00:48 * ncts opens eyes 18:01:27 I guess we have a few status updates from last time 18:01:38 next meeting organization 18:01:51 ongoing transitions/blockage 18:02:09 I'd maybe also add a small point regarding Jonas' recent ITPs to the agenda 18:02:21 o.O 18:02:34 hi! 18:02:40 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 (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 ack - I don't think we are missing anybody that said to be around? let's proceed then :) 18:04:38 #topic status updates 18:05:02 #info rustc upload happened 18:05:45 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 #action f_g ping Sylvestre about rustc 1.67 upload 18:06:14 #action f_g review 1.68 update which is prepared already as well 18:07:00 #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 great! and welcome! :) is there anything you are blocked on where team members could help? 18:08:29 As far as I have seen, there is nothing yet, but in case I will write to the channel. Thanks! 18:08:37 #info kpcyrd has prepared dependencies for the repro-env package/crate and is looking for feedback/sponsoring 18:09:36 I hope I'm doing this right, I haven't been around in the previous meetings 18:09:40 werdahias: you had a few items as well - release.sh/dput improvements, dh compat in debcargo, and wayland transition? 18:09:53 #info capitol is working on packaging more of the sequoia crates, and cargo-auditable 18:10:10 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 #info werdahias has uploaded gtk-rs 0.5, syn transition went fine, wayland trasition went fine 18:11:01 #action werdahias remove wayland-* 0.29 when all rdeps have switched to 0.30 18:11:16 #info ncts has aes transition (dc-c !45) mostly done 18:11:38 f_g: didn't have time for the rest yet, should have now 18:12:09 f_g: I take it 1.67 can be considered done? (at least for the first upload) 18:12:16 #info cargo-debstatus and gping made it into the archive 18:12:20 #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 ncts: yes, it just needs the uploads (wasi-libc to exp, rustc to bin-NEW experimental) 18:13:00 and then once it is accepted and built, re-uploads to unstable 18:13:20 #info debcargo integration tests are half-way fixed, see corresponding MR on salsa 18:13:50 #info debcargo update to cargo 0.70 (and related deps) is also pretty much done, modulo review by ximin 18:14:38 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 else I will rebase/pickup at the end of August 18:14:57 #info kpcyrd is interested in updating toml to 0.7, but we might need a toml-0.5 transitional package 18:15:15 kpcyrd: we have a toml-0.5 18:15:38 oh nice! 18:15:40 https://tracker.debian.org/pkg/rust-toml-0.5 18:15:43 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 either of you want to feel responsible for tracking rdep updates and removal once the transition is finished? ;) 18:16:26 ok can do 18:16:28 kpcyrd: my cargo branch should have everything, at least for the version listed there 18:16:46 #action kpcyrd keep track of toml-0.5 -> 0.7 transition 18:16:48 I doubt the transition will end anytime soon, too many deps on 0.5 18:17:07 #action kpcyrd update toml to 0.7 18:17:20 ncts: the most important part is to finish it before trixie gets frozen ;) 18:18:07 lib.rs/crates/toml/rev gives 425 on 0.7, 473 on 0.5 18:18:28 #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 #info kpcyrd is looking for an upload of tokio-socks so we can enable the socks feature in reqwest 18:18:52 anything else open w.r.t. last time? 18:19:35 not sure if relevant, my DD application is progessing slowly but surely 18:19:50 so I can sponsor stuff soon (tm) 18:20:10 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 #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 #action capitol will try to handle https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038381#16 18:22:30 great :) 18:22:33 #action werdahias will try to fix the diesel mess 18:23:21 #action ncts is on the way to package sqlx 18:23:39 these two are the go-to crates for sql 18:23:42 should we proceed to the next topic? transitions, packaging efforts and blockers? ;) 18:24:23 * werdahias has nothing to add 18:25:32 #topic transitions / packaging efforts / blockers 18:25:53 we already heard a few, some more from the back log - env_logger (werdahias)? 18:26:33 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 haven't looked into it yet. I ran /list-rdeps, I'll have to see if that needs patching or semvering 18:27:18 f_g: they use a very large number of crates unfortunately, I'm not sure why 18:27:38 I'm preparing gtk 0.6 atm, then I'll deal with the rest 18:27:53 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 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 #action werdahias look into env-logger update 18:30:43 anything else that's currently going that might warrant the teams attention? 18:31:33 hashbrown 0.12 -> 0.14 maybe 18:32:38 mhm 18:32:46 that's probably hashbrown+indexmap, right? 18:32:58 I'd even go further to one binary package for the gix swarm 18:33:13 #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 f_g: yes 18:33:56 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 hm with hashbrown I'm not sure how to port this, with toml I'm positive I can manage 18:34:59 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 would need to check it out* 18:35:34 yeah I mean one binary for the libs. forgot it has a binary 18:36:01 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 otoh, the binary should now be provided by the gitoxide crate 18:36:19 f_g: ok, I can try that 18:37:10 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 are you interested in evaluating packaging it? 18:37:44 yeah, just a thought 18:37:48 #action kpcyrd take a stab at hashbrown/indexmap transition 18:38:02 mayyyyyyybe 18:38:33 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 anything else for this part? 18:39:43 #action ncts tries to package gix-* as single src: 18:40:43 #topic ITPs / non-team-packages 18:41:12 since there was again some collision (signature/signature-derive) with jonas, it would be great to make some progress here 18:41:28 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 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 as long as its opt-out via an env variable, that should be doable 18:42:31 I though of using w3m to check wnpp.debian.net 18:42:32 I also wonder whether we want to add special dummy entries in debcargo-conf/src for non-team crates 18:42:50 werdahias: there is wnpp-check 18:42:51 the integration would be constrained by b.d.o processing tho 18:42:52 would appreciate ideas/help/test 18:43:03 ah 18:43:09 TIL 18:43:22 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 true 18:43:34 as long as there is a FIXME in the changelog the scripts will refuse uploading anyway 18:43:44 that would make things easier 18:43:52 #action werdahias will show us the script ;) 18:44:31 #info ncts has aes transition (dc-c !45) mostly done <-- aes is done isn't it? 18:44:43 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 it just needs to be known to update.sh I guess in some fashion 18:45:08 plugwash: I'm not sure ;) goals I listed in !45 were done, but I'm afraid something would break 18:45:14 wrt dummy entries, maybe add a no-list for new/update.sh 18:45:17 my thought process: query apt cache -> wnpp -> then file a new one 18:46:02 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 there was some practice of adding non-toml text in debcargo.toml, but it's both troublesome and cumbersome 18:46:48 f_g: I will try to make time for it, will post updates here 18:46:52 great 18:47:01 maybe I can do it at cccamp :) 18:47:16 it does sound like a nice hackathon project :) 18:47:55 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 I actually tried to write a no-list thingy a while ago, maybe I can pick that up 18:48:04 or you :) 18:48:22 * werdahias will focus on the itp thingy 18:48:38 #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 this ad-hoc build system grows even further 18:48:54 also: can I interface with reportbug directly ? 18:49:13 werdahias: you could either create just the email, or call 'bts' with the right parameters 18:49:28 hm, thanks 18:49:33 * werdahias takes notes 18:49:44 werdahias: it's python, so if you write the thingy in python you can even import it 18:49:44 well, bts is for querying, reportbug is for filing 18:50:16 ncts: I wrote it in shell, not really fluent in python 18:50:32 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 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 k, thanks 18:51:22 but that can be iterated upon, or even extended later if people want different levels of assistance 18:51:35 #link https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L806 debian BTS details for ITP 18:51:41 #topic next meeting 18:51:41 I even though of temporary wgeting the crate and extracting the metadata 18:51:48 reportbug should provide enough options for everyone's email setup in its gui. 18:52:07 *thought 18:52:12 werdahias: if you integrate it with update.sh, the metadata should already be there ;) 18:52:19 debcargo has enough metadata that it might be able to gain a command to spit out an ITP template 18:52:30 ah, indeed 18:52:30 dh-make-golang does something similar 18:52:34 wrt metadata, debcargo already does that, data is at $HOME/.cargo/registry 18:52:58 jamessan: that's true, but adapting things in debcargo has a higher bar w.r.t. stability IMHO. 18:53:47 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 Keep going :) I just had a couple minutes and read through the backlog. wanted to mention that before I forgot 18:54:45 but yeah, maybe once the ITP flow has settled, we could think about just integrating it into `debcargo package` itself 18:54:54 (I use thunderbird to send and reply to d.b.o, weirdest here I reckon) 18:55:04 haha. there's always someone ;) 18:55:15 * werdahias got some pointers, will post updates 18:55:17 dh-make-golang does something similar -- spitting out a template as part of generating the packaging for a new package 18:55:39 I've a question about the "stability" of debcargo, maybe save for after meeting 18:56:05 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 jamessan: I though about that: generating a $crate-itp.txt and then (optionally) passing that to reportbug 18:56:23 any takers? or are there too little people around anyway cause of holidays etc.? 18:57:02 fairly confident I'm the least "holiday filled" :P 18:57:31 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 seems a nice summer off 18:58:42 ncts: do you want to try to organize another round? or should we skip? :) 18:59:10 I'm ok with organizing, but there won't be many here based on replies 18:59:37 ack. then let's do the next one in september 18:59:48 #action next meeting in September, orga TBD 19:00:04 #topic anything else 19:00:25 does anybody want to add something that didn't fit the previous topics? else I'd close this meeting :) 19:00:51 notmuch ™ 19:01:27 * werdahias has nothing to add :) 19:01:41 does the ITP autobot thing mean we are going to file for lib crates too? 19:02:04 as far as I understood, yeah 19:02:12 if it's streamlined enough, I'd say yes 19:02:18 less toe-stepping in either direction 19:02:34 ha great, definitely love flooding debian-devel :P 19:03:13 #endmeeting