IRC channel logs
2025-05-14.log
back to list of logs
<potatoespotatoes>Hi! I'm trying to build a zfs kernel module with a simple derivation: (package (inherit zfs) (arguments (cons* #:linux linux-libre-arm64-mnt-reform (package-arguments zfs)))) <potatoespotatoes>But I'm getting this weird error where the patches used to build linux-libre-arm64-mnt-reform are not getting found <potatoespotatoes>Hi! I'm trying to build a zfs kernel module with a simple derivation: (package (inherit zfs) (arguments (cons* #:linux linux-libre-arm64-mnt-reform (package-arguments zfs)))) <potatoespotatoes>But I'm getting this weird error where the patches used to build linux-libre-arm64-mnt-reform are not getting found <potatoespotatoes>nothing in the zfs derivation stands out as modifying the kernel and linux-libre-arm64-mnt-reform is just defined using make-linux-libre* and adding some build hooks, so I think the problem is that something is happening in linux-module-build-system which loads the base kernel and... somehow incorrectly applies the hooks? <potatoespotatoes>actually, it might be more accurate to say that the linux-libre-arm64-mnt-reform's inputs are getting overridden and this breaks the hooks <potatoespotatoes>I'm wondering if someone can point me in the direction of where this might be happening. I followed the trail to linux-module-build-system.scm, but nothing there looks unusual. <gabber>what's the exact error message? what are you building exactly? a system? <potatoespotatoes>I am just trying to build the modified zfs package, exactly the expression above: (package (inherit zfs) (arguments (cons* #:linux linux-libre-arm64-mnt-reform (package-arguments zfs)))) <potatoespotatoes>and it results in a searchpath error for `file: "patches/imx8mp-mnt-pocket-reform/2ghz/0001-imx8mp-2ghz-clk.patch"` <gabber>i am getting the same error but i have no clue what is going wrong (and/or where) <potatoespotatoes>but yeah, it's a super weird because that input seems to disappear, and i'm not sure how <potatoespotatoes>no... I thought I could modify-inputs on the zfs variation and reintroduce reform-debian-packages. <gabber>i guess with modify-native-inputs? <gabber>this is just me spit-balling but maybe it's also modify-inputs with native-inputs as an argument? <potatoespotatoes>I think I'm just going to redefine the kernel with debian-reform-packages in native-inputs alongside inputs >.> <gabber>i'd ask in one of the mailing lists - just for the case. maybe someone knows what's going wrong and can clarify <meaty>hi, dumb question: how do I load a common lisp package from a sbcl repl within guix shell? <efraim>do we have a graphical program that can browse ftp? <efraim>looks like lynx also works. the ftp site I was going to use closed some time in 1998 :/ <efraim>looks like I might need to work up a fancy wget command to download everything over http and then host it myself :/ <efraim>not as bad as I thought it would be <futurile>I'm looking at a Nix package that sets the paralellism (sp!) of tests like this: HARNESS_OPTIONS="j''${NIX_BUILD_CORES}" - do we have an equivalent? <fanquake>probably something like parallel-job-count <dariqq>Re my question from yesterday: the gnu updater could not find any releases because it was looking in the wrong directory. Setting 'ftp-directory argument to the correct one fixes it. <dariqq> Still think that getting the car of an empty version list should not cause an exception in the updater but i dont know how i would fix that <futurile>fanquake: ah looks like we have #:parallel-tests? which is boolean <efraim>something like: (string-append "-j" #$(if (parallel-tests?) (number->string (parallel-job-count)) "1")) <efraim>not sure if the #$ is needed there <Ironsmith>hey guix! i'm trying to package something that uses 2 repositories. there's one repository that has scripts and patches, and it git clones another repo. i originally wanted to include the second repo as an (origin) inside the first (origin (patch-inputs)) but i guess that's not really possible right? keep running into issues and it looks like it <Ironsmith>can't accept (origin)s themselves. only (patches) accepts (origin)s but it's only for patches, in my case i'm trying to import code and then copy it over inside (snippet). alternatively, i can make an intermediate private (package) that has the second repo inside (inputs), i got that working. just wanted to check that i'm in the right path <aldum>I don't know if it's supported on the guix side, but have you considered using a submodule? <identity>aldum: the git-fetch method indeed supports sub-modules (add "(recursive #t)" to the git-reference), but i think whatever Ironsmith is trying to package does not use them, quote: "it git clones another repo" <identity>i started home-dicod-service with the default config, herd reports it running and listening, but neither Emacs' dictionary.el nor dico CLI seem to be able to connect to it, any tips? <Ironsmith>that's right the source isn't using submodule <hako>you can create a package with a simple build system (trivial-build-system or copy-build-system) to perform the patching steps, and use this package as source. <hako>doing it all in an origin definition is possible but can be very hacky. <Ironsmith>gotchya, nice i didn't know about copy-build-system i'll take a look. your answer confirms what i thought might be the best approach, thanks hako <apteryx>ACTION found the definitive fix for cdrom/dvdrom not automounting, and it was a one line change. <sneek>apteryx, you have 1 message! <dariqq>apteryx: could you also revert the commit that ungrafts udev on kernel-team? <apteryx>dariqq: ah, it's already been integrated in eudev proper there? <dariqq>apteryx: yes, 7cdd063ec6d07e2c06c8132b23ce8d67b2dd880f <apteryx>dariqq: done, and I've cherry picked the 3 last commits from master (hm, sgx was not needed but it won't hurt), so that eudev is ungrafted on kernel-team as it is on master. <zilti>I have a simple-service of home-shepherd-service-type that runs "emacs --fg-daemon". This seems to do what it is supposed to, as that process shows up in htop, but when I try to run emacsclient, it complains about not being able to find the emacs socket. Has anyone else run into this? How do I fix that? <csantosb>Hi Guix ! Do we have a the correct way of `guix shell -C coreutils which -- echo $GUIX_ENVIRONMENT` ? <csantosb>Meaning displaying env variables inside the shell, not outside 🧐 <ieure>csantosb, guix shell -C coreutils bash -- bash -c 'echo $GUIX_ENVIRONMENT' <ieure>Actually, this is better: guix shell -C coreutils -- /bin/sh -c 'echo $GUIX_ENVIRONMENT' <dariqq>zilti: What does herd status say? What is your emacs server-socket-dir? <csantosb>ieure: I see ... is strange that this breaks `MODULE='-m ~/.guix-profile/lib/yosys/ghdl.so'; guix shell -CP --preserve='^MODULE$' ghdl-yosys-plugin -- yosys $MODULE` <csantosb>Whereas launching the shell, first, and then `yosys $MODULE` performs as expected <ieure>csantosb, Guess: `$MODULE' gets expanded by your shell before `guix' is exec'd, and ~ expands to a different path inside the container than outside. <csantosb>I need to take out the "-m", `MODULE='~/.guix-profile/lib/yosys/ghdl.so'; guix shell -CP --preserve='^MODULE$' ghdl-yosys-plugin coreutils -- yosys -m "$MODULE"`. Anyway. <ieure>I don't think you need to do the --preserve dance, though, since $MODULE will still get expanded by your parent shell. <zilti>dariqq: herd status says that the emacs service is running. server-socket-dir is - in a manually started normal Emacs session - /run/user/1000/emacs <dariqq>zilti: do you have the socket at /run/user/1000/emacs/server ? Is XDG_RUNTIME_DIR set when you launch emacsclient? <zilti>dariqq: hmm, nope, there's nothing in there. As to whether XDG_RUNTIME_DIR is set at the point where the shepherd service runs I don't know, but it is set now <dariqq>zilti: is the socket in /tmp/emacs1000 instead? do you use logind? <zilti>dariqq: there's nothing Emacs related in /tmp. I do use logind I guess? iirc it comes with %desktop-services and I did not remove it from that list. I did replace gs <zilti>gdm in there with sddm though <dariqq>zilti: hmm I am very confused where the socket is then. Is emacs complaining about something in the shpepherd log file? What is "herd eval root '(getenv "XDG_RUNTIME_DIR")'" . What emacs variant do you use. Do you use a normal make-forkexec-constructor? <zilti>dariqq: that eval gives "/run/user/1000". I am using emacs-pgtk, but updated to 30.1, and indeed a make-forkexec-constructor. <potatoespotatoes>can anyone tell me approximately how to set up a mediatek wifi adapter connected to usb? <zilti>I tried to "herd restart emacs-daemon". <zilti>It first said something about timeout of 5 seconds having run out and sending a sigkill to -1718 (there can be negative proc nums?) <potatoespotatoes>I think the steps are: use a nongnu linux, add mediatek-firmware into the os-firmware field, add "mt76" into the initrd-modules, add services of usb-modeswitch and kernel-module-loader-service with '("mt76"). Is this last services redundant? <zilti>But it followed it with the message that the service was started. Still no socket to be found though. So I guess it is the timeout. <dariqq>zilti: does it work from without shepherd, i.e. run emacs --fg-daemon manually? do you have multiple shepherds running? I am slowly running out of ideas <zilti>dariqq: yes, running it manually works. No multiple shepherds. Assuming that using simple-service with home-shepherd-service-type doesn't spawn additional ones. <dariqq>zilti: if you relogged today there is this bug #74912 <zilti>dariqq: No, did not do that either. Freshly booted. <dariqq>zilti: I am sorry, cant help you further, i have no idea where your socket is. Maybe try a systemd-constructor service instead to place the socket at "/run/user/1000/emacs/server" where emacsclient expects it? <zilti>dariqq: I will look into that, but since manually running it places the socket at the correct spot, I doubt that that's the issue... Thanks a lot nonetheless! <dariqq>or maybe something in your emacs config does not work in the shepherd environment <zilti>dariqq: Where does shepherd store its logs? <zilti>dariqq: aaahh, it uses a different Emacs! <zilti>No idea how THAT happened, but that explains it <identity>potatoespotatoes: for help on non-free firmware, you should ask in #nonguix <omentic>hi yall -- i'm trying to build guix 1.4.0 and am getting failures beyond my c++ debugging comfortability <omentic>got a failure that the backtrace told me how to fix (added #include <cstdint>). but i've gotten this strange "no match for call to <thing>" error now, and don't think i know enough c++ to figure it out. could somebody glance at my backtrace? https://paste.debian.net/1374697/ <omentic>there's stuff about PKGBUILDs in there but right now i'm just trying to make it build in the normal ./configure && make fashion <dariqq>omentic: encountered this recently as well and this fixed it for me #78419 <potatoespotatoes>okay, I have another weird thing that I'm uncertain about but it's been bugging me a lot: I've been trying to build a guix image for some new hardware, a rk3588 arm64 chip, but it seems like the kernel arguments don't get applied on boot (among other things, like /some/ packages not being available). For instance: the screen needs fbcon=rotate:3, but this never gets applied. <potatoespotatoes>I'm using embedded-os (and previously, installation-os) to make these images -- is there something going on with this operating-system or some of the installation services that blocks the kernel arguments from being applied?