17:59:10 <ncts> #startmeeting
17:59:10 <MeetBot> Meeting started Sun Jan 28 17:59:10 2024 UTC.  The chair is ncts. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:10 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:32 <ncts> #topic roll call
17:59:43 <ncts> as usual ;)
17:59:50 * f_g waves
18:01:00 <capitol> I don't have anything more than the CI thing
18:01:00 <jamessan> o/
18:01:04 * weepingclown lurks
18:01:21 <ncts> ping werdahias as has been seen in poll
18:02:34 <ncts> werdahias__ as is in the room list
18:03:04 <f_g> count_omega for good measure (why are you here with so many nicks :-P)
18:03:29 <ncts> monikers are free online I guess ;)
18:05:10 <ncts> probably family time or something, let's start
18:05:17 <f_g> ack
18:05:37 <ncts> #topic CI & salsa integration, dashboard
18:06:02 <ncts> capitol has set up a little CI and dashboard to monitor package build status
18:06:09 <capitol> yes, https://debian-rust-ci.hackeriet.no/public-dashboards/7f1cbd7469964b9ebe9028b3d9e56deb?orgId=1
18:06:41 <capitol> it turns out that rebuilding all our crates takes almost exactly one week on an old intel NUC :P
18:07:06 <f_g> including autopkgtest?
18:07:16 <f_g> #link https://debian-rust-ci.hackeriet.no/public-dashboards/7f1cbd7469964b9ebe9028b3d9e56deb?orgId=1
18:07:28 <capitol> yes, it's a repackage.sh + build.sh
18:07:43 <capitol> but how do people feel about having some lint-jobs or similar running as part of the commit's / PR's to the repo?
18:08:11 <f_g> I think Sylvestre has a similar thing but just for testing that the binary/application packages still build
18:08:26 <jamessan> Does it honor the distribution in the changelog? i.e., use experimental and an appropriate build-dep-resolver when needed?
18:08:27 <capitol> and I guess those needs to run on runners that Debian provide, not some random individual :)
18:08:33 <ncts> continuous linting requires a linting workflow in place, but I like the idea
18:08:47 <capitol> jamessan: no, that would be nice improvement
18:09:11 <f_g> capitol: there is a pre-commit hook already, but that mostly covers some process things
18:09:47 <ncts> capitol: re on Debian runners, salsa and gitlab in general allows arbitrary CI runner, and as team infra it may be enough to have a team member provide it
18:10:14 <capitol> I think it would help new people if we linted the copyright and debcargo.toml files, and it should be fairly easy I think
18:11:19 <ncts> #idea linting, d/copyright for a start
18:11:22 <f_g> only the copyright is in git though, the rest of the FIXMEs are in generated stuff
18:11:22 <capitol> ncts: right, then it's just the security issue to handle if I would set it up, as anyone can open a MR I would like that linter job to run on a throwaway machine
18:11:42 <ncts> (should this idea command mention proposer?)
18:11:52 <capitol> s/machine/vm/
18:12:03 <ncts> or container ;)
18:12:09 <f_g> ncts: most things pick up any nicks you include, at least action does if you put it up front
18:12:35 <f_g> for salsa-ci, it would need to be some action that is "green" most of the time, else nobody looks at it
18:12:39 <ncts> f_g: sure, will add next time
18:12:47 <capitol> but alright, noone against, I'll try to build something and propose it and then we can see if we like it :)
18:13:34 <ncts> capitol: machine security is minor with containers/vms, compared to access control
18:13:50 <ncts> but salsa team is our first line of defense on that ;)
18:14:05 <f_g> I
18:14:22 <f_g> I'm sure there are tons of salsa CI actions that basically execute arbitrary code from an MR
18:14:50 <capitol> eek! :)
18:15:00 <jamessan> Like every package build :)
18:15:14 <f_g> I'm more worried about the load if we start adding builds/.., but if it's just doing repackage+checking the output that should be fine
18:15:39 <f_g> something like shellcheck or similar stuff for dev/ and the other scripts might also be nice
18:15:53 <ncts> in our team at least there's not much arbitrary code to execute, besides builds
18:16:28 <f_g> some parts could maybe also go in the pre-commit hook, either as warning or as hard error
18:16:43 <f_g> e.g., the copyright one at least ;)
18:16:56 <capitol> it should be fairly obvious if it happens, but would still be annoying to have to handle :)
18:17:41 <ncts> for that matter, "outsider" MRs can be set to manually approved to run CI job
18:18:18 <f_g> we can do that if it ever becomes too noisy, having them always one has less friction for newbies
18:18:25 <f_g> s/one/on
18:18:54 <ncts> and a rate/time limit can be impl'd on the runner side
18:19:54 <ncts> can we request a machine from the project? or do we get one ourselves?
18:21:32 <f_g> there's a common pipeline but that won't do what we want
18:21:45 <f_g> there's also a separate IRC channel (#salsa-ci) for questions
18:22:23 * f_g wonders whether the common one should be enabled for rustc
18:22:52 <f_g> it could test at least the bootstrapping profile and separate arch-any/all builds, both things that broke in the past without me realizing
18:23:34 <jamessan> Don't see why not
18:23:43 <capitol> sounds like a nice-to-have
18:24:26 * capitol meant that as a positive :)
18:24:29 <f_g> jamessan: mostly, load (rustc is on the expensive side)
18:24:33 <ncts> #action capitol to build something out to check for d/copyright and debcargo.toml as a start
18:24:36 <f_g> but that can be cleared up front
18:25:01 <f_g> #link https://salsa.debian.org/rust-team/debcargo/-/blob/master/.gitlab-ci.yml btw - that one is pretty nice and straightforward :)
18:27:11 <ncts> f_g: re rustc, those weren't possible to check through buildd builds I guess?
18:27:45 <f_g> oh, the separate arch:any/all does. the build profile is never used on buildds, it's for bootstrapping
18:27:54 <f_g> does trigger on buildds, I mean.
18:28:48 <ncts> get it. the peculiarity of maintaining a compiler it seems ;p
18:29:46 <ncts> #item f_g: good to have a CI item to check for rustc bootstrapping profile
18:30:21 <ncts> anything to add? like checks to add to the CI?
18:31:31 <capitol> lets start small :)
18:31:49 <ncts> sure ;)
18:32:15 <ncts> so, next up
18:32:36 <ncts> #topic status update on src:cargo merge with src:rustc
18:32:49 <f_g> alright :)
18:33:18 <f_g> it's mostly done, had to do quite a bit of rebasing since the MR was apparently based on a different version of rustc/cargo than we are currently at
18:33:47 <f_g> there's some follow up stuff that I haven't finished up yet, mostly courtesy of my pinched finger that made typing a bit of a pain for the last 2 weeks
18:34:02 <f_g> but that's better now (or I got used to typing with 9 fingers ;))
18:34:26 <f_g> I hope that I manage to do the upload before fosdem, not sure how fast ftp masters will be with review since it's a bigger change than usual
18:34:50 <f_g> #link https://salsa.debian.org/rust-team/rust/-/merge_requests/27
18:35:42 <f_g> #info progess a bit slower than expected, but should be done soon
18:36:32 <f_g> I also might fold in a change while we are messing up binary packages anyway - we currently ship a few symlinks that require a Suggests to be installed in order to work
18:37:03 <f_g> it might make more sense to split those symlinks into their own package and let that have a hard dependency, and then either suggesting or recommending that new package in rustc
18:37:25 <count_omega> sorry, totally missed the start :(
18:37:29 <f_g> that would be #1021868
18:37:42 <ncts> 2 weeks seem kinda serious for a finger :/
18:37:45 <f_g> for example, the rust-lld symlink is needed for building wasm stuff
18:38:11 <f_g> ncts: well, it was a good pinch/heavy door ;)
18:38:55 <f_g> that's about it I thin for this topic, once I am done, I'd be happy with other people giving it a spin, especially if you have more exotic than usual use cases for cargo :)
18:39:10 <ncts> count_omega: no worries, we are only two topics in ;) CI and (current) cargo merge
18:39:15 <f_g> although of course the first upload will go to experimental anyway
18:39:19 <ncts> f_g: hope it gets well soon!
18:39:51 <f_g> thanks. it's mostly taking an annoying amount of time
18:41:11 <ncts> #info f_g: need to properly arrange files and Suggests/Recommends among packages for rustc
18:41:40 <ncts> #link https://bugs.debian.org/1021868
18:42:49 <ncts> f_g: I see that you also mentioned BoF of FOSDEM. should that be next?
18:43:10 <f_g> if you want? that will not be a long point anyway :)
18:43:26 <ncts> (or as the last, if you want to gather more info before it)
18:44:03 <f_g> nope, it's okay
18:44:13 <ncts> then it is
18:44:22 <ncts> #topic BoF at FOSDEM
18:44:48 <f_g> as written on list, I hope to get a few people involved in packaging rust stuff together at fosdem
18:45:19 <f_g> mainly to exchange pain points, improve guides for rust devs on distro-friendly development and release practices, and hopefully improve collaboration all around ;)
18:45:48 <f_g> I've asked the fosdem people for a slot in track C, hoping to get an assignment before the event
18:46:05 <f_g> if we don't get one there, we have to get one in the A/B slots for which sign up is only in person at the event
18:46:32 <f_g> if you have stuff to add but cannot attend, just write me an email or reply on list and I'll try to include it
18:46:51 <f_g> and please forward the invitation to other non-Debian people that might be interested as well :)
18:47:57 <f_g> #link https://pretalx.fosdem.org/fosdem-2024/talk/review/XY8RVXKD98AUN3XSTTHGW9DMEHKSVGA7
18:48:12 <f_g> #info BoF for distro/upstream exchange at fosdem
18:49:26 <ncts> this is probably better organized as its own thing ;)
18:50:26 <ncts> next is from werdahias aka count_omega
18:50:45 <ncts> #topic transitions and general documentation improvement
18:53:20 <capitol> we have a lot in experimental right now
18:53:29 <jamessan> As part of updating alacritty, there are a number of semver changes that got staged in experimental
18:54:11 <jamessan> I'm currently documenting all the reverse-affected crates (due to (build-)depends or testsuite-triggers) in #57
18:54:23 <jamessan> at least for the crates involved in updating alacritty
18:54:40 <werdahias> I noticed wayland-egl has no update yet, is this intentional ? kudos for the work btw
18:55:03 <capitol> my only thing is itertools, but I only packaged that to help Jonas as he had filed some bugs about updating it, and updates for rev-deps are in dc-c already
18:55:34 <jamessan> https://salsa.debian.org/rust-team/debcargo-conf/-/issues/57#note_459134
18:56:01 <f_g> would it make sense to actually try to use the transition tooling from RT for stuff like this?
18:56:18 <f_g> we do have the permanent tracker that at https://release.debian.org/transitions/html/rust.html
18:56:47 <werdahias> the only thing from my side is that I would like a semver for proc-macro-crate as the newer glib-macros needs that
18:56:55 <werdahias> f_g: good idea
18:57:23 <jamessan> f_g: If that's something we can express via ben files, yeah
18:58:30 <f_g> I have no experience with ben, but AFAICT it's grep-dctrl on steroids?
18:58:35 <ncts> (jamessan: salsa shorthand unfortunately clashes with bts so I can only impl it for MRs, you have to do debcargo-conf#57 for now)
18:59:28 <f_g> so in this case it could probably be expressed as a series of depends and build-depends REs for good and bad
18:59:49 <f_g> it would have the advantage of being continously run, also on non-debcargo-conf packages
19:00:00 <f_g> and even if we have a semver-suffix package, it would then tell us when we can drop it ;)
19:00:13 <werdahias> fyi, a new gtk-rs will be released soon™ but that's self-contained, I will tackle that when I have more time
19:01:08 <f_g> hyper and friends will be on my agenda at some point in the next weeks, there's #1055918 for that already
19:02:02 <ncts> #action werdahias plans for new gtk-rs release
19:02:23 <ncts> #action f_g will go for hyper & co. in later weeks
19:02:42 <ncts> f_g: re "when we can drop it", how's that achieved?
19:03:20 * plugwash_ took a quick look at the hyper etc situation and concluded we would need either a massive "big bang" transition or a massive amount of semver suffixing :/
19:03:37 <jamessan> As debcargo-conf#57 shows, there's a lot of intertwined packages.  I'll keep trying to get things staged in experimental, and will file bugs on non-dcc packages.  Maybe we can then try to use ben files for the actual transitions to unstable
19:03:38 <werdahias> ncts: filing a RM request once nothing depends on it anymore I guess
19:03:40 <ncts> hmm, through the "completion" of the "transition" of a semver'd package I guess?
19:04:12 <capitol> ben files? What are those
19:04:17 <jamessan> ncts: Then ben file could look for things depending on the semver package and when there aren't anymore, then it can be RMed
19:04:20 <ncts> #info plugwash suggests transitioning hyper would be a "big bang"
19:04:31 <f_g> capitol: ben is the tool used for transition tracking by the release team
19:04:45 <jamessan> https://debian.pages.debian.net/ben/
19:04:45 <f_g> #link https://debian.pages.debian.net/ben/
19:05:00 <f_g> #link https://release.debian.org/transitions/
19:05:38 <f_g> plugwash: yes, it's a big one. I do have some experience with hyper from the dev side, so I might be able to whip up a patch or two for upstreams lagging behind
19:06:16 <plugwash_> also last I checked reqwest hadn't transitioned to the new hyper yet which afaict is a rather key part of the puzzle.
19:06:17 <jamessan> although, I guess filing transition requests would simplify the work of figuring out what needs to be updated
19:06:35 <ncts> #info jamessan works on alacritty update, which involves a lot of intertwined packages, including wayland 0.29 -> 0.31
19:07:41 <jamessan> werdahias: wayland-egl wasn't caught up in the other alacritty/wayland updates, so I guess none of that stack needs it
19:08:20 <f_g> plugwash_: yes, but there has been progress on that part at least
19:08:22 <werdahias> ah ok, just struck me as weird that it wasn't updated too
19:08:32 <f_g> I do not plan to ignore reqwest or patch that one myself :)
19:08:50 <ncts> there's also debcargo-conf#56
19:10:01 <f_g> #action f_g play around with ben and see if it's a good fit for bigger future transitions
19:11:30 <ncts> thinking of versioned packages, a terrible idea came across my mind
19:12:17 <werdahias> jamessan: once the alacritty transition is done can we drop the wl-0,29 packages ?
19:12:43 <jamessan> I believe so, yes
19:13:12 <ncts> with upstream repository, we can… "build" quite a few versions of the same crate into one debian package; that doesn't need NEW for new versioned packages
19:13:16 <werdahias> ah neat.
19:13:48 <plugwash_> last I looked alacritty was not the only user of wayland 0.29
19:14:54 <f_g> ncts: it would still require bin-NEW but complicate things by merging an older version into the same source package?
19:15:37 <capitol> there is also wl-clipboard-rs, but that have already moved to .31 upstream iirc
19:15:48 <ncts> f_g: I guess not, /usr/share/cargo/registry/foo-{x,y} in the same librust-foo-dev. but it complicates a lotta things, hence terrible.
19:15:48 <werdahias> ah, https://salsa.debian.org/rust-team/debcargo-conf/-/issues/43 documents them, might be some extra updating
19:16:32 <werdahias> I can uplod those to exp too I guess to stage another transition
19:16:52 <ncts> transitions are mostly covered I assume; werdahias: about the documentation part? and improvement part?
19:17:31 <werdahias> ah yeah, I intend to improve that by myself a bit
19:18:09 <werdahias> I had the issue where I needed to build a .so with cargo-c and the only reference i found was rav1e d/ files
19:19:00 <ncts> generally speaking, cdylibs?
19:19:04 <werdahias> So I'll write a wiki page then; imho such specific edge cases would warrant a documentation
19:19:07 <werdahias> yeah
19:19:45 <f_g> yes, cdylibs crop up more nowadays, but doc improvement and tooling improvement would be great
19:19:55 <f_g> sooner or later the same might apply for wasm things
19:20:13 <ncts> #action werdahias writes a wiki page about building cdylibs
19:21:19 <ncts> (though wiki and salsa .md's feel like separation of source of truth)
19:22:23 <ncts> #info f_g suggests wasm things might also need the care
19:23:01 <ncts> are there more general thoughts on docs and tooling?
19:23:19 <werdahias> ncts: well that's kinda an issue, but I tend to look more at the wiki
19:23:51 <werdahias> d-wiki should move to mediawiki imho, but that's OT here
19:24:26 <ncts> I like in-source docs more because they have version control ;p wikis have too, tho
19:24:38 <ncts> and wikis feel slow, frankly
19:24:49 <ncts> but the point here is source of truth
19:25:22 <ncts> so, moving on if no more thoughts on this
19:26:33 <ncts> #topic lots of semver packages taged in experimental
19:26:43 <ncts> s/taged/staged, eww
19:27:24 <ncts> jamessan mentioned this, I assume the last one in part covered through transitions
19:28:26 <jamessan> yeah, I think we already discussed this :)
19:31:01 <ncts> merged then ;)
19:31:28 <ncts> any new topics?
19:32:38 * f_g got nothing else
19:33:02 * capitol neither
19:33:49 <ncts> #topic next meeting
19:34:34 <ncts> do we have next one in a month, as usual?
19:34:58 <werdahias> sound  good imho
19:35:02 <werdahias> +s
19:35:23 <f_g> +1
19:36:10 <f_g> I'm not around from 28th to the 3rd, but I don't mind skipping either if that date range works best for everyone else
19:36:11 <ncts> (it might be good to have a revisit item next time, haha)
19:37:30 <ncts> without further ado
19:37:37 <ncts> #endmeeting