Re: Installing cross-compiled packages alongside a cross-compile toolchain
Hello Christoph, Christoph Buck writes: > Total guix newbie here. Currently i am evaluating if guix could be a > better alternative to yocto. My use case is as follows. I want to > declarative define a system (for aarch64), generate an image and deploy > it by flashing it to an sd card. Additionally i want to setup a > development environment on my x64 dev machine, which i want to use to > develop native applications for the aarch64 target. For this i need a > cross-compile gcc toolchain (host: x64 target: aarch64) and > cross-compiled packages of all libraries my application will use. Sounds > like the perfect use-case for the `guix shell` command. I'm very interested in the second part as well but unfortunately it's not something supported by Guix without resorting to hacks, as you found out. I never had the time and/or energy to dig deep into it. You went a lot farther than I did! This is a pity, because it doesn't look like this use-case would be hard to support in Guix and I think it would be a killer feature for developers, allowing it to gain more popularity as a development tool. > Is this the correct way to set this up? Is there a simpler way? It is > such a common problem and my solution looks rather complicated. Are > there any insights and tips of people with similiar uses cases? I don't know the answer to these questions, but your solution is ingenious! -- Thiago
Re: Finding Dependencies at Run Time
Hello Peter,
Peter Polidoro writes:
>> Remember the difference between inputs and propagated inputs: they're
>> the same, but when you create a profile, inputs are not part of the
>> profile (so they need a direct store reference, such as RPATH or a
>> wrapper), whereas propagated inputs are part of the profile, so an
>> environment variable allows to find them.
>
> Thank you for patiently explaining, I think I am starting to
> understand now, but please correct me if I am still wrong.
I think there are still some misunderstandings, or perhaps at least to
me it's not clear what your question is. I think if you could provide a
concrete example of what you are trying to understand it would be
helpful.
> So there is package build-time, profile build-time, and run-time.
>
> Wrappers should be used to set environment variables when the value
> can be determined at package build-time, such as absolute paths to
> inputs.
No. Ideally wrappers shouldn't be necessary and wouldn't be used, but
for some software they are a necessary/useful workaround. At least
that's my understanding.
In the ideal situation, a Guix-package program uses absolute paths to
find the resources (libraries, scripts, other files) that it needs. For
example: how does a compiled program finds the library it was linked
with? It has the full path to glibc hard-coded into the ELF's library
runpath:
popigai: readelf --dynamic ~/.guix-profile/bin/htop | grep runpath
0x001d (RUNPATH)Library runpath:
[/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619/lib:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/../../..]
Or if it's a shell script, it has the full path to its interpreter:
popigai: head -n1 ~/.guix-profile/bin/vcsh
#!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh
Sometimes the original program doesn't use absolute paths, but we can
patch it so that it does. This is the case for example in public-inbox,
which invokes “xapian-compact” and expects it to be found in PATH, and
we change it to use the full path (this is in
guix/gnu/packages/mail.scm, line 4111 in the revision of Guix I'm
looking at):
--8<---cut here---start->8---
;; Use absolute paths for 'xapian-compact'.
(substitute* "lib/PublicInbox/Xapcmd.pm"
(("'xapian-compact'")
(format #f "'~a'" (search-input-file inputs
"/bin/xapian-compact"
--8<---cut here---end--->8---
But sometimes such changes aren't possible so in that case we do use
wrappers to configure environment variables that will cause the program
to find the resource. This also happens in public-inbox, which around
line 4160 has a ‘wrap-programs’ phase that creates a wrapper so that it
can find Perl modules and also the git and curl executables.
One thing that is implicit from the above is that at runtime, Guix
doesn't do anything to help a program find its dependencies. It has
already done its job at build time by hard-coding paths so that the
program can find them on its own or setting up a wrapper, and at profile
build-time, by setting up any relevant environment variables.
> Search paths should be used to set environment variables when the
> value will be determined at profile build-time, such as relative paths
> to either propagated-inputs or packages that also installed in the
> same profile, but not listed explicitly as propagated-inputs to the
> package declaring the search paths.
I'd say that search paths should be used when the set of resources that
a program will need can't be determined at build time. For example, the
Python interpreter can load a huge number of libraries. It doesn't make
sense to hard-code the absolute paths of all of them in the Python
interpreter. Rather, it should look for the ones that are installed in
the profile.
Another use case is when a program's dependency is optional and it can
work well enough without the dependency being available. That way, the
user can install the dependencies they want and the program will use
them.
> I am still a little unclear about the difference between search-paths
> and native-search-paths, though. If not cross-compiling then they act
> the same?
Yes, that's correct.
> If you are cross-compiling, though, then it only finds packages that
> are listed as native-inputs to the package declaring the search paths?
I don't know about cross-compilation profiles, but hopefully it's
similar to the build environment set up by Guix when cross-compiling a
package. Because of that, I'll answer some of your questions in this
section of the email but not all of them.
When Guix cross-compiles a package, native inputs are the ones that will
be used during the process of building the package (and no
Re: /gnu/store
Hello, Giovanni Biscuolo writes: >> To look for a the Emacs 28.1 file takes also ages. > > What is "the Emacs 28.1 file"? I assume they mean the Emacs executable. You can look for the Emacs executable currently present in your Guix profile by looking into the ~/.guix-profile/bin directory. It's small enough that you can explore it with a file manager, unlike /gnu/store. It's also simple to check from a terminal, for example with the command “ls -l ~/.guix-profile/bin/emacs”. >> I want to change the command for opening emacs in the starter,now >> version 27.2 change into emacs 28. So that the emacs icon in the toolbar >> opens Emacs 28. Or is the simplest way deleting the icon and after every >> new emacs version creating a new icon? > > You cannot change the .desktop files used to start applications > installed via Guix since they are stored read-only in the store It's possible to override the system-installed .desktop files by creating new ones in ~/.local/share/applications. This can be done more easily with a menu editor such as ‘kmenuedit’ in KDE. I don't know what the Mate equivalent would be. A quick web search suggests there are both ‘Alacarte’ and ‘Mozo’ but it looks like neither of them are packaged in Guix unfortunately. > It's "just" a matter to refresh your graphical menu an usually we need > to logout and login (at least on a foreign distro) > >> 3. Can somebody explain to me the structure of /gnu/store? > > Please read the Guix manual at "8.9 The Store" > > AFAIK the store is set read-only **but** in any case /do not/ directly > write to the store, it is accessed by the guix-daemon via the various > "guix..." command > > use the guix cli (or the great emacs-guix interface [1]) to explore your > packages (et al) > > [...] Reading the manual section about the store as Giovanni suggested is of course the best way to learn about the /gnu/store organization, but a quick explanation about the weird directory and file names there is that the soup of numbers and letters at the beginning is a random but deterministic identifier of that particular file or package, and is based on the source code of the package and the environment needed to build it. If you change anything at all about the file/package or how it is produced, then the identifier changes as well. This helps Guix provide its reproducibility properties. -- Thanks Thiago
Re: was I hacked?
Edouard Klein writes: > Hi, > > I diffed the git log of both https://git.sr.ht/~whereiseveryone/pjmkglp > and guix official repo and could not find any difference (apart from the > most recent commits on the official repo of course). I also confirmed, > as had already been said, that commit 950f3e4f98 is indeed a descendant > of 42679e3f81, so the error message makes no sense :/ Someone mentioned inspecting the reflog. IIUC (and maybe I don't UC) the reflog is a local property to a git repo and can't be pushed/pulled. Therefore, one additional piece of evidence would be if jgart could go to ~/.cache/guix/checkouts// and post the output of the commands ‘git reflog origin/master’ and ‘git reflog master’. -- Thanks Thiago
Re: Problem with uilding a package for intel onepi fortran compiler.
Hello Céline, Céline Acary-Robert writes: > We are trying to build a package for intel onepi fortran compiler. The > sources are installed through a script "install" (/bin/sh) which calls > a binary bootstrapper which allows to download the files and install > them I don’t know about the “no such file or directory” error that you are seeing, but I can tell that if you’re able to fix it, then you’ll run into the problem that the binary bootstrapper won’t be able to download the files. Guix’s build environment doesn’t allow access to the network. A package needs to be able to be built with the declared inputs and native-inputs and nothing more. This is required for security, integrity and build reproducibility of the resulting package. Is it possible to download the files in advance and provide them as inputs to the package? > starting phase `install' > ./install.sh: line 34: What's in line 34 of install.sh? > /tmp/guix-build-intel_oneapi-2022.0.1.70.drv-0/l_fortran-compiler_p_2022.0.1.70_offline/bootstrapper: > No such file or directory If you run guix build with the “--keep-failed” argument, do you see a “bootstraper” file in the directory above? If so, and if it is an ELF binary, does running ‘ldd’ on it show that it has all the libraries that it needs? -- Thanks Thiago
Re: was I hacked?
Hello, jgart writes: > Hi Guixers, > > Sorry for the clickbait title. > > I got this error just now from the main guix channel: > > > ``` > λ guix pull > Updating channel 'guixrus' from Git repository at > 'https://git.sr.ht/~whereiseveryone/guixrus'... > Updating channel 'nonguix' from Git repository at > 'https://gitlab.com/nonguix/nonguix'... > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... > guix pull: error: aborting update of channel 'guix' to commit > 950f3e4f98add14f645dc4c9f8c512cac7b8a779, which is not a descendant of > 42679e3f81a0fa61e225b1f6aa0e80e39625372f > hint: This could indicate that the channel has been tampered with and is > trying to force a > roll-back, preventing you from getting the latest > updates. If you think this is not the case, explicitly allow non-forward > updates. > ``` > > wdyt? I don't understand why Guix thinks that. IIUC 950f3e… is a direct descendant of 42679e… -- Thanks Thiago
Re: Latam keyboard layout changed, how can I get the old one back?
Hello, "pelzflorian (Florian Pelz)" writes: > On Thu, Apr 07, 2022 at 04:55:11PM +, Luis Felipe wrote: >> I found a bug report upstream that may be related to this: >> https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/267 >> . > > I guess there’s no way around `info "(guix) Using a Custom Guix > Channel"` with (url "/home/luis/src/guix") and reverting bcfff754. I think you could also use an inferior to install xkeyboard-config from an older Guix revision: https://guix.gnu.org/de/manual/devel/en/html_node/Inferiors.html I don’t use Guix System though so unfortunately I can’t give more specific instructions. Nor be sure that this can really be done, to be honest. -- Thanks Thiago
Re: Is mkdir-p a directory outside of /gnu/store.... possible?
Hello James, James Smith via writes: > I guix package --install-from-file-myapp.scm and during the install process I > would like to > > (mkdir-p "$HOME/.config/myapp") and then > (system* (cp "/gnu/store/.../myapp/config.txt" "$HOME/.config/myapp")) Setting up a package’s configuration files in “$HOME/.config” is one of the main purposes of Guix Home, so I suggest investigate creating a new Guix Home service for your package. -- Thanks Thiago
Re: No sound on laptop after linux-libre 5.15
Hello Paxton, Paxton Evans writes: > On 2021-12-08 23:05, Leo Famulari wrote: >> On Wed, Dec 08, 2021 at 11:34:24PM -0300, Thiago Jung Bauermann wrote: >>> Em quarta-feira, 8 de dezembro de 2021, às 01:55:13 -03, Paxton Evans >>> escreveu: >>> > Rolling back to linux-libre 5.14.21 (guix >>> > ea7233befb9570cce47e5ca71725b285a580cd22) totally fixes this issue. >>> > >>> > Troubleshooting sound issues on GNU/Linux is such a nightmare that I'm >>> > hoping this list can help me, as I don't really know much about how >>> > sound on our favorite OS really works, and don't have enough information >>> > to file a bug. Can anyone give me pointers on where to start looking? >>> > dmesg on 5.15.6 didn't seem to report anything strange. >> >> Thanks for your report. Everything Thiago said is important, and it >> would also help if you told us what you had tried to do. That is, what >> are you using to make sound? >> >> My basic sound test is to use mpg123 to play an MP3 file. You can use >> the --output option to choose which output to play through, to be sure. >> And you can use --list-modules to see what's available. >> >> On Guix System, we aim to make applications use Pulseaudio by default, >> so you can use `mpg123 --output pulse file.mp3` to test that. You can >> also use `mpg123 --output alsa file.mp3` if you'd rather test ALSA. >> >> Unfortunately I currently cannot test sound on Guix System with >> linux-libre. However, it does work for me on a computer using Guix >> System with a custom kernel. > > In case anyone finds this later, I wanted to update and say that this > was indeed a kernel bug, and fixed in Linux commit > 7f6e3cbbd60044102373f5a7f86d5f4e89a99747 (included in 5.15.17 in both > vanilla and linux-libre). Thank you for the update! It’s always nice to avoid https://xkcd.com/979/ -- Thanks Thiago
Re: Initialization of environment variables for guix on foreign distro
Hello David, David Lecompte writes: > On Trisquel with mate on my laptop, when opening a mate terminal (the > command is just "mate-terminal", no option), all the suitable > environment variables for guix are set. > > On Debian with mate on my desktop (I had problems with Trisquel that I > could not solve for one year so I am using Debian), when opening a mate > terminal, the suitable variables for guix are not set. I had a similar issue recently on my Ubuntu laptop, when I switched the display manager from SDDM to GDM. From what I gather, the latter launches the desktop session without using a shell so at no point the shell initialization files are evaluated and thus the environment isn’t set up as usual. I use KDE Plasma, and it has a mechanism to evaluate shell scripts to set the environment, so in my case to fix the problem what I had to do was: $ ln -s /etc/profile ~/.config/plasma-workspace/env/profile.sh I searched a bit, but unfortunately I couldn’t find an equivalent solution for MATE. I suppose one alternative would be to switch from GDM to SDDM. :-) > Does guix configure another file to set environment variables properly > or is /etc/profile.d/guix.sh the only one? Is it supposed to be > sufficient to source it via /etc/profile? Yes, that should be enough. > If sourcing /etc/profile is supposed to address all cases, what is the > recommended way to have it sourced? (on the laptop, I searched all .* > files in my home directory, none of them is sourcing /etc/profile). > That last question is not guix-specific but any advice is still > welcome. bash automatically reads /etc/profile when invoked as a login shell. There are more details here: https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html -- Thanks, Thiago
Re: No sound on laptop after linux-libre 5.15
Hello Paxton, Em quarta-feira, 8 de dezembro de 2021, às 01:55:13 -03, Paxton Evans escreveu: > Rolling back to linux-libre 5.14.21 (guix > ea7233befb9570cce47e5ca71725b285a580cd22) totally fixes this issue. > > Troubleshooting sound issues on GNU/Linux is such a nightmare that I'm > hoping this list can help me, as I don't really know much about how > sound on our favorite OS really works, and don't have enough information > to file a bug. Can anyone give me pointers on where to start looking? > dmesg on 5.15.6 didn't seem to report anything strange. I’m not particularly familiar with the moving parts that make sound work either, so I’ll focus on the kernel side of things. My first idea would be trying to boot with the “debug” kernel command line option, which increases the verbosity of kernel messages. Perhaps something helpful will show up in dmesg that way? If not, and if the only change in the working setup vs the non-working setup is the kernel version, then it’s a regression in the kernel. If you are willing to run the upstream Linux kernel on your machine (i.e., the non-libre kernel), the first step would be to run Linux v5.15.6 and see if sound works. If it does, then it’s a bug in linux-libre itself and you should report the problem to them. If it doesn’t, it’s a bug in Linux itself and the most straightforward (but tedious and time-intensive) way to find the kernel commit that caused the bug is to use “git bisect”: https://wiki.gentoo.org/wiki/Kernel_git-bisect That is, assuming that you are comfortable building kernels. You need to use v5.14 as your known-good version not v5.14.21 because your range should be a “straight line” in the version history, and v5.14.x versions branch off from mainline and thus aren’t ancestors of v5.15.x. Also, since you’d be running random kernel commits, it’s important to be aware that there’s a small but non-zero risk of running a bad kernel version which could corrupt something on your system. E.g., not long ago during the v5.12 development cycle there was a filesystem corruption bug: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.12-Corruption-Fixed You wouldn’t be at risk of hitting that particular bug since your range starts at v5.14, but it’s not inconceivable that there could be something bad in your range (though I’m not aware of anything). The safest way to address that is to run the bisect kernels in a temporary Linux installation on your machine, such as in a USB flash drive rather than on your main Linux installation. -- Thanks, Thiago
Re: Running Out of Inodes
Hello Jonathan, Em domingo, 14 de novembro de 2021, às 15:47:54 -03, Jaft via escreveu: > Out of curiosity, I read that Btrfs requires periodic > fragmentation; how often do you find yourself doing it and do you use > any particular program for it (if you don't mind sharing, of course; I > know it's not directly Guix related)? I use btrfs for several years now — not with Guix System, though I do have Guix installed on top of Ubuntu on btrfs so I do have /gnu/store on btrfs. My experience is that it is zero-maintenance, at least on a personal laptop workload. Btrfs has matured a lot over the years, so there’s a fair amount of outdated advice still floating around on the Internet. You’re probably thinking of the ‘btrfs balance’ command. In the past, it was useful to run it every once in a while to avoid spurious ENOSPC errors. This problem has since been fixed, and current advice is that regular use of “btrfs balance” is now considered detrimental rather than beneficial since it puts more load/stress on the disk without any practical benefit. -- Thanks, Thiago
Re: Librem Mini with pureboot/head don't boot GuixSD
Hello Roland, Em quinta-feira, 19 de agosto de 2021, às 11:57:45 -03, Roland Everaert escreveu: > I manage to successfuly copy the needed files to /boot using the `for > each` loop from ‘%copy-kernel-and-initrd’, Thank You. That’s great! > However, I need to resize (i.e. reduce) the root filesystem so /boot can > live in its own one. Currently, copying the kernel files too /boot is > useless, as HEAD will scan and sign all the files in /, anyway. > > Did you have any article discussing such process? > > I find plenty of articles about increasing the root partition, but, none > to reduce it. > > As the root partition cannot be unmounted online, I need to know if there > is a simple way to "switch to an offline mode of sort". For example, I > could map a minimal root FS in memory and chroot to it. An other > possibility is to copy a guix system to a USB drive and boot from it. > > The USB option seems the easiest, but the one with the RAMFS seems neat. > > What are the recommandations of the fine folks on this ML, for such > operation? I don’t have any resource about how to shrink a partition and its filesystem. I would boot into some distro’s live image and do it from there. Shrinking a partition is dangerous and error-prone because there are two steps: 1. Shrink the filesystem 2. Shrink the partition If you get the size calculation wrong in step 2 you’ll end up cutting off the end of your filesystem and thus corrupt it. So I believe the recommended practice is to always shrink the partition to be slightly bigger than the filesystem to make sure you don’t take that risk. You can then optionally grow back the filesystem to fill the slack space (filesystem resizing tools can automatically calculate the correct size to fill the partition). Since this is a risky operation, you have to make sure you have backups of everything. And since you need to do that, to be honest what I would *really* do is wipe everything out, repartition the disk to the new layout and then restore from backups... -- Thanks, Thiago
Re: help with use of %current-target-system parameter and gexps
Hello Mathieu,
Em domingo, 15 de agosto de 2021, às 03:02:42 -03, Mathieu Othacehe
escreveu:
> > +;; LuaJIT is not ported to powerpc64le* yet.
> > +(if (string-prefix? "powerpc64le"
> > +(or (%current-target-system)
> > +(%current-system)))
> > +(substitute* fmtutilcnf
> > + (((string-append
> > "^(luajittex|luajithbtex|mfluajit)") m) +
> > (string-append "#! " m
> >
> > ;; Register SHARE as TEXMFROOT in texmf.cnf.
> > (substitute* texmfcnf
> >
> >(("TEXMFROOT = \\$SELFAUTOPARENT")
>
> The issue here is that the %current-target-system and %current-system
> are not defined at build time. You need to force their evaluation by
> using "unquote", this way:
Ah! I wasn’t aware of that trick. It indeed solved the problem. Thank you
very much for your help!
> --8<---cut here---start->8---
> (arguments
> `(#:phases
‘texlive-texmf’ already has this quasiquote, so I only needed the unquote
below to make it work.
>...
>(if (string-prefix? "powerpc64le"
> ,(or (%current-target-system)
>(%current-system)))
> ...)))
> --8<---cut here---end--->8---
>
> > +#~(let-system (system target)
> > +;; LuaJIT is not ported to powerpc64le* yet.
>
> Here also you need to unquote this part, using "ungexp":
>
> --8<---cut here---start->8---
>#$(let-system (system target)
> ...
> --8<---cut here---end--->8---
Not that it matters anymore, but just for completeness: unfortunately
I couldn’t make this one work. When I used “ungexp”, I got this error:
--8<---cut here---start->8---
[ 79%] GUILEC gnu/packages/tex.go
gnu/packages/tex.scm:6832:24: warning: possibly unbound variable `substitute*'
gnu/packages/tex.scm:6832:24: warning: possibly unbound variable `fmtutilcnf'
gnu/packages/tex.scm:6833:27: warning: possibly unbound variable `m'
Compiling Scheme modules...
Compiling Scheme modules...
make[2]: Saindo do diretório '/home/debian/src/guix'
make[1]: Saindo do diretório '/home/debian/src/guix'
gnu/packages/tex.scm:6832:24: error: substitute*: unbound variable
hint: Did you forget `(use-modules (guix build utils))'?
--8<---cut here---end--->8---
I tried using this at the beginning of the gexp:
--8<---cut here---start->8---
(with-imported-modules '((guix build utils))
#~(begin
(use-modules ((guix build utils)))
⋮
--8<---cut here---end--->8---
But it still resulted in the same error. But no problem, your “unquote”
solution worked.
--
Thanks,
Thiago
Re: Librem Mini with pureboot/head don't boot GuixSD
Hello, Em sábado, 14 de agosto de 2021, às 08:23:17 -03, Roland Everaert via escreveu: > The good news, I manage to boot the system. Nice! > I can apply your suggested workaround, but I will need some help to > understand how to adapt /etc/config.scm to copy the kernel to /boot, if > it is possible, from the configuration file. You could use ‘%copy-kernel-and-initrd’ from here as a basis: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/ berlin.scm#n97 If you change “/store” to “/boot” in the code perhaps it will work in your case. -- Thanks, Thiago
help with use of %current-target-system parameter and gexps
Hello Guix,
I would like to ask for help with a couple of issues that I ran into while
trying to fix a build failure in ‘texlive-texmf’ in the core-updates-frozen
branch on powerpc64le-linux:
fmtutil [ERROR]: not building luajittex due to missing engine: luajittex
fmtutil [ERROR]: not building luajithbtex due to missing engine: luajithbtex
The problem is straightforward: LuaJIT isn’t supported on powerpc64le.
‘texlive-latex-base’ disables these engines accordingly:
;; LuaJIT is not ported to powerpc64le* yet.
,@(if (string-prefix? "powerpc64le"
(or (%current-target-system)
(%current-system)))
'("luajittex" "luajithbtex" "mfluajit") '())
So all I have to do is disable these “*luajit*” engines in ‘texlive-texmf’
as well. Unfortunately copying the same ‘if’ expression like so:
--8<---cut here---start->8---
diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index 70166941d554..8fc420039417 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -6821,9 +6821,17 @@ directly generate PDF documents instead of DVI.")
(share (string-append out "/share"))
(texmfroot (string-append share "/texmf-dist/web2c"))
(texmfcnf (string-append texmfroot "/texmf.cnf"))
+ (fmtutilcnf (string-append texmfroot "/fmtutil.cnf"))
(texlive-bin (assoc-ref inputs "texlive-bin"))
(texbin (string-append texlive-bin "/bin"))
(tlpkg (string-append texlive-bin "/share/tlpkg")))
+;; LuaJIT is not ported to powerpc64le* yet.
+(if (string-prefix? "powerpc64le"
+(or (%current-target-system)
+(%current-system)))
+(substitute* fmtutilcnf
+ (((string-append "^(luajittex|luajithbtex|mfluajit)") m)
+ (string-append "#! " m
;; Register SHARE as TEXMFROOT in texmf.cnf.
(substitute* texmfcnf
(("TEXMFROOT = \\$SELFAUTOPARENT")
--8<---cut here---end--->8---
Results in an error:
--8<---cut here---start->8---
starting phase `texmf-config'
error: in phase 'texmf-config': uncaught exception:
unbound-variable #f "Unbound variable: ~S" (%current-target-system) #f
phase `texmf-config' failed after 0.0 seconds
Backtrace:
14 (primitive-load "/gnu/store/49q7az0dglza46v2cz06iajc568?")
In guix/build/gnu-build-system.scm:
904:2 13 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 11 (for-each # ?)
In ice-9/boot-9.scm:
1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
925:23 9 (_)
In ice-9/eval.scm:
619:8 8 (_ #(#(#(#(#(#(#(#(#(#) ?) ?) ?) ?) ?) ?) ?) ?))
245:16 7 (_ #(#(#(#(#(#(#(#(#(#) ?) ?) ?) ?) ?) ?) ?) ?))
159:9 6 (_ #(#(#(#(#(#(#(#(#(#) ?) ?) ?) ?) ?) ?) ?) ?))
293:34 5 (_ #(#(#(#(#(#(#(#(#(#) ?) ?) ?) ?) ?) ?) ?) ?))
182:19 4 (proc #(#(#(#(#(#(#(#(#(#) ?) ?) ?) ?) ?) ?) ?) ?))
142:16 3 (compile-top-call # # #)
In unknown file:
2 (%resolve-variable (7 . %current-target-system) #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: %current-target-system
--8<---cut here---end--->8---
So this is my first question: why does that ‘if’ condition work in
‘texlive-latex-base’ but not in ‘texlive-texmf’? I can’t see a significant
difference between the two.
In any case, I thought I could solve this by using a gexp. I tried several
different variations, but none worked. I think this was my best shot:
--8<---cut here---start->8---
diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index 70166941d554..1df5dbbd5f9e 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -51,6 +51,7 @@
#:use-module (guix deprecation)
#:use-module (guix git-download)
#:use-module (guix svn-download)
+ #:use-module (guix gexp)
#:use-module (gnu packages)
#:use-module (gnu packages algebra)
#:use-module (gnu packages autotools)
@@ -6794,7 +6795,7 @@ directly generate PDF documents instead of DVI.")
("ruby" ,ruby)
("tcsh" ,tcsh)))
(arguments
-`(#:modules ((guix build gnu-build-system)
+(list #:modules '((guix build gnu-build-system)
(guix build utils)
(srfi srfi-26))
@@ -6803,7 +6804,7 @@ directly generate PDF documents instead of DVI.")
#:substitutable? #f
#:phases
-(modify
Re: Guix Hang Out Attempt 2 and an Unoffical Guix Hackathon/config party
Hello, Em terça-feira, 27 de julho de 2021, às 17:54:16 -03, Joshua Branson escreveu: > Joshua Branson writes: > > Akib Azmain Turja writes: > >> Vagrant Cascadian writes: > >> > >> > >> The idea of using UNIX epoch is good. But the command showed that > >> it's > >> Wed, 28 Jul 2021 01:00:00 +0600 for me, so I can't attend. Can you > >> change the time? And, is that instance of Jitsi Meet free (libre)? > > > > I believe it is...it's the official jitsi instance. > > > > We could always meet at the official FSF jitsi instance, though I'm not > > certain if they intend their instance to be a hang out instance... > > The hangout today was awesome! It was! > I and other mysterious and extremely talented C developer discovered the > wonder of power9! > > guix environment -s powerpc64le-linux coreutils --ad-hoc coreutils gdb > > is a cool command that lets you create a guix binary that runs of > powerpc. You can then use said guix binary in qemu! Though it might > work faster if you had a power9 machine. Thank you for the “extremely talented”. Not sure about that one. :-) That is the command I’m using to investigate a test suite failure in the ‘coreutils-final’ package reported by CI¹. It will bring in the coreutils build inputs as well as GDB. If you want a minimal environment you can use this smaller alternative: $ guix environment -s powerpc64le-linux --ad-hoc coreutils It assumes that you have binfmt configured to launch the QEMU user emulator. This happens automagically on Ubuntu (and I assume on Debian as well) if you install the ‘qemu-user-static’ package. It also works for other systems such as armhf-linux and aarch64-linux. > This talented and mysterious developer also mentioned that IBM does > provide power9 VMs that you can request access to, which would make the > debbugging process a little smoothier. Indeed! IBM provides free access to powerpc64le VMs for people doing open source development: https://openpower.ic.unicamp.br/minicloud/ I just noticed that there’s a Guix logo on that page, so I guess this isn’t news for you. :-) > I talked about my current email server and other things. That was very informative. Thank you! > Hopefully we will see more people next week! And thanks again for organizing the hang out! It’s a great idea. -- Thanks, Thiago ¹ https://ci.guix.gnu.org/build/692547/details
Re: Build Mesa with a different toolchain version
Em quarta-feira, 2 de junho de 2021, às 08:13:17 -03, Tobias Geerinckx-Rice
escreveu:
> Two notes after a calming walk in the woods:
Always a good idea!
> Tobias Geerinckx-Rice 写道：
>
> > no package has a ‘gcc-toolchain’ input.
>
> Not true: 2 do. I meant that ‘the toolchain’ used to build
> everything…
>
> > It is not used internally by Guix.
>
> …is not the "gcc-toolchain" package as such.
Thanks for the clarification.
> > (package (inherit gcc->gcc-10 mesa) …)
>
> Just turn it around:
>
> (define-public mesa/gcc-10
> (package
> (inherit mesa)
> (native-inputs
> `(("gcc" ,gcc-10)
> ,@(package-native-inputs mesa)
This worked (except for the mixed-toolchains issue):
(define-public mesa-10
(package
(inherit (package-with-c-toolchain mesa
`(("toolchain" ,gcc-toolchain-10
(name "mesa-10")))
--
Thanks,
Thiago
Re: Build Mesa with a different toolchain version
Hello, Thank you for your response. Em quarta-feira, 2 de junho de 2021, às 06:42:41 -03, Tobias Geerinckx-Rice escreveu: > Thiago, > > Thiago Jung Bauermann 写道： > > > $ guix build --system=i686-linux \ > > > > --with-input=gcc-toolchain=gcc-toolchain@10.3.0 mesa > > > > […] > > successfully built > > /gnu/store/bg01dw0178yb7v9xr4zmq5f05200f2ql-mesa-20.2.4.drv > > /gnu/store/mvy7pl73yqrd9pi3k3xq14i6dmnfbl8s-mesa-20.2.4-bin > > /gnu/store/ii8fbly1s19qwpnwv002fd2pxk2h96ba-mesa-20.2.4 > > --with-input=gcc-toolchain=… is a no-op: no package has a > ‘gcc-toolchain’ input. > > It exists only because people kept installing the ‘unwrapped’ (now > hidden) GCC package with ‘guix install gcc’ and expecting a > working compiler. gcc-toolchain wraps the entire toolchain so ‘$ > gcc my.c’ produces working binaries. It is not used internally by > Guix. Ah! Thanks for the information. I didn’t have a clear picture of the relationship between ‘gcc’ and ‘gcc-toolchain’. > > So aparently it worked. > > It worked in the sense that the package was built successfully > with gcc@7.5. If your undescribed issue was a build issue, it's > not deterministic. If it's a run-time bug, whatever it is will > still happen. Right, it still happens. It’s a runtime issue. “worked” here referred to triggering a package rebuild and having it completing successfuly. > > And surprisingly, when changing the requested gcc-toolchain > > version, > > guix doesn't attempt to build anything and just returns the same > > > store items from the “10.3.0” build: > It's not surprising, it's proof that your transformation's a > no-op. Guix is very good at hashing changes; it doesn't ‘miss’ or > cache stale things. Nice. It’s good to understand that piece of the puzzle. > Two things that work (but read both): > > ~$ guix build --with-input=gcc=gcc@10 mesa > guix build: package 'gcc' has been superseded by 'gcc-toolchain' > > Is this why you tried =gcc-toolchain= above? :-) The hint isn't > relevant in this edge case, you can ignore it for once. I didn’t even try this command actually. I had noticed that I couldn’t manipulate the ‘gcc’ package from the command line, so I assumed that passing it to `--with-input` wouldn’t work. I thought it was only possible to reference it in Scheme code, via the ‘gcc’ variable. > I've included this option because it's the workin variant of your > first command. However, it rebuilds the *entire* dependency chain > of Mesa with GCC 10: glibc, bash, ed, python-minimal, guile… > > It's cool that Guix makes this task so easy, It’s very cool indeed! Unfortunately, here it’s failing early in the rebuild process, while trying to build ‘bash-minimal’: ``` configure: WARNING: unrecognized options: --enable-fast-install checking build system type... i686-unknown-linux-gnu checking host system type... i686-unknown-linux-gnu Beginning configuration for bash-5.0-release for i686-unknown-linux-gnu checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/tmp/guix-build-bash-minimal-5.0.16.drv-0/bash-5.0': configure: error: C compiler cannot create executables See `config.log' for more details ``` > but you probably want just > > ~$ guix build --with-c-toolchain=mesa=gcc-toolchain@10 mesa > > This special-case option will do the right things to rebuild > (only) mesa with the toolchain of your choice. Note the =mesa= > difference in syntax: the package you want to rebuild, not the one > you want to replace: > > […] > C compiler for the host machine: gcc (gcc 10.3.0 "gcc (GCC) > 10.3.0") > C linker for the host machine: gcc ld.bfd 2.34 > C++ compiler for the host machine: c++ (gcc 10.3.0 "c++ (GCC) > 10.3.0") > C++ linker for the host machine: c++ ld.bfd 2.34 > […] Yes, that is indeed what I was looking for. Unfortunately, as I mentioned in my other email, with this option Mesa builds some libraries with GCC 10.3.0 and others with 7.5.0. There must be something strange going on with its build system. > Not a user of PACKAGE-INPUT-REWRITING so I'll leave that to > someone else. I was able to use ‘package-with-c-toolchain’, though I get the same mixed- toolchains result. As I mentioned in the other email, I’m beginning to wonder if my time would be better spend trying to help getting core-updates ready. Then I’d get gcc-8 by default. -- Thanks, Thiago
Re: Build Mesa with a different toolchain version
Hi, Thank you for your response. Em quarta-feira, 2 de junho de 2021, às 06:22:48 -03, Efraim Flashner escreveu: > On Tue, Jun 01, 2021 at 09:46:56PM -0300, Thiago Jung Bauermann wrote: > > Hello, > > > > I'm having and issue with Mesa on i686-linux which I suspect is caused > > by the version of GCC used to build it (i.e. 7.5.0). > > > > To test my theory, I'm trying to build Mesa with a newer version of the > > compiler. I tried a few different things, but none worked. I would be > > grateful if someone could help me figure out how to do this: > > > > Try #1: > > > > $ guix build --system=i686-linux \ > > > > --with-input=gcc-toolchain=gcc-toolchain@10.3.0 mesa > > I believe you have the wrong command here. What you want is > $ guix build --system=i686-linux \ > --with-c-toolchain=mesa=gcc-toolchain@10 mesa Thanks, that worked! I read most of the Guix manual, but I had forgotten about the `--with-c-toolchain` option. Searching for it in the manual also made me find the `package-with-c-toolchain` function, which does the same thing from Scheme code. Though there’s something weird about Mesa’s build process. Different libraries end up linked to different GCC versions. :-/ $ guix build --system=i686-linux --with-c-toolchain=mesa=gcc-toolchain@10 mesa […] successfully built /gnu/store/59mczv3gwq3bnnw2jqcj8vqimihqi6c1-mesa-20.2.4.drv /gnu/store/8zlcwhd10nj2kv56ip5cgf5rg7523yvm-mesa-20.2.4-bin /gnu/store/5w54z00fldvgdknn06xp66irqslhp6ff-mesa-20.2.4 $ ldd /gnu/store/5w54z00fldvgdknn06xp66irqslhp6ff-mesa-20.2.4/lib/libOSMesa.so.8.0.0 G gcc libstdc++.so.6 => /gnu/store/92p8kxb6a5xpdi6srb8cj71fggqpkmjk-gcc-10.3.0-lib/lib/libstdc++.so.6 (0xf52e7000) libgcc_s.so.1 => /gnu/store/92p8kxb6a5xpdi6srb8cj71fggqpkmjk-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0xf51c6000) $ ldd /gnu/store/5w54z00fldvgdknn06xp66irqslhp6ff-mesa-20.2.4/lib/libGL.so.1.2.0 G gcc libgcc_s.so.1 => /gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib/lib/libgcc_s.so.1 (0xf78ed000) Also the 32-bit game I’m trying to run somehow gets linked to different Mesa builds too: libGL.so.1 => /gnu/store/27yzdsj09mm3ijj4zhikcgjjqjlr74yc-mesa-20.2.4/lib/libGL.so.1 (0xf71a9000) libgbm.so.1 => /gnu/store/6k4wj4472nbws2z4fqy1qmnp07say5x7-mesa-20.2.4/lib/libgbm.so.1 (0xf66c5000) libglapi.so.0 => /gnu/store/27yzdsj09mm3ijj4zhikcgjjqjlr74yc-mesa-20.2.4/lib/libglapi.so.0 (0xf6621000) The 27yz… build is the GCC 10.3.0 one, and 6k4wj… is the GCC 7.5.0 one. Perhaps my time would be better spent trying to help get ‘core-updates’ in shape rather than trying to work around a 4 years old compiler bug¹. -- Thanks, Thiago ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866354 – the bug is in armel, but I’m getting the exact same error message in Mesa, so I suspect it also affects i686.
Re: Build Mesa with a different toolchain version
After sending the email, I thought of another thing to try, but it didn't help. I thought I'd mention it here for completeness: Try #3: Using this definition in my local channel: ``` (define gcc->gcc-10 (package-input-rewriting `((,gcc-7 . ,gcc-10) (,(make-libstdc++ gcc-7) . ,(make-libstdc++ gcc-10) (define-public mesa-10 (package (inherit (gcc->gcc-10 mesa)) (name "mesa-10"))) ``` i.e., the only change relative to the previous try was to look for ‘gcc-7’ rather than ‘gcc’ to make the substitution. But unfortunately guix build didn't even try to rebuild the package. It just returned the store items that were built in try #2: $ guix build --system=i686-linux mesa-10 /gnu/store/8iiwn9cnjlfxfi7m1fmdavzgr7y38vv7-mesa-10-20.2.4-bin /gnu/store/hjci6cqw76hvdawdl04kjmbajklsdwx2-mesa-10-20.2.4 I believe this shows that ‘gcc’ already points to ‘gcc-7’. I just can't change it for some reason… -- Thanks, Thiago
Build Mesa with a different toolchain version
Hello, I'm having and issue with Mesa on i686-linux which I suspect is caused by the version of GCC used to build it (i.e. 7.5.0). To test my theory, I'm trying to build Mesa with a newer version of the compiler. I tried a few different things, but none worked. I would be grateful if someone could help me figure out how to do this: Try #1: $ guix build --system=i686-linux \ --with-input=gcc-toolchain=gcc-toolchain@10.3.0 mesa […] successfully built /gnu/store/bg01dw0178yb7v9xr4zmq5f05200f2ql-mesa-20.2.4.drv /gnu/store/mvy7pl73yqrd9pi3k3xq14i6dmnfbl8s-mesa-20.2.4-bin /gnu/store/ii8fbly1s19qwpnwv002fd2pxk2h96ba-mesa-20.2.4 So aparently it worked. But when checking the libraries, they still link to GCC 7.5.0. $ ldd /gnu/store/ii8fbly1s19qwpnwv002fd2pxk2h96ba-mesa-20.2.4/lib/libOSMesa.so.8.0.0 | grep gcc libstdc++.so.6 => /gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib/lib/libstdc++.so.6 (0xf51d9000) libgcc_s.so.1 => /gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib/lib/libgcc_s.so.1 (0xf50b9000) And surprisingly, when changing the requested gcc-toolchain version, guix doesn't attempt to build anything and just returns the same store items from the “10.3.0” build: $ guix build --system=i686-linux --with-input=gcc-toolchain=gcc-toolchain@11.1.0 mesa /gnu/store/mvy7pl73yqrd9pi3k3xq14i6dmnfbl8s-mesa-20.2.4-bin /gnu/store/ii8fbly1s19qwpnwv002fd2pxk2h96ba-mesa-20.2.4 Try #2: Next, I tried using ‘package-input-rewriting’ by putting the following package definition in a channel I created locally (with the appropriate ‘#:use-module’ directives at the top): ``` (define gcc->gcc-10 (package-input-rewriting `((,gcc . ,gcc-10) (,(make-libstdc++ gcc) . ,(make-libstdc++ gcc-10) (define-public mesa-10 (package (inherit (gcc->gcc-10 mesa)) (name "mesa-10"))) ``` And then: $ guix pull && guix build --system=i686-linux mesa-10 […] successfully built /gnu/store/g4j9kmxgp6lashyipcydn7i6vh2v4s3c-mesa-10-20.2.4.drv /gnu/store/8iiwn9cnjlfxfi7m1fmdavzgr7y38vv7-mesa-10-20.2.4-bin /gnu/store/hjci6cqw76hvdawdl04kjmbajklsdwx2-mesa-10-20.2.4 And unfortunately I saw many GCC 7.5.0 processes in the build, for example (command line abridged because it's too big): $ pgrep -u guixbuilder01 -a -f cc1 119240 /gnu/store/…-gcc-7.5.0/libexec/gcc/i686-unknown-linux-gnu/7.5.0/cc1 […] And indeed, still linked to GCC 7.5.0 libraries: $ ldd /gnu/store/hjci6cqw76hvdawdl04kjmbajklsdwx2-mesa-10-20.2.4/lib/libOSMesa.so.8.0.0 | grep gcc libstdc++.so.6 => /gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib/lib/libstdc++.so.6 (0xf51ff000) libgcc_s.so.1 => /gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib/lib/libgcc_s.so.1 (0xf50df000) Also tried using GCC 11 by doing `s/-10/-11/g` in the code I quoted above and building again: $ guix build --system=i686-linux mesa-11 […] successfully built /gnu/store/vnmwibfpsw3fkm7q7y6z4r5273ri4qra-mesa-11-20.2.4.drv /gnu/store/w5l307c1vnsik5h1zd9bcjzld2yp6xyl-mesa-11-20.2.4-bin /gnu/store/l98bxwa5psb3yx56hhb78zr043s10p7q-mesa-11-20.2.4 At least this time it redoes the build instead of just returning the same store items, but I still see the GCC 7.5.0 processes during the build: $ pgrep -u guixbuilder01 -a -f cc1 127514 /gnu/store/…-gcc-7.5.0/libexec/gcc/i686-unknown-linux-gnu/7.5.0/cc1 […] And again, linked with GCC 7.5.0 libraries: $ ldd /gnu/store/l98bxwa5psb3yx56hhb78zr043s10p7q-mesa-11-20.2.4/lib/libOSMesa.so.8.0.0 | grep gcc libstdc++.so.6 => /gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib/lib/libstdc++.so.6 (0xf51e4000) libgcc_s.so.1 => /gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib/lib/libgcc_s.so.1 (0xf50c4000) -- Thanks, Thiago
Re: cmake error
Em quinta-feira, 13 de maio de 2021, às 11:12:15 -03, Roy Lemmon escreveu: > Hi Thiago, > > Below is CMakeOutput.log > > I see no occurence of fastjet though. Yes, this is strange. > I should mention that I get no > error if I just use curl or wget to download the file (and it has a > proper size) plus it can then be extracted. Here the download seems to > be interrupted or not started as the file has zero size, though it is > present after running cmake ... > > In fact this is part of a larger code base but I have narrowed it down > to this trivial download problem. Is this problem happening during the build of a guix package? If so, as far as I know there's no network access inside the build container. This is to ensure that the build only uses the inputs described in the package definition and thus is reproducible. > Yes I have the nss-certs package installed though I thought that was > just for https sites ? That's true. I hadn't noticed that the URL was http and not https. I don't know why CMake would need to access CA certificates. One idea would be to use the LOG option in the file command to try to get more details (in case the build isn't happening inside a guix container as I mentioned above). Thanks, Thiago
Re: cmake error
Hello Roy,
Em quinta-feira, 13 de maio de 2021, às 14:17:21 -03, Roy Lemmon escreveu:
> Hi again,
>
> Just to not that the original CMakeList.txt file for fastjet uses
> ExternalProject_Add with the URL command. Perhaps no-one has used cmake
> in Guix with that option before ...
That's a good possibility. I tried your CMakeLists.txt example with cmake
installed via Guix and I saw the same error. With my host distro's cmake it
works fine.
So it appears that file(DOWNLOAD) is broken in Guix's cmake. Perhaps no one
noticed because when building guix packages, dependencies are download in
advance rather than as part of the build.
> Still no solution ...
Sorry, I'm not of much help. I only have very limited experience with
cmake.
I tried using the LOG option in this way:
file(DOWNLOAD "http://fastjet.fr/repo/fastjet-3.3.3.tar.gz";
"fastjet-3.3.3.tar.gz" TIMEOUT 60 LOG FILE_LOG)
message(STATUS "file log = ${FILE_LOG}")
But ${FILE_LOG} is empty. Not sure whether I'm using the option in the
wrong way, or file didn't log this problem.
--
Thanks,
Thiago
Re: cmake error
Em quinta-feira, 13 de maio de 2021, às 11:12:15 -03, Roy Lemmon escreveu: > Hi Thiago, > > Below is CMakeOutput.log > > I see no occurence of fastjet though. Yes, this is strange. > I should mention that I get no > error if I just use curl or wget to download the file (and it has a > proper size) plus it can then be extracted. Here the download seems to > be interrupted or not started as the file has zero size, though it is > present after running cmake ... > > In fact this is part of a larger code base but I have narrowed it down > to this trivial download problem. Is this problem happening during the build of a guix package? If so, as far as I know there's no network access inside the build container. This is to ensure that the build only uses the inputs described in the package definition and thus is reproducible. > Yes I have the nss-certs package installed though I thought that was > just for https sites ? That's true. I hadn't noticed that the URL was http and not https. I don't know why CMake would need to access CA certificates. One idea would be to use the LOG option in the file command to try to get more details (in case the build isn't happening inside a guix container as I mentioned above). Thanks, Thiago
Re: cmake error
Hello Roy, Em quinta-feira, 13 de maio de 2021, às 07:35:17 -03, Roy Lemmon escreveu: > I have a problem with the cmake build package. > > Below is a small CMakeLists.txt test file where I attempt to download the > file fastjet-3.3.3.tar.gz. > > * > * # Specify the minimum version for CMake > cmake_minimum_required(VERSION 3.13.5) > > # Project's name > > project(hello) > > file(DOWNLOAD "http://fastjet.fr/repo/fastjet-3.3.3.tar.gz"; > "fastjet-3.3.3.tar.gz" TIMEOUT 60) > > ** > > When I run this file I get an error about the certificates: > > ** > rlemmon@parton ~/example$ cmake . > CMake Error at CMakeLists.txt:8 (file): > file /home/rlemmon/.guix-profile/etc/ssl/certs/ca-certificates.crt > > > -- Configuring incomplete, errors occurred! > See also "/home/rlemmon/example/CMakeFiles/CMakeOutput.log". > ** > > Can someone help ? Do you have the nss-certs package installed? The Guix manual mentions¹ that it may need to be, in order for apps installed by Guix to authenticate certificates. If you already have that package, then it's necessary to look at CMakeOutput.log to see if there are more hints. Thanks, Thiago ¹ https://guix.gnu.org/manual/en/html_node/Application-Setup.html
