<mbakke>PotentialUser-69: good luck! feel free to ask about anything in the process :-) <lfam>lafrenierejm: It should be enough to do something like (define-public linux-libre-5.10 (package (inherit linux-libre) (version "5.10-rc5") (source (origin ...)))), and replace the origin as necessary. Any kernel config changes from 5.9 will be chosen automatically and may not be appropriate, but I'm sure the basics will work <mbakke>as a side note, what's going on with the Python ecosystem these days... did setup.py become deprecated or something? <mroh>yeah, I also noticed more and more poetry, pipenv and what not new build systems/setup tools. <lafrenierejm>I think the growing popularity of poetry and pipenv in particular are due to (1) low adoption of Guix/Nix and (2) a need for easy reproducibility in data science. <mbakke>right.. I remember 'python setup.py test' got deprecated recently as well, which may have contributed to this wave. <lafrenierejm>lfam: Thanks. I'm currently inheriting from 5.9 and getting some errors, so I was wondering if anyone had already worked through them. No worries, though; I'll see if I can resolve them on my end. <xelxebar>Penny for your thoughts: I am working on a package def for the programming language J. The build output depends on whether you tell it to compile with AVX-, AVX2-support, or neither. <lfam>Is there no way to make it choose at run-time, xelxebar? <xelxebar>Since --system isn't fine-grained enough to distinguish these cpu-extensions, what is the best way to handle this? <lfam>Unfortunately, we'll have to make it target to lowest / oldest chips we support. I don't recall which that is, but it's quite old <lfam>I don't think we assume AVX support <xelxebar>When I packaged this for a different distro, I just built all three versions, stuffed them under /lib/j, and had a wrapper script under /bin that parsed /proc/cpuinfo to launch tho most avx-enabled version <lfam>Maybe it's a case where one shouldn't use J on 15 year old CPUs <xelxebar>lfam: My primary machine is ~10yo and without avx-support :( <lfam>I was thinking of K, while thinking that most users are targeting high performance. I don't know about J <xelxebar>Very. Whitney wrote the original J interpreter proof of concept (in just a few 10s of lines of C!) <xelxebar>Yeah, J is focused on blasting through large amounts of data quickly, too, but there are several users of the language that just like to tinker with the novel language. <xelxebar>Anyway, would the wrapper-script idea be reasonable for guix? <lfam>I think you should use your judgment and decide xelxebar. You emailed about it, right? <xelxebar>An alternative would be to force local-builds and detect cpu-extensions at compile-time. <lfam>I don't think forcing local builds is a bad idea for cases like this. The wrapper idea is clever but in Guix we dont usually do things like that <lfam>I think I saw a related issue on the lists <xelxebar>Yeah, the only sad thing about local-only builds, is that it cripples things like `guix archive` between same-system machines in cases where you build on avx2 and send to an avx-only machine. Maybe this is really rare though... <xelxebar>lfam: Okay, I'll think about this a bit more. If I do go with a wrapper, is there a pre-baked way to build wrappers that do things more complicated than just set env vars? <lfam>xelxebar: About that limitation, wouldn't the AVX2 version fail to work on the AVX machine? <xelxebar>It looks like `wrap-program` just lets you set variables. Plus, if I have code in the script, then it feels more Guix-y to have the script be guile. <lfam>If you were to write a wrapper, this one would have to be written from scratch, I think <xelxebar>Yes, avx2 interpreter will not work on avx-only machines. <xelxebar>Okay. I don't mind writing from scratch. Just not sure how to do this. Does it make sense to have a gexp that builds the wrapper and then copy that into the output? ***chrislck_ is now known as chrislck
<guix-vits>xelxebar: in bsd-games a bash wrapper was accepted for 1-2 games. the wrapper was written as is and added as a .patch. <guix-vits>it has "PLACEHOLDER" like pieces that are (substitute* ...) 'd <vldn>how to ignore a whole group of quotation marks inside the config.scm instead escape every single one with \? like a json config :D <xelxebar>guix-vits: Hrm. Okay. Curious why we opt to go with a bash wrapper instead of guile. <xelxebar>vldn: Maybe ~s expanion could be helpful in your use case? <plasma41>vagrantc: Could you please try building your Debian Guix package after running `sysctl kernel.unprivileged_userns_clone=1` on the build machine? The container tests don't run unless unprivileged user namespaces are enabled (Debian's kernel disables them by default, see https://lwn.net/Articles/673597/) and currently those tests fail. <vagrantc>plasma41: it's not possible to build on debian anymore, as guile-gnutls is built against the wrong version of guile <vagrantc>plasma41: but yes, i never tested with the userns enabled <plasma41>vagrantc: It took me a while to track down why the container tests ran (and failed) on my home computer, but were skipped on my work computer. I eventually figured out it was because I was running linux-libre at home and debian's linux at work and that the important difference between the two was user namespaces. <vagrantc>plasma41: please file a bug report if you wouldn't mind :) <vagrantc>plasma41: my hunch/guess is they rely on bootstrap binaries that aren't available <plasma41>Will do. I just wanted to reach out while I saw you on IRC. <plasma41>vagrantc: I believe that is the reason, yes. <vagrantc>plasma41: are you using an old guile-gnutls package? <lihua>Is it a good idea to provide the'-m' option for `guix archive`? <lihua>I want to use `guix time-machine` in conjunction with `guix archive` to create profile installation packages for my offline machines, but I did not find the -m option in the guix archive to use my manifest file. <vagrantc>PotentialUser-72: guix itself is GPLv3 (mostly), but the kernel used in Guix System is (typically) a linux with the linux-libre patches applied which is (mostly) GPLv2 <vagrantc>PotentialUser-72: guix can be a package manager on any distro, or used to manage Guix System as a full operating system <plasma41>vagrantc: I have guile-gnutls 3.6.15-5 installed. I'm pretty sure I installed it from experimental when it was there. <guix-vits>... which patches take so much time to apply, btw <vagrantc>plasma41: yeah, the newer versions won't work <plasma41>vagrantc: Seems odd that the guile-gnutls package is getting compiled against guile-2.2 when the only package that currently depends on it needs for it to be compiled against guile-3.0 <vagrantc>plasma41: it hangs the test suites, so it's understandable... <spudpnds>Anybody do literate guix stuff with Emacs' org-babel? <spudpnds>I'm pretty stoked i've got it working with a persistent :session using Geiser. <guixy>My build offload attempts still say protocol error. What could I be doing wrong? <PotentialUser-98>I get an error when I try to compile pyinstaller: "AttributeError: module 'sys' has no attribute '_MEIPASS'". <guixy>guix offload: error: failed to connect to `#<input-output: channel (open) 7f97dd631d00>': Protocol error <PotentialUser-47>Hello! --- I am wondering if GuixSD can be installed with full disk encryption with uefi. I have used lvm in the past, but it does not appear to be installed on the installation image. <guixy>PotentialUser-47, I think you have to map it manually. <guixy>It says how to use LUKS, and you should be able to do a similar thing with LVM <spudpnds>How is `guix repl` different than just running `guile`? I see the prompt is scheme@(guix-user) rather than scheme@(guile-user) but is there more magic than that? <apteryx>spudpnds: it sets the GUILE_LOAD_PATH for you <spudpnds>apteryx: Huh, from a vanilla guile REPL I can "(use-modules (guix) (gnu)" which seems to work. <spudpnds>Anyway, not a big deal, just trying to grok things :) ***amfl_ is now known as amfl
<spudpnds>Ah, I somehow have GUILE_LOAD_PATH already set. <janneke>how do i get full, non-truncated messages in a guix build backtrace? <leoprikler>raghavgururajan: idk, I manually started dring because I used environments, but it should find and start dring automatically if the service is put in a well-known location <janneke>this could have been such a useful message: <janneke> 1 (rename-file "/gnu/store/n85bwd3bhs5ifax5p59116nkic02m…" …) <rekado>janneke: the COLUMNS environment variable affects the amount of truncation, but it has to be in the environment where the Guile script in question is running. Setting it so that daemon-run scripts are affected is a little cumbersome. <rekado>AppImage is … weird. It feels much less robust than “guix pack -RR” <rekado>“error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory” <rekado>then: “dlopen(): error loading libfuse.so.2” <rekado>and then “error while loading shared libraries: libgobject-2.0.so.0: cannot open shared object file: No such file or directory” <rekado>wasn’t this exactly what AppImage was supposed to handle? ***apteryx is now known as Guest12417
***apteryx_ is now known as apteryx
<pkill9>maybe the appimage creator expected the OS to provide libgobject <pkill9>rekado: are you trying to run an appimage on guix system? <pkill9>it expects some basic libraries from the OS <rekado>I’m trying to follow the PureOS installation instructions *accurately* in hopes of actually getting some support this time <pkill9>like libfuse is required to mount the appimage <rekado>I’m just surprised by zlib and libgobject <rekado>raghavgururajan: you once suggested that the problems that I have with my Librem 13 with mounting an encrypted SSD might be due to the version of SeaBIOS that they use as a coreboot payload. <rekado>raghavgururajan: do you have some experience with building coreboot with different payloads? This is not something I’m familiar with. <rekado>libasound.so.2, libcups.so.2, libnss3.so… <rekado>apparently this is an electron app, so now I need to provide the whole kitchen sink of browser dependencies… <guix-vits>abcdw: it's gnug. it's weird, unexplained: but questionlessly modern. <guix-vits>a blockchained queue of intelligent rerouting happenning thanks to robust http stack provides a REDIRECTION in the meant time. <abcdw>guix-vits, lol) anyway, if someone knows the answer let me know please. <guix-vits>abcdw: ci.guix.gnu.org provides online search. <abcdw>guix-vits, at least it has search) Thank you. <rekado>ci.guix.gnu.org isn’t really meant as a package search <rekado>I don’t know why hpc.guix.info changed. <rekado>guix.mdc-berlin.de still uses the old interface. <rekado>(though there’s a bug and you can’t actually view any package details) <ss2>does anyone use xfce4-screensaver? When I add it to screen-locker-service it will fail, since gtk doesn't allow setuid programmes. Is there a workaround this? <rekado>apteryx: 4035c2e402eb7ff42ecceacd927f34997367cdf5 updated python-cairocffi; unfortunately, this version does not support Python 2 any longer, so python2-cairocffi and all packages that depend on it no longer build <rekado>I suppose there really isn’t anything we can do about that. <rekado>the last version to support Python 2 is 0.9 from August 2018 <rekado>I guess I’ll move these to a different channel. <kisaja[m]>how to enable gtk theme from .guix-profile/share/themes/Greybird-dark, i tried adding XDG_CONFIG...=/home//.../.config and lxappearance made config files, but lxappearance can't apply theme as my variable can <abcdw>Inherited OS record from (gnu system installation) installation-os, how to add additional service to my OS record? Tried to (services (cons* (service pcscd-service-type) (operating-system-services gnu-system-install:installation-os))), but it doesn't work because it contains services, which defined by other fields (I suppose). <abcdw>rekado, guix system: error: more than one target service of type 'shepherd-root' <rekado>abcdw: can you show us the full definition? <rekado>So, PureOS with LUKS encrypted disk does boot, but they have a separate unencrypted /boot partition. <rekado>Guix System with one LUKS-encrypted partition enters GRUB, but doesn’t manage to pass execution to Linux <rekado>Guix System without encrypted disk boots fine. <maav>rekado: hmmm, i remember something like this 0:) <rekado>I’ll install PureOS again and then check their unencrypted grub.cfg <rekado>maybe there’s a module or a setting that I need to enable in my Guix System grub. <maav>probably they're generating grub.cfg with grub-mkconfig <maav>i have some patches for that, but they need a bit of work <rekado>what’s annoying about this is that booting works fine with older versions of their Coreboot fork. <rekado>it just has other unacceptable problems (extreme vertical flicker) <maav>well, i remembered it only may need a review, hehe <maav>only implements support for cryptodevices specified by UUID, but that limitation doesn't seem as hard rn, as grub.cfg shouldn't depend on physical disk locations <abcdw>rekado, found the problem. Had to use operating-system-user-services instead of operating-system-services <maav>civodul: that's the patch you meant the other day? sorry, i completely forgot about it <rekado>What I don’t understand is why the problem exists with the handover from GRUB to Linux. <rekado>Clearly, GRUB managed to decrypt the drive, or else it wouldn’t have been able to access /boot at all <maav>rekado: IIUC you mean /boot is unencrypted but / is encrypted <rekado>no, with Guix System /boot is under /, which is one encrypted partition <maav>hmmm, then that's another issue <rekado>PureOS has separate /boot and /, with only / encrypted <rekado>so I can’t really compare the two <maav>that patch is for /boot unencrypted and / under luks <rekado>I don’t understand how a coreboot (or coreboot payload) upgrade can lead to this problem. <maav>the issue is that coreboot -> grub ok, grub -> guix doesn't work... i only can think: is the grub loaded the guix generated one? <rekado>maav: yes, it’s the Guix-GRUB that’s loaded <rekado>and it does work with an old version of the Purism fork of coreboot <mdevos>still ripsnack but at least the name is spelled correctly <rekado>(but Purism support doesn’t even acknowledge that there is a problem) <rekado>my Librem 13 has been lying in a shelf for the past months, because I just can’t justify wasting time to try to fix this. <maav>rekado: i see two possible issues, either the search call doesn't come back (you won't see the loading linux blabla line) or it's an issue with the kernel or the initrd script (you can remove the quiet line from the booting system to check kernel messages) <maav>i guess that the third but most unlikely option is that the memory aperture/ACPI is buggy in your version and our grub doesn't cope with that like purism one... <maav>coreboot latest version, not yours, sorry <maav>the version you're using <maav>(IIRC linux protocol used some of those architecture dependent things) <rekado>“guix package: package 'python' has been superseded by 'python2'” <— what? <rekado>maav: I only see the Guix-themed GRUB background. <rekado>I don’t think we’re using the “quiet” argument. <raghavgururajan>rekado: I haven't build coreboot or libreboot manually. But I do use Libreboot with GRUB payload with Guix System. <raghavgururajan>There might be instructions to build coreboot image with GRUB payload? <maav>rekado: %default-kernel-arguments contains it <raghavgururajan>IIRC, FDE works only with GRUB payload (Coreboot-GRUB or LIbreboot-GRUB). <rekado>raghavgururajan: that’s odd because the old Purism coreboot with SeaBIOS payload boots my FDE Guix System just fine. <rekado>there are no instructions to build the Purism fork with GRUB payload. <rekado>there’s just a discouraging forum post from a year ago that says it’s not trivial <raghavgururajan>> rekado: So, PureOS with LUKS encrypted disk does boot, but they have a separate unencrypted /boot partition. <raghavgururajan>Yes, IIRC, you need GRUB outside of disk, like on BIOS , for FDE. Otherwise, you need separate unencrypted /boot partition, which is required by on-disk grub. <raghavgururajan>rekado: My guess is that, older coreboot versions, even though with SeaBIOS payload, were compiled with code from GRUB to support decryption of LUKS. SeaBIOS don't have that capability. <rekado>how does this jive with the fact that I can enter GRUB just fine? In the GRUB command line I can also access the LUKS disk and decrypt it. <rekado>I think there’s only one GRUB, the one on the disk, no? <rekado>I turn on the laptop, am asked for the LUKS passphrase, and then the Guix-themed GRUB appears. <maav>that should have been my reaction, hehehe :) <civodul>maav: oh, i had completely forgotten about that, apologies! <maav>civodul: me too, nothing to apologize for :) <civodul>maav: so this is to allow an unencrypted /boot together with encrypted root, right? ***zimoun` is now known as zimoun
<rekado>I don’t know if the initrd succeeds, because it doesn’t print anything visible <rekado>I see that on a successfully booting system the GRUB background lingers for while. The first few lines of Linux that I see are timestamped “14” and beyond <maav>civodul: yes, that's the use case that implements (with marionettes included, hehe) <maav>rekado: hmmm, with that 14 do you mean the boot clock ([14.xxxxxxx] some message from the kernel)? <rekado>that’s what I see when booting the USB installer <maav>did you remove the quiet option before booting up? <rekado>I’m just pointing this out because it’s not clear exactly where booting stops in the pathological case <maav>yup, the early messages should start with almost 0.0 <rekado>I installed Guix System with FDE and chose the incredibly secure passphrase “123” (without the quotes). <rekado>after hitting RET in GRUB to boot nothing seems to happen <rekado>then I thought to myself “why not try that passphrase now” <rekado>so I typed 123 into the void and hit RET <rekado>now I’m greeted with a happy login prompt <maav>so it's the screen refresh! what an unexpected visitor, hehehe <maav>either that or that the message isn't being properly printed <rekado>*nothing* is printed until *after* the passphrase has been accepted <rekado>incidentally this newer coreboot/seabios combination allegedly fixes graphics problems (that extreme flicker I mentioned earlier) <maav>yup, no refresh means no flicker at all :-P <maav>perhaps is the fb driver or the bios/vesa implementation <maav>well, it's a flickering smiley ;) <maav>now you see the eyes, now the mouth <abcdw>rekado, is Guix System can be installed with /boot being part of encrypted / ? <efraim>I'm up to the yelling part of making the lizardfs shepherd service <efraim>the one where I yell at the computer for each mistake I make <apteryx>rekado: re python-cairocffi; I don't see any dependent on python2-cairocffi, 'git grepping' for ,python2-cairocffi <rekado>apteryx: guix refresh -l python2-cairocffi <rekado>Building the following 22 packages would ensure 37 dependent packages are rebuilt: python2-htseq@0.9.1 pyicoteo@2.0.7 qucs-s@0.0.21 pbtranscript-tofu@2.2.3.8f5467f python2-biom-format@2.1.7 pepr@1.0.9 couger@1.8.2 python2-checkm-genome@1.0.13 python2-plastid@0.4.8 gess@1.0 grit@2.0.5 miso@0.5.4 python2-warpedlmm@0.21 poretools@0.6.0-1.e426b1f python2-shapely@1.7.1 grocsvs@0.2.6.1-1.ecd956a python2-ipywidgets@7.5.1 <rekado>python2-matplotlib-documentation@3.1.2 python2-ipyparallel@6.2.4 python2-jupyter-console@5.2.0 python2-numpy-documentation@1.17.3 ribodiff@0.2.2 <abcdw>rekado, will encrypted boot work with uefi? btw, can you share your configs? <apteryx>rekado: ah, indeed. We can lock the python2 version to an older version if there are packages of interested not yet migrated to python3 in that list. <ss2>Can I point channels to local directories, or does it need to be an http url? <ss2>as in (url "file:///")? <apteryx>I 'guix deploy'd a remote offload machine recently, and I now see lots of: 'guix substitute: error: connect: No route to host'. Specifying --fallback seems to allow it to go through, but the messages remain. <apteryx>Does it ring a bell? The remote guix-daemon would be newer than my local one. <rekado>(right now ci.guix.gnu.org is being rebooted) <apteryx>Hopefully the reboot of Berlin goes smoothly! <rekado>it came back up, but there’s no SSH… <rekado>looks like last time we updated the routing manually and didn’t record that in the configuration <ss2>is it possible to switch of the pager (less) in guix when searching, say, for packages? <apteryx>abcdw: encrypted boot works with uefi yes <abcdw>apteryx, wow, great, thank you for information! <lfam>Hm, the 5.10 kernel modules don't seem to include the virtio_console module, which breaks the whole Guix kernel machinery <lfam>It's weird, CONFIG_VIRTIO_CONSOLE=y <civodul>ngz: congrats on the Org release :-) <ngz>civodul: Ah, thank you! However I'm mostly retired on Org these days :) <civodul>ngz: ah, i figured you must be involved to some extent, i guess retirement is one way to be involved ;-) <abcdw>Which services are required to run sway? or any other wayland compositor? <vldn>guix import nix /tmp/nixpkgs curl just keeps beeing black and nothing happens, is there some verbose mode or sth? <vldn>trace: lib.zip is deprecated, use lib.zipAttrsWith instead <vldn>trace: warning: lib.readPathsFromFile is deprecated use a list instead <civodul>vldn: the "nix" importer has been bitrotting for a while and may soon be removed if nobody takes care of it <apteryx>rekado: Berlin seems to be serving substitutes fine; did you get back SSH after all? <guix-vits>abcdw: elogind-service for sway is bare minimum (or it to be a suid to work). <ngz>Eww. I wanted to test nu-shell. `guix import crate --recursive nu' spits 12k+ locs of unpackaged Rust dependencies… <civodul>what's the deal with those shells/terminals written in Rust? <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, dftxbs3e says: Sorry about the electrum patches mess.. git-send-email is just a mess, it doesnt account for mistakes and being able to revert them (can't delete sent emails..) - it's unclear whether things succeed or not, combined with spam filters rejecting or delaying mail arbitrarily .. <mdevos>sneek: tell sneek zombiesnack! You're alive again <lfam>ngz: That's probably going to be "normal" for any significant program written in Rust :/ <lfam>nu-shell does sound cool <lfam_>Did something happen to ci.guix.gnu.org? I noticed a lot of specifications and evaluations don't appear anymore <cbaines>lfam_, I think the database was on a tmpfs, so some state was maybe lost with the reboot? <cbaines>I'm actually sort of hoping that with the WAL behaving better, maybe that will be unnecessary. Although for write performance, the WAL would probably need some more pages. <lfam_>Does it mean that the guix data service lost information, too? <lfam_>I was meaning to use that "broken" comparison tool you showed me yesterday, but it's not giving any results now <cbaines>lfam_, no, and luckily I don't think I'm recording the Cuirass build ids, as some of those will effectivly have changed. Although I do want to start using those ID's soonish. <cbaines>lfam_, I see the same thing, no builds listed as broken. <cbaines>I'm still chasing catching up on master <lfam_>I do get results for "still working", so maybe it's correct <cbaines>and Cuirass on ci.guix.gnu.org hasn't figured out what has been built, and what's failed to build yet <cbaines>For some reason, quite a lot of staging has been built on ci.guix.gnu.org, but Cuirass doesn't know about it <abcdw>guix-vits, thank you, it didn't work for some reason even with elogind enabled, but I'll try to rebuild image one more time and re-check it. <jsoo>PotentialUser-50: there are many translations available, if you are not an English language user <janneke>guix download mes-0.22-111-g205260677.tar.gz <janneke>guix download: error: open-file: No such file or directory: "/gnu/store/2xd640fl59kifd81lb98mfb1yzm38yvm-mes-0.22-111-g205260677.tar.gz" <janneke>guix gc -D /gnu/store/...tar.gz and guix gc --verify=contents,repair did not help <civodul>janneke: could it be a --localstatedir issue? <civodul>like you built Guix --localstatedir=/whatever, run the daemon from there, and thus it doesn't look at /var/guix/db <janneke>civodul: no, i'm not using such trickery atm <ngz>I have this gammastep package definition <https://paste.debian.net/1176917/> (which is Redshift for Wayland), but whenever I try to run it, I get a warning "Failed to start adjustment method: wayland". Could it be related to my environemnt (supposedly Gnome Wayland in a foreign distro)? <procra>I try to use virt-manager and i add the libvirt service on the /etc/config.scm however when i start virt-manager it doesn't make conection. i cheked the libvirt processes running sudo herd status and it was runing. How can I fix it? <cbaines>procra, what permissions does the user running virt-manager have for that socket? <cbaines>My user is in the libvirt group on my machine, which grants access <vagrantc>i remember having to fight with polkit to get virt-manager to work ... but that was a year or two ago <procra>cabaines: oh yea, i forget that. it is only on "wheel" "netdev" "audio" "video" groups <ride>Hello! I am trying to install Guix System. I currently run another distro (Void) and I have full disk encryption including boot with LUKS and LVM set up. Since lvm support is so recent on Guix, I am wondering if it is possible to do FDE and simply replace the root volume in the lvm group with Guix System. <ride>LVM does not appear to be installed on the installation image. <arh>Hey guys. I want to move to Guix. Just completed some steps in installation and found out my wifi works on Guix. So before I install it, can you guys tell me what downsides/problems I may face? I only do basic things with this laptop like listening to music, watching movies, checking emails, and surfing the web. <ride>arh: I don't use Guix (yet) but for movies and music, if you use a platform that requires DRM in the browser such as Netflix or Spotify you will run into issues. The primary repository packages browsers without any of the DRM. <ride>But hopefully you don't use those :) <arh>ride, no I don't use those. Thanks. <vagrantc>guix is a bit of an adventure and still rough in some places, but it's an interesting adventure :) <cbaines>Ah, I didn't actually look at ci.guix.gnu.org when you mentioned it lfam_ <cbaines>Looking now, it's like it's started from an empty database, rather than just some data been lost <jeko>Nginx service doesn't want to start. Herd throws an exception. I can't find any log to help me to investigate… <jeko>herd: exception rattrapée pendant l’exécution de « start » sur le service « nginx » : <jeko>Throw to key `%exception' with args `("#<&invoke-error program: \"/gnu/store/80vpiwm22rq3wbkxvmz4d8nd5b7cjvqx-nginx-1.19.5/sbin/nginx\" arguments: (\"-c\" \"/gnu/store/y8l4kdmsxychs073381h1hy6kczdqvmz-nginx.conf\" \"-p\" \"/var/run/nginx\") exit-status: 1 term-signal: #f stop-signal: #f>")'. *mbakke attempted naively porting gcc-cross-environment-variables.patch to GCC 10, but 'gmp' fails to cross-compile due to "C++ compiler not available"/me <mbakke> /gnu/store/dlb34bysazjxz6pwz430dxh680cniqpb-gcc-cross-aarch64-linux-gnu-10.2.0/include/c++/iostream:38:10: fatal error: bits/c++config.h: No such file or directory <mbakke>indeed, bits/c++config.h is missing, but it's available in aarch64-linux-gnu/bits/c++config.h <mbakke>that is the case with GCC 7 as well, but somehow $target has gone missing from the search path with GCC 10 <mbakke>civodul: do you remember/know how GCC's tlink worked (one of the files touched by gcc-cross-environment-variables.patch)? <civodul>jeko: does restarting it again work?... <civodul>mbakke: re tlink.c, i think you have to find a file with a literal reference to "LIBRARY_PATH" <civodul>that's what we aim to replace with CROSS_LIBRARY_PATH <civodul>jeko: could it be that this nginx.conf is invalid? <civodul>you can try with "nginx -s -c ...-nginx.conf" <jeko>civodul: it seems to be! let's redeploy to get nginx commands from the terminal… <dongcarl>Question: Do I need `nss-certs` if `guix` itself is the only thing authenticating with HTTPS servers? <jeko>civodul: I can see the problem now haha 😅️ the default value for the listen parameter includes "ssl" which expects ssl_certificate defined somewhere… <jeko>But I don't have any certificates yet so lets set the listen parameter to port 80 only <jeko>then I request a certificate… <jeko>Now I can redeploy with the final nginx conf providing https support! <jeko>Hm… I don't understand the need of the (program-file <jeko> #~(let ((pid (call-with-input-file "/var/run/nginx/pid" read)))