IRC channel logs

2021-05-16.log

back to list of logs

<drakonis>v. nice.
*gn21[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/OGMoCzrHjeNBBnLKiDrfeDBC/message.txt >
<gn21[m]>thanks!
<vagrantc> gn21[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/OGMoCzrHjeNBBnLKiDrfeDBC/message.txt > ???
<gn21[m]>Sorry?
<vagrantc>is it a long message or something?
<vagrantc>gn21[m]: it seems like your client is doing something that doesn't come across very well in IRC
<gn21[m]>ok
<lfam>You need to install nss-certs
<lfam> https://guix.gnu.org/manual/devel/en/html_node/X_002e509-Certificates.html
<gn21[m]><vagrantc "gn21: it seems like your client "> I am using the revolt program from matrix. Sorry!
<vagrantc>gn21[m]: it happens, just reflecting back what i saw via IRC so you know if some messages aren't coming across to people :)
<gn21[m]><lfam "You need to install nss-certs"> It worked. Thank you very much!
<gn21[m]><vagrantc "gn21: it happens, just reflectin"> It was a copy and paste from the terminal into my matrix client window. That could be it, I don't know. Thanks for the alert.
***sneek_ is now known as sneek
<colemickens>Is it possible to use Guix in a way that does not rely on user configuration, such as that in ~/.config/guix? I can't go back to a world where I rely on the state of such things for reproducability.
<colemickens>Also, how can I ramp up on the difference between nix and guix substitution? A recent ML thread made me realize that serving guix substitutes may already be a bit more sophisticated than what Nix has (I wrote a self-host/self-service nix caching tool that I'm thinking of trying to adapt to Guix).
<drakonis>declaring channels on the system configuration?
<drakonis>i've seen that used once
<drakonis>i should gear up for moving my server to it
<drakonis>colemickens: you can also set it up on /etc/guix/channels.scm
<drakonis>but i suspect that's not quite what you want
<colemickens>You suspect correctly.
<colemickens>Put another way, I'm seeking the Guix equivalent of `unset NIX_PATH; nix-build --pure-eval ./something.nix`, where I can basically 100% guarantee that someone else issuing the same command will get the same derivation (not sure that term is used here, I need to check...).
<drakonis>ah i see
<drakonis> https://guix.gnu.org/cookbook/en/guix-cookbook.html#GUIX_005fPACKAGE_005fPATH this?
<vagrantc>colemickens: "guix time-machine COMMIT" might be what you're looking for?
*vagrantc forgets the exact syntax
<drakonis>nothing that pulling it off `info guix` cant help
<drakonis>guix time-machine OPTIONS... -- COMMAND ARG...
<vagrantc>there
<drakonis>declarative channels on the system config is a good question now
<vagrantc>it basically allows you to run guix from a specific commit
<drakonis>i was looking at the source
<vagrantc>not sure about how time-machine interacts with channels ... haven't used channels much
<drakonis>its defined in guix/channels.scm
<drakonis>the module that exports it is called guix channels
<drakonis>so you could just append the channel you want into the system config
<drakonis>but otherwise, if you want to pin, use time-machine or inferiors
<drakonis>oh i see what you want
<drakonis>okay
<drakonis>guix build -f file.scm
<drakonis>it defaults to pure eval here
<drakonis>you can use inferiors to pin the build
<drakonis>colemickens: would this help?
<colemickens>sounds like it, let me do some reading
<colemickens>I'm still getting my head around guix system having a proper api for image creation etc. It's neat, but I'm also used to Nix where it's all one big jumble of nix and modules that provide extra output modules for things like `sdImage` or `toplevel`.
<colemickens>I need to see if things like "explicitly build an expression that outputs a guix system closure, then activate the 'toplevel"
<drakonis>guix environment?
<colemickens>that looks like it's a shell, not the system
<drakonis>hmm
<drakonis>i see...
<colemickens>oh no, "Guix" is the package set and the tooling?
<colemickens>I guess I will just use guix time-machine for everything?
<colemickens>that works for me?
<drakonis>yes...
<drakonis>well
<drakonis>its very unified though
<colemickens>I don't really know what that means :P
<drakonis>aint any of those problems where it is a huge jumble of things you have to piece together to get something done
<drakonis>guix is the directory where the tooling lives and gnu is the package set
<drakonis>if you look inside the git repo
<colemickens>"The guix time-machine command provides access to other revisions of Guix, for example to install older versions of packages"
<drakonis>oh, yes.
<colemickens>that sentence strikes me as using "Guix" as a reference to the package set. It was just a bit surprising, I had to read it twice to make sure it meant what I was hoping :)
<drakonis>that's a fancy toy it has
<colemickens>or is it in fact both the tooling and the pkg set at that point?
<drakonis>its the guix repository it refers to
<colemickens>right ok
<drakonis>it has been both the tooling and package set from day 1
<drakonis>it can go very far
<colemickens>just to make sure I'm understanding, `guix time-machine` actually retrieves the `guix` package set at an older revision *and* then re-execs older tooling from that older package set?
<drakonis>i think so
<drakonis>the whole paragraph implies it is for reproducing the environment
<drakonis>reproduce the computation in an identical environment
<drakonis>there is also inferiors
<drakonis>which does what you described
<drakonis>in which it will sub-exec the environment with the packages you need
<drakonis>this is the one you want
<drakonis>ah right, time-machine is functionally inferiors on the cli
<colemickens>well, inferiors looks like overlays to me
<colemickens>inferiors seems to use the same channel type, and then provides mechanisms for composing from various guix sets
<colemickens>anyway, I am new, so we'll see, but I guess I see myself exclusively using `guix time-machine` in lieu of `guix build` to match my expectations coming from the flakes world.
<drakonis>overlays seems... overly complicated
<drakonis>its not ergonomic
<drakonis>that is
<drakonis>the usual usecase is to patch expressions in nix
<drakonis>doing the same thing in guix is much simpler
<colemickens>regardless, at a high level what I said seems to remain true
<drakonis>sure
<colemickens>The lack of flake-like features means that guix has the same cross-repo composability limitations that nix stable has, but I guess that's where things are at right now?
<drakonis>hmm
<drakonis>it does not
<drakonis>well...
<colemickens>so I can pull a random Guix project into mine via a channel and rely on the things it pulls it "just working" ?
<drakonis>yes
<colemickens>if that project doesn't have to check in it's channels, how can that be true?
<drakonis>i suppose you're talking about pinning a copy of a older version of guix to build against?
<colemickens>I'm talking about the fact that flakes projects are reliably composable in ways that nix and guix projects aren't
<drakonis>hmm, i see
<colemickens>It's also actually entirely possible that Guix isn't meant/expected to be used as generically as Nix is like this? I really don't know, just want to be clear I'm still a noob and sort of roughly stating hopes, etc. :)
<drakonis>what kind of composability are you after anyways?
<drakonis>nix has a huge fragmentation issue already
<drakonis>flakes seems to be designed entirely with that in mind
<drakonis> https://guix.gnu.org/manual/devel/en/html_node/Declaring-Channel-Dependencies.html
<colemickens> https://github.com/cole-mickens/nixcfg/blob/main/flake.nix
<colemickens>that kind of composability
<colemickens>the fact that I can pull in mobile-nixos, and override the nixpkgs it's using
<colemickens>the fact that I can pull these projects in * at all* and have them work because of pure-eval
<colemickens>that , channel deps, might be enough?
<drakonis>i think it might
*colemickens needs to read more asap
<colemickens>yeah, interesting.
<colemickens>so much good stuff to learn
<drakonis>see i told you
<drakonis>its good stuff
<drakonis>flakes is a workaround for nix's limitations
<drakonis>i see you're still using overlays to add packages to nixpkgs
<drakonis>colemickens: https://ambrevar.xyz/guix-advance/index.html
<drakonis>have i linked this yet?
<abralek>Hi Guix
<Kimapr[m]>does Guix System support LVM yet?
<cbaines>woo, I just noticed powerpc-linux derivations https://data.guix-patches.cbaines.net/repository/2/branch/wip-ppc/latest-processed-revision
<cbaines>I assume that's your work efraim :)
<efraim>yep, wip-ppc is me :)
<cbaines>previously, the systems the Guix Data Service knew about where hardcoded, but now they're not, which is good
<efraim>I think I'm going to have to rebase again on core-updates so I can test it against guile-3.0.7 and then I can push the first couple of patches, through to mesa. It'll be nice to have that upstreamed finaly
<cbaines>in terms of build hardware, is ppc64 hardware compatible with powerpc-linux?
<cbaines>like, does it have the same relationship as some armhf hardware has to aarch64 hardware?
<efraim>I believe so, but unless we actually use a big-endian ppc64 port we'd clasically need a VM on ppc64le to build 32bit ppc packages
<efraim>I haven't tried using the binfmt service
<mstrom[m]>vagrantc: I’d be happy to be reflected like gn21 if something I do looks weird too
<cbaines>efraim, OK, that's interesting to know :)
<mstrom[m]>Kimapr:
<mstrom[m]>whoops sorry
<abralek>In gnu/system/vm there is a function virtualized-operating-system which is used by system-qemu-image/shared-store-script. I need to propagate an additional qemu image with a preset data. Unfortunately virtualized-operating-system removes file-systems due to this constrain (string-prefix? "/dev/" source)
<abralek>What can I do?
<abralek>I guess I need to avoid virtualized-operating-system
<bdju>if anyone has free time, it would be nice to see the "foot" terminal package updated. it's a few months behind now
<nixo_>Hi guix! I just wanted to report that yesterday I tried installing guix from binary (on foreign distro) on the Librem5 and it worked extremely well. The install script ran super smooth. I'm now trying to replace default programs with those installed from guix. It takes ~1h to build gtk+ on it
<vivien_>Isn’t that damaging the battery long-term?
<vivien_>Obviously there’s no experimental data about this though
<pineapples>o/
<pineapples>bdju: Hello, fellow "foot" user. :) If you don't want to wait, and need features only found in the currently newest release, you can pass the `--with-commit=foot=[commit]' transformation flag to `guix install foot'
<bdju>pineapples: thanks for the tip! btw, do you have a way of opening URLs from foot? they recommend xurls, which isn't packaged. and for some reason swapping it for `urlscan -n` in their one-liner doesn't work
<pineapples>bdju: I'm sorry, no; I haven't figured out how to open them yet, either :(
<bdju>darn, alright.
<pineapples>bdju: I have installed 1.7.2, and I'm able to enter the URL mode, using CTRL+SHIFT+u key sequence
<pineapples>Ah, right. URLs aren't opened
<pineapples>bdju: It looks like "foot" would use some code patching. Explicitly installing `xdg-utils' to your user's profile should do it as a temporary workaround
<bdju>I'm still on the old one, but I adapted a config setting mentioned in a changelog for 1.4.x: `pipe-visible=[sh -c "urlscan -n | bemenu -n -m -1 -l 5 | xargs -r xdg-open"] Control+Shift+U` and it didn't work
<bdju>if the new one has better URL support, I'll maybe be okay after updating. I have xdg-open installed and configured
<bdju>I'll give it a go later
<meo>so I have a little dilemma
<meo>ssh-agent has a whitelist of library locations which is required for the operation of pkcs11 hardware token authentication such as yubikey
<meo>by default it is configured to /usr/lib and /usr/local/lib
<meo>so I compile a custom library package and it ends up under /gnu/store.. should SSH defaults be patched to reflect that? and wouldn't a whitelist for the entire /gnu/store be too permissive?
<meo>as of right now I got yubikey piv authentication to work on my ubuntu + guix machine, and tomorrow I'll try it out on ubuntu sd
<meo>s/ubuntu sd/guix sd/
<bdju>pineapples: I can't get the --with-commit thing to work: it keeps saying invalid replacement specification
<bdju>I copied the commit next to the release and I've tried removing parts of the url and auch. I can't figure it out
<bdju>s/auch/such
<bdju>hm thought I'd figured it out maybe, but no. I used --with-git-url with it but still can't figure out the syntax
<bdju>ahh I re-read what you said now and I think it's working
<bdju>I hadn't left in the foot= part when just trying the commit, and the full url doesn't work
<apteryx>is anyone else having problems building their operating-system config due to a disarchive build failure? It fails configure with: configure: error: guile required but not found
<apteryx>even though guile-3.0 is in the inputs
<apteryx>perhaps the guix package needs to be bumped?
<vldn1>how to append (dirname) with-in a (plain-file "test.txt" ... ) ? even with string-append it complains about not beeing a string :/
<brendyyn>im getting something weird. after running updating guix gc and rebuilding from git, im getting source file /home/... newer than compiled /run/current-system/profile/lib/guile.3.0/site-ccache/..., even though im using ./pre-inst-env
<brendyyn>i run make and it still does it
<brendyyn>before it would only care about the cache in home directory
<mbakke>vldn1: can you provide a more concrete example?
<vldn1>(extra-special-file "/etc/fish/config.fish" (plain-file "config.fish" (string-append (dirname))))
<vldn1>i guess there is some quote magic needed
<mbakke>vldn1: you probably want (local-file "config.fish") instead :)
<vldn1>i want to write outputs of guile expressions directly to the file
<vldn1>guile output from (dirname)
<mbakke>vldn1: ah, I see. the problem is that (dirname) needs an argument, perhaps the error message is swallowed by the gexp machinery?
<mbakke>apteryx: I'm working on TeX Live 2020 again, which is the last remaining showstopper for GCC 10, but after your "recent" changes on core-updates it no longer works: pdftex et.al can't find "mktex.opt". Does that ring a bell?
<bdju>pineapples: I can open URLs in foot now! Just tested. Thanks for the help!
<ilmu>hey I think I found a bug but I'm not sure
<ilmu>in `install-grub-efi` function (from gnu/bootloader/grub.scm) the way it appends to the mount-point path makes you get //boot/efi when your partition scheme is all split up
<ilmu>or maybe I made some other mistake, I'm trying to figure out how to test this hypothesis
<ilmu>(for reference; I have this issue on a laptop I'm installing guix on, it has two harddrives sda and sdb, sda has swap and /home, sdb has /boot/efi, / and /boot partitions.)
<ilmu>when I try to install the command that fails is `grub-install --boot-directory //boot ... --efi-directory //boot/efi
<ilmu>sorry not install, reconfigure
<ilmu>first reconfigure post-install, no change made to the filesystem or boot fields in the config
<thorwil>hi! it seems every few weeks i’m thrown into a initramfs prompt, as root got mounted read-only. the way out is always running fsck, which reports error that i either can’t map to anything, or that refer to paths that belong to guix. usually only below /gnu/store, but this time also var/guix
<thorwil>in other words, i have frequent filesystem corruption, where all issues refering to a path belong to guix!
<leoprikler>That is certainly abnormal, but note, that since much of your software resides in Guix it is highly likely that if you have a drive failure, those paths will be affected
<thorwil>this time it happened on first reboot after a `guix pull && guix package -u`
<thorwil>agreed that it could be about statistics
<apteryx>mbakke: not immediately, but I can take a look. The basic idea of the change is that the default config provided by texlive-bin enables the use of multiple TEXMF trees, which enables composing TeX Live components better.
<ss2>What is the best way to recompile the guix sources after git pulling?
<ss2>several test suits are failing, and it never completes.
<thorwil>anyway, now guix pull fails with: `;;; WARNING: loading compiled file /gnu/store/8bsnz1fk330qbn1p8k18i0j11vld4jxd-guix-module-union/lib/guile/3.0/site-ccache/guix/build-system/gnu.go failed: ;;; In procedure load-thunk-from-memory: not an ELF file`. how do i get out of that situation?
<leoprikler>thorwil: roll-back?
<leoprikler>or explicitly use an earlier guix command
<vldn>has someone an example to write a wrapper for a javaprogram? (like using copy-build-system for fetching and setting the java executable to icedtea?)
<thorwil>leoprikler: seems i was a bit too eager with throwing the trash out and have a single generation left
<leoprikler>ouch
<leoprikler>system too?
<thorwil>i don’t follow
<leoprikler>single system generation?
<thorwil>well, `guix package --list-generations` lists a single generation 59 (no, i do not quite know what i’m doing)
<leoprikler>now do `guix system list-generations`
<thorwil>heh, i was just looking if that exists. it also throws that "not an ELF file"
<leoprikler>btw. you can also look at /var/guix/profiles
<leoprikler>using plain old ls/tree
<leoprikler>that way you don't have to invoke the potentially broken guix commands
<thorwil>good idea! -> https://pastebin.com/raw/s9U6ejj2
<leoprikler>what does ls -l ~/.guix-profile say?
<thorwil>lrwxrwxrwx 1 thorwil thorwil 48 Jan 15 14:14 /home/thorwil/.guix-profile -> /var/guix/profiles/per-user/thorwil/guix-profile
<leoprikler>ahh, no, not guix-profile, ~/.config/guix/current
<thorwil>lrwxrwxrwx 1 thorwil thorwil 48 Jan 15 13:11 /home/thorwil/.config/guix/current -> /var/guix/profiles/per-user/thorwil/current-guix
<leoprikler>hmm, can you run thorwil/current-guix-62-link/bin/guix pull?
<thorwil>no: guix pull: error: Git error: invalid data in index - incorrect header signature
<thorwil>i wonder: what should i move ou of the way, to install guix anew? i have a manifest for my packages, after all
<thorwil>leoprikler: thank you! time to leave, as this hexchat is runing from /gnu/store ...
<leoprikler>welcome back!
<Linus[m]>Hi, im using Linux Mint 19 :( Is there a gui package manager?
<Linus[m]>a gui for the guix package manager? :D
<thorwil>leoprikler: thanks, though this is because i can’t figure out how to wipe out /gnu/store ... though i’m taking thi sto help-guix, now.
<leoprikler>if you wipe /gnu/store, all of guix will be gone and you'll have to reinstall it.
<leoprikler>(well, there's still /var/guix, but eh)
<leoprikler>Linus[m]: Currently not, there's a WIP project out there, but it has not been worked on for a few months.
<leoprikler>There was also some talk about writing bindings to PackageKit
<thorwil>leoprikler: of course, that was the plan.
<leoprikler>thorwil: if you still have the installation disk, you can try to mount your partition from there and then just rm -rf it
<Linus[m]>leoprikler: Do you have a link to the git repo?
<leoprikler> https://gitlab.com/daym/guix-gui
<bone-baboon>When I run `guix challenge` in the output there are a lot of warnings like this "guix challenge: warning: could not challenge '/gnu/store/<something>': no substitutes". Here is how I interpret this warning: I built the thing in question from source and it is not available from the substitute server. Is this a good interpretation of that warning message? Are these warnings the only thing that is listed as inconclusive in t
<bone-baboon>`guix challenge`? I am getting 20.9% inconclusive.
<vagrantc>bone-baboon: yes, if you have a locl build and no substitute build on the server(s), it will be considered inconclusive
<raghavgururajan>Hello Guix!
<bone-baboon>vagrantc: Thanks
<bone-baboon>Is it possible for something that was downloaded as a substitute to be inconclusive when check with `guix challenge`?
<vagrantc>i don't think downloaded substitutes are compared
<vagrantc>it only compares local builds against substitutes from the server
<vagrantc>since the paths in /gnu/store are the same, it can't really both have a local build and a downloaded build
<vagrantc>of course, you can download and extract it somewhere other than /gnu/store ... which is what i presume guix challenge does when it shows you the content diff
<vagrantc>either with diff or diffoscope
<vagrantc>guix challenge is arguably one of the features that got me most interested in guix :)
<bone-baboon>vagrantc: Thanks
<bone-baboon>vagrantc: It is also very interesting to me.
<bone-baboon>Does `guix challenge` take into acount what is built with `guix build --no-substitutes --check <package>`?
<tissevert>hi guix
<nly>any way to tell geiser to use guix environment for the project?
<bone-baboon>In the output of `guix challenge` there are many packages that are listed several times. For example guile will show up in the ouput more than once as differing for "/gnu/store/<hash>-guile-3.0.5" but with different <hash> values. Is this because the computer the command was run on has built different versions of guile-3.0.5 based on different definitions for guile over time and each of them differ?
<mdevos`>bone-baboon: guile without grafts has a different hash from guile with grafts
<mdevos`>bone-baboon: that is a possibility
<nly>d/c'ed
<bone-baboon>mdevos`: Thanks
<bone-baboon>I have not done anything to change grafts.
<bone-baboon>Just `guix build --no-substitutes guile`. Which has been run many times.
<mdevos`>bone-baboon: guix gc --referrers /gnu/store/...-guile-3.0.5/bin/guile may be informative.
***zap1 is now known as zzappie
<bone-baboon>mdevos``: Thank you for suggesting that command. Running it shows that the different guile's with the same version number do not have the same referrers. This could have something to do with Guile being used as a dependency for other packages?
<bone-baboon>I have run `guix challenge` I get 134 that differ. Of these 113 are "/gnu/store/<hash>-guix-*". I was expecting guix things to be in the identical category not the differed category.
<bone-baboon>Is it expected for there to be many guix
<bone-baboon>Is it expected for there to be many guix-* things that differ when checking with `guix challenge`?
<mdevos``>bone-baboon: there are some bug reports on bit-for-bit reproducibility of .go files on the bug tracker
<mdevos``>so not unexpected
<bone-baboon>What is the current status for bootstrapping Guix?
<roptat>l'article a passé la modération : https://linuxfr.org/news/gnu-guix-1-3-0-est-publie :)
<nckx>Morning Guix.
<jonsger>evening guix
<nckx>roptat: Félicitations!
<pineapples>Hello, nckx!
<pineapples>Hi, jonsger
<roptat>now massively updating po files on weblate, to track master instead of version-1.3.0 :)
<roptat>I think weblate is still working hard on updating the strings for the manual