readme mentions illumos/solaris but this does not seem to build #87
Comments
|
Appreciate you filing a bug report, and I am sorry My guess is, So -- how can this be made work? We can simply work around the fact illumos doesn't support a few things (xattrs aren't core functionality) with Rust's compilation targets Fixing the most immediate problem is simple, and I've created a branch for you to test: If you're still on board, the question -- is will even more complex crates build? I might test this by attempting to build two_percent, my version of |
|
I got a host I can easily try builds on so I can at least do that, I tried your branch (using: It gives the following errors: Which seems to be the same error? So maybe the two_percent on the otherhand seems to build just fine. |
|
Okay, it seems |
|
Progess! it builds now Not having much luck in it detecting zfs snapshots though, but I'll make around a bit more. At least I can manually see them in the location I think httm should be looking. I'll poke around a bit with truss later. |
|
Oh I think I see where it's getting stuck, last thing it tries is to call ZFS specific entries look like: There is no way to just get only zfs mounts unfortunately, as there is no equivalent of what |
|
Latest commit to this branch should provide for parsing this type of
This should be okay because on a non-Linux filesystem It may require trying twice as your snapshot directory automounter (as it is on MacOS) may be slower than the Linux automounter, and you may need to make sure the Good luck! |
|
Same error, but looking at it with truss I see different behavior now, so some progress! It seems to be trying to stat in |
|
Oops, my mistake. It seems mount and filesystem/dataset/device names are swapped on illumos compared to Linux and FreeBSD/MacOS? (Wow, wonder what silly Unix war that stemmed from!) See: Latest commit to this branch should provide a fix. Please redownload and try again. |
|
Yep, path and dataset/fstype/... is swapped compared to freebsd/linux. Now it just seems to hang and Ctrl-C does not stop it, SIGKILL does stop it eventually. But it seems to leave the ssh session stuck and when doing it over serial console it just makes it unsuable. It at least does seem to open the correct .zfs/snapshot dir before spewing yield() calls until killed. Edit: not using interactive mode seems to work though, I'm guessing it somehow has issues drawing the TUI. |
|
Perhaps try the fix described here for FreeBSD?: #20 Although, terminfo seems to be part of the base install?: https://illumos.org/man/5/terminfo |
|
Yes, terminfo is part of the base install and lives in Based on the truss output it does seem to load the right data: Edit: with or without TERMINFO env set explicitly |
|
I'm afraid I can't think of an obvious problem/dumb mistake on my part, from the above, but very pleased to keep working with you, if you keep digging and find more. I know If it goes any deeper than that you'd probably need to step through it in a debugger, which is probably where I would quit, but again pleased to assist, if you decide to keep pushing. I'd also be pleased to assist if you filed a bug with the illumos/Rust on illumos folks, who seem really enthused about Rust, and may be really serious about fixing bugs like this. |
|
FWIW, I do not believe it is a good idea to parse the output of As described in the mount(8) manual page, you could use On the subject of interactive mode:
@sjorge Do you have the output of |
|
@jclulow I do not, I will grab that tomorrow afterwork. |
Entirely fair. As a method, it does just work, and is fast for FreeBSD and the MacOS. I think it was a (perhaps misguided) effort to combine FreeBSD/MacOS/Linux functionality at a time when this project was younger, because MacOS may have, but doesn't use its But I'd be pleased to parse a special file for illumos, just as we do now for Linux. |
|
@jclulow the pstack |
|
Just FYI You'd probably get a much cleaner debug picture if you tried to simply run So you might try -- |
|
Another thought I had is: FYI, I ordinarily use |
|
LANG is usually Even with
|
|
I've emulated (not virtualized!) an x86_64 omnios bloody VM on my poor M1 Macbook to try to get to the bottom of this, and my conclusions are similar to yours. I can see I would push this back/down onto the |
|
At a first glance this is a bit odd: It's a bit odd that it's using select() in 2023... Not that it shouldn't work, it just makes me wonder what other unusual decisions have been made about handling the tty. In particular, if there is some bespoke code to enable raw mode or otherwise configure the tty that isn't quite right it could definitely result in the hang you're seeing. I guess tuikit is where I would look next! I'm pretty busy so it's going to take me a little while to get to it myself but I am happy to answer questions in the meantime if someone else takes a look! |
|
Another data point, I tried this again and FYI |
|
Post execution |
|
FYI, the nascent illumos support has been merged into the Unfortunately, as described, this does not include working via This also includes parsing of mounts from Took a stab at flipping some nobs yesterday which don't appear to be the problem. It's probably something along the lines of what @jclulow described: Thanks and happy hunting to anyone who is interested in tracking this down. Pleased to assist. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before you begin
Yes
README, yes, man page, no.
Sort of? I was not really expecting it to build/run.
Removing the reference to illumos (did not try on actual solaris as I have no access to that) from the README is probably OK.
Describe the bug
httm fails to build, more specifically I think (not super familiar with rust) a dependent crate. (I think xattr)
To Reproduce
Steps to reproduce the behavior:
cargo install --git https://github.com/kimono-koans/httm.git --tag 0.30.0Expected behavior
It to build as illumos was mentioned in the README
Screenshots
N/a but I have the output from cargo install
Additional context
Add any other context about the problem here. Perhaps you should include system details like:
The text was updated successfully, but these errors were encountered: