IRC channel logs
2026-06-30.log
back to list of logs
<Noisytoot>is ffmpeg compiled without alsa support? I'm trying to record audio with ffmpeg -f alsa and it's saying "[in#0 @ 0xb4fa3c0] Unknown input format: 'alsa'" <apteryx>sneek: later tell graywolf re git histogram algo, it made a world of differences when importing hundreds of node.js packages with 'guix import -i gnu/packages/node-xyz.scm npm-binary -r something'; the packages hunks would otherwise be intermingled. With the new -i switch for guix import I expect this would happen more. <sham1>Histogram is just a better diff algorithm in general IMO. I tend to just set it on everywhere I can <apteryx>"ModuleNotFoundError: No module named 'puccinialin'" <apteryx>efraim: hi! I was wondering what was the reason for using (search-input-file native-inputs "/bin/uv") is for in the uv package when its cross-compiled instead of always using (string-append #$outpT "/bin/uv")? <efraim>apteryx: when cross-compiling #$output/bin/uv is cross-compiled so we would need the uv from native-inputs <efraim>jlicht: node-24.16.0 built successfully on my RPi5 on the javascript-team branch, and no failing tests. Took just over 13 hours. <apteryx>for the installed artifacts it shouldn't matter, no? since they'll run on the actual target <apteryx>I could see maybe referencing the native uv could be useful if you wanted to run tests on the cross-compiling machine (host) <efraim>for the shell completions there's no reference kept to the actual binary run to generate the shell completions <apteryx>ah! just saw there's an invoke in there <efraim>if you want to see an old version there's procs in rust-apps.scm which hasn't been updated yet <efraim>I didn't expect it to take so long to build but I'm glad it worked so well. I would've hated to have to start again with -K to see the tests <efraim>hopefully it works well on the build farm too <gabber>Noisytoot: i don't see anything like that in ffmpeg's inputs. if you think this is a bug: please open an Issue and/or Pull Request on codeberg. feel free to add the audio-team label to it (: <adanska>would there be any reason importing (guix records) into (guix build syscalls) would be a bad idea? (guix records) just imports srfis and other built-in modules so i dont think it's going to create any bad dependency cycles... so im curious as to why it hasnt been included already <adanska>the `match-record` macro itself would be incredibly helpful <adanska>as would the improved define-record-type* <csantosb>Ey Guix ! Any idea why `guix shell -CPW emacs-org emacs-magit coreutils which -- guix package -p $GUIX_ENVIRONMENT/ --export-manifest` returns "(specifications->manifest (list))" ? <csantosb>Executing `guix shell -CPW emacs-org emacs-magit coreutils which` followed by `guix package -p $GUIX_ENVIRONMENT/ --export-manifest` returns the right manifest <gabber>csantosb: i don't have a very good answer, but i remember how i found some similar inconsistencies between the two variants of command invocation <gabber>in the former version $GUIX_ENVIRONMENT is evaluated before `guix shell` <gabber>try wrapping the first in a `sh -c'guix package -p ...'` <efraim>I was about to suggest wrapping it with sh -c <csantosb>Much better, thank ! `guix shell -CW emacs-magit bash -- sh -c 'guix package -p $GUIX_ENVIRONMENT --export-manifest'` <csantosb>Remains how to get rid of "guix" and "bash" in the resulting manifest <gabber>why do you use `guix package` and not `guix shell --export-manifest`? <gabber>or: what exactly are you trying to do, here? <apteryx>fetching the cve database takes too long as of late <futurile>apteryx: in principle, what do you think about having the CVE db as a package, and we repackage it at some "period" on the server side <apteryx>I think that'd be problematic, because it's updated all the time <futurile>apteryx: if I understand correctly we all download it constantly, so if you change 4 packages an hour, you download it 4 times <apteryx>maybe they could keep the data in a way that could be pulled differentially (I don't know how it works right now, I assume some compressed monolithic xml file or similar) <futurile>yeah, haven't looked into it, I've just got stuck a few times when the API doesn't respond or I'm not online etc. Appreciate the problem of it being updated "constantly" <apteryx>it's not re-downloaded if the copy you have matches the upstream copy, I think <apteryx>"fetch from the NIST web site when TTL has expired", from guix/cve.scm:364:64 <apteryx>and the mysteriously computed ttls values (seconds) are for the last 3 years: (518400 1036800 1555200) <apteryx>ah, the above TTLs are for the past years <apteryx>for the current year, it's %current-year-ttl, which is currently set to 30 minutes (1800 s) <apteryx>given the comments above says the feed is updated about every 2 hours, it'd make sense to relax it <apteryx>the smart way to get the vulnerabilities since NVD 2.0 appears to be via their API <futurile>ah OK, it is being "cleverer" then, if I'm working on packages for an afternoon it's going to hit it a couple of times, so I guess that's why I thought it was doing it every time <apteryx>it's a 14.3 MiB file for 2026 that downloads at 30-40 KiB/s from here :-/ <futurile>yeah it's slow - estimating over 10 mins now ... oh and it's closed the stream with an error heh <futurile>that said, we've had weird storms here - so maybe it's me - bah <dariqq>would someone know what the problem with the strip phase for the cross-gccs "doing the wrong thing" is? <g_bor>hello, I am running into a problem, on guix pull I get cannot build derivation `/gnu/store/13z9qibgrhasq9g4qgq7lx6wcqknx3d6-compute-guix-derivation.drv': 1 dependencies couldn't be built <g_bor>guix pull: error: build of `/gnu/store/13z9qibgrhasq9g4qgq7lx6wcqknx3d6-compute-guix-derivation.drv' failed and the build log says: ERROR: In procedure %resolve-variable: <g_bor>error: spawn: unbound variable <ieure>g_bor, Any third-party channels? <g_bor>no, but I think now I got it <ieure>You mean the guix for the `root' user? <ieure>If so, that's normal. There's almost never a reason to use root's guix. <ieure>And if you are, you're probably doing something... maybe not wrong, exactly, but not really how things are supposed to work. <ruined>i'm under the impression that you should 'guix pull' as root to update the guix daemon when running guix on a foreign distro <ieure>Hmmm, possibly? If so, that's an exception to the general rule. <ieure>ruined, I don't think it works that way. I have Guix on a Debian box (using the Debian packages), the systemd guix-daemon.service file has ExecStart=/usr/bin/guix-daemon ... -- `guix pull' isn't going to update either /usr/bin/guix-daemon or /lib/systemd/system/guix-daemon.service. <ruined>ah i think the difference is that i installed guix using the install script, as the guix package manager had already been removed from debian when i isntalled <csantosb>On a foreign system, I have always updated with `sudo -i guix pull` <identity>the most up to date manual is the one installed on your machine <csantosb>Online is "0a137ca — 30 June 2026", last commit as for right now; I'm impressed. <mwette>This morning, I was getting `guix pull` failure of compute-guix-derivation, different error than g_bor, though. As root (on foreign) I executed `guix pull` followed by `systemctl restart guix-daemon.service`, then as user I ran guix pull again and it seems to be going OK now. <janneke>trying to do their bit upholding the lisp curse, /me writes their first poor-mans define-method/type-dispatching macro