IRC channel logs


back to list of logs

<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)
<nckx>That should suffice.
<leoprikler>Currently not
<apteryx>Would someone have an idea about how to infer the "Guix (environment) that was used to build the Guix sources" from Guix source code?
<apteryx>I'm interested in a hack that reuses the git checkout built Guix binaries into a Guix package, that would allow very iterative Guix development && make check-system
<apteryx>very fast*
<leoprikler>you mean ./pre-inst-env?
<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 :-)
<leoprikler>you mean a binary cache for guix pull?
<pkill9>apteryx: could you post the code? i'm interested in that
<nckx>wigust: Nice, thanks for updating skarnet.
<sirgazil>These recurrent font problems are so annoying...
<wigust>nckx: np
*sirgazil looks how to set font size in Emacs
<valignatev>Hey Guix! What input should I provide if a package requires libgl?
<terpri_>valignatev, mesa has libGL iirc
<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?
<valignatev>Kinda none, because it's a cargo-build-system
<roptat>valignatev, if you look at the source code, how is libgl opened?
<roptat>maybe try to strace the binary also, that might give you some hints
<valignatev>Yeah, that's what I'm doing now
<valignatev>Maybe will end up just patchelfing it
<roptat>like if it's trying to open /usr/lib/ or simply, there's probably a dlopen somewhere :)
<nckx>valignatev: That won't work if it's dlopen()d at runtime which is what this smells like.
<roptat>(or whatever that is for rust things)
<nckx>Flippin' ninja roptat.
<valignatev>hmm, you're probably right
<roptat>rpath does help with dlopen though
<roptat>if you do dlopen('') it'll look for in the rpath
<nckx>It didn't for me, but I'll gladly blame bad 90s shooter design 🙂
<roptat>it won't work if libgl is not in the rpath of course, which is why patchelfing helps. but it's always better to substitute* it to its full absolute path anyway
<nckx>If that was directed at me, I did mean that even patching rpath still didn't work; but I completely agree with your last comment.
<leoprikler>all your shared objects are substitute*d by us
<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.
<leoprikler>#:dlopen "totally_not_dlopen"
<nckx>It's such a sane pattern.
<leoprikler>(when you need to interact with your scanner from ncurses)
<nckx>(Inb4 someone hails it as ‘more reproducible!’ and tries to sell it back to us as a good idea.)
<apteryx>pkill9: one minute
<roptat>is anyone here going to libreplanet?
<valignatev>Welp, here are paths they're trying to dlopen:
<valignatev>So "" and ""
<valignatev>So adding libgl from mesa to rpath should work, right?
***jonsger1 is now known as jonsger
<nckx>valignatev: The directory component, yes.
<roptat>valignatev, you could add a phase to do (substitute* "" (("") (string-append (assoc-ref inputs "mesa") "/lib/"))
<valignatev>Yeah, that's what I'm thinking about as well. (substitute* glutin sources might be a more clean solution
<valignatev>thanks for the help, will try to do something later. But hey, Alacritty already compiles successfully on my local Guix, yay!
***stefanc_diff_ is now known as stefanc_diff
<apteryx>pkill9: sorry for the delay...
<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 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
<vagrantc> (properties '((hidden? . #t)))
<str1ngs>is there not a cmake-build-system?
<raghav-gururajan>str1ngs Yes, there is.
<lafrenierejm>vagrantc: Ah. I missed that.
<str1ngs>lafrenierejm: would it not be easier to use cmake-build-system
<lafrenierejm>str1ngs: That's what I'm using in my package definition, but I'm getting build errors and trying to troubleshoot in an interactive environment.
<vagrantc>lafrenierejm: so it's available as an input, but not to the standard user-facing tooling, if i understand correctly
<lafrenierejm>vagrantc: Yes, that seems to be the case.
<str1ngs>lafrenierejm: use guix build -K <package>
<str1ngs>then inspect /tmp/guix-build.../
<lafrenierejm>str1ngs: TY. I'll do that and see what I can find.
<str1ngs>but say you want to manual build in a ad-hoc environment just use cmake proper. it won't hurt
<lafrenierejm>str1ngs: Sure. It was just big, so I thought I would use minimal. Then I wondered why I was getting the error.
<raghav-gururajan>Folks! Does anyone know how shepherd is different from systemd? n terms of design principle and functionalities?
<str1ngs>lafrenierejm: instead of use cmake-minimal use an expression. like so -e '(@@ (gnu packages cmake) cmake-minimal))'
<vagrantc>raghav-gururajan: i've heard people say they're actually kind of similar in design
<vagrantc>raghav-gururajan: very different implementation, of course
<str1ngs>lafrenierejm: eg. guix environment --ad-hoc --ad-hoc libvterm libtool -e '(@@ (gnu packages cmake) cmake-minimal))'
<str1ngs>minus the redundant --ad-hoc :P
<raghav-gururajan>vagrantc I see. I wonder if shepherd face same problem like systemd since they are similar in design?
<raghav-gururajan>*will face
<raghav-gururajan>Wiuld it?
<lafrenierejm>str1ngs: Thanks!
<str1ngs>lafrenierejm: no problem
<vagrantc>raghav-gururajan: i'm not deeply familiar with either ...
<vagrantc>both feel kind of cumbersome ... but i imagine if you know guile it could make some sense :)
<vagrantc>well, shepherd
<str1ngs>oddly ~/.config/guix/current/share/emacs/site-lisp is now in my EMACSLOADPATH
<raghav-gururajan>vagrantc Cool!
<vagrantc>raghav-gururajan: like most things in guix, it's guile all the way down :)
<str1ngs>until you hit emacs :P
<raghav-gururajan>vagrantc When I started to work on porting some packages into guix, I got a taste of guile scheme. It's delicious. :-D
<raghav-gururajan>str1ngs Guix and emacs are like lion and tiger. They both belong to cat (lisp) family. xD
<str1ngs>those darn kitty cats
<peanutbutterandc>Hello there!
<peanutbutterandc>Does anyone here use tuxguitar, as installed from guix? It is not working right for me, and I would like some help regarding it
<peanutbutterandc>s/would like/would appreciate/
<peanutbutterandc>First of all, I am not getting any sound. Tools > Settings > Sounds shows that 'Midi Port' is unspecified (and has no options). So perhaps something was missed during packaging?
<str1ngs>peanutbutterandc: do you actually have a midi device?
<str1ngs>like a keyboard?
<peanutbutterandc>Second, and this is what confuses me a lot, is that I am not able to input anything on a blank tab sheet using the numeric keys on my keyboard.
<str1ngs>midi keyboard specially
<peanutbutterandc>str1ngs, Hi there! No, sir. But the sound output from tuxguitar is MIDI, basically
<str1ngs>ewww it uses java!
<peanutbutterandc>str1ngs, Yes, it does. But the pro of that would probably be this: (Web-based player thing) and the app on google play
<peanutbutterandc>A very useful program, nevertheless
<nly>hi peanutbutterandc
<str1ngs>peanutbutterandc: if I use the fretboard I can input notes
<str1ngs>nly: no problem. my email work flow is greatly improved now I switched to mu4e and offlineimap
<str1ngs>peanutbutterandc: are you actually creating tabs?
<nly>i'd like to switch to something other than gnus too
<str1ngs>nly: and never go back to gnus
<peanutbutterandc>str1ngs, I could input notes using the numeric keys before (flatpak/apt). So, perhaps there is something missing in the packaging? It is too much work to click on the fretboard anyways. Oh yes, sir! :)
<str1ngs>peanutbutterandc: ironically I just ordered a midi keyboard
<str1ngs>peanutbutterandc and I play acoustic guitar.
<peanutbutterandc>str1ngs, Oh wow! Cool. Then you must like chordpro. Here: and this: (chordpro packaged in guix)
<str1ngs>I used tuxguitar way back. but only to read tabs
<peanutbutterandc>str1ngs, You should flatpak install tuxguitar and give it another shot, perhaps.
<str1ngs>nly: we need a password manager that can handle input fields in nomad
<str1ngs>nly: also I think it should use auth source format found in ~/.authinfo.pgp maybe shroud can do this?
<nly>str1ngs, i didn't knew you played the guitar
<drakonis>flatpak functions?
<peanutbutterandc>drakonis, as in "does flatpak work?" Yes, it does. For TuxGuitar, at least. :)
<nly>str1ngs: i'll see what i can do.
<drakonis>i mean, i'm getting an error when trying to enable flathub
<drakonis>it cant open /tmp
<drakonis>yelling about permissions
<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)
<peanutbutterandc>apteryx, I see. Thank you. I will try it.
<peanutbutterandc>drakonis, I am using flatpak from apt and not guix. Perhaps flatpak install --user might work?
<drakonis>hmm, i see
<drakonis>i should check how flatpak works on nix as reference
<bandali>str1ngs, why u switch away from gnus -_-
<str1ngs>bandali: I didn't like the interface
<str1ngs>that and the whole expunge weirdness
<drakonis>expunge weirdness?
<str1ngs>you can't delete emails
<peanutbutterandc>apteryx, I just install timidity++ but I still don't have any choice in the MIDI dropdown. Any ideas, please?
<str1ngs>peanutbutterandc: there is no tuxguitar synthesizer for some reason
<drakonis> a reminder that this is a pretty cool thing that should be done
<bandali>str1ngs, ah..
<bandali>as for deleting mail, i’m pretty sure you can :/
<drakonis>its a boon for channels
<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
<bandali>str1ngs, sure, to each their own :)
<bandali>i find it the other way around
<bandali>but i guess i’m well in the minority :p
<str1ngs>the reality the less I have anything to do with email the more I get done :P
<peanutbutterandc>But I have to say, guix-tuxguitar looks a whole lot better than flatpak-tuxguitar.
<str1ngs>does jack need a system service?
<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
<bandali>there’s a nice guide/tutorial at
<drakonis>the docs have a section on that as well
<bandali>but you can also attach to a ‘normal email’
<bandali>they do indeed:
<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)
<peanutbutterandc>bandali, Thank you! Here:
<peanutbutterandc>It simplifies guix a whole lot for the average-user by having a /etc/profile.d/ (much the same way as flatpak does) and provides better desktop integration
<peanutbutterandc>drakonis, Thank you! Here:
<drakonis>tbf you dont need to paste it twice
<peanutbutterandc>I am still embarressed about having to use the same email address from grade 6. :|
<drakonis>arent we all
<drakonis>protonmail still has a lot of names left
<drakonis>go claim yours
<peanutbutterandc>Haha :D protonmail?
<peanutbutterandc>looking it up
<bandali>i’d recommend tutanota at least, or perhaps
<drakonis>i figure this question is not fit for this channel, fit for #guile perhaps
<bandali>various tilde communities are great too, and usually give you a mail address too
<drakonis>with enough effort, one could implement racket's defining features into guile, right?
<peanutbutterandc>I see. How about gnu? How does one get a gnu based email address like the devs? or fsf?
<bandali>peanutbutterandc, addresses are usually only given to gnu maintainers and webmasters to my knowledge
<peanutbutterandc>I see. Thank you very much.
<bandali>no problem :)
<peanutbutterandc>That probably means that having a .gnu .fsf address is like having a .harvard address... cool!
<raghav-gururajan>peanutbutterandc is awesome :-)
<bandali>peanutbutterandc, re your patch, the first thing i noticed is the missing one-line summary (have a look at the git log for the guix repo)
<bandali>peanutbutterandc, i guess :p
<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 `.` and it didn't throw any errors.
<peanutbutterandc>bandali, I tried to emulate the previous `git log etc/` 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, Is there any input that you'd like to give me, please?
<drakonis>oh no i got nothing for you
<bandali>peanutbutterandc, cheers :)
<bandali>and good luck!
<drakonis>i mean that there's a big pile of shell scripts on the repository that i wonder whether they could just be replaced with guile after gash reaches parity with bash
<peanutbutterandc>bandali, Thank you! :)
<bandali>peanutbutterandc, you’re welcome :)
<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.
<peanutbutterandc>`guix show gash` shows it at 0.2.0
<drakonis>ah, neat then
<drakonis>it just does simple bash bootstrapping tasks
<peanutbutterandc>So, I just sent the email. Isn't it supposed to show up at: or something? I feel like a total n00b here.
<g_bor[m]>hello guix!
<g_bor[m]>I have a problem.
<g_bor[m]>I ma trying to get an installer working.
<g_bor[m]>the porblem is that guix system init in the latest stage of installation gives me an unxepected path from substituter.
<g_bor[m]>I managed to find where does it come form, it's in the daemon querying state.
<g_bor[m]>Does that ring a bell?
<g_bor[m]>this is called from wopQuerySubstitutablePaths and wopHasSubstitutes
<g_bor[m]>if I run it directly form another terminal it works, so it might be something in my installer code.
<g_bor[m]>ok, I will try something simpler first....
<vagrantc>g_bor[m]: i saw an "unexpected path from substituter" issue earlier on "guix system build" ...
<vagrantc>the next "guix system build" succeeded though ...
<vagrantc>though i had already guix pull'ed ...
<g_bor[m]>vagrantc: this seems to be very reproducible... so might be something else...
<vagrantc>first time i ever saw that message ... so to see someone mention it roughly the same day...
<g_bor[m]>I will try to 'guix build hello' to see if it works...
<g_bor[m]>What makes me suspicious, is that it breaks on different paths...
<g_bor[m]>also I always got a strange mangled output stating that a substitute is 184% ready...
<g_bor[m]>in the beginning I could iterate quite fast with guix system vm, but since cow-store does not work there this last part is really slow...
<g_bor[m]>vagrantc: ye, it might be the same issue.
<g_bor[m]>I will try to pull again.
<g_bor[m]>guix build hello worked fine...
<g_bor[m]>I have seen it yesterday already, form a quite fresh checkout.
<g_bor[m]>pulled then, but it did not help
<raghav-gururajan>Hello Guix!
<raghav-gururajan>Any commiters around?
<civodul>Hello Guix!
<raghav-gururajan>civodul o/
<vagrantc>g_bor[m]: well, i trust the issue is in capable hands, curious how it turns out!
<g_bor[m]>vagrantc: thanks. I hope that I can find out what is going on.
<civodul>hey vagrantc, wb! :-)
<g_bor[m]>It is somewhere in system build...
<vagrantc>civodul: hello, and goodbye :)
*vagrantc waves
<g_bor[m]>civodul: any idea how the unexpected path from substituter error comes about?
<civodul>g_bor[m]: i have no idea what you're talking about :-)
*civodul goes afk
<g_bor[m]>sneek: botsnack!
<lxsameer>hey people, why a specific gpg for a person is required for install guix gpg key is for "Ludovic Courtès"
<NieDzejkob>he's the project lead, right?
<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
<kirisime>Laptop screen fell off.
<oriansj>lxsameer: well there is no such thing as a project key, but rather a key held by someone who we don't know and there is no ready way to discover who they are.
<oriansj>In fact the best strategy is never trust a single binary provided to you from anyone you don't personally know and trust.
<oriansj>but as stage0 doesn't quite yet get one to full GCC and proper bootstrap yet we are currently forced to trust a handful of binaries on our systems
<oriansj>where the only binary you have to check is this: and here is its source code:
<oriansj>It should be able to be checked in about 30 minutes by hand that the source code is a direct 1:1 match with the contents of the binary. After that everything is source for you to inspect.
<oriansj>The steps are quite easy to follow:
<lxsameer>oriansj: fair enough but isn't it better to distribute the keys via a keychain ro something ?
<oriansj>lxsameer: all security is about costs; costs to perform and costs to the attacker to defeat and the value obtained by the attacker
<oriansj>aka an attacker is not going to spend $50K to break a SHA1SUM for the ability to compromise an application used by 3 people
<oriansj>unless those 3 people are worth far more than $50K to them
<oriansj>So by making the cost high enough and keeping the likelihood of detection high as well; it makes compromises expensive and easily discovered
<oriansj>aka sure they could compromise the guix build servers but no one has to use them and everyone could just run guix challenge (building from the bootstrap binaries)
<oriansj>also note it is possible to build the guix bootstrap binaries on ALL distros from source
<oriansj>So no need to worry about the keychain at all; audit the source
<oriansj>My perspective is don't trust us; trust what you can prove to be correct.
<lxsameer>oriansj: sure
<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.
<civodul>hi! :-)
<lxsameer>oriansj: that's true but i still thing downloading the key from a keychain is much nicer that downloading it from a php page
<lxsameer>is there any gnu keyring ?
<oriansj>lxsameer: yes there is a public Gnu keyring if I remember correctly
<civodul>there's but it doesn't bring anything security-wise
<lxsameer>sorry i meant keyring server
<oriansj>lxsameer: there is no difference between a keyring file and a keyring service in regards to providing security
<oriansj>both can be compromised in terms of what you get, contain outdated or wrong information and perform hash collision attacks (for weaker keys)
<oriansj>now civodul's key if I remember correctly has been signed by a good few people (including people who's keys are in the debian and arch keyrings)
<lxsameer>oriansj: ok then
<oriansj>So, it should be rather simple to verify you got the right key and who that the person responsable is for signing the binaries. Which you know exactly who to blame if something isn't right
<roptat>hi guix!
<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
<civodul>oriansj: people can run "guix publish" to well, publish their build results
<civodul>though that's still not as simple as it could be, because you need a stable connection etc.
<civodul>IPFS support would come in handy
<lxsameer>civodul: to use other people's build?
<oriansj>indeed; although I think getting the source eternally available is a higher concern (especially with providers who change files without doing a naming update or preserving the old file)
<g_bor[m]>hello guix!
<g_bor[m]>I just noticed when I try to build a system without a file-system with mountpoint / I get an ugly backtrace...
<g_bor[m]>I believe a more meaningful error message would be welcome.
<oriansj>lxsameer: also one could use IPFS to aid in the distribution of source code tars
<lxsameer>oriansj: hmmm i'm not familiar with details of IPFS but how the dependency tracking works in that case
<lxsameer>for example what if I as a peer doesn't have an specific version of a package
<lxsameer>and there is no other peer available ?
<lxsameer>failure ?
<oriansj>lxsameer: essentially yes, failure is one of the inevitable modes; that is why guix teamed up with The software heritage society:
<oriansj>So that we could have a backend source we could depend upon
<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?
<lxsameer>oriansj: cool, that's what i expected
<civodul>lxsameer: "guix publish" publishes not just binaries, but also metadata about those binaries (roughly, a signed hash)
<lxsameer>civodul: cool
<civodul>that's enough to compare build results among different machines
***ng0_ is now known as ng0
<oriansj>civodul: you may with to include publishing source files too whith guix publish
<PotentialUser-20>hi eeveryone, does anybody knnow how to ping a server in guile? (something like "(ping? server)")
<leoprikler>to check whether the server lives? wouldn't it be easier to request what you're about to request anyway?
<PotentialUser-20>leoprikler: dont know =( maybe. Could you explain please?
<NieDzejkob>what are you really trying to do? what is the *problem* you're trying to solve?
<leoprikler>e.g. assume you want to request some binary from
<PotentialUser-20>well, let me explain
<leoprikler>you would simply send the fetch request instead of first pinging and then sending the fetch request
<PotentialUser-20>i have a list of hosts and i want to check if they are alive
<PotentialUser-20>leoprikler: how to send a fetch request in guile?
<NieDzejkob>why do you want to know whether they are alive?
<leoprikler>PotentialUser-20: info "(guile)Web"
<PotentialUser-20>NieDzejkob, because it's servers that are in trains. and they move. i wanted to write simple script there health (actually i have one in ruby, but wanna implement it in guile).
<PotentialUser-20>well maybe there is a way to run bash in guile and parse an output?
<leoprikler>Well, yes, you can do that, but again, why ping specifically?
<leoprikler>What do you want to do to those potentially up train servers?
<PotentialUser-20>leoprikler: because that's the way i know.
<PotentialUser-20>leoprikler: just check that they are up
<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
<NieDzejkob>Is IceCat affected by this?
<PotentialUser-20>well I got it. is there way to run and parse bash command in guile?
<NieDzejkob>there's (system ...) and (invoke ...)
<leoprikler>(invoke ...) being a guix thing
<leoprikler>Though I think for output you'll have to use open-pipe, unless you want to wrap system in port magic.
<PotentialUser-20>leoprikler: where find definitions of such functions?
<NieDzejkob>'info guile open-pipe' ?
<leoprikler>info "(guile)Pipes"
***ng0_ is now known as ng0
<leoprikler>fwiw I looked at the ruby lib, and it does exactly what I expected it to
<leoprikler>use various protocols (including http) to implement "ping?" on top of it
<sirgazil>When you start GNOME Help, and go to the Getting started section, do the videos play?
<raghav-gururajan>sirgazil No it doesn't. :/ Thanks for bringing this up. I'll look into it. :-)
<sirgazil>raghav-gururajan: Thank you :)
<apteryx>NieDzejkob: I don't understand why arstechnica has more details about CVE-2019-17026 than or
<apteryx>usually the later compiles details about which versions are affected. Seems it's published really early in the press.
<apteryx>so we can't tell other than looking at any patches published by Mozilla and comparing the source affected to see if it's present in our versios (68).
<lfam>apteryx: In my experience MITRE is often the last to publish. It's mystifying
<hexagonal-sun>Evening guix!
<bavier>hexagonal-sun: \o
<hexagonal-sun>A quick question if that's okay, I've installed Emacs (26.3), however it doesn't seem to include tab-line. Am I missing an additional package?
<hexagonal-sun>(require 'tab-line) says it can't find the load file.
<apteryx>nckx: is the latest android-udev-rules file working for your devices?
<apteryx>I can't see any of mine anymore in 'adb devices'
<leoprikler>hexagonal-sun: could this be an Emacs 27 feature?
<hexagonal-sun>leoprikler: Hmm, not sure. Can I tell guix to build Emacs 27 to find out?
<leoprikler>sure, it's emacs-next IIRC
<hexagonal-sun>awesome, thanks leoprikler. I'll give that a try....
<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.
<jonsger>sirgazil: it was on the mailing list...
<sirgazil>jonsger: yes
<jonsger>one can see that GNOME is less SUSE then formerly :(
<raghav-gururajan>sirgazil I am worried about that too. RedHat's inflitration into GNOME. Total Nazi situation out there. xD
<dongcarl>Is python3 deterministic yet?
<raghav-gururajan>I hope the GNOME foundation members understand and stop the growth of cancer. It already started to metastasize.
<leoprikler>What exactly do you mean with cancer? GJS perhaps?
<lispmacs[work]>hi, has anybody thought about working on a package definition to build librecmc or openwrt? Just wondering if Guix could be used to build librecmc firmwares
<nckx>Could we not with the cancer Nazis.
<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: <>. 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.
<raghav-gururajan>leoprikler I meant cancer as systemd dependencies.
<raghav-gururajan>It's growing.........
<raghav-gururajan>nckx me?
<nckx>You seem to think developers should be forced to use the libraries you prefer.
<raghav-gururajan>No I didn't mean that.
<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
<leoprikler>Time to reimplement Guix in Ruby quickly.
<raghav-gururajan>nckx You are right. They should exercise their freedom to choose their deps.
<nckx>Or to blame the org for not sponsoring your favourite fringe init.
<raghav-gururajan>dctrud I second that.
<raghav-gururajan>I shouldn't have blamed. Understood now. :)
<dctrud>:-) I'm having a systemd discussions everywhere I look day.
<leoprikler>People really love to hate systemd it seems
<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
<raghav-gururajan>nckx I agree to your last message.
<nckx>raghav-gururajan: Ditto.
<raghav-gururajan>nckx Pardon?
<nckx>Never mind. ‘There could have been easy ways to disable systemd depenencies in one switch’ is an insane amount of work, it just sounds easy.
<leoprikler>That said, one such switch could be implemented for certain libraries, that only require systemd so that they can install a service file ;)
<raghav-gururajan>nckx What I meant by agree was that I realized that my thinking was wrong.
<nckx>leoprikler: I agree, those are just bugs (and not related to systemd, really).
<raghav-gururajan>Also, I don't see why GNOME started adopting sysd techs anyway, The gnome were trying to reduce the weightness of their stack and also reduce load on memory usage.
<raghav-gururajan>Not sure, if adding sysd, try to ease it or even make it hard.
<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.
<raghav-gururajan>nckx I understand.
<dctrud>nckx: That's a nice take. 'freedom' does not mean people owe you anything. But it seems people often feel the dev is obligated to enable their own take on freedom, rather than just permit it.
*nckx does not agree with your systemd dependency, but will defend…
<sirgazil>raghav-gururajan: Does GNOME Contacts starts for you? I get this error (Spanish, though):
<raghav-gururajan>sirgazil Yeah, It works good on my end.
<raghav-gururajan>Let me see your pastebin.
<leoprikler>IIRC adding logic into systemd (specifically logind) made DMs such as GDM focus more on the aesthetic side, as they no longer had to implement login on their own.
<raghav-gururajan>sirgazil Intresting. Can you send me you system config?
<leoprikler>is EDS a part of gnome?
<raghav-gururajan>Yes, EDS is a core-deps
<leoprikler>If so, it would appear as if evolution is needed for Contacts to work.
<raghav-gururajan>*is in
<leoprikler>W.r.t. gnome vs. gnome-minimal, I'd add Evolution to gnome either way and keep both out of gnome-minimal.
<raghav-gururajan>nckx dctrud leoprikler Thanks for your sound arguments. It made realize that I was being misguided about sysd.
<sirgazil>raghav-gururajan: are you interested in a particular section of my system config?
<raghav-gururajan>sirgazil packages and services.
<nckx>raghav-gururajan: Thank you for the effort you're putting into GNOME on Guix, and for taking care of any new bugs 🙂
<leoprikler>sirgazil: does it go away if you install evolution locally?
<raghav-gururajan>sirgazil Thanks!
<raghav-gururajan>nckx My pleasure :)
<sirgazil>leoprikler: I'll check...
<dctrud>Ditto nckx's sentiment! Thanks raghav-gururajan. I don't use Gnome DE, but use various apps a lot!
<sirgazil>Yeah, installing GNOME documentation, for example, solved some bugs I had on my issue list.
<sirgazil>I mean, packaging GNOME documentation
<leoprikler>you could probably also propagate evolution from contacts, but that's a bit backwards imo
<raghav-gururajan>leoprikler Hmm! I tested contacts without EDS. It worked.
<nckx>dctrud: Me too (if seldom).
*raghav-gururajan still not able to understand the ditto<-->sentiment. :-D
<dctrud>oh sorry. I agree/say the same thing that nckx said.
<raghav-gururajan>sirgazil I'll tinker with contacts and get back to you.
<sirgazil>raghav-gururajan, leoprikler: I installed evolution and contacts does not run.
<sirgazil>Same error
*sirgazil has more bugs for the rest of the week :)
*sirgazil has more bugs to entertain raghav-gururajan for the rest of the week :)
<raghav-gururajan>sirgazil Okay.
<raghav-gururajan>sirgazil Haha~ true
<leoprikler>my guess was wrong then
<mehlon>bonjour guix
<raghav-gururajan>sirgazil Wait a sec! You said you installed evolution. But that evolution-data-server is the package I was taking about.
<nckx>o/ mehlon.
<raghav-gururajan>mehlon Hey
<raghav-gururajan>sirgazil Could you try contacts with evolution-data-server installed alongside?
<leoprikler>wait a sec, let me less my config.scm
<leoprikler>yep, got an extra entry for e-d-s
<leoprikler>you goofed me, raghav-gururajan
<mehlon>hmm I wonder if there's a good client for staying connected to irc
<mehlon>what were they called again, idlers?
<leoprikler>I just let polari run
<leoprikler>I think you mean bouncers like bnc and znc?
<raghav-gururajan>leoprikler LoL no. I tried contacts without EDS. It worked.
<mehlon>ah yes, thank you leoprikler
<raghav-gururajan>I just wanted to see if e-d-s does anything on sirgazil's end.
<mehlon>I'll install one of these on my new and improved raspberry pi
<raghav-gururajan>because I never seen that error on my side.
<leoprikler>raghav-gururajan: if e-d-s fixes their problem, then you goofed yourself
<nckx>mehlon: Guix has a ZNC package but not a service yet. Still, it's what I use to lurk here.
<raghav-gururajan>leoprikler May be or may be not.
<mehlon>hmm, GNOME3's animations are making me motion sick!
<leoprikler>you can disable them afaik
<sirgazil>raghav-gururajan: You mean install EDS in my profile? And do I have to do anything to my system config too?
<mehlon>I'll try that
<bandali>i think xfce should be the default desktop
<mehlon>sneek, XFCE is the standard desktop environment!
<mehlon>almost forgot...
<mehlon>sneek, ed is the standard text editor! Ed! Ed! Ed!
<sneek>I'll keep that in mind.
<leoprikler>the standard desktop example has both gnome and xfce
<leoprikler>sneek what is ed?
<sneek>From what I understand, ed is sed for children.
<leoprikler>sneek, botsnack
<mehlon>who did this to sneek?
<mehlon>I shall never forgive
<raghav-gururajan>I still don't understand why standard desktop example has both gnome and xfce.
<nckx>sneek: That doesn't even make sense.
<nckx>raghav-gururajan: Why not?
<mehlon>gonna restart
<leoprikler>I actually think it's a very good standard.
<leoprikler>You kick the one you don't like and are happy with the other.
<apteryx>nckx: haven't dug what's at cause exactly yet, but nothing changed in my config. I can try rebooting to a previous Guix to see if it still works as I remember it.
<apteryx>then revert.
<leoprikler>Or you leave them be for multi-user setups where people disagree.
<apteryx>(test the revert, that is)
<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?
<nckx>sneek: What is GNOME?
<raghav-gururajan>nckx Why? It's like having Kodi and VLC.
<leoprikler>no its not
<nckx>raghav-gururajan: I don't understand MPV 4 EVER that reference since I don't know Kodi.
<sirgazil>sneek: GNOME is the GNU desktop environment.
<sneek>I'll keep that in mind.
<raghav-gururajan>nckx No, not like bad vs good. In sense of overdoing. May be it was meant use for different scenarios?
<leoprikler>nckx: basically they're both video players with a bunch of features
<leoprikler>But you're not overdoing things by offering multiple options.
<nckx>raghav-gururajan, leoprikler: Thanks. I don't see the problem with having different supported ‘standards’ since people get downright religious 'bout this shit but I don't really have an opinion.
<raghav-gururajan>YEah, options are always good. But all options enabled at the same time?
<leoprikler>It's like having both Firefox and Chrome in a corporate web development environment.
<nckx>raghav-gururajan: Doesn't GNOME have 2 browsers? 😛
<nckx>Epiphany and whatsherface.
<raghav-gururajan>nckx I do not think so.
<leoprikler>I don't think eolie is considered a GNOME standard tho.
<leoprikler>It's rather a side project by some GNOME-adjacent enthusiast.
<raghav-gururajan>currently, only epiphany is part of the core. eolie is still under world. But aimed to replace the former.
<nckx>I dunno, I was just asking, Raghav's the one with the cool spreadsheet. Nice work by the way.
<leoprikler>Eolie has a long way to go before it can replace epiphany, particularly in the UI.
<nckx>raghav-gururajan: So World is… written by GNOME folks but not considered canonical? Or just ‘outside’ programmes that integrate very well?
*raghav-gururajan is also planning to do similar spread sheet for Xfce.
<nckx>Also thanks for not using Froogle dox.
<leoprikler>World is projects from all over the world (inside and outside of GNOME) that don't follow the GNOME release cycle.
<raghav-gururajan>nckx world is like community repo in conventional distros.
<leoprikler>Back to Eolie: Tabs on the side, what is this? Ubuntu?
<raghav-gururajan>The projects there are community started projects which may or may not become part of core GNOME.
<nckx>But approved by GNOME? I mean, a distro repository does a technical thing; while GNOME saying ‘this is part of our World’ is just a seal of approval unless they start shipping things themselves.
<nckx>raghav-gururajan: OK, thanks.
*nckx singing Little Mermaid songs now.
<raghav-gururajan>There is no too much restrictions to add a project into the world. It just should somehow related to GNOME.
<sirgazil>raghav-gururajan: Installing evolution-data-server solved the problem.
<raghav-gururajan>sirgazil Good for you. Bad for me. :-D. I have to figure out how it worked for me without EDS.
<sirgazil>raghav-gururajan: It also solved a problem I had with GNOME Calendar, where I could not add events.
<sirgazil>GNOME Calendar was useless before installing EDS
*kmicu thinks someone wants to improve GNOME on Guix but difficult to tell xD
<raghav-gururajan>kmicu I do. ;-)
*raghav-gururajan is an idiot. he made sure EDS was not mentioned in the system config, but forgot to check user profile. xD
<raghav-gururajan>leoprikler Yep! I goofed myself.
<raghav-gururajan>sirgazil All good. I will patch them to propagate EDS.
<sirgazil>Thanks again :)
<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! ʕノ•ᴥ•ʔノ ︵λ𝛌𝚲𝝀
<bavier>anyone try packaging "anbox" yet?
<raghav-gururajan>kmicu Thanks! Yeah, even though I use GNOME, my drive is to bring more newcomers into guix. So doing my best :-)
<sirgazil>kmicu: That's why GNOME is important. It is not for people satisfied with CLIs and half-assed window managers; it is for the average Jane.
<nckx>kmicu: Why does that bear hate gammas so much?
*nckx will show themselves out.
<kmicu>Hate gammas‽ I throw the power tool of lispers at raghav-gururajan — assortment of lambdas.
<raghav-gururajan>kmicu I have not learned lisp yet. But I started to see its power.
<kmicu>(Though I would rename Hacker News to Hate Gammas.)
<nckx>kmicu: Those filthy gamma cucks. It was a silly based on the fact that my brain substitutes an upside-down table, and hence upside-down lambdas…
*sirgazil 's favorite story about Lisp is that one about the Remote Agent software on NASAs Deep Space 1, but haven't experienced himself the live programming lispers and schemers talk about.
<leoprikler>A table with many legs
<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
<raghav-gururajan>Bye Guix!
<sirgazil>raghav-gururajan: Bye
*raghav-gururajan ---> Zzz
<nckx>raghav-gururajan: o/
<mehlon>I must say, running Nix and GuixOS... hmm yes pretty decent
<nckx>leoprikler: Business aside, that sounds like fun. Risky fun perhaps, but then so is restart && pray.
<nckx>‘Guix: it's pretty decent’.
<nckx>We really need a testimonials page for these gems.
<leoprikler>It's really like configuring your Emacs as you write a program.
<mehlon>sneek, what is guix?
<sneek>I could be wrong, but guix is a functional package management tool for the GNU system
<mehlon>sneek, what is GNU?
<sneek>Someone once said GNU is not Unix
<leoprikler>very helpful
<kmicu>mehlon: it’s Guix System; Guixos is a greek god of reproducibility.
<sirgazil>Oh, great!! Finally!! Bug #35589 for qt-based applications :)
<mehlon>bah, but I don't like it! Guix OS is the logical name for it
<davexunit>at least it's not guixsd anymore!
<leoprikler>well, better than GuixSD
<mehlon>or Guix Free Software Distribution Guile/Shepherd/GNU/Linux-libre
<davexunit>(couldn't give it a good name initially due to objections by RMS)
<sirgazil>I mean, the bug is gone for qt-based applications. I can use Scribus and Pencil2D now.
<kmicu>Operating system is not accurate cuz we operate on mutable distros to fix broken updates. Guix is just System, no stressful operations required.
<mehlon>Guix: une interestinge Xysteme!
*bandali quite likes Guix System
<nckx>So do I. It's more than an OS.
<mehlon>like 'schemer', but... yknow, guix
<raghav-gururajan>Before I fall asleep, I wanted to ask if any of committers available for Thanks! :-)
<oriansj>when you have multiple Guix systems: guixen
<nckx>a chilling tale about stateful dotfiles.
<mehlon>dotfiles: not even once
<nckx>Ricardo makes the best slides:
<kmicu>That’s art for future Guix Gallery.
<nckx>(Why yes I am trolling image search engines for ‘Guix’. And good news: it's more GNU Guix and less pictures of Iberian chalk every year.)
<kmicu>[Content Warning: Erotica] For sure better than
<mehlon>all I see on duckduckgo is a bunch of people playing music instruments
<nckx>mehlon: That ‘logo’ was used by a (tiny) Belgian municipal coalition during the previous elections. I had to stop cycling and laugh.
<mehlon>kmicu: omg
<mehlon>kmicu: and it's french as well! hon hon
<nckx>kmicu: HAHAHA
<sirgazil>The operating system part of the Guix project was supposed to be called simply GNU, but the chief didn't think it was appropriate. It was dissapointing for me.
<mehlon>shouldve been called LISP
<oriansj>mehlon: then no one would have used it
<mehlon>I'm trying to find a good reaction gif
<oriansj>especially given the amount of SCHEMING required to just get the project started
<mehlon>maybe just call it EmacOS
<oriansj>Isn't there a Pizza parlor in Thailand called that?
<mehlon>maybe hide the 'o' a little: Emacₒs
<mehlon>now people will install it thinking they'll get emacs and voila! a new user
<oriansj>or make it so big it is missed (EmacS)
*sirgazil goes for a run (and to think how to separate Guix System from the "GNU Guix software environment manager")...
<oriansj>sirgazil: gentoo?
<oriansj>as guix is effectively gentoo for people who have shit to do
<vagrantc>nckx: any idea where that is?
<nckx> (Creation Date: 2012-12-12T20:22:51Z) (Guix initial commit: Wed Apr 18 23:21:11 2012 +0200)
<nckx>So that's 3 Guixes in 2012 so far. What was in the air.
<vagrantc>nckx: what's the third?
<mehlon>well I'm not sure what's going on but I put the mate desktop in my config.scm but now I'm back in gnome
<nckx>Eh, a reg'd trademark so don't let's talk about them.
*nckx shouldn't have brought it ut.
<apteryx>nckx: turns out my udev daemon had crashed for some reason
<apteryx>the android rules are fine
<mehlon>anyone here running Nix on top of Guix System
<mehlon>I'm having trouble setting up the PATH, there should be a file in /run/current-system/profile/etc/profile.d/ but it's not there
<nckx>apteryx: Oh, that's weird. Thanks for reporting back!
<apteryx>thanks for keeping them up to date!
<nckx>Dear lazyguix: should I order a new SSD (SMART says it's used but good) or check my cables or ignore it or something else:
<nckx>It doesn't *look* flash-related.
<mehlon>maybe download more ram first
<nckx>mehlon: I would but IceCat breaks ☹ (The animations at least.)
<vagrantc>restaurant es guix in majorca seems a bit of a fancy place
<nckx>Oh, now it works, thanks mehlon! I'm going to download some more RAM to a USB drive just in case.
*vagrantc blinks
<mehlon>good, it's always good to have RAM handy if you want to spin up a game of minecraft (minetest?)
<nckx>Or guix pull.
<mehlon>yep :3
<nckx>‘The most dangerous game™’.
<mehlon>LinusTechTips voice: "got this new gaming rig, 20 GHz, quantum liquid cooling.... a few terabytes RAM. yep, this baby can definitely guix system reconfigure in less than a few hours"
<mehlon>speaking of, my guix system reconfigure is ready, brb
<nckx>Your scientists were so preoccupied with whether or not they could guix pull at that speed. They didn't stop to think if they should.
<g_bor[m]>hello guix!
<g_bor[m]>I am trying to modify a service that extends shepherd-root-service so that it depends on additional shepherd services. However it seems that I can't easily modify that...
<g_bor[m]>Anyone knows what to do in this case?
<nckx>2020 will be the year I finally learn how to write a service.
<g_bor[m]>ok, it seems that I can get it ultimately...
<nckx>g_bor[m]: If you have the time, could you share your solution? I'd be grateful.
<nckx>Mainly because I said the same thing about 2019.
<g_bor[m]>nckx: ok, i am at the repl right now.
<g_bor[m]>it looks like you can get there step by step...
<mehlon>hmmm.. I wonder if I could have NixOS and Guix System on the same partition...
<mehlon>and they get to alternate who's in charge of /etc
<mehlon>it *might* work
<nckx>mehlon: You like debugging, don't you.
<mehlon>look, if I'm not actively breaking my computer programs I have nothing to do
<mehlon>it's my raisin day etre
<mehlon>and if it did work it'd be really awesome
<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.
<mehlon>I do see a few problems right away: /etc/hostname and /etc/password among others are not symlinks
<nckx>Ah, right, /etc/password, didn't even think of that.
<nckx>*passwd, how wasteful of me.
<mehlon>they are symlinks on NixOS though, although I'm not sure if they are re-instated on boot
<nckx>mehlon: Symlinks to what?
<mehlon> /etc/profile is a link to /etc/static/profile
<mehlon> /etc/static is itself a symlink to /nix/store/zwn2w....../
<nckx>But passwd?
<nckx>That needs to be stateful and can't be in the store.
<nckx>(It can, but that rather defeats the purpose of the shadow model.)
<mehlon>actually that is not a symlink and neither is os-release
<nckx>Anyway, I'm sure that for each conflict there's a way you can carefully manage things so they ‘work’, but we've only just started and already (IMO) deep into ‘is this worth it’ territory.
<mehlon>it's better to have separate /etc directories, which might be accomplished with user namespaces
<nckx>Personally: the reason I fell in love with NixOS (and then Guix) was a ‘sleeping better at night’-factor that I didn't know was attainable in the bad old days.
<mehlon>of course my goal is to reuse the /gnu and /nix store between NixOS and Guix (which I'm sure can be accomplished in other ways too.
<nckx>Your life obviously lacks excitement and mortal danger and I respect your search for it but it's not something I can help you with.
<mehlon>ah don't worry I'll figure it out
<nckx>Be safe out there.
<nckx>* mehlon has quit (fire, screams)
<mehlon>another way is to make NixOS mount the guix partition and reuse its /nix directory
<dejanr>hi, one question regarding AGPL and guix, if i use guix to package my web app, and deploy it to some host by using guix tools, does that mean that i have to open source my web app?
<mehlon>only to everyone who visits it
<mehlon>no wait
<mehlon>the guix licensing does not carry over to its packages as far as I know
<nckx>Guix is also not AGPL?
<str1ngs>guix is GPL3 as far as I know
<nckx>Yes. dejanr: what am I missing?
<mehlon>we website for Guix is AGPL but guix is not
<yrk>an entire operating system is not licensed (typically) under a single, umbrella license
<str1ngs>the website being AGPL makes sense
<yrk>instead, it is a collection of many individual pieces of software
<dejanr>aha gotcha, thanks
<nckx>dejanr: There are (probably) packages in Guix that are AGPL but they are AGPL anywhere else and not something we can change.
<yrk>each of those have their own license. in the case of a fully free OS, all are under a free license, and the parts that need to interact under compatible free software licenses
<mehlon>actually an operating system *is* typically licensed under an umbrella license but free software operating systems are different
<yrk>mehlon: nope
<yrk>mehlon: an operating system consists of a kernel and many bits of software
<nckx>The term ‘operating system’ is too vague to discuss this meaningfully.
<yrk>mehlon: it is very rare for all of those to be under a single license
<nckx>To most BSD people, that would be a strange remark.
<yrk>mehlon: especially in the free software world
<yrk>nckx: not really
<yrk>nckx: if you look closely, you'll even find variations of the various bsd licenses within a bsd distro
<dejanr>what's the downside of GPL for companies?
<yrk>nckx: (not to mention other bsd-like lax licenses)
<mehlon>I'm thinking stuff like plan9 or windows or macos which are licensed as one even though its components are also licensed under others
<yrk>mehlon: proprietary OSes are similar, but they are typically a collection of proprietary parts that have been payed for under various agreements.
<mehlon>dejanr: I guess the only 'downside' is that they don't get to keep their monopolistic control over the software...
<mehlon>which is arguably a downside even though it's good for everyone in the long run
<yrk>mehlon: and macs are infamous for being a, in my opinion, unholy union of free software with proprietary
<yrk>so in all of those cases a modern OS, which is often a huge collection of software, is a collection of individual pieces with their own licenses
<yrk>I'm guessing that very small, monolithic OSes could conceivably be small enough to be written by one entity, and licenses all "in one go" so to speak
<yrk>but I'm not very familiar with embedded and small OSes
<dejanr>e.g. if i have a web app, or SaaS product, and heavily depending on guix for building/deploying, making it reproducible, what would i have to do to comply with GPL in this use case?
<mehlon>pretty much nothing at all I think
<yrk>dejanr: if the parts you are using are under the gpl, you only need to comply with the terms of the license if you further distribute those parts, see:
<yrk>dejanr: if your clients are interacting with a part which is under AGPL, then that is different
<dejanr>yrk: but i am not modifying guix when i package my app?
<mehlon>a SaaS that uses a GPL-licensed software, does not need to release its sources
<yrk>dejanr: it doesn't have anything to do with modifying
<dejanr>yrk: nor distributing
<yrk>dejanr: as in the FAQ, if you aren't distributing GPL'd software, you don't need to do anything
<yrk>dejanr: the gpl explicitly permits you to run the software for any purpose
<mehlon>you don't even need to release the package scheme file
<yrk>dejanr: that includes for-profit activities
<yrk>dejanr: the agpl is different in this key regard
<yrk>dejanr: so just make sure you know what the license is for the part your clients interact with
<yrk>dejanr: the FAQ addresses this question directly
<dejanr>yrk: this FAQ is what i need, thanks
<yrk>dejanr: if you need to ask more long-form questions you also have the option of writing in directly to the fsf's gpl compliance at
<g_bor[m]>somehting like this should work.
<g_bor[m]>not tested, and modulo typos :)
<mehlon>how much RAM does guix need in general?
<NieDzejkob>I don't think it's particularily RAM intensive, you would probably do fine with whatever works on distros like Debian, say, 4gb
<NieDzejkob>though it's not an amount of RAM I would recommend for any computing purposes
<mehlon>I was just wondering because I think guix got signal 9'd because it filled up an entire GB of ram
<mehlon>on my raspberry pi
<kmicu>dejanr: please consult your situation with a person with expertise in licensing because a lot of written above is not accurate.
<nckx>mehlon: 1 is quite low for Guix nowadays. You should definitely not build anything in parallel, and even then…
<mehlon>I'll just swap it up
<mehlon>same thing happened when I tried nix....
<mehlon>but nix has no substitutes available at all so I won't bother with that anymore
<mehlon>.. for armv7l
<leoprikler>Does raw gst-play-1.0 work for anyone here?
<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.
<mehlon>well it failed on doing guix pull....
<mehlon>so that's guile's fault
<mehlon>maybe I could guix pull remotely..... or
<mehlon>um yeah that could work
<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.
<mehlon>I was thinking of doing a remote chroot
<mehlon>plan 9 style.
<mehlon>nckx: what's the method for 'offloading' on guix?
<nckx>mehlon: Start by reading ‘info guix offloading’ if you haven't yet done so.
<mehlon>ah that could work
<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.
<mehlon>yes... yes...
<mehlon>exactly what I need
<nckx>I've only done it for x86 though, so much will depend on the emulation quality of the qemu-binfmt-service, assuming your ‘big’ machine is not arm7, which seems likely.
<mehlon>do I need any additional setup for qemu-binfmt?