Minimal Haiku implementation

[mmuman]

This is a first try at supporting Haiku, with the minimum to compile.

[CarterLi]

Does Haiku support OpenGL, pulseaudio or something?

[mmuman]

OpenGL yes, we have our own audio framework (MediaKit)… I wanted to have something that compiles before expanding to these.

[CarterLi]

How can we know if it's running then?

[mmuman]

AFAIK this is not really used in most drivers on Linux anyway, it's here for BSD compatibility.

I'll add our own extra flags that I missed (IFF_LINK,…CONFIGURING…).

I suppose I could fake it when UP & LINK…

[CarterLi]

Thanks for your interest. Can we set up a CI to ensure it won't be broken unexpectedly?

[mmuman]

I'm not sure we can get it into the GitHub CI stuff, since we build the cross-compiler from our own build system only to generate the image…
We do have our own buildbots but they generate the official packages.

[mmuman]

Thanks for your interest. Can we set up a CI to ensure it won't be broken unexpectedly?

So I asked around, we have:

• https://github.com/korli/haiku-builder is used by various haikuarchives projects, for example https://github.com/haikuarchives/weather
• there is also a docker image that some projects like genio use: https://github.com/Genio-The-Haiku-IDE/Genio/blob/main/.github/workflows/build.yml

[mmuman]

• fixed boot time
• patch "BePC" as "i386" architecture
• add proper config dir.

[mmuman]

• fixed OS in version info
• we have a non-standard path for /etc/resolv.conf

[mmuman]

• added font support

[mmuman]

I think I picked all the low-hanging fruits, maybe we can get this in already?

[mmuman]

For the record, the JSON output: ff.json

[CarterLi]

The IFF_ string prefix in localip_linux.c should be removed. I'm ok with others.

[mmuman]

Oh right, missed that!

[CarterLi]

Thanks for your contribution. I wonder how the output is comparing to neofetch's

[mmuman]

Much fancier:

[CarterLi]

fastfetch/CMakeLists.txt

Line 1137 in 01f400c

src/detection/os/os_uname.c

This file doesn't exist. Does your code really compile?

[Begasus]

fastfetch/CMakeLists.txt

Line 1137 in 01f400c

src/detection/os/os_uname.c

This file doesn't exist. Does your code really compile?

That should be os_haiku.c, I think @mmuman used the nightly version for this, on R1B5 64bit I still need to apply a seperate patch for pipe2 and memmem.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1a8b39d..9435569 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1607,6 +1607,7 @@ elseif(Haiku)
     target_link_libraries(libfastfetch
         PRIVATE "network"
         PRIVATE "be"
+        PRIVATE "gnu"
     )
 endif()
 
diff --git a/src/common/processing_linux.c b/src/common/processing_linux.c
index 63d3951..02d3bf8 100644
--- a/src/common/processing_linux.c
+++ b/src/common/processing_linux.c
@@ -34,7 +34,7 @@ enum { FF_PIPE_BUFSIZ = 8192 };
 
 static inline int ffPipe2(int *fds, int flags)
 {
-    #ifdef __APPLE__
+    #if defined(__APPLE__) || defined(__HAIKU__)
         if(pipe(fds) == -1)
             return -1;
         fcntl(fds[0], F_SETFL, fcntl(fds[0], F_GETFL) | flags);
-- 

[CarterLi]

@Begasus Please test the newest commit

Some issue I found from your screenshot

1. Seems the monitor name isn't available on current version
2. The terminal name is wrong. I think ffProcessGetInfoLinux and ffProcessGetBasicInfoLinux in processing_linux.c lack a proper implementation for Haiku
3. The ifa name in Haiku is a device path?
4. fastfetch should report R1B5 instead of 1

[Begasus]

Thanks so far! Looks promising (mind you I'm no developer, @mmuman is the real one :)

No patching with master checkout:

[mmuman]

fastfetch/CMakeLists.txt

Line 1137 in 01f400c

src/detection/os/os_uname.c

This file doesn't exist. Does your code really compile?

Oops, thought I replaced it with the haiku one, that was a test.

[mmuman]

1. Seems the monitor name isn't available on current version

The code is there but the API returns an error, so either it's not implemented at all, or at least on VESA mode.

2. The terminal name is wrong. I think ffProcessGetInfoLinux and ffProcessGetBasicInfoLinux in `processing_linux.c` lack a proper implementation for Haiku

That can probably be fixed.

3. The ifa name in Haiku is a device path?

For most network interfaces yes, for historical reasons.

4. fastfetch should report `R1B5` instead of `1`

Yes, I didn't find an easy way to find that yet, we'd have to dig the resources in the kernel file or something.

[Begasus]

Quick check on a 32bit laptop :)

PS, is there some color switch mode? Terminal with white background doesn show the logo too wel.

[CarterLi]

--bright-color false may help. If the terminal reports $COLORFGBG, fastfetch will detect whether the terminal is in light mode and set --bright-color false by default

Alternatively, we may set

fastfetch/src/logo/builtin.c

Line 2011 in 8774fb3

FF_COLOR_FG_WHITE,

to FF_COLOR_FG_DEFAULT, so that fastfetch will use black color in light mode.

[Begasus]

to FF_COLOR_FG_DEFAULT, so that fastfetch will use black color in light mode.

That worked, --bright-color false didn't do the trick.

[jmairboeck]

Usage of pkg and pkgsrc here doesn't really make sense. These are the same kind of packages (Haiku packages, "hpkg"), but rather system packages and user packages, respectively.

I see that there is such a distinction already for other packaging systems (e.g. for flatpak here). So I think it would make sense to add haikuSystem and haikuUser there as well.

[mmuman]

Yes, I just used that because I wasn't sure how it was categorized, but that'd be better.
Ideally we'd query the Package Kit because some packages could be disabled.

[mmuman]

Hmm the newest commits fail to build on 32bit…

[Begasus]

437006f still builds here on R1B5 32bit.