17:59:10 #startmeeting 17:59:10 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:32 #topic roll call 17:59:43 as usual ;) 17:59:50 * f_g waves 18:01:00 I don't have anything more than the CI thing 18:01:00 o/ 18:01:04 * weepingclown lurks 18:01:21 ping werdahias as has been seen in poll 18:02:34 werdahias__ as is in the room list 18:03:04 count_omega for good measure (why are you here with so many nicks :-P) 18:03:29 monikers are free online I guess ;) 18:05:10 probably family time or something, let's start 18:05:17 ack 18:05:37 #topic CI & salsa integration, dashboard 18:06:02 capitol has set up a little CI and dashboard to monitor package build status 18:06:09 yes, https://debian-rust-ci.hackeriet.no/public-dashboards/7f1cbd7469964b9ebe9028b3d9e56deb?orgId=1 18:06:41 it turns out that rebuilding all our crates takes almost exactly one week on an old intel NUC :P 18:07:06 including autopkgtest? 18:07:16 #link https://debian-rust-ci.hackeriet.no/public-dashboards/7f1cbd7469964b9ebe9028b3d9e56deb?orgId=1 18:07:28 yes, it's a repackage.sh + build.sh 18:07:43 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 I think Sylvestre has a similar thing but just for testing that the binary/application packages still build 18:08:26 Does it honor the distribution in the changelog? i.e., use experimental and an appropriate build-dep-resolver when needed? 18:08:27 and I guess those needs to run on runners that Debian provide, not some random individual :) 18:08:33 continuous linting requires a linting workflow in place, but I like the idea 18:08:47 jamessan: no, that would be nice improvement 18:09:11 capitol: there is a pre-commit hook already, but that mostly covers some process things 18:09:47 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 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 #idea linting, d/copyright for a start 18:11:22 only the copyright is in git though, the rest of the FIXMEs are in generated stuff 18:11:22 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 (should this idea command mention proposer?) 18:11:52 s/machine/vm/ 18:12:03 or container ;) 18:12:09 ncts: most things pick up any nicks you include, at least action does if you put it up front 18:12:35 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 f_g: sure, will add next time 18:12:47 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 capitol: machine security is minor with containers/vms, compared to access control 18:13:50 but salsa team is our first line of defense on that ;) 18:14:05 I 18:14:22 I'm sure there are tons of salsa CI actions that basically execute arbitrary code from an MR 18:14:50 eek! :) 18:15:00 Like every package build :) 18:15:14 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 something like shellcheck or similar stuff for dev/ and the other scripts might also be nice 18:15:53 in our team at least there's not much arbitrary code to execute, besides builds 18:16:28 some parts could maybe also go in the pre-commit hook, either as warning or as hard error 18:16:43 e.g., the copyright one at least ;) 18:16:56 it should be fairly obvious if it happens, but would still be annoying to have to handle :) 18:17:41 for that matter, "outsider" MRs can be set to manually approved to run CI job 18:18:18 we can do that if it ever becomes too noisy, having them always one has less friction for newbies 18:18:25 s/one/on 18:18:54 and a rate/time limit can be impl'd on the runner side 18:19:54 can we request a machine from the project? or do we get one ourselves? 18:21:32 there's a common pipeline but that won't do what we want 18:21:45 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 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 Don't see why not 18:23:43 sounds like a nice-to-have 18:24:26 * capitol meant that as a positive :) 18:24:29 jamessan: mostly, load (rustc is on the expensive side) 18:24:33 #action capitol to build something out to check for d/copyright and debcargo.toml as a start 18:24:36 but that can be cleared up front 18:25:01 #link https://salsa.debian.org/rust-team/debcargo/-/blob/master/.gitlab-ci.yml btw - that one is pretty nice and straightforward :) 18:27:11 f_g: re rustc, those weren't possible to check through buildd builds I guess? 18:27:45 oh, the separate arch:any/all does. the build profile is never used on buildds, it's for bootstrapping 18:27:54 does trigger on buildds, I mean. 18:28:48 get it. the peculiarity of maintaining a compiler it seems ;p 18:29:46 #item f_g: good to have a CI item to check for rustc bootstrapping profile 18:30:21 anything to add? like checks to add to the CI? 18:31:31 lets start small :) 18:31:49 sure ;) 18:32:15 so, next up 18:32:36 #topic status update on src:cargo merge with src:rustc 18:32:49 alright :) 18:33:18 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 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 but that's better now (or I got used to typing with 9 fingers ;)) 18:34:26 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 #link https://salsa.debian.org/rust-team/rust/-/merge_requests/27 18:35:42 #info progess a bit slower than expected, but should be done soon 18:36:32 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 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 sorry, totally missed the start :( 18:37:29 that would be #1021868 18:37:42 2 weeks seem kinda serious for a finger :/ 18:37:45 for example, the rust-lld symlink is needed for building wasm stuff 18:38:11 ncts: well, it was a good pinch/heavy door ;) 18:38:55 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 count_omega: no worries, we are only two topics in ;) CI and (current) cargo merge 18:39:15 although of course the first upload will go to experimental anyway 18:39:19 f_g: hope it gets well soon! 18:39:51 thanks. it's mostly taking an annoying amount of time 18:41:11 #info f_g: need to properly arrange files and Suggests/Recommends among packages for rustc 18:41:40 #link https://bugs.debian.org/1021868 18:42:49 f_g: I see that you also mentioned BoF of FOSDEM. should that be next? 18:43:10 if you want? that will not be a long point anyway :) 18:43:26 (or as the last, if you want to gather more info before it) 18:44:03 nope, it's okay 18:44:13 then it is 18:44:22 #topic BoF at FOSDEM 18:44:48 as written on list, I hope to get a few people involved in packaging rust stuff together at fosdem 18:45:19 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 I've asked the fosdem people for a slot in track C, hoping to get an assignment before the event 18:46:05 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 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 and please forward the invitation to other non-Debian people that might be interested as well :) 18:47:57 #link https://pretalx.fosdem.org/fosdem-2024/talk/review/XY8RVXKD98AUN3XSTTHGW9DMEHKSVGA7 18:48:12 #info BoF for distro/upstream exchange at fosdem 18:49:26 this is probably better organized as its own thing ;) 18:50:26 next is from werdahias aka count_omega 18:50:45 #topic transitions and general documentation improvement 18:53:20 we have a lot in experimental right now 18:53:29 As part of updating alacritty, there are a number of semver changes that got staged in experimental 18:54:11 I'm currently documenting all the reverse-affected crates (due to (build-)depends or testsuite-triggers) in #57 18:54:23 at least for the crates involved in updating alacritty 18:54:40 I noticed wayland-egl has no update yet, is this intentional ? kudos for the work btw 18:55:03 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 https://salsa.debian.org/rust-team/debcargo-conf/-/issues/57#note_459134 18:56:01 would it make sense to actually try to use the transition tooling from RT for stuff like this? 18:56:18 we do have the permanent tracker that at https://release.debian.org/transitions/html/rust.html 18:56:47 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 f_g: good idea 18:57:23 f_g: If that's something we can express via ben files, yeah 18:58:30 I have no experience with ben, but AFAICT it's grep-dctrl on steroids? 18:58:35 (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 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 it would have the advantage of being continously run, also on non-debcargo-conf packages 19:00:00 and even if we have a semver-suffix package, it would then tell us when we can drop it ;) 19:00:13 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 hyper and friends will be on my agenda at some point in the next weeks, there's #1055918 for that already 19:02:02 #action werdahias plans for new gtk-rs release 19:02:23 #action f_g will go for hyper & co. in later weeks 19:02:42 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 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 ncts: filing a RM request once nothing depends on it anymore I guess 19:03:40 hmm, through the "completion" of the "transition" of a semver'd package I guess? 19:04:12 ben files? What are those 19:04:17 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 #info plugwash suggests transitioning hyper would be a "big bang" 19:04:31 capitol: ben is the tool used for transition tracking by the release team 19:04:45 https://debian.pages.debian.net/ben/ 19:04:45 #link https://debian.pages.debian.net/ben/ 19:05:00 #link https://release.debian.org/transitions/ 19:05:38 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 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 although, I guess filing transition requests would simplify the work of figuring out what needs to be updated 19:06:35 #info jamessan works on alacritty update, which involves a lot of intertwined packages, including wayland 0.29 -> 0.31 19:07:41 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 plugwash_: yes, but there has been progress on that part at least 19:08:22 ah ok, just struck me as weird that it wasn't updated too 19:08:32 I do not plan to ignore reqwest or patch that one myself :) 19:08:50 there's also debcargo-conf#56 19:10:01 #action f_g play around with ben and see if it's a good fit for bigger future transitions 19:11:30 thinking of versioned packages, a terrible idea came across my mind 19:12:17 jamessan: once the alacritty transition is done can we drop the wl-0,29 packages ? 19:12:43 I believe so, yes 19:13:12 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 ah neat. 19:13:48 last I looked alacritty was not the only user of wayland 0.29 19:14:54 ncts: it would still require bin-NEW but complicate things by merging an older version into the same source package? 19:15:37 there is also wl-clipboard-rs, but that have already moved to .31 upstream iirc 19:15:48 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 ah, https://salsa.debian.org/rust-team/debcargo-conf/-/issues/43 documents them, might be some extra updating 19:16:32 I can uplod those to exp too I guess to stage another transition 19:16:52 transitions are mostly covered I assume; werdahias: about the documentation part? and improvement part? 19:17:31 ah yeah, I intend to improve that by myself a bit 19:18:09 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 generally speaking, cdylibs? 19:19:04 So I'll write a wiki page then; imho such specific edge cases would warrant a documentation 19:19:07 yeah 19:19:45 yes, cdylibs crop up more nowadays, but doc improvement and tooling improvement would be great 19:19:55 sooner or later the same might apply for wasm things 19:20:13 #action werdahias writes a wiki page about building cdylibs 19:21:19 (though wiki and salsa .md's feel like separation of source of truth) 19:22:23 #info f_g suggests wasm things might also need the care 19:23:01 are there more general thoughts on docs and tooling? 19:23:19 ncts: well that's kinda an issue, but I tend to look more at the wiki 19:23:51 d-wiki should move to mediawiki imho, but that's OT here 19:24:26 I like in-source docs more because they have version control ;p wikis have too, tho 19:24:38 and wikis feel slow, frankly 19:24:49 but the point here is source of truth 19:25:22 so, moving on if no more thoughts on this 19:26:33 #topic lots of semver packages taged in experimental 19:26:43 s/taged/staged, eww 19:27:24 jamessan mentioned this, I assume the last one in part covered through transitions 19:28:26 yeah, I think we already discussed this :) 19:31:01 merged then ;) 19:31:28 any new topics? 19:32:38 * f_g got nothing else 19:33:02 * capitol neither 19:33:49 #topic next meeting 19:34:34 do we have next one in a month, as usual? 19:34:58 sound good imho 19:35:02 +s 19:35:23 +1 19:36:10 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 (it might be good to have a revisit item next time, haha) 19:37:30 without further ado 19:37:37 #endmeeting