IRC channel logs

2024-10-02.log

back to list of logs

<meaty>I think I've found an issue with Guix's Qt package topology
<meaty>Qtwayland 5 and 6 are both available but cannot be installed simultaneously
<meaty>this forces a choice between getting wayland support for qt5 apps or qt6 apps
<jaft_r>I've had some trouble getting some QT app.s to recognize or use QtWayland when I just install it as a package so I've been extending QT app.s I use to add QtWayland as an input but the incompatibility between them would be another reason to do so.
<meaty>I think the best solution would be to split the packages into e.g. qt5wayland and qt6wayland, same with other packages
<meaty>cos qt6 isn't backwards compatible iirc
<meaty>unless it is, and a lot of the qt apps incorrectly pin qt5
<amano>Anybody working on proper zfs support?
<podiki>jaft_r meaty I don't think you should be installing qtwayland as a user, just depends what qt version a package is using (and built with)
<podiki>(as a wayland user i haven't installed qtwayland and use a few qt apps)
<podiki>any issues would be on the packaging side i think
<meaty>Are your Qt apps running wayland-native then? or via xwayland (blurry, glitchy dropdown menus)
<meaty>@podiki
<meaty>personally I need it installe or cantata and quassel don't run native
<podiki>i haven't tried those but the qt ones i've used seem crisp and scaled
<podiki>could be those programs or something with our packaging
<podiki>neither of those show qtwayland as an input so they may not support wayland? or need an update?
<podiki>well cantata is no longer in development (since 2022) so...
<podiki>quassel too
<podiki>(unless the moved/were forked)
<podiki>so i would guess that is why
<podiki>ACTION away, night guix!
<jaft_r>podiki: in my case, I run into a similar issue with Qutebrowser; I tried submitted a patch to add a "qutebrowser/wayland" package (at https://issues.guix.gnu.org/63558) but I was given the recommendation to install QtWayland. Perhaps, like was recommended with Qutebrowser, Cantata and Quassel use it as a plugin, but it was my experience that Qutebrowser wasn't automatically detecting it.
<apteryx>is setting GUIX_LD_WRAPPER_DEBUG=1 as a make flag e.g. while building 'hello' suppposed to print the debug output of ld-wrapper?
<apteryx>it's not
<apteryx>as in: https://paste.debian.net/1331036/
<efraim>I might have a nearly-working qtwayland5/qtwayland6 combo package that can work as a generic qtwayland profile package, remind me in a few days to check for it
<futurile>efraim: has guix import changed for crates? It's doing something odd with the package inputs - #:cargo-inputs ,(list ("rust-blah" ...
<futurile>efraim: I'm correcting it to how you have everything else so (arguments `(#:cargo-inputs ( ("rust-blah" ..
<apteryx>efraim: sounds good
<civodul>Hello Guix!
<civodul>is ci.guix down?
<civodul>ACTION checks the log
<civodul>apteryx: GUIX_LD_WRAPPER_DEBUG should be set as an environment variable, not as a make variable
<civodul>futurile: i believe the ‘guix import crate’ issue was fixed: https://issues.guix.gnu.org/72939
<civodul>commit 89413a11625dd6c548827dd0078ebe0191086597
<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=89413a11625dd6c548827dd0078ebe0191086597
<galois`>When I include iostream in emacs, my LSP complains: /gnu/store/lq9y7sd4mvffs4hqp3hkr9fnd384pnkj-gcc-14.2.0/include/c++/iostream. I'm not sure what the cause is as other includes seem to work and also compilation works fine.
<civodul>berlin (ci.guix) is back!
<jlicht>hey guix!
<jlicht>I'm sitting on a build of Node.js 20 that seems to work, but next week Node.js 22 will be made the LTS version; should I send one patch-series bumping things twice (so guix time-machine users can use 20), or just skip 20 it altogether?
<jlicht>(Guix has an older revision of Node.js 18 packaged right now)
<AwesomeAdam54321>jlicht: I think you should update it twice
<nckx>Since you're offering, yeah…
<futurile>civodul: ah, I think it's because efraim's rust-team branch hasn't been rebased since that commit, as guix import works correctly when on master
<futurile>civodul: thanks for the info
<cow_2001>anyone tried using the gnulib package's gitlog-to-changelog? i don't see it as an executable when running `guix shell gnulib`
<nckx>It's installed as src/gnulib/build-aux/gitlog-to-changelog but it's not wrapped nor is the shebang patched, so you can rest assured that it has not been tested yet.
<nckx>guix shell perl bash -- $(guix build gnulib)/src/gnulib/build-aux/gitlog-to-changelog # works fine; whether the output is up to your snuff is up to you.
<nckx>The ‘bash’ argument is unnecessary trash.
<apteryx>hotspot is a really neat UI for the linux 'perf' profiler
<apteryx>civodul: make environment variables double up as environment variables for make launched processes
<apteryx>perhaps just if they are marked with 'export' though... so I think you have a point
<apteryx>at any rate I've tried both and couldn't see the output
<apteryx>OK, 'export' is for sub-make to see these same variables
<apteryx>civodul: I meant to write, IIRC: Make variables double up as environment variables in the environment of the recipes it runs
<apteryx>see: info "(make) Environment"
<apteryx>civodul: also, and more importantly, hello!
<apteryx>:-)
<apteryx>OK, retrying with setenv, it seems to work on 'hello'
<apteryx>it seems when a library links to another shared library part of the package, the runpath directive doesn't get added
<wehlutyk>Hello Guix!
<wehlutyk>I have a guile/guix question
<wehlutyk>trying to play around with guile library (guile-wlroots)
<wehlutyk>which compiles and installs fine on Guix, given its guix.scm file
<wehlutyk>but then how does one access that in a guile shell? ("scheme@(guile-user)>")
<wehlutyk>I tried "(add-to-load-path "/gnu/store/...-guile-wlroots.../lib/guile/3.0/site/ccache/")
<wehlutyk>which still doesn't solve "(use-modules (wlroots))" or "(use-modules (wlroots types))"
<wehlutyk>more broadly maybe, if one installs a guile lib (e.g. "guix install|shell guile-bzip2"), sholdn't that be generally available to guile in the same guix shell?
<wehlutyk>any help or advice or pointer is very welcome!
<apteryx>wehlutyk: there's too paths in guile; the load-path for interpreted guile sources and the compiled-load-path for byte-compiled objects
<apteryx>cccahe contains the byte compiled objects, IIRC
<apteryx>but it'd be easier to simply use the project guix.scm file to setup a shell, e.g. 'guix shell -f guix.scm guile -- guile'
<apteryx>or, if it's packaged in guix, 'guix shell guile guile-wlroots -- guile'
<apteryx>maybe add guile-readline for extra comfort :-)
<wehlutyk->apteryx: oho, thanks a lot
<wehlutyk>that solves it all, cool!
<apteryx>glad to hear it!
<wehlutyk->apteryx: I see, they key being to add guile in the "guix shell ...". I wasn't doing that, and while having guile, it didn't have its GUILE_LOAD_* env updated
<apteryx>the way search paths currently work in Guix, it's per-profile, so you always need to add the 'consumer' package, the one that comes with search paths definitions, to the profile
<apteryx>e.g. same with Python, you'd want the interpreter to pull its search paths, not just the libraries in a profile
<wehlutyk->right, I see that making sense
<wehlutyk->is that mentioned in the guix manual? I'll try and add that one day otherwise
<wehlutyk->or just in the cookbook
<apteryx>it's known as one of the oldest bug in guix
<apteryx>but since it's been like this forever, perhaps it's becoming a feature ;-)
<apteryx>the bug is that ideally (?) the search paths between multiple profiles such as the system and user profiles should compose
<apteryx>see e.g. bug #20255
<peanuts>"'search-paths' should respect both user and system profile." https://issues.guix.gnu.org/20255
<wehlutyk->oh wow
<wehlutyk->2015!
<apteryx>another old one related: bug#22138
<peanuts>"Search paths of dependencies are not honored" https://issues.guix.gnu.org/22138
<wehlutyk->yep
<wehlutyk>apteryx: rereading about the ideal you mentioned -- but then wouldn't that open conflicts when combining search paths across profiles that can be older or newer one from the other?
<wehlutyk>apteryx: and thanks for all the answers :)
<wehlutyk>my last question maybe, is getting that "guix shell -f guix.scm guile" into emacs (in my case doom) with scheme
<wehlutyk>the only way I found was loading the profile using emacs-guix, or maybe launching emacs from a shell with the right profile
<Rutherther>wehlutyk I use direnv for that, it has use guix for getting search paths out of guix shell, and there is envrc package for Emacs
<weary-traveler>hm does gcc-toolchain not provide cc?
<Rutherther>it doesn't have cc command, only gcc
<weary-traveler>Rutherther: how would i figure out given a binary/command of interest which package would provide it?
<weary-traveler>and in this case, do you happen to know the answer?
<futurile>weary-traveler: there is no cc, if you're working on a package you'll find packages that set the environment for CC=gcc (or something like that - do a grep)
<Rutherther>weary-traveler: unfortunately there is currently no good way. You can use guix locate, but it will tell you only the ones you already have in store
<weary-traveler>ack. thanks futurile Rutherther
<futurile>I can't decide if updating crates is a deathly boring treadmill, or a relaxing meditation on the nature of life
<wehlutyk>Ahoy again!
<wehlutyk>I'm trying to try out this guile-wlroots <https://github.com/Z572/guile-wlroots>
<wehlutyk>trying the examples they have, but on my side it fails with an error I can't understand
<wehlutyk> https://paste.debian.net/1331126/
<wehlutyk>would there be anybody comfy in guile having hints about this? (I'm asking the same over at #guile)
<futurile>sorry, I don't know anyything about it and still on X
<eikcaz>Is there an easy way to pass locally defined procedures into a gexp? When I try #$my-func, I get "invalid gexp input". I can't use (with-imported-modules ...) because my procedure is locally defined
<atweedie>does anyone have any experience with docker on guix?
<atweedie>I just tried adding it with (service docker-service-type)
<atweedie>but reconfigure fails with "guix system: error: service 'dockerd' requires 'containerd', which is not provided by any service"
<wehlutyk>atweedie: you can add (service containerd-service-type)
<wehlutyk>I remember a notification about containerd being separated from docker a few weeks ago (or months?)
<atweedie>thanks, that worked! at least reconfigure finished successfully now.
<atweedie>wehlutyk: was that on the mailing list?
<wehlutyk>I remember seeing it as the news during a guix system reconfigure
<elpogo>In this blog https://guix.gnu.org/en/blog/2023/dissecting-guix-part-2-the-store-monad/ the is the blurb that explains mlet* equivalence to >>= correct (search for "equivalent..." with the dots) ? Shouldn't the lambdas be nested as opposed to in sequence?
<elpogo>"(lambda (str2)" should be the second expression in the body of "(lambda (str1)", as opposed to outside it
<elpogo>(based on my understanding, which could be very wrong)
<futurile>elpogo: the manual has a mention of it that might help you it's under "The Store Monad" - I just searched for >>=
<KM4MBG>does anyone have a handy link to Ricardo's blog/presentation with the whale oil graphic/analogy?
<civodul>KM4MBG: you mean the smoothie?
<civodul>(re containers)
<civodul>many talks, including Ricardo’s, are at https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/talks
<civodul>perhaps what you’re looking for: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/talks/cern-2018
<KM4MBG>civodul: yeah, thanks!
<elpogo>thanks futurile. I understand better now.
<old>how can I remove GCC completely from a package? I'm doing the following: (package-with-c-toolchain my-package `(("clang-toolchain") ,clang-toolchain-18)))
<old>then: `guix shell -D -f manifest.scm'
<old>I do get clang in my environment, but gcc is still there
<old>(gnu-build-system)