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. :> <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>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>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? <minima>i think you can have something along the lines of "-L /my-local-repo-checkout/gnu/packages" <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>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>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 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 <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 <formbi>the service file referenced pipewire-0.3 which got moved to just pipewire <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. <mirai>apteryx: any luck figuring out what's wrong with XDMCP? <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' ^^' <podiki[m]>looks like the mesa set of patches was pushed to master (rather than a branch for building/testing) <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 <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>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. <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. <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>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. <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]>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? <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>correction: is it a store path? you could check "guix gc --referrers $GUIX_LOCPATH" if it is <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 <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>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? <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>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) <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 <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 <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 <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 <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 <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 <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! <apteryx>rekado: Just send a mail to guix-sysadmins; I'm lacking the passphrase for /etc/ssl-ca/private/ca.key <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 <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: <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" ? <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 <GNUtoo>(use-modules (gnu packages base)) will make packages from gnu/packages/base.scm available <GNUtoo>I don't see any gnu/packages/download.scm though <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)) <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 <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. <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 <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 <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 <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 <old>also is it known that clang-toolchain@15 does not support TSAN ? <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) <old>apteryx: I get the following error while configuring my projeect <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 <apteryx>efraim: did you get a CC from Debbugs for 63375 ? <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>you'd need emacs installed in the `guix package` profile for emacs-debbugs to get picked up <dust56>Does kde plasma work in guix destro ? Or still wip. I tried to set it up but after login its just blank. <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: <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>and it is the implementation of the mixing feature <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>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: <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 <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? <rekado>the quote before “(repository” has been lost <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… <rekado>--8<---------------cut here---------------start------------->8--- <rekado>--8<---------------cut here---------------end--------------->8--- <rekado>if that doesn’t come natural to you just use whatever :) <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. <Kabouik>Oh indeed that works, but should foot not use foot as TERM instead? <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 <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. <Grimpper>is the build system using pkg-config to locate libtool? <jpoiret>Kabouik: you need to install ncurses in your profile for the TERMINFO_DIRS to be properly set <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>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>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> You need libtool version 1.5.14 or newer to build FreeSWITCH from source. <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>now it just keeps complaining about libtool even though it's part of native-inputs <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>ah but apparently not. Then there is no reason not to fetch from git instead of a tarball I would say <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. <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! <jpoiret>macrocreation: I can give you something that works better but isn't finished :) <jpoiret>but i didn't switch to git-fetch, you should be able to swap that in <jpoiret>so it does need pkg-config but not to find libtool :) <jpoiret>feel free to ask any questions about my changes (other people can also answer them) <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>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>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>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 <apteryx>berlin was last reconfigured on May 5th with Guix 6922069bcbe5c08da09c00e5aad44e390ebd1cc7 <apteryx>civodul: do we have a bug # to follow on? <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 <apteryx>OK! I see no recent cuirass package updates <apteryx>hm, so we shouldn't reboot cuirass, I think 6922069bcbe5c08da09c00e5aad44e390ebd1cc7 is post-merged <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 <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>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 <apteryx>I see it's configured in hydra/nginx/berlin.scm <apteryx>";; For Cuirass admin interface authentication" <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' <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>I guess what 'generate-client-certificate!' does <rekado>apteryx: re 129: I’ll be in the data centre on Wednesday after the shutdown <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? <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 <lemos[m]>i have a little problem with the update i mentioned a few days here <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? <apteryx>Guest1972: but shepherd should probably take action when this occurs <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>commit 8b972da068708a8b17f3ab153ea940690ca49ca9 introduced commit.gpgsign=true <muradm>non gpg users or fine tuned gpg users in 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