21:00:01 #startmeeting Rust SIG (2017-03-15) 21:00:01 Meeting started Wed Mar 15 21:00:01 2017 UTC. The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:01 The meeting name has been set to 'rust_sig_(2017-03-15)' 21:00:08 #meetingname rust-sig 21:00:08 The meeting name has been set to 'rust-sig' 21:00:12 #chair ignatenkobrain jistone 21:00:12 Current chairs: ignatenkobrain jistone 21:00:15 #topic Agenda 21:00:19 #link https://docs.pagure.org/fedora-rust.sig/meetings/2017-03-15.html 21:00:22 #info (1) Roll Call 21:00:25 #info (2) Packaging Guidelines 21:00:28 #info (3) State of affairs and future plans 21:00:30 #info (4) Open Floor 21:00:33 #topic Roll Call 21:00:38 .hello ignatenkobrain 21:00:39 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 21:00:40 .hello jistone 21:00:40 .hello 21:00:42 Pharaoh_Atem: (hello ) -- Alias for "hellomynameis $1". 21:00:44 jistone: jistone 'Josh Stone' 21:00:46 .hello ngompa 21:00:50 Pharaoh_Atem: ngompa 'Neal Gompa' 21:00:51 .hellp mich181189 21:00:57 mich181189: hellp? :D 21:00:58 .hello mich181189 21:00:59 mich181189: mich181189 'Michael Cullen' 21:01:08 hellps if I can spell! 21:01:08 .hello akien 21:01:09 Akien: akien 'Rémi Verschelde' 21:01:31 #topic Packaging Guidelines 21:01:36 #link https://pagure.io/fedora-rust/sig/pull-request/9 21:01:43 this is from last week 21:01:55 I think I addressed issues 21:02:12 ohh, probably not BuildRequires =( 21:04:09 ok, are there questions about that? 21:04:43 I think it's just minor to make it as subsection and provide example 21:04:51 any other points? 21:05:01 btw, I added rust- prefix in current packages 21:05:04 everywhere 21:05:13 and fixed rust2rpm to generate proper names 21:05:20 Sounds good. 21:05:35 cool 21:05:37 the current proposed structure looks good to me 21:05:51 "Packagers **MUST** use ``with`` rich dependency operator" 21:06:08 I still would like to try the "poor" alternative 21:06:17 jistone: yeah, let's talk about this in next topic =) 21:06:35 "poor" would not be in upstream guidelines, but fedora ones 21:07:13 what does upstream mean here? the nebulous collection of rpm distros? 21:07:16 yes 21:07:49 and even for downstream Fedora, I'd like to ensure that packages can easily transition to the correct form 21:07:56 jistone: upstream == proper (the fedora-rust on pagure) 21:08:25 #action ignatenkobrain to make BuildRequires as sub-section and add example 21:08:28 Hi all. Bit late due to system issues (nvidia, 4.10 kernel) 21:08:40 hey Luke 21:08:50 Pharaoh_Atem: jistone: I don't have any updates on releng view at this moment =( 21:09:03 I guess it just seems weird to say MUST for something that doesn't even work anywhere (yet) 21:09:13 jistone: it does work 21:09:18 how did I built 100+ packages? :P 21:09:21 not in any distro, I mean 21:09:39 well, we haven't proposed guidelines to include in the monolith of packaging guidelines yet for a reason 21:09:43 not many people run ignatenkobrain-OS 21:10:01 jistone: you don't need special OS, there's repo with everything what you need ;) 21:10:13 you get my point 21:10:23 but let's discuss this after in next topic (after good news) 21:10:43 #topic State of affairs and future plans 21:11:08 #info ripgrep has been updated to 0.5.0 🕺 21:11:14 #info "Target RPM" feature has been tested on COPR dev instance, a bit more work is needed to get in prod 21:11:20 #info libdnf and dnf-plugins-core patches were merged upstream 21:12:17 so, only 2 patches are now needed (rpm and libsolv) 21:12:21 libsolv patch is oneliner 21:12:30 oh, that's an emoji! pagure shows junk in there like 🕺 21:12:33 and what about the rpm patch? 21:12:34 :) 21:12:50 yeah, that's why it took me time to copy it from terminal ;) 21:13:19 * ignatenkobrain should report bug against pagure 21:13:31 Pharaoh_Atem: about RPM patch, I don't think there are any news 21:13:39 Florian didn't wrote full patch yet 21:14:03 but I have all test-cases prepared 21:14:13 that's this, right? https://github.com/rpm-software-management/rpm/pull/164 21:14:30 https://github.com/rpm-software-management/rpm/pull/164/commits/45777d2ebf98ff2d3831c33fbfbfe900b1c2dc92 21:14:37 yeah, this one is initial draft 21:15:27 will Florian be able to work on this anytime soon? 21:15:28 so, what are the plans/targets? 21:15:36 Pharaoh_Atem: yes, it's still planned for 4.14 21:16:47 should we try to package something bigger or start working more on integrating in distro or ... ? 21:17:07 multiple things in parallel? 21:17:08 I think we should work on getting downstream distro integration going first 21:17:29 we can certainly keep packaging things, but it's going to be hard to really progress without the integration work done 21:17:37 yeah, I think "100+ packages" is plenty proof of concept :) 21:18:00 we're already going to make tons of reviewers sad when the deluge of rust packages hits the review queue :) 21:18:15 isn't that part of what a SIG is for? 21:18:21 yes 21:18:22 so we review Rust packages ourselves? 21:18:27 yeah :D 21:18:30 yep :P 21:18:48 s/sad/busy/ :-P 21:19:56 #info we need to start working on integration into distros 21:20:06 I wonder how long it will take for someone to complain about the static libs... 21:20:09 let's get back to the topic 21:20:33 jistone: if we want it now, there's no other option apart from adding that bunch of provides and so on 21:20:34 mich181189, I've handled such complaints already, before we even had rustc 21:20:42 ignatenkobrain: what does the integration need? 21:21:05 luke_nukem: on your side (openSUSE), the main thing is that you'll need rpm, libsolv, and libzypp patches 21:21:11 and perl-BSSolv patches 21:21:15 luke_nukem, given there aren't proper rich deps, or not "with", for now we have to figure out a fallback 21:21:22 yeah 21:21:29 Ah, that sort of integration. 21:21:45 jistone: main point about that hackish stuff is how to handle >=0.1,<0.4 21:21:59 in your 100+, did anything need that? 21:22:05 jistone: 3-5 packages 21:22:20 given most rust deps seem to be advisory (I've only had to make code changes on one package to change versions and it was a couple of years of upgrade) and given it's build-time only, does it even matter that much? 21:22:27 hmm, I know num's serde dep is like that, actually 21:22:56 probably we should just take first and use it 21:23:04 i.e. only Req: foo >=0.1 21:23:20 and then if someone complains -- they go to releng and implement support for rich deps 21:23:38 for legacy, we can fall back to Req >= + Req < 21:23:58 the worst thing that happens is that too many things get installed 21:24:03 or bump it to the newest we can, foo >=0.1,<0.4 -> crate(foo-0.3) >= 0.1 21:24:11 jistone: manually? 21:24:26 in theory, that could be automatic 21:24:31 nope 21:24:45 well, only if you have 2 21:24:51 otherwise parsing gets very complicated 21:24:53 jistone: it can't because something has to make the decision on how the versioning construct should look 21:25:05 ok 21:25:05 and depending on how wide the net is, that could get really screwy 21:25:06 because you need to find highest bound 21:25:43 "we can fall back to Req >= + Req <" 21:25:45 ignatenkobrain, jistone: my suggestion for "legacy" behavior is just do Req >= + Req < 21:25:48 is that workable? 21:25:59 then fine 21:26:14 jistone: sometimes that will pull 2 dependencies which is below range and above :D 21:26:14 it's a good short-term plan, as long as we ignore feature deps 21:26:24 but will not pull dep in the middle 21:26:38 because feature deps will require rich deps 21:27:05 so I think just doing Req: >= is workable 21:27:05 I fully expect that we wouldn't be packaging things this way for very long in Fedora 21:27:16 at least something will be pulled in 21:27:42 hopefully we would have such a wide spread of versions to miss the middle that's actually wanted 21:28:16 though, given the experience of what happens in golang, I think it's not very likely that we'll package libraries for EPEL7 21:28:19 "at least something will be pulled in" doesn't help if it doesn't support the latest 21:28:20 I'm fine with having multiple reqs as well. just don't want to be the one who will be fixing it :) 21:28:28 they get removed too often :/ 21:28:54 I expect to see rust and cargo move out of EPEL and into RHEL proper this year 21:28:58 or maybe next year 21:29:09 who volunteers to do work on Req+Req in rust2rpm? 21:29:20 aand genegaring multiple provides 21:29:29 Pharaoh_Atem, we've made no such commitment for RHEL 21:29:31 basically, implementing "legacy" mode 21:29:34 don't we already generate the provides? 21:29:46 Pharaoh_Atem: we generate only crate(x) 21:29:48 jistone: when the next ESR after 52 hits, it'll get pulled in 21:30:06 but not crate(x) + crate(x-0) + crate(x-0.1) + crate(x-0.1.0) 21:30:25 because based on those provides we can generate ranges 21:30:26 Pharaoh_Atem, doesn't mean you'll see it 21:30:33 or wait 21:30:34 hmm 21:30:46 yeah, you don't need provides 21:30:49 only requires 21:31:26 how? 21:31:41 you only want version ranges for everything? 21:31:54 now I'm completely lost 21:32:04 I was lost a long time ago 21:32:05 let's agree how it should look like 21:32:06 why don't we need semver provides? 21:32:22 ~0.1.80 21:32:26 how this will look like? 21:32:41 crate(foo-0.1) >= 0.1.80 21:33:22 okay, ^2.21 ? 21:33:38 crate(foo-2) >= 2.21 21:33:45 Pharaoh_Atem: ^^ 21:34:26 and something would provide both crate(foo-2) and crate(foo-2.21) 21:34:31 (or newer for the latter) 21:35:00 * ignatenkobrain is still looking for volunteer :P 21:35:39 ignatenkobrain: Err, volunteer for what? 21:35:49 making that work :) 21:35:54 luke_nukem: to implement this generator in rust2rpm 21:35:58 Sorry, trying to keep track while in class :) 21:36:14 I probably should volunteer ... right after I do the other items I haven't touched... :/ 21:36:16 sorry 21:36:38 ignatenkobrain: Ah, I'll add that to my "todo.txt" and have a look soon (day or so) 21:36:48 * ignatenkobrain is not in rush, he is perfectly happy with playground repo :D 21:36:49 how about, I volunteer to file an issue, with examples 21:37:23 #action jistone to file issue about "legacy" mode with examples 21:37:48 Cool 21:38:06 do we have some other target? 21:38:19 Hmm, I like the idea of using semver rather than >= + < 21:38:37 e.g. to re-bootstrap cargo with natively-packaged deps? :P 21:38:42 jistone: ^^ 21:38:48 That would be nice indeed. 21:39:34 basically, dropping the cargo-vendor tarball 21:39:39 or... are there some other useful tools like ripgrep? 21:39:42 jistone: yeah 21:40:13 a lot of other things that I 'cargo install' are cargo addons 21:40:21 which probably want cargo as a crate themselves 21:40:44 do you have rustfmt? 21:41:07 I do have 21:41:26 I think I even ported it to newer versions of libs :P 21:41:50 jistone: https://github.com/rust-lang-nursery/rustfmt/commits/master?author=ignatenkobrain 21:42:00 cool 21:42:52 talking about cargo... 21:43:02 Quick question about packaging rustc itself - have you experienced circular building with rust requiring cargo whcih requires rust? 21:43:05 I think only 1-2 top-level deps are missing 21:43:28 which means 4-5 deps in total are missing 21:43:44 so we're pretty much have everything in place to try it out 21:44:16 luke_nukem, that's only a problem for bootstrap under rustbuild 21:45:13 (1) build rust with upstream rust+cargo (2) build cargo with local rust and upstream cargo (3) build rust locally (4) build cargo locally 21:46:10 jistone: I think it may be more to do with how OBS is working at the moment, if either cargo or rust builds, then it triggers a rebuild of the other - infinite loop :-| 21:46:20 ignatenkobrain, if you look at cargo.spec, you can see where I unpack the vendor and setup a .cargo/config 21:46:26 luke_nukem, cute 21:47:00 luke_nukem, we have koschei to attempt rebuilds, but that doesn't go in the buildroot, so they don't end up triggering each other 21:47:15 Hmm.. 21:47:39 I need to duck out early - next class. Thanks all - will be in the usual channels. 21:47:56 ignatenkobrain, I think it wouldn't be hard to make cargo.spec conditionally point to the system repo instead 21:48:10 jistone: should not be hard I suppose 21:48:13 it's still same 21:48:14 %cargo_prep 21:48:39 the actual problem is that he has bootstrap and real package as separate specs 21:48:48 OBS cycles back and forth until all conditions are satisfied 21:48:49 rust -> cargo -> rust-rpm-macros -> rust -> cargo -> deps -> cargo 21:48:52 ? ;) 21:50:04 note that we're slowly running out of time (we have 10 mins) 21:50:27 jistone: should I finish remaining crates and try cargo rebuild? 21:50:39 (and it's good practice to try and end a little early) 21:51:00 ignatenkobrain, sounds like a good next step 21:51:33 #action ignatenkobrain to package remaining cargo deps and try re-bootstrap using system libraries 21:51:44 some other useful tools? 21:51:58 maybe xi? https://github.com/google/xi-editor 21:52:24 oh boy 21:52:26 gtk-rs 21:52:41 oh wait 21:52:47 nope, gtk frontend is written in Vala 21:52:59 google.. rust.. 21:53:08 Google does ALL the things 21:53:10 breaking templates 21:53:20 maybe librsvg2 2.41 though, that needs gtk-rs 21:53:50 "This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google." 21:54:02 one of those 20% projects, I guess 21:54:06 yeah 21:54:18 librsvg2 sounds fun 21:54:33 gtk-rs is quite a lot of stuff, though 21:54:56 okay, sounds like a plan for week at least 21:54:58 though doing those opens up nice things like systemd-manager 21:55:05 https://github.com/mmstick/systemd-manager 21:55:20 wat 21:55:25 that one is new to me 21:55:52 !!! 21:56:00 this guy wrote a cargo subcommand to generate debs: https://github.com/mmstick/cargo-deb 21:56:30 well there's debcargo now too 21:56:43 is there nothing on the rpm side? 21:56:47 that's us 21:57:09 rust2rpm 21:57:20 it just happens to be written in python 21:57:23 * jistone shrugs 21:57:24 :) 21:57:31 heh 21:57:39 #topic Open Floor 21:57:50 jistone: time to rewrite rust2rpm in rust? ;) 21:58:00 rust 1.16 comes out tomorrow 21:58:15 jistone: use #info 21:58:22 #info rust 1.16 comes out tomorrow 21:58:29 aha =) 21:58:37 ignatenkobrain: that thought had occurred to me 21:59:10 mich181189: it will make bootstrap procedure too complicated 21:59:22 s/too / 21:59:29 s/too // 21:59:40 anyway, let's try to squash in 1 hour 21:59:43 yeah... but given the spec file is almost the starting point... 21:59:44 at least once :D 21:59:48 :-) 22:00:12 #endmeeting