IRC channel logs


back to list of logs

<apteryx>is using (@ (...) symbol) a valid hack to avoid module circular dependencies?
<apteryx>raghavgururajan: looking at gajim; shouldn't it be wrapped instead of using a search-path-specification? The hard-coded 3.8 Python version is not going to last too long.
<apteryx>ah, for plugins, perhaps?
<raghavgururajan>apteryx: Yeah, the search path is for plugins.
<ccao001[m]>Hi, can a service-type be deployed in a guix environment via a manifest?
<ccao001[m]>is this possible?
<jmarsden>ccao001[m]: I don't think so. The Guix Reference Manual says "file must return a manifest object, which is roughly a list of packages: ". So if that is what manifests are, they can't include service-types, as far as I understand it.
<leoprikler>exactly, you need some different mechanism for that
<sundbry>@ccao001[m] they can not, i have tried making docker images using --manifest to do something like that. It doesn't work well at all. You have to use guix system to build a whole os.
<sundbry>Unless you hack your manifest so well to have shepherd or runit as the main package and figure out how to bundle your service configs in and your actual app you want to run, that would be possible but I have not gone that far.
<sundbry>Check out `guix system container` if you havent already
<bdju>I got this build failure
<bdju>on something pretty generic-sounding. guix-package-cache
<raghavgururajan>leoprikler: Can v24 be pushed?
<pkill9>sneek: tell civodul would it be desireable to have --with-patch put the patch in the store with a gcroot to prevent it being garbage collected, and then have the store path in the profile manifest
<sneek>civodul, pkill9 says: would it be desireable to have --with-patch put the patch in the store with a gcroot to prevent it being garbage collected, and then have the store path in the profile manifest
<pkill9>sneek: later tell civodul would it be desireable to have --with-patch put the patch in the store with a gcroot to prevent it being garbage collected, and then have the store path in the profile manifest
<sneek>Will do.
<kozo[m]>zimoun: Hey, are you around?
<zimoun>kozo[m], yes almost going to bed.
<kozo[m]>Thank you for your reply on the issue tracker about the python setup tools. Good night =]
<zimoun>yw. :-)
<kozo[m]>I wonder why it's a problem now. Syncthing-gtk was working prior. Maybe someone updated the tools
<lfam>Syncthing-gtk isn't working now?
<kozo[m]>Python2-setuptools is failing to build
<kozo[m]>and Zimoun answered in the bug report of why
<lfam>I see. We should reintroduce the older variant for Python 2, for the time being
<lfam>We do aim to drop support eventually but I think it's too soon
<lfam>We might also have to adjust package-with-python2, not sure
<zimoun>lfam, too soon? Python is EOL since more than 1 year :-p
<lfam>This could have been a good time to drop it, if we had announced that we would do so
<lfam>I don't think it should happen by accident. Maybe that would be okay if it had been longer
<zimoun>the last setuptools working with py2 is v46 and the current is v52, if I read correctly. The break happens in v47 released in May.
<lfam>Also, does this change (the setuptools update) affect the python-build-system?
<zimoun>I opened bug#38420 on 28 Nov 2019 for that, tracking the Py2 EOL. :-)
<zimoun>what do you mean? python-setuptools builds correctly.
<kozo[m]>If it's a big issue. I can take the package and build it locally with v46 instead of reverting it (Since I don't know how to do that)
<lfam>zimoun: I meant, does it cause all the python packages to be rebuilt?
<zimoun>Update is done 2021-01-26. 3142daccbe9caf8b1189a60f2974e0c938c77abf
*zimoun -> ZzZ
<kozo[m]>Good night
<raghavgururajan>sneek, later tell civodul: I am having this crazy thought. Would it be possible to implement 'multiple system profiles' for Guix System? At user-level, one can create many profiles for different purposes. At system-level, it would be cool to do the same. One profile for desktop-use and one for server-use, etc. What profile to boot can be chosed at boot time.
<apteryx>lfam: as the current active linux-libre package maintainer, do you have an opinion on this? Mark was rather against it, so it stalled.
***iyzsong-- is now known as iyzsong-w
***qyliss- is now known as qyliss
<leoprikler>raghavgururajan: looking at it rn
***iyzsong-- is now known as iyzsong-w
<civodul>Hello Guix!
<sneek>civodul, you have 2 messages!
<sneek>civodul, pkill9 says: would it be desireable to have --with-patch put the patch in the store with a gcroot to prevent it being garbage collected, and then have the store path in the profile manifest
<sneek>civodul, raghavgururajan says: I am having this crazy thought. Would it be possible to implement 'multiple system profiles' for Guix System? At user-level, one can create many profiles for different purposes. At system-level, it would be cool to do the same. One profile for desktop-use and one for server-use, etc. What profile to boot can be chosed at boot time.
<civodul>pkill9: i can imagine it being desireable sometimes and sometimes not, but anyway it's not really an option given the current implementation :-)
<civodul>raghavgururajan: interesting idea
***Server sets mode: +cntz
<rekado_>I cannot test staging on my i686 because I don’t have enough memory to build the guix-packages-base derivation.
<rekado_>are we not building the ‘guix pull’ derivations for staging?
<civodul>rekado_: the guix-modular job set is probably not building staging
<civodul>but you could run "guix pull -s i686-linux" on berlin...
<civodul>how much memory does it have?
<civodul>it's a bummer if we're again eating too much memory
<rekado_>it has only 1G
<rekado_>I’ll build it on berlin.
<jlicht>pkill9: you could already pass a `guix download' subshell to the with-patch tranformation; would that work for you? `guix download' would then need support for a `register-gc-root' flag though
<paulj>Morning all! Quick question on the recommended approach from a guix perspective: If I want to install a window manager in a way which appears in the options on the log-in screen, would I need to install it as part of the system configuration, or can I install it in the user account?
<mroh>paulj: I think, you need to install it in the system configuration in this case, because the .desktop file in share/xsessions needs to be found by the login manager.
<paulj>@mroh - thanks for the confirmation - that is what I thought.
<allana>Hi guix. Anyone know what package includes "useradd"?
<mroh>allana: shadow
<allana>mroh: thanks!
<civodul>allana: on Guix System, useradd isn't going to have a persistent effect; see instead
<allana>civodul: Thanks. What I'm trying to do is run guix-daemon within the context of a docker container. I might be going about this in the wrong way. Basically, running guix pack -f docker guix doesnt produce a docker image that can run guix-daemon.
<civodul>oh i see
<civodul>there's the other option of using "guix system docker-image"
<civodul>perhaps worth a try, starting from the "bare-bones" OS config example in the manual
<civodul>allana: ↑
<civodul>colleagues of mine tried that but i forgot what the outcome was
<allana>ah, wonderful
<civodul>it has to run as --privileged, which can be problematic in some contexts
<civodul>but i think that's about it
<leoprikler>in the context of CI, many people (myself included) use some variant of alpine + guix, which comes with all the flaws you might imagine from such a setup
<allana>leoprikler: I was also thinking of using a debian/sid docker base image. Sid has guix included as a package.
<leoprikler>That could work as well.
<civodul>leoprikler: out of curiosity, do you use Alpine + Guix on Gitlab-CI?
<jlicht>is building golang related software really really weird, or am I just that stupid?
<civodul>we really need a better story here
<civodul>jlicht: heh :-)
<leoprikler>civodul: exactly
<civodul>leoprikler: did you try something like allana was discussing?
<leoprikler>I have next to 0 experience with docker, so I just opted to take the first solution,that gave me a working "guix" command from dockerhub.
<leoprikler>I then slightly tweaked that later on, but I'm still far from an expert here.
<apteryx>it could be useful to have a 'guix history' recalling what was last built, with the logs and kept built directory if available
<apteryx>perhaps more guix build --history
<apteryx>food for thought
<allana>I just tried running "guix pull" from within a docker container using the debian/sid baseimage with guix installed and configured. I got the exact same problem when using an image that I created partially with "guix pack -f docker guix".
<allana>It starts with a warning, substitute: guix substitute: warning: host not found: Servname not supported for ai_socktype
<allana>And then fails with: build of /gnu/store/yra976v8l3dmlvrszg9y3ci3y53sydj6-isrgrootx1.pem.drv failed
<allana>And the errors in the build log reflect the same information as in the warning
<allana>Does anyone know about this "host not found" warning/error?
<leoprikler>I think the real error here is the ai_socktype stuff
<leoprikler>It has come up in the past, but I'm not sure in which context.
<leoprikler>do you run "guix pull" with "--privileged" in docker?
<allana>leoprikler: yes, tried with and without. Same result
<pkill9>are the build servers down?
<mothacehe>pkill9: I'm restarting them right now
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, civodul says: could you restart the cuirass workers on hydra-guix-129?
<bdju>kwayland (kdenlive dep) fails to build, skipped that and now python2-setuptools (syncthing-gtk dep) fails to build
<bdju>kwayland log: | python2-setuptools log:
<leoprikler>bdju: it seems kwayland-testPlasmaWindowModel fails non-deterministically. We could probably disable that test to at least get substitutes.
<civodul>mothacehe: hey ho!
<mothacehe> hey civodul :)
<civodul>just replied to your message to lfam re substitute availability
<civodul>i was wondering what could be done with the OverDrive(s) to have them plugged in
<civodul>also with the ARMv7 boards
<civodul>sneek: seen jas4711
<sneek>I last saw jas4711 in #guix 5 days ago, saying: civodul: thanks. yes, that is how i found the reference to cdrkit which i then found in guix too.
<mothacehe>civodul: I just pushed the "cuirass-remote-server/worker" service definition
<mothacehe>(they were depending on a postgresql related patchset)
<mothacehe>I'm deploying them on berlin right now
<mothacehe>regarding the overdrives, I need to reconfigure them the same way
<mothacehe>but it occured to me that that the network setup will not be that simple: the remote building mechanism needs several ports to be opened (publish servers, ZMQ socket, build log streaming port)
<bdju>leoprikler: sounds like a good idea
<civodul>mothacehe: ah, i see
<civodul>opening ports on berlin is very hard, because it has to go through the relevant team at the MDC, and it takes a lot of time
<civodul>that's why we still use port forwarding for several build machines
<civodul>not sure how to address that
<mothacehe>civodul: I was thinking about using wireguard over the ports currently open for offloading over SSH
<mothacehe>to make a VPN of remote build machines
<civodul>mothacehe: ok, why not
<civodul>basically, only a subset of the build machines is directly accessible
<civodul>so we reach the others by setting up an SSH tunnel that goes through one of those that's reachable
<civodul>(not sure if i'm being clear)
<civodul>anyway, we'd have to work with that kind of setup
<civodul> is reachable (on one port), so we can start with that one maybe?
<mothacehe>I think that hydra-guix-101/129 are on a local network
<mothacehe>the overdrives (4 machines) are not directly accessible
<civodul>yes, i was only talking about the machines not physically at the MDC
<civodul>which is all the non-x86 machines
<mothacehe>oh i see
<civodul>overdrive1 is definitely reachable directly, but there's only one open port
<mothacehe>using wireguard over port 52522 for should be doable
<civodul>if you look at /etc/guix/machines.scm, you can see which ones are accessed directly and which ones go through localhost
<civodul>i've never used wireguard but if you think it can work, let's do that :-)
<mothacehe>ok I'll try that :)
<mothacehe>it will be more difficult for dmitri & sergei but I'll see with nckx what can be done
<mothacehe>and I don't know yet where is hosted
<civodul>mothacehe: dmitri & sergei are behind an ssh tunnel; dover is at Andreas' place
<civodul>roptat: i noticed a missing paren in the first paragraph at; also the node names for "package Reference" and "origin Reference" don't match the section name, which technically works but is surprising
<roptat>civodul, oh, let me fix that ^^'
<roptat>civodul, have you seen that:
<roptat>zimoun was complaining that downloading from weblate gives us po files that are not normalized, so there are a lot of meaningless changes in the po files
<roptat>it also contains a patch to add a check-po target to the Makefile, so you can run it after downloading the latest, and make sure there's no issue in the po files
<ngz>Hello. It seems that <> is frozen since Monday.
<roptat>ngz, I also noticed the translation was not updated, though I built it successfully locally
<ngz>roptat: So, we don't know why updates do not happen, right?
<roptat>I don't, but maybe someone with access to berlin can check what's going on
<civodul>roptat: just replied
<roptat>civodul, thanks!
<roptat>could you also check for the website? :)
<civodul>roptat: often that's because there's a broken package description or something
<civodul>i can check
<roptat>civodul, though I managed to build locally using .guix.scm
<civodul>roptat: i think one can also check with: guix time-machine -- build -f .guix.scm
<civodul>that's essentially what the mcron job does
<apteryx>the log files are per derivation, right? So it only keep a single copy of a given derivation at any time.
<ngz>civodul: hmm, could it be @acronym{...} from daa4728efc14a3c4c3893ba5e4daeda4bbdabf75?
<ngz>IIRC, the Texinfo-like syntax used in descriptions do not like this command.
<civodul>ngz: dunno but 'guix lint' should catch it
<ngz>'guix lint' does not report anything wrong with the package. I guess @acronym{...} is innocent, then.
***Aurora_iz_kosmos is now known as Aurora_v_kosmose
<civodul>ngz, roptat: apparently haunt/guile gets SIGABRT while building the thing:
<civodul>not good!
*mothacehe successfully deployed cuirass-remote-server and cuirass-remote-worker services on berlin
<mothacehe>now the overdrives!
<mothacehe>for some reason static network interfaces created by Guix System do not have multicast support preventing Avahi discovery
<mothacehe>I ran "ifconfig eno1 multicast" as a cheap fix
<roptat>civodul, your website doesn't provide tls 1.2?
<civodul>mothacehe: weird; we need guile-netlink to do that right! /me looks at roptat :-)
<civodul>roptat: which web site?
<roptat>oh, mh...
<civodul>dunno, i'm not an admin
<roptat>I got a scary warning from firefox
<roptat>yes! I think I have all the low-level bits to do that
<roptat>it's just not very clear what the higher-level interface should be
<civodul>something similar to what ifconfig/ip provide
<civodul>and then appropriate data structures on the Guix side
<civodul>(easily said :-))
<civodul>roptat: did you manage to reproduce SIGABRT on your machine?
<civodul>i was going to try but it wants to download texlive so...
<roptat>civodul, no, I'm trying with guix time-machine, from a very recent commit (not sure which one is used by berlin?)
<roptat>no, I'm able to generate pages properly, no sigabrt
<roptat>could it be because berlin and I don't use the same guile?
<roptat>also, I don't have the same haunt store path
<roptat>interesting, finished all its jobs in 1970 :p
<roptat>oh no, not all of them
<roptat>but all of the haunt-0.2.4 builds
<leoprikler>1970 was a busy year indeed
<Noisytoot>roptat: It used guix time-machine to go back in time to 1970
<pretzel>Is guix network bootable? Is there an update to: ?
<liltechdude> how to solve this problem?
<liltechdude>how you any idea?
<liltechdude>any solve from ddg not helped(((
<apteryx>civodul: I've implemented your suggestion about GUIX_PYTHONPATH (no version in var name)
<apteryx>there's a bit more runtime involved, but still nothing to be concerned about
<apteryx>and it made revamping the collection with sed possible
<apteryx>I'm building the branch now, if I don't find any silly omissions I'll force push into cu/farewell-to-pythonpath soon
***fever is now known as Guest36745
<Guest36745>I've asked help earlier in this channel on getting java applications working. I installed font-gnu-freefont and font-dejavu to my system configuration. I'm still getting the same errors when trying to run jGRASP or ghidra.
<raghavgururajan>leoprikler: I just saw your email, which package were you referring to?
<raghavgururajan>Guest36745: I am not sure about the errors. But may be it is looking for a font-manager program (like fontconfig etc.)?
<Guest36745>I have fontconfig installed in my system declaration.
<Guest36745>If anyone is able to run either of those programs I would highly appreciate seeing your system declaration.
<raghavgururajan>Guest36745: Wait a sec, the application was not installed via guix package-manager right?
<roptat> Guest36745 I found this, maybe related?
<leoprikler>raghavgururajan: all of them
<raghavgururajan>leoprikler: There has been few hundred commits after the fork.
<leoprikler>which fork?
<raghavgururajan>You were asking about at which point they were forked. That differes with each package.
<apteryx>rust@1.29.2 bootstraped from mrustc@0.9 is shaping up!
<leoprikler>ahh, sure, but there has been a common ancestor at some point
<leoprikler>so it doesn't really make sense to say it's version "0" if it's actually version x.y+300
<leoprikler>and that point applies to all packages :)
<efraim>nice on mrustc. I wasn't able to get it to work the last time I looked at it
<ngz>While trying to update Apertium, I get the following build error "ld: error: /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1/lib: read: Is a directory". Does that ring a bell somehow?
<avalenn>How would you use a guile-lib module in guix ?
<raghavgururajan>leoprikler: Ah. So if it was foked after v2.4.4, the git version should be 2.4.4+?
<civodul>apteryx: re mrustc, well done!
<lfam>Hey apteryx, I saw your question last night
<lfam>I don't recall the situation very clearly, tbh
<lfam>I'm going to reread the old messages. If it's convenient, can you point out the most salient about your proposal? I don't really look forward to reading the entire discussion again
<lfam>I definitely remember the social dynamics
<lfam>I mean, can you point out the most salient message?
<apteryx>the point would be adding the capacity to say that our resulting linux-libre sources match 1:1 with those of the upstream linux-libre project
<lfam>Right, that I get
<lfam>But... as you saw... there are other dimensions
<lfam>I skimmed last night and saw that you discussed the question of whether it's appropriate for us to "make things free" with Guix tools, and came to a satisfactory conclusion about that
<lfam>Are there any cons to your proposal?
<apteryx>lfam: I added the ability to make the comparison optional, meaning it still possible to forego the comparison with linux-libre upstream if they haven't released in time for a critical security update; that seemed to be one of the reason to be against it.
<apteryx>but analysing the time frame in which the linux-libre are made, it seems the occurence where we'd have to do that would be rare (linux-libre releases rather timely)
<lfam>Right, that could be annoying, although rare in practice from what I've seen.
<lfam>Do you have an idea of how long the comparison takes? The recent-ish addition of the "check for blobs" stage slowed things down a lot and caused build failures on berlin. (That's a bug in the build farm configuration, but still a problem)
<apteryx>remaining cons are: an extra git checkout to be made
<lfam>To clarify, those "build failures" are timeouts
<lfam>The linux-libre.git repo?
<apteryx>the check the blobs is expensive both in times and memory, but the compare is cheap (other than network + disk space)
<apteryx>lfam: yes
<lfam>Is it a gigantic repo?
<apteryx>it's about the same size an an unpacked linux kernel (1 GiB)
<apteryx>last I checked
<lfam>Not too bad
<lfam>Not great but not too bad
<lfam>And it's hosted by fsfla?
<lfam>If we started to use it, we should make sure that software heritage mirrors it
<vagrantc>can that be downloaded in compressed form?
<apteryx>Git already serves it compressed I think
<vagrantc>so it's just a bit more disk space for the most part
<vagrantc>i looked into the linux-libre .git repository a while back and actually made some local kernel builds from it
<vagrantc>it turned out to be a lot slower to download the git repository, but maybe there was some way to speed it up
<vagrantc>but downloading a git repository vs. a tarball, no huge surprise
<lfam>I do think long-term availability of the linux-libre stuff is kind of a weak spot.
<vagrantc>i was also wondering if we need to run both the per-file linux-libre deblobbing check as well as the whole-tarball deblobbing check ...
<lfam>vagrantc: Are you saying that we do that already? Or are you talking about apteryx's suggested change?
<lfam>vagrantc: In general, I think we need to make this stuff more efficient.
<lfam>It's already pretty expensive
<vagrantc>i thought we're doing it already ... haven't seen apteryx's proposal
<apteryx>another cons is: still an unsatisfactory solution for some GNU FSDG proponents (in their view we shouldn't touch the nonfree stuff at all, so we should directly use the linux-libre sources rather than process it ourselves).
<lfam>Right, I know that point of view apteryx
<apteryx>but that's arguable; my opinion on this is that we're in a gray zone, and clearly our spirit is empowering users so that makes defendable in my view.
<vagrantc>i had someone innocently got caught up in the firestorm around that whole mess for a while there
<lfam>It's tricky because 1) I just don't like it! :) and 2) historically, linux-libre "source tarballs" were not available long-term
<apteryx>lfam: yes, that's history now. The git repo is there to stay and was setup for that reason.
<lfam>Like, in my opinion, it shouldn't be hard to acquire storage capacity to store these things in perpetuity. But they have not done that for the source tarballs, forcing us to deblob ourselves. But they created the Git repo to obviate that
<vagrantc>there was some resentment that guix wasn't using the linux-libre git repo
<lfam>Yes, I know
<lfam>The social dynamics are quite fresh in my mind
<lfam>And soul
<apteryx>so, after all that my proposal is somewhat a middle ground that hopes to provide a win/win fo both projects
<vagrantc>likewise ... i see the various angles and perspectives ... but also know it's an imperfect world :)
<bdju>qutebrowser 2.0 is out, hope to see it in guix soon!
***fever is now known as Guest42056
<Guest42056>raghavgururajan: No the application was not installed using guix. As far as I can tell there is no package available for either jGRASP or Ghidra.
<apteryx>in a failed build kept with -K, when are the environment variables defined in the 'environment-variables' captured?
<apteryx>supposed to be all that were defined at the time the build failed (documented).
<apteryx>which is perfect :-)
<apteryx>vagrantc: we don't run the checker twice; the linux-libre is deblobbed, packed in a tarball *then* checked, IIRC.
<apteryx>the naming of the scripts can confuse
<raghavgururajan>Guest42056: I see. I am not sure if applications not installed via guix will work in guix system, as there will be changes in FHS. But someone else might have insight on this.
<Guest42056>roptat: Thanks for sending that link to the OpenJDK issue. Is there a way to create that file mentioned locally? Or should that be something delegated to a pull request as it seems like it could affect several applications.
<vagrantc>apteryx: ah, right ... it's coming back to me :)
<roptat>Guest42056, JAVA_HOME is in the store, right?
<roptat>if so, we should fix the openjdk package
<Guest42056>Yes, although I'm not 100% sure that adding a configuration in JAVA_HOME would fix the problem, I'd have to try I suppose.
<Guest42056>Some people in the thread on github said it worked for them, others said simply installing fontconfig and dejavu fixed it.
<roptat>do you have java, fontconfig and a font in the same profile?
<roptat>are they from the same guix version?
<Guest42056>Yes, I am new to guix though so it's possible I messed up
<Guest42056> (packages (append (map specification->package '("fontconfig" "sway" "awesome" "xmonad" "dwm" "stumpwm" "openbox" "i3-wm" "i3status" "dmenu" "st" "sddm" "font-gnu-freefont" "font-dejavu" "nss-certs"))
<Guest42056>This is taken from my system declaration.
<roptat>if it's from the system, it's fine
<roptat>it's the same profile
<roptat>and from the same guix
<roptat>though I don't see icedtea or openjdk in that list
<Guest42056>I have openjdk installed in my profile.
<roptat>can you try installing a font and fontconfig in your profile too?
<roptat>(both should not be necessary, but maybe there's something where it can only look at the user profile, and not the system profile)
<Guest42056>Thanks, doing that now.
<Guest42056>Yup, just installed fontconfig and font-dejavu, and I'm still getting the error.
<roptat>can you run fc-cache -f
<Guest42056>Oh that's true
<Guest42056>Still no dice :/
<Guest42056>fc-list returns dejavu fonts along with the others I've installed so it shouldn't be that.
<roptat>well, I have no idea then
<Guest42056>Thanks for your help though.
<roptat>need to go too, hope someone else can help!
<jonsger>uff, the new cuirass is more difficult to setup and sadly not documented...
<kozo[m]>Do I need to create a package definition if I want to run a program that came in a .tar.gz?
<lfam>jonsger: You should report the missing documentation to mothacehe
<kozo[m]>When I currently try to do it, it says it can't find the file or directory
<lfam>kozo[m]: It's a binary compiled for some other system?
<kozo[m]>Excellent question...
<kozo[m]>Sorry, I don't know
<jonsger>lfam: I know, I already did it for the not merged simple-cuirass service. But in the meantime he did the hard upgrade of cuirass-service-type. So I can not upgrade my system for security updates...
<lfam>kozo[m]: It's probably reporting that it can't find some other program on the system... perhaps the loader
<kozo[m]>lfam: I used sh to run it and it says "cannot execute binary file"
<kozo[m]>so that is a yes
<lfam>It's not expected that binaries compiled for other operating systems would work on Guix
<aecepoglu[m]>I'm trying to package . I have imported it but the build fails due to glib.h being unavailable. I have it in the `inputs` and `native-inputs`. What could I do?
<lfam>kozo[m]: You could make the missing binaries available in the expected locations with the extra-special-files service
<lfam>aecepoglu[m]: As always, you should share your package definition on <> :)
<lfam>That will help people help you
<kozo[m]>lfam: Thank you for the direction.
<jonsger>lfam: found "documentation" in guix-maintenance
<aecepoglu[m]>I have been able to resolve it by adding `pkg-config` to inputs
<lfam>apteryx: Did you get my private messages? You don't have to reply to them, but it would be helpful to know if you received them
<joshuaBP`>hello guix people!
<jonsger>cbaines: your cert at expired today
<cbaines>jonsger, ah, thanks, I should fix that at some point...
<jonsger>cbaines: I discovered in long trials that you have to set nginx servers to `(listen '("443 ssl"))` in order to make them work together with certbot :)
<cbaines>I think I just need to get certbot to trigger NGinx to reload the certificate when it's updated
<jonsger>ah, I think I restart nginx and reboot my server pretty often :p
<lfam>cbaines: The bayfront.scm configuration in maintenance.git has an example
<cbaines>yeah, I've seen, I just need to get around to it
<cbaines>as with most things, it's easy to put it off by just restarting the service when it breaks