IRC channel logs


back to list of logs

<Sleep_Walker>is master building correctly for you?
<Sleep_Walker>no, in general
<Sleep_Walker>it will be on my side probably
<siraben>When I run "guix challenge" all my packages are inconclusive
<siraben>How do I resolve this?
<vagrantc>manually build some of the targets that you downloaded from the substitute servers?
<vagrantc>e.g. guix build --no-substitutes SOMEPACKAGE
<vagrantc>i *think*
***bavier is now known as Guest67244
***bavier`` is now known as bavier
<siraben>If I manually build it, can it be checked for consistency through "guix challenge" ?
<vagrantc>i think guix challenge compares the build results built locally against build results produced by other machines.
<bavier>vagrantc: yes
<siraben>I built everything from source before and it still didn't work.
<siraben>Does building from source mean "guix package -i ..." without authorizing substitues?
<siraben>Or "guix pacakge --fallback -i ..."
<bavier>siraben: if you haven't authorized substitutes, then yes, the packages will be built locally
<siraben>Should I be concerned about "guix challenge"?
<siraben>Are the packages I downloaded the same as on the sever?
<bavier>siraben: they should be :)
<siraben>So no course for alarm the
<bavier>siraben: 'guix challenge' is useful the more people use it, because it can help us fix reproducibility problems
<siraben>I have inconclusive package sthough
<siraben>What would I need to do to get "guix challenge" to work properly?
<bavier>"inconclusive" I think means that the server does not have the same store item you do
<siraben>Ok I have 1 identical package, 446 inconclusive
<bavier>which depends on what guix version you have and how up-to-date the server is on its builds
<siraben>bavier: So what does "guix challenge" say for you?
<bavier>idk, let's see...
***bavier`` is now known as bavier
<siraben>bavier: What's the output?
<bavier>siraben: "updating list of substitutes ... 57%"
<bavier>network is a bit slow too, doesn't help
<siraben>bavier: Let me know what it says
<bavier>siraben: just finished
<bavier>siraben: 4.1% identical, 0.1% differed, 95.8% inconclusive
<siraben>The inconclusive part is what I was worried
<siraben>So it's not just me
<bavier>yeah, those are all: "no substitute"
<bavier>so the build server doesn't have anything to compare against
<siraben>So, they were all built from source?
<siraben>Guix should do a collaborative style of checking, a sort of peer to peer hash check
<siraben>Kinda like BitTorrent
<siraben>Otherwise we are left with inconclusive
<siraben>Any Guix devs here? Can more builds be available on the substitute server?
***bavier`` is now known as bavier
<Digit>sometimes... participating with free software, feels like participating in technological development in the star trek next gen universe
<Digit>ACTION dreams of lcars in guix
<Digit>ACTION dreams of lcars in guile*
<siraben>Digit: What is lcar?
<siraben>Digit: Reminds me of
<siraben>The participating in free software part^
<Digit>lcars is the user interface in star trek next generation (and ds9 & voy).
<siraben>Why do you dream of it in guile?
<Digit>just happened to see reminder of guile in passing while thinking of it, and remembering seeing various projects (prominently including guix) that make it seem like a good idea, friendly and tractionable, reconfigurabliscious.
<Digit>also, i suppose hearing someone go on about how ace racket is for guis, i think it might be nice for guile to have some novel gui flexing too. but mostly i think it just a chance passing and melding of two notions.
<vagrantcish>i just ran guix pull and it started downloading the bootstrap binaries as part of the process ...
<vagrantcish>maybe i accidentally disabled substitutes or something
<siraben>vagrantcish: I found that substitutes don't actually help that much...
<siraben>Literally my guix challenge says 99.6% of packages were not substituted
<nckx>siraben, re: substitute decentralization: that thread seems to have stalled waiting for volunteers. Help very welcome!
<siraben>nckx: Huh, I have an idea of how it would work but don't how the current knowledge to write it
<vagrantcish>siraben: i don't know what you mean by not helping much
<nckx>siraben: sounds like a configuration issue; should be closer to 10-20% on average if you're anywhere close to master.
<siraben>vagrantcish: Most of the packages you download initially are build from source anyway
<siraben>nckx: I just did a guix pull
<vagrantcish>depends on your configuration
<nckx>Even 20% is a lot.
<vagrantcish>i frequently get most of the packages downloaded from substitutes
<vagrantcish>though, the more often i run guix pull, the more often a substitute hasn't built it yet
<siraben>vagrantcish: How do I check if substitutes are working correctly?
<vagrantcish>siraben: you said you initially built without substitutes?
<siraben>It did it automatically
<vagrantcish>admittedly, sometimes guix pull surprisingly does a lot of changes for reasons i don't quite grasp, but i'm a novice
<siraben>Despite following the section of the tutorial that allowed me to authorize substitues
<siraben>nckx: Should I start a thread on the mailing list?
<siraben>On substitue decentralized
<vagrantcish>siraben: normally substitutes are enabled out of the box; i've never had to do anything to explicitly enable them
<nckx>siraben: We'd like use something like IPFS or Gnunet to distribute substitutes, eventually.
<vagrantcish>siraben: so maybe somehow you misconfigured your substitutes
<siraben>vagrantcish: Darn, well, it still works but I'd like to use substitutes
<siraben>Saves compile time :)
<siraben>nckx: Interesting. Is Gnunet gaining more traction now?
<nckx>siraben: There's at least one thread about it already, I suggest reading the archives to decide whether or not to start a new one.
<siraben>nckx: Alright.
<nckx>siraben: I think most here are sympathetic to Gnunet, but I don't know enough to say whether it's a realistic solution in the near future.
<vagrantcish>i've actually built my first custom guix package ... and tested that it works ... u-boot-puma-rk3399 arm-trusted-firmware-puma-rk3399 and rk3399-cortex-m0 ... i actually might have something contribution-worthy :)
<nckx>ACTION is going to bed, it's 7:00 here -_-
<vagrantcish>(as well as some other arm-trusted-firmware and u-boot targets, but this is the first i've tested)
<vagrantcish>so, i am admittedly surprised that "guix pull" is building perl.
<siraben>nckx: Another project on decentralization which I use quite often is Zeronet
<siraben>The websites uses a lot of words like "Bitcoin cryptography" and "BitTorrent network", but you'd be surprised as to how easy the software is to install, how good the UX is and how fast it is
<siraben>IMO if Gnunet wants to succeed it needs to be easy to use, if not, even easier.
<vagrantcish>and subversion ...
<siraben>And subversion, ofc
<vagrantcish>why does guix need subversion to build itself?
<siraben>Problem is subversion is limited in scope and it's difficult for non-technical minded to use, I think.
<nckx>vagrantcish: maybe (un)expected fallout from 217b8c2e? Just a wild guess after looking at the log.
<nckx>ACTION → zzz
<vagrantcish>nckx: yeah, that's between my last pull and this one
<vagrantcish>hah. NOTICE: BL31: Built : 00:00:01, Jan 1 1970
<vagrantcish>this firmware was built decades before the hardware ;)
<efraim>perl is because the graft for perl 5.26.1->5.26.2 was pushed, so it needs to be built to be replaced, subversion because our git is built with subversion support, and we have git->guile-git->guix
<Sleep_Walker>I'm really lost on this -
<Sleep_Walker>any ideas why it fails?
<Sleep_Walker>it's after make clean
<vagrantcish>efraim: thanks for the analysis
<efraim>Sleep_Walker: maybe a stray .go file?
<Sleep_Walker>efraim: can I force ignoring "stray .go file"?
<Sleep_Walker>(stray .go file means that is no longer valid, but still used?)
<efraim>probably not, but after a 'make clean-go' it is supposed to tell you if you have any left
<efraim>right, either referencing a function that is gone or a file that was renamed
<efraim>after 'make clean-go' i normally double check with "find . -name '*go$'"
<Sleep_Walker>thanks for hint
<Sleep_Walker>I removed stray .go files but still have problem :(
***matija is now known as kons
<rekado>Sleep_Walker: does this also happen with serial make? Are you using parallel make?
<mbakke>Sleep_Walker: Is your checkout clean?
<mbakke>I get a similar problem when I try to import (gnu packages rust) in (gnu packages gnome). Didn't figure out the circular dependency yet. Are there any tools for that?
<mbakke>Sleep_Walker: I'm traveling today, but will review the updated patches tomorrow (or late tonight).
<mbakke>Regarding circular dependencies, maybe it would help to move the wildly popular compression libraries that don't have dependencies to their own/a separate module.
<rekado>mbakke: Chris had a patch to display dependency cycles, but I don’t know what came of it.
<rekado>“Package input loop detection”
<mbakke>rekado: would that help solve Guile module cycles?
<rekado>I’m not certain. But you could try applying the patch and see if it helps.
<mbakke>Try adding "#:use-module (gnu packages rust)" in gnome.scm to see what I mean.
<rekado>I know that we sometimes have these weird loops.
<rekado>I also saw this when working on (gnu packages cran) or (gnu packages machine-learning).
<mbakke>I've had those weird dependency loops with Python packages, but this is on the Scheme level.
<rekado>these module loops shouldn’t happen.
<rekado>we had them more often in the past when we would #:select or #:hide packages
<rekado>removing all of these qualifiers reduced the likelihood of these loops, because all module lookups would be performed lazily (IIUC)
<mbakke>Oh no, closing the lid doesn't cause my laptop to enter sleep mode with elogind 235.3.
<mbakke>Note to self: Don't beta test critical system components before a flight.
<mbakke>`loginctl suspend` works however.
<Sleep_Walker>mbakke: thanks for your patience with review
<Sleep_Walker>mbakke: I have never noticed indentation difference before you pointed out - intent script doesn't seem to enforce it neither...
<mbakke>Sleep_Walker: no problem! Does the indent script not work?
<Sleep_Walker>mbakke: I tried it and it fixed some other indentation in the same package
<Sleep_Walker>but not the spot you pointed
<Sleep_Walker>and it seems that in the code both indentation are used
<mbakke>Oh. Probably I just remembered wrong then. Gotta memorize dir-locals.el again ;)
<Sleep_Walker>well, I don't mind to adjust my Emacs to match your taste
<Sleep_Walker>I simply want to be sure your taste matches taste of the rest developers :)
<mbakke>If you use emacs, you can just C-M-q the thing.
<mbakke>Bbl, boarding next flight!
<Sleep_Walker>but that is what I use...
<Sleep_Walker>nevermind, I'll dig
<mbakke>Maybe it doesn't read dir-locals?
<efraim>From what I understand there are a few places where it doesn't quite work right
<efraim>Vim has the same thing, it does The Right Thing most of the time
<Sleep_Walker>interesting is that when I change it to mbakke's preference, indent thingy keeps it that way
<Sleep_Walker>I'm just not sure if it is the only occurence
<Sleep_Walker>or what is the rule behind it
<Sleep_Walker>OK, so it is exactly as indent-code.el wants but not according your taste, mbakke
<Sleep_Walker>I'll wait with push for another opinion
<Sleep_Walker>lfam: hi!
<lfam>Hi Sleep_Walker!
<Sleep_Walker>lfam: could you please tell me whether my indentantion is problem ?
<Sleep_Walker>mbakke and indent-code.el are in conflict...
<lfam>Sleep_Walker: Your indentation (2 spaces) looks correct to me
<Sleep_Walker>mbakke insist on 1 space instead
<Sleep_Walker>lfam: thanks for confirmation!
<efraim>As far as source & origin I normally compare against other packages in the module
<Sleep_Walker>efraim: I'm more concerned about functionality of the tool which should be used
<buenouanq>I'm having trouble with nginx.
<buenouanq>herd starts it fine, says everything is running and all the configs are ok
<buenouanq>but netstat shows nothing listening on the relevant ports
<buenouanq>(service nginx-service-type (nginx-configuration (file "/etc/nginx/nginx.conf")))
<buenouanq>is what I have in my main config.scm
<snape>buenouanq: I guess ps -ef
<snape>| grep nginx shows nothing?
<snape>(my new american keyboard makes me pressing "enter" when I want to press "|" -_-')
<buenouanq>snape: no, it's there
<snape>can you share your conf file?
<buenouanq>which one?
<snape>the nginx one
<snape>buenouanq: you can use for example
<buenouanq>the server block at the bottom is in a file in /etc/nginx/sites-enabled/
<snape>buenouanq: shouldn't the server block be in the http block?
<buenouanq>it is, that's the include at the bottom
<snape>well, can you share it?
<buenouanq>i did, everything but the mime type file is there
<snape>oh got it
<buenouanq>it's nothing special or weird, this config was working last week
<buenouanq>when I system reconfigure it does spit out this:
<buenouanq>nginx: [alert] could not open error log file: open() "/gnu/store/rbf5cqj01xgd707ii377ksx453vvhs9m-nginx-1.13.12/logs/error.log" failed (2: No such file or directory)
<snape>this sounds like a normal warning
<snape>what does nginx -c /etc/.../nginx.conf returns?
<buenouanq>but then it says
<buenouanq>nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
<buenouanq>nginx: configuration file /etc/nginx/nginx.conf test is successful
<buenouanq>and moves on.
<buenouanq>-bash: nginx: command not found
<snape>well, you need its full path
<snape>the one you can see with "ps auxww | grep nginx"
<snape>plus, you need to "herd stop nginx" first
<snape>(also, what is the netstat command you typed?)
<buenouanq>ok, so that ps command seems to say it's using the config in the /gnu/store and not mine...
<snape>That might explain some things
<snape>you need to stop it before reconfiguring
<snape>did you know about this?
<snape>if you modify a service and reconfigure, it won't change anything
<buenouanq>nginx: master process /gnu/store/rbf5cqj01xgd707ii377ksx453vvhs9m-nginx-1.13.12/sbin/nginx -c /gnu/store/gbxwrq8cxfq2pdj6skbpz5sv65paw6ab-nginx.conf -p /var/run/nginx
<snape>you need to first stop the service and then reconfigure
<buenouanq>well, that prolly has a lot to do with this then
<g_bor>Hello guix!
<snape>(it's a security, to avoid breaking things on reconfigure)
<snape>(on my TODO list there is a note about improving it but I still haven't found the time)
<g_bor>I'm currently trying to make the java-aqute-libg testsuite working.
<snape>hello g_bor
<buenouanq>snape: wow, that was all it was
<buenouanq>thank you
<snape>buenouanq: you're welcome!
<g_bor>I have a test failure, and I'm not sure if it is a real problem, or not. Anyone online who knows how libg is supposed to work?
<buenouanq>I feel silly - But also, I haven't seen that mentioned anywhere about reconfiguring and service stopping...
<snape>don't feel silly, it's definitely not easy to guess
<buenouanq>my next question is going to involve how the certbot service modifies things - it looked yesterday like it was forcing redirections I didn't want by itself and I couldn't figure it out. But I also didn't have nginx working properly it seems so I'll have to play with it all again first.
<snape>I can't find it in the docs either (although there is a comment about it in the code). It would probably be great to add it then.
<snape>buenouanq: yes it's in the code
<snape>sorry, in the docs
<snape>"Invoking guix system"
<snape>-> 'reconfigure'
<snape>"if a service is currently running, it does not attempt to upgrade it since it would not be possible without stopping it first"
<buenouanq>I feel as a user that if I'm running system reconfigure, I know what I'm doing and want and that that should mean things are killed and reconfigured as needed.
<buenouanq>Just ignoring it with no message/warning seems strange.
<buenouanq>That's maybe the best approach:
<buenouanq>a loud message saying `this service reconfigure will be ignored because it is currently running'
<snape>yes, but some services might be risky to restart, and sometimes you wouln't want them to restart
<snape>the behaviour is definitely not optimal, and it's going to be immproved
<snape>one of the things that we should add is a 'reload' function, that would be safe
<buenouanq>are you an official dev snape? or just someone in the know who hangs out here
<snape>well, I did some patches, if that's what you mean by 'official dev' :-)
<bavier`>there's been some discussion on guix-devel in the past on this topic
<nckx>buenouanq: no ‘official dev’ cabal here, thank god.
<snape>bavier`: Yes I'm trying to find them
<rekado>“guix pull” downloads a frightening amount of dependencies.
<rekado>that’s needed for guile-ssh and guile-git I suppose, but it’s a lot.
<emacsen>I have a dumb question. How does guix ensure that if there's a network request, that it's the same result as someone else's?
<bavier`>emacsen: which kind of network request?
<snape>buenouanq: this is the discussion:
<emacsen>bavier`, if I request eg source code
<emacsen>bavier`, maybe I'm misunderstanding something
<bavier`>emacsen: for source code a checksum is used
<emacsen>seems reasonable
<efraim>ITS ALIVE!
<efraim>now I have to figure out how to SUSE to get the other aarch64 dev board up
<bavier`>emacsen: iirc substitutes have standard integrity checks
<bavier`>Sleep_Walker: did you fix your 'make' issue?
<snape>buenouanq: I think the nginx part of the certbot service won't work if your nginx service use a handwritten nginx.conf
<snape>because Certbot _extends_ the Nginx service. It adds stuff to the nginx Scheme service configuration. It cannot do it if you directly pass a handwritten nginx.conf.
<snape>so you have two solutions: 1. use Scheme nginx configuration; 2. modify your custom nginx.conf so that it handles the certbot stuff
<snape>(it basically looks like this:
<buenouanq>snape: I have basically that in each server already - So with the certbot-service running, I should be able to remove them and just have a block listening on 443, yeah?
<nckx>So the only way to use certbot under GuixSD is to spin up a full HTTP server? :-/
<snape>nckx: Yes, we talked about this already via email. Contribution for other means to talk to Letsencrypt are welcome.
<buenouanq>nckx: no, you can just use the certbot package normally
<nckx>OK, just asking.
<snape>nckx: sorry I didn't mean to sound rude :)
<nckx>s/certbot/certbot service/
<snape>buenouanq: yes nckx was talking about the service
<buenouanq>I've been using certbot without the certbot service...
<buenouanq>oh, ok
<snape>nckx: it's a real issue. I understand that lots of people don't want nginx to be running
<nckx>I use a simple mcron job to run certbot over DNS, I just didn't realise our service was still HTTP-only.
<nckx>You're correct that I could have just seached the archives if I really cared enough to switch, but... the good-enough is the enemy of the better in my case :-)
<snape>nckx: do you think adding DNS authentication would be complicated?
<nckx>snape: That depends on how much our current service assumes HTTP. For certbot, both methods are just plugins on equal footing, I think.
<snape>I never investigated
<nckx>snape: My setup also relies on a custom hook script, but again, that's how certbot is designed so if our service is well-written it should expose all that stuff.
<nckx>Neither have I...
<snape>Our services support hooks
<snape>specifically: deploy hooks
<buenouanq>snape: is there any way to output and see what the certbot addition actually expands to?
<nckx>snape: Cool! Then it shouldn't be too hard. Oh. I don't know what ‘deploy hooks’ are, specifically.
<snape>nckx: deploy hooks happen after the renewal is successful.
<snape>it would restart a service, or copy certificates to their right location for example
<snape>there are other kinds of hooks, like the one you would run before doing the renewal (but we don't need them at the moment I think)
<nckx>Here's the certbot command my script generates:
<nckx>.../certbot certonly --agree-tos --no-eff-email --update-registration --preferred-challenges=dns --non-interactive --manual --manual-public-ip-logging-ok --manual-auth-hook='/etc/guix/certbot/dns-hook auth' --manual-cleanup-hook='/etc/guix/certbot/dns-hook cleanup' --renew-hook=/etc/guix/certbot/renew-hook --keep-until-expiring --expand --must-staple,
<snape>buenouanq: the link I sent is one an example of addition
<snape>otherwise you would need to use a default nginx configuration (or any Scheme configuration) and read it
<nckx>The auth and cleanup hooks call nsupdate to perform the actual DNS magic, so we'd have to generate those too or at least expose a way for the user to provide them.
<nckx>The renew hook is just ‘herd restart foo’ and friends, the least interesting of the bunch.
<snape>nckx: I can't find --renew-hook in certbot man
<snape>I use --deploy-hook for this purpose
<snape>but anyway this is interesting. I'll have a look at this conversation again if I find the time to implement DNS auth
<nckx>snape: Interesting. Perhaps it's an old, renamed option? The code is a year or so old. I'll take a look. Thanks for pointing it out!
<snape>nckx: yes maybe it was renamed and it's backward compatible
<nckx>OK, so the terminology did indeed change from ‘renew’ to ‘deploy’ at some point in the past. I'm not sure whether any semantic subtleties did, too. I'll keep using --renew-hook as long as it works.
<snape>buenouanq: I didn't answer your other question... this is the part of the Nginx service that would do the certbot authentication. If your service is a web service, you would need _other_ server blocks pointing to each of your services' directories.
<snape>those other services would listen on port 443
<snape>for example
<hakano>hi, all. I'm going through the installation manual and I'm having some difficulties
<snape>buenouanq: I'm not sure I'm clear, if I'm not, don't hesitate to say it :-)
<snape>Hi hakano, please go ahead and explain your issues. I'm sure someone will eventually answer.
<nckx>hakano: Shoot! And later, if possible: send bug reports and/or a record of your thoughts while reading the manual for the first time; it's a perspective none of us can recapture.
<hakano>Ok thanks. So the main problem I have while going through the manual: It seems like the entire installation process is done under ~root
<snape>hakano: so you're installing Guix on a foreign distro, right? With ./
<hakano>It seems to me that there are steps that involve setting up the user configuration
<hakano>Here is what I did so far: wget
<hakano>mkdir ~/temp && mv guix...tar.xz ~/temp
<hakano>tar .... guix...xz && sudo mv var/guix /var/ && sudo mv gnu /
<nckx>ACTION fires up ‘info guix’ to follow along at home.
<snape>(oh so you're not using Okay.)
<hakano>I think that I've done correctly, but then I'm not sure if I understand
<nckx>hakano: That all looks good, unless I'm missing a typo. But it's only the beginning.
<hakano>because what I understand: login under root and then do the entire setup and ~/.guix-profile only for root
<divansantana_>how can I troubleshoot sshd not starting on guixsd?
<hakano>with setup under 'root' I mean: ln -sf /var/guix/profiles/per-user/root/guix-profile \\
<hakano> ~root/.guix-profile
<divansantana_>log says nothings. syslogd is running
<hakano>GUIX_PROFILE=$HOME/.guix-profile ; \\
<hakano> source $GUIX_PROFILE/etc/profile
<divansantana_>not famaliar with sheperd
<snape>divansantana_: I heard Shepherd output goes to tty1, but I never tried.
<hakano>and then config the daemon
<hakano>but if I understand correctly: there is nothing to be done for user. And that irritates me.
<nckx>hakano: side tip: command lines starting with $ are to be run as a regular user, # as root. It's a subtle but useful convention. So you are correct.
<snape>hakano: your user should have access to /usr/local/bin/guix
<nckx>hakano: Did you follow ‘Application Setup’ under point 8?
<divansantana_>snape: herd start ssh-daemon basically just says failed.
<hakano>yes I have access to /usr/local/bin/guix. But I have no ~/.guix-profile, is that correct?
<snape>it will be created on your first guix use I believe
<snape>divansantana_: there is a but about it:
<hakano>@nckx: thanks for the reminder (# vs $)
<snape>but it doesn't happen to everyone it seems
<nckx>hakano: It should be created when you install your first package, which if you're following the node I mentioned is glibc-locales. *I think*
<snape>divansantana_: and is a discussion about Shepherd being not verbose enough
<hakano>so basically I went throug this manual
<hakano>and now I'm at step 8 (I left out step 7 hydra stuff)
<nckx>hakano: Sure. The # / $ thing has been a source of confusion for new users before, so I thought I'd point it out :-)
<snape>nckx: you should do step 7, otherwise you will need to build everything, which is very, very, very slow
<hakano>I hope it's OK when I paste my error message after running 'guix': guile: warning: failed to install locale
<hakano>warning: failed to install locale: Invalid argument
<hakano>guix: missing command name
<hakano>Try `guix --help' for more information
<nckx>hakano: Skipping the Hydra stuff is fine if you understand the implications and have a fast machine. Otherwise, highly recommended.
<snape>hakano, what is the output of "guix package -i hello"?
<snape>that would be a valid guix command
<divansantana_> snape: that might be useful. Let me look at that, thanks
<nckx>...or ‘guix package -i glibc-locales’ ;-)
<snape>(even better!)
<nckx>\\ (See Section 2.6.1), or you'll have some annoying warnings causing even more confusion.
<hakano>@nckx the same error (locale ... ) and then this line: guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist
<nckx>hakano: Did you follow the excursion to ‘Build Environment Setup’ in point 4?
<nckx>ACTION notices how many hyperlinks a new user has to follow; probably better than duplicating text, but... hm.
<hakano>cough cough .. no
<nckx>No bigsies. It should be possible to just run those commands now and retry ‘guix package -i’ afterwards.
<nckx>Might have to restart guix-daemon, might even not.
<hakano>nckx I'm throug step 4 and I get 'guix-daemon: cmd not found'
<buenouanq>snape: it does not seem to be issuing the 301 redirect as shown in your paste - I've got my ssl location working, but normal http traffic is a 404.
<hakano>do I have to manually source ~/.guix-profile/etc/profile when I act as ~root?
<nckx>hakano: By restarting it I mean the guix-daemon service on your host distribution, for example ‘systemctl restart guix-daemon’ (I just made that up tho').
<nckx>See point 5 ;-)
<hakano>Ok, I think it looks better now. 'guix package -i hello' as a regular user seems to run now
<hakano>It is still downloading a lot of stuff.
<hakano>yes :-). I think I got scared by 'Build Environment Setup' under
<hakano>not the most beginner friendly text ;-)
<nckx>hakano: If you didn't set up substitution, you'll be downloading everything needed to compile hello from source, and maybe even some of its dependencies. It'll work, but unless you're paranoid and don't
<nckx>whoops. *trust our build farms, substitution is the way to go.
<nckx>Artisanal home-compiled code won't run any better. We make sure of that, even.
<nckx>No -march=native for you.
<nckx>No AVX-accelerated GNU hello for you.
<hakano>nckx after running 'guix package -i hello', how can I run 'hello' as regular user
<nckx>That is great news.
<hakano>ok it seems like with 'export PATH="/var/guix/profiles/per-user/bkb/guix-profile/bin${PATH:+:}$PATH"'
<hakano>I can access 'hello'. Now my question: should I link '/var/guix/profiles/per-user/bkb/guix-profile' to ~/.guix-profile?
<nckx>hakano: I'm afraid that's where I can no longer help you. I don't know how that's supposed to be set up on a foreign disto.
<hakano>how do you (as a regular) user set your environment?
<nckx>hakano: I use GuixSD, which handles such things differently (and automatically). I used to use Guix on Ubuntu, but that was years ago and I don't remember.
<hakano>but do you use ~/.guix-profile?
<hakano>sorry I have to leave for a moment ...
<nckx>hakano: Sure. But I never had to set it up or add it to my .bashfoo.
<nckx>If this really isn't mentioned [clearly] in the manual, I'd consider that a bug.
<Sleep_Walker>bavier`: no, but I rebooted to GuixSD which is not affected so I guess it is specific for state of my OS
<buenouanq>So I see no certbot daemon running, but there is an mcron now.
<buenouanq>Am I to understand that these are related? the certbot service just adds a cron job
<nckx>buenouanq: *Is* certbot even a daemon? Cronjob sounds plausible.
<buenouanq>mcron is stopped though - I assume it wakes itself up somehow to perform the cert checks.
<nckx>Hmm. Sounds less plausible, but *shrugmoji*
<nckx>Never mind. Turns out ‘herd status mcron’ says the same here. TIL.
<buenouanq>so, with regards to nginx configuration
<buenouanq>I've always done try_files blocks within location blocks - This makes sense to me.
<buenouanq>The examples have the try-files up in the server block itself though - This does not make sense to me.
<zybell_>buenouanq: mcron:how would you setup a service (certbot) that is only needed every 30 days?Its what cron is for.
<buenouanq>I just wanted to confirm.
<hakano>hi, I'm still doing my steps and something is not clear to me. There are descriptions in manual that show how ~/.guix-profile is set for root. But I'm not sure if I understand the procesess for the regular user.
<hakano>I could read somewhere that ~/.guix-profile is set automatically when the guix daemon is started. But I think that doesnt work on my machine.
<hakano>I mean should I manually link /var/guix/profiles/per-user/me/guix-profile to ~/.guix-profile? I'm hesitant because there is no description for this.
<bavier`>Sleep_Walker: do you have guix installed to /usr on that OS?
<bavier`>if so, guile is probably auto-loading those installed guix modules rather than the ones from your build tree
<bavier`>just a guess; something I ran into recently
<buenouanq>where all does postgres save it's data and how do I find this out?
<zybell_>I think /var/something/postgresql
<buenouanq>is all I've found
<buenouanq>is that really it?
<zybell_>there could be some config in /etc
<zybell_>But if all is default it may be missing as well
<buenouanq>how do I declare a different postgres version in the main config?
<buenouanq>#:postgresql postgresql@9.6 gives me an unbound var error
<buenouanq>what type does it need to be?