<lfam>jeko: That causes nginx to reload its configuration without restarting
<jeko>lfam: Ok so I guess I miss a step because I don't get why it needs to do it
<lfam>Presumably it would be used when the configuration has changed
<lfam>IIRC, that is not actually useful in Guix, however, because the configuration is referred to by the full store path, rather than a well-known path like '/etc/nginx/nginx.conf'
<lfam>I don't know if that's still the case or not
<jeko>I can confirm it refers to the store path one
<lfam>It could be useful for renewing certificates, because they should be named by a well-known path instead of being kept in the store
<lfam>So, assuming you are using certbot+nginx, the deploy hook should run after certificate renewal. That way the new certificate expiration will take effect, but the server won't have to restart or drop any connections
<jeko>Or I could make the nginx-deploy-hook to reconfigure the system to handle ssl and then restart nginx!?
<jeko>oh ok, it is to update the certificate expiration date…
<dftxbs3e>That's what I am trying right now, should work
<dftxbs3e>marusich, for big endian, it would be nice to rebuild for reproducibility with a known GNU Guix System and GNU Guix configuration and version
<dftxbs3e>I think GCC is reproducible in that case, my tests didnt indicate the contrary
<marusich>I see. I can try that. I'm not sure I can build two separate Guix Systems from scratch (I found that I wasn't even able to run "guix pull" successfully without substitutes enabled, from various recent Guix releases). However, I'm sure I can if I use substitutes...they will just share many built artifacts, which could mask reproducibility problems.
<marusich>If you can give me access, I can run the experiments to build the big endian bootstrap binaries on two separate guix system VMs.
<dftxbs3e>marusich, let's do that, it has Proxmox installed so I can create you an account where you can create your own VMs, it's almost unused besides a GNU Guix install on the baremetal (alongside Debian Buster, not GNU Guix System)
<marusich>That would be great! Thank you. I'll shut down my little money-grubbing EC2 instances for now, then.
<marusich>I should probably get another x86_64 bare metal machine for myself for experiments. I keep holding onto old laptops that break, and they are never very fun to work with...
<cbaines>dftxbs3e, if you're looking for things for it to do, it could run a Guix Build Coordinator agent to build packages for patches/staging/core-updates
<marusich>It's good to be here! I've been pretty busy with work and life the last few months, so I haven't had much time to hack on things. What time I've had has been spent trying to get POWER9 to work, with less than great results as you know... I'm looking forward to moving on and experimenting more with bootstrapping, though.
<civodul>yeah this POWER9 bootstrapping story has been quite a ride!
<civodul>but as you wrote, let's move on to the more exciting stuff
<efraim>I for one am excited to have more architectures that I didn't bring in :)
<marusich>We'll get it. It just sucks not to be able to pin down that reproducibility problem.
<civodul>yeah but sometimes we have to admit a possibly temporary defeat :-)
<dftxbs3e>marusich, that patch you linked is the one I am rewriting, it's accounted for
<civodul>lle-bout mentioned that it has to do with the kernel version (!)
<marusich>Yes, that's true. I'm optimistic that we can get things boostrapping nonetheless.
<dftxbs3e>civodul, actually it was someone in the ML that mentioned it before and I happened to test it and it seems correct
<marusich>It was pretty frustrating, that's for sure.
<marusich>I feel exhausted just thinking about it... Anyway, I'm looking forward to trying to use what we have.
<marusich>dftxbs3e, understood re: the patch. so the plan for now is to do a fresh build of the powerpc64-linux-gnu bootstrap binaries on two separate guix system vms, hopefully confirm they are identical, and then use them. And repeat the process for powerpc64le-linux-gnu, after applying to master (or core-updates) the patch you are currently authoring.
<euandreh>civodul: I have Guix on a foreign distro, so $GUIX_PROFILE is defined. But that also means that using a tarball from a "guix pack -R" command requires me to use "GUIX_PROFILE= source etc/profile". For anybody without $GUIX_PROFILE defined, the tarball works
<euandreh>civodul: I guess the 110% failproof way would be to build the pack with '-RR', and to source the profile with 'GUIX_PROFILE= ' prefix. This way I'm always sure the tarball will work, no matter the system (with or without user namespaces) or environment variables (with or without $GUIX_PROFILE defined)
<janneke>bah, mescc-tools-0.6.1 build system changed again
<civodul>euandreh: so, when GUIX_PROFILE is defined, etc/profile simply adds the wrong file names to $PATH etc., right?
<roptat>during the build, you could copy the output of the first package, or fix the server to hardcode the location of the .js file you built
<roptat>no, we disable network in our build environment, to ensure reproducibility
<argylelabcoat>right, which makes 100% sense except when I want to do something really stupid like this
<argylelabcoat>obviously the "correct" path is to convert the package-lock into a guix file
<roptat>right, we need some sort of importer, but I can't see this happening any time soon
<argylelabcoat>but for some reason, the package-lock isn't even that deterministic... it has versions with wildcards everywhere
<argylelabcoat>so I've been parsing that, and I'm getting there with version matching, I'm down to maybe 20 nested dependencies not matching the version numbers quite right yet
<argylelabcoat>but I'd like to just make some progress even if it's naughty, hence my asking the question
<roptat>well, it's like the *2nix tools: you'd use this information to build a dependency tree for the current versions, and keep the result around, then update whenever you want to (and rebuild the npm world ^^')
<argylelabcoat>my tool 100% depends on having the package-lock, but I appreciate that all the dependencies are listed along with urls to tarballs
<argylelabcoat>I got to the point where ^1.0.0 and ~1.0.0 type wild cards work, but apparently some jerks do 1.X.X or simply 1 || 2
<aecepoglu[m]>When using install-file or `make install`, where should I be copying the files? I am attempting to overwrite the `install` phase of `gnu-build-system` for a package that doesn't have it; where should I be copying the files to? Is there an understanding of SRCDIR or DESTDIR?
<nixo_>aecepoglu: the output dir is usually (assoc-ref outputs "out"), there you can create /bin, /lib etc folders
<roptat>aecepoglu[m], on other distros, you'd have --prefix=/usr on the configure phase, but for guix, we replace by /gnu/store/... (which is what (assoc-ref outputs "out") gives you). so instead of /usr/bin, we have /gnu/store/.../bin etc
<civodul>wehlutyk: "build GLMakie" means that Julia builds the thing for you, right?
<civodul>how does it do that? like what C/C++ compiler and libraries does it choose?
<wehlutyk>yes, though they have a few pre-built artefacts in that process apparently too
<nixo_>civodul: I'm sorry I never used makie, but we have the julia-build-system (which nobody is still using XD) with which I build some julia program with binary dependencies, so I guess it would work for makie too.
<wehlutyk>I'm not that sure now that you ask, I get the feeling anything can go in 'building' a package. In this case I'm still checking but it doesn't seem to be actually compiling anything
<euandreh>responding from earlier, civodul: when $GUIX_PROFILE is defined, etc/profile is a noop
<dissoc>what is the best way to develop services? currently i am making changes and pushing it to a channel and then pulling. and on error i get exceptions that are really hard to understand (no line numbers etc)
<dissoc>there has to be a superior workflow to what im doing now
<argylelabcoat>well, mbakke, looks like my current solution is to move to yarn rather than npm, and use the yarn offline mirror mode, where the offline mirror is a guix derivation containing tarballs of all of my deps
<leoprikler>dissoc: you should probably try "-L /path/to/channel" before making public commits
<leoprikler>If you're working in the Guix repo itself, try pre-inst-env
<logiz>hey all, am I reading this right where I can take the guix package manager from a foreign distro (fedora), write a systemconfig.scm setup my partions manually then run `guix system init` pointing to the mount and the system is now useable on a reboot?
<roptat>when defining a phase, you need to tell it what variables you want, something like (lambda* (#:key outputs inputs #:allow-other-keys) ...) will make outputs and inputs available to the phase
<roptat>maybe share what you're doing, that might be easier :)
<roptat>use paste.debian.net or similar, don't paste hundreds of lines here :)
<aecepoglu[m]>And does the chdir happen inside the `install` phase or prior to it? From what I see when my install lambda runs my cwd is not inside the `source/`directory
<aecepoglu[m]>We can do a paste. Let me have another go or two at it :)
<roptat>it happens in the unpack phase, the very first phase
<roptat>although, it won't enter a subdirectory, it either enters the `source` directory if your source is from version control, or the first directory in the decompressed archive if it's a tarball or zip file
<roptat>if you're outside that, then there must be another chdir somewhere, maybe in a custom phase or in the build system you're using
<aecepoglu[m]>True, arguments is just a big list within which I have unquoted my variable `my-var` at a few locations.
<civodul>it looks... interesting, sorta like CONDA maybe
<aecepoglu[m]>I was getting confused because I was treating my lambda within the code as if it is a scheme code an not quoted code. So I had two quasiquotes nested and I was trying to unquote my variable and failing to do so. I think I actually grasped how quotes work now. Thanks roptat :)
<rekado_>civodul: uh, no, haven’t read about it. I have reached CONDA saturation.
<clone11>I can't system reconfigure after pulling today, I get "build of /gnu/store/kh19r1pwqmzh2cr8mx5cphii5rq91nxv-module-import-compiled.drv failed" which looking at the log, is caused by "ice-9/boot-9.scm:3300:6: In procedure resolve-interface: no code for module (gcrypt hash)". Anyonoe else seeing this?
<euandreh>civodul: I'll send a message to help-guix to discuss more about this $GUIX_PROFILE etc/profile issue
<rekado>guixy_: are the variables set in /etc/environment? And does your sshd read /etc/environment? (Some are configured not to do that.)
<lfam>Is it possible to double-check that ci.guix.gnu.org is building the 'staging' branch? I notice that it claims to have built nothing for evaluation 19581, which is more than a week old
<guixy_>rekado, /etc/environment is empty. What should I look for in /etc/ssh/ssh_config?
<lfam>And the most recent evaluation is 2 days old, but still "in progress"
<rekado>guixy_: on my systems I set GUILE_LOAD_COMPILED_PATH and GUILE_LOAD_PATH in /etc/environment; note that I’m talking about the config for sshd not for the ssh client program.
<rekado>guixy_: sshd_config has “AcceptEnv”, which can limit the variables that may be accepted for SSH sessions.
<civodul>mbakke: woow, i'm not sure i understand what's at stake with this patch
<guixy_>I set up the variables in /etc/environment. I set up /etc/ssh/sshd_config to accept GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH. Now ssh email@example.com env | grep GUILE shows that the variables are there. It still says there was a protocol error..
<Thrilleratplay_>I'm stumped on something. I am creating a package and want to modify the configure build phase to download a file into the build directory after extraction. Maybe use copy-build-system but cannot find any examples where two build systems are used together. Can anyone point to a similar package/channel?