IRC channel logs
2023-02-15.log
back to list of logs
<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 <surpador>attila_lendvai: looks like jlicht's solution works well! <jlicht>surpador: you're welcome. There are some conversations w.r.t. this piece of arcane knowledge being not entirely (or at all) obvious XD <surpador>Yeah seems like it might be worth a mention in the manual channels section <thanos_apollo> /msg NickServ VERIFY REGISTER thanos_apollo VfHoOCsw4CHHSIOD <vagrantc>thanos_apollo: might want to change your passphrase :) <thanos_apollo>vagrantc: a strong and complicated passphrase has been granted :) <lispmacs[work]>hi, I just noticed we have some packages for astrophotography image processing, and I was wondering if there were any Guix users who were into astrophotography <thanos_apollo>lispmacs[work]: is there any human that's not into astrophotography? Planetary astrophography is just amazing, I'm jealous of people that get to do that! <lispmacs[work]>well, what I was driving at was more to find out if there are people trying to do astrophotography with free software. <lispmacs[work]>like, capturing the exposures and doing the stack processing. I've never seen anybody using free software in any videos I've seen of it, but I haven't exactly scoured the Internet <lispmacs[work]>you can easily find proprietary apps to come with your expensive telescope purchase <thanos_apollo>lispmacs[work]: I haven't seen much free software in photography in general, but I don't know much, hopefully someone can help you here or on the fsf forum <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 <GNUtoo>Some people probably work with Guix and and astronomy somehow as there was a visit of a place related to astronomy during the guix 10 years birthday <lispmacs[work]>it sounds like guix has the software to do all the processing once you have the exposures, like SIRIL <lispmacs[work]>but I don't know about interfacing with an astronomy camera or getting the exposures pulled from it <GNUtoo>ACTION never did any astronomy though so I'm not the right person for that <GNUtoo>I guess formats like dcraw have metadata in them <GNUtoo>but beside that I've no idea how to process the files for astronomy <GNUtoo>and even what kind of data people are interested in <GNUtoo>like I guess that you could also somehow remove the IR filter of the camera for instance <GNUtoo>So maybe there are ways to get other spectrum than the visible <Apo11o[m]>How can we use doas in guix? It produces error ‘not installed setuid’ <bjc> (setuid-programs (cons* (setuid-program (program (file-append opendoas "/bin/doas"))) %setuid-programs)) <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 <acrow>configs? or is there another way? <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? <jpoiret>that's how I added the org-protocol thing to firefox <nckx>acrow: More info please :) What error message do you get when selecting something under ~/.guix-profile/bin? <PotentialUser-74>Hi everyone, I'm trying to install docker but it's failing. The system tells me that the dependency mismatch the hash. <PotentialUser-74>I just started using guix so I'm not sure if I'm doing something wrong or if upstream is corrupted. <nckx>acrow: I can choose whatever I want, AFAICT. However, this is Firefox (109), not IceCat. I'd be very surprised if that made any difference though. <nckx>PotentialUser-74: Could you share the error message on paste.debian.net? <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>Damn. Does ‘guix install docker’, or whatever you ran previously, consistently return the hash error? <nckx>PotentialUser-74: Does the sha1sum of said binary match mine above? (It should be an lzip stream.) <nckx>Oh, that message didn't make it through. <nckx>cb7cf85d761c1f9e0b5f60d3b97791fcc5eba78e <nckx>ACTION looks at the paste. <nckx>ACTION looks at your hash. <nckx>So your Guix is just out of date. <nckx>Have you run ‘guix pull’ recently? <nckx>Before you do [again], does ‘type guix’ refer to your ~/.config/guix/current/bin/guix? <nckx>And is your ‘guix describe’ date recent? <nckx>I want to make sure you're running the right Guix before you pull [again]. <nckx>Then: how are you ‘installing docker’, above? <nckx>(Aside: being logged in as root is not common, but should still work.) <nckx>(It's not generally smiled upon though, and is it really what you want?) <nckx>If guix is /root/.config/guix/current/bin/guix, and is up to date, ‘guix install docker’ should not fail in this way. <nckx>What's the ‘guix’ commit in ‘guix describe’? <nckx>Thanks, that did it. I see what I missed. I have that patch applied but it's not upstream. I'll test it properly and push it. <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. <apteryx>do others reproduce #59368? On Guix System or a foreign distribution? Do you have TZ set? <jonsger>apteryx: I don't have TZ set, but it works for me in icedove. Times are displayed in CEST. I don't use Icecat but firefox-esr, also no issues. I'm on Guix System... <zimoun>is the update of Mes by 89a8d213292ab99a4af67d9767743f47d6a1dc3f not a world rebuild because of ’(inherit mes)’ in (define-public %mes-minimal? <janneke>zimoun: no, the bootstrap binaries are not part of the dependency tree <janneke>try: ./pre-inst-env guix build hello <janneke>zimoun: i triggered a world rebuild on core-updates, though <abrenon>what X11 driver does guix use for touchpads ? <cbaines>I did spot a problem with /gnu/store/0rjjrv9gd8c7sqwd1z7rgh63scjg5i6y-gcc-core-mesboot0-2.95.3.drv <zimoun>efraim: is the update of rust-structopt-0.3 which triggers many rebuilds? Because “guix refresh -l” says few but it appears in many #:cargo-development-inputs, I guess. <efraim>zimoun: it could be. I checked librsvg so I figured it was safe <zimoun>for instance, the rebuild of ungoogled-chromium is scheduled among other intensive packages as python-scipy. <zimoun>yeah, and 520 still scheduled. :-) <janneke>cbaines: i guess we have to revert the mes-boot 0.24.2 update :-( <cbaines>ok, do you know where the issue is? Nothing is jumping out to me in the gcc-core-mesboot0-2.95.3 log <lechner>in a down moment, thank you all for working so hard on this <janneke>yeah, i wondered about that too. it's the last `ar' command <janneke>so, binutils `ar' not handling the new stat64 call correctly, or there's a problem with the new stat64 in the mes c library <janneke>strange all, because stat is being used to build already two versions of tcc and binutils <janneke>ACTION adds the paste to the revert commit message <apteryx>jonsger: thanks! would you mind trying in a 'guix shell icecat', after disabling the resistFingerprinting option? <cbaines>janneke, have you tried reproducing it on a btrfs filesystem? I think that's where it shows up for me <janneke>cbaines: no, i don't have any machines that use btrfs -- that code scares the hell out of me ;-) <janneke>it seems the bug only shows up at a "random" place, building bash-mesboot0 (that we don't have anymore) or glibc-2.2.5 <cbaines>janneke, OK, maybe once milano-guix-1 is back online, you could have the option of ssh'ing in to there (if that would help) <cbaines>unfortunately it's offline at the moment <janneke>unfortunately i don't have any time to look at this the coming week <cbaines>janneke, cool, I'll let you know once the machine is back online <janneke>ACTION would also really like to find this binutils-mesboot0-2.20.1a `ar' problem <janneke>ACTION probably needs an account there? <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. <dlowe>does anyone have experience with this? <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! <old>I want to be able to use guix-home packages from an ssh session. For example, ssh host pass show somepassword <mrvdb>How far off is 'guix system' to be available for powerpc64le? I'm running guix on top of an archpower kernel now and the mixed system is getting a bit hard to manage. <old>How can I configure my home configuration so that my ssh has PATH set to guix-home binaries? <andreas-e>janneke: I get the same failure on my laptop as observed by cbaines. So it is not related to btrfs. <janneke>it reproduces for me too, so i've reverted the patch <janneke>andreas-e: i believe the btrfs bug is related to stat64 missing and should surface with mes < 0.24.2 <dlowe>old: you install guix on the remote system and then set PATH on the remote shell? <old>guix are on both sides here. However, ssh does not read .profile where basically the home environment is sourced <dlowe>old: ah, so you're executing an command via the ssh command line <old>and I want to execute a command that is in my home profile <dlowe>old: right. The easy and secure thing is to use an absolute path. <old>ssh host /home/old/.guix-home/profile/bin/pass seems to work <janneke>andreas-e: yeah, i hoped to get the bootstrap in core-updates into a bug-free state before it gets merged <dlowe>old: the other way (which I just looked up) is that your ssh server needs AllowUserEnvironment, and then you can set PATH in a ~/.ssh/environment file <janneke>ACTION is bisecting and trying some things <dlowe>Sorry, PermitUserEnvironment <janneke>andreas-e: yeah, but /me has holidays coming up too ;) <efraim>You. Could add something to ~/.ssh/rc to source . profile <old>dlowe: Hmm I see. But I like your approach more <old>I only want to copy password locate at home so really a single path has to be set somewhere <dlowe>There's a lot less chance for things to go wrong <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. <Guest63>Do you have recommendations for SSDs? <jackhill>what's the status of the antioxident build system? <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. <lfam>We'll use the QA server to see what breaks <nckx>apteryx: But if you then set it to false in about:config, it works again, right? If so it sounds unrelated. <apteryx>nckx: nope, it doesn't work because the browser default value is used and UTC gets set anyway <lfam>Time is Hard Problem but telling applications what time zone you want them to use shouldn't be. Thanks y'all for digging through it <apteryx>it seems a race perhaps, it used to work; the user settings need to be loaded earlier for the code to do the right thing <apteryx>and that particular code hasn't change since 2017 <apteryx>I'll suggest we temporarily disable privacy.resistFingerprinting in our IceCat build until this gets fixed, as it means every IceCat user is stuck with UTC dates in their pages until then. <vagrantc>ACTION would prefer UTC over being fingerprinted <jonsger>apteryx: for me its still UTC in `guix shell icecat` even when disabling privacy.resistFingerprinting <jpoiret>mvnx: yes, it's all the transitive deps being added there <Galladite>Hi, I'm new to guix and I just have a couple of questions; should I edit config files in ~/.config directly, and is there any versioning involved in this? <unmatched-paren>Galladite: unless you're using Guix Home to manage them, you do have to edit them manually <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 <rekado>aren’t they using “top git” (?) for that? <janneke>youpi says topgit didn't work for them <janneke>ACTION is confused about all that, though <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 <nckx>apteryx: OIC! So this is more interesting than I thought :-) <nckx>Guest3: People have made 'awesome lists' (which is some cultural thing, don't ask me more) about Guix but I'm not aware of anything more specific. <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. <graywolf>nckx: Is there expected timeframe for that? The C.utf8 is somewhat important to me, so I'm curious how long will I have to live with en_US. No pressure, just asking. <nckx>(glibc 2.33 is from Feb. 2021; C.utf8 was added in Feb. 2022…) <graywolf>The en_US sorting rules are... creative, let's say. At least in my opinion. <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>Oh good, I felt bad suggesting all that crazy stuff. Yeah, just wait. <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. <rekado>which “guix” is effectively used depends on what the shell knows <rekado>when ~/.config/guix/current/bin is first then the user’s “current” guix (= the result of “guix pull”) is used <rekado>otherwise the global Guix at /run/current-system/profile/bin/guix would be used <rekado>the “guix” executable is self-contained — it comes with all modules that contain package definitions <rekado>so using a different “guix” executable will result in different package definitions to be used, so the resulting system (with “guix system build config.scm” or “… reconfigure …”) would differ <rekado>Guix records the channels used to build a system <graywolf>I see, I think I understand. So guix system describe -f channels would be necessary in addition to the config.scm to get actually reproducible system.