<lhp22>I don't know if it's correct idea or not, so I do it anyway : here the git issue I've opened about the CC variable not explicitly asked for rust. Anyways, that could keep track on rust installation on guix (sure others did, but ... ?.?) (https://github.com/rust-lang/rustup/issues/2830)
<iskarian>lhp22, the reason they don't is that most modern Linux distros make sure they have 'cc' be a symlink to 'gcc', but Guix doesn't
<iskarian>OTOH, it would be reasonable for their ./configure to look for gcc
<lhp22>iskarian: or at least to tell "hey, maybe your CC env var isn't well set up !"
<jab>Then we could create a (service desktop-service-type (guix-system-server "gnucode.me")), when the user sets up that desktop service type, it auto create and sets up an environment so that they can use their streaming media service, games, xmpp, etc.
<jab>raghavgururajan: You may want to re-read your libreboot guide. I may have messed up some of the commands, though I was trying not to.
<raghavgururajan>> jab: we could create a server-service-type that would sort of bundle lots of common server things in one service: email, NFS, git repos, game servers, music streaming, xmpp service, etc.
<KittyOwO[m]>Ah, I am also on sway, it is quite nice. I just wish I could mess around with fancy bloat like rounded corners and drop shadows lol ; actually I think there is a fork of it that does that that I might need to mess with some time
<allana>Hi guix. I'm trying to compile a toy C program and I am having a problem -- surely I have misconfigured or not installed something properly in my guix environment. Anyway, I have installed "gcc-toolchain" and "glibc". attempting to compile this toy program leads to a couple of "ld: cannot find crt1.o: No such file or directory" errors. Does anyone know what I am doing wrong off the top of their heads?
<efraim>oh wow, I actually ran out of ram building python-graph-tool
<jab>raghavgururajan: I actually use sway, because I couldn't figure out how to get gnome to honor my dvorak layout, and my trackpad on my laptop on gnome would randomly only move up and down...not side to side.
<KittyOwO[m]>A dedicated guix wm/de would be cool tbh, tbh, I think tililng windows managers if done right has the potential to be more user friendly to non-techie people than stacking ones, just needs to be done just right
<jab>KittyOwO[m]: it won't be long before we start having Guix System Starter Kits. :)
<jab>And Guix Home is going to make that super awesome too!
<KittyOwO[m]>I am just imagining something like Ubuntu to Debian but to guix, as an option on the guix installer TUI. Just something 100% foss that the average person can appreciate, use a cool gui for managing packages and the rest of the system, having a nice dark-mode guix system styled dark-grey/orange/yellow configuration on everything by default. Would also be cool if such a theoretical project also worked with places like pine64 (once they make a
<KittyOwO[m]>more libre and wifi-compatible laptop) or Raptorcs (once guix system ect. is ported) to let some niche markets see things on it by default
<KittyOwO[m]>Matrix has some actually ok clients for non-techie people, but, is a kinda janky protocol, whereas most of the reasonable protocols seem to exist as things with very terrible or nearly non-existant clients.
<KittyOwO[m]>On the topic of drivers, I really wish there was more development effort into things like hurd, something like it would be great and have good synergy with guix system. On that topic, I need to mess with Guix/Hurd in a childhurd vm some time lol, I read some of the concepts of hurd but haven't played with it yet.
<maxwell_TGAP>It would be really helpfull if there was a guix wiki, I know theres the docs and the cookbook
<jab>MysteriousSilver: that's not a lot to go on...
<KittyOwO[m]>I kinda like how it all is rn tbh, although the more options as long as the devs can sustain it the better. my only wish would be a mirrior to gemini and guix website to maybe be a fully darkmode site? Its still by far all the best I've ever seen come from a gnu/fsf styled project.
<MysteriousSilver>sneek: later tell nckx hello! you earlier mentioned that you generate guix file separately and grub.cfg sources it, how do i do it?
<jave>jab: MysteriousSilver: Thanks for the hints, I will have a look! Ideally I would like to my own patched emacs. At the moment I have a script that checks out emacs from git, and applies some patches localy. But this stoped working because some issues with fedora+gnutls+emacs
<fnstudio_>hello guix! i'm getting this error when trying to run guix pull: "guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused"
<fnstudio_>(this might have been caused to a guix pull i launched yesterday and that i had to kill halfway through because i needed some ram/cpu back)
<fnstudio_>(or that may be a red harring, i don't know)
<fnstudio_>i should mention i'm running guix on a foreign distro
<fnstudio_>if i look for guix-daemon in my list of processes, i don't see it
<fnstudio_>if i try and launch guix-daemon (as a non-root user), i get "error: cannot bind to socket '/var/guix/daemon-socket/socket': Address already in use"
<fnstudio_>i suppose this is something that'd get fixed by a reboot, but i was wondering if there could be anything marginally smarter i could try
<maxwell_TGAP>simmilar to the emacs wiki or the arch wiki, like an exstended cookbook
<maxwell_TGAP>based on .org files maybee, then it could be avalibel offline, pdf and as a published website
<maximed>so it appears Guile is really implementing IRIs and not URIs (not necessarily perfectly)
<apapsch>My use case: depend on a specific guix commit. I tried replacing ,guix in dependencies with a (package) expression but stumbled on missing imports (git-version missing etc.). Then I wrapped (package) in (begin (use-modules ...)), though Hall reads hall.scm as an s-expression and uses (match). arbitrary expressions are not possible. same with wrapping the whole hall-description in a let.
<maximed>(I meant IRI = URI + Unicode + plenty of rules)
<apapsch>I think I should maintain guix.scm by hand. Any recommendations from other hall users here?
<Rooks>I saw a few references to /share/themes and assumed it went there, my bad
<leoprikler>well, they would get installed into share/themes, but they shouldn't go into the same package either way
<leoprikler>as for the themes not being picked up, it might be the case, that you need to refresh your gnome-shell to have it picked up (idk how gnome-shell works in that regard, it's been a while since I've packaged the last theme)
<roptat>mh, so that doesn't explain why it's not detected, does it?
<roptat>mh, where are the gnome theme preferences? I can't find them on my fedora system?
<roptat>you're closing the list too early, it only contains gnome-desktop and xorg-configuration, when it should also contain the other services (except modify-services). so the modify-services ended up as a second value to the field, like (services (something) (something-else)), which is not a valid field specifier :)
<dstolfa>roptat: would be nice if we could have some kind of static checker that reports this a little bit better, at least one that's specific to guix as a general one for guile is a little difficult with all the code staging and the likes
<roptat>most of these records are guix records already, so we can change that behavior in (guix records)
<dstolfa>ah i didn't know we could change error reporting for each individual record, that's cool
<roptat>the first case wouldn't work, but otherwise, it's supposed to give you more precise error messages depending on what you typed, like (), (services), (services 1 2) or services (with no parenthesis around it)
<roptat>I think that covers all the possible weird cases
<dstolfa>roptat: that's a big improvement already, thanks!
<dstolfa>roptat: maybe that + some formatting & tests would be good to send to the ML for review?
<dstolfa>sneek: later tell civodul: indeed, the systemd part was particularly amusing (not because of systemd, but because a mitigation runs into another CVE); at least the way to exploit it is via eBPF, which is understandably a massive security risk to begin with so i have it disabled on literally every GNU/Linux machine i use
<cybersyn>i've been a'guixin and a'schemin (mostly racket tho, only now making an effort to seriously know guile) since last november, but I still haven't been able to get used to Paredit. The guide calls it "the bees knees", so I of course feel like I'm seriously missing out. how essential do you find paredit these days, and how long did it take you to get used to it?
<roptat>maximed, that rounding issue with guile sounds weird, but it doesn't surprise me too much
<roptat>I tried vim-paredit, but it's hard to use and buggy when files get big
<efraim>I never got the hang of vim-paredit so I've been making do without it for years
<efraim>I just try to be careful with indentation and that takes care of most of it. When using =%
<cybersyn>good to know! its been giving me FOMO hehe
<efraim>I should look at emacs-guix again to see if there's anything I should steal
<maxwell_TGAP>I used guix import pypi to wright a package.scm file, it builds with guix build but when i put into my $GUIX_PACKAGE_PATH it doesnt get found. I know its in the path because it complained maid my change some syntax when I ran guix search
<maxwell_TGAP>why would a valid package.scm that is in the guix path not be found by guix search or guix istall
<holzkristall>ecraven: Did you find an answer to this, I don't have the history:
<holzkristall>> ecraven: hello ;) is there a way to have guixsd restrict which parts of my home directory a given program sees? can I tell it to have blender and inkscape and gimp all not see the full home directory, but only some parts I allow them to see?
<roptat>maximed, yeah it's supported here, but the issue is that it probably won't work with a relative path
<maximed>Then use an absolute path? Guile also has some procedures for absolutising a path
<maxwell_TGAP>Im trying to compile something that requiers pkg-config, which i have but it cant find it, is there some simlink that can fix this?
<jab>roptat: does the design of guix mean that everything in /gnu/store is world readable? I feel like it might make sense to have some items only read-able by root...I guess the problem is how do you then guix gc only root readable files...?
<jab>when do you know that the root read able file is no longer needed?
<maximed>maxwell_TGAP: "guix environment --ad-hoc pkg-config", then do stuff
<roptat>maybe we could find a way to store secrets, but we haven't figured that out yet
<jab>roptat: I would love that storing secrets idea...There are many settings that are not persisitent when I upgrade my machine...email passwords, firefox sync, gajim passwords, etc. Maybe guix could work with gnome-keyring. That's what it's for. But does gnome-keyring support dumping an encrpyted database? And then when you upgrade you can pull in and decrpyt that database of passwords?
<roptat>the idea of the secret store was related to secret configuration values, like a private key as in your example
<roptat>currently, we have to remind people to keep these files out of the store
<apteryx>OK, sharing in case it'd save someone the testing: relocatable packs are not viable on Android (first you need root for exec bit permissions, second there's no userns and PRoot segfaults, at least on a aarch64 device)
<apteryx>it's not a PRoot on aarch64-linux problem, as it works fine on a Guix System aarch64 machine.
<sneek>civodul, dstolfa says: indeed, the systemd part was particularly amusing (not because of systemd, but because a mitigation runs into another CVE); at least the way to exploit it is via eBPF, which is understandably a massive security risk to begin with so i have it disabled on literally every GNU/Linux machine i use
<jab>dstolfa: I didn't realize that eBPF was not so secure.
<bricewge>roptat: mesa and libdrm updates are missing
<roptat>for core-updates? do we need them in this cycle?
<bricewge>I don't think it's required but it would be great
<dstolfa>jab`: well, eBPF lets you load pretty much arbitrary code into a highly concurrent kernel which allows pre-emption guarded only by a "verifier" at upload time. the verifier itself is written in C and very complicated, and also a part of said kernel. even assuming the verifier mostly works, it can't possibly account for all of the other stuff that could be happening alongside it in a very, very complicated
<dstolfa>this CVE just demonstrates how an unrelated bug can be used to bypass eBPF's verifier and leverage the full functionality provided by eBPF to exploit the system. people loved dtrace on solaris for developing exploits, and that was limited to root. eBPF is a much more expressive ISA than DTrace's actions and people allow it to be used as non-root
<cybersyn>hey y'all, I'm trying to package a library from sr.ht that doesn't supply a tarball, and apparently there is a reproducibility issue with fetching gits from servers using busybox (like alpine). is there a way around this besides mirroring it myself? did some searching but couldn't find a solution
<cybersyn>the issue is that git-fetching from sourcehut (sr.ht) doesn't result in a reproducible hash. its fine with tarballs, but apparently something about busybox doesn't give produce the same output each time.
<cybersyn>^could be hearsay, i found this answer on the guix irc archives
<dstolfa>jab`: yeah, set that to 1 (we should probably default to this in guix)
<dstolfa>Noisytoot: i don't think it is, my default configuration guix system VM doesn't have the bpf filesystem mounted
<dstolfa>Noisytoot: obviously, if someone were to develop an exploit which is not based around eBPF, but instead based around some other attack vector to execute kernel code execution, then guix would be vulnerable unless upstream released a kernel patch for it and guix picked it up
<dstolfa>but the exploit that was demonstrated with eBPF won't work in guix system