18:59:27 <silwol> #startmeeting
18:59:27 <MeetBot> Meeting started Wed Jul 22 18:59:27 2020 UTC.  The chair is silwol. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:27 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:45 <silwol> #topic overview
19:00:17 <silwol> I'd say we discuss the easier topics first:
19:00:21 <silwol> - regular meetings
19:00:30 <silwol> - separate mailing list
19:00:36 <silwol> and then the difficult topic
19:00:51 <silwol> - future of packaging with debcargo
19:01:05 <silwol> any other topics somebody would like to have handled?
19:01:22 <stappers> - how to help FTP-masters
19:02:29 <f_g> stappers: I think that is 'future of packaging with debcargo'
19:02:45 <silwol> it is.
19:02:49 <stappers> OK  (said the newbie)
19:03:02 <silwol> #topic regular meetings
19:03:10 <f_g> in case infinity0 joins us/is here, I'd also maybe put 'rustc 1.45' on the agenda (just a short update / whether help is needed)
19:03:30 <silwol> ok for me.
19:03:31 <f_g> and maybe if we have time, a general overview what everyone is working on / planning and what blockers are beside the whole review thing
19:04:32 <kpcyrd> there's a work-in-progress version of cargo-debstatus that I've never finished
19:04:44 <silwol> ok, so what ideas/wishes do you have in regard do regular meetings?
19:04:53 <f_g> I think regular meetings would help with coordinating bigger uploads, and maybe also help with motivating us to keep making progress
19:04:54 <hntourne> Think that is a good idea f_g (IRC) - could help clarify objectives and see if alignments are required or if those objectives are realistic at all
19:05:07 <f_g> so I'd be for it, but obviously not if it's only 1-2 people ;)
19:05:37 <hntourne> (good idea was for "what everyone is working on" ;-))
19:05:41 <f_g> (oh, I remembered another potential topic - the sprint in autumn in Germany - but that is probably to early to discuss/decide)
19:05:50 <f_g> (given the Corona circumstances)
19:06:23 <silwol> I'm also for having a regular meeting, but I'm not sure I would make it to one more than once a month.
19:06:46 <silwol> how about the others?
19:06:53 <kpcyrd> yeah, once a month sounds about right, also depends on wether it's mandatory
19:06:57 <f_g> monthly sounds okay, maybe on alternating weekdays/nights to give more people the opportunity
19:06:59 <stappers> This wednesday is a fourth wednesday of the month.
19:07:17 <silwol> bonus would be that we would produce a search-indexed history of what we discussed if we use MeetBot.
19:07:19 <hntourne> once per month ok here too
19:07:49 <stappers> #idea:  each fourth wednesday of the month  IRC meeting
19:07:50 <f_g> I think making it mandatory is not an option - we don't have anything that we can use to force peopel to attend ;) if people have something important to add but were not present, they can always reply to the mailing list summary or something like that
19:08:05 <silwol> something like stappers suggested would be fine for me, e.g. every month the fourth (or last?) wednesday.
19:08:18 <f_g> fine for me as well
19:08:24 <silwol> that's something interested parties can note in their calendar.
19:08:44 <f_g> is the time okay for everyone? AFAICT most of us are around UTC+2 ..
19:08:51 <silwol> problem is: people who don't have time on wednesdays in general aren't here today ;-)
19:09:06 <stappers> silwol: true
19:09:26 <hntourne> f_g (IRC):  time is ok for me
19:09:53 <silwol> I think it won't be much longer than 1.5h usually, so the time is ok.
19:10:26 <stappers> the next 5 month  a copy of this one.  In december polling / voting for new date schedule?
19:10:45 <silwol> stappers: good idea. so should we fix fourth wednesday every month 19:00 UTC?
19:10:47 <f_g> noone who responded to the poll was not available today. dkg did not respond and might be interested, Sylvestre is probably interested but not available this week. so maybe let's settle on Wednesday unless either of those two objects
19:11:15 * stappers checks for Christmas day  and Silvester day
19:11:46 <silwol> that's a good idea. Otherwise with the review around end of the year, we'll see if we have any problems with that date.
19:11:46 <f_g> stappers: I think we can make an exception there (or move it to congress + beer :-P)
19:12:11 <silwol> if any changes are needed, we'd announce them here and on the mailinglist.
19:12:34 <f_g> ack
19:12:35 <kpcyrd> congress meetup would be fun, whenever the next congress happens :)
19:12:36 <stappers> With last wednesday is  congress   in    :-)
19:13:05 <silwol> #agreed regular meetings every fourth wednesday of a month, we'll revisit the decision by the end of the year. if changes are required, we'll announce them in the chat and on the mailing list.
19:13:25 <silwol> #topic additional debian-rust mailing list
19:13:47 <stappers> debian-rust@lists.debian.org
19:13:57 <silwol> anybody has experience in requesting / administrating debian mailing lists?
19:14:00 <stappers> other options / propsals?
19:14:11 <silwol> stappers: that's the best I think, and it equals the irc channel name
19:14:31 * stappers did request debian-user-dutch@lists.debian.org  (long ago)
19:15:14 <silwol> I think Sylvestre and infinity0 registered the pkg-rust-maintainers mailing list.
19:15:51 <f_g> I don't care either way - compared to many other lists the current one is not that high traffic/noisy. but if people see a benefit in a separate one, I'll subscribe there too :)
19:15:53 <stappers> ML request is somewhat like  new-maintainer process:   One proposess, others  "advocate" / support the proposal.
19:16:36 <silwol> probably we'd need some volunteer(s) to register (and moderate) it.
19:16:56 <silwol> (don't know how much moderation work is necessary).
19:16:56 * stappers volunteers for doing the request. But note:
19:17:10 <stappers> < silwol> I think Sylvestre and infinity0 registered the pkg-rust-maintainers mailing list.
19:17:49 <stappers> Is  pkg-rust-maintainers  at Alioth??
19:18:05 <silwol> yes, it's https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
19:18:35 <stappers> ACK, So I'll request debian-rust@lists.debian.org   (please confirm)
19:18:43 <silwol> that would be great.
19:18:57 <silwol> anybody volunteering as a second admin?
19:19:17 <kpcyrd> I'd be ok with being the 3rd
19:19:47 <stappers> AFAIK are  doing the listmasters the actual admin work
19:20:31 <silwol> meant in terms of 'list admin'.
19:20:37 <stappers> In other words:    First admin and  Third admin  is enough   :-)
19:21:10 <stappers> In other words:    First listadmin and  Third listadmin  is enough   :-)
19:21:37 <silwol> if nobody else steps in I could do second, but I can't guarantee fast enough reaction if required, due to family demands.
19:22:18 <silwol> we'll have to update the information that is spread in documentation (such as wiki, readme etc).
19:22:42 <stappers> #idea   listadmin workload as agenda item   for our meetings
19:23:04 <silwol> #action stappers request debian-rust@lists.debian.org mailing list
19:23:09 <stappers> :-)
19:23:42 <silwol> #action silwol check wiki and readme once we have the list
19:23:51 <silwol> anything else on that topic?
19:25:06 <silwol> ok, then next topic.
19:25:06 <silwol> #topic future of packaging with debcargo
19:25:38 <silwol> what's the information status of everyone? any need to explain something about the history?
19:25:54 <stappers> please explain
19:26:04 <f_g> I can try?
19:26:13 <stappers> f_g++
19:26:49 <silwol> plz.
19:27:11 <f_g> debcargo is the main tool used for Rust packaging in Debian. besides general scaffolding/changelog/copyright handling, it does the following:
19:27:18 <silwol> for the record: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-November/008589.html contains a concise summary of the state some months ago, which hasn't evolved a lot since then.
19:27:37 <f_g> - translate features or feature sets into binary packages
19:27:42 <stappers> only time in NEW increased
19:27:56 <f_g> - translate semantic versioning as handled by cargo into versioned provides/dependencies on the debian side
19:28:28 <f_g> - generate autopkgtests for crates with dev-dependencies, per feature and for all/no features
19:29:23 <f_g> the feature -> binary package translation leads to lots of binary-NEW and RM churn, since upstreams generally introduce/remove/rename/refactor features quite often
19:29:44 <f_g> each new feature means a round trip through NEW on the Debian end, unless that feature is patched out
19:30:16 <f_g> the version translation means that each feature is provided many times for each level of semantic versioning
19:30:56 <f_g> both of these are not well-received by ftp-masters, as the trips through NEW cause review load on their end, and the long Provides lines/number of binary packages per crate are seen as bloat and misuse of these features of the archive (at least by parts of the team)
19:31:21 <f_g> some members of the ftpmasters team have basically stopped reviewing rust-* packages as a result
19:31:29 <stappers> chips
19:32:13 <f_g> also, the fact that most of the librust-foo+feature-dev packages are basically empty is not well-received either (the source code is the same so it's only shipped once, the +feature package is just to encode the dependeny in rdeps)
19:32:44 <f_g> possible solutions for the NEW issue would be:
19:32:53 <silwol> some also think the shared resource "package index" shouldn't grow due to our methods of packaging.
19:33:20 <f_g> - convince ftp-masters to auto-approve those empty binary-NEW packages (not very likely, but technically they themselves don't ship any new potentially problematic source code)
19:33:49 <f_g> - reduce the number of binary-NEW trips we have to make (issue #17 linked in the meeting invitation)
19:33:57 <kpcyrd> there was a suggestion for a repository with a separate package index that is not meant for users
19:34:38 <silwol> solution 1 is what infinity0 (main maintainer of debcargo) said would be their favorite position
19:34:43 <f_g> kpcyrd: right, but that is not something we as a team can do. we do that at work with a 'devel' repo that regular end users don't need to enable
19:35:10 <silwol> kpcyrd: yes, iirc another team suggested that (go?)
19:35:18 <f_g> we could attempt to push this in Debian, but it's probably not realistic for bullseye?
19:35:28 <silwol> maybe we could discuss the status on that with them.
19:35:53 <stappers> them:   Go pkg team??
19:36:03 <silwol> I don't think it would be ready for bullseye, unless somebody made significant progress by now of which we didn't hear.
19:36:18 <silwol> stappers: yes
19:36:29 <f_g> my prefered proposal from #17 would help with both issues, but increase the overhead for us as maintainers
19:37:00 <silwol> plus somebody would have to implement it in debcargo first.
19:37:17 <f_g> yes
19:37:35 <silwol> (and convince infinity0 that it's a good idea).
19:37:47 <stappers> infinity0: Hi
19:39:12 <kpcyrd> there was also the request to bundle multiple crates to reduce the number of packages. I'm not sure how I feel about that because it assumes that the crate is not going to have two dependents.
19:40:04 <f_g> kpcyrd: true. that was mainly for things like foo and foo-impl / foo-internal, where the latter has only the crate proper as rdep
19:40:30 <silwol> proposals on how we should proceed at that point? imho too many people of interest aren't available atm for drawing a final conclusion (infinity0, sylvestre, dkg, maybe also slomo).
19:41:06 <f_g> infinity0 and Sylvestre were pretty clearly in their (respective) positions I think, but it's a pity they are not here today
19:41:53 <f_g> I can try to implement such a 'manual bin package + provided features' feature as an option in debcargo, then we could play around with it as an alternative to patching out features
19:42:25 <kpcyrd> (manually) stripping features is the status quo right now afaik since it bypasses the ftp-masters. the way this is done correctly is 1) making all dependencies non-optional 2) set every new feature to depend on an empty set of optional packages
19:43:10 <kpcyrd> since we don't have tooling for this yet (and it's probably eventually going to blow up due to dependency cycles) this is a very labor intensive approach
19:44:05 <silwol> kpcyrd: we'd like to include an option to break out features in separate packages in order to break dep cycles.
19:44:22 <silwol> (and possibly also include some magic to detect them in update.sh)
19:45:01 <kpcyrd> so we'd keep the provides (unless we also need to cap them for stuff like web-sys) but avoid additional binary packages
19:45:06 <f_g> yes, it would basically be {"binpkgname": ["feature1", "feature2"], "anotherbinpkgname": ["feature3"]}
19:45:38 <f_g> that would build librust-foo+binpkgname-dev providing librust-foo+feature1 and librust-foo+feature2, and librust-foo+anotherbinpkgname-dev providing librust-foo+feature3-dev
19:45:43 <f_g> any other feature is not provided
19:46:41 <kpcyrd> speaking of web-sys, I'd also suggest we ignore everything web-assembly related for now. We've originally kept this in to avoid having to go through NEW again.
19:46:46 <kpcyrd> but nothing actually uses it yet
19:47:41 <f_g> sorry, laptop crashed :-/
19:48:24 <f_g> if a new rdep requires feature4, then we add it to either existing binpkg if possible. only if that would introduce a cycle or some huge additional dep chain, we break it into a new binpkg
19:48:39 <f_g> we'd have still binary package names, only adding or removing when we decide we need to
19:48:44 <f_g> s/still/stable
19:49:16 <f_g> right now, if a feature gets added the binary package might be renamed and trigger a trip through bin-NEW
19:51:11 <f_g> dependencies would still be generated like now, so we notice fast when we miss to add a feature (package uninstallable -> no migration)
19:51:22 <silwol> (same if we patched out a feature and re-add it because we need it).
19:52:18 <f_g> it would be more akin to what other eco-systems do as well - decide which configure flags to enable or which libraries to link with, instead of shipping all variants separately
19:52:47 <f_g> cargo makes this almost too easy with features, which is also why upstreams play around with it a lot causing so much churn
19:53:09 <silwol> any ideas how we could evaluate if this behavior would work for us?
19:54:06 <f_g> silwol: we could check how many bin packages we currently have that don't have a single rdep
19:54:40 <silwol> and use them for experimentation?
19:55:33 <f_g> possibly.
19:56:01 <f_g> just looking at bin packages without rdeps, and features without rdeps would already give us a rough indication of the minimum gain by such an approach
19:56:41 <f_g> then adding manually evaluating and merging bin packages would give even more reduction
19:57:22 <f_g> I can try to get some numbers with some grep-dctrl foo and post them to the issue
19:57:45 <silwol> that would be great.
19:58:14 <stappers> issue is at bugs.debian.org  ?  If yes, which number?
19:58:23 <silwol> should we attempt to go ahead with an experimental implementation of the changes in debcargo?
19:58:29 <f_g> #action attempt to estimate naive savings of dropping unused features/lib crate bin packages ( f_g )
19:58:36 <silwol> stappers: issue on salsa: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/17
19:59:03 <stappers> silwol: thanks for getting this in the meeting notes  ;-)
19:59:35 <stappers> silwol: thanks for getting the issue URL in the meeting notes  ;-)
19:59:57 <f_g> silwol: I can also try to to that as an MR, but it might take a bit so if anybody else wants to poke debcargo internals you are all more than welcome :)
20:00:27 <f_g> #info issue on salsa: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/17
20:01:03 <silwol> f_g if you like and if we find the time, we can also do a hack-session together online.
20:01:31 * silwol has done some debcargo hacking, but isn't too familiar with it's internals.
20:02:12 <f_g> ack
20:02:52 <f_g> #action silwol f_g whip up a proof of concept MR implementing bin package / feature reduction feature in debcargo
20:04:02 <silwol> should we also ask other teams whether there is any movement on the dev repo idea?
20:04:10 <f_g> yes
20:04:23 <stappers> yes
20:05:38 <silwol> who?
20:06:32 <f_g> once we have numbers/a poc we hopefully also get more feedback from people missing today, and might get some ftpmasters people to take a look again and give feedback as well
20:06:54 <stappers> Raised it  debian-devel@l.d.o.
20:07:04 <stappers> Raised it  at ML debian-devel@l.d.o.
20:07:11 <silwol> stappers: thx a lot!
20:07:27 <stappers> OOPS
20:07:32 <stappers> Raise it  at ML debian-devel@l.d.o.
20:07:56 <silwol> ah, ok. I was waiting for the incoming mail already ;-)
20:08:19 <stappers> But we shall what I do friday on it.
20:08:50 <stappers> But we shall see what I do friday on it.
20:08:54 <f_g> haha. I think we could ask the most likely affected teams directly - Go, maybe Haskell (not sure?) - first. it will take ages anyway, might be a good idea even if we implement some reduction on our end first
20:09:17 <f_g> and if it's not something that's just coming from the rust team it might help the chances of making progress
20:09:50 <f_g> (node)js might be in the same boath as well - lots of small packages, many of which are just build-deps of a few main packages
20:09:56 <f_g> s/boath/boat
20:10:08 <silwol> f_g true. I think somebody from the go team mentioned they get requests from people who installed the dev-deps and don't know what they are for.
20:11:12 <f_g> any volunteers for contacting teams (and then maybe starting a discussion on IRC/some mailing list to prepare a concrete proposal for -devel ?
20:12:10 <silwol> I think I can ask in the respective IRC channels and report the results here.
20:12:50 <silwol> so it's #debian-golang, #debian-haskell, #debian-js?
20:12:56 <silwol> any others?
20:13:57 <silwol> #todo silwol collect status information on the devel repo from #debian-golang #debian-haskell #debian-js
20:14:37 <silwol> anything else on this topic?
20:15:14 <silwol> otherwise I'd like to continue to the next.
20:15:26 <stappers> #idea   the dev repo  get included when the are deb-src in /etc/apt/sources.list
20:15:29 <kpcyrd> there's also interest by distros that downstream from debian
20:15:42 <kpcyrd> basically, kali is currently unsure how to package anything rust
20:16:30 <f_g> #action silwol contact Debian Go, JS and Haskell teams and Kali Linux maintainers for 'dev-repo' proposal
20:17:01 <kpcyrd> their policies are a lot less strict but they're still trying to get as close to the debian system as possible
20:17:02 <silwol> thx f_g, had the wrong cmd in my mind
20:17:08 <f_g> #action silwol include plugwash/raspbian in dev-repo proposal as well
20:17:18 <kpcyrd> (not specifically about the dev-repo, more about packaging in general)
20:17:40 <f_g> kpcyrd: basically in the same boat at $work, but I am here already ;)
20:17:43 <silwol> kpcyrd: I assume you're talking about rust software that differs from what we have in debian?
20:18:41 <f_g> kpcyrd: do you have any specific people in mind? maybe we could invite them to the next meeting/to this channel in general?
20:19:22 <kpcyrd> silwol: yes, they'd most likely drop their package after it arrives in debian but ship their own until then
20:20:10 * f_g is also not sure what's going on in Ubuntu/Canonical land w.r.t. Rust
20:20:48 <silwol> not sure either. I've seen they provide a recent rustc in their backports repository.
20:21:01 <kpcyrd> f_g: I've talked to steev in the past (from kali) and 5nacks from tracelabs who maintains the Trace Labs OSINT VM (which is a kali downstream trying to upstream into kali)
20:21:36 <stappers> FWIW  there is something like  #debian-meeting
20:21:53 <silwol> apart from that, they sometimes patch our packages in order to fix problems they have. but I haven't seen them use debcargo.
20:22:10 <f_g> kpcyrd: can you ping them and see if they are interested?
20:22:34 <f_g> silwol: theyll probably start providing 'cargo install' snaps soon anyway :-P
20:22:45 <silwol> :-)
20:24:03 <kpcyrd> f_g: to attend in the meeting?
20:24:12 <stappers> #info https://wiki.debian.org/IRC/debian-meeting
20:24:26 <f_g> kpcyrd: either that, or just join here for a chat to exchange what they/we are up to
20:25:02 <f_g> I am guessing the number of tools relevant to Kali (re-)written in Rust will continue to rise for the forseeable future ;)
20:25:57 <f_g> #action kpcyrd contact Kali rust people and see how/whether we can collaborate (maybe invite to meeting)
20:27:52 <silwol> I think we can skip the 'rustc 1.45' topic without infinity0?
20:28:59 <f_g> yeah. I might open MRs if I don't hear from them and the other devs at work pester me for it ;)
20:29:33 <silwol> #topic what is everybody working on / planning and what blockers are beside the whole review thing
20:30:04 <silwol> who would like to report?
20:30:23 <f_g> I'd be interested in what the newcomers to this channel are working on
20:30:37 <silwol> f_g +1
20:30:57 <f_g> and maybe also whether we want some way to keep track on that front - e.g., opening up salsa issues for bigger dep chains, resurrecting TODO.rst, ...
20:31:30 <f_g> basically I'd like to move from people all mainly doing their own thing next to eachother to more hand-offs and collab and feedback
20:32:03 <f_g> hntourne stappers I think you're the only 'new' people here right now :)
20:32:05 <hntourne> f_g (IRC): as newcomer, I am mostly looking after Fractal dependencies.
20:32:45 <infinity0> ouch sorry, i forgot about this. i'm here now though
20:32:54 <hntourne> so currently stuck at the moment since some of those dependencies relies on updated gtk/gdk version
20:32:59 <silwol> welcome infinity0
20:33:25 <kpcyrd> the last thing I was working on was trying to get sniffglue (and its dependencies) to transition to testing and update cargo-debstatus to support the new Cargo.lock format, but stopped on both fronts a while ago
20:33:43 * stappers is a DD, works in a .deb shop  as DevOps engineer, more Ops  as Dev. Is new to rust, came to this channel when he heared about 'deno'   (NodeJS rewrite in rust)
20:34:52 <silwol> regarding deno, I had a chat with humancalico (the person that filed the ITP). they had problems joining this room due to the whole registration / email requirement.
20:35:42 <stappers> chips,
20:35:50 <f_g> hntourne: are you planning on packaging it within debcargo-conf? only the api crate is published on crates.io atm
20:36:08 <f_g> it might make sense to discuss this with upstream as well to see what they are planning
20:36:24 <silwol> i helped to get started initially (./update.sh deno) a few days ago, haven't received much feedback how it went since then.
20:36:33 <hntourne> Fractal itself, probably not. But first would like to have the deps available
20:37:08 <silwol> fractal uses meson, iirc it can't be built directly without reimplementing what they do there.
20:37:10 <andrewsh> NEW is very very slow these days
20:37:17 <hntourne> f_g (IRC): they are going to drop their own api part and shift to rust-matrix-api crate, they have a GSOC student working on that
20:37:20 <andrewsh> my Rust crates have been there for 6 months now
20:37:43 <infinity0> it's slow for everyone, people on pkg-mozext were complaining too
20:37:56 <andrewsh> yeah, but Rust used to be processed quickly
20:38:06 <infinity0> everything used to be processed more quickly
20:38:19 <infinity0> might be a good case to actually try to gather people together across the whole of Debian to voice support for getting rid of NEW
20:38:20 <andrewsh> I wonder what happened, did someone resign?
20:38:25 <infinity0> er, binary-NEW at least, i mean
20:38:40 <infinity0> dunno, maybe just old-timers getting bored
20:38:52 <f_g> silwol: I think they mainly use meson as a cargo wrapper ;) but yes, needs a closer look
20:38:53 <hntourne> Regarding Fractal, one could ask upstream as you suggested f_g, not sure it would get much support from their end, they'r all for flatpak actually
20:38:58 <andrewsh> I’m getting bored of waiting :/
20:39:07 <andrewsh> and losing motivation to do anything
20:39:26 <andrewsh> I have mostly given up on packaging resvg and Fractal deps
20:39:39 <silwol> f_g I asked some time ago in their channel, and they told me so. don't remember what it was they're doing in meson.
20:40:17 <f_g> "Fractal does not currently have encryption support, but there is an initiative for it." was what stopped me from taking a closer look so far :-P
20:40:49 <hntourne> once they complete their migration to rust-matrix-api, that will help
20:40:50 <silwol> I also don't think they intend to publish on crates.io, and I also think it would fit better into the gnome ecosystem.
20:40:56 <silwol> same for shortwave and podcasts.
20:41:08 <hntourne> agreed
20:41:31 <f_g> I don't have much first-hand experience with new other than rust packaging, and that has all been in the past year. but I agree that it's frustrating, which is why I'd like to avoid NEW as much as possible..
20:42:25 <hntourne> andrewsh (IRC): : I worked on few deps of Fractal actually, silwol (IRC) kindly merged my MR for loggerv, there's also mdl and html2pango that are pending :-)
20:42:36 <f_g> I've been trying for most of that time to get a single larger dep chain updated, currently waiting for 4 months for the NEW leaf packages to get reviewed
20:43:17 <f_g> so I get the pain. I do hope that by moving a bit in their direction/compromising we can also get some faster reviews in return, but maybe that hope is misplaced
20:43:39 * silwol hopes so as well
20:44:59 <stappers> Talking to the right people does help
20:45:16 <kpcyrd> bluntly phrased, I'm still not sure why debian is so special to need NEW while every other distro I worked on didn't need anything similar
20:46:02 <infinity0> debian is one of the more strict distros
20:46:05 <f_g> heh. I think the answer you'll get from some people is that other distros can ignore it because Debian does not and frequently pushes upstream to fix issues that would otherwise affect other distros as well ;)
20:46:27 <infinity0> i think asking "why" is not super-interesting, lots of historical random things
20:46:29 <f_g> but I think that is not the case for our binary-NEW issue, which is just ftp-masters processes and rust-team processes being very much misaligned atm
20:46:49 <f_g> and one of the teams having a much larger lever than the other
20:46:56 <infinity0> binary-NEW historically was due to screwing up upgrades of binary shared libraries as i understand, not really related to rust
20:47:07 <infinity0> anyway, today it's basically obsolete, we have transition trackers etc
20:47:15 <f_g> I think it's that + namespaceing issues
20:47:40 <f_g> both don't really apply to librust-foo+feature-dev, since the namespace is clear, and the packages don't ship anything except metadata
20:47:50 <infinity0> it doesn't stop that, i've had my binary packages overridden by other source packages before
20:48:46 <infinity0> anyway, we have a process of this sort of disagreement, we can use the process
20:49:26 <kpcyrd> f_g: that argument falls short considering how much software arch ships that debian doesn't :)
20:49:27 <silwol> are other teams suffering from the bin-new problem as we are, or don't they mind because their ecosystem is less in a state of flux?
20:49:35 <f_g> sure. there is another option that we did not discuss earlier - attempt to escalate the bin-NEW issue via the tech committee or whatever the appropriate channel is
20:50:15 <f_g> it's a pretty high-risk move though - pissing off ftpmasters even more when we need them to review the regular NEW stuff as well
20:50:35 <f_g> getting rid of NEW altogether is probably not something that the project would support as a whole
20:50:53 <silwol> that means we would have to try to figure out a solution first, and then agree to disagree with them according to the procedure.
20:50:55 <kpcyrd> silwol: I've heard "if you hit NEW more than once you're probably doing something weird"
20:51:04 <f_g> so I'd only go down that route if we don't find another way to compromise
20:51:08 * stappers did learn today there is beside NEW also  bin-NEW
20:51:41 <kpcyrd> (so I assume it's less of an issue in other eco systems, like eg. python)
20:51:51 <f_g> silwol: I think we are hitting bin-NEW particularly often compared to other teams. usually you only hit it when you bump soname, or when upstream renames something
20:51:58 <silwol> kpcyrd: yes, I also sometimes have the feeling that many consider what we do "something weird".
20:51:59 <f_g> barring special cases like the kernel
20:53:30 <f_g> given how often upstreams mess up soname changes (which maintainers might not notice), dropping binary-NEW altogether is probably also not such a good idea either
20:55:05 <f_g> infinity0: have you read the backlog with the proposal? would you be willing to take a look at such a PoC MR for debcargo when backed up by potential reduction in binary packages/provides in the current set of packaged crates?
20:55:37 <infinity0> it's not just the code that needs to be written, but scripts to detect when the merged features have to be undone
20:56:12 <infinity0> sure, i'll look at it if someone else writes it, but i'd rather we take the binary-NEW issue to tech-ctte first, writing an argument in english is probably less work than writing the code
20:56:53 <f_g> you mean detecting when features A, B and C should not be provided by one binary package because of a cycle?
20:58:26 <f_g> wouldn't anything really problematic be uninstallable anyway?
20:59:15 <f_g> it might not be optimal w.r.t. the tradeoff of number of bin packages (= NEW time) vs size of dep chain, but that is a decision the humans can make on a case by case basis
20:59:19 <silwol> #topic debcargo feature-collapsing feature POC
21:01:04 <infinity0> the uninstallability might not be detected until someone does something else, and then they have no idea it was caused by this merge done here
21:01:15 <infinity0> something else in a different and seemingly unrelated package that is
21:01:47 <f_g> yes, but that is the case in general in Debian. if two of my deps (transitively) start conflicting, I file bugs or change my deps
21:02:38 <f_g> and only if that is not feasible/solvable, do I start shipping -variantA with dep A and -variantB with dep B, or drop one of them
21:03:39 <f_g> both of which would be possible with the approach in a simple and declarative way
21:04:24 <f_g> (it would also be intersting to look at this and see how many of those conflicts we actually have atm, not sure if anyone has done that yet?)
21:04:42 <f_g> like as a simple test, test for co-installability of all +feature packages of a crate
21:05:26 <f_g> would just be a snapshot, and subject to change, but might give an idea of how theoretical this problem is (or not!)
21:07:15 <infinity0> conflicts are not the same thing as cycles, i am talking about one of your reverse-dependencies that has no idea you performed this artificial merge
21:07:51 <infinity0> you can analyse the current situation already, without writing the merge code, just by looking at the existing metadata
21:08:14 <infinity0> in the long run however, working around ftp problems isn't actually helping debian, it's just adding to the piles of technical debt we have
21:08:30 <f_g> the current proposal is not merging any features, just limiting what we provide and how the provided features are grouped into bin packages
21:08:56 <infinity0> wasn't there an MR for merging features?
21:09:02 <infinity0> issue i mean, no code yet
21:09:33 <f_g> yes. collapsing, with multiple possible approaches
21:09:52 <silwol> infinity0: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/17
21:10:17 <f_g> - collapse all features into a single fake one, needs work on both sides of the dep relation
21:10:36 <f_g> - filter provided features (needs work only on the providing side)
21:10:52 <f_g> - merge/map features (needs work on both sides, more flexible but more work than #1)
21:11:12 <f_g> the filter + grouping is the simples to reason about while still offering lots of flexibility
21:12:17 <kpcyrd> if we can clarify if our usage of Provides: is a problem (besides extrem cases like web-sys) that would already help
21:12:33 <f_g> we still need to patch some rdeps, but only when they depend on feature which are broken for debian use like +vendor
21:13:18 <silwol> kpcyrd: at least some people think so, due to the index being a shared resource that gets downloaded many times.
21:13:25 <wookey_> someone asked about newcomers. I guess that includes me. (sorry if I'm butting in - just noticed this meeting happening)
21:13:37 <f_g> kpcyrd: I think that really depends on which ftpmasters members you ask. some will find it strange, but don't take offense. some hate it and think it's abuse/bloat and don't review/accept anything rust- as a result
21:13:41 <kpcyrd> because then we can make dependencies non-optional to bypass NEW while still being compatible with the packages we already have (and having a clear way to make dependencies optional again if we have to)
21:14:01 <infinity0> as far as i can tell, filtering provides is only needed for one package, web-sys
21:14:06 <f_g> wookey_: welcome :)
21:14:12 <infinity0> again, the underyling problem is FTP policy. a policy solution here is much healthier for debian than a technical hack to work around policy bugs, we should spend more effort trying to get policy fixed
21:14:25 <silwol> wookey_: welcome! we switched to a different topic for the time being, will get back to the relevant topic eventually.
21:15:26 <wookey_> right , because infinity turned up. You carry on. I have nothing important to say, but I can tell you my interest later.
21:15:40 <f_g> infinity0: the provides and binary package names are intertwined currently, a change in the former can change the latter. this is in itself a problem (I notice this at $work a lot as well, renaming a binary package means taking care to RM the old one otherwise you get weird errors/outdated versions)
21:15:44 <infinity0> having volunteers jump through hoops, just encourages debian to be full of volunteers that like jumping through hoops, rather than volunteers with their eye on the bigger picture
21:15:52 <infinity0> forcing volunteers to jump through hoops that is
21:16:32 <stappers> well said    yes, that is a compliment
21:17:28 <infinity0> jumping through hoops is not a compliment, having your eye on the bigger picture is a compliment
21:17:52 <f_g> infinity0: I don't see that part as jumping through hoops so much as part of what a maintainer does - select which features of a piece of software to enable when packaging
21:18:09 <f_g> I agree that waiting X months for review of trivial changes is jumping through hoops
21:18:46 <infinity0> it shouldn't be up to the package maintainer to do the selection, but software developers already do the selection when they add the dependency
21:19:10 <infinity0> as package maintainers, we should be trying to do as little as possible, which is what other distros are moving towards
21:19:28 <f_g> IMHO we can do both - be more selective in which features we enable, stabilize how bin packages are named to avoid churn, and attempt to get binary-NEW removed (at least for librust-*+*-dev with only metadata)
21:19:53 <infinity0> look, if web-sys didn't exist and policy wasn't an issue, i guarantee you wouldn't even have thought of this as a feature to add to debcargo
21:20:10 <infinity0> it's not a natural technical task to want to do
21:20:14 <f_g> well, currently we package and ship a lot of stuff that is not used by anyone, which is at odds with librust-* mainly being targetted at packaging lib crates for bin crate packaging
21:20:46 <f_g> if we say we want librust- to package as much of crates.io as possible for general usage, that would be different
21:20:50 <infinity0> it's packaged automatically, and in case other packages in the future depend on it. besides, if we really care about "unused" we would come up with a general automatic solution, rather than manual maintenance
21:21:42 <kpcyrd> the reason so much is not used by anything is because it's so hard to actually get to the point of uploading the _actual_ program I'm trying to upload to debian
21:21:47 <f_g> I think web-sys was just the proverbial drop that made the bucket overflow, the ratio of metadata:content is skewed for librust-* in general compare to the rest of the archive
21:22:15 <infinity0> lol, yes that too kpcyrd
21:22:17 <f_g> kpcyrd: yes, partly true as well. but we do also package a lot of features that don't (yet) have a bin crate in the pipeline ;)
21:22:42 <kpcyrd> I've started working on this 2 years ago and I uploaded one program (that I still couldn't get into testing)
21:23:02 <f_g> like I said, I'm feeling the pain and trying to upgrade a single big dep chain for 9 months already ;) with stuff stuck in NEW that's already outdated again in the meantime
21:23:26 <stappers> #info mailing request bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966088
21:25:12 <f_g> even if we manage to convince ctte to force ftpmasters to drop binary-NEW reviews in some fashion, our chances of getting through NEW in a timely fashion for all of the stuff that needs to will be rather slim
21:25:36 <f_g> so I am not convinced this is a good strategy unless we are prepared to not ship much Rust stuff in bullseye
21:26:17 <f_g> if the team agrees on taking the chances, then let's prepare a good argument for ctte and skip a release ;)
21:26:28 <f_g> brb
21:26:37 <infinity0> i personally am not too concerned about bullseye but rather the longer-term picture, sure
21:27:37 * stappers would like to hear the FTP-master side of the story
21:28:10 <stappers> infinity0++  for long term thinking
21:28:32 <kpcyrd> is there a list of non librust- packages that we shipped in buster and that we're (probably) going to ship in bullseye?
21:29:40 <infinity0> not sure exactly what you mean?
21:29:47 <infinity0> we as in this rust team?
21:29:50 <kpcyrd> ripgrep, fd, maybe 3 others?
21:29:52 <kpcyrd> yes
21:30:08 <infinity0> oh right. there's not many yes
21:30:14 <f_g> firefox, but that gets special cased in anyway for sure ;)
21:30:17 <infinity0> like 4-5 max, plus rustc and cargo
21:30:36 <silwol> hexyl, pulldown-cmark, cbindgen iirc. I think that list could be extracted from the index?
21:30:42 <f_g> yes
21:31:26 <f_g> because grep-dctrl for Source rust- and Package not librust-
21:31:37 <f_g> s/because/basically (it's getting late)
21:33:25 <f_g> https://paste.debian.net/1157463/
21:33:29 <silwol> I think we have some sequoia bin crates as well.
21:33:30 <stappers> yes, it is getting late
21:34:04 <silwol> oh yes it is - those aren't in buster yet ;-)
21:35:07 <f_g> vs. unstable https://paste.debian.net/1157464/
21:35:56 <stappers> #info pastebin 7463: aho-corasick bindgen cargo-lichking cargo-vendor cbindgen debcargo difference exa fd-find grcov hexyl nitrocli process-viewer pulldown-cmark ripgrep rustdoc-stripper xml-rs
21:36:05 <f_g> (not double-checked, just quick grep-dctrl on main Packages)
21:37:05 <f_g> should we decide today on how to proceed? or write a proposal for tech-ctte and crunch some numbers and decide in the next meeting?
21:37:22 <stappers> #info pastebin 7464: libtr-tid2 moonshot-trust-router-dbg moonshot-trust-router-dev libjs-trust-json-document bat bindgen cargo-lichking cargo-lock cargo-outdated cbindgen debcargo difference dotenv exa fd-find grcov hexyl lalrpop lscolors nitrocli process-viewer protobuf-codegen pulldown-cmark ripgrep rustdoc-stripper rusty-tags sqop sqv sniffglue spotify-tui ucd-generate xml-rs
21:38:07 <silwol> I don't think we reach a conclusion today. for the tech-ctte, at least some communication with the other party/parties is required.
21:38:58 <f_g> (and I'd still like to hear a short info from wookey_ on what he's doing, even if it's just 2-3 sentences ;) doesn't have to be now/tonight I'll catch up with it in any case :))
21:39:18 <silwol> I propose we leave this topic for now, and f_g and I decide about writing a PoC for the feature thingy.
21:40:32 <f_g> I'll crunch the numbers in any case, and see whether I find time for implementing some PoC together
21:40:41 * stappers is about to leave the meeting and says "Fourth Wednesday is 2020-08-26, which is during Debconf online"
21:40:58 <f_g> infinity0: would you be willing to write a rough draft for a committee issue until the next meeting?
21:41:06 <silwol> #topic what is everybody working on / planning and what blockers are beside the whole review thing
21:41:36 <infinity0> f_g: sure, when is it?
21:41:39 <silwol> wookey_: your turn :-)
21:41:41 <f_g> infinity0: also let's talk tommorrow about coordinating the next toolchain updates
21:41:48 <f_g> infinity0: see stappers last message
21:41:55 <infinity0> ok, sounds fine
21:42:10 <infinity0> 1.44 has lots of test failures in experimental, those need to be fixed before we can package 1.45
21:42:25 <f_g> (we agreed earlier on every fourth or last wednesday, unless there are interested people who can never make it that weeknight)
21:42:51 <f_g> infinity0: I'll take a look tomorrow and ping you in the evening or open MRs
21:42:56 <f_g> wookey_: you still here? :)
21:43:27 <silwol> maybe I use the time until wookey_ returns.
21:43:47 <silwol> I basically reduced my work to maintaining the crates I already have in Debian.
21:44:01 <silwol> for now mostly semver-compatible updates.
21:45:05 <silwol> the crates of most interest for me are fractal, shortwave, podcasts, zola, diskonaut and other interesting cmd-line tools.
21:45:52 <silwol> I mostly process their dep tree for now, but that has come to a near-stillstand due to the NEW queue.
21:46:22 <silwol> I got a new job in june, 30h/week, typically friday off.
21:46:53 <silwol> I hoped to progress on my DD application, but because the kids are at home (in the beginning due to Covid-19, now holiday) I couldn't spend too much time on it.
21:47:05 <silwol> that's it.
21:47:10 <hntourne> Ok, I will go next then. I am too interested in Fractal and Shortwave, so mostly looking at their deps so far and therefore impeded by the "whole review thing"
21:47:17 <kpcyrd> silwol: nice! :)
21:48:05 <infinity0> also i figure if ctte does rule against us then we will just implement "merge features" and that should also cover the "filter provides" case, the latter is redundant anyway if we have the former
21:48:08 <hntourne> Not much to say beside this, I also looked at their dep tree and few crates are stuck as they would require updated gtk and co
21:48:33 <hntourne> And that's it for me so far :-)
21:48:50 <infinity0> f_g: cool, thanks! i'll have a look too soon
21:48:56 <f_g> I'm trying to get back into pushing futures/tokio into Debian proper
21:49:18 <f_g> besides that, we released an initial beta of our first Rust-based product at work (proxmox-backup)
21:49:51 <infinity0> congrats!
21:49:53 <f_g> I am also always interested/working on/helping with toolchain updates and niche debcargo features for packaging in downstreams/derivates or for crates not (yet) published on crates.io
21:50:49 <f_g> long-term I'd also like to get stuff like clippy and rustfmt package into Debian proper so that we no longer have to install rustup-provided versions of those ;)
21:51:06 <f_g> but that needs more stabilization upstream, not really much to do in Debian on that front right now
21:51:25 <f_g> besides that I package stuff I stumble upon that seems useful from time to time
21:52:03 <f_g> and I might attempt to package proxmox-backup-client once that hits stable, which will probably be too late for bullseye based on the number of not-yet-packaged/updated deps in Debian proper ;)
21:52:19 <silwol> +1 for rustfmt. I set up a new ubuntu 18.04 machine at work, they have backported a rather recent rustc from debian, but for getting rustfmt I had to use rustup (because it only compiles on nightly for now afaik).
21:52:37 <f_g> in general I don't have much pain points with rust packaging in Debian, the current way is fast enough for downstream work and stuff I want to install on my machines that I am not too worried about Debian moving slowly
21:53:06 <kpcyrd> I think I've mentioned my current status earlier, I was trying to make sniffglue transition/upload the new version to fix bugs. I'm also trying to upload dfrs (which is tiny) but depends on one of the stuck crates. The other dependency I was working on was sn0int, which is also the package kali/tracelabs are interested in. I've prepared a package for them that downloads from crates.io
21:53:08 <f_g> but I'd like to push stuff I do anyway into Debian proper so that more people benefit from it
21:53:09 <kpcyrd> (still waiting on feedback): https://salsa.debian.org/kpcyrd/sn0int
21:54:19 <kpcyrd> besides that, I joined Arch about 9 months ago and spent more of my time packaging there and only responding to irc hilights here
21:55:25 <silwol> anybody else?
21:55:54 <silwol> kpcyrd: cool you joined arch, seems like you're making good progress there.
21:57:14 <kpcyrd> (oh, also found a 30h/week job after being unemployed for a while!)
21:57:26 <silwol> congrats!
21:57:41 <silwol> 30h <-- best decision ever :-)
21:57:46 <kpcyrd> yeah, same
21:58:27 <silwol> I think we'll close now, it's getting late. wookey_ if you return, feel free to post your ideas later as well, people read the backlogs and answer :-)
21:58:36 <silwol> thanks everybody!
21:58:44 <kpcyrd> thanks for hosting this!
21:58:58 <silwol> #endmeeting