18:58:41 #startmeeting 18:58:41 Meeting started Wed Oct 28 18:58:41 2020 UTC. The chair is stappers. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:58:41 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:58:45 Welcome 18:59:42 hello :) 19:00:21 * Ganneff will be around in ~10minutes 19:00:37 Acknowledge 19:01:35 20:02 * Ganneff will be around in ~10minutes 19:01:35 20:02 < stappers> Acknowledge 19:01:35 20:02 -!- waldi [~waldi@shell.thinkmo.de] has joined #debian-rust 19:01:55 moin 19:02:02 should we collect agenda items while we wait a bit for missing people to show up? 19:02:52 * Collaboration with FTP-masters 19:03:03 * Avoiding Section: FIXME 19:03:12 * .... 19:03:26 * ..... your input 19:03:37 * current packaging projects requiring coordination/help 19:03:56 * upcoming freeze and things to keep an eye out for 19:05:48 * toolchain updates (/ rustfmt / clippy) 19:08:56 Added to https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda and more agenda items welcome. 19:11:38 Pinging some of the usual suspects dkg infinity0 kpcyrd p2-mate pabs tmarble as reminder on the meeting 19:11:54 19:12:31 * stappers is happy that FTP-master team members are present 19:13:22 ping sylwol Sylvestre too (though Sylwol is not on the channel apparently) 19:13:27 . 19:13:29 * stappers is fully aware that Debian is about working together 19:14:00 gah. sorry I'm late chaps - just took 16 minutes to get 'idenitified' so I can join this channel 19:14:22 Ganneff: How usefull was the mailinglist input? 19:14:28 silwol is here over the Matrix-IRC bridge which is often flakey and AFAIU, this is not obviously visible when it happens 19:14:38 did you know that freenode and OFTC have the identify paramaters the opposite way round? 19:14:44 I mean, he's not here now, but when he is here he is here over the bridge ;) 19:15:09 f_g : like myself actually 😉 I would see him in that bridged room 19:15:19 ah okay :) 19:16:28 stappers: i havent read all of it yet, and im sorry for that. but what i read was mostly good. I do understand a bit more of the problem and how you try to deal with it. yet i still hate it, though most of it comes from the way debian is. 19:17:09 now, i dont buy that time argument we got and am on the side that size does matter, not everyhwere has good internets... 19:18:14 from all of what i read, my *CURRENT* favorite tends to go to "an own archive for "dependency/not-user-facing/build-only" packages 19:18:40 where this wouldnt matter, as it would mostly be used by buildds *or* people who explitcitly want it. 19:19:31 Has there been mailing list discussion of the great 'rust in debian/debcargo' issue somewhere that I missed? 19:19:38 that obviously means either statically linking (works for golang) or a split in "only empty feature packages go there" for rust. 19:20:02 rust already (mostly) statically links 19:20:11 as main should be self contained should still hold true. 19:20:15 easier then. 19:20:38 obviously that means that for building this self-contained must include that. 19:20:41 at least for the time being, it's not as clear cut as with golang whether it will stay that way forever 19:20:52 wookey: see https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-October/013373.html 19:21:26 oh, and im happy for any better solution, but if its the feature package approach, those in main archive is not feasible. 19:21:41 so, toolchain + related core crates + binary application packages go to main, the rest of -dev + feature packages which are only b-d of applications and themselves go to this new 'devel' or whatever archive? 19:21:55 thanks hntourne 19:22:24 you'r welcome :-) 19:22:31 f_g: yup. anything a "normal" user would need for a daily use, goes main. stuff thats expected only to build things goes over elsewhere. 19:22:34 whatever the name will be. 19:23:17 f_g: like,m golang people say "people are expected NOT to ever use our packages, they are just there for compilation. if you want to use them for oen devel foo, use go get". -> over 19:23:48 s/oen/own/ 19:24:02 we do the same at $dayjob ('devel' repo with toolchain backports + all the librust-foo stuff, the end-user facing packages go to the regular repo. both are public) 19:24:24 the devel repo which is mostly rust is 10x as big as the regular one ;) 19:24:35 so this was an obvious choice to make 19:24:43 "an own archive" / "an dedicate corner in the debian archive" sounds to me like a path we can explore 19:25:10 stappers: own archive similar to the debug one. 19:25:36 waldi: Ganneff is this something you discussed in ftp-masters and that the whole team agrees on as one avenue forward? 19:25:41 Ah, like something that has been do before 19:25:52 I find it hard to believe that there is so much rust stuff that it cannot fit in the debian archive with sensible design 19:26:09 if rust does link statically, its plenty simple to do. if there is any lib that needs to be partially there and over there too, that gets more interesting. 19:26:37 f_g: we had some short discussions, but not a formal team decision. 19:27:09 rust does current favour static linking due to unstable ABI, but that will hopefully change over time 19:27:10 wookey: if you have a design that does not need this and does not have current troubles -> get it to us. 19:27:43 most packaged rust applications depend on libc and libgcc/libclang and that's it ;) any extra deps are usually C libraries linked in, those are in main anyway. all the rust stuff is statically linked 19:27:52 I do not yet. I am quite new to this area. BUt of course, if I get sufficient understanding to work out a solution I will tell all :-) 19:28:31 A design that bakes static linking in in debian does not seem like a good long-term plan. 19:29:01 obviously this also ought to be passed by release people. especially if we need a testing something over in that other area. 19:30:07 Why the hesitation of "rus like debug archive section"? Is there a downside? (And how large/small is that possible downside?) 19:30:21 wonder how hard it would be to adapt tools like apt to deal with smaller stanzas in packages files. 19:30:26 Why the hesitation of "Rust like debug archive section"? Is there a downside? (And how large/small is that possible downside?) 19:30:30 Ganneff: if you want to look at a non-trivial example, `apt show spotify-tui` shows the rust B-D vs runtime dependency situation quite well 19:30:41 ie, the ton of feature ones consisting of 3 lines instead of 3 dozens 19:31:02 f_g: nah, im on stable here. :) 19:31:31 slow packages.d.o is slow 19:31:52 from my view there are several problems: the empty feature packages just to isolate build-deps; a lot of build-dep cycles; missuse of arch-any packages for only source; the over large provides lines. some can be isolated into it's own archive, some not 19:32:29 stappers: downside is that its an own archive. buildds need to add it. we need a kind of release management and suites in it, possibly somehow/best tied to actual testing. lots to work out in detail 19:32:54 Acknowledge 19:33:53 the large provides lines i *personally* dont have so much a problem with. tools breaking there should be fixed. (though thats not a freeby for megabyte big ones :) ). 19:34:09 waldi: some of that can probably be cut down, but resources for adapting debcargo are severily lacking, and most of those changes/PoC require changing core logic there. I am not aware of many build-dep cycles, but there are a lot of test-dep cycles 19:35:19 (stemming from upstream, which often develops sets of crates together including testing them as one set, assuming they are all available in matching versions since that's how they are in git, but then publishing as separate crates) 19:36:05 f_g: someone (I think it was you) was going to go away and look at modifying debcargo to not split out features into packages automatically. Has that progressed at all or are we waiting for tuits in the small number of people with relevant skills? 19:36:24 Ganneff: I think we all agree that web-sys is a misuse features upstream and shouldn't be mapped as-is to Debian. upstream disagrees on the former part, but if need be we can patch that out downstream 19:36:29 f_g: nothing restricts you in just bundling them into one package 19:36:37 (I've not done anything either) 19:37:03 wookey: it's basically blocked on me not returning ENOTIME all the time :-/ 19:37:47 I think infinity0 is not very motivated to implement that since he disagrees, and me and silwol are the only other ones that have hacked even a little bit on debcargo in the past year 19:38:25 waldi: for one, it's about the same effort in debcargo as adapting all the feature logic (one crate == one source package is a core assumption as well) 19:39:03 2. upstream does not guarantuee that they release a new version of all crates at the same time every time, or that they will do so in 6 months just because they do so now 19:39:29 the feature thing is not a seperate crate, but just different ways of using one, right? 19:39:35 yes 19:39:56 ok. so one crate == one source is fine. 19:40:05 it's a combination of configure flags/conditional compilation and optional dependencies thrown into the same namespace 19:40:32 we have sillier languages that put 3line functions in an own package due to $censored... 19:40:38 they are also used to break source cycles. aka: crate a with "notb", crate b with "notc", crate c with "nota" 19:40:52 so one crate as one source works nicely.. 19:41:00 now that sounds like feature, not different source. 19:41:20 :-) 19:42:03 it's usually two things - allow switching out some external implementaiton (think TLS libraries), and disabling some not-often used part of a crate (possibly with additional deps, like graphical GUI) 19:42:47 f_g so like emacs and emacs_nox 19:43:00 wellll. building with either gnutls or openssl rightfully ought to create two resulting packages 19:43:09 i would expect the bianries in them different 19:43:15 * stappers thinks that disabling not-often used parts makes sense. 19:43:18 (damn, cant write today) 19:43:44 Ganneff: the librust-foo packages only contain source code. so the end application would either depend on librust-foo+openssl-dev or librust-foo+gnutls-dev or librust-foo+rustls-dev 19:44:17 and the resulting application/bin package would of course be different if you switch that build-dependency 19:44:30 well. then that ought to be represented from ONE package to b-d on. 19:44:54 here we are at the feature flag packages or not, again, i think :) 19:45:02 'b-d' in this context means ... 19:45:09 build-dependency 19:45:15 thanks 19:45:59 so source code is always in the main -dev package, the empty ones provide the appropriate build-dependency information to encode "I want to compile this with the feature linking against openssl" 19:46:27 and if there are two features that are not co-installable, then we need two separate empty bin packages that encode this build-dep information 19:46:38 though, from what I know, merging the empty stuff into just the one with the source will make the provides go up to the sky. except for that, does it make more problems? 19:46:57 not co-installable due to different dependencies the features need that conflict, right? 19:47:03 yes 19:47:05 Ganneff: the provides are also per feature, so it will shrink 19:47:17 f_g: do you have an example? 19:47:41 waldi: oh, i would think keeping the list of possible features on par with upstream, so i would assume the provides haas them all listed 19:48:26 of such a co-installability problem? no concrete one by heart (debcargo auto-resolves them at the moment ;)) 19:48:28 Ganneff: but it does not need to list the cross product like currently 19:48:40 k 19:48:49 IIUC: Defining only one build-dependency will cause only one package. Example given: gnutls-dev as b-d will only yield librust-foo-gnutls-dev 19:48:53 but e.g., libssl-dev vs libssl1.0-dev might show up if you have some compat feature 19:49:29 waldi: I agree on that and think that at least the version stuff should go, but it's not something that is implemented yet or tested/evaluated 19:50:54 IMHO it would be better to explicitly have to say "I want to use librust-foo in outdated version X" which would re-write the generated build-depends from librust-foo-dev to librust-foo-X-dev and skip all the librust-foo-x-dev librust-foo-x.y-dev librust-foo-x.y.z-dev provides that are generated now 19:51:03 ok, before this runs for ages, does anyone more knowledged in rust matters than me has a nice idea to resolve this in a way we all will like? 19:51:45 we discussed it more in-depth already, with plans for proofs of concepts for reducing provides/features/bin package amount, but nothing material yet 19:52:24 infinity0 as the main author behind debcargo(-conf) disagrees with that and would like debian processes to adapt more to how rust works to avoid introducing more friction into the packaging workflow 19:52:52 I guess most people would be fine with some sort of middle-ground 19:53:03 sensibly reduce where possible without a lot of manual effort, or something like that ;) 19:53:17 Ganneff: as f_g said, we dsicussed a plan to reduce the combinatorial explosion, but it needs some analysis to see how mch differenc eit would make/if there are problems and b) someone to do the work 19:53:30 possible with the outlook of having a separate repo post-bullseye when packaging work will ramp up again 19:54:06 since my guess is the main effort for the next months will be keeping applications which are already packaged in archive during the freeze, and not big reworks and mass-uploads of outstanding work ;) 19:54:28 not many people understand this enough to help. 19:54:55 i can somewhat agree with him being frustrated, though i am on the opposite of it... unfortunately unable to help in the rust world. 19:55:01 not many people yet understand this enough to help. 19:55:41 * f_g is not pretending to understand all of it either - e.g. the arch:any issue is over my head 19:55:54 infinity0: do know that Ganneff understands you and does a reach out. 19:56:11 f_g: debcargo source contains a comment: we workaround a dpkg/archive/whatever bug 19:56:54 I know - I think I don't understand enough details of M-A to grasp that 19:57:33 f_g: I should be able to help you with M-A stuff as I helped design that 19:57:37 so, can we condense some action item out of the last hour? 19:58:15 - ftp team to talk about a build-only archive and talk to release team about it 19:58:18 Ganneff: I think the old ones still stand - investigate features/versions/provides/bin package reduction, implement PoCs (silwol and me) 19:58:44 a new one what waldi just said (with input/help by rust-/golang-team people?) 19:59:09 right, those are two. stappers, you are chair, could you !action or !note or !info (or whatever) them? 19:59:20 #action ftpteam to talk about a build-only archive and talk to release team about it 19:59:31 (how often do you have those meetings in here?) 19:59:37 monthly 19:59:44 last wednesday 19:59:44 last wed of month 7pm 20:00:02 (this is only the fourth one or so though ;)) 20:00:11 https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda 20:00:11 ok. can talk then again if we got any further on our items. (someone please remind me a week before, thanks) 20:00:24 #action (silwol and f_g) investigate features/versions/provides/bin package reduction, implement PoCs 20:00:29 now, before we close... 20:00:58 i wont approve the current set of rust packages in NEW that contains empty feature packages. (any without pass as usual). 20:01:21 i can either hold them rrrrrrrrrrrrrrrrreeeeeeeeeeeally long until we may have a solution, or reject them to be clear. any preference? 20:01:22 * stappers thinks that is fair enough 20:02:08 (not to be wrong, rust packages usually are an easy bunch in new. good packaging, easy to check, so from that point they would pass) 20:02:23 "any preference?" Reject and tell why 20:02:29 Either a new archive or a reduced feature set will require new uploads, won;t it? So you might as well reject them 20:02:38 k 20:03:02 wookey: yes. although a reduced feature set would still mean empty bin packages, just less of them with less provides ;) 20:03:30 if that "less" is *WAY* *WAY* less, then that could be acceptable too. 20:03:34 I think we can work around any urgent things by just manually patching stuff out (e.g. to fixup stuff for the freeze / prevent RMs) 20:03:39 fewer :-) Yes, but hopefully we will have reached agreement with FTPmaster on what is 'reasonable' by then. 20:04:27 ok, so i think for today, im out, and thanks for dealing with me silly old ftpmaster :) 20:04:42 Very useful for you to turn up. So thanks 20:04:46 Ganneff: thanks for joining and your input! 20:04:56 waldi as well, of course ;) 20:05:33 ftpmaster: the oldest package in NEW is rust-jemallocator, 1 year meanwhile, please reject it. My reason for: Remove the thing that could be (wrongly) explained as "FTPmaster do let it rot in the archive" 20:06:03 Ganneff: please make sure the rejects have an explanatory message, so uploaders know what is going on. 20:06:25 not everyone is following along here 20:06:54 should we proceed to the next point? 20:06:57 yes sir. (condensed one) 20:07:10 ;-) 20:07:42 #topic Avoiding Section: FIXME 20:08:05 * stappers thinks it happened by mistake 20:08:56 reject with "Invalid Section" will help the learning process. 20:09:20 Other opinions on this??? 20:09:41 lintian checks 20:09:43 yeah, was a mistake for sure 20:10:02 happened by mistake at least twice, and lintian does notice. thats why i mnentioned it in here 20:10:10 maybe we could make ./release.sh more robust w.r.t. to those errors 20:10:29 #agreed lintian check before upload 20:10:57 #idea make ./release.sh more robust w.r.t. lintian errors 20:11:05 stappers: agreed that this was a mistake, ./build.sh runs lintian so maybe ./release.sh should refuse uploading if there are lintian errors? 20:12:04 sounds good to me 20:12:24 #agreed that '#agreed lintian check before upload' was too fast ... 20:12:44 I mean, release.sh does not do the actual upload, right? (not a DD/DM) so it can just do lintian + SHOUT 20:12:55 #action ./release.sh should refuse uploading if there are lintian error 20:13:37 ah, it does for RERELEASE, but otherwise it just tells you to dput 20:14:41 20:14:49 and it checks for FIXME, but just in the git-tracked src/ , not in the generated files so that could be extended as well 20:15:37 What about a 15minute break before next topic? ( Yes, I would like to have a break ) 20:15:47 where does release.sh come from? I don't see it in debcargo source 20:16:11 wookey: debcargo-conf 20:16:39 it's a wrapper like build.sh, but for doing some final checks and creating the pending-foo branch 20:17:00 * stappers returns at 20:30UTC and please feel free to continue with out me 20:17:32 ack 20:17:45 you may want to addchair someone 20:17:48 any volunteers for extending release.sh? ;) 20:19:53 maybe. lets have a look... 20:29:14 volunteers for addchair 20:29:18 volunteers for addchair? 20:29:55 #topic Current packaging projects requiring coordination/help 20:30:39 hntourne and me discussed proceeding with futures+gtk in the backlog, any other big things going on/being worked on? 20:31:19 This is one part, beside this big chunk I am looking at Fractal dependencies more in general 20:32:42 Would like to sort that part first since most of missing fractal deps depend on updated gtk version 20:34:42 Thing I, dd, can do is sponsoring uploads of GTK stuff needed for fractal. 20:35:57 More on this topic? 20:36:22 that would be very heplfull stappers, I will be reaching out to you on this then :-) 20:36:33 Please do 20:36:58 Same for simular stuff 20:37:16 20:37:21 #topic Upcoming freeze and things to keep an eye out for 20:38:10 that one should be a quick I think :) 20:38:27 just be extra mind-ful when doing uploads to not break dependency chains of applications already in the archive 20:39:04 Have we tooling to help with that? 20:40:03 yes, list-rdeps.sh 20:40:07 in dev/ 20:40:33 right, yes I personnally always use that one :-) 20:40:51 also, keeping an eye out on autoremovals/bugs is extra-important in the next months 20:41:37 #note awareness on dependency chains before uploading, tool: list-rdep.sh from dev/ 20:42:29 we don't have that many applications anyway, so when in doubt it can also be easier sometimes to just rebuild them with your updated packages ;) 20:44:24 f_g / stappers : dev/rust-excuses.mk refresh all seems usefull too - will list what fails to transition to testing due 20:44:49 See RELEASE.rst - never tried it myself 20:46:52 20:46:59 #topic Toolchain updates (/ rustfmt / clippy) 20:48:22 another short one. if nobody else does it faster I'll take a stab at toolchain updating in 3-4 weeks, and also revisit whether we can finally package rustfmt/clippy. I'll coordinate with infinity0 as usual in here and via MRs to the respective repos 20:48:49 OKay 20:49:38 this might fix issues people have been reporting with some crate's Cargo.lock files 20:50:02 it might make sense to collect instances of those somewhere - maybe issues in debcargo's salsa repo? 20:53:31 On short term fine, on long term not so fine. Might be mitigated by having "export issues function". 20:54:53 stappers: bug reports in bugs.d.o are fine for me as well, or a ping in here - newcomers might feel more comfortable with salsa though 20:54:53 And do know that having some central place is better then scattered collections ... 20:55:46 f_g: Which package will be using for the "collection"? 20:55:55 f_g: Which package will we be using for the "collection"? 20:56:51 it's probably an issue with debcargo (or the version of rust-cargo that it's linked with), so I'd say that one should be fine 20:58:29 :-) Obvious now you say it :-/ 20:58:52 20:59:18 #topic last minute entries 21:02:52 none? ;) 21:02:59 ;) 21:03:02 21:03:16 #topic mailinglist debian-rust 21:03:33 No news from listmasters 21:04:52 #action stappers does another retransmit to express we want/need a discussion ML beside the auto-generated traffic mailinglist 21:05:28 #endmeeting