-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get bkt into the major package managers #12
Comments
Now packaged for Arch: https://aur.archlinux.org/packages/bkt/ |
Thanks a lot @thiagowfx! And props for your nice writeup as well. |
… link from fzf, pretty cool that it seemingly "just works".
@dimo414 FYI, I've just packaged and merged This means Regards |
Thank you very much! It looks like it's already showing up in the README :) |
Thank you for this tool. I'm using it in a slightly unconventional way, though 😄 Yeah, if you pulling the info from repology, it will mostly be up-to-date. |
Hey that sounds like a pretty reasonable use case to me :) If you'd like to share how you're using |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I've just packaged
FreeBSD users can now install the port by building: cd /usr/ports/sysutils/bkt
make install or install the package: pkg install bkt EDIT: Added installation instructions |
Wow, that's some cool timing! I just began work packaging |
Amazing, thank you @ehaupt! And thank you in advance @benthetechguy :) |
Maybe we can convince @alexmyczko to create a Homebrew receipe 😜 |
Homebrew formula is here: Homebrew/homebrew-core#95407 However, that won't be merged by their maintainers until it passes their popularity test (error message: |
The Homebrew PR merged:
|
Thanks a lot @zbentley! |
@benthetechguy just curious if you had any luck getting |
The way Debian does rust packaging is kind of confusing. The source code of all the dependencies and their dependencies need to be packaged so they can be compiled at build time of the program. |
Dang, I did not know that. What dependencies are you having trouble with? I'm not opposed to dropping/swapping dependencies that are a pain. Thank you for digging into this! |
It would help if the clap dependency was 2 instead of 3; the person who's working on clap is having a hard time when it comes to upgrading our version of clap to 3. |
So they did this in the end, I remember reading the discussion about it but, never checked back on the decision. Is Debian doing the same with Go modules? I just hope this idea doesn't spread, it might be the most correct way of packaging but, it's unsustainable, it uses a huge amount of resources and must be a nightmare for package maintainers. E.g. I keep ~ 70 Rust packages up-to-date on pkgsrc, some with a really long list of crate dependencies, IRC the largest one has 520 crate dependecies, that would be 36 400 packages to keep track of, in case all of them were the same size, which is not the case of course. In any case, keeping my fingers crossed that this remains a Debian only thing 😨 |
Hah that's a bummer, @tranzystorek-io swapped us to clap 3 in #1. We can definitely remove the patch version from serde-json. |
I've started the process to add |
…ckaging for Debian (#12). Also refresh Cargo.lock.
That's good about serde-json. Can anything be done about clap? Are those features relying on clap 3 an integral part of the codebase? If so, it'll probably take much longer as we'll have to wait for the Debian clap maintainer to finish clap 3. |
I'm hesitant to revert back to clap 2 simply because we already went through the trouble to upgrade, but I'm curious what @tranzystorek-io thinks. My impression is there's sufficient wind behind clap-3's sails that a Debian release can't be that far behind, but I'm not well informed on the matter. Is there a tracking issue or more context you can point to wrt clap-3 on Debian? |
#debian-rust on OFTC is where all the discussion happens, and the work being done is on this repo. |
Reverting to pure clap 2 would indeed be counterproductive and non-trivial. That said, we could switch back fairly easily to structopt which relies on clap 2. @benthetechguy I'm guessing structopt is available on the debian side already? |
I can definitely swap off test_dir to something else if needed, it's just used to simplify the test setup. I asked the crate maintainer if they can release an update and if not we can drop that dependency. |
Perfect, thanks. I was worried because it seemed to be everywhere in the code. I'm not experienced with Rust itself, so I'm not good at seeing how important something is outside of the size of the code itself.
When I get access to my machine again, I'll post the exact error(s) I'm getting in the issue you linked above.
|
Yeah it's used in pretty much every test, but it's not compiled into the production binary. You can see that because it's under dev-dependencies (if you know Rust of course 😄). |
Yes, Debian requires dev-dependencies for autopkgtests. |
Right sorry, I was just saying it doesn't impact the behavior of the binary itself, meaning to imply that makes it relatively easy to swap out if needed. |
I think we might need to end up doing that. The maintainer of test_dir doesn't seem to be very active. |
Published 0.5.4 |
Thanks. bkt should now be ready for Debian packaging as soon as someone uploads clap_derive and clap. P.S: You don't need to make a new release every time you change dependencies; we can and will patch trivial things. |
I have created a package if anyone wants to test: bkt_0.5.4-1_arm64.deb.gz EDIT: just realized that this package is arm64 since I've been doing all this on my Pinebook Pro. I will build an amd64 package if anybody really needs it between now and when bkt is actually uploaded and accepted into Debian. |
@benthetechguy I'd like to review a debian source package, if someone would like to have it officially in Debian (well I would like so) |
It's a bit complicated for Debian Rust packaging. Information is available at https://salsa.debian.org/rust-team/debcargo-conf |
Dependencies were uploaded by @sylvestre about a week ago, and all but one just made it through the queue a couple hours ago. Since the dependencies are pretty much done, this means that bkt itself should be ready for upload as soon as everything clears. |
Last dependency just cleared 🥳 |
After a month, a Debian Member finally bothered to upload bkt, and it has now been accepted into Debian unstable. If there are no bugs, it should migrate to testing after a couple days. |
Thanks for the update! That link seems broken now, did it get rolled back? |
It seems that the autopkgtests have failed due to a dependency that hasn't yet gone through the upload queue. This should resolve itself after a few days.
You can already install bkt on amd64 on Debian unstable: https://deb.debian.org/debian/pool/main/r/rust-bkt/bkt_0.5.4-1_amd64.deb
|
It seems like bkt is still stuck in unstable, perhaps because of the flaky test tracked in #14? I've just disabled that test for the time being, in case that's helpful. |
Aaaand we're on Void now! (Took the liberty of disabling that one test in CI) |
Neat, thank you! |
NixOS packaging would also be nice! |
@benthetechguy do you happen to know what's needed to get bkt out of Debian unstable? Also FYI to everyone who is so kindly maintaining packages, I plan to cut a 0.6.0 release in the next few days. |
Not sure but fixing this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026801 And no worries, people can request a backport of it... |
@alexmyczko sorry I missed your reply; I think that failure has been resolved by 61da09a. If it hasn't it would be great to report an issue here, ideally with reproduction steps, since I don't see bug reports submitted against Debian. |
Hi,
Sorry for my long inactivity. I've been busy with school and haven't had
time to work much on bkt packaging or Debian as a whole. I haven't used
bkt for a while now and thus no longer have much of a motivation to work
on its packaging, so I would much appreciate if someone else would adopt
the package.
Since it's already part of the Rust Team, you don't have to do anything
special apart from adding yourself to the Uploaders list in
debcargo.toml (feel free to also remove me). I think most of the hard
work is done and all you have to do to get this package to migrate
properly to testing and stable from there is to update to the latest
version. Unfortunately, since we are only a few weeks away from the
release of Debian 12 Bookworm, it doesn't seem like the new version
would make it in time to reach the stable release of Debian.
Thanks and sorry again!
|
i have requested BPO of bkt in #debian-rust (simple sid backport works fine for me) |
bkt is now packaged for trixie: https://packages.debian.org/trixie/bkt |
That's great to hear, thank you so much! |
Alpine request here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15731 |
I don't have much experience with this, but filing a bug to keep track of this over time. Package managers to consider: https://github.com/junegunn/fzf#using-linux-package-managers.
apt-get
ports
pkgsrc
The text was updated successfully, but these errors were encountered: