IRC channel logs
2025-09-22.log
back to list of logs
<ieure>Is there a reasonable way to dynamically define package variants in my channel, given a list of packages (or package symbols) from the Guix channel? <ieure>ex. I want (@ (guix packages emacs-xyz) emacs-slime) to have an emacs-slime/native variant defined in my channel. <ieure>But, instead of manually writing (define emacs-slime/native (with-full-emacs emacs-slime)) type code for every package, I want a list of packages (or symbols), and do this dynamically. <ieure>What's a reasonable way to do that? <ieure>I don't think `(for-each (lambda (package) (define ...)) (list emacs-slime))' will work, since that'll define the package inside the lambda, not at the top level of the package. <Serentty>Thanks everyone for your help earlier. I got an XFCE desktop going. Next I just need to install RADV and Plasma. <Serentty>I have noticed that in the Nix community, `nix-env` is usually discouraged. The `guix install` command seems fairly similar in concept. Does it work differently? Are there similar reservations around overusing it? <ieure>Serentty, It depends on your usecase and preferences. Genuinely don't know what the breakdown is, but there are definitely a good number of Guix users who prefer declarative package management over the mutable-env style `guix install' uses. <ieure>Serentty, Also, `guix shell' means you can use most software without having to install it. <Serentty>I have been using `guix shell` and found it pretty neat. I am curious though—does `guix install` have the same caveats that `nix-env` does with regard to upgrades? Do I need to upgrade packages installed using `guix install` separately? <ieure>Serentty, I've never used Nix, so I don't know what caveats `nix-env' has. There's no process which automatically upgrades `guix install'ed packages, you have to manually run `guix package -u' to do that (assuming you've run `guix pull' since installing some of them). <Serentty>And is that a different process than what you would use to upgrade the packages installed through configuration files? <ieure>Yes. `sudo guix system reconfigure' upgrades any in your operating-system configuration, `guix home reconfigure' upgrades ones in your home configuration. <Serentty>Okay. Is the home configuration where things installed using `guix install` go? Or is the home configuration separate from that as well? <ieure>"User profile" is what `guix install' puts stuff in. <Serentty>Ah, so you have both a profile and a configuration. Oh, profiles have generations but configurations do not, right? I think I kind of see what is going on here. <Serentty>For versioning the configuration, you would do something like track it with Git. But for the profile, it tracks previous generations itself. Right? <apteryx>sneek later tell hako in the cookbook, I read about rust packagig flow: "Don’t forget to modify all workspace members in ‘(gnu packages rust-crates)’:"; should it rather read s/modify/register/ ? <apteryx>Serentty: yes, no use for versioning or backing up "profiles", in general <Serentty>Yeah, I think I am starting to get a hang of how some of this stuff works. I moved all of the stuff that I had been installing while setting things up from my profile to my system configuration. That had some beneficial effects like giving them start menu entries when previously I had to launch them using commands. So I think the idea that I am <Serentty>getting from this about how it would logically make sense to use it is: <Serentty>Configuration: Long-term description of what you have on your system <Serentty>User profile: Medium-term persistent installation of things, such as for trying them out for a bit <Serentty>Shell: Spinning up an environment for a specific task <futurile>absolutely heaving it down with rain here, and really greeeeeeeeeeey - I miss summer alread <futurile>ekaitz: how's the streaming going these days - what are you focusing on now? <ekaitz>futurile: i'm working on GNU Mes. I rewrote the macro expansion in a separate step, so later we can compile the scheme source and make it faster. But now I have no idea of what to do with `load`, to keep it compatible with guile... <ekaitz>learning a lot but also... this thing is hard <efraim>apteryx I would try ruff or crates/ruff <apteryx>via the --manifest-path #:cargo-build-flags, right? <ekaitz>> This patch series introduces multikernel architecture support, enabling multiple independent kernel instances to coexist and communicate on a single physical machine <ekaitz>I can see the Hurd people saying: "Look what they need to do to mimic a fraction of our power" <apteryx>ah, #:cargo-install-paths is a thing <apteryx>efraim: neat! successfully built /gnu/store/5gil0q6wkykn4drx5f2zhjrz3d7scfdw-ruff-0.13.1.drv <ArneBab>ekaitz: ☺ (re hurd -- I’ve written about that a decade ago; the Hurd with sufficient care and polish would be awesome) <futurile>wtf, my brain is blow, Guile has a '1+' function - I literally thought it was a typo <ArneBab>futurile: that’s pretty useful for the most common recursion operations. The numbers-equivalents of cdr. <ekaitz>ArneBab: thank you! i'll read it carefully. I want to take part in the development of the hurd, but I need more context about it first. thanks! <andreas-e>futurile: The power of parentheses (and prefix notation)! Well, in C there is ++ and --, which is probably annoying to parse. <ArneBab>keep in mind that the article is from 2011 :-) -- the main takeaway is at the beginning: "The translator system in the Hurd is a simple concept that makes many tasks easy, which are complex with Linux … capabilities … subhurds" <futurile>yeah, I literally corrected it to (+ 1 x), and then was like "hmm this person knows more than me is that an actual mistake ..." <futurile>lucky, would have looked more stupid that way than mentioning it on a public irc channel that has a permanent log archive <ArneBab>futurile: think about stuff like (and=> (count-something) 1+) <ArneBab>⇒ if (count-something) returns something that’s not #false, increment it by one. <ArneBab>ACTION discovered (and=> ...) far too late in his path into Guile <ekaitz>futurile: clojure does `inc` instead. Which idk if its easier to read <futurile>ekaitz: yeah inc makes more sense to me, but probably because I started with Clojure. It is slightly odd in my mind to have beaten prefix notation into my brain, and then '1+' looks too close <futurile>thanks for that ArneBab - going to add it to my notes <ekaitz>futurile: (define-macro (+1 . rest) `(1+ ,@rest)) or something <ekaitz>why did I even think of a macro here? I'm obsessed with the expansion work i'm doing <lactose>is there a way to disable password auth in sudo? <identity>andreas-e: in C, ‘++’ and ‘--’ can be both prefix and suffix and they are supposed to do different things but so far nobody has managed to explain to me what the difference is and how the distinction could be useful <andreas-e>identity: It makes sense if the ++ appears inside a bigger formula. If I remember well (to be tested): <identity>common lisp has (incf place &optional (x 1)) to increment place by x, and ‘decf’ to decrement <andreas-e>a=5; b=2*(a++); Then b is set to 10, then a to 6. <andreas-e>a=5; b=2*(++a); Then a is set to 6, then b to 12. <kestrelwx>If you have 'if (i++ < limit)' and i is 'limit - 1' postfix is true and infix is false. <andreas-e>It is confusing and I tend to avoid it; for the most common use in for loops, writing i++ or ++i as a single expression makes no difference.' <nikolar>both post- and pre- increments increment the variable, the difference is wether they return to original value or the incremented <nikolar>but if you're not familiar with it, it can be non-obvious as to what it's doin <identity>handy to make your code harder to understand :3 <c0co>when defining a package's propogated-inputs, what's the correct input for explicitly specifying a version number for the input package? <c0co>for example in (propagated-inputs (list python-pyopenssl)), I want to specify that pyopenssl should be v24.0.0 if possible <ekaitz>identity: pre increment (++i) does the addition first and resolves to the added value, but post increment (i++) resolves to i but increments i later. <ekaitz>they are useful in returns for example: return i++ <ekaitz>well, returns maybe not the best example, but you get what I mean <obsolesins>Is xfce busted for anyone else? Ancillarily, has anyone defined a pipewire service type? <ekaitz>ArneBab: where shoudl I read more about the hurd? the website is terribly outdated and very hard to navigate <trev>what is the correct way to have guix-daemon use another directory other than /tmp? i'm trying to build a system image and it fails cause /tmp (my RAM) is filling up too much. I tried setting the TMPDIR env var for guix daemon but it didn't seem to do anything <mroh>--build-directory=/earth <trev>i think it will still use /tmp right? <futurile>trev: the manual says (in 2.2) that it supports TMPDIR, are you sure you added it and that you stopped the daemon/restarted it? <futurile>trev: I did a quick search of guix-devel, but can't find any references to it - so hmm <PotentialUser-46>Hi. I'm interested in using Guix system and package some games with it. But I don't have any background in programming so I wonder if Scheme is an easy or optimal route for beginning. I heard the SICP book is a good programming book, but is it sufficient for beginners? Should I take a short course in Python or something and then read SICP? or the <PotentialUser-46>My closest experience to programming is patching dwl and editing its config.h file, which is not real programming. My math is not great either. <mroh>trev: it looks like a feature: we have "*** ‘guix-daemon’ always uses /tmp in chroots, regardless of $TMPDIR" in the NEWS file. <PotentialUser-46>Hi. I'm interested in using Guix system and package some games with it. But I don't have any background in programming so I wonder if Scheme is an easy or optimal route for beginning. I heard the SICP book is a good programming book, but is it sufficient for beginners? Should I take a short course in Python or something and then read SICP? or the <PotentialUser-46>My closest experience to programming is patching dwl and editing its config.h file, which is not real programming. My math is not great either. <identity>PotentialUser-46: we heard you the first time <identity>PotentialUser-46: SICP is pretty good as a programming book, but might be a lot if you are just starting out. remember that SICP is a textbook that was supposed to be used for a full course of teaching students at MIT, so you want to take it slow; if you want to just get your hands on Scheme/Guile in the meantime, (info "(guix-cookbook) Top") has some examples and further reading you might find useful in the mean time <identity>especially (info "(guix-cookbook) A Scheme Crash Course") <futurile>Yeah, I would just learn by doing if your goal is to package something. Most of the packaging work is more about linux utilities (like how to use the compiler, or make), the Guix packaging format is probably not going to be the main thing. <identity>if your goal is to learn programming at large, i would still highly recommend SICP. there is a guix package for it, ‘sicp’, if you want to read it with ‘info’ <PotentialUser-46>futurile My goal is to become a programmer. I have other project ideas in mind other than just packaging apps, so the fundamentals matter for me. Guix is just the route I want to take to achieve reproducibility because I'm tired of configuring and managing my systems one by one. But the long term goal is beyond Guix. <ieure>PotentialUser-46, Agree with the others, SICP is not going to be a good text to help you become proficient at Guix packaging. <PotentialUser-46>identity I have the PDF version of SICP. GNU Info reader uses emacs bindings and its vim mode is not that good. <Chwoka>reading the gnu guix manual. what does the "profile" as in guix install --profile mean? it doesn't seem to mean user account. is it just a directory? <ArneBab>ekaitz: just ask in #hurd and the dev channels and keep in mind that the handful of devs are all volunteers. And the website isn’t as outdated as it seems: work is progressing slowly and without breaking much, so most content is still relevant. <isf>why is so hard to install GNU guix,/ <isf>Always when I do, then I can not just boot it. <ieure>isf, What kind of hardware are you installing on? <isf>In the thinkpad t420 <ieure>isf, Gotcha. I would make sure that you're running a current BIOS and your UEFI/legacy boot settings match how you're booting the installation image. <isf>I have legacy mode enable if im not wrong <ieure>isf, I have the same problem on a ThinkCentre M92p (~2013 vintage), it won't boot after install. But haven't had that issue on any other machine. <ieure>My dad had a ThinkPad X270 that was having similar problems with a different distro, a BIOS update ended up fixing that. <isf>I don't trust in lenovo or in other microcode distributor <isf>since all that things are satanist nonfree software, I reject it. <isf>There is not other way to jump over the issue and make it possible? <ieure>isf, No idea. Just saying, that's what fixed a similar situation. <ieure>isf, You know your CPU is running proprietary microcode blobs whether you update the BIOS or not, right? <ieure>Just, older, buggier versions of i.t <isf>ieure: I know, but i'm not tryng to justify it <trev>futurile, mroh: thanks. was unsuccessful setting it in guix-daemon and just as an exported env var. not even sure if that is my actual problem. just running out of ram trying to build the linux kernel derivation <futurile>trev: I guess you could get yourself more room by messing around with bind mounts and stopping/starting the daemon - sounds annoying! <trev>sigh...could also be that i'm on an atomic foreign distro and i had to make some tweaks to get guix-daemon working <futurile>it might be best to switch to using a plain vm <trev>shucks ok, i'll try that <Chwoka2>not really guix specific but more a terminal noob question: when i run a guix search for something simple i tend to get a lot of results, which is fine and good, but it wants me to just hold enter to load every next line. is there any flag i can set or terminal setting to just go ahead and load all the text? scrollbars exist, i can just scroll up <Chwoka>thanks. is that a verbatim terminal command for me to enter or an instruction for me the human? <jlicht>if you want it to apply only for the one command invocation <jbnote>Hi, I have what is probably a FAQ. Trying to package amd-smi (a rocm utility), part of the sources is a library file which is dlopen()'ing libdrm. As a result, the resulting .so file does not contain any reference to libdrm (which I setup as an input), libdrm's store path is not added to the .so file. amd-smi runs, but really needs libdrm to operate correctly. With an adjusted LD_LIBRARY_PATH, amd-smi is functional. I'd like <jbnote>package to avoir having to define the variable, obviously. What's the correct way to fix this? Should I manually add linker flags to add libdrm to the rpath during the .so file generation? this is my first intent, but there are other possibilities: chrpath the .so file after the build? Let binaries handle the situation, and wrap the generated binaries with a LD_LIBRARY_PATH setting? If you have any recommendation i'm all ear <jbnote>Also, in case I add the linker flags to add the rpath, will libdrm be picked up automatically as a dependency, or do i need to put libdrm in propagated-inputs? This is not clear to me either (but I will experiment). <gabber>jbnote: does amd-smi expect libdrm to be there in compiled/binary form? <jbnote>gabber: yes. It is directly dlopen'd() by the library. <Rutherther>I would probably patch the dlopen to refer to full path <jbnote>Rutherther: and add libdrm to the propagated input, I guess, so that it is present on amd-smi install. Yet another solution I had not thought of! thanks. <jbnote>As far as I understand, if an input is not detected to be a requirement of generated binaries, then it will not be installed automatically. The dlopen() call hides the requirement -- guix cannot pick up the fact that this input is actually needed, so I need to manually override to propagated-inputs. Isn't it working this way? <gabber>all inputs are *present* for that package, but are not *propagated* to a profile when the target package is installed. you add it to normal inputs and patch the package to make proper use of it, that's all (: <Rutherther>any input that is referenced by the output path is added as a reference. It doesn't matter where it's referenced. guix daemon cannot distinguish if the string is in dlopen call or in rpath <Rutherther>gabber: not all, all are present for the build. For the output of the package only the ones referenced are ensured to be present. Though, yes, that's usually all of them because you would usually remove inputs that aren't used <jbnote>Well, actually, I don't know, but I was under the impression that guix parsed the elf file to find the dependency (like what it does for validate-runpath), rather that exploring all strings in the binaries. If if parses all strings in binaries, then with your patch approach, it will probably catch the dependency, indeed. <gabber>so technically it is possible (or does that already happen) that the daemon can warn us of unused inputs? <jbnote>Rutherther: so if I follow you, just patching the file with an absolute path for dlopen(), means I will drop a mere string in the binary, which will be picked up by the dependency tracker. I understand, but this seems really quirky to me, no? <Rutherther>jbnote: guix daemon does indeed scan everything bit for bit, looking for store paths. There is no more 'magic' to it that would check how the path is actually used. This ensures that no matter the package you get everything needed as reference, ensuring it won't be gc'd as long as your package output is gc rooted by something <jbnote>Well, pure strings and actual binary dependencies are conceptually different :) One could just generate a bunch of strings just meant to be printed, so you run the risk of tracking a dependency which is not a real one. But I can see the other side too, where you can track data dependencies that would otherwise go unnoticed. <identity>gabber: guix can not detect whether something is only used during build, which would lead to false positives, but there is #:disallowed-references <Rutherther>no, they aren't different, both are regular strings <Rutherther>generating a string, like randomly? Seems quite unlikely it would match a real store path you just happened to have in inputs. But if it did, yes, then it would be referenced. This is such an unlikely scenario that I don't think it matters at all. Rather to keep it referenced even if somehow randomly pointed to than to miss a dependency <jbnote>Rutherther: it's a bit hard for me to be clear, but my remark was that (actual dependency) => (pure string dependency) but the converse does not necessarily hold. <Rutherther>gabber: I suppose, but I would rather not do that in the daemon, as I think it's already exposing the interfaces for doing that somewhere else - specifically you can just look at the references of the store path and compare it with inputs <jbnote>Rutherther: cool, then. I will try the patch route. Thanks for your insights! <Rutherther>jbnote: I don't agree, if you refer to the path from inputs, it's a reference - a dependency. If you didn't mean to refer to it, just don't do that in the first place. I don't see why you would keep the 'pure string' if not to meaningfully point to the package <Rutherther>and if you want to meaningfully point to the package, you need the package in the store, so it should be captured as dependency <jbnote>Rutherther: I agree. I had completely missed the picture; you actually have no choice for scripts, data files, etc. I've just looked at the blog post "the big change" for search-input-file, and it makes everything come together. My original view was very limited to elf binaries. <futurile>jbnote: part of it may be terminology, if you do a search for "references" rather than "dependencies" you'll find a bunch of things about this area and particularly dynamic languages <jbnote>Rutherther: thanks for taking the time to educate me. <jbnote>futurile: are you the one from futurile.net? Thanks for you very detailed articles on Guix! I've used them a lot lately. <jbnote>Rutherther: the proof of the pudding... I'll be able to submit a new package shortly! <jbnote>I just can't believe it's working with just a bunch of substitutes! It's pure magic! <futurile>jbnote: yes, thank-you for saying that - it's good to know that people read them :-) <futurile>jbnote: I'm working my way towards a post covering this very topic heh <gabber>futurile: of course we read them! <gabber>the good thing with Guix is that there is only limited material available, so stuff usually gets consulted (: <futurile>gabber: yeah the limited material is a lot of the reason I've kept going at them. <futurile>gabber: ofc, the big worry is that my misunderstanding / confusion / wrongness is then something that other people read <gabber>your honesty and clarity in dealing with the apparent confusion is what makes your texts so nice to read! <jbnote>futurile: Your articles are so detailed, it's amazing. It's very guix-y, fine craftmanship, and very hands-on. <ekaitz>futurile: should we help that dude in the mailing list that is trying to make a Guix planet? <jbnote>I've yet another newbie question for packaging amd-smi. amd-smi provides a python binding to the C library (which is built by the cmake process). The .so file that the python code wraps is duplicated under share/amd_smi/amdsmi/libamd_smi.so (it is also present under lib/), where the python wrapping code is also present. Is this something customary for python wrappers? I can feel that something is amiss; this copy is not cove <jbnote>checking/normalizing phases, for instance, and share/ is probably no place to put binaries into. Does anybody have any "good example" to look at for understanding python wrappers? <futurile>ekaitz: oh I didn't see that - that would be cool <ekaitz>futurile: i don't know how should we tackle that, but yeah... i think it would be cool to push the community a little bit <ekaitz>futurile: yesterday I watched an interview with Ton Roosendaal and he has very interesting ideas about how to empower communities... We might have some things to learn here. <futurile>ekaitz: there used to be a 'planet' code-base, I wonder if it still exists <ekaitz>futurile: someone mentioned that in the ml thread, yes <ekaitz>now i'm thinking about the changes I should apply to my blog to have a separate RSS for guix related things. I exploited the tag/category system quite a bit hehe <simendsjo>Maybe someone could explain the libxml2 issue, and why it's so hard to fix? Maybe someone has already written a blogpost on the subject (or a mailing list post) that I missed? <loquatdev>Hello, everyone. I am having a bizarre issue with hash mismatches. I have two machines, each running the exact same guix channel versions. One serves as a substitute server on my local network. When attempting to build the package on the other machine, it refuses to use the local substitute server for this package only. Curious, I decided to turn <loquatdev>the substitute server into a build machine for guix offload as well. When the other machine connects to the build machine, it perfectly matches the initial source and derivation hashes. However, it fails upon trying to download the binary from the build machine, with an error claiming that there is a sha256 hash mismatch. This is bizarre. I have <loquatdev>checked everything I can and despite producing the exact same derivation and checkout files in the store, they cannot and will not produce the same output or sync between each other. My suspicion is that it has something to do with grafts, but I can't prove it or get a different result using --no-grafts on either/both machines. <ieure>loquatdev, What's the exact error you're getting? Please use a pastebin, don't put it in the channel. <loquatdev>ieure, I'm running everything from scratch again to reproduce the different errors I received. I'll upload them here shortly. <ieure>loquatdev, Guessing.... Your build machine has bad network setup (ex reverse proxy), bad RAM, bad disk. <ieure>loquatdev, Can you wget the substitute and see if anything looks funky about it? <loquatdev>ieure, That would be odd since it's a relatively new device (Thinkpad T14 Gen 5 laptop). Every other package is substituted from it just fine. <loquatdev>ieure, As in, wget the index page it serves on port 80? <ieure>loquatdev, No, wget the actual NAR. <ieure>loquatdev, And narinfo. If you have request logs, the path should be in there. <ieure>loquatdev, Do either of those hashes match the upstream source? I haven't encountered this issue before, I *think* it's complaining that that NAR checksum doesn't match the narinfo. <gabber>how come i all of a sudden only get "signing fialed: Screen or window too small"? i don't think i've changed my gpg-agent settings since yesterday? <gabber>could this be related to issue #2801 ? <loquatdev>ieure, If it's no trouble, could you give me an idea of how to do that? I have a little knowledge about how the substitute servers work but I'm not sure how to actually find the narinfos. <ieure>loquatdev, Which? wget the nar/info(s)? <ieure>loquatdev, Easiest is to look at the paths in your server's request logs. I don't know where those are, because I don't know anything about your setup. <ieure>loquatdev, I believe the paths should be /llwsyignqi0q969yb2mss934fdi9jddm.narinfo and /nar/zstd/llwsyignqi0q969yb2mss934fdi9jddm-prismlauncher <loquatdev>ieure, I managed to find the paths and the server's request log. Thank you! I'm going to test a few on my secondary machine now <gabber>where can i find an example of fetching additional sources from a different repository in a package defintion?