<solene>vats: and if you do scheme, the syntax and libraries may slightly change dependning on the implementation you use, which is tricky... If you use guile it will work for guile but maybe not for other (certainly not)
<vats>Ah. Thank you so much leoprikler. That clarifies a lot.
<raghavgururajan>> vagrantc: the problem with xmpp is that people who are too excited about matrix will balk at it, and the problem with matrix is that the people who are happily using xmpp for ages will balk at it
<mange>solene: Isn't that essentially what Guix does already? It compares the hash of the download against the hash in the package definition, so if you just want to make sure it matches upstream you could use "guix build -S $package" to get the source, then do your own checksum (after it's already in the store).
<solene>mange: if the checksums differs from the package definition, guix will stop and delete the file
<solene>I don't know if -S make a change about this?
<mange>Right, okay. Do you currently have a package that's failing to build because the sources aren't what Guix expects, and you want to download the source yourself and get Guix to use your downloaded sources instead?
<solene>mange: no, it's because I'm updating packages
<yoctocell>Is there a reason for not generating Texinfo docs from the docstring of procedures in all the (guix ...) modules?
<leoprikler>I further assume this is within the context of EXWM?
<yoctocell>civodul: that's a good point, but not metioning them in the manual makes it harder to know that something exists. For example, I only just discovered (guix http-client) because I am writing an importer for CHICKEN eggs and looked at other importers to get an idea of how to start.
<leoprikler>chikamungus: I guess site-start.el runs before your packages are added to load-path, so you'd have to load it once more or otherwise include the blurb that says "here, generate me all autoloads"
<pkill9>i should just learn to write a configure and makefile
<leoprikler>sneek later tell chikamungus: In that case it's likely you have emacs installed system-wide (i.e. /run/current-system/profile if you're running Guix System), so you need to refer to that instead
<leoprikler>projectmoon it does make sense in some case, but the VM obviously can't check for hardware incompatibilities
<leoprikler>I suggest keeping the most minimal config.scm, that you can work with around just in case you have to deal with issues related e.g. to the GPU, that would still allow all else (most importantly file-systems) to function properly
<leoprikler>then you can `guix init minimal.scm`, reboot to Guix on metal, `guix pull`, `sudo guix system reconfigure desired.scm`
<leoprikler>if generation #2 fails to boot afterwards you can go back to #1, make changes to desired.scm until it fits and redo
<leoprikler>trust me, it's a lot less headache than running init over and over :)
<projectmoon>leoprikler: it'll be a librem 14. So it Should Work 🤔
<leoprikler>In that case, you might be on the safe side. Guix folks are at least working on Librem, but I don't know the current status of it.
<projectmoon>Well I assume all the necessary drivers are already present
<abcdw>Few weeks ago geiser started to missbehave. Updated it to latest version. C-c C-k evals buffer correctly, but if I do C-c C-c or similar eval of one or few forms it throws an error. It can be fixed by switching current REPL's module, but it's not convinient, when you work in few different modules at the same time. Am I doing something wrong?
<mjw>nckx_, yeah, it seems the fsf is slightly late here. Having a discussion on freenode while most people have already left...
<abcdw>I could reconfigure too, but guix pull was failing, give me a minute, will send you an error message
<pineapples>Hi! Does anyone know why there's a discrepancy between an amount of free space on a zstd-compressed partition, reported by `df -h' and an amount of space (in GiBs) freed up by `guix gc -F'? In my case, to free up 11GiB of disk space, I had to `guix gc -F 20GiB'
<dstolfa>yeah, FSF is just very slow at these things
<civodul>abcdw: not yet unfortunately! getting closer...
*dstolfa is itching to move to guix but still needs to sort out a few issues before he can
<civodul>abcdw: it can try it as a channel, right?
<nckx_>pineapples: I use lz4 compression on / and noticed the same thing. I can't believe the daemon is compression-aware. I think it's more likely a bug that happens to roughly match up with your compression ratio.
<efraim>pineapples: I found that compression from the guix daemon is about 3-to-1 and compression from zstd is about 2-to-1
<munksgaard>nckx_: I'm not sure. My guess would be no. I've submitted a new bug report with the additional information.
<civodul>abcdw, yoctocell: i got: guix pull: error: could not authenticate commit 416dba8bfc347775bc8e53bfc1c84c364028e76a: key 0158 61E3 2C8A E7E4 84CA 4233 ACF5 0999 A2FB 5C79 is missing; am i missing something?
<efraim>i'll run compsize on my store and post the results
<munksgaard>nckx_: My bugs are not showing up on issues.guix.gnu.org though. Perhaps I just need to wait a bit for some moderation to take place?
<nckx_>E.g., df -h says you have 5G free. You run guix gc -F 20G. Guix looks at df once, then proceeds to delete 15G of uncompressed data. It never checks df again. It exits, claiming to have freed 15G, whilst df reports only 10G free now because those 15G compressed to 33%.
<pineapples>nckx_: Oddly enough, the amount of disk space that guix frees up matches disk usage reported by compsize
<roptat>if it deletes 1GB of files that are also hard linked from somewhere else, df will not report any change
<nckx_>Because when you run guix gc -F 11G with 11G free, it has up-to-date df info and decides to delete nothing? The disparity only accrues during GC.
<civodul>anyone has a cluster-like Guix setup, where clients talk to the daemon with GUIX_DAEMON_SOCKET=guix://somehost?
<civodul>i'm seeing weird perf behavior, but i can't tell where it comes from
<pineapples>roptat: Perhaps, but as the end user I expect that the result of running `guix gc -F 11GiB' is that `df -h' and `btrfs fi usage /' report 11GiB of free disk space
<nckx_>Because Guix subtracts uncompressed $FILE_SIZE from its internal ‘I need to free this much’ counter, without checking *actual* df numbers (which would be lower) after each file. So Guix's idea of how much it's freed diverges more and more from the actual free space when you use compression.
<pineapples>If this is not a bug, perhaps this should be documented?
<nckx_>Only if btrfs fi usage and df report the same number.
<nckx_>SEARCH_V2 was tailor-made for btrfs, I have no idea if it's well designed. I guess we'll see.
<nckx_>OK, so s/tailor-made/straight-out exposes btrfs internals so any file system implementing it will have to share or emulate those/ :-/
<pineapples>nckx_: I see. Either way, I wouldn't be bothered by this discrepancy, if it wasn't for the fact that I intentionally leave a fixed amount of free disk space on my main drive so that the SSD doesn't slow down due to an exhaustion of free space or something (it's said that modern drives do not require this treatment anymore, but I do it anyway)
<nckx_>I'll open a bug when I'm sure my understanding is correct (that ‘guix gc -F N’ is really just a dumb alias for ‘guix gc -C (N - $df)’).
<pineapples>nckx_: Thanks a lot! I lack the grasp of `guix gc' to open one myself; though, I doubt anyone would bite me for simply sharing my expectation from the end-user's POV, rather than also provide technical information on how to solve this
<solene>lfam: I don't understand why you say I should discard the commit. In the gnutls update commit I also removed useless patches, it is done. I have to make a new commit for the graft thing. So, I can add a new commit for the graft + fixing gnu/local.mk in the commit. Or I can drop my existing commit to make a new one including the graft + updating gnutls + not removing patch files
<nckx>Low-budget VPS hosting is the best VPS hosting.
<solene>if the patches files are not required, I don't see why we should not remove them
<nixo>Hi guix! Something strange is going on with julia. I had to re-install guix today (because of a disk failure) and julia won't run, throwing: "ERROR: Your CPU does not support the CX16 instruction, which is required by this version of Julia! This is often due to running inside of a virtualized environment. Please read https://docs.julialang.org/en/v1/devdocs/sysimg/ for more."
<lfam>solene: "Or I can drop my existing commit to make a new one including the graft + updating gnutls + not removing patch files" <-- This is what you should do
<lfam>The patch files are still required by the 'gnutls' variable. They won't be required in the 'gnutls-3.6.16' variable
<nckx>nixo: Which CPU is that? Were you previously successfully using the same version of Julia?
<solene>lfam: ok, I understand now, this make sense to me
<lfam>solene: The reason we use a graft here is to avoid changing the derivation of the 'gnutls' variable
<nixo>nckx: hi, yep it's the same X200 I've been using for the past ~4 years
<nckx>nixo: You could build julia locally, by uninstalling it, running ‘guix package --delete-generations=0s’, and running ‘guix gc /gnu/store/*-julia-*’. If that works, run ‘guix environment julia -- true && guix install julia --no-substitutes’.
<jackhill>speaking of: would anyone like to review https://issues.guix.gnu.org/48573 botan crypto library update? The release notes don't mention security fixes specifically, but it's still probably one of those things that's good to keep up to date. Especially now while it doesn't have too many dependents :)
<projectmoon>and i suppose there's no smart way of getting that file
<nckx>Guix doesn't support running them out of the box, but there are hacks like patchelf that let you change the location of libraries & the linker/loader, or you add (extra-special-file* "/lib/ld-linux-x86-64.so.2" glibc) to your system configuration & mess around with LD_LIBRARY_PATH to point firefox to the other libraries it needs.
<nckx>The extra-special-file is that way but it's only the first step.
<abcdw>roptat: There is a pure evaluation mode in flakes enabled by default, which prevents accessing anything outside of you current flake (git repo) or flakes declared in the inputs of current flake. I had a introductionary stream on this topic: https://youtu.be/98EwejpIJzE
<lfam>roptat: Good choice, but bad for my article, since the similar names will confuse readers
<abcdw>ix: BTW, channels+inferiors seems to cover 90% of what flakes do. The setup process is a little more involved, but still managable, maybe later I'll experiment around with some nicer API + tooling for managing lock files and outputs to get more flake-like experience in Guix.
<ix>abcdw: yeah, you're the third person I've seen say that now :D
<lfam>On second thought I might not participate in the discussion on #fsf freenode. It's already a torrent of bullshit
<ix>drakonis: nixos moving to matrix pisses me off, frustration at nixpkgs, and guix might now actually be big enough that I won't risk losing all my packages. I was already on the verge of switching, guix is nearly unilaterally better, just held back by the whole flakes thing. Flakes are such a tidy and nice experience
<apteryx>civodul: is overdrive1 managed via 'guix deploy' ?
<ix>solene: less anally pure, which in some contexts is freeing. Uses a nice and well established language, which is refreshing. Development seems less pained (even if its not on github), which pleases me. The OS doesn't use systemd, which is a petpeeve of mine so rather happy about that. There's better toolage for new packages, which seems tidier than the nixpkgs way. And y'all don't use goddamn matrix
<lfam>Maybe we'll use matrix in the future, I don't know
<lfam>Using IRC instead of Matrix is not a particular value of the Guix project
<drakonis>civodul: say, why does clang-toolchain have cc/c++ symlinks but not gcc-toolchain?
<ix>Downsides; no flakes, and there's a worse repl experience, but thats it really
<nckx>I'll test it and push it if it works (should be a formality).
<abcdw>ix: Probably `guix describe -f channels > current-channels.scm` should serve your needs. After that you can do `guix pull -C ./current-channels.scm && guix WHATEVER --args` or `guix time-machine -C ./current-channels.scm -- WHATEVER --args`.
<soheil>nckx: Yes it is true, I wanted to tell the news of the new comments.
<jackhill>ix: that's interesting to hear about the REPL experience. Having not paid too much attention to Nix, I didn't even realize they had a REPL, and was blinded by the assumption that of course lisps have great REPLs :)
<ix>jackhill: it was one of the first things I tried. I use it extensively in nix, have special attrset hooks just for it, and even have it plumbed into emacs
<jackhill>I recall a discussion here in the past where I said I was interested in adding some recipes for using the programming interface to the cookbook. I haven't done that yet, bit it hasn't lost its attractiveness to me.
<abcdw>drakonis: ix: We only proposed to start a new guix-home branch for moving Guix Home from rde repo to guix repo. Idk how much time it will take. https://lists.sr.ht/~abcdw/rde-devel/%3C871raw856c.fsf%40trop.in%3E We also have activation refactoring and one more feature to finish before upstreaming. Also, need to get more feedback from other maintainers on what they think on Guix Home.
<jonsger>cbaines: I'm in the graphical installer, so I don't need to set a mount point
<maximed>lfam: Unlikely, yes, but safeonweb adds links in spam to blocklists. And I guess they have the right contacts to add phishing sites and such to the DNS blocklist. (Well, at least the one for Belgium)
<lfam>How did we install Guix System on the Overdrives? Did we use `guix system init` from another distro?
<andreas-e>Yes, I think so. At least that is what I did on dover, probably following others' lead.
<nckx>It wasn't a coordinated effort. They came with OpenSuSE. I wiped the hard drive, then booted a Debian or Fedora live ISO and installed Guix from there. Others borged the existing distribution without wiping /.
<nckx>I've never had an existing Debian installation so the experience was quite similar. Either a new OEM Debian to which I need to apt stuff & build Guix, or a live environment to which I need to apt stuff & build Guix.
<drakonis>i want to go for a live environment for running debian instead
<lfam>My options for USB / external storage are very slow
<drakonis>flip the situation around and be able to successfully build a rescue usb using guix
<lfam>So, booting the USB-backed Debian live ISO, installing Guix, running `guix system init`, it's going to be slow
<lfam>But, it sounds like that's what I have to do
<vagrantc>yeah, fail-on-missing-substitutes is a long-requested feature
<dstolfa>has anyone seen https://deb.trendtechcn.com/? this looks like it's fully free but the drivers are not in mainline. i'm not sure if any firmware is requried, but given that they support trisquel i assume there isn't any
<dstolfa>would perhaps be worth packaging if it is fully free?
<vagrantc>there are also some hooks out there to basically wrap around guix pull and pull to the most recent generation that has substitutes for a given profile or something
<nckx>vagrantc: <if you have fast CPU and slow disks, it's not really a penalty> Only if you add caching. But it's less obvious then, true.
<drakonis>the most painful thing about nix is dealing with language ecosystems in there due to everything being designed with the assumption that you'll run a function to coerce the packages into an environment with them
<dstolfa>nckx: i don't, but i might buy one. i've emailed them asking about firmware and if their installer works on guix (it's GPLv3)
<dstolfa>if it does, i'll probably get one and give it a good test. if it's satisfactory, i'd be happy to package it up
<vagrantc>dstolfa: evaluate the source code first; it may contain obfuscated code or binary blobs
<ix>drakonis: I mean sure I just don't see any convenience whatsoever from guix pack, whereas nix run I actually end up using day-to-day
<chikamungus>trying out emacs-guix: it looks lovely, however, when I tried to get it to list installed packages, I got this error: guix-geiser-eval: Error in evaluating guile expression: While executing meta-command:
<sneek>chikamungus, leoprikler says: In that case it's likely you have emacs installed system-wide (i.e. /run/current-system/profile if you're running Guix System), so you need to refer to that instead
<apteryx>it seems to hangs in the test suite at 20%
<vagrantc>nckx: weather it does anything with that, who knows
<drakonis>ix: i do certainly hope to help solving any issues you might have
<apteryx>chikamungus: hmm, yeah, emacs-guix is not very much maintained these days, which is a shame. But at the same time until the performance problems of Geiser are fixed it wasn't as useful at it could be.
<chikamungus>leoprikler: I installed emacs in my personal profile and guix-emacs runs but see above
<drakonis>installing to your profile is a supported use case though
<drakonis>so it might be a lot less painful than trying to copy nix run
<chikamungus>that is a shame - it has favourable mentions on the web
<ix>drakonis: oh I'm not actively wanting nix run, I was just musing. Guix environment will suffice where I need similar
<nckx>dstolfa: Because supporting Trisquel does not imply abiding by Trisquel's rules.
<nckx>Software doesn't have to be FSDG-free to run excellently on Guix.
<dstolfa>nckx: yeah but how do they get the firmware in if it's needed
<drakonis>i cant include guix because it does not deliberately excise half of the archive and then include a package that conflicts with the removed packages or things that conflict with their own personal beliefs
<nckx>drakonis: There are a few ‘app store’ like things that we block because of the FSDG but we don't block loading user-supplied plug-ins on purpose.
<nckx>I hope they've progressed in all ways since then.
<dstolfa>nckx: vagrantc: looking at it more, it seems that those are under a compile time guard CONFIG_FILE_FWIMG. i can't see this being turned on anywhere, so i think it actually doesn't use any blobs
<nckx>ae has the best nick and now I want to put on an Autechre record again.
<lfam>drakonis: Maybe it's the same people who think that systemd isn't free software, and thus also don't use pulseaudio, because it was started by the same author
<dstolfa>from what i can see, this driver is fully free and should be fine in linux-libre. i'll still wait to see their reply and follow up on this. they say that they offer full refunds if the customer is not satisfied up to 2 years, so i might snag one and play with it more
<dstolfa>nckx: vagrantc: right, so the only concern i have about this is that they distribute source as deb packages, which would make packaging it in guix a bit of a nightmare. i will prod them about it based on their response and as i find more things out in these drivers
<nckx>I must disagree with drakonis here, it's even less possible to legally distribute a little bit of non-free code.
<ae>I am confused. Why am I "ae"? I registered "andreas-e".
<drakonis>i honestly have difficulty believing their judgement
<nckx>drakonis: It's more than that. Building a cool blacklist in your own back yard is one thing, but occasionaly people try to pressure other distributions (through GNU & the FSF) to apply the same broken logic. That's when it gets dangerous, because the most extreme opinion often wins by default.
<andreas-e>nckx: So finally I understand: ae is registered by a user Elwell.
<drakonis>nvidia, vanilla linux kernel, some other little bits
<lfam>Rooks: Current Firefox. Many drivers from the kernel
<nckx>Zealots has to positive a connotation, and I'm not trying to be provocative. I'm not saying they should be pragmatic. I'm saying they're wrong and unwilling to listen to facts that contradict their prejudice.
<lfam>An installation might work for 15 years, or it might turn itself inside out. Humans love gambling
<leoprikler>epiphany:epiphany:parabola:367:[uses-nonfree] has non-privacy search engines e.g. Google <- can't they simply make use of freedom 2 and 3 to distribute versions of Epiphany, that have those disabled?
<vagrantc>admittedly, the whole rolling release model of guix drives me a bit crazy ... i can see the appeal on some level, i just can't stop running "guix pull && guix system reconfigure ... && guix upgrade ..." obsessively
<projectmoon>where can i find documentation on how to append to two sets of services in a single `(services)` definition?
<projectmoon>i have an entry for %desktop-services, but i also want to update %base-services
<vagrantc>leoprikler: that would require more effort than a one-line blacklist
<nckx>projectmoon: They are just lists, you append those.
<nckx>projectmoon: That's not the reason you got an error. (services (append (list ...) %desktop-services (list ...) %base-services)) would get you a duplicate service error, but (services (append (list ...) %base services) (append (list...) %desktop-services)) was just plain bad syntax.
<drakonis>vagrantc: you can always follow the branches for the releases
<drakonis>that's a only for people that have to deploy it for work
<nckx>projectmoon: Sure, and you will. It's (services LIST), you were trying to do (services LIST LIST). You could have wrapped the whole thing in yet another append and it would have worked! Ugly, but worked.
<drakonis>as they all have to..., whatchamacallit, ratify it?
<dstolfa>i'm like 99% sure that the driver is fully free (i say 99% because i didn't read through all of the loading and initialization code yet, but i have looked at anything that could possibly load blobs and it doesn't)
<dstolfa>at some point, i might need to borrow someone's time who's skeptical about it so that i can try to convince them in hopes of getting some more certainty about it :)