IRC channel logs

2019-09-17.log

back to list of logs

<gnu_srs>Found it: I had to install libsqlite3-dev.
<quiliro>Saluton Giksujo!
***sturm__ is now known as sturm_
<Bubb>`guix install python-pykka` is failing. The setup script seems to be exiting with 1 (from -v2). How should I solve this?
<Bubb>Side note - is there any way to have `guix import` include the import lines? Hunting down the packages that its handling seems silly
<dongcarl[m]>testing
<dongcarl[m]>sneek: bot snack
<reepca>sneek: botsnack
<sneek>:)
<alexanderbarbosa>what a day...
<ArneBab>When updating the system, I get an error: $ LANG=C guix system --fallback reconfigure /etc/config.scm
<ArneBab>guix system: error: symlink: Read-only file system: "/usr/bin/env.new"
<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
<civodul>Hello Guix!
<ArneBab>Hello civodul :-)
<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?
<civodul>ArneBab: nope
<civodul>or yes
<ArneBab>civodul: ok, thanks!
<ArneBab>oh …
<civodul>well you'd have to be more specific :-)
<ArneBab>When updating the system, I get an error: $ LANG=C guix system --fallback reconfigure /etc/config.scm
<ArneBab>guix system: error: symlink: Read-only file system: "/usr/bin/env.new"
<ArneBab>this is the last line printed
<civodul>this is from the "activation script", which runs after the upgrade completed
<civodul>when activation fails, it means you'll have to reboot for changes to take effect
<civodul>it'd be interesting to see why it failed though
<ArneBab>ah, ok. Can I help you with debugging?
<civodul>did you have a preexisting /usr/bin directory?
<ArneBab>yes, because I needed bash there
<ArneBab>(back when it wasn’t installed there)
<civodul>ArneBab: ah so that's probably the reason it's failing to install the /usr/bin/env symlink
<civodul> https://www.fsf.org/news/richard-m-stallman-resigns
<ArneBab>so it could be that the error message is wrong?
<civodul>wait, are you running it as root?
<ArneBab>yes
<civodul>so it really means that /usr/bin is read-only
<civodul>could you check "ls -l /usr/bin"?
<ArneBab># LANG=C rm /usr/bin/env
<ArneBab>rm: cannot remove '/usr/bin/env': Read-only file system
<ArneBab>LANG=C ls -l /usr/bin
<ArneBab>lrwxrwxrwx 1 root root 32 Jan 9 2019 /usr/bin -> /run/current-system/profile/bin/
<ArneBab>however on the root filesystem, there is /usr/bin/env
<ArneBab>or at least, I once linked it there manually
<civodul>oh i see
<ArneBab>but it seems not to be there anymore:
<ArneBab># ls /usr/bin -l
<ArneBab>lrwxrwxrwx 1 root root 32 9. Jan 2019 /usr/bin -> /run/current-system/profile/bin/
<civodul>so yes, you have to "rm /usr/bin" first
<civodul>reconfigure here expects to be able to "mkdir /usr/bin"
<ArneBab>testing that now — thank you!
<civodul>yw
<ArneBab>now that step works — thank you!
<ArneBab>the last line is now
<ArneBab>shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?).
<ArneBab>is that an error?
<civodul>it's not
<civodul>but it's apparently confusing so we should do something about it :-)
<ArneBab>yes :-)
<ArneBab>So my system upgrade is fully operational again — thank you!
<refpga>Hi, how can I declare a new group to list in the supplementary-groups of the user?
<jonsger>hm. What happened to /usr/lib/guix?
***spk121_ is now known as spk121
<civodul>jonsger: /usr? :-)
<civodul>oh, libexec/ was removed recently
<civodul>is it what you had in mind?
<freeuser58>I am trying compile with gcc but it say "ld: cannot find crt0". Any idea?
<freeuser58>On guix, of course
<rekado>freeuser58: are you using the gcc-toolchain package?
<freeuser58>yes, I installed so
<freeuser58>also, I installed the lastest version of gcc and gcc-toolchain but the problem is that
<rekado>what mean “the latest version of gcc”?
<rekado>only the “gcc-toolchain” package should be used.
<rekado>not the “gcc” package.
<freeuser58>9.1.0
<freeuser58>ok, then I'll remove gcc and I'll test it
<freeuser58>nothing, gcc is included on gcc-chaintools, srry
<jonsger>civodul: yes :)
<jonsger>civodul: so it's not needed anymore?
<efraim>that's why its hidden
<civodul>jonsger: nope, it's gone!
<freeuser58>any help?
<civodul>freeuser58: sorry, what were you asking?
<freeuser58>civodul: I am trying compile on C but I have error: it say "ld: cannot find crt0"
<civodul>freeuser58: like rekado wrote, you should run "guix package -r gcc -i gcc-toolchain"
<civodul>see https://guix.gnu.org/manual/en/html_node/Application-Setup.html#The-GCC-toolchain
<freeuser58>civodul: that I done, but the problem is same
<civodul>could you paste the output of "guix package -I"?
<civodul>on https://paste.debian.net for ex.
<roptat>refpga, use "user-group" to declare a group: http://guix.gnu.org/manual/en/html_node/User-Accounts.html#User-Accounts
<roptat>freeuser58, maybe try to source ~/.guix-profile/etc/profile
<roptat>there might be some environment variables in there that you don't have yet
*jonsger makes little progress on the Thunderbird "package"...
<civodul>"little" or "some"? :-)
<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 ...))) ...)
<rekado>sounds better than espeak
<civodul>rekado: i remember playing with it ca. 2001 (!)
<rekado>yes!
<civodul>it contributed to my vision of Scheme as The Right Thing ;-)
<rekado>there are more recent voices that sound like they are from 2002
<civodul>ah ah
<civodul>the sounds coming out from that were not exactly pleasant to the ear
<civodul>but it was fun
<civodul>you'd use it in a retro-futuristic movie i guess
*rekado –> afk
<jonsger>efraim: there is no recursive importer for crate yet?
<efraim>jonsger: it hasn't been merged yet
<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'
*jonsger sees light at the end of the tunnel :)
<civodul>kdtsh: that file shouldn't be empty; it looks like your file system is corrupt
<civodul>could you run "guix gc --verify"?
<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"?
<civodul>with the file name of that empty file
<kdtsh>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
<sneek>Okay.
<reepca>Okay.
<civodul>sneek: botsnack
<sneek>:)
<nckx>Good morning, Guix.
<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?
<sneek>Welcome back rekado, you have 1 message.
<sneek>rekado, nly says: thanks!
<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
<nckx>sneek: forget it...
<sneek>Okay.
<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
<civodul>if that happens we just try again
*civodul goes for lunch
<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...
<jonsger>hmpf one test of cbindgen failed
<alexanderbarbosa>time to grow up and learn scheme :D
<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
<roptat>rekado, would be great!
<roptat>rekado, speech synthesis would be great in the installer. We would need to have a button or a keyboard shortcut to turn it on at the very start
<civodul>kdtsh: good
<civodul> ext4 is known to leave empty files upon crashes
<civodul>that could be the reason
<civodul>reepca: hmm maybe you're right, i don't know
<civodul>so, how's the build daemon going?
<civodul>:-)
<jonsger>How could I use a newer g++ like version 7 in a cargo package? Adding gcc-toolchain-7 and/or gcc-7 to native-inputs results in weird compilation errors
<rekado>add gcc-7 with the label “gcc”
<jonsger>like ("gcc" ,gcc-7)?
<rekado>yes
<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?
<efraim>`sudo guix gc --verify=repair,contents`
<efraim>that'll check the files to make sure they're correct and rebuild/redownload them as necessary
<kdtsh>efraim brilliant - I'll give that a go, thanks!
<roptat>kdtsh, you should probably run fsck before that
<jonsger>somehow this gcc-7 stuff doesn't work. I disabled all tests for now. Which is kind of bad as only one is failing ...
<quiliro>Saluton Gikso!
<Gamayun>Saluton quiliro!
<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.
<civodul>reepca: neat
<civodul>so you're using Fibers?
<reepca>the list of stuff I haven't committed or needs rebasing keeps piling up
<reepca>aye
<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
<civodul>not your fault ;-)
<civodul>pretty cool if you're able to build derivations!
<reepca>guess I'll have to amend the test to ignore those differences then
<jonsger>ouch. TB needs sqlite 3.28 which is only in core-updates...
<reepca>I'm currently implementing add-temp-root to finish up add-to-store and add-text-to-store (which are otherwise working). All the ask-the-database RPCs are implemented.
<roptat>have we merged core-updates already?
<civodul>reepca: woow, cool!
<civodul>roptat: unfortunately no, it needs love
<civodul>but i think it's close to mergeability
<roptat>what can I do to help?
<civodul>look at "guix weather -c 10 -s WHATEVER" and see what needs fixing
<civodul>i'll merge master into it so we have a more up-to-date view
<gnu_srs>Hello, when changing the bootstrap-tarballs for Hurd from guile-2.2 to 2.0, which files to modify: gnu/packages/make-bootstrap.scm, and/or?
<civodul>hi gnu_srs!
<civodul>gnu_srs: make-bootstrap.scm, yes
<gnu_srs>civodul: Thanks, I'll make an attempt!
<Minall>Hello guix!
<quiliro>Minall: hello
<apteryx>what is the status of core-updates? Is it frozen, semi-frozen, open to big changes?
<apteryx>civodul: ISTR you had shared some way to put code in a channel definition that would look if substitutes were available for
<rekado>apteryx: core-updates is not open to big changes. We’re only fixing broken things now.
<apteryx>rekado: OK. thanks
<apteryx>*if substitutes were available for a given set (e.g., manifest) of packages. I saw a question regarding this on guix-devel but couldn't find your original posting.
*civodul pushed a merge of master on core-updates
<apteryx>rekado: any rough place I can help with on core-updates?
<rekado>apteryx: like civodul wrote above: look at "guix weather -c 10 -s WHATEVER" and see what needs fixing
<rekado>:)
<apteryx>ah, I must need glasses ;-) thanks
<rekado>it’s basically just that: making sure that the merge into master will not be something we have to regret
<apteryx>no way to see that from Guix CI ATM?
<rekado>it’s complicated :-/
<rekado>ci.guix.gnu.org does a poor job giving an overview.
<rekado>but you *can* see details of individual builds
<apteryx>OK!
<gnu_srs>When starting guix-daemon as root I get with guix build ... guix perform-download: error: refusing to run with elevated privileges (UID 0)
<gnu_srs>When starting guix-daemon as user I get with guix build ... guix build: error: opening lock file `/gnu/store/...mirrors.lock': Permission denied.
<gnu_srs>The whole /gnu/store is owned by root. Any ideas?
<nckx>gnu_srs: guix-daemon should have warned you when started as root to use --build-users-group=GROUP.
<nckx>These are the guixbuilder{01…10} users, in the guixbuild group.
<Minall>Is guix getting the newer version of gnome?
<gnu_srs>So I need to create these groups and start as root with guix-daemon --build-users-group=guixbuilder01
<gnu_srs>How do I create the guixbuild group?
<nckx>Yes. Grep the manual for these names; creating them is a standard part of installing Guix. It won't work without them. Not really.
<nckx>gnu_srs: All will be explained in the docs.
<rekado>Minall: there’s a branch with a newer version of GNOME.
<rekado>I don’t know what the status is.
<gnu_srs>I'm running with ./pre-inst-env
<rekado>gnu_srs: that’s unrelated.
<gnu_srs>I was recommended to not make install, only run the built stuff with ./pre-inst-env??
<Minall>rekado: Nice! thanks
<Minall>Is herd better than systemd?
<nckx>Minall: No.
*nckx runs away.
<Minall>jajaja
<Minall>nckx: The only reason GuixSD uses herd is because of guile?
*nckx comes back with cake.
<Minall>lol
<Minall>rekado: Where can I see that branch?
<rekado>Minall: pretty much, yes. (And making a system work with systemd isn’t all that easy.)
<rekado>Minall: in the Guix git repository
<Minall>Ok, let me check
<Minall>Oh, some packages doesn't work on my system, I don't know if it is some error on my pc or on guixSD
<Minall>How can I check this?
<rekado>(we call it “Guix System”, not “GuixSD”)
<rekado>Minall: you could write to help-guix@gnu.org with details of the command you used, the error you get, and what you expected to happen instead.
<Minall>oh, sorry, Guix System
<gnu_srs>So I need to 'make install' to get access to the guixbuilder group (and the info files)?
<Minall>I didn't did anything unparticular
<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.
<nckx>Nobody mentioned ‘make install’ at all.
<Minall>I runned: guix install lollypop, and guix install next, two packages I wanted to try
<Minall>And neither of them open...
<bavier>Minall: 'guix install' will install them, you'll need to start the programs yourself
<Minall>Can I install gnome 3.20?
<Minall>bavier: I mean, I installed them normally, and when I wanted to run them, for example, running their command, they didn't worked
<reepca>Minall: by "didn't work" do you mean you got a "command not found" message or they didn't do what you'd expect them to?
<reepca>sometimes next fails to start for me
*rekado uses M-x festival-say-buffer on the ERC buffer…
<civodul>oooh, fun
<rekado>I’m using the cmu_us_axb_cg voice and it has what sounds like a slight Indian accent.
<rekado>but it sounds much better than the diphone voice from 2010
*rekado has to try out all the other available voices
<Minall>NOpe, for example, when running 'lollypop', it tries to open
<Minall>But I get this:
<Minall>(..lollypop-real-real:2512): GLib-GIO-ERROR **: 05:13:56.718: Settings schema 'org.gnome.system.proxy' is not installed
<Minall>
<Minall>If something is not 'installed' shouldn't it be in the dependencies?
<bavier>you might need a running gnome desktop
<reepca>rekado: hurry up and push it, I wanna play too
<roptat>gnu_srs, http://guix.gnu.org/manual/en/html_node/Build-Environment-Setup.html#Build-Environment-Setup
<Minall>Mh... that could be true since lollypop integrates with gnome, but I didn't knew I needed actually gnome...
<Minall>I'll install next again, and try to install it
<reepca>Minall: have you sourced ~/.guix-profile/etc/profile?
<Minall>reepca: What do you mean?
<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>oh, and you need to download a voice, e.g. from http://festvox.org/packed/festival/2.5/voices/
<Minall>bavier: Let me try
<roptat>rekado, can we provide one of these voices, or are they not free?
<Minall>running 'source ~/.guix-profile/etc/profile' didn't give me anythin, is this that good?
<reepca>Minall: if by "didn't give me anything" you mean "didn't produce any output", that's normal
<Minall>Nice then!
<rekado>roptat: many of them are free
<rekado>roptat: some are free but depend on a non-free component
<roptat>oh :/
<rekado>I would provide voices in a separate package
<rekado>or rather one package per voice
<rekado>and then patch festival to set voice-path according to an environment variable
<rekado>then we could do without much of the .festivalrc hackery
<Minall>Yes, trying to run next gives me this: Could not connect to platform port: /gnu/store/lybgcz5bknzc75bnfhvyyy6g9lksn6vr-next-gtk-webkit-1.3.1/bin/next-gtk-webkit
<Minall>
<rekado>Minall: are you using the latest version of Guix? Have you used the latest version to install next?
<Minall>running : next-gtk-webkit & next
<Minall>
<Minall>gives me an error
<rekado>I don’t think you have to run both.
<Minall>Yes, I'm at the latest version, but how can I check this, in case
<Minall>Yes but, next doesn't start though
*jonsger misses the download speed of cloudfront a little :P
<nckx>jonsger: Was it that significant for you?
<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
<bavier>same for me
*jonsger is quite happy about his progress on Thunderbird. It now starts to compile and passed the configure phase :)
<roptat>rekado, that sounds like a very good idea
<roptat>I could even help mentor on this project I think
<rekado>roptat: the network thing? Do you happen to remember the name of the library?
<roptat>netlink? libnl?
<rekado>yes, I think that’s it.
<roptat>from iproute2 iirc
<civodul>having netlink bindings would be sweet
<civodul>it'd allow us to finally have proper network configuration
<rekado>I remember that g_bor[m] had started to work on Guile bindings, but I don’t know how far along it got.
<rekado>roptat: would you like to check with g_bor[m] and submit a project proposal on the Outreachy website?
<roptat>there was a thread on the ML, right?
<zacts>I might try guix system again, but it was pretty slow for me to do package operations
<zacts>at least in comparison to NixOS
<zacts>I want to to contribute to Guix though
<zacts>the graft feature seems to be one step in the direction of more efficient package commands.
<zacts>but maybe I'm not setting up my configurations properly
<rekado>zacts: grafts only bypass expensive builds.
<rekado>they are not a general purpose feature for better performance
<zacts>ah ok
<Minall>Can I install 'sway' on guix?
<civodul>sure
<civodul>Minall: you could run "guix install sway"
<civodul>or more likely add it to the 'packages' field of your OS config
<civodul> https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html
<Minall>Ok, I'll install it
<Minall>Does installing gnome starts it with wayland by fedault?
<Minall>default?*
<civodul>no, it's Xorg by default
<civodul>so you'd have to customize your config for Wayland
<civodul>there's no example of that in the manual, though
<Minall>I see...
<rekado>roptat: there was a call for projects on the ML; details about the netlink bindings have been posted much longer ago.
<rekado>roptat: note that the deadline for project proposals is Tuesday, Sept 24 at 4pm UTC.
<zacts>rekado: so should I have a single monolithic configuration file for my package operations, or should it be more modular?
<zacts>in NixOS I have a single configuration.nix for everything
<rekado>roptat: project proposals also need to be manually approved by the coordinators, so it would be good to have the proposal ready sooner.
<zacts>I'm wondering if this is why my package operations are slower
<rekado>zacts: what package operations do you mean?
<zacts>I don't have my guix computer next to me at the moment, but adding a package to my main config file and then telling guix to install from that
<zacts>like to install new packages on-top of what I already have
<rekado>zacts: the config file is used to build a new OS generation.
<rekado>that’s a little heavy weight if you just want to install some user software.
<zacts>ah ok
<zacts>that might be my issue then
<rekado>for that we use “guix install” or manifests (if you like to have it reproducible)
<zacts>manifest files?
<rekado>zacts: yes. The manual explains how to use them in section 4.2 Invoking ‘guix package’
<zacts>ok, thanks
<rekado>(search the index for “profile manifest”)
<civodul> https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html
<civodul>also, don't miss https://guix.gnu.org/guix-refcard.pdf !
<zacts>ok, :-)
<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.
<zacts>indeed
<reepca>what's the proper way to make emacs see new info files without restarting it?
<civodul>reepca: i do C-u C-h i ~/src/guix/doc/guix.info
<civodul>and then M-x revert-buffer as needed
<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
<rekado>oh, my bad
<rekado>I opened the file from within the build directory which included the other files.
<rekado>I only installed festival.info
<rekado>I’ll fix this in a moment
<rekado>sorry about that
<rekado>reepca: fixed
<reepca>\o/ is the 2.5 manual more up-to-date than the "latest release 2.4" that they still have on their site?
<rekado>it’s confusing.
<rekado>the manual is for version 1.4.3
<rekado>latest version at http://www.cstr.ed.ac.uk/projects/festival/ is reportedly 2.4
<rekado>but on the partner site it’s at 2.5
***jonsger1 is now known as jonsger
<zeta_0>has there been in any improvements in open hardware for guixsd, all i have heard about is: risc-v?
<gnu_srs>Hi, two more questions: I'm running out of space on /. How much is really needed in /gnu/store? Can I fool guile/guix to use a link from /gnu/store to /home (and move all files there)?
<gnu_srs>The second question is: Why is guix downloading a lot of old, not used, versions of e.g. glibc, gcc, etc?
<zeta_0>'
<gnu_srs>And why downloading linux-libre when issuing ./pre-inst-env guix build --target=i586-gnu bootstrap-tarballs?
<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?
<jackhill>pinoaffe_: unfortunately, I believe that is a know dificiency with channels currently: https://issues.guix.gnu.org/issue/37399
<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>something about nix c++ libraries.. ?
<pinoaffe_>sebboh: guix uses nix stuff in the build farm, but apart from that I don't know of any nix code
<rekado>reepca: this is my festivalrc: https://paste.debian.net/1101277/
<rekado>sebboh: no, Guix is not a fork.
<rekado>sebboh: it uses an old variant of the Nix daemon, though.
<rekado>you could say that the daemon was forked from Nix
<rekado>but nothing else is shared with the Nix code.
<rekado>roptat: oh, too bad.
<sebboh>Thanks everybody. So, ... this? https://github.com/guix-mirror/guix/blob/78249ebf5badd00d2bb130d85ca1fd2f3ac50963/nix/nix-daemon/guix-daemon.cc
<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>Cool. Thanks rekado
<kefas>Hi all! I've been a fan of GNU for a long time now. And Guix System sounds like a really cool project. But I still don't understand how Guix System achieves immutability...
<kefas>And how far reaching is immutability in Guix System?
<rekado>kefas: every package is built in isolation into its own prefix directory
<rekado>the target location is not writable
<rekado>all write access is managed by a daemon that coordinates builds.
<rekado>the system lives in a directory under /gnu/store and is “checked out” to the root (as needed) on boot.
<kefas>So even someone with root access cannot write in /gnu/store?
<rekado>kefas: we re-mount the directory so that even root can’t accidentally write to it.
<rekado>but root could get around these restrictions
<rekado>it’s just a really bad idea.
<sebboh>Not only that, but writes would break some self-referential integrity of the store, right? There's a concept of a 'valid' store, so naive modifications would be 'invalid'?
<sebboh>Something to do with hashes?
<kefas>I see... So /gnu/store is immutable, but the rest isn't?
<kefas>So there wouldn't be a way for me to know for sure if someone had added a new file to, say, /etc/.
<kefas>sebboh: that makes sense...
<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?"
<sebboh>kefas ^^
<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 :)
<kefas>pinoaffe_: ohh!:)
<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.
<pinoaffe_>kmicu: ??
<kefas>pinoaffe_: yeah, that sounds really cool!
<guixgoldfish>roptat, i did and also logged out and in again but it didn't change anything.
<pinoaffe_>there are still a couple of rough edges here and there, but all in all (imo) this is a huge improvement compared to other package management systems
<kmicu>pinoaffe_: a reference to ‘selling Guix to someone’ earlier in the backlog.
<roptat>guixgoldfish, actually I have a dictionnary for my language, but icecat is still in English too...
<roptat>a language pack*
<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... ?
<sebboh>kmicu: I see the language joke about "selling (convience)" vs "selling (barter)". :) Of course, there's this, too: https://www.gnu.org/philosophy/selling.en.html
<sebboh>*convince
<pinoaffe_>kefas: that would be possible within the guix configuration system, but I don't see a reason for doing so
<kefas>kmicu: Hehehe.. I wasn't planning on selling guix for money, just selling the idea of guix:)
<kefas>Because I don't think I can be successful maintaining Guix if I were the only one who believes in it.
<kefas>At my company I mean...
<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_>in that manner it's a chain of trust
<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 :)
<nckx>ful0n: kernel-arguments.
<pkill9>hello Guix'ers
<nckx>ful0n: So I have (kernel-arguments "btusb.enable_autosuspend=N" "btusb.reset=N" "thinkpad_acpi.fan_control=Y" "i915.<etc>"), which sets options for those various modules.
<nckx>pkill9: o/
<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.
<ful0n>managing manually doesnt require a reboot
<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!
<rofrol>hi everybody
<nckx>rofrol: Hullo 🙂
<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.
*nckx → 😴
<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
<ful0n>though
<pinoaffe_>kefas: see https://guix.gnu.org/manual/en/html_node/File-Systems.html
<kefas>pinoaffe_: That's interesting. I've never really looked at security that way as a chain of trust. But that sounds complex and so for now I'm just gonna trust in my bootloader...:)
<kmicu>ful0n: do you have old kernels there?
<kefas>Yep, I'm off to try building stuff... Thanks to all for all of your advice and ideas.
<ful0n>one other example I want to try is embedded things, like openwrt. You cant have swap on ROM due disk limited write cycles but sometimes the device is multi-core, so it can help, curious now...
<ful0n>kmicu: no, even my home router I try to be at least last stable
<kmicu>btrfs supports swapfiles since 5.0.
<nckx>(Good night everyone!)
<ful0n>kmicu: wat, I tried from the guix iso yesterday and couldnt make it work... I assumed it was still unsupported but probably I did something wrong
<ful0n>nckx: good night
<ful0n>btw, the guix graphical installer couldnt install using btrfs, had to install manually. Worked with default options though
<ful0n>(when I press the button to apply the formatting it goes back to the first screen, I have to repeat that later and see if I can get logs)
<ful0n>kmicu: thanks for that btw! this is great, I can try zswap now. Didnt know that
<rofrol>Where can I find the videos from https://git.savannah.gnu.org/cgit/guix/videos.git ?
<rofrol>Is this official place https://archive.org/details/guix-videos/ ?