IRC channel logs


back to list of logs

<stikonas>nckx: well, it's not really a daemon, it's kauth which is a wrapper around polkit. Basically in polkit world you have a non GUI app which can call small executables running as root when it needs to do some privileged operation
<stikonas>e.g. update some root owned file, change some system configuraion, do something with disk
<nckx>stikonas: OK, now we're talking.
<nckx>(Modulo the JavaScript 🙂 )
<nckx>Thanks for the clarification.
<stikonas>well, GUI running as root means much larger code footprint running as root
<nckx>I've never used Unetbootin, but doesn't Gparted do that, too?
<stikonas>nckx: yes, gparted does that too...
<stikonas>but Gnome disks don't do that
<stikonas>and neither does KDE Partition Manager
<A`>hello. I've tried to integrate this channel with Matrix room, with request integration option in Matrix.
<A`>Matrix bridge: 'No chanops found in channel!'
***ChanServ sets mode: +o nckx
<nckx>A`: I'm not good enough? ☹
<nckx>What strange requirement anyway.
<A`>Now it works, but: 'Failed to make link: Timed out'
<A`>Do not know what's the reason.
<nckx>I've tried to use Matrix 3 times and always got a new & exciting error message. Yet obviously dozens of people successfully do it.
<A`>(Channel key is empty in integration options)
<A`>Is it needed for integration?
<nckx>I don't *want* permanent ops in #guix TBH… I like the Freenode tradition of not flashing badges.
<nckx>A`: key as in +k?
<nckx>We've never had that set.
<A`>I just few times on IRC.
<A`>Matrix user for some years.
<nckx>I'm the opposite so sorry I can't be of more assistance, but thanks for doing whatever you're trying to do 🙂
<nckx>If there's anything I can do to help I'll do my level best.
<A`>OK. There is IRC Matrix Bridges room on Matrix. I'll try to ask there about.
*nckx is up to rust@1.25 in the Rust chain ♪ happy dance ♪
<jonsger>nckx: cant mrustc build rust@1.29 now a days?
<nckx>I dunno, I'm just building it, not hacking on it.
<nckx>jonsger: Or do you mean in Guix? Because this relatively fresh checkout has been happily bootstrapping from 1.21 IIRC.
<jonsger>nckx: I didn't get your last question
<nckx>jonsger: I didn't get yours. Do you mean that mrustc can now compile rust@1.29 and Guix still needs to adapt to that, or that current Guix should *already* compile 1.29 directly with mrustc?
<jonsger>nckx: the first
<nckx>So I meant that I was just bootstrapping Rust to use it, not to work on its Guix packaging.
***insertsquirrel is now known as insertnextprogra
***insertnextprogra is now known as scaredysquirrel
<scaredysquirrel>how do I get the source using guix for any package p
<leoprikler>guix build [-S | --source]
<scaredysquirrel>ok it got all of that but I can't access or see the tar file it downloads
<leoprikler>it should output a /gnu/store path
<scaredysquirrel>it did but I can't get to that path
<leoprikler>what was the full command?
<scaredysquirrel>ah it's a temporary file
<scaredysquirrel>ok so you just tell tar with tar -xavf $(guix build -S thepackagename)
<leoprikler>not sure if source files are always .tar.gz
<leoprikler>or tar.xz
<nckx>They're not, and often not even files.
<leoprikler>but e.g. for emacs you get /gnu/store/[hash]-emacs-[version].tar.xz
<nckx>They are also not temporary at all, unless you mean ‘all things are temporary and must die’ and/or ran guix gc.
<leoprikler> /gnu/store is finite
<nckx>leoprikler: All packages with snippets are repacked as .tar.xz no matter what upstream uses, and SCM checkouts are directories.
<nckx>leoprikler: Speak for yourself.
*A[m]2 sent a long message: < >
<leoprikler>Good to know.
<leoprikler>Tbh. I'm kinda worried that Git will come to bite us in some years.
<leoprikler>(note: hash collisions)
<nckx>A[m]2: Could you split your message into smaller parts next time? It appears here as an external link, which is a bit… gneh.
<nckx>leoprikler: For sure. There's work underway to move to $new_hash, which will probably be painful and of course never broken itself.
<nckx>A[m]2 said: Solved problem with integration #guix with [matrix] room.
<nckx>Great! So I can deop now?
<nckx>A[m]2 said: Topic of #guix: Savannah servers under attack: try and try again... Didn't know it few days ago when tried to install guix on Arch Linux.
<nckx>Yeah, not sure how best to advertise that. It seems to be winding down (cross fingers) or I'd suggest adding a warning to the download page.
<A[m]2>> Could you split your message into smaller parts next time?
<A[m]2>ОК. I did't know it - will write shorter.
<nckx>Also no need to Matrix-quote on IRC 🙂 People don't expect it here.
<nckx>A[m]2 said:Is it official mirror? (Didn't meet mention of it on Guix site) I'd used mirror on GitHub in url parameter of guix pull:
<nckx>It's *not* official, although it happens to be run by a Guix maintainer. They don't want it to have any special status though. Treat it as any other random untrusted mirror you find on the Internet.
<A[m]2>without this mirror it was not hope to install guix.
<A[m]2>always 502 or 504 for Savannag git repo.
<nckx>All Guix commits have been signed for quite some time.
<nckx>A[m]2: I know, it sucks ☹
<nckx>Someone was working on an official mirror (on but I haven't seen them today.
<nckx>It's not updated live though.
<A[m]2>Is there description how to get pull data from IPFS.
<A[m]2>(It will be more stable to use I think - no DDOS problem)
<A[m]2>Or this solution is just good idea still?
<nckx>A[m]2: Only an idea…
***ChanServ sets mode: -o nckx
<nckx>A[m]2: It's an idea that qualifies for a (paid) interships if you're interested & qualify for Outreachy!
<nckx>A[m]2: Did you talk with the Matrix people about the ‘a bridged channel must always have a visible operator [=administrator]’ requirement? That doesn't sound right to me.
<A[m]2>I asked about it but there no answer for this moment.
<nckx>OK. Thanks for asking, please let me know what they say.
<nckx>There's no MatrixBridge user here now. Maybe they fixed it some other way.
<A[m]2>I see this user in [matrix] room.
<A[m]2>IDK how it works.
<A[m]2>About IPFS repo: I saw some project on GitHub with solution but didn't check it.
<nckx>A[m]2: We've had quite a few [m] Matrix users in here (#guix) for years. What's different about this new bridged room?
<A[m]2>As I understand, all this users (including me) are bridged personaly to IRC chat.
<A[m]2>I wanted to create public [matrix] room and integrate it with IRC chat #guix.
<A[m]2>(Didn't know about other possibilities)
<A[m]2>As I understand, operator's rights are needed for variant I tried to do.
<nckx>Nice. And gotcha. So it was complaining that you were not an op, with the worlds most misleading error message.
<nckx>[Angry Schemer] That's *our* territory.
<A[m]2>No. I think it works something like this: chanop must get request from appservice-irc to bridge chat with room somehow.
<A[m]2>Will see when developers of this service ansver.
<A[m]2>For installation of Guix on Arch Linux I used this instructions:
<nckx>Oh, OK. I got no requests, the thing just quit. Thanks for doing this, even if I still don't get the difference 🙂
<A[m]2>But I can run guix as root only.
<A[m]2>How to install something for ordinary user.
<nckx>That's unofficial documentation that I've never heard of before, but at a quick glance look like it sets up the right things for every user. Did you reboot? Is $GUIX_PROFILE not set for you?
<nckx>That's assuming that /etc/profile.d/ does what I guess it does: get sourced by every user when they start a new log-in shell.
<A[m]2>yes, rebooted since that time.
<A[m]2>echo $GUIX_PROFILE:
<A[m]2>empty line.
<nckx>Oh. Let me read that guide again.
<A[m]2>Maybe reason is in file permissons of
<A[m]2>-rw------- 1 root root
<nckx>A[m]2: Can you run ‘/var/guix/profiles/per-user/root/current-guix/bin/guix pull‘?
<A[m]2>as ordinary user?
<nckx>Can't say much about those permissions, Guix System doesn't use /etc/profile.d.
<nckx>It should be at least ‘chmod 644 /etc/profile.d/’, though. Read only for root can't be right.
<nckx>So chmod and pull and log into a new shell & see if you have a ‘guix’ command now.
<A[m]2> /var/guix/profiles/per-user/root/current-guix/bin/guix pull
<A[m]2>bash: /var/guix/profiles/per-user/root/current-guix/bin/guix: Permission denied
<nckx>A[m]2: And $HOME/.config/guix/current/bin/guix ?
<nckx>(Disclaimer: I only use Guix System, so this is a foreign land to me.)
***scaredysquirrel is now known as darknop
<A[m]2>I did chmod 644 for and rebooted, but:
<A[m]2>bash: guix pull: command not found
<A[m]2>bash: /home/a/.config/guix/current/bin/guix: No such file or directory
<A[m]2>guix installed in /root
<nckx>‘bash: guix pull: command not found’ is weird, should just say ‘guix’ but never mind. Can you run ‘/root/.config/guix/current/bin/guix pull’ as your regular user?
<nckx>According to that article ‘/usr/local/bin/guix’ should exist, but /usr/local/bin should already be in your $PATH so something is not as it should be.
*A[m]2 sent a long message: < >
<leoprikler>A[m]2: please don't use multi-line messages. Matrix really does not want to send them to IRC.
<A[m]2>guix pull: - I wrote it manually.
<A[m]2>‘/root/.config/guix/current/bin/guix pull’ - permission denied
<A[m]2>it's link to
<A[m]2>and /gnu/store: drwxrwxr-t root guixbuild
<nckx>A[m]2: And running /gnu/store/4qvpdgmkk7wjq8h4hmv0zc1j71m0j80k-guix-command pull ?
<A[m]2>leoprikler: sorry, it's habits unadequate to IRC. I forgot.
<A[m]2>nckx: permission denied
<leoprikler>just out of interest, what are the permissions for /gnu/store/4qvpdgmkk7wjq8h4hmv0zc1j71m0j80k-guix-command?
<nckx>That is not right. ☝ do that.
<nckx>It should be -r-xr-xr-x.
<nckx>I'm also interested in the output of: ls -ld /gnu /gnu/store
<A[m]2>-r-xr-xr-x 2 root root
<nckx>For …-guix-command? OK.
<A[m]2>and for /gnu/store: drwxrwxr-t root guixbuild?
<nckx>And /gnu?
<nckx>(The 1st argument.)
<A[m]2>drwx------ 3 root root
<nckx>Should be drwxr-xr-x or so.
<nckx>Ah! 🙂
<leoprikler>that's the problem
<nckx>run sudo chmod 755 /gnu.
<A[m]2>problem with installation script?
<A[m]2>works: /gnu/store/4qvpdgmkk7wjq8h4hmv0zc1j71m0j80k-guix-command pull
<nckx>Hmm, maybe, I guess so, but you're the first to report that which is odd.
<leoprikler>This is on Arch, isn't it?
<nckx>The installation script just moves the /gnu from the binary tarball.
<nckx>leoprikler: Yes.
<nckx>Does that ring a thing?
<leoprikler>No, but I suspect that the Arch people are likelier to discuss troubleshooting on their Wiki rather than making us know of their troubles :)
<nckx>Possible, I am not familiar with the Archenfolk and their strange ways.
<nckx>How Arch could make tar+mv behave differently boggles me.
<leoprikler>Well, you could first create /gnu with wrong permissions and then copy the store into that :)
<nckx>Some weird permissions on /tmp?
<nckx>I trust A[m]2 to tell us that and not mutter ‘some bug with the script?’ but I've always been too trusting.
<nckx>leoprikler: ☝
<nckx>Plus it won't run if /gnu exists so it would take some force.
<nckx>A[m]2: You didn't do anything naughty to /gnu yourself first, I trust?
<leoprikler>I mean you could do that as part of a script. Btw. which script is being used here?
<nckx>No, the script is Guix's.
*nckx looks up the name.
<A[m]2>nckx: I removed /gnu before running this script.
<A[m]2>and other files/directories mentioned here:
<A[m]2>and there was error running this script when /gnu existed.
<leoprikler>just out of curiosity, how would mv behave with a umask of say 077
<leoprikler>and would tar behave differently?
<A[m]2>nckx: I removed /gnu before running this script.
<nckx>A[m]2: Why sorry? Doesn't look like you did anything wrong.
<A[m]2>and other files/directories mentioned here:
<A[m]2>and there was error running this script when /gnu existed.
<A[m]2>nckx: multiline post once again...
<leoprikler>this one seemed to land as-is though
<nckx>A[m]2: Ah, but this time we saw it as just (multi) regular IRC lines though.
<leoprikler>perhaps it only complains about empty lines
<A[m]2>leoprikler: OK :)
<A[m]2>leoprikler: how to see current value of umask?
<nckx>So there's no feedback? You can't tell whether we see your message, or just a horrible ‘Your friend sent you a message! Click here to read it!’-style link? That's not good, Matrix.
<nckx>A[m]2: ‘umask’ 😉
<A[m]2>I see:
<nckx>Here (Guix System) it's 0022, then on Ubuntu (0002).
<nckx>Ah. Bingoids.
<A[m]2>this is the reason?
<nckx>What wild differences between distros.
<A[m]2>I set it (umask) manually, I think.
<A[m]2>long time ago.
<nckx>So the installer should just set its own sane umask.
<nckx>It's process-local so won't mess with ‘your’ umask.
<A[m]2>Yes or check it before installation.
<nckx>I guess 0022 is sane.
<nckx>A[m]2: Hmm, I'm all for honouring user choice but what's the use case for subtly different umasks here? I see only ‘shoot self in foot’ scenarios.
<A[m]2>is it enough to add it into installation script before running?
<nckx>Setting a custom umask for your documents $ /home/ makes sense. Keeping it when installing a system-wide package manager: probably not.
<nckx>Yes, that's what I'm suggesting.
<nckx>Unless someone knows it would break somehow.
<nckx>Works here…
<leoprikler>I think setting the mask explicitly is a + for reproducibility :)
<A[m]2>I think this script must be indepentednt of system umask setting.
<nckx>Seems like we're all in agreement, I like that 🙂 Will do.
<nckx>A[m]2: So do I.
<nckx>leoprikler: 😸 nice patch.
<leoprikler>The most important one this year :)
<nckx>I added ‘sl’ another year so I can accept that claim.
<leoprikler>ah, but what about sl | lolcat?
<nckx>Oh friend you read my flippin' mind.
<A[m]2>now guix pull works without root permissions.
<A[m]2>thank you.
<nckx>A[m]2: \o/ Happy to help.
*A[m]2 sent a long message: < >
<nckx>A[m]2: Another ‘A[m]2 sent a long message: <https://…>’ ☹
<A[m]2>I tried to find ricochet messenger in guix repo - there is no such packet.
<leoprikler>Pretty much RTFM
<A[m]2>I want to add it to guix.
<nckx>A[m]2: It's OK, I clicked it.
<A[m]2>Where to start to do it?
<A[m]2>Is it enough to RTFM?
<nckx>Just be aware that some people won't and will get annoyed.
<A[m]2>I need to fix my mistake. :)
<A[m]2>I understand.
<A[m]2>BTW how do you call guix - guix or Guix?
<A[m]2>I do not like to click on links too.
<nckx>It may seem rude (and maybe it is) but it interrupts many people's flow — they don't use a browser to IRC, so they don't like being forced to open one to read 3 lines of text. And I get that.
<leoprikler>if you're using the command, lowercase, if you're talking about the project as a whole uppercase
<leoprikler>(or the system/whatever)
<nckx>A[m]2: The name is just ‘Guix’. I use the same convention as leoprikler myself. Some people type in lower case all the time and don't differentiate.
<leoprikler>as you would e.g. for GCC and other programs
<leoprikler>tbh I'm pretty lazy in chat (IRC included), not like you two, who use punctuation correctly and uppercase the starts of sentences :)
<nckx>I compensate with moronic typos that make me sound illiterate 🤷
<leoprikler>Everyone can have a typo
<nckx>But I want them all.
<leoprikler>Typomon, gotta catch 'em all.
<A[m]2>I never use upper case on mobile.
<A[m]2>When I have keyboard - it's easier.
<nckx>Interesting. People have literally told me I'm on mobile because I type like this.
<nckx>(I never mobile.)
<leoprikler>A[m]2: Back to your question. You'd start by `git pull`ing the Guix repo, then adding your package definition wherever appropriate.
<A[m]2>I think it will be not so soon. :)
<leoprikler>Be warned though, that git pull is currently somewhat hard thanks to the DDoS.
<A[m]2>I installed Guix because AUR ricochet didn't assembled as before. :)
<A[m]2>pull to Savannah?
<nckx>A[m]2: Would you like to be credited (Reported-by: …) in the fix? If so, under which name? Nickname is fine too. So is ‘no thanks’.
<A[m]2>A. (
<A[m]2>if A. isn't short for nickname.
<nckx>It's short, but that's all right. ‘A. ( on #guix’.
<nckx>Bug fixed. Not bad for day 1.
<A[m]2>Do you use Emacs for editing .scm?
<nckx>I do.
<nckx>Having an editor that can at least indicate or otherwise count brackets is IMO a must.
<A[m]2>Which packages do you use for it?
<nckx>I use hardly any packages, and none of them for editing Scheme, I think.
<nckx>I see stuff like electric-pair-mode in my .emacs but no special packages.
<nckx>It's all mail-related.
<nckx>leoprikler: Not worth sending a mail: after-line comments use a single ; tests don't exist
<A[m]2>I mean minor-modes, not packages, of course.
<A[m]2>electric-pair-mode is what I asked for, will be helpful, I think.
<nckx>A[m]2: Packages made sense too. There are packages like rainbow-delimiters (I think) that are probably helpful to some. Just not me.
<nckx>A[m]2: Once your brackets even out, C-M-q is your greatest friend. 🙂
<atw>qq: I often do things like guix environment --ad-hoc emacs-something -- emacs but of late the launched instance of emacs doesn't seem to recognize that the package is in the environment. Is this related to that EMACSLOADPATH thing? What's the best way around this? I'd be ok with "you should be using a profile"
<nckx>atw: qq?
<nckx>I know Latin and spooky Chinese companies but neither seem to fit.
<atw>quick question
<A[m]2>nckx: I can't do C-M-q on terminal Emacs.
<A[m]2>(No Meta key)
<atw>though that's a bit presumptuous of me
<nckx>atw: Ah. No, now I'm annoyed I should've seen that.
<atw>A[m]2: tap ESC, then C-q ?
<nckx>A[m]2: No Meta key? Srlsly?
<atw>nckx: terminals are weird
<atw> is good
<nckx>I completely agree, but I'm curious now 😛
<atw>(wtf every time I post that link catern is in the channel :P )
<nckx>Or at least morbidly fascinated.
<nckx>As a prolific user of terminal emacs myself.
<atw>it would be nice if emacs' HELLO file included some APL
<nckx>atw: That does sound exactly like the EMACSLOADPATH ‘bug’. I don't know the best work around.
<atw>shrug, I can probably work around it
<A[m]2>atw: ESC C-q in mini buffer (and nothing happens), not M-C-q.
<A[m]2>nckx: I mean ESC C-q is not M-C-q.
<atw>anyway, I may have to write an article about this to properly express my feelings, but I think that it's ridiculous that programmers have to do work by by emulating a device from the 60s, whose rich-text and Unicode abilities may be lacking.
<atw>Sorry A[m]2, I'm off-topic. I tried my own advice and it seems to work. Is it possible that the s-expression in front of the point is already indented properly? Is it different if you put the point before the top-level s-exp and then ESC C-q ?
<A[m]2>atw: - rare site at this times (without https).
<atw>seems like it was in my browser history as http://. Using https:// gets me an expired cert warning. catern, is your certbot running? :P
<atw>aww man gonna have to crank-call my friends and ask them that lol
<A[m]2>atw: yes, it works. (removed one bracket)
<mutoshack>Hi, I'm on 0.16.0 and just ran 'guix pull && guix package -u', but I got a "dependencies couldn't be built" error.
<Guixuser44>hello, getting this after running guix pull as a normal user: "Updating channel 'guix' from Git repository at ''... guix pull: error: Git error: failed to connect to is unreacable. I know privoxy on proxy-server locally works, as I have tested it with lynx on the same box, plus a
<Guixuser44>nother local machine. So the issue is how to configure this to work. I've set environment variables https_proxy and http_prxy to no avail.
<Guixuser44>DNS works btw, so domain responds to ping
<Guixuser44>sorry, does not respond to ping, as direct network is blocked.
<Guixuser44>I meant that the hostname resolves correctly to
<marusich>mutoshack, that's a bit rough. One possible way you might be able to get to the latest version is to try invoking "guix pull --commit=$some_commit", where $some_commit is a later commit. You would run "guix pull" commands like these to do it:
<marusich>So, you could try pulling version 0.2, then 0.3, then 0.4, etc. Or if you're feeling lucky, maybe you could try one in the middle.
<marusich>Guixuser44, if the network is blocked, Guix cannot clone the Git repository. It's basically running "git clone", I think, so you can probably try to reproduce the error yourself by running that command.
<marusich>If you run that command yourself, does it succeed?
<Guixuser44>Network is not blocked, its available over http and https on a proxy. git by itself gives command not found, and guix install git fails due to networking issues
<marusich>What about "curl -v"?
<Guixuser44>Uses proxy env variable https_proxy == 'https://blabla:8118 [...] ALPN, offering http/1,1 and hangs
<Guixuser44>It works fine from another computer in the network on the same local subnet. So it is not an issue with the local proxy server itself.
<Guixuser44>to clarify: if proxy is and guix is and other box is, then the ..10 box works fine with the http and https proxy on ...1, however guix box does not work as i want it to, might be becasue I do not have too much knowledge about guix, but trying to get to know it. I have googled this, but it is hard to figure out.
<Guixuser44> Also, it is very unfamiliar with going away from the standard /etc fiddling to configure services, but I will get used to it.
<marusich>I understand that the host has access, but I'm wondering if the host has access. Determining whether it does, was why I asked about git and curl.
<marusich>When you run "guix pull", it's either going to try to fetch the Git repository in the environment of your user or the guix-daemon; I'm not sure which. It sounds like you arranged to start the guix-daemon in an environment where http_proxy and/or https_proxy are set correctly, right?
<Guixuser44>curl gives expected output, so it has access to the proxy server.
<Guixuser44>-> It sounds like you arranged to start the guix-daemon in an environment where http_proxy and/or https_proxy are set correctly, right? <- I have tried to do this. Is there a way to verify it?
<PurpleSym>Hello guix!
<Guixuser44>I found a bindings.scm file, it has this text: ;;; FIXME
<Guixuser44>but the file is in /gnu/store/<hash>guile-git../share/guile/site/2.2/git
<Guixuser44>so guix pull uses guile-git?
<Guixuser44>and there's something called git_proxy_options , but I have no idea how to use it. Searvhing online gives not much info.
<Guixuser44>hi purple
<marusich>Guixuser44, I double checked the code for "guix pull", and it seems like it is fetching the Git repository using libgit2, in the context of your user's environment, rather than asking guix-daemon to fetch the repository on your behalf. Therefore, if you can run "curl -v", then "guix pull" ought to be able to reach the Git repository. Could you check that the curl command succeeds from
<marusich>FYI, the information here seems irrelevant for "guix pull":
<marusich>If you've set up your environment to use the proxy when you run commands like wget, curl, nc, git, etc., then it ought to probably work for "guix pull", too. If the curl command I mentioned works but "guix pull" doesn't, then I'm not sure what the problem is, and maybe if you could share more detalied output via, I could take a look.
<Guixuser44>yes, thanks for checking that, i cam to the same conclusion re libgit2. In fact that curl command does not work, it hangs with ALPN, offering http/1.1. From the other machine it seems to work. Curl version on guix is newer. Hm. gotta reeach the ALPN err
<Guixuser44>so obv something wrong with my setup. tremendously helpful you are btw. much apreciated. Trying to learn these new distros like whonix, guix and qubes. Its quite the adventure
<Guixuser44>well, they are not new... but for me they are.
<marusich>Everything is new to everyone at some point; feel free to ask lots of questions. That's how we learn :)
<Guixuser44>that's the spirit!
<Guixuser44>ok, one question. I realized it was possible to login to the guix server via ssh with a password. I would like to lock down this to allow only ssh key. So normally i would edit sshd config file, then reload service and all set. In guix i need to edit another file and 'rebuild' the system? Or how does that work?
<marusich>In Guix, the correct way to accomplish that is to change the operating system configuration file, and then run (as root, so you can write the bootloader and update various symlinks that only root has access to): "guix system reconfigure the-config.scm"
<marusich>As for how you modify the operating system configuration file, assuming you are using OpenSSH, you need to modify the configuration used by the service of type openssh-service-type.
<marusich>By default, you don't have an SSH server, so I guess you added one in your OS configuration. You can follow the example shown at "(guix) Networking Services" in the manual to modify the openssh-configuration:
<Guixuser44>ok, thanks. so the file to edit will be config.scm in etc? I did edit that file before, admittedly the workstartion guix is running on is not the fastest machine, but it took a very long time to complete. is that intended behavour? As compared to most other linuxes, you just edit sshd config file and restart the service. For instance, if you are ex
<Guixuser44>perimenting a lot with different setitngs in the sshd config file, then this method is not very expedient. However, I guess for such expermenting, a custom file and port should be used. It just seems overkill to rebuild everything for such a small change. But maybe there's a philosophy behind it?
<marusich>After you've run "guix system reconfigure" once, as long as you've only made minor changes like the kind we're talking about here, subsequent runs should complete pretty quickly, like within a minute or two. I realize that isn't as fast as manually modifying configuration files in /etc and then manually restarting a service, but that is the trade-off for describing the entire system declaratively. Guix does its best to make it as fast as it
<marusich>can, but yeah it's still not as fast as I'd prefer. Faster is always more pleasant.
<Guixuser44>ah, okay, i never tried that. the last time i ran it, it took ages ...
<marusich>yeah, if it's the first time, or if you made significant modifications (e.g., pulled in a new package as a dependency), then it's going to take longer.
<Guixuser44>so, (authorized-keys
<Guixuser44> `(("alice" ,(local-file ""))
<Guixuser44>where should reside on disk? in .ssh for the user?
<marusich>If you write it like that, as a relative file, Guix will look for in the same directory as the OS config file. At least, that's what the manual says for local-file.
<marusich>It is also possible to embed the key directly as a string, by using plain-file.
<Guixuser44>yes, i read that .authorized-keys is still honoured in the users home directory
<Guixuser44>that is ~/.ssh/authorized_keys to be precise
<marusich>Correct. So, you could also manually install the key outside the scope of Guix.
<marusich>I believe Guix installs the keys to /etc/ssh/authorized_keys.d/
<marusich>And then it starts sshd with an appropriate configuration file that tells sshd to look there for keys, also.
<marusich>BTW, if you're curious to see the actual config file used by sshd, you can find it by running "ps -wwfe | grep sshd" and looking for the -f option. it'll be a file like /gnu/store/fnsb582n2pyrm3gjmsc6idkbav8c036l-sshd_config - note that it is in the store, which means it's immutable. It isn't being read from a place liked /etc
<Guixuser44>So, since security is quite important, not running a millitary op here, but stll interested in keeping stuff secure, how safe is guix, I mean when you update the system, the updates must come from a server, how easy is it for an adversary to compromise the sources? Are there any safeguards in place like multi-signature release? Ie what prevents the
<Guixuser44> admin of the update server from injecting some malicious code into a package? Of course I don't distrust the maintainers, but this is kind of an intellectual question. As ideally I think it would be best if releases are only possible when they are signed by multiple parties on multiple locations, if not, then any powerful entity can threaten a sin
<Guixuser44>gle dev which has the release key to push a malicious release
<Guixuser44>thanks for the tip, i have played with sshd extensively in a non-guix context, but the tip was anyway a good one
<marusich>Those are good questions to ask. I won't try to answer them comprehensively, but I will mention the following. Because Guix follows the purely functional software deployment model, if you have authorized substitutes from a substitute server (e.g.,, Guix will transparently download substitutes from the substitute server when they are available, otherwise it will download the source from the location specified in the package
<marusich>definition and then build the package locally from source.
<marusich>This feature is called "transparent source/binary" deployment; Nix has it, too.
<marusich>The substitutes are digitally signed with the substitute server's key. Someone with root privileges on the local machine can authorize or de-authorize substitute server keys.
<marusich>Guix verifies the digital signature when downloading substitutes, so even if they come from some random place (like a CDN), you can be sure you are getting the exact same software that was signed by the substitute server.
<marusich>When Guix builds from source, as I said, it downloads the source first and then compiles it. The source comes from whatever URL is specified in the package definition. The package definition contains a content hash (sha256) of the source contents, which ensures it is the same contents as when the person who wrote the package definition checked.
<marusich>The people who write the package definitions are anyone who has commit access to Guix and, if you use any other channels, those channels. For Guix's core channel, all commits are signed, and everyone does their best to verify the sha256 value of a source (e.g., a tarball containing the release of linux-libre), before committing it. Committers are expected to do things like verify GPG signatures, when available, before committing the package
<marusich>The people who have access to the infrastructure and privileges allowing them to invoke sudo might, hypothetically, be able to abuse their access to insert malicious substitutes signed by the key. The people who have access are decided by the Guix sysadmins.
<marusich>I'm not sure if Guix verifies the Git commit signatures when running 'guix pull', but if any substitutes are used when running 'guix pull', those substitutes' signatures will be verified by Guix as usual.
<marusich>On that topic, this bug is related, but it is old and possibly outdated:
<marusich>When I looked at the code, it seems that our use of libgit2 doesn't verify the Git commit signatures. But you can fetch the channel over https, which uses TLS, so that's good.
<marusich>I don't know how the security of the Savannah infrastructure is managed, but surely it can't be that bad, since it's used by many important projects.
<Guixuser44>There are some terms in this process I am unfamiliar with, but in short what you are saying is that as users we need to trust single individuals (eg: devs), and if a dev is compromised, then there's no guarantee that malicious code is not propagated? Trusting a signature is ok, but if the one holding the key is compromised, then there is no elabora
<Guixuser44>te safeguards to defend against that? So lets say gov official/LE asks dev/website maintainer to prepare a specifically crafted package (sorry if my terminology is off) for downloads going to a specific ip-address in say Iran, how would that be detected? This could be done to secure shell access on a targets computer. All other users would be serve
<Guixuser44>d the normal files. I guess the target could protect against this by downloading through many different ip's and check for inconsistencies, or to download over tor, so the ip constantly changes.
<marusich>I think the risk of that is similar to the same risk in any project. For example, you could ask the same question about the openssh developers.
<Guixuser44>yes, agreed. This isn't guix specific.
<marusich>But assuming that you trust the devs, the sha256 hash of the source in any given package definition ensures that when Guix builds from source, it's building the source that was intended by the developer. And the digital signatures on substitutes ensure that when Guix downloads and uses a substitute, that substitute is exactly the same as what was built on the build farm.
<marusich>If you go all the way down to the bootstrap binaries - the opaque binaries from which everything else is built - those are also protected in a similar way. Their SHA256 hash is recorded in Guix's code, and they are downloaded from a remote server and verified against that SHA256 hash before they are used.
<Guixuser44>I have just alway though that proprietary software is inheritly insecure as there is no way to know what is running, so what prevents nsa from backdooring windows updates going to certain servers inNK for instance. As for open source software, there is the community looking at everything, but if a users is targeted specifically he will see nothing
<Guixuser44>wrong, unless he develop an elaborate defense. Most users trust software signed with a trusted pgp key.
<marusich>Sure. That is true for any project, really.
<Guixuser44>Just looked up the substitute definition. subts are prebuilt items, like deb,rpm in other distros. But
<marusich>Going farther, security updates to Guix are delivered by committing them to the master branch in a way that causes them to be used as "grafts". Normally you would just update the package definition, but if it's a widely used library, like glibc, it would cause tons of rebuilds, which would take a long time. Grafts allow updates to be applied quickly; you can read more about them in the manual. Essentially, if A depends on B and B needs to be
<marusich>upgraded, Guix builds B' and then quickly builds a version of A that is constructed not by building it from source, but by taking the original A and simply updating all the references in all its files from B to B'.
<marusich>Eventually, those grafts are removed when the actual change which causes A to be rebuilt from source using B' is merged to master.
<marusich>Regarding your question about multiple signatures on the Guix releases, I don't think the maintainers release in that way currently. Here is the release email for 1.0.0; there is only 1 signagture and some hashes:
<Guixuser44>I assume there is a pgp key locally on guix install which is used to verify a subst dl? so if the dev making that subst is compromized, the end user is compromized. And if this update is pushed only to a specific user, then the community will not detect it. So, the infrastructure should have IDS systems in place, and procedures to deal with intrus
<Guixuser44>tions / physical threats. Is it a all feasible to require that substitutes that should be made available must be signed by 2/3 devs or 3/5 devs for instance? They could all be spread out geograhically and even be anonymous partly or fully, as long as they've proven over time they can be trusted. The reason anonymous could be good is that it would b
<Guixuser44>e harder to get to all of them. I mean, a powerful org. could easily hold a single dev at gunpoint, but 3 out of 5 devs in different jurisdication would be much harder. I am aware this is going into tinfoil hat territory here for a bit, but I am really interested in the theory behind keeping everything as legit as secure as possible. Therefore I al
<Guixuser44>so use qubes, which is non-monolithic, but again it is not perfect, as intel processors have flaws which can lead to privilege escalation, which is a bit scary to be honest. But for ordinary users, I think it is reasonably secure. Wold adding 2/3 or 3/5 signing lead to too much bureacracy or inconvenience? Is that too much?
<marusich>I think that is a question for the people who make the releases. You should come to Guix Days in FOSDEM 2019 to talk more about it! :-)
<marusich>Regarding the key that is use for substitute signature verification: it is not PGP, and the details seem to not be mentioned in the manual. The key creation happens when running "guix archive --generate-key" as root. It ultimately calls this gcry_pk_genkey from libgcrypt:
<marusich>The parameter defaults are specified here:
<Guixuser44>thanks for the invite. I think participation on the mailing list first is a good alternative, getting to belgium would be a significant journey. recently I found otpclient, which can be used offline, and is a better alternative than authy and google authenticator on a phone imo, not sure if this is included in guix, if it isn't, how extensive is it
<Guixuser44> to contribute to have it included as a substitute? There are so many new concepts for me with guix as it is fifferent from debian which i have used mostly.
<Guixuser44>ie i think it is better to run otpclient on a 100% offline device, as phones are insecure by design, and also i dislike cloud solutions for 2fa
<davie`>Guixuser44: You can use oath-toolkit
<Guixuser44>thank you very much for all the detailed info, and your very friendly attitude. I certainly have a lot to read and learn.
<marusich>To cap off the discussion of the signing key, looks like it's a public/private keypair. The security of the key will depend on the parameters used, the quality of the implementation in libgcrypt, and perhaps the system on which you run it (e.g., probably good if you have lots of entropy?).
<davie`>its included in packages already. Its super cool. You can use it in cmd
<marusich>I don't know much about otpclient. When I ran "guix package --search=otpclient" and "guix package '--search=otp.*client'", I got no results. So maybe it isn't packaged. Sounds like maybe davie` has an alternative you can use!
<marusich>As for the Guix Days, sure, maybe next time. It's a lot to take in, and starting by watching the email lists is good. And by chatting on IRC! It's a great community.
<davie`>no its called oath-toolkit its a lib with command-line interface you can use for otp 2fa
<marusich>Oh, neat.
<marusich>To close the discussion about security, I'm sure I didn't mention everything. Guix has some information about security listed here and here
<Guixuser44>marusich, i sent you a pm, did you see it?
<Guixuser44>thanks, will have a look marusich
<marusich>FWIW, I feel just as comfortable using Guix as another distro for my own personal computing. However, it's true that Guix's community is smaller, so the coverage in terms of eyes and people-power is lower. Updates are fast for some packages that people care about, and slow for others. No security audit has been performed to my knowledge, which puts Guix in the a similar situation as many projects.
<davie`>we need more guix :)
<marusich>If anything, I feel that Guix's focus on bootstrappability and functional software deployment makes it in many ways *more* reliable than traditional systems.
<marusich>yeah, we do :)
<Guixuser44>well, i found it recently, and it's interesting. I am trying do diversify the systems in my home lab.
<Guixuser44>Also I like the spirit in here.
<Guixuser44>it's like the bitcoin-dev channel in the beginning, everyone curious and interested in the tech
<marusich>We're glad to have you here! Everyone is welcome, and anyone can contribute if they want to, even without writing code.
<marusich>I need to get some sleep; it's very late where I am. It was good chatting with you. Hope to see you around!
<Guixuser44>see you!
<Guixuser44>good night
<davie`>marusich: regarding package updates... I've been packaging some python and go packages and found out that many of those that are already present in guix repo are outdated. What I thought of is following... We don't have package maintainers and we won't have. I't kind of guix way. But we can have a tool for coverage which packages are up-to-date
<marusich>That sounds similar to "guix refresh".
<davie`>So we can keep up with pipy or github or gems oo hackage or etc.
<marusich>There are potentially interesting ways to use the Guix Data Service that Christopher Baines has been working on, in order to query all the packages and do various things with them. I'm sure with a bit of work, the GDS could be used to generate, e.g. a web page showing the status of packages. How out of date they are, what CVEs are out, etc.
<marusich>I'm not deep into those things, but they're really cool. Look into it if that's up your alley
<marusich>The command "guix refresh" is supposed to help update many packages, which might help with what you're saying.
<marusich>"guix lint" has a CVE checker which attempts to identify packages with known CVEs.
<marusich>One other area we are lacking is in something similar to a Nessus scan; it would be nice to surface vulnerabilities to users if they are using a terribly out of date profile, for example.
<davie`>oh wow I did't know about guix refresh
<marusich>OK, really logging out now :)
<davie`>see you
<moewe>Hey, is there a java compiler in guix besides janino?
<moewe>because i need javac for edu
<moewe>(also there's no javac in java-janino)
<Guixuser44>have a great day you all!
<davie`>moewe: don't know much about java but there is java-plexus-compiler-javac
<moewe>hmm as far as i can tell there's no way of compiling java without ant or maven
<moewe>plexus and janino are supposed to be used with them if i understand correctly
<A[m]2>guix lint:
<A[m]2>abduco@0.6: source not archived on Software Heritage.
<A[m]2>software heritage?
<jyscao_>instead of using either git-fetch or url-fetch to retrieve the package source, is it possible to directly specify a path on my local fs? I ask because I've made some changes to the package's build steps, and would just like to test it out
<leoprikler>Yes, just do "file://..."
<leoprikler>However, if you haven't commited anything, this will not work as you expected.
<leoprikler>You probably want (source (local-file ...))
<jyscao_>hmm okay, that was what I was about to ask, which field i should be modifying
<rekado>moewe: install openjdk:jdk
<rekado>the jdk outputs have all tools needed for a JDK including the compiler
<snape>you don't need to commit anything to use file://, it doesn't need to be a git repository
<leoprikler>ah, my bad, that's if you're using git-fetch
<leoprikler>url-fetch should probably be fine
<zimoun>snape: yes, but it is a better practise to use file:// with versionning. :-)
<snape>zimoun: I think you just want to contradict me ;)
<snape>but yes, of course it's always better to use git when possible
<zimoun>snape: :-)
<leoprikler>what are the Blocks.txt and NamesList.txt downloaded from
<Franciman>leoprikler, seems like it's unicode related
<jonsger>leoprikler: downloaded for the ibus package
<leoprikler>Franciman, jonsger: Thank you both.
<leoprikler>it's weird tho, why does ibus suddenly need to be rebuilt?
<snape>Hm I wonder why Cuirass evaluation for commit 8f523eb fails, and on next commit it succeeds
<snape>are there like random failuers?
<snape>and the error seems totally unrelated to the commit's content
<snape>might be an offloading error... no idea
<roelj>Does the guix-daemon garbage-collect, or in some other way delete files from /gnu/store automatically (without running "guix gc")?
<lfam>roelj: No
<str1ngs>snape: some build errors could be race conditions. so not always something easily attributed to a commit
<roelj>lfam: Thanks.
<snape>str1ngs: that would be rather annoying
<snape>I thought all those kind of Guile related race conditions were fixed
<snape>I hope it's just a connection issue
<snape>with some offloading serer
<str1ngs>not guild, but builds can have race conditions as well. especially when using many cores
<snape>this isn't a build error, it's an evaluation error
<snape>the guile stuff that returns derivations which next have to be built
<str1ngs>I'd need more context. it was just a thought I had to explain why it failed once but not a second time.
<snape>yeah sorry I hadn't noticed you were talking about builds whereas I was talking about evaluations ;)
<str1ngs>I over looked the evaluation part myself.
***gavlee_ is now known as gavlee
<kingcons>hey doges
<kingcons>ah yes, another incident due to underlying heroku problems :-/
<kingcons>i can't wait to move over to GCP or AWS *sigh*
<kingcons>... and this isn't the channel i thought it was.
<bavier>kingcons: :)
<zimoun>what is the difference between and considering substitutes?
<nckx>zimoun: They are the same machine. ci.guix was pointed to a CloudFront CDN in front of berlin for a while, but now they're identical.
<nckx>zimoun: You can choose berlin instead of ci.guix if you never want to be part of any future CDN experiments 🙂
<nckx>but I recommend using instead of the legacy
<zimoun>nckx: thank you. You confirm my guess. :-)
<zimoun>Why "guix build ungoogled-chromium -s i686-linux -n -d" does not return the same derivation than ?
<zimoun>I get /gnu/store/45cfay69pp6prky2kw0r21nv5lp3xgs9-ungoogled-chromium-78.0.3904.108-0.8f06513.drv
<zimoun>And I have tried --no-grafts
<zimoun>I am on guix 8548b3d
<nckx>We should probably set up an explicit (…phew) next time, berlin is an implementation detail.
<zimoun>I am happy with the CDN. It improves my experience. :-)
<nckx>Are people still having 50x troubles with ‘guix pull’?
<zimoun>nckx: I just ran "guix pull" couple of minutes ago. Everything was fine.
<nckx>The attack isn't over but, I am told, the largest contributor fucked off to ruin someone else's day.
<nckx>zimoun: Thanks for the data point 🙂
<nckx>sneek: later tell civodul: dmitri is taking some scheduled time off.
<sneek>Got it.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 1.0.1 is out! get it at | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckx
<rekado>logged onto berlin only to see “In procedure accept: Too many open files” printed over and over from mumi.
<kirisime>Hello guix, do we have dotnet core?
<rekado>I don’t think so. Would Mono be sufficient?
<pkill9>mono is quite old
<pkill9>the one packaged in guix
<kirisime>I need the runtime for a build of my friend's game. I'm not a developer.
<mbakke>huh, `guix weather` reports: 183.7% substitutes available (21,323 out of 11,607)
<mbakke>not sure if good or bad...
<civodul>mbakke: sounds very good! no shortage of binaries!
<sneek>civodul, you have 1 message.
<sneek>civodul, nckx says: dmitri is taking some scheduled time off.
<civodul>oh, hi there!
<mbakke>sneek: no botsnack today!
<mbakke>I wonder what happened with the latest evaluation:
*mbakke has finally started working on core-updates
<Blackbeard[m]>Hi ٩(◕‿◕。)۶
<Blackbeard[m]>What's a good begginer project I can do
<Blackbeard[m]>Something that is not so short
<Blackbeard[m]>Like a Google Summer of Code project
<Blackbeard[m]>I am on vacation and I want to help Guix
<pat_h>Hello everyone, does anybody have an idea about the simplest way I can go about invoking the 'configure' step for a package with bash in xtrace mode? When I add a pre-configure step to invoke "set -xv" the process halts with error 127 (command not found), and this doesn't seem possible to do via setting environment variables either.
<leoprikler>pat_h: perhaps you'd like to `guix build -K`, then abort and inspect /tmp/guix-build-...
<mbakke>pat_h: you probably have to (substitute* ...) the script in question to add the "set -xv" line
<rekado>Blackbeard[m]: mumi could need some work
<rekado>if you want something more challenging you could work on the GWL
<Blackbeard[m]>rekado: ah good :) is there a discussion already or something to guide me on what to do?
<rekado>e.g. guile-aws
<rekado>for mumi we need to switch to using mu for local search instead of talking to debbugs
<rekado>the code is here:
<Blackbeard[m]>rekado: OK I can start with mumi
<rekado>mumimu is the fork of mu that supports searching for bug ids
<Blackbeard[m]>rekado: mu like the mu4e backend?
<rekado>Blackbeard[m]: superb! feel free to ask whenever you are stuck, or if you changed your mind
<rekado>yes, the very same mu
<Blackbeard[m]>Awesome :D
<rekado>mumi downloads emails from debbugs and then mumimu indexes them
<Blackbeard[m]>I see
<rekado>but we dont do anything with that index yet
<Blackbeard[m]>OK I can clone the code
<Blackbeard[m]>And start looking at the code
<Blackbeard[m]>Any files in particular I should look at first?
<rekado>no, there isn’t much anyway
<Blackbeard[m]>I want to help Guix more
<Blackbeard[m]>It is just my school has been on the way too much
<nckx>pat_h: Just replacing 'configure with (invoke "sh" "-xv" "./configure") will work in most cases.
<Blackbeard[m]>But no more I'll make an effort
<nckx>rekado: What's the status of the guix.git ‘mirror’?
<rekado>Blackbeard[m]: that’s great! Thanks for your initiative!
<rekado>nckx: it exists, but I still need to manually push to it…
<rekado>so we just need to add that cron job, I guess.
<nckx>rekado: So did you use --mirror?
<nckx>Blackbeard[m]: Thank you 🙂
<rekado>nckx: no
<pat_h>leoprikler: Yeah I'll try that, thank you
<pat_h>mbakke: Not sure why I didn't think of that ha, I'll give it a shot
<pat_h>nckx: I'm a little squeamish about doing that but as a last resort that sounds good, thank you!
<nckx>pat_h: Why? It's equivalent to patching and less intrusive. But the effect is the same, do whatever feels best. You can add an (invoke "balk"), or any other invalid command, to abort the build so you can inspect it with --keep-failed.
<nckx>rekado: For any particular reason?
<rekado>I just did it before I knew
<pat_h>nckx: largely because I would prefer to keep everything else about the standard configure step the same (environment, flags, etc)
<mbakke>nckx: I'm getting a hash mismatch for the girara 0.3.3 source tarball.
<mbakke>do you have the original file?
<nckx>mbakke: I'll check.
<nckx>mbakke: You're getting 1llasnwb6zc97sqwc1nq11inzrxyh8mfwl2sqp4fm7mmv585hkks now, I presume?
<mbakke>nckx: indeed
<nckx>Now upstream is 504ing for me.
<nckx>1llasnwb6zc97sqwc1nq11inzrxyh8mfwl2sqp4fm7mmv585hkks is an HTML 404 page :-/
<mbakke>nckx: oh, right :/
<nckx>13vr62kkkqs2xsrmsn114n6c6084ix1qyjksczqsc3s2y3bdsmj4 is
<nckx>mbakke: The good news is that this jives with
<nckx>But I did not download a GitHub /archive/…
<mbakke>since berlin did not get it in time, perhaps we should revert the update until upstream recovers?
<nckx>mbakke: I think the better fix is to use git-fetch, or do you disagree?
<mbakke>or we could add the github archive as a mirror
<mbakke>nckx: that seems fine
<nckx>OK, I'll do that because it's less intrusive and 'll keep an eye on upstream.
<mbakke>nckx: tyvm for taking care of it!
<nckx>Thank you for letting me know.
<kirisime>Why is it that I can't seem to run any standalone binaries?
<mbakke>kirisime: what do you mean?
<nckx>kirisime: If you're using Guix System: because stand-alone binaries hard-code /lib/ which isn't present by default.
<nckx>Is that the case?
<kirisime>Appimages don't run, for instance.
<nckx>If so, you can add it as a special-file in your system.scm, but chances are it will fail to load any shared libraries. You can use patchelf to modify the binary to use /gnu/store libraries instead.
<nckx>kirisime: What are Appimages? Are they statically linked?
<kirisime>nckx: They're supposed to be self-contained binaries for distro-agnostic application delivery.
<kirisime>Lots of software has appimages available along with snap packages and flatpaks.
*nckx ♥ how fragmented the ‘last universal blob format you'll ever need!’ space is.
<nckx>Didn't know about AppImage.
<kirisime>It's the only one that's supposed to have no dependencies.
<nckx> says not quite, unless I misread.
<erudition>I think you'll find it's the more harmless one. This is useful to compare to Flatpak and Snap:
<kirisime>The problem is that if you give an appimage to ldd it'll say 'not a dynamic executable' and then your debugging is changing the filesystem and seeing what happens.
<kirisime>Unless you actually know what you'd be doing, but there's probably a good reason why you downloaded the appimage off the developers' website in the first place...
<mbakke>kirisime: you are probably just missing the /lib/ loader that nckx mentioned.
<nckx>(service special-files-service-type `(("/lib/" ,(file-append (canonical-package glibc) "/lib/"))…)
<nckx>kirisime: That's from my system.scm☝ although you might need to use extra-special instead.
<leoprikler>Perhaps we should make a fancy webpage for `guix pack` tarballs.
<nckx>Otherwise, not exactly motivated to help bringing these things to Guix, sorry :-/
<leoprikler>"There are twelve competing standards."
<nckx>Yeah but Guix Pack is the final one /s
<kirisime>nckx: Thanks, I'll see if it works when I get around to reconfiguring the system.
<nckx>Packaging: solved. Enjoy. Bye.
<nixo_>is perl-gtk2 failing on master?
<nckx>kirisime: Good luck! 🙂
<kirisime>Also, I'm pretty sure there was talk about making guix able to produce appimages.
<kirisime>These two can be final together.
<erudition>+1 on that
<nckx>Sure. Once you have sane, reproducible, introspective innards it probably matters little what colour the wrapper is. The goodness is the Guix inside.
<leoprikler>Maybe the real AppImage was the Guix we made on the way.
<leoprikler>(tbh. I'm glad emacs-telega got added, so I no longer have to keep flatpak around, yay)
<erudition>(I'd love for pithos to be added for the same reason!)
<kirisime>Speaking of which the first reason I tried to run appimages is that Guix' package for krita has some bug that causes it to crash when I create a canvas with GPU acceleration on when running on my discrete AMD GPU. Doesn't happen on the flatpak version.
<lfam>Hm, could you send a bug report to <>?
<nixo_>also, emacs-org-contrib isn't building
<kirisime>lfam: I'll check on it again when I reconfigure. This system is at least a month old and the issue might not be releavant anymore.
<kirisime>The appimage lets me get things done for now.
<kirisime>Which package provides Or
<nckx>kirisime: gcc.
<nckx>Or if you're compiling something: gcc-toolchain.
<gnu_srs>FYI: I'm amount to create(non-broken) tar packages for GNU/Hurd on Guix, WDYT?
<gnu_srs>Do they all have to static and stripped?
*nckx doesn't know.
<snape>so the EMACSLOADPATH bug should be fixed
<snape>there are still some broken packages though
<atw>I will see if I still see some behavior that was maybe related to EMACSLOADPATH