IRC channel logs


back to list of logs

***rekado_ is now known as rekado
***Xenguy__ is now known as Xenguy
<Aurora_v_kosmose>Does Guix contain xelatex stuff?
<FlaminWalrus>Aurora_v_kosmose: it's distributed as a part of texlive; just checked and I've got the `xelatex` command on my path
<Kolev>Installing System on laptop again. No need for Jellyfin.
<Gooberpatrol66>ping doesn't work inside a guix system vm even though other tools like wget work. is there a way to fix this?
<Aurora_v_kosmose>FlaminWalrus: Awesome, thanks.
<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?
***rekado_ is now known as rekado
<jgart[m]>Hi Guixers, we'll have a packaging meetup tomorrow, Sunday at 10:30PM ET:
<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"
<sneek>Got it.
<apteryx>Ox151: ah, it starts with o, not 0 ;-) ^
<apteryx>Gooberpatrol66: that's a documented limitation of the QEMU user mode networking
<apteryx>TCP-based tools (such as wget) works but ping uses the ICMP protocole which QEMU user networking itself uses, conflicting with it, if I recall correctly.
<Ox151>apteryx: ;) irc doesnt allow numbers at the start of a nick XD
<Aurora_v_kosmose>apteryx: I think I only need xetex and bibtex.
<Aurora_v_kosmose>FlaminWalrus: I would imagine that it could be a saved build artifact. The CI farm could cache the ones for its own builds and serve them too.
<bjc>there is a guix data service that seems like it could be made to suit the purpose of caching file locations
<bjc>ludo also mentioned another database that he'd hacked together, but i can't find the ml post right now
<apteryx>sneek: later tell attila_lendvai you could also reference the package/origin directly via gexps (e.g, #~(modify-phases ... (invoke "something" ... #$the-origin) ...)
<bjc>re: file database: i found the post
<jgart[m]>What are people's thoughts on this one?
<jgart[m]>Guix Packaging Meetup:
<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 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...
<lechner>Hi, how may I contribute a few small edits to this article, please?
<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 The contribution process is documented, see info (guix)Contributing
<apteryx>info '(guix)Contributing'
<lechner>apteryx: thanks!
***zmv is now known as notzmv
<eskin>Is there a way I could see a package's source after snippets are applied? I'm not sure if guix holds on to source code, I didn't see it when poking around
<xelxebar>Hey Guix! Is this at all reasonable for a `build-package' procedure?
<jpoiret>xelxebar: iiuc you don't need to manually consider grafts
<jpoiret>you could just lower-object instead
<jpoiret>oh, you're using package->derivation anyways
<xelxebar>jpoiret: Thanks for the input. Yeah, for some reason a simple package->derivation isn't picking up the grafts.
<jpoiret>let me look at the source
<jpoiret>at least lower-object should
<jpoiret>what does (%graft?) give you?
<xelxebar>Hrm. AFIU, `guix build` eventually boils down to a package->derivation call for simple cases, and package->derivation already does call graft-derivation*.
<xelxebar>Yeah, (%graft?) is the default #t.
<jpoiret>In what context are you running that code? guix repl?
<xelxebar>Yeah, repl.
<jpoiret>if you pass #:graft? #t explicitely to package->derivation, does it consider them?
<xelxebar>Hehe. Tried that, and I saw no difference.
<jpoiret>let me try as well
<jpoiret>it works for me though
<jpoiret>what are you testing on?
<jpoiret>polkit does get grafted for me
<xelxebar>Huh! That's interesting. I'm building a package directly from the git repo.
<jpoiret>could you paste the definition?
<xelxebar>Actually, it's probably easier to just directly grab the repo on the branch I'm munging:
<xelxebar>That's on the `devel/make3` branch, and the relevant code is inside jbuild.scm
<xelxebar>You can see the build-package definition near the bottom of jbuild.scm.
<lechner>Hi, does Guix ship foot-terminfo anywhere? Thanks!
<jpoiret>xelxebar: i don't see any grafts in your definitions
<jpoiret>orr do you mean grafts somewhere in the dep tree?
<xelxebar>jpoiret: Correct. My package doesn't directly have grafts, but some of its dependencies seem to.
<xelxebar>Yeah, the latter :)
<jpoiret>lechner: we've got with a proposed fix, not yet merged
<jpoiret>so, using build-package doesn't give you the same as `guix build -f yourjdefinition.scm`?
<xelxebar>Currently, it does. However, if I remove the explicit graft-derivation call, then build-package fails to generate the output path in the store.
<xelxebar>The "non-grafted" output path is built, however, and I see that as a dep of the .drv.
<jpoiret>xelxebar: unrelated, (concatenate (map ..)) can be replaced by append-map in srfi-1
<lechner>jpoiret: thanks, but doesn't the proposed fix require me to install the terminal app on the server, even though it is never used there?
<jpoiret>we don't have separate terminfo packages in guix unfortunately
<jpoiret>at least, not that i know of
<lechner>and pull in the wayland libs on a linode?
<jpoiret>you could set TERM=some-compatible-but-usual-terminal
<jpoiret>personally i often do TERM=xterm
<lechner>yeah, me too
<jpoiret>maybe that could be something we could do
<jpoiret>or even just add a terminfo output to all terminal packages, hopefully they won't retain references to anything
<jpoiret>xelxebar: how do you build drv when you're not using the manual grafting?
<xelxebar>jpoiret: Cheers. You should be able to see missing grafts issue if you remove line 474.
<xelxebar>Rather, the script will just error out, complaining that the package's /gnu/store/...-blah path doesn't exist.
<jpoiret>if you simply remove line 474, then you're just not building the derivation at all
<jpoiret>you need to use something like (build-derivations (list drv)) at some point
<xelxebar>Really? It'll build just fine for me :P
<jpoiret>you'll build something because package->derivation needs to build some things to work (namely the thing it's grafting on iirc), but it won't build the derivation you want
<xelxebar>I did have a built-derivations call at 474, so maybe I'm just confused.
<jpoiret>maybe i'm wrong then, if it still doesn't work with a built-derivations
<xelxebar>I could easily just be confused. Checking.
<xelxebar>Okay. It seems to be working with built-derivations :D
<jpoiret>nice :)
<xelxebar>Maybe I had been using it before I figured out that mbegin is needed.
<jpoiret>by the way, that package definition looks good :)
<jpoiret>yes, it's unfortunately needed
<jpoiret>and mlet doesn't support multiple body forms for some reason
<xelxebar>:P Still working on the cpu tuning stuff
<jpoiret>would you be interested in the mdo notation i talked about in the MLs?
<phodina[m]>Hi there!
<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?
<jpoiret>i'll try to cook up something today then
<unmatched-paren>I see Hare has gone public; no longer tells you to keep it a secret, and ddv's website has a reasonably easy-to-find page about his talk on it: i might try to package it for Guix :)
<jpoiret>phodina[m]: maybe a version constraint?
*xelxebar gives a thumbs up to jpoiret
<unmatched-paren>i did try before, but i had search path problems with it not finding the standard library
<unmatched-paren>probably easy to fix though
<jpoiret>unmatched-paren: is that the devault project?
<jpoiret>oh, ddv right
<phodina[m]>jpoiret: Thanks, I'll check that but `cargo` normally it complains if there is a specific version needed
<unmatched-paren>the build instructions are here, in case anyone else wants to help :)
<unmatched-paren>jgart: would you be interested in helping with a hare compiler package in Guix R Us? see above ^^^
<phodina[m]>jpoiret: I checked the version and there's no constrain
<jpoiret>i image you updated rust-nix but not cfg-if? could you send a paste of it so we could try locally?
<phodina[m]>Here's the build log
<unmatched-paren>this is what i have so far
<phodina[m]>jpoiret: I can send you the 18 patches you need to replicate that if you want
<jpoiret>hmmmm, maybe not
<phodina[m]>jpoiret: Nope I didn't update rust-nix, that's already on master. I just need to update the wayland crates to get newest alacritty terminal
<jpoiret>is cfg-if "propagated" properly?
<jpoiret>oh it doesn't even need to, disregard that
<unmatched-paren>hare builds but when i run it i get
<unmatched-paren>Error resolving rt: Module not found
<unmatched-paren>so i need to figure out some search path
<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>but i have those two in the search path and it's not working...
<unmatched-paren>oh, i remember now
<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: It's upstream
<unmatched-paren>aargh, no, i was wrong, rt is included in hare
<unmatched-paren>oh, oops, i had to reload the search path :)
<unmatched-paren>... and now assertions are failing in a few places :(
<unmatched-paren>*in the compiler
<unmatched-paren>they do have very helpful instructions
<unmatched-paren>but they assume FHS
<jpoiret>phodina[m]: can you keep the build directory and inspect guix-vendor?
<jpoiret>does it contain cfg-if?
<phodina[m]>jpoiret: Nope it does not
<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>eskin: Try "guix build --source the-package"
<maximed>That will build the post-snippet source
<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
<unmatched-paren>thanks to #hare i got a `hare-toolchain' package working! \o/
<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`.
<phodina[m]>Any ideas on this one?
<unmatched-paren>but i changed ~/config to ~/.config in its definition, and it still didn't wor
<unmatched-paren>anyone have any idea of what else i'd need to change?
<WesterWest[m]><unmatched-paren> "there seems to be an issue..." <- i already submitted a patch but theres no activity on it
<WesterWest[m]><unmatched-paren> "anyone have any idea of what..." <- i just hard-link it everytime, you can try sourcing the config file if it fixes it
<sneek>Welcome back yewscion!!
<yewscion>sneek: botsnack.
<wehlutyk[m]>Hello Guix!
<KE0VVT>GNU day!
<wehlutyk[m]>I'm slowly progressing with a guix-based project on rock64 (aarch64), for which I'd like to use rust
<wehlutyk[m]>I just discovered rust isn't currently supported on aarch64, but haven't found any news about current development for support
<wehlutyk[m]>(with rust in the kernel i read somewhere this will become pressing quickly)
<wehlutyk[m]>Is there anywhere I can follow this? Or give a hand?
<maximed>phodina: FWIW, I'm writing a new (Guix) build system for Rust (antioxidant-build-system), that (is intended to) integrate better with Guix
<maximed>so maybe the issue will disappear eventually
<maximed>It's not yet ready for general usage though.
<maximed>wehlutyk[m]: IIUC, the problem is that currently, Rust cannot be bootstrapped on aarch64 -- only on x86_64
<maximed>See ‘Progress’ at
<maximed>Looks like some people are looking into supporting aarch64:
<wehlutyk[m]>yes, also mrustc now supports 1.54.0 (but as you say, not on aarch64)
<maximed>There's also
<wehlutyk[m]>maximed: what's your antioxidant-build-system based on?
<wehlutyk[m]>I mean, it sounds interesting -- what are the planned benefits?
<maximed>wehlutyk[m]: antioxidant-build-system is a Guix build system like python-build-system or gnu-build-system
<maximed>It reads Cargo.toml files like Cargo does.
<maximed>But instead of calling "cargo SOMETHING", it calls the underlying rust compiler 'rustc'
<maximed>Benefits include: Removing the special #:cargo-development-inputs / #:cargo-inputs in favour of the usual 'inputs' / 'native-inputs' / 'propagated-inputs'
<wehlutyk[m]>ah yes I remember seeing that not long ago! (maybe on the mailing list)
<maximed>Also, in the cargo-build-system, the build results of dependencies were not reused in dependents
<GNUtoo>hi, do some people often have "ice-9/eval.scm:293:34: error: tcc: unbound variable" when building Guix?
<maximed>GNUtoo: backtrace?
<maximed>(which module failed to compile?)
*GNUtoo tries with make -j1 to get the full trace
<wehlutyk[m]>maximed: gccrs looks super promising
<GNUtoo>It doesn't say much more
<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>Though this will have some side effects
<GNUtoo>compile-all.scm ?
<maximed>GNUtoo: guix/build/compile.scm
<maximed>Remove the (load-files source-directory ...)
<GNUtoo>Thanks a lot
<maximed>Then if "make" fails, at least the 10% files that could be loaded will be compiled, so next time, they don't have to be loaded again
<maximed>Actually 'load-files' compiles the files I think, it just doesn't save them?
<GNUtoo>Maybe it's some race conditions because sometimes I have it sometimes not and every time I didn't understand how it disapeared
<GNUtoo>It failed again with that error: but removing my patches (that were tested and that worked before) and re-typing make made it continue to 54%
<GNUtoo>And it still continues
<GNUtoo>so maybe it's related to some build order
<efraim>hello guix!
<GNUtoo>ah it fails again at some point
<GNUtoo>It failed at 55%
<GNUtoo>The comment above ( has the same error message
<GNUtoo>So maybe I need to (1) reproduce the bug again (2) find a workaround (3) bug report?
<maximed>GNUtoo: does your guix tree have modifications?
<maximed>Maybe a cycle was introduced.
<maximed>Or maybe undo the change to compile.scm.
<roptat>hi guix!
<GNUtoo>I've now undoed all changes and I'm at 78%
<GNUtoo>It worked so I'll try to reproduce and to workaround by compiling c.scm first somehow and report if that works
<GNUtoo>Anyway thanks a lot for the help, it pointed me in the right direction as on top of the code to comment there is a bug report link
<PurpleSym>Hm, has been evaluating for hours now. Is it stuck?
<phodina[m]><maximed> "so maybe the issue will disappea..." <- Thanks for the info. Do you have a tracking branch?
<lechner>Hi, do i have to do something special to get knot to start, please?
<maximed>phodina: It's at <>
<maximed>For now, it's developed outside Guix itself.
<maximed>Though the idea is to eventually move it into Guix itself and teach "guix style" to automatically rewrite package definitions
<maximed>lechner: I'm not familiar with knot but that seems about right.
<maximed>Did you do "guix system reconfigure"?
<lechner>i did , but herd says this
<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
***Noisytoot is now known as [
<lechner>I think I have a Guile problem. How to I set action to a list containing ony 'notify in knot-acl-configuration, please?
<maximed>antioxidant update: 'sniffglue' now builds
<maximed>technor: maybe just (list "notify")?
<maximed>Also, ideally Guix would just throw some error here, instead of having to dig through the configuration file.
<lechner>maximed: the (list "notify") threw no error but produced no output
<lechner>i'll contribute better error messages once i learn more about Guix
<lechner>where can i find the Guile code for it (or whatever else i need)? it may not be implemented right
<maximed>lechner: some file in gnu/services/
<maximed>"git grep -F" may be useful to find where exactly
<maximed>The manual has some information on where to download the source code from.
<lechner>maximed: thanks!
<lechner>Hi, what are everyone's favorite DNS client programs in Guix? Also, should 'ldns' ship an executable called 'drill'?
***rekado_ is now known as rekado
<maximed>lechner: my web browser :p
<vagrantc>it's a good day when i get linux-libre substitutes for aarch64 :)
<GNUtoo>hi, is there a standard used in Guix like to tag patches?
<vagrantc>don't recall anything, per se. wouldn't be a bad idea to implement
<vagrantc>debian has a similar recommendation of patch headers
<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
<GNUtoo>vagrantc: maybe dmesg could tell?
<GNUtoo>Do you have an UART or do you see the messages somehow?
<GNUtoo>You could also try to load it manually and look at dmesg
<vagrantc>yeah, on serial console i bump the kernel logging
<vagrantc>problem is, to trigger the system, i basically have no access to anything, as all the shells/logins/etc. are stopped at that point
<GNUtoo>btw, beside that does this board works well?
<vagrantc>i wonder if shepherd is somehow seeing a kernel process as a userspace process for some reason...
<GNUtoo>You probably need to add loglevel=8 to the kernel cmdline and hook up an UART then
<vagrantc>reasonably well for me. i know rekado had some troubles with using a different sata controller
<vagrantc>i've bumped it to 9 using ctrl-a b 9 from the screen monitoring it
<vagrantc>shepherd[1]: waiting for process termination (processes left: (1 162))
<vagrantc>on the booted system pid 162 is some kernel process relating to the mmc bus
<GNUtoo>with "console=ttySomething1 loglevel=8" it will be the kernel that outputs the message, so you can remove shepherd from the equation
<vagrantc>pretty sure that is the kernel messages
<GNUtoo>so the ctrl-a b 9 is like dmesg -n 8
<vagrantc>it sends abreak signal to the serial console and enables the kernel logging
<GNUtoo>oh nice
<vagrantc>"ctrl-a b h" lists all sorts of features you can do, but most are disabled for security reasons
<vagrantc>but it might be useful to just enable it at boot since i'm having this problem
<vagrantc>the process shepherd seems to be waiting on is 162 kworker/2:2-mm_percpu_wq
<GNUtoo>It's also probably better to be 100% sure in cases like that
<GNUtoo> dev_dbg(host->dev, "remove slot\n");
<GNUtoo>It should also probably print that
<GNUtoo>it's in void dw_mci_remove(struct dw_mci *host)
<GNUtoo>At least when you rmmod
<GNUtoo>I'm unsure how it works with reboot or shutdown though
<GNUtoo>but I guess it has to disable devices at some point so it should probably call .remove()
<vagrantc>yeah, that revealed the same messages...
<vagrantc>although interestingly enough, the kernel process is now 156 instead
<GNUtoo>The pids are probably somewhat random
<GNUtoo>The OpenSSH key issue publicized that
<vagrantc>they were pretty consistent
<vagrantc>only change when i change something in the system configuration
<vagrantc>most likely because the modules from the initrd are loaded in a predictible order
<vagrantc>not autodiscovered
***zmv is now known as notzmv