<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>*(not(string-prefix? "i686" (%current-system))) <GNUtoo>I guess that should be quoted somehow <apteryx>vagrantc: re Go in Guix; the importer has made strides, but the build system is still limited (does not support Go modules) <GNUtoo>apteryx: if I add native-inputs dependencies to a go package, it will use them instead of downloading them? <GNUtoo>Like it will use the ones packaged by guix instead of making the go build system manage that by itself? <apteryx>everything gets built statically in Go, so all that adding multiple inputs gets you is sharing the source <GNUtoo>For more background, I've added the matterbridge package which is written in go, <vagrantc>the guix build environment can't download things itself ... <GNUtoo>And I didn't use guix's go packages dependencies, and it just work <apteryx>GNUtoo: does it depend on other things? If so, yes, it probably has them all vendored <apteryx>It's best to unvendor them when possible, but if the package relies on Go modules, that won't be possible currently. <GNUtoo>yes, there are vendored in some way. some of the depdencies are in guix though <GNUtoo>So If I just add the dependencies in propagated-inputs, does that un-vendor them automatically? <apteryx>e.g. you'd specify all the dependencies as native-inputs and remove the vendor directory in a source snippet <apteryx>ah, if it's a library, you'd want to list the dependencies as propagated, but if it's just a command (binary), you'd want them as native-inputs. <GNUtoo>I know there are depdencies because 'guix import go github.com/42wim/matterbridge' produces a package with the dependencies in propagated-inputs, and the package I upstreamed in guix doesn't <GNUtoo>oh ok thanks, it's a command / binary <apteryx>I may be a bit rusty, iskarian please correct me if I say something wrong :-) <apteryx>then I'd go for native-inputs, because no other package will use its sources except for itself. <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 tried #:tests? (not (string-prefix? "i686" (%current-system))) <GNUtoo>There seems to be a dnsmasq service, but I've no idea how both dnsmasq and networkmanager are supposed to interact together <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 <flatwhatson>GNUtoo: thanks, maybe some hackery is needed to support passing a dnsmasq-configuration as a field in network-manager-configuration <flatwhatson>though a lot of the dnsmasq-configuration is not relevant in that context, so perhaps better to make a dedicated config ***lithium.libera.chat sets mode: +o ChanServ
<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 <bsturmfels>I did the `guix archive --authorize` on the remote host <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 <podiki[m]>sturm: what was it? I was confused as I saw no "length" in there <bsturmfels>podiki: I don't know exactly, but I switched to using "modify-services" from the example in the manual and got rid of the errror <podiki[m]>yeah, I was wondering if you needed that with base-services providing something (though usually the error is that you already have some service) <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? <bsturmfels>how would you express Guix configuration to write a file to a location on disk? I'd like to add a demo "/var/www/index.html" to my guix deploy setup <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 <apteryx>about GOPATH build artifacts reuse, that's sounds neat! <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 <apteryx>iskarian: the use case would be to partially unbundle dependencies? because if we unbundle all of them, them all we need is (delete-recursively "vendor"), right? <apteryx>it sounds reasonable and an improvement to me! <apteryx>going full unvendored is what we should aim for but until we get there we can do things incrementally better <iskarian>With that easier way to unvendor dependencies, I think I would rather make conflicting inputs/dependencies generate a warning, so packagers are more likely to remove them from source <apteryx>although, would that go-unvendor do something more than a (for-each (cut string-append "vendor/" <> delete-recursively) '("forge1/a/b" "forge2/c/e") ? <apteryx>OK; then maybe it's not worth the added cognitive load <apteryx>perhaps what we need is some extra documentated guidelines for Go packaging <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? <efraim>has anyone gotten giara to login to reddit? <PurpleSym>How are filenames in /gnu/store/.links computed? They look like output from `guix hash`, but it shows a different output. <PurpleSym>(Solution: Use the `-r` flag for `guix hash`) *dstolfa finally got the 2nd jab <mfg>You are running guix system right? <mfg>then you might just want to `guix install blender`? <mfg>The reason it doesn't work with the official download is: the blender executable has hardcoded paths to things like the dynamic loader, those paths don't exist in guix system. <mfg>everything is in the store so it can't be found <teddd>guix install blender of course works <mfg>is the blender package outdated or why did you try the normal download? <teddd>but I am used to tweak blender from this download file. I usually tweak the python inside it <teddd>its easier than building it and stuff <teddd>specifically I am just adding some extra libraries <mfg>(i don't know blender much) <teddd>not really. I link to a lib I am developing which is not really an addon <teddd>its a more general purpose geometry lib in python <teddd>but maybe there is a way to modify the existing guix blender package so that I can have the same tweak in the store ? <teddd>like a package transformation that comes after the build <mfg>you could inherit from the blender package and add your library to the inputs, i guess <mfg>but i never tried it myself <mfg>that also means you have to write a package description for your library <teddd>I am new to guix so I might be a bit intimidated but it somehow seems difficult to develop my lib and quickly test it in blender <teddd>It seems I would need to rebuild blender each time I want to have a newer version of my lib <mfg>true, does blender respect some environment variables that could be used for that? <teddd>I'm not aware of that. Let me check <mfg>another keyword might be 'grafts' but i also only know the keyword and have never used them myself :| <teddd>I didn't check that out. I thought it had more to do with security <teddd>There is a python option --python-use-system-env <teddd>And then there is BLENDER_SYSTEM_PYTHON <teddd>I just have to be in a guix env or a guix profile I guess ***lukedashjr is now known as luke-jr
<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 <mfg>you are on guix system, right? <muradm>terminal of greeter is fine and tested <muradm>greetd master itself received a patch to avoid ugly substitute in greetd package, now we have greetd-next which builds from master <muradm>sorry if duplicate message, had some problem with connection <mfg>xeaal: then /etc/ssl/certs/ca-certificates.crt isn't a valid path, isn't it? <xeaal>mfg: Well, I'm not sure, but this file exists and it is the exact copy of the one located at /run/current-system/profile/etc/ssl/certs <xeaal>mfg: also the thing is /etc/ssl actually a symlink to /run/current-system/profile/etc/ssl :D <podiki[m]>quick question, I'm guessing if you want gdm to see an xsession file (and gdm is coming through %desktop-services) it'll need to be added in the system configuration? <Telc[m]>is this a thing for anyone else """profile contains conflicting entries for guile-gcrypt...hint: Try upgrading both `emacs-guix' and `guix', or remove one of them from the profile""" ? <vldn>@ArneBab i meant something more like a way to convert my guile script with all the parenthesis to a editable wisp script without parenthesis? <sneek>Welcome back vldn, you have 2 messages! <sneek>vldn, ArneBab says: you can use it as source format and generate a scheme-file after saving: wisp2lisp /etc/config.w > /etc/config.scm <sneek>vldn, ArneBab says: you can use it as source format and generate a scheme-file after saving: wisp2lisp /etc/config.w > /etc/config.scm <roptat>Telc[m], do you really need guix itself in your profile? <Telc[m]>@roptat an interesting question... I think yes because I'm sometimes using emacs-guix? <Telc[m]>but perhaps it just ended up like that <Telc[m]>what are the circumstances we want guix in our profile? <roptat>if you need it as a library, maybe <roptat>from what I see, emacs-guix and guix share the same guix-gcrypt propagated input <roptat>so, you can fix that by upgrading both at the same time <roptat>maybe try "guix install emacs-guix guix" <Telc[m]>doesn't that create a new profile with just those 2? <Telc[m]>i get confused with some of these methods <roptat>no, you'd need a manifest to create a profile with only these two <roptat>guix install just adds new packages or updates them <roptat>it could also be that guix package -u is not working as expected, maybe you needed to do guix package -u guix -u emacs-guix or something <Telc[m]>now all kinds of complaints with similar propagation issues now with other emacs packages <roptat>mh... guix package -u, without specifying packages then <Telc[m]>thats what i was using to begin with <Telc[m]>thats my flow "guix pull" then a "guix package -u" every week or two <roptat>mh... I don't understand why you get that message, it's literally the same guile-gcrypt package... <Telc[m]>i assume its some kind of issue with the way things get patched to avoid rebuilds ***Roman is now known as RomanRiabenko
<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 <RomanRiabenko>"libsemanage.semanage_pipe_data: Child process /usr/libexec/selinux/hll/in failed with code: 1. (No such file or directory)." Could anyone tell, please, if I am doing it wrong? <roptat>RomanRiabenko, it should be a .cil file, not .cil.in, that means it's not fully generated <roptat>I guess it's not installed with guix <roptat>you could take this file, replace every @storedir@ with /gnu/store, every @prefix@ with /usr/local, @guix_localstatedir@ with /var and @guix_sysconfdir@ with /etc <roptat>and rename the result to guix-daemon.cil <roptat>Telc[m], but that "etc/guix-daemon.cil" file it talks about doesn't exist unless you have a development checkout and you built it <Telc[m]>my guess would be he needs to turn off selinux enforcement during the install <Telc[m]>so that it can get to the point where the policy is generated <roptat>the policy is not generated by the install script, only from a git checkout <Telc[m]>well it succeeded but the daemon is stopped by selinux from starting the first time <roptat>yes, so they need that guix-daemon.cil, but it looks like guix doesn't actually ship with it <Telc[m]>there are a few copies in the /gnu/store though <Telc[m]>ie /gnu/store/227mfaqx8gnr5s3w4z2g8vqn4vs6nj1f-guix-1.2.0-12.dffc918/share/selinux/guix-daemon.cil <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. <nirnam_>hi, isn't there colemak layout in the installer? <nirnam_>aha, i forget loadkeys doesn't use the same name for layout as setxkbmap <nirnam_>loadkeys dvorak work tho, how come colemak folk have to type en-latin9? <roptat>if that's what it's called upstream, there's not much we can do <podiki[m]>sss1: yes, you can make an image of any system configuration for botting <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 <sss1>in past i have maintained gentoo based live system, but now nix and guix looks like miracle, and can do just the same but much better and simpler <podiki[m]>you could make your regular and live image be the same system configuration basically <podiki[m]>now that I'm set up on my guix system, I'd also like to do that to have a portable system image <sss1>for now i played a bit with guix system image --system=x86_64-linux -t iso9660 -v1 gnu/system/install.scm <vagrantc>what do you have to do to make it a live system? e.g. /gnu/store is always read-only anyways ... so you'd just basically have to mount the rest on some tmpfs ? <vagrantc>i know that's basically how the installer works ... <sss1>in general overlayfs + squashfs used in regular live systems <sss1>do not know guix internals yet <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 <podiki[m]>(and do let us know how it goes, so I can add the details for a cookbook live usb article when I write it) ***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<vldn>(define-module (django) #:use-module (guix) #:use-module (guix build-system python) #:use-module (gnu packages python) #:use-module (gnu packages python-xyz) #:use-module (gnu packages django) #:use-module ((guix licenses) #:prefix license:)) <vldn>i hate when my clipboard isn't synced on wayland xD <vldn>how to import setuptools <podiki[m]>also, there is a guix package for python-setuptools-scm <podiki[m]>of if that's what you are using, maybe network connectivity issue? <vldn>how to give pypi inside my package building network access? <vldn>seems like it's restricted within build env <vagrantc>otherwise your builds are dependent on the state of the network