<ulfvonbelow>shows me a bunch of comments indicating it's in glib:bin <raguay>Does anyone know if this can run on a virtual machine on a M1 chip mac? <apteryx>mbakke: I'm looking at merging master into staging, there cu <rekado>apteryx: can we merge update-vulkan-headers-staging into staging first? <mroh>Love, Peace & Guix. Good morning! <Luk6655>hi, when creating a custom channel it seems patches are searched in user's $HOME. Is there another default search path so patches can be placed in the channel? In guix channel special search-patches procedure is created to point to a subfolder, is this basically what every channel needs if it want's to deliver patches? <sneek>Welcome back Luk6655, you have 1 message! <sneek>Luk6655, jpoiret says: the code i gave you should do exactly that (deferring the calculation of inferior-with-channels) <Luk6655>sneek, later tell jpoiret: thank you, Unfortunately it still errors, but this time at time of the build rather than guix pull. So indeed your code does deferr it, but the problem gets triggered anyway... <ulfvonbelow>Luk6655: the patch search path is just the package module search path, with the exception that patches in guix itself are searched in the gnu/packages/patches/ subdirectory. So patches in channels will be searched in the top-level directory of that channel. See %patch-path definition on line 164 of gnu/packages.scm. <Luk6655>ulfvonbelow: thanks, I read the file, but I wasn't sure if %package-module-path only refers to guix top directory. I'll give it a try <ulfvonbelow>er, actually, what I said isn't quite right: it's not the package module search path, but the guile load path <Luk6655>... no, it fails to find a patch located in the root folder of a custom channel <Luk6655>so I guess guile load path doesn't by default point to a custom channel's root folder <ulfvonbelow>huh. run 'guix repl', evaluate (use-modules (gnu packages)), then check the value of %patch-path is what I'd do. <ulfvonbelow>or rather, the value of (%patch-path), since it's a parameter <Luk6655>it points to various store locations and profiles, I know it doesn't point to a channel root folder, because I placed the patch file there and it failed to load <Luk6655>btw, am I supposed to use search-patches, or just patches (list "file.patch") ? <Luk6655>it seemed to me search-patches was guix channel specific <Luk6655>it seems this would be a very common thing, to be able to deliver a patch in a custom channel... <Luk6655>yes, it works with search-patches and placing patch file in the channel's root folder ***jesopo is now known as jess
***PotentialUser-16 is now known as elevenkb
<sneek>Welcome back unmatched-paren!! <Luk6655>there is some way to display dependency between two packages, but I forgot how to do it and I can't find it in the manual... does anyone know? <Luk6655>mroh: thanks, but I read it few times (perhaps I missed something?), but it seems it is all for a situations where you're interested in one package and drawing graphs from it (up, down etc) not between two packages <ulfvonbelow>are there any examples of using 'guix home' to manage icecat profiles? <ss2>hello, I've got this problem with Guix on Debian: whenever I populate my profile with packages, KDE will fail to find breeze' icon them. Anyone else run into this yet? ***Dynom_ is now known as Guest4639
<pkill9>ss2: is the guix profile's share directory in XDG_DATA_DIRS? <ss2>It comes first before /usr/share <ss2>right, removing everything fixes it again. To bad that plasma is now broken, where the session won't load properly. <karrq>hello. I'm running guix in a foreign distro (arch) and sometime ago it just stopped being able to update. I remember there's some kind of issue with arch's guile package being stripped with also files needed by guix... <ss2>how did you install Guix in the first place? <karrq>I forgot honestly, it was a while ago <karrq>right I remember something about starting the guix-daemon as root instead <karrq>but I think that was a temporary not so nice fix <reza>Hi, I want to setup the channels as part of my os configuration file. to do so, I used the `etc-service-type` but during the boot, I faced an error mentioning about the readonly file-system https://paste.pics/IM89Y <reza>(define (channels-service channels) <reza> (simple-service 'channels etc-service-type <reza> `(("guix/channels.scm" ,(computed-file "channels.scm" <reza> (with-imported-modules '((guix build utils)) <reza> (use-modules ((guix build utils))) <reza> (call-with-output-file "channels.scm" <reza> (format port "CHANNEL LIST GOES HERE"))) <reza>does anyone have any idea how I can setup the /etc/guix/channels.scm file as part of my system configuration file? <reza>mroh: Great thank you! I'll try that approach. I also used the special-files-service-type <mroh>you are welcome! Glad, I could help. <Kabouik>I don't know what is wrong with my system now but since my attempts yesterday to install me own copy of cyrus-sasl using pre-inst-env, Guix keeps trying to rebuild the whole world, even when I don't use the prefix env variables we discussed yesterday. <Kabouik>I hope when it finally succeeds this will be sorted out, but it's literally building since 24 hours (and crashed a few times due to OOM). <Kabouik>I aborted a few times and wanted to get back to this situation later, but now I just wanted to install a simple package, and it's still rebuilding things like samba now (though it's not a dependency for nnn) <Kabouik>nnn being the package I tried to install. <Kabouik>I have not tried that, but I was thinking I should try to let guix finish (unless it goes OOM again) before trying other guix commands, since it's already been a few hours on this attempt <Kabouik>guix build nnn-ctx8-git (my modificatioin on my private channel) also finds a version in my store, but the "guix install nnn-ctx8-git" I ran hours ago is still building other things <Kabouik>It's still not the big rebuild from yesterday with pre-inst-env, that was failing on webkit due to lack of RAM. So I have not been able to test cyrus-sasl.scm, but I submitted the patch anyway because (i) I could confirm it builds, and (ii) the change is simple enough to be confident it does what it shoullld (in other distros, this is what they did too to fix the issue I am having with Exchange servers, build with "--enable-login"), see: <mbakke>I've found a new pastime for when I'm not hacking on Guix... writing about Guix! <mothacehe>apteryx: hey! regarding the news entries, we can split the work if you want. I can take the upper 50% of the commit log? <sneek>mothacehe, you have 1 message! <sneek>mothacehe, apteryx says: would you know how to make the action of registering store items in the system images used by the system tests conditional to whether a guix-daemon is configured for that system (the way we do it for docker images) <apteryx>mothacehe: that's a good way! (splitting the log :-)) <mothacehe>good :) regarding your question, what would it be for? <apteryx>efficiency! it's slow to register the store items in the guix database, and wasteful if it's not necessary <pkill9>I want to write about guix and make showcase videos for guix <apteryx>mothacehe: we'll want staging in master; I've already mentioned the reduced Rust bootstrap in the NEWS, but it lives in staging :-) <mothacehe>ok, it gives us some time to work on news update and shepherd issues :) <mothacehe>i'm a bit afraid to jump into shepherd code as i didn't follow the fiberization closely <apteryx>which issue are you looking at specifically? <mroh>oh, interesting. I just get an eof error while offloading to a machine with shepherd updated. Was working before. Also I cant ssh to this box anymore ;( <ulfvonbelow>hmm, when I try to configure ibus, I get "failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files" <apteryx>wow, magit seems much faster with comp-native <apteryx>mbakke: the master -> staging merge was easier than expected <rekado>apteryx: have you merged update-vulkan-headers-staging before that? Or does that need to be rebased on top of the latest staging now? <ulfvonbelow>(aformentioned error appears to prevent changing any ibus settings) <apteryx>rekado: I haven't touched that branch, no. yes, it should be rebased <mbakke>apteryx: nice :) did you try staging->c-u too? <apteryx>in the process of it, it was a bit more conflicted ;-) <apteryx>magit is no longer sluggish in viewing the large diffs, which is awesome! <mbakke>nice, it could take minutes to render a big merge earlier <apteryx>should we use (librsvg-for-system) for gtk 3 and 4 ? <apteryx>librsvg-bootstrap which I used on master is no longer a thing or cu <mbakke>probably the default 'librsvg' variable should be (librsvg-for-system)? i.e. rename the current to 'librsvg-rust' <mbakke>I'd go with (librsvg-for-system) in the merge <apteryx>good; another thought: librsvg-rust is really librsvg; longer term when our rust bootstrap works on all targets it won't be an issue anymore <antipode>mbakke: Nitpick: the instructions posted on that blog entry don't (currently!) work for go and rust, IIUC <rekado>apteryx: thatās a pity. This branch had already been built for a while. Iāll rebase and push again. <apteryx>rekado: if it's ready, feel free to merge it <apteryx>mbakke: master merged into staging and cu <podiki[m]>apteryx: not sure if you saw the guix-devel discussion about updates needed for the new icecat version (our current version being dropped for next ESR version); it will need the newer rust from staging <podiki[m]>any guesses for when staging will be merged into master? we can always cherry pick the couple of rust patches out (esp with subs already built) <apteryx>podiki[m]: redirecting the question at mbakke; but I think it's rather imminent :-) *podiki[m] loves shiny new packages <efraim>good news is I don't have to rebuild rust with the master->staging merge <antipode>is ci.guix.gnu.org for other people too or is it just my local network connection? ***maximed is now known as antipode
<ulfvonbelow>apparently our gdm-dbus-wrapper hardcodes ~/.guix-profile, and consequently misses ~/.guix-home/profile. Being unfamiliar with dbus, is there a particular reason this can't be run with the usual user environment? <apteryx>IIRC the dbus package hard-codes known locations containing dbus service definitions, such as /etc/dbus/* and ~/.guix-profile. <jpoiret>maybe we could parameterize this over an env variable, if that isn't already the case? <jpoiret>isn't XDG_DATA_DIRS inspected though? <apteryx>I keep forgotting about the details, but I think 51439 captured the issue <pkill9>could multiple instances of guix share a single store? <jpoiret>what do you mean by multiple instances of guix? <pkill9>eg multiple vps instances of guix sharing a single guix store from a remote server mounted at /gnu/store <ulfvonbelow>I don't understand why we can't just source /etc/profile and let it take care of setting up the environment for the dbus daemon <jpoiret>multiple guix daemons shouldn't use the same guix store, otherwise they won't have the same view of the store in their database <pkill9>i suppose it tracks everything in an sqlite database <jpoiret>pkill9: you could use a substitute for that though <ulfvonbelow>I don't think there's any exclusivity requirement for the daemon's synchronization measures to work, though I might be wrong <jpoiret>oh, but you want it to only be on one mountpoint, right <pkill9>i wonder if the guix database could be shared <pkill9>yeah,im just thinking, not gonnadothis <jpoiret>maybe you could configure guix to talk to a remote guix daemon instead of a local one <jpoiret>i'm not sure about the specifics or if it's entirely possible at all <pkill9>was curious after reading about vultr's block storage services <jpoiret>i don't think it could be shared without some refactoring and a bunch of locks everywhee <jpoiret>ulfvonbelow: re dbus, wdym by "let it take care of setting up the environment"? <jpoiret>we can't know for certain which directories one would want to use to host dbus services <jpoiret>XDG_DATA_DIRS is a reasonable option because profiles _should_ set them, although since they're pretty generic env variables that are used by a bunch of packages, i'm not sure which one should be installed <ulfvonbelow>hm, I was under the impression that sourcing /etc/profile would set up a user's environment, but it seems it only does that for ~/.guix-profile, and delegates sourcing ~/.guix-home/profile/etc/profile to ~/.profile <jpoiret>i'd rather have an interface on top of profiles (like guix system or guix home, but factorized) that would let you define "entry-points" that would activate said configuration, in which you could have an xdg-activate part or something similar <jpoiret>the XDG spec shouldn't be handled as a search-path of a particular package <jpoiret>but /etc/profile can't guess what the user wants to activate <ulfvonbelow>so wait, there's supposed to be a distinction between "installed" dbus services and "activated" dbus services? <dirtcastle>this is my first system reconfigure after installation and it doesn't go through fully successfully. <ulfvonbelow>.tar.xz.drv? That sounds like it's failing to download sources. Have you retried the command? <vivien>The pango-next issue is stupid to fix (in the pango-next definition, donāt use the package name, use "pango", otherwise it will query "pango-next" which is not a GNOME package) <vivien>But itās frustrating because the person who did the upgrade already had the file with the correct hash, so guix never tried to download it again after the rename <vivien>So, from the point of view of the person who published the upgrade, everything works reproducibly <acrow>git.savannah.gnu.org seems to be unreachable... guix pull fails. <vivien>Weāre relying on the CI to catch these sorts of bugs <acrow>Hmm... not here. I can get to the usual places google, et-al.... <apteryx>dirtcastle, vivien: ah, thanks for pointing that omission of mine <vivien>Donāt take my frustration against you please :) <vivien>Iām very grateful for the updates as a whole <dirtcastle>ulfvonbelow: I ran system reconfigure multiple times. <acrow>It looks to be a DNS problem here. <Grimpper>Hi. I'm currently trying to debug what seems to be a bug with the last emacs version on the guix repositories. It's okay to ask for debugging advise of emacs here? The problem is with the emacs-guix package and emacs with native compilation support <Grimpper>Okay so here is the issue. I've been struggling for the last days trying to find a solution for this problem. I'm currently using emacs with native compilation (28.1) however for some reason, I don't get it to work with the emacs-guix package; although I've got it to work in older versions of emacs. Could someone knoledgeable of lisp give me a <Grimpper>suggestion on how to debug this problem? This is the error I get when trying to launch <Grimpper>guix-start-repl-maybe: Symbolās value as variable is void: geiser-repl-company-p``` <Grimpper>```Debugger entered--Lisp error: (error "No prompt found!") <Grimpper>Ā geiser-repl--start-scheme(guile nil "\\(^[^@(\n]+@([^)]*)> \\)\\|\\(^[^@(\n]+@([^)]*?) \\[\\([0...") <Grimpper>Ā guix-start-repl(#<buffer *Guix REPL*> nil) <Grimpper>Ā guix-start-repl-maybe(nil "Starting Guix REPL ..." nil) <Grimpper>Ā #f(compiled-function () #<bytecode 0x5a734f009be489a>)() <Grimpper>Ā apply(#f(compiled-function () #<bytecode 0x5a734f009be489a>) nil) <apteryx>dirtcastle, vivien, should be fixed with 512fa6c7e5 <Grimpper>I'm sorry. I thought we had markdown syntax for code blocks <antipode>Grimpper: paste.debian.net or equivalent for code or error dumps <antipode>(for the future, not needed anymore as it's done here anyway) <apteryx>Grimpper: I reproduce the issue. emacs-guix has not gotten much maintenance <Grimpper>You do? Damn I was going nuts rolling back versions and what not <apteryx>you could report it by sending an email with the details to bug-guix@gnu.org <Grimpper>Okay. I've never wirtten bug repport will look how to do that. But isn't the bug related to the github package repository instead of guix? <mbakke>apteryx: thanks a lot for the merge ! <mbakke>I haven't checked the CI weather in a while, last I checked staging was just waiting for aarch64 to catch up <antipode>From what I've heard of nckx, there have been firewall problems. <acrow>My dns IS resolving for git.savannah.gnu.org but git says the network is unreachable -- ping says otherwise. I think the problem is my git, hmmm... I'm going to try an upgrade (I did a good pull yesterday). <Grimpper>Anyone could share with me resources to learn guile scheme and elisp? I'm really strugling to create guix packages. <acrow>Grimpper: The guix info manual is very good. <acrow>Grimpper: maybe not elisp but certainly guile/guix. <Grimpper>I know. But If i knew elisp i would be able to fix the emacs-guix package <antipode>Emacs has an elisp manual but I don't know if it's good, I haven't ever tried it or elisp. <acrow>the emacs elisp manual is also very good. <Grimpper>acrow: But that manual expects you to know guile and doesn't really teach you packaging, rather the general guix API <acrow>Grimpper: Another thing that might help is the guile info manual which guix installs along with guile. Your learning guix packaging request may demand that you use the info docs as well as the guix source for inspiration. It is a varied and demanding art. <antipode>(there is also (guix-cookbook)Packaging Tutorial and (guix-cookbook)A Scheme Crash Course) <Grimpper>Well the hello world package it's clear. But when I try to do rust or whatever it's get much more complicated than a hello world <Grimpper>I will surely check those resorces. I know it requires dedication but my biggest problem is my lack of knowledge of the language <acrow>Grimpper: Not to be discouraging, rust is an extreme case. <antipode>Grimpper: There are some changes in progress w.r.t. Rust to simplify the packaging (antioxidant-build-system), but it's not quite there yet. <antipode>Grimpper: Do you know about "guix import" yet? <dirtcastle>Grimpper: andrew tropin's yt videos and guix & guile manuals are amazing resources. I don't how to package but I'll go through these if I had the time <antipode>For many types of packages, "guix import" can automatically generate a package definition, including (Rust) packages from crates.io <Grimpper>That's great. I've heard about guix import but I'm not really able to know which template I should use <antipode>Grimpper: "guix import" does not use templates. <Grimpper>Doesn't it import a basic scheme template to build upon it? <antipode>No, well yes, from some point of view, but it's all done automatically, you can't ask it to āchoose a different templateā <antipode>Instead, you ask it to āmake a package definition for FOO from PyPi/ContentDB/crates.io/hackage/cpan/...ā <antipode>For a simple example: "guix import minetest worldedit" <dirtcastle>(doesn't look like my msg gone through) Grimpper: andrew tropin's yt videos and guix & guile manuals are amazing resources. I don't know how to package rn but I'll go through these if I had the time.build systems is the keyword u must be looking for <Grimpper>Yeah. I've seen that he does some videos. I will check them out also. Thanks! <acrow>I complained about guix pull failing with network errors, but I've succeeded getting a guix pull to work on another machine. So, I don't know why guix pull fails on one machine but not another but it is a local issue. Sorry for the false alarm. <attila_lendvai>my guix doesn't boot anymore with the error "no code for module (ice-9 popen)". it happened after i ran some `guix gc --delete-generations=60d` and `guix system delete-generations 60d`. i suspect the culprit was the latter. what did i do wrong, and how can i fix it? <attila_lendvai>there still are 3 system generations, but all of them dies with the same error early in boot <dirtcastle>isn't guix supposed to fix this exact problem :'). ( I suspect it's a problem with grub. but I'm noob) <pkill9>i think i had this issiue before, I hope you can fix it attila_lendvai because I fear boot problems and being dumped into a guile console <attila_lendvai>pkill9, it even goes to kernel panic because init returns. not sure why, though, because it prints the debugger welcome message with ,bt and friends <ulfvonbelow>off the top of my head, that sounds like there was an obfuscated reference somewhere that the scanner didn't see, and consequently wasn't protected from garbage collection. But (ice-9 popen) is a module that's built-in to guile, so that wouldn't make much sense. <attila_lendvai>dirtcastle, it's later than grub because the early boot guile is already speaking at this point <attila_lendvai>ulfvonbelow, no. it looks like the debugger can output what it wants, but fails when it tries to read the input <dirtcastle>where to learn to hack on guix. should I just start reading the source code <attila_lendvai>dirtcastle, if you're familiar with lisp then that's not a hopeless task. if not, then i suggest a scheme intro, and the manual <pkill9>why does guix rely on seeking out references instead of just using the specified inputs to determine the references? <ulfvonbelow>I'd start by making sure you understand the foundational concepts by reading eelco dolstra's nix thesis as well as the parts of the manual that cover them <ulfvonbelow>pkill9: because gnu hello shouldn't require gcc at runtime <pkill9>but that's in native inputs which is genrrallyjust ignired <ulfvonbelow>to give an even more extreme example, because Rust Hello shouldn't require rust-{59,58,57,56,...} <dirtcastle>I know syntax of scheme. I never had real programming experience. idk what terms like shell, environment, profile mean. ulfvonbelow <dirtcastle>correct me if I'm wrong but are u asking me to read nix manual? <acrow>Running guix package -u on my system has re-enabled guix pull. :) Much better than a login-cycle or, ugh, restart. *attila_lendvai goes AFK for a dinner <ulfvonbelow>no, just the paper that describes the design of nix, namely derivations and how they work <zamfofex>dirtcastle: What is your current goal? Do you have a specific addition or change you want to make, or do you just want to learn how to contribute in general? <zamfofex>A couple more notes about my issue: Iām using ā--with-patchā for glibc, and I *believe* it turns out Guix doesnāt allow the patched glibc to be referred to by ābinutilsā for some reason. Which is strange, because I think binutils doesnāt even list allowed/disallowed references. <dirtcastle>I want to write package definitions and services and make selfhosting easy to do and manage for myself and other noobs. <zamfofex>It would be neat if ā--with-patchā could account for that, but maybe Iām asking too much. <tricon>dirtcastle: i'm interested in packaging sourcehut and making it a service as well. <dirtcastle>idk if those already exist... idk if anybody will find it useful. <dirtcastle>i thought guix being reproducible and reliable through rollbacks it would be great for servers. <zamfofex>dirtcastle: I think I can count with my two hands the number of people who find useful over half of the things I work on, but that doesnāt stop me from enjoying working on them! And from time to time, people do end up finding interest in them for some reason or another. As they say āyou fail 100% of the things you donāt startā. <tricon>zamfofex: agreed. i have probably a dozen Guix packages i wrote last year that i've been lazy about submitting; but even if no one ever uses them, i needed them and really enjoyed creating them. it's always at least one win. <Kabouik>Where can I find a list of correct license abbreviations for packages? One of the patchset I have sent has been reviewed and apparently licenses are off ***LispyLights is now known as Aurora_v_kosmose
<Kabouik>Maybe I need to rebuild my email client against that variant of cyrus-sasl actually. <Luk6655>If using guix as package manager do we still have /gnu/store, or does it become ~/gnu/store (also the same question for /tmp) ? <antipode>First question: yes, also what else would you use guix for (I suppose you could install it for "guix download" but that seems rather heavy-weight to me). <antipode>Luks6655: Guix does not have anything named "guix os". <antipode>Even if you are using Guix System, you are still using Guix as a package manager. <antipode>Because the linux(-libre) package needs to be built (which requires dependencies), many packages for services (and their dependencies) are needed, possibly you are putting some things in 'packages'. <Luk6655>ok, so to clarify, I am using guix as an operating system (os in short), however, I indent to install it as a package manager on another distro too elsewhere and I wonder if I have to have it access the root filesystem (/gnu/store) or will it keep the store folder in my $HOME <antipode>Well you can reconfigure guix with --localstatedir=$HOME/gnu/store but I don't think you'll like the recompilation times. <antipode>And the occasional _failures_, there is a shebang length limit imposed by Linux IIUC. <antipode>--with-store-dir=$HOME/gnu/store --localstatedir=$HOME/dunno/somewhere/in/HOME/I/guess, I meant <antipode>I don't remember the default but it isn't /tmp or /home/... <Luk6655>I noticed on guix system failed builds end up in /tmp (whether they actually happen there I don't know, I assumed they are, but perhaps that's wrong). What I would like to do, is to separate /gnu/store from the root filesystem - I'll do that by creating a separate mount point /gnu, then I would like to put the build folder on fast nvme storage <Luk6655>based on my earlier assumption that would be /tmp <antipode>They do happen there, though if succesful, the /tmp/guix-build- is removed. <antipode>I suppose you can put /gnu/store on another file system but I don't see the relation to /tmp. <Luk6655>I need to separate /gnu/store from the rest of the root for backup reasons. There are lots of snapshot based backups of the root fs going on that I don't need /gnu/store to be a part of <antipode>It adds a risk though: the localstatedir is _not_ in /gnu, so it could become out-of-sync with the actual store if you do filesystem-level rollback/snapshot/../(recovery?) things, from what I've heard. <Luk6655>what is the usual location of localstatedir? <antipode>As I've written previously: āI don't remember the default but it isn't /tmp or /home/...ā <antipode>Is documented in the manual, search for 'localstatedir'