***califax_ is now known as califax
<char[m]>kiasoc5: Hello, does gnome-shell-extension-clipboard-indicator version 42 work for you? What gnome version are you using? <char[m]>I have the same question for lilyp about gnome-shell-extension-vertical-overview version 9. <char[m]>I had to do a system reconfigure to update gnome-desktop. Thanks to both of your for updating those packages. <lechner>Hi, should /etc/guix/ have the octal permissions 0555 instead of the unsual 0511? <brendyn>unmatched-paren, ive been using the native-comp version for a long time now. it was on the flatwhatson guix channel <flatwhatson>my channel is a bit outdated now, as the main guix emacs package has native-comp enabled <brendyn>and then i switched again to emacs-next (emacs 29). it apparently performs better with long lines. i want to see if it handles geiser repls with lots of output. <lilyp>char[m]: I didn't update all extensions to 42, there are some I missed ***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@2001:470:69fc:105::2:a0b1
***antoniotraderbtc was kicked by litharge (You are banned from this channel)
***litharge sets mode: -o litharge
<efraim>which package has dig? I can't remember <cbaines>efraim, the utils output of bind I believe <efraim>I always try to check isc-dhcp instead <cbaines>by the way efraim, have you caught up with the state of rust on aarch64-linux post staging merge? <cbaines>I believe it was working pre-merge, which was great, but there are mrustc problems now with building rust on aarch64-linux <efraim>I haven't yet but I can take a look at it <cbaines>that would be great, I've only been looking in to it from the perspective that this was hard to spot in the Guix Data Service comparison <efraim>I have to admit when I tested my changes to the rust bootstrap I tested on riscv64 and x86_64, I just assumed it wouldn't break aarch64 <cbaines>right, from the brief look at some issues on the upstream mrustc repository, it seems that there might be some ARM specific problems <pkill9>so how would you go about adding file lists to the guix data service? <cbaines>pkill9, I have thought about this before, the Guix Data Service does already figure out when substitutes are available, so it could fetch them and index the contents <cbaines>this isn't on my short term TODO list, but I'm more than happy to try and help others implement it ***Dynom_ is now known as Guest8855
***wielaard is now known as mjw
<sektor[m]>Is guix-style meant only for package definitions? <civodul>sektor[m], nckhexen: it can also handle whole files with '-f', but it still needs fine tuning to give good results <civodul>you can give it a spin though and report back :-) <nckhexen>(Whole files of package definitions, though.) <nckhexen>No reason it couldn't handle anything in time. <civodul>whole files of arbitrary Scheme even :-) <civodul>the use case i had in mind was System or Home config files <civodul>it's a good way to detect mismatch parens for instance <nckhexen>Heh. I got a bit too excited for a second, but it detects them all right. <nckhexen>base.scm:1468:1: unexpected end of input while searching for: ) <civodul>i said "mismatched" though, not "missing" :-) <nckhexen>civodul: I'd appreciate if you could explain the difference, rather than just repeating it. <nckhexen>I just tried everyone's favourite error reporter, Racket, and it uses indentation as a hint (possible cause: indentation suggests a missing `)` before line 34), interesting. <nckhexen>…but it's not actually that accurate. Hm. <gnucode>sektor[m]: what experimentation would you do? <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>Guessed that there was some issue like that. But where can I find such information? <pkill9>i like the idea of nyxt, I just can't be arsed to learn to use it <gnucode>a12l: firefox suggests nonfree addons, etc. <a12l>Because I don't imagine that the project don't tell its users how to access the web, without providing a web browser? <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? <gnucode>a12l: does searching for "web" help ? <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) <podiki[m]>mbakke: did the librsvg update ever make it to core-updates after it was reverted from master? I don't see it (just build locally as part of updating cairo and it build fine) <nckhexen>itd_: I agree, and that's how I used the term, but seems like it's too subjective to use to communicate. <mekeor[m]>a12l: well, the user should read the synopsis of the packages listed, i guess <mbakke>podiki: it is in core-updates; it builds fine but breaks various packages <pkill9>I have so much to modify in guix <podiki[m]>ah thanks, somehow my search was not going to the right branch <podiki[m]>our cairo is very old, anyone know why? last update was when newer versions were out but it was updated to an older version (1.16 instead of 1.17) <pkill9>i want to develop my guix sandboxing wrapper <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! <noah>@mekeor[m] is that in config.scm? <mekeor[m]>noah: yes, in your system configuration / declaration. <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]>mbakke: anything I should know about grafting cairo? I think we should have 1.17.4 due to security updates. anything I should build locally to check for problems? (cairo affects a lot) <a12l>I'm maybe in a minority, but I would actually accept "Firefox" being an alias for icecat. At least the user would get a web browser that's similar to what they expect :) <Sariboo>Not as a default. Similar is not same <mbakke>podiki: if you can reach things like 'gtk+' and 'qtbase' then the font and graphics stack should be in decent shape <mekeor[m]>a12l: btw, if you don't request a change in this matter on the dev mailing list or won't report a bug, most likely, nothing will change <podiki[m]>could make a "dummy" firefox package or something that just tells people to search for icecat instead :-P <mbakke>I don't know if 1.17.4 can be grafted over 1.16.0 though <podiki[m]>mbakke: I just built icecat with the graft and it worked <a12l>mekeor: I'll start contributing if I get Guix working :D <podiki[m]>the release notes for cairo have bugfixes and a new pixel format support, but didn't sound like abi changes? I'm not sure <mbakke>podiki: you should check that the ABI is stable with e.g. 'abidiff' <mbakke>what are the .so versions of 1.16.0 and 1.17.4 (in the lib directory)? <mekeor[m]>a12l: welcome on board. go ahead and shoot when you run into further problems :) <podiki[m]>libcairo.so, libcairo.so.2, and then finally libcairo.so.2.11600.0 or libcairo.so.2.11704.0 <podiki[m]>where can I find abidiff? tried elfutils but wasn't there <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 🤷♂️ <podiki[m]>they recently tagged/snapshotted 1.17.6 as last release with autotools (moving to meson) but I don't think that's a release <podiki[m]>mbakke: alright. I'll prepare the patch and put these quick notes in the email for discussion. <Kabouik>rekado: I guess `guix remove r-packagename` from out of R <podiki[m]>they call it a "snapshot" on freedesktop gitlab specifically, but then a "release" on the last line .... so i'm confused what they mean <mekeor[m]>noah: hmm, if you haven't installed epiphany explicitely yourself, i guess it has been pulled by some other package as "propagated-input". hmmm <mekeor[m]>noah: what's the result of "which epiphany"? <mekeor[m]>noah: that way you can find out if epiphany got pulled in through your system's configuration or user's package-management <noah>its in my system configuration <noah>./run/current-system/profile/bin/epiphany <noah>btw this is inside gnome boxes <mekeor[m]>noah: i wonder if you can use "guix graph --type=reverse-package epiphany | xdot -" to find out what pulled in epiphany <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. <nckhexen>Verrry roughly: (define my-gnome (package (inherit gnome) (propagated-inputs (modify-inputs (package-inputs gnome) (delete "epiphany"))))) … (operating-system … (services (service gnome-desktop-service-type (gnome-desktop-configuration (gnome my-gnome))))) *nckhexen is out of newlines, send hlp. <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 <podiki[m]>apteryx: I'll submit the 1.17.4 due to what looks like abi changes in latest; but I have code for that too I'll put in the email <mbakke>apteryx: I'd love to get your feedback on 58587 btw :) <apteryx>mbakke: I'll try to review it soon (TM) :-) <apteryx>sneek: later tell civodul in commit 78d55b703d1 (2018), it seems you forgot to update the docstring of (@ (guix scripts environment) launch-environment) ***mark_ is now known as mjw
<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>nckhexen: there really is no context that i can tell (apart of course from the entire declarative environment) <nckhexen>Well, the file name(s), for one. And the command you ran (presumably just ‘guix gc’ as you, but that's the kind of context I mean). <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). <lechner>it was just a pun, actually. i did not mean to make a meaningful point <nckhexen>It should be easy to test: are the links in /home/lechner/.cache/guix/profiles/ now dead? <lechner>no, they exist in my home directory, but those links are dangling! <lechner>so the gc worked, except even when i run gc as my user the daemon in unable to remove either level of the dangling links <nckhexen>Because I'm not sure how to avoid this, if there's no way for the daemon to see the entire file system, or at least the part it needs, which includes that part of /home/$user. <nckhexen>lechner: Ah, maybe I misunderstood. I thought those were (previously) live links whose targets shouldn't have been deleted. <lechner>maybe they shouldn't have. i also did delete-generations in my home environment. which is the link that must exist? <nckhexen>Problem is I'm not familiar enough with home to know by heart how that would play out. <lechner>not a single link survived, it seems <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>nckhexen: i use gocryptfs, and there is <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>i'll show you after this brief point <nckhexen>I've packaged straightforward Gothings but nothing that required wizardry. OK. <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 <nckhexen>‘sudo which guix’ and ‘command -v guix’ should both point to your guix (~/.config/guix/current/bin/guix). <lechner>nckhexen: it does, but FUSE goes by effective uid so my guix is not accessible inside sudo *nckhexen soft oofing sounds. <nckhexen>This method of ~ encryption is going to break stuff, and a good amount of stuff in Guix. <nckhexen>As a work-around for your last point: try ‘sudo $(which guix) system reconfigure …’. <nckhexen>Erroneous. Instead: try ‘sudo $(realpath $(which guix)) system reconfigure …’. <lechner>nckhexen: the point was, i do not want to pull twice! <podiki[m]>apteryx: (re: fhs landing) thanks! onward to peroxide service as my next big submit <lechner>nckhexen: maybe sudo could be patched? <nckhexen>Mmmaybe. Seems like the tiniest sudo move in any direction ends with a CVE patch one month later, and this would be a big move. But I'm not a sudo maintainer, and glad of it. <nckhexen>I am convinced that it is not a risk we should carry as a distro patch, sorry. <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>But it deleted the target of the root symlink, and it is now dead, and all its packages. <nckhexen>If I were using this root for real? Yes, I'd be hosed. <nckhexen>I get your point now, but it's still bad. <lechner>thank you for simulation. you are a treasure of this channel <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 s/one afraid/is enough/ <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. *nckhexen away again though. <itd_>lechner: Can you please also share the golang error message?