IRC channel logs

<dtx>root@2c2bf9d770e6 /# herd start urandom-seed

<dtx>herd: error: exception caught while executing 'start' on service 'urandom-seed':

<dtx>In procedure add-to-entropy-count: Operation not permitted

<dtx>Actually, now that I think about it, maybe neither of these are too needed

<dtx>networking is stopped as a result as well though.

<lfam>In general, the urandom-seed-service is useful to help the system boot quickly and improves security. But if you understand what does, you can decide to turn it off

<lfam>What it does

<civodul>dtx: i think you’d have to drop these services, because they don’t make sense in a container (and cannot really work)

<lfam>My Git problem was caused by an old `git bisect` session that I had started on the branch in question and never reset

<lfam>Relevant bug report: https://lore.kernel.org/all/CAEYvas=baW9DWQY4_MJ2-Hh0=yYwH2tGeOOwkcJr3wETCKpy4w@mail.gmail.com/T/

<homo>I notice that audio works by default without using anything from gnu/services/sound.scm, is it ok to deprecate it?

<RavenJoad>Is there any way to build a channel without pulling it? I have a file in my personal channel that uses an unimported symbol and want to quickly find out which file.

<Deltafire>for some reason system reconfigure is taking a very long time in "Indexing objects.."

<clone>RavenJoad: you could cd into your channel directory and run "guix repl -L ." then ",import (guix build utils)" and "(for-each load (find-files "." "\\.scm"))"

<lfam>Debbugs has surged past the 70000 mark!

<unmush>does anyone know why our libjit uses https://git.savannah.gnu.org/r/libjit.git? How does this differ from https://git.savannah.gnu.org/git/libjit.git?

<RavenJoad>clone: Ah ha! That's a good one! I like it!

<apteryx>ACTION wonders if the properties on gnutls are needed at all -- if I delete them, the package updates fine anayway.

<apteryx>related commit: 79be44fb51b3055d1801835dccb9ec8c8d16692e

<apteryx>I guess the upstream name is useful for the derived variants

<apteryx>not sure about the release-monitoring-url

<dtx>Is there like a dummy-networking-service-type that I can use inside a containerized guix system that just doesn't try to configure the network itself?

<dtx>Ugggh... there is a dummy-network-service-type but it's not exported in guix/gnu/system/linux-container.scm

<RavenJoad>dtx: You can always use @@ to get at it, even if it isn't exported. Just know that there be dragons.

<dtx>omg, the problem was I wasn't passing --network to my "guix system image" command to create the docker image

<dtx>it does say: -N, --network for 'container', allow containers to access the network

<dtx>so I guess at the time I assumed that it didn't apply to the 'image' command

<dtx>Thank you @RavenJoad , but luckily that's not needed now. lol

<RavenJoad>Can I access this operating-systems' groups list inside the definition of this operating system? I want a file-system entry to have the option "gid=<users-gid>" present in the options string. This is not important if this is impossible, I just want to amek sure I'm not doing something silly.

<RavenJoad>I already have (options (string-append "gid=" (user-group-id (find ... (operating-system-groups this-operating-system))))), but that fails.

<unmush>in which way?

<unmush>I imagine it's either complaining about this-operating-system not existing or trying to call string-append with #f

<RavenJoad>unmush: Sorry. I should have included the error I was getting. "guix system build" is throwing this: "guix system: error: this-operating-system: cannot be used outside of a record instantiation"

<unmush>ah, yeah, sounds like the file-systems field probably isn't thunked then (delayed evaluation until it's actually accessed)

<unmush>what you could do is define your groups in a variable outside your operating system expression and have both the groups field and the file-systems field reference that

<RavenJoad>unmush: Looking at (gnu system), you're right. groups is eagerly evaluated (no (delayed) present).

<RavenJoad>Yeah, I was just hoping to avoid capturing the group number (which I can assign above) because that would require me to do something. I was hoping I could rely on Guix to capture that number on its own. Oh well.

<s777>Hello, I am trying to compile guix from git, but I keep getting an error that looks like "contributing.ru.texi:1162: @node `???????????? ????????????' previously defined" and "guix.ru.texi:5868: here is the previous definition as @node" repeatedly

<apteryx>s777: maybe try ./bootstrap

<apteryx>ah, actually no, that error is because you need a more recent tool

<s777>apteryx: Which tool do I need to update? (I already ran ./bootstrap)

<s777>I also can't build guix through the package manager so I'm trying to figure out if this is related.

<s777>I ran all the steps on this page, both on an older version of the repo that I did `git pull` on and a fresh clone https://guix.gnu.org/manual/en/html_node/Building-from-Git.html

<s777>Am also on Fedora Asahi Remix (aarch64) host distro

<david95>Hello everyone. Can anyone from Guix developers help GNUtoo with building Guix for Parabola? I saw a message on the site that there are problems https://labs.parabola.nu/boards/4/topics/1963. Thanks in advance. Now I understand why I couldn't install Guix from the repository to work right out of the box

<levity>hi folks, i observe that issues.guix.gnu.org is down so I must bring to you my tale of woe though I reckon it's not unique

<levity>to wit: packages listed in `guix package -I' are old versions, but `guix package -u' says 'nothing to do' but it's not true!

<unmush>old versions with respect to... what you see on the package's sites, or what?

<unmush>that is to say, you've tried running 'guix pull' to get updated package definitions, right?

<levity>the versions stated in guix package -I are older than those reported as "latest' on packages.guix.gnu.org

<levity>have run guix pull, sudo -i guix pull and then restart guix-daemon then guix package -u

<levity>but still the latter replies 'nothing to do'

<unmush>and what does 'command -v guix' say?

<levity>'/usr/bin/guix/'

<levity>this guix is a foreigner within debianland

<unmush>I believe you may be interested in chapter 4 of the guix manual

<unmush>specifically: "Unless you’re on Guix System, the first

<unmush>time you run ‘guix pull’, be sure to follow the hint that the command

<unmush>prints and, similar to what we saw above, paste these two lines in your

<unmush>terminal and ‘.bash_profile’:

<unmush>GUIX_PROFILE="$HOME/.config/guix/current"

<unmush>. "$GUIX_PROFILE/etc/profile"

<unmush>"

<levity> https://guix.gnu.org/manual/en/html_node/System-Troubleshooting-Tips.html ?

<levity>oic, nm

<levity>oh yes, I have those envvars set in the relevant terminal

<unmush>ah, my manual is rather outdated, it's the section titled "Getting Started"

<unmush>perhaps it is necessary to run "hash guix"?

<levity>this guix has been in use a while and most of the packages run and work fine. I didn't notice anything wrong until today, when I saw that the package (minetest) installed yesterday is a different version than that expected

<unmush>since 'command -v guix' seems to not have picked up the new PATH elements

<levity>trying it now, where 'it' means hash guix; guix pull; guix package -u sequence

<unmush>strictly speaking the 'hash guix' should come after 'guix pull'

<levity>neat, this time 'guix pull' said 'nothing to be done'

<levity>expected, but i've never seen that before :)

<unmush>and what does 'echo $PATH' say?

<levity>it gots /home/user/.guix-profile/bin (twice)

<unmush>hmmm, it seems to be missing the 'guix pull' profile

<unmush>you're absolutely sure you sourced $HOME/.config/guix/current/etc/profile ?

<levity>i am not sure of that at all, as it happens

<levity>i use a shell script, it works in 2 steps: GUIX_PROFILE="/home/user/.guix-profile"; then source $GUIX_PROFILE/etc/profile

<Rutherther>you need to do the same with $HOME/.config/guix/current as well

<levity>oh! will just add the other to the script then. thanks for that

<levity>ok, trying again...

<levity>guix package -u still finds 'nothing to do'

<Rutherther>levity: so what does type -p guix tell you?

<levity>+ type -p guix

<levity>\/usr/bin/guix

<Rutherther>so you are still not using your user's guix

<levity>sorry, paste broke

<Rutherther>needs to be ~/.config/guix/current/bin/guix

<levity>I am using whichever guix results in the aforementioned guix package -I output tho

<Rutherther>so you either didn't source it or sourced it wrongly, ie. by not setting GUIX_PROFILE to ~/.config/guix/current

<levity>ok

<Rutherther>levity: exactly, which is your system guix, not the one you got from guix pull

<levity>i mean you are definitely correct that .config/guix/current is not getting into $PATH

<levity>so i guess i will guix install guix and then remove the guix debian package and see what happens

<rekado>levity: "guix install guix" is usually not what you want. You should use ~/.config/guix/current/bin/guix only, which comes from "guix pull".

<levity>this is a 'foreign install'. guix came from apt

<rekado>yes, but even that Guix will create ~/.config/guix/current/bin/guix when you run "guix pull"

<levity>oic... running `~/.config/guix/current/bin/guix pull'

<abbe__>hi

<homo>it's impossible to avoid building qt5 on minimal system, what exactly is pulling it and why...

<abbe__>i recently did guix gc, and guix system gc, and since then I noticed term-tty0 service scheme file ends up being empty. I'm using greetd service, and not mintty, which often results in empty initrd.

<homo>on top of that qt6 cannot be built, because the very last test, 522, fails

<abbe__>I'm on the most recent revision of guix channel

<abbe__>does this ring a bell for anyone ?

<unmush>homo: 'guix graph --path' should give an idea

<unmush>e.g. "I try building /gnu/store/blah.drv and it's building /gnu/store/qt5.drv, what does guix graph -t derivation --path /gnu/store/blah.drv /gnu/store/qt5.drv say?"

<homo>thanks

<levity>welp, removing the apt package caused `~/.config/guix/current/bin/guix pull' to fail with "building from these channels:

<levity> nonguix https://gitlab.com/nonguix/nonguix 9730e95

<levity> guix https://git.savannah.gnu.org/git/guix.git 9f53e10

<levity>Computing Guix derivation for 'x86_64-linux'... \ substitute: error: executing `/usr/bin/guix': No such file or directory guix pull: error: `/usr/bin/guix substitute' died unexpectedly"

<levity>so obvs not the Best Idea

<levity>o well, time for bad

<rekado>oh, yes, you do need to have your Guix

<rekado>the daemon you're currently running probably comes from apt

<rekado>so it is configured to use /usr/bin/guix substitute to fetch binaries.

<homo>rekado levity is offline

<rekado>homo: we've got logs

<rekado>you could start the guix-daemon that is somewhere in .config/guix/current/bin instead.

<rekado>sneek: later tell levity See https://logs.guix.gnu.org/guix/2024-12-21.log#114317

<sneek>Got it.

<rekado>sneek: botsnack, but brush your teeth afterward

<sneek>:)

<civodul>Hello Guix!

<civodul>should i push https://issues.guix.gnu.org/74892 to ‘python-team’?

<homo>according to graph, there are 4 packages that depend on qt5: gst-plugins-bad, libde265, v4l-utils and zbar

<levity>hi again all, i just popped back in to say that the problem I'm experiencing (mismatched package versions) is most likely not a problem with guix but with the debian package, and the probable solution is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061963 & thanks again y'all for the help

<sneek>levity, you have 1 message!

<sneek>levity, rekado says: See https://logs.guix.gnu.org/guix/2024-12-21.log#114317

<Rutherther>levity: how is that different from what we were already telling you?

<levity>oh! thanks rekado! Yeah I forgot to bounce the daemon.

<Rutherther>the daemon is not so important in this regard. Though it's of course better to upgrade its guix as well so that possible security vulnerabilities are fixed

<levity>It's different in that it's a permanent link to a thing I need to do

<levity>no, but the daemon will not come up again, and that would have given me a clue if i was awake

<Rutherther>do you mean after you removing the package? of course then, I don't really know why you removed it

<levity>o i removed it to see if I could get the current one to run by itself on my system

<levity>can i feed a debian alive to a guix? a system transtallation

<Rutherther>right, but it's not relevant to your message 'nothing to do'. The guix daemon runs with is not relevant to which guix commit is used to install packages

<levity>anyway bed time

<Rutherther>s/guix daemon/guix guix-daemon

<abbe__>guix system reconfigure output https://www.irccloud.com/pastebin/ateAGDGA/

<abbe__>excerpt from guix system service configuration that is causing the problem https://www.irccloud.com/pastebin/4jCejJ0W/

<homo>so, libv4l and v4l-utils are built together, which is why to get library part of it, it is necessary to pull qt5 required for utilities...

<homo>interestingly freebsd builds these 2 separately, if someone takes that work from freebsd, it will be unnecessary to pull qt5 just to have libv4l

<abbe__>If I comment this block, and restore mingetty-service, then it does not result in that error

<homo>here is how freebsd builds libv4l and v4l-utils separately https://codeberg.org/freebsd/freebsd-ports/src/branch/main/multimedia/libv4l https://codeberg.org/freebsd/freebsd-ports/src/branch/main/multimedia/v4l-utils

<homo>it seems to be trivial to get that into guix, the real hassle is test building gui part of it

<jlicht>Is it possible to have an origin in the list of (native-)inputs of a package, without using the older manual input labels style?

<jlicht>or rather; how do I refer back to my unlabeled origin input :-)

<Rutherther>jlicht: have you tried setting file-name of origin and referring to that? (not completely sure it's going to work)

<jlicht>Rutherther: good plan :-)

<Rutherther>also, if you are onto getting rid of the old style why not go straight with gexps in a phase?

<dariqq>homo: check out #74517

<civodul>jlicht: yes, it’s been changed recently: you can now do (this-package-input "foo.tar.gz") or similar

<civodul> https://guix.gnu.org/manual/devel/en/html_node/package-Reference.html#index-lookup_002dpackage_002dinput

<homo>dariqq issues.guix.gnu.org is not working right now, but thanks for suggestion

<Rutherther>homo: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74517

<jlicht>I'm trying to do this in a build-system, so ideally it'll always have the same name

<homo>thanks

<homo>that patch is not exactly what freebsd does

<homo>in freebsd, v4l-utils doesn't build the library part, only the gui part

<homo>which means v4l-utils needs to have v4l-utils-minimal (libv4l) as dependency

<homo>and that is why it is a hassle to test build it

<homo>but still that patch is a helpful start, so thanks anyway

<homo>never mind, now that I read carefully, freebsd simply makes chdir before install

<homo>what I had in mind was this https://paste.debian.net/1340780/

<rekado>efraim: I'll have to update python-pydantic-core, and I see that the changes I'd need to Rust packages are already on the rust-team branch. Is that branch expected to be ready somewhat soon?

<rekado>I'm thinking about rebasing python-team on top of rust-team, but I'm a little concerned about delaying Python fixes for an indefinite period of time.

<ekaitz>i have stupid guix style question: why do we use 2 indentetation levels in `origin` but one in the rest of the things?

<rekado>"special forms" are often indented with 2 spaces.

<ekaitz>rekado: is origin a special form?

<ekaitz>let, if and so on are, but origin?

<rekado>it's a macro

<ekaitz>oh

<rekado>it's one of these "smart" constructors

<rekado>the dumb constructor is called %origin

<ekaitz>oh thanks for the explanation

<ekaitz>it gets complicated because the automatic indentation now needs to know about what is a macro and what isn't...

<ekaitz>guix style does that well, but my editor doesn't

<ekaitz>ACTION knows about emacs

<rekado>perhaps your editor can process .dir-locals.el?

<rekado>(because Emacs also needs to be told)

<lilyp>rekado: have you seen the pillow patches that are part of 74702? they cause some 900 rebuilds

<rekado>havent seen them

<rekado>push to python-team

<ekaitz>rekado: maybe, idk, will try

<rekado>I guess it's unrealistic to expect a merge of the python-team branch soon anyway

<weary-traveler>any racket folk here? #74845 https://patchwise.org/cgi/bugreport.cgi?bug=74845 could use some eyes

<olafes>If I inherit a pacakge and change some of its properties, does the pacakge get rebuild?

<olafes>My guess was yes, but I ran some experiments and it seems guix can substitute anyway

<lilyp>properties don't change the build, so no

<jmbr>With the g++ in gcc-toolchain@14.2.0, I can't get this simple program to compile https://paste.debian.net/1340799 whereas the equivalent C program compiles without issues with gcc. The error I get is "error: ‘fetestexcept’ was not declared in this scope" Do you have any ideas what could be causing this?

<lilyp>jmbr: there was a similar issue with fesetenv in the mailing lists some while ago – maybe related

<jmbr>lilyp: I'll search. Thank you!

<lilyp>quick q: is there any way of debugging mumi (the cli)?

<lilyp>nvm, i was just too impatient to wait for the timeout

<orahcio>Hello, may I use gammastep or redshit-wayland on redshift service? Or I need to make my redshift service to wayland?

<homo>orahcio: I didn't know there is redshift service, as it is build into gnome and kde, while on other desktops it's easy to add redshift.desktop to ~/.config/autostart or ~/.config/xdg/autostart , can't remember which one

<homo>s/build/built/

<jmbr>lilyp: it turns out that if I #define _GLIBCXX_HAVE_FENV_H 1, then the problem goes away. I'll submit a bug report later today

<RavenJoad>I don't know if this is the right place to ask a Cuirass question, or if #guile is, but I'll ask here first. I cannot start cuirass-web because of an uncaught system-error because "connect" had "permission denied 13". Then later make-stack fails too.

<efraim>rekado: I thought pydantic-core might want an update soon so I made sure the rust bits were ready. I can make sure the branch is in a good shape and it should be generally ready for merge as soon as CI can build it

<lilyp>RavenJoad: you might want to use a different port – the 0 to 1024 are reserved

<RavenJoad>lilyp: I'm using the default port, 8081.

<rekado>efraim: excellent, I'll rebase python-team on top of rust-team then.

<lilyp>weird then 🤔

<efraim>if pydantic-core and pydantic updates can stand alone I can grab them into rust-team

<rekado>efraim: I don't think they can. Updating them is likely to lead to many weird failures.

<efraim>that's what I thought might happen. I updated pydantic-core and the rust crates, and then undid the actual upgrade to pydantic core since I didn't want to actually worry about all the python breakages

<rekado>:)

<rekado>I stopped worrying about this on python-team. Whenever a package breaks I'll just upgrade it and whatever it depends on if it still breaks.

<rekado>it's not fun but after all these years it has become the only workable solution.

<orahcio>homo: yes, I think is very easy to ask sway to execute gammastep or redshift, but I could see the home-redshift-service and I try to use as a service, I will use like a simple package instead service for now

<Cessation>I need the arm-none-eabi-toolchain so I can run QMK and setup my keyboard. The package is visible at data.guix at https://data.guix.gnu.org/gnu/store/63zyj6spdx2yizhjvsvqfbgd8r4ybxqr-arm-none-eabi-toolchain-6.5.0.drv, but I cant find it with 'guix search' or 'guix install'. I've updated my package listings with 'guix pull' but still can't find

<Cessation>it. How can I get arm-none-eabi?

<Rutherther>Cessation: the package is not really exposed as a package, it's just a function, so you need to call it like this: "(make-arm-none-eabi-toolchain-12.3.rel1)" to get the package. It's from the (gnu packages embedded)

<Rutherther>to install it you could do something like "guix package -e="(@ (gnu packages embedded) make-arm-none-eabi-toolchain-12.3.rel1)""

<Cessation>can I run that mate command from bash?

<Rutherther>sorry, s/=/ / and wrap with one more pair of ()

<Rutherther>so "guix package -e "((@ (gnu packages embedded) make-arm-none-eabi-toolchain-12.3.rel1))""

<Cessation>thanks! i've never run `guix package` before

<mfg>Is there a acpid service?

<rekado>Cessation: we have a qmk package

<rekado>(and various qmk firmware packages)

<Rutherther>rekado: but that's not the same thing, they want to compile their firmware. For the firmwares you mention, they target AVR only

<Cessation>I have installed the guix qmk package. That's what said I needed the ARM none thing

<Rutherther>yup, for compilation of arm firmware you need the stuff I sent you, I've successfully compiled firmware with that toolchain

<homo>orahcio is existing redshift-service-type hard to copy and adjust?

<orahcio>homo: I think that service has a option x11-display and even with redshift-wayland package and wayland method the service does not starts

<rekado>oh, got it. (I do actually have the arm-none-eabi toolchain, too, for my keyboard.)

<rekado>in my home config I define this: (define avr-toolchain ((@ (gnu packages avr) make-avr-toolchain)))

<rekado>and then cons it to the list of packages.

<Cessation>Rutherther Thanks! currently waiting at the "build phase"

<rekado>efraim: I just pushed python-team after rebasing on rust-team

<Rutherther>Cessation: for me it takes like 60 - 90 minutes to build gcc + newlib + stdc++ that are all part of the toolchain

<rekado>might be a bit early, but I'll just do it again once you've got an up-to-date rust-team branch

<Cessation>rekado I should add that to my scm too

<RavenJoad>I should definitely add that to mine too.

<noe>How do I apply a specific version of a patch without mumi?

<noe>I have the mailbox open in RMAIL

<csantosb>Magit-am ?

<noe>Well I tried but it applies every version

<whereiseveryone>hi, where's my mumi? ;()

<whereiseveryone> https://issues.guix.gnu.org/

<whereiseveryone>efraim: thnx for working on pydantic, much appreciated

<Rutherther>whereiseveryone: it's down, you can use the debbugs.gnu.org frontend instead

<csantosb>noe: have a link ?

<csantosb>or issue ?

<noe>#52555

<noe>I would like to apply v4

<dariqq>rekado: Can i kindly ask for a fix for scipy on i686? There are currently some test failures in pandas and pytest-regressions

<dariqq>(I would love to have mate build on i686 again but cantarell font pulls in a lot of python things)

<orahcio>homo: https://lists.gnu.org/archive/html/help-guix/2023-11/msg00092.html I think it is a solution, but I think he made another redshift-service with this

<whereiseveryone>Rutherther: no thanks, I'll just wait and do something else in the meantime. I can't stand to interact with debbugs ;()

<csantosb>noe: `o` saves content to a file, then, you can apply with magit-am

<noe>csantosb: thanks!

<csantosb>noe: other than this, using yhetil, select the message, download with raw, apply with magit-am

<csantosb>For example: https://yhetil.org/guix-patches/7c1c7108a369b608e8cebbe09c4cbfe24d032067.1703316055.git.pukkamustard@posteo.net/

<Guest63>Does anyone have experience with getting the KeePassXC plugin to work?

<orahcio>homo: I need to see more configuration examples to learn how to make a mingetty login with every environment variables, I back to gdm because after `guix home reconfigure` the packages did not show on PATH, with gdm everything backs to normal

<david95>Hi everyone, I made some progress installing Guix Package Manager , I tried to run the command: $ sudo guix-daemon --build-users-group=guixbuild and it worked I was able to run the command: $ guix pull But after a while I got an error:

<david95>-suspicious ownership or permission on `/gnu/store/q5sqgng4wdzxr6yrvvp706kbxa3fcfjf-bzip2-1.0.8.tar.gz'; rejecting this build output build of /gnu/store/4i9vv3kz0m7jg5xpckxl3yzq43vabp3s-bzip2-1.0.8.tar.gz.drv failed View build log at '/var/log/guix/drvs/4i/9vv3kz0m7jg5xpckxl3yzq43vabp3s-bzip2-1.0.8.tar.gz.drv.gz'.

<david95>Please tell me how to fix it.

<ieure>What does the build log say?

<efraim>it sounds like the ownership of /gnu/store is wrong

<ieure>david95, What distro are you installing Guix on?

<david95>Hi ieure. It's me) Installing Guix Package Manager in Parabola

<ieure>david95, Are you using the Arch AUR to install Guix, or doing it manually?

<ieure> https://wiki.archlinux.org/title/Guix probably has some good info.

<david95>ok, I'll try now.., thanks

<david95>After running the command: $ guix install glibc-locales I also get the error: /suspicious ownership or permission on `/gnu/store/ixb5iz7rpqcxs6s2143h5lp9wnjh2i2p-bison-3.7.6.tar.xz'; rejecting this build output build of /gnu/store/6w0c56ja6zj2253mrg0al0a5ab8l4s6w-bison-3.7.6.tar.xz.drv failed And how can I change "updating substitutes" I see https://bordeaux.guix.gnu.org maybe try another

<homo>is guix-daemon supposed to run as root? sounds dangerous

<david95>and how can i check if i run guix as root or not? Because i dont run as root user when i update or search for programs and it works..

<efraim>what's the output of 'ls -la /gnu'

<csantosb>david95: are you using the binary installer or the aur package to install guix ? (i'm running arch linux with guix foreign)

<david95>changing 'substitutes' had the effect... $ sudo guix archive --authorize < /usr/share/guix/ci.guix.gnu.org.pu

<homo>david95 you said earlier "sudo guix-daemon"

<homo>so yes, you ran it as root

<david95> https://privatebin.net/?4c22da3e411885ce#4c3XR6f4hUBBXB4FxpvU8oSgsfBQUxPu2euGxm2kzoLJ

<homo>"Error decompressing paste, your browser does not support WebAssembly. Please use another browser to view this paste"

<efraim>that looks the same as mine

<ieure>homo, Yes, guix-daemon does / is supposed to run as root.

<david95>I'm trying to use install guix from repository because building from AUR requires sudo (I don't use sudo) So this method didn't work for me..

<csantosb>From repository means this, I guess: https://guix.gnu.org/manual/en/html_node/Binary-Installation.html

<ieure>david95, Why don't you use sudo?

<efraim>I use the installer script normally

<rekado>dariqq: sorry, I won't have time to work on this soon. I have been pushing a few fixes for x86_64 to python-team, but someone else will have to continue the work.

<david95>I tried this method using the site https://systemcrafters.net/craft-your-system-with-guix/installing-the-package-manager/ but it takes a lot of time)) and free space on the disk. Of course, wiki is better, no doubt) I wanted to install from the repository and start using it, but as I understand it, I will have to use the manual installation method ...

<rekado>something urgent came up and I'll likely disappear for a few weeks again

<david95>no sudo )) => https://packages.guix.gnu.org/packages/opendoas/6.8.2/

<ieure>david95, sudo isn't required, only to run stuff as root. You can substitute doas, or `su -' and run the commands, etc.

<ieure>sudo is just the most common on Linux, so most instructions assume its use. There's nothing special about it.

<Guest46>I think I nailed down the problem for KeePassXC browser's extension not working (and some potential solutions)

<david95>I agree with you, I just like opendoas because it is minimalistic and more understandable without kilometers of descriptions)) But this is a separate conversation, I will try the manual installation method.

<csantosb>david95: rather refer to the official documentation of guix to deal with it

<david95>yes, thank you, I'll try, I didn't think that a simple installation of a program from a repository would lead to research))

<Deltafire>two of my laptops show random ^@ strings on the boot console, anyone have an idea what's causing this?

<Deltafire>i think it also interferes with password input, so my be coming from the keyboard driver

<Deltafire>not had this with other distros, and my desktop isn't affected

<dariqq>rekado: No problem

<gerogaga>What does the passage "The #:build-type parameter specifies in abstract terms the flags passed to the compiler" mean in the cmake-build-system documentation?

<rekado>I'd like to deploy to an aarch64 system, but it looks like there are no substitutes whatsoever.

<lilyp>cmake distinguishes between release and debug builds – the build-type corresponds to that

<rekado>I'd have to build glibc locally.

<rekado>is there a known good commit? Ideally after the Shepherd 1.0.0 release?

<efraim>I used 1eead56e2f763e3a1a371f9ea00e89337867d397 for riscv64 so I didn't have to build rust there

<efraim>not sure how far back that is though

<efraim>almost a month :/

<the_tubular> warning: the 'target' field is deprecated, please use 'targets' instead

<the_tubular>Other than renaming the field, what else should be done ?

<RavenJoad>If that's in bootloader, then I think just turning whatever you have as the target into a list is the only thing. I don't fully remember. It's been a long time since I saw that one.

<the_tubular>It is, it looks like : (targets "/boot/efi") is it correct ?

<the_tubular>I can't run `system reconfigure` as there is a package that fails to build ... :/

<the_tubular> (targets "/boot/efi") This seems to be accepted, but this one gives me an explosive traceback

<lilyp>use a list

<the_tubular>This one : (targets "cryptroot")

<the_tubular>How do i transform this in a list ?

<makx>(targets '("cryptroot"))?

<the_tubular>This seems to work, why is it not needed on the (targets "/boot/efi") ?

<the_tubular>Seems like one needs to be a list and the other one a string ?

<the_tubular>For the same procedure ?

<unmush>civodul, efraim: did my V2 mono series make it to you two?

<civodul>unmush: hi! yes, actually i saw it just after replying to efraim

<civodul>i haven’t looked into detail but AIUI it addresses issues with parallel builds that efraim was experiencing

<civodul>so i guess we’re all set?

<civodul>i’ll let efraim conclude

<unmush>pretty much

<civodul>thanks for the amazing work again

<civodul>if you want i think it would make sense to turn your writeup into a blog post for guix.gnu.org

<homo>after splitting pulseaudio into out, daemon and utils, I can't figure out how to make (file-append pulseaudio "/etc/pulse/default.pa") in gnu/services/sound.scm point to daemon

<unmush>I've recently been looking in to the possibility of only using the mcs (leaving out the mono runtime and library) from intermediate mono versions, and using pnet's ilrun and pnetlib to run it

<unmush>that should make intermediate builds massively faster and also allow us to make much bigger version jumps

<homo>I can't find example code that uses file-append on package specific output

<unmush>as well as solving the issue of portability of old mono runtimes

<unmush>a blog post sounds fine by me, though "postlude: a better idea makes much of what I just did obsolete" is a big of an anticlimax

<unmush>s/a big/a bit/

<civodul>unmush: heh :-)

<civodul>well this kind of work is never finished

<civodul>that’s okay, we can have “mono bootstrapped” season 2 later

<homo>#~(file-append #$pulseaudio:daemon "/etc/pulse/default.pa") seems to be the correct way to point to subpackage

<civodul>homo: ‘file-append’ doesn’t quite work with multiple-output packages

<homo>I can't figure out for string-append either

<civodul>#~(… (string-append #$pulseaudio:daemon "/etc/…") …)

<homo>thanks

<RavenJoad>I cannot start cuirass-web because of an uncaught system-error because "connect" had "permission denied 13". Then later make-stack fails too. Anyone have any ideas on how to debug this?