IRC channel logs
2025-03-08.log
back to list of logs
<JodiJodington>is there anything I can do when I try to reconfigure my system and a package's test phase fails? at this point ive been stuck reconfiguring my system for over 24 hours and still haven't figured out a path foward <jakef>JodiJodington: try again when guix weather says its available <jakef>if the package is broken, guix pull after its fixed <jA_cOp>How do I get desktop portals working, specifically with Flatpak applications? I have tried installing "xdg-desktop-portal-gtk" in both guix home and system-wide, but I'm guessing it belongs in guix home. I have the home-dbus-service-type running. On other distros it looks like portals are dbus-triggered systemd user services - how is it supposed to work on Guix? <tomenzgg>jA_cOp: I can't speak to working with Flatpaks (I was trying to get screensharing to work, in my case) but I just have xdg-desktop-portal and xdg-desktop-portal-wlr installed in my guix home (additionally, I had slurp installed and a desktop-portal-wlr.cfg file to get slurp to work for screensharing but that's obviously something different than what you're asking about). <tomenzgg>So I'd expect you need to, at least, start with xdg-desktop-portal and xdg-desktop-portal-gtk (assuming what I have isn't redundant, of course) in your guix home though I don't know what (if anything) you'd need, after that. <jA_cOp>So, if I have just "xdg-desktop-portal" and "xdg-desktop-portal-wlr" (I'm on Sway), and I start Komikku - a GTK-based app - in Flatpak, it can't find dbus interface "org.freedesktop.portal.Settings" on startup, and later "org.freedesktop.portal.OpenURI" if I try to open a file chooser <jA_cOp>I haven't been able to install both "xdg-desktop-portal" and "xdg-desktop-portal-gtk" at the same time because of conflicting versions <jA_cOp>> profile contains conflicting entries for xdg-desktop-portal ... first entry: xdg-desktop-portal@1.18.4 ... second entry: xdg-desktop-portal@1.16.0 ... propagated from xdg-desktop-portal-gtk@1.14.1 <jA_cOp>guix pull + reconfigure doesn't seem to help with this <podiki>portal-gtk propagates xdg-desktop-portal, you don't need to have that also <jA_cOp>mhm - but if I have just "xdg-desktop-portal-gtk" and "xdg-desktop-portal-wlr" I get all the same problems from Flatpak apps. I wonder if I could test the file chooser/OpenURI portal outside flatpak to see if it's a flatpak-specific thing... <podiki>jA_cOp: and did you restart/relogin after adding the portals? you should see in XDG_DATA_DIRS a dbus-1/services directory with portal stuff <podiki>anyway have to run, but there were also some updates/changes to the portal packages in guix recently <jA_cOp>thanks - that gives me something to look out for! <jA_cOp>I was able to fix it on my setup by adding this to my Sway config: exec dbus-update-activation-environment WAYLAND_DISPLAY=$WAYLAND_DISPLAY <jA_cOp>When using define-configuration, what's the field type for a file create like (plain-file "foo" "content")? e.g. (define-configuration/no-serialization my-config (action string "path to script")) except of course, it's not a string, but a file <jA_cOp>yelninei: thanks, that worked perfectly! <apteryx>lilyp: I think we've lost at least one commit of mine on gnome-team (when you rewrote it) <jas>anyone seen this error? "guix time-machine: error: corrupt input while restoring archive from ..." <apteryx>I'd like to propose we use merge instead of rebase on team branches where multiple team members might merge stuff, otherwise it's confusing and will lead to lost work. <cbaines>we know merging is error prone, I think rebasing is clearer and hopefully less error prone <lilyp>resolving conflicts, basically <lilyp>apteryx: which commit? can you find it? <Rutherther>how is resolving conflicts in merging any more error prone than when rebasing? <cbaines>Rutherther, there's conflict resolution involved in both merging and rebasing, but in the past we've ended up duplicating commits when merging (and rebasing) branches <cbaines>it's much harder to duplicate commits across branches if you just rebase (plus the history is much clearer) <cbaines>personally I find the conflict resolution clearer as well when rebasing <Rutherther>the history is less clear, because you don't see what happened in past when you are doing rebases, with merges you see clearly what happened when <cbaines>I think we want to simplify the history when working on patches and branches though, the simpler we can get changes prior to merging the better <cbaines>I don't think there's much value, and there's a lot of cost involved in preserving "history" from branches and including that on master <cbaines>so when I say clear history, I'm thinking about the history on the master branch being clearer <lilyp>I can't say I fully agree here. With history rewriting, you get the issue that things which used to work may no longer work post-rebase. <cbaines>I don't think that's avoided with merging lilyp <Rutherther>cbaines: the difference is that with merging you have kept all the lost work, so you can recover it easily. With rebasing your only possibility is reflog or other people having the work on their machine <lilyp>With merges, you can point to the merge as the time when "the fuckening" happened – which is still bad, but nicer for time machines <Rutherther>okay, if it really is combination of patches at all times, then that's true. I didn't think that was the case for when people are working on team branches <cbaines>indeed, the guidance is aspirational <apteryx>lilyp: it was the commit with Change-Id Ic63c2e879b590104d7f4c9b4513e65b51f02814f <apteryx>I've now rebased my gnome-team branch on top of origin/gnome-team, and that seems to be the only one missing <apteryx>cbaines: because rebasing changes the commits, it's not suitable for working on a branch as a team <apteryx>it's most useful to keep a clean history on private feature branch <cbaines>we've done it in the past and it's helped <apteryx>depends what is the goal: keeping a clean history yes; making things sensical in a collaborative setting, no <apteryx>It's like if someone was rewriting the master branch on a whim; would that make collaboration easy? <apteryx>it's the same in that there are multiple collaborators working on a shared branch <cbaines>but it has a entirely different purpose to a temporary topic branch <apteryx>you are focusing on the time the branch is merged to master, right? Preferring a rebased approach at that time? This I can agree with, but not while the branch is being synced with master, if there's a need for that <cbaines>I think it's useful to try and work out how to better collaborate around branches, but ruling out rebasing seems problomatic to me, since it makes it harder to address issues on the branch <apteryx>I think it could make sense to fix up branches at the last moment before a merge, but it should be avoided while the topic branch is an ongoing wip <apteryx>another pointh: for small topic branch, it makes sense to not clutter history with merge commits; but for very large branches, such as gnome-team or qt-team, etc., a merge commit would make reverting easy and help understand the history <cbaines>I'm not really thinking about pushing the branch to master (via merge or rebase), that's maybe less important as I don't think problems get introduced at that point <apteryx>OK. So we're discussing rebasing team branches during their development, right? If so, that's the place where rebase seems unfit for collaboration (more than 1 committer to the branch) <divya>Can anyone recommend some packages in Guix for GTK themes? Especially dark-mode ones <divya>I guess we don't have dracula until now? <apteryx>cbaines: reading further, they do mention that 'rebase on top of force-pushed rebase' can recover from that situation, as long as the commit changes haven't been touched and that there are no merge commits to rebase. But that still would require some sync between team mates to avoid the risk of loosing work/avoid surprises, so should be used sparringly, or just at the time of merging to master. <lilyp>apteryx: I can't seem to find that ChangeId in the mailing list <lilyp>feel free to rebase gnome-team on current master and push your commit on top <apteryx>lilyp: I merged it directly without review, we had briefly discussed it here IIRC and it was small <lilyp>if it's small enough to go to master, I won't stop you :) <apteryx>cbaines: should I give a try at updating our recommended git flow based on more conventional git practices? I could make a draft and include guix-devel so it gets discussed more <cbaines>apteryx, I've got to go now, but I think if we can move towards smaller topic branches that contain a few patches that can't go directly to master, then we'll avoid the problems you mention with rebasing and in general the problems associated with managing long running large branches <apteryx>we'll always have largish branches, sadly (think GNOME, KDE) <lilyp>think that one rust application (300 untracked dependencies) <cbaines>I'm not convinced, I'm confused to why gnome-team for example was effectively the size of core-updates in terms of builds and I'm unsure if every commit on that branch couldn't be pushed to master <apteryx>you can't typically, because you're touching like glib, and then gnome 44 apps wants one version and gnome 46 another one, etc. <apteryx>but sometimes it works, but it's a case by case that would be a pain to manage (I've attempted it in the past) <apteryx>it's easier to update everything with a manifest on gnome-team, test that, then merge <cbaines>I'm hopeful that if we can better identify how packages group together and where it might be useful to break apart the graph (e.g. by having multiple versions of packages), we can make managing changes easier <apteryx>lilyp: other than my with gripes with git flow, good job on tackling GNOME 46 mostly alone. It works well and has resolved a bunch of annoyances I've had on GNOME 44, such as applications resizing oddly after a screen lock (fingers crossed) <apteryx>civodul: hi! perhaps caused by "hydra: bayfront: packages.guix.gnu.org redirects to Guix-HPC on error." ? ^ <Minall>Guix being a Lisp environment, is it possible to debug it with something like Emacs?, for example, if I were to write something in Scheme, and use it in Emacs, be able to debug it and use let's say, the HTTP library of guix instead of the elisp one? <Rutherther>Minall: you're mixing up guix and elisp, did you mean to say guile instead of guix? guile is the language. guix is package manager / build system made in the guile language <Rutherther>I don't really know about debugging guile, so I can't really help with that. But it's possible you will have more help in the #guile channel if your question really is how to debug guile libraries, not how to debug something from guix <JodiJodington>I'm tryign to pacakge a kernel module and I'm wondering how I would get the version of the installed kernel package so I can output the kernel module to OUTDIR/lib/module/kernel/VERSION <JodiJodington>ofc I could use `uname` but that would give me the kernel version that's currently in use which isn't the same thing if, say, I'm reconfiguring my system after a kernel upgrade <civodul>i tried to help but more work is needed, apparently <Minall>Rutherther: Thank you, I'll ask there <Rutherther>JodiJodington: you shouldn't have to worry about that. The install phase puts the source to proper directory in linux-module-build-system <JodiJodington>I overrode the install phase since it wasn't working well for the way the source code is organized upstream <JodiJodington>I don't really understand where I'm supposed to place the outputted .ko file before the install phase <JodiJodington>looking at the source code for it, it only checks the linux-module-builder's dir in the store for files and I don't think I can even write into that directory? <Rutherther>if you really need to, it's at "(string-append (assoc-ref inputs "linux-module-builder") "/lib/modules/build/include/config/kernel.release")", the file contains the version directly, nothing else <JodiJodington>what would the proper way to do it though? i'd rather do it correctly if its possible I was just super lost <Rutherther>JodiJodington: I don't know why you're pointing out that you can't write into it, yes, you can't write into inputs. But you don't need to at all <Rutherther>that is not linux module build system install phase <JodiJodington>im very lost then, what was I looking at? and where is the actual source code for the linux module build system? <Rutherther>that is in guix/build/linux-module-build-system.scm. What you're looking at is the linux-module-builder which is the thing that knows the way to install the modules and the kernel version used so it installs it to the correct directory <Rutherther>as you can see in one of my previous messages, this module builder is exactly the thing you would be looking into to get the kernel release version, I sent the whole path to that file <JodiJodington>would it be fair to say that the linux-module-builder just provides the build environment for the linux-module-build-system? <daniel24>I want to try emacs 30.1 on guix. Tried setting up a channels.scm file pointing to commit 23818287c0e303cf99aa670b4fe709cc19cb4661 on the "emacs-team" branch. Then running "guix time-machine -C channels.scm -- shell emacs". Got an error "build of /gnu/store/h3mdd7h5gvjahpnhs80lyl4mcj8igdsv-guix-package-cache.drv failed". <daniel24>How does everyone test changes not yet merged to master? <Rutherther>daniel24: look at the log to see what went wrong. Also this is one of the ways. The other is to clone guix and build from that, see the manual section for building from git. It's possible it was just a fluke or guix channel is broken at that commit. <daniel24>log shows "(exception wrong-type-arg (value "scm_to_utf8_stringn") (value "Wrong type argument in position ~A (expecting ~A): ~S") (value (1 "string" #f)) (value (#f)))" <ieure>Fresh LibreWolf patches in #76869 if anyone's inclined to take a look. <sayf>is guix suitable for laptops with weak cpu? I can't use source based distros so I'm asking how reliable are binary subs <Rutherther>ieure: is the thread supposed to contain the patches already or are you planning on submitting them? because I don't see them there <ieure>Rutherther, I sent them to the wrong bug :( <daniel24>Rutherther: building from git works, checked out "emacs-team" branch and ran "./pre-inst-env guix shell emacs". Got Emacs 30.1 up and running. I'm not sure why the time machine would fail then? <wakyct>sayf define weak I guess but my daily is Guix on a laptop from 2010 <ieure>sayf, Substitutes availability is usually pretty good for x86, but it does vary over time. You can configure an offload machine to do the builds instead -- I do this even for my fastish laptop -- or wait a bit if you end up compiling stuff. <ieure>Rutherther, Resent to the right place, but mumi hasn't picked them up yet. <wakyct>sayf 'guix weather' command can help check for substitutes <sayf>wakyct I haven't installed it yet, I'm trying to know if it's designed as a source only distro with bin subs being a secondary thing, or if it can be used (most of the time at least) without compiling <ieure>sayf, It's source-based, but I wouldn't say substitutes are "secondary." <ieure>sayf, Sometimes you go to update and it wants to compiles stuff. Usually, this isn't a big deal. If it is a big build, I kill the update and try again later, and substitutes are usually there. <ngraves>I wonder because I'm not able to find it easily, where/in which package are the at/batch binaries in Guix? <wakyct>(unless I'm working on a project that needs it) <wakyct>One thing I would recommend if you're using an older machine with maybe less storage is size your root partition bigger than usual <wakyct>I installed on a 30G / which in retrospect was too low, I repartitioned recently to 60G <ieure>Even that's small IMO, >= 250gb is what I'd recommend. <wakyct>ideally I'd replace my HD entirely <wakyct>nice thing about Guix is it makes that process a lot easier <fnat>I'm trying to create a GPG key pair within a Guix container but there's not enough entropy and the command doesn't terminate. I mean, this makes perfect sense given it's a container etc, but is there any simple workaround? <fnat>I'm only testing something and I don't care about the entropy "quality", i.e. /dev/urandom would be perfectly acceptable in this case. <ieure>fnat, What usecase needs a GPG key that's not secure? <fnat>ieure: Testing something? <ieure>fnat, Can you generate the key outside the container and bind-mount it in? <fnat>ieure: Hm, good call, that probably makes sense. The full context around this is testing qtpass (mostly from a UX point of view here, hence the container to get isolation from my main environment and the relaxed security concerns). <fnat>I liked the idea of testing how qtpass handles the creation of a key pair, to gauge whether it could make sense to suggest it to someone who's not GPG-savvy. <ieure>I poked around the gpg man page, but didn't see any option to generate a key with poor entropy. It's understandable why they might not want to even make that an option. <fnat>Yeah, I was more wondering if there was some trick to start the container in a way that could tap into the host's entropy source. <fnat>Oh wait, perhaps I could bind some random source like /dev/random? <ieure>It's just a device node, if containers are isolating entropy from the host, binding that won't change anything. <ieure>I'm surprised entropy is isolated at all, honestly. <ieure>There might be something different going on. <daniel24>any docs on how guix teams test packages patches? <ngraves>IIU your question correctly : they apply patches in their branches, which are then evaluated on ci.guix.gnu.org. There they have an overview of failures created when patches are applied. <ngraves>So for python-team, you have branch on savannah called python-team <daniel24>that's what I was looking for, seems like the patches I was testing are failing - this might explain why the time-machine command was failing <ieure>Teams also push to master, ex. I'm on emacs-team and most patches go to master. <ieure>Stuff that touches Emacs itself often goes on the emacs-team branch, bumps to / additions of elisp packages go to master. <daniel24>I was trying to install emacs 30.1, it seems like it didn't make it to master yet <daniel24>Was able to do so by building from git, but not from a time-machine command pointing to that channel <daniel24>branch "emacs-team", commit 23818287c0e303cf99aa670b4fe709cc19cb4661 <ieure>It's a branch of the Guix channel. <ieure>But, yes, it's in emacs-team, but not master. <daniel24>Shouldn't I able to guix time-machine install from it? <ieure>I'm not sure you can use time-machine to install a package into your current profile. I genuinely don't know <the_tubular>How would I go to enable the SSH EnableEscapeCommandLine option? In a guix way <Rutherther>daniel24: so just install from the local checkout - ./pre-inst-env guix install emacs <daniel24>Okay, I tried a few things. Tried "guix time-machine -C emacs-team.scm -- shell emacs", also tried inferiors, and separate profile. None worked. Only the local checkout. <fnat>Here's the incantation used with qtpass: 'guix shell --container --expose=/tmp/.X11-unix --no-cwd --preserve="^DISPLAY$" gnupg qtpass coreutils -- qtpass. qtpass will start but it won't be possible to create a key pair for lack of entropy. <daniel24>Rutherther: Yeah that works for me. I was just trying to use 30.1 before it got merged, test it out. Guess I'll have to wait for it to be merged into master or just use the local checkout. <Rutherther>I really don't understand what you mean by that. The local checkout is not 'worse' than using a channel from commit. It is on the same level, you can do the same things with it. So I don't understand why you're trying to use time machine and don't just use the local checkout <daniel24>Sorry, I'm still learning the ropes around guix. Yeah makes sense, I don't know why I assumed that was "janky". I'll give that a go. <daniel24>"GNU Emacs 30.1" beautiful, thank you Rutherther <Rutherther>daniel24: note that you should be using packages that are buiilt for emacs 30 (so the ones from that branch) as well so that you don't get surprises. That is if you are using packages from guix <onf>I'm trying to install GUIX on a laptop, but the installer wont let me continue past wifi network selection. Is it possible to complete the installation without wifi? <luca>afaik you need ethernet at least <luca>or appeal to the dark propriatery masters with forbidden techniques <onf>Internet connection during install is a hard requirement? <onf>Or perhaps I can create my own iso, and preload it with whatever I need. <onf>Maybe GUIX isn't the best option for what I'm trying to do. I had more Success with NixOs, but it has its own different issues it seems like. <ieure>luca, The Guix installer requires network. <ieure>onf, The simplest way to get Guix installed is to connect an Android phone and turn on wired tethering, it shows up as a USB Ethernet adapter. <luca>I used to do that until I installed LineageOS on my phone and that also didn't support wifi because of propriatery blobs :P <ieure>Heh, may as well carry a paper notebook at that point.