18:00:29 <werdahias> #startmeeting 18:00:29 <MeetBot> Meeting started Sat Jan 25 18:00:29 2025 UTC. The chair is werdahias. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:38 <werdahias> #topic rollcall 18:00:52 <capitol> hi :) 18:01:03 <noisycoil[m]1> Hi all! 18:01:08 <ncts[m]> ;) 18:01:10 <PlexSheep> hello, I'm the new guy and just lurking 18:01:27 * werdahias o/ 18:01:44 <noisycoil[m]1> Hi PlexSheep! 18:01:56 <PlexSheep> still fiddling around with hexchat 18:02:27 <federico3> hi there 18:02:38 <PlexSheep> federico3: hello :D 18:02:53 <jbicha> o/ 18:03:09 <werdahias> f_g is excused unfortunately 18:03:43 <werdahias> ok, moving on to toolchain updates then 18:03:55 <werdahias> #topic toolchain updates 18:04:34 <werdahias> thanks to f_gs' work we are current with stable rustc and will likely have 1.85 in trixie 18:04:46 <noisycoil[m]1> \o/ 18:05:23 <capitol> \o/ 18:05:29 <federico3> \o/ 18:05:37 <werdahias> this is great to have a current version in for the freeze 18:05:38 <PlexSheep> very cool: changelogs here https://releases.rs/docs/1.85.0/ as it seems 18:06:12 <werdahias> yes, the main thing is the 2024 edition we'll have then 18:06:49 <werdahias> does anyone want to add anything about rustc ? 18:07:02 <noisycoil[m]1> Since using the new edition should be opt-in no more breakage than usual is expected right? 18:07:25 <federico3> [happy to have rust-analyzer packaged] 18:08:07 <werdahias> noisycoil[m]1: I don't think so, but not the expert here 18:08:11 <PlexSheep> c string literals seem pretty cool 18:08:24 <werdahias> eh yes, no major breakage to be expected 18:08:34 <noisycoil[m]1> Ack 18:08:53 <werdahias> ok, regarding debcargo, I hope we can get debcargo deb-dependencies landed for trixie 18:09:27 <werdahias> this basically allows generating the build-dependencies for programs written in Rust 18:09:42 <werdahias> (sans workspace support for now) 18:10:04 <noisycoil[m]1> Sounds great! 18:10:25 <werdahias> basically debcargo!49 18:10:56 <werdahias> f_g thankfully rebased it and I tested it for a bit, seems ok imo 18:11:21 <werdahias> this will help greatly with packaging rust things that are not crates 18:11:30 <noisycoil[m]1> (Looks like it needs another rebase) 18:11:52 <werdahias> f_gs' work is on another branch 18:12:08 <werdahias> ok, anything to add for toolchains ? 18:12:43 <werdahias> #info trixie will have rustc 1.85 with the 2024 edition 18:12:50 <werdahias> ok, moving on 18:12:55 <federico3> (are there tests for it?) 18:13:07 <werdahias> for what ? 18:13:26 <federico3> deb-dependencies 18:14:08 <werdahias> like parsing cargo.toml and then comparing the output? 18:14:10 <federico3> BTW <spam> if there's interest perhaps in future https://codeberg.org/FedericoCeratto/cargo-debfit could be merged in 18:14:22 <federico3> yes 18:14:37 <werdahias> federico3: not afaik 18:14:48 <werdahias> patches welcome :) 18:15:01 <werdahias> federico3: sounds interesting ! 18:15:10 <federico3> werdahias: let me know when it's rebased I'll add some tests 18:15:16 <werdahias> sure :) 18:15:20 * h01ger waves 18:15:25 <werdahias> o/ 18:15:26 <federico3> hi h01ger 18:15:28 <PlexSheep> o/ 18:15:35 <werdahias> #topic transitions 18:15:51 * h01ger is just generally happy to work together with you folks. it's a fun ride! 18:15:56 <werdahias> thanks to noisycoil[m]1s work we got env-logger 0.11 18:16:01 <werdahias> h01ger: same 18:16:21 <noisycoil[m]1> h01ger (IRC): Yep, same for me 18:16:29 <h01ger> :) 18:16:41 <werdahias> much appreciated, i didn't have the time and energy to see this transition through 18:16:42 <noisycoil[m]1> Regarding transitions, I would like to do three more 18:16:54 <werdahias> bindgen ? 18:17:00 <noisycoil[m]1> No problem werdahias (IRC) :-) 18:17:15 <noisycoil[m]1> Yes, bindgen and procfs are practically ready 18:17:21 <werdahias> nice 18:17:36 <noisycoil[m]1> procfs is waiting for procfs-core in NEW, then we can upload procfs itself to exp 18:17:40 <werdahias> #info env-logger 0..11 is done 18:17:58 <werdahias> #info noisycoil[m]1 will try to do bindgen and procfs 18:18:02 <PlexSheep> Ignore me if this is too of topic, but I'm asking since I'm new: What do you mean with transitions? Just updating crates in debian to higher upstream versions? 18:18:05 <noisycoil[m]1> For bindgen, I wanted your approval before going ahead, since we just went through another transition 18:18:12 <werdahias> PlexSheep: yes 18:18:22 <PlexSheep> werdahias: ok, thanks :) 18:18:31 <werdahias> as we update all rdeps that can be quite involved 18:18:39 <noisycoil[m]1> PlexSheep: Yes, assuming they have a lot of reverse dependencies so they must be updated in block 18:19:10 <noisycoil[m]1> So shall we go ahead with bindgen v0.71 too? 18:19:30 <werdahias> noisycoil[m]1: I have a bit of time mid-februrary but apart from that it'll be ENOTIME from me 18:19:54 <werdahias> sure, it's always good to have the latest before the freeze if possible 18:20:13 <werdahias> #info werdahias prepared zbus 5 in exp with noisycoil[m]1s help 18:20:20 <noisycoil[m]1> Nice 18:20:26 <noisycoil[m]1> There's a third one: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/106 18:20:49 <noisycoil[m]1> I wrote rustix v0.39 since the last one was 0.38, but it will probably be 1.0 18:21:08 <werdahias> does it still get release in time ? 18:21:09 <plugwash> YAY 18:21:26 <noisycoil[m]1> The reason why it's important for trixie is they update linux to v6.12, which will be trixie's stable kernel 18:21:29 <weepingclown[m][m]> ah meeting.. 18:21:35 <werdahias> ah, I see 18:21:43 <ncts[m]> fwiw, the (core libraries of the) http transition is mostly done 18:21:48 <noisycoil[m]1> werdahias (IRC): From the looks of it rustix 1.0 may be days away 18:21:54 <werdahias> well if it's doable in time for trixie I don't see why not 18:22:04 <werdahias> noisycoil[m]1: nice 18:22:21 <werdahias> #info noisycoil[m]1 works on rustix 1.0 18:22:30 <ncts[m]> should be reasonable to expect rdeps to up to reqwest 0.12, etc. 18:22:44 <ncts[m]> before freeze 18:22:47 <werdahias> #info werdahias will do a mini-cxx update (not semver breaking) 18:23:12 <werdahias> #info ncts[m] will work on the http stack 18:23:21 <werdahias> ncts[m]: nice 18:23:54 <werdahias> ok, any more transition-related things we should discuss ? 18:25:14 <werdahias> ok, then I'd move on to misc 18:25:25 <werdahias> #topic misc 18:25:30 <plugwash> note: some of the http stack stuff is producing autopkgtest regressions related to h2 at the momement which I expect will go away once we get the new h2 into testing. 18:26:04 <werdahias> that's just britney being confused, right ? 18:27:23 <plugwash> well the underlying issue is that h2 in testing is patched to use http 0.2, which means stuff expecting it to use http 1 won't build against it. 18:28:14 <werdahias> I see. Let's hope this will resolve itself with the transition 18:28:19 <jbicha> I replied on the list that I think we have a problem for things that haven't been rebuilt since debcargo switched to dh compat 13. 18:28:43 <jbicha> I think ideally we would build a list of those and rebuild those before Soft Freeze 18:29:06 <plugwash> jbicha, btw can you get trust-dns-* removed from ubuntu, it was removed from debian recently and it's blocking stuff migrating out of proposed 18:29:24 <werdahias> so quering UDD and then asking the release team ? sounds good to me 18:29:37 <h01ger> the release team is quite happy to do binNMUs as needed and requested IME 18:30:05 <jbicha> I don't think binnmus would work. I think it needs to be sourceful uploads to get the updated debian/control with the updated debhelper-compat 18:30:11 <werdahias> though that could be as much as 1000 packages 18:30:45 <noisycoil[m]1> That's easily scriptable though 18:31:07 <werdahias> if all those still build, yes 18:31:15 <noisycoil[m]1> Yes, of course 18:31:47 <werdahias> anyone experienced with UDD queries that wants to generate a list ? 18:31:50 <jbicha> plugwash: yes, Colin or another Ubuntu Archive Admin have a script that helps remove packages in Ubuntu that were removed in Debian 18:32:41 <plugwash> in previous releases I've just used older versions of debcargo as needed and/or prepared uploads manually when updating stuff in later phases of the freeze 18:32:44 <werdahias> basically select from * where maintainer is debian rust team and dh = 12 18:33:53 * plugwash is not convinced the churn of re-uploading everything is worth the effort it will save us later. 18:34:44 <noisycoil[m]1> jbicha (IRC): What problem are you foreseeing? 18:34:46 * h01ger is with plugwash here 18:34:48 <jbicha> maybe script it to run like 50 or 100 a day, to not overwhelm the buildds 18:35:19 <jbicha> just that the Debian Release Team would prefer dh compat levels not changing later in the Freeze, but maybe we want to still upload some of those packages 18:35:20 <h01ger> i'd also suugest to do local test builds first.. 18:35:35 <h01ger> #uug#ugg# :) 18:35:42 <noisycoil[m]1> jbicha (IRC): Ack 18:37:13 <werdahias> why is changing the compat levels during the freeze an issue ? 18:37:39 <jbicha> it's specifically mentioned at https://release.debian.org/testing/freeze_policy.html 18:37:44 <werdahias> it had no issues so far for rust* crates 18:38:07 <jbicha> I agree that 12 to 13 seems very minimal. Maybe debhelper was more exciting earlier in its history 18:38:08 <h01ger> werdahias: basically because its a freeze and targeted changes are wanted 18:38:12 <werdahias> ah 18:38:18 <plugwash> jbicha, there shouldn't be a massive number of changes during the late freeze anyway and it's not that big a deal to prep an upload manually or install an older version of debcargo if there is a critical fix. 18:38:39 <h01ger> one can migate this a bit by doing two builds with different dh levels and using diffoscope to show the diff is as one wants it 18:39:04 <werdahias> like we can track crates that haven't been switched, but I would assume that's a lot 18:40:46 <werdahias> # info werdahias will look into an UDD query to get the list of dh 12 crates 18:40:50 <werdahias> eh 18:41:21 <werdahias> #action werdahias will look into an UDD query for dh 12 crates 18:41:45 <werdahias> ok, I would like to talk about sbuild in build.sh 18:41:59 <plugwash> is anyone here in discussion with Jonas about rustls? 18:42:27 <plugwash> e.g. whether he plans to do it for trixie and if so whether he plans to do a big bang or a semver suffix 18:42:58 <plugwash> (lots of potential interaction with the http transition) 18:42:58 <werdahias> iirc he wanted to do semver thing but no idea what the current state is 18:43:19 <werdahias> s7semver7a semver 18:45:05 <werdahias> ok, given that sbuild is now using unshare as default on the buildds and by itself I propose we switch to it, too 18:45:38 <werdahias> !776 18:45:38 <BTS> werdahias: Error: "776" is not a valid command. 18:45:46 <noisycoil[m]1> I've never used unshare, but given the switch I'd argue we should, yeah 18:46:26 <jbicha> unshare has been working pretty well for me on Ubuntu 25.04. Simplifies setup a lot. 18:46:29 <werdahias> unshare has the benefit that it's rootless, and if you have tmpfs set up the whole build can run in the RAM 18:47:28 <noisycoil[m]1> Yep 18:47:29 <jbicha> I hesitated switching because I was afraid it would be slower than my tuned schroot but it seems fast by default 18:48:09 <werdahias> any opinions on this ? ime this is faster, and in line with the default; also no-one is actively working on the schroot backend iirc 18:48:31 <noisycoil[m]1> sgtm 18:49:26 <federico3> why using tempfs it there's eatmydata? 18:50:00 <werdahias> federico3: because if /tmp is a tmpfs that's way faster 18:50:07 <werdahias> iirc 18:50:48 <werdahias> people can still use schroot if they like 18:52:10 <federico3> I also use unshare, +1 to it 18:52:16 <werdahias> another misc topic: I would like to see improved workspace support, but this is not that relevant 18:53:08 <noisycoil[m]1> Me too but it should be a medium-term goal probably 18:54:07 <werdahias> Great :) anything else to add for the misc topic ? 18:54:09 <noisycoil[m]1> I.e. unlikely to be implemented before the trixie freeze? 18:54:13 * h01ger is also in favor of the switch 18:54:14 <werdahias> yes 18:54:48 <noisycoil[m]1> Neighboring workspace support, the book should be extended to include non dc-c stuff 18:55:29 <noisycoil[m]1> I think definitive documentation on non dc-c stuff can only be written after workspace support settles down though 18:55:39 <werdahias> well it already does, right ? but I agree we should improve things 18:55:48 <werdahias> +docs 18:56:01 <noisycoil[m]1> Already does what? 18:56:34 <werdahias> the book mentions packaging of non-crates, i.e. GUIs for instance 18:57:31 <noisycoil[m]1> werdahias (IRC): https://rust-team.pages.debian.net/book/process-workspace.html ? 18:58:28 <ncts[m]> I kinda published a draft on that 18:58:35 <ncts[m]> definitely needs working 18:58:48 <noisycoil[m]1> Blair Noctis: Is that the one at the link? 18:58:55 <ncts[m]> yeah 18:59:04 <noisycoil[m]1> I hadn't noticed it 18:59:23 <werdahias> also: https://wiki.debian.org/Gnome/Rust_Packaging for packaging rust things with the wrapper 18:59:34 <noisycoil[m]1> I see some things are missing (saying this as an observation, no blame implied at all), such as the prepare step 18:59:38 <werdahias> maybe I should add thi 18:59:43 <werdahias> at to the book 19:00:00 <noisycoil[m]1> werdahias (IRC): That would be great 19:00:24 <noisycoil[m]1> Ah and someone mentioned they would like documentation on debcargo itself 19:00:30 <werdahias> #action werdahias adds wrapper to the book 19:00:36 <noisycoil[m]1> As a standalone tool 19:01:07 <werdahias> ah, it doesn't have a man page 19:01:27 <federico3> (anybody interested in having tarpaulin for code coverage?) 19:01:49 <noisycoil[m]1> werdahias (IRC): Yes, nor docs on crates.io IIRC 19:02:40 <werdahias> noisycoil[m]1: want to file an issue with debcargo ? for starters, you can generate a man page with help2man 19:03:07 <noisycoil[m]1> Better still use (properly) clap_mangen 19:03:11 <noisycoil[m]1> I will 19:04:03 <werdahias> great :) 19:04:21 <werdahias> #action noisycoil[m]1will look into getting debcargo a manpage 19:04:48 <werdahias> ok, anything else before we close this meet ? 19:05:57 <werdahias> #endmeeting