- building a distribution consisting of packages and kernel for a Unix-like system (GNU/Linux)
- building a complete operating-system consisting of a userland and compatible applications within (BSD)

Running Guix on BSD is not possible because of the differences and their packaging-scripts are based on GNU/Linux for now, perhaps some more focus on GNU/Hurd someday? Mentioning GNU/Linux and BSD has the reasoning to be more clear about the goals both communities have. They have many things in common, but also share not everything and in some points cannot be compared in any way. So perhaps Guix could get to run onto BSD, but the repositories doesn't include applications being runnable on it this should be also kept in mind as GNU/Linux is not longer supported when HyperbolaBSD is out.
Regarding White Hole:

(source)

This is way more work incoming than creating something like Hyperguix. Creating an own package as of interest making it work, offering here for others? Yes. Needing Guix here at this distribution? Well, I have doubts about that because Hyperbola is changing towards BSD-compliant not being compliant towards Linux (without GNU) and Guix has enough freedom flaws - mentioned already here. Just because the "need for being on newer packages" I'd like to say just "No, Hyperbola doesn't need Guix then!". There are possibilities to create newer versions of packages and software already.

It is a user decision: If the user decides to run Guix? Fine then. But the distribution itself doesn't need more than one method to distribute software. There is pacman and with this reasoning back in mind flatpak was removed already: Because there are no free repositories existing for now and any repository having mixed free and proprietary licensing is just more of the known paradigm. Being strict with principles meaning being for freedom, privacy and security. Guix is mixing this and creating a method to "filter" packages is more work than just letting this package-manager out of scope. No, Hyperbola doesn't need Guix itself. If users need it, okay ... creating a package and offering here for everyone to tryout. We have the package your-freedom and creating another package for Guix including some white- and blacklist fitting is way too much. Just my point of view as user of the distribution.

In case of strange packages, the solution is so simple. You make something like hyperguix. You take instructions and if they point to a nonfree package, you throw an error. And if the package is available, you go ahead and pass that request to guix server. It's trivial guys. It's a piece of cake. You give a command like

 hguix install __ 

From what I have read Guix has no further dependencies from the installed operating-system and can run instead just with some basic packages. Meaning: Installing applications like Jami would be no further problem. Nevertheless the repositories of Guix have enough questionable packages as mentioned that have questionable licensing being not fully compliant with the principles of Hyperbola, some even are itself a security risk like Ungoogled Chromium as this project can never be free itself.

So besides getting this to run Guix has own package-repositories with questionable content. That's the reasoning to discuss from my point of view besides having another managing platform for packages besides pacman. But everyone is free to hack and modify the system for own needs and to share the knowledge for the modifications. The core team is reading here the forums as we do, so we can wait for an answer or you check out for the IRC as proposal.

Yeah, I agree with you on that, Guix does have questionable content and they don't seem to care about actual libre software...

So besides getting this to run Guix has own package-repositories with questionable content. That's the reasoning to discuss from my point of view besides having another managing platform for packages besides pacman. But everyone is free to hack and modify the system for own needs and to share the knowledge for the modifications. The core team is reading here the forums as we do, so we can wait for an answer or you check out for the IRC as proposal.

I face a very strange thing. I've installed hyperbola on a usb. I use plasma, xenocara, sddm. When I shut it down, my bootable partition isn't detected next time. I might have to use QEMU. Any help as to how to create an environment of hyperbola with QEMU? I use parabola currently.

I use lxdm, so I don't have an answer at the moment regarding why sddm makes errors.

To use PKGBUILD all steps have to fit in the end, but as mentioned: This packaging-system is handled very good and you can debug problems without further problems. Of course, precise steps needed when being finalized as this should be a running daemon on the system. I think GUIX is also mentioning nscd to be running? So this should be also noted (Link).

makedepends=(
  'bash-completion'
  'fish'
  'guile-json'
  'guile-ssh>=0.10.2'
  'help2man')
depends=(
  'guile>=2.0.9'
  'guile-git-lib'
  'guile-sqlite3'
  'sqlite>=3.6.19'
  'bzip2'
  'gnutls'
  'libgcrypt'
  'zlib')

So all packages should be installed and available. Therefore also corresponding PKGBUILD-files for creation. After the basic dependencies are available, there is GUIX in general. So I would first try to build it with "systemd" activated. Afterwards we can use the initd-configuration coming from Gentoo to recreate the package for Hyperbola.

https://git.parabola.nu/abslibre.git/tree/pcr/guix

under parabola which will be much closer to hyperbola in my view. So, how will the process go. Download source, write pkgbuild, make it, and reiterate? Give me the whole process.

PKGBUILD on the AUR

https://aur.archlinux.org/cgit/aur.git/ … ILD?h=guix

Whole package-files on the AUR

https://aur.archlinux.org/cgit/aur.git/tree/?h=guix

initd-script from Gentoo-overlays

https://data.gpo.zugaina.org/nix-guix/s … emon.initd