<Aurora_v_kosmose>FlaminWalrus: It's one of the few things that's unfortunate with Guix I think. One can't simply do something like "apt-file search $filename" as Guix has no manifest of the files in a package
<tewi>hello, in the configuration system section of the manual, i see %base-packages, %base-groups, and so on used. is there a way to see what these actually stand for, and what variables like that are bound by default?
<jgart[m]>This month we're rotating to use an APAC friendly time for our Guixers on that side of the 🌎
<FlaminWalrus>Aurora_v_kosmose: yes, that would be helpful. I recall having a heck of a time figuring out that terminfo capabilities came from ncurses...something like `guix search which` that'd return a list of all packages that provide a specific command would be great too. It'd either need a change to (package...) objects though, or be something that'd build the package in a temporary environment and inspect the output, but cache the results on
<FlaminWalrus>the substitute servers so queries wouldn't outlast the Sun...
<apteryx>Aurora_v_kosmose: yes, it's part of texlive-bin
<apteryx>but polyglossia is broken in master (fixed on the wip-ipython-polyglossia branch I'm working on)
<Ox151>is there any documentation for adding a windows partition to the grub menu?
<apteryx>sneek later tell 0x151 there's an example in "info (grub)Chain-loading"
<FlaminWalrus>bjc: I would think there would general programmatic advantages to having a summary of all side effects of a build somewhere beyond these kinds of searches; a Scheme function mapping derivations (or gexps) to a higher-level summary (i.e. only the /what/, not the /how/) could be helpful for debugging stuff like build irreproducibility or hidden dependencies. It's cool to see guix-devel already has this on the mind!
<FlaminWalrus>On the topic of changes to Guix, has anyone ever talked about first-class kernel modification support? Right now, the workflow is 1. clone sources from git.kernel.org 2. wait 3hrs 3. copy /proc/config.gz to exactly the right location in the massive source tree 4. make menuconfig 5. manually write the new config into a kernel package definition. I tried to investigate pulling the 'make menuconfig' code out of the kernel for a tool tha
<FlaminWalrus>automatically produces a package definition from the changes à la 'guix import', but the kernel's recursive Makefile structure is nightmarish and I gave up pretty quick...
<apteryx>lechner: hi! the source of the manual is at doc/guix-cookbook.texi; edit it, build it/review the result, then send a patch to email@example.com. The contribution process is documented, see info (guix)Contributing
<phodina[m]>I attempting to update rust package `rust-wayland-egl` to version 0.29.4. But the build fails as it cannot find crate `cfg-if` in rust-nix-0.22 which is dependency of `rust-wayland-client-0.29` (this is dependency of `rust-wayland-egl`).
<phodina[m]>However, when I check the `rust-nix-0.22` package it's listed in the cargo-inputs. Any idea what to do?
<phodina[m]>jpoiret: Not sure what you meant as it's listed in the cargo-inputs of `rust-nix` package.
<unmatched-paren>i have a search path for `hare', but it doesn't seem to be working...
<unmatched-paren>"When you “use” a module, Hare will search for that module in your HAREPATH, which is a colon-delimited list of directories to look through. The first directory is always the current directory, so if you want to add a private module called “example” you can place its files at ./example/*.ha. The standard library is usually installed (on Unix systems) at /usr/src/hare/stdlib, and third-party
<unmatched-paren>modules are installed at /usr/src/hare/third-party, both of which are configured in your HAREPATH by default. We recommend that you make liberal use of these resources in your work — don’t hesitiate to read the source code for your dependencies.
<unmatched-paren>the runtime is in a different place (with the bootstrap harec), so it can't find it
<jpoiret>phodina[m]: could you paste your rust-nix definition?
<jpoiret>seems it's not being picked up as a rust input
<phodina[m]><phodina[m]> "jpoiret: I can send you the 18..." <- All the patches apply and mostly just update the versions and inputs. But with this confusing message it's hard to figure out what's wrong as the `cfg-if` package is in already merged package and other packages depending on `rust-nix` compile and don't throw any error
<phodina[m]>jpoiret: If I add `rust-cfg-if` to `rust-wayland-egl-0.29` into cargo-inputs it the complains about missing `autocfg` but that's a dependency of `memoffset` which is dependency of `rust-nix`. Looking at the `rust-nix-0.22` it skips build. Could it be that's it's merged but doesn't build?
<jpoiret>why can't i just @@ the procedures defined in guix/build-system/cargo.scm :(
<maximed>(as in, the source itself, not the binaries)
<maximed>phodina: Something to be aware of: cargo-inputs != cargo-development-inputs. So maybe cfg-if is in the wrong one
<vivien>Hello guix! I see there’s a lot of activity around the python build system. I still have a patch waiting for review, but if the build system work is active as I can see right now, it is reasonable for me to wait for the job to be done and then rethink my package with the new build system.
<vivien>I’m not sure my sentence is easy to understand, that’s my bad sorry.
<vivien>Anyway, I guess there’s only a handful of python packagers in guix, so better let them concentrate on the bigger task first.
<phodina[m]>maximed: Thanks, I'll doublecheck the dependencies with the Cargo.toml
<phodina[m]><maximed> "phodina: Something to be aware..." <- Not sure why but adding the dependencies of `rust-nix` and `rust-memoffset` to cargo-development in `rust-wayland-egl` solved the build issue 🙈. I'll mention it in the patch thread when submitting.
<unmatched-paren>there seems to be an issue with the home-fish-service-type where it creates ~/config/fish/* instead of ~/.config/fish/*, probably because of the recent change where home no longer prepends a dot
<phodina[m]>I've found similar issue with `rust-glutin-0.28`. It fails on `rust-glutin-egl-sys-0.1` even if I put it in the cargo-development-inputs or inputs.
<phodina[m]>The Cargo.toml says it should be just cargo-input. Also the crate is in the `guix-vedor` dir when building with `-K`.
<maximed>GNUtoo: in build-aux/build-self.scm (or was it compile.scm?) there's a ‘load all the modules’ followed ‘compile every module’? Maybe there will be a better error if the ‘load all the modules’ is removed
<maximed>lechner: Maybe knot keeps some logs that can be investigated?
<lechner>maximed: great hint. i was looking to herd for the logs but it's not like systemd. i found something i need to recocile with the guix docs and my own knowledge of knot error: config, file '/gnu/store/1mw2hs2vsax7a4smx879995mwqxhxw9l-knot.conf', line 22, item 'acl', value 'wallace-acl' (invalid reference)
<lechner>yeah the config file doesn't look quite like i expected
<mekeor[m]>is there a search engine to search packages in a maintained set of channels?
<GNUtoo>I heard of thinkgs like that in the past but I'm unsure if it was a plan of it it exists but there is a need anyway.
<vagrantc>for reasons i don't quite understand, guix system/shepherd stalls on my rockpro64 on reboot or halt if the dw_mmc_platform module is loaded ... manually removing the module and it proceeds reasonably fast