21:00:34 <ignatenkobrain> #startmeeting Rust SIG (2017-02-08)
21:00:34 <zodbot> Meeting started Wed Feb  8 21:00:34 2017 UTC.  The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:34 <zodbot> The meeting name has been set to 'rust_sig_(2017-02-08)'
21:00:40 <ignatenkobrain> #meetingname rust-sig
21:00:40 <zodbot> The meeting name has been set to 'rust-sig'
21:00:45 <ignatenkobrain> #chair ignatenkobrain jistone
21:00:45 <zodbot> Current chairs: ignatenkobrain jistone
21:00:49 <ignatenkobrain> #topic Agenda
21:00:54 <ignatenkobrain> #info (1) Roll Call
21:00:59 <ignatenkobrain> #info (2) Cargo metadata vs [workspace] paths
21:01:04 <ignatenkobrain> #info (3) Tool for checking crates (with dependencies) in upstream vs Fedora ones
21:01:09 <ignatenkobrain> #info (4) Open Floor
21:01:13 <ignatenkobrain> #topic Roll Call
21:01:16 <ignatenkobrain> .hello ignatenkobrain
21:01:17 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
21:01:25 <msehnout> .hello msehnout
21:01:26 <zodbot> msehnout: msehnout 'Martin Sehnoutka' <msehnout@redhat.com>
21:01:59 <ignatenkobrain> hey msehnout
21:02:18 <msehnout> hey
21:02:35 <jistone> .hello jistone
21:02:36 <zodbot> jistone: jistone 'Josh Stone' <jistone@redhat.com>
21:03:17 <ignatenkobrain> #topic Cargo metadata vs [workspace] paths
21:03:22 <ignatenkobrain> #info libc uses [workspace] which doesn't exist in archive on crates.io
21:03:27 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/issue/10
21:03:32 <ignatenkobrain> #link https://github.com/rust-lang/cargo/issues/3642
21:03:52 <ignatenkobrain> how do we deal with this issue?
21:04:17 <ignatenkobrain> jistone: Unfortunately I don't get position of upstream developer..
21:04:48 <jistone> I intend to open a new issue to discuss ways to make this work better for us
21:04:53 <Pharaoh_Atem> oops, late
21:04:57 <Pharaoh_Atem> I'm here now though
21:05:23 <jistone> I believe @alexcrichton is open to changes, just not what you were implying in the bug report (to include everything)
21:06:08 <ignatenkobrain> jistone: my main point there was that cargo metadata fails on such archives
21:06:13 <jistone> yes
21:06:36 <jistone> but that's not how you framed the subject
21:07:07 <ignatenkobrain> meh
21:07:09 <jistone> I would like to see cargo metadata/build/test all work on unpacked *.crate
21:07:23 * ignatenkobrain needs to train soft skills :D
21:07:28 <jistone> without worrying about path-deps, workspaces, or optional deps
21:07:41 <Pharaoh_Atem> ignatenkobrain: now is as good of a time as any :)
21:08:27 <jistone> cargo knows how to do this indirectly, when a crate is a dependency of the current target
21:08:51 <jistone> so I think it will just be a matter of connecting the dots, maybe a new --flag
21:09:17 <jistone> feel free to assign me to follow up on this, as I mean to anyway :)
21:09:55 <ignatenkobrain> jistone: use action from zodbot ;)
21:11:05 <jistone> #action jistone to followup on cargo's handling of unpacked *.crate packages
21:11:37 <ignatenkobrain> jistone: what do I do for now with libc? just sed'ing that line?
21:11:46 <jistone> sure
21:12:03 <ignatenkobrain> #agreed just drop [workspace] thing for now in libc crate
21:12:07 <ignatenkobrain> #topic Tool for checking crates (with dependencies) in upstream vs Fedora ones
21:12:16 <ignatenkobrain> I didn't made anything on this...
21:12:23 <ignatenkobrain> but I think we need something like this
21:12:27 <ignatenkobrain> at least to have overview
21:12:38 <ignatenkobrain> e.g. we need to print graph of deps for ripgrap
21:12:41 <ignatenkobrain> ripgrep
21:12:56 <ignatenkobrain> to see what we didn't address yet, what we did and so on
21:12:58 <ignatenkobrain> wdyt?
21:13:03 <jistone> there are tools for this, cargo-tree and cargo-graph
21:13:21 <ignatenkobrain> hmm
21:13:32 <ignatenkobrain> those are crates?
21:13:37 <jistone> yeah
21:13:43 <jistone> cargo install cargo-tree
21:13:56 * ignatenkobrain installs
21:14:20 <ignatenkobrain> it has some number of deps..
21:14:20 <jistone> or, "cargo metadata" without the --nodeps should have enough info to form a graph
21:15:47 <msehnout> Do we have/plan to have any special tools for Fedora?
21:15:50 <ignatenkobrain> still compiles..
21:16:17 <ignatenkobrain> I think some handy script to see which crates are packaged would be nice
21:16:50 <jistone> msehnout, yes there's rust2rpm under development
21:17:01 <jistone> in python, so we don't have chicken/egg problems ;)
21:17:36 * ignatenkobrain nods, it still compiles
21:18:00 <jistone> rustc is not fast, it is known
21:18:10 <ignatenkobrain> error: Invalid arguments.
21:18:14 <ignatenkobrain> Usage: cargo tree [options]
21:18:18 <ignatenkobrain> very helpful
21:18:19 <msehnout> It'd be nice to have README files in both repositories as a high level overview of what it should do.
21:18:23 <ignatenkobrain> there's no -h/--help
21:18:30 <jistone> don't run it as cargo-tree, just "cargo tree"
21:19:43 <jistone> however, last I checked, cargo-tree didn't expand recursive build-deps properly
21:20:00 <jistone> so the full "cargo metadata" json may be more useful
21:21:26 <ignatenkobrain> cargo metadata doesn't do recursive..
21:21:39 <jistone> yes it does
21:21:42 <ignatenkobrain> or wait
21:21:43 <ignatenkobrain> hmm
21:21:45 <ignatenkobrain> it does
21:21:47 <ignatenkobrain> right
21:22:13 <jistone> we've just been using --no-deps which disables that
21:23:06 <ignatenkobrain> I'll try to make some script which will show tree of some crate + their packaged versions in Fedora (or at this moment, in COPR)
21:23:14 <ignatenkobrain> ack?
21:24:04 <jistone> ack
21:24:05 <ignatenkobrain> #action ignatenkobrain to write some simple script to show tree of dependencies and their packaged version in Fedora
21:24:09 <jistone> which copr?
21:24:22 <ignatenkobrain> jistone: @rust/playground
21:24:30 <ignatenkobrain> I didn't built anything there yet
21:24:40 <jistone> ah right, thanks
21:24:40 <ignatenkobrain> since I didn't have time to work on anything since last meeting
21:24:54 <ignatenkobrain> but feel free to build there anything you want ;)
21:24:59 <ignatenkobrain> #topic Open Floor
21:25:15 <jistone> Rust 1.15.1 is tagged, should be announced today
21:25:29 <jistone> I'm ready to go in the spec
21:25:47 <ignatenkobrain> #info Rust 1.15.1 is tagged, should be announced today, jistone is ready to build it in Fedora
21:25:50 <walters> just a note, i'm experimenting with rust for ostree: https://github.com/ostreedev/ostree/pull/656 https://github.com/ostreedev/ostree/pull/669
21:26:18 <ignatenkobrain> autofoo + rs..
21:26:23 <walters> if it goes well i may do more, i have some uncertanty around making this critical path particularly with respect to alternative architectures
21:26:51 <ignatenkobrain> walters: I think we cover all arches for now?
21:26:53 <jistone> walters, rawhide at least has all arches covered now
21:26:55 <Pharaoh_Atem> autofoo + rust? :'(
21:26:57 <walters> right
21:27:03 <ignatenkobrain> IIRC only s390 is not supported
21:27:08 <ignatenkobrain> or is it?
21:27:10 <jistone> it is
21:27:23 <jistone> s390x, not the 31-bit s390
21:27:25 <Pharaoh_Atem> s390x is, but I don't think rawhide has s390
21:27:29 <jistone> right
21:28:07 <ignatenkobrain> Pharaoh_Atem: it will..
21:28:14 <ignatenkobrain> dgilmore was talking something about it
21:28:25 <Pharaoh_Atem> I thought we retired s390 with F25?
21:29:09 <Pharaoh_Atem> yeah, looks like s390 is gone as of F25: https://s390.koji.fedoraproject.org/koji/buildinfo?buildID=455400
21:29:48 <jistone> well, if it did come back, there's no support at all for s390 in upstream Rust
21:31:14 <jistone> anyway, walters, the alt arches aren't as well tested upstream, so it rests a lot on us.  if you find issues, please do file bugs
21:31:31 <walters> yeah, my main concern is ppc64le
21:31:39 <walters> as i'd like to support that
21:31:42 <dgilmore> s390x is 64 bit and supported s390 is 31 bit and not supported
21:31:55 <Pharaoh_Atem> ppc64le and ppc64 are both fully supported, afaik
21:32:06 <dgilmore> for now
21:32:06 <jistone> dgilmore, thanks, that's good
21:32:24 <dgilmore> there is talk that ppc64 will get retired and we will only have ppc64le
21:32:30 <dgilmore> but thats just talk right now
21:33:22 <ignatenkobrain> walters: opportunity to test it ;)
21:33:34 <ignatenkobrain> at least it compiles there :D
21:35:33 <jistone> do we need to review former action items?  mine are "sorry, I was busy elsewhere..."
21:35:48 <ignatenkobrain> jistone: I think it's same for everyone :)
21:35:51 <ignatenkobrain> though I completed one item
21:35:54 <ignatenkobrain> :-P
21:36:29 <ignatenkobrain> https://pagure.io/fedora-rust/rust2rpm/c/c946648932a7aaa4e59154b7a3e5fda06f75cb50?branch=master
21:36:32 <ignatenkobrain> this one :)
21:37:46 <ignatenkobrain> so I think we should try harder and make them prior next meeting
21:37:49 <ignatenkobrain> =)
21:38:34 <Pharaoh_Atem> well, it was more bad timing :)
21:38:54 <Pharaoh_Atem> Akien was basically gone over the weekend due to FOSDEM, and I've been busy earlier in this week
21:39:10 <ignatenkobrain> Pharaoh_Atem: that's fine. Everyone of us have other things to do
21:39:58 <ignatenkobrain> so, anything you would like to discuss?
21:40:31 <Pharaoh_Atem> ignatenkobrain: do we have any idea of a packaging procedure yet for rust-y things?
21:40:41 <ignatenkobrain> Pharaoh_Atem: what do you mean?
21:42:09 <Pharaoh_Atem> well, we have the dep generator and we have the rust2rpm thing, but how do we judge things coming in for package review?
21:42:29 <Pharaoh_Atem> what's our measures for what is "good" or "bad" about the package
21:42:31 <Pharaoh_Atem> ?
21:42:49 <ignatenkobrain> Pharaoh_Atem: rust2rpm generates something which should be acceptable for inclusion. license, docs and such should be only fixed
21:43:03 <ignatenkobrain> I don't think we have something else to do at this point
21:43:15 <ignatenkobrain> bundled deps are as usual
21:43:17 <ignatenkobrain> no bundling
21:43:40 <ignatenkobrain> we should use our macro
21:43:59 <ignatenkobrain> although I should really merge those %cargo_install and %cargo_install_crate
21:44:10 <ignatenkobrain> I will, this weekend
21:45:28 <ignatenkobrain> do you have something else in mind?
21:46:29 * Pharaoh_Atem shrugs
21:46:39 <Pharaoh_Atem> it's just that there's a number of "general things" we need to check for
21:46:51 <Pharaoh_Atem> but are there any rust-specific things we need to check for?
21:47:20 <ignatenkobrain> I think only 1) usage of our macro 2) proper BuildRequires/BuildConflicts
21:47:29 <Pharaoh_Atem> and also mixed projects
21:47:38 <Pharaoh_Atem> Rust + C/C++ or Rust + Python or ...
21:47:43 <ignatenkobrain> oh, right
21:47:49 <Pharaoh_Atem> the most prominent usages of Rust right now are mixed language
21:47:54 <ignatenkobrain> I would prefer to not touch this at this point :D
21:48:15 <ignatenkobrain> I think everyone does it in a different way..
21:48:19 <jistone> I believe firefox is vendoring all their rust crates right now
21:48:31 <Pharaoh_Atem> right
21:48:38 <ignatenkobrain> jistone: and I guess firefox package doesn't have Prv: bundled(xxx) = yyy
21:48:42 <Pharaoh_Atem> this is the kind of stuff that I'm just not sure whow we should handle...
21:48:46 <Pharaoh_Atem> *how
21:49:05 <ignatenkobrain> Pharaoh_Atem: %cargo_prep is the thing which should set up override for crates.io
21:49:23 <ignatenkobrain> walters: how do you do it for ostree?
21:49:42 <walters> ignatenkobrain, https://github.com/ostreedev/ostree/pull/669
21:49:59 <walters> i should look at what firefox does
21:50:17 <jistone> also cargo vendor, ok
21:50:21 <jistone> I suspect that will be common
21:51:01 <jistone> rustc itself is now vendoring stuff too after the no-makefiles change
21:51:30 <Pharaoh_Atem> I think if vendoring is going to be common, we should probably be checking and ensuring bundled() provides are in place
21:51:55 <jistone> https://github.com/rust-lang/rust/tree/master/src/vendor
21:52:08 <Pharaoh_Atem> ignatenkobrain: that might mean we need something to generate that list by looking in a vendor tree and spitting them out to paste into a spec
21:52:12 <ignatenkobrain> jistone: not even submodules...
21:52:13 <jistone> but a lot of these are used only for build tools, not in shipped binaries
21:52:55 <jistone> ignatenkobrain, submodules were considered, don't recall why they didn't
21:53:07 <jistone> probably just because "cargo vendor" doesn't work that way
21:53:12 <ignatenkobrain> hehe
21:53:39 <ignatenkobrain> jistone: Pharaoh_Atem: is it always in ./vendor directory?
21:53:50 <ignatenkobrain> (relative to Cargo.toml)
21:54:06 <jistone> that's what cargo-vendor does, but it doesn't have to stay there
21:54:18 <Pharaoh_Atem> if they're (hopefully lazy), it'll be there
21:54:56 <jistone> I'm vendoring cargo's own deps too.  in that case, I made it as a separate Source tarball
21:55:06 <ignatenkobrain> then we can try to automatically add Provides: bundled()
21:55:29 <ignatenkobrain> Pharaoh_Atem: file issue for rust2rpm
21:55:58 <jistone> ignatenkobrain, won't it be hard to tell what's actually shipped?  I don't think you need bundled() for transient build artifacts
21:56:12 <ignatenkobrain> jistone: good question..
21:56:38 <ignatenkobrain> at this point I don't have answer
21:57:03 <ignatenkobrain> probably it should be manual task
21:57:13 <jistone> (fwiw, current firefox doesn't declare *anything* bundled, nevermind rust)
21:57:27 <ignatenkobrain> jistone: that's probably violation of guidelines :D
21:58:22 <ignatenkobrain> anyhow this is anyway manual task, because you need to file licenses properly
21:58:31 <ignatenkobrain> and license files
21:58:38 <Pharaoh_Atem> ignatenkobrain: done: https://pagure.io/fedora-rust/rust2rpm/issue/15
21:58:40 <ignatenkobrain> since rust2rpm isn't AI..
21:59:05 <Pharaoh_Atem> rust2rpm is going to rise and destroy us all :P
21:59:12 <ignatenkobrain> okay, let's leave it for future
21:59:19 <ignatenkobrain> anything else? (we have 1 minute)
21:59:19 <ignatenkobrain> =)
21:59:40 <Pharaoh_Atem> fwiw, Golang guys consider input stuff worth marking too
21:59:47 <Pharaoh_Atem> though I'm not sure that they do it...
22:00:13 <Pharaoh_Atem> as it's possible that builds could break due to a bundled build-time thing
22:00:24 <ignatenkobrain> #endmeeting