IRC channel logs
2025-05-13.log
back to list of logs
<sham1>Debian packaging has always been a giant question mark to me. Like, rpm-files are so much easier to deal with, I can't fathom just why debs are so complex in comparison <PotentialUser-39>gabber I hope one day reach the zen state on Guix. But it takes time and effort and, meanwhile, I have work to do. Therefore, learning things on Guix has been taking a long time. <PotentialUser-39>I don't really like the AppImage / Flatpack / Snap packages. But Portage (from Gentoo, that I never used) and Aur worked nicely. <PotentialUser-39>For clarity, I appreciate your effort. Software building *is* hard, and some times it may feel like you vs. the world when another dev takes a shortcut or implements a hack to their build script. <gabber>PotentialUser-39: in my experience, whatever issue you may encounter: just ask here. those people who are not here to ask specific questions are lurking around because they are happy to help - no matter how specific the question <gabber>and, if that helps: we know how you feel and welcome you warmly to the club (: <PotentialUser-39>Oh, the community is nice. For sure. I would have given up had it been otherwise. <PotentialUser-39>For example, Nix has a lot of packages I am missing here. But I am still persisting with Guix because of you guys. <sham1>Fwiw, you can use Nix under Guix :) <sham1>I've actually been meaning to get my first contribution going and update the nix package to be 2.24.*, but at this point it might just be better to wait until the Nix folks release their 25.05 branch stuff and choose the next Nix version to use for their stable release of NixOS/nixpkgs <PotentialUser-39>Here is something more concrete: the software kdenlive is showing a strange bug that, to me, may not be from upstream. <PotentialUser-39>If you try to add a JPEG or PNG image, it will not render. I managed to see an error message along the lines of "cannot open file qimage://<path-to-file>". WEBP images work fine. <PotentialUser-39>I think it may be related to MLT, but... I know too little about so many things. '=( <gabber>PotentialUser-39: this may (or may not) be due to a missing (build) input and no build tests covering that. i had found something similar in the past (where some tool didn't show one kind of images but the other) <PotentialUser-39>I was happy to see that Guix had a package for kdenlive, but it did not work as expected. The same thing happened with the Heroic game launcher. <gabber>PotentialUser-39: please open an issue by sending a bug report to bug-guix@gnu.org <PotentialUser-39>gabber Oh, yes. Not likely linked to tests. But more likely linking issues or a path bug (some errors had strange qimage-scheme paths that did not look right). <PotentialUser-39>gabber Often times I feel there are already enough bug reports there... By the time someone looks at it, a new major version may be out and it will be meaningless. <gabber>PotentialUser-39: "major version" of what? <gabber>the issue tracker is like an agenda of what has to be done (eventually). if bugs are not tracked there they may just never - or only by chance - be fixed <PotentialUser-39>Major version of kdenlive. I do not track it, but there is one every 6 to 12 months. The but the bug may be there or not. <PotentialUser-39>I see patches bit-rotting while waiting to be merged. Those are fixes. I feel little hope for fixes that do not exist yet. <PotentialUser-39>Again, volunteer work, I understand. My to-do list is very big too. I haven't even managed to get my printer to work, understand Guix-Home, manage my dotfiles or learn Guile! <gabber>there are many ways to help the project, even if you can't code in Guile or have no write access to the repo: filing bug reports, reviewing patches, helping others, translating strings, etc <PotentialUser-39>I don't want to be the person that seems to be saying "This is not working. Fix it for me". I wish I could do more of the tracking and fixing on my own, but I'm not there yet. <sham1>Printers "thankfully" are terrible to deal with no matter what <sham1>Even the proprietary OSes are bad at dealing with them <PotentialUser-39>I stick with Brother laser printers for that reason. They seem to be well supported most of the time. <rkazak>I have a strange problem, I recently tried to login to my desktop ( Gnome I think ) however I am unable to get a successful login, if I switch to EVWM things work... Has anyone had a similar issue? <rkazak>In the desktop chooser there is both GNOME and GNOME on Xorg - When choosing the first the screen goes black and then returns to the login screen. When choosing the second a window is thrown up which says "some went wrong" and then return to the login screen <rkazak>I went to the logging screen/session (ctrl-alt F12) and see that the gdm display session fails to register error message is "WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist" <rkazak>I am not sure why it's trying to use systemd as I think that I am using shepherd... <apteryx>cbaines: hello! Gabriel noted in bug#78352 that QA used tho wrong commit as base, in case you'd know what happens <keinflue>Hi, is it intentional that (current-guix) produces a package that does not include additional channels beyond the 'guix channel? If so, is there a similar package including all current channels? <apteryx>keinflue: it's intentional yes. what do you mean by 'all current chnnels' ? the only official channel is the 'guix' one. <apteryx>what is the problem you are actually trying to solve? <keinflue>I mean all channels that make up the guix instance that is used to build the current-guix package. <keinflue>What I'd actually like to do is to include one user's guix into the home environment of another user so that it doesn't have to maintain a separate guix. <keinflue>i.e. the one from root on system reconfigure (using the home environment service) <keinflue>There is already a guix in the system profile, but it is not up-to-date and doesn't include my own channel. <apteryx>keinflue: maybe there was something added recently to include channels in a operating-system configuration? <keinflue>apteryx I don't see anything like that in the operating-system definition or documentation. <apteryx>maybe it's indirectly made available via home-channels-service-type <apteryx>because you can now declare each users' home configuration in your operating-system definition <keinflue>that seems like it only manages the channels.scm file for the user, I would still need to pull and manage the guix instance for the user manually separately from the system reconfigure, which is what I am trying to avoid <keinflue>apteryx I am already managing the actual packages and everything else for the user from the system configuration via guix-home-service. Managing the guix command used by the user as part of the system configuration is the only thing that I can't manage to do correctly at the moment. <apteryx>keinflue: is there no way to specify the channels used for guix home users? <apteryx>including the 'guix' main channel, at any commit you may want? <apteryx>it seems to me when using guix home there shouldn't be a need to rely on the system-provided guix, which is in fact a leaky abstraction of the guix-daemon that should probably be fixed. <keinflue>apteryx The problem is not specifying the channels, it is actually getting guix build from the channels into the profile. <apteryx>so there's nothing currently in guix home that sets up the environment in away that users have guix at version X (that would translate to placing the correct ~/.config/guix/channels.scm file and then running 'guix pull'). <apteryx>ACTION is still not using 'guix home' but intends to do so soon (TM) <keinflue>yes, that's the problem I can't solve, at least if there should be other channels than the default one in that version X <apteryx>OK. It seems it'd have value to be solved properly in guix home. It sounds like a useful feature to me! <keinflue>apteryx I guess I have to look into how to build guix including additionally channels as a package. Then I could just list it in the home-environment package list and I think that would be enough. <apteryx>maybe it's just that when reconfiguring as part of 'guix system reconfigure', if there are changes to 'guix home' specified channels, it should run 'guix pull' for the affected users. <apteryx>so that what they specified is actually reflected post a reconfiguration? <keinflue>apteryx Then I couldn't roll-back to a previous version easily, which was part of my intention. <keinflue>On a related note: Is there any way I can use guix shell to provide a container environment with packages that are not part of the user's guix, e.g. by specifying a specific store output/derivation instead? The only way I can manage that currently is to have the package be part of the user's home profile and then using the -p option to include the <keinflue>whole user home profile into the environment. <dots_>Hi! very new to guix and IRC in general. i would like to know if there is a specific tag for packages such as gcc-toolchain@latest to always pin the guix home config to the latest version. At the moment my gcc-toolchain install is stuck at version 11, when there is a version 15 available. but when i try to specify gcc-toolchain@15.1.0 to test pinning in my home config. it is unbound. <ruther`>sneek, later tell keinflue: yes, guix shell is meant to use packages that aren't installed to user's profile, just specify them the same way you did in your guix home and you will get them in the shell. Doesn't matter if it is container or not <ruther`>sneek, later tell keinflue: (current-guix) is supposed to give you the same guix instance as you are using, including all channels other than guix. Are you sure you're using it at the right place and that the guix you are using to build it does have the extra channels? <futurile>apteryx: yeah, they don't really _want_ to understand the issue <apteryx>I guess that attitidue will grow with flatpakt and friends, where upstreams become their own distributor too. <futurile>Agreed, it's been a bit of a general direction of travel for upstream developers in the last 10 years. Any touching of their "pristine source" by a "downstream" is outrageous <futurile>it hasn't helped that end-users don't send bugs to the distros, they go to the upstream which is super annoying, and as we know the github (and others) tools for handling this are pretty poot <futurile>I appreciate their pain; they somewhat discount the fact that users use more than one program, so distributions have to exist for putting all the parts together imho <csantosb>apteryx, don't be surprised; this is eda world, after all. <csantosb>Any attempt to changing what they consider as their business will be regarded negatively <csantosb>Sourcehut users: Guix image usage is back again, by the way; issue was introduced in "a0941c14ef image: Create zstd-compressed qcow2 images.", not yet supported by sourcehut's qemu. <apteryx>csantosb: interesting; which version of QEMU is sourcehut relying on? <apteryx>csantosb: glad that the sr.ht issue has been promptly resolved! <apteryx>seems they just had to add zstd to their qemu build <jA_cOp>Anyone know how to get lv2 plugins working with pipewire? I get "can't load plugin type 'lv2': No such file or directory", and I think it's looking for a non-existant <pipewire pkg>/lib/spa-0.2/filter-graph/libspa-filter-graph-plugin-lv2.so <jA_cOp>maybe Guix's pipewire is built without lv2 support? <jA_cOp>adding the `lilv` package to pipewire's inputs results in libspa-filter-graph-plugin-lv2.so being built and I can get further :) <gabber>jA_cOp: would you mind sending in a patch to fix the issue? <jA_cOp>gabber: I will if I can get this working properly - currently blocked on pipewire erroring with "Invalid argument (-22)" when trying to load an LV2 plugin. I get the same error when doing `spa-inspect <pipewire>/lib/spa-0.2/filter-graph/libspa-filter-graph-plugin-lv2.so` so I wonder if pipewire SPA plugins are generally broken <jA_cOp>actually, the spa-inspect result might be normal <identity>jakef: you probably want to disable the tests/whatever that try to write to $HOME <jakef>identity: it's in the install phase though :( <identity>jakef: then you need to make sure the install phase does not do that <jakef>it's attempting to install python bindings <identity>jakef: either make so it does not, or make it install them to a package output <gabber>jA_cOp: filing a bug report can also be a valid starting point for you (in the future) and others to inspect and fix the issue <janneke>dongcarl: do you have a mingw c++ toolchain that uses winpthreads that supports std::mutex? <janneke>ACTION tries adding (native-inputs (list (cross-gcc "x86_64-w64-mingw32" #:libc mingw-w64-x86_64-winpthreads))) to the c++ package that needs std::mutex <janneke>possibly gcc needs a pthread flag (for the g++ build?), we'll see... <janneke>ACTION wonders what the reason for not always using #:winpthreads? #t might be <gabber>anybody have an idea why SuperCollider all of a sudden (between my last guix pull and right now) stopped starting? it fails: "Could not find QtWebEngineProcess". qtwebengine-5 is a propagated input and the package has not been touched for 2 years <csantosb>gabber, when was your previous guix pull ? <gabber>it works with commit: 41bd799b8a631a8ab5833b2d8157511bfef47f8e <gabber>i don't think qtwebengine-5 had any recent changes <gabber>this is from a commit almost 5 years ago <csantosb>gabber, you may try the QTWEBENGINEPROCESS_PATH trick <gabber>csantosb: thanks! this indeed works! <gabber>shouldn't this env var be set due to qtwebengine-5 being a propagated input to supercollider? <csantosb>When I 'guix install qtwebengine@5' I get QTWEBENGINEPROCESS_PATH set to $GUIX_PROFILE/lib/qt5/libexec/QtWebEngineProcess <csantosb>gabber: what are your changes to make it work ? <pastor>Hello. Is it possible to have a scheme record ungexped? <pastor>Like so: `(let ((config (home-gpg-agent-configuration))) #~(begin ... #$config))' <civodul>pastor: hi! no; you need to serialize it first, and then deserialize it on the other size <pastor>I get this error, `&gexp-input-error: #<<home-gpg-agent-configuration> ...>' <civodul>some configuration records have a “gexp serializer”, so you can ungexp them as if they were files <civodul>pastor: so in this case, serialize/deserialize <pastor>civodul: this is actually regarding a bug I wanted to discus with you. <pastor>The thing is that for GUI pinentry to work the TTY of the GPG daemon must be updated after starting this daemon, onces the display is available (i think). <pastor>So now you need to invoke this on a shell for the service to work as expected: `gpg-connect-agent updatestartuptty /bye' <sham1>I'd probably (define) a variable for the ssh-support? at the head of your define's lambda body and then reference that, because that will work <pastor>civodul: regarding your desarialization suggestiong, is the fact that `home-gpg-agent-configuration' is defined with `define-configuration/no-serialization' a problem? <sham1>So something like (define ssh-support? (home-gpg-agent-configuration-ssh-support? config)) and then below you'd do #$ssh-support? <pastor>sham1: I think you are right. I will try that <pastor>Obvious now that you say it 🙂 <sham1>As an aside, it's kinda sad to me that we need to use (getenv "HOME") to get the home directory in a guix home activation script thing <sham1>I feel like there should probably be a better way to do that <pastor>There probably isn't I've seen it countless times <sham1>Right. I feel that there probably ought to be one, however. Maybe an SRFI 39 parameter or a fluid binding <pastor>In the end it has to be an environment variable, no? A parameter would probably not be good enough. `setenv' should be able to mutate it <civodul>pastor: well yes and no, you could always define your own serialization/deserialization procedures <civodul>but maybe we should talk about what you want to achieve <pastor>civodul: I just need to know if `config' has `ssh-support?'. And seems like sham1 suggestion of just droping it in a variable is the easiest way <pastor>I didn't ping you earlier because I know you are bussy with the Codeberg migration <pastor>civodul: there is no hurry. Don't worry about it. <dariqq>hmm the gnu updater is crashing on a custom package for me. It seems like the available versions are the empty list and it is trying to get the car of them <dariqq>is there a way I can hint my package to prefer the generic-html updater by default because that works? <divya>Sent a patch to update mupdf. Need it pretty soon for another package, if any committers around, please review #78401 <ieure>divya, Can't do anything about it until I'm off my regular job, but at a glance: formatting is wrong in several places (tabs instead of spaces? But other stuff as well). Will changing USE_SONAME break packages that depend on mupdf? <divya>ieure: No worries. Take your time. I didn't change the formatting from the old definition, so not sure. I'll run guix style/lint through it again. <divya>And I don't think anything will break, because it gets symlinked to libmupdf.so anyways. <divya>Rather not having USE_SONAME enables leads to : "too many levels of symbolic links" error <ieure>divya, There's a large space added between base32 and the hash; "brotli" input "USE_SYSTEM_BROTLI" lines are misaligned. <divya>Okay, I'll check the format and send a revised patch. Thanks! <tusharhero>I think its some git feature which allows you to make pull requests <lechner>tusharhero / okay, thanks! i found it. it's a feature of Gitea to make merge requests without forking the repo on the server <ieure>Yeah, just seems like a convention for remote refspec handling, not a piece of software. <lechner>unfortunately, i cannot use it since I run a full Guix fork and pull from Codeberg <ieure>I don't think those are mutually exclusive. <ieure>You can add Guix upstream as a remote to your clone, cut a branch off it, push that with agit, merge it into your fork once it lands. <andreas-e>divya: Look at QA, your update to mupdf makes a dependent package fail. <divya>andreas-e: Ah, looks like it does. Not due to SONAME though, I need to look through the packages that depend on it better. I believe we might want to keep 1.25 still around. But thanks for making me look at the QA, I assumed it didn't work :D <ieure>lechner, I also have a mirror on Codeberg. <ieure>Keeping some of my more ambitious changes there & building them on my Cuirass. <andreas-e>QA is in a quantum state, it works and does not :) <lechner>ieure / maybe the decent thing would be for me to self-host. it will throw me into a real loop, however, when i bungle my system <andreas-e>It always chooses the latest issues, but cannot keep up with the volume of submissions. So if you are lucky, your issue is treated; if not, it slips through and never resurfaces. <ieure>lechner, I think it's fine, the Codeberg folks don't seem to have a problem. <lechner>well, i'm on sure how they are financed. they obviously have some very generous, non-corporate sponsors <lechner>where is the money coming from, and how long will the free ride last? <lechner>andreas-e / what is the rate of slippage? <ieure>I don't know how much transparency there is into who donates how much. <divya>Codeberg has been going down very often last few days <lechner>i didn't mean it that way, but hosting is expensive <divya>Earlier today I wasb't able to push or fetch from my repo with ssh for 30mins or so <lechner>i think the current issues are bot-related, not financial <ieure>lechner, I think that as with a lot of larger community projects, hosting is provided as an in-kind donation. <ieure>Probably only a matter of time until the Internet is so hostile that FOSS dev work has to move to private overlay networks. <ieure>It's pretty dark out there, my friend. <lechner>you and i could communicate, slowly, over DNS! <ieure>Pretty much anything you stand up is under constant attack within days of going live. <lechner>we need a police, but that's unpopular in our circles <ieure>There's no enforcement mechanism possible with things how they are. <ieure>Running an overlay network gives the power to self-police, by kicking off anyone behaving badly. <lechner>i am not sure the question of who does the policing, and how, is easier with another network layer <ieure>It doesn't make it easy, but it does make it possible. <lechner>given current traffic, it would be mostly an anti-AI posture? <ieure>I think it would work with multiple kinds of abuse, including AI scrapers. <lechner>we just need a good class action lawsuit <ieure>That won't work, it's an international problem. <ieure>On the open internet, there's no effective technical means to prevent someone from accessing your stuff, or from hopping IPs, or launching a DDoS. <dlowe>in the court of the internet! <ieure>An overlay network where you use Tailscale's Free (BSD-licensed) client with Headscale control servers, you can establish a governance structure where bad behavior results in deactivating the client's key, which boots them from the network. <dlowe>lechner: you have been accused of inappropriately setting the evil bit on non-evil content. How do you plead? <ieure>All you can do on the open internet is beg the ISP that's the source of the abuse to do something about it. <ieure>I guess this doesn't help if you have an open Internet IP which routes to the same hardware as your overlay network. <ieure>And the stuff like Tor which anonymizes that has no facility to boot users. <ieure>I think it's still possible with better tools. <gabber>csantosb: i did a simple `QTWEBENGINEPROCESS_PATH=$(guix build -e '(@ (gnu packages qt) qtwebengine-5)')/lib/qt5/libexec/QtWebEngineProcess SuperCollider' which worked <gabber>weird. `guix shell coreutils supercollider --pure -- env' shows that variable set <gabber>huh. i can't reproduce the issue on my laptop <gabber>i *can* reproduce! the error must have been injected since f0b502a25260bf8c6a08cc37897c13f2745d71c9. <gabber>(how) can i retrieve the path of a package output? `guix build foo' but for output 'out'? <identity>gabber: `guix build foo | grep out` should work <identity>unless the output is actually 'out', in which case just omit the grep <gabber>identity: there's multiple outputs. `grep -v debug` omits the one i don't need <andreas-e>lechner: I do not know how many issues are handled by QA vs. how many are (implicitly) dropped. <csantosb>Ey Guix ! I'm wondering about an estimate to see emacs-team merged <csantosb>Thinkin about, as building all emacs-build-system packages in the branch took something like a few hours to complete in my laptop <sham1>I would imagine that the CI servers would be faster <sham1>Especially if most of them could be done in parallel <lechner>andreas-e / can QA send an email when skipping? <andreas-e>lechner: It does not explicitly skip. It looks at a finite number of issues in a LIFO manner. If new ones appear, older ones falls off the cliff. Theoretically if enough patches from the front of the queue are closed, older ones will reappear. <sham1>Does guix.el actually work? Like, I've read some mailing list stuff and things about it being unmaintained and all that, and I'm a bit worries to be honest <ieure>Was just reading on guix-devel that activity has picked up a bit since it moved to Codeberg. <ieure>My biggest gripe is that its completion for guix commands in shell-mode don't work, and also break the regular file completions. <ieure>Filed an issue on that a while back, but it's still broken. <ieure>I haven't gotten mad enough to figure out what's going on with hit.