<ArneBab>yes, /usr/bin/ is a read-only filesystem: it’s lrwxrwxrwx 1 root root 32 9. Jan 2019 /usr/bin -> /run/current-system/profile/bin/
<reepca>ArneBab: in that case you should probably modify your /etc/config.scm to remove the recently-added service that provides /usr/bin/env as a symlink, since you're already doing something similar.
<ArneBab>reepca: I searched for a service which does that, but did not find any.
<ArneBab>herd status also does not list the special-files-service
<refpga>Hello, is adding the openssh-configuration with relevant arguments to the /etc/config.scm sufficient to setup an openssh server? I'm not able to log into the system (using password login) still (error: Connection refused). There seems no option to start at boot.
<ArneBab>civodul: does a system upgrade fail if one step fails?
<refpga>roptat: I'm having trouble with where to declare it using (user-group). Do I add it like (user-account ... (user-group (name "foo")))? But that gives an error. The problem is supplementary-groups is accepting a list of strings (of names).
<jonsger>civodul: the problem are missing rust crates for rust-cbindgen and I don't know how many are still left
*rekado packaged the Festival speech synthesizer; it’s so much fun!
<rekado>and it’s got a Scheme-like interactive mode.
<roptat>refpga, no, in your operating-system declaration, add it to the "groups" field like this: (operating-system ... (groups (cons (user-group (name "foo")) %base-groups) (users (cons (user-account ...))) ...)
<kdtsh>Hi all, I've done something to break my Guix System install ... when I try to do a reconfigure, I get a message like 'activating system...' and then 'guix system: error: error parsing derivation `/gnu/store/[...]-switch-to-system.scm.drv': expected string `Derive(['. I took a look at this file and it exists but is empty. I've looked at another
<kdtsh>installation I've got of Guix System in a VM on a different box and there's no file like this in the store. Does anyone know how I can get out of this mess?
<kdtsh>At this point, I can switch between existing generations, and 'guix system build [config]' works, but I can't use 'guix system reconfigure'
<kdtsh>I've just run it and I got a couple of lines like 'reading the store...' and 'checking path existence...' and then I return to the prompt. However, I've just done a guix pull and I'm trying a reconfigure again. I've also done an `ll /gnu/store/*switch*.scm.drv` and there are about 18 files (nearly corresponding to the number of generations I have -
<kdtsh>I have 20 currently), all but one of which are 1258 bytes in size
<kdtsh>**since I'm currently doing a reconfigure I don't know if this would impact the output of the guix gc --verify command
<civodul>can you try "guix gc -D /gnu/store/....-switch-to-system.drv"?
<reepca>civodul: any idea why addTempRoot() in nix/libstore/gc.cc bothers with the looping to check if its temp-roots file got deleted instead of just waiting to remove the gc lock until after the temp-root lock has been acquired? My first guess would be deadlock issues, but the gc always acquires the gc lock prior to acquiring the temp-root locks. It looks like an obvious improvement, so I'm highly suspicious that I'm missing something.
<rekado>roptat: what do you think about adding speech synthesis support to our installer?
<nckx>sneek: what is sure thing! I've done that just now; guix system reconfigure?
<sneek>I could be wrong, but Sure thing! I've done that just now; guix system reconfigure is still running and guix-system is building, it's taken about 10 minutes and it's on ~70% so I'm hoping it finishes up soon
<efraim>jonsger: cbindgen has a lot of dependencies. The recursive importer is fine for starting a package, but to actually upstream we need serde and rand as intermediate packages which is going to take a while
<efraim>I have some more ready for upstreaming, 'guix import crate foo@version' has been great
<civodul>reepca: hmm i think there's a time window during which the file fnTempRoots could be removed by the GC, before it has been locked
<reepca>civodul: but if we have a read lock on the GC, AFAIK it can't remove it. readTempRoots() is called in exactly one place, during which a write lock on the GC lock is held. So if we have a read lock, it can't be called.
<jonsger>efraim: I already have a lot of crates, some taken from gn/packages/crates-io.scm others are imported by myself
<efraim>ah good, was going to suggest gn/packages/crates-io
<jonsger>the problem is the amount of packages. It's now at something over 50+ compared to upstream...
<efraim>I have almost 400 in gn/packages/crates-io
<jonsger>"my" crates-io for Thunderbird growed to 250...
<kdtsh>civodul that seemed to work by the way - my guix system is working again, I was able to complete the reconfigure and it's looking fine now. I'll keep that trick in mind to garbage collect the switch-to-system drv if it's corrupted
<kdtsh>civodul that is probably exactly the reason, I've had a couple of crashes along the way here
<kdtsh>I'm actually having some issues viewing man pages which could be related. when I run `man ls` for example, I get an error like `man: command exited with status 255: (cd /run/current-system/profile/share/man && [...]`. When I tried installing groff and running `man -t ls`, I get a couple of errors like `man: can't execute
<kdtsh>/gnu/store/[...]-groff-minimal-1.22.3/bin/preconv: Not a directory`. Sure enough, groff-minimal-1.22.3/bin is an empty file
<kdtsh>Maybe there are a fair few files on my system which are corrupted. Is there a way built into guix to rebuild the system, including rebuilding derivations? Or maybe I should just do a fresh install with my config.scm?
<kdtsh>roptat i'll give that a go. running guix gc --verify=repair,contents didn't seem to work, but i'll try fsck and running it again. failing that, I'll likely do a fresh install - I'm hoping I can find what the issue is so I can handle it again if it comes up again
<reepca>civodul: It's going okay, lately I've been working on making (guix store locks) a thing that exists and plays nicely with fibers. I've basically been re-implementing file locks that will work on an intra-process basis and multiplexing them on top of inter-process locks.
<reepca>I finally got around to writing a proper test for comparing my build results with the current daemon's, so far the first thing to diverge is a module-import-compiled in which some gensym-looking things are different (but apparently consistent)
<civodul>ah yes, Guile sometimes generates different symbols
<nckx>Minall: I think it's fair to say that the Shepherd (the project that provides the ‘herd’ command) is more flexible, which lends itself well to things like Guix System that don't fit into systemd's (deliberately) narrow worldview. And that's a direct consequence of using Guile. Whether or not it's better is subjective. I oscillate rapidly between opinions myself, depending on which I'm trying to debug.
<nckx>gnu_srs: No, you just need to follow the instructions in the manual to create them.
<reepca>it's possible there are new environment variables that need to be set, but guix can't set them for you directly since it's a different process. But if you run "source ~/.guix-profile/etc/profile" you'll get up-to-date environment variables.
<roptat>gnu_srs, the first code block will create the required group and users, then you can run guix-daemon with ./pre-inst-env (or without, the build users are unrelated to whether or not you have run make install)
<bavier>Minall: for next, I had to manually start the webkit process: 'next-gtk-webkit &; next'
<rekado>reepca: done! You’ll need a ~/.festivalrc to set the voice-path, augment the load-path, set voice-b
<rekado>oops, set voice-locations, and then load a voice.
<rekado>we upgraded the uplink of the server behind ci.guix.gnu.org to 10G already. If we could get bonding to work in Guix we could increase the bandwidth some more.
***paroneayea is now known as dustyweb
<civodul>also there's this nginx issue that penalizes bandwidth on cache misses
<rekado>g_bor[m]: I know you’re really busy, so I hope you don’t me asking: did you manage to make some progress wrt to the Guile bindings for that network library? Do you think working on this and integrating it with the Guix System configuration DSL might be a good Outreachy project?
<jonsger>nckx: I have now usually 1-2MB/s, with this cloudfront thing it was often way more then 5MB/s
<kmicu>zacts: On NixOS you can also keep system stuff under /etc/nixos/configuration.nix and user stuff under ~/.nixpkgs/config.nix. What to do is a matter of personal preference. Some folks prefer to keep core system tiny and put the rest in user configs some prefer to keep everything in one place. Some folks install stuff imperatively too. There’s no Right Way™ only trade‑offs.
<reepca>I'm trying to do something like that to get it to read /gnu/store/k6ix1l2ij2sadv9r5d2j82b16bs1wa3y-festival-2.5.0/share/info/festival.info.gz, but it just says 'Can’t find festival.info-1 or any compressed version of it'
<reepca>doesn't work in a freshly-opened emacs either. Maybe it's a problem with the package?
<civodul>could be, if it misses the info-[0-9]* files
<pinoaffe_>roptat: I tried using the guix-home-manager by following the instructions on the gitlab page, but I keep getting an error message "guix home: no such command" - any idea what might be going wrong?
<grafoo>hey! are there any thoughts on bringing zfs into guix or is the licensing issue not working out with the gnu guidelines?
<roptat>pinoaffe_, you have to set GUILE_LOAD_PATH as a workaround to a bug in guix
<roptat>make sure ~/.config/guix/current is part of GUILE_LOAD_PATH
<roptat>pinoaffe_, also make sure to have a backup of your home content, because I'm not entirely sure guix home won't do something terrible to your data
<reepca>rekado: I'm having trouble getting voices set up. I extracted some of the tarballs at the site you linked and pointed voice-path to the resulting festival/lib/voices, but it still complains about "No default voice" on startup.
<roptat>rekado, I won't be able to make it then, I currently have a lot of pressure because I need to finish writing my thesis by the end of the month
<roptat>well, I can at least try, but can't promise anything
<pinoaffe_>roptat: aight, will do that, thanks for the help
<divansan`>Hi all. Clueless user trying to do minor contribution to guix to update a package. Reading "Running Guix Before It Is Installed" manual, it says run command "sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild".
<divansan`>Should this sudo command be run on your local laptop, running guix system. Seems not so "clean" in a way.
<efraim>divansan`: you can skip that part if guix itself is already installed, it's more useful for porting to a new architecture/distro
<divansan`>efraim: ok, let me play see how I go - thanks.
<reepca>divansan`: even if you had two daemons running at once, they both use extensive inter-process synchronization to ensure nothing gets clobbered. I'd expect there to just be a bit more contention than usual.
<sebboh>Hi! ltns, guix. uh somebody said that guix has some nix code, perhaps old code, deep inside. Was guix really a fork?
<sebboh>Is that what manages /gnu/store on my guix system? Like, when I ask for a gc or whatever? (I don't know the duties of the daemon.)
<rekado>yes, the daemon keeps the lock on /gnu/store.
<rekado>the daemon sets up the chroot and then runs build scripts, which are all Guile scripts in the case of Guix.
<rekado>and these Guile scripts are generated with Guix.
<rekado>the Nix daemon will eventually disappear (hopefully soon); much of the work that is done by the daemon can just as well be done with Guile — and Guix already has implementations of many of these features.
<rekado>reepca is working on replacing the Nix daemon with an implementation in Guile.
<sebboh>wait, I need confirmation on that actually. I know very little about /gnu/store; I learned things by watching you ask questions about it. My question is "is there some hashing mechanism that is checked at runtime?"
<kefas>So the only way for me to have a clean slate of system containing only files that are from packages would be if I copied /etc/config.scm to a newly installed guix system?
<pinoaffe_>kefas: /etc/ is rwx, but most files in /etc are merely r and to add a file to /etc/ you'd need to be root
<pinoaffe_>if your attack model includes someone with root privileges, it's game over from the get-go
<katco>i'm creating a tarball of some libs using `guix pack -S /opt/gnu=/ foo bar` and the tarball it produces contains two files in `/opt` both named gnu. i can untar this on my machine fine, but other machines complain "Cannot open: File exists". any ideas?
<kefas>sebboh: I don't know either, but I guess it's fine if the mechanism to check at this runtime is not available yet, because it seems like making it available wouldn't be too difficult for Guix seeing that packages are tightly tied to hashes.
<kefas>pinoaffe_: yeah, I was just trying to compare it to other GNU/Linux systems... Who knows, maybe Guix System has advantages in this area I don't know of..
<pinoaffe_>kefas: the advantage isn't that there's some all-mighty enforcer preventing you from changing the state of the machine in an unchecked manner, but it is allowing you to manage the system in a purely functional manner
<kefas>I'm interested in introducing Guix System to my company. I'd like to know all advantages (and disadvantages if there are any) so that I could sell it to colleagues and superiors.
<kefas>Can you give example pinoaffe, the advantage of managing system in a functional manner?
<dongcarl[m]>rekado: Should we open an issue about the inferior/channel problem from our discussion yesterday?
<pinoaffe_>kefas: normally, in order to set up a system, you'd go through a series of manual steps to modify its state (the available packages, the configuration files, etc)
<kefas>pinoaffe_: Configuration files? Really? I thought only /etc/myconfig.scm was the only configuration file and everything else in /etc is not supposed to be manually edited...?
<pinoaffe_>however, depending on a lot of arbitrary factors (the order in which you install certain packages, the state of the configuration system at the time of installation of a particular package, etc) it's nearly impossible to reproduce a system or to roll back to a previous state of the system, except by copying the entire file system
<pinoaffe_>kefas: I'm talking about how stuff worked pre-guix :)
<guixgoldfish>GnuIcecat: I've downloaded/installed the language pack related of my icecat version in my first language and it's activated and displayed in addons/languages but icecat is in english. Any ideas?
<pinoaffe_>with guix, you don't manually mutate the system state, you specify the system config you'd like to have and it is generated for you, in a bit-to-bit reproducible manner
<roptat>guixgoldfish, have you restarted icecat maybe?
*kmicu firmly states that Guix System is not for sale.
<guixgoldfish>well it is so easy to be not content with something maybe I should tell you all that I'm very impressed running gnu guix. :-)
<rekado>dongcarl[m]: yes, opening a bug for this issue would be good
<kmicu>guixgoldfish: IceCat could be not properly packaged to support other languages. It can be a bug.
<Tirifto>guixgoldfish: ^ I think that's the case. I remember someone trying to fix it a while back, but forgot who it was…
<guixgoldfish>Thanks. Localed Epiphany and English Icecat are good apps now I'll wait for Falkon..
<pinoaffe_>btw, I ran into some issues with the guix graphical installer a couple of days ago, I think there are some logic bugs in either the uefi detection or in the partition creation
<kefas>It seems all binaries I've seen are only links to files in /gnu/store. Wouldn't be wise to make another filesystem for everything else outside of /gnu/store with a noexec option in /etc/fstab? That way, we rest assured that no binary can run other than the hashed protected ones in /gnu/store... ?
<kefas>pinoaffe_: It would mean if any intruder had ssh access, they can't just plant or hide their rootkit tools anywhere in the system. And if they do try to plant it in /gnu/store, it would be easier for us to find out because of the unmatching hashes (assuming that this mechanism is available in Guix).
<kmicu>Most rootkits don’t work out‑of‑the‑box on Guix System/NixOS ;)
<kmicu>Most attackers prefer more profitable targets like FHS-compliant distros.
<pinoaffe_>kefas: a system like that could be pretty neat, but it'd be as strong as its weakest link, and as such, to protect against a targetted rootkit, you'd need a fully verified chain from the earliest bootrom up to userland binaries
<kefas>kmicu: I know...😂️ But I would just like to be sure. And who knows, maybe one day Guix System/NixOS will be the norm and people will try to holes there.
<kefas>I really do believe that the best way to handle a compromised system is to reinstall the system, because nothing about it can be trusted anymore, even 'ls', 'find', etc.
<kmicu>In that case Guix/Nix is your friend cuz setup is declarative and you can recreate the system from scratch in minutes.
<kmicu>(But there’s nothing equivalent to Qubes, no fuzz testing of Guix tools, no security audits so don’t expect state‑level threat modeling.)
<kefas>pinoaffe_: But can't binaries be easily verified if we have reproducible build? I don't understand...
<kefas>Anyway, I see security as layers of protection, not as links.
<pinoaffe_>kefas: for verification, we need to trust the code we use to verify, to trust said code, we need to trust our kernel, to trust said kernel, we need to trust our bootloader, etc
<pinoaffe_>this is all very theoretical, and even without a full chain of trust more signature verification could mean more security in a practical sense, but you can't know for sure until you have a full chain of trust
<ful0n>I'm lost a bit, how do I declare kernel module options? I have the documentation open so if you can point a section or anything it helps already :)
<ful0n>nckx: thanks, but I was thinking more of whats usually in /etc/modprobe.d/, like "snd-hda-intel model=dual-codecs". Is it the same? what if I want to load it when a service starts and unload when it stops? sorry if I'm extending the question too much, I want to create some packages with this kind of logic, unsure if its totally a bad idea btw
<nckx>ful0n: Whoa, that's a lot 🙂 1) Dunno what /etc/modprobe.d is. kernel-arguments sets the kernel command line at boot, which applies both to built-in/initrd-loaded drivers *and* drivers modprobed at any time later on, which is nice.
<nckx>2) Calling ‘modprobe’/‘rmmod’ from your service is the only way to do that.
<ful0n>nckx: thank you a lot! this helps me getting it to work already, when I finish learning guix I can try the dynamic way
<nckx>No opinion on whether it's a bad idea; that would probably depend on the exact use case. I'd be… extremely sceptical of a service that did so.
<ful0n>nckx: not really, you can imagine a zswap service that you can change without rebooting, for instance
<nckx>ful0n: Well, as a zswap user myself… why would I ever want to rmmod zswap?
<nckx>Or did you just mean a ‘sanity check’ like ‘if ! loaded zswap; then modprobe zswap; fi’?
<ful0n>nckx: I use zram on my servers and want it on guix, I'm trying to create a package. When I enable it or tune the values, depending on the server, I usually dont want to reboot, but thats a preference I guess
<nckx>I don't think that example belongs in a service but that's absolutely a personal opinion.
<nckx>ful0n: You have to reboot to tune zram values? Oh ☹ zswap is nice then, you don't have to do that.
<ful0n>nckx: no, I dont because for now I manage it manually, but there are some distros with services that sets and resets it
<nckx>Everything's tunable on the fly, no reloading needed. But I understand that zswap was just an example.
<nckx>Well, to get back to your actual question: services are run as root, so you can absolutely modprobe from them. You can do anything you want, especially on your own box 🙂 I have some services that do pretty un-upstreamable weird things.
<nckx>For better or worse there's no sandboxing (yet) that would prevent these things.
<ful0n>nckx: oh, actually, good point! I actually dont usually rmmod but swapoff instead... on guix, I would add it as kernel-arguments and use swap-devices to add as swap right? I will try that, thank you a lot!
<ful0n>nckx: just curious on best practices, if I wanted to make it upstream-able, the best place to add would be as a new swap-device type? :)
<nckx>ful0n: That should do it (zswap.enable=Y zswap.compressor=zstd etc.). If not, ask away.
<nckx>ful0n: We don't actually have a type like that yet. Funny you mention it, because just today I started some very rough work on one. I want to set priorities for striping, and that's not possible with the simple list of partitions we currently support.
<nckx>zstd zswap + 4-way striped swap = a *surprisingly* usable extra few gigs of RAM, I have found.
<ful0n>nckx: nice! I dont have much experience on zswap, I'm kinda stuck with zram because I use btrfs on very small VPS disks :)
<nckx>(To clarify my above remark & just in case you didn't know: everything under /sys/module/zswap/parameters is writable.)
<kefas>kmicu: Yep, I love the idea about recreating from scratch in minutes with Guix/Nix. But the problem about intrusion is, sometimes we don't know whether we've been compromised. That's why I like the immutability of Docker and Terraform, because it gives very little incentive for intruders to break into a system that will just restart itself from scratch. But their immutability means you can't have a database in your system because when the whole system starts ov
<kefas>er, your database becomes empty. This is why I think that maybe the immutability concept in Guix System (where packages are immutable and data are mutable) is superior to that because it can handle both, immutable applications and mutable database (or just data). My question earlier about whether it would be wise to mount every other filesystem other than /gnu/store with the noexec option in fstab is to enforce that "everything other than /gnu/store is just dat
<kefas>a and shouldn't have the ability to run". This way, intruders wouldn't be able to run their tools.
<nckx>ful0n: I've never used zram since zswap was so shiny & flexible. What are the advantages?
<kefas>pinoaffe_: I'll take your word for it when you said "that would be possible within the guix configuration system".
<ful0n>nckx: unsure, I just cant have a swap file on btrfs and no space for swap partitions usually, so I use it as it doesnt require disk. Also, it seems to work well if your disk is slow. I helped some friends with very low memory to use it as their computers used to freeze when it had to hit a normal swap. One good example is raspberry, the first model. If it touches the disk, the world stops. zram works fine