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