IRC channel logs
2025-07-30.log
back to list of logs
<Septimus>hey am getting into using guix linux, decided to relearn scheeme, and wanted to know what the best way to learn guile is. <Septimus>Just poking around the reference manual? <forkbombidable>Hello, I am wondering: when editing scheme files for your system, such as system config or home config or manifests, how do you best integrate Geiser to provide jump to definition, docs, etc? I changed geiser-guile-binary to be guix repl. But it is extremely slow to where it isn't really usable. I think it is because by default the GUILE_LOAD_PATH doesn't contain compiled scheme files. If I check out guix and build myself, when <forkbombidable>browsing the repo Geiser works great. Any advice? I could just add my local build to the GUILE_LOAD_PATH, but I would prefer if it used the system install of guix so it is always in sync. <mfg>is there a home service to start emacs as a server? <apteryx>mfg what does 'guix home search emacs' say? <mfg>jeez, there is a guix home search function :D i did not even know that <mfg>I see, i'll look into it <Kabouik>identity: thanks, indeed it seems the emacs-tree-sitter and emacs-tree-sitter-langs packages are not what I wanted, I was mislead by their name, but they seem to be there to build grammars from Emacs after they have been loaded, which is not very guixy. I didn't expect that the grammar packages I needed from the Guix channel do not have `emacs-` in their names. I had them installed at some point but what I was missing was the documentation stating the <Kabouik> names of the modes (i.e., r-ts-mode`, while I was looking for things named `treesit-*` or `treesitter-*` something). <Kabouik>Actually r-ts-mode is a bad example because I don't have it (which made my testing more difficult), but python-ts-mode exists for instance. <identity>Kabouik: the first hit for ‘tree-sitter’ in the emacs manual points to (info "(elisp) Parsing Program Source"), which likely has all the information you are looking for <gabber>why does `guix git authenticate` try to authenticate a commit that is not in the local branch? <gabber>i signed a commit but now `guix git authenticate` fails because the previously unsigned commit is indeed unsigned <human_equivalent>Does anybody have a working dovecot-pigeonhole setup I can look at? It just complains to me about "Unknown protocol: sieve". <jakef>im having some issues with home-dicod-service-type lately. 'telnet 127.0.0.1 2628' ends with "Connection closed by foreign host." <jakef>ah nice, i found some errors in shepherd.log :) <sneek>Welcome back andreas-e, you have 1 message! <sneek>andreas-e, jlicht says: thanks! It should most certainly build, as I just synced it up with master. I'm just planning to start merging stuff into it soon <ekaitz>andreas-e: did you experience GDB not being buildable? in x86_64 <andreas-e>ekaitz: I did not try, my programs have no bugs ;-) <ekaitz>../../gdb-14.2/sim/frv/sem.c:24344:41: error: passing argument 2 of ‘sim_queue_fn_di_write’ from incompatible pointer type [-Wincompatible-pointer-types] <ekaitz>i mean, this is a very important package <ekaitz>idk if this is affected by core-updates <andreas-e>Okay, I will have a look. I am getting experienced in repairing these gcc-14 related problems. <andreas-e>That looks like a typical message, which what used to be warnings, now transformed into errors.' <noe>ekaitz, pulled today and my gdb is fine <noe>okay this one has no substitutes <noe>also its not the same version has gdb? <andreas-e>I do not know why we have three different gdb versions. <ekaitz>multiarch is supposed to be inheriting from the default <andreas-e>And gdb-multiarch has no substitute, which probably means it does not build. <andreas-e>gdb@14 has a few dependents, gdb@15 and gdb@16 have none. I think we should try to update the inputs and drop the older versions. <m4xxed>Hello, how can I find out which package pulls in pyyaml as a dependency on my system? For some reason python-pyyaml doesn't pass it's tests... <sneek>m4xxed, csantosb says: guix emacs-lsp-mode package is not outdated, latest upstream release is 9.0.0; problem is this is from 1 year ago <ekaitz>andreas-e: the code says we have a gdb pinned to avoid massive rebuilds... <andreas-e>Ah, this one is hidden, nasty trick! So I did not see it on the command line. It looks like a world rebuild to make a change there. <andreas-e>And the file is not owned by any team; it could probably move to the c++ team (with only one member). <andreas-e>gdb@14 contains a phase that is supposed to be dropped after gdb@12; but it turns out that gdb/pinned inherits from it and is at version 12. I think we will have to schedule a rebuild at some point in time! <andreas-e>ekaitz: All this does not advance us for multiarch. I will quickly have a look. <andreas-e>ekaitz: This was really simple, just an update by moving the inheritance. You could test whether it works, I just checked that it builds. <ekaitz>also somebody screwed up with kicad <ekaitz>we have a hash mismatch on the footprints <andreas-e>Hm? I just downloaded the source without a substitute, and the hash matches. <ekaitz>csantosb: kicad symbols and such are pinned to kicad version, if we update kicad, the footprints and so on are also updated magically <ekaitz>andreas-e: it's kicad-footprints <ekaitz>and the issue is kicad was updated to 9.0.3 but the footprints' hash wasnt <ekaitz>and the kicad-footprints are tricky because their version is (package-version kicad) <csantosb>ekaitz: what ? I spent the whole night to build all the kicad dependents before submitting ... <ekaitz>csantosb: footprints and such are not dependent <ekaitz>but when you change the version of kicad, their version changes <ekaitz>i don't know who had that idea, it's kind of a recipe for disaster <ekaitz>take a look to the engineering.scm file and read the version of kicad-footprints <ekaitz>csantosb: or see: 90b0d2936b90e7a892fc43bf176977a8043ff732 (a lot of fun that i didn't mention the hash change in all those packages in the commit text...uuups) <csantosb>doing that ... sorry, I misunderstood the whole thing; I assumed all the suite was coherent with respect to the version <ekaitz>csantosb: it should be, but there's no way to do it properly because of the hashes <ekaitz>maybe we could provide the suite in a superpackage with everything so we could try to install that and see everything fail <csantosb>I see ... I naively though a build --dependents would do it <ekaitz>csantosb: you don't have to do it yourself, or do it now, I can do it later <ekaitz>this kind of fake dependencies are a pain in the balls <ekaitz>i meant one package that has all kicad-* things and propagates them <csantosb>problem is it takes so long to build, that it becomes error prone <ekaitz>at least building kicad-full would break in the subpackages <ekaitz>or we could leave a comment in the kicad package version or idk <ekaitz>it's not obvious that the -footprints take the version of the main package <csantosb>ok, i'll have a look a bit later; kicad is one of our shinning packages <ekaitz>csantosb: don't worry, I can do it <dariqq>ieure: I was able to trigger the e2fsprogs "Recovering journal" message by adding a replacement for the 'root-file-system. It did not work reliably though. I made a new issue on codeberg with links to the older ones <jlicht>dariqq: thought I was going crazy for seeing that (what I think) every single reboot XD <untrusem>my friend says guix needs to prioritize on adding new build systems <dariqq>jlicht: I usually only see it after a system reconfigure. I rebooted a lot today to test various things but I dont really want to risk data loss on my laptop and have not yet figured out how to reliable trigger it <dariqq>i am not even sure if it is related to shepherd replacements but at least that would explain why the system reconfigure specific part <gabber>csantosb: i figure you built and tested the 3 packages of PR#1706? <Rutherther>the last time I was able to reproduce it, with older version of shepherd, it was triggered by shepherd replacements. Running the upgrade script sufficed, no full reconfigure was needed <Rutherther>this issue then went away after shepherd upgrade <jlicht>fwiw, I see it on both my luks and luks-less systems on ext4 <ekaitz>gabber: i'll merge myself, don't worry <csantosb>Looking forward the day where we have a ci online <untrusem>identity: They recently switched from Nix so they want all the best system does Nix have <Rutherther>great opportunity for them to contribute to make the system better for them and others! <csantosb>ekaitz: by the way, is there a kicad-doc@3.0.3 ? <csantosb>9.0.3, right; one more, let me one minute <ekaitz>csantosb: you didn't fix -templates properly <csantosb>ekaitz: I had to remove the change for me to build now; better check that one from your side <csantosb>Guix is making me bad jokes with sha's and store items from time to time when I switch branches <ekaitz>csantosb: kical-symbols <--- check the L in KicaDDD <ekaitz>csantosb: leave them as they are, but I would've written "update hashes" in the commit, rather than fix build (it's too generic) <csantosb>ekaitz: I can do that in no time, you tell me <ekaitz>i prefer it, but many commits in guix are pretty bad in terms of specificity <ekaitz>also, here I prefer everything in one commit, but guix guidelines go against it <csantosb>ok, let me 30 secs, emacs is my friend ;-) <ekaitz>i love how codeberg complains about the manually merge commit by telling you it doesn't exist <ekaitz>but what it actually means is to use the full commit-id <ekaitz>csantosb: merged, hopefully properly <ekaitz>i only had to reopen the issue once hehe <csantosb>Thinking if it is possible in the codeberg era to join pr and commits 🤔 <zeropoint>Has anyone here gotten any nim package built? I'm running into issues and trying to hack together a solution to work around nimble requiring network requests and full git repo functionality... <gabber>drewverlee: i think the difference is mainly that install.sh installs a fairly recent Guix whereas apt installs some legacy version (which then should be upgraded via `guix pull`) <drewverlee>so no real difference given i need to run guix pull anyway. <gabber>it is possible that `apt install guix` is a bit more cumbersome than our installation script, but i have too little experience with either <drewverlee>even sudo apt install guix prompts me to answer at least one question, maybe the prompts down happen if you run the script in a certain context? <ieure>drewverlee, `sudo apt -y install guix' <vagrantc>apt install guix is actually more straightforward by a long shot, and actually has more security patches than what you get when you use the install script ... <vagrantc>but once you properly pull to the latest version for root with the install.sh script, you'll actually have more vulnerabilities patched that way <vagrantc>pretty likely the Debian package will get removed soon <Rutherther>if guix made new release, would the package be removed from Debian either way? <vagrantc>at least, i *think* the install script installs a bare, unpatched 1.4.0 ... whereas the Debian package includes some security fixes to the daemon ... <drewverlee>i'm laughing that the hardest part of being a package manager is managing other managers packaging you. <vagrantc>Rutherther: probably at this point, as we cannot maintain a stable package against a rolling release <vagrantc>Rutherther: the recent security fixes are proving hard to backport due to unrelated changes <Rutherther>yeah, I have seen that. But if that's the reason, I would expect new release of guix would 'fix' this <vagrantc>if downstreams had been notified months ago, maybe we could have figured something out, but debian is scheduled to release in just over a week <vagrantc>Rutherther: not for old versions, as debian only backports fixes ... so the current stable release *should* get security updates for at least 2+ years more <vagrantc>Rutherther: and that also does not prevent future changes from making future security updates difficult <ieure>As a user, I like Debian's approach of minimal changes to stable packages. As a developer... ugh. <vagrantc>although interestingly, someone recently mentioned that the vulnerability reproducer failed on Debian, so it is *possible* that something Debian is doing fixes the issue in some other way? <vagrantc>(e.g. some security context with systemd, security related compiler flags, etc.) <vagrantc>it could also be that the reproducer fails for some other reason <vagrantc>or that the issue was introduced more recently? <vagrantc>if you actually want to keep guix on Debian (and debian derivatives) ... NOW would definitely be a good time to lend a hand <Rutherther>so basically someone needs to backport the changes to 1.4.0? <vagrantc>there is a thread on guix-devel about it and a bit on that bug report <gabber>is there a dovecot-configuration i could glance at? <vagrantc>i will also be busy this week with FOSSY, so ... will not have much time to poke at it <drewverlee>vagrantc are you suggesting guix might become un-usable on Ubuntu in the near future?[ <vagrantc>drewverlee: as a package, yes. the install.sh script will probably be available still <Rutherther>why on ubuntu? and why would it become un-usable? You can always use the install.sh <vagrantc>drewverlee: in any case, it is currently affected by serious vulnerabilities in the daemon, unless you've manually switched to using a guix-daemon provided by guix itself <vagrantc>at which point, there is nothing left of the package, really <Kabouik>I absolutely do not have the skill to help, but a package does make Guix package manager more discoverable to Debian (or derivatives) users and they are more likely to trust it, especially if they're not skilled or up to reading sources. <drewverlee>ok, your saying people wont' be able to install it using apt-get. Thanks for helping me understand. <vagrantc>i mean, most downstream distros will probably continue to ship the vulnerable version... :( <vagrantc>so people will be able to "apt install guix" ... it will just be vulnerable. <vagrantc>Kabouik: yeah, i liked that it added a trust path to guix, rather than the install.sh script where you blindly trust the same site that is shipping the install.sh script to tell you what the correct signature is <vagrantc>but it has honestly been a lot of work to maintain guix just for that trust path... <vagrantc>maybe a better approach for the future is to write up a guix-installer Debian package, which gets you the trust path, but installs the rest of guix with guix itself <vagrantc>i would be happy to orphan all the guile dependencies and what not that are only there for guix <Kabouik>I am advocating among my group for Guix as a solution for reproducibility, and to be honest it's already difficult as is because they find it overwhelming and usually don't like an extra package manager or a change of paradigms, but having a package for the most common distributions was an asset that helped making them even consider it ("if it's packaged for my distros, then maybe it's not that niche, and at least it's not a fishy sh script"). But <Kabouik>don't get me wrong, I fully understand that this may be a dead end in terms of maintenance, just listing some benefits among non-Guix System users. <Kabouik>vagrantc: if that better approach would pass whatever prerequisites there are to be included in the Debian repository, i.e., just packaging the .sh script, then that'd be great indeed. <vagrantc>Kabouik: yeah, i get all that... I've been working on the guix package for over 5 years now ... not without reason :) <vagrantc>although i do doubt my ability to reason sometimes. :) <vagrantc>the only reasonable way to keep doing what we've been doing is if there is an upstream team of folks backporting patches to the last point release as a first-class part of the project <vagrantc>which *just* needs the people to do the work... <vagrantc>it only happened to work the last 5 or so years because little development actually happened on guix-daemon specifically <vagrantc>e.g. up till the more recent batch of security patches, most guix-daemon patches could be applied to guix 1.2 with little to no changes <Kabouik>I did not mean that as a complaint but rather the opposite to tell that all this work was appreciated vagrantc! I don't know if a solution will be realistic, I hope something can be done in a maintainable way, but in any case, thanks for having carried that package so far. <vagrantc>guix got a little bit of QA out of the process of being packaged for Debian, too. <drewverlee>why do the guix docs recommend logging out after installing? I'm asking because i need to automate the deployment of guix across several machines and i'm a linux newbie. If it helps, i can right a blog post at somepoint about what i did so that people can do my job for me by showing me how i should have done it. <drewverlee>I assume the important thing is somehow re-setting the PATH (i love how arcane that sounds). <drewverlee>so maybe i just source all the relevent files like /etc/profile, ~/.profile, ~/.bash_profile, ~/.bashrc ? <ieure>drewverlee, If you have a controlled setup where you know what you have to do, that works. But it's likely not a problem unless you're installing Guix, then immediately trying to use it. <ieure>drewverlee, "Log out and back in" is the stupidest thing that could possibly work for the various cases where people install Guix, so that's the recommendation. <drewverlee>were installing guix on ubuntu then using it to install some packages, so that we can launch a webserver. <drewverlee>i see what your saying "log in and out" will likely work across a lot of linux distributions. <ieure>drewverlee, Distros and shells, yeah. The files you list work fine for bash, but probably not for zsh or other shells. So the docs just say to log out and in, it's a big hammer, but is simple and works. <ieure>If you have a more controlled environment, you can do something else that makes more sense. <drewverlee>honest and curious question. Should i ditch zsh? I picked it up because it had vim bindings that i was used to, but i'm getting the impression, as a heavy emacs user, that i'm doing myself more harm that good. I do however, really using the vim mental framework for moving around text. It's very low friction and mental overhead. <drewverlee>as a heavy emacs user and aspiring guix user_oreloznog <drewverlee>argh, i didn't mean to ping you orelozng. tab complete mistake. <ieure>drewverlee, Up to you, really. I don't use zsh, but it does have some improvements to things like "what dotfile does the shell source in which circumstance" which are a legacy complexity nightmare in bash. <drewverlee>k. yeah, like most things, the only to learn is to play. I'll try ditching it and see how it brakes me. <ieure>I try to use actual shells as little as possible, I prefer higher-level Emacs tooling. And when I do use a shell, I use shell-mode. All the fancy new shells (and even features like programmable completion, which was gracelessly shoehorned into bash), so as far as the actual display/interaction, they're never better than bash and often worse. <ieure>Unsurprisingly, I'm also Team Emacs here, I've been using it daily for over 25 years, the more stuff I can do inside it, the better. I've been daily driving EXWM for around 7 years. <identity>drewverlee: pretty sure GNU readline lets you turn on vi keybindings if you want to stick with them, and the obvious ‘third thing’ in this situation is the fish shell <vagrantc>much to my surprise, after 25+ years using bash... <identity>i generally avoid shells myself, though if the stars align i use ‘eshell’; technically i use bash as the login shell though it has been some time since i actually directly touched it <identity>guix.el should get an eshell integration, maybe that will make me use eshell more <ieure>Its normal shell integration has been broken as long as I've used Guix. <drewverlee>Why did you gravitate towards using fish vagrantc ? <ekaitz>another build error: opencolorio fails <andreas-e>I mentioned that there is only one test, but did not manage to disable precisely this one. Disabling all tests is a solution, but maybe goes a bit too far. <andreas-e>Message to all: Search on codeberg! It saves you creating a duplicate issue; I have seen quite a few cases of this in the last days. <vagrantc>drewverlee: i first started using it on a linux-first phone, where the on-screen keyboard was limited, and the various completion options were an amazing improvement <vagrantc>drewverlee: and eventually started using it everywhere <vagrantc>drewverlee: just out-of-the box, no configuration, has quite nice completions ... and it is not *so* different if i am stuck on a machine with only bash i do not feel lost <vagrantc>i would highly recommend it as a shell for people just starting with commandline stuff <vagrantc>andreas-e: yeah, and the search on codeberg is quite responsive, too :) <ekaitz>does opencolorio upstream say anything about it? <ekaitz>hmm i don't see any issue open upstream, maybe we should <tux0r>back in my day, we didn't need search on random version control websites. we still did a pretty good job writing software. it all went downhill when hosting code ("devops") became a paid job. <tux0r>(old man yelling at the cloud.. i know) <vagrantc>yeah, nobody ever misplaced a bug in a random email <tux0r>i wonder how many working hours are lost ("spent") with managing arbitrary vcs infrastructure <PotentialUser-94>Hello, everyone. I've got what I think is a simple syntax problem. I'm trying to use a variable inside aliases in home-bash-service-type. Here's my code snippet: <csantosb>PotentialUser-94: Better use a paste online service, rather than showing your code in here <csantosb>Look at the one you have at the top right <Kabouik>vagrantc: I'm a happy Fish user too, for mostly teh same reasons you've listed. I do observe some hiccups with that workflow though, when I need to use another machine and miss my comfortable habits (but I tend to guix pack fish and transfer it to servers if I'm not admin on it) and mostly the fact that many software or configuration examples do not expect usage in Fish, so there's some tweaking necessary here and there, and most of the time I'd <Kabouik>rather not spend time on that. I also have some issues with the ssh agent in Fish, especially to manage distinct Sourcehut accounts, and web searches have shown that ssh-agent and Fish are indeed a topic of discussion. <csantosb>Hola ekaitz, I've been thinking on the kicad-all topic you mention just before <csantosb>Does it make sense to include all kicad-* as native (fake, unused) inputs to kicad ? Kind of using kicad itself as meta-package. Every time version increases, this would force all remaining packages to be built first. <csantosb>Probably not the most elegant strategy out there; not aware of anything better <ekaitz>i don't know, it's probably better to add an extra meta-package <ekaitz>if things depend only on kicad, that might be an issue, because the closure would become huge with the data <andreas-e>nomike: This looks like an error in the database on CI. You can do a "guix pull --no-substitutes" and build the derivations yourself. <nomike>andreas-e, thanks, I'm doing that already. Should I report this somewhere or is stuff like this monitored or self-healing? <andreas-e>I think there is no point. We have seen inconsistencies in the database recently, but there is nothing one can do... <nomike>Nahh..what I meant with "self-healing" is whether this database will be regenerated frequently, so the issue will just disappear on it's own. <andreas-e> In this case, it will be self-healing in the sense that people in the future will pull to a newer commit, so the thing you try to download will have changed. <andreas-e>I think it will heal on "guix gc", but I am not really sure. <teddd>how do you build a package directly in guile, ie. not in the repl ? <teddd>can I do (build my-package) ? <teddd>I want to be able to use package-file on a package, to access some of its output. But I need to ensure it has been built <ieure>teddd, You say "not in the repl," but both examples you gave are commands that only work in the REPL. <ieure>teddd, `,build' is a Guile REPL metacommand that does what you're asking. You have to use the (guix) module for that to work. <ieure>teddd, By "not in the REPL," do you mean something like `guile -c (build some-package)' ? <umanwizard>can anyone explain the difference between the glibc in commencement.scm and the one in base.scm ? <umanwizard>Here's why I want to know: I need to debug some libc functions with gdb. I am trying to get it to find the debug symbols. But unfortunately, it seems when I install "glibc:debug" it is using the glibc from base.scm, whereas programs on my system are actually linked against the glibc in commencement.scm, so they don't match ... so I'm wondering how I can install debug symbols that actually match the programs I have <ieure>umanwizard, The stuff in in (gnu packages commencement) is what bootstraps Guix. <umanwizard>If I use the gcc from gcc-toolchain to build some C program (without passing any weird cflags or ld variables, just everything default) -- which glibc would you expect the resulting program to link against? <ieure>Are you talking about a package built with gnu-build-system, or one you're compiling manually? For the Guix package case, I'd 100% expect it to link against glibc from (gnu packages base). Checking a package I created for a C program which uses gnu-build-system, that appears to be the case. <teddd>ieure I don't mind importing a module <umanwizard>ieure: so for me, the glibc against which "ls" is linked and the one I get from doing "guix build glibc" are not the same <umanwizard>brennan@eugene ~/code/guix$ ldd $(which ls) | awk '/libc.so.6/ { print $3 }' <umanwizard>/gnu/store/jq88z2ai48i9s6b3alm98z1rswrlrvs3-glibc-2.41/lib/libc.so.6 <umanwizard>brennan@eugene ~/code/guix$ guix build glibc | grep -Ev debug\|static <umanwizard>/gnu/store/i1cbahx4692f3xiicfgisf06a4kgz1vs-glibc-2.41 <umanwizard>and I believe the former is from commencement and the latter is from base <teddd>so something like `(use-modules (guix something))` followed by `(build my-package))` would be enough <umanwizard>is there an easy way to tell which package tehse derivations come from?