IRC channel logs

2024-09-20.log

back to list of logs

<aswjrisp>Rutherther: nckx: I should have said undesired behavior.
<aswjrisp>Now I am trying to get the loging to work for the service.
<makx>look: there is a crate importer?
<aswjrisp>I commented out the line nckx shared for loging because I would like to use shepherds loging.
<aswjrisp>I looked at what other services are using of the #:log-file it looks like they are using /var/log/service-name.log I tried touching /var/log/wpa-supplicant.log and changing the service log-file to that.
<look>makx: https://guix.gnu.org/manual/en/html_node/Invoking-guix-import.html#index-crate
<aswjrisp>Nothing is logged to /var/log/wpa-supplicant.log
<aswjrisp>This is the definition of the service which is not logging. https://termbin.com/rjj0
<aswjrisp>For shepherd logging is there a specific service or package I need to have for it to log the services logs?
<aswjrisp>I am getting general shepherd logs like service started and service stoped in /var/log/messages
<wizard>hi guix :) i was never able to figure this one figured out after yesterday
<wizard>im trying to update sbcl-trial
<wizard>needs a lot of deps
<wizard>here's the guix.scm i'm using to test it all out in a shell
<wizard> https://0x0.st/X3ES.txt
<apteryx>sneek: later tell civodul: congrats on 'gnu: guix: Update to e85f52e.'
<sneek>Got it.
<wizard>for some reason it doesn't compile because of a missing symbol in the pathname-utils library
<wizard>but i overrode that library to have the newest version, which has the symbol in that file
<wizard>so idk why it's not working
<wizard>anyone have any ideas how to fix?
<wizard>maybe this would be better to ask the mailing list idk
<meaty>Does Guix have any particular issues with running "loose" ELF binaries? I'm trying to execute a binary downloaded off the internet and I get 'bash: $FILENAME: no such file or directory'
<meaty>looked online and it says it could be a linker/library issue. which i'm not sure how to resolve in guix
<podiki>"issue": well binaries tend to assume FHS, e.g. /bin /lib to find things, and that doesn't exist in guix
<podiki>you can use patchelf, use the ld-loader directly, or the FHS container option of guix shell
<podiki>all require some efforts
<podiki>(that error you get is due to not finding the ld-loader where expected, because there isn't a global one in guix)
<meaty>fhs container seems like the most convenient option
<podiki>depending on what you are running and need, can take some guessing to figure out what goes in container/what to expose from host
<podiki>but it is handy (i'm biased since i helped contribute it)
<mange>Hey wizard, I had a look at your trial update yesterday. I could reproduce your problem, but I don't know what's causing it. :( If it helps, the version of sbcl-pathname-utils in Guix also has that function, but the build still reports an issue when I use it instead of your updated version.
<wizard>ty for taking a look mange :)
<wizard>glad i'm not just the only one at least haha
<mange>That is to say: I don't think the issue is with pathname-utils itself. I think there's something up with the how the build is discovering its dependencies, or something.
<wizard>i didn't want to bother upstream with it because that's what i suspected as well
<PuercoPop>podiki: does guix provide any api in their build system for patchelf?
<podiki>PuercoPop: api? i think our patchelf is just patchelf
<podiki>oh you mean a build system using patchelf
<podiki>no, not in guix
<podiki>as we build everything from source as a requirement; a few packages might call patchelf manually to do something in building though
<meaty>Oh, also I did a guix reconfigure and now my qt apps aren't using the preferences set in qt5ct, would anyone know offhand why that is? specifically including cantata and quassel
<mange>Sorry wizard, turns out I was wrong yesterday. I think there's a simpler issue going on: you're adding the sbcl-pathname-utils dependency for Trial, but there's already another (older) version loaded in the build which is breaking it. Here's an example using package-input-rewriting that gets further: https://paste.sr.ht/~czan/b52167fa93fae7e11b1a34d167f16866d06248a6
<mange>It still breaks, just later (on trying to find GLSL-TOOLKIT:PREPROCESS). This wouldn't be an issue if you were preparing the patches in-tree, and running using ./pre-inst-env, because then your updated versions of the dependencies would be propagated throughout the package graph.
<mange>To do it out of tree, I think you'll need to use package-input-rewriting for each of the packages you're updating, so make sure the replacement is done everywhere that Trial needs.
<mange>It looks like glsl-toolkit will also need an update.
<wizard>mange: tysm for taking an update :)
<wizard>taking another look*
<wizard>(i'm tired)
<wizard>very good info
<wizard>i def wanna see if i can get everything mainlained at some point, so maybe i'll just start figuring out how to contribute now rather than putting it off until after i got it out of tree
<PuercoPop>Is there a service to extend to add things to your .bashrc from another service?
<mange>For Guix Home? home-bash-configuration should do it. See "home-bash-extension" in the manual: (guix) Shells Home Services
<necto>Hi there!
<necto>I've recently learned that in addition to the `master` branch on guix repository there are various `*-team`, like `python-team` branches that seem to be pretty long lived.
<necto>Where can I read about them?
<necto>Are they supposed to merged into `master` at some point?
<Guest58>Heyho!
<necto>Also, is there a way to combine `master` and `python-team` in the meantime?
<mange>Hi necto, I believe those branches are created for different teams (see "(guix) Teams" in the manual) to update packages in their scope in a coordinated way. I don't think there's any specific timeframe for them to be merged.
<necto>Thanks, mange!
<mange>I don't know if that's written down in detail anywhere, though.
<PuercoPop>mange: Thanks
<necto>I am following this patchset: https://issues.guix.gnu.org/71540#19 and the last message "I'm building it..."
<necto>What does it mean to build a patch?
<necto>Is there an easy way to build every package that could potentially be affected and run their tests that are affected by a patch?
<necto>I am not sure how to search for it in the manual..
<mange>I assume they mean applying the patch(es), and building the resulting package. You can use "guix refresh --list-dependent" to see the packages that you'd need to rebuild to check it.
<necto>I see, nice! I'll try to do that
<apoorv569>Hi, has anyone here looked at this patch yet? https://issues.guix.gnu.org/72673
<apoorv569>Also I have some issues opened in the tracker that can be closed now, https://issues.guix.gnu.org/66385 https://issues.guix.gnu.org/71967 https://issues.guix.gnu.org/66818 (linux-libre@6.5.9 package doesn't exist anymore)
<apoorv569>Following the patch, this issue can be closed as well, https://issues.guix.gnu.org/68565
<Rutherther>can't you close your issues by yourself?
<apoorv569>Can I? I don't know how.
<Rutherther>by sending e-mail to "<issuenumber>-done@debbugs.gnu.org" instead of "<issuenumber>@debbugs.gnu.org". But I might be mistaken and it might indeed work only for maintainers
<apoorv569>I see. I can try it.
<apoorv569>I sent for this one, https://issues.guix.gnu.org/66385
<apoorv569>it looks like it just added a comment on the issue but didn't close it.
<Rutherther>but you sent it from different e-mail, so then it really cannot work as it doesn't know you are the author
<apoorv569>Where do I see which email I used? I have a couple.
<Rutherther>download the original message
<apoorv569>I see. let me try again.
<apoorv569>OK, it worked. https://issues.guix.gnu.org/66385 is closed.
<apoorv569>I didn't know that. I'll close others as well.
<nutcase>By accident, I run "guix pull" as root. Where does this store data and can I delete that?
<mange>Actually as root? Not with sudo?
<mange>Assuming the answer is yes: Icheck /root/.config/guix and /root/.cache/guix
<elpogo>does it make a difference if run with sudo or directly as root mange ?
<mange>I'm never sure about which environment variables do what when using sudo. :) I think it might even be different on different distributions? I think there are combinations where "sudo guix pull" could write to ~/.config/guix and ~/.cache/guix for your user, rather than for root.
<elpogo>wow. i always run guix as a non-root user so i can't verify, but i hope you're wrong mange. doing unpredictable things when run with sudo just doesn't seem the guix way. everything is so well designed.
<mange>I don't think it's Guix's fault if sudo leaves HOME as the user's home, but runs as root. Guix is predictable in writing to $HOME/.config/guix and $HOME/.cache/guix.
<Guest73>hi all, I had to restart the guix daemon because the system didn't automatically create the default user profile upon installation of the first package for a new user. is this a known quirk?
<nckx>‘guix pull’ should refuse to run when $HOME/.cache/guix is not owned by the current user.
<Guest73>I meant /var/guix/profiles/per-user
<nckx>I was responding to a previous message. I've not heard of your bug before, but then I haven't installed Guix in… a while.
<nckx>I've always used the ‘guix package’ interface to install user packages and have never had to restart the daemon or manually create anything in /var.
<nckx>ACTION away.
<Rutherther>Guest73: so after you restarted the daemon an rerun the same command it got created? or what exactly happened?
<Guest73>so the deamon was running for quite awhile (its a hosted system on ubuntu jammy), and likely some package was updated/restarted etc. (likely something selinux related). then a new user did $guix package -i and the daemon (or the frontend) complained it can't write to /var/guix/profiles/per-user. then we restarted the daemon and everything was back
<Guest73>to normal
<aswjrisp>I have found something wierd with a shepherd service following a sysmlink. I have made a shepherd service that runs a shell script.
<aswjrisp>In the shell script it call the path `which dhclient` outputs.
<aswjrisp>I can see from /var/log/messages that shepherd starts the service.
<aswjrisp>But then shepherd outputs "exec of /gnu/store/.../bin/dhclient failed: No such file or directory".
<aswjrisp>`which dhclient` outputs a path to a symlink and that symlink points to /gnu/store/.../sbin/dhclient
<aswjrisp>The ... is the same in both cases. What is different is shepherd is trying to use bin/dhclient that does not exist where it should be usisg sbin/dhclient.
<aswjrisp>I am not sure why shepherd is failing to follow the symlink correctely.
<aswjrisp>I do not think this is a result of me doing anything wrong in this case.
<aswjrisp>Other shepherd services I have made that call a shell script and use the path given by which work fine. So I do not know why there is a problem following the symlink for dhclient.
<aswjrisp>I could probably use the path for dhclient in the store but the symlink which gives for dhclient would be more stable, so I would prefer to use the which symlink.
<aswjrisp>Maybe a shepherd bug or a bug in something shepherd is using?
<Sintenedor>Hi, I want to use "guix home container", the user should be a member of certain groups (seat, input and video) but I do not know how to make it.
<aswjrisp>Sintenedor: Look at the guix manual section User Accounts.
<aswjrisp>It has an example.
<Sintenedor>But I am using <home-environment>, not a <operating-system> as a record input. The command that I use is: "guix home container -f home-configuration.scm".
<Rutherther>Sintenedor: groups are a system-level stuff, you cannot assign your user groups with user privileges.
<pjals>If you could assign groups in guix home, people would be assigning themselves to the disk group and shredding the drives on any public machines.
<Sintenedor>Okey, but the container change my current user groups to: users and overflow (only in the container). How can I maintain the original groups of my user?
<sham1>You don't have your original groups within the container, most likely
<sham1>You have to deal with that separately
<Sintenedor>Thanks, I want to launch a sway instance inside a container (to test configurations), maybe this a XY problem.
<aswjrisp>I tested it and the service works when it call a script that uses the path for dhclient in the store. But it fails when it uses the symlink which provides for dhclient.
<aswjrisp>yelninei: thanks for your help yesterday.
<yelninei>no problem :): Did the exec thing help?
<aswjrisp>Is there anything I can try to get the symlink provided by which to work in the script. I would prefer to use that then directely use the path to dhclient in the store.
<aswjrisp>yelninei: It works with and without exec before the symlink provided by which. But it needed the symlink provide by which.
<aswjrisp>Except for this weird case with dhclient where shepherd is not finding dhclient because it is looking in /gnu/store/.../bin/dhclient instead of in sbin that the which symlink points to.
<aswjrisp>But using the path for dhclient directly works. So there is a problem with how shepherd is following the symlink provided by which for dhclient.
<martin2020>hi, is there a way to use sdl2 that is installed by foreign-distro guix? I tried, and the headers are accessible to my compiler, but when I actually execute my app that relies on newer sdl2, it fails to find the new symbols
<aswjrisp>s/directly/directely in the store/
<aswjrisp>My correction was incorrect.
<Rutherther>aswjrisp: what is the content of the script?
<podiki>probably you want to use a gexp (and maybe as a guile script)
<podiki>e.g. (invoke (string-append #$dhcp "sbin/dhclient")) or similar
<yelninei>aswjrisp: Did you add /run/current-system/profile/sbin to the PATH of the shepherd service (the #:environment-variables option)? Because the default PATH for make-forkexec-constructor is only /run/current-system/profile/bin
<yelninei>so it might be finding the store entry for /run/current-system/profile and then tries to look for bin/dhclient which does not exist
<Kabouik>I'm really not sure what to do with that error showing up every time I open a terminal (Fish shell): https://0x0.st/X3GD.txt It didn't go away after a system reconfigure, update of my packages, or reboot.
<Kabouik>It started showing up after reconfigure/package update.
<aswjrisp>Rutherther: The script is https://termbin.com/bwbd
<aswjrisp>For this script if I change the path to be the location of dhclient in the store it works. So something is wrong with how it is following the link and using bin instead of sbin.
<aswjrisp>I was also unable to get logging working for the service so I am using the logging trick shared by nckx. But I would like to get normal service logging working.
<aswjrisp>podiki: That is a good suggestion to use a gexp. I am new to guix and have not learned guile yet. Right now using shell scripts is an expediant for me to get some network services working.
<aswjrisp>Later I can replace them with gexp once I have leared about guile.
<aswjrisp>yelninei: That is an interesting suggestion. I do have another service for wpa_supplicant that is working fine and the path that which gives for the wpa_supplicant symlink is a sbin one. My wpa-supplicant service is not using #:environment-variables.
<yelninei>weird, i am out of ideas now
<aswjrisp>yelninei: I will try your suggestion anyway.
<aswjrisp>Does shepherd logging require that specific packages or services are part of the system?
<aswjrisp>yelninei: Would I just do #:environment-variables /run/current-system/profile/sbin ?
<yelninei>aswjrisp: I think it is a list, so something like #:environment-variables '("PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin")
<aswjrisp>s/system?/system for shepherd logging to work?/
<aswjrisp>yelninei: Okay, I will give that a try.
<aswjrisp>If shepherd is meant to manage deamons, many of which are probably in sbin, would it not make since for it's path to include sbin?
<yelninei>you might have some problem with your script because shepherd will watch your bash process and not the subprocess from that
<Rutherther>yelninei: why does that matter? the bash process exits with the subprocess thanks to how it's written. And killing it will also kill its child
<nckx>Kabouik: 'Try upgrading both `libxfce4util' and `gconf', or remove one of them from the profile.' You're not upgrading gconf in the same command.
<nckx>I.e. "guix install libxfce4util gconf" — does that work?
<yelninei>hmm yeah. I might be incorrect then
<Rutherther>but I would also say using exec is better since that bash process is no longer needed
<nckx>aswjrisp: No. You're writing a hacky service as a learning experience, but this is not how the Shepherd is meant to be used in Guix. A proper service will refer only to /gnu/store file names generated by gexps in your service declaration.
<aswjrisp>Rutherther: Okay, I will use exec in these service scripts.
<nckx>Adding any random global directory is not useful in that context.
<aswjrisp>yelninei: Should I cons the PATH evironment variable to the default environment variables so that the default environment varibales are not clobbered. If so what would the default environment variables be called (ex. %base-packages)?
<yelninei>No, the default-environment-variables only has PATH with bin: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/shepherd.scm#n427
<aswjrisp>podiki: nckx: I understand now that guix services are supposed to be done with guile. But this seems like a large barrier to have infront of new guix users that do not know guile and want to make some simple services.
<aswjrisp>Is there a guile function that can be used for running shell scripts as shepherd services that handles these hacky issues I am running into?
<aswjrisp>My hacky services using shell scripts is motivated by two problems I have. The first is that I do not know guile yet. The second is that it is my understanding that guix services do not have an off by default option.
<aswjrisp>so they do not start at system start up.
<Rutherther>aswjrisp: have you tried using the function I wrote for modifying services to not auto start?
<Rutherther>it's a pity something like this is still not in guix https://issues.guix.gnu.org/27155, it would solve this issue completely
<Rutherther>of not being able to modify services easily
<aswjrisp>yelninei: When I add your suggestion to the make-forkexec-constructor (forgot it's real name) and reconfigure. The reconfigure gets stuck at starting services. I will give it more time to see if it finishes.
<Rutherther>did you put in #~(make-forkexec-constructor or only (make-forkexec-constructor?
<aswjrisp>Rutherther: I have not tried it yet because it sounded like it would not work in all cases.
<aswjrisp>Rutherther: Is that issue you referenced not resolved because they is not a complete implementation put together?
<aswjrisp>s/they/there/
<Rutherther>aswjrisp: I don't know why it's not resolved. Seems like the thread has a possible implementation put together
<aswjrisp>Rutherther: #~(make-forkexec-constructor
<Rutherther>okay, that is good then
<aswjrisp>The reconfigure is stuck at starting services.
<aswjrisp>Okay, I think a take away for me is that shepherd services do not play nicely with shell scripts.
<aswjrisp>But I think I have collected enough work arounds that I may be able to finish putting together the network services I want.
<aswjrisp>Rutherther: nckx: yelninei: podiki: Thank you for your help.
<abbe>hi
<abbe>lately I started noticing "guile: warning: failed to install locale" in my zsh session
<abbe>I run GuixSD, and have locale set in my operating-system definition, and installing glibc-locales, and am glibc-utf8-locales packages in system profile
<abbe>any ideas what am I missing here ?
<abbe>thanks in advance
<Rutherther>abbe: recently there was core-updates merge that started this. Did you reconfigure your system and home after pulling recently?
<podiki>getting could not build missing derivation again, eg https://ci.guix.gnu.org/build/5865498/details
<lispmacs[work]>hi, I was wondering... is there a way to have "guix shell" set all the environment variables without actually starting a new shell? I am trying to use "guix shell" within Eshell, but that doesn't really work because it drops you into bash.
<lispmacs[work]>I can work around it running guix shell, then saving the environment into a file, and then sourcing that within Eshell, but it is a bit of a bother
<sham1>You could always see how something like direnv does it
<lispmacs[work]>sham1: direnv...?
<Rutherther>lispmacs[work]: use --search-paths
<sham1>lispmacs[work]: <https://direnv.net/> A very useful tool. Allows you to for example set your directory-local environment to be from a given Guix shell environment or profile or whatever
<sham1>But yeah, if --search-paths would do it, that would probably be better
<sham1>There's also packages like envrc for emacs that let you integrate the direnv functionality
<Rutherther>direnv uses --search-paths as well
<sham1>Well there you go
<lispmacs[work]>i'm not quite sure if Eshell can handle the syntax outputted by --search-paths, like with {$PATH:+:} and all that
<Rutherther>then you will have to parse it
<lispmacs[work]>hmm, guess I could, but might be easier to just parse the output from "guix shell <package> -- env" which just gives you the raw environment
<lispmacs[work]>then I just have to add "export " to the beginning of each line
<ieure>lispmacs[work], No program can set the environment of the program which invoked it. Stuff like direnv works by hooking behaviors into the current shell.
<ieure>Child processes inherit a copy of their parent's environment, and can only change it for themselves. It would be a security disaster if arbitrary programs could change the environment of their parents.
<sham1>I guess the idea is to collect the output of guix shell -- env and the use that
<ieure>Yes, that would work fine.
<ieure>Helps to understand what is/not possible, though, I think.
<lispmacs[work]>hmm, okay, I think I'll go the path then of just collecting the env output. Sounds not too difficult with a bit of elisp
<galois`>Hi. How do I get Vulkan running on my machine? Currently I get the following error when running vkcube: Unable to find the Vulkan runtime on the system.
<galois`>This likely indicates that no Vulkan capable drivers are installed. I have a AMD ATI 05:00.0 Renoir GPU
<sneek>galois`, you have 1 message!
<sneek>galois`, nckx says: Guix doesn't package proprietary software. Fonts are no exception to that. If monogame(?) were in Guix we'd patch it to use a free alternative like Liberation Sans.
<aswjrisp>galois`: You could try searching for a driver with guix search.
<galois`>aswjrisp: Yeah but I have mesa installed. That should include the RADV vulkan driver
<aswjrisp>galois`: Have you tried greping your store to check for the driver to make sure it is installed?
<Rutherther>galois`: how did you obtain vkcube? - are you sure it compiled with proper dependency paths?
<aswjrisp>galois`: There is xf86-video-amdgpu
<aswjrisp>Is renoir part of radeon?
<abbe>Rutherther: yep, I regularly reconfigure, and that's when it started happening
<galois`>aswjrisp: Yeah, it's an AMD GPU, the laptop I obtained is a Tuxedo Aura 15
<abbe>pull, and reconfigure (to be precise)
<galois`>Rutherther: Well I installed vulkan-tools, vulkan-headers, vulkan-validation-layers
<galois`>aswjrisp: Yes, Renoir is part of AMD's radeon series.
<galois`>Are you able to run vkcube by any chance?
<aswjrisp>I made a service that does not auto start at boot for ntpd. For this service I am not using a shell script I am just calling ntpd directely from the service start.
<aswjrisp>After a successful reconfigure and as root I try to start the ntpd service. When I look at the log it says Permission denied
<Rutherther>galois`: I think vulkan-tools is not compiling vkcube properly. Compiling it from source is fine. I don't think it's an issue with Vulkan headers
<aswjrisp>Any idea why herd run as root would not have the permissions to start a ntpd service?
<Rutherther>"guix shell -D vulkan-tools mesa meson libpng ninja" to get the proper deps in a shell
<aswjrisp>galois`: In the description of xf86-video-amdgpu it specifically mentions radeon. Are you running x or a wayland compositor?
<Rutherther>used this as source https://github.com/krh/vkcube/
<Rutherther>s/headers/drivers
<galois`>Ok, thanks. Do you think vulkan is working then? I guess I have to try it out..
<Rutherther>yeah, I think it's working. mesa is compiled with vulkan support
<galois`>Hmm. I tried meson setup builddir and everything seems to work except: Has header "vulkan/vulkan_intel.h" with dependency vulkan: NO
<Rutherther>yeah, but that is fine, it's optional dependency
<galois`>Hmm but I couldn't compile either
<Rutherther>what is the error then?
<abbe>Rutherther: sorry to bother you, do you have any hints for me, i.e. the guile locale issue ?
<galois`>Rutherther: https://pastebin.com/RjtZpgdR
<Rutherther>abbe: apart from updating all user packages and system not, which you seem to already have done based on your response :(
<abbe>oh, okay, thanks. No problems, I'll reach out to the list.
<galois`>I'm not sure what dependencies I am missing here. Sorry for my noob questions..
<Rutherther>galois`: ah. Are you sure you don't have some kind of mismatch between glibc from your system and current guix instance you are using? that could possibly cause stuff like that. Or also set ld_library_path
<galois`>Yes that is possible. I also had some conflicting packages while trying to install something. I'll try to resolve it. Thanks for your help. Appreciate it!
<Rutherther>if you didn't want to resolve it now maybe using guix from /run/current-system/profile/bin/guix to get the shell dependencies would work as well
<galois`>Rutherther: Done that, the executable is also produced, however, I get the error: Failed to create vulkan instance
<Rutherther>hmmm, okay. I don't get that error, and I don't really know where the issue could be
<galois`>Ok that's fine. I'll try to resolve my deeper system issue and retry after that. It's good to know that it works on your end. Thanks for your help again! :D
<rkazak>I bought a Thinkpad 480s to run guix on and I see that it does not support the WiFi device that the system comes with. Can I change the Wifi device (easily)?
<aswjrisp>rkazak: You can get a usb wifi adapter.
<ieure>rkazak, Yes, T480s uses an m.2 WiFi card and you can easily swap it. All ThinkPads have readily available Hardware Maintenance Manuals which explain in detail, with diagrams, how to completely tear down and rebuild the laptop. https://download.lenovo.com/pccbbs/mobiles_pdf/t480s-hmm_en.pdf
<ieure>rkazak, If you ever intend to open it, *read the HMM*. For you machine, you will need to go into the BIOS and select "disable internal battery" before opening the bottom. Many people do not do this, and end up with broken laptops.
<ieure>T480s is a real nice machine, congrats.
<aswjrisp>rkazak: You can get a usb wifi adapter that has an atheros ar9271 that has firmware included in the base firmware for guix.
<aswjrisp>If you search for atheros ar9271 you can buy it online.
<ieure>I detest USB dongle wifi. Search up QCNFA222, it's an ath9k m.2 WiFi card, costs about $12. You can swap out the stock Intel one and have a nice clean install.
<aswjrisp>rkazak: Going with a usb wifi adapter means that you do not need to open the computer and you can just plug it into whatever computer you want to use it with if it has a usb port.
<Rutherther>galois": also see this issue https://issues.guix.gnu.org/71109, setting LD_LIBRARY_PATH to "$(guix build vulkan-loader)/lib` for starting vkcube from vulkan-tools fixes the issue with not being able to find vulkan runtime
<aswjrisp>rkazak: Internal or external are both good options with tradeoffs for each.
<ieure>Just my personal opinion, but there's closed-source firmware blobs in the USB WiFi adapters, I don't think that's significantly free-er than blobs loaded onto an m.2 adapter, but I do think it's significantly more annoying to have a dongle sticking out the laptop all the time.
<galois`>Rutherther: I'll look into it, thanks
<aswjrisp>Enabling the service first before running it did not solve the Permission denied error.
<galois`>Rutherther: Hah exporting the path worked now. Thanks!
<galois`>I am able to see the pretty cube :D
<ieure>Will just say, ThinkPads are built to be worked on. The T480s opens easily in about 30 seconds. Don't be afraid to get your hands dirty. :_
<ieure>:)
<rkazak>Thank you all - let me find that part...
<aswjrisp>rkazak: But do read the hardware maintenace manual if you are new to work on computers.
<rkazak>aswjrisp YEP!
<galois`>aswjrisp: Also thanks for your efforts!
<aswjrisp>I got the ntpd service starting by having the shepherd service call a script that starts ntpd instead of starting ntpd directly from the shepherd service.
<aswjrisp>So that somehow works around the permission denied error.
<aswjrisp>ntpd is different than the other services I have made. It starts three processes instead of just one.
<aswjrisp>When I use herd stop to stop the nptd service, herd status tells me that the service has stopped but pgrep tells me that the three ntpd processes are still running.
<aswjrisp>I am not sure why herd stop is not working with this ntpd service while herd stop did work for my other services that used shell scripts.
<aswjrisp>I think it might have something to do with ntpd starting three processes.
<aswjrisp>I wonder if I can have ntpd start just one process.
<aswjrisp>Ops the premission denied was not in the log of ntpd. I was misreading it. I was using a user that did not have permission to read the log.