<Kolev>This 'guix home reconfigure' is taking FOREVER. <Kolev>rekado: I'm not sure. It might be building Telegram Desktop, yes. <Kolev>rekado: Does "building ... drv" mean actual building, as in compiling source? <ulfvonbelow>What's the Proper Way to simply ensure a directory exists on the root file system in my system configuration? I happen to need a directory that's guaranteed to be empty for something (so something like /empty). <rekado>Kolev: depends on the derivation <rekado>a “drv” file contains what’s called a “derivation” <rekado>it’s a low level representation of “work” to be performed by the guix-daemon <rekado>this can something very simple (like creating a profile union directory) or something very complex (like compiling a package). <rekado>so “All” is not necessary “just to install Kodi” but to do a whole lot of other work <rekado>in cases like this the question to ask is: “why does it need to do that?” and not “why is Guix not faster?” <Kolev>rekado: I know it's doing all this work, but it makes me wonder if all the work is worth it. <Kolev>rekado: Sorry about the frustration. <rekado_>Kolev: I totally understand the frustration. Perhaps it would be less frustrating if Guix had a way to tell us why it’s doing something unexpected. <Ribby>Anyone know about (free) firmware. It appears that I need this after installing the driver. <atomizedalex>I installed proprietary iwlwifi drivers for my wifi card <atomizedalex>But I'm not a wiz with this. I followed the instructions from Daviwil systemcrafters page to install Guix with the Linux kernel rather than the libre kernel, so that it would work with iwlwifi <Kolev>Sigh. Telegram Desktop keeps failing to build. <apteryx>atomizedalex: hello! this channel is reserved to discuss free software; if you are having issues with proprietary software (which is not part of Guix), please seek guidance/assistance in that software space. <atomizedalex>No I'm not having issues. I was responding to Ribby, pointing him to a resource that I used. <vagrantc>shouldn't metter who's a moderator, those are the community expectations in this channel <atomizedalex>Very good and I take that seriously, so I want to know if I've overstepped the limits, as well as who is interpreting that. <atomizedalex>I'm not a developer. I am a PhD in Political Philosophy. <vagrantc>i'm not sure who the moderators are, but it's common for anyone to step up for gentle reminders, which is what i'd guess this was :) <vagrantc>ribby was also asking about free firmware, which kind of need to know for what device in order to help <vagrantc>free/libre firmware totally on topic, at least inasmuch as using it on guix <atomizedalex>There are universal rules, and then rules are applied to concrete instances. This involves interpretation, which varies according to the interpreter. I was asking if what I said did infringe on the limits, and according to whose interpretation. Where is the rule posted? <atomizedalex>The systemcrafters guy has contributed to Guix. Mentioning him seemed natural. ***califax- is now known as califax
<vagrantc>hmmm... tring to find some documentation <vagrantc>though i've definitely read some of that at some point <AwesomeAdam54321>vagrantc: I remember that /topic of this channel stated that proprietary software was off-topic <atomizedalex>I had tracked down that document as you were looking. I think that you were right in interpreting what I said as outside of the limits based on the "License Rules" section, "Information for practical use." <atomizedalex>It would be helpful to have this stated more clearly upfront. <vagrantc>probably worth bringing up on the list at some point <vagrantc>gotta head out for now, but thanks for pointing out something that is either undocumented or at the very least, not trivial to find! :) <atomizedalex>I agree with the aims of the FSF, in general terms, although my academic background leads me to see its approach as a bit Quaker--creating an island of purity with little influence on the political lifeblood of society. That of course means that there is an organizational difference and I might be more at home in a more catholic (universal) community with room for sin. <vagrantc>or even a bug report to bug-guix@gnu.org <vagrantc>yeah, you'll find people in guix who don't even agree with all the decisions, but are willing to work with this great community because of other strengths :) <vagrantc>you don't have to believe or agree 100%, just be willing to understand the boundaries :) <oriansj>atomizedalex: one does not shift a political discussion by compromising core values. <oriansj>and to argue that the FSF's puritan beliefs had little influence on the political lifeblood of society misses a great deal of the political reality of modern software. <oriansj>but I will grant that guix might not hit the global use numbers of Redhat or Ubuntu or Android; but Nix and Guix are going to chance distros forever. In fact in some ways they already have. <atomizedalex>I take your point and I appreciate programmatic points. I also appreciate the work of the FSF and the Guix developers (otherwise I would not have stumbled in here). <MisterMentat>Is gfortran-toolchain supposed to *not* export libgfortran? And if so, what package can I get from Guix to get it? <MisterMentat>After some digging, I found a gfortran installation in /gnu/store that has the libgfortran.so files but they don't seem to be exported from gfortran-toolchain. Is there some way to fix this? I'm new to Guix. (I do know scheme though.) <apteryx>atomizedalex: hello! sorry, I was away for a bit and missed your replies. I think this policy comes from the GNU FSDG yes; and the commitment of GNU Guix to free software in general. <apteryx>to be clear, steering someone toward instructions to install nonfree software is what went against it *apteryx vanishes into sleep <atomicalex>Yes, I understand; it is a central aim to make an operating system without proprietary black boxes. I share the committment, but mentioned nonfree blobs because I incline to jesuitical casuistry (which I won't do again here). <jonsger>how would one write `(mesa_path (string-append (assoc-ref inputs "mesa") "/lib"))` in gexp way? <gnoo>maybe you want: `(mesa_path ,(string-append ...)) <gnoo>or just (list 'mesa_path (string-append ...)) <civodul>jonsger: #~(mesa-path #$(file-append (this-package-input "mesa") "/lib") ...) <efraim>apteryx: yeah, I got webrtc-audio-processing building on all architectures, so that enabled a bunch of builds <mbakke>jonsger: (dirname (search-input-directory inputs "lib/libGL.so")) <jonsger>mbakke: but then I need to find an arbitrary file in the inputs "lib/" folder <jonsger>if that file gets however removed in an update it will no longer work... <jonsger>in that case I just wanna have: /gnu/store/xxx-mesa-x/lib <mbakke>jonsger: I don't think libGL.so will ever disappear from Mesa :) <mbakke>errh, I meant search-input-file above <jpoiret>is GUIX_UNINSTALLED set if and only if we're running guix from a git checkout? <jpoiret>i'll just use ((@ (guix describe) current-channels)) == () instead <rekado_>jpoiret: it’s only set by pre-inst-env <rekado_>jonsger: which part exactly is giving you trouble? <rekado_>the snippet you posted would work even in the context of a gexp <rekado_>do you want to use this-package-input and the like? <jonsger>rekado_: I tried to use the new style in (inputs) and (native-inputs), then it complains about that stuff in '("pulseaudio" "mesa"), not being a string or returning #f <jonsger>need to recompile and see the backtrace... <rekado_>you can shorten the loop by adding a build phase to the very beginning <rekado_>you don’t need to wrap anything yet; if it’s just about accessing the inputs then that should work just fine in a phase before 'unpack <vldn>civodul: are there manpages for the guile-sqlite3 module? <vldn>or some examples somewhere? <civodul>you can find examples in Guix though ***ft_ is now known as ft
***darosior3 is now known as darosior
<mbakke>would it make sense to expose native-inputs to builders even when not cross-compiling? <mbakke>then tricks like f97fe92b570b01ed1b03abd4f3ec89bf20ebc9db could be performed on the build side <gnoo>hello, looks like the pandoc package doesn't have pandoc manpage <gnoo>man pandoc -> No manual entry for pandoc <civodul>mbakke: like passing #:native-inputs to build phases while leaving #:inputs unchanged, right? <civodul>it's conceptually kinda confusing maybe <mbakke>civodul: indeed, #:inputs would behave the same as now, but builders can access #:native-inputs if they want. <mbakke>not sure if native-inputs is any less confusing today <civodul>i guess we should give it a try and see if there are corner cases or unintended consequences <civodul>it's true that those (or native-inputs inputs) bits aren't pretty :-) <vldn>mhh what for is the nix-daemon still used in guix? just for generating the hashstring+drvfile and navigating/creating the build processes? i mean the database api in guix store database is quite nice @ civodul, shouldn't be so hard to write a daemon replacement with guile-fibers or am i wrong? <vldn>maybe someone knows in which specific place/file the nix-daemon is called from our guile scripts? <sughosha>Hi, I have few questions regarding the Guix package manager. I would appreciate anyone for the help. <sughosha>1. Is there a way to list system-wide installed applications? `guix package --list-installed` lists only profile's packages. <sughosha>2. Is it possible to list files of an installed application? <vldn>guix package --list-installed --profile=/run/current-system/profile @sughosha for your guix system config.scm installed packages <Rodon>hi i am interested in installing guix on debian 11.. what is minimum size after guix -pull ? i want to start with minimum.. <vldn>and you can look at the dependency graph for your second question sughosha <vldn>guix graph PACKAGE | dot -Tpdf > dag.pdf something like this <vldn>or with xdot installed: guix graph PACKAGE | xdot - <civodul>vldn: you're right, but the devil is in the details :-) <civodul>there's a branch with a preliminary daemon rewrite in Scheme <vldn>ah sughosha maybe try guix size instead <civodul>and the goal is to do that, but the project is currently dormant <vldn>then you don't need extra tools :) <vldn>yeah already saw that and wanted to contribute or write a new one but had a hard time finding the right files to know what the nix-daemon is used for <vldn>so just this two use cases? Hash+drv into Sqlite and Buildjob management? <sughosha>vldn `guix size PACKAGE` shows the dependencies list. I wanted to list the files of the package. Anyway thank you. <vldn>then you have to cd inside your package like /gnu/store/nwi7az05ikkvnfbbkda62s4156z6rs68-wine-7.0 and make a good old "ls" :) <vldn>maybe there is some nicer way but don't know <vldn>but don't manipulate files there <sughosha>vldn Yes, but it's bit difficult to get the store link, currently I am using `find` command but it is slow. <vldn>/gnu/store should be untouchable <vldn>guix size is comparable slow too but shows the right path <gnoo>sughosha: readlink -f "$(type -p <package name>)" <vldn>should make that as an alias :D <gnoo>not the package name but the binary name <sughosha>gnoo Yes you are right. Thanks! I don't know how it functions but it worked :) <vldn>and it would be a nice addition to the guix cli or am i wrong? <gnoo>cdpack() { local path; path=$(readlink -f "$(type -p $1)"); echo "$path"; cd -- "${path%\/*}/../"; } <gnoo>a better function, cds to the path, should probably check for errors there <sughosha>vldn It would be nice to add it to guix. Some package managers like `apk` and `pacman` provide options to list the installed files. It would be really good addition to guix. <gnoo>sughosha: yeah, that's an option i really miss. void has an interesting solution to it, they have a git folder listing all the outputs of a package and provide a script that searches that folder <gnoo>so you just do xlocate /bin/emacs and it'll give you all the packages that have /bin/emacs in it's output <vldn>two more guix cli arguments, get the /gnu/store/path and one to list the files in it, maybe with an additional flag <sughosha>vldn Yes, these two options would come handy. <mbakke>sughosha: you can do 'find $(guix build package)' to list the contents <gnoo>still, you don't know which package provides a certain binary <sughosha>mbakke I was thinking that `guix build` would build a package, but it just shows the path! Cool. <gnoo>it builds the package if it's not already built but prints the path if it is built <sughosha>Yes, as gnoo said, querying which package owns the binary would be very useful. <sughosha>Actually, I am trying to build `geary`. It shows `messaging-menu` as missing dependency, but I don't know which package provides `message-menu`. <gnoo>if it uses pkg-config, that should tell the general name of package. maybe messaging-menu is a package in itself that's not on guix yet? <sughosha>gnoo Just now I noticed that `/gnu/packages/gnome.scm` doesn't include `pkg-config`. <sughosha>I think no one issued a bug for this (or at least I couldn't to find one in issues.guix.gnu.org) <gnoo>probably because it's a virtual package i.e. it itself doesn't have anything <gnoo>try 'guix edit gnome' and see that it is just a big list of propagated-inputs <zimoun>Giving a look at the GHC new bootstrap by rekado_, I notice that gcc-toochain@4.8.5 does not build. <sughosha>hm. I need more experience to understand them better. I just started using Guix this week but learnt so much from the manual and this community! <sughosha>I think the best way to understand Guix is to learn Guile or Scheme and then read the default .scm files. <rekado_>zimoun: yeah, GCC 4.7 also doesn’t build <rekado_>jonsger: can you show me the complete package definition please? <rekado_>I need to know where you’re using gexps and what the full expression looks like (what parts are quoted and how) ***dgcampea-2 is now known as dgcampea
***daviid`` is now known as daviid
<attila_lendvai>how is the release-monitoring-url property used? is it something that i can run locally? or is there a regular report published somewhere? <attila_lendvai>i have a channel, and i'd be happy to get notifications at new upstream releases... <attila_lendvai>AwesomeAdam54321, but doesn't `guix refresh` work even for packages without such a property? by guessing it? <rekado_>attila_lendvai: it doesn’t guess. There are defined updaters. <rekado_>e.g. in (guix import cran) see %cran-updater and %bioconductor-updater <civodul>release-monitoring-url is for those packages that get updated by the "generic-html" updater <roptat>you could check that the packages in your channel have an updater, and then set up a cron job to run guix refresh regularly <roptat>you'd get notified by email of the result <apteryx>civodul: there's actually some caching going on for nginx; see the %extra-content variable in hydra/nginx/berlin.scm <civodul>apteryx: oh indeed! there's a cache for nars, but not for narinfos (which is important, so that "guix publish" can have its LRU policy) <apteryx>I cleared it yesterday; so now it's testing our fresh new copy of substitutes under /var/cache. <apteryx>(or rather, rebuilding its cache from the new /var/cache/guix/publish nars) *roptat is running guix refresh -t opam again... <char[m]>just the one I can use at command line <roptat>looks like we have enough OCaml packages that I need to run it regularly <roptat>if you already have it you can try "ls /gnu/store/*/bin/dlopen" <char[m]>jpoiret: maybe I am looking for the c function then ... <jpoiret>the c function should be provided by ld.so, so I think it should be ok to use in any program compiled with gcc <roptat>the c function comes from the libc I think <jpoiret>right, it's in libc, standardized by POSIX <char[m]>roptat: for cffi to find shared libraries <roptat>then I think it's more likely you're looking for the C function <char[m]>thanks, I think glibc worked for me. <rekado_>roptat: I do the same for R packages regularly <rekado_>maybe we should automate this some more <roptat>that's a bit difficult for ocaml, because the source is usually not correct <roptat>I mean, it's usually a github tarball <roptat>so I often change that manually to a git checkout <roptat>I'd appreciate any effort in that direction though <rekado_>perhaps we can use the github API to retrieve the corresponding git commit <roptat>I'd have to guess the github URL :p <roptat>although, it's usually the package's home-page <roptat>oh but it's part of the source URI anyway, I'm stupid <roptat>mh, coq isn't going to be fun to update ***Noisytoot_ is now known as Noisytoot
<katco>hey guix friends! i'm trying to get a libvirt service to listen on a tcp socket. the docs for `listen-tcp?` say "You must set listen for this to have any effect.", but i can't find a `listen` parameter, nor a way to start libvirtd with `--listen`. any ideas? <civodul>katco: hello! i think it's actually 'listen-addr', no? <katco>civodul: hm, no i don't think so? that just tells it what address to listen on, but there is a `--listen` flag that enables listening at all <katco>i.e. https://libvirt.org/remote.html " Note: it is also necessary to start the server in listening mode by running it with --listen or adding a LIBVIRTD_ARGS="--listen" line to /etc/sysconfig/libvirtd." <jpoiret>mhmmm, i need some help on the guix bootstrapping process <jpoiret>in build-aux/build-self.scm, we explicitely don't select (guix channels), but it is still somehow ends up inside the build environment of the derivation <jpoiret>i say that because i added some code to (guix channels) that requires (guix git), in turn requiring (git object) which isn't available at this stage <civodul>katco: oh, so could it be that we're just lacking that option? <civodul>i've never used this service, so i'm just trying to guess :-) <katco>civodul: i looks that way, but i wanted to check before i submit a bug! <katco>in the meantime i'm wondering if i could work around it by passing a script into the service for its `libvirt` package <civodul>i don't see an easy way to do that :-/ <civodul>jpoiret: weird, you'd have to find out where that (guix channels) come from; you can add pk calls in there :-) <katco>hm, yeah, maybe this won't work. you can pass in the libvirt package to use, but there's more than the shepherd service's forkexec using that. <jpoiret>civodul: alright, it's definitely my fault (added a ref to (guix channels) in (gnu packages package-management)) <jpoiret>it still seems weird that guix/channels.scm is included in the source though <mbakke>Clang crashes while building the new version of ungoogled-chromium and dumps a neat reproducer; but it does not crash when running the reproducer interactively in 'guix shell' <jpoiret>setting %load-hook helped a bunch hehe ***daviid` is now known as daviid
<civodul>jpoiret: %load-verbosely is "nice", too <civodul>mbakke: it's great that it emits a reproducer, though; good intent <jpoiret>quick question, why do we take care to use source-module-closure when right at the beginning of the build script, we basically do (set! %load-path (cons source %load-path))? <civodul>these are two different things: with-imported-modules ensures that in the derivation's environment we have all the Guix modules from the host Guix <civodul>and then setting %load-path allows us to make sure we load the right modules <jpoiret>more pragmatically: won't the (use-modules (guix self)) try to load the self from source rather than from the imported modules? <jpoiret>i think i've pinpointed the issue: compiled-guix tries to pass a daemon to whole-package, which it gets from (gnu packages package-management), hence why that file ends up being loaded <jpoiret>although setting %load-hook shows that _a lot_ of (gnu packages ...) modules are being loaded <efraim>civodul: I looked at (guix cpu) again for aarch64, not all the values from /proc/cpuinfo are being read it seems <whound>Can anyone give tips on making Sonic-Pi package def ? <efraim>civodul: I think I found it, stopping the loop at flags on x86_64 works, stopping at Features on aarch64 doesn't work since CPU implementer is after it <efraim>I got it looping over all of /proc/cpuinfo, now I have the CPU implementer and CPU part, time to get the actual sorting down! <leinad>Hi Guix! Today, I have noticed the following message just before gdm shows the login screen: localhost elogind[364]: elogind is already running as PID 354 <leinad>Is this expected behaviour? Seems like elogind is started twice. <acrow>If anyone wants to harvest, what I think, is the low hanging fruit of bug#53908, I am openly lurking here. <lilyp>"all-jar" sounds suspiciously like "we're bundling all our dependencies into this thing" <jpoiret>leinad: what architecture are you running on? is your computer using a SSD or HDD? <leinad>jpoiret: A 256GB NVMe SSD on x86_64 <acrow>I could find no existing package that included everything that was required. <jpoiret>it's a known issue, but I thought it would cause actual errors <jpoiret>can you check that all services are properly started with `sudo herd status`? <acrow>Batik is, after all, a toolkit for other things. I hope the all-jar may be used by others. <leinad>jpoiret: All services are properly started, except for term-auto, this one is stopped. <jpoiret>well, if everything works fine, let's just ignore that <leinad>Yeah, it works fine :) I just have the impression it steals a second or two of my boot time <leinad>and was wondering whether I can do something about it. <jpoiret>we start elogind manually rather than on-demand through dbus, and maybe there's a race between elogind registering to dbus and someone else asking for elogind on the dbus, leading to dbus trying to start it (again) <jpoiret>although we haven't yet been able to see which program is the culprit <acrow>leinad: I was able to avoid that message by putting elogind-service and the ssdm login manager together with xfce in my system configuration. The problems went away albeit because I had the flexibility to just make some different choices. Still, maybe there is a clue in there. <leinad>I see... so maybe it's gdm itself which causes the race <jpoiret>most of the shepherd services that rely on elogind should wait until it's fully started (written its pid file), and that happens after elogind registers on DBus <acrow>leinad: that is kinda what I concluded but wasn't able to troubleshoot. <acrow>jpoiret: I think those timing issues are difficult to resolve for all systems. <jpoiret>looks like gdm-shepherd-service just doesn't have elogind as a requirement <acrow>What if gdm triggers the dbus startup of a elogind that is already in the middle of startup? <leinad>jpoiret: perfect! thank you very much <jpoiret>we can wait for elogind to be fully ready by simply having the shepherd service depend on elogind being started <lilyp>I don't think shepherd is smart enough to enforce itself upon dbus yet (which is the main difference from systemd) <leinad>lilyp: What does that mean wrt. this issue? <leinad>cool... I could apply the patch and test it with my system <jpoiret>sddm does in fact require elogind, so that's why it worked better :p <jpoiret>well, if you know how to do that, go ahead! <jpoiret>for some reason, I don't see that on my own system (maybe it's slower, who knows) <acrow>jpoiret: I doubt that slower system claim. :) <acrow>jpoiret: sounds like it has some character. <vivien>guix shell pkg-config glib --container -- pkg-config --exists glib-2.0 && echo ok <vivien>guix shell pkg-config vips --container -- pkg-config --exists glib-2.0 && echo ok <vivien>Why does the first command prints ok and not the second one? <vivien>guix shell pkg-config vips --container -- pkg-config --exists vips && echo ok <acrow>vivien: I am guessing it is because the instatiation of vips doesn't include glib-2.0. <acrow>s/instatiation/instantiation/ I hope. <ryanprior[m]>I'm having trouble with direnv installed via Guix on a foreign distro (my elementary OS laptop): when I try to run direnv it fails with an error like libc.so.6 - version not found <vivien>Thank you acrow, it seems that I have a lot of libs to find! <ryanprior[m]>But if I run `guix shell -C direnv bash coreutils` and then run direnv, it works fine. So it seems like direnv is picking up something incompatible from the base OS instead of from my profile? <acrow>vivien: I got the same outcomes you did. Using guix size you can see that vips does reference glib-2. pkg-config may not dwelve deeply enough in a guixy world, no? <lilyp>ryanprior[m]: `which direnv` normally? <ryanprior[m]>lilyp: `readlink $(which direnv)` reports the same store path inside & outside the container <ryanprior[m]>However, `ldd $(which direnv)` reports slightly differently inside vs outside. <acrow>vivien: vips certainly appears to reference many libraries. <lilyp>is that guix' ldd or foreign ldd? <ryanprior[m]>Inside the container it's Guix's ldd, outside the container it's foreign ldd <ryanprior[m]>If I explicitly use Guix's ldd outside the container, it gives me the same behavior as I get inside <lilyp>/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f01e149d000) WTF is the linker doing here? <lilyp>it already has an absolute path, so ??? <vivien>TFW a trivial package requires a huge package like pyvips for its tests, you package it, only to realize that the developer took it as an example of package that should NOT be present <Kolev>Using Kodi as a DLNA server because I can't figure out minidlna on Guix. On Ubuntu, it's easy. <leinad>jpoiret: I applied the patch, had no problems building guix. I am reconfiguring my system tomorrow and will report on #53926. Thanks, folks :) *Kolev runs `guix pull` to warm his hands <jonsger>rekado_: it's a non-FDSG compliant package, so I obviously can not share the whole package definition... <tanner40>Guix System newbie here - I see in my `/var/guix/profiles/per-user/me/` directory several symlinks with the prefix `current-guix-` and several symlinks with the prefix `guix-profile-`. What is the difference between these two types of profiles? <jackhill>tanner40: hi, welcome to Guix! the current-guix- ones are what gets updated when you do a `guix pull` to get new package definities and guix code. The other one is for software you've installed with Guix e.g. with `guix install`. <acrow>lilyp: I see how eternal vigilance is the price of liberty. Guix facilitates virtually limitless manipulation of the build process. <tanner40>jackhill thanks! so does that mean guix itself runs in an environment defined by a current-guix- profile, and that all other software runs in an environment defined by a guix-profile- ? <acrow>lilyp: The batik-all-jar was derived entirely from the Apache batik source package. I modified the build so tha the default guix ant build system target, 'jars', would yield the provided ant build target, 'all-jar'. <vivien>My python package sanity-check phase fails with: validating 'pyvista' /gnu/store/fk2k9iivcyyr90rc3nfvf93j5j78hysf-python-pyvista-0.33.2/lib/python3.9/site-packages <vivien>...checking requirements: ERROR: pyvista==0.33.2 DistributionNotFound(Requirement.parse('vtk'), {'pyvista'}) <civodul>vivien: i think it means that your package needs pyvista at run time and that it cannot be found <Kolev>Is there a way to tell Guix to not compile stuff? <civodul>vivien: ah, then it must be vtk that's missing :-) *civodul performs fuzzy matching on error messages <vivien>civodul, I don’t understand, I have vtk as a propagated input and it should be sufficient <civodul>Kolev: in what sense? it compiles only when it can't find pre-built binaries (substitutes) <vivien>civodul, what is DistributionNotFound and Requirement.parse? Is it guix-specific? <vivien>I guess it comes from a file named "sanity-check.py" but I can’t find it <vivien>OK the problem might be that vtk doesn’t install a distribution file