IRC channel logs
2024-02-28.log
back to list of logs
<ekaitz>the last think i expected to happen was to see my name there <mange>Ah, the nginx/certbot service example used in that is a bit out of date. You don't need the manual deploy hook any more, and certificates are symlinked to /etc/certs/{domain} now. That makes the example a bit shorter. <larger>GUIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIX <larger>one day i will be free of this oppressive hold the system has on me <larger>and i will instead turn around to perpetuate the cycle of abuse UPON YOU ALL <adanska>Hi, slightly off topic I think, but is there a way to check via /sys/class/power_supply/AC how much power is being delivered to my computer? <adanska>btw, why is the default kernel still on 6.6? <adanska>weve had 6.7 for a while now and its getting updated still <apoorv569>To contribute a package definition to guix, I just send the patch with the diff to the respective module to help-guix mailing list? <adanska>Question: when writing a package definition, if i want to specify my source as a local file, how do i go about doing that? <adanska>can i just use url-fetch and specify a uri to a path in my filesystem? <adanska>it says that `file://` will find the file in the store but am i able to specify a file in my home directory? will it get put in the store for me? <adanska>or do i have to do a `guix archive` to put it in the store myself? <unwox>adanska: the answer is probably (source (local-file "...")) <efraim>podiki: are you the one working on the mesa stuff? <bonz060>Hi guys! Just lurking around, felt like saying hi ;) <efraim>ACTION is terrible about remembering who's working on what :/ <jakef>how does one see what a guix team is working on? are they private groups? <fnat>The installation guide (official manual, including its devel version) doesn't seem to mention LVM logical volumes. Is it possible to set up LVM+cryptsetup as part of the installation? Any resource that documents this? <efraim>rust-team branch merged. Have a little bit more rebuilds than I would've hoped after updating libgit2@1.7 but figured it would be alright <oriansj>fnat: yes it is possible to mix LVM+cryptsetup; crypt the whole drive then put LVM inside of it <fnat>oriansj: Excellent, will try that. Thanks! <ekaitz>cbaines: QA doesn't find attached patches? <Kabouik>Could anyone with some experience with packaging from PyPi help me interpret this error? https://0x0.st/HRBJ.txt This is something I need for work and because I cannot use that library on my main Guix machine, I have to use a Windows machine from work with nothing of my usual environment and it slows me down a lot. <Kabouik>Does that mean that the package on PyPi requires Python 3.13, and the Guix build fails because we don't have Python 3.13 yet? <Kabouik>attila_lendvai: but if this is the pyproject.toml file of the Python package on PyPi, shouldn't it work with Python 3.10 just as well as with 3.13? https://0x0.st/HR9L.txt <attila_lendvai>Kabouik, sorry, but i don't know. i only have a basic knowledge of the python infrastructure. <rekado>looks like someone broke the emacs importer <rekado>"guix import elpa -a melpa mini-echo" fails, but "guix import elpa -a melpa -r mini-echo" works <jakef> changed my user shell in the system config, now i can't login via GDM, but i can login to a tty and it's using the new shell correctly... <jakef>localhost gdm: Gdm: GdmDisplay: Session never registered, failing. <ekaitz>hi! isn't it a little frustrating to do `guix shell -D guix` and not to have `git send-email` there? <ekaitz>or am I the only idiot that every time has to exit the shell and then send the patches? lol <rekado>(I have git send-email installed globally) <efraim>I have git and git:send-email in my guix-home profile <Altadil>Indeed, I was running guix pull right now and it just failed. Do you get the same error ? Mine is : <Altadil>build of /gnu/store/bjjd6i4hvd1mvn0ml3qm8m5s1hccxf3y-guix-package-cache.drv failed <Altadil>It suggests it’s related to a bug in one of the channels pulled from, but I don’t know anything more I’m afraid :( <Altadil>oooh, the log mentions rust-winapi, so I guess it is related to the very recent merging of the Rust branch <sneek>z572, lilyp says: re "guile without unicode", you might want to make use of bytevectors. Guile uses unicode for string representation (as you should in the year of our lord 2023), which also limits the character datatype to an integer between 0 and 0x10FFFF <vivien>(strings should not be arrays of code points) <z572>I'm wondering if it would be better to have a separate module for plasma 6, and I'm not sure about qtwebengine, can anyone help? <podiki>efraim: that's me! I need to send a patch for a cairo update for review (was going to take it on mesa-updates probably since updating libdrm as well). also wanted to update vulkan <efraim>podiki: ok. I ran into a test failure on gst-plugins-base on armhf where zink failed to load vulkan. I'll try to pull up the build log <erikeah>Hi! I hope everyone is having a good day! <podiki>ah right zink and vulkan....did someone figure that out? there's a patch to add a search-path to vulkan-loader (unrelated but maybe?) <efraim>there was a second, unrelated test failure, but that one reminded me I should let you know about it <podiki>this round of mesa-updates would be perfect to fix if we can. i vaguely remember discussion here but can't remember the end result <efraim>I'm not sure about zink and vulkan that much though <erikeah>I have a problem with guix :(, In my workflow I have to download several binaries using tools as asdf-vm and Mason, the main problem is the majority of the binaries has unlinked libraries how can I workaround on this? <podiki>efraim: me neither. all i know is that zink is to implement opengl using vulkan. and that we enabled building the zink driver in the last round of updates to mesa <podiki>maybe i should also cherry pick that to mesa-updates this round <Kabouik>sneek: later tell attila_lendvai: Thank you anyway! I tried other things but run into other issues. First, I tried patching pyproject.toml to remove the mention of Python 3.13, in case python-hatchling would not recognize it yet since it seems very recent. Then, I had a phase check error, so I disabled tests in the package definition, then I noticed the PyPi package comes with support for all architectures and maybe some inputs would be missing in <Kabouik>Guix for some, so I enabled only x86_64-linux as supported system, but I am still having RUNPATH issues while building, related to libusb-1.0.so.0 not being found, although libusb and python-libusb1 are both inputs. I'm lost as to why it is so complicated, it seemed like a simple PyPi package. See logs here: https://0x0.st/HRpI.txt <podiki>Kabouik: just took a quick look at your log. looks like those libraries in the cdll directory are prebuilt? so they would need to be built in your package or maybe can patchelf them. probably need to delete all and just build the one for the arch the package is being built for. <podiki>so the issue would be that this package tries to use pre-build libraries <Kabouik>It's very likely that they are prebuilt indeed, it didn't occur to me. From where I am right now, what would you think would be the easiest? Using binary-build-system? <Kabouik>I appreciate your time looking at the logs by the way, podiki, thanks. <podiki>if so, maybe you have one package to build the libraries, another for the python bindings which uses the guix package one (may need to look for how the python package opens the libraries) <podiki>i mean is the c++ repo the one that builds those libraries that the python one needs <podiki>those lines need to be patched to reference the /gnu/store/... path of the libraries built in guix <podiki>with my really quick look that's what i would do: 2 packages, one for the c libraries, one for python; python one patch the paths where it tries to open "cdll/..." to the store paths of the guix package built ones <podiki>bit of a pain for how they did different architectures. i would just do the one you need before trying to tackle it, but wouldn't be too bad <Kabouik>Thanks for the suggestion. I'm afraid it involves several steps I don't know how to perform yet though (in particular changing the path to the libraries, but not only). <podiki>or i guess just remove all the "-arch.so" in their paths, that might be enough unless the libraries come built like that <podiki>there are plenty of examples in our code. i would help but alas must stop procrastinating :) <Kabouik>Since I'm a bit in a hurry for that, it'd be totally fine to first try with only the arch I need I guess. <erikeah>I need to output to my profile libgcc_s, however it seems that gcc-toolchain is not doing the job? Any idea? <Kabouik>That's a shame podiki, your procrastination moments always magically seem to align with the moments when I make progress in my Guix rocky road. :> <podiki>i also have some security updates for some packages, overdue patches to email out, emails to respond....on the fun guix side. alas there is actual work to be done too <podiki>erikeah: it is probably in the (hidden) gcc:lib output. e.g. guix shell -e '(list (@@ (gnu packages commencement) gcc) "lib")'. i'm not sure offhand how to install <podiki>we have a pending bug report to fix it so all the libraries go into the gcc-toolchain package for users as well, but it stalled. add it to my list! <Kabouik>Honestly I'd be happy to just use the PyPi package at least temporarily while I solve the things I need it for, and then only later try to work in a proper Guix implementation for a package, but if I pip install yoctopuce, then I get that libusb error I reported a couple days ago, probably because the PyPi package can't find the library in the Guix store. <erikeah>podiki: could you send me the bug report <erikeah>podiki: With enought context may could solve the issue by myself and send patch <podiki>erikeah: there are patches there, just wasn't decided what to do exactly <podiki>Kabouik: did you try with LD_LIBRARY_PATH=$(guix build libusb)/lib or something like that? <Kabouik>Progress podiki: with that, my script returns "init error: the user has insufficient permissions to access USB devices (ypkt_lin:409)", which I believe may be a udev rule that needs to be set in my config.scm for use of USB devices as simple user <podiki>Kabouik: yup that sounds like it. i saw they had some info about udev rules. they are easy enough to add in guix at least. good luck! <erikeah>podiki: I do not understand why the "lib" output wasn't a good idea <Kabouik>Yes, I'll look into that later today. I thought I could just bypass that with sudo, but then if I do, it's the pip-installed yoctopuce that is no longer being found. <Kabouik>So I'll try udev rules in my config.scm tonight, see if it works. The LD_LIBRARY_PATH would only be a temporary workaround, but it'd be golden if it allowed me to work on the actual problem from my main Guix machine instead of the trashy Windows machines from the lab. <podiki>probably pip for root then. should be able to get around that maybe with sudo -E or sharing the right environment. though careful, might end up with root chowning some files or some such <podiki>yup, that's my philosophy exactly, whatever dirty hack i need to make things work and then go from there <podiki>erikeah: I don't know the details, but changes were made in what were the more "user-facing" gcc related packages, and along the way the lib output wasn't included <Kabouik>Unfortunately that's also often how things stall by lack of time then, just like that bluetuith scm you proved I could build from sources, but which is still made from binary-build-system on my end… <podiki>erikeah: some confusion over what gcc packages people would want or need I think <podiki>(and yes it is true, often how things can stall out, as i can attest to my local mess of packages too) <Mist37>Greetings folks! Have been meaning to try Guix out (nix user), but first I need some help figuring a couple things out. Is there a flakes.nix equivalent in guix? <rekado>I keep forgetting what flakes are. Could you tell us what your use case is? It's likely not a direct mapping to a single feature in Guix. <old>Looks simliar to time-machine? <erikeah>I have installed (list (@@ (gnu packages gcc) "lib")) but binaries are not linking to libgcc_s, any idea? <rekado>erikeah: you may actually want to use gcc-toolchain instead <erikeah>but indeed I have it installed already <rekado>it doesn't bundle it, but it lets you link with the gcc lib. <erikeah>The thing is that I need to use this lib on binaries non compiled by guix <rekado>that's what gcc-toolchain is for <cage>Hi! there is a package with a bug that has been fixed upstream, i do not want to update the guix package but i want the bug fixed, there is a way to apply a patch to the code in the package definition form? <sneek>Welcome back cage, you have 1 message! <sneek>cage, lechner says: / i'm not here often, but you can find me as @lechner on codeberg <zyd>Damn, nothing cooler than building a package from a specific upstream commit and being to easily reproduce a build error and share it. Feels like some crazy hacker moves. (sharing my joy of `guix build --with-commit=`) <zyd>never been happier dealing with errors! lmao <civodul>the front page has an article on Nix & Guix <old>civodul: I posted it here yesterday <civodul>ACTION wishes their employer had maintained their LWN subscription <old>If you something to comment (don't know if you can without sub, tell me and I can quote you) <old>If you have something* <civodul>i think i need to go cooking first but i’ll get back to it later <zyd>Are patches made via `git format-patch` compatible with `guix build --with-patch`? <podiki>should be. even a git diff should work <reedm>I have a file system mounted to /data, that is configured in my OS configuration. When I run "sudo herd status", one of the services is file-system-/data. To write a "simple-service" that changes the user/group permissions of this folder, I think I need to use the service-type of the file-system-/data service. Is there an easy way to find the <reedm>service-type of the file-system-/data service? <efraim>/ define TRUE/FLASE if not defined <PotentialUser73>Hello, I was asking yesterday about some Python questions and have another one (I'll probably actually register a nick as well). I'm working on a Python package and I think I've got it mostly working, the one issue I'm having is the authors have enabled -Werror in pytest so some tests are failing with FutureWarnings. Is it acceptable to just <PotentialUser73>disable Werror in this case? If so, is there a good example of how to do that for pytest? When I grep the guix source it looks like all of the instances of doing that are for C or Java programs. <PotentialUser73>I just tried removing it from pyproject.toml with substitute* and that does not seem to have made a difference <zyd>podiki: do you know if its possible to build a package with a patch for that package itself. In my case I am building `tinmop` with a specific upstream commit as a patch. So I tried: `guix build tinmop --with-patch=tinmop=./0001-TUI-allowed-the-backspace-key-to-send-rubout-char-AS.patch` but it fails with an error I don't understand. <podiki>well the error is important, might be that the patch isn't applying. you can just use a transformation to build from the commit directly, --with-commit i think it is, or just --with-git-url if you want the latest commit <zyd>podiki: Well in my case I want the version that's in Guix currently, rather than upstream, but with a small addition that was included from that commit. I don't want to build from that commit. Hope that makes sense. <podiki>ok. well the error message is what you need to look at. does the patch apply? or is it a build failure? <zyd>the patch does not apply, no <podiki>right, so if you want it to work you need the patch to apply <podiki>which means you may need to make the changes manually, say in a git checkout at the version in guix, and generate a proper patch that will apply <podiki>guix can't do anything fancy with the patch, it just applies it <zyd>Hm, I'm a bit confused (not super well-versed in git). Why would a patch not "apply"? <podiki>because it is trying to make changes to a file but it is not lining up <attila_lendvai>zyd, the source code has been changed since you recorded the patch <sneek>Welcome back attila_lendvai, you have 1 message! <sneek>attila_lendvai, Kabouik says: Thank you anyway! I tried other things but run into other issues. First, I tried patching pyproject.toml to remove the mention of Python 3.13, in case python-hatchling would not recognize it yet since it seems very recent. Then, I had a phase check error, so I disabled tests in the package definition, then I noticed the PyPi package comes with support for all architectures and maybe some inputs would be missing in <podiki>in other words, it is looking for some line to add or change, and it is not where it is supposed to be or has changed <podiki>a patch is just applying some changes to the source (text), but if the starting state is not similar enough then it will fail, unable to make the changes where it needs to <zyd>Oh, I see what's happening I think. I built that patch from upstream. And I'm trying to apply it to the Guix version of the source tree. But I assumed because the commit is so small it would simply add it in, clearly not how it works at all. <cage>zyd: i have uploaded a patch in your issue report thread, just with the minimum changes to fix the bug <zyd>attila_lendvai, podik: thank you for the explanations <cage>but i have to say that i did not tested it 😅 <zyd>i will soon enough ;) <podiki>anyone familiar with libnghttp2? trying to update something and it wants a version 1.6.0 but...that doesn't seem to exist? <podiki>or rather 1.59.0 is latest version, and i would guess 59 > 6.... <nutcase>Hello, I'm trying to set up a guix shell --container and the binary I'd like to run complains about not finding libgcc_s.so.1. Which guix package is the package my shell is missing? <dariqq>is there a way to run a shepherd service that executes something like foo $(bar). Problem is that the result of bar might not be the same everytime so i cant evaluate it before. <civodul>old: the article is nice; doesn’t go very far and the very last sentence is a bit disappointing, but still rather nice <civodul>i see you, jpoiret, and zimoun already commented, nothing to add :-) <podiki>nutcase: try adding -e '(list (@@ (gnu packages commencement) gcc) "lib")' <podiki>civodul: i don't remember the details of the conversation, but i would opt for the simplest just add gcc:lib to gcc-toolchain <podiki>2 people asking about things from gcc:lib that we don't have in gcc-toolchain <civodul>i thought this was related to the LWN article <civodul>podiki: i already reviewed this patch actually; would you feel like posting a followup? <podiki>yeah it is on my list :) I know simon just hasn't had a chance, last i asked <podiki>ACTION pushes a bunch of security updates <podiki>so isc-dhcp is EOL since end of 2022.... <podiki>it has 62 dependents (with, somehow, things like gtk themes) <civodul>we merged a patch recently so dhcp-client-service-type supports another implementation <podiki>is there a drop-in replacement? dhcp kea? <podiki>somehow a bunch of gnome stuff depends on things like dnsmasq <civodul>hmm actually not it’s not merged it seems <podiki>through gnome shell, settings-daemon, networkmanager, then isc-dhcp <podiki>which is unfortunate, but we should drop isc-dhcp at some point, no? <podiki>(i should send a patch for that gcc-toolchain issue just so i can stop giving the answer on how to work around it here :)) <dariqq>i guess i could just generate a bash script and execute that instead <podiki>attila_lendvai: i don't know on that one (you can retitle it if you like). alternatively, a cc-wrapper a la python-wrapper for a "user" package? note that in --emulte-fhs we do set a cc symlink for this reason <podiki>i can reply with that note about emulate-fhs, but retitling/closing i would leave to you :) <civodul>historically “we” (or at least i :-)) opposed the ‘cc’ symlink, on the grounds that upstream (GCC in this case) does not provide that file <attila_lendvai>ACTION would need to dig into the debbugs manual for the retitling, therefore postpones it <civodul>(debbugs.el makes it easy to retitle bugs) <podiki>...tell me more :) (not seeing a command come up but i'm very basic at debbugs) <civodul>podiki: press C on a bug, and then retitle <fnat>(herd-cow issue solved: I restarted the install process, re-mounted the volumes, and gave the command again - this time it worked fine.) <nutcase>podiki: thanks. I read the hint in the description of libgccjit, which says "The just-in-time (jit) part of the name is now something of a misnomer.". Adding libgccjit to the shell solved my issue. <Kabouik>Trying to set some udev rules in my config.scm, it seems I'm doing it wrong since I don't see the corresponding files popping up in /etc/udev/rules.d/. Isn't that the correct Guix way to do it? https://0x0.st/HRWy.txt <mange>That defines the rules, but you then need to include it in your services with udev-rules-service. You need to add (udev-rules-service 'shadowclient %shadowclient-udev-rule) and (udev-rules-service 'yoctopuce %yoctopuce-udev-rule) to your list of services. <Kabouik>Do you happen to know if I need double = or simple = in those rules? The one I picked from Yoctopuce website has double for SUBSYTEM and ATTR, but simple for MODE. <mange>I don't know, but I would expect == for things which need to match, and = for things which the rule sets. So = for MODE makes sense because it's setting the mode of the file representing the device, and == makes sense because that's matching the right device. <mange>s/== makes sense/== makes sense for the others/ <Kabouik>Rebooting now, to see if those rules were all I needed to make my usb device work. <Kabouik>Yup. Nice. Thanks podiki too, the LD_LIBRARY_PATH can only be a temporary workaround, but given how I've been struggling to package Yoctopuce for Guix, this will be a lifesaver for now with the PyPi package. <biodigital>Hi, I'd like some advice. my goal is to implement raid5 to 4 hds. Which controller raid with good cost benefit could I buy new old u?