<teddd>Hi everyone. I am new to guixOS just migrated from debian after a painfull system upgrade :) I'm glad I switched !
<slyfox>Is there an easy incantation to attempt to build every guix package? with "guix build -e '???'"? I did something silly with awk, but I wonder if there is a nice helper just for that.
***stikonas_ is now known as stikonas
<slyfox>If I export manually any of 'all-packages' definitions (say, from refresh) this seems to do the trick: "./pre-inst-env guix build -e '((@ (guix scripts refresh) all-packages))'". Worth moving helper out to a separate module to be useful like that as is?
<Zambyte>Hey, I am a little confused about the difference between native-inputs and inputs for package definitions. If an input is only used for tests, shouldn't it go under inputs (not native-inputs)? Are tests not run on the target architecture?
<GNUtoo>As I understand tests are run during the build
<GNUtoo>so dependencies for tests should go in native-inputs
*GNUtoo is pretty new and also has questions on tests
<GNUtoo>I'm trying to disable tests for i686 in a package, and if I do that: (arguments [...] #:tests? #f), then tests are disabled for all architectures
<GNUtoo>If I do '#:tests? (string-prefix? "i686" (%current-system))', it doesn't work, if I do (if (string-prefix? "i686" (%current-system)) #:tests #f) it doesn't works either
<Zambyte>Tests are run in the check phase, which occures after the build phase. There must be a build to be able to run tests against the build
<Zambyte>(note, I'm speaking about the meson-build-system, not sure if it's the exactly the same with others
<GNUtoo>If adding them to native-inputs automatically un-vendor the depedencies that are added that's great
<GNUtoo>My next question which is related is how to disable tests for i686 for a given package, it'd enable me to add 3 more dependencies for matterbridge
<flatwhatson>i have network-manager-configuration with (dns "dnsmasq"), which works, but now i want to customize the dnsmasq config. does anyone know how to get the "/etc/NetworkManager/dnsmasq.d" functionality?
<GNUtoo>'#:tests? #f' works, but '#:tests? (some lisp code)' doesn't
<flatwhatson>on my other systems, the dnsmasq is launched with --conf-dir=/etc/NetworkManager/dnsmasq.d, but not on guix
<GNUtoo>but I'm not sure if that could help or not
<apteryx>GNUtoo I don't think having GOPATH disables the 'vendor' directory; best to remove it completely.
<apteryx>(GOPATH is what our Go build system currently set/uses to find Go dependencies)
<apteryx>GNUtoo: since the build system arguments are usually part of a quasiquoted list `(...), and %current-system is a Guile parameter at the top-level, you'll want to unquote the parameter; ,(%current-system)
<apteryx>parameters are like procedures, they need to be evaluated to return their value
<bsturmfels>hi folks, I'm having some trouble with a first run of `guix deploy`. Seems to be connecting to the remote system fine and making some changes, but it's bailing out part way through with "guix deploy: error: unauthorized public key:"
<bsturmfels>It's obviously been able to connect to the remote machine, so I'm not sure what this error means
<ryanprior[m]>How come network-manager-openvpn doesn't include libnm-vpn-plugin-openvpn.so?
<ryanprior[m]>I'm working on upgrading the protonvpn package and I'm currently blocked because it needs libnm-vpn-plugin-openvpn.so which isn't in the network-manager or network-manager-openvpn packages
<Zambyte>bsturmfels: I have no experience with guix deploy, but are you trying to connect to the machine using SSH key pair auth? Or are you trying to connect by entering you password?
<ryanprior[m]>It is on my system (Ubuntu-based) as part of its network-manager-openvpn pacakge.
<bsturmfels>Zambyte: yes, I can SSH in no problem using the generated keypair. I think it's related to the `guix archive`, because the key it's rejecting is the one I've added with `guix archive --authorize`
<ryanprior[m]>Nevermind the above, it is part of that package after all and I'd just missed it. So I suppose the issue is that my package is looking for the library in the network-manager package directory and not the network-manager-openvpn directory.
<Zambyte>bsturmfels: You should be able to check to see if the key was added by checking to see if it's in the /etc/guix/acl file on the remote host
<bsturmfels>Zambyte: it's definitely there in /etc/guix/acl on the remote machine
<bsturmfels>Ah `guix deploy` seems to be overwriting /etc/guix/acl and removing the key I manually authorized
<ryanprior[m]>How does dlopen with Guix? Do I have to do something special to get that to find the library? I've tried putting network-manager-openvpn in the inputs & the propagated inputs, in either case network-manager doesn't find it.
<podiki[m]>ryanprior: may need to patch the path in the build? I've seen some dlopen stuff in package defs, maybe search for examples?
<iskarian>sneek: later ask yoctocell: but do we want to make having 'git' and its dependencies installed a requirement for 'refresh'? hmm... maybe we can add it to guile-git if it's already in libgit2? I vaguely recall seeing a ls-remote example in libgit2
<ryanprior[m]>I found some examples where they patch specific library paths to point to the path in a Guix package. The network-manager code doesn't seem to refer to specific paths though because it's a plugin system, so the paths aren't hard-coded, it's loaded at runtime
<iskarian>apteryx, re Go: I actually have a WIP patch for an overhauled go-build-system with module support; it could automatically unvendor dependencies that are supplied by an input. Do you think that's better than requiring them to be manually removed in a snippet?
<iskarian>I actually found a way to re-use build artifacts using GOPATH, but 1) it required the sources to still be available to not be brittle, and 2) it doesn't work in module mode at all
<iskarian>I wonder if it would work to not use propagated-inputs at all and just use LOWER to generate the tree? Would that work, or would it break other tools?
<apteryx>iskarian: it's less error prone, but we'd carry the bulk of vendor code in 'guix build -S', which is not ideal. Still an improvement, I believe, given I'm sure many Go packagers must forget to remove it (I see only one package doing it!)
<jgart>bsturmfels, you would add that file to the gnu/store via a gexps and then reference it
<apteryx>iskarian: the problem with drifting away from the normal inputs is the tooling, yes. You would no longer be able to track interdependencies easily using 'guix refresh -l' for example, as the dependency graph is made from inputs
<iskarian>apteryx, I agree on both counts about vendoring. I wonder if it would help to have a snippet generator in go-build-system? Something like `(go-unvendor IMPORT-PATH ...)` so we could write `(snippet (go-unvendor "github.com/x/y" "github.com/a/b"))`?
<iskarian>Of course, assuming they're using Go's built-in vendoring mechanism
<iskarian>I should also add a warning in the importer when it looks likes there are vendored dependencies.
<apteryx>hmm, there seems to be some kind of untold rule that importers only spit out package definitions rather than other useful information, although perhaps if the warning goes to standad error output that could be OK
<iskarian>Yes, a warning to stderr and perhaps a comment in the package definition?
<xeaal>Hello everyone! Is it fine to ask for help with the packages installed with flatpak? I need help with torbrowser in particular.
***apteryx_ is now known as apteryx
<mfg>xeaal: i'm not sure it may depend on the particular problem.
<xeaal>mfg: Well, as I know Tor Browser is really like IceCat, built on top of Firefox with a lot of things added to make use of tor features. The problem I'm having is it cannot find ca-certificates.crt file on launch. It should be located in /run/current-system/etc/ssl/certs/ca-certificates.crt and I've checked multiple times, either it actually exists and for some reason flatpak can't read it or it actually is not present on the computer and so
<xeaal> is the directory /run/current-system/etc/ssl
<xeaal>mfg: I've seen some similar problems in IRC logs, and people were talking about environment variables such as SSL_CERT_FILE and SSL_CERT_DIR
<xeaal>I tried to set them in system config file, but it didn't work, I tried to echo the variables and they didn't change.
<mfg>Hm, so there are two problems? If the directory exists it cannot be found and sometimes it even doesn't exist?
<mfg>how do you start tor-browser? searching tells me environment variables can be set when using flatpak run --env VAR=VALUE <program>
<xeaal>mfg: Yes :) I know this sounds absurd but I've probably seen this directory exist right after reinstalling torbrowser
<xeaal>mfg: I run "flatpak --user run com.github.micahflee.torbrowser-launcher" in the terminal
<xeaal>Running "flatpak run --env "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt" com.github.micahflee.torbrowser-launcher" outputs "error: Missing argument for --env"
<xeaal>I made a mistake, the correct command to run torbrowser with desired environment variable is "flatpak run --env=SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt com.github.micahflee.torbrowser-launcher", but it still outputs the same error
<RomanRiabenko>Hello, everyone! I am installing Guix 1.3.0 on Fedora 34 Workstation. I successfully ran the "shell installer script" and installed nscd as hinted. The guix-daemon is enabled. but fails to start with "Failed to locate executable /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon: Permission denied" and "Failed at step EXEC spawning
<roptat>oh no, it's from the guix package, but it's not part of the guix pull output, which I think is what you install from the installer script
<roptat>ie, no ~/.config/guix/current/share/selinux/guix-daemon.cil
***Roman is now known as RomanRiabenko
<ArneBab>vldn: there is no automatic conversion. It is possible to create one, but I did not create it yet, because this requires approximate creative judgement. It would be easy to just read the AST and output it as basic wisp, but the result would lose comments and would not be pretty. High-quality conversion (easy to read, preserves comments) would require complete parsing and representation with source-information.
<sss1>so question is, which is a simplest approach to create custom live system with additional software and settings
<podiki[m]>I really gotta write that cookbook article about it I said I would, but not difficult, basically `guix system image --image-type=efi-raw /path/to/config.scm` and then dd that image on a drive for efi boot a live system
<podiki[m]>you can start with the sample configs, like desktop; then once you boot it you can modify the system as you would any other guix system
<sss1>in my case iso is preferable, but i think i get ypur point, thx
<vagrantc>but given that system configurations are deterministic, seems like it wouldn't be much of a stretch to make a simple "live image please" flag to guix system build or whatever
<podiki[m]>btw, for making the live system image, you can ignore (all?) of the partitioning and bootloader stuff, `guix system image` will change that for making an image
<sss1>so, as i understand i can feed just "any" config to guix system image ?
<vagrantc>yeah, that's one of the awesome things about guix ... if you're trying something really experiemental, you can build a virtual machine to test it out and if it works you can just install it on your system ... would think the same would be true of a live image
<vagrantc>that said, the rollbacks are usually safe enough i don't bother with that either :)
<podiki[m]>that will be the installer I believe, but it does have guix documentation and tty too; and more up to date than 1.3.0 iso
<podiki[m]>vagrantc: not sure what you mean, but I think by default it will let you modify the system. So you can install packages, change the system configuration and do guix system reconfigure, etc.
<podiki[m]>it has been a little since I played with it, but I think worked pretty well. I don't remember if I had to change anything to get it working, don't think so
<podiki[m]>yes, it works the same for a live bootable image
<vagrantc>podiki[m]: if you want an image that will reset after reboot and wipe out all your changes, you need the writeable stuff to be to a tmpfs or some other filesystem that gets reset at boot
<podiki[m]>right, I think there is a volatile flag you can use?
<vagrantc>i *thought* the installer used that, so presumably poking around in the configs for the installer should find it