IRC channel logs
2023-09-03.log
back to list of logs
<RavenJoad>For apcupsd, I want to have the ability to run the test program. This requires the apcupsd daemon/service to be stopped. Would it make more sense to add testing as a shepherd action? Or just wrap the test program and present it in the profile? <mirai_>is it for testing whether the service works or not? <RavenJoad>mirai_: It is for testing if the config that was generated will do what the user expects. It attempts to contact the UPS over the connection method in the config file. It also allows you to simulate certain events, like line power being removed. <RavenJoad>Is there a good way to "wrap" multiple binaries for a shepherd service? I need several programs to use the same config file command-line parameter. <mirai>can you write a system test for it? <RavenJoad>I don't think I can right now. Both the daemon and the apctest programs need to have the UPS attached. <mirai>I guess you could add a custom shepherd action <RavenJoad>I could just not, and give users a wrapped apctest binary too. They would have to make sure to stop apcupsd first though (which apctest does warn about). <wone>GUIIIIIIIIIIIIIIIIIIIIIIIIIX <PotentialUser-82>Hello everyone, I want to know that someone has used docker on guix system, how can I modify config.scm to get and configure docker, thanks for the help. <apteryx>ugh; I wrote a new module (gnu packages ergodox), and when I try to use avr-toolchain from (gnu packages avr) in it, it seems to fail due to some top-level module cycles I don't understand: error: cross-gcc: unbound variable <apteryx>PotentialUser-82: it's very easy, just follow the doc <apteryx>info '(guix) Miscellaneous Services', then search for 'docker-service-type' <PotentialUser-82>I followed the documentation and added (service docker-service-type) under the services entry, but I got an unbound variable error, did I miss something? <lilyp>the use-service-modules part probably <apteryx>yep, you need docker to the use-service-modules part <wone>do appimages run on guix? <efraim>they might run inside a guix shell with the --emulate-fhs flag and with the needed dependencies, but it's less convenient than flatpak <fishinthecalcula>Hello guixers, I'm trying to have my Pinebook pro boot the guix image available on the website. Am I just supposed to flash it to an SD card with dd? I tried several times but never managed to have a successful boot <sneek>Welcome back fishinthecalcula, you have 1 message! <sneek>fishinthecalcula, daviid says: if you need help wrt g-golf, please join #guile, and ask for help there ... also, note that guix is currently unable to run g-golf - https://lists.gnu.org/archive/html/guile-user/2023-05/msg00026.html - so till the guix team fixes the problem, once for all hopefully, i would recommend you get yourself a vm with another distro, fwiw, debian testing, fedora, freebsd and even homebrew all reported to <efraim>fishinthecalcula: I've never tried teh pinebookpro image from teh website but I think it's supposed to work like that. Have you flashed towboot? <efraim>I'm currently using towboot and a guix EFI image on the emmc <fishinthecalcula>efraim: I have tow boot , what do you mean by "a Guix EFI" on the emmc? How did you build that image? <fishinthecalcula>Anyway I tried both the official image and I believe I found your repo on SR.ht online. I tried to slightly change your image and then do the partition enlargement and btrfs conversion but still it didn't boot <lrustand_>Hello, I am very new to guix, but I'm trying to start a guix shell with node.js. https://packages.guix.gnu.org/packages/node/ says the version is 18.17.1, but in my shell I get version 14.something. If I try to specify node@18.17.1 like the documentation says I can I get a "package not found for version" <attila_lendvai>lrustand_, guix shell node gives me v18.16.0. maybe you need to guix pull and reconfigure? <lrustand_>I did do guix pull. Also I installed guix like 5 minutes ago, so it should be up to date, no? What do you mean reconfigure? <nckx>How did you install Guix? <nckx>Then run ‘guix pull’ to update to the latest Guix. <nckx>The installation script doesn't install a snapshot. <nckx>And what does ’type guix’ say? <nckx>Right. That's the old guix. <nckx>Did you run ‘hash guix’? <lrustand_>I did now, but type still says the same thing <nckx>OK… It should say ‘/home/nckx/.config/guix/current/bin/guix’. Is that in $PATH? <nckx>I'm not sure how that's added on foreign distroes TBH. <lrustand_>Okay, I opened a new shell, and now it points to the right guix <nckx>Answering myself: /etc/profile.d/zzz-guix.sh . <efraim>fishinthecalcula: in towboot you can hit escape (I think) and it'll let you choose what to boot from, so you can boot from an SD card. <fishinthecalcula>efraim: I tried that but guix somehow is the only image not booting. Not really sure what am I doing wrong. I built the image on the pinebook with guix on manjaro, flashed it with the usual dd if=$(guix system image ...) of=/dev/mmcblk oflag=sync bs=4M <fishinthecalcula>What happens when I choose the sdcard from towboot is a black screen for a second and then I'm brought back to the boot menu <efraim>perhaps there's an issue with the image? or it didn't burn correctly? It's happened before <fishinthecalcula>I'm beginning to think so, is there well known image that is known to work? I'm guessing definitely the image that was first contributed as Guix supported pinebook image, but since it's only available as "latest" I'm not sure where to find it. Do you know if it's possible to obtain this information from guix data service or maybe ci.guix.gnu.org? <jpoiret>fishinthecalcula: how are you building the image? <fishinthecalcula>jpoiret: I tried both the image from guix website and the image from (gnu system images pinebook-pro). I'm using guix system image pinebook-pro.scm --system=aarch64-linux <fishinthecalcula>I also tried guix system image --image-type=efi-raw ./config.scm --system=aarch64-linux , where config evaluates to an operating-system record <leervnaec>If I installed GNOME or KDE from guix, would it be able to 'see' per se my native debian installed packages? Like from the start menu or applications/activities dashboard be able to launch them? <leervnaec>Can I install guix from a regular live GNU/Linux distro ISO? Like a debian live ISO and then install it manually from there? <leervnaec>Thanks janneke. I'll continue my question later, I have to leave now. Sorry about that. <retropikzel>I switched to labwc on guix and its really nice, however I dont know how to change screen resolution. I tried wdisplays but trying to run it it complains about missing libGLESv2.so.2. Anyone got a tip how to change resolution on guix on wayland? <nckx>retropikzel: Does ‘GSK_RENDERER=cairo wdisplays’ work? <nckx>Seems like it might happen only on ‘old’ hardware. <retropikzel>nckx, it does not help. Do you happen to no other solutions than getting wdisplay to work?? <nckx>No. I'd never heard of labwc until just now. <nckx>retropikzel: I do see that it's wlroots-based and that Guix has wlr-randr… <attila_lendvai>make -j fails in guix for me with zero useful output besides the make error message <attila_lendvai>i restarted, make clean, bootstrap, configure, without -j, and now it fails out at the .de cookbook <nckx>Is your build environment up-to-date? <nckx>That should no longer happen. <attila_lendvai>i'm using direnv, deleted the profile. it's --development guix guile-sodium guile-eris guile-fibers <attila_lendvai>nckx, what changed? is there a commit i could look at to investigate? <nckx>attila_lendvai: po4a; 352c49e1a5c48eb76389ee384eb95fc2e4a6ab32 <nckx>If it updates the guix shell/environment, fine. <attila_lendvai>i think i need to guix pull, and then retry. maybe guix shell --development guix uses the wrong/old guix package definition <attila_lendvai>which reminds me: isn't there a bootstrapping issue with the guix binary itself? and that chain of bootstrap path is not reified (expressed formally) in the sources to be able to detect such situations <nckx>…possibles? I'm not aware of a formal (reported) issue, but perhaps that's part of your point. <attila_lendvai>ACTION didn't mean a bugtracker issue, but the fact that you cannot build the versions of guix by pulling through random consecutive commits. <attila_lendvai>hrm, still no luck after a guix pull and home reconfigure. make fails with "guix-cookbook.de.texi:611: @menu reference to nonexistent node `A ``Hello World'' package'" <janneke>attila_lendvai: have you cleaned your worktree? <attila_lendvai>janneke, i did a make clean, ./bootstrap, ./configure --localstatedir=/var --sysconfdir=/etc <janneke>attila_lendvai: sadly, 'make clean' may not be good enough <attila_lendvai>unfortunately the po4a patch doesn't alter the version number, so i don't know how i could check whether i have the patched version <attila_lendvai>janneke, /gnu/store/492487vr2sy5jw3z9z6hqr2wzwp3sw45-profile/bin/po4a -> /gnu/store/rlbyjwc1kmhwr4y3a0m31wd37l0ll024-po4a-0.69/bin/po4a <janneke>attila_lendvai: if you know what you're doing, i would advise a git clean -fdx <efraim>`rm -r -- po doc; git checkout -- po doc' <janneke>attila_lendvai: that's terrible; yesterday cbaines had the same or a very similare problem and i believe git clean fixed it <janneke>efraim: how is that different from git clean -fdx -- doc po? <attila_lendvai>yep, the git clean -fdx thing fixed it. anyone reading it from the future: make a backup of your checkout if you have any files in there like a .envrc, etc... <efraim>I've never tried adding paths to `git clean -dfx' <janneke>efraim: i've learnt to be careful advising git clean -fdx without directory specifiers <attila_lendvai>this is why i like build setups where any and all derived files go into one build/ directory that can be just deleted when in doubt <attila_lendvai>FTR, re git clean: "If any paths are specified, -d is irrelevant" <apteryx>attila_lendvai: if you have 0.69, you probably have the patch <apteryx>these tools may be captured early during the bootstrap <apteryx>so you may have to re-run ./bootstrap <attila_lendvai>i think the problem was some stale files among the .gitignored one in my worktree that make clean didn't delete, nor did make distclean <apteryx>does someone have tips to debug top level bindings cycle problems? <apteryx>I keep hitting ice-9/eval.scm:293:34: error: cross-gcc: unbound variable when attempting to use avr-toolchain in a new module <apteryx>since it's a *new* module, I'm puzzled as to why this can happen <janneke>attila_lendvai: afaik, guix (like all gnu packages) support out-of-tree builds <attila_lendvai>another issue: make -j fails, while a non-parallel make seems to make progress. but i need to go AFK <apteryx>when all else fails, start from scratch; if 'make as-derivation' is not broken, something is in your tree <ekaitz>efraim: i have a cross-gcc for riscv and I get crt1.o not found <ekaitz>how am I supposed to make a cross-compiler for riscv? <efraim>I normally rely on guix for setting up the environment and just use --target=riscv64-linux-gnu <ekaitz>i'm doing something like (cross-gcc triplet #:libc crosslibc #:xbinutils crossbinutils) <ekaitz>but... i need to build a random C file <ekaitz>efraim: copying the crt1.o from my GUIX_ENVIRONMENT to the local folder happened to work <efraim>but then you need to keep track of cross_include_paths or something also <jpoiret>ekaitz: does your cross libc have the crt1.o? <jpoiret>that's weird then, I wonder why it's not getting picked up <jpoiret>ah, you probably don't have the glibc itself in your profile, only the gcc? <jpoiret>ekaitz: have you tried using efraim's suggestion of uing `--target=...` with a guix shell invocation for a package definition of what you're trying to package <jpoiret>like `guix shell --target=.... -D -f my-package.scm` <ekaitz>no, i need a gcc toolchain for something else <ekaitz>i'm not really packaging anything <ekaitz>also jpoiret if I use -L in gcc it doesn't find the crt1.o <ekaitz>so it looks like those are found using other mechanism <ekaitz>and that's why the shell doesn't let gcc find them <nikolar>how would you go about making a cross tc <janneke>nikolar: it's not a gnu package, nor does it use autotools, so ymmv. if you're lucky it it implements gnu-style --host,--build, and --target arguments <nikolar>so i can inherit from it and try changing those <janneke>nikolar: sure...but if it implements the gnu build system, doing something like: "guix build --target=i686-linux-gnu tcc" should already do it <jpoiret>ekaitz: i seem to remember there being a nice shortcut to get a cross toolchain but I can't remember which <jpoiret>I think i told janneke when i found it <janneke>sadly, home-grown configure/build systems hardly ever work that way <janneke>ACTION heard that sometimes janneke tends to forgets things... <nikolar>would that guix build cross compile tcc or make a tcc cross compiler <janneke>nikolar: hmm, that's a good question :) <nikolar>the help says cross-build for TRIPLET--e.g., "aarch64-linux-gnu" <nikolar>which doesn't help much, to me at least <nikolar>i tried it, and yes, it does produce a cross compiler <nikolar>how can i intercept the current target that's supplied to the package so i can rewrite it to something the package would understand <nikolar>when you enable cross compiling, it builds all of the supported architecthres <ekaitz>nikolar: so cross-build instead of separate pieces like the binutils, libc and then the gcc <ekaitz>tcc is supposed to work as you propose there <ekaitz>jpoiret and janneke: i'm pretty sure I knew how to make it work too, but I forgot too <ekaitz>jpoiret: but i think it was (cross-gcc ...) as I was doing here <apteryx>I thought I sent an email to bug-guix and haven't received confirmation in more than 1 hour <apteryx>actually, 3 hours, 31 minutes, 8 seconds ago <Altadil>It was down for me until not long ago <nikolar>ekaitz: what do you mean cross-build instead of separate pieces <ekaitz>nikolar: nah forget it I didn't understand you correctly <nikolar>would a cross-tcc package be accepeted <nikolar>as a version with cross compilation enabled <ekaitz>nikolar: surely, I have one for my research but it doesn't work properly <ekaitz>do you want to see as a reference? <nikolar>i was just going to inherit tcc and add --enable-cross to configure <ekaitz>in my package there are some other things mixed, don't let that confuse you <ekaitz>but it's not as simple as just inheriting <nikolar>i'll need to research that a bit more <ekaitz>if you want, you can ping me and we'll discuss it further if you want when you work on it <ekaitz>keep me posted if you want, i'm often around here <nikolar>there are two options though, treat it like cross-gcc where you can install cross tcc for a single arch <nikolar>or have one cross-tcc package with all of the supported ones enabled <nikolar>yeah it's basically for free unlike with gcc <Guest69>If I am on a GNU Guix system with TRAMP eshell and run a guix command I get this: https://paste.debian.net/1290844/ this is because I set "(add-to-list 'eshell-visual-commands "guix")" Is this fixable? <Guest69>If I login on the server with "ssh pi" it works normally, though it runs it directly in eshell instead of outsourcing it <apteryx>why can't we bind a cross-gcc package computed with the cross-gcc procedure from (gnu packages cross-gcc) ? It causes a top level cyclic dependency issue <apteryx>if you look through the code base it's typically used over and over directly in the inputs fields, which means its evaluation gets delayed <apteryx>if we could solve the circular top level dependency issue, we could bind a proper package for it and reuse this easily; it'd make it convenient to setup an environment with 'guix shell' from the command line, say <nikolar>i wonder if anyone tried packaging some vim plugins <ngz>nikolar: `guix search vim' says "yes". <civodul>apteryx: “solve the ciruclar dependency issue” sounds next to impossible in this case: package modules all refer to each other <civodul>however, we could add cross-compilation support to ‘guix shell’ <apteryx>civodul: is it impossible because guile is not lazy and binding something at the top level requires evaluating the expression? <apteryx>if that's the case, could we perhaps also accept promises as inputs and force (evaluate) them only when need (introducing delayed evaluation) <civodul>apteryx: the inputs fields are thunked (delayed, essentially) precisely for that reason <civodul>Guile module loading is very basic: it parses the file and evaluates each expression one by one <civodul>so everything goes well as long as you don’t refer to a variable that’s not defined yet <civodul>(the ‘define-module’ form roughly does (let ((m (make-module))) (module-use! m (resolve-module '(some dep))) …)) <apteryx>civodul: does that mean that the ordering of #:use-module is sensitive when dealing with cycles? <ngz>nikolar: You probably need #$(modify-phases #$phases ...) <civodul>apteryx: it could be; in (gnu packages …) module, the rule is to never have top-level references to packages from other modules <civodul>it’s annoying that we have to pay attention to that, but it’s a reasonable constraint in practice <civodul>except yeah, … terrible when you stumble upon one of these cycles! <apteryx>should a procedure that is bound at the top level, which returns a package object that only uses top level references inside inputs OK? <ngz>nikolar: typo, I should have written #~(modify-phases #$phases ...) <ngz>Then you probably want to paste the whole package, because something is fishy. <apteryx>civodul: I don't see what's not following the rule of not referencing top-level references in my ergodox module addition, unless nesting a package definition which references other packages in its inputs is somehow treated differently that simply defining the object at the top level directly. <apteryx>and as soon as I remove said module the problem resolves... <apteryx>I suppose (gnu packages avr) is to blame instead <apteryx>but the problem doesn't manifest in (gnu packages avr-xyz), which is odd (it uses avr-toolchain too!) <civodul>apteryx: the ergodox.scm module LGTM so you’re right, it must be (gnu packages avr) that’s at fault <apteryx>I'll be AFK for a bit, but I'll keep banging my head on again when I return ^^' <ngz>nikolar: I don't see what's wrong either, sorry. <nckx>nikolar: (#:phases phases) → (#:phases phases #~%standard-phases) <nckx>tcc doesn't have any #:phases, so you need to manually specify a default to fall back to. This is a gotcha. <nckx>the_tubular9: Not even proper 404s either, but 200 oopsies. 😒 Thanks for the report! Fixed. <nckx>If anyone feels like investigating this (I don't): there are 22GB(!!!) of caches at /var/cache/guix/web.old . <nckx>For comparison, a fresh installation uses 0.5GB. <civodul>nckx: lemme see; this is the hpcguix-web data, which is normally one checkout, packages.json.gz, and a bunch of symlinks <nckx>The rebuild is a lot slower than I expected. <civodul>apparently it’s the checkout that has grown this build <nikolar>nckx: i added the default but that's not helping either <nikolar>still getting source expression failed to match any pattern <civodul>indeed “du -hs ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq” says 6.7G here, whereas the equivalent Git-managed ‘.git’ is 517MiB <nckx>nikolar: You're using gexps without importing (guix gexp). <mirai>apteryx: have you looked at the bottom of cross-base.scm? <mirai>and the comment regarding %xgcc <mirai>the comments seem to suggest “don't do that” <nckx>(nikolar: note that the build still fails if you add it, but that's your problem 😉) <nikolar>yeah i can take it from there, thanks nckx :) <vagrantc>i was also worndering if it would make sense to use worktrees instead of full checkouts ? <vagrantc>that would save some space, and significant time on checkout <nckx>Does guile-git support those? A grep for ‘worktree’ turns up only 1 comment. <vagrantc>nckx: it doesn't support 'git gc' either, but we can have new things sometimes :) <nckx>Or does it just punt to (lib)git. <nckx>vagrantc: Don't let the suckless hear you. <janneke>wtf? when i move a dependency from inputs to propagated-inputs, that triggers o rebuild? <nckx>Anyway, bayfront is surprisingly slow/overloaded. I can't remember my laptop ever beating it by an order of magnitude before. <janneke>because it doesn't make *any* difference for the build <civodul>bayfront is building stuff locally; i’m not sure if this was intended, but we should probably avoid it as much as possible <nckx>If it's building actual packages on the reg, that is certainly not supposed to happen. <janneke>propagation only matters wrt to a resulting profile? <janneke>hmm, maybe the order of dependencies changed... <nckx>ACTION → 😴💤, or better said, a 2h drive to 😴💤 … … <civodul>in other news, i restarted overdrive1, which apparently went off while i was away <nikolar>how can i get target triple supplied by the --target= option <nikolar>what's the correct way to deal with this `which' imported from both (guix build utils) and (gnu packages base) <civodul>nikolar: it’s likely that you don’t need to import (guix build utils), if that’s a package module <civodul>if you do need it, you can write: #:use-module ((guix build utils) #:hide (which)) <nikolar>why does (%current-target-system) return #f even when i supply --target=riscv64-linux-gnu for example