<luis-felipe>vivien: Another thing is that when the origin is not a git repository, sometimes (or almost always?) the test suites are not even included, so the test phase fails.
***NoClu_ is now known as NoClu
<podiki[m]>okay, think I have a minimal example that builds something that tries to refer to the old (non-grafted) version
<podiki[m]>I don't know if it is this specific package building or perhaps a bug in how it is being build (not in the usual "guix build" way)...but should this be sent to the security email since it involves perhaps a problem with grafts?
<marusich>However, I don't understand how it accomplishes that task. When I invoke "make -j", what stops Make from running make-core-go, make-packages-go, make-system-go, and make-cli-go in parallel?
<marusich>I'm just curious. Does someone hre understand how it is that this Makefile.am hackery causes the .go files to not get built all at once? I don't understand it, but I would like to.
<marusich>I get that it creates multiple targets, and each of the targets builds smaller groups of files. But I don't understand what is stopping Make from just building all of those targets in parallel when I run "make -j".
<lilyp>the body probably just exists to prevent another body elsewhere, i.e. to make the alias clearer
<marusich>To answer my earlier question about how Makefile.am arranges not to run make-core-go, make-packages-go, etc. in parallel, it seems to me the answer is surprisingly simple, and that is: an explicit dependency is made, for example, from make-packages-go to make-core-go, so that make-core-go must be executed entirely first before executing make-packages-go. The same is done for all the make-*-go phony targets.
<marusich>In fact, you can see that even after you have built everything, these targets do get run, and they get run in serial. It takes a few fractions of a second, but you will see "Compiling Scheme modules..." printed 4 times, even when there is no work to do.
<podiki[m]>I think the problem I am running into is something with propagated inputs that have a replacement and doing a union-build
<podiki[m]>looking back in the logs, I see other propagated inputs with their replacement instead (eg. older gnutls ones)
<robin>gnoo, in package definitions? often (setenv "CC" "gcc") before the configure phase is enough; if it actually hardcodes the 'cc' name, i'd use substitute* on the relevant file(s), as with the 'sparse' package
<podiki[m]>union-build takes (or is used) where it looks at build-inputs, so I think that's where it gets the direct store directory of the un-replaced package?
<gnoo>robin: no, on the shell, i've got quite a few scrips that use 'cc' as a program name
<podiki[m]>lfam: I have a minimal working example, wasn't sure if I should just paste it (not a security hole per se, but)
<lfam>podiki[m]: It's entirely possible nobody tried to build a union with these types of packages before
<podiki[m]>curiously it does get the replacement package, sort of; but tries to include the older libexpat.so.1.x
<podiki[m]>I haven't tried to change the propagated input to see that it fixes this, but seems it would (bit late now for much building)
<lfam>I think others (you? :) ) will have to come up with the solution
<podiki[m]>no it builds, but the final library in the link chain won't exist (points to wrong version in the replacement expat)
<lfam>I'm not sure what you mean by that. The final library in the link chain?
<robin>gnoo, or add a trivial #!/bin/sh <<newline>> exec gcc "$@" wrapper to someplace in $PATH (maybe create ~/bin or ~/.local/bin and prepend it to $PATH in ~/.profile or ~/.zprofile, etc., depending on shell)
<podiki[m]>well for my purposes I would just put a check in to manually change the expat input or something
<podiki[m]>libexpat.so -> libexpat.so.1 -> libexpat.so.1.8.3 (I guess not chained in our build, but that's what I meant)
<vivien>Hi! I figured out my python issue: I was using the default check phase (python setup.py test) and not pytest
<dissoc>it seems like when i have a build fail i get "could not find build log for ..." any idea why i can no longer see the logs?
<vivien>And for the other package, as luis-felipe wrote, the test data aren’t distributed.
<xelxebar>dissoc: Odd. Is your local state dir the default /var? What does your /var/log/guix look like?
<dissoc>xelxebar: i think it was permission related. i didnt change them but maybe auditd did? im not sure but it seems to be working once i tried changing the permissions on /var/log
<xelxebar>dissoc: Okay. That's a good start. Did you look at the perms before overwriting?
<dissoc>xelxebar: yes. i compared it to other guix system i had working and noticed the difference
<AwesomeAdam54321>Is there a way to set environment variables of a service managed by the Shepherd? I would like to set a new environment variable to the existing environment rather than starting with an empty environment, which is what #:environment-variables does
<vivien>AwesomeAdam54321, what should dictate the environment variable value?
<vivien>Also, what "existing environment" are you referring to? That of root in a login shell?
<AwesomeAdam54321>vivien: the existing environment in this case refers to the environment inherited from PID 1
<xelxebar>dissoc: Cool. If you notice the directory flip perms again and you manually restore, it might be nice to monitor the directory with inotify.
<AwesomeAdam54321>vivien: what dictates the environment is (environ). What #:environment-variables does is use (environ) to set an environment with only the variables specified, however that's not what I'm looking for
<phf-1>Hello Guix! How can I inspect a .nar archive? I used guix --export -r > $pkg.nar
<phf-1>but apparently, some dependencies are not installed
<vivien>AwesomeAdam54321, maybe the service lets you customize the package that get its binary called. You could maybe override that to a new wrapper package that adds some environment variables?
<allana>Hi Guix! Any Golang-and-guix developers here? I'm not a golang developer, but I am considering packaging some-or-all of kubernetes. I'm curious to know about best practices. I have seen some golang monorepos that contain what should multiple guix packages, and am wondering if I should have a "source-only" ("build" stage deleted) package of kubernetes and then make guix packages for the different components that "inherit" from the source
<rekado_>and then add the last one to the group later?
<mothacehe>rekado_: great! yes i think btrfs allows to extend the raid easily
<gnoo>phf-1: yeah, -RR is only needed if you don't have sudo permissions
<gnoo>and making a package from .tar.gz files is something every distro (should?) support ootb
<phf-1>ok, well, how can I build .deb and .rpm from a package definition ?
<allana>jpoiret: thanks! There's a good chance that I won't package all of kubernetes, especially because I don't have a lot of time to do so. But I will be giving it a go over the next few weeks hopefully.
<luishgh>hi guix! i'm trying to package tree-sitter and don't know how to deal with its cli. i wanted to build it to a bin output (it is built with cargo and the library itself with make), but i would need to run a `cargo fetch` after the unpacking of the source code. however, from what i understood, build phases don't have network access. how would i deal with this situation? should i create another package for the cli and possibly use the
<abrenon>ah non, mais c'est pas pour nous attirer, il est nécessaire de présenter d'allumer sa caméra et de présenter une tasse de café à la reconnaissance de boisson automatique pour pouvoir entrer sur la visio
<abrenon>'tention, c'est ultra-sécurisé, haute-technologie
<phf-1>Haha... excellent. J'imagine nos chers anglophones qui voient la liste passer impunément de l'anglais au français... comme si on mettait un coup de blanco sur les sous-titres de Breaking Bad ;)
<SeerLite[m]>Hi! I don't understand why `guix build firstname.lastname@example.org` builds. The source asks for a version of bitflags lesser than 1.3.0 (in Cargo.toml) but the version it uses in its cargo-inputs is 1.3.2. Shouldn't it fail and give an error? Why does it only fail when used as input in a package like alacritty?
<SeerLite[m]>Oh wait I think I get it, it's because when building it it's not really building anything but just setting up its source usage to be used at build time as a dependency
<abrenon>SeerLite[m]: wait what ? it's not building anything ?
<mfg>SeerLite[m]: But you are right that alacritty doesn't build currently :(
<SeerLite[m]>Yeah hehe that's what I was trying to fix. Someone suggested a few days ago that I should update to its new RC release but after seeing I had to mess around with too many Rust dependencies I gave up (I guess I'll leave that to the experts once an actual release comes out)
<SeerLite[m]>successfully built /gnu/store/spi0f5jndl6i8rannksjbryvn5igkkq0-alacritty-0.9.0.drv
<SeerLite[m]>Should I use a snippet or a phase for a temporary(?) fix like this? (forcing Alacritty to use newer rust-nix version)
<mitsubishi>hello i need some quick help, how do i quickly add a ca cert onto guix ?
<mitsubishi>documentation says i have to make a package myself but i dont know how to write a (cert) package
<mitsubishi>or can i point my profile's ssl to a non-read-only directly with env vars
<KarlJoad>I could not find any information about this in the Shepherd manual, but does Shepherd allow for parallel starting of tasks?
<apteryx>mitsubishi: it depends if your application is using openssl vs gnutls
<apteryx>with gnutls you don't have a choice; it looks in /etc/ssl/certs
<tribals>(local-file "my-old-bashrc"))`. Unfortunately, this doesn't work.
<cbaines>I think the actual error is: gnu/system/install.scm:358:19: Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#<record-type <guix-configuration>>) ())'.
<lilyp>That doesn't make it better only more annoying
<lfam>Yeah, but it's unhealthy to stay annoyed. So we need to learn to like it
<SeerLite[m]>Yeah tbh, as someone who just started to mess around with Rust packages, currently it feels like Guix is fighting against how the Rust version system works. I wonder if there's a way to improve it? It feels weird to have all these specific versions of dependencies defined as packages instead of using whatever the Cargo.toml says
<lfam>Also I think it's corny to say the language is bad. It just doesn't really fit with how we do things in Guix
<podiki[m]>does anyone know of an example package def that has imported-modules and uses gexp?
<lfam>But, if it's at all possible to change the Rust compiler without rebuilding the entire distro, that's worth figuring out how to do before we really need to
<podiki[m]>my search is not finding any and was trying to convert piper to gexp (since I am fixing its build and running anyway)
<SeerLite[m]>faust45: I'm sorry I have no idea how to troubleshoot your issue. Maybe you can install it from a running Linux system by installing guix onto it first, but I'm not sure. Try asking on the mailing list if you don't get help here
<lilyp>lfam: I think we'd first have to split it into compiler + stdlib
<lfam>faust45: Your problem is that the installer doesn't boot?
<podiki[m]>maybe some utility the is easy to adapt to exploring the package tree in different ways
<tribals>luishgh`: found your hint in chat log, it helped. Thank you a lot!
<tribals>now next question: how to resolve path relative to source file where it is mentioned?
<tribals>like this, in ~/foo/bar.scm, i want to refer to ~/foo/baz/quix.txt, but relatively to ~/foo - "baz/quix.txt"?
<robin>sneek, later tell lfam: https://rufus.ie/en/ is a good gplv3+ usb-drive flashing tool, but for ms windows only (still possibly useful for windows users installing guix, maybe worth recommending in the manual)
<sneek>lfam, robin says: https://rufus.ie/en/ is a good gplv3+ usb-drive flashing tool, but for ms windows only (still possibly useful for windows users installing guix, maybe worth recommending in the manual)
<robin>SeerLite[m], oh, that would be nifty, assuming signature verification and such could be integrated (perf-wise rufus > unetbootin, according to the rufus author, but there are zero plans to make rufus cross-platform)
<robin>lfam, for methods that boil down to 'cat > /dev/sdX && sync', i'd think so. some tools like ventoy are apparently much more complicated though (e.g. ventoy lets you put multiple ISOs on a disk and has a custom bootloader to choose one, afaict?)
<podiki[m]>yeah, ventoy lets you (supposed to) keep a bunch of different bootable images and I think even some storage? anyway, hit or miss for me, like I said. i guess some images play nicer with that set up than others
<dcunit3d>what tools are available to plot out the PCIe bus topology in guix?
<dcunit3d>i can't remember the name of the tools that i've used in archlinux
<drakonis>ventoy makes it pretty trivial to have multiple images stored
<drakonis>but not every iso lets you mount ventoy's device while it is booted up, so you can't access any data
<drakonis>no need to format anything, just throw the isos in there and any data you might need to store or access from a running OS