IRC channel logs

2023-05-08.log

back to list of logs

<Kabouik>Installing guix packages with many dependencies on aarch64 is painful. So much deps to build. :>
<Kabouik>many*
<vagrantc>hopefully the substitute servers will eventually catch up ... the available substitutes wasn't too bad for a while
<Guest19>Do they have specific hardware for that arch or do they cross compile that
<Kabouik>Trying to instal Obs, which I will not even use much, means I have several big t packages to build. Done with qtbase, but now qtdeclarative, and then others. It could take the night. :O
<formbi>hi
<formbi>how to add something to guix home's load path?
<Kabouik>big qt package, sorry my phone keyboard is trolling me.
<formbi>I have /home/.config/guix/home/services/*
<formbi>I mean /home/user/[…] of course
<formbi>and /home/user/.config/guix/home/home-configuration.scm
<minima>formbi, something like "guix home reconfigure --load-path=/custom-path/ home-config.scm" ?
<formbi>well, I did "guix home reconfigure -L /home/user/.config/guix home-config.scm" and it complains that (home services foo) is allegedly not imported in the config (it is)
<minima>hm, why would you have "-L /home/user/.config/guix" exactly?
<formbi>what do you mean?
<minima>i think you can have something along the lines of "-L /my-local-repo-checkout/gnu/packages"
<formbi>ah
<formbi>well, it already contains channels.scm, so why not other configs
<minima>(not sure whether you need the full path like that - you might want to wait for someone more experienced to chime in)
<formbi>I tried with a relative path too
<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
<formbi>of course, I just gotta get back to my PC
<juli>np
<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
<adam-kandur>should version mentioning be mandatory?
<adam-kandur>anyway it sounds like the most possible reason
<adam-kandur>can i change gcc verions in (gnu-build-system)?
<juli>the best solution here is probably to find the last commit where the package built successfully and install it from that version with `guix time-machine'
<juli>alternatively, you could try updating the package definition so it builds again with the current version of gcc
<adam-kandur>so i cannot change version of the compiler it the build system field?
<adam-kandur>also, can i for example run "guix shell package-name" and find versions of all packages used in the env?
<juli>you'll probably want to check out https://guix.gnu.org/en/manual/devel/en/html_node/package-Reference.html#index-package_002dwith_002dc_002dtoolchain
<juli>you should be able to run `guix shell --export-manifest' with either just a package or, if you're looking to build it, `-D <package>'
<adam-kandur>juli: thank you for the help, will go to check these resourses
<juli>best of luck :)
<Kabouik>That is how good finishing to build qtwayland on a phone feels: https://0x0.st/HZJp.png
<elb>I did a `sudo guix pull` and my substitutions problems seem to have gone away, it looks like bordeaux is saving me
<zacchae[m]>Is there a way to reboot into a previous generation remotely?
<lrabbt_>hello, I'm having problems running `info`, it just aborts the execution
<lrabbt_>I found out it happens when LANG=pt_BR.utf8
<lrabbt_>it works normally when LANG=en
<formbi`>adam-kandur: you can change the C toolchain similarly to that: http://ix.io/4vqt
<formbi>juli: ok, so the home config is this: http://ix.io/4vqu and the service file is this: http://ix.io/4vqv
<formbi>ah, got it xD
<formbi>the service file referenced pipewire-0.3 which got moved to just pipewire
<formbi>the very helpful error message ( http://ix.io/4vqw ) bamboozled me
<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
<yomiio[m]> https://t.me/FloraGordon
<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.
<ryan77627>s/Way/Was
<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.
<apteryx>ce7
<mirai>apteryx: any luck figuring out what's wrong with XDMCP?
<apteryx>haven't dug into it yet :-/
<apteryx>I just pushed "b7e7744626 origin/master Revert "doc: Update all menus."; I was trying to understand why this guix-manual.drv breaks (on exercising 'guix pull' with 'make as-derivation')
<apteryx>It'd be nice to fix the menus without breaking 'guix pull' ^^'
<apteryx>I'm off to catch some zzz
<apteryx>mirai: o/
<mirai>night
<vagrantc>oof. lots of rebuilds on master...
<vagrantc>mesa -> qt* ?
<podiki[m]>looks like the mesa set of patches was pushed to master (rather than a branch for building/testing)
<ChocolettePalett>I have a quick (yes-or-no question):
<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
<jpoiret>efraim: will they be always built by CI?
<jpoiret>some other channel™ relies on newer rusts, and up until now we had to build all of the newer rust by hand if though they're defined in Guix source
<jpoiret>I just had a pretty nasty problem: my GRUB modules directory had most of its files with ~ at the end for some reason, which meant it couldn't boot. Thank god I have a rescue USB nearby
<efraim>jpoiret: the rust-team branch updates the default rust to 1.67
<jpoiret>oh, great!
<ngz>Hello Guix.
<sneek>ngz, you have 1 message!
<sneek>ngz, rekado says: #:tex-directory was a hack. The .ins files may specify directories as well, so we can’t just do whatever we want either.
<rekado>ngz: your assessment of the shortcomings of #:tex-directory are on point. We do end up with garbage in the build directory.
<rekado>ngz: that’s why there are a few packages that have a build phase just to clean up that garbage or to move files aroudn
<rekado>*around
<rekado>the build system just isn’t that great and it ignores target directory specifications in .ins files
<rekado>lots of opportunities to improve it
<ngz>I'm not sure target directory specifications matter with the change I suggest.
<ngz>Wherever the file is, no matter how deep, it should be replaced.
<rekado>yes, I saw that
<ngz>AFAIK only one TeX Live package (over 7000+) has 2 files with the same name in a non "doc/" directory.
<rekado>I feel a little uneasy about this, because it seems … a little crude.
<rekado>but it’s an improvement
<ngz>It's still less crude that putting #trivial? #t anywhere, tho. :)
<rekado>I’d be happy to see that simple-texlive-package helper disappear, and the suggested change sounds good to me
<rekado>yes, sure
<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.
<ngz>s/concentrating/focusing/
<rekado>yes, the generated .pdf files bother me
<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.
<rekado>sounds good.
<rekado>thanks for taking this on!
<ngz>Well, that itch had scratched for too long…
<nutcase[m]>Hi, I need to set (not preserve) environment variables in a guix shell container (started from a sh-script). How do I do this in the most elegant way?
<civodul>nutcase[m]: hi! there's no nice way to do that, other than: VAR=value guix shell -E ^VAR$ ...
<nutcase[m]>civodu
<nutcase[m]>civodul: ok, thank you, I hoped for a less noisy way :-)
<nutcase[m]>hmm, the problem is, that I want to add something to $PATH. I think it gets overwritten anyways, right?
<nutcase[m]>is this what --search-paths is for?
<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 "glibc@2.33") 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...
<flypaper-ultimat>ks you could check "guix gc --referrers o
<flypaper-ultimat>correction: is it a store path? you could check "guix gc --referrers $GUIX_LOCPATH" if it is
<flypaper-ultimat>(to see what is using it. )
<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")
<flypaper-ultimat>(or with `ls -ld $(guix package --list-profiles)`)
<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
<flypaper-ultimat>cool!
<ngz>When I try to import (guix import texlive) from (guix build texlive) module, I get "no code for module (guix import texlive)". What am I missing?
<ngz>I mean from (guix build texlive-build-system) module
<rekado>on the build side only (guix build *) is made available
<rekado>(guix import …) is host-side code
<ngz>rekado: Hmmm. I would like to use files-differ? as a sanity check in texlive build system.
<jpoiret>minima: guix system still builds 2.33 locales FYI
<jpoiret>so that systems that haven't updated all their profiles yet don't just error out because of locales
<apteryx>we should update xorg for a CVE; time to graft?
<Guest9415>i installed two packages with no errors but 'guix package --list-installed' wont show them
<apteryx>or we create a xorg-team branch and bunch a couple xorg-related updates there
<apteryx>anything particular to keep in mind when udating xorg-server (a patch version bump to be grafted)
<Guest9415>i found my error. i did sudo guix install ..
<apteryx>ah! what your git checkout permissions under ~/.cache/guix/checkouts now...
<apteryx>ah nevermind, that'd be something else (sudo guix pull?)
<apteryx>or perhaps even 'sudo -E guix pull'
<apteryx>rekado: I'm looking at your 'new-client-cert.scm' and wondered; is it required that the users certs go to /etc/ssl-ca/certs/users/ ?
<apteryx>it's just for the users to deploy on their own systems, right?
<rekado>correct
<apteryx>do you think the script could output the keys to the current directory instead? then it wouldn't need to run as root
<apteryx>ah it needs to run as root anyway to read the CA
<apteryx>which is reasonable
<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)
<apteryx>to root only*
<GNUtoo>hi, I'm making changes to "(source (origin [...])) by adding (snippet #~(begin (delete-file "catch.hpp"))) right before (sha256 [...]) inside (source (origin
<GNUtoo>But for some reasons when running ./pre-inst-env, it doesn't remove that file, and if I change the version in file-name to an invalid one, it doesn't fail to extract the sources
<GNUtoo>Do I necessarily need to run make before running ./pre-inst-env inside 'guix shell -C -W -D guix' ?
<nutcase[m]>flypaper-ultimat: I tried this, but interestingely the executables of the packages listed in the shebang line aren't available at (unmodified) $PATH
<flypaper-ultimat>nutcase[m]: so this doesn't work for you? http://ix.io/4vsy
<civodul>apteryx: hi! i think we do both: you submit the patch that adds a graft and the patch that removes the graft; the former goes to master, the latter to xorg-team
<civodul>that's what lfam and others proposed at the Guix Days
<civodul>that's a good way to ensure grafts are removed in a timely fashion
<civodul>GNUtoo: hi! when working on Guix itself, you can use "guix shell -CW -D guix", but from there you still need to use "./pre-inst-env guix build your-package" to test your changes
<civodul>that way you actually run the code you modified
<GNUtoo>that's what I'm doing, but for some reasons I don't see it picking the things that I modified
<GNUtoo>(the only difference is that I did -C -W instead of -CW)
<GNUtoo>I'll try to chown all files to be sure it isn't a permission issue
<GNUtoo>I did that to ~/.cache guix/ ~/.guix and I still have that strange behavior
<GNUtoo>I modify (commit (string-append "v" version)) into (commit (string-append "vv" version)) in cpp-mustache and it fetches fine
<GNUtoo>same if I modify the base32
<civodul>GNUtoo: presumably ./pre-inst-env always adds your own 'guix' command to the front of PATH
<civodul>you need to make ./configure && make though, to make sure you have a local copy of that 'guix' command
<GNUtoo>Even if I rm gnu/packages/cpp.scm it still works (It tries to build cpp-mustache)
<GNUtoo>I tried adding lisp invalid syntax and it also tried to build it
<GNUtoo>ok
<jpoiret>civodul: is there a formal xorg-team? if not it might be risky since no one will own that branch and it might just rot awy
<jpoiret>away *
<civodul>jpoiret: actually i don't know, i just saw it mentioned in the backlog :-)
<jpoiret>might be better to just assign it to some other team if it doesn't exist
<civodul>yeah
<apteryx>something fishy in the way menus are used in contributing.texi; running 'texinfo-update-all-menus' on that file causes 'make as-derivation' to fail
<apteryx>in guix.texi.de IIRC
<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!
<flypaper-ultimat>nutcase[m]: great!
<apteryx>rekado: Just send a mail to guix-sysadmins; I'm lacking the passphrase for /etc/ssl-ca/private/ca.key
<apteryx>civodul: sounds like a good process
<ekimber>Hello guix. The static networking config isn't working for me with ipv6.. the default gateway I specified doesn't get set up. I see there is an issue for it already but it has been closed
<jonsger>ekimber: could you post your network config
<jonsger>and the link to the issue :)
<rekado>apteryx: note that /etc/ssl-ca is old
<rekado>what I worked on is /etc/ssl-ca-test
<rekado>see also /root/certificate-authority for the scheme script
<macrocreation>hi all, I am trying to build my first package but struggling
<macrocreation>I get  when I try to run my scm file with guix package -f package.scm ice-9/boot-9.scm:3330:6: In procedure resolve-interface:
<macrocreation>no code for module (gnu packages base download)
<GNUtoo>macrocreation: in package.scm you have (use-modules (gnu packages base download)) ? or what kind of code do you have to add "gnu packages base download" ?
<macrocreation>Thanks - this is what I have
<macrocreation>(use-modules (gnu packages base download))
<macrocreation>(define freeswitch
<macrocreation>(package
<macrocreation>    (name "freeswitch")
<macrocreation>    (version "1.10.8")
<macrocreation>    (source (origin
<macrocreation>              (method url-fetch)
<GNUtoo>macrocreation: (1) don't patch too much lines at the same time, you could have either pasted 1 line (the '(use-modules (gnu packages base download))' line) or used a pastebin
<macrocreation>My apologies.
<GNUtoo>(use-modules (gnu packages base)) will make packages from gnu/packages/base.scm available
<Guest9415>is there a way to install amdgpu version 23 ? i found only version 22,https://packages.guix.gnu.org/packages/xf86-video-amdgpu/
<GNUtoo>I don't see any gnu/packages/download.scm though
<macrocreation>I see
<GNUtoo>If you need gnu/packages/storage.scm and gnu/packages/base.scm you could use that:
<GNUtoo>(use-modules (gnu packages base)(gnu packages storage))
<macrocreation>Ah. So those are paths?!
<podiki[m]>Guest9415: you are in luck it builds with newer version without changes, so you can do guix install xf86-video-amdgpu --with-latest=xf86-video-amdgpu
<GNUtoo>I've no idea why, but they seem to correspond to paths in the guix source code
<podiki[m]>Guest9415: see https://guix.gnu.org/en/manual/devel/en/html_node/Package-Transformation-Options.html for similar
<Guest9415>podiki[m], thanks!
<GNUtoo>To find a where a package is you could also run 'guix edit <package name>' like guix edit coreutils, it will open the file where the package definition is.
<macrocreation>got it.
<GNUtoo>As the file is read-only you can't edit it, but you can at least find where it is, see it's definition, etc
<macrocreation>I don't really know what I am doing
<podiki[m]>Guest9415: welcome
<macrocreation>This is the error if I string download
<macrocreation>hint: Did you forget `(use-modules (guix packages))'?
<Guest9415>podiki[m], do i have to remove the currently amdgpu i have installed ?
<macrocreation>when I add guix packages - I get an error saying there is no such package
<GNUtoo>macrocreation: I'm not sure what is best but if you do guix package -f some-file.scm you will have to add a lot more (use-modules) than in guix, more than just packages
<GNUtoo>For instance you often need modules like (gnu) (guix licenses) (guix packages) etc
<macrocreation>is there a guide to taking an existing package and making it available.
<GNUtoo>And at the end of the file you need to add a list with your package inside
<macrocreation>Freeswitch is the one I am interested in
<GNUtoo>An alternative that has more documentation would be to add the package in Guix source code directly
<GNUtoo>You have some more setup but less code to get right
<GNUtoo>like you don't need to add a list and most imports are usually already there if you add it to an exsting file
<GNUtoo>And the manual has documentation for building Guix, testing or installing packages withing a git checkout and even on how to send patches
<GNUtoo>Note that maintainers can take a long time to review patches, so it's good to try to ping maintainers if you have no response
<Guest9415>podiki[m], it cant compile , i get a warning about a missing public key and then an error:failed to fetch source
<podiki[m]>you need to add the public key when it asks, maybe if you don't have e.g. gpg set up you can't do that? not sure
<macrocreation>Thanks. How do I add it to guix source?
<macrocreation>And how to i then maintain this.
<Guest9415>podiki[m], i will set up gpg and test again
<old>Is there plan to add clang-toolchain@16 ?
<GNUtoo>macrocreation: First you probably need to find the best file to add it in
<GNUtoo>Maybe telephony.scm is a good place
<GNUtoo>I didn't find other SIP servers like Asterisk so maybe adding there is fine
<GNUtoo>Maintainers will tell you what is best when you send the patch
<GNUtoo>Then there is a guix manual online, let me find the URL
<GNUtoo>guix.gnu.org/en/manual/devel/en/guix.html
<macrocreation>Thanks
<old>also is it known that clang-toolchain@15 does not support TSAN ?
<old>@14 works fine.
<GNUtoo>It has information on how to (a) build Gix from git (b) build or install packages from that git with ./pre-inst-env (c) send patches
<GNUtoo>It also has information on how to create packages definitions and all that but I personally prefer to look at exsting packages
<GNUtoo>Though the manual is probably best for starting as some packages use older deprecated syntaxes
<GNUtoo>for (a): "22.1 Building from Git"
<GNUtoo>for (b): "22.2 Running Guix Before It Is Installed"
<apteryx>old: I wonder why the discrepancy between 14 and 15
<GNUtoo>Ah "22 Contributing" is probably better even as it has all that is required for contributing: it starts from Building from git and ends up with sending patches
<apteryx>AFAICT, the only difference should be that the later uses the new all-in-one shared object approach (LLVM.so)
<GNUtoo>(coding style is important too for instance)
<macrocreation>thx
<GNUtoo>ACTION will be back later
<old>apteryx: I get the following error while configuring my projeect
<old> https://paste.sr.ht/~old/e8b82fd99e51cb1f5f5ab83ab23320b0cbf7efc9
<macrocreation>Thank you
<old>apteryx: in clang-toolchain@14, I do have a /gnu/store/.../lib/linux/libclang_rt.tsan-x86_64.a
<old>not in clang-toolchain@15. I only have a the *.so
<apteryx>seems an upstream issue/limitation? the upstream suggested way to build a shared library LLVM is using '-DLLVM_BUILD_LLVM_DYLIB=ON', which is now used starting from 15
<apteryx>14 was using the deprecated -DBUILD_SHARED_LIBS=ON style
<apteryx>other than that, I don't see differences between the 14 and 15 packaging
<macrocreation>Thanks
<apteryx>efraim: did you get a CC from Debbugs for 63375 ?
<apteryx>I used X-Debbugs-CC
<apteryx>rekado: did you also receive the CC? Debbugs' confirmation mail only mentioned efraim. I used multiple X-Debbugs-CC headers.
<efraim>I may have autosorted it into my guix-patches folder. I'll check my mail server to see how it arrived
<mirai>after performing a 'guix install emacs-debbugs', what other steps are necessary to finish setting it up?
<mirai>my emacs doesn't seem to pick it up
<efraim>I'm not sure if I got it through debbugs list subscription or through X-Debbugs-CC. I'm pretty sure it's been setup to not send it twice
<efraim>I should change that rule in my sieve to check for myself in a CC
<podiki[m]>mirai: make sure emacs is in the same profile and may need to restart emacs to pick it up (or lease manually add to load path store perhaps)
<Guest9415>how can i see the files installed by a package?
<mirai>podiki[m]: packages installed with 'guix install …' and packages installed via guix home still belong to the same profile right?
<mirai>I've restarted emacs already
<podiki[m]>mirai: that I don't know, I don't use guix home. I would make sure they are both in the same, either home or other profile
<jpoiret>mirai: no
<jpoiret>you'd need emacs installed in the `guix package` profile for emacs-debbugs to get picked up
<jpoiret>(usual search-paths requirement)
<dust56>Does kde plasma work in guix destro ? Or still wip. I tried to set it up but after login its just blank.
<apteryx>efraim: hmm.
<apteryx>if that's so, I'd need to review my mail filter as well, else they won't reach my INBOX
<mirai>jpoiret: right, looks like 'guix home' and 'guix install …' from the terminal are two different profiles
<mirai>I did a guix home reconfigure but this time with emacs-debbugs added and its picking it up
<Grimpper>Good evening. Please. Cloud anyone help me double check that Inferiors are working on guix? Can anyone run the guix shell inferior example from the GUIX manual? Here is the example provided:
<Grimpper>paste.debian.net/1279682
<rekado>apteryx: I have not received an email about 63375.
<Grimpper>This is the error upon running `guix shell -m manifest.scm` on the manual example
<Grimpper>paste.debian.net/1279683
<rekado>Grimpper: same here
<Grimpper>uff
<rekado>regression!
<Grimpper>Last issue on that matter is this one: https://issues.guix.gnu.org/32759
<Grimpper>and it is the implementation of the mixing feature
<Grimpper>anyone knows if this is a known issue?
<apteryx>rekado: so our multiple X-Header-CC usage is broken...
<apteryx>indeed, reviewing GNU Debbugs's process perl script suggested so
<apteryx>the last such header encountered is the one kept
<apteryx>so instead of using multiple headers, we need to use comma-separated values
<rekado>Grimpper: this is a fairly recent regression. I’ve been using inferiors many many times since 2018 and use them in the GWL as well.
<rekado>haven’t seen a bug report about this yet
<apteryx>is it much used though? and it's hard to know the result unless you control multiple emails subscribed to guix-patches :-)
<Grimpper>excuse my ignorance. Is there a way to check where the error was introduced? I heard about git bisect before. Could it be used to find the regression source here?
<apteryx>rekado: I've sent a v2 with comma-separated values for the X-Debbugs-CC header
<apteryx>you'll probably get it now
<apteryx>yep GNU Debbugs correctly transformed the headers in a CC value with all the correspondants
<Grimpper>rekado: should I open a issue on the tracker?
<apteryx>Grimpper: if there isn't one already, yes please :-)
<mirai>is there an agreed way to store non-embedded documentation about the internals within guix?
<mirai>by non-embedded I mean files that are too large or unsuitable to be inlined into the .scm file
<Grimpper>Not sure if it is relevant but running the test `make check` on a recently build guix shows this line on the inferior test:
<Grimpper>`SKIP: tests/inferior.scm`
<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?
<Kabouik>It is set to ~/.guix-profile/lib/locale
<Grimpper>On which commit should i test the issue before submitting to the tracker?
<Grimpper>i don't understand why the last commit of master follows v1.3.0 and not v1.4.0. Could someone explain, please?
<Kabouik>Yeah that seems to have solved it rekado, thanks
<apteryx>Grimpper: probably the 1.4.0 tag was made on frozen branch that got cherry picked rather than merged, not sure
<rekado>the (guix config) compile error that happens with inferiors is odd
<apteryx>that's suboptimal
<rekado>it sees repository not as data but as a variable name
<Grimpper>so for bug reporting I should just use the last commit on master even if it follows v1.3.0 tag, no?
<Grimpper>apteryx
<rekado>this is what the generated config looks like: https://elephly.net/paste/1683567884.html
<rekado>the quote before “(repository” has been lost
<apteryx>Grimpper: yes
<rekado>this must be a bug in (guix self): make-config.scm
<rekado>commit 316fc2acbb112bfa572ae30f95a93bcd56621234 initially introduced the recording of channel metadata. This is now broken in that the result is apparently not quoted.
<Grimpper>How could I add snippets to the bug report mail? Triple back-tick? '```'
<rekado>issues.guix.gnu.org recognizes the emacs way of weird scissor lines…
<Grimpper>i don't understand what does that mean
<rekado>--8<---------------cut here---------------start------------->8---
<rekado>and:
<rekado>--8<---------------cut here---------------end--------------->8---
<rekado>if that doesn’t come natural to you just use whatever :)
<rekado>different MIME type works too
<Grimpper>alright. I'm lost. Could you give me an example mail please? D:
<ieure>I always liked the lil ASCII scissors.
<rekado>in Emacs message-mode I use C-c M-m
<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.
<TheSkylarverncc[>set your TERM to something like xterm-256color
<Kabouik>Oh indeed that works, but should foot not use foot as TERM instead?
<TheSkylarverncc[>it does, but many programs don't recognize it
<Kabouik>But I do not have to do that on my Guix System machine, with the same program instaled from my private channel, and foot from the main guix channel
<TheSkylarverncc[>maybe it's an old version or something
<Grimpper>I did submit the bug report. How could I check it it has been received?
<macrocreation>Hi all, been making some progress on the freeswitch package. However I am stuck at freeswitch asking for libtool and saying it's missing.
<macrocreation>I have added it to native-inputs but it doesn't work.
<macrocreation>any ideas?
<Grimpper>is the build system using pkg-config to locate libtool?
<macrocreation>No. I removed pkg-config
<jpoiret>Kabouik: you need to install ncurses in your profile for the TERMINFO_DIRS to be properly set
<macrocreation>as guix build kep complaining
<macrocreation>I was missing a use-module clause
<jpoiret>Grimpper: if it is you first interaction with bug-guix it will have to go through manual moderation, so it might take a bit
<jpoiret>otherwise you can have a look at debbugs.gnu.org or issues.guix.gnu.org
<Grimpper>jpoiret: first one
<Grimpper>I feel like I did a messy mail but we will see
<jpoiret>Kabouik: after doing this you'll need to log-out log-in since it added a new environment variable to the profile
<Grimpper>if you remove pkg-config how is the build system locating the libs?
<jpoiret>there are some other ways to locate libs
<jpoiret>esp. if you don't need specific building flags, using -lsomelib with your compiler is enough
<macrocreation> https://pastebin.com/X8U6fK1a
<macrocreation>And I get /scripts/ci/build-requirements.sh: /tmp/guix-build-freeswitch-1.10.9.drv-0/freeswitch-1.10.9/libs/apr/build/PrintPath: /bin/sh: bad interpreter: No such file or directory
<macrocreation>build-requirements: libtool not found.
<macrocreation>                    You need libtool version 1.5.14 or newer to build FreeSWITCH from source.
<macrocreation>Do you have an example of pkg-config in use
<macrocreation>I have tried including it in native-inputs but it doesn't work.
<macrocreation>Also does anyone know what the difference between (use-module (xx)) vs #:use-module syntax is
<jpoiret>there's no difference, but the latter is preferred if you're defining a new module
<jpoiret>well, I think there is but it's pretty low-level and not something you should worry about
<jpoiret>in any case, did you add libtool to the native-inputs?
<jpoiret>ah my bad, didn't see you posted your definition
<jpoiret>before i forget: use (invoke "some" "thing") instead of (zero? (system* ...))
<macrocreation>I've changed by native inputs line
<macrocreation>   (native-inputs
<macrocreation>     (list pkg-config autoconf automake libtool))
<macrocreation>it complained about autonconf automake in sequence
<macrocreation>and then when I added libtool.
<macrocreation>now it just keeps complaining about libtool even though it's part of native-inputs
<jpoiret>macrocreation: I'm having a look
<macrocreation>Ok thanks
<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
<macrocreation>Should i not invoke bootstrap
<jpoiret>ah but apparently not. Then there is no reason not to fetch from git instead of a tarball I would say
<macrocreation>Let me try that
<jpoiret>no, it doesn't work, just tried it
<jpoiret>by the way, under no circumstances should you use a github-generated tarball: github doesn't promise that these tarballs won't be regenerated later, possibly with a different checksum
<macrocreation>I wish you could screen record your findings. I have so many packages I need to port - this way you can replicate your thinking.
<macrocreation>Ok.
<macrocreation>Whats the best way to do it then?
<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>but some upstreams do this :(
<macrocreation>Ok got it.
<macrocreation>git-fetch against a specified commit.
<macrocreation>I'll modify accordingly
<TristanCottam[m]>Hi everyone! Is there a simple way to share a modified Guix Git repo?
<TristanCottam[m]>I started my own channel, but I'm thinking about switching to [direct checkout hacking](https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html).
<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!
<Kabouik>Thanks TheSkylarverncc[ too.
<macrocreation>Ok.
<macrocreation>Any ideas on how I proceed?
<jpoiret>macrocreation: I can give you something that works better but isn't finished :)
<macrocreation>Yeah please do.
<jpoiret>but i didn't switch to git-fetch, you should be able to swap that in
<macrocreation>Yes I can do that.
<jpoiret>so it does need pkg-config but not to find libtool :)
<macrocreation>Yeah I figure out how to add pkg-config.
<jpoiret>macrocreation: https://paste.debian.net/1279696/
<jpoiret>feel free to ask any questions about my changes (other people can also answer them)
<jpoiret>mostly good practices
<jpoiret>feel free to replace the url-fetch with git-fetch :)
<apteryx>which logs should I look at to debug 403 Forbidden from nginx?
<apteryx>I'm trying to debug authentication problems with cuirass (berlin)
<macrocreation>Wow. This seems to have gone much further along
<macrocreation>It's failing on libpq
<macrocreation>But wow.
<macrocreation>jpoiret Thank you!
<macrocreation>What does the :prefix license do?
<macrocreation>Asking because I had that there from some code I pasted and removed it.
<TristanCottam[m]>Prevents the zstd package from being mixed up with the zstd license, AFAIK.
<macrocreation>Also why include spandsp as a input for runtime? Does it solve a whole lot of other dependencies?
<macrocreation>More questions? What is the difference between (define-module...) and (package...)
<macrocreation>and (define-public ....)
<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>futurile: only in .config/guix/current
<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>I do not know
<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
<nikita>so I guess that's ok
<apteryx>civodul: oof! spawn related?
<apteryx>berlin was last reconfigured on May 5th with Guix 6922069bcbe5c08da09c00e5aad44e390ebd1cc7
<apteryx>civodul: do we have a bug # to follow on?
<jlicht>hey guix!
<acrow>Does anyone else see problems with 'guix shell scheme48'?
<jlicht>acrow: can confirm, something about 'error: gerbil: unbound variable'
<civodul>apteryx: i haven't report it yet because i'm not even sure what's going on; essentially evaluation never completes
<civodul>*reported
<apteryx>OK! I see no recent cuirass package updates
<apteryx>perhaps the core-updates merge?
<civodul>yeah
<apteryx>hm, so we shouldn't reboot cuirass, I think 6922069bcbe5c08da09c00e5aad44e390ebd1cc7 is post-merged
<civodul>yeah, probably not :-/
<apteryx>although I did do 'herd restart cuirass' earlier and it didn't seem to stop processing evaluations
<civodul>i rebooted guix.bordeaux.inria.fr lightheartedly last week...
<civodul>ah well, dunno, maybe it's just my setup
<apteryx>probably not :-)
<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....
<apteryx>weird, no man pages with openssl
<apteryx>ah, the doc output
<apteryx>how does the authentication works in cuirass?
<apteryx>seems to be purely a nginx/web server SSL auth thing
<apteryx>like, any endpoint using an admin/something URL triggers auth?
<civodul>apteryx: Cuirass has no authentication support (no accounts, etc.)
<civodul>the SSL certificate thing is a pure nginx mechanism
<civodul>i have no idea how it works though
<apteryx>I see it's configured in hydra/nginx/berlin.scm
<apteryx>";; For Cuirass admin interface authentication"
<civodul>i use an SSH tunnel to access it...
<acrow>FWIW, scheme48 finds "(. wtf?)" to be an abomination and throws the an error.
<civodul>acrow: heh, that's understandable :-)
<apteryx>civodul: oh, didn't know this bypassed the auth (a local connection)
<apteryx>so yeah, any page starting with /admin is configured to invoke 'ssl_client_verify'
<apteryx>else it returns 403
<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
<apteryx>the new one lacks the former
<apteryx>would you know how to generate it?
<apteryx>I guess what 'generate-client-certificate!' does
<rekado>apteryx: re 129: I’ll be in the data centre on Wednesday after the shutdown
<rekado>power is cut Wednesday 1am
<rekado>restored 6am
<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?
<Guest1972>s/need/did
<rekado>I’m at the dentist after that and then in the data centre to boot up the aarch64 nodes, drop off the new kreuzberg there, and plug in the cable for node 129
<rekado>oh, someone should remember to update the DNS IP so that we don’t lose the transferred zone
<rekado>better do that before the power cut
<sharlatan>Hi for anyone alive here ! =)
<lemos[m]>i have a little problem with the update i mentioned a few days here
<lemos[m]>when i clone from https://git.savannah.gnu.org/git/guix.git, and try to add guix/gnu/packages as a channel to test if the package i updated shows up correctly
<apteryx>Guest1972: someone investigated that a bit and found that it was a kernel syscall that was hanging when shutting down the system with live nfs mounts (see: https://issues.guix.gnu.org/62986)
<lemos[m]>a lot of errors come up complaining some things are missing
<lemos[m]>did i clone from the wrong repository or missed something?
<lemos[m]>s/missed/miss/
<apteryx>Guest1972: but shepherd should probably take action when this occurs
<apteryx>rekado: OK!
<sharlatan>Was anything changed during preparing patchs from curren checkout of Guix? I've got an isssue I've never seen before - whre commit can't be finished due to error of Gpg.
<muradm>hi guix
<muradm> https://paste.rs/rru
<muradm>commit 8b972da068708a8b17f3ab153ea940690ca49ca9 introduced commit.gpgsign=true
<muradm>non gpg users or fine tuned gpg users in pain
<TheSkylarverncc[>non gpg users deserve pain
<muradm>such change deserves mentioning in manual event in guix pull --news
<muradm>git reported error is at least non-informative (if non gpg user) at most misleading (if fine tune gpg user)
<mirai>git config --local set commit.gpgsign false
<muradm>mirai: that works of course
<muradm>any way, fyi, thank you, bye