IRC channel logs


back to list of logs

<nefix>But 1- it keeps asking for the "cc" program and 2- it doesn't seem to be picking up the builtin libraries `zig cc -E -Wp,-v -xc /dev/null` points to `/gnu/store/lscf3a52z0773pr8g15l1z15vrgq1wbl-zig-0.8.0/lib/clang/12.0.0/include`, but it should also have `/gnu/store/lscf3a52z0773pr8g15l1z15vrgq1wbl-zig-0.8.0/lib/zig/libcxx/include/` for example
<nefix>(keep in mind that I think I'm missing out a lot of things)
<GNUtoo>Noisytoot: There are several options: you could try to bugreport or you could try to fix it
<GNUtoo>The manual has something about both I think:
<nefix>the derivation source code is here:
<GNUtoo>The neat thing about the bug and patch tracking system is that you can interact with it by mail and through a web interface as well
*Noisytoot installs emacs-debbugs
<leoprikler>nefix doesn't the latest zig have a check phase tho?
<GNUtoo>oh nice I didn't know there was some integration inside emacs
*GNUtoo likes system with many interfaces so people can find the one that suits them more
<GNUtoo>*the most
<nefix>leoprikler: yes, but it was failing a test so I disabled it
<leoprikler>aside from that it seems you're the first to try compiling C code using this zig package, so it'd be nice if you could fix it and amend the patch
<nefix>leoprikler: but I have zero idea what is the issue and how should I fix it xD
<leoprikler>well, the issue is that zig is missing some include paths?
<nefix>I think this, and also that it somehow asks for a "cc" command when it should use itself?
<nefix>But seeing the nixpkgs derivation, they don't seem to do anything special
<nefix>and the Zig author themselves have participated on writing it
<nefix>so I'm kinda lost
<nefix>maybe I'm not doing something right
<LevyElara[m]>zig tries to use the native C compiler to figure out where things are
<leoprikler>that's a weird way of doing that tho
<leoprikler>"configure" is a tool that exists, just throwing this out there
<leoprikler>the opensfx thing is legit btw, the license changed with a major version bump
<leoprikler>(for the better, I might add!)
<leoprikler>Noisytoot: 👆️
<Noisytoot>Is Guix using the old version (that didn't change the license yet)?
<Noisytoot>also,, which guix seems to download opensfx from, is a 404 error
<leoprikler>funny how substitutes still exist :P
<leoprikler>that said, you might want to update the OpenTTD package(s)
<leoprikler>the recipe seems to be from 2017
*Noisytoot tries to build openttd without substitutes
<Noisytoot>Is it possible to get Guix to rebuild it without substitutes (if it's already been substituted)?
<LevyElara[m]>nefix: can you try pasing `-x c++` to zig cc?
<monego>civodul: saw the pytorch patches, i was also working on them, could help review if i saw a series in the list
<monego>there is one missing dependency though, which is onnx (the C++ library), we only have one package which is the python interface with the c++ library bundled
<monego>and it's been a nightmare trying to separate the two
<LevyElara[m]>nefix: do you have any code I can test with? I was able to compile the short snippet above to mips without issues using the bundled musl via `-target mips-linux-musl`
<nefix>run `zig build run`
<LevyElara[m]>It's not passing `-lc++` so `exe.linkSystemLibrary("c++");` but then it fails on the `@cImport()`
<LevyElara[m]>as `translate-c` doesn't understand C++
<LevyElara[m]>only solution there is a C wrapper unless I'm overlooking something
<nefix>aren't you getting the `cc` spawn error?
<LevyElara[m]>no, not at all
<nefix>using my `` script?
<LevyElara[m]>Ok now I am, yeah, right. `CC` and `CXX` are not set thus zig doesn't know how to find the system's libc
<LevyElara[m]>if you set `CC=gcc` it will work but fail on the missing `-lc++` and later c++ itself
<nefix>But shouldn't it use zig itself?
<nefix>Instead of gcc?
<LevyElara[m]>it only uses gcc to find where the native libc is located
<LevyElara[m]>then it uses the bundled clang in zig cc for the actual compilation step
<nefix>Oh I see
<LevyElara[m]>if you set `exe.setTarget(.{ .cpu_arch = .x86_64, .abi = .musl, .os_tag = .linux });` you'll see zig use it's bundled libc instead
<LevyElara[m]>however that fails due to the c++ header import and wouldn't pass linking later on
<LevyElara[m]>since the default is whatever the system uses
<nefix>to me, it's failing with "/gnu/store/lscf3a52z0773pr8g15l1z15vrgq1wbl-zig-0.8.0/lib/zig/libcxx/include/__nullptr:54:1: note: unknown type name 'namespace'" and more similar errors
<Noisytoot>Is it possible to build just openttd-opensfx without substitutes (not other dependencies of openttd)?
<LevyElara[m]>yes, that's clang complaining that the header isn't a C file
<Noisytoot>It's taking a long time to build cmake-bootstrap
<nefix>LevyElara[m]: oh. And what does that mean?
<Noisytoot>nefix, The header is C++, not C
<nefix>Noisytoot: so are the `.cc` files, right?
<nefix>maybe I'm too tired today. Thanks for all your help! :) Good night
<dstolfa>so, i've noticed something with chicken scheme in guix. you can't actually use `chicken-install`, because it wants to write to store.
<dstolfa>this is unfortunate.
<dstolfa>i wonder if we should have the package set up a couple of environment variables somehow so it defaults to the user home directory and magically works, instead of trying to touch the store
<brettgilio>Hello Guix
<lispmacs[work]>brettgilio: we are Guix
<lispmacs[work]>your technological and biological distinctiveness will be added to our own
<brettgilio>lol! already has been
<lispmacs[work]>as you were
<Noisytoot>leoprikler, I updated openttd-opensfx and removed cc-sampling-plus-1.0:
***califax- is now known as califax
<drakonis>the guix collective?
<char>can someone help me understand input vs propgated input?
<char>When installing common lisp packages, the inputs are needed at build time and run time, but they are only available during build time unless manually installed. Should they actually be propgated inputs?
<drakonis>there's a section on propagated inputs here
<char>based on that it seems that for the most part I am correct. If a package A has
<char>package B in it's inputs, and package B has package C in it's propogated inputs, C wouldn't not be installed along side A, correct?
<drakonis>it would, yes.
<drakonis>propagated inputs are for runtime dependencies
<drakonis>this could help?
<char>but package B is not a runtime dependency of A
<drakonis>fair enough
<drakonis>it would not pull in C
<char>It would pull it in at compile time only right?
<char>That is prefect. I wonder why the common lisp people used input instead of propogated input then.
<drakonis>good question?
<char>This came up because I needed some package on my server, and for it to work properly, I had to manually install all dependencies as it complained about them one at a time.
<tissevert>hello guix
<the_tubular>How would I go about using something that needs to be frequently recompiled, let's say dwm?
<atka>^ I'm interested in this as well
<the_tubular>atka I might have to ask on a more busy hour
<atka>the_tubular: all good, I'll check the logs sometime
<atka>I prefer to run a bunch of suckless stuff so if I figure it out, I'll pass along the info
<rekado_>propagated inputs are best avoided
<rekado_>it’s not about runtime dependencies
<the_tubular>Altough I kind of let go suckless stuff to try wayland in the last year
<rekado_>it’s about whether or not to install packages into the same location
<the_tubular>I'm not sure I understand rekado_
<atka>the_tubular: yeah, I've been wanting to switch to wayland but I just don't think its quite there yet, sway seems mature but I'm not the biggest i3 fan, I haven't found a suitable dwm replacement
<atka>I'd love to be on wayland + pipewire...soon maybe
<ecraven>if that's your cup of tea, EXWM (the emacs window manager) is really nice ;)
<the_tubular24>It's not using wayland thoughè
<efraim>/gnu/store/cciydgr8kc3jln1rr7q4glgqq3gy44bm-hello-2.10/bin/hello: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), dynamically linked, interpreter /gnu/store/12y2vx496r7s3hpy3v1as9wv8fhj33ih-glibc-2.33/lib/, for GNU/Linux 2.6.32, stripped
<efraim>the wip-riscv branch works for building to hello. time to choose the next target :)
<atka>ecraven: I've been wanting to try it, baby steps though, just started using guix recently, want to try emacs after using vi(s) for quite a while, but I wouldn't mind living in emacs if possible
<the_tubular24>vis is great!
<atka>yeah! my current setup is guix + dvtm + vis
<atka>super minimal, no X or wayland
<the_tubular24>I haven't swallowed the emacs pill yet either
<the_tubular24>I doubt I will though
<atka>I might try the evil way...I want to learn guile and lisp/scheme in general so emacs might be good
<atka>the_tubular24: have you noticed a key delay in vis on guix?
<the_tubular24>vis works well with guile
<atka>hmm, I dunno what it is, but when typing it doesn't display a character sometimes until I type the next one then both appear at the same time
<atka>been driving me crazy the last few days
<the_tubular24>I can't help :/
<the_tubular24>It only happens with vis ?
<atka>yeah, vi is fine and other programs as well
<ecraven>thanks, vis looks interesting.. I should use sam.el a lot more in emacs
<boeg>Anybody know of a good resource for getting started with using guile on guix for scripting purposes where you might normally reach for bash ?
<boeg>on guix system*
<leoprikler>What kind of bash scripts are you thinking about? You can still bash script normally on Guix System if that's a concern.
<boeg>its not, its that i have been bash scripting on guix system, but i'd like to try and use guile instead and was seeking a starter
<boeg>for example i have a bash script for connecting and disconnecting my bluetooth headphones, for running backups and so on. A resource showing what parts of guile one might use for "commanding the guix system"
<leoprikler>Hmm, `info '(guile)Guile Scripting'` is a start for general purpose stuff.
<boeg>leoprikler: thanks, ill check it out
<leoprikler>For "system" stuff, I'd recommend writing shepherd services similar to how I'd recommend using systemd for such things on foreign distros
<boeg>right, indeed
<civodul>Hello Guix!
<vivien>Hello guix, I’m writing an experimental server (, I’m using my own channel to have it installed on my machine. Would you be interested to have it in main guix?
<vivien>Or maybe wait a bit until it’s more mature?
<civodul>vivien: nice!
<civodul>i'd say you can submit a package definition when you make the first release
<civodul>you should advertise it on, others may be interested
<civodul>i see you went with Nettle; did you consider using guile-gcrypt?
<mothacehe>hey guix!
<PurpleSym>Is it somehow possible to set metadata like repository name for `guix pack -f docker`?
<civodul>hey mothacehe & PurpleSym!
<civodul>PurpleSym: currently the "repository name" is hard-coded, automatically computed
<civodul>would be nice to have an option to set these things
<PurpleSym>civodul: Yeah, looking at the code and wondering how to `docker run` the image if I don’t know its repo name in advance :/
<civodul>actually each backend potentially has its own options
<civodul>PurpleSym: the repo name is the concatenation of the package names
<civodul>i may be documented, not sure
<civodul>so if you do "guix pack -f docker coreutils grep sed", it's "coreutils-grep-sed"
<PurpleSym>That’s not necessarily unique, since it’ll be truncated to 40 characters.
<civodul>we need a way to set backend-specific options like this one
<PurpleSym>Maybe it’s docker’s fault here for not returning the image id from `docker load` too…
<civodul>hmm "docker load" does return the ID, doesn't it?
<PurpleSym>Just the repo name, which, as discussed, might not be unique :/
<PurpleSym>I’ll just go and yell at docker, thanks :)
<civodul>i guess you can report a bug then
<civodul>that's another incentive to implement backend-specific options
<vivien>civodul, I did, but I couldn’t understand how that works, plus nettle had a really good clear manual. I can switch to guile-gcrypt, if I understand how it works.
<civodul>vivien: guile-gcrypt has a manual too ("info guile-gcrypt"), but i'm interested if you have feedback on that!
<PurpleSym>civodul: It seems backend-specific options are already implemented, but only .deb makes use of it (via extra-options).
<PurpleSym>But they’re not documented in the manual.
<civodul>PurpleSym: indeed, that's brand new!
<civodul>now we need a mapping from backend-specific CLI options to #:extra-options
<civodul>not sure what it should look like
<vivien>civodul, it’s not very exhaustive (that’s just because the project is a binding for gcrypt, so it’s expected for its manual to only cover the scheme part), and I don’t know what form a "guile" sexp takes to be converted to a "canonical" sexp. The best help for me would be if it had further examples about sexps vs canonical sexps, how to access the RSA and ECC parameters, how to sign and verify signatures, and have the
<vivien>list of function with their arguments for generating random numbers, and encoding and decoding with base64 (I just need the base64url variant without padding). The hashes seem clear to me.
<civodul>vivien: yeah, these parts of the manual are missing quite a few bits
<civodul>well, we should fix it, and then we have a good reason to make another release :-)
<vivien>I have to say, I’ve had trouble with nettle to manage callbacks in a way that does not make guile crash, and I’m really not happy to have to ship more C code (plus, what if one day you rewrite the garbage collector lol) so that would be one more reason.
<vivien>Anyway, first I want to get the name changed because webid-oidc is a stupid name and since the authentication protocol switched to Solid-OIDC it’s not even relevant anymore
<maximed>If I package a bunch of Minetest mods, would it be ok to create a new module (gnu packages minetest) for these mods?
<maximed>I'm writing an importer for minetest mods using the API of, and it appears to work, though a patch to 'minetest' is required such that minetest actually finds the mods
<rekado_>maximed: if there are more than a handful of mods you can create a new module for them.
<rekado_>otherwise you could just add them to the same module where minetest resides
<cbaines>civodul, there hasn't been a gnutls release with the latest fixes for the guile bindings, right?
<cbaines>I guess it would be good to have a new release, since then it could potentially be included in the core updates changes
<vivien>I like tail-recursive acronyms :)
<NicholasvonKlitz>How do you deal with rust workspaces (monorepos where a single git repo contains several crates) when packaging?
<maximed>rekado: I'm adding about 7 mods.
<jlicht>NicholasvonKlitz: same origin for several packages, some chdir phase to get to the right subdir for each package perhaps
<jlicht>I don't package rust stuff though, so take my advice with a grain of salt :)
<maximed>There are a lot of mods on <>, so I'd imagine other people will package other mods and (gnu packages minetest) would grow over time
<leoprikler>I think we can push those packages over to minetest.scm once they reach a certain size
<leoprikler>I wouldn't create a minetest.scm file for two or three mods, though
<vivien>Do you have an example of how to use (guix docker) build-docker-image to create a docker image with hello in it? I don’t understand what the "paths" and "prefix" arguments are about. Should I put a list of packages in "path"? If so, what is "prefix"?
<civodul>vivien: you can look at how (guix scripts pack) uses it, but note that (guix docker) is semi-private (or semi-public?)
<civodul>cbaines: right! i lost track of it, lemme see
<civodul>cbaines: the fix will be in the yet-unreleased 3.7.3:
<civodul>let's apply the patch to 3.7.2 for the time being
<civodul>(it's rather small)
<vivien>I was looking for (guix pack) and I could not find it (obviously). So I think docker-image in (guix scripts pack) is what I want.
<civodul>yes, probably
<civodul>eventually, we'll probably consolidate it as an official API in (guix pack)
<civodul>that's how it often works: things are nurtured internally in the modules that use them, and eventually turned into a public API
<dstolfa>civodul: i updated our guix-jupyter stuff, still works after your release, so all is well! :)
<vivien>Mmh maybe I would be better off with a bash script invoking guix pack then
<vivien>(or a non-bash script)
<civodul>could be
<civodul>dstolfa: yay!
<civodul>dstolfa: if you publish notebooks that use it, i'm interested in taking a look!
<dstolfa>civodul: i will likely publish them with my dissertation, pinned to a guix commit (+ all the data that i gathered)
<dstolfa>i'll let you know once they're all public
<civodul>dstolfa: neat
***Server sets mode: +Ccntz
***tissevert1 is now known as tissevert
***jpoiret1 is now known as jpoiret
***Lightsword_ is now known as Lightsword
<jorge[m]>Hola,puede algun colaborador revisar mi reporte
<roptat>jorge[m], "Entry not found"
<rekado_>jorge[m]: do you have network?
<rekado_>you can also try: sudo herd restart nscd
<jorge[m]>rekado_: si
<jorge[m]><roptat> "jorge, "Entry not found"" <- Se venció el anterior,tengo este
<roptat>looks like DNS or nscd issues
<PurpleSym>rekado_: I looked at that article wrt PYTHONPATH again and implemented a simple finder, which works similar to how NPM packages work (i.e. subdirectory in package dir, which has links to dependencies). The simple PoC works, but it’d have to show it works with Guix too.
<PurpleSym>Here’s what it looks like: Unfortunately we have to unwind the stack to get the caller :(
<podiki[m]>hey #guix, long time no see
<podiki[m]>how frozen is frozen for core-updates now? I ask because I am that broken record still trying to get very out of date Mesa updated (patches have been ready to go, libdrm and mesa)
<roptat>podiki[m], it only accepts fixes now, no more updates
<roptat>you can still target core-updates, which will be merged in the next cycle
<podiki[m]>the patches have been done for a long time, i'm not sure why the holdup?
<podiki[m]>i've been trying for weeks to get them merged in core updates
<roptat>mh, did you send them to guix-patches@?
<roptat>they might have fallen through the cracks...
<roptat>sorry about that :/
<podiki[m]> and
<podiki[m]>I know there are a lot of patches and we need more people-power, I understand
<podiki[m]>I had updated the mesa patch since there were 2 more bugfix releases from when the patch was first submitted
***xMopxx is now known as xMopx
<roptat>which patch should be applied first?
<podiki[m]>libdrm (mesa depends on libdrm update)
***Noisytoot_ is now known as Noisytoot
<civodul>podiki[m]: i think it's still time for patches to things like mesa on core-updates-frozen
<civodul>so yes, someone™ should take a look (it might be me this week-end, we'll see!)
<podiki[m]>civodul: great, thanks! (I was away for a few weeks but back now, so if anything comes up with the patches I will be around)
***Kimapr0 is now known as Kimapr
<rovanion>My Awesome WM does not have my ~/.local/bin in the PATH it uses to launch programs. Any idea as to where that PATH might be set?
<roptat>~/.profile or /etc/profile maybe?
<rovanion>~/.profile looks like it sets it, will have a look at /etc/profile.
<Guest33>hi guix!
<Guest33>I think the setuid-programs declaration in operating-system is broken.
<Guest33>Suppose I wanted to add vlock to the setuid-programs. Shouldn't `(setuid-programs (cons #~(string-append #$kbd "/bin/vlock") %setuid-programs))` work?
***dstolfa_ is now known as dstolfa
***karthik[m] is now known as SaiKarthik[m]
<leoprikler>Guest33: setuid programs recently changed to a record-based interface
<Guest33>Ok. I'll pull and check the manual for that.
<leoprikler>if you want to use a gexp as before, wrap the #~(...) in a (file-like->setuid-program ...) call
<Guest33>leoprikler Perhaps that should be clarified in the manual. `(setuid-program (program (file-append #$shadow "/bin/passwd")))` fails because there is no gexp to match the ungexp.
<Guest33>It looks like it works fine if I remove `#$`
<Guest33>Another thing, isn't working with ungoogled-chromium...
<Guest33>Access to XMLHttpRequest at '' from origin '' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
<Guest33>by guix
<roptat>that sounds like maybe a plugin is blocking this? I see these CORS policy errors when using umatrix in icecat for instance
<roptat>or an issue with the headers of
<rovanion>roptat: Figured it out. I exited my .bashrc before setting the path if it was a noninteractive session. Thanks for the clues!
<thorwil>hi! i had to set up a new ubuntu installation and decided to use the apt-get packaged guix. after `guix pull` i started to wonder: are there differences from the script-driven or manual installation in ongoing use?
<thorwil>the first oddity is that this guix doesn’t know audacious and libreoffice
<thorwil>then even after explicit `guix install inkscape` (normally, I use a manifest), `which inkscape` is "".
*GNUtoo sees libreoffice on i686 and on x86_64
<NicholasvonKlitz>While trying to package 2 rust crates that are dependent of each other, I am facing some issues. Any suggestions/experience?
<NicholasvonKlitz>Theses are the 2 crates:
<NicholasvonKlitz>And these are the package definitions I have so far:
<dstolfa>thorwil: while guix can be packaged, it's probably not something that should be updated by the distribution and left alone, however from the issues you're describing i think it's clear that it's not been packaged correctly
<NicholasvonKlitz>When building either of the packages I receive the following error:
<thorwil>i removed the guix apt-get package, but of course now that there is a /gnu/store, the installation script refuses to work
<drakonis>debian's guix package is entirely under vagrantc's auspices
<thorwil>luckily, this time i could delete the whole store and various other traces to finally get the script to work
<drakonis>technically, it's not packaged wrong, it's debian's rules that made it behave strangely
<thorwil>based on my experience, i would say that package has no place in any official debian or ubuntu repository
<drakonis>nix is also packaged there but it is in worse condition
<drakonis>i think opensuse has a package for it
<drakonis>it works surprisingly well
<drakonis>the most troublesome part here is that the packages are frozen at a specific revision
<drakonis>debian bullseye is frozen at 1.2
<drakonis>they're all inherently conflicting with the packaging model
<Noisytoot>does guix pull work to update it?
<maximed>I think the idea is that you do "sudo apt-get install guix" for an initial guix version to start with (and to run the guix daemon) and then do "guix pull" like on Guix System to get up-to-date packages
<thorwil>i was pleased how fast works, but now i have to note that things still don’t end up in my path!
<thorwil>i though it would take care of all the linking and environment variables?
<drakonis>Noisytoot: it should
<drakonis>but there are paper cuts
<drakonis>thorwil: you should log out first
<drakonis>hmm, 1.3.0 is on experimental, not even unstable
<thorwil>drakonis: had done that already. the one missing ingredient is `GUIX_PROFILE="/home/thorwil/.guix-profile"` `. "$GUIX_PROFILE/etc/profile"`
<drakonis>if i remember correctly, the big gotcha with debian's guix package is that you can only run guix as a superuser
<drakonis>maybe not
<drakonis>just chucked it into a container
<drakonis>works fine lol
<drakonis>systemd-nspawn is terrible
<drakonis>its blocking access to the keyring so i cant do pulls from a container
<NicholasvonKlitz><NicholasvonKlitz> "While trying to package 2 rust c" <- Just wanted to follow up on this in case someone had a stroke of genius :)
<dstolfa>NicholasvonKlitz: well... that's a new horrible, even for rust. i guess this is because it's just statically linked so it doesn't technically matter, but this is just a new level of awful
<dstolfa>rust never fails to disappoint me even further
***taylan2 is now known as taylan
<dstolfa>NicholasvonKlitz: this is probably due to rust statically linking all of this mess together so it "doesn't matter", but it's horrible regardless.
<dstolfa>i don't know if guix allows cycles in dependencies
<dstolfa>i'd say probably not?
<dstolfa>NicholasvonKlitz: try using #:cargo-development-inputs, maybe that works (see examples in gnu/packages/crates-io.scm)
<NicholasvonKlitz>dstolfa: Thanks. Actually turns out the initial error I was describing results from the monorepo housing the two crates having set `resolver = 2`. I need to patch the Cargo.toml before build to override the resolver version. Afterwards I'll see if guix gives any errors for circular dependencies
***jonsger1 is now known as jonsger