Get bkt into the major package managers

[dimo414]

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.

• Arch / Pacman
• Debian / apt-get
• FreeBSD / ports
• macOS / Homebrew
• NetBSD / pkgsrc
• NixOS
• Void / XBPS

[thiagowfx]

Now packaged for Arch: https://aur.archlinux.org/packages/bkt/

[dimo414]

Thanks a lot @thiagowfx! And props for your nice writeup as well.

[0323pin]

@dimo414 FYI, I've just packaged and merged bkt into the main pkgsrc branch.
See, https://mail-index.netbsd.org/pkgsrc-changes/2022/02/01/msg248020.html

This means bkt is now available for NetBSD users and users of other supported platforms, https://www.pkgsrc.org/#index4h1

Regards

[dimo414]

Thank you very much! It looks like it's already showing up in the README :)

[0323pin]

Thank you for this tool. I'm using it in a slightly unconventional way, though 😄
I'm setting the time to few minutes and launching troublesome programs to catch why and when they crash or segfault.

Yeah, if you pulling the info from repology, it will mostly be up-to-date.
I say mostly because we use cvs and the git-repository is just a mirror. Repology pulls information from git and it can be a delay of up to one day. So, don't worry if you make a new release and it takes a day or two to be marked as updated, that's normal.

[dimo414]

setting the time to few minutes and launching troublesome programs to catch why and when they crash or segfault.

Hey that sounds like a pretty reasonable use case to me :) If you'd like to share how you're using bkt in more detail in https://github.com/dimo414/bkt/discussions/categories/show-and-tell it might inspire other or help me plan future features.

[ehaupt]

I've just packaged bkt for FreeBSD: https://cgit.freebsd.org/ports/commit/?id=6f16c9c835c7c33e302e5e2b2a559a00d210944d

• FreeBSD / ports

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

[benthetechguy]

Wow, that's some cool timing! I just began work packaging bkt for Debian almost exactly when you made that comment.

[dimo414]

Amazing, thank you @ehaupt! And thank you in advance @benthetechguy :)

[ehaupt]

Maybe we can convince @alexmyczko to create a Homebrew receipe 😜

[zbentley]

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: GitHub repository not notable enough (<30 forks, <30 watchers and <75 stars)), so it's in draft for now.

[zbentley]

The Homebrew PR merged:

zac.bentley@ZacBentleyMBP ~ ∴ brew update; brew install bkt
==> Pouring bkt--0.5.2.monterey.bottle.tar.gz
🍺  /usr/local/Cellar/bkt/0.5.2: 7 files, 1.3MB
zac.bentley@ZacBentleyMBP ~ ∴ bkt
error: The following required arguments were not provided:
    <COMMAND>...

USAGE:
    bkt [OPTIONS] [--] <COMMAND>...

For more information try --help

[dimo414]

Thanks a lot @zbentley!

[dimo414]

@benthetechguy just curious if you had any luck getting bkt packaged for Debian?

[benthetechguy]

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.
I had the actual packaging of bkt done an hour after I made my initial comment, but there's still work going on to package all the dependencies and get them uploaded into the Debian archive, which can take a few weeks.

[dimo414]

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!

[benthetechguy]

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.
It would also be useful to generalize the serde_json dependency to 1.0 (or at least something a bit older like 1.0.45).

[0323pin]

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.

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 😨

[dimo414]

Hah that's a bummer, @tranzystorek-io swapped us to clap 3 in #1. We can definitely remove the patch version from serde-json.

[tranzystorekk]

I've started the process to add bkt to Void Linux: void-linux/void-packages#36124

[benthetechguy]

Hah that's a bummer, @tranzystorek-io swapped us to clap 3 in #1. We can definitely remove the patch version from serde-json.

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.

[dimo414]

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?

[benthetechguy]

#debian-rust on OFTC is where all the discussion happens, and the work being done is on this repo.
There is one interesting thing happening, however. A package rust-clap-2 was just uploaded to Debian a few minutes ago. When a package is upgraded but others still depend on the old version, this can happen. The uploading of rust-clap-2 is a hint that rust-clap will be upgraded to 3 in the near future. This gives me hope.
I've just asked what the current status of clap 3 is.

[tranzystorekk]

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?

[dimo414]

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.

[benthetechguy]

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.

[dimo414]

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 😄).

[benthetechguy]

Yes, Debian requires dev-dependencies for autopkgtests.

[dimo414]

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.

[benthetechguy]

I think we might need to end up doing that. The maintainer of test_dir doesn't seem to be very active.

[dimo414]

Published 0.5.4

[benthetechguy]

Thanks. bkt should now be ready for Debian packaging as soon as someone uploads clap_derive and clap.
The reason things are often outdated in Debian is because so much time is spent waiting around for someone to bother to upload something ;)

P.S: You don't need to make a new release every time you change dependencies; we can and will patch trivial things.

[benthetechguy]

I have created a package if anyone wants to test: bkt_0.5.4-1_arm64.deb.gz
It's compressed with gzip because for some reason GitHub only allows certain file types to be uploaded and this is one of them.

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.

[alexmyczko]

@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)

[benthetechguy]

It's a bit complicated for Debian Rust packaging. Information is available at https://salsa.debian.org/rust-team/debcargo-conf

[benthetechguy]

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.

[benthetechguy]

Last dependency just cleared 🥳

[benthetechguy]

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.
https://packages.debian.org/sid/bkt

[dimo414]

Thanks for the update! That link seems broken now, did it get rolled back?

[benthetechguy]

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

[dimo414]

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.

[tranzystorekk]

Aaaand we're on Void now! (Took the liberty of disabling that one test in CI)

[dimo414]

Neat, thank you!

[thiagowfx]

NixOS packaging would also be nice!

[dimo414]

@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.

[alexmyczko]

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...

[dimo414]

@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.

[benthetechguy]

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!

[alexmyczko]

i have requested BPO of bkt in #debian-rust (simple sid backport works fine for me)

[alexanderkjall]

bkt is now packaged for trixie: https://packages.debian.org/trixie/bkt

[dimo414]

That's great to hear, thank you so much!

[yonas]

Alpine request here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15731

[thiagowfx]

Alpine: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68650