IRC channel logs


back to list of logs

<jaeme>Can a committer for Rust please look at my patches for rust library/binary crates? None of them have been looked at for some time.
<jaeme>I don't want to write any more package definitions for Rust for the time being right now.
<apteryx>mirai: 1h30 o.O
<mirai>yeah, writing the log for 3/4 in #66935 wasn't fun
<peanuts>"[PATCH 0/4] Dovecot service refactor."
<KE0VVT>Seems to be stalled at `guix system: bootloader successfully installed on '(/dev/sda)'`.
<podiki>python depends on libx11??
<podiki>sneek: later tell apteryx I didn't realize ungrafting libx11 means rebuilding python and thus basically everything. should I not ungraft on mesa-updates then? or just fold it all into core-updates instead?
<sneek>Will do.
<podiki>sneek: later tell apteryx that means nghttp2 and curl get rebuilt and should be ungrafted at the same time too. ...which I guess makes it core-updates then. what do you think?
<sneek>Got it.
<ieure>I want to package some fonts, but the download link for them produces a different hash every time. Is it possible to make a Guix package for them in this situation?
<ieure>The license allows for gratis personal use, but they aren't Free. I could download one copy and rehost it, but the license prohibits redistribution. So this would violate the license, but downloading directly fails because of the different hash.
<adanska>hey guys, im trying to add a file system to my setup, a simple exfat partition that im to share between my windows and guix install. how should i set its mount point? i dont know if i can simply just set it to /mnt or /media because then it will just take over the entire directory. how do i make it mount on a directory that has yet to be created?
<adanska>if that makes sense
<adanska>i want mkdir -p type behaviour
<adanska>is there a way to just get it to mount to a /media directory automatically like an external drive would
<sundbry>adanska: Use `create-mount-point? #t` on the (file-system) config
<peanuts>"File Systems (GNU Guix Reference Manual)"
<sundbry>ieure: You are probably SOL with that use case
<adanska>sundbry: Doh! thank you so much! eyes must have glazed over when looking at that haha
<sirmacik>hi \o
<tux1c>is anybody else having troubles with emacs-guix? whenever it tries to start the REPL I get:
<tux1c> geiser-repl--start-scheme: Couldn’t start Geiser: (wrong-type-argument stringp nil)
<lilyp>ieure even if you do find a solution that works for you, you can't well upstream it to guix :)
<sarg>hi guix, it seems that with-commit transformation doesn't preserve patches. Is that expected?
<sarg>looking at `transform-package-source-commit` it just replaces `package-source` with an explicit `git-checkout`:
<peanuts>"transformations.scm\guix - guix.git - GNU Guix and GNU Guix System"
<jpoiret>sarg: yes, that's the case for with-branch as well
<jpoiret>it's not documented but i guess the rationale is: if you're changing versions, you might want to use new patches with it as well
<futurile>out of curiousity, do you still have access to the patches, so can you alter the phases to reapply them?
<sarg>patches go to the `package-source`, not in the phases. I've made a workaround by explicitly defining the packages:
<peanuts>"dotfiles/guix/telega-next.scm at master ? sarg/dotfiles ? GitHub"
<jpoiret>you can do --with-commit=... --with-patch=original-patch1 --with-patch=original-patch2 ...
<janneke>rekado: istm that mumi fails to show the second patch/attachment here:
<peanuts>"Wrong glibc-utf8-locales package used on GNU/Hurd"
<sarg>jpoiret, sure, but for that I have to checkout guix repo, where the patches reside.
<jpoiret>you don't need to check it out, just see what the list of patches is
<jpoiret>the patches should reside in ~/.config/guix/current/share/guile/site/3.0/gnu/packages/patches/ if you need the path (but i think just the names are enough?)
<sarg>jpoiret: transform-package-patches runs `local-file` on the input parameters
<jpoiret>ah, mb then
<sarg>maybe guix needs `--with-preserve-patches=package`? I think the default use-case for `--with-commit` is to try out the bleeding age quickly. It implies to apply the previous patches (at least ones which weren't merged upstream).
<nckx>So having a long --do-what-i-asked option makes little sense, it should just not nuke the patches.
<nckx>ieure: I'm having trouble coming up with a solution. It seems risky to use these fonts without unintentionally violating the licence (which is their intention). Do you know why the hash differs? Metadata? To track users?
<nckx>Assuming the extracted font file(s) are bit-identical, you could write 'host-side' code that downloads & unpacks the fonts to a cache directory, then returns a package that takes those as local-file source. Yuck.
<nckx>That's not a good solution but it's a solution.
<mirai>Is Hartmut Goebel on this irc channel?
<nckx>Kind of: last in August of this year (as htgoebel).
<rekado>janneke: it appears as an attachment. I don’t know why.
<rekado>janneke: the patch is probably too big
<rekado>when the size of the body is >= 5000 it just links the mime part as an attachment
<mekeor>when transforming packages via cli, can i specify a package from my current user profile? --with-input=foo=$FOO_FROM_MY_USER_PROFILE
<mekeor>would be nice if i could pass a store-path :D
<mekeor>but i just realized i don't need this; thanks anyway :)
<futurile>Q: Has the idea of creating additional tests for packages been discussed in the past? Guix is already extensively tested, but there are no 'distribution' package tests right?
<futurile>(I'm reading guix-devel and Felix Lechner's mention of the idea when discussing Cargo tests)
<janneke>rekado: ah yeah -- missed that
<mirai>nckx: thanks
<futurile>ah found it
<nckx>futurile: As in, per-package tests, but written by us? The only ones I'm aware of are when upstream provides no tests at all, so we add a 'test' phase that tests something simple, or even trivial like 'make sure that foo --help runs'.
<nckx>(I didn't read that thread.)
<nckx>We do have 'system tests' but that doesn't seem to be what you mean.
<mirai>I've suggested coupling some of the system tests to the packages in the past here
<futurile>yeah I see ideas about running 'per package' tests - it's come up a couple of times this year. In part because tests are taking a long time in builds (Efraims Crate thread), and separately people looking for more comprehensive package testing.
<sarg>it's been a long time since I hacked on guix. I've updated tdlib package in my local checkout, now trying `./pre-inst-env guix build tdlib` and it just returns me the current version from `/gnu/store` w/o building anything`. What do I miss?
<mirai>sarg: perhaps you're not using (… git-file-name …) if this is a git checkout?
<mirai>by git checkout I mean the package source
<sarg>no, I've meant guix checkout, not tdlib checkout. I'm just bumping the version of a package
<mirai>is tdlib using url-fetch or is it git-fetch
<mirai>do you have a line that goes like (file-name (git-file-name name version)) ?
<sarg>yes, it's there
<mirai>are you bumping version or is this a particular commit
<sarg>both. The upstream doesn't tag releases anymore. I've changed the version and the commit in the package definition
<efraim>have you run bootstrap and configure?
<sarg>yeah, and then `make clean` and `make make-go`
<sarg>oh, there is no `scripts/guix` file, which means that the profile one is used. I probably need to run full build with `make`
<mirai>what about (git-file-name name commit)
<sarg>no, that isn't the case. The cause was that I hadn't run `make`, so my profile's guix was running
<sarg>after `make guile scripts/guix` it works as expected
<sarg>I don't run full `make`, because it's too long and does unnecessary things like building all the documentation
<Altadil>Is there documentation on how to close an issue ? I couldn’t find it in the manual. :/
<nckx>Send mail to
<Altadil>nckx: thanks!
<civodul>is Wilko around? looks like there are hash mismatches for the Linux tarball on ‘kernel-updates’:
<sarg>how about this sanity-check in `pre-inst-env`?
<Andronikos>I use the "home-files-service-type" for moving my file to the $HOME dir. Basically, I thought I could use guix home instead of manually symlinking the files. But it can't be executed since permission is denid. The symlinked file will be in the store with root:root permissions. Does that mean I still need to do it manually?
<Andronikos>I also did the same with a ".xinitrc" file which doesn't even let me run guix home reconfigure. It says .xinitrc is a invalid file. I don't know why.
<voroskoi>Andronikos: see my river/init here:
<peanuts>"~voroskoi/dotfiles.guix: home-configuration.scm - sourcehut git"
<voroskoi>this is how You preserve the +x state of the file, the name is a bit misleading, but works
<ieure>nckx, extracted two archives and the fonts themselves aren't bit-identical, but they only differ by ~6 bytes; it doesn't seem like enough to be a fingerprint. I suspect that the whole font archive is getting created on demand and something in that process gives non-bit-identical results.
<ieure>lilyp, Agreed, I wouldn't be upstreaming these, just using them personally.
<Andronikos>voroskoi: Thanks! It worked. I would add to the manual, since as a beginner that read the manual, there was no chance I could have known that.
<voroskoi>Andronikos: it is documented here:
<peanuts>"G-Expressions (GNU Guix Reference Manual)"
<voroskoi>telling the truth I did not find it either, the meaning of G-Expression is also a bit foggy for me
<Andronikos>voroskoi: Yep, my idea would be a hint to this documentation. I have read the local-file docs but I didn't remember that permission bit for recursive.
<Andronikos>Sometimes I have this problem: "guix home reconfigure home.scm" returns "guix home: error: failed to load 'home.scm': No such file or directory" but "ls" returns that home.scm file
<Andronikos>Ah, I think it is a problem with Emacs, which automatically creates my vterm or eshell buffer in that directory. I created one again but in $HOME and used cd to go in this directory. Now it works.
<Andronikos> now I need to understand why this is happening. Btw, does .xinitrc even require +x?
<peanuts>"debian Pastezone"
<voroskoi>Andronikos: AFIK .xinitrc does not require +x
<voroskoi>regarding Your error: try to rename the file in local-file and make sure the path is relative to the script, not the calling point
<lilyp>ieure you could do a computed origin in which you blank those bytes
<ieure>lilyp, Have a link/reference/docs for that?
<nckx>IceCat uses one.
<lilyp>sadly no, computed origins are ad-hoc
<nckx>I don't think it's {well,at all} documented.
<lilyp>icecat and linux-libre may serve as examples
<ieure>Okay, thanks.
<nckx>(281474976710656 permutations is more than enough for a fingerprint. I'm just being paranoid, but why would they waste their server resources like this?)
<futurile>Yay Efraim accepted my Librespot/Spotifyd packages - just checked, started working on them January 28th - whoop!
<futurile>{yes, I am congratulating myself I know heh}
<ieure>You can configure various things about the font, like the glyph used for a, g, i, l, 0, etc. So downloads have to do some sort of build process. I'm guessing that something in that isn't reproduceable, like maybe it has the current time or something embedded in the font.
<nckx>Ah. I might even know which font this is.
<ieure>It's Input Mono, but I've seen this with several programming fonts.
<nckx>Yep, but that's the one.
<ieure>It's a real good one.
<nckx>I stick to Hack out of habit, but yes.
<nckx>Anyway, yes, I think Lily's computed-origin suggestion is the best solution here, and it's underdocumented so you get free fun.
<sarg>dear guix committers, if you have a spare minute, please merge a couple version bumps:
<peanuts>"[PATCH 1/2] gnu: tdlib: Update to 1.8.20."
<Andronikos>voroskoi: Thanks it worked. I just called it xinitrc instead of .xinitrc. Though it kinda triggers me, that I don't understand why the dot is an issue for local-file
<nckx>It's a store file name restriction that the daemon inherits from Nix. I don't think there's a good reason.
<civodul>agreed, but it’s “set in stone”
<civodul>‘local-file’ could error out early on though
<Andronikos>Ah good to know. Thanks for the information. Now I feel better.
<nckx>civodul: Why is it set in stone?
<nckx>local-file (or even something lower-level) could strip the '.'. I'm not aware of a contract about exact store item naming.
<lilyp>well, '.' is not the only invalid character that we might want to sanitize; I think a warning might be better than trying to be smart
<KE0VVT>How do I get swaylock-effects added to %setuid-programs?
<lilyp>instead of the percentage variable, use the operating-system field (sans percentage)
<exorcista>hello to all humans out there on the planet and in space
<exorcista>Î tried to install guix, I only run in secure boot mode
<exorcista>the system doesn't start :(
<exorcista>how can I launch ubix system in secure boot mode?
<lilyp>I don't think we have the signed shims that are required to do "secure" boot
<ieure>Does someone have a good example of a package which users trivial-build-system? I want to make a package for some weirdware with an uncommon build system, and I'm not sure how to make this work.
<ieure>Software is this thing:
<ieure>It has a build/unix/Makefile, install is roughly `make -C build/unix/Makefile all install`
<exorcista>lilyp, what is required to sign the shims?
<exorcista>Microsoft is obligued to provide those
<exorcista>every distro has them
<exorcista>why not guix?
<ieure>Probably because it can't be reproduced by an end-user.
<ieure>It'd be nice if Guix let you deploy your own keys and sign the shim with them.
<rekado>ieure: I don’t use the trivial-build-system. It’s easier to start with the gnu-build-system and replace or delete phases.
<lilyp>yeah, trivial-build-system is rarely what you want; it has mostly been obsoleted by copy-build-system to copy files as-is
<podiki>sneek: later tell janneke for skipping a test in curl/fixed for hurd, is there a reason the test number wasn't added to test/data/disabled like the others? (working on ungraft)
<ieure>Hmm. This is my current iteration of the recipe: -- but it bombs with `make: *** build/unix: No such file or directory. Stop.`
<peanuts>"debian Pastezone"
<ieure>This works fine if I unpack the archive and run the command in the dir that makes -- do I have to manually set the CWD in the recipe or something?
<podiki>sneek: late tell janneke oh, I guess the ~ (run but don't use output) doesn't work in tests/data/DISABLED?
<sneek>janneke, podiki says: oh, I guess the ~ (run but don't use output) doesn't work in tests/data/DISABLED?
<podiki>sneek: later tell janneke oh, I guess the ~ (run but don't use output) doesn't work in tests/data/DISABLED? (sorry if sneek did this twice)
<sneek>Got it.
<civodul>ungrafting, when?
<exorcista>what do you guys think about chromium ungoogled?
<ieure>I refuse to use any Chrome/Chromium-derived browser. Even the ungoogled stuff helps their strategy of taking over the open internet.
<Andronikos>exorcista: Can you be more precise?
<exorcista>I mean, what is your opinion about it, and if you think some other is better what is that browser then
<Andronikos>ieure: You don't need gcc-toolchain as native-input since this is indirectly understood by using the gnu-build-system
<Andronikos>exorcista: Ah okay. Well, it is Googles approach to control the Internet. It was initially good but I switched to Firefox. It has better developer tools as well.
<exorcista>but firefox also has google stuff attached to it.. :(
<exorcista>for example, if you switch to diferent search engine, it still opens tcp conections to google
<exorcista>even if the site has nothing todo with google..
<exorcista>do a 'lsof -i' and you will see
<Andronikos>Yes, but a little bit is better than nothing.
<exorcista>is there a Firefox ungoogled?
<Andronikos>Well, I guess IceCat. Firefox is not free as in freedom. IceCat is.
<podiki>civodul: live and in-person! ...meaning i'm doing it locally
<podiki>civodul: i didn't realize libx11 touches nearly everything (via python); so now i'm locally ungrafting nghttp2 and curl as well; i'll see what apteryx wants to do on core-updates or not
<Andronikos>I just wish that we could install extensions like for ungoogled-chromium via Guix. That is an awesome feature and makes it easer to have "dotfiles" for a browser.
<podiki>ACTION finds out we didn't enable parallel test on curl...that's a huge speed up!
<ieure>exorcista, I use as my daily-driver browser, it strips out a lot of the trash that's in Firefox.
<ieure>The connections it makes to Google are probably search suggestions or the safe browsing list.
<ieure>You can disable those, even in Firefox, but it's annoying to deal with all the junk it ships these days.
<ieure>I don't believe there's a Guix package for LibreWolf. I'm not daily-driving Guix yet.
<podiki>civodul: I think the difference will be the glibc graft, as locally i did libx11, libxpm, nghttp2, and now curl; i might just submit this to mesa-updates anyway even though it has grown in scope
<exorcista>disabling search sugestions doesn't help, firefox still does does conections...even without any page open!you start it..and that it :(
<exorcista>maybe there are a way to disable those conections, but I never found a way todo so
<exorcista>maybe in about:config or something like that
<podiki>you could look into some of the user.js out there with defaults for hardening
<podiki>betterfox, arkenfox user.js (i haven't tried but it is on my list)
<exorcista>icecat from gnu is still maintained?
<Andronikos>ieure: The build system will switch the directory. Maybe is that the issue?
<Andronikos>exorcista: Don't know if it is actually maintained but there are quite behind. AFAIK it is not that easy to clean it.
<ieure>Andronikos, How would I tell what the CWD of the build process is when it invokes make?
<mekeor>exorcista: last commit 13 days ago:
<peanuts>"gnuzilla.git - GNUzilla and IceCat"
<ieure>Whatever CWD is, it's not the root of the tarball, because `build/unix` exists in there, and the error is that it doesn't.
<mekeor>Andronikos: afaik, ublock origin for ungoogled-chromium is packaged in guix
<mekeor>PRs for other extensions are welcome :D
<mekeor>*patches, whatever :)
<Andronikos>ieure: Ah I don't find it but somewhere in the manuals it mentions that the build process creates a new directory and sets that.
<Andronikos>ieure: Run the build command again with -K which means it should keep the directory. Then you can investigate with the exact environemtn variables as the daemon. I look for the manuals. Somewhere they showed the process.
<podiki>ieure: right, you may need (chdir "somewhere") for instance, where as mentioned you can see the directory structure in /tmp/guix... after using -K
<ieure>Okay, so, that gives me: `note: keeping build directory `/tmp/guix-build-toolshed-2.2.drv-1'`
<ieure>And in there, environment-variables has: export PWD="/tmp/guix-build-toolshed-2.2.drv-0/toolshed-2.2"
<ieure>Which is correct
<ieure>ls -l /tmp/guix-build-toolshed-2.2.drv-0/toolshed-2.2/build/unix/Makefile
<ieure>-rw-r--r-- 1 ieure users 983 Sep 9 2017 /tmp/guix-build-toolshed-2.2.drv-0/toolshed-2.2/build/unix/Makefile
<ieure>So like. what gives
<podiki>what is the exact error message?
<Altadil>exorcista: I know it’s a bit extreme, but there is also the option of Tor Browser. It is based on Firefox, but I trust they have cleaned it well. :)
<peanuts>"debian Pastezone"
<Andronikos>mekeor: I know. That is what I mean. It is for ungoogled-chromium but not yet for IceCat
<ieure>Andronikos, ublock-origin-icecat exists.
<podiki>ieure: this is with gnu-build-system?
<ieure>podiki, Yes, the recipe is here:
<peanuts>"debian Pastezone"
<Andronikos>Ah okay. "guix search ublock" only shows the ungoogled-chromium package. Nice that means it got figured out how we can do it.
<ieure>Andronikos, Maybe your Guix is out of date? Shows up in search for me.
<Andronikos>Ah you only want that target I understand
<Andronikos>I can't really find it but the build system creates a new directory and switches to that and runs the default commands. That is your problem since you don't expect that if I understand it correctly.
<podiki>ieure: maybe try without the -C flag and doing an explicit (chdir "build/unix") in a phase before build? or maybe see what the default make-flags are in gnu-build-system maybe there is a conflict?
<ieure>podiki, I suppose, but that makes no sense at all. The gnu-build-system runs typical ./configure && make && make install type things. Those only work if PWD is correct. Obviously this thing works for other packages, so like... can that possibly be the problem? Seems way unlikely.
<ieure>And the environment-variables shows the PWD is correct! So like. what the heck
<podiki>well just from experience I never did a -C but have used chdir; just a guess
<Andronikos>ieure: Yes my Guix is outdated.
<exorcista>mekeor,peanuts, many thanks
<Andronikos>ieure: Here: this should help. With that you can simulate what the daemon does and better find out the issue. Pretty sure it is the path because the default behaviour changes it.
<peanuts>"GNU Guix Reference Manual"
<Andronikos>I had the issue in the past as well. Sometimes it creates troubles. Though maybe it is something else and not what I think. But just do that and you know exactly why it is not working.
<podiki>more current manual:
<peanuts>"Debugging Build Failures (GNU Guix Reference Manual)"
<podiki>(note the "devel" and yes this really needs to be the default)
<ieure>Andronikos, When I do that, the build works.
<Andronikos>You cded in to build/unix and run make?
<ieure>Okay, no, hold up. I cd into the source directory from the unpack and run `make -j12 -C build/unix CC=gcc` (just like the build daemon does) and it works.
<ieure>But $PWD is /tmp/guix-build-toolshed-2.2.drv-0/toolshed-2.2
<ieure>And the source dir is /tmp/guix-build-toolshed-2.2.drv-0/toolshed-2.2/toolshed-2.2
<ieure>Okay, I'm sorry, I'm getting confused here. That is not accurate.
<ieure>Let me paste a log here, one sec.
<podiki>oh your source unpack is toolshed-2.2/toolshed-2.2?
<podiki>a (short) tree of /temp/guix-build... would be helpful
<ieure>Okay, here's an extensive build log:
<peanuts>"debian Pastezone"
<ieure>The builder fails, but when I run the same command from the same PWD as the build, it works.
<ieure>It really shouldn't be this hard to run make.
<ieure>what the fuck
<ieure>-bash: cd: /homeless-shelter: No such file or directory
<ieure>what on earth
<ieure>Oh, it's because I sourced those env vars and they wrecked my session. okay
<podiki>you should follow the manual about using guix shell -C if you want to have the build environemnt
<podiki>otherwise it could be something from your normal environment; though I agree i don't get it here
<ieure>So hold on, your theory of why the builder fails to build my package is that something in my normal environment is breaking it?
<podiki>try instead of "-C build/unix" to have "-C" "build/unix" (split the string
<ieure>oh jesus
<ieure>You're 100% going to be right.
<podiki>i've done this same mistake...
<podiki>how many times....likewise with messing up apply and invoke and how they do arguments
<ieure>Yeah, that works. Thanks for the pointer, I definitely should have known that.
<podiki>i _did_ know that and still missed it
<podiki>on the plus side I got curl to build and test in 2 minutes rather than I would guess ~30 minutes (yay for parallel tests)
<Andronikos>Ah. Didn't know that. It is like with the invoke command where everything needs to be quoted. Okay learned something new.
<Andronikos>Though it still does not build for me
<ieure>I have other issues to address.
<Andronikos>Yep, fuse.h is missing
<ieure>But also: this thing includes like six libraries, 15+ binaries, dozens of scripts, and documentation, and I need to figure out how to split all that stuff up.
<Andronikos>You mean multiple outputs?
<ieure>Well, I think?
<ieure>Can I express that one output (say, a binary) has a runtime dependency on another output (a library?)
<podiki>i wouldn't worry about outputs yet, just getting what you want built first
<podiki>outputs is just splitting up the various files at the end, still one build
<Andronikos>Do "guix edit gtk" it is basically definined three outputs and splitting them up at the end like podiki said.
<Andronikos>But this is not a must, only if the size does actually matter
<Andronikos>use "guix size" to see
<podiki>yes. but really all easier details than getting something built usually :)
<Andronikos>Yep. First things first which means get it to work.
<ieure>Fair enough, though I'll eventually want to solve that. For example, this thing bundles a FUSE filesystem, but also CLI utils. The CLI utils should be usable on non-Linux systems which don't have fuse.
<Andronikos>I assume you want to delete the CLI utils. There is the (delete-file-recursively dir) function. Do that in the snippets or in the phases
<ieure>I do not want that.
<rekado>I’m having some problems with shepherd on my rockpro64 aarch64 machine
<rekado>at some point “herd” will block and I can’t talk to shepherd any more
<rekado>(the machine is in this state right now)
<rekado>this means I can’t reconfigure or reboot it gracefully
<Andronikos>ieure: Oh, I missunderstood. Anyway with that you can delete whole dirs. It is like rm -rf
<rekado>the second independent problem is that halt/reboot doesn’t work. When I’m connected via SSH “reboot” will kill the SSH connection, but the mingetty process keeps running.
<ieure>Andronikos, I don't want to delete anything. There are "my personal needs," but also "how do I package things correctly" and I'd prefer to do things correctly than just what satisfies my needs. That means splitting this up so it produces reasonable outputs, but also, allowing the CLI tools & libs to be built on systems which support those, and the FUSE thing on the systems which support that.
<Andronikos>rekado: This is not the issue I had in the past since there was no RTC on the system?
<ieure>I suspect that means I need two packages which use the same source. Or something? idk
<rekado>Andronikos: it doesn’t have a RTC; I’m setting the time via NTP on boot.
<ieure>Okay, I have run out of time and patience to struggle with this any further for now. I will be back, though.
<Andronikos>rekado: Is one core fully 100% utilized?
<Andronikos>ieure: There is a something like if system arch or x86 do this specific steps. You will always have that one package.
<rekado>Andronikos: no.
<Andronikos>rekado: I had an issue with my RPI4 which doesn't had a RTC and since guile-fibers had an issue, it tried to catch up from 1970 to 2023.
<rekado>I wonder if my custom shepherd service is at fault
<Andronikos>rekado: Okay, it is not that bug
<rekado>its command line is a “guix shell” command and CPU utilization is unusually high for what it is.
<rekado>the service is running, though.
<rekado>(it is a little local web server)
<civodul>rekado: are you hitting ?
<peanuts>"High CPU usage on system time change ? Issue #89 ? wingo/fibers ? GitHub"
<Andronikos>Ah civodul was faster than me. Yea that is the thing I thought. But he doesn't have the 100% core utilization.
<Andronikos>Which version of Guix is running on the SBC? This should be fixed.
<rekado>I used “guix deploy” with 5cbb0b15cce1cb9977dec29594c4b34aee3ddd2b on the deploying host
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<rekado>is there something I can do to help debug this?
<rekado>attach to pid 1 and snoop around?
<Andronikos>Definitly not that time bug with guile-fibers. At this point it is to much for me.
<rekado>(I rebooted the machine three times in the last few hours; shepherd became unresponsive each time, but I didn’t check how long it took.)