<ryanprior>lfam: I didn't realize that either, but I guess I'm not surprised since it's such a customizable architecture
***ezzzc2 is now known as ezzzc
<bdju>anyone know if I'll be able to use an M3D 3D printer on guix system without packaging additional things?
***ezzzc0 is now known as ezzzc
<singpolyma>Hello all! I am trying to build the latest version of alacritty, by starting with the definition already in guix and pointing it at the latest version. I have taken terminals.scm and removed all definitions for other terminals and un-package-wrapped it so I can feed it to guix package -f -- I get this error: "error: rust-serde-1: unbound variable" -- this variable does not seem to have been set in term
<singpolyma>str1ngs: I understand that. But for some reason even though I use the module, guix package -f reports that error
<lfam>singpolyma: I would follow the instructions in the Guix manual section "Building from Git" to get a Guix development environment set up. Then, I would proceed with updating the package
<lfam>The rust-serde package variable was renamed recently (see commit 271161db255304804b4aeabcba246686e76cf1b3). It's possible that whatever modules are being used when you do `guix package -f` are too out of date
<singpolyma>lfam: right. that sounds like what I expected the issue to be. But should guix pull not fix that?
<lfam>It should, yes. I don't have much experience using `guix package -f` or the -f option in general, so I'm not sure how it does these lookups
<str1ngs>singpolyma: also add alacritty at the end of the file. -f works of of the package the file evaluates too
<singpolyma>I'm looking at the "building from git" page and that seems like an incredible amount of overhead just to build one package
<str1ngs>singpolyma: does guix show rust-serde work?
<singpolyma>str1ngs: since the file is just a single package definition expression it shoudl evaluate to that, es?
<lfam>singpolyma: Yes, but it's a powerful tool once you have it. And if you are trying to update this package... it would be very nice if you contributed the update back to Guix :) And for that you'll need a development environment to test your patch
<singpolyma>str1ngs: yes, guix show rust-serde shows reasonable looking output
<str1ngs>singpolyma: no, because the packages is a define. you need to have it evaluate that's what adding the name at the end of the file does.
<lfam>You may need to start a new login shell for it to take effect. So, you could log out and back in, or just do `bash --login`
<singpolyma>lfam: ah, yep. bash -l has PATH set right already. So I just tried to use it too quickly after running the installer :P
<str1ngs>singpolyma: it's a little easier to work in the git tree. with ./pre-inst-env guix. when upgrading packages. if you plan to send patches.
<str1ngs>also if the declaration has not changed much. you can just inherit the original package and update the version that way.
<str1ngs>this ensure if there are any changes to the package declaration your custom version will also benefit
<singpolyma>Ok. I should read the manual about the inherit feature probably for the future
<str1ngs>-f is nice thought if you are just starting out. not wanting to deter you here :)
<singpolyma>The idea of sending a patch sounds fun. At this point I just want to see if it will build, etc
<singpolyma>I'm trying to convince myself that guix is the "right way" to run any software not in my main distro. Which may not even be a thing guix wants to convince me of, but I have a suspicion it is close
<str1ngs>singpolyma: the new term is guix system. and I recommenced it as well.
<singpolyma>the main thing that makes me a bit uncomfortable about using Guix on Debian (as I am attempting to do here anyway) is that all dependencies that a guix program has that are already on my main system will be there twice. But I think I'm supposed to pretend my hard drive is of infinite size
<str1ngs>singpolyma: I use it on both Debian bullseye and Ubuntu 20.04 LTS and 18.04 LTS works great.
<lfam>Yes, and it is! As long as you don't add new software too quickly
<lfam>Yes, propagation should be avoided when possible and convenient
<str1ngs>pkg-config will check the dependency and complain. both autotools and meson will bail. so should be easy to determin.
<apteryx>I guess they don't need to be propagated, because Requires would be used to transitively search for packages via pkg-config, while Requires.private will not expose those dependencies to dependents, so it's really just a mean for flag dependencies used for *this* library (no transitive pkg-config search involved, so no propagation required)
<apteryx>thanks for helping me understanding this :-)
<singpolyma>Ok. Build logs being in a compressed file instead of on my terminal is not my favourite thing. But I think I can live with it
<str1ngs>for the very adventurous. I've released a new version of nomad. It's now 99.9% written in guile scheme. has improved emacsy support for modeline and echo area. it's now in guix so if you have pulled today guix show nomad. should be @ version 0.2.0-alpha . you can give it a quick run with guix environment --ad-hoc nomad --nomad. please let me know if there are any blaring problems!
<str1ngs>nomad is a extensible web browser written in guile scheme FYI
<jgart[m]>str1ngs: Awesome!! I'm looking forward to giving it a test run.
<str1ngs>correction to run without installing use guix environment --ad-hoc nomad -- nomad .
<str1ngs>jgart[m]: it's still early days. so any feedback is appreciated
<luhux>Has anyone successfully run buildroot on Guix?
***apteryx is now known as Guest39705
***apteryx_ is now known as apteryx
<fnstudio>hi all, it seems that `guix install guile` gives me version 2.2.7; is there a specific reason for it not being v3? (sorry, i'm learning, not even sure if i need v3...)
<smileyface>I'm trying to reconfigure a guix install from a chroot within the live-CD. When running "guix pull" I get "guix pull: error: failed to connect to '/var/guix/daemon-socket/socket': Connection refused". I assume this is because the daemon was started outside the chroot by the live-CD. How should I go forward to make changes to the chrooted system? Just start guix-daemon again from inside the chroot?
<fnstudio>oh interesting... i knew font-ibm-plex was part of debian contrib - i think as a result of the font build process requiring non-free tools
<leoprikler>also our font-build-system does not actually build fonts IIRC, so if the tarball includes already built ones, we simply copy those
<leoprikler>(by building fonts I mean generating ttfs from svgs for example)
<fnstudio>leoprikler: no, you're right, contrib and non-free are two separate debian categories
<fnstudio>efraim: understood re that slight difference between dfsg and fsdg, interesting thanks
<rovanion>NieDzejkob, jlicht: The DNS resolution in IceCat seems to have been fixed, at least for this boot, by the command you gave. Do you know why `sudo herd invalidate nscd hosts` would have this effect, and is it possible to incorporate as a post-install trigger to the IceCat package into Guix?
<pkill9>i don't think the fold-packages procedure gets packages from additional channels
<leoprikler>pkill9: you can manually pass the modules to it, but it should search all of %package-module-path
<leoprikler>I have the uneasy feeling, that something broke emacs
<sneek>I think I remember vagrantc in #guix 3 days ago, saying: guix could have dependency packages for recommended package sets, such as the way gcc-toolchain pulls in several dependent packages ... that could be where you include the "default" font.
<tissevert>anyone using LXDE and/or specifically lxterminal with Guix ?
<leoprikler>okay, so after some debugging, I found, that it segfaults while creating X windows
***jonsger1 is now known as jonsger
<pkill9>leoprikler: funciton like (specification->package) find my channel's package definitions though
<christianbundy>It looks like the current version of nodejs is was released in 2018, is there a package for more recent versions?
<leoprikler>it's a soft error as I can see; the service is correctly started on reboot
<leoprikler>perhaps some incorrect logic in the upgrader, though
<tissevert>guix-vits: nope, I'm running in circle, maybe my config is wrong but I have no idea since I've found absolutely no information about how things are supposed to be run under Guix and apparently no one else uses this DE
<guix-vits>tissevert: Why no LXQT? Aren't LXDE abandoned by upstream? (I'm sorry for off-topic, just curious).
<tissevert>no particular reason, except I never managed to get a Qt input method handler
<tissevert>and I didn't want to have both GTK and Qt apps on my box
<roptat>can anyone record audio with audacity? When I press the record button, it stops immediately, recording nothing. I see it's set to alsa, but I can't change it to anything else, like pulse, i wonder if it's related?
<pkill9>why does this just return "open-zwave" in guile?: (fold-available-packages (lambda* (name version result #:key outputs location supported? deprecated?) name)
<butterypancake>so I'm really struggling to make this package :/ I'm really starting to thing that the parallel-tests? flag doesn't work when using the emacs-build-system
<stikonas>last release of lxde was 3 years ago, so it is abandonned in favour of lxqt
<butterypancake>ya, I cannot set parallel-tests? to #f in the emacs build system. I replaced the check phase with a phase that just prints out that variable and it's always #t
<butterypancake>is there a good way to debug the build system? I can turn the derivation into a gexp or something and print it out? gexps honestly go right over my head
<leoprikler>what exactly do you mean by "debug the build system"?
<leoprikler>the scheme code itself? the underlying build system it invokes?
<butterypancake>idk, I'm just trying to figure out why the build system is throwing aways parallel-tests?. I can replace phases so it's obviously not throwing away everything. So I'd like to look at the package object to see what arguments are actually in it
<leoprikler>You can read the check code in build-system/emacs to see whether it passes it to the underlying build system
<leoprikler>if it does (and imo it should), you need to debug that build system
<butterypancake>the check function uses the variable so I'm pretty sure that's fine. I'm really not sure how to debug the build system itself
<leoprikler>guix build -K, then experiment with the directory that you get
<leoprikler>if you want to inject a stop at a specific point, use (lambda _ (error "stop")) or anything similar
<butterypancake>no, the problem doesn't show there. The build system is running the command "make -j 12" and I need it to not. So I set parrallel-tests? to #f and it's still running make -j 12. So then I replace the check phase with my own lambda that prints the value of parallel-tests? and it says it's #t
<Jacob_>pkill9: I'm sorry about the late reply, but thanks for confirming that I'm not the only person who has experienced it. May you fill a bug report? I know I'm not in a position to request that, but I find Guix's email-based workflow daunting, and impractical in my case and, at the same time, I don't want to leave this issue unaddressed
<butterypancake>I'd just like to throw in that the problem with my package wan't fixed by setting paralell-tests? to #f. I still have to finish troubleshooting my original package :P
<pkill9>Jacob_: all you need to do is post to firstname.lastname@example.org, and when replying use reply-all
<greenrd>sounds good actually - I never found the USE flags concept in Gentoo/Exherbo very useful, and I see that Guix has a better way to recursively transform a package dependency tree if you really need to do that for a small system
<leoprikler>indeed, but it may come at the minor inconvenience of not having an easy way of choosing gtk or qt for packages that can be built with either, but not both
<greenrd>oh yeah, I can see how that would be awkward
<greenrd>good thing there's no packages that can be built either for emacs or vi, that would cause a holy war ;)
<leoprikler>I think there are one or two, like editorconfig, which aim to supersede (parts of) both. Those fools.
<pkill9>there is talk of parametarized packages which is supposed to be equivalent to use-flags
<greenrd>I am not sure it is worth the extra packaging effort tbh - how many users would actually gain a tangible benefit out of it, as opposed to a warm fuzzy feeling from making their system a bit more lean?
<pkill9>that's what i thought, but apparently people want it
<greenrd>but I suppose if the majority of the work could be delegated to the build-system support code in guix, the packaging effort could be quite low
<roptat>I'm trying to make ibus work. ibus is running and when I hit Super+Space, I see a window where I can switch keyboard between French and Anthy (Japanese), however it doesn't affect anything. Am I missing something?
<roptat>oh yes I am, the GUIX_GTK3_IM_MODULE_FILE has ~~ in it, which is incorrect
<butterypancake>like a work profile that can access a work channel, but you don't want your guix search to show work stuff unless you're using that profile
<nefix>is there any way to setup a docker container or something like that as a server for building derivations?
***daviid is now known as Guest52359
***Guest52359 is now known as daviid
<roptat>I can't open the anthy preferences from ibus-setup
<roptat>and when I run the anthy preferences directly from the store, I get org.freedesktop.IBus.Config.SetValue: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._dconf_5ferror.Code2: The operation attempted to modify one or more non-writable keys
<roptat>from strace, it looks in the store path of ibus instead of ibus-anthy
<NieDzejkob>nefix: it shouldn't be too hard to offload to a containerized build machine, but I am not aware of anyone doing so. Maybe you should ask on help-guix@