<wviana>hello there. Is there something where I could get information about how to install linux on guixsd? I intent to use it just with linux-libre, but I'll have to install libreboot on my x200 first.
<mange>What problems are you having with linux-libre?
<OriansJ>wviana: The difference between linux-libre and vannila linux is about the inclusion of binary blobs. Which unless your hardware requires a binary blob to boot, should not be an issue.
<OriansJ>Also, you can always make your own linux package based on the linux-libre's package definition.
<wviana>mange: OriansJ thats it, my current wifi will not work on linux-libre. I have a USB one but it don't work too. To replace my wifi card I have to flash my bios with libreboot first.
<OriansJ>wviana: as a short term solution, you could grab the debian package for your binary driver and unpack it manually but that isn't something we support and you'll have to figure out which */lib/firmware to put it into on your own but it should give you enough internet access to do what you need to get libreboot.
<wviana>OriansJ: Thanks. I'll try it. Or try to install default linux so I could chose with kernel to book on grub.
<mange>OriansJ: Last time I checked linux-libre couldn't load firmware blobs. Has that changed?
<ray__>Oh hi there guys. Here's an issue I have with guix: if I have ghc installed in the system profile, and I install a library into my user profile, the environment variable GHC_PACKAGE_PATH isn't updated properly. If I install ghc into the user profile along with the library, though, GHC_PACKAGE_PATH (and other environment variables) is set properly.
<ray__>This is kind of annoying, and I'm basically wondering if this is an issue that anyone has thought about before
<mange>The reason that happens is because the GHC_PACKAGE_PATH specification is on the ghc package, not on the library's package. In general I would recommend not installing much in the system profile and installing most things in the user profile. If multiple users have the same version of things they will re-use the same store item.
<ray__>Yeah, mmhm, that all makes sense. However, here's my exact scenario: the xmonad window manager. Users can do xmonad --recompile to compile their custom configuration which resides in their home directory.
<ray__>To do this, ghc and xmonad itself need to be in some profile
<ray__>However, the story gets much more complicated when you consider the ghc-xmonad-contrib package, which is a library which adds many configuration options
<ray__>The ideal setup, I'm thinking, would be to have xmonad in the system profile, and ghc-xmonad-contrib in the user profile
<ray__>But this doesn't work, because if I just naively do this, GHC_PACKAGE_PATH isn't set properly
<ray__>I guess it works, actually, to just put ghc-xmonad-contrib in the system profile, so maybe that's the solution here
<ray__>(I hadn't actually thought of that until just now
<mange>Yeah, I mean, I use awesomewm and I just have the user install awesomewm into the user profile, and launch it from within the user profile.
<mange>So the equivalent scenario would be to have xmonad, ghc, and ghc-xmonad-contrib in the user profile, and have the user manage it.
<ray__>Okay that seems fine. Here's a tangentially related issue: ghc, when compiling, calls as, which resides in binutils. So to actually use ghc for anything, the user has to have binutils in their profile. This also seems kind of annoying
<ray__>Should binutils be a propagated-input for ghc? Is that the way we do things in guix?
<mange>Progagated inputs are basically just a way for a package to install something else to the user profile, which isn't ideal. Usually we'd try to patch ghc to invoke as using an absolute path to the specific version it was compiled with.
<ray__>Yeah that does sound nicer. Maybe I'll try to figure out how to do that.
<ray__>Are there any examples of packages which do something similar I can look at?
<mange>Yeah, heaps! bcftools was the first in my grep, which is in bioinformatics.scm. On line 320 there's a call to substitute* to replace "/bin/bash" with (which "bash"), which will insert the absolute path to bash.
<ray__>Cool. There's my project for the next few days, then :) Thanks for your help.
<mange>There's another way, instead of calling which you can use (string-append (assoc-ref %build-inputs "bash") "/bin/bash"), which you can use when referencing things which aren't necessarily on the PATH, but that you want an absolute reference to.
<mange>One example of that is in emacs.scm, on line 7408, but there are others around the place, too.
<ray__>What's the difference between substitute and substitute*? In general, does * have a consistent meaning when appended to a function name?
<mange>In this case, substitute is a procedure and substitute* is some syntax that calls substitute to do its work. Usually I associate X* to be a helper, or variant of, X, but in this instance the naming seems reversed to me.
<mange>So, I don't know. Maybe I'm wrong with my usual interpretation of a trailing *.
<ray__>Actually... the specific error ghc spits out is gcc: error trying to exec 'as': execvp: No such file or directory
<ray__>So I think ghc executes gcc, which can't find as?
<mange>I don't think you have to use emacs to do it. I assume it just opens $EDITOR? For me that's emacs, so it's hard to say. :P
<ray__>Oh, that may be true. I think I have EDITOR unset so it chose emacs
<ray__>I may abandon this issue for now, as I'm pretty afraid to touch the gcc package
<mange>It would be good to check if it's been reported before, and maybe open a bug so we can track it. For the issue compiling with GHC, that is. I think the GCC solution is to use gcc-toolchain, which is documented.
<g_bor[m]>civodul: I've seen in our package list, that we have libinfinity. I did not see an infinoted service, though. I was thinking about writing up a document about Cuirass changes, and it would be nice to be able to collaboratively edit it. WDYT?
<civodul>g_bor[m]: what's libinfinity and infinoted, and how do they relate to Cuirass?
<g_bor[m]>They are collaborative document editing facilities. You can start a server, host the documents there, and text editors can connect, and edit the document, shared and knowing which user did what.
<g_bor[m]>Actually from the documentation it seems, that it can be used with emacs and org. Why I like these solutions is that they allow for faster iteration. You can see other edits in almost real time. I will have to do some experiments though.
<efraim>pkill9: sounds like it needs a service then
<pkill9>ACTION needs to learn how to write services
<mbakke>It looks like staging is ready for merge. "gexiv2" is failing on i686, but I'm willing to punt on that.
<tibbe>Hi, I fixed a bug with a guix package, how can I verify that my change does not break anything else?
<jlicht>tibbe: push to master and wait for the sirens to go off in the distance ;)
<jlicht>just kidding, of course, but you could send it to the guix-patches mailing list and ask someone to still verify that it works for them. You could also try to see if it (still) reproducibly builds using the --rounds and --check flags I think
<lfam>tibbe: There are a couple ways to check which packages will be affected by your change.
<mbakke>tibbe: You can use `guix refresh -l package-name` to see which packages that will be rebuilt.
<mbakke>And then `./pre-inst-env guix build <package-list>` to test that nothing breaks.
<rekado>I don’t want to keep anyone from hacking on this, but we would not accept patches to replace the shepherd with systemd.
<jlicht>ryanprior: there is currently an intern working on being able to have some integration with systemd unit files as their GSoC project
<rekado>the shepherd is still rather simple and doesn’t really show off its strengths.
<pkill9>what's the difference between a GuixSD service and a Shepherd service?
<rekado>pkill9: a Shepherd service is what you already know as services in other systems.
<rekado>i.e. an init-managed process that spawns a daemon and keeps track of its life.
<rekado>you might wonder why one would ever need more than that.
<pkill9>there's three services i want to make: one to provide elogind power management hooks e.g. reload a module after waking up from suspend, a powertop service that runs `powertop --auto-tune` on bootup, and for providing a config to udev hardware database (or whatever /etc/udev/hwdb does)
<rekado>the need for a GuixSD service arises from two peculiarities of GuixSD: 1) the system is stored in non-standard locations under /gnu/store and 2) the daemon processes themselves may need a certain environment before they can be used.
<soundtoxin>can someone remind me how I remove old guix generations?
<rekado>out of (1) follows that the system must be “checked out” on booting it.
<ryanprior>jlicht: that's cool, integrating with unit files will help the platform I bet.
<rekado>pkill9: this happens by creating /etc and populating it from the store, creating user accounts and groups, and so on.
<rekado>a system services could be to add a file to the /etc directory whenever the system boots.
<rekado>we have an etc-service-type for that, and you can define a “service extension” that extends the etc-service-type.
<rekado>the extension would create a file in the store and give it a name, and since it is an extension to the etc-service-type the file would end up in /etc.
<rekado>one of the system root services is the shepherd-root-service-type; by extending that service type you get to register a new shepherd service.
<rekado>the system service framework is pretty powerful and allows you to extend almost every part of the system setup, including the creation of user accounts and groups when the system is “checked out” from the store.
<rekado>for the LDAP authentication service, for example, I need to generate a configuration file from Scheme, serialize it to /etc (using etc-service-type), create a system user account and group (by extending account-service-type), create a state directory (by extending activation-service-type), append some lines to files in /etc/pam.d/ (by extending pam-root-service-type), …
<rekado>register an NSS plugin (by extending nscd-service-type), and registering a shepherd service that actually starts the daemon process (by extending shepherd-root-service-type).
<rekado>not every service is going to be as complicated as that, of course.
<rekado>providing files in /etc might be accomplished by extending the activation-service-type or the etc-service-type.
<rekado>we have a udev-service-type, but it only accepts udev rules, not arbitrary files. Providing a hardware database might require changes to the udev-service-type and the udev-configuration.
<jlicht>Could anyone try to build emacs-biblio on current master? I get a problem about "dash" not being loaded (which I can solve easily by adding "emacs-dash" to the list of inputs), but would first like to confirm that this is not something on my end
<jlicht>same story, but with the package `emacs-helm-bibtex' and the emacs-ivy dependency
<rekado>pkill9: do you know where the database is stored and how it is read?
<pkill9>i don't really know naything about how it works, that article is the first i've encountered it, but if you run udevadm hwdb --update it outputs "Failure writing database //gnu/store/k7r8yfy9f3ab2qycnc62wj9r7ffahv9c-eudev-3.2.5/etc/udev/hwdb.bin: Read-only file system"
<rekado>jlicht: I have the same problem with emacs-biblio on master (some commits back, but still recent)
<rekado>pkill9: I see that “udevadm hwdb” takes a “--root” argument.
<rekado>I suppose with that you could make it look up things in /etc and write there too.
<rekado>the required work here would be to extend udev-configuration such that these hardware overrides can be added in addition to udev rules.
<rekado>the udev-service-type would then run “udevadm hwdb --root / --update” (as an activation-service-type extension) after placing the files in the expected location.
<rekado>(not sure if activation-service-type would happen too early; in that case this may have to be done as a one-shot shepherd service)
<pkill9>hmm the --root argument merely prepends the path that it says it fails to write to, including the /gnu/store/.. part
<g_bor[m]>snape: I've also just had a hint recently.
<pkill9>are the tp_smapi and acpi_call kernel modules in any of the packages? I want to use tlp to set charging thresholds
<g_bor[m]>snape: Guix is compatible with Nix, so it is possible to share the same store between both. To do so, you must pass configure not only the same --with-store-dir value, but also the same --localstatedir value. The latter is essential because it specifies where the database that stores metadata about the store is located, among other things. The default values for Nix are --with-store-dir=/nix/store and --localstatedir=/nix/var.
<g_bor[m]>Note that --disable-daemon is not required if your goal is to share the store with Nix.
<kmicu>g_bor[m]: ah, thank you, now I understand. That was a quote from the manual.
<snape>in the end I really don't think we can package ZFS, because we would be adding material to a GPL covered work.
<snape>"This is not limited to your changes to the lines or the modules of the GPL-covered work you started with. Any material you add falls under the same requirement, so such additions do not become excuses to deny users' freedom."
<civodul>snape: did you figure out where the waitpid error comes from when running "herd schedule mcron 100" or similar?