IRC channel logs
2024-12-20.log
back to list of logs
<civodul>hmm, how can we know who the owner is? <lechner>civodul / i'm sure but how do we get a hold of them? <lechner>Codeberg first. The owner is probably a friend <lechner>Hi, is anyone here a Codeberg e.V. member? <lechner>civodul / good night. I may open an issue noting that organizations do not identify their members <civodul>lechner: as member of an org, you can choose whether or not to display it publicly <civodul>that membership is concealed by default is quite annoying <ieure>Might be worth pinging @Codeberg@social.anoxinon.de about this. <lechner>okay, i'll ask them to send the list of those admins to you, if that's okay. there shouldn't be any question about your interest <Kolev>I don't see @guix-maintainers on Mastodon. <jmes>In the new Timers feature for Shepherd, `actions' can be a "suspendable thunk", what does it mean to be suspendable in guile? Need I handle SIGINT or something? <unmush>look up 'suspendable-continuation?' in the guile reference manual <unmush>there's also some discussion of suspendable continuations in the fiber manual <unmush>the short version is "doesn't need to suspend while in a C procedure" <unmush>since guile doesn't know how to save those stack frames to be reactivated later <jmes>unmush: Thanks! I did read something like that in the continuation docs, but I didn't connect the dots. Time to do some review. Thanks again :) <unmush>is there a way to tell git to not normalize line endings when producing a patch? <unmush>I have a patch P1 that, among other things, adds a patch P2. P2 in turn is applied to a file that uses CRLF line endings. <unmush>When I try to use git format-patch to produce P1, it normalizes the line endings, which makes P2 not cleanly apply <mange>Looks like there's an core.autocrlf setting for that. Maybe "git config --global core.autocrlf false"? <unmush>it's not set either locally or globally <mange>Yeah, I'm saying to set it to change the behaviour. <mange>I assume it defaults to "input". <unmush>It looks like that's got it including the ^Ms now, thank you <Kolev>Does Guix System still do "Error in .... Success!" <apteryx>in there any gotcha to use tmpfs for /tmp on guix system? <lechner>Kolev / i don't think so, but am not sure <apteryx>probably a good idea to minimize wear on flash storage <apteryx>arg, my magit still puts me in odd diectories when I commit <apteryx>after pressing 'c c', in the commit buffer, C-h v local-directory shows I'm in /home/maxim/src/guix/.git/worktrees/guix-gnome-team/ <apteryx>it should be /home/maxim/src/guix-gnome-team otherwise diff commands don't work <apteryx>anyone else having this kind of issue with magit as of late? <apteryx>ACTION tries to reproduce the issue with a minimal environment <ElephantErgo>Hey, so I'm trying to build a version of llama-cpp with ROCm support using the hipamd package from the guix-hpc channel. I'm running into a problem where configure is unable to find the cmake files it wants. Specifically,it's missing rocm-toolchain-6.2.2/lib/cmake/hip-lang/hip-lang-config.cmake. Does anyone know if I can find some package (or package version?) that provides this cmake file? I'm sorta at a loss as to how to proceed. I <ElephantErgo>can of course provide the source for the package recipe I have so far. <apteryx>weird, /pre-inst-env guix shell emacs emacs-magit --with-version=git-minimal=2.45.2 -- emacs -q -> enters a loop fetCIng git-2.54.2.tar.gz ad-eternam <unmush>oh, also, one thing I forgot to mention, the pnetlib tests are still a bit flaky, and may require multiple attempts before they pass <ElephantErgo>So how do I go about invoking a bash command when setting an environment variable in a package definition? <unmush>when you say "when setting an environment variable", do you mean during the package build? <unmush>or are you referring to one of the *-search-paths fields? <ElephantErgo>Yes, during the package build. I'm adding a phase for setting environment variables prior to the "configure" phase using setenv <unmush>well, you could use (ice-9 popen) to get access to open-pipe, and (ice-9 textual-ports) to get access to get-string-all <ElephantErgo>That sounds pretty good! I'm very much a Scheme noobie, so let me see if I can figure out how to put these together. These very much sound like the right direction π <unmush>just be careful that when you modify the #:modules package argument that you also include the original build system build-side code <unmush>for example, if you're using gnu-build-system, you'll need to use something like #:modules '((guix build gnu-build-system) (ice-9 popen) (ice-9 textual-ports)) <unmush>this is because #:modules completely replaces the list of used modules in the build script, and of course the procedure that actually runs all these phases is defined in (guix build gnu-build-system) <ElephantErgo>Interesting... I'll be honest in saying I'm not quite sure I follow, but it's starting to get very late as I bonk my head against the keyboard trying to figure out how to pull this build together π <ElephantErgo>(guix build gnu-build-system) has been imported at the bare minimum, and I appreciate the warning even if I am not lucid enough to heed it to its full extent π <unmush>the relevant guile reference manual sections would be 7.2.10 for pipes and 6.12.4 for get-string-all <podiki>you can just use the function setenv <podiki>try "git grep setenv" to see examples in guix tree <podiki>oh you say you need some bash command, what exactly? <podiki>what do you expect the output to be? will it point to a clang from a package (like clang? <podiki>because typically it would be something like (setenv "HIPCXX" (search-native-input-file "bin/clang")) or something like that <podiki>in other words, to find it from a build input <ElephantErgo>That first one in particular will point to a clang. I have another variable that I believe points to a path of cmake files. I used to construct these by hand using (string-append (assoc-ref %build-inputs "rocm-toolchain") "/bin/clang"), but I found that this actually linked to a different output than I was expecting <ElephantErgo>Very similar looking directory for a package with an identical name and version number, but a different value in the store. Some files I needed at build time were missing <podiki>you mean your inputs contain multiple files that will match the search-input-file? <podiki>then you may have to refer to the package specifically <podiki>or i'm not sure, but same name and version but different hash means it is a different build of the package, perhaps coming from something propagating that input? <podiki>probably would help to share your code at some point if you haven't already (though I need to take off soon) <ElephantErgo>It's more that the version of the rocm-toolchain package that amdhip points to is different than the version that is pulled into my profile upon installing rocm-toolchain by name. The specific hash I need seems to be an input specifically of amdhip- exactly. <podiki>well a package build is completely isolated from everything else in the system <podiki>so if you are expecting to use what you have installed, that won't work in a package definition <podiki>and the package you install may indeed be a different one than the variable points to in a package definition <podiki>e.g. "gcc" the variable may be gcc v11 when "gcc" the package by name that you install will always be the highest version, like v14 <ElephantErgo>That's why I was hoping to invoke hipconfig -l when setting the environment variable. It seems to be pointing to a path inside some other variant of the rocm-toolchain package than when I list it as an input under regular circumstances <podiki>e.g. we use "gcc-toolchain" for the user package someone will install, while in build systems it uses "gcc" the variable (not a public package) <ElephantErgo>I think largely the analog in terms of how I've seen it used is that hipamd:rocm-toolchain as gcc:gcc-toolchain <podiki>i really don't think you need to invoke so much as make sure you are including the actual package you need in the build <podiki>can you share a package def? or what are the inputs you include? <ElephantErgo>Hmm... I'm just not sure what the clean way to include the package would be... My first guess would be pulling it out of the amdhip package definition <ElephantErgo>It's an LLM (generative ai) client. It lets you run ai models locally. I'm hoping to teach it how to do AMD graphics card acceleration <podiki>so essentially you want to use the rocm tools rather than the defaults cmake-build-system uses? (gcc i guess?) <ElephantErgo>Well, sorta. The build process is a little different than standard when building for amd hardware acceleration, so additional considerations are being added based on the original source's readme. I'm not sure if it would be necessary to swap out the cmake version in the package definition to use the rocm variant or not. I was getting the impression that it wasn't necessary given example packages I saw in guix-hpc, but I'm not certain <podiki>but rocm-toolchain the build input doesn't have the right version you expect? but when you do "guix install rocm-toolchain" it is what you want? <ElephantErgo>Exactly. Both when doing "guix install rocm-toolchain", and when providing rocm-toolchain as an input, it installs a version with a different hash than what I need <ElephantErgo>I only realized that there are versions of the package with what I need just based on doing "find / -name hip-lang-config.cmake" on a whim <podiki>so, I see rocm-toolchain has an input of rocm-clang, why not use that directly? <podiki>and however you are using guix-hpc you could be on different commits (what you have with your "guix pull" and what you have in e.g. a channel dependency) <unmush>so uh... I just got this response from debbugs-submit-owner@debbugs.gnu.org: <unmush>You tried to send a mail to one of the GNU bug mailing lists that uses http://debbugs.gnu.org to track its bugs. Your request was: Posting of your message titled "V2 series". Your mail has been rejected by the debbugs moderator. The moderator gave the following reason for rejecting your request: "I'm rejecting your message, it's too long for a mailing list; please consider publishing the long part somewhere else and posting a link -- <podiki>unmush: did you send more than one patch in an email maybe? even really long changes like new kernel configs go through <unmush>because I dunno how to use a client with protonmail <podiki>i send with protonmail but i have a bridge running locally <podiki>people generally prefer one patch per mail too for workflows <podiki>unfortunately i don't think you have much choice but to break it up into at least more messages with fewer patches <podiki>ElephantErgo: in any event, trying to call a command in a build phase won't magically change what you have in the build environment, if the rocm-toolchain input is for whatever reason not what you need, it will still have the same files however you point to it <ElephantErgo>Hmm... I do see how that would make sense... I was just sorta hoping that hipamd was propogating a specific version of rocm-toolchain π€ <ElephantErgo>I think rocm-clang makes sense to investigate, though... But it isn't installing for whatever reason. I can't see it when I do "guix search" for some reason <unmush>it's worth noting that not only input packages, but their transitive references also are included in the build environment's /gnu/store <ElephantErgo>Oh you're totally right. I was finding some build artifact in the store that doesn't actually point to anything. <ElephantErgo>Invoking hipconfig the way I was doesn't even point to that store hash <podiki>rocm-clang may not be a public package name <podiki>anyway, maybe something changed in the current build of the rocm tools and you don't have the file you were looking for <podiki>or the configuration changed (even if the version didn't from some other build changes) <podiki>i don't know much about rocm, but i know what hardware it supports or doesn't (and when it changes) was impossible to find out when i had looked. and more things worked than was "officially" listed <ElephantErgo>Hmm... That does sorta seem to be the case. It's just sorta confusing that I have store items that are structured the way that llama-cpp suspects them to be while retaining the same version number... I'm not sure what to make of that in terms of a path forward π€ <podiki>so the store name is <hash>-name-version <podiki>anything that changes the package will change the hash, but version is set in the package definition <podiki>so, could be same name and version but if anything changes for the package (or it's inputs) the hash will be different <podiki>e.g. you adding in your package the new phase changes the store hash, or even reordering your setenv calls should also change the hash <podiki>(whitespace, comments, etc. of course don't, but if it changes the build derivation the hash changes) <ElephantErgo>Right... That makes sense. That's so strange, though... The package as it was was exactly what I needed, and I'm not sure how to go about getting back a version of the package that would work for what I need. It's as though configuration changes removed the cmake files I needed <podiki>you could try older commits of guix-hpc (either in local checkout or with time-machine) to bisect, but you'll of course need a version that works first (or find one) <podiki>i'd check the history of the relevant packages and key inputs to see what changed <podiki>or see if you can get clang-rocm (or whatever) to build with what you need, seeing if you need maybe to change some config option there? <podiki>maybe try seeing what the /gnu/store/<thing that has what you want> has as referrers, maybe that will give you a clue <podiki>see guix gc --referrers or --references <podiki>hopefully you've got some possible directions now, sorry that sounds like a rather annoying mystery :( <ElephantErgo>Dozens more leads than I had an hour ago. You've been incredibly helpful, and I appreciate your patience in investigating this π <podiki>welcome! sorry it wasn't so easy (so far, maybe it will be by the end!) <podiki>there's a lot of less obvious stuff at play here, don't feel bad <podiki>(I also have a personal stake as someone that uses rocm for opencl in darktable; I dealt with updates to rocm in guix some time ago, that was tricky enough) <podiki>(i haven't tried to update those packages since :-P) <ElephantErgo>I really appreciate your encouragement! π You'll likely see me back here sooner rather than later once I pursue some of these leads. π Here's to hoping that the commit logs will be kind and yield something promising right away π <podiki>guix-hpc people are often here too, or else you might try opening an issue/request in their gitlab <podiki>i best get going, hope to hear of success in the near future! <unmush>is there an easy way in guile to run a process with stdio redirected to/from a file other than using 'spawn', which is a guile 3.0 thing IIRC? <rekado>I need a little help on python-team. Since an upgrade to python-eventlet other packages throw this error: type object 'GreenSocket' has no attribute 'sendmsg' <rekado>it's not reported anywhere on the bug tracker <rekado>my next step would be to choose a slightly older version of eventlet, but that's suboptimal <csantosb>Hello Guix ! I have a weird issue here whith building a patch ... What am I doing wrong ? <iyzsong>csantosb: what's the issue? it may download instead of build it when substitutes is available on CI. <hako>csantosb: You need to have guix compiled before using pre-inst-env. <csantosb>It downloads 0.47, whereas the patch applied stands for 0.48 <csantosb>It is not supposed to build 0.48 instead ? <iyzsong>um, i see. yes it should build 0.48. you could try 'make' before './pre-inst-env guix' <david95>Hello everyone. I would appreciate your help. I wanted to install Guix package manager in Parabola https://wiki.parabola.nu/Using_GNU_Guix_on_Parabola I use OpenRC so this guide is not suitable. I installed guix , it is in the Parabola repository. Now I get the error: $ guix upgrade guix upgrade: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory What do <david95>What does this error mean and how to fix it? <iyzsong>csantosb: okay, does "./pre-inst-env guix edit yosys" open the correct file with 0.48 version? <unmush>david95: sounds like the daemon isn't running <iyzsong>david95: that mean 'guix-daemon' is rot running, you need get a openrc unit for it <unmush>I'm not familiar with openrc, but I imagine the parabola pacakgers may have set it up so that it doesn't autostart once installed, and maybe you have to manually start it the first time (with it automatically starting on reboot?) <david95>thanks for your answer. No, the daemon did not start automatically, I checked it was disabled and I had to change the rights from 640 to 755, but it did not help, I can not start it, but I was able to add it to the automatic startup. I did not reboot the computer, maybe it will work after rebooting? <AwesomeAdam54321>david95: What's the error message for the guix-daemon not starting in the logs? <iyzsong>csantosb: does the file location is right? it should in the git checkout directory <csantosb>iyzsong: `git log -1 --oneline` replies "ab62c46 (HEAD -> master) gnu: yosys: Update to 0.48." <david95>I don't see any messages in the logs about guix ($ sudo tail -f /var/log/daemon.log ) <david95>$ rc-update -v show | grep guix guix-daemon | $ rc-update add guix-daemon default * rc-update: service `guix-daemon' is not executable <david95>guix refresh guix refresh: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <iyzsong>david95: to fix 'is not executable', you could try 'chmod +x guix-daemon' in /etc/rc.d (i guess) <sneek>Welcome back orahcio, you have 1 message! <sneek>orahcio, homo says: plasma, just like gnome, is not lightweight, is more buggy and worst of all in qt and kde world every theme is .so file, furthermore I didn't see automatic creation and deletion of workspaces feature being available anywhere outside of gnome, and that feature alone saves me a lot of time <homo>orahcio: I see, I'm not into autologin, so I'll need to figure out how to setup wlgreet <orahcio>homo: just now I could read your message about automatic workspace just now. Good, I will try to setup wlgreet <homo>so I noticed, sneek is a good bot <homo>I didn't expect to see mingetty as argument to modify-services function <csantosb>iyzsong: indeed, one need to make before all the rest ... <orahcio>homo: there is another way to do auto-login with mingetty without modify? Because I use %desktop-services. O auto-login with gdm I did the same <homo>you did the same on auto-login with gdm because gdm was already embedded into %desktop-services list <homo>modify-services returns a list, which means you can prepend mingetty instead <orahcio>and mingetty was embedded into %base-servicesm and it into %desktop-services <homo>hold on, if it's already embedded, doesn't it autologin you on every vt? <orahcio>homo: yes, every vt, I weant now to login into just tty1 <Rutherther>so just make it conditional when you set auto login to true, check the name of the tty in configuration with an if <orahcio>now I will learn how to do conditions in guile <orahcio>I made it to start sway, but it was on a shell script into the inicialization file <df>is there an easy way to get a symlink from cc -> gcc for things that expect it (eg make's default rules)? <orahcio>homo: this alternative starts mingetty just on tty7 Maybe I get error because I call mingetty once to autologin and again with the %desktop-services. I got this type of error when I try to configure sddm at the first time <homo>if you try to start second mingetty on tty1, it's obviously a conflict <homo>same with sddm, it cannot co-exist with gdm on the same tty <homo>but you can have both gdm and sddm on different ttys <orahcio>nice, I will try both alternatives, and I will try on another tty the question about wlgreet <orahcio>thank you very much homo and Rutherther <homo>I'm surprised wlgreet is runs on top of sway, not cage <homo>orahcio: btw, I checked that pipewire-pulse and pw-jack are already part of pipewire package, so maybe it's not necessary to rebuild any package <homo>the real question is why it's not started automatically by gdm, sddm and greetd <orahcio>Sway is more complex than cage, of sway, it gets to be more simple than cage? <homo>orahcio: if I understand correctly running wlgreet on top of sway means using sway on top of wlgreet on top of sway <homo>considering cage is simplistic, it's best to run wlgreet on top of cage, in other words sway on top of wlgreet on top of cage <orahcio>homo: yes, It is the proof that, if you need a graphical login, maybe the graphical login can be your WM <homo>the thing is when you login, you are not using sway inside which wlgreet runs <homo>I would be surprised if wlgreet gave you control of sway that already runs <homo>ACTION needs to read documentation <orahcio>yes, but I think it will be the sway inside the sway, because I used the tuigreet to choose my sway session before on nixos, and makes sense the wlgreet be just another flavor to greet <homo>orahcio: when you login, it kills sway, then it starts another sway <homo>as I understand advantage of gtkgreet is that you can easily change its appearance <homo>and in terms of resource usage it doesn't matter as it gets killed after login <orahcio>At this line? exec "wlgreet --command sway; swaymsg exit", sway also is very easy to modify appearance, maybe it is the answer to use sway intead cage <homo>gtkgreet also requires sway or cage <orahcio>so, wlgreet and gtkgreet has almost no difference <homo>yeah, ability to change theme is the difference <orahcio>I like it, devs make things because they can <homo>anyway, most likely I won't need to give up gnome and gdm just to properly setup pipewire <homo>the real question is why pipewire is not even installed and why it's not started by any dm <homo>also neither pulseaudio nor pipewire are supposed to be started as system-wide services, so it's a mystery what pulseaudio is doing in %desktop-services <orahcio>Now I could unsderstand your question, you want gnome started by another dm intead gdm <homo>orahcio: no, initially I though switching to pipewire-pulse over pulseaudio would require rebuilding gdm and gnome, so I intended to give them up <homo>I don't want gnome started by another dm because then it cannot lock screen <homo>pipewire is supposed to be started by greetd, gdm and sddm <df>is there a conventional way to have a mostly-generic config.scm with a few hardware-specific bits for different machines? <homo>I'm going to try the most naive approach - disable alsa-service-type and pulseaudio-service-type, install pipewire and wireplumber, hope that it works <orahcio>good luck homo, why pipewire instead pulse? <Rutherther>homo: how did you figure out it's supposed to be started by dm? display managers don't start anything, other than what's in your profile fils, and even that, not all of them d <apteryx>magit + git worktrees user: you probably want to set git-commit-cd-to-toplevel to t (non-nil) <homo>orahcio: pulseaudio is effectively dead, pipewire is a drop-in replacement <homo>despite disabling pulseaudio and also, pulseaudio still starts itself... <orahcio>homo: pulseaudio does not want to die despite being effectively dead <homo>open 3 shells, in shell 1 "pkill -9 pulseaudio && pipewire", in shell 2 "pkill -9 pulseaudio && wireplumber", in shell 3 "pkill -9 pulseaudio && pipewire-pulse", this completely replaces pulseaudio with pipewire <Rutherther>just configure pulseaudio to not autostart when client wants audio <homo>I don't know how to make that by default without rebuilding tons of packages <homo>also why pipewire and wireplumber are not started automatically when installed? <Rutherther>it's just an option to configuration... ie. ~/.config/pulse/client.conf autospawn = no, I don't understand what you mean by rebuilding packages. <Rutherther>because why would they be? nothing is started automatically when installed, something has to start it <homo>ew, modifying ~/.config instead of /etc/config.scm <homo>Rutherther I'm trying to make that system-wide default which will affect everyone installing or upgrading guix system <homo>so, if I touch something in gnu/packages, it will cause a massive rebuild of many packages <homo>this will make guix like other distros - autospawn pipewire, wireplumber and pipewire-pulse <Rutherther>homo: well, it was just an example, signaled with that 'ie.', you can of course manage your pulse config with your system configuration. <homo>I want to make that default system configuration, that is upstreamed in git repo <rekado>homo: use "guix home" for launching wireplumber <rekado>and you don't need to rebuild anything <rekado>I'm now using sway on my laptop and I configured my system not to launch pulseaudio, so it doesn't <rekado>the packages are still *able* to do that but won't <homo>and how will that replace pulseaudio with pipewire-pulse in official git repo? <rekado>why would you replace it? you just need to tell the linker/loader to load pipewire-pulse instead of the libs provided by pulseaudio <lechner>rekado / Hi, I copied you, too, on my Codeberg request. I was unable to find any other current or former project maintainers there <rekado>lechner: I don't know who owns the Guix org there <homo>impossible as pipewire-pulse is linked to pulseaudio, and pulseaudio installs bin/pulseaudio <rekado>(I've come late to the codeberg party and was only recently added to the guix-science org) <rekado>homo: I don't understand your problem. All I can tell you is that on my system pulseaudio plays no active role. <rekado>(granted, my audio playback needs are limited to firefox, mpv, and ardour, but I think that's diverse enough) <iyzsong>homo: well, we can build libpulse (pulseaudio package without server part) and link all application to that instead of pulseaudio. that can avoid autostart of pulseaudio in edge cases and save some MiBs.. <homo>that's what I was thinking about, which is why I said it will trigger rebuild of many packages <apteryx>it's a bit of a fail that we can't easily map the command line interface to Scheme at the REPL <apteryx>ACTION falls back to do ./pre-inst-env guix refresh -u -e '(@ (gnu packages gtk) at-spi2-core)' <apteryx>perhaps we need ',refresh some-package' after ,use (guix) :-) <lechner>Hi, the latest Guix does not allow me to load an operating-system record inside the machine spec. What's the proper remedy, please? error: (operating-system (load "operating-system.scm")): extraneous field initializers (load) <Rutherther>lechner: what's in operating-system scm exactly? does it return operating-system record? if so, then just (load "operating-system.scm"), not inside of (operating-system) where it counts as a field initializer <orahcio>Rutherther: I managed the auto-login with conditional about tty, thanks for the tip, if I want to proceed with tty7, I need to use just %base-services instead the %desktop-services without gdm? <sneek>Welcome back orahcio, you have 1 message! <sneek>orahcio, homo says: I found the cure!!! open 3 shells, in shell 1 "pkill -9 pulseaudio && pipewire", in shell 2 "pkill -9 pulseaudio && wireplumber", in shell 3 "pkill -9 pulseaudio && pipewire-pulse", this completely replaces pulseaudio with pipewire, now the real challenge is to make that default <Rutherther>orahcio: you definitely don't need to go with base services, just removing gdm/sddm from desktop services is enough <orahcio>homo: nice the big way, pulseaudio definitively is difficult to kill <Rutherther>it's not, it's just a simple config option to not auto start <orahcio>Rutherther: I am trying again with tty7 string just removing gdm <Rutherther>orahcio: if you are starting mingetty there don't forget to also get the console-font-service-type for tty7 <orahcio>I got this error when reconfigure `guix system: erro: error parsing derivation `/gnu/store/c698bbnj8jz2dsdhv0sdvg5pbmgpnm1b-upgrade-shepherd-services.scm.drv': expected string `Derive(['`maybe it is because the font service? <Rutherther>lechner: so it already returns operating-system, I really don't get why you are loading it inside of (operating-system) <Rutherther>oh wait, it's a field, I thought you were initializing a module, having the whole code explains it more <darth-cheney>There are no arm64 isos for the guix system available anywhere, correct? <darth-cheney>I'm trying to get a vm running in the m1, and all the instructions I'm finding online are failing <lechner>Rutherther / it doesn't work the other way. <Rutherther>darth-cheney: yeah, there are no prebuilt images by the CI <darth-cheney>damn, that's too bad. What I'm doing is I have a VM with debian 12 arm running, and I'm trying to build a guix system image from within it, but it keeps failing <Rutherther>darth-cheney: what is the command you are trying and what does it fail waith? <rekado>orahcio: that sounds like file system corruption <rekado>then you may need to run "guix gc --verify=repair,contents" after fsck on the file system (if appropriate) <orahcio>rekado: the error message occur just when I try to use "tty7", I will do the verify and repair <homo>both text editor and manual counting show they are balanced <lechner>Rutherther / it doesn't work they way you suggested, even though that made sense logically <Rutherther>lechner: yup. As I said I made a mistake in assumption. I thought you were instantiating a record called operating-system, but you aren't, you are populating a field called operating-system <lechner>Rutherther / but isn't the value of that field a record called operating system? <lechner>(operating-system operating-system) effectively <Rutherther>yeah, if you did it in one place without loading it would be "(machine (operating-system (operating system ... (services ...) ...))", where the first operating system is field name, the second is record instantiation <lechner>Rutherther / thanks for bringing light into a confusing situation! <homo>I'm now puzzled even more, that missing parenthesis error fixed itself without me changing anything in that file <homo>never mind, it came back <darth-cheney>the command I'm running is `guix system image --image-type=qcow2 --image-size=50G config.scm` <Rutherther>darth-cheney: hm. Seems to me the grub-bootloader is actually not really ready for arm64, as it always "i386" no matter the target architecture. But I might be missing something <Rutherther>the grub efi is ready for arm64 though, can you use that? <orahcio>rekado: You are correct, after repair `error: error parsing derivation `/gnu/store/c698bbnj8jz2dsdhv0sdvg5pbmgpnm1b-upgrade-shepherd-services.scm.drv': expected string `Derive(['`I can not change this derivation anymore <homo>it appears "add-after 'install 'split" triggers "missing closing parenthesis" error, but how comes it doesn't trigger such error in git package? <alaskanbaguette>Hi. I was able to install GNU Guix + i3, but wasn't able to run a web browser. I tried both ice cat and nyxt, but the terminal just spits out "Killed". dmesg talks about nouveau, and something about null point dereferencing, but I'm not sure whether this is a red herring. Reason being that I was able to run Anki, which I think uses Electron.Β Any <alaskanbaguette>ideas? I used the latest version installer, but I would be surprised if that caused the issue. <Rutherther>alaskanbaguette: what you mean by latest version installer? did you pull newest guix to upgrade after you got in the system? <alaskanbaguette>Rutherther: I downloaded the latest version iso and installed that. But I also ran guix pull, guix upgrade and guix reconfigure. That didn't help though. <Rutherther>but what does latest mean? do you mean from the site - that means 1.4.0, being year and a half old, or the one from CI, being built few hours/days ago? <alaskanbaguette>Honestly, it would surprise me a bit that nouveau would run differently on linux-libre, but I don't know too much about that part of the system. <Rutherther>seems unlikely to me if other apps do work fine... but I don't really understand stuff like that, and less so without any log to go on, just "Killed" seems very strange <orahcio>rekado: Some idea to repair the derivation? I got this error `error: cannot repair path `/gnu/store/c698bbnj8jz2dsdhv0sdvg5pbmgpnm1b-upgrade-shepherd-services.scm.drv' <Rutherther>orahcio: just remove it - with guix gc -D, if something holds it there, it will tell you what and you need to remove that as well, the same process, with guix gc -D <Rutherther>you cannot really repair derivations that aren't substitutable, it cannot know what's wrong with the file, so you need to get rid of it instead <orahcio>thanks Rutherther, I will try to remove that derivation <darth-cheney>Rutherther: Thanks for your tip earlier. Had to run out to get an emergency burrito, but I think it worked <yarl>And one can't build a bootable image either. This is a very simple but efficient fix. <yelninei>lechner: I just build it successfully on current HEAD on x86_64 (I even rebuilt with --check because i got a substitute) <yelninei>derivation is /gnu/store/swfafpv6dhhlg0k8p42s8m6hzc3v8067-upower-1.90.2.drv <orahcio>nice Rutherther, just remove give no errors anymore <lechner>yelninei / do you have Dbus running locally? <yelninei>lechner: yes, i have all of %desktop-services <lechner>yelninei / thanks! maybe that makes a difference <yelninei>lechner: shouldnt the build directory be sandboxed? <homo>it seems to me that guile utilizes dynamic polymorphism, because in package definition it throws type mismatch error only after it is done building and attempts to install it <lechner>homo / what do you mean by 'install', please? <lechner>yelninei / i'm not sure what that means but i'm pretty sure it's not a container <lechner>yelninei / i think we use just unprivileged users. <homo>lechner literally (arguments (modify-phases (... <homo>it doesn't error when it compiles, it errors when it runs, which means types are not checked during compilation <Rutherther>homo: no, it's not dynamic polymorphism. The arguments are passed to guix-daemon, and only guix-daemon evaluates them. <Rutherther>that is why they are quoted, to be passed to guix-+aemon <homo>you mean they are passed as strings to daemon and then daemon compiles them? <homo>it would be helpful if it threw type mismatch error much earlier <Rutherther>it can't, you are quoting it, it's just treated as data, not code <Rutherther>lechner: it is a container. Builds run in a container <Rutherther>builds are completely isolated, to make reproducibility easier <homo>lechner: because I wait several minutes for it to finish compiling and enter install phase each time after I change package definition, if it could tell me from the get go that I pass wrong type, I wouldn't need to wait so long <homo>and it gets more difficult to fix such error with packages that take hours to build, this is where strong static type checker would save time <ieure>This is technically difficult to do, and IMO unlikely to happen. <ieure>A thing I've thought would be interesting is if Guix builds worked a bit like Docker image builds. Each step could happen in a container which inherits the state from the previous step, and unchanged steps could be cached and reused. <ieure>That'd let you solve issues with installation after a big compile without having to waste compute rebuilding the stuff that works. <ieure>Not sure how practical it would be to implement such a system. <ieure>I've definitely felt the pain around this, it sucks to sink 45m into building LibreWolf only to find that a copy command fails at the very end, or whatever. <homo>these are source and error <homo>I don't understand what that means, I am sure I passed string to mkdir-p <homo>but it complains it's not a string <Rutherther>why don't you try stuff like that in repl? you would be able to debug faster <Rutherther>you actually don't pass a string, you are passing a list to mkdir-p, because you have (lambda dir (mkdir-p dir)) instead of (lambda (dir) (mkdir-p dir)) <lechner>ieure / i feel the same about build-time tests <homo>wow, I thought () are for lambdas with multiple arguments, thanks <lechner>do you have to use file-append inside a G-Exp? <PotentialUser-36>Rutherther: Regarding icecat and nyxt just getting killed - Reinstalled 1.4.0, followed by guix pull and reconfigure, and somehow it works now. <Rutherther>lechner: what do you mean by that? have to, to do what? <Rutherther>PotentialUser-36: that's interesting, and are you sure you are on recent guix now? note that after first pull you need to relog / manually source file that will give you correct guix in path. You can check with guix describe what version you currently have <homo>lechner: do you mean string-append? <Rutherther>here it should be fine to use either file-append or string-append <Rutherther>with string-append you can move the ungexp inside of it, with file-append you need to ungexp the whole thing <lechner>i saw some code comments or Git commit commit messages that file-append was preferred <homo>well, I took code from git package <PotentialUser-36>Rutherther: Good point. I restarted and it seems I am currently on commit 7f91b12, which seems to be the newest one. <lechner>upower is not building on my equipment per above (and my Guix is modified, meaning I cannot rely on substitutes). should I disable #:tests? <Rutherther>lechner: you can try as a quick dirty possible fix. A proper fix would be to investigae what's failing and why. It is possible the test is what's broken <Rutherther>some tests can expect environment/feature that's not accessible in the container <lechner>i'll try but sometimes i wish for per-package maintainers like in Debian <Rutherther>the person who updated it probably didn't check arm architecture <homo>hm, rename-file throws "no such file or directory", but I don't see its name, so mysterious <homo>backtrace doesn't show full path to it <homo>but considering it says 0.0 seconds, I assume it means /etc/xdg/autostart/pulseaudio.desktop <homo>which is strange because that file exists <Rutherther>I don't know how your current version looks but in the old one you had utils/zhs in the let, but then use utils/zsh in the rename recursively <Rutherther>as for debugging the issue you can just do more logging, especially since you are calling a function repeatedly it will be easy to display what's being passed to it <homo>but considering it didn't error on unbound variable, it must have failed much earlier than that <Rutherther>and librewolf works? there is something strange going on with nyxt then, hm <homo>it says pulseaudio.1.zst file is not found... <homo>I see, man pages are compressed much later <dlowe>I'm having a weird thing -- I'm trying to upgrade my profile and it's complaining that 'build' phasebuilder for python-irc-parser-tests is failing <dlowe>I try to remove python-irc-parser-tests and it's not installed. I tell it --do-not-upgrade and it still tries to build it. <Rutherther>dlowe: it's probably dependency of something else, read the end of the log <dlowe>"setuptools.build_meta" "dist" "{}" failed with status 1 <Rutherther>not what I meant, and that's not right, it is very useful <Rutherther>I meant the end of the log, where you can see what package wants this one to be built <dlowe>sorry, I thought you meant the build log. I'm not sure what log you mean. Standard output doesn't say why it wants to build it <Rutherther>since the python team mearge setuptools and wheel are missing for a lot of packages, so the line you sent with setuptools error is super useful. It means python-setuptools is missing in native-inputs. And after it's added, another package is revealed to be missing, python-wheel <dlowe>is this regarding the 3.12 removal of disttools? <Rutherther>no, it's about build system change in guix, python3.10 is still used <Rutherther>anyway you are right that your log doesn't reveal the package exactly, it's strange, it usually should reveal. Anyway guix graph --type=reverse-bag python-irc-parser-tests reveals it is soju that needs it <dodoyada>guix adds emacs packages from melpa automatically, right? I was looking for treesit-auto on guix and not finding it <dlowe>Rutherther: perfect, thank you! <rekado>on commit fdcb67250af3df91b3ef090915ba32fe22cce86e python-irc-parser-tests builds again <alaskanbaguette>argh, after restarting (removed icecat and friends), the browsers don't start again <homo>dependency hell, in order to build pipewire, it is necessary to build sdl, openal, ffmpeg, qt6, gstreamer and tons of texlive and python packages <homo>alaskanbaguette2: no, I am complaining about unrelated problem <homo>I am shoked at how many and what kind of dependencies pipewire wants, this looks unbelievable <Rutherther>alaskanbaguette2: can you try instaling that older icecat again? ie. "/var/guix/profiles/system-1-link/profile/bin/guix install icecat" <homo>how comes pipewire doesn't get stuck in circular dependencies <PotentialUser-93>Rutherther: I rolled-back to generation 4 and everything seemed to work. Now, I updated my config.scm (adding some keyboard layout stuff), reconfigured, rebooted. Starting librewolf did not work, but first starting Icecat, and then Librewolf somehow works! <Hamled>homo: i'm wondering what part of it ends up depending on qt <homo>no idea, but now I seem to understand why pulseaudio is the default <lfam>error: cannot delete branch 'contrib-linux-libre' used by worktree at '/home/leo/work/guix' <lfam>But, `git worktree list` only shows a single tree, and the 'master' branch is checked out in that tree <lfam>I'll try updating Git from 2.46.0 <dtx>Hey everybody. I'm trying to get a guix system working inside a rootless podman container. Is this even possible? <dtx>I've mananged to build and run it, but loopback and urandom-seed fail to start. <lfam>Also, you can remove urandom-seed-service if you don't care about the system random number generator. Not sure about the loopback <dtx>root@2c2bf9d770e6 /# herd start loopback <dtx>herd: error: exception caught while executing 'start' on service 'loopback': <dtx>Throw to key `%exception' with args `("#<&netlink-response-error errno: 1>")'.