<darkpsi>hey having some trouble getting xmonad to work the slim does not seem to know how to handle xmonad has any one got xmonad working? <atw>darkpsi: what's the issue, from the perspective of slim? <darkpsi>well not sure how familur you are with xmonad but xmonad compiles a binary to then execute as the wm (like a few other wm) when i select xmonad on the slim it fails to execute a wm and does not use the binary or xmonad.hs file in my ~/.xmonad directory <darkpsi>can not find too much infomation on configuring xmonad on guix <buenouanq>the manual configuration info for the certbot service is not inline with the service itself <buenouanq>has erroneous fields like `name' which seems to have been changed instead to `certificates' <buenouanq>can someone post for me an example certbot-service-type declaration please? <darkpsi>hey having some trouble getting xmonad to work the slim does not seem to know how to handle xmonad has any one got xmonad working? <iyzsong>darkpsi: xmonad doesn't provide a desktop file, so it's not detected as desktop session by slim. you can put something like 'exec xmonad' into the ~/.xsession script to start it manually. <buenouanq>If I have different/multiple webroots and domains, do I need a separate certbot-service-type for each?... <efraim>There might be examples in the guix-maintenance repo ***Gamayun_ is now known as Gamayun
<snape>buenouanq: no, you need only one certbot-service-type <snape>'certificates' takes a list of 'certificate-configuration' records, each of them being associated to many domains ***dddddd_ is now known as dddddd
<vagrantcish>so, i installed libvirt, added a service for it, and it started running. had some issues connecting to it with virt-manager that seemed to be polkit related. but after a reboot, libvirtd gets disabled, respawning too fast... <vagrantcish>i'm not sure where to look for information about why it's restarting ... /var/log/messages is pretty minimalistic <snape>zero21: what command do you run? <zero21>sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild but i think any command with ./pre-inst-env wont work <zero21>./pre-inst-env guix import gem ruby-jekyll also doesnt work <zero21>its like i need to do something to enable it before i use it <zybell>you are on guixsd and want to do something *before* installing guix? <roptat>./pre-inst-env is a script in guix sources <roptat>on guixsd you don't need that because guix is already installed <roptat>if you want to add packages to guix, you first need to clone guix sources, then you will have pre-inst-env <roptat>(notice ./ before the command? it means it's a file in the current directory) <roptat>you won't have the script before you get the sources <zybell>if you want to follow this you need to do the git clone. <vagrantcish>if i'm already running linux-libre 4.16.x, why would a new "guix system reconfigure ..." be rebuilding linux-libre-4.15.x ? something else that depends on the headers, maybe? <sneek>catonano, you have 1 message. <sneek>catonano, ArneBab says: autotools is pretty nice, but it is hard to find clear documentation because lots of half-truths are floating around the net and it misses clear guides "how to do X nicely with autotools". <vagrantcish>catonano: in fact, way more helpful than the topic at hand, even ... a real-world example of how to look up some things <vagrantcish>like: guix package -p /run/current-system/profile -I <vagrantcish>trying to figure out how to do that sort of thing for a while :) <zybell>and a new insight: libvirt needs logging <vagrantcish>would libvirtd be disabled while "guix system reconfigure" is in progress <vagrantcish>both libvirtd is running, and my user in the libvirt group can access it <zero21>did i understood right that: to create a new package that isnt in guix repository and definiton of that package was made with use of guix import command, i will have to do "git clone https://git.savannah.gnu.org/git/guix.git" to get pre-inst-env script without which it is not possible to make packages. Or i am mistaken? <zybell>it is not possible to make packages *the way you have chosen* without pre-inst-env <zero21>but there is other way to do packages? <roptat>svn-fetch looks unreliable. I get a different hash every time I try to download a package <roptat>or you can have a file with the package definition and load it with guix package <roptat>but the way you want to do it is the best I think <roptat>because then it's easy to send a patch <catonano>vagrantcish: are you uusing a local checout ? I would "make clean" and then "make -j 4" again <catonano>vagrantcish: are you on GuixSD or Gix on a foreign distro ? <catonano>vagrantcish: ok. Are you using a local guix checkout ? <rekado>vagrantcish: did you download the Guix sources and use “./pre-inst-env”? <catonano>vagrantcish: did you clone thhe guix git repository on your local disk ? <rekado>vagrantcish: oh, if you’re using “guix pull” the answer is likely “no”. <vagrantcish>rekado: no, but i did the steps leading up to that in order to try and answer someone's questions earlier with pre-inst-env <vagrantcish>yes, i have a local clone, but i mostly just use that to look at the guix changes, and hope to someday actually start making patches <catonano>vagrantcish: ok. Then I don't now why you envirroinment won't work <vagrantcish>but i did "guix environment guix" and ran autoreconf -i && ./configure <catonano>vagrantcish: ok. And did that work ? Or did it produce any error ? <vagrantcish>catonano: it worked, and produced the pre-inst-env file, which was my goal at the time ... but i never called ./pre-inst-env <catonano>vagrantcish: you need to run make before you can call pre-inst-env <catonano>vagrantcish: I suppose the error produced by guix pull is not related <catonano>vagrantcish: it's the same error: util-linux-2.3.1.1 unbound variable <catonano>vagrantcish: I sugget you to write on the help mailing list, as pecisely as you can <snape>vagrantcish: can you paste the command you run? <snape>so... ln -sf /some/other/guix /home/vagrantcish/.config/guix/latet <snape>but did you try with pre-inst-env ? <vagrantcish>snape: i deleted all the stuff that "autoreconf -i && ./configure ..." generated <vagrantcish>and i don't have the packages installed to regenerate them without ... guix environment <snape>then you can have a look at the one your daemon is using <vagrantcish>so, should i generally be cautious about running guix commands while in a guix git checkout? <snape>you should be cautious at not removing the Guix you are using I guess <buenouanq>snape: so that's a good example of multiple domains on the same webroot, but what about different webroots? <snape>buenouanq: the webroot that is in the example isn't the same you are talking about, I believe. <snape>it's the one that is used to communicate with Letsencrypt to update the certificates <snape>whereas I think you are talking about webroots of sites that use certificates <snape>but the Certbot service doesn't need to know about them <buenouanq>that would make sense except the webroot I'm talking about has to be provided (with -w (in addition to the domains using -d)) when you call certbot by itself. <snape>so why would you need two of them? <buenouanq>because I'm serving multiple different wobsites in different places <snape>and those services are hosted on the same machine right? <snape>so you need only one '-w' webroot <buenouanq>but they're not servered from the same webroot... <snape>the point of that webroot is to serve files related to letsencrypt, that are used to renew certificates <snape>it's not the webroot of your sites <snape>it should typically be "/var/www/certbot" <snape>if, say, you host three websites <snape>site1, site2 and site3, you would have 4 webroots <snape>/var/www/site1, /var/www/site2, /var/www/site3, /var/www/certbot <buenouanq>ok then - I guess I'm confused on what this actually does then, but that does clear up my question. thank you <vagrantcish>is using --keep-going dangerous with guix package -u or guix system reconfigure ? <vagrantcish>my thought was to complete all the things it can, rather than fail on the first failed build <snape>buenouanq: yw! Basically, certbot has many ways to renew the certificates. The one we chose is to place authentication files in Nginx's webroot. We chose it for its simplicity. It's not ideal, but it works for now. <snape>It's not ideal because it requires a web server to be running. <snape>vagrantcish: yes, it's the intended use. It will fail, but later. <vagrantcish>anyone know how to configure macvtap for guix's libvirtd/virt-manager ? <dustyweb>I can't upgrade my server because it OOMs <dustyweb>I guess I should scp over an enclosure of the system tthat I build from my desktop <mbakke>dustyweb: `guix copy` is handy for that, though you need to copy the ungrafted derivation. <dustyweb>mbakke: hm, guix copy? I'm not familiar with that one... <mbakke>I just checked the `guix copy` help text, perhaps it could omit the build-related options :P <vagrantcish>so, is guix pull --url=/my/local/repository --commit=COMMITHASH a reasonable way to build custom packages? <rekado>vagrantcish: I’d use GUIX_PACKAGE_PATH instead. <vagrantcish>oh, yes, that's much nicer. not having to rebuild guix every time you tweak a package... <ngz>Hello. I'm trying to package some software that requires PyQt. I added it to the dependencies and build is ok. However, when trying to run the software I get the error "pkg_resources.DistributionNotFound: The 'PyQt5<5.10,>=5.9' distribution was not found". <ngz>I guess I have to somehow point to the appropriate location for PyQt at run time, too. <ngz>What would be the preferred way to do that ? <ngz>Note that I tried to put pyqt to propagated inputs, to no avail. <taylan>which package contains the command 'xset'? <ngz>taylan: I would say "xset" <taylan>ngz: I could have sworn that package doesn't exist :| thx ^^ <dustyweb> 273:18 1 (send-files #<build-daemon 256.97 25a5e60> _ _ # _ # _) <dustyweb> 397:8 0 (node-eval #<node cwebber@192.168.10.232:22/37146 53b8…> …) <dustyweb>ssh/dist/node.scm:397:8: In procedure node-eval: <dustyweb>Throw to key `node-repl-error' with args `("Evaluation failed" "scheme@(guile-user)> While compiling expression:\\nERROR: no code for module (guix)\\nscheme@(guile-user)> " ())'. <dustyweb>I just did a make clean of guix and a rebuild <dustyweb>can someone else test against guix master and see if they're hitting similar problems? <efraim>good news, looks like the keepassxc-browser integration works with our keepassxc package <efraim>i assume kari is an ssh alias for an actual machine <efraim>guix copy: error: SSH authentication failed for 'git.flashner.co.il': Access denied. Authentication that can continue: publickey,password <efraim>i still normally use 'guix archive --export --recursive $(guix build --no-grafts foo) | ssh other-machine guix archive --import' <rekado>dustyweb: you need to make sure that the remote guile process is started in an environment where GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH are set such that the (guix) module can be found. <rekado>dustyweb: this may require creating an /etc/environment file containing definitions for these variables. <rekado>dustyweb: after changing /etc/environment make sure to kill the listening guile process <dustyweb>rekado: could you paste such an /etc/environment <dustyweb>and also, I wonder if I should have my guix system configuration have those <vagrantcish>well, built my first derivation ... arm-trusted-firmware-rk3399 ... still struggling with u-boot-firefly-rk3399 <zybell>ssh sets an env from file in $HOME <vagrantcish>i should probably actually read some guile intros or something at this point <taylan>is there something like 'guix pull' for the system-installed guix? the closest thing I can think of is running 'guix pull' and 'guix system reconfigure /etc/config.scm' as root, which will make the system-installed guix almost up-to-date but not entirely :) <buenouanq>taylan: that's how it's done and as uptodate as you can possibly get <taylan>buenouanq: my understanding is that this will install the version of guix that's currently declared latest in the package DB, which can't be the latest commit because of the chicken-and-egg problem. (in theory it could be the fore-last commit, but that would mean you need to update the guix recipe with every single commit to reference the previous commit, which obviously isn't done.) <rekado>zybell: this is Guile-SSH, so it’s a possibility that it does not read this file. <rekado>dustyweb: I needed to do this on the build nodes of berlin.guixsd.org. <dustyweb>zybell: hm... seems you need to set an sshd config option to enable .ssh/environment <mbakke>taylan: by "system-installed", do you mean for users that haven't run `guix pull`? <taylan>since it takes a lot of time, even on this super new laptop I have from work <mbakke>taylan: IIUC Guix will use the embedded "snapshot" (the "guix" package) if no local package definitions are found. <taylan>on a single-user system, you'll need to run it at least once with root to update the system, and once with your normal user to update your packages... <mbakke>Though admittedly I'm not very familiar about how that works. <mbakke>taylan: With the recent `guix pull` improvements, at least you don't have to actually build everything if another user already built the same commit. <mbakke>I sometimes just update the `~/.config/guix/latest` symlink manually though.