IRC channel logs
2025-11-18.log
back to list of logs
<JodiJodington>does anyone know how to escape parantheses in substitute*? I.e I want to match a literal (foo) instead of capturing foo <JodiJodington>that worked! thanks. why \\(? I wouldve thought \( would work <JodiJodington>oh nvm I get it, because guile would interpet \( as an escape sequence for the string literal itself <ieure>JodiJodington, You're dealing with overlapping syntaxes here, you have to escape the paren for the regexp with \(, but you also have to escape the backslash for Guile's strings with another \. <ieure>Emacs Lisp strings work that way, too, so a fair bet that other older Lisps also do. <JodiJodington>is it expected that some tests in `make check` fail? I'm building the guix repo right now <JodiJodington>the new codeberg-based workflow is giving me some trouble :/. I forked guix, made some changes, commited them locally. Now I am trying to push it back to my forked repo and one of the push hooks is calling `guix git authenticate` which crashes with a very strange error: https://bpa.st/GVRA. My only guess is that it's because I'm authenticating my commits with ssh, I have no clue what guix expects. <JodiJodington>(Should i turn off signing commits for this repo and let guix handle it?) <mange>If you're not a committer to Guix upstream then you don't need Guix to verify your commits. That hook is important for committers, because if they push a commit with an invalid signature it breaks Guix. For your fork it's probably not a big deal (unless you're planning to distribute your fork separately). <JodiJodington>How does that work with PRs though? won't accepting a PR merge the commits as they are (i.e without a signature)? <mange>Hmm. Actually, that check should only fire if you're pushing to codeberg.org/guix. Are you trying to push to the upstream Guix instead of your fork, by accident? <mange>Guix doesn't merge PRs through the Codeberg UI. Committers re-sign commits with an appropriate key as part of a manual merge. <JodiJodington>and no I just checked, im pushing to the right repo (my fork) <JodiJodington>nope, cloned less than an hour ago. Looks like `guix git authenticate` is what adds this pre-push hook (odd behavior imo) so it's not actually shipped with the guix repo, it's just added when you run `guix git authenticate` as one of the steps in the "Building from Git" chapter of the manual <mange>Hmm. That does seem less than ideal. <JodiJodington>deleting the pre-push hook worked! Im not sure that git guix authenticate adding the pre-push hook should be the default, it's a bit invasive. Is that something I should bring up in the mailing list or is it too bike-sheddy? <mange>If following the instructions in the manual got you stuck on this point then I think it's worth bringing up on the mailing list. <JodiJodington>mange: I just sent an email if you want to add or correct anything, the subject is "Guix Authenticate confusing behavior" (not the best description I know, im not too good at those :p) <lugeha>I added home-niri-service-type to my home config, but the service doesn't show up in my herd config, so the service doesn't run. Am I missing something? <apteryx>lugeha: did you 'guix home reconfigure ...' ? <lugeha>added to my services list as per normal, no modificaitons <mange>Can you send a link to a paste with your config? I've definitely had it work in the past. <mange>apteryx: Yeah, I've seen a few "store your issues in git" sort of projects. I'm not sold on the approach. I think Fossil has a similar feature, though, so maybe I'm the weird one. <lugeha>haha, i just figured it out... namespace collision with third party channel. <apteryx>mange: must be super fast to track bugs, the but obvious downside is that now only committers can report bugs I suppose, raising the bar to report bugs <apteryx>but apparently there are bridges with github, so migth work with codeberg too <apteryx>perhaps something became more strict in the build env used by gexp->derivation and --appimage-extract-and-run can't extract anymore (read-only?) <apteryx>no errors though, and can't run strace in such env <noe>Can you find the build log for that derivation? <noe>See the last patch I sent <apteryx>emacs takes a ridiculous amount of time to build single core <apteryx>apparrently due to non-determinism, but I see no comment nor an upstream issue for it <apteryx>noe: thanks, I'll try your patch tEre <apteryx>noe: I tried the patch, but the test still fails. Hm. <noe>I will but I don't have time today <apteryx>it's that same "appimage + localstatedir" test <apteryx>noe: OK! I'll follow up on the original report to let people know where to grab the branch <noe>Sounds good, thanks for paying attention to the tests <apteryx>noe: actually, just replied to the mail thread, it was easy with 'mumi send-email' :-) <apteryx>re slow emacs build: building of `/gnu/store/pr2xvvkcx28brq9wvw130vyigwxa6pwn-emacs-minimal-30.2.drv' timed out after 3600 seconds of silence ^^' <apteryx>Info files are now Zstd-compressed on the `add-compress-debug-symbols-phase' branch! <apteryx>I think that's the last feature I'll squeeze in for this world rebuild branch: https://codeberg.org/guix/guix/pulls/4173 (it has mmap for ELF files manipulation, Zstd-compression + DWZ deduplication of debug outputs, and now Zstd-compression of Info nodes). <apteryx>the rest is stabilization/opportunistic updates work <civodul>apteryx: hey! i don’t know, do you have a link to the build? <civodul>ISTR gcc-mesboot does take ages to build <civodul>apteryx: re .info, does ‘info-reader’ know how to handle ztsd-compressed files? <apteryx>unzstd patched in filesys.c on that same branch <apteryx>(and zstd wrapped in Emacs for the same reason) <civodul>so the ‘timeout’ property isn’t honored <civodul>(isn’t this PR the kind of thing should go on ‘core-packages-team’?) <apteryx>yeah, either it isn't or I'm patching the wrong package def, but I think there's a single gcc-mesboot variant at that version <civodul>so the problem is that gcc-mesboot really needs more than 21k seconds to build <civodul>this build happens as part of the evaluation (on berlin, but it’s offloaded) <civodul>one way would be to change the default timeout for guix-daemon on all the build machines <civodul>and a quick workaround is to “guix build --timeout=0 --no-offload …/gcc-mesboot” on berlin <apteryx>"as part of the evaluation" this is what you mean by "not an actual build" ? <apteryx>OK! And in this case the property won't help? <apteryx>changing the default timeout means we could get stuck really long without noticing <apteryx>could the evaluation sum the timeout properties? :-) <apteryx>ACTION has a poor understanding of why builds part of an evaluation are not treated the same as "real" builds <cbaines>I'm stopping bordeaux build farm stuff on bayfront to mess with the build coordinator database... <graywolf>Are you interested in numbers from non-comitters as well? :) <graywolf>apteryx: One question though, would it not make sense to have the flag other way? <graywolf>I would expect that `make check' runs basically all tests it can, so what about `make check SKIP_SLOW_TESTS=1' in the hook instead? <apteryx>graywolf: sure :-) in my experience, if tests take more than 20 minutes to run, few will run them, that's why the default includes only fast tests <apteryx>I'm always personally annoyed when the test suite of a package takes more than a few minutes, and 'make check' is the test suite of the Guix package ;-) <graywolf>38.87s on home server, 116.04s on laptop for the fast variant, the slow variant I had to kill after ~45 minutes on both, since there did not seem to be any progress. <graywolf>I do see your point regarding the slow/fast preference (though I am not sure, do we run check during build of guix package? if so, we probably want the slow there) <graywolf>But would be nice to at least have check-full so that tab completion works ^_^ <pooyam>Was Guile chosen since Guix is aa GNU project? <pooyam>(as opposed to other schemes/lisps) <df0>"The project began in June 2012 by Ludovic Courtès, one of the GNU Guile hackers." <ekaitz>pooyam: the author is also one of the maintainers of GNU Guile <civodul>apteryx: i like that BTW, been spending too much time waiting for tests :-) <civodul>i think some of them are poorly written (like they invoke the GC just to remove one store item) <civodul>but others are inherently expensive (like those that actually test the GC) <apteryx>graywolf: yes we do run 'make check' as part of the guix package build, that's when it's hard to update it ;-) <apteryx>(it's always broken, slight exageration) <apteryx>which is one thing that having 'make check' in a pre-push hook would tackle: broke the test suite? sorry, can't merge that. <apteryx>civodul: I thought as part of that change I could document the expectation for test duration included in 'make check'; ideally each tests should run under a second or at most a few seconds. Slower tests should either 1) be rewritten to be fast or 2) marked as slow, if the value they provide justifies keeping them around. <apteryx>graywolf: it'd be easy to add 'make extended-check' or something (as a .PHONY target in Makefile.am). <civodul>apteryx: yes, that makes sense to me <slipening>Hey, does anyone here have a dead-simple user Shepherd service for starting Emacs as a daemon, or know where to find one? I'm so close to having it work on my Guix SD machine, but it'ss failing to start. The log file shows me that emacs-pgtk can't find the native compilation .eln files and just fails after trying to find window.eln. I'm just trying <slipening>Oops *I'm just trying to find a config to compare to <PotentialUser-85>oh my bad it's not in the `%default-substitute-urls`. I thought because it's authorized it's in there <Rutherther>sneek, later tell slipening, you're experiencing a bug due to how guix wrappers work + emacs handling of $0. Solution is to put emacs in PATH before starting it. <Rutherther>PotentialUser-85: you might set substitute urls through the guix-configuration in your system config in an order you prefer <user7485859>Does anyone know who is supposed to approve emails on help-guix from non-subscribed addresses? I sent one about 24h ago and it hasn't gone through yet. <gabber>user7485859: it takes some time for the first email of a new address to go through but it should eventually reach us IIRC (: <JodiJodington>I'm trying to package the new yt-dlp-ejs but it's a PITA. it relies pretty heavily on rollup and rollup relies pretty heavily on rollup too... <JodiJodington>maybe itd be worth doing a rollup bootstrap at some point since lots of new stuff uses rollup. For now I'll try rewriting the rollup script in esbuild but it's pretty hairy <gabber>ACTION just learnt about the *fresh new way* of bundling js modules <JodiJodington>I've had the displeasure of learning about 4 fresh new ways :p <ieure>People keep inventing new, worse ways of doing this. <gabber>it's about time for extreme programming to step back a notch and make way for dependable and sustainable engineering <slipening>sneek: Rutherther said you're experiencing a bug with guix wrappers + emacs handling $0? I'm trying to run emacs as a daemon with a Shepherd service, but it's not finding the native-lisp directory. Do you have an example on how to fix that? A custom package definition of emacs? Adding an environment variable to the (make-forkexec-constructor ...) <sneek>slipening, you have 1 message! <sneek>slipening, Rutherther says: you're experiencing a bug due to how guix wrappers work + emacs handling of $0. Solution is to put emacs in PATH before starting it. <vagrantc>is it just me, or sometime in the last months "guix pull" changed soemthing which started spitting out tons of deprecation warnings ? <vagrantc>those warnings do not really seem actionable or meaningful in the context of guix pull, unless i am totally missing something ... <ieure>vagrantc, There was a big branch merge that rearranged / renamed packages and deprecated the old ones, the warning happens any time anything uses a deprecated package, including Guix. <Rutherther>slipening: no need for a custom packge definition. Setting the env var in the service suffices, ie with the #:environment-variables option of make-forkexec-constructor <ieure>vagrantc, There's been some post-merge cleanup, so it's less than it was initially, but yeah, still some more work to be done there. I agree that it'd make sense to suppress those during `guix pull', specifically. <vagrantc>ieure: yeah, my guess was it is triggered because guix pull effectively references every package, so yeah, it will reference a bunch of deprecated packages :) <slipening>Rutherther: perfect! thanks! Saves me from trying the custom package definition route, and saves me from looking into whether I needed to add the default-environment-variables back in or not. <Rutherther>well you do not need to, but you will soon find out that you want to :) <Rutherther>note that an alternative is adding emacs to your home profile service that way it will be in your PATH by default <slipening>I have emacs-pgtk added with a home-profile-service, do you mean to also add the plain 'emacs' package, too? Running emacs as a daemon seems to work fine when I'm logged in. It's just Shepherd that seems to have the PATH issues. <Rutherther>are you sure the emacs in your service is the same emacs as you have in your service then? <slipening>emacs-pgtk is the only emacs package I have anywhere in my system. Only installed by home-profile-service, and not installed by guix install. <Rutherther>I am not sure why you get the error then, because you should already have the correct emacs in PATH <slipening>Hmm, I haven't tried guix gc yet - not sure how often that helps, there's definitely another emacs package in the store somewhere <Rutherther>emacs in store does not matter, emacs in PATH matters <slipening>K. I'll still try messing around with adding other PATHs to see if it'll fix it for me. <bavier>anyone know what's up with our gtk package? It ftbfs. <ieure>bavier, I don't know about the package, but curious where you got "ftbds" from? I know what it means, just haven't seen it used much outside Debian developer circles. <bavier>ieure: lol, learned it here many years ago :) <ieure>bavier, Ha, well, there you go. <ieure>I think there's some Debian/Guix developer overlap. <bavier>ah, and nvm about gtk, failure is in my local tree. :| <vagrantc>there are soem corner-cases where packages are not substitutable <ieure>FuncProgLinux, Yes, the zfs package is an example of one, due to licensing. <FuncProgLinux>for example when defining a package inside a manifest it searches it on substitutes every time the a new shell using said manifest is invoked. I really don't mind rebuilding them on each new shell invoke and know about --no-substitutes but wouldn't that also propagate to other packages from the manifest? <vagrantc>git grep -i 'substitutable? #f' gnu/packages <FuncProgLinux>ieure: I've heard very little about ZFS. I only heard about the <FuncProgLinux>...the *buntus shipping it. But I got lost of the news when btrfs was the cool friend in town <ieure>FuncProgLinux, The "Updating substitutes" messages happen basically always, I think we're doing that unnecessarily in some cases. <FuncProgLinux>ieure: Was it the issue opened by ngraves at codeberg? #1010 i think ? <ieure>FuncProgLinux, "Updating substitutes" mean Guix is sending a bunch of HEAD requests to substitute servers to see what substitutes they actually have or don't, so it can plan which things it needs to download. But I have noticed that this happens even when all the needed items are already in the store. <ieure>FuncProgLinux, Related, but not the same. <FuncProgLinux>ieure: Ahh so that's why! I was assuming there was no caching of manifest declared packages. Thus why I was confused why would guix be searching for substitutes on a local-file package <vagrantc>yeah, not querying the substitute servers when you have everything seems suboptimal ... although there are some computed substitutes where the value is not known in advance or something that might make it trickier <FuncProgLinux>vagrantc: I very much thank guix for having browser substitutes :s <vagrantc>had a bit of relief from the constant churn of stable kernel updates ... but now back to grinding package update checks ... <ieure>vagrantc, Run a substitute server on localhost, make that the first entry in substitute-servers. Infininte bandwidth and profit awaits! <vagrantc>FuncProgLinux: i'm very thankful when i get substitutes on aarch64/arm64 ... as some of those builds can take forever ... <vagrantc>looking at you, linux-libre source tarballs ... which take longer than actually building the actual kernel <FuncProgLinux>vagrantc: I don't knw much about those architectures. I have an orange pi (armhf) lying somewhere. But no single distro survived a reboot. <vagrantc>ieure: and recursive loops, perhaps, too? :) <vagrantc>some things have decent (near-)mainline support these days <vagrantc>ieure: but yeah, i should definitely get a local substitute server going ... <FuncProgLinux>Hopefully they reach 1.30.0 soon and see if their progress on the wayland thing has evolved <FuncProgLinux>just saw the ZFS PR. So the license issue is redistribution in binary form (?) <vagrantc>it is impossible to comply with the both terms of both GPL and whatever ZFS is licensened under while redistributing binaries <vagrantc>it is free and open source software, it is in fact distributable <FuncProgLinux>you may distribute the binary but not the source. Not the other way around <ieure>Yeah, you end up with some weird licensing situations like this with a lot of ex-corporate software, which ZFS is. <vagrantc>it is not an explicitly forbidden case, it is the intersection of two licenses ... each thing on it's own is unambiguoous <FuncProgLinux>I remember a similar situation back in 2017~ with grsec kernels <ieure>Maybe not "a lot," but these types of licensing concerns make a bit more sense when it's ex-corporate code instead of something born free. <waffles>ive been recommended guix for an old i686 dell d600. was wondering if it was compatible with libre <df0>wifi is the main stumbling block with libre <waffles>i can get a usb wifi thingie if thats an issue <cdegroot>"ex-corporate software" is secret speak for "all the garbage licenses that Sun invented"? ;-) <df0>the problem i had with usb wifi was that the firmware blob is required for it to operate, and that wasn't available in libre - but there are some usb wifi adapters that do work <waffles>i bought 2 of these for use with linux pcs maybe its fine? Realtel RTL8188 <ieure>cdegroot, I'd point at basically everything Apache hosts, other than the namesake web server. Whole project is like the island of lost toys for code tech companies wrote and got sick of maintaining. <FuncProgLinux>ieure: oh I remember when they got Netbeans in their hands...it was horrible <ieure>Cassandra, Kafka, CouchDB, the entire Hadoop ecosystem. Definitely gobs more I've never even heard of. <cdegroot>ieure: it's strange, since I'm not using Java anymore, ASF might as well not exist. They really went into a different corner there. <FuncProgLinux>I used it back in the day when I studied and that forced us to switch to intelliJ ram-eater <waffles>my current network card in this machine is a intel 2200bg <waffles>if its an issue though my laptop has a... i think a mini pci card reader <JodiJodington>is there a utility function to replace the contents of a file with a string? currently doing `(copy-file (plain-file ...) dest)` but it's kind of inconvenient <waffles>btw did u see the downloads for guix r currently 502 bad gateway <FuncProgLinux>waffles: I don't know much about that I think realtek has a lot of proprietary drivers which might not be in linux-libre. But I think it's best to give it a shot. The installer will notify you if you got incompatible hardware as far as I know <df0>something that does work with linux-libre, for emergency network access, is using a phone in usb-tethering mode <JodiJodington>mine is but it's also broken upstream so i can't use it without out-of-tree drivers anyway :p <waffles>for now is there a mirror to download guix <vagrantc>there are approximately 1-2 usb wifi dongles that work with linux-libre ... the ones that are ath9k based ... and maybe one other? <ieure>I have a random Netgear one that works fine. <ieure>> Bus 001 Device 031: ID 0846:9041 NetGear, Inc. WNA1000M 802.11bgn [Realtek RTL8188CUS] <ieure>Very small antenna, though, tethered phone works better in my experience. <ieure>I use my old phone for that. <JodiJodington>vagrantc: really? I thought very few wifi cards still required blobs <vagrantc>JodiJodington: i think you have that inverted <jlicht>Rutherther: your understanding wrt the build system (and importer, probably) not supporting the npm: notation is correct (imho) <ieure>JodiJodington, PCIe WiFi cards basically all require them.