<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?
<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...).
<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"
<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
<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
<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>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>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 :(
<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
<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
<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>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`
<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?
<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
<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
<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.