Package up rust bindings as debs #355
Assignees
Labels
Milestone
Comments
dankamongmen
changed the title
|
This ought be a good bit easier now that we've accepted a multistage build (since moving Python out of the CMake run). We ought just be able to do standard packaging, along with some |
|
I've got the package building now in |
|
DBTS 972542 filed for the ITP. |
|
It looks like we might need package up a dependency or two:
i'm not sure exactly what's up with the |
|
Crates These are the only usages ATM (probably more when I get to finish the bindings): |
|
The actual technical part of packaging up the dependencies isn't that much of a PITA, but the social component of getting them through Debian can be. With that said, the Debian Rust team seems a good bunch of people. Let me see what I can do; keep using your preferred technical solution for now. =] |
|
OK, this week I think I'm gonna try to get the rust deps packaged up and submitted. Do you know off the top of your head if any of these four are dependent on any others within the set? |
|
libc & cty don't depend on anything here you can see the dependencies of specific crates, e.g.: BTW take a look at this: In theory only librust-libc-print-dev, librust-cty-dev, and librust-cstr-core-dev should be needed, since it seems you can create packages without providing packages for its dependencies? |
|
|
I'm filing an ITP on |
|
See #1119 -- we no longer need |
|
Well, So we're just looking for |
|
|
Yeah, I don't like to depend on it just fot the C type aliases for use with bindgen but it seems it has to be that way. It seems it doesn't work as a build-dependency like bindgen, so it must be a normal dependency. There are plans to include it as part of libc in the future, but for now it is how it is. |
|
The whole library is very tiny, we could also embed it. |
I'd rather not have to track changes upstream, and Debian/Fedora would also throw a fit (this is called "vendoring", and very strongly frowned upon). It isn't too difficult to add another rust package to Debian now that I've done one, and Fedora is working on a whole rust scheme that is not yet settled AFAICT. btw, i'm gonna be completely straight up here: i doubt that i'll be in a position to package up the rust bindings for all the distros where i manage notcurses packages, simply because rust is being handled wildly differently by different distros, and i'm not of the mood to learn FooBarQuxx Super Awesome Penguin Linux's rust techniques. the general trend seems to be towards simply submitting a crate, and having automatic packaging generated from it -- those i can obviously handle. i volunteered to package alacritty for Fedora, and had to abandon the effort, due to the difficulty of getting rust packaged up there right now. :/ |
|
To be honest I wouldn't worry very much about packaging the rust bindings... The most important thing is to package the C library... Correct me if I'm wrong but I believe having the packages would only be useful for redistributing binaries built with Rust that have a dynamic dependency on libnotcurses-sys? So Rust programs statically linked wouldn't be affected?... Rust statically links everything (except glibc) by default.... |
it is necessary for including anything using libnotcurses-sys into distros like Fedora and Debian, where you are neither allowed to vendor dependencies into your source package, nor to download things at buildtime. yes, this works very much against the workflow of recent languages like Go and Rust. |
|
Very interesting info. Then maybe supporting Debian and Fedora may be enough for now. |
|
We're now at: looks like Debian has pkg-config 3.18; I'll submit an update. likewise, they have bindgen at 0.55. update time. and i need to get that |
|
|
Hey @joseluis , we're getting some pushback on the upgrade of bindgen and pkg-config. Do you know for sure that we need the absolute newest versions? Debian ships 0.55.1 bindgen and 0.3.18 pkg-config. |
|
We can use the previous ones for sure. Sorry, I'm used to upgrading to the latest versions as a reflex but I didn't take packaging into account. It is Ok to downgrade them. |
no problem, sweet! we might very well find ourselves a debian rust package very soon, and i suspect that will be a strong positioning for the future. |
|
I'm gonna try to complete the unit tests because there are several things that aren't working for me from rust, or maybe I don't understand them well yet... I'll probably have to ask you for some more of your knowledge in the next few days. |
joseluis
added a commit
that referenced
this issue
Nov 30, 2020
|
Thanks for the quick change, @joseluis . I think we'll be able to package these up with 2.0.9/2.1.0. |
|
rust-cty passed FTPMaster approval and entered Debian Unstable yesterday evening. I'm going to test packaging of rust-notcurses 2.0.9, which i suspect will work. at that point, we can submit rust-notcurses to NEW. @joseluis i know you've done a ton of work on rust recently. would you like me to hold off to 2.0.1x/2.1.0 before submitting? |
|
I'm seeing one failure and a number of warnings. The failure arises from a missing output log (Click to expand) |
|
I don't know why it couldn't file that file, but it turns out that we don't actually need it, so we can delete it along with the cc build-dependency too! |
joseluis
added a commit
that referenced
this issue
Dec 6, 2020
I... never know when you ask me about packaging stuff :) I know I still have a lot of work to do, though... What would generally be the criteria for me to determine a need to hold off the submission? I'm just refactoring/fixing/testing/adding stuff regardless. |
|
BTW I just made collapsible the humongously long output log... |
In the words of Father Rabbit, "My lord. All the Saints and the Angel Moroni".
i don't know, threats against the person of Infanta Sofia would definitely seem out of place. don't threaten Infanta Sofia in any of your examples, if you can avoid it, and even less Leonor. if there's any of that in 2.0.9, let's hold off until 2.0.10 to package it. |
Lol, will do. And that very much reminds me about some curse words and offensive commentary in notcuses.h that I totally forgot about, and I was gonna suggest you to consider removing. Not only to avoid the possible, albeit remote, theat of islamic terrorism in the future, but because it feels a bit too much. |
hot holy shit i'd forgotten all about this. thanks for bringing it to my attention lol yeah let's target that for removal by 2.1.0. i'll set my palestinian alarm clock https://www.youtube.com/watch?v=NZkStSdlh3c |
|
|
I'll go ahead and put up a merge request =]. I don't see a notcurses.so dep specified in |
|
¡Hola mundo! |
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With #101 complete and #320 hot on the docket, we'll soon want to be building Debian crates. Once more into the big shitty breach! hax0rs ahoy
The text was updated successfully, but these errors were encountered: