21:00:01 #startmeeting Rust SIG (2017-02-01) 21:00:01 Meeting started Wed Feb 1 21:00:01 2017 UTC. The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:01 The meeting name has been set to 'rust_sig_(2017-02-01)' 21:00:04 #meetingname rust-sig 21:00:04 The meeting name has been set to 'rust-sig' 21:00:08 #chair ignatenkobrain jistone 21:00:08 Current chairs: ignatenkobrain jistone 21:00:11 #topic Agenda 21:00:14 #info (1) Roll Call 21:00:18 #info (2) Current State of Packaging 21:00:22 #info (3) Wildcard Versions 21:00:25 #info (4) Normalize versions for RPM 21:00:29 #info (5) Boilerplate in %install 21:00:32 #info (6) Packaging binaries (and libraries together) 21:00:35 #info (7) Optional dependencies which do not exist 21:00:38 #info (8) Open Floor 21:00:41 #topic Roll Call 21:00:45 .hello ignatenkobrain 21:00:46 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 21:00:55 .hello lupinix 21:00:56 lupinix: lupinix 'Christian Dersch' 21:00:59 .hello jistone 21:01:00 jistone: jistone 'Josh Stone' 21:01:01 .hello ngompa 21:01:05 Pharaoh_Atem: ngompa 'None' 21:01:11 phooey 21:01:12 Pharaoh_Atem: fill your name :D 21:01:20 FAS knows who I am, damn it 21:01:24 anyway, Neal Gompa :) 21:01:34 someone else? 21:01:52 bah, I'm me (Neal Gompa) 21:02:00 okay, so let's move on 21:02:01 if I'm not me, then... I don't know who I am...? 21:02:04 anyway 21:02:04 #topic Current State of Packaging 21:02:09 #info We have RPM macro for build/install procedures, dependency generator and even generator of spec files! 21:02:12 #link https://pagure.io/fedora-rust/rust2rpm 21:02:44 nothing actually packaged with this yet, right? 21:02:46 Also, /me did initial work on crates.io for release-monitoring.org and jcline fixed it a lot ;) 21:02:53 jistone: no, just playing around still 21:03:06 finishing macro / tools / etc. 21:03:11 ok, and that's fine, what I expected 21:03:17 .hello jflory7 21:03:18 jflory7: jflory7 'Justin W. Flory' 21:03:42 we can slowly write guidelines in our repo and host it and when everything will be agreed -- we can promote for FPC 21:03:55 any questions on current state? 21:04:13 do we have any particular targets to package initially? 21:04:16 .hello akien 21:04:17 Akien: akien 'Rémi Verschelde' 21:04:24 Pharaoh_Atem: good question 21:04:29 ripgrep is a juicy target 21:04:30 .hello msehnout 21:04:31 msehnout: msehnout 'Martin Sehnoutka' 21:04:34 ripgrep \o/ 21:04:46 mou... even Akien's name shows up on hello 21:04:49 jistone: how many deps does it have? 21:04:59 maybe cargo itself, but that's special 21:05:34 ripgrep is around 30 afaics 21:05:46 (some might be optional, that's just from a quick cargo-tree) 21:06:02 https://crates.io/crates/ripgrep 21:06:04 this one, right? 21:06:11 yep 21:06:11 yes 21:06:18 makes sense! 21:06:35 (I've been using it locally for a few months, I love it :D) 21:06:54 there's a package review already, but they didn't attempt offline builds 21:08:04 #info initial target is to package ripgrep and its dependencies (definitely should be build-able in koji which means w/o network as well) 21:08:13 For the reference, list of applications made with rust: https://github.com/kud1ing/awesome-rust#applications-written-in-rust 21:08:29 (I think trying to package a few applications is funnier than just packaging lib crates without end product in mind :p) 21:08:46 yeah, long target could be servo ;) 21:08:56 generally, I wouldn't bother with any crate until it's needed for a leaf app 21:09:10 I agree. Packaging the whole of crates.io would be impossible 21:09:20 I dunno if I want to package all of crates.io... 21:09:48 I know I don't want to :P 21:09:50 I think crates should be packaged on an ad-hoc basis as they're needed, just as we do with golang and.... nodejs... 21:09:53 jistone: for me first step was to package libs because without that we can't proceed 21:09:59 yep 21:10:07 and putting Requires/Provides/Conflicts all the way is bad idea 21:10:21 unless you find a lucky app built only with libstd 21:10:34 * ignatenkobrain doesn't expect to find such 21:10:39 jistone: that's going to be rare 21:10:46 there's no compelling reason to do that 21:11:03 I know, see my toungue in my cheek over here 21:11:20 *tongue 21:11:41 anyway 21:11:43 Talking about packaging the libs that we need for leaf packages.. do we have plans regarding how and how often we'll want to package new versions of those crates? 21:12:04 good question 21:12:18 well, ideally, we should be systematically updating them as anitya tells us about them 21:12:21 *if* we split up cargo to use these, then I expect that to be the biggest driver of updates 21:12:33 Could we have a kind of tool that could analyse the requires/conflicts to show us which crates could be safely updated to e.g. a new minor? 21:12:49 (I mean analyse all the rust stack we package) 21:12:51 I think that's going to be necessary 21:13:00 Pharaoh_Atem, if we blindly do that, we'll certainly cause ftbfs 21:13:02 I think we want to keep stuff updated as much as possible 21:13:14 jistone: note "ideally" 21:13:28 a similar question is whether we want to ever package multiple versions of a crate 21:13:28 jistone: well, definitely we're not going to do this blindly 21:13:29 So we could identify that libfoo 1.2.0 can actually move to 1.4.x as all its reverse deps require 1.0 or later 21:13:42 jistone: this is also good question 21:13:50 unfortunately, I think we're going to have to 21:14:03 jistone: it depends... if upstream supports "LTS" versions and other stuff depends on this.. 21:14:04 yeah 21:14:13 multiversioning is already something that the php, golang, ruby, and nodejs packagers in Fedora deal with 21:14:18 but unless we really need this, I would prefer to not 21:14:22 I think the rust ecosystem is not so LTS minded so far 21:14:27 LTS on a project less than two years old yet, ha! 21:15:22 but we need enhancements in RPM to properly handle this in a way that makes the requirement get handled as a single unit, and also allows for multiple versions to be installed in parallel to satisfy different programs 21:15:25 we should really just go ahead and file issues to upstream (and fix if possible) 21:16:01 But yeah, I think a first step could be to focus on packaging e.g. ripgrep in a copr and see how it goes 21:16:03 this is not unique to us, of course: https://bugzilla.redhat.com/show_bug.cgi?id=1389871 21:16:17 That should answer some of our questions, and bring many new ones :) 21:16:28 yes 21:17:29 and as Akien and I do double-duty in Fedora and Mageia, we can leverage COPR to help us evaluate issues as they crop up for all of us (Fedora, Mageia, and EPEL) rather quickly 21:18:09 okay, so we have initial target. 21:18:10 #topic Normalize version for RPM 21:18:16 #link https://pagure.io/fedora-rust/rust2rpm/issue/3 21:18:39 #link https://pagure.io/fedora-rust/rust2rpm/issue/3 21:18:53 does "link" even work? 21:18:54 if the semantics of 0.9.3~rc3 are the same, your plan sounds fine 21:19:02 Pharaoh_Atem: it does 21:19:28 jistone: I'm not sure about very complicated ones 21:19:35 like .rc8+post1 21:19:44 I think this is rare in crates anyway 21:19:52 yes 21:19:57 so I need volunteer ;) 21:20:01 jistone: the semantics of versioning are described here: https://fedoraproject.org/wiki/PackagingDrafts/TildeVersioning#Basic_versioning_rules 21:20:02 it should be very easy task 21:20:19 I only *just* found out that such deps broke old cargo, which indicates that no one was really doing this 21:20:31 hehe 21:20:51 where all those brave volunteers? ;) 21:21:02 what do you want us to be brave about? :) 21:21:04 oh fine, I'll take this one 21:21:06 :P 21:21:26 #action jistone to implement normalizing pre-release versions for RPM 21:21:36 #topic Wildcard Versions 21:21:41 #link https://pagure.io/fedora-rust/rust2rpm/issue/6 21:21:48 wildcard versions should be relatively easy to handle 21:21:54 especially since * is now forbidden 21:22:18 As Josh pinted out, it seems it's possible to normalize it to tilde version 21:23:11 does that even resolve in rpm? 21:23:15 the library which we are using doesn't support wildcards 21:23:17 I thought ~ only works as a suffix 21:23:21 not as a prefix 21:23:37 Pharaoh_Atem: I mean to tilde version in terms of semver 21:23:39 ah 21:23:43 then we do our magic 21:23:48 yes, in terms of semver, it works 21:23:48 for Req/Con 21:24:22 #link https://github.com/rbarrois/python-semanticversion/issues/51 21:24:44 so we probably don't want to implement only our own solution, but also to contribute to library which we are using 21:24:52 really, though, * means we don't specify a version 21:24:56 that's easy enough to do 21:25:20 true 21:25:38 rpm naturally handles versionless deps anyway 21:25:42 so we're fine in that regard 21:25:48 Pharaoh_Atem: hmm 21:25:56 but you forgot essential part 21:26:04 oh? 21:26:14 1.2.* -> Req: >=1.2.0 + Con: >=1.3.0 21:26:21 yeah, that needs to work 21:26:27 I was referring to "*" as a dep req 21:26:33 not x.y.* 21:26:42 ah, this is deprecated and very trivial to implement ;) 21:26:53 volunteers? 21:27:00 * ignatenkobrain can do this as well 21:27:03 if no one else wants 21:27:44 #action ignatenkobrain to implement support for wildcard versions 21:27:46 #topic Boilerplate in %install 21:27:50 #link https://pagure.io/fedora-rust/rust2rpm/issue/7 21:28:07 this is more interesting thing ;) 21:28:25 basically I would prefer to stop doing %cargo_install_crate %{crate}-%{version} 21:28:32 that could just assume %{crate}-%{version} 21:28:48 unless you pass -n switch or something 21:28:56 %cargo_install sounds great :) 21:29:14 because it's 1) duplicate of name-version info 2) duplicate of lib/bin info which metadata has 21:29:16 the only reason to have that in my prototype was in case something had multiple crates to install 21:29:31 jistone: are they all coming from same Cargo.toml? 21:29:34 or how does this work? 21:29:36 some example? 21:29:42 hypothetical 21:29:48 you wouldn't get this from crates.io 21:30:05 if you perhaps had some other source tarball with multiple crates to provide 21:30:14 iow, we probably don't need this flexibility 21:30:18 ignatenkobrain: I think by default, it shoudl assume %crate-%version, but we should probably have a "-n" switch to let us override it 21:30:19 then we should be fine 21:30:21 *should 21:30:32 %cargo_install for binaries 21:30:38 %cargo_install_crate for source lib 21:30:39 Pharaoh_Atem: why should I care as maintainer what it shouljd do under the hood? 21:31:09 jistone: that seems a bit awkward 21:31:12 I'm thinking mainly of people building packages from private crate repos, which may be more flexible than crates.io 21:31:13 ignatenkobrain: Well you should care in case what it does under the hood is not what you need :D 21:31:19 or bundling more crates in one package 21:31:44 Pharaoh_Atem: then you change directory and do %cargo_install, no? 21:31:52 fair point 21:32:02 as long as the Cargo.toml is well-formed, that should work 21:32:08 we rely on current directory as on something what we should copy 21:32:15 ignatenkobrain, %{crate}-%{version} doesn't care about directory 21:32:27 oh, you mean not to even use the rpm vars 21:32:33 jistone: yes 21:32:36 just %cargo_install 21:32:45 it will do cp for lib and cargo install for bin 21:32:50 right, but I thought that might use the vars inside 21:32:54 as we do now, but it will choose automagically 21:33:33 should there be a sanity check that rpm's %{crate}-%{version} matches Cargo.toml? 21:33:51 jistone: one problem is that we don't really define crate.... 21:34:00 it's up to maintainer to define it that way 21:34:14 and as Pharaoh_Atem mentioned, if you package multiple crates in one RPM.. 21:34:19 that will just be broken 21:34:28 unless you play tricks with redefining crate 21:35:18 it may also depend on *how* we install 21:35:35 jistone: I like current way that it just copies current directory.. 21:35:37 if we build an ad hoc registry like debian is doing, that changes how we'll do bins 21:35:51 jistone: meh... 21:36:00 what's the advantage of that method? 21:36:12 apart from that local paths 21:36:13 no worries about optional deps or path deps 21:36:17 they allow for depsolving from cargo 21:36:26 so when dependencies change, it'll throw an error 21:36:31 Pharaoh_Atem: we do it as well 21:36:48 jistone: optional deps are different story 21:36:52 well, when you're updating an existing spec, you're not likely to run rust2rpm 21:37:09 it's more about Req for RPM 21:37:13 the idea is that in that case, cargo can resolve and see that something is missing 21:37:19 or no longer valid 21:37:22 Pharaoh_Atem: and in current case? 21:37:27 cargo install . 21:37:36 ... or how we execute it... 21:37:45 which fails for opt/path deps 21:37:50 well, I think we already sorta generate a local registry, don't we? 21:38:00 on the fly, we declare %_usrsrc/rust and put things in there 21:38:01 jistone: path deps we will make symlinks. 21:38:11 Pharaoh_Atem, initial plan was for /usr/src/ to be the whole registry 21:38:12 and what's about optional deps? 21:38:42 debian's approach is make a registry in the build root which links to those /usr/src/, and also puts the current crate in the registry 21:38:53 then just "cargo install foo" by name 21:39:05 jistone: so it puts all crates in buildroot? 21:39:12 by all I mean ALL 21:39:18 symlinks, but yes I think so 21:39:27 also with that way we can't run cargo test 21:39:36 true 21:39:39 jistone: optional deps are always included in BuildRequires 21:39:48 so they will be in our local registry 21:39:52 /usr/src/rust 21:40:02 are you going to package clippy 21:40:03 ? 21:40:18 there may be a lot of niche optional deps that we don't really need/want to package 21:40:29 more BuildRequires is not a problem 21:40:33 missing BuildRequires is a problem 21:40:37 jistone: why wouldn't we have clippy? 21:40:42 it's nightly only 21:40:54 jistone: for now RPM doesn't have flexibility in this, so we don't have other ways 21:41:03 (for now, that one is special enough that it may become part of the rust distribution) 21:41:15 it seems like it would make sense to merge into rust proper 21:41:18 #link http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/000448.html 21:41:19 ignatenkobrain, it means you filter those out of generated buildreqs too 21:41:25 #link http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/000447.html 21:41:51 jistone: yes, we basically do some magic for nightly stuff 21:41:59 we don't have really other ways for now 21:42:13 see links to rpm-ecosystem@ discussion 21:43:02 even if you solve this on the rpm side, you have to solve cargo too 21:43:10 what exactly? 21:43:28 if you do "cargo install .", I think it will want to *full* resolve deps, even optional that it's not building 21:43:44 vs. "cargo install name" should be more selective 21:43:47 ignatenkobrain: keep in mind once rpm is solved, we're still blocked in Fedora until we get rid of yum in our releng 21:43:49 ... I think 21:43:49 I don't think so 21:43:54 both should be same 21:44:01 if not I'm sure it's bug in cargo 21:44:18 not sure 21:44:29 I know that cargo treats path deps differently in these cases 21:44:33 in Mageia, I'm trying to avoid the yum/urpmi pitfalls for Mageia 7... 21:44:50 jistone: so you are willing to investigate this waters, right? 21:45:27 I'll look into it, but this one is a group effort, I think 21:45:32 * ignatenkobrain thinks that 1 hour was under-estimating 21:45:39 jistone: at least minimal analysis 21:45:45 yes 21:45:56 let's get moving then 21:46:02 #action jistone to investigate differences between cargo dependency-resolving in `cargo install foo` and `cargo install .` (at least minimal analysis) 21:46:08 #topic Packaging binaries (and libraries together) 21:46:12 #link https://pagure.io/fedora-rust/rust2rpm/issue/11 21:46:13 one hour is a reasonable block out of one's schedule 21:46:30 this should be easier 21:46:58 I'm not too familiar with how this is described in Cargo.toml 21:47:03 so I was thinking a bit and I think we want to have Name: foo and subpackage rust-bar-devel 21:47:11 does the metadata have a concept of targets for this to work? 21:47:20 Pharaoh_Atem: yes, it does 21:47:35 there are "bin", "dylib", "staticlib", "bench" 21:47:38 or something similar 21:47:56 I'm not sure how exactly to deal with all those, but at least we should agree on some naming for now 21:47:56 are this fixed names (that is, in a specification), or up to the author? 21:48:05 we shouldn't ship dylib or staticlib (no Rust ABI) 21:48:13 fixed names 21:48:19 cargo has to understand these 21:48:23 jistone: by those two we differentiate bin and lib ;) 21:48:38 jistone: could we not build them and throw them away? 21:48:55 we can build them sure. just don't ship it 21:49:17 * Pharaoh_Atem is thinking of how we would make sure targets are sane when bumping the rust stack 21:49:19 bin -> /usr/bin/foo, lib -> /usr/src/rust/foo-1.2.3 21:49:36 I guess building even if we package only the source would be good yes, so that we know the crate is valid 21:49:59 I think the golang guys do this, especially so that go tests work 21:50:04 I'm actually not sure whether such practice is acceptable by upstream (I mean that one crate provides lib and bin) 21:50:12 it's definitely like this in C world, but... 21:50:21 ignatenkobrain, it definitely happens 21:50:25 it's definitely possible 21:50:33 I think even some servo components work this way 21:50:33 cargo itself is a binary and lib 21:50:35 How does the Cargo.toml look like in such a case? 21:50:42 jistone: so then Name: foo and subpackage rust-bar-devel? 21:50:51 one [lib], can be many [[bin]] 21:51:00 Ok 21:51:09 ignatenkobrain, that's fine 21:51:23 the devel name doesn't matter much if we're using crate(foo) deps, right? 21:51:30 right 21:51:34 jistone: it's useful for searching 21:51:38 it just helps users 21:51:39 so it should match 21:51:41 to some degree 21:51:56 I mean, heck, if they're not getting split up, then they could just be Provides lines 21:52:07 #agreed bin + lib naming scheme is Name: foo and subpackage rust-bar-devel 21:52:08 so rust-foo-devel could provide rust-bar-devel, rust-baz-devel, etc. 21:52:21 #topic Optional dependencies which do not exist 21:52:23 How do we do with bin1 + bin2 + lib? 21:52:26 #link https://pagure.io/fedora-rust/rust2rpm/issue/12 21:52:41 Akien: up to maintainer 21:52:41 Akien, it's fine for the base package to ship multiple bins, I think 21:52:50 Ok 21:52:55 I don't see a reason why not shipping multiple bins in the base package 21:53:05 the optional deps is some follow up from what we discussed earlier 21:53:24 I think this is going to be an ugly situation 21:53:30 since RPM doesn't have way to have such flexibility for now we have to put all optional deps 21:53:35 it's not really a problem 21:53:44 (please drop me a ping at open floor!) 21:53:46 unless it comes to nightly things 21:53:52 jflory7: sure, it's last topic ;) 21:53:57 well, the ideal situation would be to use rich dependencies for this 21:53:59 it's possibly extra/unnecessary packaging work 21:54:00 :) 21:54:16 but we're in a Catch-22 with rich deps 21:54:18 same for dev-deps, actually, if we're running tests 21:54:31 jistone: there's nothing unnecessary, because optional deps are used for features 21:54:44 which means they end up in some circumstances 21:54:53 and I really don't want to filter out features 21:55:02 I think it's ok to say that some features won't work in fedora 21:55:08 *especially* nightly stuff 21:55:23 Yeah but some creates will *require* a dep with its optional feature 21:55:27 *crates 21:55:29 jistone: so my proposal is to have exclude list where we will put all nightly stuff 21:55:47 representing features to rpm is tough. I think debian is using empty subpackages for this to reduce buildreqs 21:56:00 we don't need empty subpackages, though 21:56:04 jistone: I was thinking about this 21:56:04 we can use Provides lines for that 21:56:15 and it means we can't remove them in stable branch 21:56:22 we should put obsoletes and so on 21:56:26 and it's really painful 21:56:31 esp. for depgenerator 21:56:44 Pharaoh_Atem: no, until RPM implements those features 21:56:47 ignatenkobrain: would this be easier to do with rich deps? 21:56:49 Pharaoh_Atem, the point being to only pull in what you need 21:57:08 jistone: we can't do that now (see rpm-ecosystem@ mails) 21:57:25 and I will work with ffesti on this 21:57:36 we could with subpackages, though, right? 21:57:42 not saying that's the right way 21:57:45 just a possibility 21:57:46 jistone: then we can't remove them without obsoletes 21:57:50 ack 21:57:59 so it will be very painful 21:58:15 now we generate this automatically 21:58:28 with subpackages we will completely stop using dependency generator and start doing manually 21:58:34 IMO this is very wrong approach 21:58:49 so we need rich provides, don't we? 21:58:58 Pharaoh_Atem: man, this doesn't work as for now 21:59:02 read rpm-ecosystem@ 21:59:04 links are above 21:59:05 I'm reading it 21:59:11 I'm trying to understand what is actually missing 21:59:19 But it doesn't work since it works the RPM thinks that crate(clap)(xxx) is going to be installed (since it's provided by same package) so it requires other packages to be installed as well which is something not what we want. 21:59:32 ah I see 21:59:56 Pharaoh_Atem: I discussed with Florian about this and we need to implement autobuildrequires first 22:00:03 ah 22:00:08 then RPM will propagate builddeps 22:00:16 (ignatenkobrain, btw don't expect much deep reading *during* a meeting. send links ahead of time if you want folks to be caught up) 22:00:26 which will lead to correct solving for Provides/Requires, right? 22:00:31 yes 22:00:44 jistone: do you have advise how to detect nightly stuff? 22:00:48 so then prebuildreqs -> buildreqs -> rich provides + rich requires 22:00:49 which is likely to be missing 22:01:01 Pharaoh_Atem: something like this 22:01:02 there's nothing that indicates a crate requires nightly 22:01:17 nor even a minimum rustc version, though that's a hot request 22:01:26 jistone: I think usually people just putting [features] nightly = [] 22:01:26 (several rfcs along those lines) 22:01:28 there's no such thing as minimum rustc? 22:01:34 Regarding those optional features, we'll always package the source for each crate, so in the end it's mostly a matter of finding the proper auto BuildReqs that will allow to build the necessary crate dependencies with their *required* optional features, right? 22:01:42 jistone: probably we should open request to upstream about this 22:01:54 Akien: the main issue is when we *can't* satisfy it 22:01:56