<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 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 <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>maybe I'm not doing something right <LevyElara[m]>zig tries to use the native C compiler to figure out where things are <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 <Noisytoot>Is Guix using the old version (that didn't change the license yet)? <leoprikler>that said, you might want to update the OpenTTD package(s) *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)? <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` https://0x0.st/-W0V.txt <LevyElara[m]>It's not passing `-lc++` so `exe.linkSystemLibrary("c++");` but then it fails on the `@cImport()` <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]>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? <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 <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 <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? <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>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 <lispmacs[work]>your technological and biological distinctiveness will be added to our own ***califax- is now known as califax
<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>propagated inputs are for runtime dependencies <char>but package B is not a runtime dependency of A <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. <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. <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 <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 <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 <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 ;) <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/ld-linux-riscv64-lp64d.so.1, 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 <atka>yeah! my current setup is guix + dvtm + vis <atka>super minimal, no X or wayland <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? <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 <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 ? <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 <vivien>Or maybe wait a bit until it’s more mature? <civodul>i'd say you can submit a package definition when you make the first release <civodul>you should advertise it on guile-user@gnu.org, others may be interested <civodul>i see you went with Nettle; did you consider using guile-gcrypt? <PurpleSym>Is it somehow possible to set metadata like repository name for `guix pack -f docker`? <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>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 :/ <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). <civodul>PurpleSym: indeed, that's brand new! <civodul>now we need a mapping from backend-specific CLI options to #:extra-options <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 content.minetest.net, 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? <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 :) <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>let's apply the patch to 3.7.2 for the time being <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>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 <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 ***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 paste.debian.net/1205873 <rekado_>you can also try: sudo herd restart nscd <jorge[m]><roptat> "jorge, "Entry not found"" <- Se venció el anterior,tengo este paste.debian.net/1206059 <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. <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... <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? ***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>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 `#$` <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 kiwiirc.com <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? <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 <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>the most troublesome part here is that the packages are frozen at a specific revision <drakonis>they're all inherently conflicting with the packaging model <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 guix-install.sh 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>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>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>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