<marusich>If you don't have Emacs handy, you can also view the manuals by executing "info" on the command-line. The interface is similar; the help tutorial I mentioned just now also discusses that reader.
<marusich>Most of the GNU software is written in TexInfo. A well-written TexInfo manual is much easier to navigate than a generic man page (woman page? I haven't used woman myself, so I don't know how different it is).
<marusich>Here's an example to whet your appetite. Suppose you're reading a Makefile. You see a symbol like $<. What's that? Well, you can easily look it up in the index of the GNU Make manual. If you have it installed ("guix package -i make", I think), after opening the manual, you can just type "i", then "$<", and hit enter, and it'll take you to exactly the page where it's defined.
<marusich>No, it doesn't create entries for other distros automatically. However, you can add them manually if you want, by declaring an appropriate "menu-entry" in your operating system configuration file.
<marusich>If you want to do that, the details can be found in the manual here: (guix) Bootloader Configuration
<lyr3>$ grub-mkconfig -o /boot/grub/grub.cfg, works on terminal after everything is installed, doesnt? If so, then its similar to gentoo
<marusich>That might work, yeah, but it isn't really the expected way that users will manage their bootloader configuration in GuixSD.
<lyr3>wow, guixsd has another way to set grub entries?
<marusich>Instead of manually generating the file, it is preferred that you declare what the file should contain in your operating system configuration file, and then rely on commands like "guix system reconfigure" to update the config.
<marusich>The idea is that you should not have to destructively mutate your system, since it is risky.
<pkill9>just put it in the file and you won't have to think about it
<marusich>The benefit of doing it this way is that you can be confident that you will not break your system.
<marusich>GuixSD makes sure to put old system "generations" into the menu entries, so if something goes wrong, at boot time you can always select an older generation to boot from.
<pkill9>i think also your grub configuration would get wiped everyttime you run `guix systemr econfigure`
<marusich>It's like having instant access to previous versions of your system.
<marusich>Yes, that's also true. Your manual modifications will not be saved.
<vagrantc>guixsd kind of has built-in configuration management ... if you've ever used puppet or ansible or whatever ...
<lyr3>reconfigure is literally generating copies of a earlier state of the whole system?
<vagrantc>so managing configuration files by hand kind of breaks that
<marusich>The motivation for doing this is to follow a functional paradigm for system configuration: you declare inputs, you get a system as output. It's all immutable, so it's easy to flip from one version of the system to another.
<marusich>When you run "guix system reconfigure my-config.scm" it will build everything that is declared in your config file. If anything is the same as a previous generation, the new generation basically will re-use what was built before. All these built components reside in "the store", which is a directory at /gnu/store that contains immutable build artifacts which are managed by the guix-daemon.
<pkill9>there's basically a link to each generated state
<marusich>lyr3, Guix follows a "functional" paradigm; that's why we prefer to declarativly define the system, instead of destructively modifying the system in place, like most other distros do. For more information, the following manual sections are probably helpful:
<marusich>(guix) Introduction, (guix) Package Management, (guix) GNU Distribution (in particular (guix) System Configuration).
<vagrantc>ACTION generally finds emacs to be a useable text editor... and mail client ... and struggles with the other built-in features
<marusich>lyr3, and personally, if you find the "functional" aspect of this system exciting, I highly recommend reading the first 15 pages of Eelco Dolstra's Ph. D. thesis. It explains very clearly the problem that Nix solves. Under the covers Guix is basically the same as Nix, so everything in the intro applies to Guix, also.
<thomassgn>I also like that guix has both SICP and th gnu C manual as packages for info... :)
<marusich>From what I've heard, it sounds like the Nix expression language suffers from limited extensibility. It is good, but people wanted to do more, which is awkward since it started just as a specific-purpose EDSL.
<marusich>Well, E for external, I guess, not E for embedded. That was ambiguous :)
<lyr3>I hope that soon I will helping Guix team improving it
<thomassgn>this. It's the main reason I switched from nixos
<marusich>With Guile scheme, there is already great support for extensibility. And htere is an ecosystem surrounding it, although it may not be as big as an ecosystem surrounding C or Java.
<marusich>So, it's a bit more complicated, I guess, but the idea is that its expressive power is better than an external domain specific language like nix expressions in the long run.
<marusich>lyr3, it's a really welcoming project. We would love to have you helping out!
<ng0>jD91mZM2: yes, by doing the same configuration as every other OS does. You get the source, apply your changes, create a patch from it (or, if trivial, guix' substitute function, and create a custom st package
<ng0>once upon a time I had a public example for this somewhere
<jD91mZM2>ng0: So no special case, like NixOS lets you override the `conf` variable?
<oleo>i removed the mapped devices module dependency
<oleo>and deleted the encryption part from my config.scm
<ng0>a hypothetical "suckless-build-system" could read and write configs through the package definition, but suckless has too little packages to justify this. of course if you throw these build system definitions in your local path guix would catch them, but that's up to you. I found patches to be more predictable.
<ng0>I have encountered some upstreams cnfiguring their builds similar to suckless. so I might end up doing this when I get too annoyed by a stack of repetive work
<ng0>maybe describing how to modify st as an example would help to get people started, it's a frequent question.
<IntoxicatedHippo>What could be causing this? "sudo: /gnu/store/...-profile/bin/sudo must be owned by uid 0 and have the setuid bit set"
<mubarak>IntoxicatedHippo: did you add your username to sudoers file via # visudo?
<mubarak>IntoxicatedHippo: did you add your username to sudoers file via # visudo?
<pkill9>it's pretty insightful, there's a bunch of stuff with vulnerabilities on mine
<g_bor>I would proposed to move the strip-jar-timestamps procedure to java-utils, but it might well be, that leaving the ant-build-system alone, and duplicating that code in the ant-bootstrap package definition would be cleaner. Do you think there is a better way? I currently see these two options, but I might be missing something obvious.
<g_bor>We also discovered, that it would be nice to add some capability to the linter to print custom notices, or something like that.
<g_bor>We have a possibility to suppress a cve warning, but we do not have the tool to add one. So sometimes it happens, that a cve is not reported, but the developers know, that the package is affected
<davidl>pkill9: possibly :-) Im not sure that would be a good thing since you lose some overview. I considered to make lines org-mode-style, so you can put specific info like that in org-mode drop-down stars ('*' '**' etc).
<civodul>davidl: nice indeed, i came up with the name 'guix health' for such a command :-)
***jonsger1 is now known as jonsger
<efraim>I was thinking about --recursive for guix lint, so you could also check all the dependencies of your installed packages also
<g_bor>civodul: do we have anything to do currently about GSoC? Recently I wasn't on irc, but I checked the mailing list. I did not yet see too much related activity.
<g_bor>I've also sent you the slides from my talk yesterday on the Hungarian Free Software Conference. The talk went great, the room was full, and it was really nice to present about this great software! Thanks to the community for making this possible.
<civodul>g_bor: oooh, didn't know you were giving a talk, sounds cool!
<uniq10>hi, when I am in ./test-env I keep getting this error: "unexpected Nix daemon error: guix download: error: lstat: No such file or directory: "/home/uniq10/guix/guix/gnu/packages/bootstrap/x86_64-linux/guile-*"