<drakonis>anyone has any advice on how to append arbitrary menu entries to grub? <drakonis>the current menu entry record only covers a very limited subset of grub's config options <jab46>drakonis What other feature do you need? Just curious? <jab46>is that for booting Windows? <jab46>What would you use those features? <raghavgururajan>sneek, later tell char: Arch is binary-based, whereas, Guix is source-based. Also, I just saw your DM. :) <drakonis>jab46: its for booting other operating systems <jab46>drakonis: Does guix's bootloader configuration let you boot one of the BSDs? ***Noisytoot is now known as [[
***Noisytoot_ is now known as Noisytoot
<jab46>raghavgururajan I've used the custom menut-entries to boot dual-boot guix and debian...do the custom menu-entries support booting the BSDs? <jab46>I guess I will just have to try. :) <jab46>raghavgururajan ....maybe we could write something like (apologizes for the poor syntax): <jab46>(etc-file "/ect/grub.d/40_custom (plain-file "menuentry "OpenBSD" { <jab46>Or I could just extend our grub to support chainloader +1 ***califax- is now known as califax
<zacchae[m]>Anyone here use browserpass in chromium? I've tried every install method for the browser extension, but it can never connect to the native host (browserpass-native guix package) <MysteriousSilver>How do i know the version of a currently installed packaged through the package manager? <leoprikler>if it's in another profile, you just have to use that <leoprikler>if not, then you'll have to parse some surroundings ***soheilkhanalipur is now known as Soheil[m]
***rt is now known as robin
<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 <bricewge>Wrong permissions are set at activation probably *bricewge is working on adding a "guix-configuration-channels" field to have a self-contained operating system with custom channels <lispmacs>roptat: sounds like a bug in the package definition. I see there is a list of configure-flags already used, maybe one could be added with the correct user/group...? <lispmacs>I would download the source and see what ./configure options are available <bricewge>roptat: It seems there is several bug in dovecot-service, user and group are hardcoded <bricewge>And that service change owners for /var/run/dovecot at activation <roptat>I thought dovecot and knot had a configuration option to set the user' <dstolfa>has there been any update on electron's audit? *dstolfa would really like to get electron things in guix <vldn>anyone updated sway to 1.6 or further? <vldn>guix refresh sway -r gives an error <roptat>bricewge, right, but for knot for instance, I see it creates a knot user, and in the activation script, it looks for it (getpwnam "knot") <bricewge>roptat: I've just reconfigure with a dovecot-service (for the first time), /var/run/dovecot is owned by lp <bricewge>I really don't like it when a GID don't correspond it's UID counterpart... <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. <dstolfa>subaru[m]: fc-cache -rv should fix that <vldn>how to set display drivers in guix? <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. ***mihi_ is now known as mihi
<bricewge>nckx is too fast for me, he fixed rsnapshot before I noticed! <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>e.g. `guix environment --container` and everything associated with it would instantly break on any BSD kernel <dstolfa>GNOME barely works on the BSDs due to (e)logind being difficult to support <leoprikler>you wouldn't have the expected BSD userland on any of Debian kBSD or HyperbolaBSD <dstolfa>sure, but the libc doesn't really matter if you're still lacking the underlying kernel functionality <leoprikler>perhaps, but it's the same problem with the Hurd <leoprikler>so if you have software that doesn't need those fancypants things, you could stuff it into a Hurd/BSD container or even actual machine <leoprikler>And I'm pretty sure for some people out there that'd be very fine <raghavgururajan>jab55: I was/am interested in having HyperbolaBSD as an alternative kernel in Guix. At first I was looking at LibertyBSD, but now its abandoned in favor of HyperbolaBSD. <dstolfa>one thing you'd immediately hit is that a good deal of guix functionality wouldn't work, so you'd have a very barebones guix <dstolfa>(assuming it even builds due to glibc not being fully supported on the BSDs) <leoprikler>At the very least I don't think "Oh noes, this can't run latest chromium in docker" is a good reason not to do something. <dstolfa>leoprikler: it's not just docker. `guix environment --container` with the given flags simply can't work on the BSDs the way it does on linux <dstolfa>there's no cgroups/capabilities/etc you can expose, it's completely different semantically <dstolfa>i don't know if guix uses sysfs or procfs for anything, but that would stop working too <leoprikler>Sorry, but I don't regard --container as a core feature of Guix. <raghavgururajan>Since HyperbolaBSD project rewrites certain parts of BSD's userspace and kernel, I think they might reuse some components from GNU userspace. <dstolfa>maybe not, but it's just one (obvious) example :D <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>maybe patches could be reused from the ports tree... but it sounds like a good amount of work <leoprikler>even assuming you can't patch things conditionally in the origin, you can conditionally patch in the build anyway <dstolfa>leoprikler: yes, but it's *a lot* of patches <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 <leoprikler>updating guix software already requires updating patches though? <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) <dstolfa>who's going to review 758 patches to chromium for it to run on freebsd for the version in guix, many of which are specific to freebsd kernel semantics? <dstolfa>google, and guix doesn't need 758 patches to build chromium on linux <leoprikler>Yes, defer to Google, because they're going to tell you all about the JS they vendored, the telemetry, and the other stuff if you don't make any attempt to look into it yourself. <dstolfa>i mean sure, but you don't need to be dealing with seccomp patches, sound system patches and so on <dstolfa>wide system support is always a nice and noble goal, but it's not trivial to package software for a different kernel without experts of that kernel helping <dstolfa>especially if the kernel is as massive as the BSD kernels <leoprikler>Sure, but that's assuming people would just go to implement it for no one to use <drakonis>leoprikler: it is highly non trivial to maintain patches for multiple operating systems <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 <leoprikler>but you'll need at least one person with such understanding to get things going anyway <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>I'm trying to get fun with GNU guix distrubtion, and first I was trying to customize $PS1. But i get a strange problem : is it impossible to get bold text ? \033[1m \033[0m doesn't seem to work <bricewge>lhp22: Such issu shouldn't be specific to Guix <bricewge>With alacritty the following “echo -n '\033[1mfoo\033[0mfoo'” work as expected with a first bold “foo” then a normal “foo” <lhp22>Yeah but I get it only on guix <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 ] <lhp22>Hm. This is a environment variable which contains all the installed programs ? <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) <iskarian>all of the environment variables contained in the file $GUIX_PROFILE <lhp22>hm. so, doing `su - user` makes their env variable (of this user) workign <lhp22>but indeed, $GUIX_PROFILE is a directory filled with many things <katco>does anyone know why i would be seeing `[ 8.284415] cfg80211: failed to load regulatory.db` in dmesg? i have `wireless-regdb` in my OS's packages... <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`? <lhp22>not at all, I was just investigating <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/ <anadon>If I get these working, I might be able to get traction for wider adoption of my job. <leoprikler>it's set to a guix profile only to ". $GUIX_PROFILE/etc/profile" and nothing else <iskarian>anadon, this only happens from behind a VPN? <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 <katco>bricewge: i of course don't mind opening a bug, but i don't even know what the bug is so far? if that makes sense? <leoprikler>GUIX_PROFILE isn't meant to point to any particular location, it's meant to point to the location of the guix profile you're sourcing <leoprikler>and in a typical Guix setting it takes at least 2 values during init <lhp22>That source means to be $GUIX_PROFILE or $GUIX_PROFILE/etc/profile ? <lhp22>I'm never against more informations and explanations if you're ok >.> <bricewge>katco: You can't set a regulatory domain and we both see an error message on the kernel rig buffer so at least something is off <leoprikler>in bash you'd write "source $GUIX_PROFILE/etc/profile", but the POSIX-compliant thing is to s/source/./ <katco>bricewge: ok, i'll open a bug just around the dmesg error since i would expect that to work. maybe fixing that fixes the actual issue i'm seeing <leoprikler>$HOME/.config/guix usually holds guix itself whereas $HOME/.guix-profile holds the packages installed through Guix <leoprikler>oops, should have been $HOME/.config/guix/current <iskarian>anadon: my instinct is something odd with the VPN (is it proxying? doing some sort of MiTM?) <iskarian>and as for the latter error, 999 is (or should be) the user ID of a guix build user <lhp22>leoprikler: just check on my system, and you're right. Why "usually holds" ? <leoprikler>if your VPN injects some weird certs then yeah, that's an issue <lhp22>Can be otherwise without config changements ? <leoprikler>you can do more than those two if you find it meaningful. Then $GUIX_PROFILE would e.g. also point to $HOME/my-extra-stuff/… <leoprikler>important to note is that it ought to only take one of those values at a time and the value is only meaningful during the "source $GUIX_PROFILE/etc/profile" invocation <anadon>iskarian, leoprikler: I know for a fact the VPN does inject certs, and that the Windows system has additional certs installed for the company. <leoprikler>hmm, if it's company intranet certs, than those maybe fine (albeit self-sigend, of course) <anadon>However, by specifying the env variable (something like CA_CERT_DIR) to a manually downloaded cert file provided directly from Mozilla, it worked. <leoprikler>but it shouldn't go around changing already existing certs, e.g. giving you another fsf.org <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>What ever the defaults are when using WSL2 with Ubuntu 18.04. <katco>bricewge: i think the `-7` error code might be the kernel rejecting an "unsolicited" request? `iw reg set US` works, but unfortunately doesn't solve my actual problem of broadcasting <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