18:58:59 #startmeeting 18:58:59 Meeting started Wed Aug 26 18:58:59 2020 UTC. The chair is silwol. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:58:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:08 Welcome everybody! 18:59:14 hi! 18:59:22 Hello 18:59:36 #topic agenda 18:59:48 I created a wiki page at https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda for collecting the agenda topics. 19:00:47 My idea is that we collect the topics between the IRC meetings. 19:01:24 just made it 19:01:27 I simply created it in the debian-conf namespace, not sure it's exactly the best place. 19:01:34 welcome wookey_ 19:02:30 any input on this topic? 19:03:06 which topic? 19:03:21 where to put the agenda? 19:03:27 exactly. 19:03:58 I'd use the debian wiki rather than the salsa wiki for this sort of thing 19:04:11 but I don't suppose it matters much 19:04:11 silence is consent ;-) 19:05:23 for me it doesn't matter. I didn't think about the debain wiki as I don't use it that much, the thought was more whether the debcargo-conf namespace is the correct one. 19:05:33 but debian wiki is a good idea also. 19:05:46 I'd expect that to be about debcargo-conf package 19:05:58 the debian wiki is the right place for info not specific to packages 19:07:25 it mainly is, but we'll probably also touch other relate topics in the future. 19:07:52 I think we'll leave it as is for now, except if somebody comes around with a proposal. 19:08:04 #topic status updates on the topics from the previous meetings 19:08:11 if you are used to using salsa to organise the team then putting all the info on salsa makes sense I guess. 19:10:00 I contacted the golang team and asked for the information about working on a repository for build-time deps only. 19:10:34 they already had a bug report on which people from our team commented that weren't present on the previous meeting. 19:10:56 * silwol looks up the bug no… 19:11:12 #idea dedicated Salsa project for orga stuff as an agenda 19:11:43 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949163 19:12:42 I didn't get around to contact any of the other teams as mentioned in the todo. 19:13:27 kpcyrd: you mentioned you were in contact with kali people, would you like to talk a bit about their stance? 19:16:36 yes, hold on 19:20:30 here (better late than never ;)) 19:20:46 welcome f_g 19:21:28 you've not missed much :-) 19:21:35 I'm here too... sorry for being late! 19:21:55 welcome eriol 19:23:13 while we're waiting for kpcyrd's report, I can in the meantime tell that I didn't manage to contact f_g, so no process on creating the feature-collapsing PoC :-( 19:23:39 indeed. been busy with non-Debian stuff like vacation ;) 19:24:10 there has been 'progress' by the way of lots of REJECTs, and the BoF today though. 19:24:24 so maybe a report from that would be interesting for those that missed it? 19:25:09 f_g we have that on the list, we're currently wrapping up the status of the todo list from the previous meeting. 19:25:19 ack 19:25:23 (I updated https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda accordingly ;-) ) 19:25:29 my take on the BoF: we didn't really have that much of solutions in the BoF, it was more that people shared their frustrations and got to meet eachother 19:25:54 oh, sorry for going out of turn :) 19:26:02 got a call, be back in a few min sorry 19:26:31 maybe we should talk about the debian-rust mailing list topic? 19:27:21 stappers: you wrote to the listmasters, would you like to report what the status is there? 19:28:15 The sad news is there is nothing to report. 19:28:44 Listmasters didn't yet respond. 19:29:06 In attempt the break the silence 19:29:36 +1 19:29:43 I did invite listmasters to attend this IRC meeting ( silwol had CC ( yesterday )) 19:29:53 stappers: do you have the needed advocacy for the request? If I recall well you mentionned 2 DD should be "supporting" the request 19:29:56 I read that. Not sure any is present. 19:30:21 I'm a DD 19:30:28 I'm a DD too 19:30:34 hapy to support the idea that rust should have a mailing list 19:30:45 me too of course 19:30:48 * stappers is not sure about the minium DD count for a new ML 19:30:48 surpried you don;t have one already! 19:31:06 wookey_: we do, but it has a difficult-to-remember address, and is spammed by package upload messages. 19:31:08 wookey_: there is an alioth one that is the maintainer address 19:31:30 we'd like to have debian-rust@, but keep pkg-rust-maintainers@ for the package upload messages. 19:31:41 right. makes sense 19:32:07 that's where I just looked, to see no list :-) 19:32:15 eriol: wookey_ please use your "DD status" on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966088 19:32:53 Will do 19:33:00 :-) 19:33:13 sure! :) 19:33:41 #todo eriol wookey_ write support e-mail to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966088 bug 19:34:03 anything else open from the to-do list? 19:34:33 stappers: https://www.debian.org/MailingLists/HOWTO_start_list - says that it s appreciated if other shows shared interest - does not seem mandatory but can't harm :) 19:34:45 infinity0: wanted to write a TCTTE draft AFAIR 19:36:13 OK. bug mailed 19:38:06 f_g seems the item didn't land on the todo list, so no idea whether the idea was to write a draft already. 19:39:30 I guess that's related to the NEW/debcargo/crates issue which we'll no doubt get to shortly 19:40:15 kpcyrd: should we proceed to the next topic and you tell your report later? 19:40:23 silwol: see 21:40:58 ff from last log 19:40:32 I'm back 19:40:41 cool! 19:41:10 ok, so kali would like to ship rust software, but they would prefer something that's simpler than what we're currently doing (until the software landed in debian proper, at which point they would drop their package) 19:41:54 do they have any plans to implement something by their own? 19:43:03 they are still looking for an approach that builds offline, now I'm wondering what's the easiest way to 1) take the upstream tar ball 2) populate it with cargo vendor 3) repack it as tar ball and proceed with regular debian tooling 19:43:31 for the 3rd step I'm lacking knowledge about how to do that with debian tools 19:43:56 kpcyrd: you could look at what src:cargo does in Debian 19:44:05 (not src:rust-cargo !) 19:44:11 and I'm not sure what's the right channel to get support, #debian-devel is probably just for debian specifically 19:44:17 f_g: good hint, thanks! 19:44:52 dpkg-source will repack a debian source tree 19:45:13 that might be what you are looking for 19:45:37 it's basically what we do for cargo the binary package, vendor all the crates it depends on so that we don't have the cargo <-> debcargo-conf bootstrapping problem 19:46:38 sounds great, I'm going to look into that and ask in #debian-rust if I'm stuck :) 19:47:11 https://salsa.debian.org/rust-team/cargo/-/blob/debian/sid/debian/scripts/debian-cargo-vendor 19:48:05 It looks like I'll have to leave in about 20mins. 19:48:27 dpkg-source -x package.dsc, add crates, dpkg-source -b 19:48:50 we can proceed to the next topic! 19:49:11 #topic summary of the BoF earlier today. 19:49:35 who would like to give the summary? 19:49:59 you were there :-) and knwo what's what :-) 19:50:12 I tried my best. 19:50:38 but it's difficult for me to summarize. 19:50:52 of course the main topic was the ftp/binpackage problem. 19:51:59 I think we found that FTPmasters (at least according to Waldi, and no others came despite being given opportunity) 19:52:25 really are no longer going to accept the existing debcargo scheme 19:52:42 So we can: 19:52:46 yeah, they were quite clear on that 19:52:48 1) give up a go home 19:52:55 2) change to some other mechanism 19:53:02 3) take it to the technical committeee 19:53:38 It ewas good to have some go people present as they are in a similar situation 19:53:54 but have chosen a more conventional packaging system 19:54:22 I assume the go people don't have the problems in the same way we do, as the go bulid system doesn't support features from what I can tell. 19:54:36 Agreed - there are technical differences 19:54:59 which I have not yet grokked 19:54:59 What we have in common is the static-lib issue though. 19:55:07 or better, static-compilation. 19:55:43 from what I assume the issue is that debian is mainly designed to work well with shared libs, and reflects that in the packages. 19:56:18 the debian security team had a question on how we track security issues in crates when everything is statically compiled, and I think our answer was that we don't 19:56:25 we talked about mechanisms to do rebuilds when there are updates to libraries 19:56:29 if you find a security issue for example, you fix that, and as long as no ABI-incompatible changes were made (which rarely is necessary for that type of problem), you just replace the affected lib with a fixed version. 19:56:50 that would be an nice thing to work on at some point in the future 19:56:59 capitol: you basically re-compile leaf packages that ship binarys that are built-using the affected library crate 19:57:01 with our packaging scheme, we upload source code into binary packages, so once we update a lib, we have to recompile the affected bin packages. 19:57:03 capitol: right, and it's not unreasonable to ask that we make one 19:57:05 but no automation for that yet 19:57:22 f_g: yes :) 19:57:58 is that a solved issue in golang? it seemed to me that they don't have a solution to that eiteg. 19:57:59 either. 19:58:15 silwol: yes I think they are looking for something too 19:58:49 in the trivial/API compatible case its a grep on build info + schedule bin-NMU 19:59:03 It was noted that the haskell team have a system, but that is tpo deal with the fact the the abi for everything changes when the compiler is updated 19:59:13 which is a bit different 19:59:20 in the non-trivial case, it's the same as for shared libs that break ABI in a security fix, look at the breakage, fix it, do an upload 19:59:37 wookey_: rust is the same, which is why nobody does shared linking 19:59:43 I think a shared solution between the teams - or one that is similar in handling by the security and release people - would help here. 20:00:02 (so rather package metadata than anything rust-specific) 20:00:14 f_g: right, I see. so we _could_ do that, at the cost of having to rebuild _everything_ on a regular basis 20:00:26 we could pull security information from: https://github.com/RustSec/advisory-db/ 20:01:00 wookey_: in theory yes. in practice, there are a few road blocks to even do that ;) 20:01:23 f_g: OK, what is the problem? 20:01:39 capitol: https://github.com/RustSec/cargo-audit might help here as well. 20:01:52 I don't have the details handy, but a colleague did an attempt at shared linking at work and there were quite some more caveats beside the whole 'toolchain update invalidates all the built binaries/libs' 20:02:24 IIRC something regarding the std lib, and intra-crate linking 20:02:39 I saw something about symbol mangling. I need to investigate/understand this 20:03:23 I talked to efraim (rust-guix, was in the bof today) in person after their rust presentation on fosdem, they have similar problems. 20:03:43 The current security assumption is that it only needs to be fixed in one place, and that package gets fixed, re-uploaded and built 20:04:15 that's not really true because we already have embedded libraries so somtimes more than one thing needs to be fixed/uploade/rebuilt 20:04:23 true, and in our scenario we have the additional point "find all affected leaf packages and rebuild them as well". 20:04:23 yes, but they already needed some mechanism/tooling for go for Buster IIRC 20:04:31 the number just rises for statically-linked things 20:05:18 yep. and it's mostly automatable (as in, a script that gives you all the packages needing a rebuild/bin-NMU given a fixed lib crate package) 20:05:20 seems to me that fixing this for the general case in the tooling that the security team use would be a good plan 20:05:58 a generic one that detects whether the fixed package is a go/haskell/rust/.. package and then runs the appropriate lookup over build info is probably a good idea 20:06:13 first step would be to ask them whether they have anything like that already that could be extended to support rust 20:06:42 some tool that knew how to follow the build-deps/build-info/built-with metadata for various languages and schedule/order builds/binnmus as required would make a lot of people happy 20:07:28 does any of these metadata sources already contain everything required? 20:07:57 I presume that the necessary info can be extracted, but I don;t actually know. 20:08:16 The catch is having to grok 8 different languages and their tools :-) 20:09:06 IMHO the bigger question is how to proceed w.r.t. ftp-masters and debcargo 20:09:27 I remember this tool for Go: https://tracker.debian.org/pkg/ratt but I don't know if it covers the security related use case. I used Go several years ago, but never used it. 20:09:54 I've been using that tool successfully recently 20:09:59 f_g yes, that's currently the most pressing issue to unblock. 20:10:13 it uses dose to calculate reverse dependencies and then invokes sbuild to build each of them 20:10:35 I was going to say that dose can probably help us work out the deps 20:11:00 should we make a list of people that want to look at the security tooling problem and continue to the ftp-master problem? 20:11:09 I have to leave soon also 20:11:18 I'm willing to be on that list 20:11:37 Sure 20:12:17 the security thing is important, but not as urgent as 'our whole language is blocked until we think of a new plan' 20:13:19 I think we have to decide if we want to fight or acquiesce 20:13:33 just to throw something radical out there: could we vendor all dependencies instead? 20:13:52 capitol: `cargo-deb` ;-) 20:14:17 capitol: you mean put all the deps in the source of each rust package? 20:14:22 #topic debcargo future / ftp masters rejects 20:14:38 not sure the security team would be happy about that, I think it would be too easy to overlook vendored crates. 20:14:54 capitol: I don't think either ftp-masters or security would be happy about that approach 20:15:05 see discussions about kubernetes a few months back on -devel 20:15:28 it also scales rather badly when more and more tools written in rust get packaged 20:16:00 plus you'd have many libs in different versions. 20:16:02 (if you don't want to drop all pretense of packaging the deps sanely, e.g. try to avoid duplicate versions, vendored bindings, ...) 20:16:02 so they want one package per crate, but not our current solution for features 20:16:06 I'm up for doing some analysis on the current situation and what happens if we collapsed all the features 20:16:38 which seems to be the main sticking point 20:16:42 capitol: not necessarily. e.g., the JS team sometimes bundles small modules into a single source+bin package 20:17:04 but yes, they don't like that we ship many empty binary packages 20:17:15 #todo silwol still would like to work on adding the feature-collapsing to debcargo. 20:17:20 they also don't like that we do a lot of provides encoding semantic version info in the provided package name 20:18:04 both would be reduced if we don't enable all features by default 20:18:59 f_g do you think some kind of "whitelisting" for features, or simply patching out everything we don't need? 20:18:59 but both would only go away completely if we don't automatically convert the info from Cargo.toml to d/control, but instead specify it manually on a case-by-case basis 20:19:53 IMHO a map of {"bin_package_a" -> ["feature_1", "feature_2"], ...} would be the most sensible middle-ground approach 20:19:54 f_g: yes, but that's what packaging is. 20:20:47 It's nice to have totally automatic packaging from upstream's module system, but sometimes that doesn;t really make sense, or upstream's sysem is just to crazy to map into a distro well 20:21:17 We only have to do it once for each package, don't we? 20:22:19 (sorry if I'm asking dumb questions here - I'v enot yet taken the time to propoerly understand this stuff) 20:22:22 what if we default to collapsing all features in a package with a specific naming scheme? it would help us to find and exclude features that miss dependencies, and it would only require work on packages that depend on such packages that were not collapsed. 20:22:34 (thus saving us from polluting the provides lines) 20:22:51 wookey_: you'd have to do it for both sides of the dep relation if you do it fully manually 20:23:05 and upstreams basically change/add/remove feature every second patch release for some crates 20:24:02 rust makes up ~4% of source packages in main, I think it would not be very feasible to have this kind of overhead for packaging lib crates 20:24:17 a single binary can easily have hundreds of transitive dependencies 20:24:55 f_g: if we add metadata to a package to conflate features, why can' tthat metadata be used automatically by things that depend on the package? 20:25:18 i.e why do we have to 'do both sides manually'? 20:25:46 because debcargo as a standalone tool does not know/care about the current instance of debcargo-conf 20:26:06 so it would not know where to find that information 20:26:15 it operates on a single crate at a time 20:27:29 Does anyone think that in fact debcargo is just the right way to do this and the FTPmasters are wrong to reject it? 20:27:52 i.e we should write a complainto the technical committee? 20:28:02 infinity0 definitely does ;) they're also the main author of debcargo :-P 20:28:50 I think debcargo works quite well, but I can understand some parts of the criticism. it's rather different from most other packaging approaches 20:28:50 I haven't understood if we are running into some sort of technical limitation, or if it's just someone who thinks it's ugly 20:29:26 I don't have very strong opinions on that. I have been maintaining an in-house repo with a major part of the crates for some time, and it worked really well. 20:29:27 ah yes, one other thing of significance from the BoF. When asked about 'why are we going through NEW', FtP masters did sort-of agree that if there was a reliable way to distinguish being 'real NEW' and 'NEW that should be autoaproved' then maybe that could be done 20:29:34 I think it's mainly an argument of 'this is a waste of resources'. both human (bin-NEW triggers ftp master reviews) and machine (bigger Packages files -> more parsing overhead -> ...) 20:29:50 but we have the shared resource "package index", and from that pov I understand that there are some issues. 20:30:54 wookey_: according to waldi they basically have that reliable way, but they decided that rust isn't worthy of getting access to it :-) 20:31:13 So it may be worth pushing the idea that manual NEW review could be skipped in specific circumstances, if we could reliably define those 20:31:47 silwol: hmm, that's not what I understood from what was said. I thought he said there was no such mechanism 20:32:08 (implying that if there was a mechanism they were happy with, then maybe it could be done) 20:32:23 * stappers was not at the BoF 20:32:41 as I said earlier, I assume that waldi's position may not be same as the one of the majority within the ftpmasters team, but that's just my impression from the outside. 20:32:41 wookey_: it would basically be 'auto-approve bin-NEW for librust-.*+.*-dev' 20:32:50 Which other FTP masters beside Waldi did speak? 20:32:57 as those are always empty semantic packages atm 20:33:16 stappers there was a general invitation addressed to the ftpmasters team, but only waldi showed up. 20:33:28 f_g: but those packages are actually 'genuinely NEW' on initial upload 20:33:34 chips 20:33:43 If I understood it correctly waldi said they have such a mechanism, but it's more targetted towards kernel packages et al. 20:34:11 f_g but 'genuinely NEW' is also triggered on new source packages, right? 20:34:22 silwol: yes 20:34:22 wookey_: no, on first upload rust-* is NEW 20:34:45 on a 'new/renamed/...' feature upload, only librust-.*+.*-dev are bin-NEW 20:34:51 OK. I see what you mean. Should work 20:35:13 and the non-features bin package which is built from every rust source package would also be new on the first upload. 20:35:21 Waldi claimed to speak for all ftpmasters on this. We don;t know if that's really true 20:35:35 But I have no reason to doubt it 20:35:55 but such an auto-approve would just solve our problem of long bin-NEW wait times 20:36:08 it does not remove the concerns about the index/Packages file 20:36:14 f_g: exactly 20:36:20 IMHO that matters 20:36:22 and it's unlikely we get such an auto-approve before we managed to clear those concerns 20:37:05 so it's back to square one - do we want to attempt CTTE to get a third opinion on whether our usage of Packages to encode semantic information is okay 20:37:28 and if no, or if yes and it fails, how do we reduce the number of things we encode there 20:37:49 1.) don't package all features, but only a sub set that is explicitly specified 20:38:12 2.) don't split binary packages by feature (sets), unless explicitly specified 20:38:23 was what I proposed back in the salsa issue 20:38:32 I'd possibly even add 20:39:11 3.) don't encode semantic versioning information in provides, instead implement a mechanism to map package names in rdeps to support the rare case of multiple lib crate versions in one release 20:39:23 then we can instead do plain versioned build-deps 20:39:42 This is the way I would try to go if it was up to me. 20:40:22 the first two would work simply on the rdep side, the third one would need to be done on both sides of the packaging equation, but is/should be a rather rare occurrence 20:40:40 as I put in the etherpad, we currently have 14,148 binary package from 767 source packages 20:40:48 that's excessive IMHO 20:41:30 yes, and lots of features that are no used by any rdeps, but it's hard to tell how many of those are just unused because stuff that would use them is not yet packaged/did not make it through NEW (yet) 20:41:40 18 binaries per package 20:42:27 that seems more than I would assume from my experience working on the packages. 20:42:44 I'd also say that there are some false positives or some massive outliers in there 20:42:45 I'd also push back upstream on the static/dynamic thing. People are ARM are doing this too 20:42:48 are these true bin packages, not provides? 20:43:10 silwol: not sure - I did some quick apt-cache grepping last night 20:43:49 I don;t think apt-cache shows virtual provides, but it may show non-virtual provides. I forget the details 20:43:52 if the provides were included the number would be around what I'd expect. 20:43:58 I count ~1700 bin packages in main, for ~800 source packages 20:44:39 (via grep-dctrl | sort -u | wc -l, so might have some noise in it as well) 20:44:43 OK, that sounds a lot better 20:44:53 It was 2am :-) 20:44:57 thats nearer to what I'd expect. 20:46:06 so basically, that number could be reduced to match nearly the number of source packages, and the provides could possibly removed if we didn't encode the semver information in our version numbers, right? 20:46:14 that 14,000 is from apt-cache dump | grep librust- | grep Package: | sort | uniq | wc 20:47:49 yes, that includes provides at a quick glance. 20:47:59 OK. 20:48:30 silwol: ISTM that the semver info should only be encoded in package names when you need to have more than one in the archive at once 20:48:53 wookey_: or not even then, you just need to tell the rdep to explicitly depend on the older package 20:49:01 yes, I also think it is the exception to have more than one version. 20:49:02 for that vast majority of packages where 'latest' will do it's not needed 20:49:21 From the design it looks to me as if it was intended to provide smooth migration to newer versions. 20:50:12 I also think the package name without the version number in the name was not there from the beginning, but got introduced at a later point. 20:50:39 right. I saw some debate about that in a bugrep 20:50:46 yes, the current mechanism allows to upload a crate B that depends on crate A ver X 20:50:58 so all packages were intended to look like librust-rand-0.6-dev, but that was in the time before the first crate packages got uploaded to the archive. 20:51:09 and even if we later upload crate A in ver Y, and re-upload crate A-X for version X, the old built crate B is still vaid 20:51:47 the new mechanism would require a rebuild of crate B with a flag to encode the version X of A in the dependency package name 20:52:44 which is okay, as that is supposed to rarely happen, and if it does, it's a simple rebuild without any other changes 20:52:48 I worked on the rand 0.6 to 0.7 migration some time ago, and the main blocker was getting 0.6 through NEW before updating the non-version-named package to 0.7, just to have the 0.6 packages removed afterwards. 20:53:13 silwol: even more reason to make that a rare exception ;) 20:53:33 I also think if we make the parallel version installable package the exception this increases the pressure on us to push upstream. 20:54:16 It seems to me that we may be reaching a consensus amongst those present on the direction to take? 20:54:32 BUt we may get disagreement from those not [present 20:54:57 true. so how do we proceed on this topic? 20:55:04 all this still requires someone to do some work 20:55:43 infinity0 expressed thy would take a look at the MR if we proposed one. 20:55:45 If we had a mailing list, I'd say a summary to the list :-) 20:55:55 wookey_: silwol and me already volunteered trying a PoC for debcargo last time, we just didn't do it yet. I am not that familiar with CTTE and policy to weigh in whether we want to go down that route 20:56:10 I'd be willing to work on debcargo, but I can't promise I'll be able to invest a lot of time, so help would be welcome. 20:56:51 https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers for now. 20:56:56 I think the action is to look seriously at what a new scheme would look like 20:57:21 what that does to the number of packages and provides and circular dependencies 20:57:28 I just don't know if I would able to work on something like this, but as I said I changed job to have more time, so I can help here if someone can mentor me. 20:57:35 I'll try to find some time in the next 2 weeks to start on the feature/bin-package filtering feature and flesh that out more as well 20:57:57 I think the version thing is fairly straight-forward, it's mostly dropping or selectively disabling certain code paths 20:58:04 I have some expertise in dependency analysis, but very little in debcargo yet 20:58:27 Last 3 weeks I have done nothing but wall insulation :-) 20:58:39 wookey_: I think the main issue is that it's hard to estimate what the additional work load to think about and manage those feature sets will be 20:58:46 I have to leave, I'll read the rest of the meeting tomorrow 20:58:48 but it might be that we don't have a choice anyway 20:58:54 I put last board up 3 hrs ago, so when I go back to work I can spend some time on this 20:58:56 bye capitol 20:59:04 bye capitol! 20:59:49 Thanks for a productive discussion. 21:00:08 f_g is it ok for you to contact me when you want to work on this? I usually have my day off on fridays, and when school starts again, it will be easier to allocate that for whatever I want. 21:00:36 apart from that, evenings are ok as well most of the time. 21:01:14 I imagine I could start hacking, but I'm sure I would miss many edge cases and ideas you already thought about. 21:01:29 yes, sure :) will probably end up being the first week of school anyway ;) 21:02:20 #todo f_g silwol hack on feature-collapsing in debcargo (again ;-) ) 21:02:34 for real :-P 21:03:01 ok, so I think we'll leave this topic for now. feels like we're making some progress. 21:03:32 #topic overview page for packaging 21:04:14 I stumbled over https://go-team.pages.debian.net/ some days ago, and found that a really great entry point for people new to a team. 21:04:47 I think we should put the idea of creating something similar on our radar. 21:05:03 (no immediate action required, just wanted to drop it so it's seen by others). 21:05:23 that's all from my side. 21:05:36 any other topics? 21:05:57 not from me 21:06:16 silwol: looks similar to the wiki.d.o page: https://wiki.debian.org/Teams/RustPackaging ;) 21:07:04 basically yes, but more structured and better-looking. 21:08:31 :D 21:08:37 although I'd say our page contains much more detailed information than required for a newcomer. I also really like the short list of helpful links for daily packaging tasks that is easy to spot. 21:08:57 would not hurt for sure, just needs to be kept updated as well.. 21:09:10 (I don't have any other topics either btw) 21:09:22 ok, then I'd say we close the meeting. 21:09:28 thanks everybody, see you next time! 21:09:32 #endmeeting