IRC channel logs
2026-06-22.log
back to list of logs
<apteryx>hm, would someone know why in the guix checkout, the moment you step into a container, e.g. `guix shell -C`, you loose guile-readline support? I tried adding it to the manifest.scm but it doesn't change that <apteryx>ah, ~/.guile -> (module-ref module 'activate-readline), I guess <apteryx>(to use it you can use something like 'guix shell -C --expose=$HOME/.guile') <meato>can anyone help me figure out how to get KMail working outside KDE? it errors out immediately with `Unable to obtain agent type ''` <meato>akonadi is running and i can see the sockets in /run/user/... <meato>and more strangely i actually was able to get it to start normally once, but it then crashed when I tried to add an account <ruined>Hello. I am wondering what a typical --no-substitute install time should be for a small package. I am trying to install figlet without substitutes as a test, and it went for over 12 hours before encountering an error. <ruined>This is with guix on a foreign distro (debian) <iyzsong>though figlet is a simple package which doesn't have dependencies, it needs toolchain and glibc, guix will bootstrap all things from sources if without substitutes. <ruined>yes, I suspected that, thanks. I guess I was still surprised at the time taken. <apteryx>ruined: the Mes-based gcc toolchain bootstrap is very lengthy <ruined>ah yes i saw many derivations with "mes" and was wondering what it is <ruined>i didn't see packages with the "mes" bit in the repo <Alavi_me>How do you guys find which commit in guix contained a certain package or certain version of package? <futurile>Alavi_me: 'git log' right now (used to use the info service) <Alavi_me>futurile: So you keep a local clone of guix on your system with `git clone` and pull it and then search it with `git log`? <futurile>Alavi_me: yes, that's the best way currently if you're trying to search for a commit where a package changed. You'll need the commit for guix time-machine etc, so it's quite useful. <futurile>Alavi_me: there was an online service that we used, but it's not active any more after we moved to Codeberg <Alavi_me>futurile. Hmm. That really seems too much hassle. If guix cli added a command for that it would be awesome. I might actually make a CLI tool for it with scheme if I find the time. <futurile>Alavi_me: yeah agreed, there is a local git repo in the end-users set-up so you could probably do it. <futurile>Alavi_me: though, I think guix time-machine is pretty advanced, and there's lots of funny detail in using it <futurile>Alavi_me: under ~/.cache/guix I think - actually not sure as I don't mess with it <identity>what is the proper way to refer to a different package in a package description? just @code{package-name}? <untrusem>yeah go with it, reviewers will correct you if its wrong :p <Alavi_me>futurile: No I found it at ~/.cache/guix/checkouts like you said! thanks! <futurile>Alavi_me: just remember that's "live", if you change anything (e.g. you move the checkout) then your guix pull will easily be messed up <Alavi_me>> I think guix time-machine is pretty advanced, and there's lots of funny detail in using it < The thing is, how do I build, test projects that use old versions of something then? Isn't time-machine the preferred way? <futurile>Alavi_me: yeah sorry if that's confusing. It _is_ the preferred way and it's unique. But you need a good mental model of how it's all working together I think. <sham1>Time-machine and then probably inferiors might be the way to go, since then you can of course just pin the particular commits of your channels you want to target <nomike>I want to update the package "pythonscad" (I'm one of the developers of it). PythonSCAD supports both qt5 and qt6 but we recently switched to qt6 being the default. Thus I also want to switch the Guix package to use qt6. <nomike>The issue I'm facing: pythonscad depends on qscintilla, which is the code-editor widget we use. In Guix qscintilla depends on qt5. My plan is to also package qscintilla for qt6. But there are a number of existing packages which depend on qscintilla and use qt5. <nomike>As I understand the proper way is to switch the existing "qscintilla" package to qt6 and then create a new package called "qscintilla-5" which inherits from the other one and just replaces qt6 with qt5. This would require an update to ~10 other packages to change their inputs from "qscintilla" to "qscintilla-5". <nomike>Assuming this is the correct way forward, this raises a few questions: <nomike>Should I put this whole qscintilla refactoring into a single commit, or do I need to split it up in individual commits, one per affected package? <nomike>And what's best practice for how to put this into PRs? Should I do the whole qscintilla stuff and the update of pythonscad (and also openscad, which has the same issue and pythonscad inherits from it as it is our upstream project) into one PR or should I split them up into two? <nomike>I thought it's better to ask beforehand instead of guessing and then getting my PRs rejected, wasting time of people who review them... <identity>two PRs, one for qscintilla, one for pythonscad <identity>i would think the change for qscintilla and dependents should be a single commit <nomike>I though so too, as otherwise the in-between state between those commits would not build properly. <untrusem>you will need to make qscintilla-6 package and rename the curent to qscintilla-5 <nomike>untrusem, ah..OK. I didn't have that right yet. I didn't know about the "-6" suffix. I saw other packages where there is i.e. "qtbase-5" and "qtbase". So I though qt6 packages generally don't have a suffix. It seemed a little weird, given that this will require a refactoring again once qt7 is out, but I though that if that's the norm, I will just stick to it. <neonio>I have been triying `guix shell kdepim-{runtime,addons} akonadi akonadi-{calendar,contacts,mime,search} kmail -- kmail` <Alavi_me>futurile: Thank you for the great post! But one question. How do we avoid/fix the "Time travel bombs"? <Alavi_me>> pay attention to the fact that before October 2021 guix shell didn't exist <Alavi_me>so we can't use the `guix shell` command on a commit from before 2021? Doesn't that render the whole time machine functionality kind of pointless? <Alavi_me>Or today I got error about my guile version when using time machine: <Alavi_me>❯ guix time-machine --commit=f4a8081d24 --unsafe-channel-evaluation -- shell ruby <Alavi_me>guix time-machine: error: cannot travel past commit `4a0b87f0ec5b' from May 1st, 2019 <Alavi_me>If it isn't "really a time machine" then what's the point of a time machine? <jlicht>Alavi_me: you can't travel to timelines that don't (yet) have a timemachine ;-) <jlicht>The use is that you will always (hopefully) be able to travel back to anything that has the changes in 4a0b87f0ec5b contained in it (and not broken by some other commit) <Alavi_me>jlicht: Isn't that really limited usecase? I'm having problem understanding this because this basically negates the promise of reproducibility if I can't even get to that commit? <jlicht>Alavi_me: could you try to explain what you are trying to do? <Alavi_me>jlicht: For example, here, I am trying to build the Telerik UI docs for offline usage. <jlicht>ah no that won't work indeed; you could try with a newer version of ruby (we have 2.7.8 I believe) <Alavi_me>jlicht: But that doesn't work with the project <Alavi_me>My point is more hypothetical. If I want to create a declerative development environment for my projects using guix, so everybody can just get to work the project, I need Guix to be able to get an exact version of a package that was at some point in guix, and use it. Otherwise, this doesn't seem very different to me than just normal package managers in that regards. Things just get deprecated and you <Alavi_me>can't use them anymore. Am I missing something? <Rutherther>Alavi_me: I think you are correct and guix already offers this <Alavi_me>Rutherther: Sorry, didn't understand what you mean. Guix offers what? <tsmish__>Can guix system boot from bcachefs? From what I see in source code, bootloader code still requires /gnu/store to be available to GRUB. <gabber>tsmish__: not sure about whether it can boot from bcachefs, but GRUB absolutely does need access to the store <tsmish__>gabber: Do you know if somebody implemented copying kernel+initrd to /boot partition? I think it is actually all that grub requires. <gabber>tsmish__: i don't! but IIUC the problem is that every time you reconfigure your system you'd have to repeat this step <Rutherther>that's exaxtly what the guix bootloader installer does, it runs code to install the configuration for a new generation on every reconfigure <gabber>Rutherther: i did not intend to problematize this per se, but i wanted to warn tsmish__ from attempting to do this manually <Claude42>Hello. How can I define extra licenses? Stuffing a symbol into (license) field does not work, and constructor in (guix licenses) is non-public. <gabber>Claude42: You mean add a license that is not yet part of (guix licenses)? <Claude42>Yes. It is not a free license, so it does not make sense to add upstream to Guix proper, but I would still like to track it for packages in my channel. <gabber>you can reference non-exported symbols via the (@@ (foo module) some-symbol) expression <Claude42>In my experience it does not always work, due to them sometimes being elided by compiler. So I try to avoid that, but will give that a try. Thanks. <mwette>e.g., `(define foo-license ((@@ (guix licenses) license) "Foo 1.0" "https://loc" "comment"))' <bjc>~/src/guix/master $ ./pre-inst-env guix build -s x86_64-gnu --without-tests=emacs-minimal emacs-minimal → /gnu/store/gsiqv1jl8nwgpncaqbbq9rv1gr4g3wd6-emacs-minimal-30.2 <bjc>failed tests are unix process related, but haven't looked deeper <gabber>are you running the Hurd on bare metal or in a vm? <postroutine>Does grub is re-installed in it's partition target every time I do a `guix system reconfigure` or when I switch to another system generation ? <bjc>reconfigure will reinstall grub, booting into other generations shouldn't <identity>i think the question was about rolling back to a different generation <bjc>i *think* grub is ontly reinstalled and the grub.cfg rebuilt during system reconfigure, but i'm not 100% on that <bjc>i don't believe rollback will touch it <Rutherther>switching a generation through guix system command will also install the bootloader so that you boot to the correct generation <postroutine>From what I understand, it use the commande `grub-install` to install grub, it's modules and 1 font. <postroutine>But `grub-install` will not install the keyboard layout file. It will still in the store. <ieure>postroutine, It's a known bug that Grub keymaps are broken. <yelninei>bjc: Iirc an earlier version of emacs had no test failures but I might be misremembering frm 1.5 years ago <postroutine>I was exploring how Guix System install and configure Grub, in case I could find a fix. But it's maybe too soon for me. I lack enough experience in how Guix System work internally. Especially when it's about the bootloader. <bjc>yelninei: hopefully whatever changed is straight-forward <sham1>I wonder why the whole "copy kernel and whatever else is needed to the ESP" thing isn't a default at least on platforms like x86_64-linux with bootloaders like grub-efi-bootloader <ieure>sham1, It's to keep that stuff on the encrypted partition. <sham1>The encrypted partition that has to be LUKS1 because grub still lacks the appropriate KDF support for booting from default LUKS2 encrypted partitions <orahcio>Hi, Does somebody have a openvpn-client-service-type example? <identity>csantosb: i think the Guile docs are under there, but the prospect of adding more projects might have stagnated <tsmish__>Is it possible to fork guix monorepo while preserving authentication? My key is not in .guix-authorizations and I think I can't add it myself as the commit that adds it won't be signed. I had a patch that added ability to add trusted keys to channel introduction. Is that still necessary or has a better way arisen? <ieure>tsmish__, Forking is possible, but difficult. For `guix git authenticate' to work, you have to rewrite history. <tsmish__>ieure: but that will break all signatures that are already there <ieure>tsmish__, That's implied in "rewrite history." <ieure>tsmish__, You have to rewrite history in a way which replaces those signatures with a key in the new introductory commit. <ieure>You can squash every commit into one and sign that; or replay history and sign every commit with your key (or some other one/s you set up). <yelninei>cant you authorise your own key and change the introduction commit to that? <Rutherther>tsmish__: it is possible, without rewriting any history, no need for that. Just change the introduction commit <Rutherther>tsmish__: yes, exactly, authorize your key and change the introduction commit to it, of course it means you cannot easily rebase on upstream master then, as every time you would be changing the introduction commit and have to change the definition every time <Rutherther>so if you are going to fork, possibly better to merge from upstream guix to your guix. Unless you want to redo the introduction commit as part of every guix pull <tsmish__>I have this memory of someone implementing something like that in upstream. <Rutherther>tsmish__: so apart from the .guix-authorizations you would have a set of trusted keys in your channel definition? <tsmish__>Rutherther: Yes. I need to add a commit to a branch that would pass authorization. <tsmish__>Not that I'm planning to fork guix right now. Last time I tried it, it was rather painful with updates requiring git pull, git rebase, guix pull. But I may require it and looking if something changed since then. <orahcio>How to turn off auto-start of openvpn-client-service-type? Is there any way to do that? <ieure>orahcio, It would have to be a configuration option; I don't see one. If you don't want the network connection running all the time, you're probably better off using Network Manager for it. <orahcio>ieure: So, if I do not use Network Manager I need to disable openvpn-service-type by `herd disable ...`, Is there no way to do it on the configuration file? <Rutherther>orahcio: https://paste.debian.net/hidden/1c161008 here is a generic function to turn off auto start of any leaf service producing shepherd services. It will not work well on non-leaf guix system services (the ones you extend further). So for openvpn-client-service-type it could work fine, since there are no extensions in guix channel and you typically do not need to extend it further <Rutherther>orahcio: herd disable disables it only for current boot <orahcio>Thanks Rutherther and ieure, I will try without Network Manager at first <ieure>orahcio, For it to not start, the service-type's configuration record would need an option to not start it by default. Since it lacks one, you can't have it do that. <Rutherther>I disagree, the code I sent does exactly what orahcio is asking for <orahcio>ieure: Maybe openvpn-client-service-type needs one patch to add a auto-start? field, right? <ieure>orahcio, That seems like a good option, yes. <Rutherther>it's a bad option, despite being the only proper one available <Rutherther>it's a bad option, because it's obvious people will want to customize their services, so the services do or do not autostart, so why should every guix system service expose auto-start option... that's solving the issue at the wrong level <orahcio>Rutherther: many *-service-type has auto-start field, guix shepherd services already solve this issue by adding or not this field on it service definition, Am I right? <Rutherther>orahcio: yes, unfortunately they do that, because as I said, there is currently no better solution <orahcio>Rutherther: yes, I also think so, auto-start? would be a standard field for all services, with #t value by default <Rutherther>which is exactly what I am saying, you would have to add the same thing to every service, solving it a the wrong level, it should be solved at a more general level to allow this behavior for all services while not repeating over and over auto-start? in all configurations <simendsjo>Are there any up to date git mirrors? I'm unable to pull and need update an old computer. I thought I could do a "sync" in the codeberg gui, but even that gives a 400. <simendsjo>.. correction. I get 400 or 504. I hate that codeberg is getting ddosed constantly :(