Debian Packaging #2
Comments
|
The question is how to create .dsc package? |
|
I think the "dsc" file is just a metadata file that has package information (checksums, etc.) looking at this guide https://wiki.debian.org/SimplePackagingTutorial And you can see an example in this repository: https://github.com/trevorsandy/lpub3d/blob/master/builds/linux/obs/debian/lpub3d.dsc The instructions for the simple packaging tutorial seem pretty straight forward, but I'll let @yarikoptic weigh in. |
|
|
|
If you haven't already, you should contact the people from https://wiki.debian.org/Teams/RustPackaging |
|
okay I posted to the list, here https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-October/007819.html and got a response quickly! https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-October/007820.html You can read the response in detail, but in summary:
https://gist.github.com/vsoch/af0d7533775e3c21418e6b8a6a3825bd Also note that I ran the command And directly from the response - the other challenges we'd run into:
So - thinking / looking this over, I think we could try to tackle this now, and it would be huge amounts of work to first add all these other projects, but more realistically if we just wait some time for the ecosystem to develop, the dependencies will be available as packages, and perhaps a stable version will exist that doesn't require a beta release. Thoughts? This isn't blocking anyone from developing or using rust - there are containers available along with the ability to hack around locally. My thinking is that the best strategy is to wait, and then come back when nu doesn't need a beta rust, and cargo-debstatus doesn't return (mostly missing) packages. |
As is noted in the e-mail, both issues are bound to resolve. 1.39.0 release will happen on Nov 7, 2019, so in precisely three weeks, while futures 0.3.0 will likely have a release around that time as well: rust-lang/futures-rs#1893 |
|
Great! So @est31 should we put a TODO to take a look on November 8th? |
|
Hi :) How are we doing here? @vsoch @yarikoptic |
|
Also please read - even with the rust release it may be there are too many dependencies not packaged yet to do. #2, and time might be the best asset here. Note that I'm not an experienced debian maintainer (I know pretty much nothing) but I'm feeling out as I go! |
When I said that there will be a release on November 7th, I meant the upstream release, not the release in Debian. Not sure when it'll be in Debian. Debian unstable still has 1.37.0 and 1.38.0 is needed in Debian before it can upgrade to 1.39.0. |
|
Debian unstable now has 1.39.0: https://packages.debian.org/unstable/rustc. |
|
okay I'm running the command again, the steps I took are:
cargo-debstatus debstatusfrom the root of the repository, and the updated output is here: There are still quite a few outdated - is this something we can take any kind of action on? @yarikoptic |
|
Of course there are some possible actions. For example, shows subprocess needs to update crossbeam-utils dependency. Looking at subprocess repository, this is already done, just not released. When it is released, nu can update subprocess dependency, etc. It is somewhat daunting to go through the long list, but I think there is no way around it. Good news is that it is finite. |
|
@sanxiyn could you explicitly state what you are suggesting that we can do? To go through the list, one by one, check the output and then package.. and then what? |
|
@yarikoptic @sanxiyn and @est31 I'd like to help as much as I am able - can we choose one of the libraries that isn't on debian, and together walk through how we would package? If I am able to help with a single external dependency, then I can slowly work through some of the others, and at least get us closer. |
|
Hi @vsoch - has this progressed since? It's been almost 1 year and a half, hopefully by now the adoption of the Rust ecosystem within Debian is much better. |
|
I'm not working on it actively, so no. I just tried to install cargo-debstatus to generate another tree to look at, but it no longer compiles on my system. Maybe someone else can give it a shot? I opened the issue to express the next but I am not a debian developer nor do I have the expertise with rust to be able to really take charge of it. |
|
cargo-debstatus still builds on my system (rust 1.52.1 on Arch Linux) but I had trouble keeping up with cargo development and it has never been properly ported to the new Packaging the rust ecosystem in debian is quite labor-intensive (both getting the packages in and maintaining them afterwards) and there are requests by the debian ftp-master team that haven't been implemented due to lack of volunteer time. Uploads are being processed again though and there are still people working on rust packaging in #debian-rust on oftc. Merge requests can be sent to this repository https://salsa.debian.org/rust-team/debcargo-conf/, the readme contains instructions on how to do that (though, granted, there's no intro text but running the commands Debian is currently in freeze for the next release, if you're planning to do non-trivial uploads you might want to wait until debian bullseye has been released. |
|
This issue is being marked stale because it has been open for 30 days without activity. If you feel that this is in error, please comment below and we will keep it marked as active. |
|
If someone is interested in working on this, please let us know. We would be happy to coordinate to work on an official package. |
|
This issue is being marked stale because it has been open for 90 days without activity. If you feel that this is in error, please comment below and we will keep it marked as active. |
|
This issue has been marked stale for more than 10 days without activity. Closing this issue, but if you find that the issue is still valid, please reopen. |
|
Should this be reopened? Just to advertise that help packaging is still wanted |
|
I took a little time to play around with this here https://github.com/Inveracity/nushell-debian-package I'd be happy to collaborate on this |
|
@Inveracity Thanks for investigation. PRs are welcomed. and we can test it in nushell/nightly repo |
|
If you get something completed, you should reach out to the Debian Rust maintainer group. They have picked up a few things recently, https://qa.debian.org/developer.php?email=pkg-rust-maintainers%40alioth-lists.debian.net (I did not check if there is already an open issue, there might be already) |
I've focused my attention on packaging the prebuilt binary, is that still a good fit for the Debian Rust maintainers? |
It is definitely for shipping binary crates - but all dependencies also need to be in the repo so there are a lot more library crates than final binaries. (I believe dependency resolution is what makes the upstream packaging so difficult, since sometimes overrides need to be done by hand) . But binaries like Config for the debian repositories happens via |
|
I see, thanks for the information! For the time being my personal motivation is being able to install nushell with apt, either through a PPA hosted via nushell.sh or via package-cloud or otherwise. I hope my PR is enough to at least get the wheels turning for an eventual I will leave the crate packaging up to someone who is more experienced in the rust eco-system 😄 |
|
As already pointed out by @tgross35, all crates nu depends on need to be uploaded to Debian first, before you can upload a To get a status report you can run cargo-debstatus on nu and get something like this (I can not post the full output because it's about 2 MB of text and I could not find a pastebin that allows me to paste this much text): Some crates that do not have Nu is in itself split in many small crates, merging this back into fewer crates (like tokio did) would help with packaging. The amount of crates nu itself is split into is also the reason the If you're interested in helping out you can pick any crate from this tree that has all its dependencies already marked with |
|
maybe this issue can be moved to https://github.com/nushell/integrations? |
|
Would adding the package to the MPR be a short-term solution? |
…#13131) # Description Closes: #13010 It adds an additional check inside `parse_string`, and returns `unbalanced quote` if input string is unbalanced # User-Facing Changes After this pr, the following is no longer allowed: ```nushell ❯ "asdfasdf"asdfasdf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #1:1:11] 1 │ "asdfasdf"asdfasdf · ────┬─── · ╰── invalid characters ╰──── help: Try removing them. ❯ 'asdfasd'adsfadf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #2:1:10] 1 │ 'asdfasd'adsfadf · ───┬─── · ╰── invalid characters ╰──── help: Try removing them. ``` # Tests + Formatting Added 1 test
…#14385)
# Description
As title, this pr is going to deprecate `--ignore-shell-errors` and
`--ignore-program-errors`.
Because I think these two flags makes `do` command complicate, and it
should be easy to use `-i` instead.
# User-Facing Changes
After the pr, using these two flags will raise deprecated warning.
```nushell
> do --ignore-program-errors { ^pwd }
Error: × Deprecated option
╭─[entry #2:1:1]
1 │ do --ignore-program-errors { ^pwd }
· ─┬
· ╰── `--ignore-program-errors` is deprecated and will be removed in 0.102.0.
╰────
help: Please use the `--ignore-errors(-i)`
/home/windsoilder/projects/nushell
> do --ignore-shell-errors { ^pwd }
Error: × Deprecated option
╭─[entry #3:1:1]
1 │ do --ignore-shell-errors { ^pwd }
· ─┬
· ╰── `--ignore-shell-errors` is deprecated and will be removed in 0.102.0.
╰────
help: Please use the `--ignore-errors(-i)`
/home/windsoilder/projects/nushell
```
# Tests + Formatting
NaN
# Description Before this PR, `length` did not check its input type at run-time, so it would attempt to calculate a length for any input with indeterminate type (e.g., `echo` which has an `any` output type). This PR makes `length` only work on the types specifically supported in its input/output types (list/table, binary, and nothing), making the behavior the same at parse-time and at run-time. Fixes #14462 # User-Facing Changes Length will error if passed an unsupported type: Before (only caught at parse-time): ```nushell "hello" | length Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry #2:1:11] 1 │ "hello" | length · ───┬── · ╰── command doesn't support string input ╰──── echo "hello" | length # => 1 ``` After (caught at parse-time and run-time): ```nushell "hello" | length Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry #22:1:11] 1 │ "hello" | length · ───┬── · ╰── command doesn't support string input ╰──── echo "hello" | length Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #23:1:6] 1 │ echo "hello" | length · ───┬─── ───┬── · │ ╰── only list, table, binary, and nothing input data is supported · ╰── input type: string ╰──── ```
I reached out to @yarikoptic about proper Debian packaging (I've never done it!) and he has shared his wisdom! Here is his proposal for going about this:
This doesn't really afford a complete GitHub or general CI release cycle, and for this reason we can definitely provide the Docker build, but maybe we should also try to do this proper? Thoughts?
The text was updated successfully, but these errors were encountered: