<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… <jeko>Oh my, there is auto completion for guix environment ! neat… <arh>OK I'm installing Guix now. It's been downloading packages for 20 minutes now. <arh>I hope touchpad works. <arh>WiFi works, hope that means touchpad works too. <mbakke>'vtk' fails on the "ungrafting" branch, seemingly because of FreeType changes <mbakke>I guess we learned an important lesson about API compatibility vs ABI compatibility :-) <mbakke>oh, from reading the gcc 10 strace, it tries to stat 'gnu/store/dlb34bysazjxz6pwz430dxh680cniqpb-gcc-cross-aarch64-linux-gnu-10.2.0/include/c++/aarch64-linux-gnu' (note the missing leading /) <mbakke>hmm, maybe it need sysroot=/ or something along those lines <mbakke>adding --sysroot=/ made no difference, wew <mbakke>ah, this is the crucial bit added by the tlink.c patch, I think; when $LIBRARY_PATH is '=', sysroot is implicitly added according to cppdiropts.texi <ride>arh: How is the experience on guix so far? <dongcarl>issues.guix.gnu.org is down just in case it hasn't been brought up yet <dissoc>what is the best way to run services in a virtual machine or container with guix? is it possible to specify them in the config.scm? <raghavgururajan>dissoc: If they are system-services, you can mention them in config.scm. If they are user-services, you can run them via shepherd. <guix-vits>dissoc: u mean a vm running inside the guix system? <euandreh>the rellocatable pack example from the blog post is failing for me <euandreh>even though the binaries are there, ',use(json)' isn't working <euandreh>that is weird, the $GUILE_LOAD_* variables inside etc/profile look fairly normal <serce>hello. how can i add edit GRUB_CMDLINE_LINUX grub parameter from /etc/config.scm file? <xelxebar>serce: In general, see the `operating-system` reference in the guix manual for this kind of thing. In this case, you are looking for `kernel-arguments`. <serce>xelxebar: thank you. i figured it out. ***iyzsong-- is now known as iyzsong-w
<marusich>I'm doing well. How about you? I'm trying to see if I can build the bootstrap binaries for powerpc64le. <dftxbs3e>marusich, I'm doing okay! Funny I'm doing the same :-) - Preparing the patch for master, see ML. <dftxbs3e>I built them before with patches applied on master but Ludovic applied one of them on core-updates instead where I didnt test and where it does not work so. <dftxbs3e>We finally agreed to get it on master instead! :-) - To avoid affecting many packages I am trying to rewrite it in some special dynamic way. <dftxbs3e>marusich, the IPv6 range given by my ISP has changed for some reason, so if you need access to gentoo-ppc64 (it's still up BTW), you'll just need the new IPv6! <marusich>I have my own Debian-based ppc64le system now, but the more the merrier <dftxbs3e>marusich, oh right you do! :-) - Blackbird? <marusich>Yeah! What should I try building, then, for the bootstrap binaries? What commit and/or patches? <marusich>To close the loop on the powerpc64-linux platform, I can go ahead and do the work in the next couple days to add the bootstrap binaries we built half a year ago. <marusich>I'm wondering what to build for powerpc64le, though, since it sounds like some of the changes are in flux. <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. <dftxbs3e>marusich, I got a powerful 48-core AMD Epyc (7 nm) server we can try on there <marusich>That works. I've been paying for EC2 instances, since they're not too expensive if used sparingly. <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 <dftxbs3e>marusich, still preparing, it will be quick, don't go AFK :-) <cbaines>dftxbs3e, you'll need me to generate a UUID/password, but that's about it <dftxbs3e>marusich, yes because I am trying to make a patch that can be pushed to master without causing world rebuild (libffi is required in lots of places) <dftxbs3e>cbaines, OK! Will have a look at that soon, thank you! <marusich>Got it. So you haven't created a "bug" (for tracking the patch, at guix-patches), about it yet, right? <dftxbs3e>marusich, not yet, I just tested it actually and it worked. So I'll have to submit it just after I got your access ready. <dftxbs3e>marusich, I am setting up a private NAT network since I actually never created any VM on that Proxmox yet <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. <janneke>how do i factor-out code (a procedure) from a build stage without putting it in (guix build utils) <janneke>wondering if we have an example, other than something like make-foo-package <marusich>The procedure just needs to be importable on the build side, right? Is there another module like (guix build utils) that can be imported on the build side? *efraim still needs to figure out the guile-final build on powerpc32 <civodul>janneke: you can always factorize it on the "host" stage <civodul>as in (define foo #~(lambda args ...)) <janneke>marusich: yeah, but the code is very package-specific <efraim>oh, guile-3 transition hit debian ppc, I'll have to update my packages if I upgrade from 2.2 <jonsger>civodul: did you upload the zstd compressed nar somewhere? <dftxbs3e>(poor ludo getting kind of harassed as soon as they are here aaaaa) <marusich>Alright, I need to go to sleep. Thank you civodul and efraim and dftxbs3e for the encouragement re: power9; I'm really looking forward to getting it working! <efraim>iproute doesn't cross compile correctly <civodul>jonsger: no i just fetch the ungoogled-chromium nar, decompressed it, and recompressed it with zstd <rekado_>I’d like to move all my Emacs stuff to a separate profile and use a manifest that is declared inside my init.org. <g_bor[m]>civodul: you told me to coordinate about the commit access for lemes <civodul>(i didn't "tell you", twas just a suggestion :-)) <civodul>so what's the user account on Savannah? <mbakke>rekado_: I have Emacs + extensions in a separate profile managed by a manifest, but don't get what you mean by declaring manifest in init.org <mbakke>I just source the profile at login time, and everything "just works" <rekado_>mbakke: my init file is an Org file. I declare the manifest in there as a Scheme source block that tangles to ~/.emacs.d/manifest.scm <rekado_>a sh source block follows that runs “guix package -p ~/.emacs.d/.guix-profile -m ~/.emacs.d/manifest.scm” <rekado_>I suppose I now only need one more thing to set the environment variables so that Emacs finds packages in that profile <civodul>g_bor[m]: i've added magali as a member of the group; now creating a branch etc. <civodul>how to call that branch? "wip-guix-log"? <mbakke>rekado_: maybe a wrapper script? now I'm tempted to do the same thing, I don't really need EMACSLOADPATH set for my entire session... <mbakke>civodul: the issue with GCC 10 C++ cross-compiling is that it looks for its own headers in "gnu/store/xxx-gcc/include/c++/aarch64-linux-gnu" (note the missing leading '/'). <mbakke>probably because it does prefix the "sysroot" <euandreh>the pack works and has the binaries, but the Guile environment isn't working <civodul>g_bor[m]: i've created the wip-guix-log where Magali can commit <civodul>g_bor[m]: Magali should make sure to check the pre-push hook bit in the "Commit Access" section of the manual <civodul>mbakke: oh, interesting; that's core-updates + gcc 10 upgrade? <civodul>euandreh: could you check $GUILE_LOAD_PATH after sourcing etc/profile? <euandreh>civodul: hmm, curiously it didn't changed <euandreh>before: /home/andreh/.config/guix/current/share/guile/site/3.0 <euandreh>after: /home/andreh/.config/guix/current/share/guile/site/3.0:/home/andreh/.config/guix/current/share/guile/site/3.0 <euandreh>civodul: hmm, I think I got it, the problem is the $GUIX_PROFILE variable <euandreh>civodul: sourcing the file like this works 'GUIX_PROFILE= source etc/profile' <euandreh>the thing is, it looks if $GUIX_PROFILE is already defined before writing to it <euandreh>looking at the build/etc-profile function in guix/build/profiles.scm, it looks like it is the same function used for generating default user profiles <euandreh>and when $GUIX_PROFILE is defined pointing to the current profile symlink, running 'source etc/profile' is a noop <euandreh>this is expected behaviour in a way, but is a gotcha: if $GUIX_PROFILE is defined, sourcing etc/profile won't work <harlchen>hi, i have a freshly installed guix-system and it fails to continue booting on changing clocksource to tsc, any pointers ? <civodul>euandreh: hmm there's no 'if' in etc/profile <civodul>g_bor[m]: if Magali can stop by here, i'm happy to provide guidance <euandreh>civodul: there is in the variable definition: 'export GUILE_LOAD_PATH="${GUIX_PROFILE:-/gnu/store/...}..."' <euandreh>if $GUIX_PROFILE is undefined, use the /gnu/store/... value <jonsger>guix-vits: I don't think that has any impact on icecat. Firefox@Android and firefox@desktop are pretty different, technical wise... <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>this is expected behaviour, just a gotcha for whoever has $GUIX_PROFILE set <aecepoglu[m]>Oh man, took me a while but I just got kak-lsp build and installed using guix. <guix-vits>jonsger: +/-, but about:config is a sacred part of fox-n-forks. will we all die now, on droid? <dftxbs3e>guix-vits, wtf.. why do they act like this.. why in the world..? *jonsger doesn't care that much about android. It's a completly broken eco system... <dftxbs3e>first dropping extension support unless approved explicitly by Mozilla, now this.. <guix-vits>idk, but i just downloaded fox, and found i cannit force dark theme. deblobbed fennec in f-droid glitches on my device, and icecat did not reacted on settings. <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? <cbaines>I don't understand enough about the change to tell why though <civodul>cbaines: it just resolves symlinks on the font file <cbaines>I get something like: (canonicalize-path "/b417a70xw82g7x6gxk608ixw50kc15f0-g?") which errors <civodul>i guess it should be canonicalized relative to store-mount-point and store-directory-prefix <civodul>so it probably works when the store is in the root partition <civodul>but breaks if if it's not, or if you're using btrfs thingies <cbaines>My store is in the root partition, and I get the above failure <cbaines>at least for the basic and patchwork system tests <cbaines>I'm guessing anyone with master up to date at some point today should be getting the same issue <civodul>hmm error: channel-source->package: unbound variable <cbaines>I remember seeing that as well at some point *civodul -> "make clean-go" <civodul>anyone knows why gconf depends on orbit2? <civodul>hey! time to submit a talk for FOSDEM! <civodul>the minimalist and HPC submission deadline is today <civodul>cbaines: broken for me as well, i'll rever <guix-vits>who put the hpc into submission? was nukes used? <civodul>hi PotentialUser-96! Guix is all free software, yes :-) <kmicu>Realtek so firmware is a blob, driver must be libre to include in kernel. <PotentialUser-96>rekado_, Yes, Thanks, which network card do you know that is free (software)? <kmicu>PotentialUser-96: only specific old Atheros cards and a very specific and very old Broadcom b43 card. <PotentialUser-96>Unfortunately I'm not in the US, so I can not buy the products of these brands ... <kmicu>PotentialUser-96: correction: the cheapest thing is to use the stock Linux kernel and don’t buy anything at all but official Guix channels do not provide any support with that. <kmicu>PotentialUser-96: correction: the cheapest thing is to use the stock Linux kernel and don’t buy anything at all but official Guix channels do not provide any support with that. *kmicu is sorry for double posts but somehow pressing RET is faster than eyes noticing diconnection. <argylelabcoat>hey, so weird question -- is there workaround for having a derivation depend on the output of npm ? <argylelabcoat>npm + guix seems to be my own personal hell the past few days <roptat>what do you mean? if you have a derivation with npm as an input, isn't that enough? <argylelabcoat>I have a C++ application that runs a webserver (civetweb) and it hosts this file <argylelabcoat>so I'd like my guix package around this application to also depend on the output of this npm build process <argylelabcoat>I've not had great luck with npm -> nix -> guix via guix import a node2nix output <roptat>but you don't need npm to build that application, do you? <roptat>you could combine both build systems, but that's not very easy or practical <roptat>but you could have two packages from the same source <roptat>one package that uses the node-build-system, to build the .js file <argylelabcoat>I parsed the lock file with python and found over 950 packages in the npm project <roptat>and another that builds the server package. You'd use the first package as an input to the second <argylelabcoat>I might be able to output a guix scm file from the python parsing, but I was curious if there was a convenient way to simply: npm i; npm run-script build... as a build system in guix <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 <argylelabcoat>clearly moving the python code to guile would be a community-friendly thing to do <roptat>we have a guile-semver package that we use for the rust importer, maybe we could reuse it there? <argylelabcoat>see, that sounds nice, I probably should look for a python package right now to do semver <argylelabcoat>I saw guile-json and I am getting better at guile, having written tools to work with password-store for private git-repos in my guix definitions <argylelabcoat>I'm just really rusty at scheme yet, having not touched it in more than 10 years... <roptat>as a very dirty workaround, you could host the output of npm somewhere, and use it in your server package <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 <wehlutyk>(By the way, it's nice to have so many substitutes now!) <rekado_>aecepoglu[m]: is that a problem? “/usr/” is just a useless prefix in the Guix world. <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 <civodul>nixo_: maybe you're familiar with that? ↑ <civodul>perhaps we should arrange so that Julia's packaging tools use Guix under the hood, somehow <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 <rekado_>civodul: I guess we should add that guix.install R function to “r-minimal” in Guix, so that it works out of the box. <rekado_>I guess if it were on CRAN it wouldn’t be quite as useful <civodul>rekado_: yes, sounds like a good idea <civodul>perhaps you can also add it on CRAN, i don't know <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 <nly>creating torrents of /gnu/store (31GB or 29040 items) > 700MB (29897) torrents <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? <logiz>awesome, thanks. Off to guix land I go :) <lfam>logiz: Yes, that's the idea. You should take extra care regarding the bootloader of your system, however <logiz>will do, got a new drive for it <lfam>Should we try to make it work? Skip it? <lfam>Does it represent a real problem with the package? <lfam>I found some packages that seem to address this issue. Hopefully it helps... <civodul>euandreh: etc/profile cannot be a no-op because it systematically augments environment variables, whether or not GUIX_PROFILE is defined <rndd>hi everyone! is there way to set custom image for slim-service-type? <lfam>Hm, I notice a handful of packages in kde-frameworks.scm disable tests related to MIME <aecepoglu[m]>roptat: so if I'm using the `%outputs` assoc list to find path of where to install files, is there something similar that will take me to the srcdir? <aecepoglu[m]>There is an inputs assoc-list but I haven't seen what its keys are <roptat>hm actually no, "source" is the source itself, so it could be a tarball or anything <roptat>usually, the source gets decompressed by the unpack phase, and it also chdir into the top-level directory of the source, so in the next phases, you're already in the source directory <roptat>but if that's what you want, then (assoc-ref inputs "source") :) <aecepoglu[m]>When my modified install is running it hasn't cd'ed into the directory yet <roptat>er... you might be doing it wrong <aecepoglu[m]>It really doesn't matter what I want. I am also trying to have an understanding of how things work. <roptat>also %outputs sounds wrong, because that's a variable from the host-side, not from the build-side <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 <mbakke>a-ha, GPLUSPLUS_TOOL_INCLUDE_DIR somehow gets configured wrong for GCC 10 *civodul cheers at fearless mbakke <aecepoglu[m]>roptat: I forgot a lambda keyword so my install lambda was running prematurely. We fixed that error <aecepoglu[m]>Now, if I wanted to expose more variables into the lambda, I would just say `(lambda* (#:key outputs my-other-var) (...)`, right? <roptat>aecepoglu[m], yes, but they must be variables that the build system knows about, otherwise you'll just get #f <aecepoglu[m]>So do I create custom variables and make them known to the build system? <roptat>you can't, but you can pass in some values directly by unquoting them <roptat>if you define a variable outside your package, say (define foo 1), you can pass it to the build-side by using ,foo (in the generated .drv file, the value of foo will be substituted) <roptat>that's because the arguments is a big list created with a quasi-quote <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? ***rekado_ is now known as rekado
<civodul>it could be related to changes i pushed earlier today <guixy_>I'm trying to set up a system that lets me offload builds to an ARM machine with a foreign distro. <civodul>guixy_: hi! did you try "guix offload test" to get a diagnostic? <guixy_>$ guix offload test /etc/guix/machines.scm 12 <guixy_>guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... <guixy_>guix offload: Guix is usable on '192.168.1.12' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") <guixy_>guix offload: '192.168.1.12' is running GNU Guile 3.0.4 <guixy_>guix offload: error: failed to connect to `#<input-output: channel (open) 7f27c10412e0>': Protocol error <civodul>guixy_: did you create a signing key on the build machine? <guixy_>I exchanged ssh keys and `guix archive` keys <civodul>"ssh 192.168.1.12 env | grep GUILE_LOAD_PATH"? <guixy_>Now I'm trying to figure out where GUILE_LOAD_PATH is set in my ssh login shell... <civodul>the build machine is on a "foreign distro"? <guixy_>or whatever it's called these days <civodul>ok, so there's a bit more manual setup <civodul>you should arrange so GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH are set when you log in non-interactively over SSH <civodul>and they should point to ~/.config/guix/current/... <civodul>clone11: pushed a fix in d88ff09ea3138fc85c1463b0b345bd6ba71ca568 <clone11>no problem, thanks for the quick fix! <dongcarl>Hi all, so after "self: Use a 'guile' that doesn't complain about locales.", is there still a need to install glibc-utf8-locales or no? <rekado>it doesn’t complain about missing locales, but it still needs them. <apteryx>what does 'top-level' mean in 'list top-level dependent packages that would need to be rebuilt as a result of upgrading PACKAGE...' (the help doc for guix refresh --list-dependent) <mbakke>civodul: I can't spot what a "good" workaround/fix would be from that diff though, ideas? <guixy_>I've set the variables in .profile, .bash_profile, and .bashrc and still no luck. <rekado>guixy_: these files are not read when logging in non-interactively <guixy_>I set it at the beginning of .bashrc and it works. .bashrc is read when loggin in non-interactively but it quits early. *dongcarl wishes there were a `guix doctor` command that checks for common setup problems <guixy_>guix offload is still failing... <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 pi@192.168.1.12 env | grep GUILE shows that the variables are there. It still says there was a protocol error.. <leoprikler>Now that's a package I haven't thought about for a long while. <luis-felipe>Global search, syntax checking, autocompletion, documentation on hover, don't work. <mbakke>hm, 'guix build --target=i586-pc-gnu guix' fails on core-updates, possibly related to the glibc 2.32 upgrade <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? <leoprikler>Thrilleratplay_: Not exactly a copy-build-system example, but there are some emacs packages, that mix gnu-build-system with emacs-build-system <leoprikler>Typically, you will have to import the extra modules and then add their phases inside modify-phases <leoprikler>luis-felipe: sysprof sounds like a missing dbus service, perhaps you should install that as well? <leoprikler>As for python, that's a bigger oof and will take some time to debug