Experiment - Building Rustic, on Haiku

[vmlemon]

Whilst I realise that Haiku isn't an officially supported platform, for Rustic, it recently gained a port of Rust 1.83.0 (as part of https://github.com/haikuports/haikuports/issues/11369), and there's a working patch to Tokio (an annexe to https://github.com/tokio-rs/tokio/issues/7002), that can be applied, by crowbarring the following into Rustic's Cargo.toml:

[patch.crates-io]
tokio = { path = "../Tokio7042/tokio" }
[dependencies]

(That's after applying the patch from https://github.com/tokio-rs/tokio/pull/7042, to a local copy of the Tokio repository, TAR-ing it up, and pushing it to a Haiku VM).

With those changes, I can get pretty far, in building, but it seems there's some issues, with the "Heck" library, that seem transient (reported at https://github.com/haikuports/haikuports/issues/11502), and "Hyper-Util" (reported at https://github.com/haikuports/haikuports/issues/11501), which seems to be a dependency of the WebDAV implementation, from what I can gather:

~/rustic> ./build.sh 
   Compiling hyper-util v0.1.10
   Compiling num-iter v0.1.45
   Compiling num-bigint v0.4.6
error[E0599]: no method named `with_interval` found for struct `TcpKeepalive` in the current scope
   --> /boot/home/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hyper-util-0.1.10/src/client/legacy/connect/http.rs:122:12
    |
122 |         ka.with_interval(interval)
    |            ^^^^^^^^^^^^^ method not found in `TcpKeepalive`

error[E0599]: no method named `with_retries` found for struct `TcpKeepalive` in the current scope
   --> /boot/home/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hyper-util-0.1.10/src/client/legacy/connect/http.rs:144:12
    |
144 |         ka.with_retries(retries)
    |            ^^^^^^^^^^^^
    |
help: there is a method `with_time` with a similar name
    |
144 |         ka.with_time(retries)
    |            ~~~~~~~~~

For more information about this error, try `rustc --explain E0599`.
error: could not compile `hyper-util` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

Since I'm far from fluent in Rust, and it's taken quite some effort, to even figure out how to get Rustic to build against a patched version of Haiku, I thought I'd leave this here, to track progress, in case there's any interest, in seeing this become alive.

I assume that, as a workaround, it's not possible to pass in a build flag, to disable the WebDAV/HTTP components, to push things along? :)

[Fancy2209]

This is probably more missing haiku checks in cfg metadata blocks

[vmlemon]

Looks like fixes to Tokio, and Hyper-Util have landed, in their respective master branches, but I'm unsure about when they're going to arrive in new releases, given that there's mutual dependencies involved, from what I can tell.

[vmlemon]

Looks like I can get significantly further, by adding this, to the Cargo.toml, for Rustic-RS:

[patch.crates-io]
tokio = { git = 'https://github.com/tokio-rs/tokio.git', branch = 'master' }
hyper-util = { git = 'https://github.com/hyperium/hyper-util', branch = 'master' }

Sadly, somewhere in "nix", or "rustic-core", things choke on mknod(): Not sure, if it'd be necessary, to fix it, in Rustic, itself, or the "nix" Crate, at this point...

[aawsome]

About the device id. This is indeed very platform specific:

• for macos and openbsd, it is i32
• for freebsd it is u32.
• for linux it is u64.

And there are curently platform-specifc code lines in rustic_core.

I don't know about the right type on Haiku, but most likely we have to change the rustic_core code for correct support.

BTW: Thanks a lot for your efforts to add Haiku support! Would you mind opening a PR on rustic_core once you get it compiled?

[vmlemon]

Sure. At the moment, to get this far, it's a case of adding some extra Cargo.toml lines, to use newer dependencies, from upstream Git repositories, until they get put into releases - at least the Hyper-Util fixes are awaiting packaging, but the Tokio stuff has been ready, for a while, and seems to at least enable things to build.

Extended attribute support is in a weird place, since there's technically a PR (https://github.com/Stebalien/xattr/pull/67), and Haiku has a veneer API, that's compatible with the Linux one, but I can't test it, because some of the underlying libraries aren't plumbed in (at least https://github.com/bytecodealliance/rustix/issues/1251), from what I can tell.

I did have a quick hack, that copies the FreeBSD target stanza, for the S_IFBLK/S_IFCHR stuff, but I'm unsure if it's the correct approach, given that Haiku's system headers give 64-bit stat structures, and #defines, and the "nix" stuff uses 32-bit ones (https://github.com/nix-rust/nix/issues/2586):

~/rustic_core> git diff crates/
diff --git a/crates/core/src/backend/local_destination.rs b/crates/core/src/backend/local_destination.rs
index bef3852..3ba4fe7 100644
--- a/crates/core/src/backend/local_destination.rs
+++ b/crates/core/src/backend/local_destination.rs
@@ -642,6 +642,7 @@ impl LocalDestination {
                     target_os = "macos",
                     target_os = "openbsd",
                     target_os = "freebsd"
+                    target_os = "haiku"
                 )))]
                 let device = *device;
                 #[cfg(any(target_os = "macos", target_os = "openbsd"))]
@@ -660,6 +661,14 @@ impl LocalDestination {
                         source: err,
                     }
                 })?;
+                #[cfg(target_os = "haiku")]
+                let device = u32::try_from(*device).map_err(|err| {
+                    LocalDestinationErrorKind::DeviceIdConversionFailed {
+                        target: "u64".to_string(),
+                        device: *device,
+                        source: err,
+                    }
+                })?;
                 mknod(&filename, SFlag::S_IFBLK, Mode::empty(), device)
                     .map_err(LocalDestinationErrorKind::FromErrnoError)?;
             }

I also had issues, with trying to use a patched rustic-core crate, because of "virtual manifest" problems, so I haven't gotten around to testing it, yet.

It's mostly been one of those "Let's see if it's possible" projects, given that Haiku has had a fairly-modern Rust part, for a while, and quite a lot of the dependencies already have some level of support, so the temptation to try building Rustic, and seeing what issues shake out, was there. (There's also a usability hole, in terms of having a Restic-compatible archiver, that would be nice, to fill, given that Haiku's GoLang support is absolutely ancient, so it made sense, to see how far I can get, in getting Rustic to work). :)

[vmlemon]

And, revisiting things, a few months on, using the latest nightly build of Haiku, and the latest versions of dependencies, I was kinda hopeful, that things had improved, given that most components seem to build, but no dice:

Haven't seen much sign of life, in terms of responses to issues, in prerequisites, but this project has been on the back-burner, for a long time...

[aawsome]

@vmlemon For me it seems that you could just add some modifications to rustic_core for haiku (type of device) and the reported errors will vanish. Maybe this means, that it'll already work. If you get it working, can you please make a PR? Thanks!

[sanmai-NL]

I'd always consider what delivers most value to users. The factor number of users is significant, e.g., Windows would be far more important and deserves priority over this, in my opinion.