IRC channel logs
2024-01-19.log
back to list of logs
<mekeor>i think i just missed a deadline at university because... my computer clock is lagging several minutes behind because... i don't have a ntp-service set up on my guix system? <mekeor>is it possible that a missing ntp can lead to this? <mekeor>do you recommend ntp- or openntpd-service? <vagrantc>i always expect guix pull to revision X ... followed by X+1 with only a minor leaf node package update ... to go much faster than it does <lilyp>guix pull is fairly constant time, guix package/guix system are O(n) where n is the number of changed packages in your profile <jpoiret>guix pull is O(how many packages are in the huge cyclic graph containing all guix dependencies) <janneke>jpoiret, civodul: so apparently i /didn't/ successfully build hurd with glibc-2.38 yet, and i broke the hurd build on core-updates <janneke>ACTION is not sure what they tested or saw before... <janneke>ACTION pushes a fix for gnumach-headers to core-updates <janneke>i'll go on to test removal of %glibc/hurd-configure-flags workaround later <civodul>janneke: you’re testing natively, right? <janneke>in the glibc-2.38 based hurd build (that supports x86_64), the gnumach(-headers) package now must build a machine symlink <janneke>so, core-updates is still much more broken than i thought, but it's getting better :) <janneke>but still working to build a hurd vm on core-updates <janneke>hmm, the i686-linux bootstrap hasn't even been built on core-updates <cbaines>looking at QA, my suspicion is that there's some cycle when trying to compute the guix derivation for i586-gnu <janneke>ouch, let's hope that's not the case; for now i'm not seeing anything hang <janneke>grmbl, cross-built hurd still cannot find mach/machine/mach_i386.h <janneke>turns out that somehow gnumach-headers-cross-i586-pc-gnu isn't included in C_CROSS_INCLUDE_PATH!? (anymore?) <janneke>hmm, cross-gnumach-headers wasn't needed as a dependency before? <ulfvonbelow>just to double-check, has anyone tried using the i386 guix installer image within the past several months? <jpoiret>janneke: don't we do a union of a bunch of outputs, which breaks the symlink? <janneke>and to which gnumach-headers[-cross-i586-pc-gnu] would now have to be added? could be... <jpoiret>the machine symlink needs to be done at the level of gnumach headers, not just the cross variant <jpoiret>I think the issue comes from hurd-core-headers <jpoiret>we could probably get away with using a relative symlink instead of what I presume is an absolute one <jpoiret>that way it would not be broken when copying <janneke>ACTION just patched glibc and the cross-glibc, but i won't push that now <jpoiret>I haven't looked at hurd yet, we still can't build the desktop os example config on c-u for x86_64-linux for now <jpoiret>ah. So the compilation error happens for xhurd-minimal? <jpoiret>janneke: I'd guess the gnumach headers are part of the toolchain, that's why they aren't in inputs <jpoiret>can you find the gnumach headers in `guix build -e '((@@ (gnu packages cross-base) cross-kernel-headers) "i586-pc-gnu")'`? <jpoiret>it's a shame those aren't exported which forces us to resort to @@ for debugging <janneke>jpoiret: yes, gnumach-headers are included there <janneke>$ l /gnu/store/4wyh5y18kci1kzznjhd89qapr1ikdr6r-hurd-core-headers-cross-i586-pc-gnu-0.9.git20230520/include/mach/ | grep machine <janneke>-r--r--r-- 55 root root 8480 Jan 1 1970 machine.h <janneke>lrwxrwxrwx 1 root root 4 Jan 1 1970 machine -> i386/ <jpoiret>unless the i386 directory is empty 🤨 <janneke>well, the i386/mach_i386.h file is in glibc-cross/include/mach/i386/ <janneke>jpoiret: it's not empty, it just only contains the gnumach-headers bits, not glibc (of course) <jpoiret>are they also in `guix build -e '((@ (gnu packages cross-base) cross-gcc-toolchain) "i586-pc-gnu")'`? <janneke> (inputs `(("gnumach-headers" ,xgnumach-headers) <janneke> ("hurd-minimal" ,xhurd-minimal))))) <janneke>hmm, hurd-minimal should include glibc/hurd-headers <jpoiret>for packages in hurd.scm, the toolchain (cross or native) should include the gnumach headers <janneke>hurd-minimal and xhurd-minimal both do include [cross]glibc-hurd-headers <jpoiret>huh. Also, I think most of the package in hurd.scm shouldn't have any dependencies on eg. gnumach-headers <jpoiret>since they should already come from the toolchain <cdo256`>Hey Guix, is there a policy for packaging libraries that may require bringing in shared-objects external to the Guix store? <cdo256`>In my case gitleaks uses zerolog which uses go-systemd is Go bindings for libsystemd. And libsystemd I expect won't be packaged in Guix any time soon. <cdo256`>So should I do surgery and lop off all the Systemd bits from this dependency train, or leave them on and let it run time panic if you try to log to a journal that isn't there? <graywolf>I find the footer ("Now with even more λ!") of issues.guix pretty ironic given I was told not to use λ in the code :D <tex_milan>Hello, update always fails with: substitution of /gnu/store/s5sq7fvrxy7k8jzx5crxdb0zxxy9j0jb-linux-6.6.12 failed, guix system: error: corrupt input while restoring archive from #<closed: file 7f2da2ec2380> How to fix it? <civodul>tex_milan: hi! do you see above the error message the URL where it’s downloaded from? <tex_milan>civodul: ? only see that error. but the download looks like interrupted in 23.4% <tex_milan>Throw to key `zstd-error' with args `(decompress! 18446744073709551596)'. <jpoiret>janneke: I can build Hurd without any modifications on c-u <jpoiret>was it the hurd build that failed or something else? <jpoiret>ah no, hurd-minimal, my hurd build was stuck because of failing downnloads <apteryx>podiki: thanks for the i686 catch2 test fix! <janneke>i've patched [cross-]glibc to also create the machine symlink, and now it builds <janneke>possibly there's a better way to do it, but at least it builds now <jpoiret>i'll have a look also, for some reason the dde-sources checkout was hanging <jpoiret>shouldn't take too long now that my toolchain is built tho :) <jpoiret>I'm surprised hurd-minimal would build but not hurd itself <apteryx>what is the lightest capable browser? is nomad good in that regard? better than icecat? <apteryx>my computing is slowed down by this mastodonte <apteryx>I have 8 GiB of RAM and it's always filling up due to icecat, although most of what I do is editing text files in emacs on a pretty minimal system (ratpoison on X) <apteryx>actually perhaps my problem is zram causing lag in icecat/elsewhere; my ram usage is currently 65% but icecat is super slow <apteryx>seems to be using the zram swap to its full extent (100% used). I have defined half of my RAM (4 GiB) as zram swap. <ulfvonbelow>I routinely forget to add --verbosity=2 to my 'guix build' command, so it's not unusual for emacs to be using over 1GB at any time for me <apteryx>I've learned to never run 'guix build' from emacs, if I don't want to have to kill the thing when it hungs on long lines or too much output <ulfvonbelow>I have an offload machine, which means that log files routinely get truncated when there are build failures <ulfvonbelow>I guess that doesn't strictly speaking matter, but it makes me want to run my commands from within an emacs shell buffer so that I can always freely navigate the output <apteryx>yes, searching is most comfortable within emacs. I open the build log in emacs after it's done, if I need to search something. <ulfvonbelow>I recently disabled my swap entirely, and confusingly enough, it seems to have made things even less responsive. I'm puzzled how I can switch to an icecat window and have it take 5+ seconds to display anything while not touching the hard drive. <apteryx>do I need to edit the source to skip Emacs ERT tests? <apteryx>sadly no command switch to do so when invoking ert-run-tests-batch-and-exit <podiki>apteryx: welcome! thanks to the others that actually figured out what the problem was <jpoiret>ulfvonbelow: in general, swap is important, even if you have lots of ram <jpoiret>the kernel is quite clever with what goes in the swap and it's generally a net plus <graywolf>In general on my guix build machine I have 128GB of ram, and still 56.8M of swap is used (for some reason) <graywolf>So at least small amount of swap usually get used sooner or later <ulfvonbelow>the kernel may well be very clever, but it ain't a prophet, and it routinely gets pulseaudio stuck in loops of 2-3 seconds when trying to play videos in mpv, which all the while spews out a bunch of "audio device underrun" messages to stderr <ieure>That has nothing to do with the kernel. <ieure>Audio device underrun means the program isn't sending data to the audio device fast enough. <ulfvonbelow>I'm not sure whether "audio device" here means "the pulseaudio instance mpv talks to" or "the audio device pulseaudio talks to" <ulfvonbelow>but in any case, I have yet to have that happen while swap is disabled, and it happens quite a bit with swap enabled <ieure>ulfvonbelow, It means the ALSA device. Whatever userspace program is sending it audio data is sending it too slowly, so the buffer underruns, but the audio device is still turned on and you get a skipping sound because it's still playing whatever's in the audio buffer, but userspace isn't putting new audio data in. <ulfvonbelow>and presumably the userspace program in question is pulseaudio, then? <ulfvonbelow>I've also noticed that the frequency of these audio issues increases greatly with disk activity - for example if I'm copying a big file over the local network. <ulfvonbelow>but then again it only seems to happen with mpv, so it might just be some implementation quirk in it? <ulfvonbelow>well, I guess there was a time where I tried using mplayer and something similar happened <ieure>Yes, if your system is starved for IO, you can't read the files off disk (or wherever) fast enough to put in the audio buffer. <ulfvonbelow>we're talking reading a 150MB file over the course of tens of minutes, that would have to be some pretty severe starvation <jpoiret>janneke: I think it might be the fault of the union-build-system or w/e <jpoiret>the symlink does exist in the cross toolchain, but is pointing to hurd-core-headers-cross-i586-pc-gnu-0.9.git20230520/include/mach/machine <jpoiret>maybe we can manually copy the symlink without fully resolving it (which I'm guessing is happening) <janneke>although, i still think glibc should also create that symlink <janneke>(in fact, with my patch, now it does create the symlink) <jpoiret>yeah but how do you determine the name of the target? it might be fragile wrt. Makefile changes <jpoiret>and also for when we want to support x86_64 <janneke>yeah, i've hardcoded "i368", but i was imagining a (match (or (%current-target-system) (%current-system)) ("i586-gnu" "i386") ("x86_64-gnu" "x64_64")) or something <jpoiret>we can pass create-all-directories? #t to union-build in the toolchain package to preserve the directory structure. <jpoiret>ehm, actually not, it'd be the exact same problem, ehhh. We'd need to copy the symlink itself exactly, but stat doesn't let us discriminate on that <janneke>build of /gnu/store/whlnhq9aqiw2ybhahlzd74k1cnnp6h45-binutils-mesboot0-2.20.1a.drv failed <janneke>ERROR: In procedure open-file: No such file or directory: "po/SRC-POTFILES" <janneke>it says what it does, but there's no why, right? <jpoiret>janneke: we'll probably have the same issue with native builds down the line, right? <jpoiret>so it might be a patch we want to apply to glibc <jpoiret>TIL emacs in diff-mode can reverse diffs with C-c C-r <yewscion>Hello Guix, this might be a bit off-topic (sorry!) but I was wondering if anyone had figured out a reliable way to work around Automake checking for info_TEXINFOS members' existence before any other rules are run, to accomodate generated *.texi files (in this case, from an org mode export). <yewscion>As it stands, if I specify the .texi file in info_TEXINFOS, then autoreconf will error complaining that the .texi file does not exist, since that check occurs before any rules are run. <yewscion>I could just compile it manually, but I can't find the actual process which is followed anywhere for building and installing the info files in order to write my own identical rules. <yewscion>(And I'd rather keep everything as standard as possible, rather than go fully ad-hoc with just a makeinfo/install-info call. <lilyp>yewscion: have you tried BUILT_SOURCES? <lilyp>If not, you can try copying what Guix does <yewscion>lilyp: I have not, but I'll look it up now! <yewscion>lilyp: Also, that is a good call, looking at how Guix handles it might be the best fallback, and then trying to emulate that in the Makefile. <janneke>hmm, the binutils-mesboot0 seems to have been a stray failure, it now built for me <rekado>apteryx: I keep building things in M-x shell. It mostly works fine, though sometimes I need to run M-x comint-truncate-buffer to make it go fast again. <rekado>it’s especially bad with the bazel-build-system (in guix-science), because that outputs *a lot* of stuff <apteryx>oh, about bazel, I have a forgotten branch where it was mostly bootstrapping, albeit using its bundled libs <apteryx>we'd just have to package extra stuff to have a clean bootstrap, I think <apteryx>it was based on what debian is doing, IIRC <apteryx>if you are interested I could push it somewhere <rekado>guix-science has two bazel packages. We’d need more Java packages to replace those that bazel includes. <jpoiret>i've stopped using a terminal, i mostly use eshell and then EAT for the times I need lots of scrolling text <mwette>Does anyone use tramp in emacs to access files on a remote guix system? I get: couldn't find a proper `ls' command <apteryx>mwette: works for me, with /ssh:host: <podiki>mwette: are you ssh-ing from a non Guix system? <podiki>we have some changes in emacs to deal with tramp and paths for guix, maybe that is needed? <rekado>jpoiret: what’s EAT? (Or is it just emphatic ingestion of food in defiance of scrolling text?) <podiki>been meaning to try it, hear good things <jpoiret>podiki: once you get used to C-c C-e to get usual emacs keybindings and C-c C-j to get back the nice semi-char mode it's really good <podiki>i just occasionally use shell or eshell or ...ansi-term? but get confused over different muscle memory <podiki>between emacs and my usual terminal <podiki>(e.g. C-p will give me previous command in a terminal but go up a line in eshell) <mwette>podiki: thanks -- I'll check that over <mwette>I am ssh'ing from a Ubuntu system <jpoiret>podiki: yeah, with EAT you get the usual terminal keybindings except for C-c <podiki>jpoiret: sounds good. as i've said, heard good things, just got lost in all my tabs to check out :) <podiki>look forward to my next yak shaving session! <janneke>jpoiret: it still eludes me how one (debian?) could build glibc without knowing for which platform it's being built? <janneke>we can of course just "do our thing", but iwnbn if such stuff could be fixed upstream <jpoiret>it's not debian here I think, more that the Hurd people wanted a way to cross compile and just went with one solution <bienjensu>Does anyone who uses ConTeXt on guix let me know what their workflow is? I can't seem to get any of the usual tools to work, and texexec doesn't seem to be packaged. <rekado>does anyone here use M-x build-farm with ci.guix.gnu.org? I seem to only get “Wrong type argument: stringp, nil” <redacted>The "surf" browser is slow for me, and I've heard that building webkit from source might fix that. Is there a way I can build one dependency from source, but use substitutes for the rest? <rekado>we’re building webkit from source. <rekado>you can replace our webkit with a modified package via --with-input <rekado>I suggest looking at the definition of the webkitgtk package to come up with a modified variant that suits you better <lilyp>For the record, compiling webkitgtk out of all packages in our list from source is probably not the wisest idea (~10h build time) <redacted>I think I don't know enough about what I'd be doing to justify that effort <jackhill>redacted: I would be interesting to know how surf compares to other webkit browsers like epiphany (a.k.a. GNOME web) <redacted>good question. I should check before blaming webkit <jackhill>lilyp: hehe, but compared to icecat and ungoogled-chromium it's an easy compile <lilyp>And then you have genius ideas like gjs being based on spidermonkey anyway :) <jpoiret>do not utter the name gjs ever again