***lukedashjr is now known as luke-jr
<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. <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 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>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 <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 <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>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>most of the packages in that module can probably be bumped in versions but it should help <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>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>Although I suppose worst case scenario it gets tweaked later while writing a service <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>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>error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.19 but the autoconf macros are from gettext version 0.20 <raghavgururajan>If anyone knows any solution for this, please leave me message via sneek. <NieDzejkob>sneek: later tell raghavgururajan: you could try regenerating the autotools files, cf. the bootstrap phase <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>Interesting that Nix has since incorporated Luca's posts into their official docs. Wonder when that happened. <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. <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? <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. <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.) <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>we are talking about them in #fossandcrafts and so I searched my email for "guix pinebook" and saw your patch <pkill9>although i wasn't aware of the gnu importer <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 setup.py 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! <jonsger>lle-bout: what was not working out of the box? <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 *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>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 :) <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. <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 ??? <jackhill>very. One theory is that xorg-server-xwayland is crashing and gnome-shell has setup a trap for that. <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?