21:00:01 <ignatenkobrain> #startmeeting Rust SIG (2017-02-01)
21:00:01 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:01 <zodbot> The meeting name has been set to 'rust_sig_(2017-02-01)'
21:00:04 <ignatenkobrain> #meetingname rust-sig
21:00:04 <zodbot> The meeting name has been set to 'rust-sig'
21:00:08 <ignatenkobrain> #chair ignatenkobrain jistone
21:00:08 <zodbot> Current chairs: ignatenkobrain jistone
21:00:11 <ignatenkobrain> #topic Agenda
21:00:14 <ignatenkobrain> #info (1) Roll Call
21:00:18 <ignatenkobrain> #info (2) Current State of Packaging
21:00:22 <ignatenkobrain> #info (3) Wildcard Versions
21:00:25 <ignatenkobrain> #info (4) Normalize versions for RPM
21:00:29 <ignatenkobrain> #info (5) Boilerplate in %install
21:00:32 <ignatenkobrain> #info (6) Packaging binaries (and libraries together)
21:00:35 <ignatenkobrain> #info (7) Optional dependencies which do not exist
21:00:38 <ignatenkobrain> #info (8) Open Floor
21:00:41 <ignatenkobrain> #topic Roll Call
21:00:45 <ignatenkobrain> .hello ignatenkobrain
21:00:46 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
21:00:55 <lupinix> .hello lupinix
21:00:56 <zodbot> lupinix: lupinix 'Christian Dersch' <lupinix@mailbox.org>
21:00:59 <jistone> .hello jistone
21:01:00 <zodbot> jistone: jistone 'Josh Stone' <jistone@redhat.com>
21:01:01 <Pharaoh_Atem> .hello ngompa
21:01:05 <zodbot> Pharaoh_Atem: ngompa 'None' <ngompa13@gmail.com>
21:01:11 <Pharaoh_Atem> phooey
21:01:12 <ignatenkobrain> Pharaoh_Atem: fill your name :D
21:01:20 <Pharaoh_Atem> FAS knows who I am, damn it
21:01:24 <Pharaoh_Atem> anyway, Neal Gompa :)
21:01:34 <ignatenkobrain> someone else?
21:01:52 <Pharaoh_Atem> bah, I'm me (Neal Gompa)
21:02:00 <ignatenkobrain> okay, so let's move on
21:02:01 <Pharaoh_Atem> if I'm not me, then... I don't know who I am...?
21:02:04 <Pharaoh_Atem> anyway
21:02:04 <ignatenkobrain> #topic Current State of Packaging
21:02:09 <ignatenkobrain> #info We have RPM macro for build/install procedures, dependency generator and even generator of spec files!
21:02:12 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm
21:02:44 <jistone> nothing actually packaged with this yet, right?
21:02:46 <ignatenkobrain> Also, /me did initial work on crates.io for release-monitoring.org and jcline fixed it a lot ;)
21:02:53 <ignatenkobrain> jistone: no, just playing around still
21:03:06 <ignatenkobrain> finishing macro / tools / etc.
21:03:11 <jistone> ok, and that's fine, what I expected
21:03:17 <jflory7> .hello jflory7
21:03:18 <zodbot> jflory7: jflory7 'Justin W. Flory' <jflory7@gmail.com>
21:03:42 <ignatenkobrain> 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 <ignatenkobrain> any questions on current state?
21:04:13 <Pharaoh_Atem> do we have any particular targets to package initially?
21:04:16 <Akien> .hello akien
21:04:17 <zodbot> Akien: akien 'Rémi Verschelde' <rverschelde@gmail.com>
21:04:24 <ignatenkobrain> Pharaoh_Atem: good question
21:04:29 <jistone> ripgrep is a juicy target
21:04:30 <msehnout> .hello msehnout
21:04:31 <zodbot> msehnout: msehnout 'Martin Sehnoutka' <msehnout@redhat.com>
21:04:34 <Akien> ripgrep \o/
21:04:46 <Pharaoh_Atem> mou... even Akien's name shows up on hello
21:04:49 <ignatenkobrain> jistone: how many deps does it have?
21:04:59 <jistone> maybe cargo itself, but that's special
21:05:34 <jistone> ripgrep is around 30 afaics
21:05:46 <jistone> (some might be optional, that's just from a quick cargo-tree)
21:06:02 <ignatenkobrain> https://crates.io/crates/ripgrep
21:06:04 <ignatenkobrain> this one, right?
21:06:11 <Pharaoh_Atem> yep
21:06:11 <jistone> yes
21:06:18 <ignatenkobrain> makes sense!
21:06:35 <Akien> (I've been using it locally for a few months, I love it :D)
21:06:54 <jistone> there's a package review already, but they didn't attempt offline builds
21:08:04 <ignatenkobrain> #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 <Akien> For the reference, list of applications made with rust: https://github.com/kud1ing/awesome-rust#applications-written-in-rust
21:08:29 <Akien> (I think trying to package a few applications is funnier than just packaging lib crates without end product in mind :p)
21:08:46 <ignatenkobrain> yeah, long target could be servo ;)
21:08:56 <jistone> generally, I wouldn't bother with any crate until it's needed for a leaf app
21:09:10 <Akien> I agree. Packaging the whole of crates.io would be impossible
21:09:20 <Pharaoh_Atem> I dunno if I want to package all of crates.io...
21:09:48 <jistone> I know I don't want to :P
21:09:50 <Pharaoh_Atem> 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 <ignatenkobrain> jistone: for me first step was to package libs because without that we can't proceed
21:09:59 <jistone> yep
21:10:07 <ignatenkobrain> and putting Requires/Provides/Conflicts all the way is bad idea
21:10:21 <jistone> unless you find a lucky app built only with libstd
21:10:34 * ignatenkobrain doesn't expect to find such
21:10:39 <Pharaoh_Atem> jistone: that's going to be rare
21:10:46 <Pharaoh_Atem> there's no compelling reason to do that
21:11:03 <jistone> I know, see my toungue in my cheek over here
21:11:20 <jistone> *tongue
21:11:41 <jistone> anyway
21:11:43 <Akien> 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 <jistone> good question
21:12:18 <Pharaoh_Atem> well, ideally, we should be systematically updating them as anitya tells us about them
21:12:21 <jistone> *if* we split up cargo to use these, then I expect that to be the biggest driver of updates
21:12:33 <Akien> 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 <Akien> (I mean analyse all the rust stack we package)
21:12:51 <Pharaoh_Atem> I think that's going to be necessary
21:13:00 <jistone> Pharaoh_Atem, if we blindly do that, we'll certainly cause ftbfs
21:13:02 <ignatenkobrain> I think we want to keep stuff updated as much as possible
21:13:14 <Pharaoh_Atem> jistone: note "ideally"
21:13:28 <jistone> a similar question is whether we want to ever package multiple versions of a crate
21:13:28 <ignatenkobrain> jistone: well, definitely we're not going to do this blindly
21:13:29 <Akien> 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 <ignatenkobrain> jistone: this is also good question
21:13:50 <Pharaoh_Atem> unfortunately, I think we're going to have to
21:14:03 <ignatenkobrain> jistone: it depends... if upstream supports "LTS" versions and other stuff depends on this..
21:14:04 <jistone> yeah
21:14:13 <Pharaoh_Atem> multiversioning is already something that the php, golang, ruby, and nodejs packagers in Fedora deal with
21:14:18 <ignatenkobrain> but unless we really need this, I would prefer to not
21:14:22 <Akien> I think the rust ecosystem is not so LTS minded so far
21:14:27 <jistone> LTS on a project less than two years old yet, ha!
21:15:22 <Pharaoh_Atem> 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 <ignatenkobrain> we should really just go ahead and file issues to upstream (and fix if possible)
21:16:01 <Akien> 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 <Pharaoh_Atem> this is not unique to us, of course: https://bugzilla.redhat.com/show_bug.cgi?id=1389871
21:16:17 <Akien> That should answer some of our questions, and bring many new ones :)
21:16:28 <Pharaoh_Atem> yes
21:17:29 <Pharaoh_Atem> 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 <ignatenkobrain> okay, so we have initial target.
21:18:10 <ignatenkobrain> #topic Normalize version for RPM
21:18:16 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/issue/3
21:18:39 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/issue/3
21:18:53 <Pharaoh_Atem> does "link" even work?
21:18:54 <jistone> if the semantics of 0.9.3~rc3 are the same, your plan sounds fine
21:19:02 <ignatenkobrain> Pharaoh_Atem: it does
21:19:28 <ignatenkobrain> jistone: I'm not sure about very complicated ones
21:19:35 <ignatenkobrain> like .rc8+post1
21:19:44 <jistone> I think this is rare in crates anyway
21:19:52 <ignatenkobrain> yes
21:19:57 <ignatenkobrain> so I need volunteer ;)
21:20:01 <Pharaoh_Atem> jistone: the semantics of versioning are described here: https://fedoraproject.org/wiki/PackagingDrafts/TildeVersioning#Basic_versioning_rules
21:20:02 <ignatenkobrain> it should be very easy task
21:20:19 <jistone> I only *just* found out that such deps broke old cargo, which indicates that no one was really doing this
21:20:31 <ignatenkobrain> hehe
21:20:51 <ignatenkobrain> where all those brave volunteers? ;)
21:21:02 <Pharaoh_Atem> what do you want us to be brave about? :)
21:21:04 <jistone> oh fine, I'll take this one
21:21:06 <jistone> :P
21:21:26 <ignatenkobrain> #action jistone to implement normalizing pre-release versions for RPM
21:21:36 <ignatenkobrain> #topic Wildcard Versions
21:21:41 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/issue/6
21:21:48 <Pharaoh_Atem> wildcard versions should be relatively easy to handle
21:21:54 <Pharaoh_Atem> especially since * is now forbidden
21:22:18 <ignatenkobrain> As Josh pinted out, it seems it's possible to normalize it to tilde version
21:23:11 <Pharaoh_Atem> does that even resolve in rpm?
21:23:15 <ignatenkobrain> the library which we are using doesn't support wildcards
21:23:17 <Pharaoh_Atem> I thought ~ only works as a suffix
21:23:21 <Pharaoh_Atem> not as a prefix
21:23:37 <ignatenkobrain> Pharaoh_Atem: I mean to tilde version in terms of semver
21:23:39 <Pharaoh_Atem> ah
21:23:43 <ignatenkobrain> then we do our magic
21:23:48 <Pharaoh_Atem> yes, in terms of semver, it works
21:23:48 <ignatenkobrain> for Req/Con
21:24:22 <ignatenkobrain> #link https://github.com/rbarrois/python-semanticversion/issues/51
21:24:44 <ignatenkobrain> 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 <Pharaoh_Atem> really, though, * means we don't specify a version
21:24:56 <Pharaoh_Atem> that's easy enough to do
21:25:20 <jistone> true
21:25:38 <Pharaoh_Atem> rpm naturally handles versionless deps anyway
21:25:42 <Pharaoh_Atem> so we're fine in that regard
21:25:48 <ignatenkobrain> Pharaoh_Atem: hmm
21:25:56 <ignatenkobrain> but you forgot essential part
21:26:04 <Pharaoh_Atem> oh?
21:26:14 <ignatenkobrain> 1.2.* -> Req: >=1.2.0 + Con: >=1.3.0
21:26:21 <Pharaoh_Atem> yeah, that needs to work
21:26:27 <Pharaoh_Atem> I was referring to "*" as a dep req
21:26:33 <Pharaoh_Atem> not x.y.*
21:26:42 <ignatenkobrain> ah, this is deprecated and very trivial to implement ;)
21:26:53 <ignatenkobrain> volunteers?
21:27:00 * ignatenkobrain can do this as well
21:27:03 <ignatenkobrain> if no one else wants
21:27:44 <ignatenkobrain> #action ignatenkobrain to implement support for wildcard versions
21:27:46 <ignatenkobrain> #topic Boilerplate in %install
21:27:50 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/issue/7
21:28:07 <ignatenkobrain> this is more interesting thing ;)
21:28:25 <ignatenkobrain> basically I would prefer to stop doing %cargo_install_crate %{crate}-%{version}
21:28:32 <jistone> that could just assume %{crate}-%{version}
21:28:48 <Pharaoh_Atem> unless you pass -n switch or something
21:28:56 <Akien> %cargo_install sounds great :)
21:29:14 <ignatenkobrain> because it's 1) duplicate of name-version info 2) duplicate of lib/bin info which metadata has
21:29:16 <jistone> the only reason to have that in my prototype was in case something had multiple crates to install
21:29:31 <ignatenkobrain> jistone: are they all coming from same Cargo.toml?
21:29:34 <ignatenkobrain> or how does this work?
21:29:36 <ignatenkobrain> some example?
21:29:42 <jistone> hypothetical
21:29:48 <jistone> you wouldn't get this from crates.io
21:30:05 <jistone> if you perhaps had some other source tarball with multiple crates to provide
21:30:14 <jistone> iow, we probably don't need this flexibility
21:30:18 <Pharaoh_Atem> 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 <ignatenkobrain> then we should be fine
21:30:21 <Pharaoh_Atem> *should
21:30:32 <jistone> %cargo_install for binaries
21:30:38 <jistone> %cargo_install_crate for source lib
21:30:39 <ignatenkobrain> Pharaoh_Atem: why should I care as maintainer what it shouljd do under the hood?
21:31:09 <ignatenkobrain> jistone: that seems a bit awkward
21:31:12 <Pharaoh_Atem> I'm thinking mainly of people building packages from private crate repos, which may be more flexible than crates.io
21:31:13 <Akien> ignatenkobrain: Well you should care in case what it does under the hood is not what you need :D
21:31:19 <Pharaoh_Atem> or bundling more crates in one package
21:31:44 <ignatenkobrain> Pharaoh_Atem: then you change directory and do %cargo_install, no?
21:31:52 <Pharaoh_Atem> fair point
21:32:02 <Pharaoh_Atem> as long as the Cargo.toml is well-formed, that should work
21:32:08 <ignatenkobrain> we rely on current directory as on something what we should copy
21:32:15 <jistone> ignatenkobrain, %{crate}-%{version} doesn't care about directory
21:32:27 <jistone> oh, you mean not to even use the rpm vars
21:32:33 <ignatenkobrain> jistone: yes
21:32:36 <ignatenkobrain> just %cargo_install
21:32:45 <ignatenkobrain> it will do cp for lib and cargo install for bin
21:32:50 <jistone> right, but I thought that might use the vars inside
21:32:54 <ignatenkobrain> as we do now, but it will choose automagically
21:33:33 <jistone> should there be a sanity check that rpm's %{crate}-%{version} matches Cargo.toml?
21:33:51 <ignatenkobrain> jistone: one problem is that we don't really define crate....
21:34:00 <ignatenkobrain> it's up to maintainer to define it that way
21:34:14 <ignatenkobrain> and as Pharaoh_Atem mentioned, if you package multiple crates in one RPM..
21:34:19 <ignatenkobrain> that will just be broken
21:34:28 <ignatenkobrain> unless you play tricks with redefining crate
21:35:18 <jistone> it may also depend on *how* we install
21:35:35 <ignatenkobrain> jistone: I like current way that it just copies current directory..
21:35:37 <jistone> if we build an ad hoc registry like debian is doing, that changes how we'll do bins
21:35:51 <ignatenkobrain> jistone: meh...
21:36:00 <ignatenkobrain> what's the advantage of that method?
21:36:12 <ignatenkobrain> apart from that local paths
21:36:13 <jistone> no worries about optional deps or path deps
21:36:17 <Pharaoh_Atem> they allow for depsolving from cargo
21:36:26 <Pharaoh_Atem> so when dependencies change, it'll throw an error
21:36:31 <ignatenkobrain> Pharaoh_Atem: we do it as well
21:36:48 <ignatenkobrain> jistone: optional deps are different story
21:36:52 <Pharaoh_Atem> well, when you're updating an existing spec, you're not likely to run rust2rpm
21:37:09 <ignatenkobrain> it's more about Req for RPM
21:37:13 <Pharaoh_Atem> the idea is that in that case, cargo can resolve and see that something is missing
21:37:19 <Pharaoh_Atem> or no longer valid
21:37:22 <ignatenkobrain> Pharaoh_Atem: and in current case?
21:37:27 <ignatenkobrain> cargo install .
21:37:36 <ignatenkobrain> ... or how we execute it...
21:37:45 <jistone> which fails for opt/path deps
21:37:50 <Pharaoh_Atem> well, I think we already sorta generate a local registry, don't we?
21:38:00 <Pharaoh_Atem> on the fly, we declare %_usrsrc/rust and put things in there
21:38:01 <ignatenkobrain> jistone: path deps we will make symlinks.
21:38:11 <jistone> Pharaoh_Atem, initial plan was for /usr/src/ to be the whole registry
21:38:12 <ignatenkobrain> and what's about optional deps?
21:38:42 <jistone> 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 <jistone> then just "cargo install foo" by name
21:39:05 <ignatenkobrain> jistone: so it puts all crates in buildroot?
21:39:12 <ignatenkobrain> by all I mean ALL
21:39:18 <jistone> symlinks, but yes I think so
21:39:27 <ignatenkobrain> also with that way we can't run cargo test
21:39:36 <jistone> true
21:39:39 <ignatenkobrain> jistone: optional deps are always included in BuildRequires
21:39:48 <ignatenkobrain> so they will be in our local registry
21:39:52 <ignatenkobrain> /usr/src/rust
21:40:02 <jistone> are you going to package clippy
21:40:03 <jistone> ?
21:40:18 <jistone> there may be a lot of niche optional deps that we don't really need/want to package
21:40:29 <ignatenkobrain> more BuildRequires is not a problem
21:40:33 <ignatenkobrain> missing BuildRequires is a problem
21:40:37 <Pharaoh_Atem> jistone: why wouldn't we have clippy?
21:40:42 <jistone> it's nightly only
21:40:54 <ignatenkobrain> jistone: for now RPM doesn't have flexibility in this, so we don't have other ways
21:41:03 <jistone> (for now, that one is special enough that it may become part of the rust distribution)
21:41:15 <Pharaoh_Atem> it seems like it would make sense to merge into rust proper
21:41:18 <ignatenkobrain> #link http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/000448.html
21:41:19 <jistone> ignatenkobrain, it means you filter those out of generated buildreqs too
21:41:25 <ignatenkobrain> #link http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/000447.html
21:41:51 <ignatenkobrain> jistone: yes, we basically do some magic for nightly stuff
21:41:59 <ignatenkobrain> we don't have really other ways for now
21:42:13 <ignatenkobrain> see links to rpm-ecosystem@ discussion
21:43:02 <jistone> even if you solve this on the rpm side, you have to solve cargo too
21:43:10 <ignatenkobrain> what exactly?
21:43:28 <jistone> if you do "cargo install .", I think it will want to *full* resolve deps, even optional that it's not building
21:43:44 <jistone> vs. "cargo install name" should be more selective
21:43:47 <Pharaoh_Atem> 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 <jistone> ... I think
21:43:49 <ignatenkobrain> I don't think so
21:43:54 <ignatenkobrain> both should be same
21:44:01 <ignatenkobrain> if not I'm sure it's bug in cargo
21:44:18 <jistone> not sure
21:44:29 <jistone> I know that cargo treats path deps differently in these cases
21:44:33 <Pharaoh_Atem> in Mageia, I'm trying to avoid the yum/urpmi pitfalls for Mageia 7...
21:44:50 <ignatenkobrain> jistone: so you are willing to investigate this waters, right?
21:45:27 <jistone> 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 <ignatenkobrain> jistone: at least minimal analysis
21:45:45 <jistone> yes
21:45:56 <jistone> let's get moving then
21:46:02 <ignatenkobrain> #action jistone to investigate differences between cargo dependency-resolving in `cargo install foo` and `cargo install .` (at least minimal analysis)
21:46:08 <ignatenkobrain> #topic Packaging binaries (and libraries together)
21:46:12 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/issue/11
21:46:13 <jistone> one hour is a reasonable block out of one's schedule
21:46:30 <ignatenkobrain> this should be easier
21:46:58 <Pharaoh_Atem> I'm not too familiar with how this is described in Cargo.toml
21:47:03 <ignatenkobrain> so I was thinking a bit and I think we want to have Name: foo and subpackage rust-bar-devel
21:47:11 <Pharaoh_Atem> does the metadata have a concept of targets for this to work?
21:47:20 <ignatenkobrain> Pharaoh_Atem: yes, it does
21:47:35 <ignatenkobrain> there are "bin", "dylib", "staticlib", "bench"
21:47:38 <ignatenkobrain> or something similar
21:47:56 <ignatenkobrain> 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 <Pharaoh_Atem> are this fixed names (that is, in a specification), or up to the author?
21:48:05 <jistone> we shouldn't ship dylib or staticlib  (no Rust ABI)
21:48:13 <jistone> fixed names
21:48:19 <jistone> cargo has to understand these
21:48:23 <ignatenkobrain> jistone: by those two we differentiate bin and lib ;)
21:48:38 <Pharaoh_Atem> jistone: could we not build them and throw them away?
21:48:55 <jistone> 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 <jistone> bin -> /usr/bin/foo, lib -> /usr/src/rust/foo-1.2.3
21:49:36 <Akien> 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 <Pharaoh_Atem> I think the golang guys do this, especially so that go tests work
21:50:04 <ignatenkobrain> I'm actually not sure whether such practice is acceptable by upstream (I mean that one crate provides lib and bin)
21:50:12 <ignatenkobrain> it's definitely like this in C world, but...
21:50:21 <jistone> ignatenkobrain, it definitely happens
21:50:25 <Pharaoh_Atem> it's definitely possible
21:50:33 <Pharaoh_Atem> I think even some servo components work this way
21:50:33 <jistone> cargo itself is a binary and lib
21:50:35 <Akien> How does the Cargo.toml look like in such a case?
21:50:42 <ignatenkobrain> jistone: so then Name: foo and subpackage rust-bar-devel?
21:50:51 <jistone> one [lib], can be many [[bin]]
21:51:00 <Akien> Ok
21:51:09 <jistone> ignatenkobrain, that's fine
21:51:23 <jistone> the devel name doesn't matter much if we're using crate(foo) deps, right?
21:51:30 <Pharaoh_Atem> right
21:51:34 <ignatenkobrain> jistone: it's useful for searching
21:51:38 <jistone> it just helps users
21:51:39 <ignatenkobrain> so it should match
21:51:41 <ignatenkobrain> to some degree
21:51:56 <Pharaoh_Atem> I mean, heck, if they're not getting split up, then they could just be Provides lines
21:52:07 <ignatenkobrain> #agreed bin + lib naming scheme is Name: foo and subpackage rust-bar-devel
21:52:08 <Pharaoh_Atem> so rust-foo-devel could provide rust-bar-devel, rust-baz-devel, etc.
21:52:21 <ignatenkobrain> #topic Optional dependencies which do not exist
21:52:23 <Akien> How do we do with bin1 + bin2 + lib?
21:52:26 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/issue/12
21:52:41 <ignatenkobrain> Akien: up to maintainer
21:52:41 <jistone> Akien, it's fine for the base package to ship multiple bins, I think
21:52:50 <Akien> Ok
21:52:55 <Pharaoh_Atem> I don't see a reason why not shipping multiple bins in the base package
21:53:05 <ignatenkobrain> the optional deps is some follow up from what we discussed earlier
21:53:24 <Pharaoh_Atem> I think this is going to be an ugly situation
21:53:30 <ignatenkobrain> since RPM doesn't have way to have such flexibility for now we have to put all optional deps
21:53:35 <ignatenkobrain> it's not really a problem
21:53:44 <jflory7> (please drop me a ping at open floor!)
21:53:46 <ignatenkobrain> unless it comes to nightly things
21:53:52 <ignatenkobrain> jflory7: sure, it's last topic ;)
21:53:57 <Pharaoh_Atem> well, the ideal situation would be to use rich dependencies for this
21:53:59 <jistone> it's possibly extra/unnecessary packaging work
21:54:00 <jflory7> :)
21:54:16 <Pharaoh_Atem> but we're in a Catch-22 with rich deps
21:54:18 <jistone> same for dev-deps, actually, if we're running tests
21:54:31 <ignatenkobrain> jistone: there's nothing unnecessary, because optional deps are used for features
21:54:44 <ignatenkobrain> which means they end up in some circumstances
21:54:53 <ignatenkobrain> and I really don't want to filter out features
21:55:02 <jistone> I think it's ok to say that some features won't work in fedora
21:55:08 <jistone> *especially* nightly stuff
21:55:23 <Akien> Yeah but some creates will *require* a dep with its optional feature
21:55:27 <Akien> *crates
21:55:29 <ignatenkobrain> jistone: so my proposal is to have exclude list where we will put all nightly stuff
21:55:47 <jistone> representing features to rpm is tough.  I think debian is using empty subpackages for this to reduce buildreqs
21:56:00 <Pharaoh_Atem> we don't need empty subpackages, though
21:56:04 <ignatenkobrain> jistone: I was thinking about this
21:56:04 <Pharaoh_Atem> we can use Provides lines for that
21:56:15 <ignatenkobrain> and it means we can't remove them in stable branch
21:56:22 <ignatenkobrain> we should put obsoletes and so on
21:56:26 <ignatenkobrain> and it's really painful
21:56:31 <ignatenkobrain> esp. for depgenerator
21:56:44 <ignatenkobrain> Pharaoh_Atem: no, until RPM implements those features
21:56:47 <Pharaoh_Atem> ignatenkobrain: would this be easier to do with rich deps?
21:56:49 <jistone> Pharaoh_Atem, the point being to only pull in what you need
21:57:08 <ignatenkobrain> jistone: we can't do that now (see rpm-ecosystem@ mails)
21:57:25 <ignatenkobrain> and I will work with ffesti on this
21:57:36 <jistone> we could with subpackages, though, right?
21:57:42 <jistone> not saying that's the right way
21:57:45 <jistone> just a possibility
21:57:46 <ignatenkobrain> jistone: then we can't remove them without obsoletes
21:57:50 <jistone> ack
21:57:59 <ignatenkobrain> so it will be very painful
21:58:15 <ignatenkobrain> now we generate this automatically
21:58:28 <ignatenkobrain> with subpackages we will completely stop using dependency generator and start doing manually
21:58:34 <ignatenkobrain> IMO this is very wrong approach
21:58:49 <Pharaoh_Atem> so we need rich provides, don't we?
21:58:58 <ignatenkobrain> Pharaoh_Atem: man, this doesn't work as for now
21:59:02 <ignatenkobrain> read rpm-ecosystem@
21:59:04 <ignatenkobrain> links are above
21:59:05 <Pharaoh_Atem> I'm reading it
21:59:11 <Pharaoh_Atem> I'm trying to understand what is actually missing
21:59:19 <ignatenkobrain> 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 <Pharaoh_Atem> ah I see
21:59:56 <ignatenkobrain> Pharaoh_Atem: I discussed with Florian about this and we need to implement autobuildrequires first
22:00:03 <Pharaoh_Atem> ah
22:00:08 <ignatenkobrain> then RPM will propagate builddeps
22:00:16 <jistone> (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 <Pharaoh_Atem> which will lead to correct solving for Provides/Requires, right?
22:00:31 <ignatenkobrain> yes
22:00:44 <ignatenkobrain> jistone: do you have advise how to detect nightly stuff?
22:00:48 <Pharaoh_Atem> so then prebuildreqs -> buildreqs -> rich provides + rich requires
22:00:49 <ignatenkobrain> which is likely to be missing
22:01:01 <ignatenkobrain> Pharaoh_Atem: something like this
22:01:02 <jistone> there's nothing that indicates a crate requires nightly
22:01:17 <jistone> nor even a minimum rustc version, though that's a hot request
22:01:26 <ignatenkobrain> jistone: I think usually people just putting [features] nightly = []
22:01:26 <jistone> (several rfcs along those lines)
22:01:28 <Pharaoh_Atem> there's no such thing as minimum rustc?
22:01:34 <Akien> 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 <ignatenkobrain> jistone: probably we should open request to upstream about this
22:01:54 <Pharaoh_Atem> Akien: the main issue is when we *can't* satisfy it
22:01:56 <jistone> Pharaoh_Atem, nothing in Cargo.toml indicates rustc/libstd requirements
22:02:03 <Pharaoh_Atem> that's... annoying
22:02:08 <jistone> yes
22:02:20 <ignatenkobrain> to distinguish between some optional deps and nightly
22:03:01 <Pharaoh_Atem> Akien: we want provides to disable themselves when they can't be satisfied
22:03:08 <Pharaoh_Atem> likewise for requires
22:03:13 <Akien> Pharaoh_Atem: But for a crate A that requires such an optional dep of crate foo, which is e.g. enabled by crate bar, we'd have to get A buildrequire foo + bar basically
22:03:35 * lupinix has to read the logs… to deeply involved in other meeting
22:03:39 <Akien> Which might be doable by parsing the manifest, no?
22:03:49 <ignatenkobrain> Akien: no, we put all optional deps as Requires for crate
22:03:57 <ignatenkobrain> even optional (which needed for features)
22:04:59 <ignatenkobrain> let's solve it on-demand since we can't find any solutions for now..
22:05:12 <jistone> what does that entail?
22:05:13 <ignatenkobrain> on-demand == once we get such problem ;)
22:05:48 <ignatenkobrain> once we start packaging some crate and encounter that it requires some nightly stuff, we record it and adding to blacklist
22:05:51 <Akien> Wouldn't this work? https://hastebin.com/xusarufiyi.erl
22:05:52 <ignatenkobrain> e.g. clippy
22:06:08 <Akien> Since we package only sources, it's just a matter of getting the right crate sources in the buildsystem.
22:06:17 <Akien> And Cargo.toml should tell us everything
22:06:23 <ignatenkobrain> Akien: we don't have autobuildrequires
22:06:31 <jistone> I mean, we *could* package clippy sources - they'd just be useless to us
22:06:51 <Akien> ignatenkobrain: Then the packager should BR the right optional crate :D
22:06:56 <jistone> (ditto any other nightly package)
22:07:29 <ignatenkobrain> Akien: which means always checking all dependencies & putting it manually all the time, not gonna work
22:07:41 <ignatenkobrain> all dependencies includes underlying libraries
22:07:47 <ignatenkobrain> jistone: hmm
22:08:07 <ignatenkobrain> jistone: then why don't we package it and ignore it? ;)
22:08:18 <jistone> same for stuff like winapi, which we'll hit all over the place
22:08:29 <ignatenkobrain> jistone: winapi is managed by target
22:08:37 <jistone> not always
22:08:37 <ignatenkobrain> which is something I wanted to discuss (but not today)
22:08:49 <jistone> some people put unconditional dep, then cfg it in actual sources
22:08:55 <Pharaoh_Atem> uggh
22:09:00 <ignatenkobrain> jistone: then we create patch ;)
22:09:01 <Pharaoh_Atem> but Cargo supports target specific deps
22:09:07 <jistone> it didn't always
22:09:16 <Pharaoh_Atem> oh, well, then
22:10:30 <ignatenkobrain> jistone: cargo doesn't inspect sources
22:10:35 <ignatenkobrain> so it would pull dep
22:10:43 <ignatenkobrain> yes, it exists, but it's wrong anyway
22:10:44 <jistone> right
22:10:48 <ignatenkobrain> so I would rather fix it properly
22:11:09 <ignatenkobrain> by proper pull-request to upstream + temporary sed in our package
22:11:11 <Pharaoh_Atem> well, there's fedora's value-add (fixing the world's Cargo.toml)
22:11:20 <Pharaoh_Atem> :{
22:11:24 <ignatenkobrain> Pharaoh_Atem: yeah, we fix a lot of upstream issues ;)
22:11:26 <jistone> some crates won't accept that, if they still want support for those old cargos
22:11:43 <jistone> for upstream PRs, I mean
22:11:52 <ignatenkobrain> jistone: should I count size of fedora patches for xmlrpc-c? ;)
22:12:11 <ignatenkobrain> and basically we do out-of-tree patches for almost each package
22:12:14 <ignatenkobrain> it's nothing new
22:12:22 <ignatenkobrain> we should write documentation about this tho
22:12:24 <jistone> it may be easier just to package a useless winapi crate too
22:12:48 <ignatenkobrain> like "if you encounter that something depends unconditionally on win*, do: ...."
22:13:02 <Pharaoh_Atem> jistone: well, would having the winapi crate help with cross compiling rust code?
22:13:05 <ignatenkobrain> jistone: does cargo/rust supports cross-compilation?
22:13:15 <jistone> yes and yes
22:13:24 <Pharaoh_Atem> so there's a perfectly valid use-case for having the crate, then
22:13:34 <jistone> assuming we also had cross-std and linker, of course
22:14:15 <jistone> not sure people really need to use distro crates for this though, vs. just pulling from crates.io
22:14:17 <jistone> but whatever
22:14:20 <ignatenkobrain> so then let's just package winapi and so on
22:14:36 <ignatenkobrain> agreed?
22:14:44 <jistone> ok
22:15:02 <Pharaoh_Atem> I'm okay with this
22:15:13 <Pharaoh_Atem> jistone: we offer distro packages for mingw* packages too
22:15:13 <ignatenkobrain> #agreed we will package even winapi stuff (since it would probably make sense for cross-compilation and will not give any problems)
22:15:33 <ignatenkobrain> #topic Open Floor
22:15:35 <ignatenkobrain> so, finally
22:15:38 <ignatenkobrain> jflory7: ^^
22:15:41 <Pharaoh_Atem> jflory7: we're back to the open floor :)
22:15:46 <jistone> Pharaoh_Atem, yeah, but C doesn't have a nice online package manager for its libraries :P
22:15:59 <Pharaoh_Atem> jistone: yes, but think about mixing C and Rust
22:16:05 <jistone> FYI, release day tomorrow
22:16:13 <Pharaoh_Atem> sweet, new rust?
22:16:13 * jflory7 waves
22:16:43 <jistone> yeah, Rust 1.15 / Cargo 0.16
22:16:48 <ignatenkobrain> so, since I think none of us have time / skills for advertising...
22:17:10 <ignatenkobrain> #info Rust 1.15 / Cargo 0.16 releases tomorrow
22:17:15 <Pharaoh_Atem> :D
22:17:27 <ignatenkobrain> jflory7: I was thinking how would you help us...
22:17:32 <jflory7> Yeah! So I had some ideas for how we could better promote the presence of this SIG, since Rust is pretty new in Fedora and some people might be interested to know more about Rust. I had some ideas to share...
22:17:43 <ignatenkobrain> go ahead!
22:18:32 <jflory7> For one, I might suggest someone writing an introductory Community Blog post about the SIG, what kind of goals you all have and hope to accomplish, and also point out to others how to get involved. Additionally, given the recent news of a Rust release, a Fedora Magazine article would be a great way to promote Rust on Fedora too...
22:18:54 <jflory7> Additionally, are there any kind of onboarding steps in place already? So if someone comes along and wants to participate, will they be able to figure out how to get involved?
22:18:55 <ignatenkobrain> jflory7: probably we can bundle those two
22:19:09 <jistone> note that Rust releases every 6 weeks, not something we'll parade every time :)
22:19:17 <ignatenkobrain> jflory7: I'm not good for writing texts...
22:19:25 <Pharaoh_Atem> I could probably whip something up
22:19:27 <ignatenkobrain> basically it's just about joining IRC and mailing list
22:19:50 <Pharaoh_Atem> as it is, I'm preparing a presentation to talk about Rust and Fedora Rust SIG at my local LUG that's in an hour :)
22:20:10 <ignatenkobrain> Pharaoh_Atem: will there be recording?
22:20:12 <jflory7> I definitely think that might be two types of tasks to work on for getting ready to promote the SIG. Obviously, some kind of onboarding steps coming first before promoting the presence of the SIG. :) So then we can easily point people to steps for how to get involved.
22:20:22 <Pharaoh_Atem> ignatenkobrain: sadly no, but the presentation slides will be available online
22:20:32 <Pharaoh_Atem> we have no resources for recordings :(
22:21:00 <ignatenkobrain> #action Pharaoh_Atem to provide presentation slides from his local LUG afterwards
22:21:02 <jflory7> I know for both the Community Blog and the Magazine, we'd love to hear more about the cool things happening with Rust in Fedora, and I imagine a lot of readers would too. :)
22:21:04 <ignatenkobrain> :-P
22:21:14 <Pharaoh_Atem> jflory7: and our Rust SIG has a little cross-distro action, too :)
22:21:15 <ignatenkobrain> jflory7: hm
22:21:24 <jflory7> Pharaoh_Atem: Oh, really?
22:21:24 <ignatenkobrain> so, what we need
22:21:31 <Pharaoh_Atem> jflory7: Akien is from Mageia, and I work in both Fedora and Mageia
22:21:32 <ignatenkobrain> 1. How to get involved?
22:21:43 <jflory7> Oh, yeah, I know Akien from #fedora-games :)
22:22:04 <Pharaoh_Atem> we're involved to develop best practices together
22:22:23 <jflory7> Pharaoh_Atem++ Akien++ CrossDistroCollaboration++
22:22:23 <Pharaoh_Atem> so that Fedora and Mageia have best packaging for Rust by leveraging the best of us :)
22:22:31 <ignatenkobrain> 2. Write some introduction to new release of rust + some introduction to our SIG (goals, etc.)
22:22:49 <ignatenkobrain> jflory7: am I right with those 2 steps?
22:22:54 <ignatenkobrain> did I miss something?
22:22:59 <Pharaoh_Atem> Akien could probably help me write up something for the blog + magazine for the Mageia perspective :)
22:23:09 <Pharaoh_Atem> as I think it's an awesome point about this SIG
22:23:10 <jflory7> ignatenkobrain: +1, and in that order. :) Something I can help out with too for #1 is getting a badge for the Rust SIG members.
22:23:20 <Pharaoh_Atem> yes, BADGES!
22:23:27 <Pharaoh_Atem> MUST... HAVE... BADGES
22:23:33 <jflory7> Heheh :)
22:23:48 <ignatenkobrain> jflory7: yeah, badges are cool. though we will need again separation from private part and public one as for python
22:24:04 <jflory7> ignatenkobrain: +1 to that too. Do you have FAS groups created?
22:24:10 <ignatenkobrain> since group::rust-sig has commit rights for ALL rust packages (at least plan is like this)
22:24:16 <ignatenkobrain> jflory7: we have only private one
22:24:18 <jistone> just the private rust-sig group so far
22:24:29 * jflory7 nods
22:24:33 <Pharaoh_Atem> we should probably have a rust group for people to join
22:24:54 <jflory7> So maybe having one like rust-sig-team or something similar.
22:25:05 * ignatenkobrain is reluctant for renames
22:25:13 <ignatenkobrain> but I think `rust` should work out
22:25:13 <Pharaoh_Atem> the current rust-sig group would probably be rust-maint, actually
22:25:23 <jflory7> Whatever the naming convention you all agree on will work fine. :)
22:26:09 <jflory7> Pharaoh_Atem: I think there is a hard requirement on having a FAS group end with -sig in some instances... trying to remember what that was for.
22:26:14 <ignatenkobrain> jistone: could you write up about new features of release?
22:26:17 <ignatenkobrain> jflory7: yes
22:27:21 <jflory7> Anyways… I think you all have a good idea of where to start for promoting the SIG. Start with some sort of onboarding steps so new people know how they can get involved and help, and then get a Community Blog post introducing the SIG in Fedora with goals and then linking back to the steps for getting involved. A Fedora Magazine article about new Rust changes coming to Fedora is bonus points!
22:27:55 <ignatenkobrain> seems like good summary
22:28:10 <jflory7> I'll help with a badge and promoting posts on Fedora social media as they come up. :)
22:28:16 <Pharaoh_Atem> sweet
22:28:53 <ignatenkobrain> Pharaoh_Atem: you wanted to take onboarding steps part?
22:28:56 <Akien> Awesome :)
22:29:09 <Pharaoh_Atem> I'll take on the Community Blog post, yeah
22:29:17 <Pharaoh_Atem> Akien will help ;)
22:29:28 <jistone> it's hard for me to know how to talk about a new release besides "check out these upstream release notes!"  or copying therein
22:29:42 <ignatenkobrain> jistone: pick more hottest ;)
22:29:56 <Pharaoh_Atem> jflory7: have we ever talked about Rust on the Magazine before?
22:30:08 <jistone> there have been a couple articles, I think
22:30:10 <jflory7> Pharaoh_Atem: I think only once, when it actually landed in Fedora. Let me look...
22:30:15 <jistone> (not from me)
22:30:30 <jflory7> Pharaoh_Atem: https://fedoramagazine.org/rust-meets-fedora/
22:33:01 * jflory7 has to duck out for a bit - in case the meeting ends, anyone is welcome to shoot me a PM or find me in #fedora-commops anytime :)
22:33:07 <msehnout> I wrote a localized version for mojefedora.cz, but I'm not sure if it'd be of any help for SIG.
22:33:26 <ignatenkobrain> Akien: Pharaoh_Atem: so, I put for you to write introduction to SIG, its goals and so on. And for myself I'm going to write about joining SIG more. Right?
22:33:30 <ignatenkobrain> msehnout: do you have link?
22:33:46 <msehnout> ignatenkobrain, https://mojefedora.cz/rust-oficialne-ve-fedore/
22:34:27 <ignatenkobrain> it's just translation of the post from fedoramagazine I guess, right?
22:35:46 <msehnout> Not exactly translation, but it is inspired by the original one.
22:35:54 <Akien> ignatenkobrain: Sounds good :)
22:36:18 <Pharaoh_Atem> ignatenkobrain: yes
22:36:23 <ignatenkobrain> #action Akien Pharaoh_Atem to write introduction to SIG, its goals and such
22:37:02 <ignatenkobrain> #action ignatenkobrain to write about how to get involved
22:37:42 <jistone> is this for a combined article?
22:37:51 <jistone> I can add the new release summary if you want
22:38:15 <ignatenkobrain> jistone: the acrticle will have intro to SIG and will point out to "how to get involved"
22:38:27 <ignatenkobrain> most likely, a wiki page
22:38:29 * ignatenkobrain nods
22:38:44 <ignatenkobrain> jistone: would be cool. at least some interesting features
22:39:04 <jistone> sure.  this one actually has "macros 1.1", which is big news
22:39:37 <ignatenkobrain> #action jistone to write about features in new version of rust/cargo
22:40:09 <ignatenkobrain> then I think we will try to combine all this things and ask jflory7 for help ;)
22:40:52 <ignatenkobrain> comments? something else to discuss?
22:41:05 <ignatenkobrain> who said that 1hour is more than enough?! :P
22:41:13 <jflory7> ignatenkobrain: +1 from me!
22:41:33 <ignatenkobrain> #info jflory7 approves plan
22:41:45 <jflory7> Heheh
22:41:57 <ignatenkobrain> so, let
22:42:09 <ignatenkobrain> let's start countdown then
22:42:11 <ignatenkobrain> 10
22:42:12 <Pharaoh_Atem> 9
22:42:12 <ignatenkobrain> 9
22:42:14 <ignatenkobrain> 8
22:42:16 <ignatenkobrain> 7
22:42:17 <ignatenkobrain> 6
22:42:18 <ignatenkobrain> 5
22:42:19 <ignatenkobrain> 4
22:42:21 <ignatenkobrain> 3
22:42:22 <ignatenkobrain> 2
22:42:23 <ignatenkobrain> 1
22:42:25 <ignatenkobrain> so
22:42:28 <ignatenkobrain> thanks everyone
22:42:31 <ignatenkobrain> #endmeeting