18:58:41 <stappers> #startmeeting
18:58:41 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:58:45 <stappers> Welcome
18:59:42 <f_g> hello :)
19:00:21 * Ganneff will be around in ~10minutes
19:00:37 <stappers> Acknowledge
19:01:35 <stappers> 20:02  * Ganneff will be around in ~10minutes
19:01:35 <stappers> 20:02 < stappers> Acknowledge
19:01:35 <stappers> 20:02 -!- waldi [~waldi@shell.thinkmo.de] has joined #debian-rust
19:01:55 <waldi> moin
19:02:02 <f_g> should we collect agenda items while we wait a bit for missing people to show up?
19:02:52 <stappers> * Collaboration with FTP-masters
19:03:03 <stappers> * Avoiding Section: FIXME
19:03:12 <stappers> * ....
19:03:26 <stappers> * ..... your input
19:03:37 <f_g> * current packaging projects requiring coordination/help
19:03:56 <f_g> * upcoming freeze and things to keep an eye out for
19:05:48 <f_g> * toolchain updates (/ rustfmt / clippy)
19:08:56 <stappers> Added to https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda and more agenda items welcome.
19:11:38 <stappers> Pinging some of the usual suspects dkg infinity0 kpcyrd p2-mate pabs tmarble    as reminder on the meeting
19:11:54 <stappers> 
19:12:31 * stappers is happy that FTP-master team members are present
19:13:22 <hntourne> ping sylwol Sylvestre too (though Sylwol is not on the channel apparently)
19:13:27 <Ganneff> .
19:13:29 * stappers is fully aware that Debian is about working together
19:14:00 <wookey> gah. sorry I'm late chaps - just took 16 minutes to get 'idenitified' so I can join this channel
19:14:22 <stappers> Ganneff: How usefull was the mailinglist input?
19:14:28 <f_g> 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 <wookey> did you know that freenode and OFTC have the identify paramaters the opposite way round?
19:14:44 <f_g> I mean, he's not here now, but when he is here he is here over the bridge ;)
19:15:09 <hntourne> f_g : like myself actually 😉 I would see him in that bridged room
19:15:19 <f_g> ah okay :)
19:16:28 <Ganneff> 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 <Ganneff> 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 <Ganneff> 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 <Ganneff> where this wouldnt matter, as it would mostly be used by buildds *or* people who explitcitly want it.
19:19:31 <wookey> Has there been mailing list discussion of the great 'rust in debian/debcargo' issue somewhere that I missed?
19:19:38 <Ganneff> that obviously means either statically linking (works for golang) or a split in "only empty feature packages go there" for rust.
19:20:02 <f_g> rust already (mostly) statically links
19:20:11 <Ganneff> as main should be self contained should still hold true.
19:20:15 <Ganneff> easier then.
19:20:38 <Ganneff> obviously that means that for building this self-contained must include that.
19:20:41 <f_g> 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 <hntourne> wookey: see https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-October/013373.html
19:21:26 <Ganneff> 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 <f_g> 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 <wookey> thanks hntourne
19:22:24 <hntourne> you'r welcome :-)
19:22:31 <Ganneff> 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 <Ganneff> whatever the name will be.
19:23:17 <Ganneff> 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 <Ganneff> s/oen/own/
19:24:02 <f_g> 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 <f_g> the devel repo which is mostly rust is 10x as big as the regular one ;)
19:24:35 <f_g> so this was an obvious choice to make
19:24:43 <stappers> "an own archive" / "an dedicate corner in the debian archive" sounds to me like a path we can explore
19:25:10 <Ganneff> stappers: own archive similar to the debug one.
19:25:36 <f_g> waldi: Ganneff is this something you discussed in ftp-masters and that the whole team agrees on as one avenue forward?
19:25:41 <stappers> Ah, like something that has been do before
19:25:52 <wookey> 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 <Ganneff> 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 <Ganneff> f_g: we had some short discussions, but not a formal team decision.
19:27:09 <wookey> rust does current favour static linking due to unstable ABI, but that will hopefully change over time
19:27:10 <Ganneff> wookey: if you have a design that does not need this and does not have current troubles -> get it to us.
19:27:43 <f_g> 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 <wookey> 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 <wookey> A design that bakes static linking in in debian does not seem like a good long-term plan.
19:29:01 <Ganneff> 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 <stappers> Why the hesitation of "rus like debug archive section"?  Is there a downside?   (And how large/small is that possible downside?)
19:30:21 <Ganneff> wonder how hard it would be to adapt tools like apt to deal with smaller stanzas in packages files.
19:30:26 <stappers> Why the hesitation of "Rust like debug archive section"?  Is there a downside?   (And how large/small is that possible downside?)
19:30:30 <f_g> 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 <Ganneff> ie, the ton of feature ones consisting of 3 lines instead of 3 dozens
19:31:02 <Ganneff> f_g: nah, im on stable here. :)
19:31:31 <Ganneff> slow packages.d.o is slow
19:31:52 <waldi> 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 <Ganneff> 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 <stappers> Acknowledge
19:33:53 <Ganneff> 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 <f_g> 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 <f_g> (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 <wookey> 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 <f_g> 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 <waldi> f_g: nothing restricts you in just bundling them into one package
19:36:37 <wookey> (I've not done anything either)
19:37:03 <f_g> wookey: it's basically blocked on me not returning ENOTIME all the time :-/
19:37:47 <f_g> 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 <f_g> 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 <f_g> 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 <Ganneff> the feature thing is not a seperate crate, but just different ways of using one, right?
19:39:35 <f_g> yes
19:39:56 <Ganneff> ok. so one crate == one source is fine.
19:40:05 <f_g> it's a combination of configure flags/conditional compilation and optional dependencies thrown into the same namespace
19:40:32 <Ganneff> we have sillier languages that put 3line functions in an own package due to $censored...
19:40:38 <waldi> they are also used to break source cycles. aka: crate a with "notb", crate b with "notc", crate c with "nota"
19:40:52 <Ganneff> so one crate as one source works nicely..
19:41:00 <Ganneff> now that sounds like feature, not different source.
19:41:20 <stappers> :-)
19:42:03 <f_g> 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 <wookey> f_g so like emacs and emacs_nox
19:43:00 <Ganneff> wellll. building with either gnutls or openssl rightfully ought to create two resulting packages
19:43:09 <Ganneff> i would expect the bianries in them different
19:43:15 * stappers thinks that  disabling not-often used parts makes sense.
19:43:18 <Ganneff> (damn, cant write today)
19:43:44 <f_g> 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 <f_g> and the resulting application/bin package would of course be different if you switch that build-dependency
19:44:30 <Ganneff> well. then that ought to be represented from ONE package to b-d on.
19:44:54 <Ganneff> here we are at the feature flag packages or not, again, i think :)
19:45:02 <stappers> 'b-d' in this context means ...
19:45:09 <Ganneff> build-dependency
19:45:15 <stappers> thanks
19:45:59 <f_g> 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 <f_g> 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 <Ganneff> 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 <Ganneff> not co-installable due to different dependencies the features need that conflict, right?
19:47:03 <f_g> yes
19:47:05 <waldi> Ganneff: the provides are also per feature, so it will shrink
19:47:17 <waldi> f_g: do you have an example?
19:47:41 <Ganneff> 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 <f_g> of such a co-installability problem? no concrete one by heart (debcargo auto-resolves them at the moment ;))
19:48:28 <waldi> Ganneff: but it does not need to list the cross product like currently
19:48:40 <Ganneff> k
19:48:49 <stappers> 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 <f_g> but e.g., libssl-dev vs libssl1.0-dev might show up if you have some compat feature
19:49:29 <f_g> 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 <f_g> 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 <Ganneff> 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 <f_g> 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 <f_g> 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 <f_g> I guess most people would be fine with some sort of middle-ground
19:53:03 <f_g> sensibly reduce where possible without a lot of manual effort, or something like that ;)
19:53:17 <wookey> 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 <f_g> possible with the outlook of having a separate repo post-bullseye when packaging work will ramp up again
19:54:06 <f_g> 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 <wookey> not many people understand this enough to help.
19:54:55 <Ganneff> 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 <stappers> 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 <stappers> infinity0: do know that Ganneff understands you and does a reach out.
19:56:11 <waldi> f_g: debcargo source contains a comment: we workaround a dpkg/archive/whatever bug
19:56:54 <f_g> I know - I think I don't understand enough details of M-A to grasp that
19:57:33 <wookey> f_g: I should be able to help you with M-A stuff as I helped design that
19:57:37 <Ganneff> so, can we condense some action item out of the last hour?
19:58:15 <waldi> - ftp team to talk about a build-only archive and talk to release team about it
19:58:18 <f_g> Ganneff: I think the old ones still stand - investigate features/versions/provides/bin package reduction, implement PoCs (silwol and me)
19:58:44 <f_g> a new one what waldi just said (with input/help by rust-/golang-team people?)
19:59:09 <Ganneff> right, those are two. stappers, you are chair, could you !action or !note or !info (or whatever) them?
19:59:20 <stappers> #action ftpteam to talk about a build-only archive and talk to release team about it
19:59:31 <Ganneff> (how often do you have those meetings in here?)
19:59:37 <wookey> monthly
19:59:44 <f_g> last wednesday
19:59:44 <wookey> last wed of month 7pm
20:00:02 <f_g> (this is only the fourth one or so though ;))
20:00:11 <wookey> https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda
20:00:11 <Ganneff> ok. can talk then again if we got any further on our items. (someone please remind me a week before, thanks)
20:00:24 <stappers> #action (silwol and f_g) investigate features/versions/provides/bin package reduction, implement PoCs
20:00:29 <Ganneff> now, before we close...
20:00:58 <Ganneff> i wont approve the current set of rust packages in NEW that contains empty feature packages. (any without pass as usual).
20:01:21 <Ganneff> 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 <Ganneff> (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 <stappers> "any preference?"   Reject  and tell why
20:02:29 <wookey> 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 <Ganneff> k
20:03:02 <f_g> wookey: yes. although a reduced feature set would still mean empty bin packages, just less of them with less provides ;)
20:03:30 <Ganneff> if that "less" is *WAY* *WAY* less, then that could be acceptable too.
20:03:34 <f_g> 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 <wookey> fewer :-) Yes, but hopefully we will have reached agreement with FTPmaster on what is 'reasonable' by then.
20:04:27 <Ganneff> ok, so i think for today, im out, and thanks for dealing with me silly old ftpmaster :)
20:04:42 <wookey> Very useful for you to turn up. So thanks
20:04:46 <f_g> Ganneff: thanks for joining and your input!
20:04:56 <f_g> waldi as well, of course ;)
20:05:33 <stappers> 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 <wookey> Ganneff: please make sure the rejects have an explanatory message, so uploaders know what is going on.
20:06:25 <wookey> not everyone is following along here
20:06:54 <f_g> should we proceed to the next point?
20:06:57 <Ganneff> yes sir. (condensed one)
20:07:10 <stappers> ;-)
20:07:42 <stappers> #topic Avoiding Section: FIXME
20:08:05 * stappers thinks it happened by mistake
20:08:56 <stappers> reject with "Invalid Section" will help the learning process.
20:09:20 <stappers> Other opinions on this???
20:09:41 <wookey> lintian checks
20:09:43 <f_g> yeah, was a mistake for sure
20:10:02 <Ganneff> happened by mistake at least twice, and lintian does notice. thats why i mnentioned it in here
20:10:10 <f_g> maybe we could make ./release.sh more robust w.r.t. to those errors
20:10:29 <stappers> #agreed  lintian check before upload
20:10:57 <stappers> #idea make ./release.sh more robust w.r.t. lintian errors
20:11:05 <hntourne> 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 <f_g> sounds good to me
20:12:24 <stappers> #agreed that '#agreed lintian check before upload'  was too fast ...
20:12:44 <f_g> 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 <stappers> #action ./release.sh should refuse uploading if there are lintian error
20:13:37 <f_g> ah, it does for RERELEASE, but otherwise it just tells you to dput
20:14:41 <stappers> 
20:14:49 <f_g> 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 <stappers> What about a 15minute break before next topic?   ( Yes, I would like to have a break )
20:15:47 <wookey> where does release.sh come from? I don't see it in debcargo source
20:16:11 <f_g> wookey: debcargo-conf
20:16:39 <f_g> 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 <f_g> ack
20:17:45 <Ganneff> you may want to addchair someone
20:17:48 <f_g> any volunteers for extending release.sh? ;)
20:19:53 <wookey> maybe. lets have a look...
20:29:14 <stappers> volunteers for addchair
20:29:18 <stappers> volunteers for addchair?
20:29:55 <stappers> #topic Current packaging projects requiring coordination/help
20:30:39 <f_g> hntourne and me discussed proceeding with futures+gtk in the backlog, any other big things going on/being worked on?
20:31:19 <hntourne> This is one part, beside this big chunk I am looking at Fractal dependencies more in general
20:32:42 <hntourne> Would like to sort that part first since most of missing fractal deps depend on updated gtk version
20:34:42 <stappers> Thing I, dd, can do is sponsoring uploads of GTK stuff needed for fractal.
20:35:57 <stappers> More on this topic?
20:36:22 <hntourne> that would be very heplfull stappers, I will be reaching out to you on this then :-)
20:36:33 <stappers> Please do
20:36:58 <stappers> Same for simular stuff
20:37:16 <stappers> 
20:37:21 <stappers> #topic Upcoming freeze and things to keep an eye out for
20:38:10 <f_g> that one should be a quick I think :)
20:38:27 <f_g> just be extra mind-ful when doing uploads to not break dependency chains of applications already in the archive
20:39:04 <stappers> Have we tooling to help with that?
20:40:03 <f_g> yes, list-rdeps.sh
20:40:07 <f_g> in dev/
20:40:33 <hntourne> right, yes I personnally always use that one :-)
20:40:51 <f_g> also, keeping an eye out on autoremovals/bugs is extra-important in the next months
20:41:37 <stappers> #note awareness on dependency chains before uploading,  tool:  list-rdep.sh   from dev/
20:42:29 <f_g> 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 <hntourne> f_g / stappers : dev/rust-excuses.mk refresh all seems usefull too - will list what fails to transition to testing due
20:44:49 <hntourne> See RELEASE.rst - never tried it myself
20:46:52 <stappers> 
20:46:59 <stappers> #topic Toolchain updates (/ rustfmt / clippy)
20:48:22 <f_g> 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 <stappers> OKay
20:49:38 <f_g> this might fix issues people have been reporting with some crate's Cargo.lock files
20:50:02 <f_g> it might make sense to collect instances of those somewhere - maybe issues in debcargo's salsa repo?
20:53:31 <stappers> On short term fine, on long term not so fine.  Might be mitigated by having "export issues function".
20:54:53 <f_g> 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 <stappers> And do know that having some central place is better then  scattered collections ...
20:55:46 <stappers> f_g: Which package will be using for the "collection"?
20:55:55 <stappers> f_g: Which package will we be using for the "collection"?
20:56:51 <f_g> 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 <stappers> :-)   Obvious   now you say it    :-/
20:58:52 <stappers> 
20:59:18 <stappers> #topic  last minute entries
21:02:52 <f_g> none? ;)
21:02:59 <stappers> ;)
21:03:02 <stappers> 
21:03:16 <stappers> #topic  mailinglist  debian-rust
21:03:33 <stappers> No news from listmasters
21:04:52 <stappers> #action stappers  does another retransmit to express we want/need  a discussion ML beside the auto-generated traffic mailinglist
21:05:28 <stappers> #endmeeting