IRC channel logs
2026-05-03.log
back to list of logs
<nixfreak>What does everyone use for a light weight pdf reader ? <nixfreak>I like mupdf , or a pdfjs for a browser but anything else ? <bdunahu>and zathura-pdf-poppler (I have the mupdf plugin for it installed too but don't know which one actually gets used) <bdunahu>zathura hides all of the cool features behind vim keybindings, but you can customize them to be more emacs-y <sham1>Emacs can of course also do PDFs by itself with doc-mode, but there's also pdf-tools <bdunahu>I would rather have a config for that, but my emacs never ran well at all with 1000+ page pdfs <nixfreak>yeah I should try pdf-tools on guix , I tried that on msys2 at work and it was a royal pain <ieure>So I'm trying to rewrite the package inputs to stop it from doing that. <ieure>It pulls the transitive propagated inputs, removes the package labels, and filters it to all the apache-parent-poms propagated. Then sorts them, takes the newest, and constructs a rewriting list to replace the old ones with the new. <ieure>All that seems to work, in that the rewrite-spec looks good, etc. But the rewritten package still has the same conflicting apache-parent-poms in it. <ieure>So something with the rewrite has to be horked. <ieure>Don't see what, though, it's a pretty straightforward old->new alist <ieure>Uh, nevermind, this was all a wild goose chase. yay <csantosb>Hi Guix ! I have a bunch of third party scripts with a #!/bin/bash shebang, is it possible to get this with guix system ? <janneke>csantosb: possibly using the extra-special-file service? <janneke>assuming you don't just want to s,/bin/bash,/usr/bin/env bash, <csantosb>Next, try to fix tones of "libc.so.6 => not found" <csantosb>Full of them. Amd's Vivado, for those interested on feeling the pain. <janneke>yeah, well, guess we're getting the morning off <cbaines>I can ssh in to berlin, so maybe it's just come back? <cbaines>yarl, I think the MDC block ping at the network level, so I think you always can't ping berlin <cbaines>I've restarted cuirass-web on berlin, so it's back serving requests for now <janneke>hmm, it was only up for the briefest of moments? <sham1>`guix shell -CF` is just a wonderful thing <sham1>Now for your own convenience, you just create a wrapper package that will create the container for you and you no longer need to go through all that noise to get the program up <andreas-e>It is where the berlin build farm is located, whence the name. <noxi>sham1, the guix shell is truly impressive, yes <noxi>i never develop any software without a manifest.scm and/or a guix.scm <Rutherther>PotentialUser-76: are you pulling from codeberg.org? <Rutherther>that's fine then. And you're getting authentication failure, yeah? <Rutherther>guix does not use gpg directly, it does not use your gpg toolchain, it does not mind if a key is expired <PotentialUser-76>oh so maybe i did something wrong, i was trying to read to the isntall script <Rutherther>although noe should definitely extend the end date and reupload it, but that's a different matter, it does not matter for a guix pull <Rutherther>so you're pulling from savannah then and not git.guix.gnu.org <Rutherther>could you try "cd ~/.cache/guix/checkouts/7x37p6bub2newlthjx5kk2mco2aq44vxbqp5gwa3sifqxzfb3aqq" and then "git fetch origin keyring:keyring", guix pull with --url=... afterwards? <Rutherther>I am not really sure what the issue is since for me the verification passed <PotentialUser-76>i guess i didn't merge the keyring branch, so i am sending the result of git branch too <Rutherther>so you've never pulled before, right? just plain installation from that package you sent? <Rutherther>PotentialUser-76: just tried authenticating from 1.4.0 commit (the one that's used for the package) and it went fine. So I think the package you're using is broken <Rutherther>PotentialUser-76: so I would recommend using the official installer. You can even see someone else reporting the same issue in nov 2025 in the package comments <yarl>I was expecting that the cached checkout to be git-pulled (via ~update-cached-checkout~) only by ~guix pull~ (via ~latest-channel-instances~ and ~channel-news-for-commit~) but: ~guix system reconfigure~ and ~guix home reconfigure~ use it via ~check-foward-update~ via ~channel-relations~. <yarl>I think this is useless loads and connectivity (not that big but hey) both locally and on the git repo. <Rutherther>yarl: that's not relevant, since the forward check needs to pull the repo to check commit relations <Rutherther>even if latest-channels-instances were memoized, that's not what check-forward-updates uses <Rutherther>it's mostly a sanity check preventing new users from downgrading. For example when you install a new system without guix pulling, you would be downgrading. And worse so, each reconfigure would be downgrading more and more into the past <yarl>specifically, why we need to GIT-pull when we do a reconfigure since we'll only go to the last 'guix pull' <yarl>If there's no cached checkout, of course we need it. <yarl>But guix pull probably got us one that's here and if so, we can could check for forward update without GIT-pulling <Rutherther>reconfigure will fetch only when the commits aren't available in the associated cache <Rutherther>what you're getting at presumably is that the caches are different since you system reconfigure as root, so it's root's checkout that's being pulled <Rutherther>the cache is at ~/.cache/guix, so it depends on what user guix command runs as <yarl>Rutherther: I'm not sure we're talking about the same thing. <yarl>This will sort of "git pull" into ~/.cache/guix/checkouts/SOMESHA, right <Rutherther>yes, as long as the ref does not exist, if you read its source you will see "reference-available?" call that checks if the ref is available. If it is, there is no fetch <Rutherther>of course this assumes the ref is stable, ie. a commit hash, if it's a branch, you cannot rely on that. But on reconfigure it's a commit hash that's supplied to update-cached-checkout <Rutherther>see guix/scripts/system/reconfigure.scm, line 417, it passes in the commit ref <yarl>I'll read the blog post :p <lullaby>Recommendation for a pdf reader with dark mode on guix? I installed zathura but it won't open any pdfs for me. <Rutherther>lullaby: presumably you forgot to install the zathura-pdf-mupdf extension and relog / source the ~/.guix-profile/etc/profile manually to use it in current shell <lullaby>Rutherther: :boom: that did it! I had tried the zathura-pdf-poppler before with no success. zathura-pdf-mupdf works :) <jbnote>Hi there, i'd like to add #:ambient-capabilities and #:inheritable-capabilities to shepherd's forkexec constructor (which I need). Is here the right place to discuss this kind of patch? (i'm wondering how to make this properly conditional for linux, among other things). <Rutherther>jbnote: I think it will be better in shepherd issues <Rutherther>- to make the discussion more persistent and something to come back to easily <graywolf>I see we are still on gnupg 2.4.8 (2.4.9 is out for half a year), but more importantly, the 2.4 will EOL in two months. Do we have any plans here? <lilyp>From my personal experience, we update GNUPG faster than other distros, so we're still kinda safe. <dajole>Is there a way to surface guix deploy errors? I get `guix deploy: error: failed to deploy foo: remote command '/run/setuid-programs/sudo -n -- guix repl -t machine' failed with status 1`, which is not very helpful. <nnnn20430>i just spent few hours figuring out why things i manually build as normal user with gcc don't find libraries, and it seems gcc-toolchain package provides ld-wrapper to make sure ld always sets rpath, but at some point i installed binutils alongside in my profile, and it overwrote the ld in the profile <nnnn20430>ironically quite the side effect for a functional package system <sham1>It does make sense though, because what else could it really do when you have both gcc-toolchain as well as binutils in your profile's closure. One of them is going to in, and since you seemed to have installed binutils later, it does make sense that it takes priority. <nnnn20430>only makes sense if you know how the whole rpath ld-wrapper gcc-toolchain system works, if you're just randomly installing packages and all of the sudden things you build can no longer find libraries, it's very confusing