<jab>jgart[m]: why not artanis? <jab>it's guile scheme... <jab>I'll admit everytime I tried to use it the documentation seemed a little light... <jgart[m]>jab: With the above I just meant that we need opinionated development guides for various languages, including guile, common lisp, haskell, rust, go, etc... <jgart[m]>I tried using artanis before for a project but it wasn't a pleasant experience. Maybe, I didn't give it a fair chance. When I find the time I'll try it again. <jgart[m]>Lately, I've been using common lisp for web development with GNU Guix <jgart[m]>Common Lisp is quite comfy for web development I have to say. The debugger environment is first class. <atka>I'm curious as to why there is so much tab completion lag with a variety of guix commands, can it be remedied? <lfam>atka: I don't know the full answer off the top of my head, but I guess it's because the results must be computed and that is slow <lfam>For example, if you want to tab-complete the name of a package, I don't think there is a big list of packages in a text file that the shell can choose from "instantly" <lfam>Instead, Guix has to collect the list of packages and then the lookup can occur <lfam>Overall, it's just not optimized <atka>ok no problem, just curious, thanks! <florhizome[m]>Infam: I concur that is just how the package is packaged at the moment. This one is an update. In general, the importer only works for stuff that is hosted via the gelang proxy, right? <florhizome[m]>But if the GUILE_ env var is meaningless it just becomes completely random lol <florhizome[m]>I really just wanted to give you it a GO but it seems that’s not what that name actually means <zamfofex>Hello, everyone! I have recently decided to investigate the status of the Hurd once again (and my efforts to get networking functional), and I concluded that my work in <https://issues.guix.gnu.org/51770> is slightly disfunctional *because* I hadn’t updated MIG alongside the other packages. <zamfofex>While trying to update MIG, I concluded that it is not currently trivially possible due to a change in Mig that makes it incompatible with glibc 2.33. Any glibc version after commit 0eb230ccceee70c4b5d2a75807d2189aa4ed6e7c should work more easily, though (that includes 2.34 and 2.35). <zamfofex>I was wondering if there is any ongoing effort towards updating glibc, or some kind of protocol that is followed for updating it. Because if there isn’t, I’m willing to investigate starting that effort! (On ‘core-updates’ only for now, of course.) <bdju>can anyone tell me how I'd go about enabling debug symbols for a package that lacks the output? or if someone is feeling kind, I want it for the nheko package this time, so maybe someone could take care of it for me. <jab>zamfofex: it sounds like you want to run GNU Guix/Hurd on real hardware? How close are you to realizing that dream? <zamfofex>jab: I was able to run it on real hardware! Though I didn’t have networking, which is what I’m trying to resolve by updating netdde. <kitty1>im curious as well how progress is going there with hurd, I should probably mess with it some time myself <nckx>florhizome[m]: It's not meaningless, it just isn't related to the problem you're interested in, and would only lead you astray. It's like a compiler deprecation warning. <nckx>Well, that's exactly what it is, actually. <jab>zamfofex: I guess you can run Guix on real hardware...but not Guix System yet right? <florhizome[m]>What I mean is that the output as such is pretty useless, like normally you would get some indication of what’s missing. <nckx>Oh, yeah, totally agree. <nckx>‘Warning: you did a thing. Don't do it again!’ <nckx>GUILE_SAY_THE_THING being false by default is certainly odd. <nckx>Disproportionate overhead? I don't know. <atka>guix home reconfigure is giving error: mkdir: Permission denied, hmm, the same config with guix home container worked <atka>is there a way to see what its trying to make? <florhizome[m]>I actually tried setting that env var, it changed nothing :D I guess it’s something inside gccgo or gcc … wherever guile plays a role there ^.– <atka>mkdir("/run/user/1000", 0777) = -1 EACCES (Permission denied) <florhizome[m]>well I’m going to sleep now. rclone 1.58 has bidirectional syncing so I will give it another GO soon <florhizome[m]>@atka if you scroll up I fixed a problem I had with shepherd initiation by changing the permissions of the shepherd socket to 700 *nckx exports USEFUL_UNIX_ERROR_MESSAGES=1 but it does nothing. <nckx>Unixy error messages (single string; no subject) are just a pet peeve of mine. <atka>nckx: what are you referring to? <nckx>atka: ‘footool: error: No such file or directory.’ <nckx>user: ‘Uh… which file or directory?’ <nckx>unix: …you've got strace ain't ya? <atka>oh, yeah I just had to do that above <atka>guix home reconfigure can't create a run directory for my user apparently <atka>oh hey, a reboot fixed it <atka>just tried again and it worked <atka>just a demo of the new guix home container and guix home reconfigure commands etc <florhizome[m]>we could maybe file a complaint so it’s better checked, like it should be a trivial thing <zamfofex>jab: I’m not sure what you mean by that. If you mean “Guix System on the Hurd”, then yes, I was able to run Guix System GNU/Hurd on real hardware. It actually went fairly smoothly! You don’t even need my patches to do it, you could just ‘guix system image ...’ and it should be bootable in real hardware. <zamfofex>bdju: Are you still interested in that? The package seems to be a CMake package (using the Qt build system). Can’t you just modify the ‘configure-flags’ argument to say ‘-DCMAKE_BUILD_TYPE=Debug’ instead of the ‘=Release’ that is there currently? <atka>zamfofex: would hurd run on 32 bit core2 hardware from 2006? <zamfofex>atka: I don’t know. I’d imagine so, but I’m not sure. <atka>oh ok, more modern than I thought, though I haven't seen much about hurd since 2019 or so <atka>looks like progress has been made <lfam>The part that interests me is that one of the candidates for leadership position is focused on improving how Debian handles firmware and microcode <lfam>"I'm not advocating to just include non-free bits on all our media, but I do think there are improvements we can make and actions we can take without compromising our core values. I'd also like to approach both FSF, OSI and LF to see if there's scope for us to work together on firmware problems." <lfam>In the long run, I think it's something we have to address <cdegroot>Question - what is the easiest way to get packages built from local Guix source into my system? I'm working on adding driverless to Cups and while I think it's all good, the only way I can see to actually test it is to somehow reconfigure my system with the packages built from my local source mods. <lfam>cdegroot: What is your "local Guix source"? <cdegroot>checked out Guix sources with local mods (to cups-filters, which is in turn used by the cups service) <lfam>You should use the 'pre-inst-env' script to run Guix. It makes Guix use the source tree that it is run from. It's how one tests modifications during development <cdegroot>Yeah, but I'm not sure that `system reconfigure` will work from there. <lfam>Compared to using it with `guix build` and `guix package`, you may need to make a few extra development dependencies available when using it with `guix system` <lfam>But, that's handled by `guix environment guix` <bdju>zamfofex: I've never modified + installed a modified packaged before <cdegroot>...like the channel I use. I already have the environment setup, the first thing I always pop into a checked out source tree is an .envrc with `use guix guix` in there :) <verkty[m]>I wonder if it's possible to add support for using freebsd's kernel. Would be like a dream come true. <bdju>I am still interested but not sure when I'll get around to it <cdegroot>(I'm testing on my laptop which, alas, requires the intel wireless firmware; so I have to figure out how to make pre-inst-env pull in that extra channel then) <lfam>cdegroot: You can also use `guix time-machine` for this. <lfam>Like, `guix time-machine --url=/path/to/local/repo --branch=foo --commit=blah -- system reconfigure ...` <lfam>pre-inst-env is usually faster <lfam>Using time-machine is nice because the system provenance will be correct and useful <cdegroot>Ah, that may work better. `sudo ./pre-inst-env guix system reconfigure ...` crashes immediately <lfam>And that helps when testing things <lfam>Okay, well I can help you with pre-inst-env if you want. It definitely *can* work if you hold it right <lfam>Tbh, I would just login as root (or use `sudo --login`) and then do `/full/path/to/pre-inst-env ...` <lfam>It's a little easier to get everything right that way <lfam>And of course, you need to do `guix environment guix` to set up the environment, and you have to do it in the right context <cdegroot>Ah, `$ sudo guix environment guix -- ./pre-inst-env guix system reconfigure ~/.config/guix/dell-xps.scm` does the trick but hits on the missing channel right away, so I'll have to tweak the search paths a bit to find that code. <cdegroot>(probably easier to just checkout that channel that has the firmware my laptop needs and point at it than try to get a proper channel setup using git. Nicer too in case I want to make changes there as well) <cdegroot>Hmm... pointing GUILE_LOAD_PATH does the trick, I did a quick edit in the script, now figure out where in that command line I can add the variable export lol. <cdegroot>Yeah, and then I'll mess up and send that change in a patch. <cdegroot>sudo guix environment guix -- bash -c 'GUILE_LOAD_PATH=/...path-to-extra-channel-source... ./pre-inst-env guix system reconfigure ...system.scm' <cdegroot>Now it's gonna do a big build so I'll be asleep before I know whether it works but given that it's loaded everything without errors and is now listing a ton of derivations to build... looks good to me. Thanks for the help ~lfam! <lfam>cdegroot: I advise to run the command with --keep-going <lfam>At least that way, if one thing doesn't work, Guix will finish all the other tasks that it can <cdegroot>Ah, good one. I'll add that if it crashes. I'm an optimist, hence the if :) <cdegroot>I'm also gonna wrap that command line in a shell script otherwise I'll have it forgotten by tomorrow lol <cdegroot>(can't wait to run Guix system on my main desktop which does not need silly closed firmware, but I need that thing for work so the laptop is the first test run) ***iyzsong- is now known as iyzsong
<bdju>zamfofex: oh, nice! thanks, I will try that out later <KarlJoad>How easy is it to do kernel development on Guix? <jgart[m]>singpolyma will be discussing and demonstrating how to write a Guix package with javascript instead of guile. ***lukedashjr is now known as luke-jr
<AwesomeAdam54321>KarlJoad: Once you set up your own package channel, you can do kernel development there <KarlJoad>That makes sense for customizing a kernel for your liking. But what about writing your own kernel modules? ***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<iyzsong-w>I think 'build-flags' are passed to 'make' (or 'cmake', etc.), yes not environment variables. ***lukedashjr is now known as luke-jr
<mekeor[m]>KarlJoad: i don't have experience with kernel modules but I think it should be easy to use your own within your system configuration/declaration <efraim>looks like there might be a qt-5.15.3 official release that isn't commerical-only <mekeor[m]>KarlJoad: in the guix system declaration, "operating-system" has a field called "kernel-loadable-modules" which holds a list of packages which represent kernel-modules. you can easily use your custom modules there. <Lumine>10 hours of sleep, now that's more like it! <allana>Hi guix! I'm searching through guix issues and I found one (https://issues.guix.gnu.org/42920) that matches my current problem/curiosity about running conda in a guix environment/container. I'm here to see if anyone has successfully activated and used a conda environment. Has anyone? I'm quite familiar with Python, but not at all familiar with conda. ***luke-jr- is now known as luke-jr
<allana>So I could be making silly mistakes with conda, but it also looks though there is a problem in guix with that package as well. <FlaminWalrus>I spent a lot of time getting a build of dwm working via guix package --install-from-file. In trying to get a personal channel set up, guix pull is spitting out an error while building the derivation; the error message logged is "no code for module." The package definition is https://bpa.st/LV7A. I followed the manual's directions for setting up a channel, and while the error makes it seem to be a Scheme error, there is every <FlaminWalrus>possibility I messed up something with the authorization. Any ideas? <jpoiret>FlaminWalrus: how did you set up the channel? <FlaminWalrus>guix pull recognized the channel (in the "buiding from these channels:" part) but threw a scheme error when building the derivation <jpoiret>oh, right, i thought it was erroring out at `guix package --install-from-file` instead <yewscion>FlaminWalrus: I have only had success using a top-level module name; e.g. dnwm instead of dnw packages dnwm. Been unable to find how to make full module names work with guix. <jpoiret>guile modules need to follow the filesystem <jpoiret>here you'd need a folder with dnw/packages/dnwm.scm <yewscion>jpoiret: Oooooh! Thank You, that makes a lot of sense. <FlaminWalrus>That was it. Now it's giving me "source expression failed to match any pattern" on the (define-module ...) expression...it's identical syntax to the gnu hello recipie, no? <jpoiret>are you sure it's on the define-module? it seems ok, would you mind paste.debian.net 'ing the backtrace and error? <FlaminWalrus>It's in the second-most-recent commit to the github repo I linked, dnwm.scm file. Testing right now if I needed parentheses around the module name. <tex_milan>Hello fellow Guixers! How do you scan with sane-airscan? I have this in my system config: (sane-service-type _ => sane-airscan) and simple-scan or scanimage -L tells me there is no device detected. I know scanner works because my other laptop running NixOs and sane-airscan detects it. Any idea how to make it work? <tex_milan>airscan-discover works and discovers my scanner.... <tex_milan>@nckx can you share your custom sane-backends recipe using airscan-discover? ***alMalsamo is now known as lumberjack123
<maximed>yewscion: As an example, maybe have a look at the native-search-paths of 'guile', 'emacs' and 'info-reader' <maximed>'guile' and 'emacs' use 'native-search-paths' to support add-ons (Guile and Emacs libraries) <maximed>'emacs' and 'info-reader' use 'native-search-paths' such that 'INFOPATH' is set to a (list of) directories wherein the 'info' documentation of all stuff in the environment resides <maximed>Likewise, 'ncurses' uses 'native-search-paths' to find the 'terminfo' files corresponding to the terminal emulators in the current environment <yewscion>maximed: Thanks, I'll try that! I think that part makes sense to me; the part I'm struggling with is mostly how to apply that search path to a package, once it's defined. Maybe I'll have a look at some Emacs libraries in addition, to see the entire process from definition through use in a dependent package. <maximed>yewscion: emacs libraries do (usually?) not have native-search-paths <yewscion>Hmm, I must still be missing some piece of it, then. <yewscion>If the emacs package defines a native search path, don't the libraries need to interface with that search path to be found? Or if not, how can I use the native search path from one package in another? <yewscion>Do I just redefine the same search path? For instance, adding a TERMINFO search path definition to orca-lang, in my package definition (because ncurses needs it)? <maximed>yewscion: The emacs library is in /gnu/store/...-emacs-library/share/emacs or something like that <maximed>emacs has an EMACSLOADPATH which looks in 'share/emacs' <maximed>Then, if you install both emacs and the emacs library in the same profile, Guix will set EMACSLOADPATH <maximed>EMACSLOADPATH will then be set to ~/.guix-profile/share/emacs <yewscion>Ahh, so in a way, we are overriding the default environment variable EMACSLOADPATH so long as the emacs package is installed (since it defines the search path)? <maximed>yewscion: Basically, you can just copy the search path: (package (name "orca...") (native-search-paths (package-native-search-paths ncurses))) <maximed>yewscion: No, IIRC the environment variable will _only_ be set if there's also an emacs _library_ installed (though that's quite an implementation detail I'd say) <maximed>and I don't see any overriding here, since the environment variable did not exist in the first place <maximed>Also, w.r.t. ncurses, there were some other problems, let me search <yewscion>maximed: Oh, I must have missed the `package-native-search-paths` function. That seems really useful for situations like this. <yewscion>And I see, so both need to be present for the variable to be defined. Would it be right to phrase it this way: it accepts the definition in the "parent" package, and then checks to see if a "child" package exists in the defined path before setting it? <yewscion>Thanks for the link, I'll read it over! Sorry for all of the questions; I dunno why this is such a sticking point for me. <maximed>yewscion: I'm not 100% IIUC correctly, but that seems to be it. <maximed>Though, FWIW, in general there isn't really a parent-child relation. For example, emacs has some info documentation, and it has INFOPATH <maximed>seems a bit weird to me to call 'emacs' a child of itself <maximed>I guess what I'm saying, is that the search path code does not compute any trees <yewscion>maximed: I see, yeah, that makes sense. If there's no tree, then what about collisions? Are these variables globbed together if they're defined more than once? <maximed>yewscion: Do you mean, say, what if both "emacs" and "info-reader" (which both have INFOPATH) are installed? <yewscion>maximed: Yup, that's what I'm worried about. Perhaps because I'm used to bash. <maximed>yewscion: Let's test: guix shell --pure emacs info-reader bash -- bash -c 'echo $INFOPATH' <maximed>result: /gnu/store/s6hr9cwamihrs7wj1lqfiivw94qbvv0v-profile/share/info <maximed> ls /gnu/store/s6hr9cwamihrs7wj1lqfiivw94qbvv0v-profile/share/info --> lots of info files <maximed>(in particular, texinfo.info-1.gz and elisp.info.gz) <maximed>Not sure about the _how_, but the result seems fine <maximed>Presumably there's some code somewhere that removes duplicate search paths <yewscion>Just did so on my machine too. Interesting; I have a lot to learn about how guix works, internally. But at least I'm no longer worried about accidentally overriding a variable for another package! <maximed>Is there some "earliest version of guix for which pulling to current master is supported"? <maximed>I'm modifying some "guix pull"-related code, and I wonder how far in the past I have to test things <yewscion>maximed: I've successfully added TERMINFO_DIRS manually to the package spec, but when I add `(package-native-search-paths ncurses)` the build complains about a bunch of undefined variables, including some that I know to be defined in the `music.scm` file (like ncurses itself). Is there something else I would need to do to make the above work? I'm <yewscion>looking for other uses of `package-native-search-paths`, but haven't found any yet. <maximed>yewscion: Those undefined variable problem is probably caused by some cyclic imports <maximed>so I guess that somehow, (gnu packages ncurses) imports (gnu packages music)? ... that doesn't seem right <yewscion>Interesting. Perhaps it's another bug somewhere; for now, I suppose I can just explicitly define TERMINFO_DIRS. <gnucode>does guix not have an lsdvd program? <gnucode>now I'm curious...does guix support a ~/tmp filesystem? Where ~/tmp is tmpfs? Aka writing to ~/tmp is just writing to RAM? I suppose you could just create a symlink to /tmp... <abrenon>gnucode: the system declaration lets you define arbitrary mount points, so you could in particular add that for some users of your choice <abrenon>last time I checked, tmpfs wasn't mounted by default on /tmp and I had to define it manually <abrenon>guix search doesn't return anything for lsdvd, but maybe you can import a declaration for it if it's written in one of the supported package formats ? (see guix import) <gnucode>abrenon: I guess I would not know how to define arbitrary mount points...I don't think the filesystem code supports type "tmpfs"...but I am not certain... <gnucode>I just went to the code: %shared-memory-filesystem. <acrow>abrenon: the botanical hostname is a nice choice. :) <gnucode>are there any web applications that guix has packaged yet? <yewscion>How does one specify a specific output for a package with the new input style in a package definition? <acrow>I don't think that has changed. <gnucode>I actually decided that I didn't need it. :) handbrakecli has a --main-feature option that lets you detect the main feature. :) <tex_milan>nckx: can you share your custom sane-backends recipe using airscan-discover? <agnem>I'm trying to use a relocatable pack of tmux on a different machine, but tmux fails to set a utf-8 locale even though I specify an installed one with environment variables. Are anyone aware of any other issues with locale, or some resources on the topic? <yewscion>acrow: Thanks for the link! I was actually able to find the answer under propagated inputs; What used to be something like ("glib:bin" ,glib "bin") is now `(,glib "bin"). I'd been looking in https://guix.gnu.org/manual/en/html_node/ ; I didn't realize the devel manual would have the update! <acrow>yewscion: That's good to hear. <zacchae[m]>I installed every rocm package and tried to run rocminfo to make sure my gpu showed up, but I got an error: unable to open /dev/kfd: no such file or directory. <zacchae[m]>I suspect it may be that my kernel is too new. Is there an easy way to see what commit a package was added/modified? I assume that the rocm drivers worked when they were added, so I'd like to roll back <acrow>zacchae: IIUC, you might just try guix edit <your-pkg> the commit/version will be in there. <acrow>zacchae: looking at guix package -s rocm, it appears that ver 4.3.0 is the roc you are dealing with. I'm going to back away now because though this looks very cool I have no experience with either roc or gpu's. <pranavats>Hello, does the Berkeley DB (bdb) package in guix include bdb-je (Berkeley DB Java Edition)? <zacchae[m]>acrow: I'm not worried about the upstream package version. I'm sure that's all fine and dandy. I suspect the problem is with an implicit dependency, namely my linux kernel version, so I want to roll that back. <zacchae[m]>Maybe I can do a git blame on the package to see a gui <zacchae[m]> * Maybe I can do a git blame on the package def to see a guix commit? <zacchae[m]>though it could be that rocm never worked and packaging it is still a work in progress... <zacchae[m]>pranavats: the package def says it supports Java Object storage. Though I don't know if that's a feature of non-java edition. <acrow>zacchae: having acknowledged that I am just guessing I don't think that is the guix way, but after installing the new packages you probably do need to reboot. I will also add that kernel access is a root perogative that guix must honor; so a guix system reconfigure might also be in order. <acrow>zacchae: kernel access to a gpu is something that may need to be installed by the root user. Alternatively, maybe, you need to put users that want to get access into a special group. These are all just guesses though. Hopefully someone with experience in these matters will come along, see this and pipe in. <acrow>zacchae: the guix way being declarative system configuration. So, I think, all the packages usually work with all the system kernels. caveat -- I could be wrong. <zacchae[m]>I mean, the package "shouldn't" break, but it did. I'm just trying to do a hardware test, so if it worked once, I should be able to use guix's reproducibility and make it happen again. These packages are known to only work with very specific kernel versions. Also, I'm running these things as root :) <acrow>zacchae: I'll be watching to see your eureka moment. :) ***the-porcupirate is now known as porcupirate
<jgart[m]>it's currently called `mupdf-x11` which is kind of annoying <jgart[m]>I'm used to always calling it as `mupdf` <tschilptschilp23>This goes very much over my head, as the driver-package openjdk collides with does not use any java as far as I know, and I wonder what puts python in place here? <djeis>It seems the ceph packages in guix are broken by the recent update in snappy to disable rtti. <ngz>jgart[m]: IMO, it makes sense to symlink mupdf-x11 to mupdf in the package definition. <djeis>Since the snappy project refuses to support rtti going forward it sounds like ceph either needs a patched snappy that adds back rtti (which is what they've done with some distros) or have it pinned on an older snappy (like 1.1.8). <tschilptschilp23>same goes with openjdk{9-14}, but icedtea-8 installs and does what I need. This means I have my solution for what I need -- but I'd still be interested at hints how to (start to) debug(ging) the error from above... 