<atw>my vote is for the classic "guix pull: error: some substitutes for the outputs of derivation `/gnu/store/….drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source "
<leoprikler>Is there something I need to consider to run a VM generated by `guix system vm`?
<leoprikler>Running it as normal user produces some weird KVM error, but I hesitate to sudo.
<nckx>leoprikler: Is your user in the kvm group? ($ groups)
<apteryx>I have almost all the bits, but the reused guix-daemon binaries are looking for their dependencies from the Guix being built rather than the Guix that was used to build them... I realize this probably sounds very confused/confusing ;-)
<apteryx>leoprikler: nope, I mean a custom guix/built package that inherits from the regular guix package, but replaces the source by the untouched git checkout *built* sources
<apteryx>that were built at the time issuing 'make' in a Git checkout. This allows skipping rebuilding all the binary artifacts (*.go, daemon binaries), making the Guix package available in a matter of seconds instead of like 20 minutes.
<apteryx>I can share code if that helps understanding :-)
<valignatev>I see that kitty has ("libgl1-mesa" ,mesa) in its inputs and then some insane magic to patch a patch to libEGL, but I don't know if this is it
<nckx>valignatev: terpri_'s right, ‘libGL’ is just mesa. Any extra prodding that your package may need to find its libraries is unrelated.
<valignatev>Got it. Just adding mesa to inputs didn't help though
<valignatev>I'm getting Error creating GL context; Received multiple errors. Errors: `[NotSupported("lacking either libGL or libEGL so could not fallback to other"), NotSupported("both libGL and libEGL are not present")] when I try to run compiled binary
<valignatev>ldd tells me that compiled binary isn't linked against anything like libgl
<valignatev>So I guess I have to do some shenanigans to make it work :(
<leoprikler>valignatev what configure options are available?
<nckx>It's a time-honoured tradition that every programme that needs libGL has to dlopen it in a slightly different and if possible broken way. I guess it's the ghost (hah) of crappy proprietary drop-in drivers or something.
<apteryx>leoprikler: this is the experiment I was talking about ^
<vagrantc>ugh... failing tests for u-boot-tools updating to 2020.01 ...
<apteryx>pkill9: actually, try re-enabling the validate-runpath phase to see the current problem. A workaround is to rebuild the daemon, but that is counter to what I'm trying to achieve here. Ideally, we'd make this guix/prebuilt package inherit from the guix package from the inferior of the environment in which the sources were built.
<lafrenierejm>I'm attempting to package https://github.com/akermu/emacs-libvterm and am running `guix environment --ad-hoc libvterm libtool cmake-minimal` to build manually. That command failed with `guix environment: error: cmake-minimal: unknown package`. Any ideas why that package is unkown?
<vagrantc>lafrenierejm: i don't see cmake-minimal as a package in guix
<drakonis>i wonder if its because i dont have polkit here
<apteryx>peanutbutterandc: I tried using tuxguitar recently and had issues too (wouldn't load a .gp5 file), not sure if I had sound or not. You might need to install timidity++ and use that like I usually needed to do on Debian.
<apteryx>(I think it is a midi sound server or something)
<str1ngs>bandali: I just find mu4e easier to use in the long run
<peanutbutterandc>str1ngs, I just reached the same conclusion after installing tuxguitar from flatpak! Also, I realized that guix's tuxguitar > Tools > Plugins is pretty empty whereas the flatpak one (and even the apt one - the dpkg shipped in the website) has quite a few plugins
<peanutbutterandc>Sorry, I don't really know. But tuxguitar can run with plain pulseaudio too. I think that is what flatpak is doing.
<bandali>haha same. but at the same time, i have to deal with a nontrivial amount of mail (>100 every day) and i’ve found nothing quite lets me do it like gnus without getting in my way
<bandali>notmuch was pretty close and its tagging is awesome, but i’ve found gnus’s article-mode vastly superior to notmuch’s message display mode (can’t remember the name)
<peanutbutterandc>I have a question (a really n00bish one). Regarding patches that one wants to contribute to guix, is it okay to send them as attachments from normal email or does one have to use git-email or something like that? I'm sorry, I'm just a GitHub-PR-kiddie
<bandali>generally speaking, git-send-email is probably the safest option
<peanutbutterandc>I see. Thank you very much. (Yes, I have read it and still had the question)
<bandali>cheers :) i’d emphasize the last 2-3 paragraphs regarding formatting (plain text email (and not html) preferred) and a nice and descriptive subject
<peanutbutterandc>Another one: The guix maintainers would probably take my patch and apply it as a separate commit, right? That probably means that one might be excused for a not-too-well-written git log?
<bandali>yes, but please do your best to write a good commit message :)
<bandali>there plenty of examples in the git log for the guix repo ;)
<efraim>ArneBab: I did some work before to build pypi but I didn't make it through the bootstrapping it from python phase
<peanutbutterandc>bandali, drakonis Would you like to see a patch that I want to contribute and give me some reviews so that I can send a good one to the maintainers?
<bandali>peanutbutterandc, sure, if you could give a link (please don’t paste here lol)
<drakonis>those shells scripts will be rewritten in guile once gash is ready, yeah?
<bandali>peanutbutterandc, also, thank you for working on making the out of the box experience better
<peanutbutterandc>bandali, Wow! I feel like a kid getting praised for doing small thing. The pleasure/honor is all mine (if the patch gets merged). Guix has made computing fun again for me :) Thank you for being so kind. I will look at the one-line summary right away.
<bandali>peanutbutterandc, cheers :) i’m very happy to hear that! all in all guix has a very kind community, and i’m happy to be a part of it. also, i’m not the best person to evaluate your patch function-wise, but i’m sure once you send it over to guix-patches@ folks would be happy to give you more useful feedback
<peanutbutterandc>bandali, I see. So I had the 1 line summary but it has become the 'Subject' of the patch. The summary is there in `git log` in my branch. What should I do?
<bandali>peanutbutterandc, ah yes! that seems to be what happens; should be fine then
<bandali>then just make sure its formatting adheres to the convention
<peanutbutterandc>drakonis, I just ran gash and `. the_script.sh` and it didn't throw any errors.
<peanutbutterandc>bandali, I tried to emulate the previous `git log etc/guix-install.sh` commits as much as possible
<bandali>peanutbutterandc, sounds like a good idea! :)
<peanutbutterandc>bandali, I see. Then I will be sending the patch to the maintainers then. Thank you very much for your help.
<peanutbutterandc>drakonis, I just tried a few basic things in gash as it stands right now, and it seems to work like bash, too - the shell expansions and all. S-expressions entered directly don't seem to evaluate, however.
<lxsameer>yeha but i mean why not have gpg key under the project name
<kirisime>I generally don't trust any form of abstract entities. An abstract entity is capable of making decisions no human would agree on, so if Ludo signs his personal mail with the same key I'd trust that it's in his interests to not compromise it.
<lxsameer>kirisime: good point. but at the same time. for a user it's raise a question, of is it legit thing ? if it is why i'm downloing the key from a php page rather that fetching it from a keyring
<wingo>the web of trust does not require trust in where you get the key
<oriansj>Yeah, it wouldn't be hard for civodul to generate a key that says "GNU Guix" and use it to sign the binaries but it doesn't make it any more secure
<oriansj>that is why myself and others are working to eliminate that false assumption about binary security by providing a bootstrappable path, that can be picked up in the morning and fully understood by lunchtime.
<oriansj>at the end of the day, we don't want to have to trust any developer not to get compromised
<oriansj>that is why ultimately guix includes a way to build the bootstrap binaries yourself. So that given the recipe you should get the exact same output.
<oriansj>now perhaps guix should take a lesson from bitcoin and have a repo where people can upload proof that they were able to replicate the guix bootstrap binaries themselves; to allow a much larger web of trust and a single point where we can detect either a single developer got compromised or a single developer is the only non-compromised system.
<oriansj>but it is import to start the discussion perhaps not with the details but the general goal of making our system more trust worthy
<oriansj>right now there are improvements that need to be made to ensure that guix build scripts continue to work forever; thus eliminating the current problem of oops the source file on the server changed and we don't know why and now everyone's builds are broken
<lxsameer>oriansj: i suppose we treat the source files on the server as immutable datasets as well, right ?
<oriansj>lxsameer: well if we don't; how could we expect 2 people getting different files to get the exact same output?
<leoprikler>but that is not the only way, that exists and "just checking" is not really a good reason
<leoprikler>even if you are "just checking", so that you can report your findings on a dynamically updated website or whatever for others to use, there will be a specific use-case associated with the server that you're "just checking"
<NieDzejkob>yeah, maybe only the kernel is up and while it responds to pings, whatever you actually want the server to do doesn't work
<sirgazil>As far as I know, GNOME is the "GNU desktop enviroment", and it is a GNU project (though it doesn't seem like so), but I just read someone saying that GNOME is now a Red Hat project, not GNU 🤦
<leoprikler>GNOME people secretly wear Fedoras when no one sees them.
<nckx>apteryx: It worked back when. I don't have any devices myself to test it now. Are you sure the rules are to blame? AFAICS no existing rules were removed or modified: <https://www.tobias.gr/android-drools/>. Have you tried with a reverted b7db2c?
<sirgazil>raghav-gururajan: I use GNOME pretty much for the same reasons you mention on the mailing list. But I wouldn't call RedHat people creeps or Nazis (you might be joking, but still).
<nckx>I forgot to add: except the MIDI one which doesn't look relevant.
<sirgazil>But it's really frustrating when something starts libre, then goes open-source, and finally becomes proprietary...
<raghav-gururajan>sirgazil I was joking. I meant as a refernce to authoritarianism. Where their products force things into adoption.
<nckx>Why can't you respect their freedom to choose their own dependencies? 😉
<dctrud>Guix is a great example, really, of how things aren't to that point, isn't it? I can use Gnome or whatever else without systemd etc.
<raghav-gururajan>There could have been easy ways to disable systemd depenencies in one switch.
<leoprikler>imo systemd is really not the worst dependency to have, especially with folks putting up alternatives for its components
<nckx>No, Guix is an authoritarian cancer Nazi because you can't use Ruby, only Guile. And once Guile goes proprietary, we're screwed.
*nckx thinks they're getting the hang of this logic.
<dctrud>I mean, yeah there could be a flag, but when an org is paying people to drive forward development it's not really constructive to blame those people for not adding exceptions to what their salary is paying them to do
<nckx>GNOME is free software. One can fork or maintain support for other systems perfectly. However, this requires ‘effort’ and ‘skill’. Trying to bully Red Hat into writing your code for free takes neither.
<dctrud>Nothing yet beating the conspiracy theories at last LUG meeting I went to though
<nckx>raghav-gururajan: My ire is aimed at the ‘logic’ in that (and similar) mailing list post, not you. 🙂 I only object to your twisting of the word ‘freedom’ in that perverse sense. But I don't blame you for that, it's everywhere.
<nckx>raghav-gururajan: I'm not saying they were a good idea, but most systemd dependencies replace abstraction layers that were considered ‘bloated’ before. It's hard to win.
<nckx>raghav-gururajan: Do you mean that there should be only one standard; that GNOME and XFCE are bad choices (to an i3 user they are both ‘similar’ but I doubt that's what you mean); or something else?
<kmicu>Great. Guix deserves a modern desktop with all long‑word features. I will not use it cuz XMonad is enough for me but some a11y, i13n and so on features provided by GNOME are real life savers for other so I appriciate your efforts anyway! ʕノ•ᴥ•ʔノ ︵λ𝛌𝚲𝝀
<nckx>sirgazil: I too have yet to experience that enlightenment. I write Scheme like I do any other language (including CSS): write, save, run, repeat. I use REPLs for short tests but not ‘lllllllllllllive’.
<nckx>Er, my input driver hung (it does that sometimes), nice flair of the dramatic tho'.
***MinceR_ is now known as MinceR
<leoprikler>I see "live programming" mentioned in the context of servers a lot.
<leoprikler>Specifically big servers running some functional or otherwise declarative programming language.
<leoprikler>being able to hot patch code without shutting down the server is apparently a big business plus there
<nckx>I think it's unlikely to work well. Guix, at least, does not nuke /etc at boot. NixOS remnants will remain, which could be harmless *or* be picked up at runtime and explode. I guess you'll find out.
<nckx>mehlon: Swap and (zstd) zswap might give you a tiny bit more breathing room, but don't expect miracles. If I were using Guix on such a ‘small’ system, I'd (cross-)compile substitutes on a bigger one.
<nckx>There are ways to ‘pull remotely’. In fact guix pull is already substitutable. guix pull --commit=<a commit that's, say, a day old> might work. Or you can configure offloading to another arm7 machine, or to one of another architecture that's set up to transparently compile using the qemu-binfmt-service.
<nckx>The result is that ‘guix build’ or indeed ‘guix pull’ on your Pi will send build instructions (and all dependencies) to your bigger, fatter Guix box which will send the build results back when finished, printing the build output on your Pi as if it were local. Very transparently.