<jbnote>nckhexen: for grub-efi-netboot-bootloader, the target directory is *not* relativized to MOUNT-POINT (the last argument to guix system init). This is a special case; I guess the rationale is to decorrelate the tftp directory from the NFS root. However, i'd like both to be linked, as in the standard case, which I find more easy to handle.
<nckhexen>‘MOUNT-POINT is the last argument in 'guix system init /etc/config.scm mnt/point'’
<vagrantc>although there may have been some work to improve that a bit ...
<Kolev>Has anybody configured Guix as a Kodi system?
<mwette>I'm guessing substituions won't help w/ riscv. I have a VisionFive2 w/ 4 GB.
<singpolyma>Yeah. I would be prepared to wait many weeks to install stuff
<Kolev>singpolyma, that idea reminds me of my FreeBSD days.
<Kolev>singpolyma, I got Guix System doing all my jobs.
<vagrantc>mwette: another option might be to cross-compile your image on another machine with more resources ... but then you'll need to regenerate the image rather than upgrade in place for the most part
<mwette>vagrantc: thanks. I am toying with the guix option for my box, and would look to keep the package and service count small.
<NewGuixUser>rekado: so this "(use-modules (past packages python)) (specifications->manifest '("firstname.lastname@example.org"))" builds on v1.4.0
<NewGuixUser>I guess all I can really do is very slowly add things in one by one
<ulfvonbe`>there are two 'member' procedures: (@ (guile) member) and (@ (srfi srfi-1) member)
<ulfvonbe`>the former is documented in section 126.96.36.199 "API Reference > Data Types > Lists > List Searching" of the guile reference manual, and the latter is documented in section 188.8.131.52 "Guile Modules > SRFI Support > SRFI-1 > SRFI-1 Searching" of the guile reference manual
<ulfvonbe`>note that because the former uses 'equal?' for comparison by default, it will work everywhere that 'string=?' works
<ulfvonbe`>you could check whether replacing the 'member' on that line with '(@ (srfi srfi-1) member)' makes it work
<NewGuixUser>I'll try that once this current build either succeeds or fails. I ended up going back to a very simple/naive approach in hopes that I can get something building
<NewGuixUser>I can't tell if that helped or not because I can't figure out which channels.scm I used with it and haven't been able to reproduce the error. I've just been trying so many different things.
<NewGuixUser>One interesting thing though is if I build email@example.com and use a transformation to skip tests the build fails due to missing zlib, but if I don't skip tests the build succeeds and then fails on a test
<ulfvonbe`>could you paste a more-or-less minimal reproducer of that?
<ulfvonbe`>of anything you'd like a closer look at, really
<jaeme>When should I CC people from the mentors team?
<jaeme>I noticed that theres no team within scope of gnu/packages/wm.scm
<NewGuixUser>ulfvonbe`: so here's my manifest and channels https://paste.debian.net/plainh/6991d5c9 I've gone back to a much more simple approach just trying to get really anything building. I can run that with "guix time-machine -C channels.scm -- environment -m manifest.scm -c 0" and I get an environment with Python 3.8.5 as expected, but the pypi packages
<NewGuixUser>are still built with 3.9.9 so they aren't available in the python repl.
<ulfvonbe`>I would expect that's happening because you're using a graft to go from 3.9.9 --> 3.8.5
<NewGuixUser>I originally tried to do a package transformation but that was when I was getting those odd build issues so I switched to pulling it from guix-past and the build succeeds
<ulfvonbe`>you can use with-input instead of with-graft. It will result in the builds being done post-replacement, instead of first building everything with 3.9.9, then trying to patch all references to refer to 3.8.5
<NewGuixUser>rekado was trying to help me reduce the number of builds, but honestly if I can just get the packages I need built I'll put up with any number of builds
<NewGuixUser>Ok so switching to with-input fails when building "python-pytest-forked-1.3.0". The log doesn't help much, just says there was an uncaught exception
<NewGuixUser>I can skip the tests on that and get further, but then a direct dependency of numpy ends up failing a test case. I'm a little hesitant to skip the tests on that one since it's a direct dependency"
<NewGuixUser>Ok I think this is my last question for now. So I ended up skipping that direct dependency and numpy built fine, it exists in the environment with the right python version and I can import it. However, if I rebuild and don't skip numpy's tests the build fails and the error is "ModuleNotFoundError: No module named 'numpy'". I'm assuming there's
<NewGuixUser>something odd going on where the tests are expecting the package to be installed under a specific version of Python and that's why they're failing, but I don't know how I could confirm that. Do you have any advice on how I should proceed? It looks like I can install it fine, I'm just wary about installing packages that look like they work but don't
<NewGuixUser>rekado: Whenever you're online I would appreciate it if you could take a look at this https://paste.debian.net/plainh/c9617b2c. That almost builds properly and the couple remaining errors were things that I thought could be resolved by adding back in the cut? strategy you were helping with earlier. However, when I do that I get back to the same
<NewGuixUser>build failure on "python38-attrs-bootstrap" we saw previously. I'm hoping there's just a bug in the recursion because otherwise I'm unsure what else to try.
<jbnote>Hi there, i'm using Guix on a cluster configuration, as described https://guix.gnu.org/cookbook/en/html_node/Installing-Guix-on-a-Cluster.html. /home is also shared, as you can imagine. The nodes are GuixSD (completely diskless and netbooted, but this is a detail); they mix x86_64 and aarch64. Problem is, the default profile as setup with /etc/profile is from one arch. Is there a standard way to handle this use case? I'm starting to
<jbnote>customize /etc/profile to source different profiles depending on the arch but i'm anticipating problems with guix install being hard to use for simple users (would there be a way to customize the "default profile" through environment variables?) and guix home does not seem compatible with this approach (unless ~/.profile can be also customized?)
<jbnote>same for the default profile used by guix pull BTW: can it be customized dynamically and transparently through environment variables?
<lilyp>jbnote, you can use (getenv) in your config.scm
<lilyp>I'd recommend doing that + (operating-system (inherit base-config))
<jlicht>rekado: thanks! That's a pretty nifty feature to have \o/
<graywolf>This is interesting, when using guile-build-system, the target output directory's scm path is *not* added into %load-path, but go path *is* added into %load-compiled-path. Would anyone know why?
<graywolf>Seems weirdly asymetrical, so I assume it is intentional.
<vivien>I am skeptical installing the scm files is needed at all.
<graywolf>Isn't having the source code useful (for a user) when trying to figure out how stuff works?
<graywolf>I guess there could be a separat :scm output I guess...
<vivien>We don’t install source code for C programs and libraries
<graywolf>Hm, fair point. I somehow consider "scripting" languages different, but cannot exactly pinpoint why.
<snape>i don't want to use guix repl because my goal is to put this in direnv
<graywolf>Running just guile does not set the paths correctly afaik, but I will not pretend why. There was a fairly deep dive into this done on a bug tracker for a popular channel that packages non free software. You could try reading more there (MR about .dir-locals.el).
<phf_>Hi #guix! Where can I find help to make a build system reproducible? I've this result: https://imgur.com/a/MTgKb2L from: diffoscope --html diff.html /gnu/store/gjg...-elixir-dialyxir-1.4.1 /gnu/store/gjg...-elixir-dialyxir-1.4.1-check
<phf_>Ok, I'll try: 1) check the build logs and/or the code for things that record timestamps 2) bug reports and patches in a distro, maybe Debian 3) issue database and 4) diff reported by diffoscope and figure out how that file is produced
<phf_>If all Guix packages are supposed to be bit reproducible, then I guess that rebar3 is not since I get: https://imgur.com/a/nKmVfsb from: guix build --rounds=2 -K rebar3 and diffoscope --html /tmp/diff.html /gnu/store/1ylhh2j996bnnm9mxac2d7y06c7l0fa6-rebar3-3.18.0 /gnu/store/1ylhh2j996bnnm9mxac2d7y06c7l0fa6-rebar3-3.18.0-check
<jaeme`>What should I do if my patch hasn't been responded to in nearly a week?
<mirai>sneek, later tell phf: perhaps a matter of supporting SOURCE_DATE_EPOCH ?
<nckhexen>#guile doesn't have an entry message, but civodul could set one with ‘/msg ChanServ SET #guile ENTRYMSG Blah blah welcome to #guile blah blah.‘. Or add it to the topic. I'm not a chanop there.
<nckhexen>jaeme: You can send a ping to the bug# and/or link it here asking for reviewers.
<santiagopim>Hi, 'guix pull' creates a new generation in the 'guix describe' stack, but how can you list or switch those generations ? When 'system' or 'home' it is possible to browse the respective generations.
<santiagopim>I usually use 'guix describe; guix system describe; guix home describe' as a command in my bash prompt.
<NewGuixUser>Looks like the cut? isn't working quite right. My build hasn't failed yet but it is currently trying to build inkscape. It's weird because I feel like I understand how cut? works and it seems clear to me that it should be skipping inkscape.
<lilyp>mirai: As Ludo points out, longer-term we need a way to signal deprecation :)
<NewGuixUser>rekado: I was just double checking my existing requirements.txt and saw that I need to include boto3 and do not need to include pytest-asyncio. I'm going to make those changes to the latest manifest you shared and see if that builds. I must have tried adding in an old pytest-asyncio at some point to work around another build issue.
<nckhexen>Lumine: Thanks for the report. I'm trying to reproduce it. I've also noticed something's wrong with the deblob script hashes.
<Lumine>nckhexen: a patch was submitted for the hash earlier by jlicht
<NewGuixUser>python-pytest-asyncio still fails. I guess I'll try re-enabling tests in the python38 function but disable them specifically for python38-pytest-asyncio in my initial transform function. If that still fails my only other thought is to copy the package code into my manifest and manually remove the tests.
<rekado>added a special case for python-pytest-asyncio
<rekado>(situations like this are the reason why we added #:tests?)
<nckhexen>Hm. I agree that this is a bit confusing. ‘guix build --rounds=2 hello’ does absolutely nothing twice, and immediately reports an already built hello. ‘guix build --check --rounds=2 hello’ does the pedantically correct thing, which you must be a seasoned Guixer to recognise (test the grafting derivation twice), so what the average user would want is ‘guix build [--rounds=N] --check --no-grafts PACKAGE’.
<nckhexen>Not great UX, and maybe could be improved beyond merely documenting the status quo.
<NewGuixUser>I'm seeing a build error on python38-importlib-metadata which I could have sworn had been building previously, but I may be mistaken
<fnat>If I roll-back to a previous generation - say from 100 to 90 - and then redeploy (in my particular case, this means "guix home reconfigure config.scm"), what I get is generation 91, which overwrites the original generation 91 - is my understanding correct?
<Altadil>nckhexen: Ok, it’s clearer in my head now, thanks!
<nckhexen>fnat: I think so, or something very close to that. There isn't some fancy undo tree.
<nckhexen>fnat: Sorry for the disappointing answer. If you want to document your journey it would certainly be a welcome addition to the cookbook. If ‘guix build --check --no-grafts […] PACKAGE’ doesn't say ‘differ’, but just prints a store file name, that's good.
<Altadil>nckhexen: not disappointing at all! You’re helping me a great deal, thanks. :)
<Altadil>I guess we should document this in the "22.7 Submitting Patches" part of the manual, since that is what I was getting my initial info from. I haven’t looked into how to contribute documentation yet, but I’ll try to make this my next patch after this one I’m testing.
<NewGuixUser>Ok my build finally finished. I'm looking at that matplotlib error now.
<NewGuixUser>This error is bizarre. I thought that maybe the issue was that setuptools wasn't installing properly and we're just seeing it complain about the setuptools_scm_git_archive plugin but that doesn't seem to be the case.
<jaeme`>nckhexen: You're right it should be gpl3+.
<jaeme`>Should know better to check further than the LICENSE file.
<nckhexen>Counterintuitively, LICENSE or COPYING files aren't the ideal source of licencing information, since they just say ‘yo I'm the GPLv3’. A file header with ‘this software is licenced under the GPL, but only uneven versions, and under the MIT licence if you're Spanish’ takes precedence.
<jaeme`>Why couldn't they have a nice gpl3+ flair in their README /half-joke?
<jaeme`>nckhexen: yeah so I have to check out for that.
<nckhexen>No biggie. I'll adjust it here, I just wanted to double-check.
<nckhexen>(General WTF) uhm does the copy-build-system just compeletely ignore cross-targets? Like, at all? Because that does seem to be the case.