IRC channel logs
2023-10-25.log
back to list of logs
<elevenkb>basically, say that electron is f(chromium) then we should package f(ungoogled-chromium) imho. <futurile>elevenkb: I don't know tbh. Maybe there's some reason electron is considered nonfree. <futurile>elevenkb: probably look at what's happening over there - maybe it will say why. Or do a search of the email archives. <Kolev>When is the LUKS passphrase prompt issue going to be fixed? <rekado>Kolev: can you remind me what the issue number is? <lilyp>vivien: not sure, afaik committer.scm only handles basic stuff <alxsim>but it feels like I'm not using the right build tool for the job (using pyproject-build for now) as it contains both rust and C dependencies <gabber>alxsim: what languages dependencies are written in shouldn't factor in what a new package needs <gabber>what kind of pointer are you looking for? i guess it doesn't work yet? <alxsim>gabber: So I'm on the right track using the python builder? <gabber>we usually try to *not* propagate inputs, but patch relevant sources of packages <alxsim>Sorry I don't follow, pretty new to packaging <gabber>alxsim: i am currently not in a position to answer this question with any expertise, but IMO if it works, then it's ok (: <gabber>no need to be sorry! the first step is to make it work, you can still clean the build up later on <alxsim>I have this error error: failed to get `demes-forward-capi` as a dependency of package `fp11rust v0.1.0 <alxsim>although I packaged demes-forward-capi in the same file and included it in the native-inputs <gabber>and `demes-forward-capi` builds (and works as expected)? <alxsim>yes it builds, but unsure how I'd test it <alxsim>but it feels more like it's not picked up in the build env of the first package <alxsim>Anyway, I'm out of my depth at this point I think. Just wanted to see if there was an easy fix or a close example I could follow (i.e. python packages with rust bindings) <gabber>are you sure it belongs in native-inputs (i don't think that's the source of your current problem, but still) <gabber>alxsim: there may be, maybe have a look at (gnu packages python-xyz) or other python package modules? <gabber>python-orjson seems to be one (but dang this looks complicated/advanced) <alxsim>ok so it seems I should instead use cargo-build-system and create a manual build python module phase it looks like <gabber>the build system is the one that the authors of the source code use to build the software -- i think the presence of the setup.py in fwdpy11 hints towards the use of python-build-system <gabber>sorry, python-orjson might not have been a good hint. i'll leave you now and wish you a pleasant and successful journey! <mroh>alxsim: python-cryptography-rust does something like that. <alxsim>mroh: ok I'll need to dig a bit to understand what inputs does in the following python-cryptography <Kolev>Hm. Pika Backup isn't packaged. Vorta will work. <Kolev>I really don't like having to type my LUKS password twice. <lars`>Hello, I installed Guix on a foreign distro (arch), and now tmux refuses to start, saying "tmux: invalid LC_ALL, LC_CTYPE or LANG". I followed the tips in "Application setup" and installed glibc-locales, but that didn't help. I have checked the variables that it complains about, LC_ALL is set to en_US.UTF-8, while the other two are unset. I tried setting them also, but tmux still says the same thing. I think guix is doing something <roptat>lars`, did you install tmux with guix? <lars`>Although initially I had installed it with pacman <lars`>But now it is (also) in my guix home config <lars`>I also have this message every time a shell starts: "ice-9/psyntax.scm:2824:12: In procedure syntax-violation: Syntax error: /home/lars/.guix-home/on-first-login:3:1272: sequence of zero expressions in form (begin)", don't know if it is related <futurile>lars`: I've seen the tmux thing as I run Guix apps on Ubuntu. It was because my locale wasn't exporting correctly. <lars`>How did you solve it? My LANG seems to be okay, and I also manually set and exported the other ones before launching tmux. I even tried adding them to /etc/locale.conf and ~/.zshrc <futurile>lars`: yeah - just trying to figure that out in my notes - hold on <futurile>lars`: it looks like I tried adding LANG/LANGUAGE/LC_ALL to .bash_profile but I couldn't get it to work. So I've reinstalled the systems locales and regenerated the locale files - notes aren't showing me the specific commands I ran -sorry! <lars`>So, it was the system locales (not guix) that needed to be reinstalled? <lars`>Did guix overwrite something from the system then? <futurile>lars`: that's the solution I did - I *think* it was conflict between the locale in the local system and the one set by guix with glibc-locales <futurile>lars`: no Guix doesn't change the system one - you installed guix' glibc-locales into your profile right (it's in the set-up instructions somewhere) <lars`>Regenerating system locales using locale-gen didn't work for me <lars`>Yes, I added it to my list of packages in home config <lars`>It also says to do this: "export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale", though that path does not exist <futurile>sorry - that's all I've got. I guess try searching the bug list and asking on the mailing list <lars`>Must be because the locale path does not actually exist <lars`>But why doesn't guix create it when installing glibc-locales? <lars`>Installing glibc-locales using "guix install" created the missing locale path, but tmux is still complaining. Shouldn't installing the packaged from my home.scm give the same result as using guix install? <roptat>lars`, you might need to log out and in again, guix home installs some scripts that I think are only run when you log in <lars`>roptat: I have even rebooted <roptat>GUIX_LOCPATH should help, and the directory doesn't exist because you used guix home, so it would have been .guix-home/profile instead of .guix-profile <lars`>Oh, that makes sense. I'll try exporting that instead <roptat>my last resort would be to "strace -f tmux" in the hope I can find some hint of what it's trying to do <lars`>Exporting the other path didn't help. Could this error message be relevant? guile: warning: failed to install locale ice-9/psyntax.scm:2824:12: In procedure syntax-violation: Syntax error: /home/lars/.guix-home/on-first-login:3:1272: sequence of zero expressions in form (begin) <roptat>ah that might mean the script didn't run, so it couldn't set up the session correctly <roptat>would you mind sharing that file? <lars`>I have that same error on two different machines, one debian and one arch <lars`>On the debian one installing glibc-locales was all it took to make tmux work, although the error still remains <roptat>I see, it doesn't look important after all <roptat>I'd try to strace it then, and see if it even tries to open the locales directory <roptat>even at the right location, so why isn't it happy then? <lars`>well, I think it actually finds it at startup now, because tmux does actually start now. But it is inside the session that it craps itself. I have some hooks that set the background color of the active pane that calls on a tmux command. I think now it is those that fails <lars`>But I have the exact same tmux.conf on the debian machine, and there it works fine after installing glibc-locales <rekado>Kolev: if there’s no bug report to focus the discussion and gather solutions then it’s unlikely to be worked on soon. <lars`>Okay, I think maybe now the other error seems to be unrelated to locales. It did have the same error message earlier, but now at some point it has started saying something else. So it appears something I did fixed the locale error, although I have no idea what. Might have been installing glibc in addition to glibc-locales, might have been updating the guix daemon, or might have been installing the locales as root, or possibly something <futurile>yeah I think this is why I didn't report a bug - there's lots of issues/answers on the Internet for 'tmux doesn't work with my locale' - did a bunch of stuff and then it just started working. <lars`>Okay, after another reboot all is good <lars`>I think the docs should be updated, because installing just glibc-locales is apparently not enough, at least one of the following is also needed: glibc-locales as root, glibc, glibc as root, glibc-locales in host package manager, adding LC_* variables to many different files, exporting GUIX_LOCPATH from many different files, etc <lars`>And a full reboot is also apparently needed, as neither logging in again, nor restarting the guix daemi <futurile>you really need a repeatable use-case to document the problem and the solution - personally I couldn't identify the specific problem and the specific solution <fnat>I've been trying to create a Python virtual environment in a Guix container, as a quick and dirty solution before trying to package a couple of missing Python libraries <fnat>It confirmed to be a dirty approach, quick? not so much. Here's a log of what I've been doing, inclusive of error message: https://bpa.st/ASWA <fnat>tl;dr: create a container, create a venv within the container, install numpy, import numpy, error <fnat>(numpy is just an example here) <fnat>Is the container+venv approach doomed to fail? Any quick fix that could get me going? <futurile>fnat: you're definitely missing the zlib.so - you could try explicitly exporting your hosts LD location - export LD_LIBRARY_PATH=/lib:/usr/lib <fnat>ah! thanks futurile, that fixed it :) brilliant <rekado>I’ve seen people connect from macos to a RHEL server over SSH, and then launch tmux from Guix. <futurile>fnat: you could also try adding 'zlib' to your guix shell command above <rekado>the macos SSH client would set an invalid locale, which obviously could not be found in the locales provided by glibc-locales. <rekado>the current locale must be valid, GUIX_LOCPATH must point to the directory provided by glibc-locales, tmux must be launched in the environment where GUIX_LOCPATH is set. <rekado>root doesn’t play a role here. All that matters is the environment of the tmux process. <fnat>futurile: Oh yes, I should have mentioned that, it works if I add zlib to the initial Guix command (which I had tried already, but I missed the path step, as you indicated) <rekado>lars`: okay. You can look at /proc/PID/environ to see the environment variables for the misbehaving tmux process. Especially LANG, LC_*, and GUIX_LOCPATH. <futurile>rekado: oh wow that's cool for debugging {learns something new} <fnat>this successfully lists a bunch of libs: "guix shell --emulate-fhs --container coreutils -- ls /lib" <fnat>however, there seems to be no "/lib" ("/usr/lib" and other variants neither) if I try from within a VM built and run with "guix system vm" <sneek>Welcome back snape, you have 1 message! <sneek>snape, apteryx says: thanks for the quick fix <lars`>snape: so I can just remove the empty (begin)? <lars`>crap, I can't modify the file <snape>well, no, Rostislav did a fix, which hasn't been merged yet <snape>the correct file to fix is: gnu/home/services.scm:438 <lars`>Okay, for now it seems like it doesn't cause any obvious problems, only an annoying error message when starting new shells <snape>yeah indeed, it's harmless it seems <snape>is there a way to access guix-devel with gnus? <snape>like it can be done with guix-patches (through debbugs) <snape>that is: without subscribing <tux1c>how would you go about adding iptables rules conditionally? say, I have ssh configured on a server, then I would like to bundle iptables rules with the ssh configuration such that it accepts ssh connections, but if the user comments out the service, then it will also not apply those rules? <snape>and without manually downloading mbox files <tux1c>my current idea is to set up a one-shot shepherd service that adds the rules by cli, and make ssh server dependent on that shepherd service, but maybe there's a better way? <snape>tux1c: you can use iptables-service-type <snape>if (whatever) (iptables service type, ssh service type) <tux1c>snape: I can't have multiple instances of that service type though, right? I would like to create such rules for all the network services i use, so if you enable ssh but disable httpd it blocks port 80 but passes on port 21 <snape>tux1c: I believe you can use conditions within the iptables service definition <snape>tux1c: and I can't see why you wouldn't be able to have multiple instances of that service <tux1c>snape: hmmm thank you, i was under the impression you can't do that, I'll try it out and report back :D <snape>well, forget what I just said, it's probably impossible to have multiple instances indeed <Kolev>rekado, I submitted a bug. LUKS password prompt invisible, prompts twice. <vivien>Should I wait a bit more for QA to start building #66689 v3, or should I send it again and hope that will unblock it? <lars`>I'm trying to install zsh-autosuggestions and several other zsh-* packages. They are not getting symlinked anywhere, the files are just sitting in the store. Is this how it is supposed to be? <nckhexen>lars`: How did you verify that they aren't symlinked (that's the only job of ‘guix install’, and it works here)? <lars`>find / -name "zsh-autosuggestions.zsh" <nckhexen>~ λ guix install zsh-autosuggestions && ls ~/.guix-profile/share/zsh/plugins/zsh-autosuggestions # works here. <lars`>Oh, wasn't aware that find doesn't find symlinks <Kolev>My email hasn't shown up in the Guix issue tracker yet. <lars`>nckhexen: How do you use it? Do I have to source it from my zshrc? <lars`>I thought you said it worked for you <nckhexen>Its job is to symlink store items into the profile (~/.guix-profile by default), and it did. <lars`>Other stuff gets symlinked into the correct location also <nckhexen>Hm, in the zsh package definition I see --enable-additional-fpath=…,/run/current-system/profile/share/zsh/site-functions <nckhexen>What that means in Guix-speak is that it explicitly adds system-wide site-functions. <nckhexen>It doesn't explicitly add user profile ones, but as a non-zsh-user I don't know if that's a problem or not. <nckhexen>Adding ~/.guix-profile/share to your shell start-up file isn't wrong. You could ask on the help-guix at gnu dot org list whether this is expected, though. <nckhexen>The ‘no graphical output’ on some {Core,Libre,…}booted systems is also familiar. Does this machine lack the VGA blob by any chance? <Kolev>nckhexen, I don't know. It's just an X200. <nckhexen>IIRC Linux doesn't know how to draw to your framebuffer. You need to figure out what kind of framebuffer it is and which driver would need to be included in the initrd. <nckhexen>Kolev: I thought you said it was a Librebooted X200. <nckhexen>That's a very different machine from a normal X200. <Kolev>nckhexen, yeah, it's a Libreboot X200. Is it normal for it to have no VGA? <nckhexen>I think so, yes, since the VGA blob is generally proprietary. <Kolev>nckhexen, so the solution is to type into the gray void. <nckhexen>So that's probably what you need (the .config reversions weren't needed and CONFIG_GOOGLE_FRAMEBUFFER_COREBOOT should not have been disabled), and the fact that we can't parameterise kernel modules on kernel versions is keeping us from fixing this in Guix. <nckhexen>You can add it to your own system configuration though. <nckhexen>You need to (1) ensure that the simplefb module is built (2) add "framebuffer_coreboot" "simplefb" to your initrd modules. <mirai>I'm getting this oddity following a home reconfigure <mirai>ice-9/psyntax.scm:2824:12: In procedure syntax-violation: <mirai>I didn't change anything in it though <nckhexen>PotentialUser-43: JSYK that link works fine for me. <PotentialUser-43>nckhexen: When I click on the link I mentioned, firefox says that the SSL handshake failed because the host uses an old, vulnerable method. The link you shared works perfectly though, thanks! <PotentialUser-43>I am using that same version, maybe it's because librewolf has a stricter security configuration? <PotentialUser-43>Whelp, but since I already have the image I guess that it's no longer my problem. Thanks again! <ngraves>Hi guix ! I have a trivial patch series just moving packages in node-xyz.scm in alphabetical order waiting for review in 66180, and there's no Node team for now, if a commiter can take a look ;) <nckhexen>ACTION gets the dreaded ‘error: could not build fake ancestor’. <porcupirate>I am unable to pull successfully, but if I pull from an up-to-date local mirror it works. <porcupirate>-builder for `/gnu/store/znzj9d79qb4md9255akybizab962ccqj-guix-package-cache.drv' failed to produce output path `/gnu/store/a5x12429nnjqh9zg4dy51q7avi65jmjn-guix-package-cache' <porcupirate>build of /gnu/store/znzj9d79qb4md9255akybizab962ccqj-guix-package-cache.drv failed <porcupirate>hint: This usually indicates a bug in one of the channels you are pulling from, or some incompatibility among them. You can check the build log and report the issue to the channel developers. <nckhexen>porcupirate: That is not a useful paste. <nckhexen>(Even if you know p.d.o's URL scheme to get the ‘raw’ data, it's corrupted.) <porcupirate>View build log at '/var/log/guix/drvs/zn/zj9d79qb4md9255akybizab962ccqj-guix-package-cache.drv.gz'. <jpoiret>porcupirate: are you using channels? <sneek>Welcome back jpoiret, you have 1 message! <phf>jpoiret: It's Ok, I've figured it out. <nckhexen>ngraves: I'm at patch 15 and I'm tired of this. Can you rebase your series and send a v2? I'll merge it. <nckhexen>porcupirate: See the note about incompatible channels. Don't assume that your ‘pull from an up-to-date local mirror’ is doing what you think it's doing. <porcupirate>jpoiret: guix pull --details says I do have channels, but channels file is mostly commented out. I tried --without-channels without success. I moved my channels file where it won't be detected and I'll try gux pull --url=<local guix mirror> and see if that works. <nckhexen>porcupirate: And the log still blames python-pycrypto? (No need to re-paste if so.) <nckhexen>Apart from what appear to be forgotten patches (which I'll remove), I don't see any reference to python-pycrypto in Guix proper. <nckhexen>The removal is also very old and any mistake would have been spotted months ago. <nckhexen>(Unless this is a merge commit, nckhexen.) <pkill9>what are some of the best and/or most valuable guix issues to work on/ <bonmlp`>Well this is disappointing. I downloaded the latest .iso, version 1.4.0, used qemu to make a .qcow2 image of it, connected and ran 'git pull' and it failed while computing the derivation. Is this likely to be a resource issue? I made the qcow2 with -m 1024. Should I make it bigger? <rekado>bonmlp`: 1G is too small. Try 2G or more. (It’s a known problem.) <pkill9>does guix have a kde plasma desktop service now> <nckhexen>bonmlp`: By ‘making a .qcow2 image of [the iso]’ you mean booting the ISO and running the Guix System installer and rebooting, right? <apteryx>does someone know why Emacs infer scheme-mode for the e.g. etc/committer.scm.in template? <nckhexen>(There have been people who thought that QEMU requires qcow2 for storage, I just wanted to check.) <porcupirate>pkill9: Looks like plasma-desktop-service-type does the job. <lars```>I'm trying to use Guix on top of Arch, but I'm having problem with some programs failing on getaddrinfo as described here: https://guix.gnu.org/manual/en/html_node/Application-Setup.html. As described by that page this is because nscd is needed by Guix. nscd has been removed from Arch as of glibc-2.38-4 and there is no replacement for it as far as I can see. Is there any alternative way to make Guix programs play nice? <nckhexen>Kolev: Are you runnning x86_64 Linux on that X200? <bonmlp`>OK so my 'guix pull' worked with 4G of memory but now the next step fails. The manual says to do 'sudo guix system reconfigure /etc/config.scm' but it complains that there is no /etc/config.scm What now? <nckhexen>Our i686 and x86_64 kernels have inexplicably different settings for Coreboot framebuffer support. I'm not sure it's the cause of your lack of display, but it can't help. <porcupirate>What's the difference between 'guix pull --details' and 'guix pull --list-generations'? Is there a way to get the info just for the current generation? <nckhexen>porcupirate: --details will show more details (try it) but I think you're looking for ‘guix describe’. Unfortunate UI. <jpoiret>heh, is that another case of an unclead .cache checkout? <nckhexen>It occurred to me, but I don't understand how it can lead to this failure mode (describing an internally inconsistent guix HEAD, presumably). <nckhexen>But maybe there was a third-party channel slipping in after all. <bonmlp`>lars```: Thanks! I'm using that now and it's complaining about the file-system-label "my-root". How do I find what label to put there? <nckhexen>‘Whatever you named your root file system’ is the end answer. <bonmlp`>nckhexen: 'sudo lsblk' does it, thanks! <porcupirate>pull progress 40% through indexing objects and I need to go now. I'll follow-up later if the problem persists. <bonmlp`>nckhexen: OK it's doing something now. <gabber`>is the --system part of a $(guix build foo --system=foo2) broken? i run into "a `aarch64-linux' is required to build `foo', but I am a `x86_64-linux' <gabber`>so, $(guix build hello --system=aarch64-linux) does not work, which i guess is a bug. <jpoiret>gabber`: what do you expect --system to do? <NewGuixUser>Hello everyone, I'm a new guix user and am having some issues with installing Python packages. I am trying to reproduce a Python environment from ~3-4 years ago. Many of these package versions never existed in guix so I'm taking existing packages that were very similar in version and modifying them to grab the appropriate versions. When I try to <NewGuixUser>install one of these packages the logs show the bytecode compilation succeeded but it crashes in the check phase when running pytest. I see errors like "ModuleNotFoundError: No module named 'py'" and "%exception #<&invoke-error program: "/gnu/store/nwhsvpc0fal2fjgl2ygkkhn6x4cykkc3-python-pytest-5.4.3/bin/pytest" arguments: ("-vv") exit-status: 1 <NewGuixUser>term-signal: #f stop-signal: #f>". Does anyone know how I could debug this? <gabber`>emulate the system (qemu) and building within that? or am i confusing it with something else now? <nckhexen>Did you enable & start the qemu binfmt service that comes with Guix System? (I forget the exact name.) <jpoiret>guix is not (yet) a complete CPU emulator <nckhexen>guix build --emulate-gentoo hello just sets CFLAGS='-O99 -fadd-extra-loops -funroll-loops'. <gabber`>what strikes me as sub-optimal UI is that --list-systems lists all possible systems, but when it fails (due to the missing service) there should (IMHO) be an indication for the missing service (or infrastructure) <nckhexen>By how often my system flat-out refuses to boot I should be barred from providing support forever. Now it says I need a rootfs. Which is, uhm, worrying. <gabber`>also, $(guix build --help) says: -s, --system=SYSTEM attempt to build for SYSTEM--e.g., "i686-linux" <gabber`>nckhexen: well, you probably do need one (: <apteryx>does adding coreutils to inputs enough to shadow the 'native' implicit one, when it gets picked on PATH? <nckhexen>gabber`: I'm not seeing the issue with that help text? Help me. <nckhexen>Did anything change in the Guix System initrd realm lately (past weeks, say)? <gabber`>there should be some rather obvious hint that without adding support for this emulated build it won't work -- for idiots like me who tend to forget rather quickly about things that /just work/ <nckhexen>My rescue initrd which uses the exact same kernel version can mount / just fine. <gabber`>the way it's worded currently implies that functionality is just there <bdju>what is the process for getting guix system on aarch64 or powerpc64le? I only see a download for the package manager. is it possible to get the whole distro? <nckhexen>gabber`: Guix just punts to the machine/OS combo. But adding somu auto(?)detection code to the list sounds cool! <jpoiret>bdju: yes, you need to install guix on a running linux first though <jpoiret>ie. we don't provide prebuilt images <NewGuixUser>Ok so I only have the issue I described earlier with my own packages, not with anything available in upstream. For example, if I install python-numpy it works fine, but if I try to install python-numpy@1.19.0 I get that pytest error I described earlier. All I did with my python-numpy package was I pasted the existing package into a new file and <NewGuixUser>updated the version number and hash to correspond to 1.19.0. Is there a better way to get old versions that may not have ever existed in guix? Unfortunately I cannot upgrade packages for regulatory reasons and pip is inconsistent when trying to reproduce this old environment. <bdju>so basically you start with some other distro, whatever you can get installed, and then you turn it into guix system? <nckhexen>Some people even init / while the old distro is running, although that results in a very unclean system when you reboot into Guix System. <bdju>that's pretty cool. thanks for the info <nckhexen>I don't see a good reason not to init a separate partition unless the system is extremely constrained. <jpoiret>bdju: that's how i installed guix personally <jpoiret>it surprised me that i could just do that <jpoiret>NewGuixUser: i don't think you can expect the new packages definitions to work mutatis mutandis with old versions <jpoiret>esp. since our build systems have changed since then <jpoiret>i'm not saying there's a better way though, just that it might require some work to get it working <NewGuixUser>jpoiret: Would using time-machine to revert to a version of guix roughly around the time those packages would have been recent help? <jpoiret>yea, that would help wrt. build-system changes <nckhexen>Inferiors are also something to look into for a more declarative (also, complex & slower) approach than manually keeping guix balanced on some magic old version. <NewGuixUser>Just checked numpy 1.19.0 and according to pypi it was released in June 2020 <jpoiret>nckhexen: if it's an isolated stack i'm not sure the complexity is worth it <NewGuixUser>nckhexen: For all future projects I am planning to just use whatever is current in guix at the time and use time-machine to restore that version as needed. Unfortunately I can't do that with this project since it didn't use guix originally. <NewGuixUser>I thought about just doing "guix import pypi my-package@version" but a lot of them can't be parsed properly since they're older and don't use requirements.txt <nckhexen>Inferiors are just a way to codify an older (or alternative) Guix version in the same way a shell script with 'guix time-machine -- something foo' could, it's just a bit more native & flexible. But also more complex indeed. <NewGuixUser>The issue I'm having with time-machine at the moment is the package definitions I modified are too new, so I'm going to have to grab some from an older version and hope they work <jaeme`>Can someone explain (let ((commit <commit>) (revision <num>))) syntax for packages fetched from git? <jaeme`>Why do we bind the commit and revision? <nckhexen>jaeme: Because they are almost(?) always used multiple times in the body. <nckhexen>Well, maybe not revision, but it's human-friendlier to keep them visually grouped. <jaeme`>So is revision just used for versioning? <nckhexen>It's bumped each time you change COMMIT. <jaeme`>If a package has tagged releases, do we still use revisions? <nckhexen>If a package has tagged releases, why are we using a commit? <gabber`>it's also bumped when you change the package definition, no? <nckhexen>This is also not part of our Gentoo emulation. <jaeme`>nckhexen: Ohhhh, I get it better now. <gabber`>ACTION thinks they aren't getting some joke <nckhexen>gabber`: It comes back to 'guix package's being something of an emulator for a traditional PM. As part of those semantics it will 'upgrade' changed (edited) packages with the same version number, but not with a lower one. <nckhexen>And 3.1-abcdef0 is lower than 3.1-fedcba0. <nckhexen>gabber`: The only joke was me mentioning Gentoo, but many distributions do bump package versions/revisions any time anything changes. Guix doesn't. <nckhexen>We have a 100% reliable way to detect rebuilds (erring on the side of rebuilding), there's no point in packagers babysitting the PM for that. <nckhexen>Not an answer, but you do know that our IP is whitelisted, rite? <jaeme`>If the documentation for a package says that it depends on ~grep~ and ~sed~, do we include that as a propagated input or just ignore it? <nckhexen>We patch the source or script(s) to refer to (search-input-file inputs "bin/grep"). <nckhexen>If that's too hard, we wrap the executable(s), but this is inferior. <jaeme`>The package I'm referring to is a shell script <nckhexen>Propagation is even more inferior and should be avoided. <nckhexen>Some languages like Python have historically used propagation to moke them work in Guix but don't take this as global good practice. <jaeme`>nckhexen: I don't know how to do that yet (patching the script) <gabber`>nckhexen: thanks for the explanation! i guess lechner mentioned gentoo to your inspiration (: <gabber`>btw is this your spooktober name, nckhexen ? <rekado>sneek: later tell civodul guix.bordeaux.inria.fr ran out of space while building tensorflow <lechner>jaeme / for installed programs, you probably want to use wrap-program <nckhexen>(substitute* "script" (("grep|sed" command) (search-input-file inputs (string-append "bin/" command))) is a good base pattern IMO. <nckhexen>But you'll probably have to add a \b or two to match only whole words. Depends on the script. <jaeme`>Would you mind looking at the patch I submitted to debbugs because I'm still unclear on how to implement this? <lechner>nckhexen / thanks for the rsync command <jaeme`>nckhexen: which adds the ~ani-cli~ CLI <jaeme`>nckhexen: Thanks a lot in advance though <jaeme`>I have a feeling that there's a much better way to write that package than what I have now. <nckhexen>Probably, but that applies to most code. <nckhexen>And I said that without looking at yours :) <NewGuixUser>Ok so I took the numpy package from guix v.1.4.0 since it was only slightly newer than 1.19.0 and now get this error when I try to build "INTERNALERROR> pytest.PytestConfigWarning: Unknown config option: env" <rekado>are you mixing packages from Guix 1.4.0 with recent packages…? <NewGuixUser>No, I'm using time-machine to go back to 1.4.0 and trying to build a modified numpy package. I need numpy 1.19.0 (along with a whole bunch of other specific python packages) and 1.4.0 had the closest version I could find <NewGuixUser>I talked about my issue a little earlier if you were online <NewGuixUser>Basically I have a list of several python packages from ~3 years ago and I need to install those specific versions. <rekado>can you show us the command you’re using? <NewGuixUser>guix time-machine --commit=v1.4.0 -- environment -m manifest.scm <NewGuixUser>and the numpy package is literally identical to what is in v1.4.0 except I changed the version string and the hash string <rekado>what does the manifest look like? <lechner>nckhexen / i get 'Unknown module 'var-lib-debbugs' wit the rsync command. is that because my IP is not whitelisted? <NewGuixUser>rekado: (specifications->manifest '("python" "python-numpy@1.19.0”)) <lechner>rekado / nckhexen / fyi, fsf is willing give me access, but they don't currently agree with my plan to merge Mumi into GNUBS, the yet to be named GNU bug system <NewGuixUser>and if I do "guix time-machine --commit=v1.4.0 -- package -s "python-numpy"" I do see numpy 1.19.0 and the location is my local file <nckhexen>Even if it's not, you can't just ignore the fact that your IP is not our IP, and you should talk to the debbugs admins first or you'll certainly get booped. <NewGuixUser>Or if anyone has any other suggestions about how to accomplish this I'm open to anything really. My only real limitation is that I have to use the exact versions currently included in our requirements.txt. <rekado>NewGuixUser: I’ll try to reproduce this <NewGuixUser>rekado: I can provide my numpy package definition if that would help <rekado>lechner: I don’t think it’s necessary to merge the two projects, especially not at this early stage. The backend that handles email processing could be blissfully unaware of the frontend, separated by a boring interface barrier. <rekado>if it’s going to be a complete rewrite you don’t need anyone’s permission anyway. <rekado>lechner: would you like a copy of some .log files that we’ve got for mumi? <rekado>NewGuixUser: is this meant to be used with the time machine or with a modern Guix? <rekado>I see this-package-input, which suggests the latter <NewGuixUser>I've been using time-machine. I took that package from v1.4.0 since that was on numpy 1.21, so pretty close to what I need <NewGuixUser>and I'm just kinda hoping that all of the other packages I need are also close on v1.4.0 <rekado>we’ve worked on older versions of numpy and Python in the guix-past channel <rekado>perhaps it would be worth building an old Python (and other old packages according to your requirements) on top of a recent Guix <NewGuixUser>I was originally trying to do that, but a lot of the build system stuff has changed in current guix <NewGuixUser>and "guix import pypi my-package@my-version" doesn't work for all of them since some are missing a requirements.txt <rekado>it’s also questionable to use old Python packages with current versions of openblas or GCC (for example) <rekado>after all the resulting behavior can be influenced by any of the nodes in the dependency graph <rekado>(which is why Guix doesn’t really give all that much importance to version strings) <NewGuixUser>honestly I have no idea what the graph is today, which is why I need to get this on to guix so I can guarantee it's consistent <NewGuixUser>all I know is pip is starting to struggle with older packages and gives inconsistent results <rekado>I believe it’s best to stay in the 1.4.0 world and define these packages in the manifest for that version of Guix. <rekado>NewGuixUser: yes, with more work done in the manifest. <rekado>NewGuixUser: I’m trying to define numpy with package transformations instead <NewGuixUser>I'm not sure I follow what you mean by doing more work in the manifest <achow101>also this is with guix time-machine at commit 160f78a4d92205df986ed9efcce7d3aac188cb24 <NewGuixUser>rekado: I'm trying it now, needed to add (gnu packages machine-learning) but it's running now <NewGuixUser>Ok I just took your most recent version and added coloredlogs to see if I'm understanding correctly <rekado>successfully built pandas at the specified version <rekado>it’s probably better to use these package transformations (at least initially) so you don’t need to mess with all that boilerplate of package definitions <rekado>once you’re happy with the environment I’d suggest moving to explicit package definitions to make this all future proof. <NewGuixUser>so do you expect these transformations will work for any python package? <NewGuixUser>the only other thing I need to guarantee, which I forgot about until now, is I need to get on Python 3.8.5 instead of whatever version is in v1.4.0 currently <rekado>then you’d need another transformation that replaces “python” (which is 3.9.9) with old-python, which you’ll define earlier with a package transformation. <rekado>but since a lot of things use Python (and not just packages that have the python-build-system) you’ll have to apply this transformation selectively <rekado>or else you’re going to have a bad time spent building all sorts of other things that happen to use Python in their build. <alxsim>achow101: I've recently got a getaddrinfo error that was due to selinux policy <NewGuixUser>I'm not going to have anything else in the manifest aside from those packages I listed earlier and python itself <lars```>Does anyone know if there is an alternative to nscd on foreign distros? <rekado>NewGuixUser: but transformations apply to the whole graph by default <NewGuixUser>so to get 3.8.5 do I just add guix-past to my channels and add python@3.8.5 to the manifest? <rekado>so even though your manifest doesn’t list other things like, say, inkscape your package graph might still include it <rekado>lars```: you’d need to do something like this: export LD_LIBRARY_PATH=$(guix build sssd)/lib <achow101>alxsim: interesting. I don't think I have SELinux setup since Arch doesn't seem to support it. <achow101>it actually looks like my issue might have been solved with a 'guix gc'. at least it hasn't errored in the past 30 minutes which is an improvement. <rekado>so you’d still use Python 3.9.9 to run a little script during the build of inkscape (or whatever) and reserve the use of Python 3.8.5 only for your Python modules. <NewGuixUser>so I'm not really sure what exactly I need to do. Do I need to do a transformation for 3.8.5? Or can I just add the guix-past channel and call it a day? <NewGuixUser>I did try to add the guix-past channel but now when I rebuild I'm getting "Computing Guix derivation for 'x86_64-linux'" which makes me think that time-machine didn't jump to v1.4.0 now <lilyp>NewGuixUser: You'd typically time-machien to when 3.8.5 was a thing. guix-past is for stuff older than time-machine, though perhaps there are exceptions <NewGuixUser>Well I don't think adding the guix-past channel even worked because my manifest doesn't recognize python@3.8.5 <lars```>rekado: didn't seem to help. I still get errors when applications try to use getaddrinfo <lilyp>Try 8944f1a4a4bfe65ad83d4926fbdbeb3e11ec7728 as commit for time-machine <NewGuixUser>I assume that has python 3.8.5? If so, how did you find it? <lilyp>git log gnu/packages/python.scm /3.8.5 :) <NewGuixUser>Well I'm running the build now with all of those package transformations, so hopefully it all just works <NewGuixUser>I'm seeing a lot of lines like "@ substituter-started". What exactly does that mean? <NewGuixUser>I'm guessing it's downloading from somewhere other than the typical upstream build server? <lilyp>uhm, no, it's doing the same stuff as always, though possibly at higher verbosity <nckhexen>Directly patching the script was too much work, it is too complex. <nckhexen>jaeme: Extra notes: please put it in the file alphabetically (so near the top); s|allanime|@uref{https://allanime.co/,All Anime}|; s| shell script|| <pkill9>im getting no output after running guix pull and it saying this: /gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory <pkill9>hmm, running `ldd /gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile` has "libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f7d7af89000)" in the list <NewGuixUser>lilyp: Ok good to know, I guess I've just never noticed it before with more typical builds <jpoiret>pkill9: are you running a vanilla daemon? <pkill9>jpoiret: yea, I think I just fixed it anyways, thanks <pkill9>I just ran guix gc --verify=repair <VesselWave>Or maybe someone knows how to create a new service-type in system definition?