IRC channel logs

2025-11-29.log

back to list of logs

<PotentialUser-28>I sorta upgraded Jikes (the ancient java compiler in c++) to java 1.7 level. I believe you use jikes for openjdk bootstrap, so, could someone of you be interested?
<flurando>I could not use math.h on Guix now, nor could I dynamic-link "libm" in Guile
<sneek>flurando, you have 1 message!
<sneek>flurando, ArneBab_ says: would it be OK for you if I posted your tutorial to Hyphanet so it can live independent of a hoster?
<flurando>ArneBab_: Ok, but note that the writeup is too messy to be categorized as a tutorial. I guess maybe you have to edit it before posting or wait for me to write a cleanly organized version some day. Some further changes include using --rsync="sudo rsync" --chown=... to make ownership right, and a cleaned up source code repo at https://codeberg.org/rw-flurando/GuixCloudInit , which is the current final
<flurando>version. However, I don't have effort to rewrite a tutorial several months ahead.
<flurando>Does anyone know why libm.so in glibc here not usable, saying invalid ELF header?
<flurando>I am on a school work project requiring the use of erfc function, which is not available in Guile. When I try to wrap it, dynamic-link failed, then I use c code to test, include <math.h> does not work at all...
<flurando>If this is a bug instead of my fault, I might have no choice but use python instead, since on a tight schedule:(
<flurando>well, c works by adding -lm to gcc. But somehow Guile still fails
<flurando>strange, it is trying to find libm in glibc, while guix locate libm.so only gives me gcc-toolchain and clang-toolchain found
<flurando>No use, it says invalid ELF header even when trying the gcc and clang's libm.so
<flurando>I could not run a single example in Guile document about ffi successfully. Even libguile.h is not found after guix shell -D guile -D gcc-toolchain gcc-toolchain. I would like to check guile repo to see how they setup to use libguile.h
<flurando>Amusingly, none of Guile examples, I mean those about c or development env, works on my machine. I decide to just use python as a workaround and check the cause of this later.
<vntsuyo>how do I always keep the build tree when building a package?
<vntsuyo>i can only see --keep-failed
<Rutherther>like if it doesn't fail? That's not possible, it needs to fail
<vntsuyo>why?
<Rutherther>because no one deemed necessary implementing such feature to the daemon
<vntsuyo>i have a package that was building and installing binaries normally
<vntsuyo>but then after some upstream Guix update, it still builds fine but didn't install any binaries
<vntsuyo>what should i do
<Rutherther>probably add "#:cargo-install-paths '(".")" to arguments of the package
<Rutherther> https://codeberg.org/guix/guix/issues/4321
<vntsuyo>so its a known issue
<vntsuyo>thanks
<flurando>Found a not so performative implementation on web, as a wrokaround in the end, glad not needing to touch python!
<gabber>kestrelwx: how newer?
<gabber>luca: bummer. current working hypothesis is: turning the monitors off (swayidle) crashes sway
<luca>oof. that sounds literally like my issue
<kestrelwx>gabber: I last updated them 3 weeks ago, seems.
<kestrelwx>Could you see if you have any X11 applications with `xlsclients`? I remember there was a thing where XWayland crashing would crash the compositor, and I used to hit that.
<gabber>kestrelwx: ah. so we're probably on the same version (:
<kestrelwx>Yeah, just their master commits from the time.
<gabber>xlsclients returns with code 0 and no output—i don't know what that means
<kestrelwx>Oh, doesn't seem to work for me either. :P
<gabber>maybe we hit this one: https://github.com/swaywm/sway/issues/8829
<kestrelwx>gabber: I guess there is the exact issue. https://github.com/swaywm/sway/issues/8926
<kestrelwx>Are you on 0.19.2 as well?
<kestrelwx>For wlroots.
<gabber>i'm on 0.19.1
<gabber>kestrelwx: are you ahead of guix/master?
<kestrelwx>Yes, I'm on 3 week old HEADs for wlroots and Sway.
<kestrelwx>I guess we could bump wlroots to 0.19.2 already, since they did do a point release.
<Rutherther>#4528 updates wlroots to 0.19.2
<gabber>Rutherther: thanks for the heads-up!
<trev>did anyone on gnome notice that the monitor won't go to sleep/idle anymore? didn't change anything except guix pull'd and reconfigured system
<gabber>Rutherther: you're listed as reviewer but i don't see your approval on the PR?
<Rutherther>I didn't have a time for review
<gabber>Rutherther: all good (:
<gabber>i guess i'll just merge that, no?
<flurando>I have never been able to sleep/idle, the only action that don't require a hard shutdown(poweroff) then boot later is lock screen.
<flurando>so I just turn the action off in elogin service, and tell myself not to touch suspend button in gnome
<Deltafire>flurando: have you tried recently? it never used to work on my desktop, but now it does (suspend mode)
<Deltafire>monitors have always powered off
<trev>flurando: suspend works for me
<trev>on a thinkpad
<alanz>I just did a guix pull (having done one earlier today). It says " commits 9edb3f6 to 2efb4f3 (1,283 new commits)". Is that an expected number of commits, in a few hours?
<identity>alanz: branch merge
<alanz>thanks
<Rutherther>alanz: while under some circumstances this could happen, it's not the case here. 9edb is the channel introduction commit. Your guix pull has made a completely new checkout. I expect you used 1.4.0 and did guix pull from savannah. Then after you pulled the default guix channel url has changed so a new checkout had to be made (the checkouts in cache are separated by urls)
<untrusem>hello what would be the reason to have a package uses d
<untrusem>ahh half message
<untrusem>anyway
<alanz>FWIW, it said "Updating channel 'guix' from Git repository at 'https://codeberg.org/guix/guix.git'". Anyway, my question is just for interest
<Rutherther>that's not a default url so you must've changed it through channels.scm or --url
<alanz>and running guix version guix (GNU Guix) 2efb4f3bd48abac4a44b3f434bc8b269032d7619
<alanz>yes, I did, but some time ago
<untrusem>btw what would be a reason a package uses different version of a input from the store
<alanz>what should the default url be?
<Rutherther>the default url is https://git.guix.gnu.org/guix.git
<alanz>thanks
<untrusem> https://paste.debian.net/1411186/
<untrusem>I am trying to find why the `dotool` package is using different version for libxkbcommon?
<Rutherther>so where's it's definition? And did you by chance pin it when installing?
<untrusem>just a sec
<untrusem> https://paste.debian.net/hidden/b8d25dcc/
<Rutherther>that's definitely not enough info... is that a part of a module of a channel you have added or what? really it's not easy to say why a package isn't updating or if it is updating, but the libxkbcommon version is different. And first and foremost, this isn't the package you have installed, because it doesn't propagate anything
<untrusem>ohh I changed its defination, removed the propagated bit, I am currently building it
<untrusem>ok it build, yes my internet connection sucks
<untrusem>I just listed it as a input not a propagated input, good enough for me now
<Rutherther>if this package is upgrading, then it's probably waydroid that's pinned
<untrusem>I am not upgrading
<untrusem>I am installing it, its not in guix proper
<Rutherther>then that's the issue. You have an old waydroid and newer guix
<untrusem>but waydroid is also not in the guix proper either
<Rutherther>that is completely unrelated, libxkbcommon versions are the ones differing and it's because waydroid has been built with older guix version than you have now
<untrusem>ohh
<untrusem>but I looked into the warning both package requires libxkbcommon@1.11.0
<untrusem>ok I tried to upgrade waydroid, some dependecies and packages have changed
<untrusem>maybe its gtk
<Rutherther>'both packages requires libxkbcommon@1.11.0' that is again not important. What's important is that the packages differ, you see that with the whole path. And the path changed probably because a dependency of libxkbcommon changed
<untrusem>hmm, thanks for the info
<untrusem>btw would these three package go in the same file if I try to upstream it?
<untrusem>dotool would go into xdisorg
<untrusem>would the depencies would also go in the same file or somewhere else, i packaged a go package for the first time
<Deltafire>i have emacs installed via guix-home. If I install an emacs package using "guix install" then emacs doesn't see it, because it's not in the load path. Is this something I have to configure manually?
<efraim>I would assume you'd have to install it using guix-home also
<identity>Deltafire: you have to have both in the same profile
<Deltafire>oh ok, that's what i've been doing but sometimes it's a bit time consuming adding a package to home just to try out quickly
<identity>you can do ‹guix shell emacs emacs-whatever -- emacs› instead
<kestrelwx>Is it fine I bump https://codeberg.org/guix/guix/pulls/4350 here? Or that's too soon...
<ekaitz>kestrelwx: is always fine to bump, but it's also ok to ignore the bump :)
<hanker>Is it possible to expand macros inside of gexps at compile-time'
<hanker>Is it possible to expand macros inside of gexps at compile-time?
<ieure>hanker, Pretty sure that's how they work. What are you trying to do?
<hanker>My macro looks like
<hanker>```
<hanker>(define-syntax-rule (thing arg ...)
<hanker> (system* #$(file-append package "/bin/thing") arg ...))
<hanker>```
<hanker>so when I place `(thing` in a gexp it's expanded to a `system*` call
<hanker>and then the gexp looks like #~(being (thing "something") (thing "something" "else"))
<ieure>hanker, I believe you need to wrap your gexp with `with-imported-modules' to include the module where the macro is defined; and also (use-modules ...) within the gexp to load it. Or you can define the macro inside the gexp. Or you can rewrite it as a function, as it doesn't appear to be doing anything actually requiring a macro.
<csantosb>sneek, later tell civodul, I just pushed emacs-xelb 0.22, in case you're still randomly crashing, hope that helps
<sneek>Will do.
<acidbong>evening (hopefully i don't disconnect this time). how does Guix deduplicate files: just by hardlinking them or does it use reflinks where supported, like Btrfs and Xfs?
<acidbong>i know Nix only does the former
<ieure>acidbong, I believe it's hard linking only.
<cpli>nckx re: "if the recutils package installs a $output/lib/bash *and* is installed into the same profile as bash" it successfully installs: /gnu/store/2lds9jkh5r8k9bx4779klvf8cms29djy-profile/lib/bash/readrec, but even though recutils a native-input guix shell doesn't make it available
<noe>Hey guix
<Rutherther>Hey noe :)
<noe>Does anyone remember where is the page that had the graphs of opened / closed issues from debbugs
<noe>Rutherther, :)
<noe>Found it at https://debbugs.gnu.org/rrd/guix-patches.html, I guess it was removed from the main page since the Codeberg move
<Rutherther>noe: this? https://debbugs.gnu.org/rrd/guix.html
<noe>oh perfect!
<noe>That makes for issues and patch series
<bdunahu>For developing guix with geiser+emacs, I find that allowing the .dir-locals.el file to run, calling M-x geiser, and evaluating the define-module expression at the top of the file takes 10+ minutes to compile without feedback on what guile is doing. Is this the expected workflow?
<bdunahu>it seems to specifically have issues compiling gnu/packages/rust-crates when I try this
<PotentialUser-28>Ergh, IRC is dated. Essentially, I could someone give me a hint how may I contact the JDK maintainers? I've tried to revitalize the ancient Jikes compiler which, I believe, is still used by Guix to bootstrap OpenJDK and I wonder if that might be of interest to anyone. Here is the thing: https://github.com/7mind/jopa