IRC channel logs


back to list of logs

<redacted>Doesn't appear to be a way to programmatically create a swapfile. Is that correct?
<rekado>NewGuixUser: I think something else is going on. When you patch matplotlib’s you’ll find that even if you remove setuptools-scm* it will not even find numpy.
<rekado>I don’t know why this only happens for matplotlib and not for the other packages we’ve successfully built already
<rekado>I noticed one thing in the build logs that’s not right, though: python tk is for 3.9.9, not for 3.8.5
<rekado>oh… environment variable `GUIX_PYTHONPATH' set to `/gnu/store/iffaxh1y899wdh62f14wbmrnvvcq169j-python-pygobject-3.40.1/lib/python3.9/site-packages:/gnu/store/akhfk7wq2i8bkxlv8i6ra10cy0b7iq6l-python-3.9.9-tk/lib/python3.9/site-packages'
<rekado>that’s not right
<rekado>that explains it
<rekado>these two packages must also be rebuilt with python 3.8.5
<rekado>for some reason GUIX_PYTHONPATH is set *twice*
<rekado>once to the correct value, and then again for these two packages
<rekado>and that’s why none of the python modules are found
<rekado>the solution is to update the cut? procedure to include these two guys
<nckhexen>redacted: You might be right. Seems like you can only declare a swap-space-dependency on a file-system, not on your own service…
<NewGuixUser>rekado shouldn't the cut procedure already rebuild them since they're python packages?
<redacted>nckhexen: unfortunate. my vps doesn't have enough ram for `guix pull' without the swap space
<gx1>has anyone had any luck using those $10 generic wifi dongles on guix sd?
<nckhexen>redacted: Understandable, but (why) isn't manually creating a swap partition or file an option?
<NewGuixUser>Oh wait I think I get it after re-reading your message
<redacted>nckhexen: it's an option, I'm just trying to make my deployments as fire-and-forget as I can manage
<NewGuixUser>So matplotlib is resetting the GUI_PYTHONPATH env var when it gets rebuilt, causing the required 3.8 packages to not be found.
<rekado>I have removed pygobject but python-3.9.9-tk still needs work
<rekado>it’s an output of the python package
<nckhexen>redacted: Note that I haven't actually tested whether there's an ordering issue, only glanced at the code; actually writing a system service that truncates a swap file should be trivial if you can get the swap-service to depend on it.
<rekado>looks like a bug in the package transformation code to not have python:tk rewritten.
<rekado>this gets us past matplotlib, but it fails in scipy
<rekado>got to go now
<rekado>more tomorrow!
<NewGuixUser>Thank you so much, in the meantime I'll look at scipy and see if I can figure anything out. I'll just go down the list of the issues we've come across so far and see if it looks like any of them apply to scipy.
<jaeme`>What's the equivalent of 'mv' in Guix? I want to both copy and rename and config file to a package's /etc directory.
<redacted>> web/client.scm:84:6: Throw to key `gnutls-not-available' with args `("(gnutls) module not available")'.
<redacted>not sure how to make gnutls available
<redacted>wrapping the script's code in (with-extensions (list guile-gnutls)) still gives me the error
<redacted>installing gnutls and guile-gnutls globally doesn't help either
<Guest1>Hello everyone,
<Guest1>I installed Guix a HDD and worked on it for a while and then I installed windows on my other sdd. Now I installed windows on my other disk and updated my bios. The problem is, that I cannot boot from my Guix hdd. I get the message "reboot and select proper boot device, when I start from my Guix hdd. Any ideas how to fix this problem?
<Guest1>do I need to reinstall grub on my Guix hdd?
<Guest1>I feel a bit lost here, I really would like to start my system in Guix again.
<mirai_>redacted: can you paste snippet?
<redacted>mirai_: ok
<redacted>It seems that (web client) needs gnutls for https connections
<wdkrnls>Dear Guix, any tips for launching another Emacs server inside of Emacs?
<wdkrnls>I think Guix may be setting some extra environment variables which is messing up the launched Emacs macro expansions.
<wdkrnls>Specifically, things like "EMACSLOADPATH".
<wdkrnls>Maybe there are only four to worry about.
<mirai_>redacted: huh, it should work
<mirai_>my script does a very similar thing to yours
<wdkrnls>Nevermind, I figured out some elisp to remove those environment variables mentioned in the Guix emacs package definition.
<NewGuixUser>rekado: I looked into that scipy issue as best I could and thought that it might be an issue with pybind11 overriding an environment variable so I did the same as what you did for pygobject to see if it would fix it. It did not work so either that wasn't the issue or there's something else going on in conjunction with it.
<nckhexen>Guest1: It does sound like Windows or something else wiped GRUB, if you're sure you're selecting the right HDD from your BIOS boot menu (you do mean BIOS, not UEFI, right?). It's not *that* hard: boot the Guix System installation ISO, select a shell, then manually invoke grub-install on said HDD.
<Guest1>nckhexen thank you for the answer, i reinstalled Guix, I did not see the shell option during install :)
<nckhexen>That'll work too!
<nckhexen>I think it's one of the very first menus. It has 3 items. I'm only confident because I recently booted the installer. Let's hope you don't need it again.
<Guest1>nckhexen ty, will be more careful next time, good to know
<Guest1>I just install flatpak run com.dropbox.Client. When running it, I get the error Failed to call portal: GDBus.Error:org.freedesktop.DBus.Errror.UnknonMethod: No such interface ?org.freedesktop.portal.OpenURI? on object at path /org/freedesktop/portal/desktop
<Guest1>I installed xdg-portal, but it did not help. Any idea, how to solve that?
<podiki>Guest1: you need xdg-desktop-portal-gtk (or wayland one), and then a relogin or reboot is a good idea, i always have bad luck with dbus
<Guest1>Guest1 actually I did already, but it did not help. Same error.
<podiki>(and/or -kde one if you are on kde?)
<podiki>which package exactly? and you relogged in?
<Guest1>podiki I am using i3 , but kde I also tried and it did not work
<Guest1>podiki yes, I did, package is com.dropbox.Client
<podiki>i3 on xorg? then xdg-desktop-portal-gtk is the one (and only) you should need
<Guest1>podiki from flathub
<podiki> the portal packages are on the guix side, to be clear
<Guest1>Guest1 I just did the standard installation, I think it is on xorg
<podiki>and you may need to make sure i3 is being launched with dbus, personally i use my own start script for wm and call dbus-run-session <mywm>
<podiki>anyway, have to run but those are the ingredients: make sure dbus is running your session, and xdg-desktop-portal-gtk installed
<Guest1>podiki can you share you script please
<podiki>i use xinitrc-xsession as my xsession file (also packaged on guix), and you can see all my dots here (guix config there too), though some out of date. ignore the i3 that was long before guix
<peanuts>" at master ? podiki/ ? GitHub"
<podiki>night guix!
<Guest1>podiki thank you, night!
<rekado>sneek: later tell NewGuixUser It was a problem with pybind11:
<rekado>sneek: later tell NewGuixUser It’s done:
<sneek>Will do.
<attila_lendvai>custom shepherd actions (i.e. herd my-action my-service) are executed as root, right?
<attila_lendvai>i have an action that calls tar, and it works fine if i copy-paste it from the log into a root prompt, but otherwise i get a 127 exit code. without --gzip it also work. PATH contains coreutils and gzip.
<attila_lendvai>s/otherwise/from the custom action/
<attila_lendvai>it is started using system, and the PATH is printed from the action. i assume the forked bash inherits the PATH.
<attila_lendvai>the exit code is 127, which probably means command not found
<attila_lendvai>and the worst part is that it works in a guix system vm where i'm normally testing this, but fails when i guix pull it on my server... :/
<attila_lendvai>tried to avoid any use of PATH, and it still returns exit code 127, but if i copy-paste it into a root prompt, then it just works as expected. i have no idea how to debug this.
<futurile>morning Guixers
<mekeor>hello. when installing emacs-packages --with-input=emacs-minimal=emacs-next, guix' emacs-build-system provides precompiled .eln-files. .eln-files follow the pattern {name}-{path-hash}-{content-hash}.eln. unfortunately, the path-hash of the .eln-files provided by guix does not match emacs' expectation; thus, emacs native-compiles world. am i the only one experiencing this issue?
<attila_lendvai>mekeor, random guess: there are simply no substitutes for that non-standard --with-input config? did it ever work before?
<mekeor>attila_lendvai: i'm not expecting any substitutes. i just expect the package that guix builds to contain .eln-files that match emacs' expectations.
<mekeor>attila_lendvai: yes, this was working for me, until just a few days/weeks before.
<gabber`>is the location of the env binary in `/usr/bin/' a guix-local convention or is this part of a standard or wider convention?
<mekeor>gabber`: it's a very common thing in unix. idk if it's standardized
<gabber`>i'm reviewing code right now where someone uses `/bin/env` (sic) and i'm wondering whether that actually exists on some platforms
<efraim>Perhaps with merged-usr, but even having /usr/bin/env on guix system is customizable
<mekeor>oh yeah the manual explains that it's provided by the default configuration for special-files-service-type
<mekeor>see (info "(guix) Base Services")
<jpoiret>gabber`: env is not mentioned in the FHS sections for /bin and /usr/bin
<jpoiret>so purely convention it seems
<gabber`>jpoiret: yeah, i checked FHS -- that's why i'm wondering...
<gabber`>i guess i'll have to figure out with the person whose code i'm reviewing what makes most sense
<civodul>ACTION reconfigures berlin & the build nodes
<cbaines>I'm sitting around waiting for the data service to finish, so if anyone wants to do some patch review, I can take a look at committing things
<apteryx>off-topic, but is it me or the duckduckgo search results have gone downhill recently?
<attila_lendvai>apteryx, i'm not sure, but as one data point, i have switched to a few months ago (which is i think anonymized google).
<efraim>Looking at the rust patches from this past week I think I'll have to pull them into the rust-team branch
<cbaines>here's an experimental QA page on a specific topic, reproducible builds in this case
<peanuts>"Reproducible builds Guix Quality Assurance"
<cbaines>this is probably a better thing to link to from than the current "Continuous Tests" link
<civodul>cbaines: wo0t! very nice!
<civodul>i agree it would be nice to patch the R-B web site to link to that
<civodul>apteryx: depends: IceCat redirects to, which gives poor results, but gives good results
<civodul>in other news, Cuirass 1.2.0 deployed on berlin + x86_64 build nodes
<guix-noob>Hi people. I am starting with guix as a package manager and want to package own programs. I read parts of the manual and cookbooks and watched videos. Unfortunately I am a bit confused now and have many questions.
<gabber`>guix-noob: if you asked them here you might get some answers ;)
<guix-noob>First question: When I wrote a little program and want to package it, where does the guix package definition go? Should it go into my program's project directory? Seems like it is the other way around and I define where guix could fetch the program's source from in the package definition. But then where does the package definition itself should be
<guix-noob>located at?
<guix-noob>I am talking of local development so far. Publishing will come at a later point.
<gabber`>you can create a guix.scm file in your source tree and then call $(guix build -f guix.scm) in there
<gabber`>if you intend to publish your package definition in a channel, you will have to clone that channel's repository, make your changes in there. you could then test these with $(guix build -L path/to/that/checkout you_package_name)
<guix-noob>Mhm, but what's the point of telling guix where to get the source from?
<gabber`>the former way (-f option) tells guix to build whatever is defined in that file, the latter (-L option) tells guix to include a directory in its load path
<gabber`>i don't understand your last question
<guix-noob>I mean when I put the package definition in my source tree, why telling guix then where to get the source from. If I cloned my source to get the package definition the the actual program source is already there, too.
<snape>the usual case is: the source is somewhere on github, gitlab, etc
<snape>in your case the source would be a local directory
<snape>there is no default, so you have to tell guix about it
<gabber`>Ah, you can omit that, by putting (source #f) or (source (local-file "." #:recursive? #t))
<gabber`>in your package definition
<snape>are those equivalents?
<gabber`>the source field tells guix where to get the sources from. guix then (if the field is not #f) copies the source to the store (if it isn't already there)
<guix-noob>Okay I will note that an look it up in the API manual.
<guix-noob>I actually want to do Scala development with guix, but Scala isn't packaged in guix, yet. Maybe it isn't bootstrapped from zero, yet.
<gabber`>nb: i usually start building locally by creating a manifest file and hit (depending on my project, but usually) execute `make` into that shell.
<guix-noob>If I would build a package with the scala binaries, is there any reason that it would not be allowed to be published in guix?
<gabber`>Guix does not (as a policy) make use of pre-produced binaries.
<gabber`>but since it is super easy to make use of other channels it could be made use of in an other (or a separate, new, scala specific) channel
<gabber`>but getting Scala into guix should be the main goal (:
<guix-noob>I would start with some easier tasks anyway. How about building a Java Hello World package.
<Lumine>Sounds complicated. :P
<guix-noob>I saw there are build-systems for the build tools Ant and Maven. But I would like to get read of those build tools and use pure guix instead. That's one of the reasons to use guix in the first place. A simple java package would depend on the JDK. And guix would have to call the java compiler and pass the sources. Would I have to implement a guix
<guix-noob>build-system that does that or can I do that without an extra build-system just in the package definition?
<graywolf>I cannot built linux-libre-lts, is that problem on my part?
<gabber`>graywolf: have you done some funky things? what's the error?
<peanuts>"debian Pastezone"
<graywolf>Not that I am aware of
<graywolf>weather shows no substitutes
<gabber`>you can always check whether builds have worked on official build infrastructure
<gabber`>ewww, that implies that the source checksum is wrong (or has been tampered with)
<graywolf>Aaand it did not. Cool, not a fuck up on my end
<graywolf>I think the patch was just wrong, the deblob checksum was not adjusted with the version bump
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<gabber`>would you mind either opening a bug report and/or submit the patch fixing the issue while you're at it?
<graywolf>lechner: I wonder if peanuts needs to repeat the url, maybe the title is enough?
<graywolf>Will send a bug report, my patches do not have a high acceptance rate, so bug report will likely be faster
<graywolf>Shit, I cannot send emails (I updated my system :D it was a mistake); eww, ugly report will be sent from gmail
<gabber`>i am somewhat convinced that a patch like this would probably be accepted and streamlined within minutes -- i think (from a quick glance over this affects multiple versions?
<HexMachina>Hi guix! I'm running into a segfault with bpftrace and wondering if it's because I'm on a foreign distro, or if folks on guix system are affected too: guix shell bpftrace; sudo $(which bpftrace) -e 'tracepoint:syscalls:sys_enter_openat {}'
<HexMachina>The bpftrace script is irrelevant, every -e '...' I've tried segfaults immediately
<HexMachina>I've tried some minor debugging with `guix shell valgrind bpftrace --with-debug-info=bpftrace` and re-running the command under valgrind; the segfault seems to happen deep in the guts of the c++ std library after accessing uninitialized memory.
<old>I have in my system configuration a `(extra-special-file "/bin/bash" (file-append bash "/bin/bash"))' because I work on projects that have #!/bin/bash everywhere
<old>I wonder two things here
<efraim>HexMachina: I'm on the train ATM, does it will happen with grafts turned off?
<old>1. If I want to use another version of bash for the project, I can't because it is using the system version. Is there a way to change this, perhaps in a container?
<old>2. Is /bin/bash a standard on Linux? I'm pretty sure /bin/sh is
<graywolf>old: guix shell -C -S bash=/bin/bash could work for the different version
<graywolf>/usr/bin/env bash is a "standard", after that I would say /bin/sh; /bin/bash is a thing, but in my experience less common
<old>grundle: okay so container is the way
<old>graywolf: * sorry
<unwox>HexMachina: i think in the command you gave "$(which bpftrace)" executes before "guix shell bpftrace"
<old>graywolf: do you happen to have a link for the /usr/bin/env bash being a standard ?
<graywolf>No, because technically speaking there is no standard. Hence the "".
<unwox>to execute something inside the shell use -- (with spaces before and after) instead of ;
<graywolf>It is customary location, but strictly speaking there is no portable, always-there-by-spec, path
<old>graywolf: Right. But IIRC, there is actually a standard for #!/bin/sh I think
<old>Like, it is mandatory
<graywolf>If you find it let me know.
<graywolf>I am not aware of it, but it is possible I just failed to find it.
<bjc>the /usr/bin/env is a posix thing, iirc. bash has no “standard” location. /bin/sh is also required by posix but that isn't necessarily bash, and bash isn't 100% posix sh compatible
<graywolf>bjc: Would you have a link where in POSIX is this said? I remember looking and not finding.
<bjc>it's posix.1
<bjc>i can't remember where, but it's old. basically everything breaks without it
<graywolf>Maybe the hold in posix.1, but in 2017 volume I see: Applications should note that the standard <i>PATH</i> to the shell cannot be assumed to be either <b>/bin/sh</b>
<graywolf>I don't think the /bin/sh is mandated. Everyone thinks, so, therefore it works, but I never managed to find a line in posix actually mandating it...
<graywolf>thinks so*
<bjc>i don't have my posix.1 book anymore so i can't check
<HexMachina>unwox: the sudo $(which bpftrace) is executed inside the guix shell; it's necessary because bpftrace needs to run as root, but root doesn't have the same PATH, so I have to resolve the path to the local bpftrace and run that explicitly with sudo
<HexMachina>efraim: I still get the segfault with `guix shell --no-grafts bpftrace`
<bjc>posix apparently doesn't define ‘#!’ either, so i guess it's all moot
<gabber`>i seem to be able to confirm the /usr/bin/env being a POSIX thing rumor. there is a mention in gnu coreutils, though:
<peanuts>"env invocation (GNU Coreutils 9.4)"
<gabber`>maybe it's a GNU thing?
<unwox>HexMachina: ok, right, i get the segmentation fault error too
<bjc>the safest assumptions, imo, are that ‘#!/bin/sh’ are a bourne-compatible shell, and if you need bash, specifically, use ‘#!/usr/bin/env bash’
<old>Anybody ever got a: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate
<old>when running Python in a container?
<bjc>on freebsd, for instance, you'll find bash in ‘/usr/local/bin’, if it's even installed at all
<gabber`>old: do you have networking enabled in your container?
<HexMachina>unwox: thanks for testing! Are you on guix system or a foreign distro?
<old>gabber: Yes. I'm running a Python binary installed from pip
<old>maybe there is something missing related to certificates that needs to be put in the package list of the guix-shell
<unwox>HexMachina: i'm on guix system so it's probably not related to you being on foreign one
<gabber`>old: nss-certs, usually
<gabber`>but to answer your question: no, i have not experienced that failure (probably because i usually don't run python in a container)
<NewGuixUser>rekado: Thank you I'm trying it now. I had accidentally tried to modify python-pybind11 instead of pybind11, so that's part of my problem
<sneek>NewGuixUser, you have 2 messages!
<sneek>NewGuixUser, rekado says: It was a problem with pybind11:
<sneek>NewGuixUser, rekado says: It’s done:
<old>gabber`: I have to for now because the package has not been packaged for Guix yet (I'll do it later)
<old>And I do not specially trust packages coming from pip blindly
<gabber`>i get that. maybe (i have no expertise in saying that, like at all) packaging it for guix makes the package misbehave less. packaging pip packages that use python-build-system is relatively painless IMO (there i have some expertise)
<old>I will try that
<old>oh now that is crap. The software I'm using is Pyright (Python static checker) and is actually implemented in Typescript
<old>the portion that crashed is telemetry sent to Microsoft to see if I have the latest version of the software
<gabber`>ACTION cringes
<gabber`>that should be easily patchable (and by patching i mean removing)
<unwox>HexMachina: bpftrace was last updated to 0.18.1 on September 10, maybe try time-machining to any commit before that?
<HexMachina>I was looking around and found this debian bug, which looks like a similar issue:; they had to change libbcc to compile with -DENABLE_LLVM_SHARED=on. I tried to test this by defining my own bcc package that added this configure flag, but then the build fails in the link step doing a "-lLLVM" because it can't find that library to link
<peanuts>"#977549 - bpftrace: all programs fail with Segmentation fault - Debian Bug report logs"
<HexMachina>I tried adding llvm-9 to the package inputs, but that didn't work. Not sure if I'm going down the right path or not, maybe there's another package input I need to use instead? I've only done very basic packaging in guix
<gabber`>HexMachina: if you refer to the package by string, you might need to use the @ notation (i.e. "llvm@9.0.1")
<NewGuixUser>rekado: It looks like everything is correct except for pytest, for some reason I'm seeing "This is pytest version 6.2.5, imported from /gnu/store/548bkq42cxlajxj6acli1c3wy3lwl87f-python38-pytest-5.4.3/lib/python3.8/site-packages/pytest/" when I do "pytest --version". So for some reason 6.2.5 is being installed when it tries to install
<NewGuixUser>5.4.3. It doesn't look like the same issue as with python-pygobject and pybind11. I'll look at it some more today.
<radio>I came here some days ago relating a problem where, after a guix pull and guix home reconfigure, my telegram stopped working, no errors whatsoever, the process just didn't spawn
<radio>I was oriented to switch the pull generation temporarly and reconfigure my home there, and it worked
<radio>Some days passed, and I pulled again, and the telegram issue it's solved
<radio>But now the exactly same thing happens to mpv
<gabber`>have you opened a bug report about the telegram issue?
<radio>I haven't :/, but I know I should
<radio>I may do it for mpv today
<gabber`>how do you know it's the *exact same* issue?
<radio>I mean, from a user point of view, is the same issue. I get no errors to know what is happening, the process just doesn't spawn
<radio>I have no way to gather further information without errors or logs
<gabber`>how sure are you your environment (in this case desktop) is configured correctly?
<gabber`>is /var/log/messages empty? have you checked your desktop-environment's log?
<radio>I'm pretty sure I haven't any strange configuration that could affect these applications
<radio>nothing mpv related on /var/log/messages
<gabber`>i have a "./.cache/gdm/session.log" that contains a bunch of log messages
<radio>I don't use a display manager or a desktop environment, just a standalone wm
<gabber`>~/.cache/gdm/session.log that is
<rekado>NewGuixUser: the pytest thing is due to this line:
<rekado>it’s a lie
<peanuts>"check.scm\packages\gnu - guix.git - GNU Guix and GNU Guix System"
<gabber`>that /might/ be the root cause of your problem. the desktop manager does a bit more than just start yourm WM (like setting some necessary variables)
<rekado>in newer code we use #$(package-version this-package), which will do the right thing
<radio>Which ones, for example?
<gabber`>i have not the slightest idea
<radio>I hadn't this problem for almost 8 months using guix
<rekado>here we modify the python-pytest package and recursively rewrite its inputs and change the #:python argument. But we don’t change the build phase that embeds the package version of the original python-pytest package.
<radio>Only recently it started happening
<rekado>so it’s just a cosmetic issue.
<gabber`>radio: what WM are you using?
<radio>awesome wm (I really don't think this have to deal with the problem)
<radio>running mpv --help on tty give me no output
<gabber`>that uses X, right? i am on sway (wayland) but running `env` gives me a bunch of variables that might need setting before applications work correctly: XDG_SESSION_DESKTOP, XDG_SESSION_TYPE, DBUS_SESSION_BUS_ADDRESS, and lots of others (i really have no clue about these things)
<gabber`>you could (cough) strace your application call to see what actually happens
<radio>Ok, but running mpv --help on a tty should give an output, shouldn't it?
<radio>hm, i'll try to strace it
<gabber`>if you want to check (and maybe solve in a timely fashion) if that would solve your problem you could (temporarily) install a desktop manager
<radio>execve("/home/radio/.guix-home/profile/bin/mpv", ["mpv", "--help"], 0x7ffc7f379068 /* 84 vars */) = -1 ENOEXEC (Exec format error)
<radio>strace: exec: Exec format error
<radio>+++ exited with 1 +++
<radio>The strace output
<ieure>The binary is for an architecture that isn't the one you're running.
<NewGuixUser>rekado gotcha, thank you
<radio>ieure: How?
<gabber`>radio: what does $(file `which mpv`) output?
<ieure>radio, No idea, but that's what the error means.
<ieure>Yep, paste that, also the output of `uname -a`.
<radio>/home/radio/.guix-home/profile/bin/mpv: symbolic link to /gnu/store/fqxxf5kdjf6d67szgh5rz64mzkxwm2yx-mpv-0.36.0/bin/mpv
<radio>Linux buer 6.5.7-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux
<ieure>Run `file /gnu/store/fqxxf5kdjf6d67szgh5rz64mzkxwm2yx-mpv-0.36.0/bin/mpv`
<NewGuixUser>rekado I think I just have one last question for you. How reproducible is the whole "with-source" transformation? If one of those pypi downloads is broken, will guix still fall back to software heritage or will it just fail since this is a transformation and not a "real" package? If I want to make all of this "safer" or more reproducible would the
<NewGuixUser>next step be turning each of those "with-source" transformations into actual packages in my own channel?
<radio>ieure: /gnu/store/fqxxf5kdjf6d67szgh5rz64mzkxwm2yx-mpv-0.36.0/bin/mpv: empty
<radio>how could it happen?
<gabber`>that might be a hint towards the no output thing ;)
<gabber`>try the same thing in a $(guix shell mpv) ?
<gabber`>out of curiosity: what's the size of that empty mpv?
<radio>gabber: yes
<radio>gabber: 0
<gabber`>what commit are you on? -> $(guix describe)
<radio>This is my current commit: 7e9783b2ab8c747ef340daa749bdeba9e924ec57
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<radio>haha, was sending just that
<rekado>NewGuixUser: personally, I’d replace the with-source stuff with explicit origins that have hashes
<rekado>we need those hashes to be able to look up source code by content
<rekado>this would allow future you to get sources via different URLs as long as the hash is identical
<rekado>(e.g. with “guix download” or through Software Heritage)
<gabber`>ACTION tries to build that mpv
<HexMachina>unwox: I dropped back to bpftrace 18.0 by picking the commit just before it was upgraded to 18.1: guix time-machine --commit=56790b9dbca9add9a66d2c9e38969031a880c2b6 -- shell bpftrace
<HexMachina>and it still segfaults the same way :(
<HexMachina>maybe it's been broken for a while... the bpftrace package has #:tests? #f, so it could have been an issue for a while
<HexMachina>(although this was the first time I've used guix time-machine, so yay for that and I'm very impressed that things like that are possible in guix)
<NewGuixUser>rekado: Is that possible with a package transform, or would I need to inherit the package and replace the source and hash expressions?
<NewGuixUser>I'm looking at the package transformations and package variants sections in the docs and it looks like defining a package variant is what I need to do, but I'm not sure how complete the transformations docs are
<gabber`>radio: i get the same hash with a working mpv binary
<gabber`>(at least there's text output when invoking it without arguments, i haven't tested it any further)
<gabber`>i guess you installed it in one of the usual ways?
<radio>It's just declared on my home packages
<peanuts>"radix/radio.scm at main - radix -"
<gabber`>radio: what happens if you $(guix build mpv) (with an optional --rounds=2)?
<radio>Let me see
<radio>It simply returns me an already built store item
<radio>And I can't gc it because it says it's still alive
<gabber`>ah, --no-substitues
<radio>Yeah, I tried with that too
<radio>Just returns the same store item
<gabber`>what about --repair?
<radio>I tried it too
<radio>same store item
<gabber`>i'm sorry, i'm waaay out of my field of expertise here
<radio>I'll reboot the machine to see if I can gc the item
<radio>be right back
<gabber`>you won't be able to gc the item as long as a profile you are using points to that build
<radio>No, I can't, it's still alive
<gabber`>you just missed my last messages.. that is how it is designed
<gabber`>as long as one of your profiles uses that build it won't be gc'd
<radio>Yeah, you're right
<radio>I'll run gc on everything to clean the profile of the guix shell that built it
<radio>It seems to consistently generate the same empty binary
<gabber`>what architecture are you on?
<radio>I gc'ed 3 times, and ran `doas guix build mpv --repair --rounds=4` 3 times
<radio>The most common one, probably
<gabber`>and does it actually build it (it took a couple of minutes on my relatively beefy machine)?
<radio>Let me run it again with no-subs
<elevenkb>Hello there, I'm a bit surprised that cargo build --release takes a lot less time than guix build for a guixified version of some package.
<elevenkb>I wonder why that is, just out of curiousity for now.
<radio>the build fails
<gabber`>radio: now that's interesting (it worked on my x86_64 machine)
<gabber`>what does it tell you (either check the logs or run it with `--verbosity=3`)?
<futurile>elevenkb: does cargo build --release compile all the dependencies, or use binary crates?
<radio>Yeah, it fails consistently when using --no-substitutes
<radio>There's nothing substantial in the build log, strangely:
<radio>[ 1/ 2] Loading './guix/build/utils.scm'...
<radio>[ 2/ 2] Compiling './guix/build/utils.scm'...
<radio>And that's it
<elevenkb>futurile: how could I tell?
<vivien>cbaines, congratulations for your NLNet funding!
<elevenkb>cbaines: w00t! nice win!
<futurile>elevenkb: well I think my Google searches are showing that Rusts cargo does compile dependencies from source. But, if it has the library already it caches it. I think that the cargo-build-system doesn't do that - it does a clean compile each time.
<janneke>when running system init with grub-efi-bootloader, do i need (targets (list "/mnt/boot/efi")), i.e., where it's mounted right now?
<janneke>or (targets (list "/boot/efi")), where it will be mounted later?
<janneke>hmm, tried both and the disk is still not bootable
<janneke>oh wait, the bios possibly needs to know about efi right
<apteryx>civodul: ah, I'm using that page (IceCat)
<apteryx>weird that a js version of it would change the results
<Andronikos>Lets see if 32 kbit/s is enough for IRC. I have trouble with the home-files-service-type. (".xinitrc" ,(local-file "./.xinitrc")) returns guix home: error: invalid name: `.xinitrc' but other files that start without a dot work out of the box.
<Andronikos>I initially tried with a simple ".xinitrc" which returns the same. The current ./ I tried since the manual uses that syntax.
<the_tubular>rekado, sorry for the ping. Just google'd into guile-aws, any clue if it still works ?
<nutcase>janneke: I'm not sure, if this answers your question, but I have this in my system configuration:
<peanuts>"debian Pastezone"
<Kolev>What's the command that unblocks Wi-Fi?
<jackhill>Kolev: rfkill?
<rekado>the_tubular: yes, it works all right. I’ve been using it for EC2 mostly.
<rekado>NewGuixUser: here’s a version that specifies hashes and explicitly replaces source and version fields:
<the_tubular>Was looking for a Secret Manager client, you think that's a good option ?
<the_tubular>I wish guix had better ways to deal with secrets :/
<rekado>the_tubular: uhm, what? You want to use AWS Secret Manager with … Guix?
<the_tubular>Yeah, that's my plan
<the_tubular>Unless there's better way of doing this
<rekado>what exactly are you trying to do? Local storage of secrets in an encrypted file not enough?
<Guest22234>i just am reconfiguring first time and i am stuck here:
<Guest22234>building /gnu/store/9n8c3gm1n6qy049p8n4hp3g9cfzja47c-linux-libre-5.15.137-guix.tar.xz.drv...
<Guest22234>Can anyone help please
<peanuts>"debian Pastezone"
<Guest22234>is 5.15 not any goodc
<the_tubular>Yes, also keep them in sync with what I have on the cloud side
<rekado>Guest22234: building this takes a long time, no wonder it appears to be stuck.
<rekado>Guest22234: but… why aren’t you getting binaries for this?
<rekado>I’m getting a binary from for this very same derivation.
<rekado>the_tubular: I would accept a patch that adds support for the Secret Manager API
<rekado>Guile AWS just compiles the upstream JSON to Guile, so it should not be too difficult to add. (Unless it’s a weird API like that of S3…)
<Guest22234>rekado thanks i did not know ita takes long. i will wait thank you
<rekado>Guest22234: it’s going to take even longer
<rekado>that’s not the kernel you’re building there
<rekado>that’s the *source code* for the kernel
<rekado>are you not using binary substitutes on purpose?
<Guest22234>rekado no, i did not know i can do this. Can you recommend, how i read about it
<rekado>how did you install Guix?
<Guest22234>rekado yes
<Guest22234>it aborted btw
<Guest22234>cannot build derivation `/gnu/store/rmfkqkhlv0lvifsix4fj0x90ip8n5z7h-linux-libre-5.15.137.drv': 1 dependencies couldn't be built
<Guest22234>guix system: error: build of `/gnu/store/rmfkqkhlv0lvifsix4fj0x90ip8n5z7h-linux-libre-5.15.137.drv' failed
<Guest22234>anbody an idea
<Guest22234>dave@host /etc$ cat /gnu/store/rmfkqkhlv0lvifsix4fj0x90ip8n5z7h-linux-libre-5.15.137.drv
<Guest22234>i really do not understand, i have been using this config bfore
<rekado>please don’t paste all this here
<rekado>the contents of the derivation file don’t tell us anything
<rekado>the file looks identical everywhere
<rekado>you haven’t answered my question above, so I cannot help you: how did you install Guix?
<Guest22234>rekado sorry. i installed from usb
<Guest22234>rekado and then i pasted my config and reconfigred, then i did guix pull and reconfigured again
<Guest22234>rekado i am in guix right now
<rekado>please check if you have binary substitutes enabled
<Kolev>jackhill, thanks. rfkill. My Wi-Fi gets shut off at software level and I have to reboot.
<graywolf>Does opensmtpd segfault for anyone else or is that just me? Git bisect points to b6e8d587c4551f0fd28fcef96f33909a8ab8e9df (which makes sense).
<peanuts>"guix.git - GNU Guix and GNU Guix System"