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