<siraben>When I run "guix challenge" all my packages are inconclusive <vagrantc>manually build some of the targets that you downloaded from the substitute servers? <vagrantc>e.g. guix build --no-substitutes SOMEPACKAGE ***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. <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? <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: 'guix challenge' is useful the more people use it, because it can help us fix reproducibility problems <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`` is now known as bavier
<bavier>siraben: "updating list of substitutes ... 57%" <bavier>network is a bit slow too, doesn't help <bavier>siraben: 4.1% identical, 0.1% differed, 95.8% inconclusive <siraben>The inconclusive part is what I was worried <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>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>The participating in free software part^ <Digit>lcars is the user interface in star trek next generation (and ds9 & voy). <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 <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? <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? <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>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. <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>IMO if Gnunet wants to succeed it needs to be easy to use, if not, even easier. <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. <vagrantcish>nckx: yeah, that's between my last pull and this one <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 <efraim>Sleep_Walker: maybe a 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$'" ***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. <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: 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 <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>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>OK, so it is exactly as indent-code.el wants but not according your taste, mbakke <lfam>Sleep_Walker: Your indentation (2 spaces) looks correct to me <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>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"))) <snape>(my new american keyboard makes me pressing "enter" when I want to press "|" -_-') <snape>can you share your conf file? <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>i did, everything but the mime type file is there <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>nginx: the configuration file /etc/nginx/nginx.conf syntax is ok <buenouanq>nginx: configuration file /etc/nginx/nginx.conf test is successful <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>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 <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. <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>"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>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? <emacsen>bavier`, if I request eg source code <emacsen>bavier`, maybe I'm misunderstanding something <bavier`>emacsen: for source code a checksum is used <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 <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 <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... <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. <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. <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 --email=hostmaster+certbot@tobias.gr --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 --cert-name=www.tobias.gr --domains=www.tobias.gr,tobias.gr <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... https://paste.debian.net/1020899/ 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 <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 ./guix-install.sh <hakano>It seems to me that there are steps that involve setting up the user configuration <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 guix-install.sh. 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 <hakano>with setup under 'root' I mean: ln -sf /var/guix/profiles/per-user/root/guix-profile \\ <hakano>GUIX_PROFILE=$HOME/.guix-profile ; \\ <hakano> source $GUIX_PROFILE/etc/profile <snape>divansantana_: I heard Shepherd output goes to tty1, but I never tried. <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? <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 <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* <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>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 <nckx>...or ‘guix package -i glibc-locales’ ;-) <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. <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'). <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>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 <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>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>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. <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_>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