IRC channel logs
2023-12-02.log
back to list of logs
<nckx>ACTION adds ‘echo -17 | sudo tee /proc/*/oom_adj’ to their start-up script. ‘There, fixed it.’ <nckx>There's no built-in feature for this in Guix or el Shep, right? <PotentialUser-77>hey there!, trying to use the guile json library in a gexp. it seems that that module import fails even with the full closure imported. Is this a dead end and not possible? <lilyp>vivien got a local dbusmock build :) <lilyp>… or not, confused it with dbus-python <attila_lendvai>nckx, there's some userspace early-oom-something in guix. it works much better than the kernel oom killer. <nckx>PotentialUser-77: Any chance you can get away with using (guix build json) instead? I know that works. <nckx>attila_lendvai: Yeah, but it just polls in a loop, which bugs me. I haven't used it though. <attila_lendvai>nckx, earlyoom-service-type. i didn't tune it much, just added a prefer-regexp for my browser <attila_lendvai>nckx, you shouldn't have told me that! (just joking... :D life is too short to be bugged by unoptimal solutions in an OS entirely built on the wrong foundation...) <graywolf>nckx: 1. Thank you, the native-inputs approach looks *much* better. 2. Why do I do (assoc-ref inputs ..) even though I put the file into (native-inputs)? <Kolev>What is the difference between inputs and native-inputs? <singpolyma>inputs are things that will be used on the target native-inputs will be used on the host <vagrantc>where target and host are confusingly termed :) <singpolyma>They are roughly depends vs build depends, but of course not quite <vivien>Good news, I already had the webkitgtks. Less good news: I have now booted into the VM, and logged in. The GNOME session is incredibly slow to start, I still have a black screen and a default X cursor <lilyp>I assume you have dbus-python dbusmock et al? <vivien>lilyp, no, I have #:tests? #f :) <graywolf>Sure, I will wait, not like I can do anything else, but I am not sure it will help. <vivien>graywolf, I wanted to elaborate but I’m not great at following conversations this late, sorry. The sentence was a bit short and the tone was not right. It is not unusual for QA to leave outdated series information, even if it knows it has to refresh the issue. <vivien>QA has multiple moving parts, we have to be patient with it. <vivien>“Oh no! Something has gone wrong.” says the GNOME sad face :( <graywolf>Ah I see, thank you for the explanation :) <lilyp>I'll hopefully have a working dbusmock once I wake up <vivien>Silly me, I did not allocate enough memory for the VM <nckx>‘Kernel panic - not syncing: System is deadlocked on memory’ <nckx>Now whosoever could have forseen that. Totally unpredictable I say. <nckx>graywolf: I'm probably missing your point but how else will you address a specific input to get its store file name? <vivien>I think I’m the first one to have a full GNOME 44.6 experience on Guix <graywolf>nckx: I expected (assoc-ref native-inputs), that's it. <vivien>It’s a small step for GNOME, but a huge step for Guix or something like that. <graywolf>What works is (lambda* (#:key inputs ...) ...), but I originally expected (lambda* (#:key native-inputs ...) ...), so I am just curious why <vivien>Night light and dark theme do not seem to work though <vivien>(the thing gsd-color was supposed to mock) <nckx>Ah. Now I understand. I think the native-inputs *keyword* is only set during cross builds, so you should use something like (or native-inputs inputs). If you used only inputs, I think your package will break with --target=aarch64-linux-gnu. <nckx>graywolf: However, if it works, you should probably use (this-package-native-input "foo"), it didn't occur to me earlier. <nckx>Test everything I say because I didn't. <graywolf>hm, the this-package-native-input thing would require me to change the arguments from `(..) to use gexp, correct? <graywolf>Is that desired? I admit I do not fully understand what is the difference and which is prefered <nckx>So assoc-ref is acceptable, just less modern. <nckx>Gexps are the newish hotness and preferred, but you're not obligated to switch existing code. <nckx>(And if you do, do so in a separate commit, if at all possible.) <nckx>(Since it will re-indent everything and obscure real changes.) <jeremyc>I am trying out guix for the first time, but speed to do install/download packages, etc... is very slow here. Getting between 10-20k/sec. I am on gigabit fiber, speed test is showing mb/sec. Any thoughts? <Kolev>jeremyc, I find Guix to be slower than Fedora's DNF, but maybe that's just me. <jeremyc>Slower may be one thing, but if 10-20k/sec is normal, then I think it's unusable. I get 30-40mb/sec w/fedora and debian (debian is my std distro). <jeremyc>I was hoping there was something I could do, set a diff mirror or something but web searches have not found anything for me. <dthompson>guix doesn't have the bandwidth available that major distros have but I regular observe over 1m/sec download speeds <jeremyc>OK, that's good to hear. Maybe I should just try again in a day or two. First run was last night, then another ah hour ago. No difference. <jeremyc>1m would be perfectly fine. Not as though this is every day, but yesterday about 1 1/2 hours into the install I gave up. <dthompson>I haven't seen a download speed that slow in ages and I use guix all the time <jeremyc>Like the declaritive nature of GUIX, Emacs user, and very interested with all the proprietary things going on, snooping, etc.... would like to support and use a truly free platform for my computing needs. <dthompson>just for fun I did 'guix shell zig' (something I've never installed) and I'm getting ~3m/sec download speeds <jeremyc>weird... wonder what it could be. Speed test right now is showing everything normal for me right now. I am in OH, USA. <dthompson>the guix servers are in europe but I'm still getting good download speeds from the US <dthompson>at least I think they're all in europe... I don't keep up with where the substitute servers live <dthompson>ci.guix.gnu.org is the server that should be being used <jeremyc>you know, I did enable substitutes. Wonder if that's my problem? <dthompson>I just wanted to make sure that you are downloading from the right place. it should be the default. <jeremyc>right, that's what I thought. Was thinking maybe you didn't have them when you talked about not knowing where the servers were. OK. Just started the installer again. <jeremyc>I didn't see an option to set the download location. <jeremyc>Maybe I'll try this in a VM see if I get any diff than on bare metal. <jeremyc>OK, at the prompt. Substitute Server Discovery ENABLE/DISABLE. That's what I was talking about having Enabled. Is that what you were talking about as well? <dthompson>that can be safely disabled. that will look for substitute servers on the local network. that's a more advanced feature for people that have other machines on their network serving up binaries. <jeremyc>Hm, I am now getting 520k/sec. I can live with that. <jeremyc>I wonder if it found some other server it was downloading from. OK... yeah, now stuff is coming in at 3-5mb/sec. <jeremyc>I'm further already than I was after 1 hr yesterday... <jeremyc>yeah, big diff. everything is > 3mb/sec now. Thanks for that. I was going to give up. <jeremyc>I may try this again enabling the discovery and see if it is slow again. Just for knowledge. <dthompson>I wouldn't think that would make a difference but maybe? <dthompson>if it does then maybe someone else will be able to explain why <jeremyc>No, it did not make a diff. Still downloading 3-5mb/sec. Could it be that some hop between here and there just resovled itself while chatting? That'd be quite the conincidence... <dthompson>there is a lot of networking hardware between here and there... <jeremyc>well, I'll chock it up to network issues and continue on. Just glad I did not give up. Was going to after this evening it still being 10k/sec. <PurpleSym>vagrantc: I’m looking into python-sphinx-prompt. <PurpleSym>I fixed it, just running `guix pull` to be sure I did not break anything. <msavoritias>Hey. Is the guix project open to add more chat groups to the contact page? in different systems than irc <msavoritias>Assuming they are free software of course. I am saying because of accessibility mostly <cmiller>I use Linux Libre with nouveau. My Nvidia Geforce GTX 970 does not work though. I have xf86-video-nouveau installed and Xorg loads it, but it reports "(EE) NOUVEAU(0): Error creating GPU channel: -19" and therefore "(EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel" which means I don't have any 3D acceleration which should be supported. Does someone know how I can debug this or what I may <civodul>should i go ahead and apply or would you like more feedback? <civodul>(i’d still need to run the system test) <cbaines>whoo: compressing cached Git repository at '/home/chris/.cache/guix/... <cmiller>Do those HiFive Unmatched RISC-V boards work without issues on Guix as of firmware/drivers etc.? <cmiller>Would be interested in the experience with the Starfivetech VisionFive 2 and the LicheePi 4A, too. <attila_lendvai>i don't know, but i'm listening. i need to buy a new home router, and i'm staring at Banana Pi BPI-R4, but i'd much rather own an even more open hardware... <Franciman>can i build a deb package out of a guix package definition? <nckx>Franciman: Yes, see ‘guix pack --list-formats’. Note the caveats in the manual under (guix)Invoking guix pack. <nckx>In short, this isn't a good distribution mechanism for ‘end users’ of ‘apps’. <cmiller>attila_lendvai: With GNU Guix or OpenWRT? I have something like this on my to do list as well. Though HW is currently just to expensive for me. <attila_lendvai>cmiller, i'd like to run Guix on it, but if it turns out to be too much trouble, then i'm ready to roll back to openwrt, at least for a while. <vivien>lilyp, I’m sorry, I messed up my reply to #67582 (in multiple ways even). You may not have received it in your inbox, but it’s on the issue page. Sorry. <lilyp>vivien: thanks for the heads-up <lilyp>your accountsservice patch looks weird; what's the problem there? <lilyp>I don't mean the update, I mean the style change for the else <vivien>Upstream changed their style, so the patch fails to apply <lilyp>that makes it a little clearer, thanks <lilyp>btw. can you prepare a v3 for 67473 where we keep libsoup-minimal, but bump it to the libsoup version? <lilyp>I'll push that next week along with this one <lilyp>should minimize our world rebuilds <mirai>civodul: re dovecot, I think it's ready to go (I compared the generated config files) <vivien>Should I restore libsoup-minimal as an input for rhythmbox, tuba, python-nbxmpp and gnuais too, instead of libsoup? <lilyp>yes, keep the changes minimally invasive :) <vivien>Do you prefer the same string literal for both package versions, or (version (package-version libsoup-minimal)) along with a comment on libsoup-minimal to also update libsoup? <lilyp>If possible, I'd prefer one to inherit from the other (probably libsoup on libsoup-minimal to minimize rebuilds) <vivien>Please ignore, we don’t need the version field since the origin is the same <vivien>libsoup-minimal* both use substitute-keyword-arguments without a default value for each argument; should I leave it like that or add a default value? <lilyp>if no default is given, the argument probably already exists, but do verify that <mwette>cmiller: I have the VisionFive2; was starting on trying to get guix running on it, though I expect it to be slow (e.g., 4 GB ram only). I was planning to try recent kernel release with he RV64 guix bootstrap tarballs. <efraim>cmiller, mwette: I'm running Guix System on my hifive unmatched and I have a couple of patches ready for the visionfive2 that I'm going to test again now that the 6.6 kernel is out. <lilyp>Btw. does anyone know why patch-set/N does no longer work on mumi? <lilyp>It's really breaking my workflow <Kolev>Packaging: How do I just run `make` and not do `./configure`? <lilyp>Kolev: (modify-phases %standard-phases (delete 'bootstrap) (delete 'configure)) <Kolev>lilyp, do I put that code inside `package`? <lilyp>(package … (arguments (list #:phases <here>)) …) <vivien>Kolev, you may need to write #~(modify-phases … instead of just (modify-phases … <vivien>Kolev, you have to change the module name, it should not be (guix-packager) but maybe (kolev packages supdup) <vivien>You have #:configure-flags, but you removed the 'configure step… How is the build system supposed to do --enable-silent-rules then? <vivien>How do you know it won’t build? Do you have an error message? <vivien>Since you specify (commit "master"), as soon as a new commit will be pushed on master, supdup will fail to build because the source will not have 1xbb… as a hash <vivien>You should replace "master" by a commit ID here, or a tag. <Kolev>vivien, supdup has no tags. I guess I can use commit IDs. <vivien>Kolev, The Makefile tries to install things in /usr/local, but it should install them in the store. Adding #:make-flags #~(list (string-append "PREFIX=" #$output)) to your package arguments should make sure it is installed in the correct place. <Kolev>vivien, added. Thank you for your patience and help. <cddr>msavoritias: I just installed guix on a encrypted btrfs partition with subvolumes for root and home <sneek>cddr, apteryx says: I'd also like to know how to tell Geiser to browse the Guile's source. <cddr>msavoritias: all I needed to do is to add (options "subvol=root") to the file-system expression <msavoritias>i have a feeling for some reason grub doesnt like something <civodul>janneke: apparently /gnu/store/5dk8z6lbbfjjxcgizv8iw0hgmlbjvwx0-guix-1.4.0-16.aeb4943-checkout is being “built” right now <msavoritias>i read in the manual that it is only but only supports the PBKDF2 key derivation function <vivien>Kolev, this is the derivation file, there should be a log file with an extension <cddr>msavoritias: yes, I chose luks2 and pbkdf2 <Kolev>vivien, but it said View build log at '/var/log/guix/drvs/j1/9g8mhj2hqp3i0fpxwrg5wnnqilxr3a-supdup-0.0.drv.gz'. <vivien>Are you sure this is the file you pasted on paste.rs? <Kolev>vivien, I did emacsclient /var/log/guix/drvs/j1/9g8mhj2hqp3i0fpxwrg5wnnqilxr3a-supdup-0.0.drv.gz and pasted the buffer. <Kolev>vivien, that's the file I pasted, yes. <Franciman>hi, does anybody have a package definition of texlab? <lilyp>I fear needing millions of crates <lilyp>vivien: btw. we meme about webkitgtk a lot, but let's take a moment to appreciate inkscape's build time and memory requirements as well <singpolyma>And how inkscape is indirectly a dependency for basically everything with a gui... <lilyp>and even stuff without a GUI :) <cmiller>mwette, efraim: Good to know. If RISC-V does not end up like ARM, I am going to buy a RISC-V SBC. <Guest33>Is there any guides on running guix on riscv? <efraim>guix systeom on riscv or guix on a foreign distro on riscv? <Guest33>any would be interesting, but guix system would be most interesting <Guest33>i have got one riscv board but i have not even booted it yet <efraim>I have 1 here too, I need to see if the 6.6 stock kernel works with it <Guest33>i'm just getting back to find an irc setup i can live with, then i'll be here more, very nice to know others here have the same board! <vivien>I otfen rebuild qtbase too, surprisingly <msavoritias>is there any guide to installing guix with an unencrypted boot and an encrypted hard drive? <sarg>why ci and bordeaux have different substitute availabilities? Aren't they mirrors? <civodul>sarg: hey! no, they are two independent build farms <sarg>civodul, I've responded in the openvpn thread <Kolev>vivien, any other comments w.r.t. supdup.scm? <vivien>I don’t know what the error message is, unfortunately, and I don’t see immediately why it would fail <janneke>Evaluation started 3 hours ago. -- hmm <janneke>and most everything is idle, it seems that ci is not happy <sarg>I've sent a patch w/o checking that there already is an open issue fixing the same. Should I close mine or merge it with the existing? <cddr>msavoritias: I have exactly that setup I have a unencrypted boot parition with other oses efi as well. This seemed to be giving me no trouble <cddr>my root is encrypted btrfs with pbkdf2 <ieure>The guix manual says: "It is possible to manage stateful data with Guix Home, this includes the ability to automatically clone Git repositories on the initial setup of the machine..." <ieure>But there's no further documentation about this ability. Anyone know of a reference for that stuff, or do I need to go read the source to figure it out? <civodul>ieure: there’s currently no such Git service in Guix Home <civodul>maybe there’s something like that in rde, dunno <mwette>efraim: that great news to me -- sounds awesome. I've been trailing some chatter on #riscv and I believe the 6.6 kernel does not have everything. NVMe is not supported. If I find more I will let you know <ieure>civodul, Super annoying that the docs say this, then. It's a thing I'd like to use. <msavoritias>cddr: can you share the boot and filesystems of your config? <sarg>civodul, for a duplicate in debbugs, should I close or merge? <msavoritias>first time i am trying to have boot separately and unencrypted <msavoritias>there are files in /boot which is already unencrypted but grub still puts symlinks to the store <cddr>It's the standard guix installation recommendation that I followed <cddr>(bootloader (bootloader-configuration <cddr> (bootloader grub-efi-bootloader) <cddr> (keyboard-layout keyboard-layout))) <cddr>At /boot I mount my existing unencrypted boot partition <cddr>and here is the filesystems spec <cddr> (device (file-system-label "guix")) <msavoritias>so probably instead of disk i just point to /boot instead <cddr>Yeah you need it mounted not as a device path <cddr>yes but when you add the other root etc. partition in there I think you need to put the mapped-device as dependency as well <msavoritias>cddr: in the boot? i already have mapped devices as a depedency to btrfs <cddr>no I meant the btrfs root, which now I see that you have <ieure>I tried that, but it doesn't seem to work -- I ger "guix build: error: Git failure while fetching git@....: Failed to retrieve list of SSH authentication methods: Failed getting response" <ieure>I can clone the repo from the shell. <ieure>Anyone else have this working, or have a viable approach to the problem? <civodul>hmm looks like git.savannah.gnu.org ran out of disk space, so “guix build /gnu/store/h680kwg43p39iydw097ib4209rv9qg4k-guix-1.4.0-16.aeb4943-checkout.drv” never completes <janneke>civodul: it built for me... /gnu/store/5dk8z6lbbfjjxcgizv8iw0hgmlbjvwx0-guix-1.4.0-16.aeb4943-checkout <nckx>Yes, that seems to be the issue here: Dec 2 19:40:44 localhost sshd[28308]: Unable to negotiate with 2a02:1810:1c81:e400:ebfa:9d01:17f:b0c5 port 47420: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth] <nckx>(So ‘their’ is the client's.) <ieure>nckx, Hmm, could be? My host does offer rsa-sha2-512 and rsa-sha2-256 host key algos. Your theory is that libssh2 doesn't understand those and blows up? <ieure>Okay, no, I think I was looking at the algos the client supports. Connecting to the Git host shows "debug1: kex: host key algorithm: ssh-ed25519" -- so I don't think my host key is rsa-sha2-*, so I don't think that's the problem. <nckx>Yes, until the next release and Guix package update that is what I think is happening. <nckx>Is this only about host keys? I'm no longer at a computer. <ieure>I have no idea what it's about. <nckx>There may be multiple bugs here, I got 2 different errors for 2 different hosts (gitlab.com & tobias.gr). <nckx>What I'd do (but understand if you won't) is update libssh2 to its current master and see which errors, if any, go away, before debugging potentially fixed bugs. <ieure>nckx, I'm game. This does touch on something I'd been wondering about, which is: what's the best way to hack on packages already in Guix? Edit directly in ~/.cache/guix/checkouts? Make another clone and `guix build -L.`? Make another clone and follow "Running guix before it is installed?" <nckx>I run entirely from a checkout, and use either ./pre-inst-env guix (when possible) or commit && guix pull && test, because my 'guix URL in channels.scm points to file:///home/nckx/guix. I regularly pull upstream changes to my own checkout. <nckx>I don't think editing ~/.cache/guix/... will end well, and it's definitely not supported. <ieure>Interesting. I have a mix of systems, most are on Debian with guix installed from apt, but I have GuixSD on a spare laptop that I'm slowly building up to daily-driveable. <nckx>Host OS doesn't really matter for this workflow. Both will support it just fine. <nckx>(You might have to 'guix shell' more packages into one environment than the other, but that's probably it.) <jeremyc>New Guix user, trying dev work on my new install. gcc -o hello hello.c yields "ld: cannot find crt1.o: No such file or directory". I can't seem to find a reference to this related to Guix. Any thoughts? <nckx>How are you providing this gcc binary? <cmiller>civodul: "guix build /gnu/store/h680kwg43p39iydw097ib4209rv9qg4k-guix-1.4.0-16.aeb4943-checkout.drv" I run it on my x86_64 system and it substitutes it. If I rerun again with "--no-subsitutes" it just points to the downloaded store item. Do I now need to run guix gc? I guess you did not mean substitutes by building. <nckx>jeremyc: guix shell --pure gcc-toolchain -- gcc -o hello hello.c works here. Does that, at least, work there? <nckx>ACTION haf to eath now, forry. <cmiller>I also read through the whole Guix manual and Guix cookbook and wrote some stuff down. It is 100+ lines. If I post this in the guix-devel ML, should I have it in the email body or as attachment? <nckx>I meant inline body text, but if you want to preserve line breaks & such inline attachment is fine I guess. <nckx>I'm not sure how the archives deal with those. <cmiller>Okay, just to get it right. I should not create an attachment? <nckx>It would be a shame if your actual message weren't archived. <nckx>cmiller: I wouldn't unless you yourself have a reason to do so. <cmiller>Ah thanks. Since it says so for issues and was not sure if it is the same for the ML. <nckx>jeremyc: Still, guix install should work just as well. Something about your environments seems to be breaking Guix's GCC. <jeremyc>I've done a lot of messing around learning things these past 6 hours or so. Just install guix last night :-) <jeremyc>I'll dig around, maybe create a new user and see. <nckx>cmiller: We are not cranky old byte-perfect 'netiquette' nazis, good intentions are what matters, we can always fix the rest if needed. <cmiller>Yeah but it is my perfectionism that would trigger me. Therefore I just ask before I annoy myself with a "mistake". <cmiller>Has it's benefits. And it's downsides. <cmiller>Does someone use Guix System with Emacs and libvterm? Does directory-tracking work for you? It does not for me and wonder if it is a problem on my side or the package. <ieure>nckx, Updated my clone of guix, updated libssh2, rebuilt, made sure I'd set SSH_AUTH_SOCK in the shell I built it in, ran `./pre-inst-env guix build -L/path/to/my/channel package-with-source-in-authenticated-repo' <ieure>nckx, Now I get "failed to start SSH session: Unable to exchange encryption keys" <cmiller>I also can't see the Bash script if I look into the package via guix build but it has that #:include keyword. <ieure>Is there a way to either: download the source for a package without building it; or: keep the build directory even when building the package is successful? <ieure>I can go rummage around the package definition and figure out the URL and wget it, but it'd be very nice if there was something like `guix download -p package-name' <cmiller>ieure: "guix build -S <package>" should download the source and build only the source but not the package itself. <lilyp>that being said, guix build -S does apply all the guix patches already, so if your build fails there, then it's no luck for you <lilyp>you can also try `guix download <upstream-source>' <lilyp>That'll give you a store path and a hash <ieure>cmiller, Thank you, very helpful. This is an upstream package I'm messing with, so patches aren't going to cause a failure. Probably. <ieure>lilyp, `guix download' requires a URL, though, yes? <ieure>lilyp, Yeah, I specifically want to avoid that. <ieure>build -S does close enough to what I want. <apteryx>cmiller: did you follow the nouveau feature matrix to discover whether your GPU should have acceleration without proprietary firmware? <lilyp>btw. you can also use guix build -K to keep failed builds, that'll give you a (pre-configured, etc.) source <lilyp>so many options, which one makes sense depends on your use case :) <cmiller>apteryx: Yes, so GM204 which also shows lspci -k <ieure>lilyp, It doesn't keep non-failed builds, which would also be a helpful thing for me. <ieure>Context here is that I'm brutally hacking xkeyboard-config so I can have my beloved Hyper modifier. <cmiller>I also get memory errors in dmesg, since I use Guix and have the GPU installed ([ 0.000719] gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 62M) I think Nvidia just hate me a little bit more than other costumors. <apteryx>civodul I have in in by INBOX, among 200 other unread messages, I'll try looking at it, thanks for the reminder :-) <cmiller>ieure: Keeping the build directory of a successful build was something I required some time ago, too. <cmiller>apteryx: Yes, that wonders me as well. AFIK proprietary firmware is only for video decoding required but not for 3D. I wanted to test it out how well it works for games. <apteryx>maybe check in the dri-devel channel (on oftc? can't remember) if they can help with the error <apteryx>maybe there's something outdated or unexpected in our packaging of mesa <civodul>apteryx: heh, no problem (i know that feeling :-)) <cmiller>Will do. Maybe they know what is going on. <ieure>cmiller, Yeah. While I've been making packages, I've added build steps that intentionally fail, just so I can keep the source and poke around to figure out why a step doesn't work. <ieure>Seems like there's some improvements that could be made around debugging builds, generally. <civodul>turns out connectivity cloning Guix from ci.guix.gnu.org is extremely slow right now <civodul>i worked around it by fetching over Tor, which was way faster :-) <civodul>so now /gnu/store/5dk8z6lbbfjjxcgizv8iw0hgmlbjvwx0-guix-1.4.0-16.aeb4943-checkout is in store and all <nckx>ieure: Yeah, that was it. Adding ‘HostKeyAlgorithms=ssh-rsa,ssh-rsa-cert-v01@openssh.com’ to my sshd_config ‘fixes’ the Unable to exchange encryption keys error. <cmiller>Okay I asked on #nouveau on oftc.net. Turns out the 970 requires proprietary firmware even for 3D acceleration which completly eliminates the point of nouveau in my opinion. In that case you could go full proprietary and have better experience. <nckx>ieure: I'm not sure why your attempt didn't work, whether libssh2 master is still missing something, or whether your updated version still wasn't actually used when you invoked Guix. <nckx>But this does sound like the same issue that should have been fixed upstream… 🤔 <iK0u>Has anyone managed to compile librecmc/openwrt on guix? <iK0u>I was trying it with and without the new fhs emulation but ran into a lot of issues <iK0u>Also I was looking around and it appears guix does not have a firewall, is this true? Is there no way to configure a firewall for guix? <apteryx>iK0u: haven't tried; a package for it would be dandy! <nckx>iK0u: Firewalls are provided by the kernel, not the distribution, and Guix's kernel has all of them enabled AFAIK. However, it's true that there's no easy ‘firewall helper’ interface built into Guix like there is in Nix (again AFAIK). You'll have to manage your firewall yourself. <nckx>(Put differently: firewalls aren't packages, you can't install a firewall.) <apteryx>cmiller: uh; so perhaps that matrix table should be marked as EXTFW instead of DONE for the NV110? Or is this requirement specific to just 970 among that family? <nckx>the_tubular: iptables, nf_tables, at least. <apteryx>cmiller: also make sure to mark this card as not working on h-node.org to save the next free hardware shopper the hassle of discovering that themselves <the_tubular>One of those was suppose to replace the other one right ? <nckx>This is Linux so haha but yes. <iK0u>So iptables, etc can still be used normally? <iK0u>Does guix have a sane default ie block all inbound <nckx>Again, Guix does not ship any firewall policy. <the_tubular>But you also need userland utility to use those FW correct ? <iK0u>I figured firewall belonged in the kernel, but I guess I got confused with the vast amount of fw related tools on linux compared to bsd <nckx>Yes. You can ‘guix install iptables’ or ‘… nftables’. <nckx>iK0u: There are tools like ‘ufw’ that abstract over the real firewall and that (+ some default policy) is what distributions provide and what users (seem to) see as firewalls now. Similar to Windows Firewall. <apteryx>which is surprising if 970 GTX requires a blob for the 3D <iK0u>Thanks that clears up my confusion a lot haha, but i am also surprised that linux has multiple firewalls in the kernel <nckx>the_tubular: That's a very good question I've never pondered. I don't know! <the_tubular>There's one that is more modern, you should probably use that one iK0u <nckx>iK0u: Like the_tubular rightly said, nftables is much newer and aims to ‘replace’ iptables, and my flippant reply was just because iptables is ingrained that I don't see it leaving the kernel within 20 years. <nckx>Aw look at us crediting each other in our replies :) <iK0u>I will make sure to remember that I should use nftables, thanks, also, I guess since it uses a configuration file you can probably don't need guile bindings to use it, right? <iK0u>You can probably just include it like a dotfile <the_tubular>I remember seeing some in someone else's config iK0u, but it's been a while and you'd have to confirm <cmiller>UFW would be not kernel but a userspace program? <iK0u>I get that guix isnt entirely beginner friendly yet, but isn't it a little dangerous to ship without any firewall policies by default? <nckx>There is an iptables-service-type that you can use but it's all raw rules and there are no ‘block everything‘ defaults. <nckx>Oh, there's an nftables service too, I didn't know that. <nckx>cmiller: Yes as in it provides a nicer UI to control the kernel firewall, no as in it does not process packets in userspace. <the_tubular>I'm not sure, code would be a better source than me :P <the_tubular>And I'm waching emacsconf and don't feel like checking it right now <iK0u>Oh I see these services in the manual now, must have missed them. "This service comes with a default ruleset %default-nftables-ruleset that rejecting all incoming connections except those to the ssh port 22." <nckx>Yeah, I was only familiar with iptables, sorry. <nckx>The nftables one seems to be a lot more featureful. <nckx>Guix's nftables one I mean. <iK0u>This seems totally reasonable <nckx>Note that it's only the default once you explicitly add nftables-service-type to your services. <nckx>It's not ~The~ default for new installations. <iK0u>Yeah, maybe that should be an option in the installer or something, either way it is much easier to find than I thought, it was my fault for only checking the manual for ufw <Kolev>I have a problem. Someone in #pdp-10 is wanting me to build a program with `make` and `gcc`. <nckx>Kolev: You're missing ncurses. <mwette>In a package extension, if I want to replace the configure arg "--foo=1" with "--foo=2" can I use delete (or something else) with "foo", i.e., w/o knowing the "=1" part? <nckx>Also, (string-append "CC=" #$(cc-for-target)) <nckx>the package defaults to ‘cc’, not ‘gcc’. <nckx>It also doesn't create $PREFIX and doesn't seem to have tests (although I didn't check—heh). <nckx>But those seem like trivial things to fix since it built fine with the above changes. <Kolev>+ #~(list (string-append "CC=" #$(cc-for-target))) <nckx>Yeah, before or after your PREFIX-settin' sexp. <nckx>I'm away though, but the remaining fixes should be trivial. Good luck. <nckx>A phase that mkdir-p's #$output &c. <iK0u>Oh by the way, has anyone managed to make a graphical guix live iso? <iK0u>I managed to do it with nix but not guix unfortunately <iK0u>Sometimes I need these for testing things, I would love to be able to further move away from nix to guix <iK0u>Kolev, thanks! Is it also possible to make it function like an offline installer, so that a particular configuration can be installed without internet? <cmiller>apteryx: Yes, 970 requires firmware for 3D acceleration. I have a 770 which appearantly works with 3D acceleration without firmware blobs. They also told me that nouveau is not intended with Linux Libre. (Which at least makes the nouveau project for me questionable, I mean at this point, I could just use proprietary and get everything out of my hardware... At least I personally see no sense in the efforts) The <cmiller>les Nvidia did some months ago). This is all just stupid. Anyways, I am testing out if the 770 actually works and report it to h-node as well as my 970. Why 960 works without, I don't know. Maybe the 970 was the first that required signed firmware. Sorry for the wall of test.