<tschilptschilp23>on a qemu-vm on the same system running debian11 i clearly get a 4 in the last line <rekado_>tschilptschilp23: I see this error in *Messages*: Error during redisplay: (jit-lock-function 315) signaled (wrong-type-argument markerp nil) <rekado_>right after “Guile REPL up and running!” and before “Code block evaluation complete.” <tschilptschilp23>also, I cannot even call 'geiser-version' here (cannot open load file: No such file or directory, geiser-version) <tschilptschilp23>although i can M-x geiser-version with tab-completion, 'guix show emacs-geiser' tells me it's 0.26.1 <ric342[m]>Can guix be used to configure routers? Like openwrt <ric342[m]>It would be nice to be able to create a minimal image for router with musl and busybox with a .scm *tschilptschilp23 replaces the keyboard with a book for today. <jab>ric342[m]: I think currently guix is glibc only. :) <pkill9>actually I can use the API with curl, nvm, still would be nice though <pkill9>actually the REST api is deprecated and hut is recommended ***califax_ is now known as califax
<old>pkill9: I'm making a guile-sourcehut btw if you want to hack your hut with Guile. It uses the GraphQL API ***PotentialUser-7 is now known as johnabs
<johnabs>Hopefully easy question: my nmapplet icons are all look like "do not enter" traffic signs but without the words. I've installed other icon themes and tried using lxappearance to fix it, but no dice. Any tips on how I can fix this? <johnabs>(p.s. same johnabs as the matrix one, but on my new, almost completely working, guix box :3 ) <podiki[m]>johnabs: perhaps a reboot/relogin and/or fc-cache update (guix does not run the font cache update automatically) <johnabs>podiki[m]: I don't think it's the font cache, as I'm trying to use icon themes, right? I'll try relogging, brb <johnabs>I'm so close to having this system finalized I can almost taste it :D <podiki[m]>likely xdg_data_dirs needed to be reread/set which needed a new login <johnabs>Gotcha; also, random other question: any reason why fn keys would be unrecognized by xev? Specifically my brightness keys don't work :/ <podiki[m]>depending on your DE/WM may have to set that up manually? (I've generally worked in just plain window managers and so set those keys manually with a tool like light) <johnabs>Right, but I mean the keypresses themselves dont appear in xev, but f8 and f7 do for some reason <johnabs>My other fn keys register, but they don't have the typical XF86some_key_function associated with them <podiki[m]>could also be a bios setting, sometimes there is something there for what is the default behavior (with/without fn key pressed), otherwise I don't know <johnabs>Oh, I didn't consider that, I'll check it out! thanks again for your help :D <podiki[m]>and at other hours there are plenty of laptop guix users (I use it mainly on a desktop) that can help <johnabs>Solved the keyboard issue, but I'm unsure how to blacklist a modprobe module. Does that happen in the (initrd ) form? <kreved>johnabs: I think (kernel-arguments '("modprobe.blacklist=...") is enough <johnabs>Does that form go in the (kernel linux) form or elsewhere in the operating system form? <johnabs>That may seem like a silly question, but I've been confused on form placement all day lol, and thanks for the input :3 <johnabs>Actually, it compiled, wish me luck lol <johnabs>It says I need to create a file: /etc/modprobe.d/framework-als-blacklist.conf and add blacklist hid-sensor-hub to it <johnabs>I added this form (kernel-arguments '("modprobe.blacklist=hid-sensor-hub")) Am I missing something here? <johnabs>Does guix reconfigure update the initramfs? <johnabs>Okay lsmod shows it's still there, so no dice yet :/ <johnabs>Thanks kreved I got it! Turns out the original thread I was using didn't have the same lsmod entry as me ( I needed underscores instead of hyphens). <ytc>how can i change the configuration of network-manager? guix manual doesn't offer many options. <vivien>ytc, you can configure it from your user account, with gnome-control-center or nm-connection-editor <vivien>Make sure that the connection is available to all users <tatsumaru>hey guys, noob question, but is it a good idea to run guix on production servers / containers running web apps etc.? <rekado>tatsumaru: it’s not a question of Guix but of whether a sysadmin exists to maintain the server <tatsumaru>wouldn't any linux sysadmin be able to maintain a guix server? <rekado>Guix is perfectly fine for production use, but it’s no magic bullet — you’ll still need someone to stay on top of updates <rekado>tatsumaru: would you say that any Debian admin can maintain a RHEL system? <tatsumaru>rekado: I am not sure, I am not a sysadmin myself, but if I had to guess, I'd say it wouldn't be too difficult for them to learn the differences <rekado>tatsumaru: right, but learn they must. <rekado>Guix is different enough to require some learning. <rekado>no, but all of *.guix.gnu.org does ***Dynom_ is now known as Guest9721
<ytc>I cannot connect any Wifi network using nmtui with my user account. It says "Insufficient privileges." <ytc>How can I use network-manager as a non-root user? <civodul>it built fine on i686-linux though, go figure <civodul>"Error 134" means SIGABRT, which is not good <civodul>it looks non-deterministic though, lemme retry the build <lizog>civodul: thanks for the quick response <civodul>heh, it's has already succeeded (most likely another build machine had built it in the meantime) <brendyn>ytc, not 100% sure but ive had that problem in the past. you may need to run a polkit authentication agent <brendyn>if you are not already in a desktop like gnome <ytc>brendyn: i have to run "sudo nmtui" to connect wireless networks <brendyn>ytc, yep but its possible to do it without sudo you just need the polkint authentication agent running i think <pkill9>does cgit provide an rss feed for commits? <gnucode>nckx`: I think I finally got opensmtpd-service to let you define filters! <gnucode>I feel like Dr. Frankenstein. It's alive! It's alive! <mohamed>go: could not create module cache: mkdir /homeless-shelter: permission denied <mohamed>Any idea how to fix it/allow tcp when building package <gnucode>mohamed: I believe the goal is to NOT allow a package tpc access when bulding a package. The goal is an isolated build environment. <gnucode>Whatever dependency it is trying to get, it should not be allowed to willy nilly download from the internet. :) <gnucode>My 2 cents. :) I would know... I've never packaged anything in guix before. :) <shcv[m]>gnucode: nice; I've been interested in setting up email on a guix host <shcv[m]>mohamed: yes, builds are supposed to be reproducible and thus should not interact with the environment <shcv[m]>that looks like go is trying to install a dependency; try adding that package to the inputs <shcv[m]>try searching for the package in the guix repo, but if it doesn't exist you can use `guix import go <package>` to generate a package for it <shcv[m]>packaging in guix isn't usually hard, it's just occasionally tedious because you have to hunt down all of the dependencies <gnucode>that's where I am currently trying to improve our current opensmtpd service. <mohamed>Ok thanks @gnucode and @shcv, I will look at it. I need to add the dependencies both in the import package and in "native-input" ? <shcv>mohamed: depends; `native-inputs` is for tools needed at build time but not runtime, like parser generators. Looking at other golang packages (in guix/gnu/packages/golang.scm) I think you probably want `propagated-inputs` for most of your libs, and `inputs` for testing frameworks etc. <shcv[m]>unmatched-paren: I think I'm still having the issue where `guix pull` doesn't update the repo that `guix system reconfigure` is using. `which guix` is /home/shcv/.config/guix/current/bin/guix, and `guix --version` is "guix (GNU Guix) 0"... I have also tried guix home, which I thought might be interfering, but reconfiguring it didn't seem to change anything <antipode>shcv: It's not about build-time vs runtime, e.g. header-only packages are only needed at build time, yet they need to be in inputs. <antipode>It's about 'architecture it's built on' vs. 'architecture it will be run on' <antipode>(headers are sometimes architecture-dependent!) <antipode>shcv: Testing things are for 'native-inputs', as tests are run on the architecture things are built on. <mohamed> Ok thanks guys, to be honest it way more complex than "make & make install" but I will try to do it <shcv>antipode: whoops; you're right, thanks for the correction. I think I abridged my message incorrectly and got inputs and native-inputs swapped. <shcv>(was looking at docs for the definitions and and golang.scm for examples, so I should have no excuse...) <PurpleSym>Do any Rust wizards know how I can resolve the following error during 'build? error: failed to get `anyhow` as a dependency of package `dolby_vision v2.0.0 (/tmp/guix-build-dovi-tool-1.5.7.drv-0/source/dolby_vision)` <antipode>PurpleSym: Did you check that 'rust-anyhow' is in the inputs (actually #:cargo-inputs, I guess)? <PurpleSym>antipode: Yeah, both rust-dolby-vision-2 and dovi-tool (which I am trying to build) have this dependency in #:cargo-inputs. <PurpleSym>I also updated rust-anyhow to 1.0.65, because that’s what both require. <old>Hey any way to tell `guix pack` to not include everything? For example when I bundle a package, the entire inputs are pulled as if they were propagated inputs. <old>This results in having header files in the bundle when they are not needed for example <antipode>old: IIUC, "guix pack" only pulls in references. <antipode>Perhaps one of the things it refers to can be split up in separate outputs (e.g. with a separate "include" output). <old>antipode: Right. It's one downside I found of it. The resulting bundle are enormous <lilyp>that's the point – you get everything you need <lilyp>guix packs are not that large compared to equivalent docker container or similar solutions <old>My point being there's thing that are not needed. My program does not need header files of llvm at runtime <old>They are large depending on what you put in it. <old>I have a bundle that uses rocm-runtime, the resulting tar.gz is a few hundreds MB at least <old>Ofc the header files are probably not going to downsize that much. But I'm sure there's other things that could be left from the bundle and reduce the size. Such as the entire coreutils translation in 60 languages <antipode>old: What downside are you referring to? <antipode>If headers are large, and hence should be in a separate output, that's a ‘bug’ of the llvm package, not "guix pack" <antipode>old: "guix pack" doesn't know what language you would like to use tings with. <old>I agree. Maybe I should just do some triming after the pack then <antipode>Why not adjust the outputs of packages instead? <antipode>nckx: sneek's connection is misbehaving, is there such a thing as a 'temporary ban'? <old>antipode: So I should use a transformer for that? Adding an output to the packages and only use that for the bundling <antipode>old: You could do that, but that's (1) complicated and (2) only benefits yourself. It would be simpler and benefit more people to modify the package definition instead and send a patch. <old>Right. But what if I want to trim everything except the bare minimal. A `diet' bundle. I can't impose that on other <old>ofc if thing would benefit the community I would contribute to the main channel instead <old>Yes that's my idea also. Just unpack, sweep things and pack again <antipode>Though I expect there is something between 'status quo' and 'diet' that would be acceptable for upstream Guix, so I would propose to patch+send things for upstream Guix where feasible and unproblematic and leave other things for post-processing. <two[m]>if i'll install guix again, will it reuse /gnu/store <pkill9>two[m]: nah i think it'll overwrite the database so effectively won't 'see' anything in it, I think, idk <jab>I should have another patch for opensmtpd-service with proper scheme records in a few days hopefully. Pretty excited about that. <antipode>civodul: ‘build-system: Factorize 'strip' flags and directories.core-updates’ causes a build failure (of openjpeg-data) <antipode>civodul: The issue appears to be that 'copy-build' does (sexp->gexp strip-flags) even though the new strip-flags is a G-exp. ***bovid-19 is now known as bovid
<Gu4st>I'm getting nouveau crashes regularly (crashes desktop environment), dmesg reports `nouveau 0000:09:00.0: fifo: fault 00 [VIRT_READ] at 000000000c8ab000 engine 0f [ce0] client 20 [HUB/HSCE0] reason 02 [PTE] on channel 4 [00fec51000 elogind[489]]` <Gu4st>been happening with icecat open watching youtube, 3 times so far <Gu4st>not sure where to look for this kind of error, seems pretty low level driver/memory stuff <jpoiret>wouldn't that be a nouveau issue mostly? <jpoiret>especially if it's a stability issue <jab>Gu4st: What kernel version are you using? <jab>and what is your hardware? <Gu4st>not recent, but maybe too recent for nouveau to be comfortable with... <jab>Gu4st: well it's not a bad kernel... 5.19.12 was the bad one... <Gu4st>I'll ask in the nouveau channel <andi-[m]>I am trying to generate a JSON file as part of my home configuration. Is there a function that generates a JSON file based on the values that I pass in my guile code? <jab>I just stumbled upon libre.computer <jab>Seems like you can buy some open-ish SOCs <two[m]><andi-[m]> "I am trying to generate a JSON..." <- as i understand it's like <two[m]>(scm->json-string `((type . Person) (name ,username))) <pkill9>rekado: i noticed you mentione din the mailing list that gnome on wayland has problems for you, specificlaly you mentioned that it flickers with black screen, do you know what might be causing this? <nckhexen>sneek: later tell antipode: We do, through litharge, which is a bot (oh! vile bots!) that remembers to unban the person. Unlike, say, me. That's as high-tech as it gets. That and prodding sneek's owner in #guile. <lechner>Hi, why does ./pre-inst-env guix build X recompile nearly all scm files for being newer than the corresponding go's, please? <podiki[m]>I don't think it recompiles but just tells you that the compiled version is out of date (since it will keep saying so until you run make, if I remember) <lechner>podiki[m]: ah, thanks! so running make once will save time? <lechner>Hi, i'm trying to update sequoia but the rust prerequisite structure is quite complex. Is there a simple strategy at which point I should be working off of core-updates instead of master? <podiki[m]>yup, and that should be quite quick, unless you are catching up on lots of commits and need to do a frull rebuild <lechner>also, is gnu/packages/crates.io meant to be modified by hand? <lechner>I guess my question is, how can tell quickly if core-updates or staging contain newer versions while packaging a less popular package on master? <lechner>newer version of any required prerequisites, that is