IRC channel logs
2023-04-21.log
back to list of logs
<ryan77627>Awesome, I will try that. For future reference for myself, how would I go about finding things (like these variable names I always see in docs) out so I don't need to come and ask every time, I'm trying to learn the system :) <bjc>i use ‘guix search’ to find them, although that only shows packages, you can see *where* they are defined, and then search through that file <bjc>there may be better ways <Guest31>when you do "guix edit gcc@12" it points you to the package definition and you can see the variable name for the version <ryan77627>I see, thanks for the help everyone! I'm slowly learning the ins and outs of guix ^-^ <bjc>it just occurred to me that i should be doing this work on top of the ‘rust-team’ branch, and now i want to cry <podiki[m]>wow python-numba is a long test suite (build is short) <RavenJoad>I am migrating from msmtp's old msmtpqueue scripts to its new msmtpq and am having trouble figuring some things out. Does someone else here use msmtp and msmtpq who would be willing to share their config(s) with me? <RavenJoad>Something Nixpkgs has that I am not sure we have in Guix is a program/scripts that builds all dependent package updates. Meaning if I update something, I can run the script to build all packages that would be affected by my update. Is there something like that? <cbaines>RavenJoad, guix refresh --list-dependent <bjc>ugh. hit a wall and need rust 1.61 at least <lfam>Let me know if you have any specific questions <spiderbit>pfff that is still so dumb... when I want to use the stumpwm-screenshop package, instead of (load-module "screenshot") <spiderbit>I still have to set 4 paths to common lisp packages <spiderbit>I know there are some big solutions to use quicklisp, but why would I want to use a 3rd party installer in guix when the packages I need are there <spiderbit>It's so strange to have this problem in THE lisp linux distribution :D <spiderbit>I am pretty sure in 99% of all other distributions that just works <AwesomeAdam54321>oriansj: Should a guix AI model package be trained or should it just be an opaque pretrained one obtained elsewhere? <podiki[m]>do you have sbcl in the same profile installed? it should find via that search path I would think, but there was some message/bug report about this we should sort out if true <flora1[m]>"I'll teach 10individuals how to earn $100,000 in 72 hours from the crypto market. But you will pay me 10% commission when you receive your profit. if interested send me a direct message by asking me (HOW) for more details on how to get started <oriansj>ideally such that people can specify their own desired training set if they so desire <podiki[m]>spiderbit: add sbcl to your profile, then xdg_data_dirs will have those paths and i think that's all you need <bjc>these crate modifications are endless <bjc>i cannot believe how long i've been doing this <AwesomeAdam54321>bjc: If you want, I could send you my patches of trying to get antioxidant-build-system up to date <bjc>i'm already neck deep. maybe even further. i'll try to finish this up the old fashioned way <bjc>but for sure, i'm not touching another rust package without something like antioxidant. this has been a miserable experience <spiderbit>(specification->package "sbcl-stumpwm-ttf-fonts") <spiderbit>that is not enough I have to explicitly do the same fro sbcl? <RavenJoad>lfam: I have a working msmtp config. I can send emails fine. I am interested in getting msmtp's mail queuing scripts, msmtpq, to work. <spiderbit>I can't even really test easily my system profile <podiki[m]>wherever you have installed stumpwm and related stuff; I use different manifests and profiles, but just needs to be in the same one (user, system etc.) <spiderbit>hmm but it installs stumpwm as dependency and that is not enough? <podiki[m]>it is okay to duplicate and have stumpwm and friends in your user profile as well, for instance, so you don't need to do a system reconfigure all the time <lfam>RavenJoad: Looks like I'm using msmtpq and didn't even realize it. I set it up years ago. It just works for me when invoked by mutt <spiderbit>I think it works now, use the nonguix with firefox and kernel and had no substitute so it tried to compile <podiki[m]>no, not in the sense I think you are thinking <podiki[m]>stumpwm depends on sbcl so it will have it available to use, but it doesn't put it in your profile <spiderbit>ok if that works I am happy... is that some general rule, for all sorts of interpreters <spiderbit>that I have to install it explicitly to have imports working <RavenJoad>lfam: Ok. May I see your muttrc config then? I am trying to adapt my mu4e config. <spiderbit>also question try to find out how xterm would change the title when I change the path, currently the title is fix "xterm" not only the class that is "Xterm" but .bashrc is some link probably because I use homeconfig <spiderbit>now do I have to hard restart stumpwm to make it aware of the paths I assume? <RavenJoad>lfam: Do you have any MSMTP environment variables set? <podiki[m]>spiderbit: yes to the question of modules; e.g. just python-<some pkg> doesn't give you the search path for python to find the module, so generally you want the tool/compiler/etc. and the modules together <podiki[m]>as for your other questions I don't follow, sorry; and need to run <spiderbit>podiki[m] ok would be really nice I even wrote my own rofi-stumpwm window switcher because I could not got ttf-fonts for stumpwm included <RavenJoad>spiderbit: Part of the reason StumpWM behaves a bit strangely when loading the stumpwm-contrib modules is because StumpWM's *module-dir* variable is set to $(pwd)/.stumpwm.d/modules at build-time. The $(pwd) expands to /tmp on a running system. That is something I wanted to tackle long-term. <spiderbit>would be nice to see that in the wiki or was it cookbook <lfam>RavenJoad: No environment variables set that contain 'SMTP' <RavenJoad>Neither. It is a behavior of StumpWM that I tracked down a while back. You can use the set-module-dir function with a string argument with the path to the stumpwm-contrib modules on your system. <podiki[m]>oh for modules I use a local git checkout anyway, so maybe my advice before doesn't help for that <RavenJoad>lfam: Ok. I guess I might be over-complicating my mu4e config for queuing then... <spiderbit>that's when you adapt stuff to your format :D <podiki[m]>but generally for something like sbcl or python to find modules it needs to be in a profile together <lfam>RavenJoad: I'm sure there are other people here using mu4e + msmtpq <podiki[m]>ACTION has to be off, will push more python core-updates fixes later <RavenJoad>spiderbit: I intend to eventually get around to getting the stumpwm-contrib packages composed with regular StumpWM in such a way that you specify both and a /gnu/store path is used instead of /tmp for *module-dir*. <RavenJoad>lfam: Probably. I originally wrote my config on OpenSuSE and NixOS using very old versions of the software stack. Currently bringing a 3 year out-of-date config back to life for future-proofing. <spiderbit>ok restart-hard killed stumpwm have to logout for a sec <RavenJoad>spiderbit: Yeah. Tinkering with Stump in Guix without setting *module-dir* with set-module-dir is difficult at best right now. <spiderbit>or is there a easy solution to have xterm change it's title to not be statically "xterm" <spiderbit>well have to downgrade tomorow to kernel 5.15 because probably it somehow killed s3 suspend outside of gnome <spiderbit>see ya thanks for the information anyway, even it did not work today <RavenJoad>spiderbit: About XTerm, there is the -T and -n flags. Both are documented in the man page for XTerm. <spiderbit>yes but that set's it that doesn't describe the mechanism the probably bash code to do it dynamically <spiderbit>and the main problem I have is that .bashrc is a link to system <spiderbit>but even if I want to change that it's a link probably because I use guix home-config <spiderbit>sorry I am tired if I go on I might get a bit frustrated and impatient... again thanks anyway <RavenJoad>PS1 is the prompt printed by the shell. The terminal emulator itself can also have a title. Sometimes the title of the terminal is the prompt of the shell. <spiderbit>well the point is it should change not stay fix <spiderbit>so opening xterm with a parameter doesn't help for that <spiderbit>xterm -xrm 'XTerm.vt100.allowTitleOps: false' -T windowname <spiderbit>that seems to deactivate this behaviour so in other words <AwesomeAdam54321>Is there a way to use find-files to only find files one level deep in a directory, and not recursively? <podiki[m]>apteryx: are you familiar with python-llvmlite? there's a phase to fix the libllvmlite.so loading but i'm not sure how to test it. seems to build fine and python-numba passed its long test suite <podiki[m]>so i'm thinking to remove that (and the fix test phase since that passes for me too) and update it to python-numba and dependents will build <zacchae[m]>Alright, I am satisfied with my initial setup of guix home on my Librem 5. There were some hiccups which have been addressed. I think it's a good starting point for others. <zacchae[m]>Is there a good place for me to put a guide detailing what I've done? <zacchae[m]>If I send a guide in an email to help-guix@gnu.org, will people be able to find it? <ChocolettePalett>Well, I found some useful stuff in those emails, but only because it was indexed by search engines <podiki[m]>cuirass doesn't seem to be building x86_64 right now...hopefully comes back soon, there's a bit of a back log now; night guix! <rekado>very close to fixing tensorflow on core-updates <rekado>but there are still problems with create_python_api.py <andreas-e>What is the relationship between tensorflow and tensorflow-lite? They are at different major versions. <andreas-e>rekado: ci.guix.gnu.org has apparently disappeared. <andreas-e>Oh, it looks like only I am blocked from ci.guix.gnu.org because my restarting of builds was considered a DoS attack! <dds>hey guix hackers. would you say that it is efficient in the long term to fully learn and use the standard emacs keybindings or is evil better? i feel evil mode brings too many inconsistencies with the rest of emacs, even with evil-collection. what do you think? <ngz>dds: I think Evil is evil. Nuff said. ;) <ngz>"guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out" :( Builds on powerpc64le are failing on CI. <evilsetg[m]>I think evil is great and after a while of adapting it works really well with everything. I never learned the standard keybindings though. In the I landed in a spot somewhere in between using only emacs or only evil bindings, so it's kind of a weird miz. But for me that is fine, every emacs config is unique anyways. <tribals>I'm trying to set up build offloading to another machine. Actually, I'm having two - one is cloud provider and one is my personal hardware. Cloud runs Guix System, and personal one using foreign distro installation. I set up cloud machine to become offloader successfully, but can not to the same to personal one. <rekado>andreas-e: tensorflow-lite is for inference on mobile devices <ngz>nutcase[m]: Maybe guix shell --with-latest=maven-pom maven-pom -- ... <ngz>I meant --with-latest=maven-pom maven -- ... <tribals>I'm getting error like 'Failed to execute `guix repl ...` - file not found <tribals>As I'm understood this, it is because there is no `guix` in path while connecting over ssh through sudo. But the problem is that I don't understand what to fix - guix, sudo or ssh. <nutcase[m]>ngz: I get "guix shell: warning: could not determine latest upstream release of 'maven-pom'" :-( <evilsetg[m]>@tribals Can you use guix if you just ssh into the cloud machine? You should not need sudo to use guix once it is installed. <tribals>There is no problem with cloud machine <ChocolettePalett>> <@nutcase:matrix.org> ngz: I get "guix shell: warning: could not determine latest upstream release of 'maven-pom'" :-( <ChocolettePalett>You could try inheriting the package or even writing your own definition for a newer one <ChocolettePalett>I'm not sure it'll work though, I've installed GNU Guix (the best linux distro) as early as today <tribals>So, I set up offload machine with my own user account. Meaning that when it tries to offload build, it does roughly this: <tribals>`ssh offload-machine guix repl -t machine`, with my own user <andreas-e>ngz: ci.guix.gnu.org is maybe a bit slow, but reachable, <andreas-e>Have you got a link to a build that fails unsuspectedly on powerpc64le? <ngz>andreas-e: Sure, let me see… <andreas-e>Ah, missing derivation; that is a known bug in cuirass... <andreas-e>The only way I know how to correct this is building the package on the berlin by hand, then restart the build on CI. <andreas-e>Too much work to do for all of them! The other day I started a script for the emacs-* packages, but gave up when it ended up trying to recompile failing packages over and over again. <ngz>OTOH, building an Emacs package from source is usually almost as fast as downloading a substitute. <andreas-e>Yes, it is probably not a big problem for the users. But it shows more red than needed on the dashboard. <ngz>mekeor[m]: Thanks! I'm just a chan away from my previous place. :) <ffrrnn>I will learn you soon, but until then, I have a question: Does guix maximize library reuse, or are all installations of packages independent of each other, still? <ngz>ffrrnn: Packages depend on their inputs. If two packages have the exact same input, they will share it. If they share no input, they will be independent. <ffrrnn>Does guix, in this regard, avoid all forms of dependency looping? <ffrrnn>ngz: Just in the sense that an output causes the analysis of its inputs, with a memoized tree allowing the algorithm to avoid unnecessary remaking. <ffrrnn>Perhaps I don't mean looping, either. I mean instead that dependencies are not singular, and that instead, different dependencies that would normally be shared on a system can coincide--is that right? Does that mean that every package must be very carefully specified for that sake? <ngz>AFAIU, there cannot be dependency looping because all inputs have to be resolved before building. If an input is already built, it isn't built again when another package depend on it. <ngz>ffrrnn: Have you looked at a package definition already? It may answer some of your questions. <rekado>fixed tensorflow on core-updates, but I think this is a fool’s errand in the long run <rekado>we accumulate patches to make it work with numpy, Python 3.7, 3.8, 3.9, and now 3.10, GCC 11, etc <rekado>and I have less and less trust in the result <rekado>it’s about time we package bazel and upgrade tensorflow <nutcase[m]>> <@chocolettepalette:matrix.org> You could try inheriting the package or even writing your own definition for a newer one <nutcase[m]>> I'm not sure it'll work though, I've installed GNU Guix (the best linux distro) as early as today <mirai>apteryx: nice followup to the docbook-xml changes <mirai>are those all of the packages that monkeyed with the xml files? <mirai>sidenote, we probably should fix the “conflict in profile” thing <mirai>so that multiple docbook-xml packages can be active <ngz>mekeor[m]: I meant an IRC channel. <mirai>technically if libxml2 is added as an input you also forego having to explicitly set XML_CATALOG_FILES env var <andreas-e>rekado: Congratulations, these are good news! <ardon>Hi Guix, is there a way of having a local channel not use an absolute path? I want to use a single channels lock file in two foreign distro guix home installations but each one has different usernames. I found no way of specifying a relative path with file:// to point to the local channels <nutcase[m]>ChocolettePalette: Thanks, I'll have a look into it <ChocolettePalett>Are there only 3 cursor theme packages in GNU Guix? At least it's all I found on packages.guix.gnu.org <mekeor[m]>ardon: isnt a channels file just scheme? if so, you could just write some scheme... <apteryx>mirai: re docbook monkeying, yes :-) <blacktoad>Hello Guixers. I built Guix from source code. Then when I run "make clean-go" I get this message: "warning: stray .go files: guix/build/po.go". Is this .go file supposed to be deleted like the others? <mirai>apteryx: nice! thanks for doing the S&D phase of the plan <apteryx>yw, it had been annoying me for a while, thanks for fixing it! <gabber>i'm facing challenges with setting up my childhurd setup. i've set it up according to the blog post but now `guix build git -i i586-gnu` fails building openssl -- it doesn't offload correctly. also: `ssh childhurd` does not work as described in the blog post. do i have to add an entry to my /etc/hosts for that to work? i can connect to the machine when specifying identity file and port manually <apteryx>mirai: 'conflict in profile' seems a bit niche; most projects should focus on using a single version I guess <apteryx>but if you have an itch to scratch, a fix would be welcome <mirai>oh, it's mostly so that it will work within a guix shell (for authoring, etc.) <mirai>sure, I'm not too familiar with this area but it seems doable <mirai>is it only docbook-xml package that needs tweaking or does it involve libxml2 as well? <apteryx>just docbook-xml I think; the search path seems written in a way that would still work <andreas-e>blacktoad: I also see this and usually remove it; but I think it is harmless to keep, and it will be recreated if something changes. I think we should add it to a Makefile somewhere. I will file a bug. <andreas-e>Most of the time the warning refers to .scm files that have been removed; then keeping the .go file also does not hurt, but it may as well be removed by hand. <mirai>apteryx: where can I read more about this ”conflict in profile” thing (how do they work and what's going wrong with the current docbook package?) <mirai>or perhaps a package that I can use as an example? <mirai>sidenote, the good thing with the fixed catalogs is that we now have a better chance at getting shared-mime-info updated so that AVIF, AV1 and other file types will actually work on guix <apteryx>mirai: profiles are a union-build of all the packages' files joined <mirai>since the pixbuf stuff (and possibly other things as well) rely on the mime database to know how to handle the files <apteryx>if two files share the same file name, they conflict, and the first one takes precedence <gabber>nvm, i think i found (some of) my mistakes <apteryx>this morning's offload problem is: guix package: error: corrupt input while restoring archive from socket <apteryx>it tries to send a lot of sources over the wire to be built <mirai>apteryx: the file name portion in “/gnu/store/k08003hgs8wkc86zf08azr4447784wla-docbook-xml-5.0.1/xml/dtd/docbook/catalog.xml” is “xml/dtd/docbook/catalog.xml” right? <apteryx>has anyone looked at the freerdp failure? <mirai>the search-path thing works recursively right? <mirai>ok, I'll send in a patch for it in a bit (with CC) <wdkrnls>Dear Guix, can you help me understand what is the state of Go on Guix? I chose a Go program for my backup tool, but have noticed Guix's version is really old. <apteryx>probably just updating freerpd must do it <wdkrnls>From what I saw some people have tried to update it, only to give up since Go seems to zealously download files from elsewhere. <wdkrnls>I saw in the Reproducible Builds report that Go reproducibility itself will be improved in upcoming versions. <wdkrnls>However, from reading it wasn't clear to me if the issue of downloading files within the builder was actually resolved. <attila_lendvai>is it expected that i get a lot of substitute downloads at the end of a sequence of: guix system reconfigure, guix gc, guix system reconfigure? (config unchanged) <andreas-e> attila_lendvai: Yes, I have also been surprised by it. <nflqt>Hello. I would like to report a weird thing on the french installation instructions. Can I write in my language? <andreas-e>wdkrnls: I would not say that there is an "issue of downloading files within the builder". It is not possible, period. All inputs to a package need to be specified in the recipe. You cannot have functional package management when downloading random stuff. <andreas-e>nflqt: Bien sûr, si tu es prêt à baisser tes chances d'une réponse. Peut-être qu'il serait utile de faire un rapport de bogue le cas échéant que quelqu'un de l'équipe de traduction peut traiter. <andreas-e>attila_lendvai: This may have to do with grafts again. You install grafted packages, then "guix gc" removes the ungrafted ones; when you pretend to install the same again, Guix does not see that they are the same until the ungrafted packages are downloaded again, and maybe regrafted. <nflqt>andreas-e: I just checked. The passage I do not understand is also in the original version (English). (Translated with LibreTranslate.com) <nflqt>"$ gpg --verify guix-system-install-1.4.0.x86_64-linux.iso.sig" should be "$ gpg --verify guix-system-install-1.4.0.x86_64-linux.iso.sig guix-system-install-1.4.0.x86_64-linux.iso", isn’t it? <andreas-e>Ce n'est pas nécessaire. Normalement quand gpg voit une signature détachée, il cherche lui-même le fichier (et prend le même sans le suffixe .sig ou .asc). <andreas-e>J'utilise toujours la première commande, je ne suis donc pas 100% sûr, mais je pense que les deux sont équivalentes. <nflqt>Effectivement andreas-e ! J’avais mal interprété la première ligne de GPG. <nflqt>andreas-e: En tout cas, je comprends gpg vérifie l’authenticité de l’iso. Vérifie-t’il également son intégrité comme le ferait un md5sum ? <gabber>nflqt: no, it verifies whether the iso was really created by one of the people you have obtained a public key from <andreas-e>Si, une signature numérique vérifie les deux. Si tu changes un bit à .iso, la signature ne sera plus vérifiée. En fait la procédure de signature commence par calculer un haché (qui n'est plus MD5, mais peu importe), puis signe le haché. Sinon la signature serait aussi longue que le fichier à signer. <andreas-e>civodul: Incredible, I do not even remember we had something like this. It must fill the mailing list server with information nobody ever reads! <andreas-e>Ah, the good old times when we had so few packages that breaking one was an event! <mvnx>I've been catching up on the LUKS/GRUB situation. What are you all using for full disk encryption? <nflqt>gabber: and andreas-e: Thank you! <nflqt>i'm chasing my Guix System discovery :-) <mvnx>wdkrnls: I only looked into it briefly so I don't have the full story but it looks like the build system was never updated to build for Go modules. I also need this because package restic is too far out of date for me. It's way too above my skill level to contribute at the moment. The Nix Go build system would probably be a good point of reference since there was a point it had to support Go modules as well. <jpoiret>seems that the running zig binary has a borked GOT table for some reason :/ it's starting to get a bit too out of my comfort zone, I'd probably need to debug what ld is doing (and might be related to the move to a PIE glibc) <gabber>any practical ideas on how i could test my unified home-night-time-service-type? is it easiest to create a vm and then configure a home environment with that service? <andreas-e>gst-plugins-bad exceeded its test times again, so we lost gnome again. This can probably be fixed by restarting the build, but with all packages depending on it, this is a lot of boring busywork :-( <podiki[m]>is that something about cuirass or luck of the draw with what else is being built and so it goes slower? <andreas-e>It looks like I can compile kdoctools with docbook-xml-4.5, which should hopefully solve the problem. <mirai>gabber: you'll have to do a vm and test this manually <andreas-e>If restarting it solves the problem, then it may be random. <mirai>afaik there's no check-system test equivalent for home services <mvnx>jackhill: What are people using instead? <mirai>andreas-e: looking at the definition for kdoctools, it has a substitute* for "cmake/FindDocBookXML4.cmake" <mvnx>I guess yeah, `go mod download` and `go mod vendor` <andreas-e>jackhill: I did not quite understand the problem with LUKS. The security should not depend on the speed of the key derivation function, but on the entropy of the passphrase. Of course you should use passphrases with 128 bit of entropy ;-) <mirai>so my guess is that it wants docbook 4.x (which version exactly will require looking at the sources and seeing the what the DTD declaration says) <mirai>I wonder if those substitution snippets are still required <nflqt>Zut! L'installateur me prévient que la carte wifi de mon ordi (Intel Corporation Wireless 8265 / 8275) ne dispose pas de pilote libre. Est-ce qu'il y a la possibilité de la faire fonctionner a posteriori sous Guix System ? <andreas-e>mirai: Yes, I just compiled it with docbook-4.5. Strangely before, it was compiled with docbook-5 (5.0.1?), which still worked. <mirai>is there an easy way to download the source of this? <jackhill>mvnx: I think the general approach is to keep the sensitive data someplace that grub doesn't have to unlock, either by having unencrpted /boot (not well integrated in Guix System, but possible) or haveing a separate partition for data that is not needed for boot. <andreas-e>nflqt: Non. Le noyau linux-libre refuse de charger un firmware non libre. De mon côté, j'ai une carte wifi Atheros dans une clef USB. <jackhill>mvnx andreas-e: right passphrases that are stored in (human) memory are bad! Using a separate hardware token to store the passphrase might be the way to go. <andreas-e>mirai: You mean "guix download kdoctools -S"? <mirai>andreas-e: ah, the previous docbook-xml name is misleading, it's inherited from docbook-xml-5 but the version is "4.5" <nflqt>andreas-e: Merci. Je vais de ce pas voir si je peux acheter ça. 😃 <mirai>so it was actually building with 4.5 <andreas-e>Ah, I see. So you changed variable names, which automatically updated every package to docbook-xml@5. And if it does not work we need to replace by docbook-4.5. <mirai>yes, though if you really want to be “right” about things then you have to find out exactly which docbook version was used to write the documentation <andreas-e>Then I will just upload my fixed kdoctools without checking whether the remainder of KDE will build with it. Let CI be bothered with the compilation! <mvnx>jackhill: I'm fine with unencrypted boot but this may be a struggle for me if it's not well integrated in Guix <andreas-e>Actually CI would not even need to rebuild things, I think, since it is just the status quo ante. The derivation will not know about the name change. <mirai>there was a name change and a change to the build-system <jackhill>mvnx: yeah, indeed. I don't have references handy to how to do that, but it would be good to get those cleaned up and an option by default. It would be useful for more than just this too, like booting straight from u-boot to fancier disk setups, etc. <apteryx>andreas-e: is kdoctools still in need of fixing? I'd replace docbook-xml with docbook-xml-4.5 <mirai>including some permission changes (I doubt the X in XML stands for Executable) <blacktoad>andreas-e: Thanks! (and sorry for my late reply.) <mvnx>jackhill: I'd love that yes. <civodul>cbaines: hi! qa.guix is all 504-timeouty today :-) <andreas-e>This is a known problem with a corrupted database :-( <andreas-e>There is a mail to the sysadmin mailing list. <andreas-e>Murphy's law! These things come à point nommé. <jpoiret>a sample C program that just does "getenv" segfaults with gcc-toolchain@11 on core-updates <andreas-e>jpoiret: You mean they do not try to unbundle Go packages? At least they compile them. <mirai>andreas-e: guix download -S kdoctools complains that the -S option is invalid <civodul>jpoiret: now that's getting interesting <jpoiret>andreas-e: I think they even rely on go downloading all dependencies, not just vendors <andreas-e>I still remember the time when I wanted to get inspiration from Nix for packaging texlive, and they just used the debian binary packages as their "source". <jpoiret>civodul: I don't understand the bytecode of the glibc's getenv, it doesn't try to write anything to __environ <jpoiret>civodul: ah, no, i'm spreading misinformation <mirai>so, I'm reading what the .cmake things have to say <jpoiret>I just can't write proper C programs. But still, the segfault in zig comes from __environ not being initialized for some reason <mirai>and looks like docbook-xml-4.5 is the right choice <mirai>> # By default it will find version 4.5. A different version can be specified <civodul>jpoiret: does zig provide its own '_start' symbol or something, somehow overriding that crt*.o do? <civodul>well i don't really want to know ;-), but that's something worth checking <jpoiret>damn, i think you're right, I should've noticed earlier that _init_first is from the zig binary not glibc <jpoiret>no, actually it is the glibc _init_first. i'll try to see why the env pointer is invalid <mirai>civodul: is there a way to have a “conflicts-with” feature for shepherd services? <mirai>short of having them bear the same canonical name <mirai>I see you can have both of them with the same canonical name, they just can't start simultaneously <mirai>thought it was forbidden to have more than one service with the same name <mirai>disregard the same canonical name thing <mirai>different canonical names but same virtual symbols <civodul>mirai: "conflicts" had actually become non-existent since the introduction of "replacements" in the Shepherd, years ago <civodul>in 'master' i've removed traces of "conflicts" <mirai>is it feasible to have 'replacement' support in guix? <civodul>it's there already: it's used anytime you reconfigure <mirai>I'm getting uneasy with my horrifying approach for a btrfs-scrub service <mirai>so, the idea is to have a service that does “btrfs scrub start …” but in the case that it doesn't complete due to a reboot or $REASON, it uses activation-service to create a transient service that performs a “btrfs scrub resume …” which is launched after boot <mirai>naturally, if this transient btrfs-scrub-resume-… service is running, the usual btrfs-scrub-… service shouldn't run (it will automatically fail without our intervention anyways) <civodul>it fixes a pretty important issue wrt. recovering svn source, it's safe, but it rebuilds lots of things <mirai>but rather than all this horrifying circus across the subsystems, perhaps (shepherd-service …) could make use of a replacement field instead? <mirai>idk if we can matryoshka the record-type definition this way since the value for this replacement field would be a shepherd-service itself <mirai>another thing I'd like to know is if “herd start foo 1 2 3 4” will result in “1 2 3 4” to be passed as arguments to the procedure in the start field <nflqt>Est -ce que H-node fait toujours référence pour le matériel ? 😃 <andreas-e>civodul: You mean merge to core-updates? I suppose it rebuilds everything with subversion sources? <andreas-e>Then we could combine it with the valgrind/lz4 commit, that would bring R and some texlive packages back to powerpc. <andreas-e>We should then make sure they are pushed at the same time, to avoid cuirass evaluating two commits and possibly building more or less the same packages twice. <blacktoad>Excuse me, I compared the list of .scm files in "MODULES" variable in Makefile.am with the list of built .go files. It looks like "guix/scripts/import/cpan.scm" is missing from "MODULES". Is this intentional? <andreas-e>I am mainly worried about aarch64. I think the other architectures are being built sufficiently fast now so that we can cope with even moderately large rebuilds. <andreas-e>Now that the Guix Data Service is offline, we have almost no vision of the status of aarch64. <mirai>the reason for this path change is that the current docbook-xml packages conflict in profile <mirai>so they'll have to be fixed and for packages that use the XML_CATALOG_FILES env var via libxml2 nothing changes <andreas-e>The less we change in packages compared to the pristine source, the better it is. Let us not go the Debian way... <mirai>but for packages like kdoctools that happen to use cmake instead then we'll have to patch them <andreas-e>We package an enourmous amount of software with very few people. If we start modifying the source code we package substantially, we will never see the end of it. <mirai>actually idk we even have to patch the thing at all <mirai> # for building with Nix package manager <mirai>I think it searches recursively <andreas-e>Why does one need several docbook versions in the same profile? <mirai>andreas-e: if you're authoring some documents which for $REASON are in different versions <mirai>but fundamentally they're DTDs and are organized specifically not to conflict with each other <andreas-e>Then why not use different profiles? This amounts more or less to the same thing, no? Binaries with the same name end up in different directories. <andreas-e>But apparently upstream creates the conflict then. I would go upstream with the problem. <mirai>upstream does it like this “/usr/share/sgml/docbook/xml-dtd-4.5/ent/isonum.ent” (overlook the SGML for now) <mirai>well, the 4.x series should actually place the SGML files in a sgml/ dir and a catalog.xml in xml/ anyways but I only wind of that a few days ago <mirai>I'll try taking a stab at the issue and see if things can be fixed without introducing more patches <andreas-e>I see, we use the copy build system. Then I have no opinion. We should do what is common so that our software finds what it needs ;-) For instance, if we could drop the substitute* in kdoctools, this would be a plus. <andreas-e>The FindDocBookXML4.cmake has a line for the Nix package manager, I wonder if this could not work for us as well. <andreas-e>10 minutes of clocking between building gst-plugins-bad and restarting everything needed for gnome. It is like a computer game. I am getting good at it! <andreas-e>Why does something called "gst-plugins-bad" is even considered as an input for something as important as gtk+? Should we not take it out? <andreas-e>Time to see if I can switch my system and user to core-updates! <andreas-e>No. For x86_64, we miss substitutes for openjdk (19 down to 9), icecat, ungoogled-chromium and qtwebengine (for calibre). <andreas-e>civodul: Honestly, it is too late for commits with costly rebuilds. They tend to cost us one day for being up to par (not even speaking of aarch64), which is incompatible with the merge schedule. <civodul>andreas-e: yeah, that's what i thought; we can always do that afterwards, that's fine <civodul>i thought i'd ask anyway, just in case :-) <mvnx>andreas-e: What kind of effort would be required to set up your own subsitutes for those? I was thinking maybe you could fire up low-cost one time builds for every new version on some cloud provider and then push the substitutes to a CDN - many free options there at least for bandwidth required for personal use. <lfam>TLDR, libreoffice does *not* refer to the ungrafted mariadb, but it also does not depend on the grafted mariadb <lfam>But rather a third unknown mariadb <andreas-e>civodul: We can quickly create a new branch with all these svn/lz4/valgrind commits lumped together, build it out on CI and merge it. <lfam>Check my recent reply for more detailed analysis <lfam>My reply hasn't hit the web archive yet <mjw>andreas-e, we are working on valgrind 3.21.0-RC2 right now (with 3.21.0 final end of next week). Any of these valgrind commits you want to see upstream or is this all guix specific? <andreas-e>civodul, rekado: Cuirass not doing topological sorting is terrible. pankow has been building abbaye for over 24h now. That is because it does not build abbaye, but recursively its inputs. So now it is at gcc. So what can happen is that in parallel another build machine builds gcc for another package. In fact *all* aarch64 build machines might be stuck building the same gcc, if I understand things correctly. <andreas-e>What is worse: GC runs every night. So once abbaye is finished, gcc may be garbage collected, and be rebuilt for the next leaf package. I think in the worst case we may end up rebootstrapping the whole chain for each and every leaf package. <lfam>andreas-e: Yes, it's not efficient <lfam>Hydra was much better at this <lfam>The related problem is that there may be no way to search for or view the job that built GCC <andreas-e>mjw: It is not even a commit of valgrind. We just want to upgrade to 3.20 and remove it as an input to the lz4 package. So only internal "bookkeeping", but it would require us to do quite a few rebuilds. Thanks for reaching out! <lfam>andreas-e: Unrelated, are you preparing for one last big rebuild of core-updates? <andreas-e>lfam: No, I hope the rebuilds are over. Just leaves or things close to them. I hope for a merge on Tuesday. <mjw>andreas-e, haha, so I am actually making you sad working on a 3.21.0 release, then you have to do lots of rebuilds again :) <lfam>Okay andreas-e. We missed updating the time zone database, unfortunately. Well, the true misfortune is that our packages depend on it, which is ... demented <andreas-e>lfam: If there is no gc, the problem is not as bad; the gcc will remain in the store of the build machine, and if cuirass asks for it, it will be returned immediately. This works particularly well if there is only one build machine and no gc. <lfam>Somehow tzdata grew 18000 reverse dependents <andreas-e>With many build machines, there is a high risk that gcc will be built on each and every one of them. <lfam>Yes, it can work andreas-e. But it the wrong way to do it <lfam>Hydra was aware of the dependency graph and would first build GCC, then the things that depended on it <lfam>tzdata provides timezones. Otherwise we all use UTC <andreas-e>lfam: It is definitely the wrong way to do it. The Guix Build Coordinator gets it right. <lfam>The tricky thing with time zones is that local authorities change things about the time zones periodically, so the database must be updated, or our users clocks would be incorrect <andreas-e>Yes, but what depends on time zone data? The "date" command I suppose. The desktop. <lfam>Well-behaved programs look up the database dynamically at run time, and do not depend on it statically <mjw>andreas-e, BTW. valgrind 3.21.0 final is scheduled for upstream release next Friday April 28th. And I am fairly confident about that date. RC1 had some small issues, RC2 is looking good. Don't expect any blockers to pop up. <andreas-e>mjw: Nice! Someone else can do the upgrade and rebuilds in Guix then ;-) I will be on vacation. <lfam>It's hard to tell andreas-e. The rust packages don't work with `guix graph` <lfam>So our diagnostic tools fall apart <lfam>tzdata is a big part of why I want a package property that forbids keeping runtime references <lfam>The reverse of #:disallowed-references <lfam>We are working ourselves into a corner without it <tribals>I'm trying to set up native builds in Guix on a foreign distro. I already set up binfmt for aarch64 in order to utilize `--system` option. But whenever I'm trying to build something I got strange errors like `/gnu/store/xxx-guile-3.0.7/bin/guile` not found. I tried to build it, and it builds correctly, but hash is different from what command tries to execute <tribals>I have another machine, which is Guix System. And there native builds just works. <andreas-e>mjw: When I look at our valgrind recipe, there seem to be FHSisms in the program! Things such as /lib, /usr/lib and /usr/X11/lib. <lfam>Maybe the time zone database should be part of the build environment by default, which would help remove some uses of it in native-inputs <mjw>andreas-e, those are in the suppressions I assume <mjw>ACTION looks for guix local valgrind patches <andreas-e>mjw: Yes, exactly. We replace /lib by */lib in the suppression files. <andreas-e>lfam: You mean register with tzdata that nobody should keep a reference to it? So behave as if tzdata would be added as a #:disallowed-reference to all packages? That looks like a nice feature. <mjw>andreas-e, interesting, maybe we can make that more generic upstream, we did get some support for distros using versioned/arch /usr/lib-* already <lfam>It's a mistake to depend on it <andreas-e>mjw: And we add "CFLAGS+=-maltivec" for powerpc* architectures. But this was introduced for valgrind 3.17 and is maybe not needed any more? <andreas-e>Somehow my system depends on openjdk. Is that normal? Is there a service that pulls it in without looking like java. <civodul>andreas-e: yes, that's terrible: to build GNOME's Cantarell font, we need OpenJDK <civodul>see "guix graph --path font-abattis-cantarell openjdk" <andreas-e>civodul: This is already done, I think. So once it exists, it is downloaded. But if I understand things correctly, cuirass orders the offloaded tasks; out of 10000 packages, it may put gcc last. Then it asks for 9999 offloaded builds, and the build machines start building gcc, but never send it back to cuirass, because they were not asked to. <andreas-e>civodul: That is ridiculous. I do not even use gnome, but xfce; I suppose that gdm pulls it in, then? <civodul>it's nice that we're building these fonts from source <civodul>it's less nice that we need OpenJDK for that... <andreas-e>Can we not use a different font? I do not really care which font my login is printed in. <andreas-e>OpenJDK19 depends on 18 downto 9, then icedtea 3 and 2. So we build 13 versions of Java one after the other. <andreas-e>Strangely, CI is building 17 right now, but my machine does not see it (yet?) and wants to start building version 10. <andreas-e>And every 6 months, if I remember well, it is one additional version. <civodul>or we could look for an actual solution? :-) <andreas-e>The argument that Rust is already needed is another reason to switch, not to keep the Java dependency. <andreas-e>But seriously, is there a reason why "./pre-inst-env guix build openjdk@19 -n" starts at 10 on my laptop, and 17 on berlin? If the other packages are built, why do they not show up as substitutes? <jpoiret>civodul: btw you were right, zig exports symbols usually exported by the libc. It's quite annoying that the symptom is a random segfault <civodul>jpoiret: is that reported upstream? are we the only one to have a problem? <jpoiret>I haven't seen it reported anywhere else <jpoiret>I'm wondering how nix copes, I didn't find anything specific to their build process <andreas-e>jpoiret: The derivations for 17 to 19, which would be built by both, are the same. <jpoiret>ah no, I know, they're statically linking LLVM <andreas-e>lfam: So where does tzdata start to ooze into our packages? Is there a single place, or are there a few places where we could act? <podiki[m]>andreas-e and apteryx: any thoughts on python-virtualenv? it is quite outdated and poetry needs a newer version; virtualenv is like ~430 dependents; poetry doesn't have many dependents but the failure i'm looking at is yubikey-manager which i'd say is pretty important for users <podiki[m]>complicated by virtualenv i think needing some hatchling packages added so I haven't actually seen if it builds and if i can then fix yubikeymanager, so a bit theoretical <podiki[m]>I could try and see if it is reasonable first <apteryx>podiki[m]: there's now hatchling on core-updates with two of its extensions <podiki[m]>I think hatchling-vcs is what virtualenv needs; I have it locally but need to polish it <podiki[m]>unless it is part of hatchling? haven't tried with your update <apteryx>there's python-hatch-vcs on core-updates <podiki[m]>great, then maybe it is easy enough and worst case can revert if it breaks <podiki[m]>I'll test locally if it helps fix some leafs first <bleb>is there something like nix, but only the part that identifies a package by a hash that includes all the dependencies? <bleb>I don't need the system configuraiton parts, etc. <bleb>just need an unambiguious way to refer to a program (any unix filter), including all the dependencies etc. <bleb>haha sorry I wrote nix instead of guix <bleb>but is there a smaller part, maybe just a standard for how to build the hashes, that I could use for my purpose? <lfam>andreas-e: I'm looking into the reverse graph of tzdata <zacchae[m]>AwesomeAdam54321: Haha, no. I'm running PureOS + guix home. <podiki[m]>virtualenv has quite the test suite, doesn't look like we've run it before/it is new <zacchae[m]>sneek later tell AwesomeAdam54321: Haha, no. I'm running PureOS + guix home <lfam>The bulk of the tzdata madness is through the Go compilers, which evade inspection via `guix refresh -l`, since that tool doesn't capture build-system dependencies. Unfortunately, other languages now depend on Go in Guix, so the embedded (???) copy of tzdata we add to Go causes many thousands of reverse depenencies. There are also a few thousand reverse dependencies via libical, a problem which is now almost 5 years waiting for an upstream release: <lfam>For libical, we should see what Nix does, maybe cherry-pick a patch, maybe write our own, or just nerf the functionality entirely <lfam>For Go, we should either not embed the time zone database, or switch to something like tzdata-for-tests, since if they require an embedded DB, one can hardly care if it's out of date <lfam>There are also dozens of packages that depend on tzdata without many dependencies. We can either ignore those or revert the relevant commits <lfam>In the long run, a new property like #:disallow-references is crucial to enfore these kinds of policy decisions in the packages <lfam>Despite years of me harping on about this, the message is still not widely received <apteryx>lfam: I was thinking the other day, if it'd be possible to automatically populate disallow-references with the native inputs <lfam>I think the mechanism would have a lot of uses <apteryx>for native builds it wouldn't work though, eh <lfam>We'd have to do something clever <lfam>As long as the linter doesn't alert on a huge number of packages, sure. I think that enforcement is better than warning for policies that will impact a large number of packages. Or else we will have to answer the same question a million times <lfam>I'm creating a local branch to cherry-pick the Nix patch to libical, and changing Go to use tzdata-for-tests, which could perhaps be renamed to tzdata-pinned or whatever the conventional name is for packages like this <lfam>Also going to try building Go without tzdata at all <mirai>lfam: are the linux-4.x and linux-5.x system tests supposed to work? <lfam>I don't even know what that is <mirai>they haven't been building for quite a while for me <lfam>Your attention to those tests is welcome! <mirai>make check-system TESTS="linux-libre-5.10 linux-libre-5.4 linux-libre-4.14 linux-libre-4.19 linux-libre-5.15" <lfam>I don't even see the string 'linux-4' in guix.git <mirai>I recall seeing some compilation failures due to something involving dddci or similar with those older kernel builds <mirai>let me get a log of one of these tests <mirai>either I'm misremembering the name of the test or the problem got fixed in the meantime <lfam>Alls well that ends well <mirai>is there a way to load udev rules at runtime without doing a guix reconfigure <podiki[m]>in continuing down the updating virtualenv hole, needs an update to python-filelock which has ~3000 dependents <podiki[m]>perhaps I'll have to pre-emptively start a python-updates branch for these, all that to try to get yubikey-manager to build... <podiki[m]>so far pretty trivial changes, except a bunch of virtualenv's tests don't pass/error (looking for windows stuff, trying to use pip to download, etc.) <podiki[m]>civodul: was that "uh" for this discovery of very outdated python core packages? <podiki[m]>sigh...and requires building inkscape, webkitgtk-with-libsouop2, gst-plugins, ...I'm guessing from some substitutes missing not these updates but I guess I'll let everything build locally and see how it goes <bjc>i'm amazed at how deep in the package graph inkscape sits <civodul>podiki[m]: yes, it always feel daunting to me when deep Python packages need an update <podiki[m]>something about the package graph must be a bit separable in a sense, since it is only through a few leafs that I found these very outdated packages with lots of dependents <podiki[m]>separable in versioning; once one needs a newer deeper dependency the whole graph is thrown in upheaval <podiki[m]>I think I better bring this up on guix-devel to see how people want to proceed. it is only a handful of updates, but I don't know what else will then break/need updates <jackhill>podiki[m]: I thought python folks had moved to using venv standard library module <lfam>I forgot, but python-pytz contains its own copy of the time zone database and has a few thousand dependents. But thankfully it looks like that's being replaced in Python-world with new support in dateutil, although I have no idea if dateutil does the right hting or not: https://fedoraproject.org/wiki/Changes/DeprecatePytz <lfam>I wonder why changing the Go compiler, libical, python-pytz, tzdata, and tzdata-for-tests packages cause the Rust compilers to be rebuilt <podiki[m]>jackhill: i know some python but not up on the packaging ecosystem; virtualenv doesn' <jackhill>podiki[m]: yeah, I was podering if it became outdated because it had fallen out of use, so no one noticed. Seems like it is still relivent, but more niche, so all that make sense. <jackhill>Unfortunately, doesn't help with the update work :) <jackhill>ACTION is waitng on nss to finish testing on core-update aarch64 after `guix pull` <podiki[m]>right, that's my impression, but then following the thread led to a few that are used a lot yet still very outdated <lfam>That's a very long test suite jackhill <podiki[m]>luckily so far the patches have been pretty trivial, so maybe I'll put the set to guix-patches and ask on guix-devel how we feel <podiki[m]>probably do this as a feature branch immediatel post core-updates, if we do manage to merge that early next week? <jackhill>yeah, I've noticed. I only have A53 cores too :) <podiki[m]>yeah, nss has one of the longest test suites I've eve seen <lfam>You might wanna wait for substitutes <jackhill>lfam: yep. I'm kind of hoping that core-updates will fix some of the broken builds, or at the very least I'd rather troubleshoot on core updates. In the meantime, may as well try to help core-updates along however I can. <lfam>guix show libgweather | grep synopsis <lfam>synopsis: Location, time zone, and weather library for GNOME <lfam>Why are these the same package <civodul>because the weather varies as a function of location? :-) <civodul>DST happens in summer, and in summer, the weather is sunny <old>hey is `docdiff' package somewhere? <lfam>old: Doesn't look like we have it in Guix yet <old>or is there an equivalent? I need to produce a diff for PDF <civodul>andreas-e: i have a Java-less Cantarell! \o/ <civodul>(the same one as the one bundled by cffsubr) <lfam>old: I don't know a tool to diff PDFs. If it were me, I would try diffoscope, you can even use it on the web <lfam>But, it might be too fine-grained <old>diffocscope would produce a diff of the binary :-/ <old>might require to use an online tool for that or boot a ubuntu Vm <bjc>if i submit each patch i have to get alacritty's rust deps up-to-date, i think i'm going to cross the 50 patch threshold~ <lfam>djc: Good time to learn about the '--stdout' option of `git format-patch` <lfam>`git format-patch origin/master --stdout > my-patch-series.patch` <bjc>good news: i haven't broken things down into multiple patches yet <bjc>my current head is just a huge ball of interconnected diffs <bjc>no. submitting them in order so builds don't break is going to be awful <lfam>What works for me is making everything work, then taking a break. I come back to make the commits in another state of mind <bjc>that's my plan. this is my third day doing this; what's another one? <lfam>Could also apply to become a committer and then sneak the changes in via `git merge` 😈 The git log tooling usually doesn't show changes done in merge commits <lfam>You could do it all in one commit <lfam>But, I think that's considered "bad" and "against the rules" <bjc>that's why i'm going to bribe one of you to do it for me so ludo will blame someone else <podiki[m]>speaking of commit stuff...my signing subkey will expire in may, I will renew it, does that change the fingerprint we use? <podiki[m]>did we stall out on the whole subkey and expiration issue? <lfam>podiki[m]: Renewal doesn't change the fingerprint. Also, expiration dates don't matter for code signing <lfam>So, you can do whatever you want <podiki[m]>whatever I want = usually remembering a month after expiration 😆 <bjc>unmatched-paren: that's a good point. what does ludo like? can i bribe him with patches? <podiki[m]>i'll have to reupload to keyservers and such since I finally put it on there, so that will show i still have control <lfam>The greatest gift is a flurry of code review and project management <podiki[m]>ludo may be partial to vegetarian/vegan food and reproducibility ;-) <civodul>podiki[m]: changing the expiration date doesn't change the fingerprint <bjc>well, i have a garden and three kids. does that count? <podiki[m]>civodul: okay good, thought i'd check. maybe i'll revive the issue about subkeys and such anyway, it is a good reminder <podiki[m]>ACTION is off to enjoy daylight while the computer continues building diligently <apteryx>it's "guix package: error: corrupt input while restoring archive from socket" day here <lfam>Have you cleaned the socket lately <lfam>Patches sent re: time zones <lfam>I'm looking to do the high-impact patch series in a feature branch soon after core-updates <lfam>It will rebuild about 18300 packages <bjc>any rust people here? is there a way to cache the ‘patch-cargo-checksums’ or ‘upacking’ phases across builds? <bjc>i assume the reason it uses every crate on the system is because building the graph of crates is hard for those steps <lfam>You should keep waiting for a more expert answer, but I know that our rust package building doesn't work in the "normal Guix" way, and doesn't even have a concept of dependencies that can be manipulated with the Guix tooling, due to a large number of dependency cycles in Rust-world <singpolyma>Someday we'll invent a way to handle coreqs in guix <bjc>i was wondering how the dependency cycle tracking was working! <bjc>i keep running across crates that refer to each other, and i'm pretty confused as to how they can even build. <bjc>my best guess: intermediate object files, and everything is just linked together at the last step, with lto throwing away the cruft <singpolyma>And pull all the source for every dependency and build it all at once <bjc>oh, you'd have to, because there's no output for the intermediate objects <singpolyma>And because guix can't handle cycles yet in a general way <lfam>(opinion incoming) It's basically ruined part of the Guix user interface, since tools like `guix graph` and `guix refresh` don't work consistently anymore <lfam>And it's not like just a few packages. There are soooo many Rust packages <bjc>i'm curious how much work is left in anti-oxidant. i got the impression it was pretty close <bjc>the last 5% is pretty notorious for breaking projects though <lfam>What's anti-oxidant? Hard to google for <jackhill>ha! I was just trying to remember that name so I could look it up <bjc>maximed was working on a new rust build system a while ago <bjc>and now nckx is missing. a worrisome trend <bjc>if there's no way to limit the unpack and patch-cargo-checksum phases for rust, it has to be adding a tremendous burden to ci. they're, by far, the longest step in most crate builds, and it happens for so, so many crates <bjc>i wonder if fixing that would be the single biggest drop in build times the ci infrastructure ever sees <f3n1x>in order to switch from pulseaudio to pipewire based audio management, may i remove pulseaudio and pavucontrol and install pipewire ? thanks, thanks, thanks <jlicht>Regarding the rust packages ruining guix graph, guix refresh; we'll need to do something similar if we want to build any complicated node packages as well <jlicht>(even with the binary npm importer) :-( <singpolyma>I haven't fully thought it out, but coreq might be enough and guix should be able to add such a concept <singpolyma>It just means having metadata about the refs, which currently is not done <jlicht>I haven't got the faintest clue what 'coreq' is, but I am definitely interested <singpolyma>Like in University if two courses have to be taken either one before the other is at the same time but order doesn't matter <singpolyma>"if you have me as an input you must have Y as an input as well"