IRC channel logs
2026-07-02.log
back to list of logs
<JessXP>hi I'm writing a guix package rn and running into the issue that using (recursive? #t) in (git-reference) doesn't fetch the git repos submodules <JessXP>i'm quite certain that the repos submodules are properly defined in the .gitsubmodules file as i have no issues initialising and updating the submodules via git in the cmd <hjolmir_the_peni>> hi I'm writing a guix package rn and running into the issue that using (recursive? #t) in (git-reference) doesn't fetch the git repos submodules <JessXP>as a follow up i'm also curious if theres a way to specify which submodules should be fetched as some projects have quite large submodules and don't require all of them <ryanprior>I'm working on a blog post (for my blog at www.ryanprior.com/posts/) about using Guix for Lua software development. Anybody interested in proofreading? I've got ~2k words. <czan>Yes, I am! Partially also because I'm interested in improving Lua development support in Guix. <ryanprior>czan: that's great! how should I send you a draft? <czan>Maybe DM me a link? I might take a little while to get to it, because my day today is pretty interrupted. <vermiculous>I'm new to Guix and Scheme but I was trying to "convert" some cronjobs I had on FreeBSD to be managed by my Guix Home. I'm just messing around with shepherd-timers and trying to better learn the syntax (although it's not too far off from Common Lisp/Elisp so I understand it a bit). Every time I trigger this timer then I lock up shepherd and herd status no longer works until I restart my system. Could someone tell me what exactly is <vermiculous>Also, I know the appropriate way would probably be all in Scheme but I don't understand it enough to not have to use the built-ins: find, chmod, chown, et cetera. <identity>vermiculous: see chown, chmod at (info "(guile) File System"), and ftw at (info "(guile) File Tree Walk") <identity>also, logging out and then back in should be enough to restart the user Shepherd <vermiculous>identity: Thank you. I just found geiser/geiser-guile as well so that should help along with the docs. <ryanprior>Anybody use geiser successfully lately? I haven't tried using it in years now, but it used to be a total trap. <ryanprior>in the sense that it looked like it should work, and its continued development implied that people were getting value out of it, but actually trying to use it to get work done was not really feasible <identity>but, at least currently, it is fine for my needs <identity>do we have a way to deprecate package outputs? <Guest20>Hi guys, I've got a situation that I'm unsure is an issue or not <Guest20>Trying to do a reconfigure and I've been stuck at 0% of building guix-1.5.0-3 for quite a while <Guest20>Have I done something wrong perhaps? Did a fresh guix pull too <csantosb>7e0f9d22198 * gnu: guix: Update to 1.5.0-3.76c084f <Guest20>csantosb I'm pretty new to guix, what does this mean on my end? <identity>csantosb: and you say that right after i started guix pull :/ <identity>Guest20: basically, just wait until it gets fixed <identity>you might want to pull from a commit right before that one (e1f5946742c73941f43dd2a37ff023dd3eadc6ad) <dariqq>Is something wrong with the guix update? I hoped to have a substitute available but I am currently rebuilding it <adanska>dariqq, I did not have to build, maybe check the substitutes again? <dariqq>huh now there is? It definilty was not 15 mins ago. <csantosb>Just did a guix pull && guix upgrade; all fine from my side <futurile-afk>(ugh ankle rehab morning, off to cry while someone yanks on it) <sham1>I'm getting some errors trying to build some emacs packages in my profile when rewriting an `emacs-minimal` input as `emacs-next`. I wonder if this is an upstream bug or something peculiar to Guix. Either way, does anyone know if there's a ticket for this or if I should make up one <sham1>Specifically it's about loaddefs-gen <identity>it is probably an «outdated upstream» sort of bug… <identity>sham1: check whether it works on the emacs-team branch <sham1>If this works, I'll probably have to make an inferior out of it <sham1>Either that or manually track the upstream Emacs commits in my config <ieure>untrusem, Thanks for the heads up, I'll plan on packaging 153.0 if it lands in that timeframe, unless you say otherwise. <ieure>Put up 152.0.4-1 last night, it has some memory corruption fixes. <untrusem>sorry i am not contributing that much these days <ieure>It's all good, I appreciate your help. <sham1>Hm, even with the most recent emacs-31 commit, the check times out. Seems that it's an upstream bug, though <nomike>Oh...forgot to say hi! Mea culpa! Too many things in my head at once I suppose... <nomike>So regarding that package: I've already renamed the variable name of the old package to `qscintilla-5` and created a new variable called `qscintilla` which inherts from the other and doe a replace of `qtbase-5` with `qtbase` in the inputs. <nomike>The issue is, that there are now two packages with the name `qscintilla` which have the same version, but are different (one for qt5 and one for qt6). <nomike>I've tried looking up how this was done in other parts of Guix. There the packages have the same name (e.g. "qtsvg") but one is at a 5.x version and the other at a 6.x version. <nomike>But I guess as qscintilla is not part of core Qt but an external library, it doesn't follow Qt's versioning scheme and the version in Guix is now 2.13.4 (the latest online is 2.14.1; I'm planning to update that as well). <nomike>My idea was, to deviate from the usual scheme in this case and really name the libraries different. Like one being "qscintilla-qt5" and the other "qscintilla-qt6". <newguixbieoldbra>hi #guix, i am still on my slow multi-month journey to get engaged in i686 guix, but i wanted to pop in because i tried the 1.5.0 install cd and it failed to boot <newguixbieoldbra>it seems that zisofs doesn't work well on i686 due to a change in how new kernels handle high memory. <newguixbieoldbra>with a lot of boot tweaking i see 3 kernel panics, let me redo the tweaking <jresich>why does `guix time-machine -C channels.scm -- describe` return the commit hash specified in the channel file, but `guix time-machine -C channels.scm -- shell guix -- guix describe` always return commit 520785e...? <Rutherther>jresich: guix shell guix will give you the package from (gnu packages package-management) module that's pinned to a specific commit. It doesn't 'always' return that commit, but it might return that commit for couple of months depending on when the package is bumped <Rutherther>jresich: if you wanted to pass current guix to a container, use --nesting <jresich>what if I just want a shell where guix is at the specified version? I don't want a container <newguixboldbrn>Rutherther: sorry my device lost power. the v1.5.0 install cd panics immediately after loading system/boot . i have the panics in front of me atm <newguixboldbrn>this is a lenovo T60 i686. the 1st panic is at mm/highmem.c:622 kunmap_local_indexed+0xf0/0x110 called by zisofs_read_foli-+0x9e0/0xb70 called by read_pages+0xed/0x1c0 ... i think this is a known issue with zisofs on i686 according to an AI which said new kernel versions require i686 high memory page usage ordering that zisofs doesnt respect. 2nd <newguixboldbrn>panic also in highmem from page fault, then guile errors showing data corruption, corrupt variable names <Rutherther>the zisofs error is a red herring, it's not an actual error <Rutherther>or like... it probably is an actual error, but it's not fatal is what I wanted to say <newguixboldbrn>yes, you are already tracking it, great :) it should probably be built with the uncompressed image type. i will read your thread. <newguixboldbrn>thoughts on my issue: :: an AI said it related to memory ordering so it could relate to timing issues :: i had this issue earlier with debian and it turned out the failing zisofs code was giving garbled data to the filesystem, that is what caused the guile and other errors :: _the i686 image should be built uncompressed_ :) <newguixboldbrn>Rutherther: to clarify i see the zisofs issue as causing data corruption which for me is fatal and prevents install. can you reopen the issue? <newguixboldbrn>regardless though thank you for pointing me to the issue and for the very inspiring 1.5.0 release <guixguest>are there alternate installation ISOs for Guix, similar to many other distros? <ieure>newguixboldbrn, Maybe the 1.4.0 installer would work, and you can update after? <newguixboldbrn>ieure: yes that is the path i was doing before. but i think it might also work to decompress the cd manually. <mattl>gross. please don't post slop.