<nckx>pkill9: Look at fold-packages & friends in gnu/packages.scm. <leoprikler>the straightforward answer would probably be (fold-packages cons '()) <fnstudio>(guix-daemon.service is, instead, so i don't think it's a problem with my system but rather a small glitch in the docs?) <fnstudio>i do see a guix-publish.service though, instead of gnu-store.mount <leoprikler>gnu-store.mount is a rather new addition, you can check it out from git <leoprikler>(although there isn't really anything wrong if you don't have it) <fnstudio>leoprikler: i see, thanks, cool - so i can just skip that bit? i'll just copy over the guix-daemon.service then <terpri_>dustyweb, offtopic question, but do you have some automated tool to crosspost between mastodon and twitter, or do you just do it manually? <fnstudio>how about the other service file that i see in my tar? the guix-publish.service <terpri_>i've been looking for an activitypub/proprietary-services bridge to make it easier to extricate myself from proprietary social networking sites <terpri_>(someone told me "look at actix" but that looks like...just a rust web framework, though maybe it has a good activitypub module or something) <terpri_>maybe i'll just write one myself, it can't be that hard <fnstudio>leoprikler: thanks, i'll skip it for now then <Noclip>Why does guix not support openjdk 8? I think it's still LTS and widely used. <nckx>guix show icedtea, add 5. <nckx>OpenJDK <= 8 wasn't completely free software. <Noclip>(I do not really know what icedtea is except that it provides java somehow.) <Noclip>OpenJDK on the other side tells with it's name what it is xd <nckx>No, add 5 to the version: icedtea@3 → frees openjdk@8. <nckx>icedtea = Sun's ‘open’jdk - proprietary garbage + free replacement. Hence not named openjdk. I agree it's confusing, but at least it's in the past. <Noclip>After playing around a lot with guix in the last days there is especially one thing that I really hate about Guix more and more: <Noclip>It's inefficient and insane hungry way of using disk space. <Noclip>Before I used Guix I thought flatpak would be exstremely bloated but when I compare disk usage now flatpak seems to be kind of "minimalistic" compared to Guix. <Noclip>That's especially sad as before trying Guix I thought of it as a lightweight package manager that could just be added to any linux distro (here I'm really only referring to the kernel) and then be used to install every kind of bleeding edge software on that system while using less disk space as flatpak but more as debian. <Noclip>However it turns out that this concept completely doesn't work on machines with a small amount of available disk space. ☹️ <pkill9>you just need to delete old generations and garbage collect <pkill9>one thing I think would be neat to create, is make it so when upgrading a profile, have the upgraded packages graft the dependencies of the previous profile generation's package if those dependencies are the same version <Noclip>Just to make this clear: I don't want to blame Guix or any of it's devs for that! You can't have everything in life and reproduceable, functional package management seems to be just some type of double edge sword. <nckx>I agree that Guix isn't suitable for ’smaller’ storage, at least for interactive use. You can use it to build for & deploy to such devices. I wouldn't call Guix bloated (I do call Flatpak that), but it's not ‘lightweight’. Whoever gave you that idea should give you your money back. <Noclip>I think I gave myself that idea xD <nckx>Noclip: Yeah, it's mostly a side effect of the functional strictness. ‘This is basically that, just us—’ Guix: ‘Nope.’ <PotentialUser-81>I just installed guix, I'm trying to get my wireless working but it seems like free firmware doesn't support my Qualcomm Atheros QCA9377, so how can I get the nonfree version? <Noclip>I had been told that it uses more disk space than traditional package managers but I did expect it to be that much more. <pkill9>Noclip: is the extra space usage after upgrading your profiles? <blackbeard[m]>Noclip: how much more is it? Are you using the distribution or the package manager? <nckx>Someone came into here asking how to make Guix build everything using their system's LLVM and libraries because ‘they already had everything’. That didn't go well. <blackbeard[m]>I think the distribution doesn't use that much more space than my parabola <pkill9>guix as a package manager is more like a distribution with the software exposed to the system <Noclip>PotentialUser-81: You won't get it from gnu. However maybe the keyword "nonguix" might help you ... <pkill9>could guix ever become 'ightweight'? <Noclip>nckx: That sounds efficient but has nothing todo with functional package management. <brettgilio>nckx: guix size emacs-telegs shows the whole closure is 800+ MB. Any good tips on reducing closure sizes without compromising functionality? <nckx>I'm not saying there's no room for improvement or that Guix can't use a diet, but: contrast ‘guix size emacs’ and ‘guix size emacs-telega’. <nckx>You'll always have emacs installed to use it, and then emacs-telega adds ‘only’ ~260 MiB. <brettgilio>Mind if I use that "guix on a diet" trope for my next blog post title? <nckx>That always trips me up. <Noclip>nckx: Even if you would make that possible it would most likely end in a completely unstable system. (At least when it comes to the packeges installed with guix.) *brettgilio isn't sure if you're kidding or not haha <nckx>Noclip: Absolutely. And you'd have patched Guix into a useless crying heap just to get there. <nckx>brettgilio: I mean ‘go ahead’ 😉 <Noclip>pkill9blackbeard: Yesterday I installed "ghc-pandoc". It added ~3G to my store and most of that can't be collected by gc. <nckx>‘A variable and everything it refers to, and everything they refer to, etc., until you stop adding stuff’ (i.e. you have a closed world were nothing points outside of it). <brettgilio>pkill9: basically a fancy word for everything in a scope <nckx>I assume you've seen a more formal definition so forgive my deliberately informal one. <brettgilio>So the closure for a package would be everything it may possibly touch <brettgilio>In the sense I was using it above, the closure package size would be what `guix size` returns on the package name <nckx>brettgilio: Anyway, once you've been reassured that -telega is a mere 260 mebibytes, you can diff ‘guix size emacs’ and ‘guix size emacs-telega’ to see what's unique to telega, and you're in a better position to know what could go than I am. <nckx>brettgilio: Pff, the ‘correct’ and ‘accurate’ sense perhaps. <nckx>An intuitive approach has its merits. 😶 <Noclip>"guix as a package manager is more like a distribution with the software exposed to the system" <Noclip>pkill9 That's the problem: Installing guix on another distro is like adding a completely new operating system to it. But not just like a little chroot system. When looking at the disk usage it's more like adding another desktop linux to your system even if you just installed a few packages with guix. <terpri_>dustyweb, ah well, i suppose copy&paste works well enough :) <terpri_>dustyweb, any recommendations for good activitypub client libraries? (ideally scheme or lisp, but i'm not picky) pubstrate perhaps? <pkill9>Noclip: even basic command-line utilities? <pkill9>if you install any desktop packages it wouldn't surprise me really <pkill9>some packages have KDE libraries as a dependency, which is a whole framework <nckx>Noclip: That's a problem if you're unaware of it (as said person was — they thought Guix would link with their OS because ‘they can live together’ on the home page), or it doesn't solve any problems that you have. But it does solve many real problems for many. For those, storage space is a cheap price to pay for time/sleep/peace of mind. <nckx>But everything's a trade-off, and ‘iz big’ is never positive of course. <Noclip>pkill9blackbeard: With only those packages: "glibc-utf8-locales hello neovim glances guile ghc-pandoc graphviz ungoogled-chromium" my store has and absolute minimal size of 5.9G. *nckx .oO ‘only’, ‘ungoogled-chromium’. <nckx>(Sorry 🙂 Your point is of course valid.) <Noclip>Yea, chromium might be a bit outstanding here. <nckx>Your point would still be valid without it, if less spectacular. <pkill9>ungoogled-chromium is 1.3gb onmy system according to `guix size` <nckx>Hm. OK. Not as bad as I expected. <pkill9>ghc-pandoc is 3GB according to someone earlier in the conversation <nckx>Oh GHC is known-terrible. It's a bug but not trivial to fix, although I think Ricardo is trying. <Noclip>pkill9nckx: Pandoc is just a command line utilitie but with 2 to 3G it should be the biggest of all those packages. <Noclip>APT says installing pandoc would add 53M to my system ... <pkill9>i think pandoc is a special case though <Noclip>It doesn't even want to pull ghc into the boat. <pkill9>since there is work on splitting it up or something <Noclip>pkill9: According to me I think. <lfam>I would check the mailing list archives. This has been discussed before and it will save you time <Noclip>(Just run "guix size ghc-pandoc") <lfam>Rather than rediscovering the root of the problem <pkill9>i'm not trying to undermine your point, but rather i'm being optimistic that the problem isn't as big as it seems <wdkrnls>Hello everyone, I've built up 76 R packages in my own custom channel and I would like to push for these up to go into guix proper instead. <pkill9>it's a valid concern that guix uses up a tonne of space, but there's work on the size of that particular package, and all the extra space guix uses can be alleviated in ways <nckx>There really still are some low-hanging wins remaining in this area for anyone motivated enough to dive in. <wdkrnls>My problem is that I'm really not great at git. <pkill9>for example my idea of reusing previously built dependecies and grafting them onto package upgraded <wdkrnls>I struggled to submit a patch for a single package, much less 76. Can anyone suggest any tips? <nckx>wdkrnls: Do you have git:send-email installed? <lfam>wdkrnls: With the right setup, it's just as easy to send 76 patches. Do you remember what you struggled with before? <nckx>wdkrnls: Is your main worry the sending, or getting 76 packages from your channel into your local guix first? <wdkrnls>I managed to get a couple packages included in guix a while a go such as herbstluftwm. Thankfully, Ludo is very good natured and patient :) <wdkrnls>I am well aware, having got so much help from this channel :D <lfam>As a reviewer, I would say that the easiest way to handle 76 patches is to cat them together into a single file <lfam>If your patches are in Git, you can do something like `git format-patch origin/master --stdout > allmypatches.patch` and then attach that to an email <lfam>I have to go AFK for a bit but I'll be back in a few hours <wdkrnls>I have never dealt with multiple outputs from packages before. Does git:send-email install with git? <lfam>No, you would do `guix install git:send-email` <Noclip>A hour ago I wanted to pack a pandoc tarball (just for experimenting). The process failed very fast as my /tmp directory is a 2G ram disk and 3G pandoc doesn't fit in there ... <lfam>By default, Guix adds ":out", under the hood. So if you do `guix install git` it actually does `guix install git:out` <leoprikler>which is sufficient for sending email, but don't expect it to handle commit etc. <nckx>wdkrnls: caveat: you need to install git:send-email in the same profile as your git command (system vs. user) or it won't work. <Noclip>I think I will just use a smaller package for it now. <leoprikler>I personally use ad-hoc environments for send-email and it has always worked for me :( <lfam>Personally I wouldn't bother with git-send-email if you aren't a Git and email wizard <lfam>I would use `git format-patch` and then just attach the files to an email by hand <lfam>It's just not a trivial setup <wdkrnls>lfam: that sounds like a good first thing to try. thanks <wdkrnls>nckx: I need to get these packages from my channel to guix git first. <nckx>I— hm. I found git send-email by far the most noob-friendly solution when I was an actual noob, but I can see lfam's point too. Everyone's different. <wdkrnls>I can definitely use magit to commit them each one at a time. <wdkrnls>I'm not sure what to do with all the guix dependencies, though. Should I just include all of those in the first commit? Do I make one commit, or several? <wdkrnls>* goes back and reads the info manual on contributing <guixy>ungoogled-chromium takes a long time to build and is updated so often. Is there a way to make it build faster? <guixy>It's preventing me from updating my other packages. And it will take a day to install it to its own profile. <wdkrnls>guixy: I was running `git show master@{yesterday} | cat | grep ^commit | awk '{ print $2 }'` to find the last commit from the day before and hoping the build farm had already built that. Then I ran `guix pull --comit=$YESTERDAY`. <wdkrnls>(where git was run from a fresh guix git repository) <wdkrnls>However, I just tried to use it and guix was complaining it might be a downgrade attack. So, I'm not sure this is the best idea. I could very well have made a mistake. <pkill9>guixy: you can use --do-not-upgrade to prevent guix upgrading that package <Noclip>guixy: Are you building everything from source? <guixy>I think I know why ungoogled-chromium needs to be re-built so often. I keep rebasing my channel so I can keep track of the patches I sent upstream and see what remains. <guixy>One of the packages I changed is ffmpeg, which is one of ungoogled-chromium's dependencies. <guixy>If I switch to using the default channel, I might have a substitute <guixy>But then I won't have access to all the changes I made to guix that make it easier on me. <guixy>I already sent those patches, so I could remove them from my channel. <Noclip>So you maintain your own chromium version? <guixy>No, I keep my channel up-to-date with the main guix channel. <Noclip>(Or own versions of it's dependencies.) <guixy>Speaking of those patches, ffmpeg specifies no inputs or propagated-inputs, but it installs gcc. <guixy>That increases its size by a lot. <guixy>My patches adding gme support to ffmpeg and vlc won't be accepted because libgme installs gcc. <guixy>Anyone know how to go about fixing this? <guixy>I would think it would be just like any other cmake-build-system package with no inputs. <wdkrnls>pkill9: I find the documentation for --do-not-upgrade kind of confusing. I tried guix package --upgrade . --do-not-upgrade webkitgtk but the first thing this does is start compiling webkitgtk. <pkill9>you may not to do --do-not-upgrade=webkitgtk instead <wdkrnls>Hmm... this happens either way: = or no =. <pkill9>oh, it won't affect dependencies <pkill9>you'll need to find out which package has webkitgtk as a dependency and avoid upgrading that <pkill9>try opening <guix profile>/manifest and search for 'webkitgtk', and see which package it's under <guixy>Or guix refresh --list-dependent webkitgtk <guixy>and check against your profile <wdkrnls>I didnn't see that info in the manifest file and the guix refresh command suggests there are a lot of packages which depend on it. <guixy>dependencies=`guix refresh --list-dependent webkitgtk`; for package in `guix package -I | cut -f1`; do echo $dependencies | grep $package; done <guixy>dependencies=$(guix refresh --list-dependent webkitgtk); for package in $(guix package -I | cut -f1,2 --output-delimiter="@"); do echo $dependencies | grep $package; done <guixy>That's the best I can do I think. egrep doesn't hilight matches. <guixy>Well, I fixed my ungoogled-chromium problem. <guixy>It would be nice if guix upgrade had a --do-not-upgrade option. IINM it's exclusive to guix package -u *Noclip just noticed that his binarys don't run on android because he forgot about cross-compiling ... <wdkrnls>For some reason, my channel stops being recognized by guix on my desktop after I ~guix pull~. It shows up on the laptop just fine. <wdkrnls>Frustratingly, webkitgtk doesn't want to build there. I was hoping it is an issue with my laptop being underpowered. However, I can't upgrade without my personal channel working. <wdkrnls>it was recognized as part of guix pull... but it's clear all the packages are gone when I start running guix upgrade. <Noclip>How do I specify a --target triplet for android (armv7) cross compiling? Or is that not possible? <lle-bout>hello! ci.guix.gnu.org is giving 502 bad gateway for me! <pkill9>much nicer than dealing with bash <pkill9>there's so much I could do to make that script less of a monstrosity <wdkrnls>Does Guix allow un-authenticated channels anymore? <wdkrnls>Really confused why my ~/.config/guix/channels.scm file is being ignored. <wdkrnls>It'se not very clear how to roll-back your default profile. It's very clear how to roll-back the system profile. <apteryx>wdkrnls: guix package --roll-back to roll-back your main user profile <wdkrnls>apteryx: thanks, that did roll-back. However, I still cannot `guix describe`. <wdkrnls>guix describe: error: failed to determine origin <wdkrnls>I think I am getting bitten by all these new security and authentication features. <apteryx>was thix guix installed using 'guix pull' ? <wdkrnls>You mean at the system level? I haven't upgraded the system level yet. <apteryx>like, if you had done ./pre-inst-env guix pull in a Guix checkout, I think it would lead to this message. <wdkrnls>I did guix pull --channels=my-channels.scm <wdkrnls>No. It was definitely done with guix pull if that's what you mean. <wdkrnls>My systems are broken in two different ways: my laptop can't upgrade because it can't build webkit and my desktop can't upgrade because it can't detect my channels. <wdkrnls>I was hoping to upgrade on my desktop and try building webkit from there. <Noclip>"$ guix pack -R --target=arm-linux-gnueabihf guile" <Noclip>This doesn't work. As soon as I remove the "-R" it does work however. <efraim>NieDzejkob: I ran into the same issue on core-updates on aarch64, glibc-2.31:debug tries to refer to glibc-bootstrap. so it wasn't related to bumping that package <brettgilio>Noclip: what does the R flag do? I don't see it listed <brettgilio>Well what does it do when you do pass that flag? <Noclip>It instantly aborts the operation and says the feature wouldn't have been implemented yet and I should contact the developers. <efraim>NieDzejkob: it's glibc-intermediate, I'm going to try it with the debug output removed <apteryx>neat! I got Ubuntu 20.04 installed in GNOME Boxes with Jami on top of my Guix System, and I could passthrough a USB webcam. I'll be using this Jami as a 'standard' to compare with when I find issues in our Jami package. <apteryx>there was one permission hack required for the camera, as its USB device is not part of any group or my user, I had to give it the 'users' group, like: 'sudo chown root:users /dev/bus/usb/001/039', so GNOME Boxes was able configure it in passthrough. Could be fancied with a udev rule. <Noclip>Does relocatable only not work with cross compiling (--target) or does it in general not work for arm? ***apteryx_ is now known as apteryx
<brettgilio>One day people will realize we can't help if we can't see what you've done <nckx>brettgilio: Thanks for the CI heads up. Prodded. <nefix>sleeping is kinda important xD <nckx>brettgilio: It's 10 o'clock in the morning, friend. <nckx>pkill9: You're actually one of the reasons I gave it another try. Bookmarked! <nckx>You just want me gone so you can revert s'more patches. <brettgilio>nckx: Ill revert them til the moon turns black. Patches are meant to be reverted <NieDzejkob>efraim: but doesn't glibc-intermediate have the -intermediate in the name? I'd expect the problematic store path to be called ...-glibc-intermediate-2.31-debug <NieDzejkob>(also, glibc-intermediate doesn't specify any #:allowed-inputs) <nckx>nefix: Depends on what you want to use them for. Guix environments are better in some ways (more generic & composable); I'm sure venvs (being the privileged ‘native‘ solution) have other advantages. Is this about PYTHONPATH? I don't think they allow mixing 2/3 either. I'm still not a Python dev though. <efraim>NieDzejkob: A lot of commencement.scm has lots of inheritance, the name or allowed/disallowed -inputs might be elsewhere <nefix>nckx: yeah, you can have two different guix environments and have both python3 and python2 with the dependencies and both work <nefix>the only missing thing is how can I make the environments "persistent" or something like that <nefix>so I can have ~/.config/guix/python/python3 and ~/.config/guix/python/python2 and set them as the neovim python providers <NieDzejkob>efraim: note that glibc-final:debug is pretty important, as that's what gives us libc debug symbols for stuff compiled with gcc-toolchain... ***sputny1 is now known as sputny
<efraim>that certainly creates a problem... <NieDzejkob>efraim: well, make-gcc-toolchain uses (libc (if libc libc glibc-final)), so... <efraim>hello built, i'll check gcc-toolchain and see how that goes <efraim>guix build: error: reference to invalid output 'debug' of derivation '/gnu/store/6kgya4xqmky2sxh3w7zaf640zf519j3c-glibc-2.31.drv' <efraim>when I put back the debug reference in glibc-final it complains about the missing debug reference from glibc-intermediate <nefix>it seems to be working now!! guix profiles were the solution! <nefix>the plugin itself is not though :( <nefix>but nvim's checkhealth states that both python3 and python2 providers are healthy :D <NieDzejkob>I don't see anything using glibc-intermediate:debug <efraim>when I make glibc-intermediate only have out and static outputs and I try to build gcc-toolchain I get the error above <efraim>building the debug output I get the error about a disallowed reference, skipping it I get an error about the debug output missing <NieDzejkob>"guix build -e '(@@ (gnu packages commencement) glibc-final-with-bootstrap-bash)'" has glibc-intermediate in the path, why are you getting -glibc when it refers to intermediate? ***rEnr3n1 is now known as rEnr3n
<NieDzejkob>hmm, this clearly works on master, maybe we should bisect this? <efraim>with just glibc-intermediate changed I get this while building glibc-final: derivation contains an illegal reference specifier `debug' <efraim>the hard part is I'm sure it only affects arm/aarch64 machines <nefix>I'm stupid. I forgot to add a folder in the deoplete.nvim package definition, so it wasn't finding the python code required so it failed so I thought it was the Python thing but in reality it was all my fault at the end :( <nefix>sorry for making you waste your time like that :( <NieDzejkob>efraim: hmm, I don't see where glibc-final is referring to glibc-intermediate:debug. Is that the full error? <efraim>yeah, that one I built on x86_64 <efraim>with just glibc-final changed I had that error <efraim>on aarch64 when glibc-intermediate is changed and glibc-final isn't changed then glibc-final:debug tries to refer to glibc-bootstrap <efraim>on x86_64 with glibc-inermediate changed and glibc-final not changed then there is no issue building glibc-final:debug <NieDzejkob>efraim: hmm, could you run the (unmodified c-u) build with -K and give me access to the result somehow? <NieDzejkob>oh, substitutes for the derivations that succeed could also help, I can build glibc itself with qemu-binfmtt <efraim>NieDzejkob: ok, I'm building it now. it takes about 45 minutes on my board <efraim>I have both changes commented out, glibc-final-with-bootstrap-bash (aka glibc-intermediate) gave me a debug output without problems <efraim>glibc-final should fail, I'm building it with -K <Tirifto>Hello! I’m guessing my local copy of Guix (after running ‘guix pull’ recently) should have more up-to-date documentation than the website? <Tirifto>I’m trying to get set up for contributing a little bit, and I’ve cloned Guix with Git, but I’m not sure how to properly verify it. Running the ‘guix git authenticate’ command from the latest manual throws an error, so either my copy isn’t genuine, or that’s not what I’m supposed to do. <nckx>Tirifto: You need to checkout the ‘keyring’ branch locally. <nckx>Or update it with ‘git fetch upstream keyring:keyring’. <nckx>Where ‘upstream’ may be ‘origin’ or whatever name you use. <davidl>Why am I getting this error message when I run ./configure from the guix source tree? config.status: error: cannot find input file: `etc/indent-code.el.in' The file is there before I run ./configure <nckx>davidl: It was deliberately renamed to drop the .in in May. <nckx>Is your tree up to date, clean, and did you re./bootstrap it? <nckx>I can't find any references to indent-code.el{,.in} so I blame a stale Makefile for now 🙂 Let us know what happens. <wdkrnls>Hi everyone, I"m seeing this error with guix after upgrading: guix describe: error: failed to determine origin <wdkrnls>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version <wdkrnls>All of this is from after guix pull followed by guix upgrade. <nckx>wdkrnls: What does ‘hash guix; type guix’ say? <wdkrnls>guix is hashed (/run/current-system/profile/bin/guix) <nckx>It should be /home/wdkrnls/.config/guix/current/bin/guix, that's the ‘pulled’ guix. /run/… is the system's fallback/bootstrap guix, and will never be as new. <davidl>nckx: after running ./bootstrap before ./configure I stopped receiving the error. <nefix>hello! Is it a good idea to add propagated dependencies between vim plugins? <nckx>wdkrnls: Is ~/.config/guix/current/bin in your $PATH? <nckx>On Guix System, sourcing /etc/profile puts it there. It's very unusual that it's missing. <wdkrnls>yeah, I'm definitely running that. =/ <nckx>And you're not overriding PATH anywhere (maybe a forgotten ~/.bash_something)? <nckx>Does ‘. /etc/profile’ change it? <nckx>Hm. There's not much I can remotely do to debug what happened but now you know the problem. <nckx>nefix: It's probably the way to go. <nckx>wdkrnls: No! Definitely not. <wdkrnls>hmm... I guess I see it there already inside an if-statement. <nckx>Yeah, so unconditionally adding it at the bottom will do bad things. <wdkrnls>But I'm accessing this computer over ssh through Emacs shell. <nckx>wdkrnls: Could you open a bug for that? <nckx>I'm not a qualified emacs shell professional. <wdkrnls>Yeah, I just tried connecting via ssh through a regular terminal and the path seems to be set well enough to enable `guix describe` to work. <nckx>SSH does correctly mark the shell as interactive: see ‘echo $-’ in the SSH shell. <nckx>Does ‘echo $-’ in emacs shell also contain ‘i’? <nckx>If not, I consider this an emacs bug/misfeature. The amount of those is why I don't use emacs shell. <nckx>Why doesn't ~/.bash_profile's if clause get triggered? <wdkrnls>I do have a weird way of starting my Emacs shell which might be responsible. <wdkrnls>(let (default-directory "/ssh:wdkrnls@remote:/home/wdkrnls")) (shell "*shell<remote>*")) <wdkrnls>At some point and in some fashion I thought that was fixing my bash completion on the remote system with emacs. <c4droid>Someone have example system config for awesome and dwm desktop? <nckx>wdkrnls: That's Greek to me 😛 I'd suggest adding some echoes to your remote .bash_profile (or wherever it ends up leading you) to find out what is actually happening. <c4droid>I want to try these two desktops and then go from the desktop I'm using now. <nckx>c4droid: Not really a system.scm example, but I use (service slim-service-type) to start my ~/.xsession, which then does ‘exec dbus-launch --exit-with-session ssh-agent <wm of choice>’. <c4droid>nckx: I mean the package list, the services I'll to custom. <wdkrnls>My .bash_profile doesn't have anything really in it other than sourcing .bashrc if it exists. <Tirifto>nckx: Thanks, I could move on to a different error now! :D <wdkrnls>And bashrc only mentions /etc/profile through a conditional clause if $SSH_CLIENT is not empty (which appears to be the case). <nckx>Tirifto: great. wdkrnls: I mean add echos to .bash_profile to find out if $PATH is actually set to what it should be at the end, how it's modified, whether the ‘if’ is(n't) actually triggered, whether what ‘appears’ is actually so, etc 😉 OK, got to run, take care of each other y'all. <nckx>(or ‘set -x’ if you're lazy). <wdkrnls>that is definitely my goal. I just added it t ran it and nothing printed from my Emacs way. Lots printed from the terminal way. <wdkrnls>so, I guess this means that bash is not executing .bash_profile at all =/ <bdju>lotta icecat crashes lately. pasting text, switching tabs too fast(?!) <Tirifto>Now ‘guix git authenticate’ tells me: ‘error: commit […] not signed by an authorized key: […]’. Apparently I already have the key, although the fingerprint on it doesn’t match the one Guix prints; not sure if it’s supposed to. Am I expected to trust it more, or did something else go wrong? (Sorry if this is an elementary topic, but I never really grasped PGP management and I’m not sure how/if it ties to Guix.) <Tirifto>For what it’s worth, the on-line manual talks about fetching keys, while the local one does not. <hendursaga>Tirifto: First thought was that your local keyring isn't in sync with remote. <Tirifto>hendursaga: In that case ‘gpg --refresh-keys’ should fix it, right? <Tirifto>To where? I both cloned Guix and ran ‘guix pull’ today, so the repository and the verification instructions should be up-to-date. <hendursaga>The remote keyring branch? Sadly I'm not up on Git as much as I'd like. <Tirifto>Not sure; I ran ’git clone [repository]’ and then ‘checkout keyring’. <nckx>Tirifto: Who actually signed that commit (git show --show-signature <commit>). <nckx>‘Authorized’ refers to .guix-authorizations (not on the keyring branch). <nckx>It's a file with fingerprints of all currently authorised committers. <nckx>While the keyring branch holds the actual key files. <Tirifto>nckx: ‘Tobias Geerinckx-Rice’, alias… oh, is that you? :D <Tirifto>So is my copy of your key out-of-date? <nckx>What does gpg --list-keys nckx have to say about it? <nckx>(Note that it *will* display a revoked expired key, but there should be a valid one through 2022.) <Tirifto>Oddly: pub rsa4096 2015-05-26 [SCEA] [expire : 2027-06-25] <Tirifto>(And three other lines if you want them.) <Tirifto>ec32c8591eb111023db514800145532a1e454125 <nckx>So it should be ed25519/0x0DB0FF884F556D79 2017-07-23 [S] [expires: 2022-07-01] <nckx>I'm not sure if ‘guix git’ even uses your user's gpg keyring. This is all pretty new. But it's as good a time as any to make sure it's up to date. <nckx>Trust is not required. And I thought we didn't actually check expiration dates at all :-/ <Tirifto>The commit info lists fingerprints of the master key (clef principale) and a sub-key (sous-clef); the gpg command shows the master key which—according to it—expires in 2027. <nckx>What did your guix git authenticate (g g a from now on) look like exactly? <Tirifto>I’m not sure if Guix cares about expiration; it just says: ‘error: commit ec32c8591eb111023db514800145532a1e454125 not signed by an authorized key: F5DA 2032 4B87 3D0B 7A38 7672 0DB0 FF88 4F55 6D79’, which is the signature of the sub-key, which is also shown for the commit by ‘git show’. <Tirifto>When I run ‘guix git authenticate '9edb3f66fd807b096b48283debdcddccfea34bad' "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"’, Guix says: ‘Authenticating commits 9edb3f6 to ec32c85 (3 new commits)...’, and then: ‘guix git: error: commit ec32c8591eb111023db514800145532a1e454125 not signed by an authorized key: F5DA 2032 4B87 3D0B 7A38 7672 0DB0 FF88 4F55 6D79’. <Tirifto>For the record, I am Czech, but trying to learn French. :) <nckx>(Of course that command runs finely here, hmph. I was hoping you'd passed a bogus commit.) <nckx>And ‘git show keyring’ shows ec32c8591eb111023db514800145532a1e454125? <nckx>This is quite desperate, but: try removing ~/.cache/guix/authentication :-/ <NieDzejkob>yeah, it'd be nice to have a reproducer if this fixes the issue <nckx>I guess. They should be simple check points (commits), I don't actually expect this to solve anything. <nckx>It didn't help here either, it still succeeds. Stupid thing why won't you break. <NieDzejkob>efraim: thanks. Could you also get me the incomplete outputs in /gnu/store? <Tirifto>nckx: Sorry I forgot, but could the problem be with my local keyring being out-of-date or something? <nckx>I didn't think we used the local keyring (or called out to ‘gpg’ at all) anymore. <PotentialUser-77>HI all, I have just installed guix and created a new generation. I set the GUIX_PROFILE env variable. I'm a bit confused as to where the built binaries are <nckx>Indeed. Tirifto: Your local keyring should have no effect on ‘guix git authenticate’. <Tirifto>nckx: Okay, good, because I can’t get it to refresh my keys. >_< <nckx>PotentialUser-77: They are in /gnu/store, under each package's subdirectory, and your profile aggregates them into a single /bin (etc.) directory through symlinks. <nckx>Just setting GUIX_PROFILE doesn't do anything. If you followed instructions, didn't they say to source $GUIX_PROFILE/etc/profile or something? <nckx>Tirifto: I think I see the problem. <sneek>rovanion, you have 1 message! <sneek>rovanion, nckx says: I've moved ‘Help’ to a more prominent place. The old order didn't make sense to me. This better fits a new user's steps & is more likely to be seen. <nckx>Tirifto: I bet you still have ‘keyring’ checked out, not ‘master’. <nckx>You guix git authenticate master, not the keyring branch. <nckx>If I ‘git checkout keyring’ and don't switch back I get the same error. <Tirifto>Indeed; I didn’t realise I had to switch back. <nckx>rovanion: I later saw that Guile also uses ‘Learn’. <nckx>Tirifto: Ah :-/ Sorry about the confusion. <nckx>rovanion: I don't have a preference (maybe because I grew up in a time that people still knew & used the ‘Help’ menu in desktop (remember those?) applications). <Tirifto>nckx: No worries; the manual doesn’t mention the ‘keyring’ branch in the first place. Maybe I should file a bug report for that? <nckx>Tirifto: Assuming you're using the latest manual: yes please. <nckx>Tirifto: It's ‘documented’ under --keyring=: ‘By default the keyring is loaded from the branch named @code{keyring}.’ <nckx>But I agree that it should be part of the main section. It's crucial to the operation. <nckx>An 2-line git example would also be nice. <nckx>Tirifto: ‘git fetch upstream keyring:keyring’ should work. It did, right? <rovanion>nckx: I'm leaning towards Learn. But I think a button labeled "Manual" could be added to the "Discover" section of the frontpage right by "Videos" and "All packages". <rovanion>But its not a strong opinion, on the subject of "Learn" v.s. "Help". <PotentialUser-77>Does guix have support for any old packages? I see "postgresql" comes up with 11.6, but you can't subversion, like postgresql-9.6 <Tirifto>nckx: I didn’t run that; I read about checking out locally, so I did ‘git checkout keyring’ and it said it would track the distant branch ‘keyring’, so apparently that worked. <nefix>PotentialUser-77: you can choose which version to use: postgresql@9.4 <nckx>Guix supports different versions of the same package in the same repository (or in different channels), but they must be explicitly packaged. It won't synthesise a 9.6 for you based on the 11.6 package. <nckx>Or the 9.4 package if one exists. <nefix>There's the postgresql@9.6.16 <nckx>Then I don't understand ‘you can't subversion, like postgresql-9.6’. Because that will work then. <nckx>guix install postgresql@9.6 works here. <rovanion>That's the same thing as in Nix right? Someone has to define a package postgresql-9.6.10 in the Guix git repository for it to be available in the package manager. There's no way to just say 'give me postgres==9.6.10' and it will be built from the package definition of postgres, right? <PotentialUser-77>sorry, first day with guix. I want to see if I can use it instead of snap for some things <nefix>you could even run two different postgres versions within the same machine! <nckx>You could create an auto-inheritor that tries building the closest packaged version with different sources, and that would be a cool use of Guix, but it's outside of upstream Guix's scope. <PotentialUser-77>I first heard about it a while back when someone asked in the gitter Spacemacs channel what the license of Spacemacs was because they wanted to see if it could be included in Guix. I thought it was interesting, but now that I have a few major gripes with snap I started looking at it more closely <rovanion>I'm often a software developer by day and I sometimes dream about using Nix or Guix instead of the myriad of different language specific package managers out there. But since one has to essentially mirror the language specific package indexes it seems, to me, like a pipedream at the moment. <nckx>PotentialUser-77: Welcome! I'm sure you'll find gripes with Guix, but I hope they'll be minor. <rovanion>But, they still have other qualities which make them interesting! <PotentialUser-77>I'm trying to explain to my colleague but he's like "so like docker? portainer? etc" <Tirifto>By the way, if I wanted to discuss/suggest changes to the Icecat package, would the ‘guix-devel’ mailing list be the most appropriate place for that? <nckx>Tirifto: Probably, as the Guix package is technically a ‘preview’ even though it's maintained by an IceCat maintainer. <nefix>peanutbutterandc: I doubt that I'd be helpful, I started with Guix like 4 days ago xD <peanutbutterandc>I wish someone could help me out though. I really would like to get this working <brettgilio>I'm at the doctor right now, so I can't look. I'll try to look later <brettgilio>This will probably be the shortest doctor's visit. I had some sudden hearing loss that was reversed, and I'm here to just be like "yeah. Ears are good now. Thanks" <peanutbutterandc>nckx, Oh hey there!!!!!!!! I'm so excited to see you! You surely can help me! Yay! :) <brettgilio>nckx: I've had problems with my ears all my life. I've had a number of surgeries, especially on my right ear. The fact that my hearing isnt severely diminished right now is nothing short of my surgeon being incredible. <nckx>peanutbutterandc: Uhm. Maybe 🙂 <nckx>peanutbutterandc: That's more than I have time to read right now (still workng), will reply later. <nckx>I can fart around on IRC but not concentrate on real bugs 😉 o/ <peanutbutterandc>nckx, I see. That was supposed to be an IRC thing but then Mr. Courtes was here and he encouraged me to report it too. But it's just an issue of me not knowing how (trace-call-to-procedure) from (system vm trace) not working. <peanutbutterandc>I did (trace-call-to-procedure procedure) but none of the subsequent calls to (procedure) produced a trace <efraim>NieDzejkob: sorry, I was afk. only the debug output showed up in the store, I'm tarring it up now <peanutbutterandc>nckx, Just a request (since I don't have a bouncer): Please do reply to the bug tracker rather than here (if you have the time). That way I will surely get the update. I really want this trace thing to work and don't want to miss anything. Thank you for your help. :) (I will have to disconnect in a while since it's already time to sleep over here) *kmicu has tried to check guix log but magit+git hit 100CPU and refuse to do anything useful. <NieDzejkob>sneek: later tell civodul: the guile docs are severely lacking a simple example of how one might use traps. <peanutbutterandc>NieDzejkob, Also could you give me some pointers!? I'd be able to sleep soundly knowing how to trace my procedures properly <NieDzejkob>anyway, I have tried figuring out how traces and traps should be working, and I'm as confused as you are. possibly more <peanutbutterandc>Perhaps I should go to sleep now. Please do send an email in the bug's thread if you stumble into something, so that I won't miss it. <Tirifto>Huh. Now I notice that WebRTC is disabled in the package definition for Icedove, not Icecat… I wonder if it’s supposed to be enabled in Icecat after all? <PotentialUser-77>What are the criteria for packages? Are AGPL3 packages covered? or does it depend on their individual dependencies as well? <lfam>The packages must be free software and meet the criteria of the Free System Distribution Guidelines <nckx>PotentialUser-77: Everything must be FSDG-free, including all dependencies. <PotentialUser-77>ok, interesting, are there any options for 3rd party package definition repositories? <nckx>For example: VirtualBox is free software and could be patched to be FSDG-compliant if it isn't yet, but it can currently only be built with a non-free compiler so currently not in Guix. <nckx>PotentialUser-77: Guix supports channels, which are ‘package definition repositories’. <PotentialUser-77>at work the system we are developing on is AGPL3 but I notice that it isn't in the guix packages, but it has a ton of dependencies <nckx>Anyone can create their own channel but we ask that you don't promote ones with non-free software in Guix communication channels. <PotentialUser-77>I actually took my current job because they were developing on an AGPL3 product, so I'm surprised it isn't listed (Odoo). I can only assume that someone in the chain they have a dependency that doesn't meet the FSF standards <tissevert>I'm facing difficulties with reproducibility : I thought the state of the config.scm determined exactly the content of the output system, are there any subtleties that could make the previous wrong ? <lfam>PotentialUser-77: It's more likely that nobody has tried packaging it for Guix yet <PotentialUser-77>I'll definitely be interested in trying. I've never used Guile though, only a small amount of emacs lisp <lfam>The code you'll need to write for packaging is really simple. In many cases you can't even really call it "programming" <lfam>It's more like filling out a form <NieDzejkob>tissevert: config.scm + guix describe determines it exactly <retropikzel>On package definition, using gnu-build-system I would like to replace one of the flags of configure phase. Is this possible? If I replace whole phase the prefix goes wrong, so alternative could be getting the prefix from somewhere. <NieDzejkob>it's a bit more declarative than a Dockerfile's list of commands <nckx>retropikzel: (lambda* (#:key configure-flags #:allow-other-keys) …) ? <nckx>Then you can simply append your own overrides. <NieDzejkob>retropikzel: does the #:configure-flags argument help <NieDzejkob>i.e. (arguments '(#:configure-flags '("--with-foo"))) <tissevert>NieDzejkob: hmmm I had completely overlooked this. Thanks ! <nckx>retropikzel: Does your configure script choke on unknown flags? <blackbeard[m]>NieDzejkob: error in process filter: [mu4e] mu server has version 1.4.12 but we need 1.4.10 <tissevert>I modified my services to remove GDM and replace it with SDDM, everything worked fine, but now I'm trying to come back to GDM so I simply took the previous revision of config.scm without my modification and launched a guix system reconfigure, hoping that would bring GDM back <retropikzel>nckx: The configure script does not support --enable-fast-install which is one of the default flags of the build system, I would like to take it away. I will investigate the configure-flags argument, but it seems to be to add flags? <nckx>blackbeard[m]: Restart all emacs (the daemon if you use it) and any ‘mu server’ processes. <nckx>retropikzel: Lots of configure scripts warn about that flag but run fine. Does it actually break? <nckx>retropikzel: Yes, #:configure-flags can only add to the defaults. If you use the lambda* above you get them all and can manipulate them as you see fit. I'm not convinced it's not overkill yet 🙂 You can just add (string-append "--prefix=" (assoc-ref outputs "out")) IMO. <nckx>retropikzel: Yes, but does it die. <nckx>Many packages print that and build fine. <nckx>& if it dies, that might still be a red herring. <nckx>retropikzel: You'll need to bind outputs in the same way: (lambda* (#:key outputs […] #:allow-other-keys) … ) <tissevert>but guix describe only seems to refer to the state of the «package database», right ? <nckx>Yes. That affects everything you build with it. <tissevert>ok, but how could that break GDM ? surely it would be known if a recent commit on guix.git was breaking GDM, right ? <nckx>That's not really a question one can answer. <nckx>I mean, I hope it's clear how it could break GDM (some dependent package was upgraded introducing some bug/bad interaction/…). I don't use GDM, so I wouldn't know if any of ‘my’ updates would do that. <nckx>Multiply that by all committers & the immense size of the GDM closure & you see the problem. <nckx>I haven't seen any test failures. What's the actual bug, tissevert? <efraim>Could be ownership problems of /var/lib/gdm <tissevert>ok, being the «default» display manager, I thought all newbs like me would build their first systems with it and such a problem would show immediately <tissevert>NieDzejkob: thanks a great deal, I clearly am facing something stateful, and I didn't know where the state could be hiding <nckx>Someone has to be first 😉 But 2 weeks is indeed a suspiciously long time. <tissevert>I'm also trying a rebuild with my revision from the end of June, since the commit that «guarantees» my state is from that time range <tissevert>thanks a lot to all of you for all the good hints, I had no idea what to look for and now at least I've got things to try <tissevert>hmmm very strange indeed, I hadn't even downloaded any Guix-related installation media at the time of this bug report ^^ <ryanprior>efraim: did you watch my talk @ GUADEC? I'm thinking about re-using that format and tailoring the content to other audiences, eg Python or DevOps groups. Any feedback would be super helpful :) <tissevert>I'm so relieved, thank you I had been at it for hours and going slightly mad ^^' <nckx>tissevert: What was it? Feel free to add your experience to that bug report. I think that's reasonable after all this time. <tissevert>ok, I'll read it in details later and add some feedback if it seems relevant <tissevert>(I simply removed /var/lib/gdm and everything worked again) <nckx>I'm sure there are good (obvious) reasons no to disable caching but I wonder if anyone's tried. <Tirifto>Has anyone tried making a voice/video call (with Jitsi, Riot/Element, etc.) in Icecat somewhat recently? If yes, did that work for you? <nckx>Tirifto: ‘It looks like you're using a browser we don't support. Please try again with the latest version of […] Firefox.’ <bavier[m]1>yeah, their browser support checks are too strict <bavier[m]1>though, I think I've been successful with Element/Matrix <Tirifto>nckx: Thank you for checking! :) I’ll report it as a bug, since I’m not sure it’s intentional. (The flag to disable it was added in the Icedove package definition, in an Icedove patch, plus it used to be enabled and advertised as such.) <Tirifto>bavier[m]1: Was that in the last couple of months? <nckx>This was meet.jit.si by the way. <Tirifto>Neither one has worked for me in the more recent versions. <Tirifto>And Icecat was next updated to a newer version on 02 June 2020. <nckx>Tirifto: WebRTC in IceCat was undisabled in 2015. 2015! 2015. <Tirifto>(I don’t think I’m going to be around for 2015! :) ) <Tirifto>Seems like WebRTC should work then. But for some reason it doesn’t work for me. :/ <nckx>Have you asked about this in #icecat yet? <Tirifto>Oh, no! I completely forgot IceCat had its own channel! <pkill9>has there been any progress on packaging chromium extensions? <nckx>Is the manual wrong or is there some subtlety of language that I'm missing? *nckx would finally like to switch to Sway today. <pkill9>I've been using sway as my main window manager, haven't encountered problems with running applications, I think the manual is wrong <nckx>I'm chuffed to hear that. <Tirifto>Enlightenment should support Wayland, too, no? <nckx>Maybe not on Guix, I have no idea. *nckx sees all their custom xorg.conf lines to make their trackpoint & touch screen sane — oh, right, hmm. <jgart[m]>Where should one start if they'd want to package mediawiki for guix? I see that php is packaged in guix but there is no `composer-build-system` yet. Should the first step be to attempt to build a `composer-build-system` system? The source code for mediawiki is on [gerrit](https://gerrit.wikimedia.org/g/mediawiki/core). Or would one just use the `gnu-build-system` for a php package like mediawiki? I see that in this nix <jgart[m]>any help or tips are greatly appreciated <nckx>roptat has written a composer-build-system. <nckx>With some luck they will answer all your questions: <jgart[m]> * Where should one start if they'd want to package mediawiki for guix? I see that php is packaged in guix but there is no `composer-build-system` yet. Should the first step be to attempt to build a `composer-build-system` system? The source code for mediawiki is on [gerrit](https://gerrit.wikimedia.org/g/mediawiki/core). Or would one just use the `gnu-build-system` for a php package like mediawiki? I see that in this nix <nckx>Hai please don't spam (even by accident) 🙂 <nckx>Or is that Matrix doing something silly? <jgart[m]>do you mean the markdown hyperlink syntax? <jgart[m]> * do you mean the markdown hyperlink syntax that doesn't get rendered because irc will only receive plain text? <nckx>Well, that too, but that's all right. <alextee[m]>jgart: when you edit your post matrix actually sends duplicate messages on IRC <jgart[m]>I've made that a habit since using matrix. Might be good to let future matrix users know somehow. <nckx>It just interacted poorly with the length of your message. <jgart[m]>Can a guix channel replace fdroid as an alternative android app store. Has anyone tried something like this yet? <nckx>jgart[m]: I have a Matrix account but am a total noob. Is there a ‘channel entry message’ I could set that only accosts Matrix users? <jgart[m]>nckx: Not that I know of. The only thing I can think of is adding it to the matrix room topic. <nckx>I think it's linked to the IRC one (which is all right) but I don't think anyone actually reads all of our humongotopic anyway. <jgart[m]>nckx: I'm not sure if the irc bridge might have a feature to set what you described above <roptat>so you're interested in php and android? they're also my areas of interest, with ocaml <roptat>if you know how to apply my patches from the link nckx gave you, you should be able to run the importer and try importing mediawiki (my initial goal for creating the composer build system ^^) <roptat>for now, I only imported phpunit, but you should be able to import everything with something like "guix import composer -r mediawiki" (replacing mediawiki with the actual name of the package in composer) <roptat>jgart[m], we have fdroid-server in guix, and you can use its tools to build an app, but that downloads a lot of binaries outside of the guix repos <roptat>ideally, we'd have a way to build android apps directly with gui <roptat>there are currently two things we need before we can do that: we need gradle (which lead me to a rabbit hole of building maven and adding the maven-build-system very recently), and we need the android sdk <roptat>we can probably skip gradle and instead run similar commands to what gradle would do, but that's not going to work for complex apps <ryanprior>I noticed there are few if any PHP libraries or tools packaged in Guix, is that due to some technical or licensing difficulties, or just not enough overlap between Guix and PHP communities yet? <roptat>we don't have a proper build system yet, but that's going to change :) <roptat>once we have it, I don't think there'll be any big technical difficulty <ryanprior>I didn't realize PHP needed a build system, I haven't used it in years but back then it was fully dynamic and I never actually used a build tool. <roptat>ryanprior, it doesn't really build anything, but it needs configuring and installing at the right locations <roptat>oh yeah, I remember talking with someone from replicant, I think it was two years ago <jgart[m]>roptat: I will try applying your patch and suggestion. If you're not busy and would like to further help out in anyway just join us on #replicant. Any help is greatly appreciated <roptat>although I don't have that much time recently ***evhan` is now known as evhan
***terpri__ is now known as terpri
<fnstudio>hi :) i've recently installed guix on a debian host and i'm not trying to move as much as possible as a guix package <fnstudio>some apps though don't seem to come with the right icon set, eg meld <fnstudio>i get this error `GLib.Error: gtk-icon-theme-error-quark: Icon 'folder' not present in theme Adwaita (0)` <fnstudio>is that something anyone here has already encountered by any chance? <fnstudio>ah! `guix install gnome-icon-theme` actually fixed it... <fnstudio>not sure whether gnome-icon-theme should be reported as a dependency for meld? i.e. not sure if i should raise this as a bug...? <NieDzejkob>yeah, meld should be patched to load the icon from the store path or it should propagate the icon theme as a dependency <nckx>fnstudio: Any icon theme would do, which is why I don't think it should be hard-coded. <nckx>(gnome-icon-theme is just an older version of adwaita-icon-theme, which probably would work just as well, for example.) <fnstudio>nckx: ah, interesting, thanks! is there any concept of "suggested" package in guix (as you'd have with apt-get, for instance)? <nckx>No, and I'm not familiar with apt's implementation. <nckx>(Guix suggested package: adding ‘This package requires an icon theme’ to the description 😛) <vagrantc>yeah, there's no reasonable way for guix to do so, since it's all declarative <nckx>We have the same ‘problem’ with fonts: many packages require *a* font, but it can be any font, and I'm in the camp ‘hard-coding one is worse than the current situation’ camp. <kmicu>fnstudio: on a Guix System a basic desktop service could provide a font, an icon set, a pointer icon set and so on but with Guix on a non‑GuixSystem we need to answer the qestion are fonts, icons and all similar stuff a real dependency of a package or not? There’s no answers yet. <fnstudio>nckx: excellent, that makes sense, thanks for your help, my app is up and running again now - happily part of my growing guix package set now 