18:58:56 #startmeeting 18:58:56 Meeting started Sun Jun 18 18:58:56 2023 UTC. The chair is f_g. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:58:56 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:37 #topic meeting agenda 19:00:08 maybe let's start by doing a roll call and a 1 sentence intro why you are here today/what you are doing in the team (or want to be doing ;)) 19:01:26 sounds good :) 19:01:39 hah, we didn't have a sign-up 19:02:35 #info Fabian, mostly working on toolchain stuff and associated crate packaging (rustc, cargo, debcargo) 19:03:01 #info James, mainly working on alacritty and tree-sitter related crates, but try to help out with things in general and sponsor when I have free cycles. 19:04:09 #info Blair, at the beginning general stuff that I found useful, now starting on the toolchain 19:04:15 (if you prefix lines with #info, they will show up later in the meeting summary, instead of just the logs. there are similar other commands for noting todos and decisions) 19:04:24 #info Matthias, mainly working on the gtk-rs stack and dependencies for GTK rust apps 19:04:44 (https://wiki.debian.org/MeetBot in case you've never been in one of these :)) 19:07:20 any additions to the agenda proposed in the announcement mail? (https://lists.debian.org/debian-rust/2023/06/msg00001.html) 19:07:52 besides the transitions count_omega already replied with (I'd say we handle transitions as one single topic, unless there is some bigger issue with one in particular) 19:08:27 Looks good 19:08:53 that covers most I know of 19:09:03 +1 19:09:13 ack, then let's proceed :) 19:09:21 #topic rust toolchain updates 19:09:41 #info rustc 1.64-1.66 are in experimental 19:09:57 #info 1.64 is prepared for unstable, but not yet uploaded 19:10:18 #action mjt Sylvestre should figure out who does the upload 19:10:33 #action f_g will monitor the situation and prepare the next uploads 19:10:44 #info 1.67 is up for review (thanks ncts!) 19:11:07 #info upstream is already at 1.70, so there are three more versions to update/review/upload 19:11:50 there is one issue with the current workflow with regards to the patches that I'd like to improve, to reduce the diff for reviewing 19:12:21 #action f_g look at gbp pq or other tools for managing the patch queue(s) to have a single, unified format that works for everyone 19:12:39 ncts: will you look at the next upstream versions once 1.67 is reviewed and progress on uploads has been made? 19:13:10 my latest 1.68 build log doesn't look very bad, albeit generated in april 19:13:54 in general I have the feeling that updating itself worked well over the past few months despite Ximin and Sylvestre being completely and mostly out of the picture, the main bottle neck is DD capacity for uploading to bin-NEW 19:14:28 #action ncts will prepare 1.68 update once 1.67 has been reviewed 19:15:39 the "toolchain" already in place seems like an easy enough routine, but speaking of that, I imagine we can have something similar to x.py upstream 19:16:42 for patch handling? or unifying the various other helper scripts for pruning and checking? or for starting the Debianized build? :) 19:17:12 unify patch handling and other helpers into a single Debianized build script I guess 19:18:16 maybe we can open an issue and collect ideas there? and decouple it from the ongoing updates? 19:18:30 there is for sure some potential for deduplication in the helper scripts :) 19:18:50 #action f_g ncts brainstorm improvements for rustc packaging helpers 19:19:24 with cargo the situation is a bit different - we are at 0.66 (== rustc 1.65), and mostly stayed there because of the freeze 19:20:02 I will try to find the time to update in the near future (with cargo we can thankfully skip versions most of the time), mainly for the sparse registry feature 19:20:13 unless there is somebody else that wants to drive that? 19:21:01 in any case it does require a DD to be around for uploading, as there are usually double digits crates that require updating 19:22:56 I've not been involved in that before, but I could give it a shot 19:23:11 ack :) 19:23:40 #action f_g jamessan do a walkthrough of src:cargo updating 19:24:18 we could split it up into cargo and debcargo updating if you want? they usually (have to) happen in lockstep, but the actual work is fairly independent 19:25:15 anything else on the non-debcargo toolchain side? 19:25:17 We need someone to publish debcargo in order to update that, right? 19:25:35 yeah, that is its on separate topic :) 19:25:56 I can contribute on the cargo side, somewhat 19:26:55 #action ncts also offers help for cargo update work 19:27:19 Sylvestre might use some help on llvm, but that's a whole different thing 19:28:01 yeah, that's another team entirely :) although I am sure they can also use more people ;) 19:28:11 maybe let's proceed with debcargo maintainership? 19:28:43 ack 19:28:52 #topic debcargo maintainership 19:29:41 the main issue here is likely who can cut releases, as that is currently Josh Triplett (not active in Debian anymore AFAICT) and Ximin (currently on vacation, and in general, their involvement has decreased over the last 2 years) 19:31:02 afaik, I have permission to merge to the repo. The issue is more on the crates.io side, I believe 19:31:15 exactly, that's what I meant with "cut a release" 19:31:39 most (all?) of the Rust team has push rights on the repo IIRC, it's publishing an "official" version of the crate that is limited 19:31:42 You have to be added on crates.io as maintainer to release iirc 19:31:54 and our packaging in turn is based on what's published on crates.io 19:32:16 obviously we can work around that for urgent issues and just patch, but that is not a good work flow for whole features or big deltas 19:32:38 maybe we can ask ximin to grant someone from the team access 19:32:51 you should ask infinity0 for upload right IMO 19:33:02 for being the most familiar with it 19:33:26 IMHO the way forward would be exactly that - at least 1-2 people from the team should be granted publish rights, and we should have some sort of decision making for what goes in other than regular cargo and dep version updating and clear bug fixes 19:33:51 e.g., if we continue to have these meetings, anything that might be controversial could be agreed upon here first before being implemented 19:34:17 agreed. 19:34:51 speaking of, I'd like to finish off the rust-version MR 19:34:53 #action ask infinity0 to give two team members access 19:34:59 otoh, debcargo is used almost exclusively by DRT 19:35:15 jamessan: it's on my TODO list :) 19:36:06 it's more or less an "debian internal package" that happens to have to be pulled from crates.io because our setup is centered around that 19:37:25 yes, so IMHO it makes sense to reduce the scope of the "ownership" on crates.io to make it more of an implementation detail of the "cut a release" procedure, and less of a "these are the people that have to ack and implement any bigger changes" 19:37:48 I mean, it's not a bad thing to have it published on crates.io, but as an internal tool, maybe we can shift to an "internal" approach, like how rustc and cargo are done 19:38:43 releaseing tarballs on GL is also an option 19:38:51 * releasing 19:38:52 would work as plan B as well (for example, using the local source support). it would be a bit weird to do that without also marking the published crate as no longer being published though 19:39:32 it's definitely not only used in Debian itself btw, there are downstreams/derivatives that use it as well ;) 19:39:41 iirc you can't delete crates, only yank them 19:40:11 Do they consume it by importing from Debian or by using the crate, though? 19:40:53 speaking for my $dayjob, we basically fork debcargo-conf and patch as needed, and that includes debcargo 19:41:03 not sure what others do 19:41:39 for me almost all variants are workable 19:41:47 I'm not saying to abandon it on crates.io ;) just that it's not the "source of truth" 19:42:41 let's see what Ximin thinks about giving access to a few more people, if that works, it's probably the lowest friction variant for now 19:42:51 agreed 19:43:05 +1 19:43:09 +1 19:43:39 #action f_g write to Ximin+CC about details of transfer/expansion of ownership 19:43:44 #topic debcargo changes 19:44:01 #info jamessan already mentioned the MSRV translation that is up for review 19:44:28 #info mjt proposed an alternative encoding of dependency ranges 19:45:05 #info semver_suffix changes need to be implemented in debcargo proper (Breaks+Replaces issue with Provides/virtual packages) 19:45:23 #info ncts proposed feature-less packages that encode feature information not in package name but in d/control field 19:45:25 ;) 19:45:37 q: could we drop the compat file, use debhelper-compat and but it to the latest (13) ? 19:45:57 if so, maybe also update Standards-Version 19:46:14 yes and yes, such things are usually done when updating debcargo :) 19:46:16 Yeah, that seems like something that should be reviewed once or twice a Debian release :) 19:46:17 there's a MR by capitol for that 19:46:47 maybe I can look into the compat thing 19:47:09 there is a list of smaller and bigger backlogged issues in salsa as well, like allowing bin-only packages 19:47:38 support for arch:all -data bin packages and multiple bin packages might also be nice to have at some point 19:47:58 I don't think those are filed/spec'ed yet though :) 19:48:14 I'd like to also throw in a broad concept that is an overhaul of our setup 19:48:34 yeah I remember filing that; the compat thing might be something I'm competent doing though 19:48:49 ^the bin-only thing 19:49:12 ncts: shoot :) or at least, a fix sentence summary maybe ;) 19:49:26 #action count_omega potentially will take a look at DH compat changes in debcargo 19:49:42 #action f_g will review jamessan MSRV translation MR, which got updated since the last feedback 19:49:59 the current one is 1) rustc with a bunch of ad-hoc helper scripts 2) cargo with a bunch of ad-hoc helper scripts 3) debcargo which has a good base concept of overlay but lack quite some pragmatic things 4) a whole pile of package overlays organized under an ad-hoc repo named debcargo-conf 19:51:15 I'd like to throw in that d-c-c is getting quite big 19:51:44 ncts: that's a short summary of the status quo, yes :) 19:52:35 maybe it belongs to another issue and discussion organized after this meeting 19:52:38 I'd also propose we discuss https://salsa.debian.org/rust-team/debcargo/-/issues/43 (not now though) 19:53:00 I have to admit the frequent urge of overhaul despite having no clear clue to implement 19:53:34 count_omega: definitely something we should pick up again in the near future, maybe something for the next meeting? 19:53:40 There's also the issue of debcargo's integratinon tests being outdated/broken, and no clear (that I'm aware of) documentation about that process 19:53:52 f_g: sure 19:54:21 ncts: you could also write up a more extensive proposal before a meeting, that way we could read and then discuss it? I know I am not always the best at getting back in a timely fashion to longer mails, but maybe the meeting deadline helps :) 19:54:51 #action f_g write more documentation for debcargo integration tests 19:54:58 it actually comes out midway, but the writeup, definitely 19:55:00 #action unbreak debcargo integration tests 19:55:27 #action ncts write up proposal for more fundamental changes in packaging work flow 19:55:56 anything else that's needed for debcargo itself before we proceed to the monorepo-related topics? 19:56:11 almost forgot the manifest replacement 19:56:51 the "a section of debcargo.toml replaces a section of Cargo.toml" thing 19:57:14 along with "d/control replacement" 19:57:47 yeah, there is a slew of features going in that direction that we should evaluate - like removing targets, removing features, removing benches/examples 19:58:11 +1 for that 19:58:32 but that might need a bit more testing before a concrete proposal :) 19:58:33 I lean towards the generic approach, plus a spec 19:58:50 it's almost too easy to replace a toml section with another 19:59:51 specific features, otoh, are impl's of the same underlying thing with different focus 19:59:54 that sounds like xpath/xslt :-P 20:00:16 in the generic sense, yes 20:00:53 ahem but that's also impl detail 20:01:03 could be explored as well, but sounds like a bit of an orthogonal feature that could be used for similar goals. my guess is the UX of that would be worse than anything custom tailored for our common problems 20:02:04 but if we start generating patches from declarative input, having such a generic option as part of that for those that want to use it could work 20:02:25 I'd not see it as replacement for "remove_examples = true" though :) 20:03:18 oh, sorry for forgetting about the meeting :( have been running around outside all weekend. I will read the backlog 20:04:05 On to the next topic? 20:04:08 #action ncts might explore a "generic semantic toml patching" feature for debcargo, to allow replacing/adding Cargo.toml 20:04:21 #topic debcargo-conf tooling/improvements 20:05:14 we recently had some reports of friction from people new to rust packaging, but not to packaging/Debian. 20:05:32 release.sh was the main culprit, but https://salsa.debian.org/rust-team/debcargo/-/issues/55 was also a result of that for example 20:06:20 I really think release.sh should default to NOUPDATE (as a comment in release.sh suggests) 20:06:42 release.sh should just be about producing the final source package 20:07:21 I was always a bit hesitant about changing release.sh as a non-DD 20:07:45 so be a DD :P 20:07:58 imho it should default to source-only uploads since most of the times it's just for updates 20:08:09 but yeah, that sounds like a good idea, the one below as well. there was also the question of whether the RFS/Uploaders check really makes sense 20:09:48 #action jamessan remove "update" functionality from release.sh 20:11:12 count_omega: we basically have the information whether it requires a bin upload or not anyway, so it should be able to do the right thing 20:11:26 do you want to take a stab at improving it if it does not handle some case correctly at the moment? 20:11:27 There's been some good progress on documenting workflows, but I agree that there are papercuts we could improve 20:12:09 Yeah, I thought release.sh did default to source-only unless it detected the package was new. Maybe there are some missing heuristics 20:12:33 f_g: I can put it on my to-do list but I can't promise I will tackle it soon, maybe once study break rolls around 20:12:55 ack 20:13:12 #action count_omega (time permitting) will look at release.sh generating/dputting the right kind of changes files 20:14:56 anything else for the tooling side of the monorepo? probably filing issues/MRs is a good idea when anybody encounters something that could be improved - it's usually an "in the moment" thing that is forgotten sooner rather than later (at least for me it usually is ;)) 20:15:57 clean up deprecated crates (ncts did some work on that) 20:16:21 kinda ot but, how do you build a chain of deps? 20:16:37 Sort of. I think the "no ITP" policy worked ok before we had a significant non-monorepo contingent of packages. It might be a good idea to revisit that, maybe with some tooling to help file the ITPs, so we play nicer in the broader Debian ecosystem 20:16:58 I just put crates and versions into a file and run a shell loop over that :) 20:17:21 jamessan: I think the main reason that was not done in the past was the sheer amount of ITP noise that would cause 20:17:29 I wrote chain_build.py which you feed crate names and optionally versions in the order you want built 20:17:41 but the feeding part is another problem 20:17:44 chain_build.py is handy. I have a local patch that has a "repackage.sh" mode instead of "update.sh", if people think that's useful 20:18:08 like stated above: dcc is getting kinda big, maybe we need to think about organizing it otherwise sometime in the future 20:18:37 jamessan: sounds like a reasonable addition 20:18:46 jamessan: I agree with f_g here: just this week I'd have to have filed like 8 itps 20:19:11 IMHO filing is not really the issue (it's a bit tedious, but fairly mechanical) 20:19:14 jamessan: feel free to push it! only until recently did I realize that more than not what I want is repackage.sh, not update.sh 20:19:26 it's getting on other people's nerves that would be my concern 20:19:34 That's why I mentioned automating the ITPs. The perl and go teams do something similar, and that would reduce the animosity (and toe stepping) from non-dcc folks 20:19:35 true 20:19:59 dh_make_rust when :P 20:20:16 count_omega: could just be a script in dcc's dev dir 20:20:30 ./dev/generate-itp.sh [version] 20:20:40 imagine the scaled up ITP farm 20:21:03 and then of course, debcargo or one of the scripts should check for an ITP bug and close it ;) 20:21:06 in d/changelog 20:21:24 any takers for writing a PoC helper? 20:21:35 I actually tried hacking a dh_make_rust for packaging gui rust apps but failed at writing the dependency translation stage 20:22:06 I can take a stab at it in august 20:22:15 I can try that too ;) 20:22:36 ncts: Would you prefer the default to be repackage or update? Currently, I have it look for REPACKAGE=1 since I didn't want to disturb the default 20:23:02 count_omega: file https://salsa.debian.org/rust-team/debcargo/-/issues/56 for that just now so we don't forget 20:23:07 generating is not a problem compared to "integrating" it into the workflow 20:24:02 #action count_omega will take a look at ITP filing assistance in August, if nobody else does it before that 20:24:23 f_g: ty 20:24:38 jamessan: I hard coded a func to collapse_feature, that requires a update.sh run, other than that I think it's safe to just repackage.sh 20:24:53 Yeah, I skip that part when repackage is in use 20:26:15 just punsh it ;) 20:26:33 #action jamessan will push some improvements to the chain build script by ncts 20:27:00 it's getting late, should we move to transitions/breaking updates? maybe just a short overview of what's going on/planned? 20:27:18 Maybe default to repackage.sh unless =REALVER specs are seen? That would require more changes. I'll push what I have and we can improve later 20:27:23 f_g: ack 20:27:35 #topic ongoing and upcoming transitions 20:27:51 #info base64 seems to be going well, plugwash did most of the heavy lifting 20:28:31 #info rust-cargo will happen in the next weeks, and might involve some other transitions as well 20:29:00 jamessan: that's a good idea, I'll save it for after this meeting 20:29:04 wayland 0.30 is staged in experimental, but alacritty will need 0.29 20:30:05 that's not that urgent tbh since ashpd will be uninstallable anyway after the gtk upload 20:30:16 I just prepared it 20:30:47 Yeah, it just surfaces another "papercut" of our current workflow, since we don't have distinct branches for the different Debian releases 20:30:48 "This can effectively be considered a new crate altogether." how many users are there of <= 0.29 atm ? 20:31:16 might be time to start "transition"ing aes, which is a security concern and doesnt affect too many rdeps 20:31:36 https://salsa.debian.org/rust-team/debcargo-conf/-/issues/43 20:32:22 +1 for aes/cipher since I might need it for other packages 20:32:38 ncts: will you drive that? 20:32:51 can do ;) 20:32:53 count_omega: okay, so that one is atm still blocked waiting on upstream changes 20:33:00 #action ncts will look at aes transition 20:33:15 I can nudge the alacritty folks to see if they have a plan to get new winit and alacritty releases out that use wayland 0.30 20:33:29 #info wayland 0.30 would break winit/alacritty, waiting on upstream developments 20:33:37 That would avoid updating the stack to a newer 0.29 release 20:33:45 yeah no rush on that 20:33:46 #action jamessan will nudge alacritty upstream to update 20:34:12 They've already updated winit, iirc, but not released it 20:34:22 if there is no progress within a reasonable time frame, semver_suffixing it is also an option (in this case, 0.29 and 0.30 are considered almost different crates by its upstream after all) 20:34:55 count_omega jamessan will you keep the tracking issue updated from time to time? 20:35:04 Sure 20:35:08 sure 20:35:20 #action jamessan and count_omega will keep wayland transition issue uptodate on salsa 20:35:30 btw count_omega I'm interested in packaging wezterm too, daily driver on mac now and will be glad to see it on debian 20:35:36 what about gtk, zbus and syn? any problems/blockers? 20:36:09 gtk is ready to go to unstable except 2 armhf failures for gio and glib 20:37:01 I tried setting up a armh qemu autopkgtest today but it failed to start ( on two different machines) 20:37:25 zbus needs only zbus-1 to be accepted from new 20:37:37 sounds manageable :) 20:37:47 https://release.debian.org/transitions/html/rust.html is also not looking too bad 20:37:51 syn is just waiting for autopkgtest failures/passes 20:37:55 ask for a porterbox or something? 20:38:20 hm, yeah. can I run a backtrace there 20:38:22 ? 20:39:24 regarding wezterm: I commented on the dep list but I don't have any time to package /maintain it 20:39:49 I also need to look into the diesel mess 20:40:39 count_omega: a binfmt/qemu-user-static env might also work for your test case checking - doesn't allow gdb, but at least debug-by-coding ;) 20:41:37 the CI log looks like some derive macro or code generation gone wrong - https://ci.debian.net/data/autopkgtest/unstable/armhf/r/rust-gio/34125397/log.gz 20:42:04 #info gtk transition still has some arch related issues to iron out 20:42:16 #info zbus is waiting for zbus-1 in NEW 20:42:20 I did that: https://paste.debian.net/1283399/ (except arch set to armhf) 20:42:23 #info syn also looks to be on track 20:43:02 no, I mean something else :) I'll ping you tomorrow? 20:43:09 any other transitions worth mentioning? 20:43:24 no 20:43:28 thanks :) 20:43:37 * f_g also doesn't have any planned 20:44:27 #topic future meetings 20:44:57 should we keep doing these? with what frequency/schedule? 20:45:20 like at least once a month ? 20:46:01 aye, imo it can push some things farther 20:46:05 I think once a month is a good frequency, and I do like that they provide a sort of focus point, even if obviously most of the work still happens outside of the meetings 20:46:11 +1 20:46:42 monthly is quite standard, haha 20:46:44 it would also give us some sort of natural area for discussions and decision making that is not too async and/or verbose 20:46:51 any preferences for slots? 20:47:08 like last sunday? 20:47:22 btw, what's our timezones? 20:47:34 * f_g is in CET, which is UTC+2 atm 20:47:39 any time is fine by me though I'd prefer it not to be wednesday evening 20:47:46 America/New_York 20:47:46 * count_omega too 20:48:53 Asia/Shanghai but I now live like Europe/Berlin 20:49:42 so still 19:00 UTC? 20:49:54 so would 6 or 7 pm UTC work for everyone? that's (late) evening in central Europe early afternoon in NY? 20:50:07 yes 20:50:33 Yeah, that worked fine this time. Maybe they'll be a little shorter if we have them on a more regular basis :) 20:50:43 last Sunday of the month would be 30th of July as next meeting 20:50:58 do we have some ical service? 20:51:01 jamessan: yes, 1 to at most 1,5h would be my preference/goal ;) 20:51:20 ncts: don't think so, but I guess a reminder here and on the list a week before serves a similar purpose :) 20:51:51 would 6pm UTC on July 30th work for everybody (present)? 20:51:59 I can ofc set up an event on my own cal, but anyway 20:52:32 yeah should have time 20:53:18 Not for me. Week before or after would 20:54:05 weekend before or after doesn't work for me, during the week after woul 20:54:20 haha the reality 20:54:37 If it's just me, then I can read the notes :) 20:54:48 by doesn't work you mean only sunday or the whole weekend? 20:55:08 (I guess it's the plural) 20:55:20 I'm out of town the weekend prior, I am on my way to the other side of the world the weekend after :) 20:55:38 Currently, it's just that Sunday. VAC plans that week, starting July 30th 20:55:51 would friday evening work? 20:56:15 should we do the 27th or 28th? or I could also do another doodle with a deadline of end of this week, with a few suggestions around end of july/start of august 20:56:49 During the week is tougher, due to work, unless we did it later 20:56:59 we could just use a team scheduling tool and choose which days are available 20:57:09 +1 20:57:23 ack, I'll send out a doodle-thing tomorrow 20:57:30 Thanks 20:57:34 ncts: if you have a suggestion for such a tool, drop it here, I'll take a look 20:57:47 looks like doodle.com is such a thing 20:57:49 #action f_g send out mail with links to meeting notes and call for finding next date 20:58:02 with that, I'll head off to bed :) 20:58:25 thanks for attending, and see you around! 20:58:34 #endmeeting