IRC channel logs

<nckx>Whatever Guix prints out.

<nckx>It's relevant in the context of the command, not outside of it.

<nckx>Corollary: don't go adding it to shell start-up files, Guix is not asking you to do that.

<Guest14>Hi, I am trying to install GuixSD on my Thinkpad T440p with coreboot. I boot the iso from the usb and I see the initial screen to install Guix and then I press Enter, then I end up with a gray screen with Guix logo, I cannot reach the blue screen to start installation. Any help is appreciated!

<nckx>Is the grey screen with Guix logo the background image from the previous (GRUB) menu? I'm guessing it is, and that for some reason Linux is unable to use the screen.

<nckx>Which is surprising on an old Thinkpad.

<Guest14>Yes it is the same background image

<nckx>I'm not hopeful, but does pressing ‘e’ at the GRUB menu and editing the kernel command line to remove ‘quiet’, then booting with C-x make any difference?

<nckx>I'm a bit surprised that our kernel doesn't include GOOGLE_FRAMEBUFFER_COREBOOT. Maybe because it depends on GOOGLE_FIRMWARE which sounded scary?

<nckx>I know it's possible to build Coreboot without support for VGA blobs, but I'd still expect the i915 driver to take over & work.

<Guest14>I just did and it did not help. I tried other commands there before but no success so far

<Guest14>and the screen is not fullscreen, the screen that I see is somewhat less than the half of the screen where I see the background image and logo

<nckx>I'm sorry, nothing immediately comes to mind.

<nckx>I know people have installed Guix System on their corebooted T440p. But one coreboot build is not the other.

<nckx>ACTION → 😴💤

<Guest14>Thats ok

<apteryx>civ

<apteryx>sneek later tell civodul thanks for fixing the rewrite-url test!

<sneek>Will do.

<drewjose>Is there any reason for ghc being stale? 9.2.5 instead of 9.2.8 (to be fair they were only released 6 months apart). I would like to request a version bump somehow, is the issues ML the right place?

<mekeor>drewjose: sure, you could file a bug by sending a report to the guix-bugs mailing-list, yes.

<mekeor>Guest14: i don't know how, but it'd be best if you could somehow gather an error message or so.

<Guest14>mekeor I am looking into that

<ieure>Okay, I'm trying Guix again.

<ieure>I downloaded the 1.4.0 VM image and ran it like the manual says.

<ieure>I ran `guix pull`, since I know the image is a bit out of date.

<ieure>At the end of the pull, it says "hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/sherab/.config/guix/current/bin/guix'."

<ieure>It does not say what it should be set to or have a pointer to any more information. This is the literal first command I've run in the VM.

<ieure>There's this post to help-guix from 2020 with the same situation: https://lists.gnu.org/archive/html/help-guix/2020-01/msg00114.html

<full-recovery>"what does this mean??" https://lists.gnu.org/archive/html/help-guix/2020-01/msg00114.html

<ieure>Which says "If you are using Guix System you don’t need to do anything."

<ieure>So like. Do I need to do anything here, and if so, what?

<ieure>A Reddit poster had the same issue: https://old.reddit.com/r/GUIX/comments/f84saw/new_guix_user_that_needs_help_what_does_this_mean/

<ieure>And another https://old.reddit.com/r/GUIX/comments/dh0o90/some_guix_beginner_questions_and_daily_usage/

<ieure>Seems like a common problem.

<ieure>Okay, so my hypothesis is that the message prints even if you don't have to update PATH. I believe that /home/guest/.config/guix/current/bin is what should be in my PATH, and it is already.

<free>Hello friends, are there riseup.net users here? For privacy purposes, I want to have a riseup email but I don't have an invitation code, can someone provide me with an invitation code? To be clear, due to my location, I can't seem to offer any compensation unless you need internet service.

<drewjose>uh, add" /home/sherab/.config/guix/current/bin/guix" to path if it isn't? ieure

<drewjose>yeah you got it

<ieure>drewjose, Yeah, it's just a very confusing message.

<ieure>It should be way less dumb. Cloning the source now to see how hard that'd be.

<ieure>Okay, now is my next favorite thing, "guix system: warning: cannot determine provenance for current system"

<ieure>This is in the VM, I ran "sudo cp /run/current-system/configuration.scm /etc/config.scm"

<ieure>And got that message when I ran "sudo guix system reconfigure /etc/config.scm"

<ieure>So far, every attempt at Guix has started griping about provenance early on and never stops once it starts.

<ieure>What's the deal with this, how I do I debug it?

<ieure>Or is it another scary-looking message that actually means nothing?

<lilyp>ieure: it actually means nothing, it just tells you that this guix has been configured in a way that you can't tell where its configuration lies

<lilyp>moving it around doesn't help you, you have to reconfigure it once which will give you provenance by default

<civodul>Hello Guix!

<sneek>civodul, you have 1 message!

<sneek>civodul, apteryx says: thanks for fixing the rewrite-url test!

<civodul>yw :-)

<janneke>hi civodul, and +1

<civodul>i thought berlin was supposed to be turned off yesterday night and felt bad because i had forgotten about it

<civodul>but apparently it’s hasn’t been turned off?

<Lumine>Hello #guix !

<janneke>rekado: headsup, i've added java-rdf.scm to gnu/local.mk

<janneke>lilyp: ^

<efraim>I think I've figured out the julia patches to keep the speed-up from openblas-ilp64 and not have julia choke on lapack not have '64_' symbols

<davidl>Important security notice I believe:

<davidl> https://www.bleepingcomputer.com/news/security/google-assigns-new-maximum-rated-cve-to-libwebp-bug-exploited-in-attacks/

<davidl>guix graph --type=reverse-bag libwebp # a lot depends on this lib

<rekado>janneke: thank you!

<rekado>civodul: yeah, weird

<janneke>yw :)

<rekado>it would be news to me if all our servers were on UPS

<rekado>civodul: could also be that maintenance of the power station simply didn’t require a complete shutdown of the data center after all

<rekado>I’ll ask later to satisfy our curiosity

<civodul>rekado: alright, thank you!

<civodul>i’m glad we didn’t mess up with anything

<civodul>davidl: indeed, thanks for the heads-up

<civodul>i don’t know if anyone’s working on it, but if you want to prepare a patch, do ping this channel when you have something!

<efraim>heads up if anyone is interested, raspberrypi5 was just announced, looks like it'll be ARMv8.2

<efraim>ACTION checked the GCC sources rather than try to figure it out from broadcom or RPi

<nutcase>Hi, can I refer to a specific output of a package with specification->package?

<efraim>nutcase: you want specification->package+output

<efraim>so that'd be something like git:send-email

<nutcase>efraim: exactly, with `(packages (append (map specification->package '( ... "git:send-email" ...)))), I get https://paste.debian.net/1293380/ .

<full-recovery>"debian Pastezone" https://paste.debian.net/1293380

<efraim>change specification->package to specification->package+output

<efraim>the default is :out, so you won't have to change any of the other packages

<nutcase>Docs say: "To avoid that, one can use the specification->package procedure of the (gnu packages) module, which returns the best package for a given name or name and version:" [https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html#Globally_002dVisible-Packages]. It (correctly) does not tell how to provide name + output or name + output + version.

<full-recovery>"Using the Configuration System (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html#Globally_002dVisible-Packages

<nutcase>efraim: thanks, this works.

<mekeor>hello guix!

<allana>Hi #guix! Anyone here have experience debugging package definitions where we have a Python extension module which fails to pass a sanity-check due to undefeined symbol(s)?

<mekeor>is it possible to remove a package-input on the command-line? e.g.: guix install emacs-consult-eglot --with-input=emacs-eglot=NOTHING

<mekeor>allana: could you share more detailed error messages with us? it seems like you need to patch the package's source code somehow, or deliver some config flags.

<rekado>mekeor: I don’t know, but you could use “hello” instead of “NOTHING”

<rekado>not quite the same, of course, but the effect should be comparable

<mekeor>oh cool, in my concrete case, it makes sense to replace it with emacs-next, and it works, too! yeay :) thanks, rekado :)

<rnytom>Hi guix! When running `etc/teams.scm cc-members` (which is now run when through git-send-email) on a Debian host inside an environment created with 'guix shell', I get a backtrace that ends with 'no code for module (guix ui)'. Has anyone seen this issue before?

<allana>mekeor: ImportError: /gnu/store/31qypcwzn63p1ldxw2j5jskgx107qr0r-python-awslambdaric-2.0.7/lib/python3.10/site-packages/runtime_client.cpython-310-x86_64-linux-gnu.so: undefined symbol: _ZN3aws14lambda_runtime7runtime12post_failureERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS0_19invocation_responseE

<allana>So, that's the exact error. I have applied patches to the input library, and the extension builds fine. But when running the sanity check it fails with that message

<civodul>rnytom: hi! i guess you need to run ‘./pre-inst-env etc/teams.scm …’ so that it can find (guix ui)

<civodul>maybe that’s a regression?

<civodul>maybe not: it’s been that way for more than a year

<civodul>that said, i can see why it’s a problem on foreign distros

<rnytom>civodul: Thanks! using './pre-inst-env' does the trick indeed, I didn't even think about trying that --'

<rnytom>I can now also successfully do './pre-inst-env git send-email' when sending patches

<rnytom>Maybe there could be a note about it in the manual? I'll check where it could fit

<SuperKamiGuru>I was looking through the "Invoking Guix System" docs and noticed that there is an example of building a qcow2 image with grub-efi-bootloader using lightweight-desktop.tmpl, but underneath it states with the qcow2 image type "The grub-bootloader bootloader is always used independently of what is declared in the operating-system file passed as

<SuperKamiGuru>argument"

<SuperKamiGuru>So does that mean that in the example where it says it is generating a qemu img with grub-efi-bootloader, it is actually using grub-boot loader?

<SuperKamiGuru>Link to the page I am referring to https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html

<full-recovery>"Invoking guix system (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html

<civodul>SuperKamiGuru: hi! it means that the ‘bootloader’ field is overridden when running ‘guix system image -t qcow2’

<civodul>on another topic: i just noticed that ‘r-build-system’ doesn’t honor ‘parallel-job-count’

<civodul>apparently the number of R processes that are spawned is always equal to the number of cores

<civodul>does that ring a bell, rekado?

<rekado>oh, good catch

<SuperKamiGuru>civodul: Ah ok. Thanks for the clarification. Wasn't sure with the way the example above it was worded

<gabber`>is there a way in Guix to allow an unprivileged user to bind a port to a socket?

<nckx>I still need to do a final review but <https://issues.guix.gnu.org/61462> would allow setting cap_net_bind_service on arbitrary binaries (but this would not privilege entire users).

<speedy-recovery>"Add support for file capabilities(7)" https://issues.guix.gnu.org/61462

<rekado-web>evolution-data-server fails to build, so gnome-shell fails to build

<rekado-web>I just upgraded an old workstation to the latest Fedora. They have since removed nscd from the distribution, so now things like git no longer work, because Guix software can't talk to the host system's sss service.

<rekado-web>I vaguely remember that there might be a way to let Guix software talk to sss over /var/lib/sss/pipes/nss

<rekado-web>any ideas how to accomplish this?

<rekado>I suppose it involves putting libnss_sss.so from Guix on the LD_LIBRARY_PATH, and hope that this library will talk to /var/lib/sss/pipes/nss

<rekado>civodul: can you give me an example of a package where R uses all available cores?

<rekado>the build system uses R CMD INSTALL, which in turn uses install.packages(); that procedure takes an argument Ncpus, which by default is whatever getOption("Ncpus") returns (or 1).

<rekado>that’s used as an argument to ‘make‘ (if it needs to be called)

<rekado>I confirm that this works: export LD_LIBRARY_PATH=$(guix build sssd)/lib

<rekado>with this change Guix software works fine on Fedora (without nscd)

<lechner>sneek / later tell nckx / thanks for your help yesterday! I think I got a little bit ahead of myself

<sneek>Will do.

<davidl>civodul: np! No chance Ill be able to prepare a patch for it (although I wish I had the time to work more on Guix related things :-) )

<gabber`>nckx: thanks for the info. i think i could work with that :)

<civodul>rekado: i think you can still set up nscd on Fedora, even though it’s not installed by default, right/

<civodul>?

<civodul>alternatively, if/when sss becomes ubiquitous, we can libc close over it

<lechner>sss is becoming ubiquitous?

<efraim>also I'm not sure about gnome-shell not building on master

<civodul>lechner: it’s effectively seen as replacing nscd, without the “cache” part

<avalenn>Packaging is a really tedious task. Every software has its own way to build and I hit problems after problems. I just want one package but I am in dependency hell.

<avalenn>for kapitan (python-software), I need go-jsonnet (Go library) which is coupled by common FFI interface shared with jsonnet (CPP library) which now needs rapidyaml which uses git submodules for some of its dependencies

<avalenn>How do you guys cope with that ?

<avalenn>ACTION sends a lot of love and admiration to all packagers in the world

<avalenn>I just rage-quit the thing for today. Will come back to it an other day.

<civodul>avalenn: heh, the “preferred” way of dealing with that in Guix is by “unbundling”: having a package for each dependency

<civodul>as opposed to just fetching all the submodules and building stuff from there

<civodul>it can be tedious sometimes though

<rekado>civodul: I haven’t found a way to install nscd

<civodul>oh, so they really really didn’t like it

<rekado>there seems to be no package for it, but perhaps it’s part of some other package

<mirai>Turning maven/(java?) dependencies into a DAG has got to be one of those ancient greek pantheon joke tasks

<avalenn>rekado: https://www.fedoraproject.org/wiki/Changes/RemoveNSCD

<speedy-recovery>"Changes/RemoveNSCD - Fedora Project Wiki" https://www.fedoraproject.org/wiki/Changes/RemoveNSCD

<graywolf>Is there any blogpost or guide available for adding new updaters? I have a package in a channel-that-shall-not-be-named and would like having guix refresh working with it. 1. Is that possible? 2. How?

<rekado>avalenn: I know about this.

<rekado>I just wonder if we should do something about this to make Guix work better on systems like this where nscd has been removed

<rekado>(our advice of installing nscd no longer appears to apply)

<rekado>mirai: you can unroll cycles but it’s even more tedious than the original task

<mirai>It's fun when there are things like A->B->…->Z->A (cycles with length >2)

<mirai>I wonder how much additional fun is there to be had with circuits instead

<mirai>I guess perhaps an earlier version of some package A might have less cyclic dependency problems and can be more amenable to do the unrolling

<mirai>but the task of figuring out what to unroll is now augmented with the dependency graphs of every past version of the involved packages

<jonsger>ACTION has a "similiar" bug like rekado. openSUSE Tumbleweed "guix build" won't work because /etc/services moved to /usr/etc/services

<mirai>I'm sure there's some graph theoretical goodness that can help here or perhaps some kind of program that can help navigate this mess

<mirai>but transforming cyclic graphs with hundreds of nodes into a DAG by hand is untenable

<superkamiguru>Is there anyway to disable the grub-bootloader override when creating a qcow2 img with "guix system image"? Trying to make an aarch64 compatible qemu image and my previous methods that used to work are no longer working

<lilyp>janneke: oops

<podiki>why does guix refresh libx11 -l only show a few dependent packages? mesa depends on libx11 and doesn't come up

<podiki>does it miss because it is a propagated-input?

<efraim>there's likely a minimal version

<weary-traveler>between enabling a guix profile in current shell by sourcing "$GUIX_PROFILE"/etc/profile vs invoking guix shell and passing profile as a parameter, which is preferred? what are the differences/tradeoffs?

<lilyp>weary-traveler: the difference is $SHLVL

<lilyp>in the first, you remain in the same shell, in the latter you spawn a subshell

<lilyp>take care that your rc files don't mess up that subshell

<lilyp>I recently switched back to bash and setting up environment variables appears to be way more of a pain than it was in zsh

<weary-traveler>lilyp: with guix shell invoking a new "interactive" shell (as opposed to login) i imagine?

<lilyp>yep, so it's really just .${SHELL}rc

<lilyp>but with bash sourcing its rc files weirdly you are tempted to put a lot into bashrc

<weary-traveler>lilyp: i recently made some changes to how i was setting some variables in my ~/.bashrc to make it more ... idempotent. i had to (re)invent a few things along the way. let me know in case something in your bash environment variable is still giving you grief

<lilyp>nah, it's fine, I only got PROMPT_COMMAND, PS1 and SHELLOPTS rn

<graywolf>Would anyone know if guile-git should give me same commit (eq?) when doing (commit-lookup)?

<graywolf>I would swear it did work...

<lilyp>that last one was a pain point tho

<lilyp>graywolf: eq? works for records and it can also be made to work for pointers

<lilyp>oops, equal? that is

<lilyp>maybe you were confusing the two

<weary-traveler>my PS1 was a mess. as were my path variables. creating functions (with error checking) that set those helped

<weary-traveler>graywolf: should probably be equal?

<weary-traveler>i don't believe strings are interned

<graywolf>Same result with equal?... hmm

<graywolf>Awesome... (equal? (commit-lookup %repo oid1) (commit-lookup %repo oid1)) returns #t for some hashes and #f for others

<graywolf>That is... unexpected.

<antipode>eq? works on anything (even on integers, but with serious caveats); the question is whether it works like you want it to work.

<antipode>graywolf: Are these hashes returned as strings or as some kind of record?

<graywolf>(define oid1 (string->oid "sha1 hash of the commit"))

<antipode>If the latter, guile-git probably has an oid=? procedure or the like?

<antipode>Don't know what name the procedure has, though.

<graywolf>The git-commit is some record, probably wrapped around the pointer or something, not sure.

<graywolf>I don't even mind it does not work, what is mindboggling is that is works just for *some* hashes

<lilyp>c a c h i n g

<antipode>graywolf: maybe if the hashes come from the same source they then come from the same pointer, but for other hashes things are different because the objects were made independently?

<antipode>+ what lilyp said

<graywolf>This is all in one repl though... done in the same way. Could you please expand on the caching?

<antipode>It's caching, not interning.

<antipode>There is no guarantee that equal objects are identical -- caching is an optimisation, not a guarantee.

<antipode>(That's assuming that the cause is caching, which AFAIK hasn't been confirmed.)

<graywolf> https://paste.vpsfree.cz/UaFuLKDU/+inline I mean this is just confusing. And when I restart repl, and swap last two lines, the results are the same. (oid2 #t, oid1 #f)

<graywolf>Very bizzare

<antipode>If you want to figure out the cause, I recommend actually opening the guile-git source code. If you want to ‘fix’ it, then I recommend modifying guile to make equal? extensible in the same sense of set-record-type-printer!. If you just want to compare things, I recommend looking at the documentation of guile-git for how to do that.

<antipode>(assuming it has documentation)

<antipode>Probably something like oid=? exists, I recommend using it instead of staring at a REPL.

<jaeme>avalenn: Ive spent a little over a week and ongoing on a single rust program

<weary-traveler>guile doesn't have docstrings, right? what's the recommended way to look up documentation? info pages?

<jaeme>Which has over 100 crates worth of dependencies after unbundling

<antipode>Guile does have docstrings.

<weary-traveler>oh.

<antipode>It has plenty of docstrings.

<antipode>You can read them with (procedure-documentation the-procedure), IIRC.

<antipode>I don't think think it works on procedures defined in C, though.

<PotentialUser-23>just nuked my system by disabling the login service and configuring agreety-greetd wrong B)

<jaeme>weary-traveler: you can also read them in the repl with ,d

<antipode>For those defined-in-C procedures (and also defined-in-SCheme procedures), you can look at the info manual.

<jaeme>The dependency for rust-mint-0.4 is rust-mint-0.5.

<jaeme>crates dot io is an amazing place

<weary-traveler>oh i see. it's similar to elisp in terms of placement.

<weary-traveler>thanks jaeme and antipode!

<weary-traveler>but now i'm wondering if i've been using the wrong reference to learn guile. i don't see a mentions of docstrings in https://www.gnu.org/software/guile/manual/html_node/Lambda.html

<dthompson>weary-traveler: it's the 'define' form that allows for specifying procedure docstrings.

<dthompson>(define (foo x) "Do something with X." ...)

<weary-traveler>yep, that's what i used to test. but i don't see a mention of docstrings in the lambda alternatives section either (which covers define)

<weary-traveler> https://www.gnu.org/software/guile/manual/html_node/Lambda-Alternatives.html

<weary-traveler>dthompson: actually, docstrings seem native to lambda syntax. the following works '(procedure-documentation (lambda (x) "hello world" (+ x 1)))'

<weary-traveler>and unless i'm doing something wrong, it doesn't look like guile supports docstrings on variables. though maybe there's another form that supports it?

<weary-traveler>what do i need to do s.t. procedure-source leads me to the source for guile procedures? i presently have guile installed via "guix install guile" i.e., in my default profile

<antipode>I don't think procedure-source actually works.

<antipode>weary-traveler: There is no such thing as 'variable docstrings' in Guile -- in Guile, it's the procedure that has the docstring, not the variable containing the procedure.

<antipode>weary-traveler: That is the right reference. However, docstrings are apparently undocumented.

<weary-traveler>antipode: thanks for confirming my beliefs

<weary-traveler>and that's unfortunate, regd procedure-source

<antipode>Well there's documentation in (guile)Function Snarfing, but that's for C stuff, and if you search for "docstring" you'll find a few hits, but nothing explicit on the Scheme level.

<weary-traveler>okay i see the mention in function snarfing; thanks

<weary-traveler>for a given package installed in a profile in guix, how do i locate its source?

<jaeme>weary-traveler: use guix edit <pkg>

<jaeme>It will open the scheme file the package is located in with $EDITOR I believe

<antipode>Caveat: you can't use "guix edit" for editing, only for reading.

<antipode>(Unless it's pre-inst-env stuff)

<weary-traveler>lol

<jaeme>If you just want the summary of the pkg

<antipode>I think "guix edit" should be reserved for ‘non-installed’ guix, and instead "guix locate" would print the source location or someething like that. (Well not "guix locate", because that name is already used for something else ...)

<weary-traveler>no, the source. and guix edit puts me in the right vicinity. i at least know now where it's located

<antipode>weary-traveler: "EDITOR=echo guix edit hello"

<antipode>(without the ")

<weary-traveler>yep

<antipode>Not a true editor but probably closer to what you actually need.

<weary-traveler>indeed

<jaeme>Highly recommend just cloning the guix git repo

<weary-traveler>jaeme: i probably will. but getting this to work without requiring that has other utility

<antipode>Well you still need to figure out _where_ it is located in the Guix repo.

<antipode>(Though perhaps you are using emacsserver + emacs + ./pre-inst-env guix edit?)

<antipode>(emacsserver to not open multiple Emacs instances when editing multiple files)

<jaeme>antipode: sounds like some high octane (rip)grepping

<weary-traveler>this is the way.

<weary-traveler>okay need to prep for $work-call. this will have to go on hold for a bit

<ulfvonbelow>my static networking seems to be not working

<ulfvonbelow>adding a network-address like: (network-address (device "br0") (value (string-append internal-ipv6-address "/128")) (ipv6? #t)) causes guile-netlink to yield a netlink error with value 17 (which appears to be EEXIST)

<ulfvonbelow>oh, never mind, apparently ifconfig just doesn't show ipv6 addresses and I have to use ip addr now

<ulfvonbelow>anyway, when I try restarting networking, I get: In procedure string->number: Wrong type argument in position 1 (expecting string): #f

<somenickname>nckx: Hey. Did you find out why "Error in service module" happens with my system config?

<sneek>somenickname, you have 1 message!

<sneek>somenickname, nckx says: Not much, but enough to learn that it's very likely a race condition in configuring PAM (so naught to do with Shepherd services or Guile modules) that can be worked around with (login-pause? #t) for now.

<somenickname>nckx: Thanks. Is there some ticket or ML thread I can follow to know when I can remove the work around?

<nckx>I haven't written anything but the above sneek message.

<sneek>nckx, you have 1 message!

<sneek>nckx, lechner says: / thanks for your help yesterday! I think I got a little bit ahead of myself

<nckx>sneek: botsnack, busy girl.

<sneek>:)

<nckx>somenickname: You can report a bug yourself…?

<somenickname>nckx: Sure, wasn't sure if you created one already. Will create one (though I am still working on my mail server so it will take some time)

<weary-traveler>i see that conda is available on guix. interesting. anyone using conda from guix? is that a drop-in replacement for doing a miniconda bootstrap to get conda, or are there other consequences?

<lilyp>assuming it works – haven't checked, it's the same disclaimer as always: don't write to /usr ;)

<sevan>to survive 'guix pull' on a memory constrained pinebook with 2B RAM and still remain in gnome, I found restricting the CPU usage to 2 core with '-c 2', it's still going so there's a possibility it'll fail on building guix-packages-base but it would have failed at least once if I didn't restrict things

<sevan>I'd previously shutdown wayland and dropped to a console to attempt the guix pull which it would thrash as it struggled though

<sevan>drop_caches, drop_caches often during the process

<sevan>sync; echo 3 > /proc/sys/vm/drop_caches

<weary-traveler>hm emacs-guix is all sorts of broken. had to (unintern 'pcomplete/guix nil) to disable the completion mechanism from raising exceptions.

<mekeor>weary-traveler: yes, it's flawed. personally, i only (require 'guix-devel)

<weary-traveler>mekeor: it has a nice ui for inspecting profiles that seems to work and is better than CLI

<weary-traveler>i wonder if simply tweaking the GUILE_LOAD_PATH would fix the issues i'm seeing with things like pcomplete/guix and guix-command

<ieure>I added a channel to /etc/guix/channels.scm and ran `guix pull`. There should be a clone of that repo on disk somewhere after that, yeah? Where would I find that?

<graywolf>~/.cache/guix/checkouts

<graywolf>ieure: ^

<ieure>That has guix, but not my other channel.

<ieure>Oh, huh, because... it doesn't believe in that other channel for some reason, it's not in `guix system describe`. Hm.

<graywolf>Does it show the channel during guix pull?

<graywolf>If not, you can try guix pull -C /etc/guix/channels.scm to make sure it uses that file.

<ieure>Looks like no, I think I got confused about my VM state.

<ieure>Thank you for the answer, though, I'm glad to know the location either way.

<graywolf>guix system describe will show it only after reconfigure I think? guix describe might be the one you want.

<ieure>Is there any difference between `guix pull` as a user vs. as root?

<graywolf>One will end up in /home/U

<graywolf>/home/USER/.cache/...

<graywolf>the other one in /root/.cache/...

<graywolf>Every user has their own guix

<ieure>Yes, I get that, what I'm still fuzzy on is the boundaries between the user-specific guixes and the Guix System OS.

<ieure>Only root can `guix system reconfigure`, I guess that means root needs to pull then reconfigure in order to update all the OS-level stuff?

<nckx>The difference between ‘guix pull’ as user vs. root is the difference between ‘guix pull’ as bob vs. alice. root isn't ‘system’.

<nckx>No.

<nckx>You generally (and I recommend) reconfiguring with sudo.

<nckx>And pulling as you.

<graywolf>You can do `sudo guix ...'. Notice there are no flags for the sudo, therefore environment is preserved and it runs yours (users) guix version under the root uid.

<nckx>Otherwise, you have two guixen to keep updated for no good reason.

<nckx>(No flags == preserve_env is not universal across distroes, but deliberate on Guix System.)

<graywolf>ACTION did not know that, was using doas for too long it seems...

<graywolf>Some people do guix deploy to localhost instead of the sudo, just fyi.

<ieure>Okay, I think that makes sense. But, say I'm on commit A of the guix channel, and there's an update to shepherd in commit F. So I pull as my user, then `sudo guix system reconfigure`, which preserves the environment, and users my user's guix state to make system-level changes like upgrading shepherd?

<nckx>graywolf: Does ‘doas guix system reconfigure’ work the same way?

<graywolf>I was using alpine as a main system for many years, did not try doas on guix :)

<nckx>ieure: Yes, IIUUC.

<ieure>Picking shepherd because that's a thing that doesn't run as my user -- but the same question could apply to the linux kernel, initrd, the guix daemon itself, etc. System-level stuff.

<nckx>I'm not sure where else they'd come from in this example.

<nckx>You update your guix, then upgrade the system with that guix, hence the system will match your guix.

<ieure>Okay. It just *feels* weird to have system-level concerns originate from a non-root user, you know?

<nckx>Can't say I do.

<ieure>Okay, well, it does.

<nckx>If you're against sudo/doas/…, you can keep a separate root guix around and su - root. It's just more work.

<ieure>I'm not against anything. Just trying to figure out how this thing is supposed to work, after running traditional Linuxen since the mid-1990s. It's way different and not well documented.

<nckx>I just mean that sudo/doas/… are the definition of ‘system-level concerns originate from a non-root user’.

<ieure>What I mean is: on Debian, `apt update` refreshes the cache of available packages. There's only one, and it's only writable by root; as a user, you can't control it at all. `apt upgrade` uses that cache to install or upgrade packages. But in Guix, the *source* of that stuff is some stuff sitting around a random user's $HOME, but you're taking that and changing the whole system.

<ieure>That is why it feels weird to me.

<ieure>Note that this isn't a value judgement, I'm not saying either is right/wrong/better/worse. But it is very different to what I've been used to for ~30 years, so it feels weird.

<ieure>That two different users could run `sudo guix system reconfigure /etc/config.scm` and get a different system in response to that feels weird.

<nckx>Sure, but it's a framing (‘random user’ — with sudo access

<nckx>* ?) that implies some value judgment 😉

<nckx>On a shared system, you *could* agree for everyone to use root's guix, just like you'd agree (by distro convention) that everyone use /usr/bin/apt.

IRC channel logs

2023-09-28.log