<lispmacs[work]>is gnome-maps working fine for everybody else? I'm getting an Internet connection error that prevents it from displaying any maps, even though my internet connection is working fine in other applications
<lfam>lispmacs[work]: It's probably not just you. I've always had trouble of some sort with it
<bdju>is doing a guix pull the only way to get up-to-date results from `guix search`?
<roptat>technically, you could use the time-machine
<vagrantc>which is sort of a wrapper around guix pull :)
<sneek>vagrantc, hurricos says: Hi there, you talked about linux-libre on your Asus C201 / veyron around September last year, did you replace u-boot on flash to attempt to boot it, and did it ever boot?
<vagrantc>hurricos: i never got a working u-boot on it, have only used coreboot/libreboot successfull
<bdju>I guess I'm fine sticking with guix pull, I just wonder if there's a faster way to find out if a package has been updated or not
<bdju>like if I basically just wanna see if the version number changed
<leoprikler>lispmacs[work]: the only problem I have with gnome maps is that I have to launch it from the command line like a caveperson when dinosaurs still existed when I already sent a patch fixing that bug ages ago
<bdju>I did find out that I had to update the mpv-gallery-view script I was using. there was a commit where they moved gallery.lua from lib to lib.disable so it doesn't try to get loaded by mpv as a lib
<kozo[m]>Hey all, what changed with guix environment? What do I have to add to my config.scm to fix this?
<kozo[m]>guix environment: error: cannot create container: unprivileged user cannot create user namespaces
<kozo[m]>guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1"
<guix-vits>aside. i'd just a wifi error, and guix environment (older commit) get "no route to host". so this laptop decided to build python :) i wish there was some guard against such minor inconveniences. like --network-try-twice[=y]
<rekado_>the problem with 22952 appearing as “open” is that it’s not entirely clear from the Debbugs data whether the issue is archived or not.
<rekado_>Debbugs has two file trees: for archived issues and for active issues.
<rekado_>in this case only the archived file contains the information that the issue has been closed, but there is *also* a newer file indicating that it is an active issue — and that file does *not* mention that the issue was closed
<rekado_>so I guess mumi needs to gain even more heuristics and look at both files…
<rekado_>archiving issues has to be one of the more annoying features of Debbugs.
<rekado_>it also prevents emails from being processed unless the first email it receives is an unarchive command
<rekado_>oh, looks like this issue *actually* has been reopened, so the only problem here is that mumi sees the archive and displays those message instead of the new messages that have been received since unarchiving.
<olivuser>hello guix. I'm on a mostly freshly installed machine. When I try to launch programs (like geiser in emacs), I am prompted with the error message "could not find guile" even though I have installed it. I have already added $HOME/.guix-profile/bin to my $PATH
<olivuser>I'm on a mostly freshly installed machine. When I try to launch programs (like geiser in emacs), I am prompted with the error message "could not find guile" even though I have installed it. I have already added $HOME/.guix-profile/bin to my $PATH
<olivuser>to be a bit more precise: I have said packages installed. Also, my problem is not only related to geiser, but also to git. Whenever I try to open a file, I get prompted with the error message that git was not found (the file is opened regardless).
<olivuser>also, dmenu does not find any program inside emacs, even though SUPER-& finds them
<emys>so th problem was that I got GUIX_PROFILE wrong, which meant the wrong profil was sourced
***apteryx is now known as Guest25677
***apteryx_ is now known as apteryx
<olivuser>will come back to that later, thanks so far :)
<elais>Is there any downside to using a simple etc-service-type to store a channel as part of the os config?
<elais>Just realized I could use a scheme file gexp to do this inline with the config and it saves me some manual steps
<civodul>elais: that's a good idea, but there might be complications because you have to create the /etc/guix sub-directory
<elais>I haven't thrown it on a system but using the `file-union` procedure allows me to collect files into a directory, then I feed that gexp to the service and it looks like it does what I want when checking three system build output
<emys>civodul, It seems that now I got two places where excutables are stored /home/holger/.config/guix/current/bin/ (e.g. guix) and /home/holger/.guix-profile/bin (e.g. tig/emacs other installed packages)
<elais><leoprikler "it creates a directory, but the "> Modify guix-service-type instead of using `simple-service 'blah etc-service-type`?
<emys>let me rebuild the alpha build with tests enabled again, just to make sure I didn't mess this up
<emys>another option I guess would be to not bundle smalltalk release and alpha and just provide the smalltalk-next from git as a functional package (until someone feels compelled to engage in software archeology for Gnu Smalltalk).
<emys>for my use cases the VCS version would definitely suffice
<civodul>yes, but Guix is for additional people too ;-)
<emys>civodul, I am sorry I didn't mean it in that way
<zimoun>apteryx: I hit the bug#42371 about «guix build: error: all build users are currently in use;…» using a manifest file with 200+ packages. Well, because of that, massive rebuild from the command line is annoying. Have you investigated more since you have reported it?
<sneek>zimoun, nikita` says: I also do not intend to react to bugtickets that old (see icecat localizations one) because I have no means to reproduce it and don't really have the spoons to deal with more than one project this year
<civodul>it's the interface that i blame, not the underlying tool ("git grep")
<bavier[m]>hi civodul, um, I think it's just a little harder to make .so libraries in scotch :)
<bavier[m]>I was going to upgrade that package soon, so I can take a look.
<zimoun>civodul: guix describe says 17d9a91, then git -C ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/ show 26e92a3025 works, then guix time-machine --commit=26e92a3025 -- help fails.
<dannym>* Stop autoboot (otherwise it fails and eventually falls back to sd card boot because there's still an old guix generation for it (because I used cp -a to get everything from the sd card to the sata drive))
<janneke>in order to get that to work with the mes-tcc bootstrap, i could try simplifying the TCC_ARM_VFP branches...but i'd rather pause here then and finish the bisecting; corner and fix the bug that is avoided by this bisecting and simplification work
<elais>civodul: I did run into trouble doing the etc-service-type but using the `extra-special-file` procedure I was able to place the channel file
<bdju>does anyone here have a pinephone or other device running postmarketOS? I'm trying to get USB Internet working on it, but the instructions only cover other distros, and so far I haven't been able to figure it out.
<bdju>I just need to do this temporarily due to some wifi issues, so nothing needs to be saved to configs really
<bdju>I did the sysctl command, but I haven't got iptables or firewall-cmd. my attempt at the first nmcli command in the RHEL section tells me my interface is invalid even though it's exactly what's listed in both `ip a` and `nmcli` outputs
<elais>civodul: improve on it how so? Maybe adding a operating-system field for declaring system wide channels but I think its handled pretty elegantly by defining a scheme file-like object and symlinking it into place with that extra-special-file procedure. I think this is the ideal use case for that, though it is pretty hidden in the docs.
<civodul>elais: yes you're right; it would just be nicer if we could do that via etc-service-type maybe, dunno
<civodul>bavier[m]: big patch is not great, maybe better wait until they DTRT upstream
<janneke>dannym: okay, and the hope is that using TCC_ARM_VFP will not emit those instructions?