IRC channel logs
2025-06-11.log
back to list of logs
<jlicht>apteryx: do you happen to have a log for the failed node.js test? <bdju>It seems the Nyxt package is very broken. I even moved/renamed my config and whole ~/.local/share/nyxt dir but I just get a blank white page and none of the common emacs/vim keybinds seem to work, can't open any cli or anything, can't see a help page, and there's an error about a GTK thread shown at the bottom. <bdju>I hadn't used it in a while so I'm not sure at what point it may have broken. I just felt like checking up on it. <bdju>Hopefully if I check back in 6 months it won't still be broken. <ieure>bdju, Want to open an issue? <bdju>If it doesn't take too long, I guess I can. I haven't done it since the move to Codeberg. <moshh>stupid question - i've been playing around with guix in a VM, decided to try `guix home` to install packages. set it up to install emacs but after running `guix home reconfigure` and it downloading emacs I now have `~bash: emacs: command not found` do I need to do a `guix install` first - I thought `guix home` replaced that process? <meaty>moshh: `guix install` wouldn't do anything <meaty>are you sure emacs is in your home config file? <moshh>(packages (list emacs)) & (gnu packages emacs) <meaty>moshh: yes try logging out then in again first <moshh>logging out fixed it - do I need to do that every time I run `guix home reconfigure`? <moshh>ahh right. thanks meaty and identity. I'll continue exploring! <meaty>moshh: if it helps, I like to imagine the guix environment as having three layers: system, home, and package, and additionally any `guix shell` environments. `guix install/remove/update` are just aliases for `guix package -i/r/u` <moshh>another stupid question sorry - why are individual package modules needed (gnu packages emacs) (gnu packages wm) when the individual packages are being defined later in the home-configuration.scm file? <meaty>They aren't defined, but refrenced from those modules <moshh>ahhh that makes sense. thanks <meaty>if you like, you can use specifications->packages, which will do the work of importing modules for you <moshh>right. I will remember that thanks meaty <ghodawal`>Hello! do we have something similar to build-essential in Guix? <ghodawal`>I want to compile GDB so I need the tools... <meaty>ghodawal`: `guix shell --development gdb` <meaty>should drop you in a shell environment with everything GDB uses to compile in guix <meaty>`guix edit gdb` will show you the package def, where the *-inputs fields will give you an overview of what is used <meaty>does anyone know which package(s) have desktop-file-validate, pod2man, glib-compile-resources <meaty>well, the last one is in glib:bin <meaty>desktop-file* is in desktop-file-utils <meaty>also, I am having tests failed with the dreaded 'Settings schema 'org.gnome.system.proxy' is not installed'. How do we fix these errors? <meaty>I am used to having it happen once in a while, I install a program and it breaks immediately with a similar error. It's happened several times but sparsely enough that I never made an issue <meaty>but this is the first time I've seen it happen in build-land <meaty>idk how gnome works, is it expecting that I test in a gnome session? <noe>meaty, desktop-file-validate in desktop-file-utils <meaty>If I'm packaging a plasma app, should I push it to kde-team? It seems kinda abandoned <cbaines>meaty, I think the relevant bit might be: " Any changes that can be made on the master branch, should be made on the master branch. If a commit can be split to apply part of the changes on master, this is good to do." <postroutine>Hello. I registered to the help-guix mailing list, I can receive other messages but can't send thems. Is it something special to do ? <efraim>postroutine: the first mesages are sometimes held by the system, I'll release them <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, csantosb says: could you please have a look at #140 in science ? the source tarball being gone, all dependencies on gnat break; guix linting apparently doesn't compute the swh backup of tarballs, I'm afraid <civodul>andreas-e: i’m catching up on core-packages-team! <civodul>ungrafting things as a low-hanging fruit to get started <andreas-e>civodul: Excellent! There is a message by yelninei about important breaking packages (that block grub, for instance). They have already repaired two of them. I had a quick look as well, but they are these kinds of test failures that are difficult to repair without knowing the software... <ekaitz>noe: should I send the email calling for more guile contributors? <mawumag>has anyone any experience developing python packages with guix? I basically would like to reproduce the behavior of editable installs (`pip install -e .`). I see that a `python-editables` package exists, but not sure how to use it <noe>ekaitz, in my opinion. A guile maintainer should do that, it is up to them if they want to set up a friendly space for new contributors or keep the status quo. <noe>You can call for contributors, but if you can’t accompany them then I’m afraid it will only lead to frustration <noe>What about a call for guile maintainers to call for contributors? :P <ekaitz>well, i could be empathetic in the email and cover those possibilities through my personal experience <noe>Personnally, I want to contribute but I’m also scared to do it all on my own and then get the patch ignored. I would need to be accompanied a little. <ekaitz>noe: that's what I want to break -> the fear <ekaitz>and also, that I'm there to help <ekaitz>and I want to call for some guix contributors to help each other with guile, acting as friends when things in guile get hard <noe>great idea, but please find a guile maintainer or two to be in the movement! <ekaitz>noe: easy: civodul ^^ how do you feel about this? should we try it? <ekaitz>i'm also trying to become a guile commiter myself but I don't think I would be able to help a lot, i don't have much time to spend there <civodul>ekaitz: egun on! should we try what? <civodul>ekaitz: oh, calling for more Guile contributors? it’s tricky at the moment, as noe rightfully wrote <noe>civodul, what makes it tricky? <civodul>noe: that there are few people (euphemism) spending time on reviewing patches <civodul>i do that occasionally, but all too infrequently <civodul>there’s a couple of committers on #guile who’re willing to help though <ekaitz>civodul: what i'm looking for is to make some people push for becoming guile commiters <ekaitz>or use this opportunity to encourage people to step up <xdej>Is there a way to change this path to something in my $HOME ? <aldum>btw, someone made shepherd work on Void (allegedly) <identity>xdej: why would you want to move that to your $HOME ? <xdej>and this folder is "drwxr-xr-x 11 root root 4096 13 mai 15:53 /var/guix/profiles/per-user" <identity>xdej: does the fix suggested in the bug report not work? <xdej>identity: I got this error with following command: guix install python-gpustat <identity>the daemon should create that directory for you, as mentioned in the issue <xdej>identity: there are folders for 9 users, but not for me. <xdej>identity: the following command prints nine lines in "drwxr-xr-x 2 $user root 4096 $someDate $user": ls -l /var/guix/profiles/per-user <identity>xdej: do you not have root priviliges on the machine? then you probably should ask the sysadmin about this <xdej>identity: ok thanks, will do ! <identity>that directory should normally be created automatically, it is weird that it is not <xdej>identity: I found another way, this works without creating the folder: guix shell python-gpustat <civodul>ekaitz: yup, i understand and agree it’s a worthy goal; it has to be done, really <civodul>i’m not available currently for this, but i’d love to help later <civodul>(i’m trying to avoid being on too many fronts at once :-)) <civodul>in the meantime i recommend checking with the fine people on #guile <ekaitz>hmm i just don't know who they are, i think my proposal is going a little bit more in the "we are alone in this" line <ekaitz>which we are not, but we shouldn't impose an overload of work on the current commiters in Guile <podiki>should have all substitutes built already (except riscv64-linux which isn't on the CI mesa-updates job or QA) and things look good, but feel free to ping me directly if you run into and breakage later <podiki>newer vulkan, wayland-protocols, and mesa <podiki>wlroots has been using just wayland-protocols, so it will now use the latest version, if that's what you mean <podiki>(maybe in the past it used a newer version of wayland-protocols? but now we'll be caught up) <podiki>there was "wayland-protocols-next" which just a couple of packages used and i've gotten rid of it with this update <ruther>podiki: great to hear. FYI I am running off of mesa-updates branch for a couple of days and didn't notice anything out of the ordinary <podiki>ruther: thanks for the testing! i ran a few packages which have extensive dependencies and checked my own manifests too <podiki>after this i should put my efforts to that core-updates (or similar) as we really need to get that finished and be fully ungrafted <ruther>podiki: definitely, I think that currently the most problematic issue on core packages is going to be that gcc lower than 14 do not build <ruther>or rather... libstdc++ does not build and that's dependency of gcc <ruther>since the error is an internal compiler error, I am completely clueless. <podiki>yeah I saw that but haven't looked into it. i'm certainly no compiler/gcc/stdc++ expert but i'll see if i can help <podiki>i wonder if it is related to something I reported some time ago, with libstdc++ being different in its own procedure compared to built as part of gcc-toolchain, something like that; symbols were missing <ruther>I started thinking if it might be better to revert the changes to libstdc++ (using version compiled for specific gcc version) and do it next time... but not my place to decide <podiki>given how long it has been stuck for that might be a good idea, but i don't know what the changes are/what debt that sets up for later <podiki>have to run for now (literally); will check in later guixers! <alethkit>Is it possible to make a metadistribution out of Guix, gentoo-style? <ruther>alethkit: not sure what that means. But note that Guix is completely source based, you can modify anything <alethkit>ruther: If you look at the gentoo wiki/handbook, it encourages a lot more customization by default, whereas the guix install guide tries to simulate an installation of a normal distribution like Fedora. <alethkit>Is there some sort of advanced installation guide? <Tadhgmister>alethkit I mean once you have the first iteration the documentation does encourage you to edit the config file and look into system configuration, abiet not super promonently <Tadhgmister>I know for me having that first revision with a working if not super enjoyable settings to roll-back to when I broke stuff was very appreciated <Tadhgmister>does anyone know of a WebDAV/CalDAV server written in lisp/scheme/guile? both xandikos and radicale are not compiling on arm <alethkit>this is more of a "having a single source of truth though" <alethkit>so I suppose I would prefer starting from a hyper minimalist install <alethkit>rather than the default operating system settings <Tadhgmister>that is fair, a friend of mine recently went through their first guix install and noted the lack of "no window manager just plop me in a tty" option in the graphical installer process <Tadhgmister>having an option in the default process to disable the gui login process and all the gnome related dependencies it has would probably be good to offer (might be wrong about it using gnome but it does have many dependencies for a minimalist setup) <identity>alethkit: i am not what you mean exactly, but some packages have -minimal versions that have less dependencies, and some have the tunable? property set to #true if they can benefit from SIMD CPU instructions and such things. if you want more than that (for example, to fiddle with build flags yourself), you could also write your own package definitions pretty easily <Tadhgmister>but like I just the other day ran into an issue where transmission depends on a bunch of gtk stuff which is totally useless for default output it only matters for the `gui` output and had to write my own version to just drop some dependencies and add 1 flag to disable gui compilation <Tadhgmister>I can see a world in which it can be smarter where somewhere I can just specify I am compiling packages for a headless server and it automatically selects a version without graphics dependencies and that would be lovely from a user prospective but with the goal of having reproducable builds you'd want every permutation of a given package to be tested and with the way our build farms works I don't know it would be a good goal to actually implement <Tadhgmister>a package with N optional features would generate 2^N permutations, and I can't imagine a way to effectively share built results other than the way we do it now by having one package that setups everything (or all the ones that are typically enabled by default) and then possibly having alternative outputs to limit runtime dependencies even if build time dependencies are worse <Tadhgmister>*build time dependencies assume you may use all outputs 