<roptat>mh... my server has an issue: /var/run/knot is owned by root:root, and that prevents knot from starting. Also, /var/run/dovecot is owned by knot:knot which doesn't seem to pose any issue to dovecot
<roptat>I forcibly changed permissioned and I was able to start knot, but everytime I reboot, it goes back to that state
<the_tubular>bricewge good to know, I'll install dovecot on guix soon :)
<Guest39>Hola,si tengo rufus que debo usar para guix fat32 o ntfs ? gracias
<subaru[m]>hello, I’m new on guix. how can I install font? I try to guix install fira-code, check with “guix package - -list-installed” package is installed but ungoogle-chromium, vimb and emacs cannot recognize, are there other way to install font? I cannot found anything on the web. the one font worked is google noto all the other will not recognize by any program.
<bricewge>sneek, later tell mothacehe: Would it be possible to have RSS feed from Curiass per build history? So that a person interested in, say the "hello" package, can follow updates and failing builds of that package.
<jab55>Hey guix, very random speculative question...provided that the HyperbolaBSD project or Debian kDSB is successful, is there any interest is having a Guix BSDSystem?
<jab55>I personally prefer the Hurd, but it needs a some work. In my non-expert opinion.
<jab55>"non-expert" ---> "complete newbie and probably doesn't deserve an opinion."
<leoprikler>I think BSD kernel + GNU userland should be doable in principle, but I know no one who is actively working on it.
<dstolfa>it's doable, but you won't get all the things you'd want by default
<dstolfa>system libraries usually assume some kind of underlying kernel, not just POSIX and that's pretty much a must these days
<dstolfa>porting efforts are difficult with guix already for certain software, as it must deal with lack of FHS and the likes. adding a BSD kernel into the mix would just make it an almost impossible effort
<dstolfa>and it's not just differing system calls, it's just overall differing semantics in subtle places
<leoprikler>I don't think Guix would be as affected in terms of FHS though, given that we're the ones messing it up the most
<dstolfa>leoprikler: oh sure, it's more just a general statement of: "FHS + needing to support a kernel that doesn't have all the necessary things that most software uses" sounds like an awful time
<dstolfa>leoprikler: but mind you, it's not just guix's functionality itself, if you look at say FreeBSD ports, there are a lot of patches hanging around to make the software even compile, and often it's very stripped down from some functionality
<dstolfa>so all of the package definitions would need to be maintained differently for the *BSD kernel
<dstolfa>someone would need to either automagically pull patches from the each individual BSD's ports tree and keep it up to date, or manually maintain each and every patch and understand how each of the BSDs work
<leoprikler>And we wouldn't have too many BSD kernels flying around anyway
<dstolfa>leoprikler: the problem that would also need to be resolved are package versions. specifying a bit further to say freebsd here: the ports tree contains diffs for a lot of pieces of software (e.g. bash has 8 diffs to the source code) that work for a particular version of bash that is currently in freebsd. updating it might require updating those patches
<dstolfa>leoprikler: yes, but guix packages on linux, hurd, freebsd and openbsd would all be different versions with different patches
<dstolfa>and you'd need to have someone meaningfully maintain this or end up with severe bitrot
<leoprikler>time-machine exists, so even if bits rot, people can use old definitions while fixing things
<dstolfa>(and mind you, these patches are far from simple for some software, as they mess with things like sandboxing and kernel semantic differences that are written by people who understand the *BSD kernel they're writing it for pretty well)
<leoprikler>That's not how free software works – at least the ones implementing it have a reason to do so.
<drakonis>for good measure, you should check how large openbsd's ports tree is
<dstolfa>leoprikler: sure, but having official support for it would be iffy to say the least. it's very easy to get it wrong and end up with massive security holes
<drakonis>ie: how many patches there are for software
<drakonis>don't let me stop you though, but it is a very difficult thing
<dstolfa>if there's nobody willing to review patches to guix's freebsd packages without a good understanding of at the very least capsicum, kqueue, oss, jails and the differing semantics around read/write to different kinds of file descriptors compared to linux, it's not going to be feasible to provide the same quality that guix does on linux
<dstolfa>and it will likely end up with bugs everywhere
<dstolfa>and mind you, my dayjob for the past idk how many years has been writing freebsd kernel code, and i wouldn't dare review stuff like that alone
<drakonis>the bsds themselves might not be interested enough it guix to have a stake in maintaining code for guix
<dstolfa>the point i'm arguing is that while it would be nice to get official guix support for the BSDs, it's extremely complicated and error-prone, especially if there's no *BSD kernel developers to help do it. having an official GuixBSD with these circumstances will end delivering really bad quality software and might not be the best idea for both the perception that users might have of guix as a result, and the
<dstolfa>amount of effort that would go into it is herculean when it comes to maintaining it over time
<leoprikler>development would start far off in a wip tree anyway and if it doesn't get enough momentum and people going, that tree will just get stale
<drakonis>there is only one way for it to work and it is by somehow convincing developers/users of the given OS that it is a viable option
<leoprikler>we don't experiment with architectures on master either, do we?
<dstolfa>i just don't think this is realistic whatsoever and the only way it can exist is if the *BSD devs actually decide to do it
<drakonis>dstolfa: perhaps it is best to do any of this on a experimental branch
<drakonis>only commit to such a thing if there's enough manpower to keep it going
<drakonis>i am however not a fan of supporting hyperbolabsd only because it is a project by a gnu endorsed distro
<drakonis>it is a fools quest driven by what i could call silly notions
<dstolfa>yeah, maintenance burden is my biggest fear with all of this, along with quality and lack of expertise
<dstolfa>thousands of freebsd developers who know the ins and outs of the kernel are trying to make things work on freebsd, and it's really difficult to begin with
<dstolfa>leoprikler: btw... to be clear i'd be happy to look at patches should someone seriously consider doing this for freebsd and spread the word amongst the freebsd developers and the likes, i'm just a bit pessimistic about the whole thing because it's a massive effort that requires continuous engagement between both projects
<lhp22>oh ? Indeed, I use the right terminal, without graphical configuration
<lhp22>Oh. Ok. On the no graphic terminal, it doesn't get bold but changes the color
<lhp22>I've another question. I'vn't used Guix for months, and maybe it's why I don't understand. I login in user, and install vim. Then I unlogin, and then logit root and then `su user`, and I can't use vim. What's exactly happening on this way ?
<lhp22>[So can be that I never really understood how su work. If it comes from it, just tell me rtfm :p ]
<iskarian>(you need the profile environment variables set, so you can either directly source them from /home/user/.guix-profile/etc/profile or start a new shell as the user, which will run .bashrc and so on)
<katco>i've read in a few places that it's safe to ignore, but in my case i think this is preventing me from broadcasting to set up an AP
<lhp22>Hm. Nié ? Why $GUIX_PROFILE doesn't point on "/home/user/.guix-profile/" ?
<anadon>Hello all! Been about a year since I last made some noise.
<anadon>I'm running into two WSL2 related issues which I think could be taken into account, but would like to pass them by people here first before filing bug reports.
<anadon>The first is that during installation behind a VPN, the CA certs get messed up so all network connections fail with auth issues. It seems like bundling a certs file and using an option to use it might get around it.
<iskarian>lhp22, looks like I was wrong; even when set, that variable just refers to ~/.guix-profile
<iskarian>Anyway, is there a reason why you can't use `su - user` or `su user; bash`?
<anadon>The second is that after installation, `guix install`, `guix pull` and the like all fail because they fail to kill a process with user ID 999 with error one. There isn't any more specific information given to the user.
<lhp22>iskarian: My $GUIX_PROFILE points to '/home/user/.config/guix/current'
<iskarian>that's also valid, since that's a profile directory
<lhp22>Oh, ok, all .guix-profile are hidden in /var/
<katco>bricewge: i've tried that as well, but i get "Failed to set regulatory domain: -7"
<anadon>iskarian: From what I have tried. My testing time is limited, and I don't fully admin and manage the system so there are details about it which are tweaked that I'm not even aware of. This is the most detailed relevant information I have given my constraints.
<bricewge>katco: Can you open an issue describing waht I have tried, I don't see any related issue in the bug tracker
<katco>this is a really confusing problem. i'm unsure if the issue is that the `regulatory.db` can't be found, that `crda` fails, or that my card's eeprom is hardcoded with a country code of 00 (global) and can't be overridden
<anadon>leoprikler: manually messing with those is too much "initiation" for my coworkers. I can get around it. But here is a current difficulty to adoption to where I am. I'm more here to communicate that particular than demand a fix.
<leoprikler>of course if your container lacks certificates that would be needed for normal operation, that is also an issue (not necessarily a security one, but rather convenience), but it can be worked around in the way you noted
<anadon>Any idea on "Cannot kill process with UID 999 with error 1" when invoking `guix pull`?
<anadon>That's the step that is stopping me from using it in my workflow.
<anadon>leoprikler: I figured that one might more be an actual bug or missing feature in the installer or something. Again, I'm not actually sure so I'm asking here before filing a bug report or anything.
<anadon>leoprikler: Uhhh, let me log in and get that.
<leoprikler>on a semi-related note you did already set up your guixbuilders, right?
<iskarian>leoprikler, shouldn't the install script do that?
<leoprikler>yes it should, I'm just wondering how far it got with your other errors