IRC channel logs


back to list of logs

***lukedashjr is now known as luke-jr
<raghavgururajan>Hello Guix1
<raghavgururajan>Which package provides gcov (GNU gcov)?
<raghavgururajan>Found it! gcc-toolchain
<lispmacs>what do I do if I need a --pure environment, but need to pass in all my x11 display environment?
<xelxebar>lispmacs: Should be enough to set DISPLAY and XAUTHORITY.
<lispmacs>xelxebar: ok, thx
<xelxebar>lispmacs: What are you trying to do, though? Your question prompted me to notice that DISPLAY is already set in --pure environments. You may not even need XAUTHORITY
<brown121407>Hi Guix! Is there any way to get appimages to work on a Guix System? Trying Krita gives me "bash: ./krita-4.3.0-x86_64.appimage: No such file or directory"
<fps>brown121407: you probably need to use patchelf to fix some rpaths in the executable, etc...
<fps>brown121407: nixos has a notion of fhs-environments which basically provide an environment with paths that meet the fhs standard. maybe there's such a thing for guix as well. might be simpler than using patchelf
***nikita_ is now known as nikita`
***apteryx_ is now known as apteryx
<greenrd>I am trying to fix
<greenrd>I am getting the error ice-9/eval.scm:293:34: error: serialize-local-file: unbound variable
<greenrd>it suggests I may have forgotten a `use-modules' form, but services/auditd.scm already contains #:use-module (guix gexp)
<greenrd>which I believe contains local-file
<greenrd>I don't know what this "serialize-local-file" thing is
<greenrd>maybe I am referencing the config that contains a local-file wrongly
<greenrd>brown121407: I don't know about appimages, but flatpak works out of the box (if you pass the --user option on the command line). There is a flatpak for krita on flathub.
<greenrd>brown121407: but there is also a krita package in guix. Any reason why you are not using that? Or you were just testing out a random appimage?
<brown121407>greenrd: I was just curious about appimages, that's it. If I'm going to use krita it'll probably be from guix. Thanks for the tip on flatpak
***jonsger1 is now known as jonsger
<greenrd>my config that contains a local-file is called configdir
<greenrd>I was hoping to be able to reference the path of the local-file in the store by using #$ similarly to how #$ when given a package, seems to yield the path of that package in the store
<mbakke>greenrd: local-file copies a file into the store and returns the store item
<mbakke>if you upload the code maybe someone is able to spot the error :)
<mbakke>btw, we seem to be missing a system test for auditd, that would probably make testing easier
<greenrd>this is the file that produces the error:
<mbakke>greenrd: to use a directory with local-file you need '#:recursive? #t'
<greenrd>gnu/services/auditd.scm:34:0: error: (define-configuration auditd-configuration (audit (package audit) "Audit package.") (configdir (local-file "aux-files/auditd" #:recursive? #t) "Directory containing config file for audit package and optionally audit rules to instantiate on startup.")): source expression failed to match any pattern
<kmicu>alextee[m]: I assure you I will pay for your version and not NieDzejkob’s because the whole point is to support the original devs. 😺
<mbakke>sneek: later tell greenrd I'm not sure if define-configuration is supposed to be used like that, you'll probably have an easier time by making an <auditd-configuration> record type
<sneek>Will do.
<alextee[m]>kmicu: thanks! XD
<kmicu>alextee[m]: Protecting your trademark is important when we want to avoid someone trying out ZRythm from unofficial sources and then yellin ‘ZRythm is completely broken, avoid! what a garbage' only because some creative distro maintainer used a wrong dependency version.
<alextee[m]>(it's broken either way) but yeah it helps with things like that
*kmicu is still baffled when libre folks are negative to protecting a good name of something.
<pinoaffe>hi guix! I'd like to build some stuff for android on guix, am I correct in assuming the easiest route towards that would be packaging maven-android-plugin? or is there already some build system on guix that can target android?
<guixer>Hi there. I am trying to build a newer version of the package afew. I used guix import and the original afew definition from mail.scm to create a package. Now when I try to build it it says: unbound variable for python-dkimpy. I added dkimpy to propagated-inputs. Do I need to create a seperate package for python-dkimpy and further dependencies or c
<guixer>an they be created on the fly by the the python build system?
***dongcarl9 is now known as dongcarl
***stefanc_diff_ is now known as stefanc_diff
<nckx>Mornin' Guixers.
<nckx>Oh, and Guixer. Re: dkimpy: The former. Nothing is created on the fly.
<nckx>blackbeard[m]: Very well, thank you 🙂
<guixer>nckx: So I need to make sure all dependencies are satisfied by creating packages if necessary?
<nckx>guixer: Hint: check out ‘guix import pypi -r dkimpy’ (the -r is for recursive).
<nckx>I think it only works ‘within’ importers though, so pypi will only suggest other pypi packages etc. Not sure.
<guixer>nkcx: Thanks for the hint with '-r'. Looks good so far, it found at least one unavailable dependency.
<efraim>I found a copy of python-dkimpy
<efraim>most of the packages in that module can probably be bumped in versions but it should help
<nckx>Heh, ‘found’ 🙂
<guixer>Another question. When I create a package based on the output of 'guix import' what do I need to add in the preamble part to make it compatible to install it via channel? I like to create a package and then like to do guix install packagename. What I don't understand how to make the packages available and how to solve naming conflicts like afew v1.
<guixer>2.x vs afew v3.0.0
<guixer>efraim: Thanks for the link. I can probably make use of it.
<nckx>guixer: A channel file would look just like a gnu/packages/foo.scm file: a licence header, module imports, then one or more package definitions.
<efraim>I normally do 'define-public foo-version` and leave the name as foo. then in a package I can refer to it as ("foo" ,foo-version) and 'guix install foo@version'
<nckx>guixer: As for versioning, just use the same technique that Guix proper uses and that I think efraim describes.
<nckx>(define-public afew-3 (package (name "afew") …))
<efraim>yeah, main package is foo, other ones are foo/fixed for grafts or foo-version for a different version
<nckx>There are no conflicts unless you create them (and even if two channels wouldn't play well together, Guile has facilities to disambiguate. Not sure about the CLI).
<nckx>efraim: Why not submit Mailman?
<efraim>I think it wasn't ready yet
<efraim>Although I suppose worst case scenario it gets tweaked later while writing a service
<efraim>ok, you've convinced me :)
<nckx>Thank you!
<guixer>nckx: For a channel specification would I need to add '(channel (name my-packages) (url "file:///home/user/.channels/my-packages/"))' and put packagebundle{1,2,3}.scm to the my-packages folder in order to install them via guix install?
<greenrd>Now I'm getting error: audit: invalid field specifier
<sneek>Welcome back greenrd, you have 1 message!
<sneek>greenrd, mbakke says: I'm not sure if define-configuration is supposed to be used like that, you'll probably have an easier time by making an <auditd-configuration> record type
<greenrd>yup, I read that message in the irc log, now I'm trying to do that
<nckx>guixer: I think that would work (don't forget to quote the name symbol). My channels mimic the upstream directory structure (i.e. <channel.git>/nckx/packages/gnuzilla.scm), but I don't think it's mandatory. You'd have to (use-modules (packagebundle1)) which isn't very descriptive.
<nckx>You'll have to ‘guix pull --disable-authentication’ until you add keys & set up authorisation, and ‘--allow-downgrades’ if you rebase.
<nckx>Channels have become a bit complex to use.
<NieDzejkob>roptat: now java-kafka-clients failed on CI. One of the tests in org.apache.kafka.common.memory.GarbageCollectedMemoryPoolTest fails, but I can't reproduce it on my machine.
<mbakke>NieDzejkob: it only seems to happen on huge-memory systems, see
<mbakke>greenrd: the default in the record type should be just (default audit)
<efraim>I try to keep genenetwork's organized, so python packages in python.scm. for me I'll add python packages in whatever file needed them added
<raghavgururajan>Hello Guix!
<raghavgururajan>error: gettext infrastructure mismatch: using a from gettext version 0.19 but the autoconf macros are from gettext version 0.20
<raghavgururajan>How should I resolve this?
<raghavgururajan>If anyone knows any solution for this, please leave me message via sneek.
*raghavgururajan --> zzZ
<NieDzejkob>sneek: later tell raghavgururajan: you could try regenerating the autotools files, cf. the bootstrap phase
<sneek>Will do.
<NieDzejkob>How do I resolve this? guix git: error: could not authenticate commit 3f17586269d2984bc592a9bd225fb89f4d9742d8: key #vu8(232 42 192 38 149 214 255 2 67 202 30 92 246 197 45 209 186 39 203 135) is missing
<NieDzejkob>I have confirmed that the #vu8 is the fingerprint that's present in .guix-authorizations
<mbakke>NieDzejkob: update your keyring branch
<guixer>nckx: Thanks for the info about the channels. I wrote it down and will get into it later :)
<efraim>I checked quickly, not all the mailman packages build anymore, I'll have to fix that latee
<NieDzejkob>mbakke: Thanks! Maybe we should add a note to the error message that explains this?
<nckx>Makes sense for ‘guix git’.
<chrislck>Is there a version of "guix pills" similar to "nix pills"
<nckx>I know someone used the name ‘Guix pills’ a while back but it never got beyond a very basic introduction (too basic if you'd even heard of Nix pills).
<nckx>Ah, not searching for ‘gix pills’ helps 😒
<nckx>Interesting that Nix has since incorporated Luca's posts into their official docs. Wonder when that happened.
<chrislck>nix has much better tutorials imho
<chrislck>also you seem to be named after it :)
<nckx>No h needed.
<nckx>We're named after the same pun 🙂
<nckx>chrislck: For straight tutorials there's the Guix cookbook. It's small and contributions are very welcome.
<NieDzejkob>Hmm, looks like we'll have to fix our ld-wrapper such that it handles utf-8 filenames even if LC_ALL=C
<blackbeard[m]>nckx: wonderful 🙂
<greenrd>I attempted to simulate a guix pull as described at
<greenrd>However, I get guix pull: error: Git error: cannot locate remote-tracking branch 'origin/keyring'
<greenrd>Yet the remote branch does exist: $ git branch -r|grep keyring
<mfg>hi, so the currently active udev rules are in `herd rules udev`, that is rules added in an environment should also be in that directory?
<greenrd> origin/keyring
<nckx>greenrd: Create a local tracking branch, git checkout origin/keyring.
<pkill9>is there a way to get the list of available build systems via guile?
<mfg>sry, didn't know that herd restart udev crashes the system ^^
<nckx>I wondered what kind of experimentation was going on.
<nckx>mfg: No, udev is a system service, users can't influence it by starting random guix environments.
<nckx>That'd be bad.
<NieDzejkob>pkill9: you could try to find a way to list the modules under (guix build-system)
<mfg>nckx: hm i see but how does udev know about rules some packaegs might add?
<mfg>or is it necessary to add those rules to the system definition?
<mfg>but that could get annoying :D
<nckx>Basically, yes. Through udev-rules-service. It's similar (in spirit) to how rando packages can't make things setuid, only the administrator can.
<nckx>See for example sane-service-type. All it does is install the udev rules. (And required user accounts, fine.)
<mfg>So that means that this doesn't have influence? (just an example i don't do anyting with that package)
<nckx>mfg: It has the important task of installing the udev rules (sane-service-type won't work without them) but no, it doesn't magically load them, the admin must do so through sane-service-type. Although in practice I think it's part of %desktop-services.
<mfg>Ahh, that makes sense now, thank you, i totally missed the service :D
<nckx>I understand how this could seem like annoying manual work, but anything else would likely be a straight-to-root security hole.
<mfg>now that i know that i can services for it, it's okay :D i just didn't know that this is how it's done
***terpri__ is now known as terpri
<dustyweb>janneke: you have a pinebook pro working with guix...???
<dustyweb>how is it?
<dustyweb>we are talking about them in #fossandcrafts and so I searched my email for "guix pinebook" and saw your patch
<pkill9>I started working on a script to generate guix packages, I'm liking Guile scripting so far
<blackbeard[m]>pkill9: looking good
<NieDzejkob>(you're aware of guix import, right?)
<pkill9>although i wasn't aware of the gnu importer
<pkill9>do you give it a URL?
<dftxbs3e>davidl, hey there! if you want GNU Guix on your machine just ping me, it already works, just not upstream
<pkill9>I want mine to do more than most of the importers, like extrapolate the build system from the presence of files like for python build system, cmake for cmake, etc
<pkill9>is it possible to take a guix profile, and graft all the software existing in it?
***sputny1 is now known as sputny
<lle-bout>NieDzejkob: I tried making GNU Guix the default on my new laptop but the lack of good out of the box experience made me gave up, back on Fedora - I hope to help improve that somehow!
<lle-bout>NieDzejkob: btw I was PotentialUser-30
<jonsger>lle-bout: what was not working out of the box?
<kmicu>wifi xD
<lle-bout>jonsger: touchpad options not working and unclear how to solve primarily
<lle-bout>gnome somehow slow when my machine is more than capable
<lle-bout>kmicu: wifi wasnt the issue
*kmicu still bets on lack of drivers in kernel Libre-linux—for touchpad and for gfx hence slow Mutter in GNOME.
<lle-bout>kmicu: I wasnt running linux-libre so that can't be the issue
<lle-bout>touchpad problems is an issue with xorg and libinput but it's unclear how to fix it
<lle-bout>libinput comes to replace many other older packages that provided support for specific input devices and named accordingly
<lle-bout>and it seems that GNU Guix still uses these older packages in the GNOME configuration created by the installer
<lle-bout>I couldnt select any touchpad configuration options in GNOME due to it
<lle-bout>like tap-to-click, etc..
<jonsger>lle-bout: did you filed a bug?
<lle-bout>I tried through dconf but it simply had no effect
<lle-bout>jonsger: I don't know what the issue is unfortunately
<kmicu>dmesg and Xorg log would clear things up
<lle-bout>I need to work on other things right now, don't have the time to fiddle with GNU Guix to eventually have it work 2 weeks later
<kmicu>(though if that’s from vanilla Linux then there’s no point anyway)
*jonsger knows that feeling. But I'm happy that I got Guix working in an acceptable state as daily driver :)
<lle-bout>kmicu: touchpad drivers are free
<jackhill>I would like to get GDM working with Wayland in Guix, but I'm stuck at "WARNING: Application 'org.gnome.Shell.desktop' killed by signal 5". Interestingly enough, I can launch a wayland GNOME session from a tty.
<kmicu>Drivers ≠ firmware.
<lle-bout>kmicu: there's no firmware for touchpad
<jackhill>I can file a bug later one I stare at it a little more. Unless someone here knows :)
<lle-bout>jackhill: there may be a story with wayland in GNOME being integrated with systemd and because GNU Guix uses shepherd there's some work to do to support non-systemd Wayland
<lle-bout>jonsger: it will have to be on top of Fedora and in VMs for now for me! >:s
<jackhill>lle-bout: interesting. I do wish how all the parts are supposed to go together was better documented. GDM is trying to start the greeter in a wayland session, but ghe shell dies with the mysterious error.
<jackhill>I guess I should look at how it works on another non-systemd distro. I guess my options are, Gentoo and ???
<lle-bout>SIGTRAP weird
<jackhill>very. One theory is that xorg-server-xwayland is crashing and gnome-shell has setup a trap for that.
<jackhill>lle-bout: thanks for the link
<jackhill>the other theory is that it has to do with out XDG_DATA_DIR length
<nckx>efraim: Super cool idea (the vidstream).
<nobodynogroup>so, sorry for this noob questions, but i am trying to do guix system reconfigure (for the first time) and e2fsprogs is a failing a test m_hugefile. I used -K and have a build that works now by skipping the test (nix irc logs have other people doing it). but now... is there a way to use this to build my system? or a way to locally add a hook to delete the m_hugefile tests when building e2fsprogs? I'm a little lost
<NieDzejkob>nobodynogroup: did you have substitutes enabled? guix should be able to download a prebuilt e2fsprogs from CI
<nobodynogroup>i am on armv7, some things were substituted so i believe they are on but i will make sure
<nobodynogroup>hmmm yeah its in aarch64, which reminds me that i need to figure out why its using 32 bit instead of 64. thanks
<NieDzejkob>guix weather --system=armhf-linux e2fsprogs tells me substitutes are available. What does 'type guix' say?
<NieDzejkob>(same for aarch64, fwiw)