dimo414
Get bkt into the major package managers
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.
- [x] Arch / Pacman
- [x] Debian /
apt-get - [x] FreeBSD /
ports - [x] macOS / Homebrew
- [x] NetBSD /
pkgsrc - [x] NixOS
- [x] Void / XBPS
@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
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 😄 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.
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.
@dimo414 E.g., I know that firefox spits quite a few harmless errors so, I'll use it as an example.
$ bkt --ttl=30min --cwd -- 'firefox91'
will produce a log which I can look at later in /tmp/bkt-0.5-cache/data
Hah alright, that is a bit more unusual :) Happy to chat about it more in a discussion if you'd like to post one.
@dimo414 Forgot to reply. Do you think what I'm doing is wrong? Of course /tmp is cleared upon reboot but, I could re-direct it to a more permanent location.
Not necessarily, though it's somewhat unexpected that a user would manually access the cache directory. Happy to discuss it further but I'm going to hide these comments to keep this issue on-topic.
I've just packaged bkt for FreeBSD: https://cgit.freebsd.org/ports/commit/?id=6f16c9c835c7c33e302e5e2b2a559a00d210944d
- [x] 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
Wow, that's some cool timing! I just began work packaging bkt for Debian almost exactly when you made that comment.
Maybe we can convince @alexmyczko to create a Homebrew receipe :stuck_out_tongue_winking_eye:
Homebrew formula is here: https://github.com/Homebrew/homebrew-core/pull/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.
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
@benthetechguy just curious if you had any luck getting bkt packaged for Debian?
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.
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. 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).
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 😨
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 bkt to Void Linux: https://github.com/void-linux/void-packages/pull/36124
Hah that's a bummer, @tranzystorek-io swapped us to clap 3 in https://github.com/dimo414/bkt/pull/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.
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.
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.
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?
Yeah, it is. I'd wait a bit before changing anything too much, though; It's possible that if you wait a little bit we'll have clap 3 in Debian. As mentioned previously, we've had a hint that clap 3 is around the corner, and I'm awaiting a response from the maintainer for a status report.
Nice, the serde version drop also bumped up the autocfg version, which fixes an issue in Void CI when building cross targets 🎉
Good news, clap 3 is now in Debian. This means I should be able to package bkt, and provided someone's there to sponsor the upload, get it into Debian!
It seems that the derive feature is missing from Debian's clap. I will investigate the cause for this. In the meantime, in case getting derive is a no-go, how important is it to bkt?
I rewrote all clap v2 parsing into clap derive to make the code more readable and concise, going back to the builder API is a step backwards. 😐
Ofc, we can also just switch back to structopt as I mentioned before.
When they get back to me on what the deal is with derive, I'll see what our options are. There has to be a reason they disabled it.
@dimo414 I'm not sure if this is worth the time but in the Void CI the tests sometimes fail, somewhat nondeterministically: https://github.com/void-linux/void-packages/runs/5711656703?check_suite_focus=true
Good news and bad news. The good news is that I have solved the clap_derive issue and it will be in Debian soon. The bad news is that there are problems with test_dir. The code is quite outdated and has some problems compiling in Debian's setup. Can we do without test_dir, or is it absolutely needed for bkt?
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 😄).
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.
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.
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.
@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.
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
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)