IRC channel logs

2024-08-18.log

back to list of logs

<vagrantc>ieure: taking a stab at the latest librewolf patches ...
<vagrantc>ieure: they are simple enough even i can read them :)
<vagrantc>been meaning to take a peek at librewolf anyways...
<Franciman>wow we have librewolf?
<Franciman>i can't wait to try it
<vagrantc>yeah, though a little lagging due to lack of reviewers...
<vagrantc>ieure: hrm. nss-rapid failed to build :/
<vagrantc>does guix not produce unique logs per build? i effectively restarted a build that failed ... but now the log is truncated
<vagrantc>the log for the original build
<vagrantc>and my scrollback does not go back far enough to see the what exactly failed
<vagrantc>huh. second build of nss-rapid worked. *shrug*
<nckx>vagrantc: <does guix not produce unique logs per build?> Just to confirm: it does not.
<vagrantc>nckx: thanks for the confirmation.
<vagrantc>and hi!
<nckx>o/!
<nckx>That looks more like a little dude fishin' than was intended. Hi!
<vagrantc>ACTION whio
<vagrantc>hah.
<vagrantc>ACTION whispers sneakily about capabilities patches for guix
<nckx>Oh. Yes. Well! Yes.
<nckx>I re-saw it today when rebasing my commits so it comin'.
<nckx>Sorry for the delay.
<vagrantc>last i tried not crazy long ago they still rebased pretty easily and worked ...
<vagrantc>guess that was late 2023 :)
<vagrantc> https://issues.guix.gnu.org/61462 for those following along at home :)
<nckx>OK, I don't think my version has changed significantly.
<nckx>That's for tomorrow. 'Night!
<vagrantc>ACTION waves
<vagrantc>ACTION calmly listens to the rare sounds of thunder passing overhead...
<pabs3>noracodes: which hardware will you be getting?
<LesikEdelweiss>Hi! I'm quite a begginer here, and I try to package Hyprland, which recently dropped wl-roots if favor of its own library aquamarine. However, it seems all Hyprland code require GCC 14 for C++26 support. How can I tell in a package to use GCC-14 when compiling? And is there any chance that code that requires GCC 14 will be merged to the upstream?
<jaft_r>Hey there, LesikEdelweiss; could you share what you have written for your package definition, so far?
<jaft_r>(just via https://paste.debian.net or https://pastebin.com/, etc.)
<LesikEdelweiss>Sorry, I've never used IRC before, and I'm trying to login from my PC
<jaft_r>No worries; took me a bit to get the hang of – too –, first time I joined.
<lilyp>LesikEdelweiss: Add gcc-14 to native-inputs, that ought to do it.
<lilyp>Yes, the patch should be accepted, as long as you have the comment "; for C++26 standard" or similar
<LesikEdelweiss>So, jaft_r, right now I've written a definition only for Hyprutils, which is a dependency of Hyprland https://paste.debian.net/1326747 and successfully built it with --with-c-toolchain option.
<LesikEdelweiss>lilyp, Thanks, it worked! Strange thing it's not in manual, it probably should be included there (only thing I've found in manual was the "package-with-c-toolchain" procedure, but I couldn't get that to work)
<lilyp>That is a transformation for a c package that already works – you swap out the default gcc (GCC 11 currently) with the one specified as argument
<LesikEdelweiss>Hi! I'm still trying to packaging Hyprland, and while trying to build it's dependency "aquamarine" I meet an error that I can't resolve, the definition for aquamarine is https://paste.debian.net/1326752/ and the error I get is "Could NOT find OpenGL (missing: GLES2)". I assume I need to patch CMakeLists.txt in some way for it to find libGL.so?
<Rutherther>it says GLES2, have you tried adding mesa to inputs?
<Rutherther>also I am pretty sure hyprland-scanner should be in native inputs, as it's a used to scan for deps during the build process
<LesikEdelweiss>Rutherther, sorry, I forgot to put mesa back in inputs after I was trying to resolve this issue, with mesa it still gives me the same error. Also good point about hyprwayland-scanner, thanks
<LesikEdelweiss>The error is in CMake "FindOpenGL" thing, and I've found that it could be resolved with "set(OPENGL_gl_LIBRARY /path/to/libGL.so)" in CMakeLists.txt, but I'm not sure on how to add this string to a file and how to get path to libGL.so
<Rutherther>hm. I am not sure it's the way to go. In Nix aquamarine is without patches, seems that pkgconfig just finds it. But if you wanted to go this way, you could use search-input-file to search for libGL.so path
<Rutherther>and patch it inside of a phase
<LesikEdelweiss>Thanks, I'll try it. Maybe someone could figure out a better way, but if it works it'll be good for now
<bdju>horrible gajim breakage, can't decrypt or send messages suddenly after crash + restart. didn't remember upgrading packages recently but that's the only thing that makes sense
<bdju>is there a way to check when my last guix upgrade was
<bdju>like n days ago
<bdju>I know it warns you if you install something without doing a pull in a while so surely it's keeping track somewhere
<bdju>wow list-generations is way more slow and intensive than I would've guessed
<bdju>okay these are dated. my last several generations were installing or updating single packages so it's for sure been over a month since gajim would've been updated. I'm skeptical I had it open that whole time with an old version in memory
<bdju>my terminals have been laggy and weird lately too and my thumbnails are broken in pcmanfm-qt. the number of broken things is growing with no signs of salvation. truly suffering
<bdju>I swear under 10 people must use half the packages I use for them to stay in this broken state so long
<bdju>I'll first gamble on upgrading everything again and if that doesn't seem like it'll fix gajim I may have to next try rolling back about ten generations and see how that goes
<LesikEdelweiss>About my error with Hyprland. This is probably because our CMake is too old, the OpenGL "GLES2" component support in CMake was introduced in 3.27, and ours is 3.25. There is a patch for newer CMake here: https://issues.guix.gnu.org/70675 , but it's not applied
<Rutherther>hm, that's interesting
<LesikEdelweiss>I'll try to build it with an updated CMake and check if it works
<xFFFC0000>I have installed liblzma, but still cmake is not able to find liblzma-dev library. Any suggestions? the package I want usually provided in deb based distribution with liblzma-dev.
<lynn_sh>hello. when I moved over to guix, i copied over my ~/.gnupg folder as well to continue signing things with my identity. im trying to use it at the moment, but gpg --list-secret-keys is empty so I am guessing I am missing a service, or guix is looking somewhere else for my keys. Any direction?
<xFFFC0000>( a minor correction about my question. I want static lib. not the dynamic. dynamic `.so` is present )
<bdju> https://0x0.st/X4Rv.txt
<bdju>whoops there was a newline on my clipboard
<bdju>that's an openscad build failure I just hit
<jonsger>ACTION resumes work on icedove@115
<nckx>xFFFC0000: There's an xz:static with a liblzma.a. Many other packages in Guix don't bother building or installing static libraries, though.
<nckx>sneek: later tell lynn_sh Guix doesn't use any weird/custom gnupg locations I'm aware of. Mine are in ~/.gnupg/private-keys-v1.d/ if that helps.
<sneek>Will do.
<nckx>sneek: later tell lynn_sh Also, make sure your permissions survived the copy. They should be 700 for the directory, 600 for the files.
<sneek>Okay.
<bdju> https://0x0.st/X47O.png why is this 2 year old issue suddenly affecting my gajim that was fine a month ago? maybe I'm missing something here
<bdju>upgrading all my packages did not fix it sadly
<Rutherther>are you sure it doesn't cache anything? if it does, have you tried removing its cache?
<bdju>that python env var thing from the gajim gitlab actually worked but they make it sound like a non-optimal solution
<apoorv569>anybody here have thoughts on running jack apps with pipewire without needing to do pw-jack APP?
<apoorv569>like on arch linux for example, there is a package you can install, pipewire-jack
<apoorv569>AFAIK, it moves the jack libs to /usr/bin replacing the standard jack libs with pipewire ones..
<bdju>I've been wanting to move to pipewire for a while but it seems to require guix home or something, which I wasn't using
<apoorv569>it can be done by adding an option to meson, -Dlibjack-path=
<nikolar>nckx: re the package test timout from yesterday, there's only one place where i can find a set timeout
<nikolar>i kind of just need your help to make a proper patch :)
<apoorv569>i have tried adding this to the pipewire packag, (string-append "-Dlibjack-path=" #$output "/lib")
<apoorv569>but no luck..
<nckx>nikolar: Nice. And it's 300s?
<nikolar>yup
<nckx>Ah yes: tests/at-spi2-atk/meson.build:test('atk-test', atk_test_bin, timeout: 300)
<nikolar>indeed
<nikolar>should i just use substitute* to replace the line
<nikolar>or the ", timeout: 300"
<nckx>Were this me I'd get fancy with (substitute* "…/meson.build" ((", timeout: [0-9]+") "") in case the default changes, but matching 300 is fine too.
<nckx>Can we just omit the 3rd argument?
<nckx>I don't know, but I assume so.
<nikolar>looks like we can
<nikolar>that's actually a keyword argument
<nckx>I don't know how much you know, so let me know with what part you need help. I could also bang up a quick patch if you're not in the mood to be forced to Learn at this time.
<nikolar>i do want to learn :)
<nckx><keyword argument> Thought so, but 100% my Python knowledge was imparted by this weird cult worshipping a cargo crate in the woods.
<nikolar>yeah i am quite familiar with python, but not meson heh
<nikolar>nckx: is there some documentation about contributing
<nckx>Yes! https://guix.gnu.org/en/manual/devel/en/guix.html#Contributing
<nckx>Also available in your friendly local copy of the manual, of course.
<nikolar>does this diff look reasonable nckx: http://0x0.st/X47h.diff
<nikolar>against the current master
<nckx>It does! Only a nitpick: make the comment longer (;; Full line.) to add that it actually caused builds to fail on aarch64.
<nckx>ACTION away a bit.
<nikolar>cool, thanks
<xFFFC0000>nckx: thanks. that was what I was looking for. I was not aware of :static syntax.
<xFFFC0000>Is there anyway to set up CMAKE_SYSTEM_INCLUDE_PATH CMAKE_SYSTEM_LIBRARY_PATH CMAKE_SYSTEM_PREFIX_PATH automatically when starting a guix dev shell? What I want to do is to install all the dependencies via guix, but build my project with cmake.
<Rutherther>are you sure you need that? When I do "guix shell" with cmake and libs, I get CMAKE_PREFIX_PATH, and it seems that inside of this profile there are the libs etc. For example di tried "guix shell -D openjpeg", and the configure phase found everything. I suppose it's thanks to this prefix path
<Rutherther>Moreover I wasn't able to get any matches for the variables you specfied in Guix, so it seems to me Guix doesn't use those in the compilation process. But I might have missed something of course
<xFFFC0000>Rutherther: I was under the impression that I don't need those. But looking at the CMake cache, I see some path are not correct. let me paste it
<xFFFC0000> https://paste.debian.net/1326775/
<Rutherther>keep in mind that this cache will have to be rebuilt when gc removes the dependencies, unless you make sure you somehow gc root them, cmake won't do it by itself
<Rutherther>so how did you start your shell?
<xFFFC0000>`guix shell --development monero`
<xFFFC0000>( one quick question, is there anyway to make shell/env permanent?
<xFFFC0000>)
<apoorv569>xFFFC0000: I use direnv to set some stuff for any guix shell env..
<Rutherther>permanent in what sense?
<apoorv569>I can give you an example, one sec.
<xFFFC0000>apoorv569: good suggestion. Didn't cross my mind. let me try it.
<xFFFC0000>Rutherther: look at this line for example: CMAKE_SYSTEM_INCLUDE_PATH=/usr/include/X11
<xFFFC0000>this shouldn't be here in guix shell. Unless I am missing something
<xFFFC0000>unless it is coming directly from cmake itself : https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_INCLUDE_PATH.html
<Rutherther>are you sure you don't have anythign that overrides your path in .bashrc or other rc file for your shell? have you tried --check with guix shell?
<xFFFC0000>let me double check.
<Rutherther>I have only CMAKE_PREFIX_PATH when I do "guix shell -D monero". No CMAKE_SYSTEM
<xFFFC0000>aha, i see where the misunderstanding coming from. Those are not path variables. those are cmake variables.
<apoorv569>xFFFC0000: https://codeberg.org/apoorv569/CourseByte/src/branch/master/.envrc
<apoorv569>check this out.. this is how I add various libs to LD_LIBRARY_PATH so that I can compile the project
<apoorv569>I also have a manifest.scm file that installs various guix packages in the guix shell env.
<apoorv569>combine this direnv package for emacs.. it auto loads the packages when I open my project in emacs
<Rutherther>xFFFC0000: how are you compiling exactly then, and which revision of the project are you on? I cannot seem to find dependency on zlib in guix definition nor in their CMakeLists.txt. When I ran the configuration, I've got some errors (after it said Configuring done), but different ones, but the build is actually passing
<Rutherther>also skimming through the definition in guix, there is a need to set Readline_ROOT_DIR to readline package
<Rutherther>apoorv569: if you are compiling something, setting LD_LIBRARY_PATH should be unnecessary as the dependencies should be found prior to the build by setting stuff like PKG_CONFIG_PATH, and using pkg config to find them, or for cmake this CMAKE_INCLUDE_PATH. ld lib path would be only for stuff that's not compiled properly with correct paths to the libs
<xFFFC0000>Rutherther: Once I find out why we don't have this as dependency I am will submit a PR: https://github.com/monero-project/monero/blob/a1dc85c5373a30f14aaf7dcfdd95f5a7375d3623/CMakeLists.txt#L1131
<Rutherther>I suppose because it was added only after latest release that's in guix
<noracodes>Hi folks! Thanks to help here I am finally up and running with KDE on Guix. I'm using flatpak for a few missing applications, and I noticed that the Flatpak system service doesn't install the Flatpak share dir to XDG_DATA_DIRS. It's a pretty easy fix, and I'm curious if a patch to change this would be accepted?
<Rutherther> https://github.com/monero-project/monero/blob/v0.18.3.3/CMakeLists.txt this is cmakelists for the release that's used by Guix
<Rutherther>so you will have to add it yourself to your shell, since the newer version changed dependencies
<xFFFC0000>Rutherther: thanks. I will submit a PR to monero, and ( guix too, this one I should learn more about development process )
<Rutherther>pr for what? because it's not in a released version, so I don't see why submit a pr
<xFFFC0000>I believe they would eventually add that to release branch. ( although haven't been added yet )
<snamellit>What would be the best way to add ~/.local/bin to my path with Guix home-manager configuration? guix shell is complaining my startup scripts are clobbering my environment.
<Rutherther>paths should be added inside of profile files, not rc files, that's why it's complaining
<snamellit>Yes, but how to do that properly so it does not capture the value in whatever profile is active at the moment?
<Rutherther>sorry, I don't understand what you mean by that
<xFFFC0000>Rutherther: anyway, thanks for your detailed answers. Helped me a lot :)
<snamellit>Rutherther: I am struggling to add the magic incantations in my home configuration to add to the search paths so that ~/.local/bin is added to the path in my home profile.
<Rutherther>how do you add it now? my guess is in .bashrc (equivalent), and that's why Guix shell is complaining. have you tried just putting it to your .profile (equivalent) file?
<snamellit>isn't the ~/.profile not overwritten on `guix home reconfigure` ?
<attila_lendvai>nckx, re your recent commits: didn't you want to squash them before pushing to master? thinking of guix time-machine or bisecting ending up in the middle of them... or was this intended?
<snamellit>well kinda overwritten, it is a symlink to a file created in the /gnu/store
<nckx>attila_lendvai: I didn't mean to squash them because it shouldn't have been needed. It's academic now, but which intermediate state(s) do you see as problematic?
<Rutherther>snamellit: yes, of course, and I didn't mean for you to add it there manually into the file, I meant to edit it with what manages it, being home-shell-profile-configuration service in this case. But you might want to put it to your shell profile instead, being bash_profile, zprofile etc., I don't know which shell you use, that's why I said "equivalent".
<attila_lendvai>nckx, e.g. adding the new path to the search path in a separate commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e364d1a494140c26f95a90176b3216428bbaf944
<nckx>Why is that a problem?
<nckx>(See commit message for d6c9754c568588929c3350da8f7b17ae92d2b801 for as to why this shouldn't cause issues, unless I made a mistake…)
<attila_lendvai>nckx, if you ask that then i probably just don't understand well enough what's happening. sorry for the noise, i guess.
<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d6c9754c568588929c3350da8f7b17ae92d2b801
<nckx>attila_lendvai: No, it's good to be sceptical.
<nckx>It's just that without concrete examples I can't say much more than ‘uh, it, like, shouldn't break stuff’.
<nckx>I will be keeping an eye out for bug reports because there's a lot of places for bugs to hide.
<attila_lendvai>nckx, maybe it's some kind of a staged solution? where both exists for a while, and the phasing out of setuid programs has not started yet...? then i'd understand how all these separate commits wouldn't cause any issues. but again, i don't have a good model of all the stages in guix, so it's much more probable that i just don't get it through a quick skimming of the commits.
<snamellit>Rutherther: Cool, it seems I can use the `zprofile` field in the home-zsh-configuration to add the path. Thanks a 10^6 for getting me back on the way.
<nckx>attila_lendvai: Yes, my intention was to keep /run/setuid-programs around for quite some time, populated with symlinks.
<nckx>That's the commit message I meant above.
<nckx>Sorry if it wasn't clear. I've seen these patches so often it's hard to look at them afresh.
<attila_lendvai>nckx, no, it's ok, i just didn't look deep enough. but i'm happy to see you back! it makes me wonder whether you managed to get you setup alive, and recover the SSD discard patches... ;)
<nckx>Haven't looked yet but will. My setup is mostly restored… but I keep tripping over baby yaks like git ‘now’ refusing to serve my repositories because of something called safe.directory. Does anyone know how to set (or ignore…) this with git-http-backend? The --global configuration file seems to live in the store, so that's out.
<nckx>The issue seems to be that HTTP fetches use the fastcgi user, whilst SSH pushes use the nckx user, and git expects the user and repository owner always to match.
<xFFFC0000>Rutherther: can you take a look at this: https://paste.debian.net/1326785/ I have gcc-toolchain setup, I am in dev shell with `guix shell --development monero`. But I still get those errors. which says something about the paths/setup
<Rutherther>oh, are you building for amd64? maybe that's the reason Ididn't get so many errors, I was trying only x86_64
<Rutherther>wait I am dumb, I thought it was arm64, sorry
<LesikEdelweiss>So, about packaging Hyprland again, I'm too dumb to do that :0 Apparently it has some bundled things, and I don't know how to unbundle them. Is there someone smarter who wants to package Hyprland too? :)
<xFFFC0000>Yes, amd64, aka x86_64.
<jonsger>apteryx: I posted a v3 on icedove@115: https://issues.guix.gnu.org/67849#8 yet I didn't tried to get localized icedove building, but I think we should pushed it anyways (security fixes etc.)
<apteryx>do we have a sip client that works well? I was using linphone-desktop but Im̀ getting an annoying problem with it: https://github.com/BelledonneCommunications/linphone-desktop/issues/580
<sneek>apteryx, you have 1 message!
<sneek>apteryx, nckx says: Belated thanks for your response to my PM!
<apteryx>nckx: o/
<apteryx>jonsger: I do not currently have any steam in this game; if there are CVEs waiting to be patched, that is a good enough reason to push it as is in my opinion.
<apteryx>we can refine later
<ekaitz>hi, i have guile package that is only guile files and doesn't have any extension but uses some library, how should I package this? do you have any examples?
<ekaitz>I'm using guile-build-system but it's not finding the library it needs even if it's added to inputs
<taeaad>Is there a no-AI rule at GUIX like with BSD?
<taeaad>Or some sort of opinion about it.
<Rutherther>xFFFC0000 sorry, I am unable to reproduce that. For me "guix shell -D monero zlib googletest", "git clone", "git submodule update --init --force", "make -j4" succeeds with whole build
<singpolyma>taeaad: not really an enforceable rule either way
<taeaad>I suppose.
<nikolar>nckx: my parch is on the mailing list :)
<cbaines>nckx, I hacked around the Git serving repositories issue by using fastcgi_param GIT_CONFIG_SYSTEM \"/etc/gitconfig\"; as part of the NGinx config
<nckx>cbaines: That is exactly what I wanted, just a different mechanism. Thank you!
<nckx>nikolar: I'll take a look when I'm not borrowing a 'phone to use a sneaky termux to tunnel through 2 hosts to use weechat at a party.
<nckx>I'm great fun at parties.
<nikolar>lol i like how you party
<nikolar>i am too great fun at parties
<nckx>There's some exxellent gin, which is another good reason not to review patches at this time.
<nckx>ACTION AFK.
<nikolar>kek
<xFFFC0000>Rutherther: anyway to debug this? I am still getting those errors. It is strange it seems guix does not have glibc installed.
<xFFFC0000> https://paste.debian.net/1326816/
<Rutherther>xFFFC0000 could you start from a fresh clone and send commands you execute?
<sneek>Rutherther, you have 2 messages!
<sneek>Rutherther, Rutherther says: hello there
<sneek>Rutherther, Rutherther says: hello
<Rutherther>heh, I was trying that out in dms and hoped it will reply in DMs, but it never did. Here it is.
<tachymelia>heyo! if you have two services of the same service-type, and try to extend one, what happens?
<xFFFC0000>Rutherther: fresh clone of guix? I am doing that inside environment. cleaning that environment is not enough?
<Rutherther>I meant fresh clone of monero
<Rutherther>xFFFC0000 I am asking for this just because I would like a reproducer. If I don't know how you got it, I am out of ideas. I personally don't get that when I try to build it myself
<Rutherther>...but maybe I don't get it only because you do something else in one of the steps
<xFFFC0000>Rutherther: same thing. I cleaned my PATH variable in case that was causing issue. Same problem so far.
<Rutherther>can you share the commands you use?
<xFFFC0000>Rutherther: no problem at all. I totally understand you want to reproduce it. I hope I can help with that
<xFFFC0000>sure. after cloning the repo.
<xFFFC0000>`guix shell --development monero zlib googletest gcc-toolchain`
<xFFFC0000>`cd monero; mkdir build; cd build`
<xFFFC0000>`cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTS=OFF -G "Ninja"`
<xFFFC0000>or `cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTS=OFF`
<xFFFC0000>then use `make` or `ninja` ( based on the generator you have used )
<xFFFC0000>I tried with `guix shell --development monero zlib googletest` and `guix shell --development monero zlib googletest clang-toolchain` too. Samething
<Rutherther>and the repo is https://github.com/monero-project/monero, correct? and you are on master branch?
<xFFFC0000>Repo is same. I am on release branch. Latest release tag. Let me copy paste it. ( going behind desk in few seconds )
<xFFFC0000>But honestly, that doesn’t look like repo error. It seems there is some thing missing.
<xFFFC0000>Take a quick look at this:
<Rutherther>I am not saying it's a repo error, just trying to get the same environment. I thought you were on master and that's why you added zlib. Latest tag doesn't need zlib
<xFFFC0000> https://paste.debian.net/1326816/
<xFFFC0000>This is not repo error. This says something missing related to glibc. Ubuntu provides that files with libc6-dev I believe
<xFFFC0000>Unless I am doing something seriously / fundamentally wrong. That should not happen.
<Rutherther>if you are on foreign distor, have you tried doing this inside of an container? guix shell --container
<xFFFC0000>Will give it a try now.
<Rutherther>I don't understand why you are sending that. guix shell isn't supposed to modify ~/.guix-profile. Look up what is in your GUIX_ENVIRONMENT env var, and search there
<xFFFC0000>Aha. Good point. I forgot guix shell puts in its custom path.
<xFFFC0000>s/in/it in/
<xFFFC0000> https://paste.debian.net/1326824/
<Rutherther>oh, in the log it shows you it uses something from /usr/include. Then I am quite certain the issues stem from it picking up your environment somehow
<xFFFC0000>Rutherther: Exactly. that is what I think too. /usr/include should not be there ( my understanding )
<xFFFC0000>ubuntu (`apprmor`) rejects `guix shell --container`, I believe fedora (selinux) does reject it too.
<Rutherther>oh, I suppose you have user naspaces disabled
<xFFFC0000>it is a default installation.
<xFFFC0000>vanilla
<Rutherther>yeah, probably has disabled by default
<Rutherther>as for the issue. It might just be that cmake is picking up stuff in /usr/include by default somehow. Might be difficult to overcome. Though it's strange it doesn't look for the stdint-least.h in /usr/include as well. Guix libc doesn't have stdint-least.h, and it is not include anywhere, so there is not a problem on of guix side.
<xFFFC0000>About "Guix libc doesn't have stdint-least.h" why it is including it then?
<Rutherther>Guix is not including it. What you have in /usr/include is
<Rutherther>if you don't want to have much work around it maybe easiest would be to enable user namespaces and build it in --contaienr
<xFFFC0000>one thing I suspect is. even if I install `readline` with `guix install readline`, it cannot find readline library.
<Rutherther>yes, that is expected. Guix solves this when it builds the derivation with an env var that I already mentioned further back
<Rutherther>so you need to set it yourself
<Rutherther>"(string-append "-DReadline_ROOT_DIR=" #$(this-package-input "readline")))" this is from configure phase. Sorry, not an env var, it's a flag to cmake
<xFFFC0000>Yes, wanted to mention. That readline is present in my shell: `/gnu/store/9j4q2h8sbdpy3zj9b04fzzgqw2gn96gi-profile/include/readline`
<Rutherther>that doesn't matter, still need to set the variable. So set it to $GUIX_ENVIRONMENT
<Rutherther>assuming you added it to your shell itself, not to a separate profile
<xFFFC0000>`-DReadline_ROOT_DIR=$GUIX_ENVIRONMENT` solved the readline issue. why readline is not able to find it from $GUIX_ENVIRONMENT automatically?
<Rutherther>I don't know. But even the one that was packaging monero to guix was not able to solve it other way.
<duncan>hi, let's say I want to edit a service or package upstream. What's the proper way to do it, say I've got a local copy of guix.git from savannah?
<xFFFC0000>I was able to compile it successfully. Rutherther thanks for your help . Few issues needed to fix: (a) that readline flag helped a lot. (b) it needs specific compiler version (c) it needs glibc too. `guix shell --development monero zlib googletest gcc-toolchain@11.3 readline glibc`
<xFFFC0000>one last question. Is there debug version of the packages I can install? I need it that for debugging.
<Rutherther>guix shell -D monero is supposed to give you glibc right away. Also gcc-toolchain contains glibc. I don't think it solved the underlying problem, it just worked around it somehow
<xFFFC0000>I agree.
<Rutherther>as for debugging info, you can use transformation "--with-debug-info". Some packages have also :debug output, but this is not the case for monero
<xFFFC0000>Rutherther: although it compiles. but as you said, the underlying problem has not been solved. If I enable tests (`-DBUILD_TESTS=ON`) and compile, one of the test cases still gives error related to libstdc++. https://paste.debian.net/1326826/
<xFFFC0000>trying with gcc-12.3.0
<xFFFC0000> https://paste.debian.net/1326827/
<civodul>nckx: 👍 for the (gnu system privileges) changes!
<civodul>very cool
<civodul>i noticed that something pulls in libcap when building a childhurd, i’ll take a look tomorrow or so
<mgd>Hello. I'm trying to set up Postgresql. Can anyone have a look at my config file and see why I'm getting an unbound variable exception on "postgresql-10"? https://paste.debian.net/1326832/
<mgd>and just for completeness, I am trying to reconfigure my system with that config file
<jonsger> mgd you need to add `(use-package-modules databases)` as the variable `postgresql-10` is defined there
<llano>Hi folks - hoping for a pointer.  Trying to build a package and i'm getting early errors from Cmake about OpenGL not being available, but I have mesa in the inputs.  Any ideas what I might be missing?
<mgd>jonsger do I need `databases` to be part of the `use-service-modules` declaration?
<jonsger>as well
<jonsger>both
<jonsger>in the service module `postgresql-service-type` and co are defined
<mgd>Thanks, just giving it a try now
<jonsger> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/databases.scm#n44
<mgd>I also noticed there isn't a package for pgadmin?
<jonsger> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/databases.scm#n1395
<llano>How would I force the cmake-build-system to use the full version of cmake rather than cmake-minimal, which seems to be the default?
<nckx>llano: I see that there's a #:cmake keyword that presumably does the obvious if you specify ‘#:cmake cmake’. I didn't test it though.
<nckx>civodul: Well, it had been a few days since the last review, so I decided to be bold -__- About libcap, though, hmm, I thought that was all conditional. I'll also look around to see what I missed.
<nckx>Bets on ‘something bloody obvious’ will not be accepted.
<llano>Thanks, let me try that. Still very new to guix.
<nckx>Actually it seems like specifying ‘#:cmake cmake ;need some full-cmake feature’ is its only use case in upstream Guix, so odds are good that it does exactly what you want.
<nckx>s/full/full-or-more-recent/
<nikolar>nckx: done with the party :P
<olndrxyz>Hello! Does hardware acceleration work for you on Icecat? When I start Icecat from the terminal, this message is displayed: "Crash Annotation GraphicsCriticalError [0] [GFX-]: vaapitest: ERROR
<olndrxyz>(t=0.631902) [1][GFX1-]: vaapitest: VA-API test failed: libva-drm.so.2". This library is present in the Guix Store. The libva-utils and the intel-vaapi-driver are installed. LIBVA_DRIVER_NAME=i965 is set.
<nckx>nikolar: Regrettably, we are old, and have jobs.
<llano>nckx: that looks to have successfully swapped which version of cmake is used, as the build log shows cmake-3.25 rather than cmake-minimal-3.24; but unfortunately didn't fix my underlying error