IRC channel logs
2026-07-01.log
back to list of logs
<apteryx>noe: on my current gnome 48 (haven't redeployed with gnome-team yet, right-click -> properties on an external drive in nautilus crashes it -- do you reproduce?) <RavenJoad>How can I get LaTeX documentation when using a collection/scheme (like texlive-scheme-medium)? texdoc works and is looking in the right spots(profile/share/texmf-dist/doc/), but the directory is empty. I know each leaf texlive-* package has a doc output. <czan>Hmm. Good question. I can't see any easy way to do it, but I've just tried writing a manifest for it. I'm just building it to make sure it works before I share it. <RavenJoad>czan: I tried in a manifest both a bare texlive-scheme-medium and a (texlive-local-tree (list texlive-scheme-medium)) and neither installed the documentation. I don't think the collection/scheme packages carry over the constituent <czan>I built it with --no-grafts, because it was taking forever. :) <czan>Yeah, my code walks through the packages to find all the doc outputs, and then creates a manifest with them all. <RavenJoad>Yeah, that is pretty annoying. Perhaps the collections/schemes should have a doc output too. <czan>Running "guix shell -m texlive-doc.scm --no-grafts" gave me an environment where $GUIX_ENVIRONMENT/share/texmf-dist/doc/ had stuff in it. <czan>I think the problem is that the collections are made with propagated-inputs, which doesn't have a way to link together the outputs like that. So they'd either need to include the docs in the meta package, or we'd need to introduce a bunch of code to copy the docs into the "doc" output of the meta package. <czan>Obviously both are doable, but I'm not familiar enough with the TeX packaging to know what's best. <RavenJoad>Yeah... I figured it would be something tricky like that. <RavenJoad>I would really like to have all of my documentation offline. Right now, this is the last piece missing from my system. It would be nice to have. <czan>Does that manifest solve your immediate problem? I agree it would be nice to have a nicer way to do it, but that could work for now? <czan>I've restricted that to texlive- packages, but in principle you could do something similar to walk your OS and/or user profiles and collect up all the doc outputs of everything you have installed. <RavenJoad>czan: Immediate problem solved, yes. (This is not pressing, just something in the back of my mind everytime I have to go online and search "texdoc <package>".) <RavenJoad>Admittedly, I did not search the issues too hard for this, so seeing there is an actual issue for this makes me happy. <czan>Well, I've commented with some slightly more general code on the issue. I don't have strong opinions about what a good solution to this looks like, so I'm unlikely to push it further than that. <acidbong>moin. i saw that encrypted root and LVM are in the ROADMAP file, yet the manual has instructions on both. is the file outdated? <futurile>acidbong: I don't think the ROADMAP file is used honestly, check the git log for it <identity>somewhat annoying that i cannot put the help-wanted label on my own issues, or any label for that matter <jresich>what's the best way to 'pin' a system configuration to a certain version of guix? <jlicht>jresich: I use guix time-machine + a "channels" file for that. I wouldn't argue it's the "best" solution, but it works for me :-) <jlicht>jresich: e.g. "guix time-machine --channels=channels.lock -- system reconfigure mysystem.scm", /w channels.lock from "guix describe --format=channels > channels.lock" <jlicht>(you may need some sudo/doas somewhere in there, YMMV) <Air4x>Hi everyone, do any of you have an example of a shepherd service to start sway on login? I was thinking about a one-shot service, but i'm not sure how dependencies between services works in this case. <MichaelGame_Dev>- not being stuck with a tiny terminal with my eyesight this would be a nightmare. I'm thinking either try the graphical installer or turn on SSH and get in from my main desktop. <MichaelGame_Dev> - installing with nonguix, which I am guessing I'll need for a framework laptop <trev>MichaelGame_Dev: setfont ter-128b <trev>for nonguix, just use the iso on their gitlab <futurile>I'd also check the framework forums, as I'm sure I've seen people talking about using Guix, so maybe there's some nice posts <ieure>MichaelGame_Dev, You'll have to ask in #nonguix about nonguix stuff. <futurile>ah I love it, Thunderbird is renaming all their snap/flatpak stuff so that "stable" is their monthly, and if you want to stay on esr, you have to specify it in your snap/flatpak configuration <futurile>this is presumably because a lot of users consider the email client to be "done" so are on "stable" (annual) updates, and that's not what thunderbird wants - so now the default will be "monthly releases" but labelled as "stable". No doubt the fact they are changing the UI constantly now doesn't count as "non-stable". <identity>their monthly is their stable, though. the ESR being the default is probably a bad idea <identity>instead of getting new bug(fix)s every month, you just get old bugs <futurile>guess it all depends on whether you think your email client is really having old bugs fixed enough, to put up with the fact htat they also don't _only_ fix bugs in their "stable". <ieure>futurile, The constantly changing UI creates new bugs! <futurile>ieure: heh don't worry, they'll fix them in next months stable update! <jlicht>is there a way to configure guix pull to use (something similar to) ssh's ProxyJump? I'm having some routing issues between my at-home ISP and codeberg that I doubt will be resolved soon, and would love to route my traffic via my VPS that does not have this issue :-) <trev>jlicht: i think it only supports http(s) proxies. i sometimes use torsocks or full VPN <trev>you could actually use torsocks with any socks5 proxy <trev>ssh -D [port] [VPS IP] and then torsocks with that, perhpas <RavenJoad>What is the opinion on tools that need to invoke other tools? <RavenJoad>I have asymptote (which generates graphics) that depends on ghostscript. You can do `asy -gs="path/to/gs"` or set the env var ASYMPTOTE_GS with a path. Should "guix shell asymptote" pull everything in to let asymptote just run or should both be specified? Right now they must both be specified so asymptote picks up gs in $PATH. <jonsger>hm, I switched from sddm back to gdm as Gnome Shell (Wayland) didn't started at all. But the mouse cursor was just a white box. I head to do a: guix shell glib:bin -- gsettings set org.gnome.desktop.interface cursor-theme 'Adwaita' (proposed by Googles AI prompt ^^) <ieure>RavenJoad, Depends on how critical the tool is to the program working. If asymptote cannot reasonably function without ghostscript, its package should take ghostscript as an input and write its path into its output. If ghostscript is optional or one of many possible things you can do, it's probably fine to rely on $PATH and running in a profile where both are available. <RavenJoad>I am double-checking, but let's say asymptote's asy binary requires ghostscript's gs. The easier Guix solution would be to wrap asy with wrap-program to set ASYMPTOTE_GS. Is that Guix's preference too? (I need to investigate if one of the two can override the other.) <futurile>there's no use-case for using 'asymptote' without ghostscript then? <RavenJoad>At least for simple things, yes. My test file (which just generates a PDF with the text "Hello world!") does _shipout to generate the figure, asymptote complains about missing ghostscript. <RavenJoad>I just read through asymptote's docs and we can provide a configuration file in the system directory (/gnu/store/.../share/asymptote for us) that will be overridden by user configuration. Between the config file and wrapping, which is "the Guix way"? <ryanprior>I'm working on a blog post about using Guix for Lua software development. Anybody interested in proofreading? I've got ~2k words. <futurile>if you think users will basically assume/need ghostscript then wrapping is your best option. This will point to /gnu/store so it does impact the overall size of the application in Guix (downside if someone tries to put it in a container). If you think Guix users will use it without Ghostscript OR will just know they should add ghostscript then they can use a configuration file. The one most people <futurile>want to avoid is adding ghostscript as an input in the package definition -> nckx would appear from the ether and tell us off <futurile>that's how I understand it, ieure may have better thoughts <futurile>ryanprior: woah nice, as a PR or you gonna email 2k words ;-) <RavenJoad>futurile: ghostscript is already a part of asymptote's native-inputs, so I would just move it to inputs. I would need to check if you can even use asymptote without ghostscript in there somewhere. <ryanprior>futurile: I can send my org-mode source for the post, or a PDF, or whatever makes sense. Email is fine, not sure how a PR would work. <ryanprior>I'm planning to publish to www.ryanprior.com using hugo <futurile>RavenJoad: if you can't really use it without ghostscript it's a non-issue at that point. Hopefully your reviewer will be fine with that. <RavenJoad>Right, that was my thinking too. So then the question becomes, do I do a wrap-program to set ASYMPTOTE_GS or generate a default config.asy file in the system directory? <futurile>if all those options are equal - I would go for wrapping as it's the most common one <RavenJoad>I don't know if they are all equal. I have only just started getting interested in it for stuff. <RavenJoad>My first hunch would be the config file is more flexible because a user can still override the default ghostscript we provide with one in their environment by setting ASYMPTOTE_GS or using the -gs flag. But I don't know which wins (env-var or -gs) when both are specified. <RavenJoad>But by at that point, users might just override the asymptote package's ghostscript anyways. <ieure>RavenJoad, In order of preference: Writing store paths to the output > creating a wrapper > * <RavenJoad>ieure: Just to be clear, you mean writing store paths to the output (config file) is better than creating a wrapper? <ieure>RavenJoad, In the general case of "program tries to exec `other-binary'", the preferred approach is to replace the unqualified literal path of `other-binary' with `/gnu/store/...-other-binary-package-1.2.3/bin/other-binary'. <ieure>If you can avoid wrapper scripts, IMO, do. Craps up `ps' output, makes `killall some-program' not work, etc. I dislike it. <RavenJoad>Rewriting the default setting in the C++ is the cleanest solution in my mind. It allows both the env-var and the -gs flag to modify the program without us muddying things. <sneek>Welcome back jan0t, you have 1 message! <sneek>jan0t, daviid says: g-golf is also in netbsd and homebrew <jan0t>how do you manage the guix when you install it as a package manager in other distros? <jan0t>by my experience i got 2 problems <jan0t>same packages installed in both the guix and the standard one by the distro conflicting <jan0t>and the second was about making it visible to the system <ieure>jan0t, How do the packages conflict? <jan0t>let's say i install apt install openssl <jan0t>then i use guix install openssl <ieure>jan0t, Yes, but that is not a conflict. <jan0t>conflict in the sense that if i call openssl idk which one would be called <jan0t>and they might interfere with other apps and etc <ieure>jan0t, If you have Guix configured normally, the Guix one. <ieure>How would the Guix package interfere with other apps? <ieure>I guess if they call `openssl' unqualified and the Guix binary works differently than they expect? <futurile>the way I do it on my mixed hosts is I install all system requirements using the host package manager (e.g. apt install blah). Then my standard user, has "guix packages" for all the things that user needs which are not supplied by the system. In general I try and keep the "system install" as small as I can. <jan0t>futurile: I wanted that but i already am using this system for some time <futurile>jan0t: yup, if it's your own system, then you can cut down things over time if you want to. So maybe "as your user" just install small command line tools initially. I avoided daemons or system things (e.g. X environments) and just kept the ones from Ubuntu (in my case). <RavenJoad>Well I'm glad I asked, because I would not have checked and substitute*-d the settings.cc file without your suggestions. <jan0t>the only way i would use guix is to install the guix system and then allow the nonfree channels <jan0t>because of the amd integrated gpu <ieure>That's how most of us use it. <futurile>yeah, that's "replacing devuan", and as ieure says that's how many people use Guix, but you could also use it "on top of". It's a good way to initially learn Guix while still in the safety of a distro you understand. <jan0t>i would buy a t480 if i knew it would happen :P <ieure>jan0t, I run Guix System with third-party channels which do not share the same strict approach to licensing as Guix. <ieure>The Guix user/contributor survey done in 2024 shows that the majority of Guix System users run it like that. <ryanprior>jan0t: I recommend thinking about it as a base system, where your distro-provided packages dominate, and then Guix environments inside that, where Guix-provided packages dominate. Applications you install using Guix should use the Guix-provided openssl, but applications from your base system should not worry about it. <ryanprior>If you were to switch to use Guix System, then obviously Guix would be your base system, but that's not necessary to get the benefits of Guix. Inside a Guix environment, libraries from Guix should take precedence over those from your distro. (Or inside a Guix container, your distro's libraries won't even be discoverable, giving you the best isolation for better or worse.)