<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? <ray__>Maybe gcc needs to be patched? <mange>How are you getting that error? <ray__>guix package -i ghc; echo 'main = return ()' > test.hs; ghc test.hs <mange>Yeah, okay, I can reproduce that in a pure container. <mange>I'm on a foreign distro, so my initial test just picked up /usr/bin/as and worked fine. :P <ray__>Actually, just guix package -i gcc; echo 'int main(){}' > test.c; gcc test.c <mange>Okay, well, that seems like a bug. <mange>But it also seems like the sort of thing that would have come up before now. <ray__>I talked to someone the other day who told me about gcc-toolchain <mange>Yeah, that is the solution for the gcc case. <ray__>Which I don't really know what it is, but it gives you gcc and related things (maybe as propagated-inputs?) <ray__>But am I correct in thinking that it'd be better to patch gcc to refer to the paths directly? <mange>I'm not really sure about gcc. Sometimes with the more "core" things the rules are a bit different, and I'm not really familiar with the issues involved. <mange>If you want to see the definition for a package (like gcc-toolchain), you can use guix edit gcc-toolchain. <mange>gcc-toolchain is a bit weird because there are a few variants of it, but there's a comment at the end of the function that explains why gcc-toolchain exists. <ray__>I have to learn how to use emacs XD <ray__>That's a cool command, though <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. ***jonsger1 is now known as jonsger
<jonsger>sneek: later tell civodul: the guix from the installer scripts also fails at guix weather with the "patch not found" error :( <rekado>“gcc” should not be installed by users; “gcc-toolchain” is for interactive use. <rekado>the “gcc” package is useful for cases where packages need a different version of the compiler. <sneek>civodul, you have 1 message. <sneek>civodul, jonsger says: the guix from the installer scripts also fails at guix weather with the "patch not found" error :( <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. <civodul>i guess it'd be nice to have a infinoted service <civodul>for myself i prefer Git + Org files or something similar <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>testing it now without the llvm bump <g_bor[m]>civodul I intend do do a short writeup on the Cuirass web project, and I thought that i will do it in an org document. What is the current best course of action to share that with you? <snape>ACTION is pulling a Guix with civodul's new Shepherd patches applied, through the new Cuirass, and the new "guix pull" <jonsger>I didn't get "guix environment" working neither from script installed guix nor from my opensuse package <civodul>g_bor[m]: depends on how much we have to interact: perhaps email is enough, or the guix-maintenance.git repo, dunno <snape>jonsger: what do you mean by "not working"? <jonsger>after "guix environment hello" for example, I'm in the environment but hello is not in the store and just running hello doesnt work... <snape>jonsger: "guix environment hello" will put you in an environment with hello dependencies available, not hello itself <snape>if you want hello to be available, you need the --ad-hoc option <jonsger>ACTION tested too many guix commands and got's now a little confused :P <rekado>efraim: the firewall rules have been updated, I was told. <efraim>rekado: oh good, I hope it works <janneke>apteryx1: did you have and solve the offload problem "build failed: implementation cannot deal with > 32-bit integers"? i'm experiencing that now <Rukako>civodul, g_bor[m]: to my experience most tools for collaborative editing in emacs have been quite buggy so I would suggest git instead <Rukako>although it might be due to my inexperience with emacs and elisp <Rukako>oops, gobby seems to be the only maintained tool for that job in emacs <Rukako>but it lacks things such as hosting a server that uses tls and had emacs freeze multiple times while using it <snape>ACTION just killed his server by running strace on pid 1 -_- <libertyprime>snape: drooling over this os already. it's likely going to be my next main OS <civodul>snape: i think what you really want is a REPL server in PID 1 :-) <snape>civodul: very interesting! I'll read the thread. But you didn't commit it did you? <civodul>no because not everyone likes to live this dangerously <civodul>when Shepherd is Fibers-powered, we can try to do that in a safer way <snape>I was thinking about Fibers and Shepherd today, when I read the "main" <snape>it seems that it won't check for dead services until there is a command on the socket <snape>if it's the case, I guess it would need to check for dead services in a separate fiber <snape>hmm seems like I misunderstood, there is the 0.5 arg to selec <pkill9>is there support for /etc/udev/hwdb.d somehow? <pkill9>running udevadm hwdb --update tries to write to the guix store <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. <lfam>Another useful tool is: `guix graph --type=reverse-package foo | dot -Tsvg > ~/tmp/out.svg` <lfam>If you are a more visual person... <jlicht>lfam: wow, aliased that one, nice <mbakke>I also use `git grep ,variable-name` occasionally.. <tibbe>lfam: That was the thing I was searching for. I just had no idea on how to get a guix build quickly installed that contains my patch <lfam>The only trick is finding something will displan an SVG file ;) I use my Firefox browser <mbakke>lfam: I typically pipe such stuff straight to `feh` :-) <mbakke>Not sure if it supports SVG though, but you can use `dot -Tpng` as well. <tibbe>lfam: I think it has an option for emitting dot code... Then you could render it as a png <lfam>Yeah, that is nicer, but I found that the PNG generation was slow <lfam>I chose SVG because the dot->svg computation was a lot faster than dot->png <tibbe>lfam: Open a SVG in a text editor and you know why :) <jlicht>Is there some way in which to manage my NetworkManager configurations in a way that does not involve `sudo cp ...' from one machine to another? <jlicht>bonus points if there is a magical GuixSD in which to do this <efraim>Can someone start an eval of the qt-update branch? <lfam>efraim: Can you send the request to <guix-sysadmin@gnu.org>? We need to coordinate evaluations among branches <Misha_B_>Hello, I'm trying to install guix, but whenever I use the guix system init it says that mapped-devices is an unbound variable. And that I forget a use-modules form <Misha_B_>my use-modules is (use-modules (gnu) (gnu system nss)) <lfam>You can probably remove the (dependencies mapped-devices) unless you know you are trying set up some mapped device <lfam>The message about missing a use-modules form is basically a hint that we added to help with some common errors. Unfortunately the hint didn't help this time <Misha_B_>yeah, I just realised my mistake. I was copying from the desktop sample but removed the mapped-devices thing <Misha_B_>strange thing is that it said the error was on line 14, the bootloader line instead of the file-systems line <lfam>`make check`... You better "check" the clock and "make" sure you have a while :) <lfam>Misha_B_: I have to offline now or I would help debug. If nobody else pipes up, please send your problem to <help-guix@gnu.org> <snape>Misha_B_: you need to replace 'list' with 'cons*' <jlicht>Misha_B_: You seem to missing a cons(*) call in your file-systems field <snape>Misha_B_: (list a b c d) is the same as (cons* a b (list c d)) <snape>what you did looks more like (list a b (list c d)), that is '(a b (c d)) <rekado>pkill9: writing services is not too hard, but it can be a bit tedious. <rekado>pkill9: luckily, the system service framework provides lots of ways to extend existing root services, which is really convenient. <rekado>pkill9: if you want we can write a system service + shepherd service collaboratively, here or on guix-devel. <rekado>It helps to know in advance what you want the service to do; does it need to create user accounts, directories, …? How would it be invoked…? <rekado>What configuration options are there? <rekado>having answers to these questions in advance makes the whole thing a lot easier. <rekado>ACTION currently finishes the nss-pam-ldapd service <rekado>I want to write my first system test next, but I guess I’ll have to package 389ds first. <snape>pkill9: yeah as rekado said, there is a distinction between GuixSD services and Shepherd services. <snape>it's not obvious if you don't know about it <ryanprior>I know that guixsd uses shepherd by default, but is there an option to use systemd? Is it packaged in guix? <snape>ryanprior: there is no option. And no plan :-) <snape>One of the reasons is that systemd is Linux only <snape>but there might be other reasons <rekado>ryanprior: mbakke packaged it (the patch is on the mailing list as an April 1 post), but it cannot be used as the init for GuixSD. <rekado>I’m sure it could be made to work as PID 1 with some effort, but the price would be high. <ryanprior>Thanks snape. Does the guix package archive exclude all software that depends on Linux specifically? <rekado>It’s just not a good idea for us to use an init that only works with Linux. <snape>because Guix is supposed to work with other kernels too <rekado>GuixSD has a system service framework to set up the system on boot, and it integrates nicely with the shepherd. <rekado>You would not be able to benefit from this integration with another init system. <ryanprior>Yep, that makes sense. I was curious as to how hard it would be to use GuixSD to recreate the operator experience of other distros that depend on systemd. <rekado>since the initrd, shepherd, and Guix are all written in Guile we also benefit from code sharing, which would also be lost when using SystemD. <rekado>I don’t know how hard it would be. <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 <divansantana_>the latter fails to unlock when trying this: (screen-locker-service i3lock-fancy "i3lock-fancy") <snape>divansantana_: maybe that's because the program that needs to be setuid is still "i3lock" <snape>so you would need rather something like (screen-locker-service i3lock-fancy "i3lock") <snape>you would need (screen-locker-service i3lock "i3lock") <snape>but there is no i3lock package :p <snape>so maybe: (screen-locker-service i3lock-color "i3lock") <divansantana_>snape: this works (screen-locker-service i3lock-color "i3lock") <divansantana_>(screen-locker-service i3lock-fancy "i3lock") results in guix system: error: copy-file: No such file or directory: "/run/setuid-programs/i3lock" <snape>and you type i3lock-fancy instead of typing i3lock <divansantana_>(screen-locker-service i3lock-fancy "i3lock-fancy") produces no errors and is setuid. when I run /run/setuid-programs/i3lock-fancy <divansantana_>but fails to unlock. Let me try reboot, though doubt that will make a diff <snape>but i3lock-fancy is a shell script isn't it? <snape>so it can't be setuid if my understanding is correct <snape>so you need i3lock to be setuid <snape>(screen-locker-service i3lock-color "i3lock") <snape>as the command to lock your screen <g_bor>can someone clarify me what the database in guix is used for? <divansantana_>(screen-locker-service i3lock-color "i3lock") works. But I still think this should work rather (screen-locker-service i3lock-fancy "i3lock") <divansantana_>snape: it however complains like so ==1865==ERROR: LeakSanitizer: detected memory leaks SUMMARY: AddressSanitizer: 624 byte(s) leaked in 6 allocation(s) <snape>divansantana_: I'm glad it works :-) <snape>there is no "i3lock" in the i3lock-fancy package, so there is no way it will work <snape>it takes the second argument in the bin/ directory of the first argument <snape>the first argument is the package output <snape>g_bor: I didn't know there was a database in Guix <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. <pkill9>you won't be able to use the nix substitutes will you? <Xiro`>is ZFS support for root/non-root fs possible or planned? <vagrantc>Xiro`: wouldn't be surprised if the licensing conflict prevented that <efraim>I don't think anyone's working on it, but I assume with the license issues it'd have to be marked '#:substitutable? #f' <vagrantc>does guix publish refuse to publish such builds? does guix copy do anything special? ... zfs licensing opens up lots of ugly complications <Xiro`>well, technically speaking how easy new fs, say bcachefs, someone could add to own setup? <kmicu>g_bor[m]: did you do that and you know it works for sure? <snape>vagrantc: it's not a technical restriction <snape>so guix publish wouldn't "refuse" <snape>(well unless they are marked as not substitutable, of course) <vagrantc>was wondering how far-reaching '#:substitutable? #f' would be <snape>but anyway it's pretty clear from the article that we can't even write an official package for it <g_bor[m]>kmicu: no, I did not, and I think it does not work any more. I was just wondering what the database referred is used for. <snape>"if you distribute modules meant to be linked together by the user, you have made them into a combined work, and you must release the entire combined work under the GNU GPL" <vagrantc>the workaround used in some distributions is to build it at boot, and not distribute the binary modules <snape>so if we distribute Linux and ZFS as meant to be linked together (which is the case if we do a package for ZFS), we must release the entire combined work under GPL <vagrantc>obviously such workarounds really don't keep in spirit of the GPL <vagrantc>there's a lot of not-quite-certainly-wrong-but-not-really-right-either on the issue <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? <snape>well, yes, I sent you an email <civodul>but that doesn't really tell us where it comes from :-) <snape>my understanding is that it's the same problem start and stop have <snape>since the program returns immediately, SIGCHLD is sent <snape>and if it's sent before running is set, we have that error <snape>but it's just my reading of the code, I'm not sure <civodul>'running' is already set at that point <pkill9>does anyone have a configuration setup for installing the kernel modules required for 'tlp'? <civodul>also, the handler uses waitpid*, which swallows exceptions <snape>doesn't waitpid* only swallow system-error exceptions? <OriansJ>vagrantcish: thanks for informing me about that grub's MBR stage is able to open LUKS volumes <snape>civodul: but you're right, running is already set at that point, because it's set on 'start'... so I don't know :-) <civodul>snape: ooh, i see: close-pipe calls waitpid, but if you're unlucky, the SIGCHLD handler has already run by the time we call waitpid <civodul>we could block asyncs, but it's safer to not do that and instead simply ignore the close-pipe exception <snape>hehe my analysis was totally wrong then <snape>why doesn't it happen when ran outside of the Shepherd then? <civodul>because mcron itself doesn't have a SIGCHLD handler <civodul>well, and the thing here uses open-pipe <civodul>so it's a race between the handler and the direct call to close-pipe <civodul>ACTION just discovered the ENOPKG error code, fun <snape>I'll answer my email then, unless you prefer to do it <civodul>i was about to reply, i'll do it :-) <lukeshu>wingo: Am I correct in surmising that github.com/elogind/elogind has your blessing as the "real" elogind? <civodul>that's the version we've been using in Guix for a while