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 haikuports/haikuports#11369), and there's a working patch to Tokio (an annexe to tokio-rs/tokio#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 tokio-rs/tokio#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 haikuports/haikuports#11502), and "Hyper-Util" (reported at haikuports/haikuports#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 (Stebalien/xattr#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 bytecodealliance/rustix#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 (nix-rust/nix#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). :)