21:00:05 <ignatenkobrain> #startmeeting Rust SIG (2017-02-22)
21:00:05 <zodbot> Meeting started Wed Feb 22 21:00:05 2017 UTC.  The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:05 <zodbot> The meeting name has been set to 'rust_sig_(2017-02-22)'
21:00:08 <ignatenkobrain> #meetingname rust-sig
21:00:08 <zodbot> The meeting name has been set to 'rust-sig'
21:00:12 <ignatenkobrain> #chair ignatenkobrain jistone
21:00:12 <zodbot> Current chairs: ignatenkobrain jistone
21:00:15 <ignatenkobrain> #topic Agenda
21:00:20 <ignatenkobrain> #link https://docs.pagure.org/fedora-rust.sig/meetings/2017-02-22.html
21:00:25 <ignatenkobrain> #info (1) Roll Call
21:00:28 <ignatenkobrain> #info (2) Current status of packaging
21:00:31 <ignatenkobrain> #info (3) Open Floor
21:00:36 <ignatenkobrain> #topic Roll Call
21:00:56 <ignatenkobrain> .hello ignatenkobrain
21:00:57 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
21:01:12 <jistone> .hello jistone
21:01:13 <zodbot> jistone: jistone 'Josh Stone' <jistone@redhat.com>
21:01:36 <ignatenkobrain> looks like today not that much of us ;)
21:01:47 <ignatenkobrain> hey ljones
21:01:56 <ljones> hi
21:02:26 <Akien> .hello akien
21:02:28 <zodbot> Akien: akien 'Rémi Verschelde' <rverschelde@gmail.com>
21:02:56 <ignatenkobrain> okay, so let's move on ;)
21:03:01 <ignatenkobrain> #topic Current status of packaging
21:03:06 <ignatenkobrain> #info 30+ crates in COPR repo, but there’s blocker – DNF doesn’t support rich builddeps
21:03:10 <ignatenkobrain> #link https://pagure.io/fedora-rust/rust2rpm/pull-request/23
21:03:27 <ignatenkobrain> I have patch for libsolv and RPM, but DNF doesn't support rich deps =(
21:04:58 <ljones> ignatenkobrain: Does using strict `==` versioning help this, or is it still related to having two or more of the same crate but different versions?
21:04:59 <ignatenkobrain> I'm not sure how to proceed at this moment
21:05:14 <ignatenkobrain> ljones: strict versioning helps
21:05:24 <ignatenkobrain> but this means we have to put it everywhere
21:05:28 <ignatenkobrain> and it's PITA
21:06:31 <ljones> *Note: I'm here mainly to catch up with what has been happening (been quite busy).
21:07:05 <ljones> Can the crate2rpm not rebuild the crates with strict versioning in place?
21:07:12 <jistone> what will it take to enhance dnf?
21:07:31 <jistone> ljones, that would require us to update all crates when just one updates
21:07:33 <ignatenkobrain> jistone: this is good question. at this moment it tries to parse string all the time
21:07:58 <ignatenkobrain> I set up meeting with my colleagues tomorrow, so we will see
21:08:18 <ignatenkobrain> proper solution is not trivial, but probably we will try to find some quick workaround
21:08:39 <f2u> I still don't understand the root of the problem.
21:08:43 <ignatenkobrain> probably some method which will ask libsolv to parse richdep and give RelId
21:08:55 <jistone> and how does this affect other Fedora package managers?  e.g. the gnome package updater, whatever that's called
21:08:56 <f2u> Are there distinct packages which provide the same capability at different version levels?
21:09:02 <f2u> And are supposed to be installable in parallel?
21:09:25 <ignatenkobrain> jistone: PackageKit uses libdnf, but PK is not affected since it doesn't care about builddeps
21:09:41 <ignatenkobrain> f2u: yes, all libs can be with different versions
21:09:53 <jistone> f2u, yes, we could have semver-incompatible versions of the same crate, and cargo will use both
21:09:53 <ignatenkobrain> for example, in dependency chain of ripgre, there are 3 versions of serde
21:10:00 <ljones> jistone: as I understand gnome-software et al, these ask packageKit to do the work, and pk then utilises the system tools (rpm, dnf)
21:10:01 <ignatenkobrain> 0.6.x, 0.8.x and 0.9.x
21:10:08 <f2u> ignatenkobrain: And this is good how?
21:10:12 <Pharaoh_Atem> ooh, here
21:10:15 <Pharaoh_Atem> .hello
21:10:18 <zodbot> Pharaoh_Atem: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
21:10:19 <Pharaoh_Atem> .hello ngompa
21:10:21 <zodbot> Pharaoh_Atem: ngompa 'Neal Gompa' <ngompa13@gmail.com>
21:10:27 <Pharaoh_Atem> sorry I'm a bit late
21:10:32 <ignatenkobrain> f2u: this is not very good, but we can't port whole world to new versions
21:10:36 <ignatenkobrain> it's just impossible
21:10:43 <jistone> is it?
21:10:44 <jistone> hard, sure
21:10:44 <ignatenkobrain> hey Pharaoh_Atem
21:11:17 <f2u> ignatenkobrain: The multiple versions are a support nightmare.
21:11:17 <jistone> but most things in the distro do use the same versions
21:11:22 <jistone> parallel versions are the exception
21:11:34 <Pharaoh_Atem> ljones: PK does not use DNF
21:11:48 <Pharaoh_Atem> it uses libdnf the library directly, and does solving slightly differently
21:11:53 <f2u> And it's mot just about DNF, the EPEL chroots will be built with mock on yum, which doesn't deal with rich dependencies, either.
21:12:05 <ljones> I stand corrected
21:12:17 <Pharaoh_Atem> for the moment, I think EPEL is going to be a vendored world
21:12:24 <Pharaoh_Atem> which means our bundling rules will apply there
21:12:26 <jistone> sadly
21:12:38 <jistone> reluctantly
21:12:42 <Pharaoh_Atem> despondently
21:13:25 <ignatenkobrain> f2u: we're in Fedora, so I don't care much about RHEL... but RHEL8 should support rich deps ;)
21:13:44 <Pharaoh_Atem> and if we're lucky, it'll even support "with"
21:14:05 <ignatenkobrain> Pharaoh_Atem: I'm sure Florian can make it in time
21:14:29 <Pharaoh_Atem> I don't doubt that, since he works on RHEL RPM maint along with Fedora RPM maint and upstream RPM development
21:14:30 <ignatenkobrain> but now there's problem with DNF =/
21:15:19 <jistone> so I think the short term solution is that we need to patch deps to the latest
21:15:31 <ignatenkobrain> I'll see tomorrow if I can have dirty workaround
21:15:47 <jistone> that may be the long-term solution too, since multi-version libs aren't really desired
21:16:01 <ignatenkobrain> if not, then we will have to either patch to latest version or patch requires/buildrequires to have exact name of package
21:16:23 <Pharaoh_Atem> essentially doing packaging-time resolution like what Debian does?
21:17:45 <ljones> ignatenkobrain: A lot of crates seem to have an exact version of their deps in the Cargo.toml, so perhaps using Build/Requires exact wouldn't be too much of a problem?
21:18:05 <ignatenkobrain> ljones: almost none of them have =x.y.z
21:18:17 <jistone> ljones, version = "1.2.3" is *not* an exact dep
21:18:18 <Pharaoh_Atem> if they had exact versions, then rust2rpm would print those out
21:18:31 <ignatenkobrain> yes, it's transforms into CARET dep
21:18:38 <ignatenkobrain> 1.2.3 == ^1.2.3
21:18:50 <ignatenkobrain> which is IIRC 1.2.3 <-> 1.3.0
21:18:55 <jistone> yes
21:19:03 <ljones> So looking at rustc-serialize for example, https://github.com/rust-lang-nursery/rustc-serialize/blob/master/Cargo.toml
21:19:10 <ljones> rand = "0.3"
21:19:17 <ljones> How does that translate?
21:19:18 <Pharaoh_Atem> that's not exact
21:19:29 <Pharaoh_Atem> it says, sematically 0.3 is the minimum
21:19:31 <ignatenkobrain> ljones: 0.3 <-> 0.4 IIRC
21:19:31 <jistone> that's >=0.3, <0.4
21:19:33 <Pharaoh_Atem> it's a Cargo shorthand
21:20:01 <jistone> http://doc.crates.io/specifying-dependencies.html
21:20:02 <Pharaoh_Atem> version selection has a lot of implicit behaviors in Cargo, compared to explicit behaviors in pip, gem, etc.
21:20:16 <ljones> I seem to have misunderstood that then. I always had thought that it was an exact requirement and cargo wouldn't build said package with any other version.
21:20:21 <Pharaoh_Atem> nope
21:20:26 <jistone> "The string "0.1.12" is a semver version requirement. Since this string does not have any operators in it, it is interpreted the same way as if we had specified "^0.1.12", which is called a caret requirement."
21:20:37 <Pharaoh_Atem> IIRC, it was an explicit design goal to avoid making it default to locking versions like that
21:21:23 <jistone> you can say "=0.1.12" if that's exactly what you want
21:21:30 <ljones> Ah, yes sorry, the caret requirement - I had forgotten what it means.
21:22:16 <ignatenkobrain> #info We have 3 ways of "solving" issue: 1) Some dirty workaround/solution in DNF 2) Patch crates for latest versions 3) Patch (Build)Requires to have compat-rust-fooXY-devel dep and remove Provides: crate() from such packages
21:22:41 <ljones> Though still, this means that locking a crates BuildRequire to a version wouldn't be too much of an issue in the long term
21:22:49 <ignatenkobrain> #action ignatenkobrain to get back with more info on workaround/solution in DNF
21:23:08 <ignatenkobrain> ljones: it will be just painful always to patch spec
21:24:01 <ignatenkobrain> and in future when we will have auto-buildreq it will be even more pain
21:24:15 <ignatenkobrain> but for now it would work
21:24:35 <ignatenkobrain> that's why I wrote solutions in best order
21:24:50 <ignatenkobrain> i.e. if we fix in dnf - great, if not - patch, if not - manual work
21:25:27 <ignatenkobrain> agree with me?
21:25:33 <Pharaoh_Atem> yeah
21:25:49 <ljones> aye
21:25:51 <jistone> yes
21:26:00 <ignatenkobrain> good
21:26:06 <ignatenkobrain> I was disappointed today very much
21:26:29 <ignatenkobrain> because Florian did great job to implement rpmds parser (in hurry)
21:26:38 <jistone> on 2, we may find that patching an update to one dep will automatically get you newer deps for other things
21:26:46 <jistone> if some of the old stuff is just transitive
21:26:58 <ignatenkobrain> jistone: in case of ripgrep
21:27:20 <Pharaoh_Atem> ignatenkobrain: yeah, I didn't realize he'd already gone through and written the basic parser for it
21:27:23 <ignatenkobrain> there are first level deps which require different versions of serde
21:27:32 <Pharaoh_Atem> that's amazing, and now I feel bad about it :(
21:27:35 <ignatenkobrain> Pharaoh_Atem: I asked him to do that today
21:27:49 <ignatenkobrain> and shame for me that I didn't test dnf before
21:27:54 <Pharaoh_Atem> ffest is literally made of amazing
21:28:04 <Pharaoh_Atem> ffesti especially
21:28:37 <ignatenkobrain> anyway, I will get back with results of DNF discussion somewhere tomorrow during day by UTC ;)
21:28:43 <jistone> ignatenkobrain, my thought is that perhaps an update to those first-level deps might update their serde req too
21:28:55 <ignatenkobrain> jistone: unfortunately not
21:29:49 <ignatenkobrain> ripgrep -> clap -> vec_map -> serde 0.6.x
21:29:59 <ignatenkobrain> vec_map is latest
21:30:24 <jistone> it's a year old, maybe they'd take a PR and release a new version
21:30:58 <ignatenkobrain> jistone: if you can prepare it, I would be happy
21:31:08 <ignatenkobrain> and there's something else in depchain which requires 0.8.x
21:31:08 <jistone> plus serde is an optional dep there - is it even used?
21:32:34 <ignatenkobrain> didn't remember
21:32:40 <ignatenkobrain> but for other 0.8.x it's hard req
21:34:33 <ignatenkobrain> so, we'll see tomorrow :)
21:34:46 <ignatenkobrain> #topic Open Floor
21:35:11 <ignatenkobrain> #info Many crates now contain license text in crates.io archive
21:35:28 <Pharaoh_Atem> when did that happen?
21:35:30 <jistone> did crates.io change?
21:35:32 <ignatenkobrain> I filed 15+ issues on github and I think almost all of them were fixed
21:35:33 <ignatenkobrain> :D
21:35:42 <ignatenkobrain> jistone: nope, just massive bugfilling
21:35:42 <jistone> heh, ok, in the crates themselves
21:36:18 <Pharaoh_Atem> maybe could request that it be part of crate submissions to include the data
21:36:26 <Pharaoh_Atem> s/data/file/
21:36:42 <ignatenkobrain> there's license_file
21:37:10 <ignatenkobrain> but it's 1) not widely used 2) can have only one file while usually stuff is licensed under multiple licenses
21:38:16 <ignatenkobrain> now we have nice workaround for removing dev-deps :D
21:38:37 <ignatenkobrain> https://pagure.io/fedora-rust/rust2rpm/c/d4334a2ee7e30f8a50f425393af188320a94c1d3?branch=master
21:39:31 <ignatenkobrain> problem is that cargo creates lock file at any of build/install/test commands which means it wants all dependencies resolved at that point (even dev ones)
21:39:33 <jistone> that happens in %prep?
21:39:44 <ignatenkobrain> jistone: no, in %build
21:39:49 <jistone> the workaround, I mean
21:39:57 <ignatenkobrain> ah, partially yes
21:40:08 <ignatenkobrain> there's part in %install as well
21:40:34 <ignatenkobrain> because we get original cargo.toml installed into registry
21:40:54 <ignatenkobrain> 40 + %if ! %{with check}                                                       \ 41 +   %{__install} -p Cargo.toml.orig $REG_DIR/Cargo.toml                     \ 42 + %endif                                                                    \
21:40:58 <ignatenkobrain> argh
21:40:59 <ignatenkobrain> 40 + %if ! %{with check}                                                       \
21:41:03 <ignatenkobrain> 41 +   %{__install} -p Cargo.toml.orig $REG_DIR/Cargo.toml                     \
21:41:06 <ignatenkobrain> 42 + %endif                                                                    \
21:41:15 <jistone> ok
21:41:24 <jistone> it's not actually necessary to keep the original, is it?
21:41:39 <ignatenkobrain> it's not necessary, but why not ;)
21:42:04 <Pharaoh_Atem> keeping the original is useful for validation
21:42:13 <Pharaoh_Atem> and when you're debugging, since we're monkeying around with the file...
21:43:23 <ignatenkobrain> oh, I have topic to discuss
21:43:40 <ignatenkobrain> how do we get rid out of useless stuff in registry
21:43:41 <Pharaoh_Atem> oh?
21:43:45 <ignatenkobrain> like appveyor.yml
21:43:51 <ignatenkobrain> and such stuff
21:43:56 <Pharaoh_Atem> what about them?
21:44:04 <ignatenkobrain> Pharaoh_Atem: we don't want to package them
21:44:16 <Pharaoh_Atem> well, yes
21:44:23 <jistone> who cares?
21:44:25 <Pharaoh_Atem> they don't really help us, so they shouldn't be installed
21:44:32 <ignatenkobrain> jistone: sometimes it adds some additional dependencies ;)
21:44:41 <Pharaoh_Atem> are you serious?!
21:44:41 <ignatenkobrain> for example, libc has some CI scripts
21:44:52 <ignatenkobrain> and one shebang is #!/usr/bin/expect
21:45:01 <ignatenkobrain> and I didn't even had expect installed on my laptop
21:45:12 <ignatenkobrain> and it was surprise why rust-libc-devel requires expect :D
21:45:21 <ljones> Sheesh... Well, that's a good thing to know about.
21:45:25 <jistone> should we filter $REG_DIR from dep searching?
21:45:33 <jistone> or would that kill your auto stuff?
21:45:41 <Pharaoh_Atem> that'd kill all the autostuff
21:45:50 <jistone> boo
21:46:01 <ignatenkobrain> jistone: we would have to patch each autothing to exclude dir
21:46:19 <ignatenkobrain> or turn all thing completely, but this doesn't make any sense
21:46:44 <ignatenkobrain> ideally, cargo-package would print only needed stuff
21:47:31 <jistone> with build.rs scripts and such, I don't think it could know what's actually needed
21:47:45 <jistone> that's why Cargo.toml has include/exclude
21:48:19 <ignatenkobrain> should we send patches to each project to have only useful stuff in include meanwhile?
21:48:33 <Pharaoh_Atem> probably
21:48:48 <ignatenkobrain> but what would be workaround for now? removing all crap in %install ?
21:48:55 <Pharaoh_Atem> yeah
21:49:04 <jistone> or in %prep
21:49:05 <Pharaoh_Atem> it's the same thing we have to do in other packages :/
21:49:25 <ignatenkobrain> jistone: yeah, %prep is better because then we will know if we broke something ;)
21:50:18 <ignatenkobrain> #agreed remove all useless files (like appveyor.yml or CI scripts) in %prep
21:50:30 <ignatenkobrain> another question is license/readmes
21:50:37 <ignatenkobrain> we can't remove them in prep
21:50:53 <ignatenkobrain> but we don't need to have 2 copies of licenses/docs in system
21:51:04 <ignatenkobrain> probably %exclude in %files?
21:51:13 <Pharaoh_Atem> either that, or just delete them at %install
21:51:25 <Pharaoh_Atem> the latter is probably less confusing
21:51:32 <jistone> can't you %license the file under the installed $REG_DIR path?
21:51:44 <ignatenkobrain> jistone: that is usually bad idea
21:51:56 <Pharaoh_Atem> I'm not quite sure it works that way, either
21:52:08 <ignatenkobrain> I didn't remember, but it causes some problem
21:52:09 <ignatenkobrain> s
21:52:26 <ignatenkobrain> but I can check it
21:53:38 <ignatenkobrain> warning: File listed twice: /usr/src/rust/libc-0.2.20/README.md
21:53:59 <ignatenkobrain> that's bad idea
21:54:31 <ignatenkobrain> so I think %exclude probably will be better since it will be in same section as all %license/%doc stuff
21:54:33 <jistone> ah
21:54:33 <jistone> well
21:54:43 <jistone> I have a few warnings like that in rust.srpm
21:54:51 <jistone> "it's just a warning..."
21:55:14 <ignatenkobrain> jistone: many tools rely that licenses will be in /usr/share/licenses
21:55:18 <ignatenkobrain> and docs in /usr/share/docs
21:55:43 <ignatenkobrain> what I mean is that when you have this warning when you will try to install without docs, it will still install docs
21:55:54 <ignatenkobrain> which is not welcomed with containers
21:55:57 <ignatenkobrain> because of size
21:56:19 <jistone> bah, these are tiny compared to the binary parts of rustc  :P
21:57:00 <ignatenkobrain> that's also true
21:57:45 <ignatenkobrain> anyway, let's vote 1) remove them in %install 2) %exclude in files 3) forget about it
21:57:57 <ignatenkobrain> I'm 2 and 1
21:59:25 <ignatenkobrain> Pharaoh_Atem: jistone: ljones: ^^
21:59:39 <Pharaoh_Atem> I'd prefer 1
21:59:48 <Pharaoh_Atem> obvious and clear that way
21:59:54 <jistone> I have no real opinion here
22:00:29 <ignatenkobrain> I will file issue somwhere with examples and then we'll choose offline what's the nicest way ;)
22:00:36 <ignatenkobrain> so, it's time already
22:01:00 <ignatenkobrain> someone wants to say something important ? ;)
22:01:50 <jistone> thanks everyone
22:01:51 <ignatenkobrain> so, then countdown ;)
22:01:52 <ignatenkobrain> 10
22:01:54 <ignatenkobrain> 9
22:01:55 <ignatenkobrain> 8
22:01:57 <ignatenkobrain> 7
22:01:58 <ignatenkobrain> 6
22:01:59 <ignatenkobrain> 5
22:02:00 <ignatenkobrain> 4
22:02:01 <ignatenkobrain> 3
22:02:02 <ignatenkobrain> 2
22:02:03 <ignatenkobrain> 1
22:02:07 <ignatenkobrain> Thanks everyone!
22:02:11 <ignatenkobrain> see you on #fedora-rust
22:02:15 <ignatenkobrain> and here next week
22:02:17 <ignatenkobrain> #endmeeting