<iskarian>And yes, you would have to unquote that, so typically ",(package-version some-package)" <ruffni>iskarian: thanks! but i already tried that... this gives: unquote: expression not valid outside of quasiquote in form (unquote (package-version perl)) <ruffni>ummm.. do i have to do anything special to post on paste.debian.net? i get "could not add your entry... *do not spam*") <ruffni>(i'm on a newish guix system with vanilla ungoogled-chromium) <iskarian>it should be "(arguments `(" not "(arguments '(" <iskarian>No problem :) I've just looked at far too many package definitions in the past month, haha <iskarian>You also shouldn't have to manually set "#:tests? #t", that's the default <iskarian>ruffni, more importantly you'll want to use (default-perl) instead of perl, so you make sure you use the version of perl that's used in perl-build-system <iskarian>I suppose it'll be fine. It uses the latest perl anyway... <ruffni>iskarian: well... "latest" is kind of relative with perl <iskarian>Either way, it's moot, since the only perl packaged in Guix is 5.30.2 ***lukedashjr is now known as luke-jr
<lhp22>May someone know which rustup-init should be used to install Rust on Guix distro ? <iskarian>lhp22, would you not use "rust" and perhaps "rust-cargo"? <subaru[m]>I installed rust and rust-cargo, I don’t know why but only install rust-cargo will not compile the code. <lhp22>iskarian: I didn't find a clean way. I've guix installed rust and rust-cargo-platform, and then find the executable cargo somewhere <lhp22>It wasn't found before by just running 'cargo' <lhp22>and then using it to compile from the 'rustup' repo with 'cargo run --release' <lhp22>when I saw that 'rust' package existed, I'vnt asked more questions <iskarian>subaru[m], I believe the difference is that technically you can compile with just "rust" though in practice you'll need "rust-cargo" if you use dependencies <iskarian>(I do not use the rust toolchain, so I'm making educated guesses here) <iskarian>Perhaps users would benefit from a rust-toolchain which includes all three packages? <lhp22>cargo is just a "make-like" program for rust programs <lhp22>Indeed, should be better to know which "rustup-init" to use <lhp22>rustup-init is an executable which should set up all of needed for rust programmation <iskarian>On Guix there is no packaged rustup-init <jorge[m]123><jorge[m]123 "guix.jpeg"> No he podido utilizar mi sistema operativo debido a esos errores,alguna ayuda ? <iskarian>Ah, looks like I missed that "rust-home" is just a cargo package <lhp22>which package 'libssl' is known ? <lhp22>'libssl-dev' more precisely >.> <lhp22>and nope 'r-openssl' doesn't match <lhp22>doesn't appear with "guix search ssl" <lhp22>it was somewhere in the list <lhp22>Ok. This guix virtual machine is about to make me mad <lhp22>pkg-config doesn't detect it <lhp22>And, in the other way I was explored, I've a beautiful "./rustup-init \n -bash: ./rustup-init: No such file or directory". And yes, the autocompletion well found the rustup-init file <lhp22>I just have to set up the OPENSSL_DIR <lhp22>When I "ls /gnu/store | grep openssl" <lhp22>And why the derivations stay in my /gnu/store ? <iskarian>re: r-openssl, what's the description say? <iskarian>re: derivations remaining in /gnu/store, they are not removed until guix gc is invoked <lhp22>Your question made me parse "R bindings" as "well, R is a programation language indeed" <lhp22>didn't parse this way before, so makes no sense <iskarian>to remove a specific path, you can `guix gc --delete /gnu/store/...` <lhp22>sorry, my questions must be a bit boring <iskarian>the typical usage is `guix gc --collect-garbage` or `guix gc --delete-generations` <iskarian>The exact invocations and argument descriptions are in the manual <lhp22>I hope 'last question' : what is 'cc' ? <iskarian>For systems which use a c compiler other than gcc <lhp22>Ok. Totally weird. "Failed to find tool. Is 'cc' installed ?". Yes. But I think it's just a wrong debug message <lhp22>What the hell to get the rust-toolchain on a guix distro >.> <lhp22>Is there any documentation on how to make packages ? <lhp22>I'm pretty sure I don't have level to do a clean package for rust >.> but meh, maybe I can try <lhp22>1.1 "A Scheme Crash Course" x'D <iskarian>As for rust, you'll probably want to start with a `guix import crate package-name` or `guix import crate -r package-name` <iskarian>Guix import generates a barebones package definition from package repository information <lhp22>Indeed ... that could help me for what I4ve just done :'D <lhp22>I love the rustup compilation "you should first unsintall your rust installation". AND HOW I COMPILE YOU DARLING ? <iskarian>You won't need to actually have rust installed in your profile if you are just building package definitions <lhp22>I was compiling rustup written in Rust <lhp22>I'm sure it's in the manual but I try : is there an easy way to list the installed packages ? <lhp22>So. It's enough for my night, goodnight iskarian and thanks for your precious help ! <jab>Hey #guix people! I am currently copying some documentation for the cookbook. <jab>Feel free to come watch my screen and ask any questions: <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 !" <lhp22>their configure looked for gcc, that was the funniest >.> <lhp22>guix isn't the more dark distro where I could imagine installing rust >.> <lhp22>So, without your tip, I could look for help for many days ***califax- is now known as califax
<brendyn>MysteriousSilver, How did you go with that program that uses conan package manager? <brendyn>I'm also packaging a program that now uses conan ***Kimapr1 is now known as Kimapr
<jab>so apparently "guix build guix build guix build guix build" etc. totally works. :) <jab>that's hilarious. :) ***rt is now known as robin
<raghavgururajan>Btw, I just came across your website. The contents are damn good. :) <jab>raghavgururajan: thanks! coming from you! That's high praise! <jab>I just thought of a pretty cool idea for guix... <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. <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>Soheil[m]: (services %desktop-services) <jab>or (services %base-services) <jab>good morning civodul ! <jab>I thought your tweat about guix build guix build guix build is hilarious! <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. <raghavgururajan>jab: We could achieve the goals of mail-in-a-box, freedombox etc., in a declarative and reproducible way. <jab>raghavgururajan: Julien Lepiller has got it started! He's got a lepiller-mail-services: <jab>It combines smtpd, dovecot, and dkim-proxy services. It's pretty rad. *raghavgururajan checks if he is in dream or reality <jave>I'm experimenting with guix on top of fedora. I want to try building Emacs from git, using guix. Any pointers <jab>jave: You should check out my custom channel where I am working on jmacs. <jab>You could create a custom channel, and build your packages from it. <jab>You would have to tweak your package definition... <raghavgururajan>jab: From one of your blog posts, I presume you are using wayland+sway? If so, are you using display manager? <jab>I am using wayland+sway. :) I am not using a window manager... <jab>I auto login and start sway. <jab>see my new-ish cookbook entry for "Auto-Login to a Specific TTY" <jab>I also have this old-ish patch that was never merged to the cookbook. <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>KittyOwO[m]: I think it would be cool if guix had it's own wm/desktop environment. We could build off of wl-roots, and use guile...but it probably wouldn't work so well on the Hurd. <jab>Guix home...Guix vm. <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. <jab>I haven't had those issues on sway. <efraim>allana: start by uninstalling glibc, gcc-toolchain is supposed to have everything you need for compiling c/c++ <efraim>you might need to set some environment variables to find includes, but I'm not sure about that <jab>jave: check out the section in the guix manual 9.1.2 Package transformation options <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>something like that. <KittyOwO[m]>or a sort of "hybrid" where windows float but not stack <jab>raghavgururajan: just a second and I'll show you my .bash_profile <KittyOwO[m]>honestly, now I wonder how user friendly something like sway would be if you configure it just right... just expect the average user to drag stuff around with the mouse *raghavgururajan is interested in weston, but the build fails on master <jab>KittyOwO[m]: it would probably be ok. I think you can set the default new window to be moveable by the mouse. <KittyOwO[m]>maybe right click dragging windows could lead to a blender-like pie menu <jab>that any waybar ? can be cool, but I have not set it up yet. <KittyOwO[m]>oh gosh, I am just imagining how cool it would be to make a non-techie friendly OS setup that guix system would manage <jab>Then when users encounter bugs, we can add this to the manual: please use this command and reproduce the software bug: <jab>guix system vm --image-type=sway-wm <allana>efraim: Thank you. That did the trick. <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 <jab>KittyOwO[m]: me too. <KittyOwO[m]>jab: Isn't guix home on some type of experimental/unstable/development channel or something? I haven't looked into it really. <jab>It's in development. civodul (ludo) tried it out, and he said it's actually pretty cool. <jab>It is planning on being merged soon. <jab>also guix-y people. I'm planning on having a public/private pubnix. <jab>I've got a guix system server. 32GB. Dell optiplex 7020. <jab>my roommate upstairs doesn't want me to set up a static IP address because he feels that that violates his privacy. <jab>he said that I can probably set up dynamic IP... <MysteriousSilver>hello, trying to mount a NTFS file system, should I specify type as ntfs-3g or just ntfs? (in system.scm) <jab>basically, I would give ssh or sftp access to people. They could upload their website to /home/<user>/public_html/...and then their site would go live at gnucode.me/~<user> <jab>KittyOwO[m]: dynamic ip is the opposite of static ip address. do a ping -c 3 gnu.org. <jab>That ip address that it shows has been the same probably for the last decade. <KittyOwO[m]>jab: ah, that looks neat. Yknow, on that topic its a shame the situation right now with FOSS text protocols and clients, the only good protocols have bad clients and vice versa lol <jab>KittyOwO[m]: I'm not certain what you mean <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]>and will probably stay in these kinds of communities for a while but not really go anywhere else again lol <Soheil[m]>jab: Thank you. Could you send a complete config.scm? <jab>MysteriousSilver: would you post your config on debian's paste bin? <jab>the first config is has an example. <jab>diff /run/current-system/configuration.scm ~/.config/guix/system.scm <jab>what's the difference between those two files. That may help you get started. <jab>ohhh. and also send me a link to you config please! <jab>I wanna see your custom linux package! <jab>That wasn't intended to sound like a pick up line. :) <jab>what if we could specify in config.scm our computer model... <jab>Then guix would create a custom kernel specific to our machine. It could cut out various drivers that we would not need. <jab>might not be worth the effort though. <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... <jab>Is there something wrong with your pinned function? <jab>maxwell_TGAP: I know there has been talk about that, but I think the guix developers would prefer to push documentation toward the manual. <jab>that way users can read it offline. <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? <KittyOwO[m]>Hurd is an example of some of the worst websites I've ever seen, while Guix and the documentations it links is one of the examples of a great website lol <KittyOwO[m]>Documentation I also personally find nice but haven't played around too much with guix system yet <jab>the_tubular: can you download the arch wiki? <maximed>kiwix can be used to read Wikipedia offline <jab>and do you know of package that translates the arch wiki into info pages? <maximed>maybe it also works with the arch wiki? <the_tubular>I don't know how that will help you with guix though <jab>I will definitely be installing kiwix soon. <jab>the_tubular: it'll help me configure/troubleshoot applications. <jab>and wikipedia is fun to read <the_tubular>Yeah, I used to have a copy of Wikipedia without images <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>fnstudio: Maybe do the equivalent of "sudo herd restart guix-daemon" on the foreign distro? <maximed>sneek: later tell civodul: I sent a patch to adding -fexcess-precision=standard (tested with --system=i686-linux) ***MidAutumnMoon90 is now known as MidAutumnMoon9
<sneek>vivien, bricewge says: You can use simple-service to avoid the boiler plate when you are extending a single service <maximed>vivien: be careful with the differences between IRIs and URIs <maximed>vivien: apparently NFC normalisation is required <vivien>maximed, what do you mean "NFC" normalization? I know unicode normalization, which is only relevant to compare two URIs or two IRIs. <vivien>Soheil, you’re missing the second argument of append <vivien>or (modify-services %base-services (xxx-service-type config => new-config) ...) <maximed>normalisation is apparently sometimes required when converting IRIs to URIs <vivien>maximed, there’s no mention of IRI in the manual that I know of <maximed>vivien: I thought IRI = URI + plenty of rules, and URI don't allow Unicode characters (except some ASCII characters) -- they must be percent-encoded <maximed>and the patch is about Unicode support <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? <vivien>So the patch is not really correct, I should rather provide a new (web iri) module <maximed>Or a comment could be added to the Guile manual explaining its really IRIs that are implemented, not URIs <vivien>That would be very confusing if the code for IRIs is in (web uri) <maximed>whatever you do, please write plenty of tests, this seems rather complicated <maximed>About your original question: There don't appear to be many people actively working on Guile itself <maximed>raghavgururajan: "git grep -F 'define (version-major '" might find the appropriate module <raghavgururajan>maximed: Hmm. Its already imported at the top of the file. I am still getting unbound-variable version-major <Soheil[m]>raghavgururajan: Oh 😅 just please help me with this <raghavgururajan>Soheil[m]: Context please. I have no idea what is it you are asking. <maximed>An general approach to figure out the issue is to remove stuff one-by-one until the issue is obvious. And if it still isn't obvious, at least it is simpler <maximed>You need to move '(modify-services ...)' after 'list' <efraim>raghavgururajan: the '.*' in '.*-viewer$' is implied. just a FYI :) <Rooks>So for copy-build-system, where I am trying to install a gtk theme, do I just need to have an install-plan of installing the ./{icons,themes} to share? or am I missing a step? <leoprikler>Rooks: there are already gtk icon themes using copy-build-system, are there not? <Rooks>I found them, but they seem to not appear in theme managers after installing from file <Rooks>I'm not sure where I went wrong, should I post the scm? <leoprikler>does this concern an existing package or your own? <leoprikler>in that case paste the scm, there's probably something wrong with it <Rooks>I referenced a delft-icon-theme <roptat>maybe if it's the first icon theme you install, your environment is missing a variable? <roptat>although, XDG_DATA_DIRS should be the one you need, and I think it's already set for you on the guix system <Rooks>It also included a ./themes, which is what I was confused about <Rooks>The icons appear, but not the theme <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>I see the gruvbox theme there, so it seems to be working <roptat>but it's magical how changing the theme from light to dark also changes some website appearance <leoprikler>you may call it magical, but there are two options at play here <Rooks>Do I need to install it on system or can it be in user profile? <Rooks>I modified it to be "themes" "share/themes" and it appears in xfce4-settings-manager, but not lxappearance? <Rooks>Am I missing a environment for lxappearance? <leoprikler>idk about lxappearance, maybe LXDE uses different theme folders? <roptat>maybe lxappearance is looking for something different? it seems to be a gtk3 theme, so it doesn't appear in obconf for instance <roptat>or maybe lxappearance is not looking at $XDG_DATA_DIRS at all <Rooks>lxapperance depends gtk2 haha <Rooks>I should probably be using $XDG_CONFIG_HOME/gtk-3.0/settings.ini anyways I think <dstolfa>Soheil[m]: you want (services (cons* (service gnome-...) ... (modify-services %desktop-services ...))) <roptat>no I think it's correct if you count the parenthesis <roptat>the indentation makes it hard to read but the list is close just before modify-services <dstolfa>roptat: ah... i was going by indentation :) <roptat>so it's an append of two lists, which is correct *dstolfa finds it hard to count parentheses in a browser *roptat has experience with counting parenthesis manually <roptat>Soheil[m], what's the error message? <dstolfa>roptat: i could get years of experience, i'd still get it wrong i think <roptat>the trick is to use your fingers to count forward and backward at the same time ;) <dstolfa>i'm one of those people who's too lazy to manually indent/wrap things and would rather build a tool to do it <dstolfa>sounds like there's a typo somewhere in one of the configuration records to me? <roptat>maybe that services field is not part of the operating-system record directly? <raghavgururajan>efraim: Ah yes. There are two files, pipe-viewer and gtk-pipe-viewer. :) <roptat>oh, the append is closed too early <roptat>I thought I counted the parenthesis right, but the list is also closed earlier than I thought <roptat>there's one closing parenthesis after the set-xorg-configuration that shouldn't be here <Soheil[m]>I use nonguix and Linux LTS (I do not want to advertise it). Could it be a problem because of that? <roptat>Soheil[m], not at all, it's the parenthesis <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 :) <roptat>(also, reindented so it looks nicer) <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>no, I don't mean we can change the error report depending on the record, but I mean we can make a change in guix to do that <roptat>or at least, we could have a more specific message like "services: got ~a values, but expected ones. Values are:~%~[~a~%~%~]" or something <dstolfa>roptat: yeah, and this wouldn't be too hard to hack together honestly just for guix <dstolfa>for guile in general it's a bit harder, but just for guix-controlled records i think it's quite easy <Soheil[m]>"Guix system: error: service 'networking' provided more than once" <dstolfa>Soheil[m]: i assume that dhcpcd-service-type and dhcp-client-service-type shouldn't be in there together <dstolfa>actually, seems like network-manager-service-type provisions networking, and so does dhcp-client-service-type <dstolfa>so i don't think you can use them together <dstolfa>(and i assume that network-manager would give you DHCP?) <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? <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, maximed says: I sent a patch to adding -fexcess-precision=standard (tested with --system=i686-linux) <civodul>the "mitigations" section is fun too <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 <roptat>so is there a released kernel with a fix? do we have it in guix yet? <dstolfa>my fedora box at home had an update with linux this morning, so i guess there must be? <roptat>sounds like "systemd friendly crash" before someone can exploit the bug through fuse wouldn't work on guix system :) <dstolfa>roptat: well, unless you have eBPF enabled on your system for unprivileged users, you're fine either way <roptat>I was under the impression you needed both, not just one of them <roptat>but in any case, it doesn't really prevent the issue <dstolfa>roptat: well the exploit kind of depends on having access to eBPF, if you just remove access there's no exploit <dstolfa>it uses a TOCTOU vulnerability in the kernel where the verifier says the program is OK, but it gets swapped out before it gets used. <dstolfa>so basically, the verifier verifies one program, but the JIT compiles down another which has not been verified <dstolfa>note that what i'm saying is true for this particular exploit, other vectors could be found to get code execution, eBPF is just the most obvious one <dstolfa>still, i think a kernel update is out already? <roptat>also, what's left before we start freezing and evaluating core-updates? <maximed>roptat: bug#49659, to fix compilation of guile on i686-linux <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 *dstolfa just moved to emacs <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 <maximed>the variable holding the package needs to be exported <maximed>did you use "define-public" instead of "define" <roptat>also I think it needs to be a valid guile module, so the name in define-module needs to match the file name and its relative path to $GUIX_PACKAGE_PATH <apteryx_>ah, creating symlinks upon tar extraction on android requires root; which someone defauts relocatable packs ***apteryx_ is now known as apteryx
<apteryx>even after extracting it with 'su tar oxf guile.tar', attempting to run guile failed with a segfault. Now to check without the -RR wrapper. <jab>hello #guix! I'm working on setting up my email server at gnucode.me...again. <apteryx>which somewhat defeats relocatable packs (on android) * <jab>roptat: are you the person that has been helping we with my email server? My main issue right now is that dkim-proxy is responding too quickly. shepherd disables it. <jab>whoops, the second link is right. <roptat>jab, I suppose this means dkim-proxy crashes or exits with an error <roptat>probably, it's not finding the key. You can run the same command as shepherd manually to see what it's saying <roptat>(would be better if the shepherd could capture the standard/error output, but well) <roptat>I use (key "/etc/mail/dkim/private.key"), and I think it's supposed to be absolute, because otherwise it's relative to the directory the shepherd executes from, and I don't know what that is <jab>roptat: yes! it would be awesome if shepherd could capture standard error output. Also it would be great if herd config <service> would show the config file that the shepherd generated. <jab>roptat: that's probably my issue! I using a relative path. <jab>or perhaps I could use (key (local-file "./relative/path")) <jab>actually perhaps that's not a good idea, because then the key is in the store... <jab>Is there such an option (local-file "./relative/path" #:only-root-can-read) <maximed>jab: Some service configuration records accept a string <roptat>if it's in the store, it's readable to everyone <maximed>(That won't be interned into the store) <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 <jab>roptat: yup. I'm one of those people. :) <jab>roptat: dkimproxy-out is running! sweet action! <jab>ok my dkim DNS record is incorrect... <jab>there's a space in my key...fixing that. <jackhill>+1 for figuring out secrets, but I haven't had any bright ideas yet. <sneek>Welcome back jackhill, you have 1 message! <jackhill>On another note, and idea that I had today was for a service that would read cloud-init data an reconfigure the system accordingly <jab>jackhill: Another idea is to use btrfs volume manager. <jab>nice my dkim info is good! <jackhill>jab: I'm not familiar with btrfs volume manager <ecraven>holzkristall: guix environment --cointainer --share/--export seems to be it, but I haven't tried that yet <jab>jackhill: thanks for sharing! <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. <civodul>hey! looks like something broke: "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (bash-minimal)) (value #f))" <sneek>civodul, you have 1 message! <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 <civodul>yeah, maybe we should consider disabling eBPF by default <dstolfa>civodul: i think it's okay to compile it in, but maybe just default it to off if we don't already (or at least root only) <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>it has its uses, but i wouldn't trust it even on a laptop <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>sorry, i was just knocked off if anyone replied to my question re: fetching from alpine servers <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 <vagrantc>if two different fetches result in a different git history, there's something very broken in git <cybersyn>sorry, so if i do guix download <link> multiple times with the same link, i wont get the same result each time -- the sha256 is different <jab`>dstolfa: how would you disable it in config.scm? And other kernel modules? <cybersyn>apparently this is the case with all git-fetches from sr.ht <roptat>like, if you download twice and check with diffoscope? <vagrantc>cybersyn: could you give a specific URL that triggers the issue? <vagrantc>that page probably generates dynamic information <vagrantc>you can't use guix download to download git repositories, as far as i'm aware <jab`>dstolfa: It just reminds me of someone's 10th law...any sufficiently large program has a buggy, poorly defined, half of common lisp. <dstolfa>jab`: what does mount | grep "/sys/fs/bpf" say on your system? <vagrantc>you need to download the git respository, cd to the directory, git reset --hard commit, guix hash -rx . <vagrantc>where commit is the commit or tag you're trying to check <jab`>dstolfa: I did not say anything. <cybersyn>ok, got it, yeah that makes sense. i misunderstood as needing to use the guix download method <dstolfa>jab`: you can also check `sysctl kernel.unprivileged_bpf_disabled`, if that returns 1, that means it only works with root <dstolfa>Noisytoot: give me one minute and i'll tell you <jab`>so perhaps I should set it to 1 <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 <dstolfa>(and the mitigation which is blocked by systemd's CVE can be applied on guix system without worrying about the systemd CVE obviously) <jab`>dstolfa: if you would like, I can submit a patch to disable ebpf <dstolfa>jab`: it's perhaps best coordinated with lfam, as they're doing kernel things. however, i think ebpf is by default disabled on guix system given that it's not even mounted <dstolfa>the sysctl is only relevant if users choose to enable it <jab`>lfam: would you like me to submit a patch to disable eBPF via a sysctl ? <dstolfa>they're not here :P. also it's not disabling eBPF, it's just disabling unprivileged access to eBPF (so that normal users can't access it, but for example root can) <jab`>anyone here using bcachefs? How's it doing? <jab`>and how easy is it to use in guix? <Rooks>What could cause a program running in guix environment to not be able to see controllers even with /dev/input and /sys/class/input exposed? <jab`>nckx: can you send me a copy of your confi <lispmacs[work]>hi, is anybody else getting a javascript error when trying to launch gnome-maps? <leoprikler>I tried fixing it by updating to the latest version and that worked locally, but then failed once the thing had been installed <drakonis>jab`: bcachefs is already hooked into the config system <leoprikler>I don't think we can before raghav does their thing *dstolfa appreciates the work raghavgururajan is doing with GNOME <leoprikler>My patch is successful! GNOME Maps now does nothing, not even print a warning! <leoprikler>why would the thing try to unregister at startup? <dstolfa>it's GNOME... as nice as it is to use (IMO at least), i rather not touch the actual code :D <jonsger>leoprikler: you talk about 718c09cf73e55f54a98c8e3c554a76ac768de2ee? <leoprikler>you can verify it gives you a different error prior to that :P <jonsger>it starts for me, but I can't scroll and move with mouse. Only with +/- buttons... <leoprikler>also what's "it"? the current version or the old one?