<juli>are you willing to share the config in question? and i'm assuming this is a custom service so the service's source file as well? through a pastebin service like ttm.sh or paste.debian.org, of course
<juli>i belive the -L flag is the same as the one in Guile and if that's the case I suspect the module declaration is incorrect and/or does not correspond appropriately to the filesystem hierarchy
<juli>because i've run into issues for that reason before ;)
<adam-kandur>hi guix! I have a problem, there is a package libtcod which worked fine but for some reason it cannot be built anymore. I checked git log of gnu/packages/game-development.scm and this packages have same hash sum and git tag. What could go wrong?
<juli>most likely the version of some input or other has changed, thereby altering the conditions the package is built under and preventing it from building successfully
<juli>ah, yeah, that'll do it XD glad you figured it out :)
<yomiio[m]>I'm making over €100,000 weekly from Mrs FloraGordon, if you are in search of good platform to invest your bitcoin with, click on the link below to contact she will help you make profit on weekly basis
<ryan77627>Hey, quick question. I am trying to make a new package definition for a utility I use (wdisplays) and i got it to build, however it fails to launch due to a missing shared library, apparently it cannot find "libGLESv2.so.2". Way wondering if anyone knew which package provides this so I can add it to my package's inputs.
<podiki[m]>probably mesa, but if it built it is likely trying to do a dlopen or something where the path will need to be patched to point to the mesa package (lots of examples of this in guix to look at)
<podiki[m]>otherwise build would have failed when it couldn't find that library to link to
<ryan77627>podiki[m]: Ah, I have seen this a few times and wasn't sure what they were for. That is probably what is going on since adding mesa as an input already failed. I will look into adding the correct path-patches in. Thanks!
<podiki[m]>yup, usually if something built but then doesn't run due to missing library, something is trying to load a library directly at runtime and so wasn't caught at building
<podiki[m]>look for dlopen calls for instance, or similar (e..g. pythons has...I forget, but a direct open of library)
<podiki[m]>searching for libGLESv2 in the code should get you there
<ryan77627>Hmm... I did a quick `grep -r` through the repo's code, and there is absolutely no mention of libGLESv2. I was able to get it to launch (albeit with some bugs) by setting GDK_GL=false. I am not familiar with GTK, so I am unsure what this actually did on the GTK side.
<ChocolettePalett>Is it possible to configure "Initial RAM Disk" to autounlock LUKS-encrypted partitions so that I only have to type my password once?
<podiki[m]>I don't think so (not direct experience, but from hearing that asked frequently; I believe the limitation is due to the store being world readable and the issue of storing secrets, but not sure the details here)
<efraim>rekado: I successfully built rust-1.67 from rust-team on aarch64 locally
<rekado>reminder: ci.guix.gnu.org will be shut down on Wednesday morning
<rekado>the aarch64 nodes will be offline for a while longer as I’ll have to boot them manually.
<efraim>hopefully it'll be done building rust by then
<rekado>to make up for the downtime I’ll be returning kreuzberg with a new disk to the data centre when I go to boot the other two nodes
<rekado>simple-texlive-package could be renamed crude-texlive-package
<ngz>I wonder if we should make an effort about also replacing "doc/" files, or if concentrating on runfiles is enough. Some packager motivated enough can add phases just to take care of "doc/", so I'm not sure we should try automating it.
<rekado>but I think the most important improvement is to the runfiles
<ngz>rekado: For the time being, I have a local branch that fixes a couple of issues in simple-texlive-package, improves the importer, and rewrites a lot of Texlive package using old conventions. Maybe it could be a first step while I'm experimenting crudity on the texlive build system.
<civodul>nutcase[m]: yes, PATH gets overwritten if you use --pure or --container
<minima>hi, i think i have glibc 2.35 installed via guix home (on a foreign distro) but i still see 2.33 in my $GUIX_LOCPATH folder - do i need to do anything to "regenerate" the locales?
<flypaper-ultimat>nutcase[m]: you could also make a shell script yourself and have the shebang be "#!/usr/bin/env -S guix shell <your args to guix shell here + bash> -- sh" and then set it as you would in a sh script.
<minima>ok, perhaps i should rephrase it like this: if i install glibc and glibc-locales via my guix home configuration - what version am i going to have installed? 2.32, 2.33, 2.35?
<minima>ok, i suppose that "glibc" (as opposed to "email@example.com") simply gives me the latest version, i.e. 2.35, that's ok
<minima>but then i wonder why i still see 2.33 in my $GUIX_LOCPATH...
<minima>flypaper-ultimat: hey thanks, hm, yes, there's a bunch of profiles and various derivations that seem to be dependent on it - although i'm not sure how to interpret this exactly
<minima>i have glibc (and glibc-locales) listed as an installed package in my guix home configuration; i run guix pull and guix home reconfigure - and my expectation would be to have 2.35 in GUIX_LOCPATH, since that's the most recent version; instead i still have 2.33, i must be missing some step...
<flypaper-ultimat>you could check if any of `ls -ld $(guix gc --list-roots)` match up with the profiles that you got from the previous? I personally don't use guix home, so i dont know if it sets GUIX_LOCPATH, but the info pages for installation on a foreign distro suggest that you set it yourself. (info "(guix) Application Setup")
<minima>ah! i see, apparently my GUIX_LOCPATH was set to "~/.guix-profile/lib/locale" whereas i suppose it needs to be "~/.guix-home/profile/lib/locale"... thanks flypaper-ultimat, that might the cause of my issue
<apteryx>so if a user needs root to generate them, they'd have access to the other users keys, so changing the output dir is moot
<minima>jpoiret: hey thanks for the heads-up; i think i eventually found the culprit; i had mistakenly hardcoded GUIX_LOCPATH to the wrong value in my guix home bash service (i use guix home on a foreign distro); all seems to be working fine after removing that spurious line :)
<apteryx>rekado: perhaps just the whole of /etc/ssl-ca/ can be made readable to root (currently anyone can read the user certs)
<nutcase[m]>flypaper-ultimat: https://paste.debian.net/1279664/ this works now. I previously had --expose=/dev/dri included (and other parameters) that somehow caused some problems that I weren't able to relate to these parameters. And with another version mvn couldn't find the JVM. Now it works, thank you!
<Kabouik>I am getting a 'setlocale() failed' with foot installed from Guix on a foreign distro, and no such issue with foot installed from apt. Is there a Guix package I need to install to fix that? I would prefer using the Guix foot package.
<Kabouik>I have no experience with Guix as just a package manager on a foreign distro, not sure which packages are needed for locale issues.
<rekado>Kabouik: glibc-locales (or a subset thereof) and GUIX_LOCPATH
<Kabouik>Thanks rekado. Installing the package. GUIX_LOCPATH is set automatically, right?
<ieure>Even thought they also look like the yip-yips from Sesame Street.
<Kabouik>I am having an issue with foot terminal and SOME terminal programs with Guix package manager. Some programs throw 'Error opening terminal: foot'. To be clear, foot is already started and I am running the binary commands in it. Apparently this usualy is a terminfo issue, but 'infocmp -a' shows key sequences as I think it should, no error. Guix package for foot also installs the required terminfo I think.
<Kabouik>The package I am trying to run is github.com/d99kris/nmail. I packaged it in my private Guix channel, it compiled and instaled fine. It even shows its --help just fine, but fails when trying to start its TUI if I ask it more than just --help.
<Kabouik>I have no such issue on a machine running Guix System, but here this is Guix on Debian.
<jpoiret>first things first, they use another script to detect the build dependencies, which relies on libs/apr/build/PrintPath but which has a wrong shebang (/bin/sh doesn't exist on Guix, you'd need to replace this by the actual path to sh)
<jpoiret>but i'd expect the tarball to already contain all configure scripts without needing to bootstrap first
<jpoiret>this means that down the line the package definition might be invalidated because of it. Using a git-fetch instead should guarantee that the source doesn't change at all, unless upstream moves the tag you're referring to (which they should *never* do)
<jpoiret>macrocreation: you can still use a tag instead of the whole commit, and if upstream is really facecious and moves their tag around then you can settle on commits instead
<Kabouik>Thanks jpoiret, that was it. Actualy I did install ncruses when I saw that --help would work but not the UI of the program, and was surprised it did not install ncurses as a dep. But then I did not log out and in again, that was my issue!
<macrocreation>I think I know what prefix does. Allows you to specify license as license:
<Guest6120>If I do 'guix pull' my understanding is that it updates the guix binary in ~/.config/guix/current, and the one in ~/.guix-profile right? I'm doing a `guix pull --channels=<file>` and it seems to only update the ~/.config/guix/current profile - is that the expected?
<jpoiret>if you have a guix in .guix-profile, that's probably because you installed the guix package which `guix install guix` which is a bad idea, you should remove it
<futurile>jpoiret: ah OK, I didn't realise that - been holding it wrong the whole time =-)
<ulfvonbelow>is there a way to GPG-sign mail sent by 'git send-mail'?
<Guest19>I bought a SATA SDD. Can someone tell me the steps I need to execute to install my system on my new SSD? I know that I need to boot from the guix iso and setup my SSD to the old UUID from my config.scm but what else?
<apteryx>ulfvonbelow: yes, git takes care of it if it's configured correctly
<apteryx>see etc/git/gitconfig file in guix checkout, which is used out of the box
<jpoiret>apteryx: really? I don't think there a way to do that
<jpoiret>git send-email talks smtp directly, it would need to attach a gpg signature which I'm not sure it can do (at least I've never found anything when I searched a couple of times)
<apteryx>ulfvonbelow: ah, I misread. I thought you wrote sign a commit, not the email
<apteryx>then no, but you could try using something like GNU Anubis
<ulfvonbelow>would a gpg signature interfere with the recipient trying to use 'git am' or similar?
<apteryx>ACTION is still getting 403 Forbidden with a cert made with CN=ci.guix.gnu.org.
<apteryx>I'm not sure if nginx uses the new /etc/ssl-ca, as nothing can seemingly be done to restart it or reload it ('herd restart nginx' fails, 'herd reload nginx' hangs)
<nikita>I'm looking at the perl-reproducible-build-date patch which guix applies, and I wonder if in a system (pkgsrc) which does not yet have a formalized, all-across the packages, way for time to be set to a fixed stamp, does anything using perl rely on the default output of perl -V?
<apteryx>rekado: would tonight (CEST time -- in a few hours) be a good time to reboot berlin?
<apteryx>node 129 is still not reachable -- in case of problems you would be on the line
<vagrantc>nikita: currently, SOURCE_DATE_EPOCH is set to 0 in the build environment (usually)
<civodul>apteryx: in case you're reconfiguring, Cuirass doesn't work on current master
<nikita>maybe my sentence was too long :D in pkgsrc we don't do that yet (still some way to get there). I see that we use some output of perl -V for packages, but neither kernel version nor build time.
<civodul>i started investigating but that needs more time
<civodul>i'll have to work on it tomorrow anyway (hoping i can make enough time for it!)
<acrow>I wanted to better understand civodul's koan, (call-with-input-string "(. wtf?)" read) and tried to execute it against other than guile. kawa does what guile does, scheme48 -> wouldn't go into a shell....
<acrow>That kawa and guile appear to smooth things over is somewhat disturbing. More so that the simple 'guix shell scheme48' fails to work.... Though the scheme48 package appears to be relatively mundane. I've never seen guix shell fail before.
<apteryx>rekado: I think the old /etc/ssl-ca had both a /etc/ssl-ca/private/ca.crl and a /etc/ssl-ca/private/ca.key
<Guest1972>I mounted a nfs share from my vm. I shut down the vm and forogot to unmount my share. Now the whole system freezed up. I needed to login to a new tty and even ls need not work but after I forcefully unmounted the share everything was back to normal. is that a problem with guix or ext or just generally normal behaviour with nfs?