IRC channel logs
2024-10-26.log
back to list of logs
<rekado>redacted: why are you using gcc without a C library? Is that on purpose? <ekaitz>redacted: you are using it in a `guix shell` right? <ekaitz>our cross compilation is broken in guix shell if i'm not mistaken, it searches the wrong things and explodes <ekaitz>Rutherther made some package for arm-none-eabi-toolchain that actually works <macabro>I'm having issues installing or upgrading the emacs-elpy package, how do I report it? <luca>check out /topic bugs & patches link I suppose <luca>Oh it fails during the check phase <wdkrnls>Dear Guix, I keep getting errors when I try to upgrade the guix-daemon: guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function. <wdkrnls>I've tried a couple of times and it seems consistent :/ <redacted>ekaitz: I'm installing it with `guix package -e` <redacted>And no, doing it without a C library is by ignorance, not intent. <redacted>I don't really understand what I'm doing. <ekaitz>redacted: i'm not sure if installing would work, probably same issue <lilyp>nutcase: can you edit your Cargo.toml to just say 0.2.5? :P <podiki>anyone suddenly getting a certificate failure for ci.guix.gnu.org? unknownissuer <nutcase>lilyp: maybe that is possible, but I don't think that this is something I should do, when 0.2.1 is available at cargo.io, right? <lilyp>Rust crates are notorious for having overly specific requirements – we patch them all the time <graywolf>Hello :) Not sure who to ping, but there is typo in the natest blog post: `If it is vulnerable, the last line will contain your system is not vulnerable,' <graywolf>I am pretty sure that should start with `If it is *not* vulnerable <z572>on qa.guix, mesa-updates say "Merge base has not be processed by the data service yet." It seems like there has been no movement for five days, maybe we need rebase it to master, let qa reprocess it? <graywolf>civodul: Hi :) Not sure who to ping, there is a typo in the blogpost regarding the daemon vulnerability. <civodul>i’m happy to fix more typos though, tell me :-) <graywolf>`If it is vulnerable' should be `If it is not vulnerable' I believe. <civodul>(anyone with commit access can do it) <getstate>Do I need to package all dependencies for a go package? Trying to update restic, but the azure SDK is painful w/a lot of transative dependencies. I'm also not a go dev, so idk what I'm doing =) <jaft_r>Does anyone else have issues with mcron scheduling? <jaft_r>I've got a job in my home profile that runs a Guile script. I know the script works and I know that mcron can run it as, when I first set it up, things ran fine. The script shoots off a little notification, at the beginning, to alert it's going to run. It's supposed to run at the same hour, every day, and doing a "herd schedule mcron" shows the correct schedule. <jaft_r>But I started to notice it would run a good 3 or 4 hours before or after it was scheduled to run. And, now, it never seems to run, at all. <jaft_r>I never paid close attention, before, to other short times I'd tried setting up an mcron job but I did seem to notice this with previous jobs before, never quite seeming to run exactly at the time I scheduled, eventually. <getstate>Stumbled upon #69872, which is what's blocking me atm - will just wait until that's merged. <chloris>how can I check if I have installed "meson" in Guix SD? <jaft_r>chloris: "guix package --list-installed" will tell you anything you've installed via "guix install <package>". <chloris>thanks, I didn't install it, but may be it is a dependence of another package and it was installed <chloris>"guix package --list-installed" shows the main packages <Rutherther>chloris: you can check referrer paths of your profiles with guix gc <Rutherther>chloris: but I doubt you would have it installed. It's a build dependency, why would any package propagate it... <chloris>If I have installed a package, and I install it again, is there a problem? <chloris>you can check referrer paths of your profiles with guix gc how do I check this? <lh>what is going on with the mesa-updates branch? Andreas commented that he rebased it a week ago but it seems like there have been more rebases since <lh>the current version of mesa has bugs that cause guix programs to crash on one of my systems :( <civodul>lh: i think podiki is shepherding it, waiting for a CI green light <podiki>lh: what bugs? mesa on there is the latest stable release, i run my system from there at least <podiki>unfortunately QA hasn't said anything for at least a week now? coverage for i686/x86-64 should be as good as it gets, no idea on others unfortunately <podiki>i know efraim had reported success of building mesa at least on others <podiki>i can do a rebase today though i don't know if that will help qa <crzjp>hello everyone, i'm trying to setup a tiny development setup using emacs and manifests: in eat (an emacs terminal), I start a shell with `guix shell -m path/to/manifest.scm` and get the tools installed, but I'd like to expose the new environment to my running emacs session, so it can recognize for example the tools executable path. how can I do this? or there is a proper/better way? <Rutherther>crzjp: direnv with envrc package in emacs is quite nice for that <sadmax>I am having a hard time using Guix while trying to develop a Rust project. <sadmax>But then `cargo build` complains with `/home/zlef/polars/target/debug/build/num-traits-f133684cb30af2df/build-script-build: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory` <sadmax>And I cannot, for the life of me, figure out how to get these libraries sorted out. <crzjp>Rutherther: yes I could take a look on it and seems pretty neat, but I dont understand how to setup it, like, is there a command so guix shell prints the paths or something? <sadmax>I'm not super familiar with the linux build system <crzjp>`guix shell --search-paths` dont print useful output <Rutherther>crzjp: what do you mean? it's super useful output... you just use "use guix" in .envrc, it will use guix shell --search-paths under the hood itself <crzjp>sadmax: sad, its rust related too <podiki>sadmax: if you don't already have a gcc-toolchain input in guix shell, then you need that. otherwise it could be that it is trying to load something else (even though it complains about that library), so try running with strace or using ldd on what is being executed <sadmax>I do have the gcc toolchain. I construct my environment with `guix shell --network --container --emulate-fhs qemu bash coreutils curl grep nss-certs gcc-toolchain pkg-config glib cairo at-spi2-core gdk-pixbuf gtk+ git --share=$HOME/Developer/rustup/=$HOME` <crzjp>Rutherther: WHOA, sorry, just have a HUGE inattention of mine, I was running `guix shell --search-paths` without the related package, so it wasnt doing anything xD <sadmax>crzjp: Which guix package contains ldd? <Rutherther>given that gcc-toolchain is union build of gcc and libc, it's not surprising finding :D <crzjp>about the shell and env thing, now i have the way to solve the rest. thank you all! <sadmax>zlef@zlef-guix ~ [env]$ ldd .cargo/bin/cargo <sadmax> linux-vdso.so.1 (0x00007f4d08808000) <sadmax> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f4d087d0000) <chloris>If I want to install C++17, there are many packages:tomlplusplus 3.4.0 <chloris>Header-only TOML config file parser and serializer for C++17 <chloris>Header only C++ std::filesystem compatible library <chloris>C++17 header only library for compile time reflection of enums <sadmax> librt.so.1 => /lib/librt.so.1 (0x00007f4d087cb000) <sadmax> libpthread.so.0 => /lib/libpthread.so.0 (0x00007f4d087c6000) <sadmax> libm.so.6 => /lib/libm.so.6 (0x00007f4d086e6000) <sadmax> libdl.so.2 => /lib/libdl.so.2 (0x00007f4d086e1000) <sadmax> libc.so.6 => /lib/libc.so.6 (0x00007f4d08503000) <sadmax> /lib64/ld-linux-x86-64.so.2 => /gnu/store/13c6dkn0n40mb5xqhy1xg9vra30clrqi-glibc-for-fhs-2.39/lib/ld-linux-x86-64.so.2 (0x00007f4d0880a000) <lilyp>sadmax: please use a paste service <chloris>which of the packages should I install? <lilyp>chloris: personally, for dev stuff, I prefer a guix shell – use `gcc-toolchain` along with whatever packages you need <Rutherther>chloris: what do you mean you want to install c++17, do you mean you want a compiler that supports compiling c++ version 17? <chloris>I wanted to install "paps" for printing in emacs and Lois said I should install C++17. What it means exactly I don't know. <lilyp>In Guix you can just `guix install paps` – assuming this is the paps you talk about <Rutherther>chloris: if they meant for you to compile paps, then there is no need as you can use the one from guix channel <chloris>Jean said : I should install _ paps, meson, fmtlib/fmt, cairo, libpaper, C++17. <krascovict>hello everyone, i want to suggest you the Veracrypt package <chloris>and he said, after installing those packages, I should run: meson build , cd build && ninja <chloris>only then "paps" will work correctly in emacs <Rutherther>chloris: that sounds more and more like they meant for you to compile paps itself, but guix does that already... you don't need to compile it yourself <sadmax>I would have expected including gcc-toolchain as a dependency fix `error while loading shared libraries: libgcc_s.so.1: cannot open shared object file` <chloris>do you mean, after installing "paps"? <sadmax>At this point I'm at a loss. I do not know what to do. <sadmax>Is there someody in particular I should talk to with Rust help in Guix? <futurile>sadmax: go back one step. You're trying to develop (polar-rs), and that requires rust nightly right, which you're downloading the binary for. <futurile>sadmax: so you can't use the 'binary' download of Guix, because Guix doesn't keep it's libraries in the standard places. You clear on that? <futurile>sadmax: duh - I mean you can't ue the 'binary' download of Rust, .... <sadmax>Even though I'm in an environment with `gcc-toolchain --container --emulate-fhs` <futurile>sadmax: OK, so that's kinda "option 1" - we use "guix shell" with --emulate-fhs as a way to trick binaries that are expecting the libraries in the "standard" Linux locations. <futurile>sadmax: you can also use LD_PRELOAD and friends, to tell the binary to look in other locations. <futurile>sadmax: so you install some library into the shell, get the new profile path and then do someting like: LD_PRELOAD=$HOME/.guix-profile/xxxx/libs ./my-compiled-binary <sadmax>Sort of -- I'll try to read up on it. <sadmax>In general though -- are there docs for doing this sort of stuff? <sadmax>I know very little about gcc and build systems and make and whatnot. <futurile>the guix-help mailing list in the arhives is a good place to search. This isn't really Guix specific, it's generally "manipulation the shell for builds" knowledge, so it's spread around <futurile>sadmax: what platform do you usually do your Rust dev on? <futurile>sadmax: as (option 2) is to run a VM and do your dev work in there to start with. <Rutherther>sneek, later tell chloris: if you wanted to go the VM way I think a better way is to use Nix instead, you still have lot of benefits of Guix, and it has a mechanism for obtaining rust toolchain without downloading it as a binary, see https://ayats.org/blog/nix-rustup for details <sadmax>I ususally run Rust on my work machine which is arch linux <Rutherther>oh sorry that message was for you sadmax, not chloris, I got confused <Rutherther>sneek: later tell chloris: scratch that message, I got confused <futurile>sadmax: so there's you're option on the VM front. You could start a VM under Guix, load Arch into that and use rustup there. You could also run the Nix service on Guix as Rutherther suggests. <sadmax>I have considered using Arch as the OS and Guix as the package manager. <sadmax>I'm frustrated with my lack of understanding of this stuff. I feel as though this _should be possible_ and I'm missing something simple. <futurile>sadmax: also a good option. I started that way as I've used Ubuntu/Debian for a long time. <futurile>sadmax: I don't think you're missing anything. You basically landed up in the hard stuff immediately ;-) <futurile>sadmax: I started by using Guix on Ubuntu like a "normal" package manager; then I started using declarative stuff for my packages; then got into the other parts - using VM's <sneek>Welcome back x8dcc, you have 1 message! <sneek>x8dcc, Rutherther says: you should add ~/.guix-profile/share to XDG_DATA_DIRS in your shell profile file. That way fonts can be detected and also other things (launcher apps, icons, themes). You might have to run fc-cache manually first time/after adding fonts <sadmax>futurile: ah, well I appreciate your help <sadmax>And I'd *love* any books/web resources to learn this stuff of stuff. <x8dcc>Is root supposed to own the contents of ~/.config/guix/current/ ? <x8dcc>or ~/.guix_profile/ for that matter <futurile>sadmax: no worries - sorry it wasn't an better solution <Rutherther>x8dcc: that symlink? I wouldn't say so, your user should own it. But it's true that it links to store that is then owned, correctly, by root. So depends on what you are actually looking - owner of symlink or owner of target of symlink <Rutherther>x8dcc: if you are looking with that appended "/", then you are looking into the store that is owned by root, so it's correct <x8dcc>Rutherther: The symlink is owned by my user, but the contents are not (/var/guix/profiles/per-user/username/current-guix/*) <x8dcc>Ah, okay. I was going to add what you suggested to ~/.guix_profile/etc/profile, but it's read-only. Is it the right place? <x8dcc>Ideally, I would like to keep most of the guix stuff in guix files, not in ~/.bash_profile, for example <Rutherther>x8dcc: what I suggested should probably not be added to there - or if you really wanted to you would have to install a package with search path that adds XDG_DATA_DIRS <x8dcc>Hm, I am not sure what you mean by "a package with search path", sorry :/ <x8dcc>Okay, so if I understood correctly, the font package should have added that, right (in theory) <x8dcc>The package declaration for the font should have used `native-search-paths' <x8dcc>Or did I understand it wrong?