IRC channel logs
2024-11-05.log
back to list of logs
<vhns>("Unbound variable: gexp"), that is <PuercoPop>When the check phase fails to run due to /bin/sh not pointing to a valid shell, how should one proceed? Is there a bash/shell package one needs to add as input?. <PuercoPop>How important is to have the tests passing for the software we are packaging? <jaft_r>PuercoPop: does it say which file this is occurring on? I'm not an approver, any, but my understanding is they should work so long as it's feasible to get them to. I forget which phase patches (maybe it's "patch"?) common executables (including "sh") with the location of the Guix ones but sometimes it misses some; it sounds like a file largely used for testings wasn't patched so you may have to do so manually. <jaft_r>PuercoPop: yeah; I can't guarantee how much further it'll get you but throw "bash" in as a "native-input" and add a phase before "check" that subs the "/bin/sh" of "test-driver" with the path of the executable in the "bash" package. Can't guarantee it won't stumble into another issue (including other executables in the script that might need subbing, as well) but it'll, at least, allow the tests to run the script. <PuercoPop>jaft_r: By subs you mean thing like substitute-string? Would simply disabling checks be ok if the goal is to upstream to guix? most distros don't run the test suite fwiu <jaft_r>PuercoPop: specifically "substitute*" but yeah. I'm not a maintainer so I could very well be wrong but, on the first patch I ever submitted, I was adviced to get tests working; it was only in cases where it wasn't possible (e.g. tests which use the internet which isn't available during a package build) was disabling tests generally allowed. <PuercoPop>Do I need something more than loading the module in the geiser repl to get jump to definition (M-.) working? <PuercoPop>Or is there a way to print to stdout while building a package? <PuercoPop>I'm trying to check if (find-files "." "^t\\.") is matching the files I expect. ie files starting with 't.' <jaft_r>PuercoPop: mmm; maybe you don't need to make sure it's an input. Note to self to update some of my packages before I submit them upstream… <jaft_r>Regarding to printing to stdout, just use "display"; that should work, I think. <PuercoPop>Thanks for the pointer though. I learned a little more about packaging things <jaft_r>PuercoPop: you're close but you've given "search-input-file" "/bin/sh" which is an absolute path. Change "/bin/sh" to "bin/sh" (no "/", at the beginning). <jaft_r>Ahh or maybe that doesn't matter. I just saw some examples of packages I wrote with the slash. Nvm. <podiki>sneek: later tell jpoiret did see your earlier messages now about mesa-updates and sway. will do the merge tomorrow (well, ~12 hours) assuming still looks good and then we can put libva, sway, more mesa updates on the branch for the next go round <jaft_r>PuercoPop: something else that might be helpful, wrt packaging, is – if you try to install the package via "guix package" – you can use "--keep-failed" to keep the files that occur (before the failure) under the /tmp directory <jaft_r>Looks like the error's stemming from the files listed ("t.gal2", etc.) but they don't exist in the initial packages files. I'm guessing they get generated at some point during the "check" phase (given they would've gotten targeted with the phase you added before "check", otherwise). <Ironsmith>hello! how can i use the guix repl to list out all available drives similar to lsblk or blkid (preferrably to see UUIDs)? trying to debug a new system setup and adding `gnu.repl` to the linux entry in grub <jaft_r>PuercoPop: yup; that's it. Don't bother targeting all files that start with a "t" and a period: they get generated by the Makefile. Target that file and it'll pass all tests and install. <jaft_r>I just swapped your (find-files "." "^t\\.") with "Makefile" <PuercoPop>Which looks like the Makefile writing out #!/bin/sh to generated test files as you mentioned <PuercoPop>It works, I don't even have to add bash-minimal to the inputs. Thanks! <taeaad>How do I delete /gnu, it says "read-only file system". <taeaad>I tried to change permissions on /gnu but doesn't seem to work. <taeaad>Installed Guix via the install script. <taeaad>The installation is too large for my server which is why I am deleting it. <Ironsmith>humm on debian/ubuntu i remember sometimes when i get stuck like this where sudo doesn't work, i use plain `su` to switch to the root user then `rm -rf ...` <Ironsmith>otherwise `sudo chown -R root:root /gnu` then try deleting? <apteryx>efraim: in the meantime, have you tried 'mumi am' ? works great for me, as long as MUMI is running. <avph>Hi! I was going through the guix source code and found a lot of instances of what my editor displayed as ^L . I could not find what it meant. <Guest60>Sorry if the question is dumb but how do I run ssh-keygen? <cbaines>(and yesterday I managed to stop the bots crawling it to death) <futurile>Q: what's the "ordering" of options in commands, it doesn't appear to be alphabetical, is it human-thought-this-made-sense ordering? <futurile>I'm not seeing it - maybe I need more coffee <gabber>are there unit tests for our `guix lint` utility where i can test my changes against? and if so, how can i invoke them? <mange>Looks like test/lint.scm and tests/guix-lint.sh might be relevant? Maybe 'make check TESTS="tests/lint.scm tests/guix-lint.sh"'? <futurile>sneek: later tell noe #73842 is very cool! <decfed>futurile: if you have time could you test the patch specifically with a package where the entry point is a shell script? I have my suspicions if that works but no time to investigate right now. btw: I co-authored the patch with noe. <jakef>are others still getting the warning about postgresql-11 being deprecated with every guix pull? <stochastic>> are others still getting the warning about postgresql-11 being deprecated with every guix pull? <apteryx>jakef: yes; looks like someone introduced deprecation but forgot to update packages using the deprecated package :-) <pjals>Hello, is there a way to make the Guix backtraces any better without touching the source? `In guix/store.scm: 2095:12 19 (_ #<store-connection 256.100 7f47c36fb7d0>)` is NOT useful in ANY way. <ieure>pjals, Short answer is no. This is an issue with Guile, the language Guix is built in, not a Guix issue specifically. <hako>ieure: Have you seen the review in #74070? Why removing the " %u" in desktop file btw? <futurile>hako: did you find a commit where guix package stopped being reproducible? seems like the test suite should have caught that <hako>futurile: I didn't go that far. I can take a look in that direction later, time for sleep now ( <pjals>What does the phase `seperate-from-pid1' do and why is it in my package? <pjals>It's throwing a keyword-argument-error with the keyword tsche-dev (<package-name>-<version>). <pjals>The worst thing is that seperate-from-pid1 appears nowhere in the Guix codebase nor in mine.. <yelninei>but not sure why it is causing a probelm for you <pjals>I'm messing around with custom build systems :P <ieure>I think that patch to disable parallel Guix builds either broke master or made the build unreasonably slow. <ieure>I did a `guix home reconfigure' on a machine this morning, it tries to build guix because there aren't substitutes (because ci is wedged), it never proceeds beyong "0%". <ieure>hako, I didn't see that, but 132.0-1 is out already and I have patches teed up for it later today (probably.) <Rutherther>ieure: it makes sense it made build slow, doesn't it? reducing number of cores is going going to make it slow <ieure>Rutherther, Slower, yes, definitely. "So slow local builds stay at 0% for several minutes" is may be slower than expected. <podiki>will go and do that mesa-updates merge....! <yelninei>Hi janneke, saw the discussion around #73181 . I've been working around the stoi error by adding GC_LARGE_ALLOC_WARN_INTERVAL=100 (resp something sufficiently large) to the guix-daemon environment <pjals>How do I use a custom libc with the GNU build system? Do I need to use my own? <futurile>Q: is there a way to get the TAP test-suite to output? I'm trying: make check TESTS="tests/guix-refresh.sh" SCM_LOG_DRIVER_FLAGS="--brief=no --comments". <futurile>From what I've read it should be showing me any line with a # at the start if I have --comments on <podiki>what will be nice is we can now upstream hyprland, as hako already has those in their channel (which i was using) <podiki>more eyecandy for wayland in guix :) <podiki>sneek: later tell hako with mesa-updates merged should be easy (i think) to upstream hyprland, thanks for maintaining that! <nutcase>without really understanding, what it means to have mesa-updates merged: congratulations and thanks :-) <Rutherther>nutcase: it just means that the work that was done on the mesa-updates branch, namely update of mesa package and related packages, is now provided on master, so users will get the changes <nutcase>Rutherther: My guess: mesa updates is related to OpenGL and DRM etc? Since a lot of packages depend on these, the update was not trivial? <ieure>Yeah... My personal channel is rebuilding everything. <sneek>noe, civodul says: tried a few pairs and found this relatively long path: guix graph --path libreoffice openblas <sneek>noe, futurile says: #73842 is very cool! <noe>What is this hello mr bots <noe>Couldn’t have made it without Sebastian <noe>I don’t use flatpak :p <noe>but I looked into making that PackageKit interface <decfed>first time I am hearing of this one <Kolev>peanuts, GNOME Software can install Guix packages?! <decfed>Kolev: did you get the instructions for running guix atop Silverblue I posted here a few weeks ago? <Kolev>decfed, whoa! No! I did not! <decfed>should I repost or will you find it in the logs? <noe>Kolev: not yet but that’s the feature requested in the issue <vagrantc>hrm. wonder why there are no substitutes for linux-libre, the kernel-team branch built them successfully ... but something in it's dependencies must have changed since? <ieure>Would be really nice if there was a setup where ci would build off a `next' branch (or similar), then merge to master after building the changes. <ieure>You wouldn't end up missing substitutes due to `guix pull' racing the build farm. <vagrantc>ieure: yes, but they were recently built on kernel-updates branch <vagrantc>which is kind of like that ... but sometimes this sort of thing happens <vagrantc>i cannot fathom the three updates i did broke that <Kolev>decfed, nice. Can I do /var/gnu/store/? <vagrantc>so, unless something changed in the build dependencies since that build, it shouldn't matter that ci hasn't built it on master yet, because the matching substitute should already be present <vagrantc>guess something changed in the derivation ... <vagrantc>/gnu/store/0hvf65p7f5rnnpbbp88xm1nfjgr2m8xa-linux-libre-6.11.6.drv vs. /gnu/store/s6l5qz2hn8zak25vjhrmwkrxra0ijgdy-linux-libre-6.11.6.drv <ieure>I'd assume linux-libre is very low in the dependency tree. <yelninei>i guess the kernel updates were branched off earlier <vagrantc>ieure: that's present in the branch that I *thought* was built <vagrantc>anyways ... whatever. it's just mysterious guix stuff. :) <yelninei>Something in between 6333849010b94ba72c7198d3560c6301fc9e657c and 7bc82833a206fbf3f0ccc1226399bf10d8187012 (judging by the cuirass evaluations) <Sharlatan>futurile Nigith is my free time =); go-team is re-based on the way to be merged, fixing missing inputs swarm for python-team on my leasure... quite a lot. And packing some astrosoft from my list for this mont