IRC channel logs


back to list of logs

<graywolf>samplet: Ok, in the end it was pretty easy:
<graywolf>Only downside is that things like geiser-restart-repl and C-c C-z to "bring the repl back" do not work (they spawn the normal geiser). But I can live with that.
<samplet>graywolf: Cool. Thanks!
<oriansj>Guest28: it is best if users choose for themselves instead
<oriansj>ideally the only things that guix enforces are isolated package builds, freedom respecting code and the use of guix as the package manager. Everything else is optional
<nckx>oriansj: Good defaults & user choice are bffs forever.
<nckx>Well, I'll settle for s/Good/Working/.
<fries>if updating an existing go package to a newer version required for a go app to work, but that package required go 1.18 or later due to using generics; would it be the best to create another guix package for that newer version that has someway to indicate you have to set the dependent packages to use go 1.18 or later or just update all the existing dependents to use go 1.18?
<fries>if anything, im talking about updating ( which has a file that uses go generics in the newer version
<fries>and i have to update a package depending on that (tview) to get gdu to not hang and do nothing while opening
<fries>as whatever old version of tview in the guix repos thats there doesn't work
<fries>if anything, i think i would have to update every package that has that package in the dependency chain to use a newer go version
<nckx>Welcome :)
<deedend>Hi everybody, total newbie here, has anybody managed to install guix on a Thinkpad T480? Any issues/workaround for firmware etc?
<sneek>Welcome back deedend, you have 1 message!
<sneek>deedend, nckx says: You can include any custom Xorg configuration (in xorg.conf syntax) using the extra-config field of the xorg-configuration record. Which is often used as the value for the xorg-configuration *field* of your display manager, so you get something like
<nckx>…and of course that paste is expired by now. Sigh. Sorry.
<nckx>Probably too old to matter.
<viaken>RIP. I was chasing getting docker working (after having failed with podman) and it complained that it needed dbus & elogind, so I added them without config and now everything is broken.
<Guest6>how would i mount a btrfs file system with deduplication activated?
<podiki>Guest6: isn't that just a property of btrfs (by default)? i don't think there is any mount options
<Guest6>podiki: Ah, right.  THanks
<podiki>no problem!
<jpoiret>viaken: did you not have dbus & elogind before?
<viaken>jpoiret: They aren't in %base-services, so no
<efraim>is VDPAU_DRIVER_PATH supposed to be a singular path?
<efraim>after updating my home profile on aarch64 I can no longer see any text in alacritty
<efraim>the main difference between the two is the update to mesa
<efraim>looks like it's a problem with alacritty, I added terminology to try again and I'm not having problems with text there
<minima>hi, is there any guix home facility for xinitrc files? one can simply use local-file i suppose but i was wondering if there could be anything more specific to xorg/xinitrc/startx?
<PotentialUser-60>Which version of GNOME is available in guix
<minima>PotentialUser-60: guix show would seem to indicate 42.4?
<PotentialUser-60>Is kde available?
<minima>PotentialUser-60: I'd think so but not really sure, sorry, I'll leave others to take this
<PotentialUser-60>Which version of Firefox is icecat based on?
<minima>PotentialUser-60 it's information that you should be able to access from here - you can click on a specific package and then follow "Package source" to get to the repo page; i can see the version number should be 102.14.0
<jpoiret>I think icecat is based on the latest ff lts
<nckx>(They've left but) ‘KDE’ as in Plasma desktop isn't available, but there's a patch for it <>.
<parnikkapore>How do you test a Guile macro? I've tried searching around but found no answers
<parnikkapore>(asking again here because there are a lot more people)
<Kabouik_>Why is kmonad only avilable to x64 and i386? I don't think anything prevents building it on arm in the sources.
<Kabouik_>I don't see where is that restriction in the package definition actually; else I'd have tried removing it.
<efraim>haskell dependency
<efraim>well, it is a haskell program ;P
<efraim>we don't have a GHC bootstrap for arm* yet
<Kabouik_> I already managed building it from sources on Debian arm though
<Kabouik_>But okay, we are missing GHC bootstrap, understood
<efraim> here is part of one, but tests should be disabled since they're more than 48 hours for aarch64
<janneke>sneek: seen civodul?
<sneek>I think I remember civodul in #guix 17 days ago, saying: and i586-gnu native compilation, yay!.
<janneke>sneek: seen regtur?
<sneek>Not as far as I can remember.
<janneke>sneek: botsnack
<podiki>efraim: re vdpau_driver_path, yes singular
<RavenJoad>lilyp: I got build-image working. I needed a (with-store store (run-with-store store ...)) wrapper.
<Kabouik_>efraim just foy your information, I was able to build kmonad for aarch64 again (latest commit) using `cabal` instead of stack. This is already what I did in 2021 in the Github issue I linked, but it still works. As far as I remember, compiling it with `stack` as recommended in the instructions would fail. I don't know if that can be useful to know to make the Guix package work on arm one day too.
<Kabouik_>I'll update the issue to report the same info.
<RavenJoad>I am writing a Guile/Guix script that uses qemu. How can I reference the binary? (string-append qemu "/bin/...") fails with a type error because #<package ...> is not of type string. file-append does not make sense, because this is a single-phase process (no lowering).
<jpoiret>RavenJoad: you want file-append instead of string-append
<jpoiret>also you'll need to use #+ since you want the builder's qemu
<RavenJoad>jpoiret: Thanks! I always used file-append with gexps, so I was not sure it would work. No gexps or builders here, yet.
<jpoiret>ah, I don't understand, you want to use guix's qemu from a guile script?
<jpoiret>that's going to be significantly more difficult, since you'll need to interact with the store, and also handle possible errors while building
<jpoiret>is there any reason you can't just do `guix shell qemu`?
<jpoiret>and run your script inside of the shell?
<neox>Hi there, did somebody saw that the xonotic package hasn't been properly updated ?
<neox>It seems that someone forgot to bump xonotic-data version to 0.8.6 as well x)
<RavenJoad>jpoiret: Yes, a qemu provided by Guix. There is no real reason, no. I just want a script that does the qcow2 image stuff from (guix) Invoking guix system.
<jpoiret>To avoid additional complexity i'd suggest just assuming that qemu is available, and running the script in a shell
<RavenJoad>That may be the better solution long-term. I also wanted to try my hand at using Guix as a library.
<RavenJoad>I intend to also add this to my Guix home definition, which will ensure qemu is built too, the assumption will last.
<nckx>neox: Hello this is someone.
<nckx>I actually did update the datas, I just… didn't push it.
<neox>nckx, haha okay, well it did confuse me for some hours x)
<ekaitz>is a gdb-multiarch an interesting guix package or should I not bother and keep it for myself?
<minima>i'm experimenting with `home-unclutter-service-type' but it doesn't seem to work - it doesn't seem to hide the pointer; i can see `unclutter' listed under `herd status' as a "one-shot" service
<minima>any idea on where i should start to look at?