IRC channel logs
2025-01-02.log
back to list of logs
<muradm>x8dcc: docs will answer question when to use how many spaces for indentation, if you are specific to problems with indentation under emacs especially, that is different story <jjba23>Hey all could someone help me with figuring out why a Guile web app (that does multi threading) crashes as Shepherd service, but not when run normally <jjba23>is there something that needs to be enabled in Shepherd services in order to allow multithreading? <jjba23>btw Rutherther that dbi-close error can be ignored, i verified that causes no problems <jjba23>I suspect my call to (call-with-new-thread) causes the BOOM.. do i need libltdl installed in my Guix server, or something like that <jjba23>Otherwise do you all have some suggestions of async libs i could use in Guile? <Rutherther>jjba23: try running it in "guix shell --pure" where you "export PATH=/run/current-system/bin" (that is what shepherd has) <Rutherther>and of course your other environment variables you added yourself <Rutherther>I don't know why call with new thread would 'cause boom' if it works in your normal environment, but not in shepherd (that just executes the process and tracks it) <jjba23>it's so strange indeed.. i had that big path added since I saw `root` uses that. but do shepherd services run as root too ? if no #:user specified <jjba23>i am first gonna try disabling GUILE_AUTOCOMPILE=0 maybe that changes something? <jjba23>in the server, logged in as root and adding those env variables, then running the command, all works perfectly <jjba23>but when run as Shepherd service it just crashes on multi-thread stuff <Rutherther>you first have remove all other variables, ie by running pure shell. Did you do that? <jjba23>thanks for the tip Rutherther I will try to get more familiar with guix shell and do as you say <jjba23>i think removing the autocompile helped <jjba23>holy smokes it really was that GUILE_AUTOCOMPILE=0 that made the Shepherd unhappy and made him crash the whole stuff <jjba23>do you have any clues as to how this can be Rutherther ? <Rutherther>I still doubt your presumption that it made shepherd itself unhappy is wrong and rather, it is the whole environment. As for why that environment makes it fail, I don't know <divya>I'm trying to package and build a rust app on Guix, the app builds find on `cargo build` and the package definition also goes through the build phase fine, but in the package phase it halts because of some failed tests, the backtrace is here: https://paste.debian.net/1342159/ <Rutherther>divya: in cases like that it can be necessary to browse the source code of the package to see what file it cannot find. As initial guess with failing tests with missing files I would say the crate is trimmed and you might need to use github repo directly. But can be something else <divya>Rutherther: So, the crate that's published on crates.io doesn't have the tests? <divya>Or, the files that are to be tested that is. <divya>Rutherther: Got it. So you recommend me to fetch it from the git repository instead.. <homo>sway doesn't have proper clipboard <ieure>Okay, so I have a Guix System VM image that boots to a sddm login screen. sddm won't let me log in, I guess because my user doesn't have a password set? And for reasons I don't understand, I'm unable to switch to a text console to set the password. <ieure>I configured sddm to auto log in my user; it doesn't work. It doesn't show the root account, but that also has no password, so I wouldn't be able to log in as root, either. <ieure>Ah, okay, I got to the text console. <ieure>Had to capture input devices for the VM to let me send Ctrl-Alt-F1 <Rutherther>ieure: if you are using qemu gtk there is also just console where you can send ctrl alt f1, without capturing your input <ieure>Rutherther, I'm using UTM, which is a macOS GUI that wraps QEMU, I don't see anything like that available in it. <ieure>ugh, argh. My image says it should be 250gb, but is actually only 5gb. <rekado>I restarted issues.guix.gnu.org; no idea why it got stuck again and I won't investigate. <ieure>lfam, I'm not sure what you're asking. <lfam>VM images have a balloon feature, where the actual image file will only be as large as necessary, even though the virtual filesystem can grow to a much larger size <lfam>So, it's expected that a new VM image would be small, even though it can grow to a large size <ieure>lfam, That's not the issue. I believe that's a non-optional feature of qcow2. Issue is that my image specifies a 250gb image, but qcowinfo shows that it's 5.5gb. When I boot the VM and clone my dotfiles git repo, it runs out of disk space. <lfam>How did you create the VM? <ieure>lfam, `guix time-machine --commit=96cd163c14e68c66c6a4cf0b18261fc454f8c1ba -- system image vakum.scm' <ieure>The operating-system is changed (fixed), the (image ...) is identical <lfam>Huh, I've never used the Scheme tools to size the image <ieure>Maybe I need to manually specify the partitions in the image? The VM boots with only /dev/vda1 mounted. <ieure>Not sure how it works all, honestly. <lfam>It's been a while since I've made an image at all, but I always used --image-size successfully <ieure>I'd think the `size' field would be equivalent. <lfam>Maybe they are, maybe they aren't. But --image-size existed for a long time before the Scheme interface <ieure>Well, it's taking way longer to build the image, which might be a sign that it's working. <ieure>And, uh, it's a fixed size, which is a problem, because I want it to be 250gb, but am building it in a different VM with 250gb of disk. <janneke>many python packages depend on zsh, wtf? <ieure>Argh, tried specifying partitions in the image, but it complains: error: "vfat": invalid field specifier <ieure>But the exact same code works in the REPL. <lfam>janneke: Any packages in particular that depend on zsh? Seems funny <janneke>lfam: it's only one pacakge: python-argcomplete <janneke>but many python packages depend on that <lfam>janneke: Looks like a couple dozen packages according to `guix refresh -l python-argcomplete`. Does that match what you see? <janneke>lfam: that could be, clicking through ci.guix.gnu.org for failing packages <janneke>once you follow more than five and finally reach the same root cause it starts to feel like "a real lot" <janneke>seems i got myself fooled a bit there <janneke>hmm, i get: ./pre-inst-env guix refresh -l python-argcomplete <janneke>Building the following 240 packages would ensure 522 dependent packages are rebuilt: .... <lfam>My `guix describe` is 9b1fb12978482ffb, from November <lfam>Maybe it grew more dependencies <meatus> is there some trick to getting emacs to detect tree sitter grammars installed via guix?