<surpador>If I've added a third-party channel in my ~/.config/guix/channels.scm, is there an easy way to get a repl where the modules that channel exports are available? Or do I have to clone the channel repo and set search paths manually to point to the checkout?
<jlicht>surpador: assuming you've run `guix pull', try running `guix repl', and starting out with a ",use (gnu packages)". After that, things should be loadable, afaics
<GNUtoo>for free software photography there are things like magic lantern for expensive cameras and CHDK for more affordable ones, these are applications on top of a nonfree (camera) OS though
<GNUtoo>Apart from that there were also Android cameras but I don't know much about them
<lispmacs[work]>I wouldn't really mind using an astrophotography camera with a nonfree-os, but was wondering about the bigger picture (pun not intended) as far as triggering and pulling all the exposures, then processing the image stack with free software
<lispmacs[work]>in astrophotography you need to take a ton of exposures and then process them all to come out with a final image, or so I understand
<GNUtoo>ah yes, there is software for that but I've on idea if it works for astronomy
<GNUtoo>darktable, gimp, krita, etc can post process pictures
<lispmacs[work]>so, just wondering if there were any free software fans into astrophotography and what kind of setup they had
<apteryx>I think the problem with timezone and icecat is that setting resistfingerprinting to false somehow stopped working
<acrow>icecat causes questions regarding the guix 'way'.
<acrow>My example is using the icecat gui to set the applications for particular file types, eg.. .mkv files.
<acrow>It may be my fault that icecat sent those to vlc but vlc fails; so, we want to change it.
<acrow>However, when we use the application chooser gui, we discover that hidden directories like $HOME/.guix-profile are disallowed; so we cannot choose it without making a link to a non-hidden location. I simply did ln -s <.guix-profile/bin/mpv> <$home/bin/mpv>. My question is, shouldn't we package all such applications to provide link in $HOME/bin/? or is this something that we expect users to put into their .bash-profile or .guix-home
<efraim>does anyone know offhand the bug number for the '24 cores is too much' bug?
<mfg[m]>acrow: depending on what the reason for disallowing hidden files is, the solution might just be to patch the offending program to allow them
<mfg[m]>Which application chooser gui do you mean btw?
<acrow>mfg: Yes, this is driven by the limitations of the icecat gui and fixing that would address my tiny observation. In icecat, see about:preferences#general and then Find 'applications' and try to assign any guix application to any type of file. If it isn't the default -- I think you are stuck. Or you have to find an underlying configuration file to change. It's just awkward.
<acrow>Maybe the answer is to couple icecat with it's supporting packages together in a container using --emulate-fhs. Hmmm...
<mfg[m]>acrow: that might work, but you are right; this should work oob
<jpoiret>acrow: wouldn't you need to fiddle with the default apps for mime types that xdg-open also uses?
<nckx>acrow: I installed the latest Guix IceCat package, but browsing or selecting ~/.guix-profile/bin isn't disallowed/broken at all (mailto: links now open in Xonotic, which I think is an improvement). This is an issue with your system, somehow, can't say more without details.
<nckx>PotentialUser-74: Should be fixed now, sorry for the delay.
<nckx>What's weird is that https://issues.guix.gnu.org/59927 never made it to my inbox and hence my ‘patches to push’ queue, although I'd applied the same fix locally. I wonder if it was ever delivered to subscribers at all.
<puddinghead>i've already installed a few programs through guix and i think its going pretty well! only one app has a problem, but i think that might be a dependency issue given that i managed to fix a bug within another literally just through installing another package
<puddinghead>i would like to actually learn guile/scheme soon so i could contribute to guix with packages as well!
<apteryx>nckx: I can reproduce with vanilla Firefox by adding 'pref("privacy.resistFingerprinting", true);' in browser/app/profile/firefox.js and building with that
<mvnx>Anyone know why most but not all of the rust crates use `#:skip-build? #t`? I'm new here and just trying to package some crates that are dependencies of apps I'm trying to eventually package.
<efraim>mvnx: there's a disagreement about packaging them. Building the crates and running the tests is a waste of compute power since we only care about the sources, but building them and running the tests ensures we have the inputs correct.
<mvnx>As I'm packaging these rust dependencies, I'm testing locally using `guix build -L ~/pkg rust-cratename`but `patch-cargo-checksums` runs through all of the crates including those not listed as dependencies for these crates. For example a crate may only have 3 other crate dependencies as inputs, but literally every crate is being output in this
<mvnx>step. Any way to speed up the iteration cycle here?
<dlowe>I'm modifying the tcl package to have a sensible search-path, but I can't figure out how to test this in isolation. Does anyone here have experience with this?
<mvnx>RE: myself - Maybe it's not all, maybe it's just dependencies of dependencies adding up and so the answer would be no. Hard to tell.
<rekado>I can’t easily use “guix copy” because guile-ssh doesn’t support the “IdentityAgent none” option
<rekado>I have many different ssh keys and for some reason ssh will try all sorts of keys that the identity agent knows about, leading the remote to cancel the connection due to too many failed authentication attempts.
<rekado>how do others with many ssh keys avoid this problem?
<mvnx>jpoiret: Thanks yeah I started to notice just the scope of this package I'm trying to build :)
<janneke>cbaines: heads-up, i'm re-pushing mes-boot 0.24.2 to core-updates, gcc-core-mesboot0 builds for me using a fix in tcc-boot
<janneke>hey rekado, it's been a while that you asked bug-hurd about aa recipe to update the hurd in guix and got a kind-of complicated answer along the lines of "we're in flux, no can do"
<janneke>while i'm happy to see still much going on on the bug-hurd list, maybe it's time to ping them again, wdyt?
<janneke>efraim: core-updates uses mes-0.24.2 right now, and gcc-core-mesboot0 builds for me
<janneke>it would be great if it built for you, using tmpfs
<rekado>janneke: I’d like to see the Hurd updated in Guix, but I got a little too used to feeling stupid and annoying when asking for help on bug-hurd.
<janneke>rekado: yeah, i really didn't like how you were treated...
<janneke>it seems lots is going on wrt device drivers/rump kernel, x86_64 and smp...
<janneke>i believe someone should make a git archive using the debian patch thingies they are using
<Guest3>Hi, is there any central place where people publish/share their guix system setup where you can learn and adapt from? I want to have an extremely simple, terminal-based setup (dwl, z.sh, ytfzf, vim-bindings everywhere etc.) and I'm sure someone has already created that
<rekado>mekeor[m]: I have IdentityFile set in every Host block. (I wonder now if order matters.)
<mekeor[m]>rekado: maybe also consider IdentitiesOnly, as described in 'man ssh_config'
<Guest3>nckx, mekeor[m]: okay, thanks for the hints. it would be cool if there was some website or repository where communities try to create the best-possible distributions for a given theme. one theme could focus on terminal-software, another on emacs-purism and so on. i don't have enough guix-knowledge to start something like this, but maybe i will try
<mekeor[m]>Guest3: btw, for channels, there is this search engine from the non-official guix community: https://toys.whereis.xn--q9jyb4c -- but it does not offer to search operating system declaration source codes of people. only channels, including their packages and other scheme variables.
<rekado>mekeor[m]: I do use IdentitiesOnly, but guile-ssh doesn’t seem to like it: ;;; [2023/02/15 21:24:09.936424, 1] ssh_config_parse_line: Unsupported option: IdentitiesOnly, line: 124
<graywolf>Hi, is it possible to use C.UTF-8 locale under guix? Naive approach of (locale "C.UTF-8") led to failed derivation build. Is it possible to somehow get it to work?
<nckx>graywolf: C.utf8 is a glibc 2.35 feature. Guix is still on glibc 2.33, but the next core-updates merge will pull in 2.35.
<nckx>I don't know if it's possible to build your own C.utf8-locale-definition-but-for glibc 2.33 by hand. Probably. Probably not worth it IMO.
<graywolf>I'm pretty sure I do not want to go that way :) I can definitelly wait few weeks or something. I'm still in a process of figuring out what will my guix setup look like, so there is no real rush to migrate from my side.
<nckx>Guest3: I wouldn't have the time to maintain it either, but I agree it would be nice :)
<graywolf>I am little confused about relation between the "system"-packages and "user"-packages under guix. I've (finally!) managed to install a bare-bone guix into a qemu. After restart (from the install disk), I've logged in as root and tried guix system reconfigure (to make sure nothing changes; I got ssl certificate error). However guix pull did work. After I tried guix pull and hash -r, the guix system
<graywolf>reconfigure works as well. So, my understanding is thas: 1. guix system reconfigure used a system guix and failed for some reason 2. guix pull used (again system guix binary) and worked for some reason 3. hash -r switched to newly install guix, but that was installed into *user* (root) profile 4. guix system reconfigure now used the user's guix and update the system (which included the system guix)
<graywolf>First, is that roughly correct grasp of situation? Second, sorry for wall of text.
<rekado>“guix pull” uses its own profile: ~/.config/guix/current
<rekado>(just to be make that you haven’t done “guix install guix”)
<rekado>before “guix pull” you likely only have /run/current-system/profile/bin/guix
<rekado>if at any point you are confused about what Guix you’re using, try “guix describe”
<rekado>every user account (including “root”) can have their own independent Guix, or fall back to a system-wide “guix” executable
<graywolf>rekado: right, so regular `guix pull' and `guix install xx' (or what is it) installs to the (current) user profile, but `guix system reconfigure' uses guix version from *current* profile, but modifies the *system*? So if two users (root, foobar) both run `guix system reconfigure' with same manifest, the resulting system will (might) be different based on whether they guix-pulled to the same commit.