<ArneBab>I had searched before — it might be pretty useful to have.
<rekado>kreuzberg overheated once during the build, not sure what happened the other time. I left it building over night, and according to “guix processes” it was still going when I got up in the morning.
<rekado>I cancelled again; it’s now building linux, so at least it’s doing something productive now.
<cbaines>rekado, do you know what's pulling in guile-fibers?
<cbaines>ah, I think the shepherd does as of recent Guix revisions doesn't it
<chomwitt>Hi. can i use non free firmware with guix distro ?
<cbaines>chomwitt, that's the same as asking "can I use non free firmware with linux-libre", to which the answer is no.
<cbaines>if you want to use non-free firmware, you have to use a different kernel
<cbaines>rekado, ah, I think cuirass depends on that
<cbaines>the approach I took with the build coordinator is to have a guix-build-coordiantor/agent-only package, which doesn't include any of the dependnecies needed for the coordinator, just the minimal dependencies to run the agent
<cbaines>I think the same could be done here, as I don't think cuirass needs fibers for the worker
<carmenshea[m]>Hey all, I just finished building Guix Home. Seems to look and work exactly as before, just a few differences appear in the home directory...most of the directories now appear to be symbolic links. I have a question: Will guix pull, guix upgrade, and guix reconfigure work as before?
<minima>carmenshea[m] i think so, but i also think that you're supposed to use "guix home reconfigure home-config.scm"
<efraim>you'll want guix home reconfigure instead of guix pugrade
<efraim>I've gotten into the habit of locking my computers whenever I stand up, I've had to reboot 4 times already today
<minima>i've started seeing the "hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH' ..." message - which is puzzling me because my bash profile includes the usual GUIX_PROFILE var definitions, like this: https://bpa.st/RF76S
<minima>sorry, the message is displayed when using any guix command
<minima>(oh other addendum: i'm on a foreign distro)
<rekado>minima: have you installed glibc-locales and set GUIX_LOCPATH?
<minima>hey rekado, thanks, yeah, i've done both things; to be clear, glibc-locales is installed via guix home (hope that's ok) - and yes, GUIX_LOCPATH is defined in my .bash_profile (which i even tried and parsed explicitly before running a guix command, to make sure it gets set)
<minima>i.e. i also get the "guile: symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE" error, although in a slightly different context than what reported above
<minima>i get it when running "./pre-inst-env guix search hello" from within a guix pure shell, i.e. after "guix shell --pure -D guix help2man git strace"
<minima>this may very well be unrelated from the other glibc-locales issue i was mentioning a minute ago, but i also think both issues could be diff symptoms of the same problem or misconfiguration
<mekeor[m]>hello. is there a easy way to "make" the guix repository without docs? i wanna save time :)
<rekado>minima: this looks like you have a bit of a mismatch. E.g. an older daemon in a newer environment.
<rekado>glibc 2.33 has been upgraded to 2.35 already
<rekado>so it’s worth figuring out which part of your environment still uses the old glibc, and then upgrade that
<efraim>you can check 'guile' in the root of the guix repository, I ran into that recently
<minima>oh cool, that'd explain the issue... thanks rekado - this is a guix on foreign system installation, i've also upgraded guix from root and then i restarted the guix daemon but that didn't seem to do it
<minima>efraim, ok, yeah, i see the guile shipped with the repo is linked to 2.35 now
<minima>weird, if i use the binary (as in "./guile --version") i still get the error re 2.33 though
<minima>oh, ok, no i get it, it's because the daemon is older than the rest of the system
<minima>hm, barring the idea of waiting for my distro to ship an updated guix, what could be the solution here? to roll back to a previous guix home generation to avoid the glibc mismatch? or to use some form of containerisation (basically a VM i guess, with its own updated guix daemon)?
<efraim>we have 'ada/ed' packaged, which apparently can function as an Ada 83 interpreter, but we've never progressed from there
<efraim>also I'm pretty sure it builds correctly on powerlc-linux
<efraim>well that's incredibly frustrating. I'm pretty sure rust-bootstrap has been failing on riscv64 because it runs out of space in /tmp
<ngz>rekado: I thought about an improvement (two, actually) over #:tex-directory in texlive-build-system. I'm worried that sometimes, cruft generated in the build directory gets installed in the output.
<ngz>rekado: Also, sometimes, generated files in the build directory need to go into two or more directories, which cannot currently be handled by #:tex-directory keyword.
<ngz>rekado: So, my first idea would be to get rid altogether of that keyword. During the build phase, we generate files in a top "build/" directory (i.e., at the same level as "doc/"…), then, for each file in "build/", we look into the other directories ("doc/", "tex/" or whatnot), and if we find the same file, we _replace_ it with the new one. Files that cannot be found elsewhere are considered as cruft and ignored.
<ngz>rekado: During the install phase, we copy everything but "build/" as is in #$output, which will therefore contain generated files.
<ngz>rekado: As a bonus, we don't need to specify non-generated files in simple-texlive-package's locations argument anymore.
<ngz>I think the world will be a better place if we implement that.
<jlicht>ngz: Consider me an uninformed outsider w.r.t. texlive, but how would your rewrite work with false positives and false negatives?
<jlicht>where positive = file is included, negative = file is not included in the installed package
<ngz>jlicht: That's the good news about Texlive. Everything is included already, so we cannot miss anything out. IOW, it would work even if we didn't try to generate anything.
<ngz>If we generate a file that doesn't exist in the other Texlive directories, then it is not necessary. If Texlive directories contain a file that wasn't generated, it will be copied over anyway since all directories are copied.
<apteryx>jlicht: probably need to rebuild the .go files
<cbaines>apteryx, that string comes from the patchwork series I think
<cbaines>I'm not quite sure why that issue first had some csvkit related patches sent to it, then a gdb update.
<Guest9415>jlicht, i dont supply it. there is an efi record in more than one storage unit of my system
<Guest9415>in the nvme storage that i want to install , there a fat32 boot,esp /boot/efi partition , an ext4 partitoin mounted on / , and a swap partiton. There are boot efi partitoin also but at other storage units
<Guest9415>but in the next step i see in the /etc/config.scm indeed all boot efi partitions of my system
<Guest9415>i'll try to edit it to remove the ones i dont wont.
<Guest9415>strange thought. in debian -based installers i havent seen that
<Kabouik>How come Guix wants to instal all this from the command I ran? http://0x0.st/HZf6.png It is now installing a million of texlive packages, and others things not related to TeX, and one of this seems remotely related to ytfzf.
<Kabouik>I rsync-ed some of my .config folders from my main Guix system laptop to my phone running Guix package manager only. Could it be that Guix picked something up in a config folder to install packages instaalled on my laptop? I do not see which config folder could have caused that, though.
<Kabouik>What are those? TeX and other things listed there seem totally unrelated to ytfzf dependencies, which are just fzf, yt-dlp and mpv.
<ngz>Kabouik: you can use "guix graph --path ytfzf texlive-whatever" to see how it happened.
<ngz>Kabouik: The command "guix graph --path ytfzf texlive-bin" gives me the following path ytfzf -> libnotify -> ... -> texlive-bin.
<yelninei>Hi everyone, I hope this is the right place ask a question. I am currently trying to write some guix packages. One requires multiple patch files located at another git-repo. Is there a way to let guix fetch and apply these automatically when building the package? My current solution is downloading the files manually and hard coding the path
<ngz>yelninei: No, there's no internet access during the build. you need to download the patches and add them to the repo (and register them in "local.mk").
<Guest9415>unfortunately editing /etc/config.scm can help because efi boot partitions are identified by their uuid and i dont know which is which. can i execute 'lsblk' by another terminal ?
<mfg[m]><Kabouik> "What are those? TeX and other..." <- Transitive in the mathematical sense. Itemas these TeX dependencies are most probably dependencies of the direct dependencies. Because it's TeX I'd assume it's for building documentation.
<mfg[m]>s/Itemas/I'd guess/ the heck did this come out as Itemas?!
<mfg[m]>Do we have package transformations to add inputs as command line arguments to a guix shell invocation?
<mfg[m]>Such that a package gets modified to include that additional input?
<Kabouik>Thaanks mfg[m] and ngz for your answers. It's still building, it won't be quick on a phone when things like tbase need to be built. :<
<ngz>yelninei: origin objects are downloaded before the build starts. But I may have misunderstood your question.
<mfg[m]>Kabouik: Ah yeah that's true. Why can't you use substitutes though? are they unavailable? If so, it might be worth to find out why; maybe there are build failures, then you would not have to waste time trying to build things locally that don't actually work right now :)
<Kabouik>I believe substitutes should be used by default, no? I am aassuming there is just no prebuilt version for aarch64 yet.
<mfg[m]>Kabouik Ah yes, aarch64 🤔 did you check the build logs of the larger builds (as qtbase for example)? You can check them on ci.guix.gnu.org iirc if the log says that there was a build failure you don't need to build it, as it most likely will not succeed.
<Kabouik>Is `ERROR: ld.so: object 'libtls-padding.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.` a preload Guix package manager does? I am having a hard time identifying the source of it, but it happens for every Guix command I run, in any terminal. The commands still work, there is just this error at the top. This does not happen for commands other than guix.
<Guest9415>Where should i add in my config.scm (kernel-arguments (append (list "nomodeset") %default-kernel-arguments)) ?
<Guest9415>my freshly installed guix system throw an error in 'guix system reconfigure /etc/config.scm' , aborting reconfiguration because commit 8e2... of channel guix is not a descendant of 98....
<juli>This probably means that at some point there was an amended commit and/or rebase of the git repo. If you're confident you're pulling from the correct place, you can add the `--allow-downgrades' flag and it should work. The other option is that someone has hijacked your route to the git repo and is offering spoofed code. This is improbable, but not impossible.
<mekeor[m]>Guest9415: if you know what you are doing, you might pass --allow-downgrades, but make sure you have not been pwned first :)
<mekeor[m]>Guest9415: put `kernel-arguments` just inside `operating-system`.
<juli>on the topic of repository verification, why can I no longer make commits to my local checkout of the Guix repository? Do I need to configure GPG or something?
<mekeor[m]>juli: someone mentioned that guix recently began enforcing cryptographic commit signatures. but did you also try to just guix pull?
<Guest9415>mekeor[m], i am a new guix user. I found in the guix forum a hint to add a kernel argument line in my config.scm and then guix reconfigure
<mekeor[m]>Guest9415: "pwned" means maliciously hacked / cracked
<mekeor[m]>Guest9415: i don't think that two things you are talking about are related to each other. namely: (1) the "aborting because commit ... is not descendant of ...". and (2) adding kernel-arguments.
<Guest9415>mekeor[m], i see. i hope not. i've just installed guix and tried to solve a booting issue
<elevenkb>Guest9415: in order to compare versions.
<Guest9415> i mean that the default guix repo has a latest commit and thus a head version from which i pull packages. How can i inspect the version and the contents of that 'version' (like for example i would examine the contents of a debian repository)
<mfg[m]>Guest9415: you can see which guix you are using when running `guix describe` the commit hash that you see there for the channels are the git hashes which you can use to checkout the channels git repo at exactly that commit. There you see all the code that this specific version uses. I hope this is what you are searching for?
<mfg[m]>So afaik the guix that runs on your system and that you configure with `guix system reconfigure` uses it's own copy of the repo. It's because every user can use a different version of the packages (which are part of the same git repo as the guix Daemon sources). The commit that your system uses should be displayed with `guix system describe`
<mfg[m]>So when a user `guix pull`s the specific commit that the user is using can be different from what the system guix is using
<mekeor[m]>hello. i'm trying to add a package "tree-sitter-gomod" to guix proper. why do i get the following build error when i run `./pre-inst-env guix install tree-sitter-gomod`?: Throw to key `gnutls-not-available' with args `("(gnutls) module not available")'. https://paste.rs/5ne
<nikita>I guess it doesn't matter if you didn't run into this before or had the necessity to change it
<elb>`guix pull` keeps timing out for me on substitutions for various packages; it _looks_ like it makes more progress each time it runs, but I don't want to be hammering on a server that appears to have Problems at the moment. Is there a way to tell it to just be more patient, I don't care how long the update takes? (I left for a few hours and came back, and still have the same problem)
<lilyp>you can use --fallback to build packages from source when the substitution fails
<elb>unfortunately that didn't work, although the `guix pull` command does say that it should
<elb>(in fact, as far as I can tell, the error was exactly the same)
<lilyp>Guix show shows all versions currently installable via that syntax. For versions gone, use time-machine.
<panosalevro>I'm not sure where I can see that information with guix show
<juli>right so that command will search for any package definitions in the version of Guix you're using which provide that version of the package. If you want to see the history of package versions available, as far as I personally know, you'll need to find a commit of the Guix source repository (https://git.savannah.gnu.org/cgit/guix.git) with that version available, then operate from that commit using, as lilyp said, ti
<juli>me-machine. Not all past versions of a package may have been in the source tree; in such situations, you can try to write a package variant for that version such as by inheriting from a current version of the package