<itd_>nckhexen: A guess: In `(package name "foo")` parens are missing (assuming it should be `(package (name "foo"))` instead) and in `(package (name "foo")` parens are mismatched, since another `)` is needed.
<a12l>Where can I find information about web browsers in Guix? I'm trying to find one, but when I run `guix search firefox` I don't get any direct hits on Firefox. The manual doesn't seem to discuss web browsers, and the website's package search interface seem to only allow browsing, and not actually searching?
<a12l>Thanks for all the tips! But where would new users find this information?
<mekeor[m]>a12l: does "guix search browser" give helpful information?
<Kabouik>There is not a lot to learn about Nyxt if you stick with the base config and already know emacs or vim (there's also a CUA binding mode anyway); but the base config is hard to stick with, I changed mine
<mekeor[m]>mekeor: that search has too many hits, but useful packages seem to be included
<Kabouik>a12l you could look into `gnu/packages/web-browsers.scm` if you clone the Guix repo
<a12l>I'm more interested in where I can find the documentation that tell new users what they need to do to get going.
<mekeor[m]>mekeor: it's unfortunate that "icecat" is not described as "web browser" but as "browser" only. otherwise, searching for "web browser" would have been a nice solution
<Kabouik>Note that what I said just above obviously not really is adequate to informing new users
<mekeor[m]>a12l: i think, in general, if you look for a package with a certain function, the package-search seems the way to go; i'd say :)
<a12l>mekeor: I got a few hits, but a lot of them is irrelevant. And it's quite unintuitive (I think) that I need to search for "browser", because no big browser has the word "browser" in its name?
<a12l>gnucode: After scrolling a few hundred lines I haven't found anything that seems like a web browser.
<Kabouik>Thinking of it, it'd be cool to have some kind of `guix search --like qutebrowser` command, which would return all packages from within the same upstream .scm file (without forcing the user to clone Guix). It would help discovering program alternatives available in Guix. Of course it woul be a mess for all those packages in *-xyz.scm files.
*mekeor[m] wonders why "guix search firefox" does not find icecat because "firefox" is in icecat's synopsis
<Kabouik>An extension to that could be to allow `guix search --like keyword` whereby keyword is not available as a Guix package but just is widely popular, like Firefox.
<a12l>mekeor: Icecat is returned as a result, but a user that search for Firefox isn't interested in Icecat (at least initially)
<a12l>mekeor: it says "IceCat is the GNU version of the Firefox browser. It is entirely free software, which does not recommend non-free plugins and addons." It does not say "Firefox isn't available in Guix's package repo", etc. If users don't know that Firefox isn't available, they don't look at the description of Icecat.
<pkill9>which will help make it easier to do further modifications because, then you can run different configurations of software in a mangeable way
<pkill9>which makes iteration and thus hacking easier
<podiki[m]>I take it back, I thought I saw cairo updated in guix when there were newer versions out, but maybe that was seeing the merge of it from core-updates or something
<mekeor[m]>a12l: agreed. there should be a chapter in the guix-manual which describes such specifics of guix. "you can try icecat if you are used to firefox". what else would go in that chapter?
<Kabouik>You're right a12l, however if users come to using `guix search firefox` or `guix search browser` after failing with `guix install firefox`, they probably understood that Firefox is not available, which gets clearer with Icecat's description stating that Firefox is not totally in sync with Guix' philosophy.
<a12l>mekeor: I was searching for "web browser" in the manual, so maybe a chapter named that there the different web browsers that are available are discussed?
<a12l>Kabouik: I'm not so sure about that. I guessed that Firefox probably was considered "problematic" because I've used Debian before when "Firefox" wasn't available. I know that was because of different reasons, but it make not-obvious that Firefox is available in a Linux repo.
<podiki[m]>hrm... guix lint notes some possible CVEs for our old cairo version, should we graft 1.16 to 1.17.2....?
<podiki[m]>(i don't think significant changes api-wise, but is a version change)
<a12l>The amount of distributions that don't include Firefox is few, so new users probably assume that Firefox should be available; and if they can't find they guess that they're doing something wrong?
<noah>I am trying out Guix for my personal desktop right now. Is there a way to uninstall packages installed on the base system (part of %base-packages)?
<mekeor[m]>a12l: i think listing and discussing all available browsers is too much. and we already have configuration documentation in the manual, like nixos.
<Kabouik>If I am fully honest a12l, I remember I did ask here if Firefox was available in Guix (and it is but not in the main guix channel that complies with Guix philosophy). I don't use it, but wanted a fallback browser for when things don't work. I now use Icecat for that, but actually Icecat does not always work as one would expect for those mainstream things (like videoconferencing).
<unmatched-paren>noah: Just change the ``packages'' field of your operating-system record.
<Kabouik>They could expect that firefox is not available but firefox-esr is, too. But yeah, that's a problem with those very famous programs that anyone would expect to be packaged, indeed.
<mekeor[m]>noah: you can probably set (operating-system (packages '())) or so. but be careful!
<a12l>mekeor[m]: This is a bigger change, but would it be possible to add tags to packages that make it easier for new users to find available packages for a task? This is less necessary for Nix (that I currently use) because pretty much all applications are available, free and proprietary alike. But for Guix which filter out a lot of applications should maybe make it easier to find alternatives?
<a12l>But then you also need to take into consideration that to much chooses could create decision paralyzes in new users.
<podiki[m]>I believe we have 20,000 packages, so that's a lot of tags
<podiki[m]>perhaps a manual section of "common desktop setup tips" or something like that, about things to know about getting started on guix (like we have for applications on foreign distros)
<mekeor[m]>podiki: "like we have for applications on foreign distros"?
<a12l>A getting started would be a great first step!
<Kabouik>a12l that would be nice but probably impossible to do for the existing packages. I also suggested something less powerful but easier above with `guix search --like keyword` where keyword would be a program. (To disambiguate, that guix command does not exist, but I think it could help a bit).
<mekeor[m]>i still think it's not catastrophic to require guix-users to read the synopsis of 5 search-results
<a12l>That's one option. With that you could also add an entry that says that Firefox isn't available, and list similar packages
<mekeor[m]>are there any other mappings like firefox->icecat for incoming users?
<Kabouik>Considering they most probably had to go through the Linux-libre vs Linux kernel before, they probably are a bit educated about what Guix has to offer indeed. Might be different for users of just the package manager though.
<mekeor[m]>another possibility would be that for some certain keywords, like "firefox", "guix search" notes: "Firefox is not packaged for Guix but you can try Icecat"...
<podiki[m]>it outputs nothing, I assume that means same? or should I run with some options
<nckhexen>Hi all. Has anyone looked into yesterday's gnupg security announcement? I don't want to step on toes.
<mbakke>podiki: nothing means no changes IIRC, you can run verbosely to confirm
*nckhexen also hasn't yet checked how/if it affects Guix.
<podiki[m]>mbakke: thanks for the help. I guess I'll submit a patch with some caveats that this is a version change and touches a bajillion things
<Kabouik>I am getting https://0x0.st/owpJ.txt when trying to install r-styler. It complains about r-rrpp which needs to be upgraded, but r-rrpp no longer exists in Guix
<mbakke>podiki: cairo follows (or at least used to..?) an even/odd stable/unstable release versioning like GNOME, I haven't updated to 1.17.x because I was expecting 1.18 stable to release since...years :P
<Kabouik>Perhaps it got installed out of Guix package manager when I used r-guix-install?
<noah>mekeor: I have (packages(append(list(specification->package "nss-certs") What do I change to remove Epiphany from my installation?
<podiki[m]>mbakke: I see. I was actually in a rabbit hole about some emacs stuff and stumbled upon cairo being old. we have some cve patches but guix lint suggests other cves
<noah>sorry, kind of a noob - i checked docs and tutorials but I couldn't find much
<Kabouik>rekado: how do I uninstall a package installed in R with r-guix-install? remove.packages() does not find them, and guix.install does not have a remove option.
<a12l>I'm running Guix in a VM using KVM. I'm using the QXL driver/model. When I try to change the display resolution from 1024x768 to 1920x1080 it temporarily switch resolution, to very quickly change back to 1024x768.
<a12l>I'm using the VM image that you can download from the website
<mbakke>podiki: looks like debian unstable is on 1.16, while arch and centos has 1.17, so 🤷♂️
<mekeor[m]>i just searched the gnome.scm module in the guix git repo x)
<nckhexen>Guix's ‘gnome’ (meta)package is just a collection of propagated inputs. If you want ‘gnome’ without epiphany, you'll have to define your own gnome package variant (that removes packages you don't want) and pass that to the service.
<podiki[m]>cairo 1.17.6 seems to work in e.g. running icecat, but abicheck says 5 removed functions
<podiki[m]>so...still confused about cairo versions but guess I'll send a patch to graft to 1.17.4 and see what people think
***noah is now known as kyte
<apteryx>it'd be nice to have a way to define a default sticky value for a search-path-specification; e.g. "." for CLASSPATH, so that the current directory is considered, as should be by default
<apteryx>podiki[m], mbakke for what it's worth, I think it's fine to package latest releases of any GNOME thing. Fedora does that.
<apteryx>some GNOME components label their releases as stable/unstable, but that seems to be progressively phased out as a practice
<rekado>Kabouik: I can add a remove option if needed. To be honest, the bigger problem that I wanted to address was installing things, so I never bothered even considering a remove option :)
<mbakke>podiki: if the 5 removed functions are not part of the public API that's mostly okay (some may still rely on it, but that would be weird and we can handle those separately) ... but I think it would be better to only graft the two CVE fixes, and instead update to 1.17.6 on core-updates
<lechner>Hi, is it a concern when 'guix gc' produces messages like cannot read potential root `/var/guix/gcroots/auto/ ? Thanks!
<nckhexen>It's not… great. It shouldn't mark live items as dead, but you really don't want to rely on ‘shouldn't’ here. Why is it inaccessible? It's 755 here.
<gunnargrop[m]>Hi, I have this problem where GNOME won't see the .desktop files from applications installed via Flatpak. I've tried adding "XDG_DATA_DIRS=$XDG_DATA_DIRS:/path/to/flatpak/desktop/files" in /etc/environment, but to no avail. Does anyone have any ideas?
<lechner>nckhexen: sorry, i cut off the paths. it's referring to items in that folder, not to 'auto' itself
<nckhexen>Mmm, that's better, and should be of no concern whatsoever. If you want to file a ‘Guix scared me for no good reason’ bug, though, please go ahead.
<lechner>the run is taking so long, and the output was so voluminous; i have to re-run in a minute to get the paths
<nckhexen>Oh, yeah, I definitely don't mean the huge list after ‘deleting [blah]…’ ☺
<lechner>okay, i see it now. the links are inaccessible due to my encrypted home folder, like /var/guix/gcroots/auto/i6rg9dk20y8adm461cswksgaz484ppr5 -> /home/lechner/.cache/guix/profiles/jwt4sykgzzw7tmj7dolpvvg27ucpv237pod3pe45jenndezneb6a
<lechner>i am logged in, but as is customary for FUSE, root does not have access
<nckhexen>Well, let's not debate that notion of security. What matters is that it could lead to Guix not seeing certain roots, I think, since it could consider those links deleted (vs. ‘unreadable’, I don't know & didn't check if it treats that differently).
<Kabouik>rekado: I think removing is indeed not a big deal, the function already does wonders. But when hitting such incompatibilities like I did, it's not straightforward that guix.install() cannot uninstall, and remove.packages() does not know about what guix.install() did, and hence the uninstallation has to be done in Guix itself. A remove option could make sense so that all package management is done with guix.install() (and perhaps it should clean the
<Kabouik>.scm file accordingly when removing something?)
<nckhexen>Back to my previous point: this isn't a bug in Guix, but it's a… gotcha. Guix allows you to specify any file anywhere as a GC root, but the deal is that that file must remain visible to the daemon. It seems like clever modern stuff like this might make that fundamentally impossible, and we'd have to move all roots to /var/guix/ (no intermediate links) to be safe.
<nckhexen>And ‘not a bug’ sounds rather subjective if Guix just deleted all your stuff :)
<nckhexen>lechner: What kind of encryption do you use? Is this on Guix System (yet? ☺ probably not…)?
<lechner>nckhexen: i just ran 'home reconfigure' again to be safe
<nckhexen>lechner: An is there an option to make those files root-readable that we can suggest until this has been investigated?
<lechner>it would also be helpful to run sudo guix but referring to my own version of guix. i am currently working on some ideas for FUSE based on the effective/real UID but that would not solve the daemon problem
<nckhexen>I don't think that sudo would help, or you'll have to explain how it would.
<lechner>i have not been successful in packaging gocryptfs and could use help from someone with experience in the golang build system
<lechner>to reconfigure the system without 'deploy', the advice in the manual says to 'pull' as the user and then run 'sudo guix system reconfigure' but that does not work on my system (or does not use my guix, i cannot recall). either way, i have to pull as the root user, which complicates system management a little and run 'system reconfigure' as root
<lechner>as for gocryptfs, i maintained it in Debian for five years and, being friendly with the creator, hope to effect some positive changes there, i.e look at the real uid too
<nckhexen>(We already ‘patch’ sudo's default configuration from most other distributions by defaulting to ‘-E’ instead of ‘-i’, exactly to make this regular-user-guix magic work, in normal circumstances, but that's just using a well-understood upstream option.)
*nckhexen has simulated your problem, got the ‘cannot read potential root’ warning, but guix gc is silently taking forever—it did finish for you, right?
<nckhexen>…and just as I hit return, it starts deleting.
<nckhexen>…and it deletes the invisible potential root, dammit.
<lechner>nckhexen: did it delete the current home generation?
<nckhexen>(◍•ᴗ•◍) Thank you for reporting this bug, and giving enough details to make me suspicious.
***jonsger1 is now known as jonsger
<nckhexen>I might be jumping the gun, but I don't see how current Guix can be compatible with this permissions model. Something will have to give, or be adjusted.
<lechner>nckhexen: doesn't the issue also exist with automounted homes? what if someone else runs gc?
<nckhexen>This effective uid thing is a whole separate problem.
<lechner>btw, i do maintain another per-user folder under /acct/ that holds static data expected to be around when the user is not logged in, like for ssh. maybe that would be a better place for the user roots
<nckhexen>lechner: I don't know, I've never tried or considered that. Maybe as root, yes. Not as regular user.
<lechner>nckhexen: mv gc won't catch your deleted roots?
<nckhexen>My first thought is to just move everything to /var/guix (it already has per-user subdirectories).
<nckhexen>lechner: mv will invalidate roots, yes, they are tracked by name, and if (any component of) the name changes, they are dead. That would be an example of the ‘don't do that’ use case I meant above.
***TopExpert is now known as Glassfish
<nckhexen>lechner: Would you mind opening two bug reports for the ‘cannot read’ and broken-sudo bugs? Maybe somebody will reply with an obvious fix and we can all relax :)
<nckhexen>I could, but it would help if you could describe your real-world set-up vs. my fake deliberately broken one.
<lechner>nckhexen: yes, i'll be back here in twenty minutes to discuss details if you are still around
<nckhexen>I'm afraid not, that was meant as something of a closing remark I'm afraid. I have to go.
<nckhexen>I might be back tonight CEST, but can't say. TTYL!
***Glassfish is now known as NormalPerson
<rekado>Kabouik: not sure if it should remove the package definition on removal. This would be tricky to get right. We’d have to make sure that the definition is not used by anything else in the module.
<lechner>nckhexen: when you see this, why is there a bug in sudo?
<Kabouik>Exactly, that's why I put that in the form of a question actually rekado. If a user had to tweak the defintion a bit, they would probably not want to get that cleared when uninstalling either.
<jab>well looks like I need to dive into my opensmptd records and use (guix diagnostics) for all the error messages...
<nckhexen>lechner: Like in Guix, there is no outright bug in sudo, just conflicting requirements. When you (literally: you) type ‘sudo COMMAND’, it looks up COMMAND as root. But COMMAND is in /home/you, which root can't see, so it keeps walking $PATH and finds the wrong COMMAND (here, root's guix). The ‘sudo $(realpath $(which COMMAND))’ looks up COMMAND as your user first, and dereferences the symlink in /home/you to a file name in /gnu/store, and only
<nckhexen> *then* is sudo invoked with that absolute /gnu/store file name, which it can see just fine.