IRC channel logs
2025-03-29.log
back to list of logs
<Kolev>mjw, is this about That Man? I refuse to cancel him. It's an injustice. <mjw>Kolev, why would you cancel him? <Kolev>mjw, IIRC some leaders in Guix wanted to take over GNU with the gnu.tools site, because they signed documents wanting to cancel That Man. <mjw>ACTION isn't a "leader", but I did help set up gnu.tools <Kolev>mjw, I detest gnu.tools agenda. <anemofilia>ieure: and I don't use the system level ssh service <Kolev>mjw, cancelling people isn't the solution, and we need to maintain a unified front. Don't be another OpenBSD, which sows infighting within the free software community about such issues as firmware. <mjw>Kolev, I am not sure who is cancelling people. Obviously since I helped set it up I believe it describes the GNU spirit. Do you think we should improve it? <Kolev>mjw, gnu.tools was created by people who signed a document against That Man that people don't like. <divya>mjw: Not to start a flamewar, but I think the claim that GNU is so toxic is a bit too generalizing. The GNU still stands for freedom more than anyone else. I think things can be mended. <Kolev>mjw, the Document was a manifesto to cancel That Man, and Guix devs signed it. <mjw>Kolev, which document do you mean? <mjw>divya, I do hope so. But after some years I admit I have become somewhat skeptical. <Kolev>mjw, I believe it was the first letter asking for Stallman to be cancelled, not the second one that Drew DeVault popularized. And Drew DeVault sinned; we should cancel him as well. When does the division in the community end? <mjw>Kolev, I have no idea what you are talking about, sorry. <Kolev>I'm proposing mercy for both Stallman and DeVault. <divya>mjw: I understand the frustration. I still think we should imagine friendship. <mjw>Kolev, I did publish a couple of idea about GNU a few years back when setting up gnu.tools. Maybe you like them? <Kolev>mjw, Guix devs are on that letter. I do not trust Guix to go in this new direction. <mjw>Kolev, Maybe some are. And trust is a difficult concept. <mjw>divya, I did help draft that one <mjw>Kolev, yes, I am one of them, even though I don't really count myself as a guix dev. <mjw>Kolev, is there something in particular you don't like about it? <divya>mjw: Hmm. Would you like to talk about this elsewhere about what could be done? I am not really here to be a GNU fanboy, like you I wish to see free software people to be united. <Kolev>mjw, it sets an air of fear over the community. It sets in motion a witch hunt, albeit from our own side of the political fence (liberal/progressive politics). <Kolev>And Stallman is progressive, yet he's not progressive enough, it seems, for the new generation. <Kolev>Maybe I'm not progressive enough, even though I support many socialist economic policies and health care for trans folks. <Kolev>Maybe you'll cancel me, too. <mjw>divya, yeah, probably best to leave this channel to guix development. Sorry, I was just wondering what Kolev meant. But this channel is probably not the best to debate that. <mjw>Kolev, feel free to private message me if you want to discuss this some more. <divya>Kolev: Let's not be combative and take this elsewhere. <Kolev>mjw, I'd rather not discuss this more. I've said what needs to be said, and I don't want to run off the rails and get high blood pressure. <Kolev>divya, I would like to observe this discussion if it happens elsewhere. <Kolev>I have no desire to participate further, however. <dcunit3d>not sure whether to take any of that seriously though. there's a conflicted choice of wording. <sleepydog>I think I just rendered my system unbootable by running out of inodes :( <divya>sleepydog: Oh, you're on ext4 filesystem? <divya>No idea about that...but you can chroot and take the configuration of your system and reinstall on another filesystem (preferrably btrfs) <sleepydog>I was able to delete enough files through the rescue shell to boot and run guix gc <divya>But it's a filesystem issue. <divya>I experienced this on ext4, and never had it again after btrfs <lilyp>Kolev: while these are notes from the Guix days, they currently don't seem to be actively discussed on Guix devel, unlike e.g. the move to Codeberg/Forgejo <lilyp>ngz: wdyt about making texlive respect XDG_CONFIG_HOME? It should be possible by patching texmf.cnf <ngz>lilyp: You mean set TEXMFCONFIG to $XDG_CONFIG_HOE <lilyp>Relative to XDG_CONFIG_HOME, yes <ngz>XDG_CONFIG_HOME/.texliveYYYY/texmf-config <lilyp>and set a default for XDG_CONFIG_HOME as $HOME/.config <ngz>It doesn’t change much on out side, but the historical directories, which predate XDG stuff, may be expected by some users <ngz>So I’m not sure we should diverge from upstream. <ngz>(even if it probably makes more sense) <lilyp>I mean, we could probably submit a patch upstream too – I just want less of our packages to litter in $HOME <ngz>That’s understandable. <ngz>To my knowledge, there are <ngz>three variable we could change: TEXMFCONFIG, TEXMFVAR and TEXMFHOME. <ngz>I guess they could relate, respectively, to XDG_CONFIG_HOME, XDG_CACHE_HOME and… XDG_DATA_HOME? <ngz>Not sure about the latter, tho <ngz>lilyp: TEXMFHOME is never automatically created. I think it is more reasonable to not touch it and let users decide what to do with that location. I guess we can change the default value for the other two, but it’s a world rebuilding change. <hiecaq>Hi Guix, I was just reading about #77086 and I have a noob question: Is fsck logged? I grepped /var/log/*.log with 'fsck' and the output is empty, does that means I'm good...at least for now? <ngz>lilyp: one of them is what? <lilyp>I think TEXMFVAR is automatically being created <ngz>Yes it is. And TEXMFCONFIG could be, with some active user interaction. TEXMFHOME, never. <Rutherther>hiecaq: no, you will see it only when booting. Fsck happens before the root fs is mounted, so it can't be saved anywhere <hiecaq>Rutherther: uh, I'll pay close attention to that recently then, thanks for clarifying <Rutherther>hiecaq: then I would estimate the fsck to take a couple of minutes, so if you are near your computer when it's booting you would probably notice it <hiecaq>Oh, if that's the case I haven't noticed anything like that recently. I'm a little relieved now XD <ngz>lilyp: Thinking a bit more about it, it seems we can also drop TEXMFSYSVAR and TEXMFSYSCONFIG from TEXMF, which are never used. But TEXMFLOCAL needs to be re-introduced in case some external tree is installed. <lilyp>I'm not suggesting to drop anything, I'm suggesting to add some bits to make things work with XDG_*_HOME <lilyp>I think this change should be smooth when doing a year change too, since the config files for the new year wouldn't exist yet <ngz>lilyp: I know you didn’t suggest that. I was merely thinking out loud. <apteryx>the nginx-activation procedure checks the nginx configuration but invokes nginx -c with just 'system*', disregarding the returned value, whic does not much, right? Should this be called with 'invoke' instead? Could this break boot, or is it safe to raise an error there? <apteryx>looks like the activation gexps will be run as part of the boot script (produced by boot-service-type) <apteryx>now to check if/how errors from these are handled <apteryx>re activation gexps, they end up in activation scripts that are 'primitive-load'ed in a for-each loop in /run/current-system/activate <apteryx>it's not handled for errors (which would probably be a better idea than fail the boot) <Rutherther>how is the ":output" implemented in gexps? I would like to have a list with packages and their outputs and I would like to ungexp this whole list <lilyp>and I think on the other side you want gexp-inputs :) <Rutherther>last week I was walking someone through reinitialization of guix system without removing data, only the store and /var/guix and they were unable to boot because of acl file being in the way, pointing to non-existent store location... <ieure>Once again reviewing Emacs patches this morning. Feel free to ping me if you have one needing attention! <ieure>I can look at other stuff as well, but depending on the problem domain may or may not be able to push. <Rutherther>I would appreciate if someone took a look at #77201 it's a very simple bug fix <Rutherther>and possibly also #77251 that is not so simple, but on the other hand it's causing profile builds to be much slower for big icon themes and causing a lot of inodes to be in the store <ieure>Rutherther, So the behavior here is that if /etc/guix/acl ends up a broken link, `guix system reconfigure' doesn't replace it with a good one? <Rutherther>ieure: the exact behavior was that the activation on boot didn't replace it and failed with symlink: File exists, but the same would go for reconfigure, yes <apteryx>Rutherther: thanks for confirming, I've created bug#77365 <apteryx>another weird thing: I'm calling 'ngircd --checkconfig' and its code waits on keyboard if isatty(fileno(stdout)) is true, which oddly it is. <ieure>Rutherther, Okay, let me get through some of these simpler Emacs patches, then I'll see if I can replicate behavior in a VM. <Rutherther>ieure: okay, definitely, you should be, I was able to replicate it in vm by adding something like ln -s /non/existent/file /etc/guix/acl <apteryx>anyone knows how I could run some script in activation gexp, making sure isatty on stdin and stdout does not return true? otherwise it halts for a key. <Rutherther>apteryx: doesn't inputting /dev/null into the program (shell equivalent would be program</dev/null) do that? at least for stdin. As for stdout, piping to another program like tee could work I think <apteryx>that works, thank you. I guess another way would be to fork and close the inherited fd for stdin stdout or something, but that's more involved. <apteryx>is there a simple way in guile to change stdin before running with 'system*'? I guess I'll end up shellling out via 'system' <apteryx>Rutherther: maybe with-input-to-port but I seem to recall there's a bug in guile that causes this to have no effect on forked processes (system/system*) <apteryx>I know I've attempted this long time ago myself and got confused <apteryx>what is odd is that when I test at the Guile REPL with '(system* "ngircd" "--configtest")', it doesn't pause for a key (isatty is false for either stdin or stdout) <apteryx>not sure why that's different in the boot script <apteryx>maybe qemu -nographic does something? <ieure>Huh, I applied a patch to my local checkout, but building it downloaded a substitute from bordeaux. Which I guess means the same version bump is on a branch somewhere. Don't see it, though. <apteryx>hm, I guess that's it, the -nographic option hooks an emulated serial port to the console <apteryx>re -nographic, that works when using qemu (I can press enter to dump the problematic config file), but it hangs in 'make check-system TESTS=ngircd', so that's still not understood. <ngz>lilyp: (re XDG and TeX Live) Done. <ieure>Rutherther, Looking at your patch, I agree with the diagnosis, but the logic needs some work, and Guile semantics are a real impediment here. <ieure>Rutherther, will follow up with some suggestions. <ieure>Rutherther, So the main issue here is that `file-exists?' is arguably buggy, since if you give it a broken symlink, it returns `#f' -- which is true for what the link points to, but wrong for the link itself. <ieure>Rutherther, But the rub here is that `symbolic-link?' raises an exception if given a path that doesn't exist. <ieure>Rutherther, Which means `(or (file-exists? acl-file) (symbolic-link? acl-file))' will raise if /etc/guix/acl doesn't exist. <ieure>So I think what this needs is either to guard `symbolic-link?' in a `with-exception-handler' or just call `lstat' in a `with-exception-handler' and use that to drive the behavior. <ieure>I also think this logic is complex enough that it should get refactored into a `cond'. <ieure>Rutherther, Does all that seem like something you're willing to do? Happy to drop this feedback into the ticket if so. Otherwise, I could rewrite your patch and send a v2, but then wouldn't be able to apply it. <ieure>But I don't want to rewrite anyone's patch out of nowhere, you know? <Rutherther>I guess I now understand why the person writing the special file service went with making a .new file that they then move to the proper location with rename-file that doesn't mind if there is already a file in the way <Rutherther>ieure: I am fine with rewriting it, though I am not sure if I will do that today. Also, what about making this into a procedure? Because I think that this behavior could be wrong even elsewhere and a procedure could be handy, expecially given that one has to also guard for the exception from symbolic link <ieure>Rutherther, Okay, will lay this out in a reply to your bug. And I agree that a procedure would be helpful. I'd factor it such that it does everything except populate the new file, so mkdir-p's as needed, deletes symlinks, or renames to ".bak". <Rutherther>ieure: also since you're here, what fs are you using on the machine that doesn't cleanly unmount root fs? <Rutherther>because I've tried with bjoli's config and I can't replicate easily, but I've changed the filesystem to ext4, bjoli uses btrfs, it was easiest for my current workflow, of course would be better to try with btrfs <ieure>I think that's in the config I shared <Rutherther>oh, you've shared it already? I haven't seen it yet then <Rutherther>I expected an e-mail to me and didn't check the issue <Tadhgmister>if I am packaging a game and it expects to have a folder with several font files specified at build time is there easy guix machinery to create a union package of the font inputs? <ieure>Tadhgmister, I'm not aware of one. Does it need the fonts to run? <Tadhgmister>right now hyperrogue only depends on deja-vu but apparently it is setup to try to load another font if it detects the system locale is Chinese and I'd like to fix that while I'm fixing another issue with fonts but I'm not sure the best way to get "this is a folder you can find font files in" <ieure>Tadhgmister, You'd need to make a fonts directory in the package output and symlink the fonts from the package input into that. <ieure>Tadhgmister, I guess this game loads fonts directly instead of using whatever's available on the system? That sounds like an upstream bug to me. <Tadhgmister>yeah I hadn't considered "does it actually need that folder" as a possible avenue <ieure>Tadhgmister, And it seems like SDL_ttf doesn't support any kind of system font stuff, which I guess makes sense given its purpose. <ieure>Tadhgmister, I would make a directory in the output and symlink the fonts it needs from the Guix packages in its inputs. <Tadhgmister>would it make sense in the output? I guess so, without some builtin machinery to handle this specific case which you are right most of the time wouldn't be needed cause it'd use system wide stuff <ieure>Yeah, I think dir in output is what makes the most sense. <ieure>Even though it's pretty goofy. <Rutherther>if you can point the game to any directory imo it's better if it's not in the output so it's not propagated to the profile user install it to <Tadhgmister>wait.... the guix package refers to HYPERFONTPATH and that is no longer referenced anywhere in the repo... <Tadhgmister>I think I should stop chasing this goose and try just updating the version of the guix package <Rutherther>ieure: hmmm, on the first look to your configuration, shouldn't the autofs service type depend on file-systems service? <Tadhgmister>ok so compiling kernel with both guix specific config stuff and target of "multi_v7_defconfig" does not seem to work, how do I set (parallel-job-count) to 1 so I can more clearly see which part was failing? <Rutherther>Tadhgmister: if you want just for debugging, then just --cores 1 <Rutherther>if for something more permanent where parallel builds shouldn't be enabled, then by #:parallel-build? #f to the package arguments <Tadhgmister>is just for debugging although knowing about parallel build option is good to know, it seems "gcc plugin latent entropy" is the culprit? (not liking cross compiling, is specified in guix kernel options) I'm not at all even clear what that plugin does <Tadhgmister>like it says it is a gcc plugin which suggests it is only relevent for compiling but guix is trying to make the build totally reproducable, or it is a feature that changes the built kernel in which case it being called a gcc plugin is confusing <Tadhgmister>ok so it will take me a while to confirm but it seems like if I just drop `CONFIG_GCC_PLUGIN_LATENT_ENTROPY` from gnu/packages/aux-files/linux-libre/6.12-arm.conf I can just directly cross compile the installer image for arm, that is the only one that doesn't play nice with the cross compiler <Tadhgmister>should I ask about that in a mailing list or something? it seems wrong to submit a patch when I have no idea what the repercussions are, but I went through hours and hours of trying stuff to get guix on my arm board and the first thing I tried was stopped by that one line <Tadhgmister>and I definitely don't have the know-how to try to do a bug report upstream <Tadhgmister>when I do guix system init onto a flashdrive that already has a bunch of the dependencies it seems to just re-copy them all, is there a way to skip that, possibly with `guix deploy` where I specify the system as a locally mounted partition? <Rutherther>Tadhgmister: I am afraid not an easy way as you can have just one guix store per machine, so tools like deploy/copy don't really work like that. One workaround could be to make a container or a virtual machine that will have the flash drive mounted and you will just guix copy to it. But still no good way to actually deploy a full system including the bootloader as the container/virtual system won't really match your real one and you won't be able to... <Tadhgmister>surely there exists some way, the installer has you enable a cow-store service to copy packages over to speed up init process, could I potentially just enable that before recompiling my kernel to speed it up a bit? <Rutherther>the cow store is to prevent writing to the ram disk the installer's /gnu/store is on <Rutherther>it would be faster without the cow store as writing to ram is faster than writing to the disk, but your ram would fill up <Tadhgmister>ugh, this is probably not related to guix but I am trying to compile something in a guix shell and when I run the `cc` command within the shell it works properly but when it gets run from make it doesn't seem to have the right includes... <Tadhgmister>oh wait actually I think I know the answer, I just have to do `env` to show environment variables and figure out which one is being touched by any of the makefiles <Tadhgmister>yeah it was just unexporting C_INCLUDE_PATH *rolls eyes* <PotentialUser-11>Hi, I have a custom keyboard layout that I made by editing files /usr/share/X11/xkb. How do I port these files to guix? <Tadhgmister>might just be `#:options '("A" "B" "etc")` to your keyboard layout in the os declaration <PotentialUser-11>But where should I copy the files? Into /usr/share/... like they are on my current system? <Tadhgmister>oh I see it isn't just a few options, hmm.. it is likely there is a system service you can specify it to to put it where it needs to be let me take a look