IRC channel logs
2026-02-17.log
back to list of logs
<Kolev>>Your Guix installation is 205 days old. <Kolev>Guix pull doesn't work, because I'm 100% full on / even after doing `guix gc`. <ekaitz>Kolev: did you delete-generations? <Kolev>No. `guix delete-generations`? <Kolev>Oh, `guix gc --delete-generations`. <ekaitz>and guix package --delete-generations <acidbong>are repo admins able to gc the repo on Codeberg or only Codeberg admins? it used to be under 600 MB last month and only increased tenfold since <ekaitz>sneek: later tell janneke tcc-boot0 also fails for me <Kolev>When should I give up on `substitute:` lasting for minutes? <apteryx>janneke: the latest qemu we have is 10.2.0 <apteryx>podiki: info "(guix) Build Systems" works here <podiki>it was the capitalization that got me (not guix, but both build and systems) <apteryx>efraim: 77192e834b81cc6622ce755fd7e515528d278dbc (gnu: icedtea-8: Fix building.) disabled parallel builds for the bootstrap java packages; is it really needed? And why not use #:parallel-build? #f instead of a custom build phase? <apteryx>efraim: ah! /tmp/guix-build-icedtea-3.19.0.drv-0/icedtea-2.6.13/openjdk-boot//make/Main.gmk:80: *** make -j is not supported, use make JOBS=n. Stop. <apteryx>oh, and that does not mean that parallel build is disabled, interesting <PotentialUser-38>Has anyone made an article/video/blog about setting up emacs with geiser for guix development? Tried following the steps in the manual but I couldnt really get it to work. <ieure>PotentialUser-38, What didn't work? I use Geiser in Emacs regularly to hack on Guix. <ieure>I didn't follow `(guix)The Perfect Setup', but I already had most of what it wanted in my setup, just had to add the Geiser packages. <PotentialUser-38>ieure well i added the package, accepted all .dir-locals started the repl, hovered the cursor over a keyword (say a build system) and ran geiser-edit-symbol-at-point as a test and it couldnt find it. Im pretty sure im missing a big step but I didnt see anywhere exactly what <folaht>futurile, Well, considering that I don't understand what Rutherther was talking about, I'm still stuck with the flatpak issue. I'm also questioning myself which proprietary software package manager I should use. There's nix, flatpak and nonguix. I'm going for flatpak at the moment because that's the one I know. <folaht>And I'm watching the System Crafters introduction video <folaht>Guix looks very promising, but currently I feel restricted for now because of the flatpak issue and the next issues I want to solve once I have the flatpak issue solved. <Rutherther>folaht: just put (simple-service 'flatpak-profile-d etc-profile-d-service-type (list flatpak)) to your services <Rutherther>And feel free to ask for a clarification if you dont understand something I say <Rutherther>If you installed via the tui installer, it is at /etc/config.scm. It is how you configure everything system related on Guix System <folaht>Yes I am. I'm just completely unfamiliar with guix. So far I just was happy with being able to run icecat and visit my favorite sites. Alright, I found the config.scm file. I'm gonna try and edit it. <Rutherther>Example: On other distros you modify /etc/ssh/sshd_config to configure ssh server. On Guix System you modify openssh-service-type in your system configuration and apply the confoguration <Rutherther>After you edit it you need to apply it. Thats done with "guix system reconfigure /etc/config.scm". Then if that succeeds you will need to relog due to the specific change <Rutherther>Also maybe its not clear, you need to run guix system reconfigure with sudo as it modifies system files <folaht>I feel like this distro decided that you need configs so that if your system crashes, you can return things to normal, which is awesome, because I've had a particular issue with Manjaro due to some very unusual way I try to setup things. <folaht>Well, one particular thing and I hope guix will solve this issue. <folaht>But I'll need to solve all the other issues before I can work on that. <folaht>I do have one question though: I see a lot of emacs love in guix. I never used emacs and I have fallen in love with vim. So what's quix take on vim? <folaht>What happens if my edited config.scm is faulty and I restart my computer? <Rutherther>Nothing. The config has to be applied manually so that the change has effect <Rutherther>No, it is not correct, this is a syntax error. Put it inside of the list above, like after the cups service type <sunless>i have an emacs problem with "aspell-dict-en", when i use "guix home" to install it, the dictionaries can't be found, but when i use "guix install" it's found ... so how do i configure emacs to find the dictionaries from "aspell-dict-en" installed by "guix home"? <efraim>apteryx: do you still have a question about icedtea-8? Looking at my commits there it looks like I was fixing building it on powerpc-linux <janneke>sneek: later tell yelninei: your suggestion worked, proper fix pushed to master, workaround reverted again <sneek>janneke, you have 1 message! <sneek>janneke, ekaitz says: tcc-boot0 also fails for me <efraim>sneek: later tell ekaitz it is a shame about non-inclusive language in the Spanish translation. I remember we once had someone come in an complain about the inclusive language there and said it was off-putting for them. My wife and I still joke about needing "manly-man" translations and things <efraim>janneke: re make-bootstrap, as a style thing, I sometimes use string-join instead of string-append so I don't need to worry about where to put the extra spaces <janneke>efraim: noted; the make-bootstrap fix was reverted again <efraim>oh, I hadn't gotten to that commit yet :) <janneke>or rather, the make-bootstrap workaround was reverted after making the proper fix :) <efraim>ugh I forgot that mes-boot0 can take 3 days on riscv64 <rustyguix>efraim: is there rough estimate on the expected date to merge rust-team into master? <efraim>rustyguix: the rust-team merge is after the gnome-team, so hopefully very soon <rustyguix>efraim: Thanks! In guix land, does "very soon" mean just a few days? <rustyguix>Sorry, I am super new to the guix ecosystem! <efraim>I'd assume by the end of the month. the gnome-team is currently stuck with a build error on one of the bordeaux build-farm machines so rust-team might jump over them or we might be stuck until they can unstick themselves <efraim>both branches include a rust rebuild though, so there will probably be a gap between applying them <efraim>hmm, I don't think the qt-build-system passes on the build-type flag <yelninei>janneke: Thanks a lot. For some reason guile-static@2.0 compiles without error even though it should have the same issue. Or maybe it sets an older C standard so gcc does not complain <sneek>Welcome back yelninei, you have 1 message! <sneek>yelninei, janneke says: your suggestion worked, proper fix pushed to master, workaround reverted again <rustyguix>efraim: thanks! By rust rebuild, do you mean from 1.73+ and up? <efraim>rustyguix: for x86_64 yes, for aarch64 and riscv64 from 1.54 <efraim>mrustc is almost ready to bootstrap 1.90, so that should make it better <efraim>yeah, still looking for what the error could be <efraim>I was able to run update-guix-package on gnome-team... <apteryx>efraim: no more question about icedtea, thanks for checking! <apteryx>gives something like In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): list <apteryx>the source says nobody ever succeeded or attempted that particular one ;-) <efraim>I have something similar in rust-team for disallowing references to rust:cargo <apteryx>ah, I deleted the labels, so now they must mismatch and return #f <efraim>I couldn't refer to "cargo-bootstrap" since it was really `(,rust "cargo) <apteryx>yeah, it was a label issue, "openjdk9" -> "openjdk" for the auto-generated ones <efraim>now that we have gcc-15 packaged I'm tempted to try again to add aarch64-w64-mingw32 as a supported cross-target <apteryx>what was the trick to get the current package #$version in a gexp in a way that it doesn't get backed-in for inherited variants? <apteryx>I think the trick is #$(package-version this-package) <futurile>apteryx: I'm going to post a blog post about the fundraising and send a pr to remove the fundraising banner, you want to review? <aaavigatori>I tried to install guix system on my computer with the standard (1.5) iso, however, the installer wouldn't disappear after having selected the language. After that it was just a blank, blue screen for 20min. I tried the other TTYs of which only the documentation one (F2?) worked. The other TTYs said to press enter to login, but after doing that the <aaavigatori>prompt never appeared and eventually I got the message "login timed out", still with no prompt. Any further input was not accepted (or at least it didn't seem to do anything). <Guest72>i have (service pam-limits-service-type (list (pam-limits-entry "*" 'both 'nofile 100000))) in my os config <Guest72>however it seems to not have any effect, ulimit -Hn still returns 4096, even after reboot. what am i missing? <aaavigatori>I tried to install guix system on my computer with the standard (1.5) iso, however, the installer wouldn't reappear after having selected the language. After that it was just a blank, blue screen for 20min. I tried the other TTYs of which only the documentation one (F2?) worked. The other TTYs said to press enter to login, but after doing that the <aaavigatori>prompt never appeared and eventually I got the message "login timed out", still with no prompt. Any further input was not accepted (or at least it didn't seem to do anything). <futurile>Guest72: did it add the alteration in the underlying file - look at man pam_limits if you haven't used it before. <futurile>Guest72: if it's not in there, then the service hasn't run - maybe you didn't apply it properly <Guest72>i have sometking that looks correct in gnu/store/xxxx/limits.conf <Guest72>but i do not know if it is being loaded <Guest72>the store also has old versions of the file, not sure how to check which one is active <futurile>Guest72: well if you don't want to fiddle around just reboot, since you know it's in the config etc <futurile>Guest72: hmm don't know then - if the config is in the file, then as far as Guix is concerned it's done it's part - the service is just 'writing the value' to a file' <Guest72>can i check somehow which file is being read? <futurile>Guest72: now the challenge is whether the value in teh file is correct, whether the limits.conf is actually working <futurile>Guest72: no idea honestly, I don't use pam_limits <futurile>Guest72: I would start by looking at the ArchLinux Wiki - that's where I go anyway - see if there's examples there of how the service is used. It's "standard Linux" from the point that the 'value' is in the config file. <Guest72>it does, i'm pretty sure the file is right, so the problem might be that lunix is not finding it <futurile>aaavigatori: so to be clear the screen showed just one dialog, and you scrolled down/up moved around in it to set the keyboard. Are you sure you hit the right key to move forward to the next screen? <Guest72>ok so /var/guix/profiles/system/etc/pam.d/login link to the correct limits.conf, so i guess it's a linux thing, or it's somehow getting reset in another place <aaavigatori>futurile pretty sure, yes. I tried it two times. Tho I don't think it was for selecting the language of the installer. In my VM the keyboard layout selection came later. In any case I selected "English" with the up and down arrow keys and then pressed enter. After that the next section didn't appear. Instead only the blue background was shown <futurile>aaavigatori: hmm - OK, what linux distribution are you using at the moment? <aaavigatori>futurile none ._. But I used to use Ubuntu on it in the past <futurile>aaavigatori: ok, did you use ubuntu on that hardware? <futurile>aaavigatori: confirm that's what you saw - it should just move forward a page <aaavigatori>futurile it used the standard ubuntu kernel in the past. It has an nvidia card, but nuveau used to work acceptably in the past at least. I tried to prepare a non-free kernel in a VM, but ironically, that one makes my VM hang. So I thought I'd give the linux-libre kernel a try :D <futurile>aaavigatori: are you sure you hit 'return' to move forward and you didn't hit the 'Exit' button that actually **exits** the install <futurile>aaavigatori: that page is confusing if you ask me - hitting the button is the wrong thing to do - you have to use the <return> key <futurile>aaavigatori: yeah linux-libre and your hardware is a different problem - for later I guess :-) <aaavigatori>futurile yes, the screen at 8:50 was shown, but after enter the selection window at 8:46 didn'T show up. It was just the blue background, along with the notive in the bottom left corner. If I hit Exit (Escape?), shouldn't the blue background disappear too? <aaavigatori>tbh, it might have something to do with my hardware. I tried to install Ubuntu again 5 months ago. The installer ran the entire night and when I rebooted it turned out that it didn't install anything, didn't even install the bootloader. I last ran ubuntu on it 6 years ago. My hardware is from 2011 <futurile>aaavigatori: hmm pretty odd if you can't even use the selection window. <futurile>aaavigatori: I guess you could try using virtual box on Windows, install Guix in a VM there and play around <futurile>aaavigatori: no it's just writing a value into a file, so you can go backwards and forward in the installer all you want - until the last step where you confirm "write all this to my hard drive" <aaavigatori>futurile oh I was just joking. Do you have an opinion on the other issue I described: I couldn't use the other TTYs. It said the login timed out <aaavigatori>futurile I actually set it up in a VM and the installer worked properly : ) I wanted to use it to get familiar with the system, and maybe try a different kernel, tho that one made the VM hang. Tho that's an issue for a ... different channel <futurile>aaavigatori: uck - I would try it in a VM to start. I think potentially your system isn't in a good video situation which is why you can't see the installer properly. The only the other thing I can think is that the USB/file you downloaded is corrupted. It's not doing much at the point you're in. <futurile>aaavigatori: you could try using the nonguix kernel - see if that works with your hardware - but it's so early on in the install, it's confusing why you'd have problems there <futurile>aaavigatori: sorry, not really a resolution :-( <Rutherther>aaavigatori: have you tried switching tty before the installer has gone wrong? <aaavigatori>Rutherther yes, that works. The switching action itself. It also continues to work after the installer hangs. But I can't interact with any other TTY other than the documentation one on, I think, TTY 2 <aaavigatori>Rutherther I will have to check that later, let me make a note. Is there some specific output you are looking for? <Rutherther>aaavigatori to be cleqr I did not mean just the switch, I meant to actually log in. Before the installer goes in the wrong state <Rutherther>aaavigatori: just any output, feel free to take a photo of all messages shown in tty12 and send that. <Rutherther>I expect the reason installer hangs is going to be the same reason the login hangs <Rutherther>One of the reasons I am aware of is large date/time switches. Unfortunately it hangs at least shepherd. And maybe it does even hang log in, I did not check that <Rutherther>But there should be no reason for a date jump in your scenario <aaavigatori>Rutherther I actually have a date issue on windows. Every reboot the time is offset by an hour in the past. No matter which timezone I choose. Not sure if that can be caused by hardware <Rutherther>An hour jump is fine. Only something like more than a day is troublesome <efraim>I think vim-gnupg doesn't work well with using gpg-sq for git commands <yelninei>the 1h jump could be because windows and linux dont agree wether the system clock is in UTC or local time (and their timezone is UTC+1) <yelninei>janneke: I built hello on i586-gnu so the only issue is with the x86_64 bootstrap files <efraim>ok, it looks like I misunderstood the interaction between vim-gnupg and vim-fugitive. <janneke>yelninei: so what you're saying is that the bootstrap seeds must be updated? <yelninei>if I understand this correctly yes. because the mig update changes alignment for mach rpcs with 64bit values, the bootstrap-libc does not agree with the running servers on the interface <yelninei>debian has patches in libc to mitigate this but they only need to care about 1 libc at every time <janneke>yelninei: ugh -- has this insight in an issue yet? <yelninei>ig you try to run the current hello on a X86_64 system with glibc compiled with the new mig a stat for libgcc_s.so fails with the bogus error 18446744073709551316 because the libc and the hurd servers dont agree on how a io_stat_request looks like <futurile>csantosb: they also had problems yesterday - someone DDoS them again probably - such a weird world <yelninei>I tried to look around on bug-hurd but could not find anything regarding this <futurile>Gosh I'm having a hard time finding a peertube instance which isn't some poor person being a massive charity. <futurile>it's all very well wanting FOSS solutions, but I'm not sure it's better bankrupting someone <sigh> <aaavigatori>Apparently no preinstalled program an resize images on redmond OS ?? <aaavigatori>Why make it usable, if you can make it dysfunctional <bjc>internet economics have never made sense. the more popular something you make is, the more you have to pay for it <bjc>it's the central flaw of the whole network <aaavigatori>@Rutherer this is the output of TTY12 before I did anything: https://ibb.co/jvdHPdpS (Trying) to log into another TTY didn't change the output. Neither did selecting the language in the installer. Sorry for the potato quality <Rutherther>aaavigatori: okay and afrerwards, nothing in tty12? <Rutherther>aaavigatori: okay and what about the log in prior to the hang, have you tried that? <Rutherther>If that doesnt work, this is not debuggable right now <aaavigatori>Rutherther: Yes, it's not possible to log in. I simply get a timeout <Rutherther>I doubt nonguix ISO would solve it, if anything it would solve it on the account of being for 1.4.0 where this would be fine <aaavigatori>so you think it's an issue with the installer or with guix itself? <Rutherther>I expect it could be something in pam hanging. Well one thing you could try is flashing the ISO once more, maybe it could be a corruption. Sometimes corruption presents similarly <aaavigatori>Rutherther: what is your take on trying to create my own image? I tried flashing the image twice already <Rutherther>aaavigatori: I would be afraid you will end up with same issue. Rather try 1.4.0. But even if it succeeds be prepared for the fact that the target system might exhibit the same issue <Rutherther>In any case please report back with your findings if there are any more <Rutherther>But its hard to debug it and currently I dont really have scenarios in my mind that would explain it <janneke>ACTION will add these to codeberg once it's up <janneke>the mig-boot0 will, using, git-fetch-from-tarball, use the sources from the mig git checkout <yelninei>janneke: If the git-fetch-from-tarball does not work, can we just let it fully inherit the source + version to not have to update it twice? <janneke>yelninei: "janneke: If the git-fetch-from-tarball does not work," -- why wouldn't it work? <janneke>yelninei: git-download /is/ not available; that's why your paste is wrong; it removes the git-fetch-from-tarball which is helping to work around that <folaht>I'm getting an error from this added line; error: 'etc-profile-d-service-type': unbound variable <janneke>yelninei: to build from a git checkout in commencement, you need git-fetch-from-tarball <yelninei>janneke: only if builtin:guix-download is not available, or am I misunderstanding git-fetch-from-tarball? And in that case we have the problem with savannah <yelninei>janneke: Maybe git-fetch-from-tarball should be reworked to fall back to SWH immediately in that case instead of trying the git-fetch/in-band which will create a problem. <yelninei>because the SWH fallback for the tarball wont work because it ask SWH for the tarball whose hash we cannot determine and not the checkout <Rutherther>folaht no, why is there a ' after the profile d service type? Other than that yes. You might be missing the module with flatpak though. Try the reconfigure and it will tell you <Guest21>What is the best way to mount a NFS share on GNU Guix? I only require it for my user, system wide not needed, though I am the only user. If best practice would be to use system wide, I would be fine with it, too. <futurile>Guest21: there's no 'best practise' that's specific to Guix. Mount it as you would normally. <identity>Guest21: (info "(guix) Network File System") may be of interest <Guest21>in that case, is it possible to use file-system which can auto mount and auto create dir? does it support nfs <Rutherther>Guest21: It should. Worst case you will boot to previous generation if something has gone wrong. You might want to mark it as mount-may-fail #t in case it might not be available <Guest21>futurile: Is it possible to see the generated website of the commit? <kestrelwx>Hello! I was going to say that IRC logs might be having issues, but apparently I have connection to that machine throttled too now. It looks fine through a proxy. <futurile>Guest21: not before it's pushed, we don't have a test site - you have to read it on Codeberg, or pull down the website source and build it locally <janneke>yelninei: i don't really understand; it works for me: <janneke>./pre-inst-env guix build -e '(@@ (gnu packages commencement) mig-boot0)' --system=x86_64-gnu <janneke>/gnu/store/00sfjzniijz1fsahp4j7dhanwmxyd28q-mig-boot0-1.8-0.3f4b006 <janneke>(this is with my patch, so only the mig update) <Guest21>futurile: I read over it and can't find obvious problems, at least for the written part. <Guest21>futurile: only l 125, Youtube should be YouTube, but that's only for the perfectionists <kestrelwx>I think 'organising'/'annualise' should be written with a 'z' isntead, since the website is in US English? Are there guidelines for this? <Guest21>if you want it in us english, learnt should be learned, though I think using british english makes more sense, since guix targets world <futurile>kestrelwx: yeah, I'm not following the language hegomony of the USA <yelninei>janneke: yes, but what should happen if builtin:git-download is not available? the normal git-fetch in that case uses the regular git package which does not work, git fetch-from-tarball falls back to the snapshot which also does not work <janneke>yelninei: yes, if you're running a very old daemon, that may/will not work. <cbaines>janneke, yelninei Guix generates different derivations if the daemon doesn't have the git-download builtin <cbaines>although this can cause problems when the derivations are moved around between machines <yelninei>janneke: then just get rid of git-fetch-from-tarball and simplify? It would be enough if either the daemon in the childhurd or the daemon of the host has git available. <yelninei>janneke: I built the bootstrap-binaries locally and am trying to see if all problems go away, though injecting these into bootstrap.scm was a bit tedius <identity>futurile: organize comes from Medieval Latin organizō, itself from organum («organ»); i believe that the American/Oxford British spelling is ‹more correcter› in this case <identity>Late Latin annuālis, from which annual comes, does not have a declension ending in -iz*, though. the American/Oxford spelling is still -ize <Guest21>Wha does it mean when I boot my Guix VM and I only see a cursor blinking? I added my NFS share in the file-system description. <janneke>yelninei: i'd like not to get rid of git-fetch-from-tarball without consulting civodul, but other than that, sure <janneke>"<yelninei> janneke: I built the bootstrap-binaries locally": very nice! <identity>«According to the Oxford University Press, the belief that the ‑ize spelling of the suffix is an exclusively North American variant is incorrect, with its usage in British English rather attested over centuries.» <ieure>Guest21, When are you getting that? As soon as you start the VM, you get nothing but the cursor? <yelninei>janneke: Maybe we can replace the fallback from the tarball to SWH directly? <janneke>ACTION did that at least a dozen times when creating the 64-bit hurd build <identity>indeed, organi{z,s}e comes from Middle English organizen, organysen <ieure>Guest21, Sounds like a bootloader issue. <janneke>yelninei: how does that help, when the SWH fallback is already in place? <Guest21>ieuere: I only added the nfs share and reconfigured the system. It worked, the system created the directory in my user directory. Though I wanted to try out if it works on restart, too <kestrelwx>futurile: I tried proofreading, hopefully it's not noise. <Guest21>I assume bootloader issue means broken vm, which means starting over again? <yelninei>janneke: The fallback is only there after git-fetch fails, but if git-download is not available we dont want to attempt git-fetch at all. In the log you shared you got a SWH fallback for the snapshot tarball download and not the git-download <yelninei>(but any daemon that can run on x86_64-gnu should have git-download available so I dont think it matters much) <yelninei>so my idea was to immediately fallback but I dont know how to hook that up <identity>futurile: "During December and January 17 people" needs a comma, badly <folaht>Rutherther, why is there a ' before flatpak? <folaht>I added another ' because I thought that a quote was missing. <folaht>Without either single-quotes I get => error: flatpak-profile-d: unbound variable <kestrelwx>folaht: The intent to put the service name there as a symbol, so it needs to be quoted, which is what the ' does. You can look it up what's quote or what's symbol in either Scheme specs or literature or Guile manual has it too. <gabber>pcscd fails to recognize my keycards (all of a sudden). have pulled and reconfigured somewhat recently, the machine is freshly booted and both my cards don't work. pcscd doesn't show any activity in the logs but the USB is recognized. did something change? could it an udev thing? does anyone know of any changes recently? <futurile>gabber: hmmm I _might_ have seen someone else ask about this recently; unless you've asked more than once <Guest21>guix system vm defaults to x86 machine and grub-pc fails on aarch. How can I say guix vm that i am on aarch machine and want a aarch vm? <identity>Guest21: try passing --system or --target with aarch64-linux <Guest21>undefined variable default-guile-json when i use --target=aarch64-linux-gnu <Kabouik>May I ask if anyone has a greetd + tuigreet configuration for config.scm to share? I am currently using GDM and checked the manual for greetd-service-type but I'd like to see a working example before I break things. <csantosb>gabber: in case you have some spare time, it would be nice to have this #6509 in EDA, for a local training in a couple of days <Kabouik>That's a lot more complex that I that I was expecting, my GDM configuration was just 5 lines long. <yelninei>janneke: glibc-intermediate failed with a python import error for math <yelninei>this is also not built on the current python-boot0 on x86_64-gnu and I am not sure why it is required now? <yqshao>Kabouik, I believe the extra things are not doing much special, only to make a record type out of tuigreet-session so it can be somewhat configurable, so I think your version is good (I hope so but I won't be able to verify things shortly) <yelninei>error: static declaration of 'sinpi' follows non-static declaration <Kabouik>yqshao: I will try it anyway, at worst I have a backup of my previous config.scm with GDM, and should also be able to reboot from that generation from GRUB if anything goes too wrong. <Kabouik>It's still building but I have to go, I'll test it later. <yelninei>janneke: i guess that is because of changes in glibc that do not work with the ancient python <janneke>yelninei: oh, and/or possibly something like -lm ? <yelninei>janneke: Python-3.5.9/Modules/mathmodule.c:70:1: error: static declaration of 'sinpi' follows non-static declaration, glibc-bootstrap-0/include/bits/mathcalls.h:81:1: note: previous declaration of 'sinpi' with type 'double(double)' <janneke>yelninei: could that be a gcc-14 strictness thing? <yelninei>janneke: these glibc definitions are new with glibc 2.41 (previosuly it was 2.39) <janneke>the older python doesn't compile [cleanly] with the newer glibc <yelninei>the glibc definition is behind a #if __GLIBC_USE (IEC_60559_FUNCS_EXT_C23) but i am not sure how we can disable that? <janneke>hmm, possibly/if we're lucky with a --std=cNN, but dunno... <janneke>the question was, what is NN, and does it change the __GLIBC_USE... define? <yelninei>in libc or in python? I am trying CC=gcc -std=c17 in python right now <ieure>It's comfy, at least for me. <untrusem`>I mostly use a xmpp client client to use irc <untrusem`>also get a free bouncer as xmpp can have history <FuncProgLinux>untrusem`: I like erc but I have grown accustomed to icedove :s <FuncProgLinux>but nothing beats the IRC <-> code switching experience in Emacs <untrusem`>I mean soon emacs will also be a video editor <divya>I got a ping, hello untrusem <divya>Yes, playing supertuxkart on stream while chatting on ERC is the next week's plan <yelninei>neither c17,c11 or c99 work and the libc header is just a bunch of nested macros <FuncProgLinux>untrusem`: I didn't knew emacs could do that. Not even remotely <FuncProgLinux>I mean I know some people used EXWM as their main user interface <ieure>I'm old, used to be you got the choice of twm, fvwm, olwm/olvwm, and that was about it. <FuncProgLinux>Wait but if emacs is the wm. What happens if a window hangs or crashes? does it also handle that? :o <ieure>Works about the same as any X11 WM, if a client crashes, the window stops updating and you can kill it. The jank is that if *Emacs* freezes, the whole session does. <ieure>There is no daemon, but yes. <ieure>You lose the session. It's not great... but I still prefer it. <identity>not like on-topic discussion is particularly active here right now… <aaavigatori>does anyone know why the libera.chat webinterface is nonfunctional? <aaavigatori>but the browser cache holds all my delicious cached data ;_; <Rutherther>I did not mean the whole cache, I just meant for this specific website <aaavigatori>heh, it works when I open it in a different firefox profile, strange <janneke>Rutherther: you asked me a question about closing issues, and i read the email, but i cannot for the life of me even find where to comment on it :-( <janneke>Rutherther: of course i'd be happy to do "things like they should be done", but as it stands, the web ui is terrible enough for me as it is, fj.el is sort of almost managable.. :-( <janneke>i'm trying to avoid the web ui (i've been inadvertendly closing or resolving things, i'm terrible with any graphical ui) <janneke>but i visited this in the browser, no idea how to look this up via fj.el :) <janneke>apropos `Merges: #PR`, can we please avoid the word "merge", as i believe wy try our best to only rebase and push? <Rutherther>still the wording is used by most people, team branches are also so called merged even though the merges are only ff <janneke>ACTION dislikes using wrong wording, even if it's popular...but yeah <Rutherther>same with PRs, it's fast forward merges. I do not really care about the wording, more like the idea. I think it is civodul who came up with it and I just took inspiration from it and also use it when I close PRs <Rutherther>is it wrong though? You can use git merge easily with the current workflow <Rutherther>ie. git checkout pr && git rebase master && git checkout master && git merge --ff-only pr does what we're aiming for (not saying it's the best way to do it of course) <Rutherther>but I think it's shows that the wording is not off <yqshao>Kabouik: your ver. worked fine on my computer! (I'll probably still wrap it with greetd-user-session but thanks for cleaning up my dirty config :-) <Rutherther>personally I use a short git alias that just cherry picks the commits on top of master <janneke>anyway, what do i need to do next time when closing an issue or pr?; and is there a document that i failed to read? <Rutherther>janneke: I doubt there is a document about this. I am myself not really using fj.el at the moment so I cannot say for that. But at least with the web ui, if you open the PR I sent earlier, you can see that you've 'closed' it. Then look further and you will see I put it as 'manually merged commit' (I only later realized I might have better postponed on it and let you try to do it) <janneke>yes, i'm seeing: " Rutherther manually merged commit b57b0ee8dc into master 2026-02-17 19:31:35 +01:00 " <Rutherther>and in the web ui, it is done by clicking on the "Manually merged (when checks succeed)" - the "when check succeeds" can just be ignored. On any open PR, ie. here https://codeberg.org/guix/guix/pulls/6512. You click on it (no need to worry at this point if you click on it accidentally, it doesn't do anything yet), fill in the commit id you pushed it as (the last commit in the PR is used) and then click on manually merged once more. <Rutherther>I would expect fj.el to also support this, but I am not sure. I have never merged anything with it although I briefly used it <janneke>Rutherther: ah! I've seen that button but was scared away by the "when check suceeds" <janneke>makes sense, and thanks for the heads-up <janneke>and thanks for "correcting" my closed PR :) <Rutherther>I think it might be wrong configuration or just Forgejo not supporting any other wording, not sure. There are no 'checks' in the Guix repo <janneke>in fj.el there's a: "M fj-merge-pull" <janneke>that doesn't really sound like a "manually merged" check-off, though... <Rutherther>janneke: there is manually-merged in fj-merge-types. If I am reading the code right it asks you about the type. Then on manually merged it asks for the commit. So I think it should do the same thing <janneke>Rutherther: that sounds beautiful, thanks! <Rutherther>janneke: you can try it on a different repo just to make sure, but I wouldn't worry too much about it, because as far as I understand it other than manually-merged type is not allowed on guix/guix, so I think the other types should just give you an error (but I haven't tried it so I cannot vouch for this 100 %) <janneke>yes, that's what i thought, most probably any "automatic"/"button-press" merge should fail <janneke>Rutherther: fwiw, with all my personal "troubles" of codeberg, i can clearly see how the move to codeberg was a very good thing, and how it organizes things and streamlines communication very effectively <janneke>Rutherther: and i'm very grateful for your guidance, thanks! <jab`>if I want to run hurd via qemu on guix system, do I need to add my user to a kvm group ? <jab`>assuming I want to use intel_kvm <jab`>ls -lha /dev/kvm is owned by the group kvm <jab`>guix system: error: corrupt input while restoring archive from #<closed: file 7fe8c585ee00> <jab`>I did just complete a guix pull. Maybe I need to try rebooting and see if that fixes it. <jab`>nevermind, the second attempt at reconfiguring worked.