16:58:32 <werdahias> #startmeeting 16:58:32 <MeetBot> Meeting started Thu Oct 26 16:58:32 2023 UTC. The chair is werdahias. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:32 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 16:58:48 <werdahias> #topic roll call, collecting 17:00:27 * stappers_ is present 17:01:04 * ncts observes 17:02:31 * f_g will be back in ~30m ;) 17:03:08 <werdahias> h01ger and jbicha are also present 17:03:40 * h01ger waves 17:03:53 <werdahias> anything urgent to add to the agenda before we move on to status updates? 17:05:00 <werdahias> ok, moving on .. 17:05:21 <werdahias> #topic status updates 17:06:02 <werdahias> #info work for cargo 0.70 still underway 17:06:58 <werdahias> #info rustc 1.70 landed in unstable/testing 17:08:29 <werdahias> #info gtk-rs +libadwaita is on par with upstream and (mostly) regenerated code to comply with dfsg 17:09:07 <werdahias> anything else from your side ? 17:10:45 <werdahias> #info f_g takes care of cargo 0.70 and a new debcargo release 17:13:27 <werdahias> unless someone wants to add something, I'd proceed to the next topic: transitions, packaging efforts and blockers 17:13:47 <werdahias> *blockers 17:14:19 <werdahias> #topic transitions / packaging efforts / blockers 17:14:36 * capitol is also present 17:15:59 <capitol> I'm wondering if anyone is working on hashbrown? gix needs 0.14 and it reexports some new symbols from 0.14 so it's not safe to downgrade 17:16:46 <werdahias> can it be bumped safely or do we need a semver ? 17:18:20 <capitol> haven't investigated, but I saw that a semver was prepared so i guess "no" 17:18:51 <capitol> maybe kpcyrd knows more 17:20:01 <werdahias> glancing at the last meetlog kpcyrd said they looked into it 17:20:47 <capitol> right, i'll follow up with him then :) 17:21:27 <werdahias> #action capitol and kpcyrd take a look at hashbrown transition 17:22:37 <werdahias> #info work on magic-wormhole-rs is progressing slowly but steady 17:23:59 <werdahias> anything else ? 17:24:51 <werdahias> #topic ITP for crates 17:25:53 <werdahias> revisiting from last time: since jonas continues to work outside the team and only checks wnpp this causes friction and deduplication 17:26:21 <stappers_> deduplication is much better as duplication :-/ 17:27:12 <werdahias> eh I meant duplication 17:28:22 <werdahias> I wrote a draft shell script to check if a crate has been packaged, but didn't have time to work on it further /integrate it into update.sh 17:28:24 <capitol> maybe we can do a bit of outreach and invite him to the next meeting or something? I have understood that there was some differences of opinion before, but maybe enough water have passed under the bridge now? 17:28:49 <capitol> h01ger: you know him a bit maybe? 17:29:48 * h01ger looks up 17:30:28 <h01ger> yes, i know him, but i'm not sure this will make much of a diff 17:30:56 <capitol> ok :) 17:31:21 <capitol> maybe we can make ./package.sh also send an ITP email 17:31:40 <werdahias> capitol: I'm all for it, but from my experience not much has changed 17:31:51 <werdahias> that was the idea, yeah 17:32:05 <capitol> aha, right :) 17:32:24 <werdahias> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/524 17:32:25 <fe2o3bot> merge_request rust-team/debcargo-conf 524 (opened): "initial ITP script draft" - https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/524 17:32:48 <werdahias> ah, I really need to use shorthands (: 17:33:42 <werdahias> I'd appreciate review/testing since I didn't really have the time to take a second look at it 17:34:05 <stappers_> #action learn which shorthands are provided by fe2o3bot 17:34:40 <werdahias> #action werdahias take a look at the ITP script 17:36:59 <werdahias> anything else for this topic ? then I'd move on to miscellaneous 17:37:15 <werdahias> #toptc miscellaneous 17:37:22 <stappers_> "non user consumable packages", special part of Debian archive a.k.a. special kind of Debian packages 17:37:27 <werdahias> #topic miscellaneous 17:37:31 <werdahias> yeah 17:38:02 <stappers_> Do we have a name for it? How should it be called? 17:38:20 <werdahias> I thought of main-dev as suite name 17:38:59 <stappers_> Sounds reasonable 17:39:10 <werdahias> the idea is that all libraries (including crates) that are just used to build other software should "live" there 17:40:57 <werdahias> stappers_: do you want to write a proposal to the d-devel ML maybe ? 17:41:27 <stappers_> #action stappers write a proposal for main-dev 17:41:39 <werdahias> nice :) 17:41:45 * f_g is back now 17:41:59 <f_g> it might be a good idea to get other teams in similar positions on board as well? 17:42:11 <stappers_> yes 17:42:14 <werdahias> agreed 17:42:17 <f_g> e.g., go and haskell work pretty similar AFAICT 17:42:39 <f_g> and probably a tentative "we won't NACK this in principle" from ftp-masters/RT would be good as well, but I am not sure how that would be best approached 17:43:10 <werdahias> ask them nice (: 17:43:27 <stappers_> and knowning that it makes sense 17:43:41 <werdahias> maybe list the advantages in the mail 17:44:45 <werdahias> jbicha: regarding your question(s): once an old crate is RM'd 17:44:45 <stappers_> (: the proposal will be more as just Subject: suite main-dev 17:45:07 <werdahias> we usually rm the src/crate directory as well 17:45:31 <f_g> (two more (possible) points for the agenda - possible rustc/cargo packaging merge, rustc -> crate autopkgtest trigger) 17:45:46 <werdahias> ncts did some mork on "dead" crate in the dcc-conf dir 17:45:55 <silwol> https://bugs.debian.org/949163 17:45:58 <fe2o3bot> Bug #949163: "Please provide a repo for packages not intent for users" - https://bugs.debian.org/949163 17:47:32 <stappers_> #link https://bugs.debian.org/949163 17:47:33 <fe2o3bot> Bug #949163: "Please provide a repo for packages not intent for users" - https://bugs.debian.org/949163 17:47:39 <werdahias> s/mork/work 17:49:13 <h01ger> oh, btw, as you (on irc) undoubtly noticed from me brabbling along here now sometimes: i'm a total newbee to rust and rust packaging (though i'm a somewhat experienced DD), so if i do silly (or just less than optimal) things, please do tell me. i want to be a good team member. my focus is sequoia packaging. 17:49:38 <werdahias> f_g: you wanted to talk about rustc updates ? 17:49:39 <f_g> #info I plan on merging my src:cargo update to 0.70 MR and put that into experimental soonish, src:rust-cargo still needs a few deps to go through NEW 17:50:00 <f_g> h01ger: welcome, and don't hesitate to ask and point out pain points :) new people are usually in a good position to do that ;) 17:50:08 <werdahias> +1 17:50:30 <f_g> werdahias: yes. I am not sure if it warrants its own topic? 17:50:32 <stappers_> so true 17:51:01 <stappers_> so true ( new people are usually in a good position to do that ;) 17:51:19 <h01ger> f_g: werdahias: thank you. i generally feel very welcome here, so thank you all too! 17:52:30 <werdahias> f_g: if it just status updates we can fit it in here, unless you want a seperate topic 17:53:12 <f_g> no status update, just the open question of whether we want to merge src:cargo and src:rustc 17:53:47 <werdahias> what would the advantages be ? 17:54:15 <f_g> Ubuntu recently did it, so it would make collaboration in both directions easier. 17:54:38 <f_g> besides that, it moves us closer to upstream 17:54:55 <werdahias> right 17:54:58 <f_g> they publish the whole toolchain including cargo and rustc in lockstep 17:55:27 <f_g> and it would allow us to get rid of the ugly "try to sync patches between vendored sources and debcargo-conf" dance that we do right now, which is a major PITA when upgrading cargo 17:55:42 <f_g> since the vendoring is a moving target that changes every day 17:56:13 <f_g> the main downside is that it could make us complacent and let more stuff slip through via vendoring that we currently patch out via that ugly dance ;) 17:56:45 <werdahias> well I know next to nothing about the toolchaing but if it makes the packaging/updates easier and seems like a sensible choice I'm all for it 17:56:53 <f_g> both src:cargo and src:rustc currently vendor their whole dependency tree, with pruning for Debian mixed in, but that pruning happens via patches for rustc+tools, and by re-using debcargo-conf for cargo atm 17:57:14 <h01ger> and upstream its one git repo? 17:57:50 <f_g> yes and no. upstream development happens in a separate repo, but that one is synced into the main rust one. the release artifacts are built from the rust one upstream 17:58:25 <h01ger> and ubuntu has it merged / follows upstream? 17:58:40 <f_g> yes 18:00:08 <f_g> rust-analyzer, clippy, rustfmt are also developed (and released) in the same fashion upstream, and we have those in src:rustc as well already 18:00:15 <f_g> well, rust-analyzer only partially 18:00:49 <werdahias> #action f_g explore merging of src:rust and src:cargo 18:01:20 <h01ger> f_g: i'm guessing you're the one involved in src:rust in debian, so what are the people maintainign src:cargo saying to this proposal? 18:01:36 <f_g> I did the bulk of the work for both in the recent past :-P 18:01:43 <h01ger> :) 18:02:03 <f_g> (it was my gateway into this team and DM-ship ;)) 18:02:25 <f_g> (or rather, the final push to step up and get more involved) 18:02:34 <h01ger> another idea would be to file a wishlist bug and explore pro & contras there, giving people a place to read about the proposal and object/modify 18:03:16 <f_g> that sounds like a good idea. I'll try to summarize it tomorrow and file it, and then we could also point ftp-master people at it so that they can chime in if they feel like they want to 18:03:45 <f_g> I will be away for the next week, so at least 10 days or 14 before I would start doing any practical work anyhow 18:04:11 <f_g> #action f_g file wishlist bug for discussing merge of src:cargo into src:rustc 18:04:27 <jbicha> I wish we should stop setting skip-not-installable for all our autopkgtests 18:04:40 <h01ger> letting that settle for 1-2 weeks surely will not hurt 18:06:38 <f_g> jbicha: because you think it hides real issues? 18:07:28 <jbicha> f_g: yes, maybe allow opting in to skip-not-installable and see how much it is needed, but I don't think it should be the default any more 18:09:27 <f_g> switching it to opt-in shouldn't be too hard I guess, and might make issues more obvious earlier on 18:10:00 <jamessan> It should only be used if we are explicitly uploading without dev-dependencies packaged, which we be good to avoid where possible. 18:10:08 <jbicha> it may make migrating big transitions (like gtk) harder but maybe we just need to tighten our dependencies 18:13:28 <f_g> I mean, we already have test_is_broken that is used to pass in "flaky", we could modify or extend that to pass in an arbitrary restriction instead.. or add a second field that works the same way 18:13:39 <f_g> then we could also mark tests as requiring root, or other shenanigans 18:14:34 <f_g> any takers for writing the MR for something like that? :) 18:15:03 <jbicha> btw, some of the gtk autopkgtests need a test-command-prefix of xvfb-run now. We've been adding that manually 18:15:53 <werdahias> yeah that's a debcargo limitation that yu have to manually create and update d/t/control 18:17:29 <f_g> well, adding a prefix in debcargo.toml would be doable I guess? we already have one for extra test dependencies 18:17:58 <werdahias> that'd be an improvement 18:19:02 <f_g> those two changes would likely touch similar places, so might be best to have a single person working on it 18:19:07 <jamessan> There's a lot of room for improvement in the test handling :) 18:20:01 <f_g> yes, like 18:20:06 <f_g> debcargo#59 18:20:07 <fe2o3bot> issue rust-team/debcargo 59 (opened): "generate correct tests/control with prerelease version" - https://salsa.debian.org/rust-team/debcargo/-/issues/59 18:20:13 <jamessan> Like declaratively excluding testing of certain features or requiring a certain feature to be present, although hopefully the latter dies out some with the "dep:..." stuf 18:20:14 <f_g> debcargo#58 18:20:15 <fe2o3bot> issue rust-team/debcargo 58 (opened): "Please make Test-Command configurable" - https://salsa.debian.org/rust-team/debcargo/-/issues/58 18:20:28 <f_g> debcargo#51 18:20:29 <fe2o3bot> issue rust-team/debcargo 51 (opened): "Allow test_is_broken for specific arches" - https://salsa.debian.org/rust-team/debcargo/-/issues/51 18:20:38 <f_g> and debcargo#40 18:20:39 <fe2o3bot> issue rust-team/debcargo 40 (opened): "marking tests for all features case as not broken doesn't work." - https://salsa.debian.org/rust-team/debcargo/-/issues/40 18:21:24 <f_g> jamessan: excluding testing of certain features should work via test_is_broken, but it's a bit cumbersome to write out 18:21:49 <werdahias> since we're discussing debcargo: anything speaking against the merge of debcargo!51 18:21:50 <fe2o3bot> merge_request rust-team/debcargo 51 (opened): "Draft: Switch dh compat to 13" - https://salsa.debian.org/rust-team/debcargo/-/merge_requests/51 18:21:57 <f_g> having a way to say "test foo requires feature bar" would save us a few patches for sure 18:22:09 <f_g> "test for feature foo", that is 18:22:26 <f_g> because upstreams often only test a certain feature set, and not every feature on its own like we do (by default) 18:22:38 <f_g> and often there are features that are not meant to be used on their own at all 18:22:52 <jamessan> Or "all tests require feature foo", where the crate requires one of N features to be enabled to be able to run 18:22:55 * capitol have sent a lot of such patches upstream 18:23:10 <jamessan> (like "x11" vs "wayland") 18:23:10 <f_g> jamessan: looking at sequoia :-P 18:23:11 * werdahias nods 18:23:29 <h01ger> compat 13 seems reasonable to me, i was surprised to see 12. (but what do i know.) 18:23:41 <h01ger> same for policy 4.6.1, 4.6.2 is current 18:23:44 <f_g> werdahias: I left my "senf" already in the issue, but agree :) 18:24:14 <f_g> I think any potential downfall would be in "special" packages anyhow (or rather, their overrides), and not in the stuff that debcargo generated 18:24:20 <werdahias> ah right, didn't see that 18:24:54 <stappers_> #idea next topic or closing the meeting 18:25:03 <werdahias> h01ger: capitol bumped standards version but the current debcargo does not have it 18:25:19 <werdahias> nothing from my side 18:25:40 <f_g> the test trigger stuff was already discussed here, I'd add it to debcargo unless somebody objects 18:26:11 <f_g> the idea was to let all crates be triggered by toolchain updates - right now it's only dh-cargo (and the test dependencies between crates of course) 18:26:39 <f_g> so that we uncover rustc/cargo regressions faster and can hopefully also attribute them more clearly 18:26:54 <jamessan> I have a WIP for the rustc trigger. I just hadn't added any tests yet. 18:27:18 <jamessan> Was also waiting for a bug fix in dpkg, because currently dpkg doesn't generate Testsuite-Triggers if there's an arch-qualified test Depends 18:27:47 <f_g> okay, great. we already got an ack from elbrus for that btw 18:28:41 <werdahias> #topic next meering 18:28:55 <werdahias> *meeting, sorry 18:29:49 <werdahias> (unless there's anything else I'd discuss the next meet and close it then) 18:30:19 <f_g> roughly in a month? I guess it might make sense to either skip December after that, or have it earlier, or have an informal one in Hamburg for those who manage to snag tickets and are there 18:31:12 <werdahias> right, ccc is happening 18:32:16 <werdahias> how does everyone fell about the day of week ? rather move it tho the weekend or are workdays ok ? 18:32:32 <werdahias> s/fell/feel 18:34:10 <f_g> for me most days work except for Fridays (provided it's far enough in advance, of course) 18:36:43 <capitol> thursdays are good for me 18:37:08 <werdahias> #action next meet in ca. a month, date and orga tbd 18:37:49 <jbicha> Nov 23 is a US holiday so wouldn't work for me 18:38:18 <werdahias> we could do 30th 18:42:24 <werdahias> #action werdahias do a poll for a date 18:42:55 <werdahias> anything else ? otherwise I'd end the meet 18:43:07 <f_g> nothing from me, thanks for setting it up and moderating! 18:43:49 <werdahias> yw, one more skill to add to the cv :> 18:43:52 <werdahias> #endmeet 18:44:19 <werdahias> #endmeeting