IRC channel logs
2023-10-28.log
back to list of logs
<nckhexen>Kolev: It does that a lot, it's very sensitive to having a UTF-8 locale configured on both ends. <Kolev>nckhexen, weird. Didn't have that issue on Fedora. I'll just use regular SSH I guess. <NewGuixUser>rekado so is the result of that map compose the input to my manifest? like (packages->manifest (map ....))? <rekado>I haven’t tested this whole composition myself, so there’s a good chance I overlooked something <rekado>but it’s very similar to what we did in guix-past, so it (or a variant of it) should work <NewGuixUser>Yeah I'm seeing "guix/packages.scm:1419:23: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): "python-coloredlog"" <rekado>oops, somewhere you’re passing a string instead of a package value <rekado>could you show me the whole thing you’ve got? <jbnote>nckhexen: thanks for the tip about (command-line). The targets are absolute for netboot-installer, contrary to the other bootloaders, so I have to resort to this. <nckhexen>Kolev: I can't reproduce it now, of course, but it's a classic. I don't have a remote Fedora system, only Debian, and I can mosh just fine to that from my Guix System. <NewGuixUser>when I unquote them I get errors about unbound variable, so I guess I need to import the appropriate modules containing each one? <nckhexen>I think I last got it when 2 Guix Systems had different glibc locale versions. <nckhexen>They are ‘absolute’ relative to the target system, not the host system. <nckhexen>Are you doing some double-nesting-type-deal-thing-amabob? <nckhexen>If they really are absolute relative to / during installation, that sounds like a mere bug that should be fixed in Guix, since it directly contradicts [my reading of] the docstring. <rekado>NewGuixUser: just a moment; I’ll prepare something <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'’ <jbnote>nckhexen: the grub-efi-netboot-bootloader codepath is probably not very well tested; for instance it breaks if you don't put a trailing slash in the targets directories. <nckhexen>Anything making a user think they need to parse the command line is a bug 😉 <nckhexen>It's a clever workaround, but I urge you to submit a bug report when you have the time. <jbnote>nckhexen: Ok, will do along with the trailing slash bug (which I have fixed locally). Thanks for your insight. The documentation not being very clear, I didn't recognize this as a bug. <rekado>NewGuixUser: I’m still having some trouble to cut the recursion early <jbnote>nckhexen: I don't mean to be mean to guix documentation. It is generally completely awesome, btw. <nckhexen>It's not mean, it falls short in places. <nckhexen>Perhaps you were reading something else. <nckhexen>Said something might be in need of loving improvement. <nckhexen>And not to offload (more) work, but said improvement would ideally be done by someone actually familiar with netboot, which is not me. <NewGuixUser>rekado: so you mean you're still seeing it build unnecessary packages e.g. inkscape? <jbnote>nckhexen: thanks for pointing out the documentation in the code. I was reading in the website html manual. This is definitely more clear. <nckhexen>It's a habit I don't often notice I have. <rekado>NewGuixUser: yes, the problem was with the order of the transformations <rekado>there’s some verbose debugging output in this code; hope you don’t mind :) <rekado>I’m building this with this command: guix time-machine -C channels.scm -- environment -m manifest.scm <nckhexen>jbnote: I doubt it'll make a difference in this case, just general advice. <rekado>(not Guix Past, because I didn’t want to figure out which version of that channel works with 1.4.0 of the Guix main channel) <NewGuixUser>I'm running the build on my end as well with the same channels.scm you provided <jbnote>nckhexen: thanks a lot for your guidance. <rekado>I haven’t built it all, but the initial output looked fine to me <NewGuixUser>cannot build derivation `/gnu/store/gw34l7ikhmvpdm4862c9m721207z4acx-python38-attrs-bootstrap-21.2.0.drv': 1 dependencies couldn't be built <NewGuixUser>the error from the log is "zipimport.ZipImportError: can't decompress data; zlib not available" <rekado>that’s in the build of python 3.8 <rekado>maybe worth adding guix past for that package after all… <NewGuixUser>hmmmm so even the most recent commit on v1.4.0 cannot build python@3.8.5 <Kolev>How do I use my personal shell scripts? <mwette>Does anyone have an idea of the minimum RAM requirements for a Guix System? <Kolev>I've thought of putting Guix System on an SBC, configuring it as a Kodi machine. <vagrantc>based on experience, 2gb is painful, but not impossible ... 4gb is a bit rough ... 8gb is pretty ok <singpolyma>Probably depends if you can get substitutes for everything you need ;) <vagrantc>even if you can get substitutes, guix pull has a fair amount of non-substitutable bits <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 '("python@3.8.5"))" 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 6.6.9.7 "API Reference > Data Types > Lists > List Searching" of the guile reference manual, and the latter is documented in section 7.5.3.7 "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 <NewGuixUser>honestly I didn't write that function and I don't fully understand the broader context yet, but I know the code loads srfi-1 <ulfvonbe`>note that the uses of modules in the "host" and "build" sides are independent <ulfvonbe`>so, for example, a #:modules argument to the package won't affect it <ulfvonbe`>and it has a (use-modules ... (srfi srfi-1) ...) somewhere before where this is defined? <ulfvonbe`>or a (define-module ... #:use-module (srfi srfi-1) ...) <ulfvonbe`>my tests in a repl suggest that after (use-modules (srfi srfi-1)), a plain 'member' should refer to the srfi-1 member <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 python@3.8.5 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 <ulfvonbe`>note that it will likely cause significantly more builds <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 <Kolev>Where is the system declaration for the installer? I want a live system with GNOME. <Lumine>Hello, linux-libre-deblob-check-6.5.9-gnu fails to build this morning on a hash mismatch <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)) <rekado>NewGuixUser: this builds python38-attrs-bootstrap and many more just fine <rekado>but once those python38-* packages have been built there’s another round of builds which is not correct <rekado>I’m busy most of the day today, but I can take a closer look later <jbnote>lilyp: thanks a lot. I'm a bit new; which config.scm are you referring to? there are so many config hooks that it is not clear to me :) <lilyp>jbnote most folks refer to /etc/config.scm when they say config.scm – the one you use to reconfigure your operating system config <lilyp>not sure what the canonical name for your home config is <cow_2001>How did you put links in Guix search output? I see, for example, a license "ASL 2.0" is a link to the GNU web page describing the license. <theesm>Lumine: there has been an update to the 6.5.x linux-libre deblob-scripts in linux-libres upstream three days ago that causes the hash mismatch to happen, should be quick to fix <jlicht>I've been a bit out of the loop, what's this "Change-Id" that is now added to my commit messages? <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>Hi, how can I use guix shell so that it sets GUILE_LOAD_PATH corresponding to my currently pulled guix? <snape>so that I can use guix modules from there <snape>it seems to me that 'guix shell -C guile guix' sets GUILE_LOAD_PATH corresponding to the guix package, which is old <graywolf>snape: How are you running the guile? Using `guile' command? <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). <cow_2001>The magic is in colors.scm's definition of the procedure "hyperlink": (string-append "\x1b]8;;" uri "\x1b\\" text "\x1b]8;;\x1b\\") <snape>graywolf, do you have a link to the ticket? <graywolf>I do, but I think pasting it here would violate the channel rules, which I do not want to do, sorry. <graywolf>ACTION wonders how to direct messages in irc <graywolf>"Please do NOT promote or refer to this repository on any official Guix communication channels." <snape>and you already broke it btw <snape>I guess my solution is to manually set GUILE_LOAD_PATH to ~/.config/guix/current/share/guile/site/3.0 <vivien>I seem to remember #guile was not open to participation of the public, is it still true? <vivien>snape, would you try to say something there? <snape>well no because it's really a guix issue <vivien>Sorry my question was unrelated to yours <vivien>Maybe I’m banned? How would I know? <snape>they say: "Nobody is banned!" <snape>maybe you need to be logged in <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 <civodul>phf_: hi! there are several strategies <civodul>one is to check the build logs and/or the code for things that record timestamps, which is quite common <civodul>that typically leads to either entire strings (date/time) or 32-bit values to change in the resulting binaries <phf_>Hi civodul! You have all my attention. <civodul>the other approach is to start from the binary diff reported by diffoscope and figure out how that file is produced, what the differing bytes represent, etc. (harder!) <civodul>another strategy is to look for bug reports and patches in Debian :-) <civodul>though apparently there’s no “dialyxir” package there <phf_>I'm pretty new to these things. You mean that people in Debian have Elixir packages and should have face the same reproducibility issues and should have also found fixes? <civodul>reproducibility issues are usually shared among all distros <civodul>and Debian is one of the most active distros fixing these things <phf_>So, I'll look at other dristros since Debian does not have a dialyxir package. <phf_>So, to understand what's happening here: a value may be time dependent at compile time and then transported in the resulting artifact. <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>vivien: You need to be registered with (and logged into) NickServ to speak in #guile. <nckhexen>Or a chanop needs to unset +R on the channel. <vivien>nckhexen, I constantly bump into the same issue and forget the details a few months later <vivien>If the channel message could make it explicit, that would be nice <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. <vivien>That’s what I mean by “welcome message” <nckhexen>That's the topic. Entrymsg is an extra message (#guix has one). <nckhexen>It may also be that the reason for having +R set has passed. <mirai>tldr; use NEWS to announce field renames & co. instead of spreading deprecation-handling code <pastor>Is it posible to use `substitute*' to replace multiple lines? <NewGuixUser>rekado: Thank you, I'll give those a try now and see if I can figure out any of those new failures <nckhexen>sneek: later tell pastor Sometimes. Depends on the exact requirements & how hacky a result you can get away with. <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 :) <rekado>python38-pytest-asyncio fails its tests, though <rekado>perhaps the old package definition does not respect #:tests? <santiagopim>Well, I suspect 'guix pull' has no possible roll-back, so no listing or switch. Only with version controlling the 'channels' definition, if there is any customization there ... *digging <nckhexen>santiagopim: Why don't --list-generations and --roll-back suffice? <santiagopim>'guix system' and 'guix home' have that options, but for the 'guix pull' there is not. <nckhexen>I'm not aware of any breakage in that area. <santiagopim>Not a bug, just asking. Try 'guix describe; guix system describe; guix home <nckhexen>‘guix pull --list-generations’ or ‘guix pull --roll-back’ no longer working is definitely a bug. <nckhexen>All options listed by ‘guix pull --help’ should work. <nckhexen>All these options & subcommands & profiles can be confusing. <nckhexen>And to your point: I do also recommend keeping your system configuration under version control, like all code. <vivien>And the “base commit”, which is the tip of gnome-team, is marked as “yet to process revision” <vivien>Could someone restart that revision? <NewGuixUser>rekado: I'm running that build now. Is there a reason we couldn't just skip the tests with a transformation on python38-pytest-asyncio? <NewGuixUser>Wait it looks like you've already disabled tests with "#:tests? #false"? <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. <Altadil>Do we have in the documentation some examples of good and bad outputs of guix build --rounds=2 ? I mean, when testing for reproducibility. <rekado>NewGuixUser: that’s right. This 'check phase ignores #:tests?. <rekado>so we’d need to modify this package and delete its check phase directly <nckhexen>Altadil: What kind of examples? (But no, I don't think so.) <nckhexen>Mainly because ‘good’ is identical output, and ‘bad’ is anything else. <Altadil>nckhexen: one for a package that builds reproducibly and an example of one of the types of common failures. I’m very new, so I find it difficult to understand the output of the command. <nckhexen>Altadil: I don't remember what exactly it prints, but all it does is report whether both builds are identical. It does not give hints or report common failures. <nckhexen>Altadil: If you're at a loss for what to do when it reports a mismatch: use --keep-failed, then use diffoscope to compare the two reported store items. <Altadil>nckhexen: I guess I’m missing basic understanding of it then. ^^ <Altadil>It’s telling me about the sucessfull build, as it does without the rounds option, but then prints : <Altadil>The following build is still in progress: <Altadil>and finally shows the path of the package <Altadil>nckhexen: Sorry, I wasn’t clear : I don’t even know if what I am seeing is OK or not <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. <rekado>NewGuixUser: I’m still building pandas… <fnat>nckhexen: oh ok, no prob, I can live with that - good to know I wasn't missing anything major then - thanks <rekado>NewGuixUser: it complains about not having setuptools>=56 <NewGuixUser>rekado: I think mine tried to build importlib-metadata before pandas, at least for me pandas is at the bottom of the "The following derivations will be built:" list <johnwind>happy holloween everyone. I have a question about eBPF and the package bcc. I couldnt import it while using python, does anyone have any experience on setting up bcc ? <rekado>added a new special case for importlib, but matplotlib fails for a similar reason <rekado>(it’s a bit annoying that Guix keeps downloading the replacement sources over and over again) <rekado>(this still fails on matplotlib, but we’re getting close) <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. <nckhexen>I've merged it, but it hasn't showed up yet. <nckhexen>All mentions I find say ‘either version 3 of the License, or (at your option) any later version.’. <nckhexen>Just want to check I didn't miss a ‘version 3, full stop’ somewhere. <jaeme`>Oh, I just checked the LICENSE file of the project repo and it says gpl3, I don't see where it says and later. <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.