18:01:21 <werdahias> #startmeeting
18:01:21 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:26 <werdahias> ah
18:01:34 <werdahias> #topic rollcall
18:01:36 <werdahias> say hi
18:01:42 <ncts[m]> I should drop the message and let it go silent when unknown !message
18:04:07 <noisycoil[mds]> Hi there!
18:04:09 <ncts[m]> 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 <noisycoil[mds]> Is it just us 3 right now?
18:05:52 <werdahias> seems like it
18:06:11 <ncts[m]> echo "meetbot: ping+all" | sed s/+// it seems
18:06:24 <ncts[m]> but oh well, probably no
18:06:58 <werdahias> ok, moving one
18:07:01 <werdahias> on
18:07:06 <noisycoil[mds]> Yeah
18:07:33 <ncts[m]> lol
18:07:56 <werdahias> #topic transitions/toolchain
18:08:10 <werdahias> not much going on here I guess since we are in the freeze
18:08:13 <noisycoil[mds]> Shall I start?
18:08:17 <noisycoil[mds]> Yep
18:08:27 <noisycoil[mds]> I just wanted to add rustix is almost ready in git
18:08:34 <weepingclown[m]> oh meeting
18:08:37 <weepingclown[m]> o/
18:08:42 <noisycoil[mds]> I'm not completing it since we'll have to wait forky anyway
18:08:50 <noisycoil[mds]> Hi weepingclown[m] !
18:09:23 <weepingclown[m]> I think we can skip this one since we won't be doing any such heavylifting this late into the freeze
18:09:26 <noisycoil[mds]> Also many upstreams are transitioning, so the later we update the higher the chance we don't have to write patches
18:09:30 <werdahias> agreed
18:09:47 <werdahias> #topic AOB
18:10:07 <weepingclown[m]> ok that's quick xD
18:10:10 <werdahias> noisycoil[mds] , ncts[m]: I think you had agendas
18:10:17 <ncts[m]> 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 <werdahias> https://pad.riseup.net/p/DebianRustTeamMeetAgenda-keep
18:10:38 <noisycoil[mds]> Yep
18:10:39 <ncts[m]> h01ger did show up earlier IIRC
18:10:46 <noisycoil[mds]> Nothing about toolchain?
18:11:06 <weepingclown[m]> werdahias: I suggest pad.d.n for the next time :)
18:11:17 <werdahias> TIL
18:11:21 <ncts[m]> not much, also not much on rustc without f_g
18:11:47 <noisycoil[mds]> Yeah
18:11:58 <noisycoil[mds]> weepingclown[m]: Nice!
18:12:06 <ncts[m]> plus my items aren't really good when there are few - they need consensus and action
18:12:20 <ncts[m]> but I'll try anyway
18:12:36 <noisycoil[mds]> 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 <ncts[m]> lol thanks
18:12:52 <noisycoil[mds]> ;-)
18:13:49 <weepingclown[m]> 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 <weepingclown[m]> which is ~3months away
18:14:27 <ncts[m]> not sure I'll make it, for one
18:14:58 <werdahias> FTR I agree with a team logo
18:15:06 <ncts[m]> but uh, yes we sure can discuss then
18:15:21 <noisycoil[mds]> Yes, and the one which Blair proposed looks so cool
18:15:35 <ncts[m]> maybe another poll would do
18:16:45 <noisycoil[mds]> Yes. I propose we hold a proper vote
18:16:56 <werdahias> on lists.d.o ?
18:17:08 <noisycoil[mds]> Yep
18:17:13 <werdahias> ack
18:17:13 <ncts[m]> but this is quite off the current # topic cough
18:17:13 <weepingclown[m]> werdahias: where else?
18:17:17 <noisycoil[mds]> Oh sorry, I meant on our list
18:17:21 <ncts[m]> let's follow the agenda
18:17:27 <werdahias> #info vote for thee logo on lists.d.o
18:17:40 <weepingclown[m]> ncts[m]: isn't the topic AOB
18:18:07 <werdahias> should we move on to the book agenda ?
18:18:26 <ncts[m]> oh, that, missed ;p
18:18:31 <ncts[m]> yeah
18:18:49 <ncts[m]> team book editorial group and process
18:19:05 <ncts[m]> guess at this point we could first have some volunteers
18:19:26 <ncts[m]> technical writing skills and whatnot
18:19:44 <werdahias> I don't  have those :P
18:20:09 <weepingclown[m]> not taking on much commitments atm but I can at least help proofread
18:20:10 <ncts[m]> I bet you didn't have rust skills 10 years ago ;p
18:20:25 <werdahias> I mean I can help more in forky with the book
18:20:25 <noisycoil[mds]> Volunteers to do what, to be clear?
18:20:36 <ncts[m]> that said, it's ok to first proofread like weepingclown proposed
18:20:45 <noisycoil[mds]> Meaning, do you have something in mind that we are not already doing?
18:20:45 <ncts[m]> to be in the editorial group
18:20:49 <ncts[m]> i.e. be an editor
18:21:15 <noisycoil[mds]> Ok, so a proper organization and so on
18:21:17 <noisycoil[mds]> Got it
18:21:25 <noisycoil[mds]> Make it more official and structured basically
18:21:27 <ncts[m]> (sub)team, yeah
18:21:37 <noisycoil[mds]> Yeah, you can count me in
18:22:01 <weepingclown[m]> I think we need a wider audience again to have more volunteers on this, so may another mail for the list?
18:22:01 <ncts[m]> ;)
18:22:08 <ncts[m]> yeah
18:22:13 <weepingclown[m]> s/may/maybe/
18:22:16 <noisycoil[mds]> I mean, I can't vouch for skills, but at least there's the intention ;-)
18:22:41 <ncts[m]> not like I have a strong skill set in that :> I just started
18:23:20 <ncts[m]> #info mail asking for volunteers into the editorial group
18:23:38 * weepingclown[m] have an English literature degree!
18:23:40 <weepingclown[m]> (which amounts to nothing but this is literally one of the rare occasions to flaunt it)
18:23:53 <ncts[m]> that's quite nice
18:23:56 <noisycoil[mds]> literaturelly
18:23:57 <weepingclown[m]> s/have/has/ there we go :p
18:24:12 <noisycoil[mds]> Lol
18:24:28 <ncts[m]> the process could be later discussed through an issue I reckon
18:24:36 <werdahias> aaything else for the book topic ?
18:24:46 <werdahias> *anything
18:25:19 <ncts[m]> #info discuss editorial process in an issue after we have enough volunteering "editors"
18:25:27 <ncts[m]> nothing much, after
18:25:48 <werdahias> the patch style ?
18:26:00 <noisycoil[mds]> Yep
18:26:09 <ncts[m]> yeah. this one's gonna need another poll I guess lol
18:26:18 <weepingclown[m]> I thought we came to a conclusion on that one before
18:26:30 <weepingclown[m]> guess not
18:26:34 <noisycoil[mds]> Yeah, I don't think we're going to take a lot of decisions today :-)
18:26:36 <ncts[m]> there were some individual agreements but not a consensus
18:27:03 <noisycoil[mds]> Blair, what's your position on renaming patches and so on?
18:27:16 <noisycoil[mds]> We were about to have this discussion in the book issue
18:27:16 <ncts[m]> ah, that.
18:27:20 <noisycoil[mds]> Let's have it now
18:27:30 <weepingclown[m]> sheesh my quilt config looks bigger than my emacs config
18:27:57 <ncts[m]> would you mind linking the comment and reiterating your points?
18:28:06 <noisycoil[mds]> Yep, give me a sec
18:28:09 <ncts[m]> I'm on mobile now and it's a bit inconvenient
18:28:43 <ncts[m]> thanks ;)
18:28:44 <werdahias> https://codeberg.org/werdahias/graffe/src/branch/main/.quiltrc
18:28:54 <werdahias> that's what I propose
18:29:48 <ncts[m]> basically wiki:UsingQuilt?
18:30:05 <noisycoil[mds]> Found it
18:30:06 <noisycoil[mds]> https://salsa.debian.org/rust-team/book/-/merge_requests/3#note_602314
18:30:44 <ncts[m]> thanks. ok, first on the renaming of patches
18:30:44 <weepingclown[m]> werdahias: https://paste.debian.net/hidden/601f490a/
18:31:02 <noisycoil[mds]> Yep, go ahead
18:31:43 <jbicha> 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 <ncts[m]> so noisycoil felt that a "upgrade-<dep>-<ver>.patch" naming would rather frequently need renaming, as dep's version goes
18:32:17 <noisycoil[mds]> Yes
18:32:28 <bastif[mds]> i tried, it's not possible as the upstream sources are not in the vcs
18:32:34 <weepingclown[m]> I strongly object against enforcing naming rules on patch names
18:32:37 <ncts[m]> my point is that we shouldn't fear renaming patches; a clear name is also important.
18:33:06 <noisycoil[mds]> 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 <weepingclown[m]> leave it to people to have sensible names for their patches
18:33:15 <ncts[m]> 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 <noisycoil[mds]> I proposed something like "relax-<dep>.patch"
18:33:43 <noisycoil[mds]> Not that I feel a strong need to fix patch names
18:33:58 <noisycoil[mds]> I generally agree that a clear enough name is good enough
18:34:15 <f_g> sorry for b eing late, will skim backlog
18:34:18 <ncts[m]> I still wanna insist that we keep a direction by "upgrade"/"downgrade", but that's up for debate
18:34:39 <weepingclown[m]> I think the team generally follows a relax-deps.patch naming for the most part on dependency version changes
18:34:48 <weepingclown[m]> and that feels very reasonable to me
18:34:56 <weepingclown[m]> not that people have to use that
18:35:25 <ncts[m]> 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 <weepingclown[m]> ncts[m]: my suggestion is to leave it to individuals
18:35:30 <noisycoil[mds]> 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 <ncts[m]> like the relax-deps thinf
18:35:49 <ncts[m]> so code changes
18:36:05 <weepingclown[m]> noisycoil[mds]: the answer then is "it depends"
18:36:18 <ncts[m]> weepingclown: a consistent naming convention is a good "interface" ;)
18:36:28 <weepingclown[m]> I tend to use something like "x-v1.2-compatibility.patch" blah blah
18:36:55 <noisycoil[mds]> 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 <noisycoil[mds]> It just feels as extra burden with nothing in return
18:37:27 <werdahias> I think we can write a recommendation in the book, but wouldn't forcce a hard convention
18:37:30 <ncts[m]> well, then it's up to individuals I guess
18:37:36 <f_g> 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 <weepingclown[m]> 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 <noisycoil[mds]> If we're talking about {upgrade,downgrade}-<dep>-<version>.patch
18:37:52 <bugge> relaxing deps is semantically not the same as upgrading a dep, well
18:37:53 <weepingclown[m]> and I think it'd just overly confuse people
18:38:08 <ncts[m]> though the style of the meat of patches?
18:38:51 <ncts[m]> before I dive in: just drop the recommendations about patch names entirely? let people adapt to existing ones
18:39:02 <weepingclown[m]> f_g: maybe we can hack that at the debconf?
18:39:55 <weepingclown[m]> my suggestion in general is that, we shouldn't try to bring standard for things that aren't absolutely necessary
18:39:56 <noisycoil[mds]> Yeah, let people adapt sounds good to me. Patch style, on the other hand, should probably be discussed
18:40:02 <noisycoil[mds]> At least for stable team members
18:40:08 <werdahias> +1
18:40:38 <noisycoil[mds]> It happens too often that we have to push changes that are just due to different .quiltrcs
18:40:42 <weepingclown[m]> 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 <weepingclown[m]> can't say the same for patch names
18:40:59 <ncts[m]> if allowed to be radical I'll even propose the tools to work on real repos, heh
18:41:06 <noisycoil[mds]> weepingclown: agreed
18:41:21 <ncts[m]> start of thread: https://lists.debian.org/debian-rust/2024/09/msg00004.html
18:41:48 <ncts[m]> we can revisit and see what we get now
18:41:53 <werdahias> ack
18:41:58 <bastif[mds]> There is a quilt config suggested here https://wiki.debian.org/UsingQuilt
18:42:08 <werdahias> anything else for the patcch topic ?
18:42:18 <noisycoil[mds]> Blair: 100% agree with ML email
18:42:20 <noisycoil[mds]> Yes
18:42:54 <noisycoil[mds]> 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 <ncts[m]> do we discuss commit messages along with this one?
18:43:12 <ncts[m]> federico3 brought this up
18:43:38 <noisycoil[mds]> I think this is a separate topic?
18:43:41 <werdahias> I would suggest cratename: update to 0.21 e.g
18:43:43 <ncts[m]> is it appropriate to just mandate a quiltrc in the team?
18:43:48 <ncts[m]> yeah then
18:43:57 <weepingclown[m]> I use exactly those in UsingQuilt wiki page plus some custom stuff of my own for -U1 et al
18:43:58 <werdahias> ncts[m]: yes
18:44:04 <noisycoil[mds]> I don't think it is appropriate to mandate it
18:44:15 <werdahias> like suggest it at least
18:44:16 <noisycoil[mds]> But to strongly suggest it, yes
18:44:21 <noisycoil[mds]> Yeah
18:44:32 <weepingclown[m]> ncts[m]: not mandate, but recommend
18:44:35 <weepingclown[m]> or suggest
18:44:40 <ncts[m]> I mean, we already are kinda fed up with the result of the lack of one
18:44:42 <noisycoil[mds]> Yeah
18:44:47 <weepingclown[m]> recommend, in apt terms :p
18:44:56 <ncts[m]> oh
18:44:57 <federico3> +1 on recommend
18:45:06 <werdahias> --no-install-recommends :P
18:45:44 <weepingclown[m]> werdahias: could result in dysfunctional installations if you don't know what you are doing, exactly the point :p
18:45:49 <ncts[m]> 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 <ncts[m]> any idea?
18:46:34 <federico3> dysfunctional? should be a Depends for those
18:46:38 <noisycoil[mds]> Which should be a suggestion to define an rtquilt alias
18:46:44 <ncts[m]> also there is more to just a quiltrc; you kinda need to "curate" patches
18:47:08 <weepingclown[m]> federico3: well, let's just say that I meant underperforming :p
18:47:09 <ncts[m]> some pseudo headers with metadata for quilt, even
18:47:53 <noisycoil[mds]> So, action to be taken: discuss actual patch style?
18:47:55 <ncts[m]> like Context-Radius: 2
18:48:24 <jbicha> 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 <ncts[m]> I think we mostly agree to a git style: no index ===, no timestamp after ---/+++
18:48:48 <noisycoil[mds]> jbicha: agreed. Whatever we do we should allow those
18:48:54 <weepingclown[m]> jbicha: agreed
18:48:56 <noisycoil[mds]> At least as an alternative
18:49:04 <werdahias> +1
18:49:41 <jbicha> it's too bad that quilt doesn't have options to exactly match the git style
18:49:47 <federico3> I'd love a more expressive way to relax deps
18:49:51 <weepingclown[m]> like, whatever we do should result in improvements, and I think allowing git-formatted patches are important in that regard
18:50:10 <noisycoil[mds]> Yes
18:50:23 <ncts[m]> the git style is kinda a LKML thing IIUC, while DEP3.. well
18:50:33 <weepingclown[m]> federico3: +1 there, debcargo.toml could have something for that
18:51:07 <weepingclown[m]> that'd allow us to move away from custom cargo.toml patches
18:51:24 <jbicha> I ignore DEP-3 except for adding Origin or Forwarded to my git patches
18:51:27 <ncts[m]> and disable deps? brought up on multiple occasions, we can definitely have those in debcargo, but that needs work ;)
18:51:36 <weepingclown[m]> although that'd probably make it harder to detect dependency version changes
18:52:29 <weepingclown[m]> but it's something to ponder about for sure
18:52:56 <ncts[m]> so we all agree that a git style patch is preferred?
18:53:09 <f_g> 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 <weepingclown[m]> jbicha: I think it is nice to follow DEP-3
18:53:16 <ncts[m]> (I don't mind a git style header as long as it's consistent, but we also got DEP3..)
18:53:25 <weepingclown[m]> ncts[m]: I don't see anyone objecting
18:53:29 <f_g> (I prefer git-style patches, but can live with both)
18:53:52 <ncts[m]> also see the thread about the "curate" part
18:53:53 <werdahias> same
18:54:29 <ncts[m]> like reduced context radius
18:54:33 <weepingclown[m]> let's say we have a consensus now and discuss the very specifics later, maybe in the ML?
18:54:43 <ncts[m]> (that's probably the only one, heh)
18:54:45 <werdahias> agreed
18:54:45 <noisycoil[mds]> The problem with git-style patches is it requires separate tooling
18:55:26 <ncts[m]> wait, I think I mistook #action with #info for previous points lol
18:55:33 <weepingclown[m]> noisycoil[mds]: I think engineering problems are at least easier to solve than the social ones xD
18:55:43 <noisycoil[mds]> That's for sure lol
18:56:10 <noisycoil[mds]> I wouldn't object to a rust-team-tools debian package that provides those tools
18:56:22 <weepingclown[m]> let's move on? technicalities can come up in the broader discussion
18:56:33 <noisycoil[mds]> So we don't have to ./dev/$EVERYTHING
18:56:38 <noisycoil[mds]> weepingclown: agreed
18:56:43 <ncts[m]> sure
18:56:57 <weepingclown[m]> noisycoil[mds]: we had a discussion in the past about turning the shell scripts into a package....
18:57:11 <ncts[m]> I was going to suggest we have a pre-freeze sprint, but alas
18:57:17 <weepingclown[m]> federico3: did you ever make any progress in that?
18:57:29 <weepingclown[m]> ncts[m]: sprint regarding?
18:57:49 <federico3> yes, a bit
18:57:51 <ncts[m]> cruft cleanup, transitions, the like
18:58:06 <ncts[m]> but we are past the stage and it's probably better left for DC
18:58:07 <weepingclown[m]> well, too late :p
18:58:10 <noisycoil[mds]> We've already talked about transitions
18:58:22 <noisycoil[mds]> Any known cruft?
18:58:27 <f_g> the current business is fixing RC bugs (and removing cruft/packages which should not be in trixie)
18:58:28 <weepingclown[m]> federico3: will you be at the debconf? that'd be a nice thing to hack on during the debcamp
18:58:50 <f_g> noisycoil[mds]: I suspect quite a big chunk of the dh-11 packages, but I haven't managed to really investigate
18:58:56 <ncts[m]> 2 at least: real feature packages and obsolete versioned packages
18:59:07 <weepingclown[m]> 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 <noisycoil[mds]> f_g (IRC): Ack, I think there's an open issue for that?
18:59:19 <weepingclown[m]> and there is no benefit to having them in trixie
18:59:21 <f_g> there is
18:59:22 <ncts[m]> yeah RC bugs are still worth a sprint, BSP probably
18:59:43 <ncts[m]> f_g: had fun in Vienna? ;p
18:59:49 <f_g> https://salsa.debian.org/rust-team/debcargo-conf/-/issues/112
19:00:01 <f_g> ncts[m]: yes :) it was very nice!
19:00:20 <ncts[m]> ##79
19:00:22 <federico3> 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 <noisycoil[mds]> Ooof, quite a lot of ones
19:01:30 <noisycoil[mds]> federico3 (IRC): nice!
19:01:47 <noisycoil[mds]> Do you feel comfortable sharing it on the mailing list?
19:01:47 <federico3> 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 <ncts[m]> 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 <f_g> federico3: there's already an issue tracking that for forky
19:02:47 <f_g> https://salsa.debian.org/rust-team/debcargo/-/merge_requests/81
19:02:55 <federico3> noisycoil[mds]: I can but if any early adopter could poke a bit at the prototype feedback/PRs would be welcome
19:03:42 <noisycoil[mds]> Sure
19:04:08 <noisycoil[mds]> The ML thread would be aimed to that too
19:04:40 <weepingclown[m]> 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 <werdahias> anything else on this?
19:04:56 <weepingclown[m]> and if it's necessary to have, people can change it to false
19:05:13 <noisycoil[mds]> werdahias (IRC): I think we're losing track of what "this" is :-)
19:05:18 <f_g> weepingclown[m]: I think the way I proposed should be workable?
19:05:30 <noisycoil[mds]> (I am)
19:05:57 <weepingclown[m]> #action have a clear agenda and follow it next time
19:06:03 <noisycoil[mds]> Lol
19:06:21 <ncts[m]> one last point and mine are done ;p but this one's probably left for later: DC25 talks/workshops/sprints/meetups?
19:06:29 <noisycoil[mds]> We do have a clear agenda, it's the follow part that we're not being so good at today
19:06:57 <weepingclown[m]> if we have enough people at debconf, we can do a BoF
19:07:04 <weepingclown[m]> we do have a lot of things to discuss afterall
19:07:12 <ncts[m]> maybe try video next time, so anyone on mic automatically blocks the queue lol
19:07:26 <werdahias> yeah sorry am a bit distracted today
19:07:49 <f_g> I submitted a talk proposal, see backlog earlier today ;) Diziet proposed a get-together between various Rust packaging approaches
19:07:50 <noisycoil[mds]> Are you comfortable doing video in the middle of the night? :-P (Hopefully we'll do it earlier next time)
19:08:02 <werdahias> according to the agenda we still want to discuss backports
19:08:09 <noisycoil[mds]> Yes
19:08:13 <eamanu> oh, seems that I missed the meeting
19:08:24 <ncts[m]> right in the middle!
19:08:30 <noisycoil[mds]> Shall we move to backports?
19:08:39 <ncts[m]> before that:
19:08:50 <ncts[m]> Ian Jackson proposed a workshop IIRC
19:08:54 <noisycoil[mds]> Oh sorry I didn't read f_g's message
19:08:55 <noisycoil[mds]> Yeah
19:08:59 <weepingclown[m]> right
19:09:04 <eamanu> yes
19:09:07 <werdahias> replied on-list
19:09:09 <f_g> yes, Ian Jackson == Diziet ;)
19:09:13 <ncts[m]> oh
19:09:20 <ncts[m]> didn't realize that
19:09:22 <eamanu> :-O
19:09:50 <ncts[m]> .oO ( we should ban people from using IRC nicks different from Debian logins)
19:10:24 <ncts[m]> ;p then ok, seems not much to add to that
19:11:11 <werdahias> moving to backports then ?
19:11:34 <ncts[m]> sure
19:11:40 <weepingclown[m]> famous last words
19:11:44 <noisycoil[mds]> Right
19:12:00 <weepingclown[m]> ok that's just my element being slow xD
19:12:01 <noisycoil[mds]> So as far as I now there's the intention to do more backports in trixie
19:12:20 <f_g> I am planning to upload rustc to backports at least for arm64/amd64 starting with Trixie, unless the backports admins object
19:12:22 <noisycoil[mds]> For instance, I think f_g said he's going to backport rustc?
19:12:31 <noisycoil[mds]> Precisely
19:12:35 <f_g> basically every release as soon as it hits testing
19:12:40 <werdahias> do we have a tool to rebuild stable against e.g. a newer serde before uploading the latter?
19:12:45 <weepingclown[m]> since we are heavily reliant on team tooling in general, it'd make sense to have tooling for backports
19:12:54 <weepingclown[m]> idk how complex the work for that is
19:12:54 <noisycoil[mds]> 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 <ncts[m]> that kinda feels like chromium/firefox lol
19:13:01 <weepingclown[m]> f_g: thoughts?
19:13:23 <f_g> 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 <noisycoil[mds]> f_g (IRC): Agreed
19:13:44 <ncts[m]> we discussed a repo structure for the "backports era" earlier
19:13:48 <f_g> then the main conflicts should be changelog entries (in case of multiple subsequent backport updates), and of course backports-specific delta
19:13:58 <f_g> I use a similar workflow at work
19:14:11 <noisycoil[mds]> I had started some work to make dcc branch-independent
19:14:25 <f_g> (although sometimes I am too lazy to cherry-pick and just git reset a crate-dir to master ;)
19:14:26 <ncts[m]> I'd say branch-aware
19:14:30 <noisycoil[mds]> At this time all team tooling relies on having a single branch
19:14:45 <f_g> what do you mean with branch-independent/-aware?
19:14:47 <ncts[m]> I mean, the master is basically sid
19:14:58 <f_g> sid and experimental mixed
19:15:07 <weepingclown[m]> ncts[m]: also experimental
19:15:08 <ncts[m]> and the tooling needs to learn about trixie/, forky/, etc.
19:15:14 <noisycoil[mds]> Yes
19:15:30 <ncts[m]> yeah, should we have an explicit experimental branch?
19:15:53 <weepingclown[m]> f_g: the rough idea is fine, how complex do you think the implementation will be?
19:15:58 <noisycoil[mds]> I am not against it, but have not made up my mind yet on whether it's worth the effort
19:16:06 <noisycoil[mds]> For backports, it's a clear yes
19:16:07 <f_g> 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 <ncts[m]> that's up for debate I guess
19:16:22 <ncts[m]> f_g: that's for sure
19:16:27 <werdahias> an extra trixie branch would work I guess
19:16:44 <weepingclown[m]> f_g: maybe just rmadison? :p
19:16:47 <f_g> 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 <ncts[m]> there was a mess when the http stack changelogs with experimental were reverted for  in-between unstable uploads..
19:17:17 <f_g> weepingclown[m]: could be used for such a check, yes
19:17:24 <noisycoil[mds]> Yeah
19:17:41 <f_g> ncts[m]: yes, having a separate branch makes sense (one crate-specific per experimental upload even?)
19:17:54 <f_g> similar to the pending one?
19:18:00 <f_g> experimental-libc
19:18:08 <ncts[m]> IIRC we did have suggestions as dist/crate branches
19:18:37 <noisycoil[mds]> Also, trixie-pending-* branches
19:18:38 <ncts[m]> and pending/dist/crate, for that matter
19:18:41 <noisycoil[mds]> And so on
19:18:44 <noisycoil[mds]> Yeah
19:18:50 <werdahias> +1
19:19:25 <noisycoil[mds]> Action discuss implementation on list?
19:20:10 <werdahias> yes
19:20:10 <weepingclown[m]> seconded
19:20:17 <ncts[m]> thirded ;p
19:20:27 <noisycoil[mds]> Ack
19:20:29 <weepingclown[m]> it's 12:50 AM here :p
19:20:41 <ncts[m]> 03:20 here ;)
19:20:53 <federico3> D-:
19:20:55 <ncts[m]> diversity and all that
19:21:06 <weepingclown[m]> my mind is starting to wander around and it says we should wrap up soon xD
19:21:10 <noisycoil[mds]> I feel so guilty
19:21:14 <ncts[m]> see the timezone ranges at the end of the pad
19:21:14 <weepingclown[m]> I think that was the last topic?
19:21:24 <noisycoil[mds]> Nope
19:21:32 <noisycoil[mds]> Two of mine missing at least
19:21:37 <weepingclown[m]> there's more?
19:21:43 <werdahias> yes
19:21:43 <noisycoil[mds]> Yes
19:21:46 <ncts[m]> nah, I chose to sleep for 2+ hours, wake up, and sleep for more, so that's my fault;p
19:21:49 <weepingclown[m]> go ahead, make my day :p
19:21:53 <ncts[m]> just carry on
19:21:57 <werdahias> applications subgroup
19:22:09 <werdahias> is the next one
19:22:12 <noisycoil[mds]> This is actually from federico, but he didn't add it to the list so I did
19:22:15 <weepingclown[m]> could you elaborate>
19:22:17 <weepingclown[m]> ?*
19:22:31 <ncts[m]> salsa:rust-team/apps/foo
19:22:34 <noisycoil[mds]> He proposed to have a subgroup in rust team's namespace for applications
19:22:42 <noisycoil[mds]> Or something similar
19:22:43 <federico3> we don't have a dedicated subgroup for packaging applications
19:22:44 <noisycoil[mds]> Yeah
19:22:53 <werdahias> don't object, personally
19:22:54 <federico3> yep, and related documentation on the wiki
19:22:55 <weepingclown[m]> sure
19:23:05 <weepingclown[m]> how do we handle app + library cases though?
19:23:18 <noisycoil[mds]> Do you see a clear advantage over having everything under rust-team?
19:23:19 <ncts[m]> simple ones are already in dc-c, so there's limited benefit
19:23:22 <werdahias> woul tend to dcc
19:23:30 <federico3> right now the wiki points people at the Rust team for libraries and "just follow the gnome packaging" for applications
19:23:32 <werdahias> for those
19:23:32 <noisycoil[mds]> app + library I would use app
19:23:58 <werdahias> federico3: that needs changing, sure
19:24:08 <ncts[m]> but indeed, we could ask some maintainers with :debian/foo to move under the umbrella
19:24:10 <federico3> noisycoil[mds]: it's not just about keeping the repos tidy but comaintaining Rust applications
19:24:32 <noisycoil[mds]> As in not a single, but multiple maintainers?
19:24:39 <weepingclown[m]> noisycoil[mds]: that's a grey area because oftentimes app could just be a companion packaged because it's maybe nice to have it
19:25:05 <noisycoil[mds]> weepingclown[m]: Yeah. I guess it depends on the app/library
19:25:07 <ncts[m]> re wiki, (personally, and kinda selfishly as I started the book) I think it's better we drop the wiki entry down to "see the book" :>
19:25:22 <noisycoil[mds]> Blair Noctis: I agree
19:25:25 <federico3> noisycoil[mds]: like the crates - team mailing list as Maintainer and multiple uploaders
19:25:28 <werdahias> same
19:25:40 <weepingclown[m]> ncts[m]: makes sense, since the book is maintained well
19:25:51 <noisycoil[mds]> federico3 (IRC): Got it.
19:26:07 <werdahias> anything else to add ?
19:26:27 <noisycoil[mds]> I think there's agreement we should have an app subgroup?
19:26:34 <werdahias> yes
19:26:35 <ncts[m]> do I read it correctly that this subgroup is a salsa subgroup and a coordinating umbrella only?
19:26:37 <noisycoil[mds]> (Pending workspace support, probably)
19:26:45 <noisycoil[mds]> Yes
19:27:02 <federico3> ("only" in contrast to what?)
19:27:13 <ncts[m]> then I think we'll have to see how it goes, doesn't hurt to set it up
19:27:43 <ncts[m]> in contrast to having its own Maintainer address etc. a higher/more formal status?
19:28:30 <noisycoil[mds]> I think federico said these would specifically be team-maintained packages?
19:28:32 <weepingclown[m]> ncts[m]: it'll still be maintained under the rust team, right? why have a different maintainer then
19:28:45 <federico3> I was proposing team maintenance albeit I don't see a need for a dedicated email addr
19:29:03 <Diziet> f_g et al: I haven't put my proposal in yet.  I may send a draft to the list if I get my act together in time...
19:29:05 <werdahias> workspace support would be great to havve
19:29:05 <noisycoil[mds]> Agreed it doesn't need another email
19:29:06 <ncts[m]> reminds me of https://en.wikipedia.org/wiki/One_institution_with_two_names
19:29:12 <Diziet> Otherwise I'll just put it in.
19:29:17 <weepingclown[m]> Diziet: noted!
19:29:42 <weepingclown[m]> werdahias: I was going to mention workspace support in the end, to have as a topic for the next meeting
19:30:04 <werdahias> we can end it if you want and postpone ws support
19:30:12 <ncts[m]> Diziet: looking forward to it :o
19:30:31 <weepingclown[m]> werdahias: no, if that is a scheduled topic, do go ahead
19:30:54 <weepingclown[m]> actually even if it isn't, now that we are actually talking about things!
19:31:07 <noisycoil[mds]> Shall we move ahead?
19:31:19 <ncts[m]> noisycoil wrote ws support for -debstatus though
19:31:19 <werdahias> f_g:  how hard would workspaces in debcargo be ?
19:31:24 <noisycoil[mds]> Yes
19:31:40 <noisycoil[mds]> Before debcargo
19:31:52 <ncts[m]> debcargo support is much larger
19:31:55 <weepingclown[m]> I think people got confused when I mentioned the time, but I generally sleep after 4-5, sometimes after 8, even on work days xD
19:31:59 <noisycoil[mds]> We should support workspaces in cargo-debstatus
19:32:07 <ncts[m]> certainly
19:32:10 <noisycoil[mds]> I opened a PR for this
19:32:11 <noisycoil[mds]> https://github.com/kpcyrd/cargo-debstatus/pull/58
19:32:27 <noisycoil[mds]> It's already in working order, but I would very much appreciate comments
19:33:20 <noisycoil[mds]> In the PR you'll find some (non-aligned) output examples
19:33:25 <f_g> dh-cargo could support it, debcargo doesn't really make sense I think
19:33:40 <werdahias> ack
19:33:51 <f_g> or at least, it would be a rather big rework and change of scope
19:34:01 <federico3> noisycoil[mds]: oh nice!
19:34:07 <noisycoil[mds]> :-)
19:34:08 <weepingclown[m]> I had a nice local customization of cargo-debstatus that'd only print the unpackaged tree, I should probably send it upstream
19:34:09 <f_g> extending debcargo deb-dependencies to properly support it would probably be nice though
19:34:21 <werdahias> +1 for that
19:34:46 <ncts[m]> ah yes, debcargo isn't really prepared for a workspace setting
19:34:49 <weepingclown[m]> f_g: is it complex work? because having it could simplify a lot of things, I think
19:35:03 <f_g> and for dh-cargo it would probably be do-able as well, we'd need to settle on a d/control scheme first
19:35:12 <ncts[m]> noisycoil: good job btw
19:35:13 <federico3> +1 , I'm grepping for the red dot and it's a bit ridicolous
19:35:34 <noisycoil[mds]> Blair Noctis: Thanks :-)
19:35:52 <f_g> weepingclown[m]: extending deb-dependencies I think is not that much work, extending dh-cargo is mostly designing the interface(s), the actual changes are probably not too hard then
19:37:52 <weepingclown[m]> f_g: alright, I'd be happy to help if I can get some pointers, because I myself (and the whole team) could benefit a lot from it
19:37:54 <ncts[m]> speaking of, it's probably sensible to backport dh-cargo, debcargo etc. along with rustc
19:38:10 <noisycoil[mds]> +1
19:38:28 <werdahias> +1
19:38:48 <f_g> debcargo would be a massive backporting effort
19:38:54 <f_g> dh-cargo should be do-able
19:39:24 <ncts[m]> yeah, so only "sensible" at this point. let's see..
19:39:40 <ncts[m]> I almost forgot backports are mostly manual
19:40:02 <werdahias> I propose  we hold the next meet in ~2 months which is 13th July
19:40:31 <ncts[m]> isn't that the opening day of DC25?
19:40:33 <weepingclown[m]> werdahias: you mean June
19:40:41 <werdahias> weepingclown[m]: right
19:40:43 <f_g> was just about to say, and yes :)
19:41:19 <noisycoil[mds]> Mid June should be fine for me
19:41:42 <werdahias> any objections for the date ?
19:41:51 <werdahias> I'd like to end the meet soon
19:41:53 <ncts[m]> so a bimonthly schedule, no problemo for me per se, but I'm curious
19:41:54 <noisycoil[mds]> Not at this time
19:42:40 <noisycoil[mds]> What week day is it?
19:42:41 <ncts[m]> let's first free you then ;p
19:42:44 <weepingclown[m]> werdahias: yes, please end the meeting before noisycoil has objections :p
19:42:59 <noisycoil[mds]> Hahaha
19:43:09 <werdahias> :D
19:43:17 <werdahias> was productive though
19:43:20 <werdahias> #endmeet
19:43:21 <ncts[m]> 06-13 Fri
19:43:26 <werdahias> #endmeeting