18:01:21 #startmeeting 18:01:21 Meeting started Fri Apr 18 18:01:21 2025 UTC. The chair is werdahias. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:21 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:26 ah 18:01:34 #topic rollcall 18:01:36 say hi 18:01:42 I should drop the message and let it go silent when unknown !message 18:04:07 Hi there! 18:04:09 werdahias: not sure if you'd want it but uh, debconf team roll call does a {something}all action that just pings everyone in the room 18:05:25 Is it just us 3 right now? 18:05:52 seems like it 18:06:11 echo "meetbot: ping+all" | sed s/+// it seems 18:06:24 but oh well, probably no 18:06:58 ok, moving one 18:07:01 on 18:07:06 Yeah 18:07:33 lol 18:07:56 #topic transitions/toolchain 18:08:10 not much going on here I guess since we are in the freeze 18:08:13 Shall I start? 18:08:17 Yep 18:08:27 I just wanted to add rustix is almost ready in git 18:08:34 oh meeting 18:08:37 o/ 18:08:42 I'm not completing it since we'll have to wait forky anyway 18:08:50 Hi weepingclown[m] ! 18:09:23 I think we can skip this one since we won't be doing any such heavylifting this late into the freeze 18:09:26 Also many upstreams are transitioning, so the later we update the higher the chance we don't have to write patches 18:09:30 agreed 18:09:47 #topic AOB 18:10:07 ok that's quick xD 18:10:10 noisycoil[mds] , ncts[m]: I think you had agendas 18:10:17 I think at least f_g and eamanu marked yes for this slot in the poll, even though I didn't think of this in the rollcall part :> on mobile and that 18:10:20 https://pad.riseup.net/p/DebianRustTeamMeetAgenda-keep 18:10:38 Yep 18:10:39 h01ger did show up earlier IIRC 18:10:46 Nothing about toolchain? 18:11:06 werdahias: I suggest pad.d.n for the next time :) 18:11:17 TIL 18:11:21 not much, also not much on rustc without f_g 18:11:47 Yeah 18:11:58 weepingclown[m]: Nice! 18:12:06 plus my items aren't really good when there are few - they need consensus and action 18:12:20 but I'll try anyway 18:12:36 On the one hand I agree, on the other hand I can't wait to say yes to the logo, so let's proceed 18:12:44 lol thanks 18:12:52 ;-) 18:13:49 ncts[m]: we've been keeping this topic for a long time now, maybe debconf is a nice place to have some concrete ideas on this 18:14:04 which is ~3months away 18:14:27 not sure I'll make it, for one 18:14:58 FTR I agree with a team logo 18:15:06 but uh, yes we sure can discuss then 18:15:21 Yes, and the one which Blair proposed looks so cool 18:15:35 maybe another poll would do 18:16:45 Yes. I propose we hold a proper vote 18:16:56 on lists.d.o ? 18:17:08 Yep 18:17:13 ack 18:17:13 but this is quite off the current # topic cough 18:17:13 werdahias: where else? 18:17:17 Oh sorry, I meant on our list 18:17:21 let's follow the agenda 18:17:27 #info vote for thee logo on lists.d.o 18:17:40 ncts[m]: isn't the topic AOB 18:18:07 should we move on to the book agenda ? 18:18:26 oh, that, missed ;p 18:18:31 yeah 18:18:49 team book editorial group and process 18:19:05 guess at this point we could first have some volunteers 18:19:26 technical writing skills and whatnot 18:19:44 I don't have those :P 18:20:09 not taking on much commitments atm but I can at least help proofread 18:20:10 I bet you didn't have rust skills 10 years ago ;p 18:20:25 I mean I can help more in forky with the book 18:20:25 Volunteers to do what, to be clear? 18:20:36 that said, it's ok to first proofread like weepingclown proposed 18:20:45 Meaning, do you have something in mind that we are not already doing? 18:20:45 to be in the editorial group 18:20:49 i.e. be an editor 18:21:15 Ok, so a proper organization and so on 18:21:17 Got it 18:21:25 Make it more official and structured basically 18:21:27 (sub)team, yeah 18:21:37 Yeah, you can count me in 18:22:01 I think we need a wider audience again to have more volunteers on this, so may another mail for the list? 18:22:01 ;) 18:22:08 yeah 18:22:13 s/may/maybe/ 18:22:16 I mean, I can't vouch for skills, but at least there's the intention ;-) 18:22:41 not like I have a strong skill set in that :> I just started 18:23:20 #info mail asking for volunteers into the editorial group 18:23:38 * weepingclown[m] have an English literature degree! 18:23:40 (which amounts to nothing but this is literally one of the rare occasions to flaunt it) 18:23:53 that's quite nice 18:23:56 literaturelly 18:23:57 s/have/has/ there we go :p 18:24:12 Lol 18:24:28 the process could be later discussed through an issue I reckon 18:24:36 aaything else for the book topic ? 18:24:46 *anything 18:25:19 #info discuss editorial process in an issue after we have enough volunteering "editors" 18:25:27 nothing much, after 18:25:48 the patch style ? 18:26:00 Yep 18:26:09 yeah. this one's gonna need another poll I guess lol 18:26:18 I thought we came to a conclusion on that one before 18:26:30 guess not 18:26:34 Yeah, I don't think we're going to take a lot of decisions today :-) 18:26:36 there were some individual agreements but not a consensus 18:27:03 Blair, what's your position on renaming patches and so on? 18:27:16 We were about to have this discussion in the book issue 18:27:16 ah, that. 18:27:20 Let's have it now 18:27:30 sheesh my quilt config looks bigger than my emacs config 18:27:57 would you mind linking the comment and reiterating your points? 18:28:06 Yep, give me a sec 18:28:09 I'm on mobile now and it's a bit inconvenient 18:28:43 thanks ;) 18:28:44 https://codeberg.org/werdahias/graffe/src/branch/main/.quiltrc 18:28:54 that's what I propose 18:29:48 basically wiki:UsingQuilt? 18:30:05 Found it 18:30:06 https://salsa.debian.org/rust-team/book/-/merge_requests/3#note_602314 18:30:44 thanks. ok, first on the renaming of patches 18:30:44 werdahias: https://paste.debian.net/hidden/601f490a/ 18:31:02 Yep, go ahead 18:31:43 I prefer using git to manage patches (like with gbp pq); however the current debcargo workflow doesn't really use git like that 18:32:04 so noisycoil felt that a "upgrade--.patch" naming would rather frequently need renaming, as dep's version goes 18:32:17 Yes 18:32:28 i tried, it's not possible as the upstream sources are not in the vcs 18:32:34 I strongly object against enforcing naming rules on patch names 18:32:37 my point is that we shouldn't fear renaming patches; a clear name is also important. 18:33:06 I agree that a clear name is important. I don't see a lot of benefit in enforcing an overly precise name 18:33:10 leave it to people to have sensible names for their patches 18:33:15 though now I also understand that such a patch could be viewed as an "ongoing" effort, and in that view there's no need to 18:33:26 I proposed something like "relax-.patch" 18:33:43 Not that I feel a strong need to fix patch names 18:33:58 I generally agree that a clear enough name is good enough 18:34:15 sorry for b eing late, will skim backlog 18:34:18 I still wanna insist that we keep a direction by "upgrade"/"downgrade", but that's up for debate 18:34:39 I think the team generally follows a relax-deps.patch naming for the most part on dependency version changes 18:34:48 and that feels very reasonable to me 18:34:56 not that people have to use that 18:35:25 as far as this goes, the paragraph that linked comments are about is obsolete, there is effectively another set of conventions in play 18:35:30 ncts[m]: my suggestion is to leave it to individuals 18:35:30 weepingclown: we are talking about the scenario in which you actually need to write a patch for relaxing the dep, not just bumping/downgrading the version 18:35:33 like the relax-deps thinf 18:35:49 so code changes 18:36:05 noisycoil[mds]: the answer then is "it depends" 18:36:18 weepingclown: a consistent naming convention is a good "interface" ;) 18:36:28 I tend to use something like "x-v1.2-compatibility.patch" blah blah 18:36:55 Blair Noctis: I agree, but I don't see any advantage in having to maintain (as in actual maintenance) of file names 18:37:10 It just feels as extra burden with nothing in return 18:37:27 I think we can write a recommendation in the book, but wouldn't forcce a hard convention 18:37:30 well, then it's up to individuals I guess 18:37:36 if we want, we could probably adapt a git-based patch rebasing workflow, we'd just need some scripts to synthesize a git repo. is there interest in exploring that? 18:37:39 ncts[m]: a naming convention to ever changing patch names that could just be ephemeral for a revision, I don't feel that need for it 18:37:44 If we're talking about {upgrade,downgrade}--.patch 18:37:52 relaxing deps is semantically not the same as upgrading a dep, well 18:37:53 and I think it'd just overly confuse people 18:38:08 though the style of the meat of patches? 18:38:51 before I dive in: just drop the recommendations about patch names entirely? let people adapt to existing ones 18:39:02 f_g: maybe we can hack that at the debconf? 18:39:55 my suggestion in general is that, we shouldn't try to bring standard for things that aren't absolutely necessary 18:39:56 Yeah, let people adapt sounds good to me. Patch style, on the other hand, should probably be discussed 18:40:02 At least for stable team members 18:40:08 +1 18:40:38 It happens too often that we have to push changes that are just due to different .quiltrcs 18:40:42 keeping the crate name in the commit message to indicate what's changed is a good standard in a monorepo, for one 18:40:54 can't say the same for patch names 18:40:59 if allowed to be radical I'll even propose the tools to work on real repos, heh 18:41:06 weepingclown: agreed 18:41:21 start of thread: https://lists.debian.org/debian-rust/2024/09/msg00004.html 18:41:48 we can revisit and see what we get now 18:41:53 ack 18:41:58 There is a quilt config suggested here https://wiki.debian.org/UsingQuilt 18:42:08 anything else for the patcch topic ? 18:42:18 Blair: 100% agree with ML email 18:42:20 Yes 18:42:54 I propose we open a ML thread and collect team member suggestions, then write down an actual .quitrc and add it to the book as a suggestion 18:42:57 do we discuss commit messages along with this one? 18:43:12 federico3 brought this up 18:43:38 I think this is a separate topic? 18:43:41 I would suggest cratename: update to 0.21 e.g 18:43:43 is it appropriate to just mandate a quiltrc in the team? 18:43:48 yeah then 18:43:57 I use exactly those in UsingQuilt wiki page plus some custom stuff of my own for -U1 et al 18:43:58 ncts[m]: yes 18:44:04 I don't think it is appropriate to mandate it 18:44:15 like suggest it at least 18:44:16 But to strongly suggest it, yes 18:44:21 Yeah 18:44:32 ncts[m]: not mandate, but recommend 18:44:35 or suggest 18:44:40 I mean, we already are kinda fed up with the result of the lack of one 18:44:42 Yeah 18:44:47 recommend, in apt terms :p 18:44:56 oh 18:44:57 +1 on recommend 18:45:06 --no-install-recommends :P 18:45:44 werdahias: could result in dysfunctional installations if you don't know what you are doing, exactly the point :p 18:45:49 but the dc-c scripts don't touch patches so it's up to individuals to do the "install recommends by default" 18:46:18 any idea? 18:46:34 dysfunctional? should be a Depends for those 18:46:38 Which should be a suggestion to define an rtquilt alias 18:46:44 also there is more to just a quiltrc; you kinda need to "curate" patches 18:47:08 federico3: well, let's just say that I meant underperforming :p 18:47:09 some pseudo headers with metadata for quilt, even 18:47:53 So, action to be taken: discuss actual patch style? 18:47:55 like Context-Radius: 2 18:48:24 I think git-formatted patches should also be explicitly allowed, at least because there are patches that we can easily cherrypick from upstream 18:48:33 I think we mostly agree to a git style: no index ===, no timestamp after ---/+++ 18:48:48 jbicha: agreed. Whatever we do we should allow those 18:48:54 jbicha: agreed 18:48:56 At least as an alternative 18:49:04 +1 18:49:41 it's too bad that quilt doesn't have options to exactly match the git style 18:49:47 I'd love a more expressive way to relax deps 18:49:51 like, whatever we do should result in improvements, and I think allowing git-formatted patches are important in that regard 18:50:10 Yes 18:50:23 the git style is kinda a LKML thing IIUC, while DEP3.. well 18:50:33 federico3: +1 there, debcargo.toml could have something for that 18:51:07 that'd allow us to move away from custom cargo.toml patches 18:51:24 I ignore DEP-3 except for adding Origin or Forwarded to my git patches 18:51:27 and disable deps? brought up on multiple occasions, we can definitely have those in debcargo, but that needs work ;) 18:51:36 although that'd probably make it harder to detect dependency version changes 18:52:29 but it's something to ponder about for sure 18:52:56 so we all agree that a git style patch is preferred? 18:53:09 we've discussed it a few times, and I think the consensus was having a declarative way to patch Cargo.toml would be appreciated :) 18:53:10 jbicha: I think it is nice to follow DEP-3 18:53:16 (I don't mind a git style header as long as it's consistent, but we also got DEP3..) 18:53:25 ncts[m]: I don't see anyone objecting 18:53:29 (I prefer git-style patches, but can live with both) 18:53:52 also see the thread about the "curate" part 18:53:53 same 18:54:29 like reduced context radius 18:54:33 let's say we have a consensus now and discuss the very specifics later, maybe in the ML? 18:54:43 (that's probably the only one, heh) 18:54:45 agreed 18:54:45 The problem with git-style patches is it requires separate tooling 18:55:26 wait, I think I mistook #action with #info for previous points lol 18:55:33 noisycoil[mds]: I think engineering problems are at least easier to solve than the social ones xD 18:55:43 That's for sure lol 18:56:10 I wouldn't object to a rust-team-tools debian package that provides those tools 18:56:22 let's move on? technicalities can come up in the broader discussion 18:56:33 So we don't have to ./dev/$EVERYTHING 18:56:38 weepingclown: agreed 18:56:43 sure 18:56:57 noisycoil[mds]: we had a discussion in the past about turning the shell scripts into a package.... 18:57:11 I was going to suggest we have a pre-freeze sprint, but alas 18:57:17 federico3: did you ever make any progress in that? 18:57:29 ncts[m]: sprint regarding? 18:57:49 yes, a bit 18:57:51 cruft cleanup, transitions, the like 18:58:06 but we are past the stage and it's probably better left for DC 18:58:07 well, too late :p 18:58:10 We've already talked about transitions 18:58:22 Any known cruft? 18:58:27 the current business is fixing RC bugs (and removing cruft/packages which should not be in trixie) 18:58:28 federico3: will you be at the debconf? that'd be a nice thing to hack on during the debcamp 18:58:50 noisycoil[mds]: I suspect quite a big chunk of the dh-11 packages, but I haven't managed to really investigate 18:58:56 2 at least: real feature packages and obsolete versioned packages 18:59:07 fwiw I will be filing RC bugs on a bunch of my packages to keep them away from trixie, to make the future work smoother 18:59:12 f_g (IRC): Ack, I think there's an open issue for that? 18:59:19 and there is no benefit to having them in trixie 18:59:21 there is 18:59:22 yeah RC bugs are still worth a sprint, BSP probably 18:59:43 f_g: had fun in Vienna? ;p 18:59:49 https://salsa.debian.org/rust-team/debcargo-conf/-/issues/112 19:00:01 ncts[m]: yes :) it was very nice! 19:00:20 ##79 19:00:22 I have a prototype at https://salsa.debian.org/rust-team/debcargo-conf/-/commits/dabs/?ref_type=heads - I'm not going to be at the next MiniDebconf (but I'll join online) and I'll be at DebConf - we can definitely give this stuff a good push 19:00:31 Ooof, quite a lot of ones 19:01:30 federico3 (IRC): nice! 19:01:47 Do you feel comfortable sharing it on the mailing list? 19:01:47 FTP masters usually ask for collapse_features to be enabled. Should we default to enabling it automatically when creating a new package? 19:01:47 I did an analysis of obsolete versioned packages as a list mail, jbicha did reference it on a few occasions but I guess it could use a proper tracker 19:02:10 federico3: there's already an issue tracking that for forky 19:02:47 https://salsa.debian.org/rust-team/debcargo/-/merge_requests/81 19:02:55 noisycoil[mds]: I can but if any early adopter could poke a bit at the prototype feedback/PRs would be welcome 19:03:42 Sure 19:04:08 The ML thread would be aimed to that too 19:04:40 f_g: can we make it so that it'd detect multiple libust-* package scenarios and automatically insert "collapse_features = true"? :p 19:04:41 anything else on this? 19:04:56 and if it's necessary to have, people can change it to false 19:05:13 werdahias (IRC): I think we're losing track of what "this" is :-) 19:05:18 weepingclown[m]: I think the way I proposed should be workable? 19:05:30 (I am) 19:05:57 #action have a clear agenda and follow it next time 19:06:03 Lol 19:06:21 one last point and mine are done ;p but this one's probably left for later: DC25 talks/workshops/sprints/meetups? 19:06:29 We do have a clear agenda, it's the follow part that we're not being so good at today 19:06:57 if we have enough people at debconf, we can do a BoF 19:07:04 we do have a lot of things to discuss afterall 19:07:12 maybe try video next time, so anyone on mic automatically blocks the queue lol 19:07:26 yeah sorry am a bit distracted today 19:07:49 I submitted a talk proposal, see backlog earlier today ;) Diziet proposed a get-together between various Rust packaging approaches 19:07:50 Are you comfortable doing video in the middle of the night? :-P (Hopefully we'll do it earlier next time) 19:08:02 according to the agenda we still want to discuss backports 19:08:09 Yes 19:08:13 oh, seems that I missed the meeting 19:08:24 right in the middle! 19:08:30 Shall we move to backports? 19:08:39 before that: 19:08:50 Ian Jackson proposed a workshop IIRC 19:08:54 Oh sorry I didn't read f_g's message 19:08:55 Yeah 19:08:59 right 19:09:04 yes 19:09:07 replied on-list 19:09:09 yes, Ian Jackson == Diziet ;) 19:09:13 oh 19:09:20 didn't realize that 19:09:22 :-O 19:09:50 .oO ( we should ban people from using IRC nicks different from Debian logins) 19:10:24 ;p then ok, seems not much to add to that 19:11:11 moving to backports then ? 19:11:34 sure 19:11:40 famous last words 19:11:44 Right 19:12:00 ok that's just my element being slow xD 19:12:01 So as far as I now there's the intention to do more backports in trixie 19:12:20 I am planning to upload rustc to backports at least for arm64/amd64 starting with Trixie, unless the backports admins object 19:12:22 For instance, I think f_g said he's going to backport rustc? 19:12:31 Precisely 19:12:35 basically every release as soon as it hits testing 19:12:40 do we have a tool to rebuild stable against e.g. a newer serde before uploading the latter? 19:12:45 since we are heavily reliant on team tooling in general, it'd make sense to have tooling for backports 19:12:54 idk how complex the work for that is 19:12:54 So right now we don't have the infra in dcc to do backports, mainly because we have a unique master branch 19:12:55 that kinda feels like chromium/firefox lol 19:13:01 f_g: thoughts? 19:13:23 I think at the time of full freeze, we could branch off a trixie-backports. and then try to ensure commits to master only touch a single crate at a time, so they can be cherry-picked and then adapted 19:13:42 f_g (IRC): Agreed 19:13:44 we discussed a repo structure for the "backports era" earlier 19:13:48 then the main conflicts should be changelog entries (in case of multiple subsequent backport updates), and of course backports-specific delta 19:13:58 I use a similar workflow at work 19:14:11 I had started some work to make dcc branch-independent 19:14:25 (although sometimes I am too lazy to cherry-pick and just git reset a crate-dir to master ;) 19:14:26 I'd say branch-aware 19:14:30 At this time all team tooling relies on having a single branch 19:14:45 what do you mean with branch-independent/-aware? 19:14:47 I mean, the master is basically sid 19:14:58 sid and experimental mixed 19:15:07 ncts[m]: also experimental 19:15:08 and the tooling needs to learn about trixie/, forky/, etc. 19:15:14 Yes 19:15:30 yeah, should we have an explicit experimental branch? 19:15:53 f_g: the rough idea is fine, how complex do you think the implementation will be? 19:15:58 I am not against it, but have not made up my mind yet on whether it's worth the effort 19:16:06 For backports, it's a clear yes 19:16:07 ncts[m]: I think we'd then also need some machinery that warns if you update in master if experimental is newer 19:16:17 that's up for debate I guess 19:16:22 f_g: that's for sure 19:16:27 an extra trixie branch would work I guess 19:16:44 f_g: maybe just rmadison? :p 19:16:47 well, at work I have no implementation at all ;) probably some helpers to sync a crate with master/sid would be nice, and of course some places like protecting master, ./release.sh etc. would need some adaptations 19:17:13 there was a mess when the http stack changelogs with experimental were reverted for in-between unstable uploads.. 19:17:17 weepingclown[m]: could be used for such a check, yes 19:17:24 Yeah 19:17:41 ncts[m]: yes, having a separate branch makes sense (one crate-specific per experimental upload even?) 19:17:54 similar to the pending one? 19:18:00 experimental-libc 19:18:08 IIRC we did have suggestions as dist/crate branches 19:18:37 Also, trixie-pending-* branches 19:18:38 and pending/dist/crate, for that matter 19:18:41 And so on 19:18:44 Yeah 19:18:50 +1 19:19:25 Action discuss implementation on list? 19:20:10 yes 19:20:10 seconded 19:20:17 thirded ;p 19:20:27 Ack 19:20:29 it's 12:50 AM here :p 19:20:41 03:20 here ;) 19:20:53 D-: 19:20:55 diversity and all that 19:21:06 my mind is starting to wander around and it says we should wrap up soon xD 19:21:10 I feel so guilty 19:21:14 see the timezone ranges at the end of the pad 19:21:14 I think that was the last topic? 19:21:24 Nope 19:21:32 Two of mine missing at least 19:21:37 there's more? 19:21:43 yes 19:21:43 Yes 19:21:46 nah, I chose to sleep for 2+ hours, wake up, and sleep for more, so that's my fault;p 19:21:49 go ahead, make my day :p 19:21:53 just carry on 19:21:57 applications subgroup 19:22:09 is the next one 19:22:12 This is actually from federico, but he didn't add it to the list so I did 19:22:15 could you elaborate> 19:22:17 ?* 19:22:31 salsa:rust-team/apps/foo 19:22:34