IRC channel logs
2026-01-18.log
back to list of logs
<Noisytoot>guix pull: error: Git error: unexpected http status code: 502 <ekaitz>there's some service degradation <oliverD>when i installed python-pygobject package and use it, it errors with Namespace Gtk unavailable. <oliverD>My desktop still takes 15+ minutes before i can click on anything. Also when I start Icedove it prints `undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE` <mthl>Hello, guix refresh reported me that java-hamcrest-core package could be updated from 1.3 → 3.0, however this package is a dependency of java-junit which latest version requires an annotation class ‘org.hamcrest.Factory’ provided by java-hamcrest-core that has been removed since version 2.1. Given that java-junit is in maintenance mode and will never update its dependency to a breaking version it means that we need to ke <mthl>java-hamcrest-core@1.3. To avoid other Guix contributors to loose time in trying to update hamcrest, I wonder if it is possible to annotate a package definition to tell the refresher to ignore newer versions ? <identity>mthl: just create a separate package variant ‘java-hamcrest-core-for-junit‘ and update ‘java-hamcrest-core’ to 3.0 <mthl>identity: Indeed, seems logic! thanks for your help <stfnbms>I have a Guix System installation, with my user configuration and packages in ~/.guix-profile. <stfnbms>Now I would like to dip my feet into Guix Home, but to start with *only* with one home-shepherd-service-type for timed tasks, *not* any package management. <stfnbms>Will it be safe to do “guix home reconfigure” on a configuration file with just this service specified, and no “packages” section, i.e., will the Guix Home installation leave my existing dotfiles and packages under ~/.guix-profile (as well as the system-wide packages) untouched, accessible and working as before. <identity>just (home-environment (services %base-home-services)) should work <stfnbms>Okay, that seems to have worked. Thank you. <stfnbms>And what if later I do start adding packages to my Guix Home configuration? Will that disable my packages in ~/.guix-profile, or can I use both mechanisms for user packages in parallel? <identity>stfnbms: you can use both at the same time, though i would recommend only using one at a time to avoid getting confused about what package comes from where <stfnbms>Okay, great. Part of the reason I am asking is that I like using emacs-guix, and that manages only ~/.guix-profile, I believe, not Guix Home packages. <identity>you do not need emacs-guix to manage packages with guix home <stfnbms>I know, but I like the emacs-guix interface. <identity>you can still use the interface for things not related to *installing* packages <stfnbms>True. I can look up and choose packages, and then use Guix Home to install them. Anyway, I will start out using Guix Home just for services, then dotfiles. <efraim>I tried to use vagrant's tarball to build a .deb of guix but debian has switched to using gcc-15 so the tarball doesn't have the changes to the daemon we needed to make it work with newer GCC versions <Rutherther>efraim: is it that we do not have these changes at all in Guix repo or only not in the tarball you have? <efraim>Rutherther: it's not in the tarball <efraim>Rutherther: it's not in the tarball that I have <efraim>vagrant made a fake release so he could bump guix in debian before it got pulled from the archive <efraim>the debian version is 1.4.0+154928+f1810-1 <Rutherther>that's Feb 25, while the change dariqq sent is in May 25 <Rutherther>efraim: if you could test a tarball built from version-1.5.0 branch through make dist, it would be nice. I have merged some changes, so now it should be fine. The rc1 was missing some files that made it not buildable <efraim>Rutherther: I can try when I get home, I'm currently trying on powerpc so I'm expecting it to be bad <luca>Hi, now that easytag has been removed does anyone have any recommendations music metadata editing software? <Wurt>Hello! Who manages the wlroots/Wayland packages or services for Guix? <identity>Wurt: it does not look like there is a team in place. you could just ask your question and see if somebody has an answer <Wurt>identity, I did some PR related with Wayland, and I want to set the reviewers field. <Rutherther>feel free to put me, but don't expect a review from me in less than a week now <identity>somebody should come around to review it either way <civodul>you have to scroll down an entire page of text because you see a mention of the installation script <civodul>(now there are # on each line so it’s not even copy/pastable) <civodul>er s/because you see/before you see/ <civodul>it also uses @samp and @command inconsistently <Rutherther>civodul: I suppose if we just changed it now, the translations would be missing, right? <civodul>and there’s a whole paragraph about Parabola, which probably few people care about <Rutherther>seems that it's translated almost fully only for German and Portugese. Maybe this is something to look out for, to ensure a few pages like the binary installation have a good structure and are translated as much as possible, ie. to ask the translators to prioritize these <civodul>comes from 227e0469dbfec7e47b57d824dcf45a04ac4026c9 <civodul>i’m a bit grumpy because the previous wording had been carefully crafted over the years; it probably needed to be improved but here what i see is not immediately identifiable as an improvement :-) <Rutherther>civodul: I agree it's worse now. The previous one I could just skim and see the method for installation right away, it's highlighted. In the new one I am lost and I have to read everything <civodul>Rutherther: if you want i can try to propose a minimal diff that hopefully preserves translations; WDYT? <Rutherther>civodul: just noticed that the manual built with my changes from the update to 1.5.0 does not contain proper versioned urls on the index page, "This manual is also available in ...", any idea where these urls are defined? <Rutherther>note that they're wrong for the devel manual, pointing to the versioned manual <ekaitz>csantosb: what do you mean by "in red"? <ekaitz>the meta-package is just keeping things together with a kicad-toolchain <identity>the «in red» is about not being on the latest point release for kicad <civodul>Rutherther: good point, that’s in htmlxref.cnf <Rutherther>hmm, the htmlxref doesn't seem to have the latest version available and I think it's better to avoid putting it to more places <civodul>ACTION unhappy with this “Binary Installation” mess <Rutherther>civodul: thanks, I am hoping this will allow the iso/qcow2 to build <PotentialUser-42>does anyone know if there's really no package for gtk dbus appmenu exporting or am i just unable to find it? <acidbong>there's one thing i can't find in either the manual or the code: how does `guix search` invoke `less`? if it's not in the Guix code, could it come from Guile internals? <acidbong>and how can I sync $LESS value with it (from what i know, Git lets LESS through, and Systemd uses $SYSTEMD_LESS)? <m4xxed>Good evening people, did anybody run into the issue of `scanimage` (from the `sane` package) stating that certain supports for formats like png, pdf, jpeg etc are not compiled in? I have `sane` and `sane-backends` installed in my `guix home` and am scratching my head about this :) <m4xxed>Nevermind, one has to make sure not to install the plain `sane` package into their `guix home`. Apparently this delivers a `scanimage` version without those compiled. Just using `sane-backends` did the trick. (Leaving this here for people who might use the logs to find for answers) :) <identity>acidbong: i think you are looking for PAGER <acidbong>identity: that sets the pager executable, but I'm looking for how to pass `less` flags <identity>acidbong: look for ‘less’ in guix/ui.scm <dariqq>Rutherther: I dont quite understand the point of fixing qt6 when all of gstreamer, gtk4 and webkitgtk are also completely broken <Rutherther>dariqq: in the same way, or is it different failures? <dariqq>gstreamer and gtk4 can be saved by skipping tests, webkitgtk g++ fails in build with "virtual memory exhausted: Cannot allocate memory" (and that is not easily solveable) <Rutherther>oof so during the build there is too much memory used? <Rutherther>and I expect this is even with --cores=1, right? <Rutherther>in that case this convinces me we should stay on sddm with %desktop-services for i686, because it seems it will not be easy to get gdm to build any time soon. While sddm should be fairly trivial by removing these phases in qt packages <Rutherther>let's make our own compiler for webkitgtk I guess:) <dariqq>you can wrok around it by letting _Complex expand to nothing but lets not go that round <Rutherther>oh so you meant like the case where you try to add the gcc-15 along with gcc-14, yeah. There is the build-system-with-c-toolchain, have you tried that instead? <Rutherther>I am afraid that with what you're doing you aren't actually replacing it all because the gcc is going to be added by the build system, not in inputs. But I really don't have much time to check now, so I might be wrong here <dariqq>i think i tried that and it did not work but I might be wrong <dariqq>But %desktop-services also dont build because vte fails tests and depends on gtk4. Then there is also udisks which fails of the test framework for iniparser cant find 64bit integer types <dariqq>So again I dont quite understand what your goal is <Rutherther>I've hidden the desktop page in the installer for i686 because of it <Rutherther>dariqq: really just to get more packages build. But don't worry about it, since you've explained the situation is quite bad, let's just keep it like that and solve it later <dariqq>Rutherther: If it were only a few test failures and the qt oom i'd say it would be doable but e.g xfce and mate depend on webkitgtk (i think via gnome-online-accounts) and that one is just broken <look>dariqq Rutherther: about iniparser on i686, I was working on a fix about 3 days ago, but didn't have time this weekend to open a PR <look>it should at least be an immediate fix for the iniparser tests, however not really the best solution, as it would be better to yank the unity-test source and modify iniparser's cmakelists to use this yanked source with the compiler options <dariqq>look: When i defined UNITY_SUPPORT_64 in iniparser via CMAKE_C_FLAGS it segfaulted trying to print the result. I gave up and in my pr i just skip the tests in iniparser <look>thats because unity-tests itself should be compiled with #define UNITY_SUPPORT_64 <dariqq>then I think it is bad design that unity-test has both a meson and cmake but only exposes this option by manually editing a header. Or do they expect everyone to just vendor that for every package? <look>since we don't use unity-tests source directly, we cannot compile it with UNITY_INCLUDE_CONFIG_H, which is what does the magic of enabling unity-test to read the iniparser's header file that defines UNITY_SUPPORT_64 <look>I think thats exactly how they expect people to use unity-tests tho, haha <look>took me a while to figure this all out, but the easiest solution imo is simply patching our unity-tests with UNITY_SUPPORT_64 by default, and patching every package that depends on it to pkg-config our unity-test package <dariqq>not a fan, but your change is probably better as it does not require patching every package using unity-test. Ill update my lazy pr with your change instead <yelninei>iirc it was PATH_MAX and the updates only improve windows support or something like that. <yelninei>I was only searching in guix and not guix-patches. it is at #76085 <janneke>ACTION can write that comment again? <yelninei>ACTION is annoyed by the design of PATH_MAX <optimal>i'm trying to make my first contribution to Guix and i'm trying to push my new commits to a fork, but guix git authenticate fails when i try to push the commits to my forked branch. the commits are signed with GPG and have signed off by headers. am i doing something wrong?