<mirai>How does this #:search-path argument work for build-systems
<mirai>setting it to some value unfortunately erases the typical GUIX_LOCPATH, ACLOCAL_PATH and other search-paths
<mirai>is there no way to append a search-path specification into #:search-paths?
<makx>maybe this is an insanely stupid question, but, I am trying to define my own image and want to add a home partition; the initializer for this partition doesn't need to do anything, but the default seems to be "put root filesystem here";
<Guest34>Isn't something like root and file permissions useless on a computer that is used by only one person? Does Hurd have something like a root user as well?
<mirai>Guest34: not really, suppose you have a program that due to some programming mistake does a rm -rf /usr
<mirai>or you're opening some document-sent-by-asshole.docx that triggers some malicious exploit and starts siphoning the memory contents from every program (including $browser where you're doing some banking operations)
<mirai>clearly you'll want some way to segregate how the programs interact, even if you're the only user of the computer
<Guest34>Okay so for the first message, this would be handled by file permissions I assume. Not by a special user. The second is something else isn't it? That is memory address space
<mirai>memory space is one possible avenue from many others
<Guest34>Basically my main question would be, are those things invented for pcs system or implementations from mainframe times and compatability
<mirai>said exploit could be a webserver that starts reading the contents from $HOME/Documents (where it has no business)
<mirai>that's why things like selinux got invented
<Guest34>Ah okay, good to know. I read that hurd uses the hurd filesystem. This is not something like ext or btrfs but more like a translation layer for an actual filesystem or did I understood that wrong?
<bjc>hurd uses ext2. the translators are a layer on top of that
<nckx>For (random) example, I have /gnu/store/r14adwd69sns9zyhkrxlspmxbs3wiswy-hplip-minimal-3.23.5-ppd .
<gcarlos>so this meas you have the output ppd of hplip-minimal installed?
<nckx>That's ‘clearly’ the :ppd output once you know how Guix names things. It's not unambiguous—you could create an ‘hplip-minimal’ package with version ‘3.23.5-ppd’ and it would look exactly the same, but it's a very good heuristic.
<Guest28>How is decided if something should be a system service or a home service?
<bjc>context? but you don't necessarily have to pick anymore. ludo added a system → home service transformer
<bjc>not that you ever *had* to pick, but now you don't have to write it twice
<nckx>gcarlos: There might be a way to get this in Guile code but (1) you won't be able to run it on arbitrary existing profiles, only ones that your code builds at run time (2) it probably won't be simple (3) I'm not sure if there's a place where all packages are present as package objects at the same time.
<nckx>So, if your use case is anything close to idle curiosity, I'd say stick with ‘guix size’.
<nckx>Also, ‘why my profile so chonky what to remove’.
<Guest28>"but someone else might just argue that for their headless needs, a system “syncthing” service makes more sense (to them)" basically my case, I wish that znc would be a system service instead of a home service. What exactly is the difference? It's like with packages so scope/permissions?
<Guest28>can't they be universal and ultimately be defined as system if they are in a (operating-system ...) definition or (home ...) definition
<bjc>no, home services are strictly for home definitions. system services are, likewise, only for system definitions
<aarcov>Looks like I'll be checking in the morning then, if it doesn't show up, I might need to change something in my config (although the output reported success (Result: 250) and I got my CC'd copy)
<apteryx>aarcov: normally it's refreshed every 15 minutes, I think
<aarcov>sweet, maybe I'll do another quick check in a bit
<apteryx>are the 504 errors on substitutes because berlin's anti-DDoS mechanism?
<Guest28>nckx: Uhh POWER. IBM machines ( I assume some IBM POWER system?). Do you know about reliability? I heard that IBMs are tanks and HP is the worst. Dell is kinda okayish appearantly. If that dc buys new ones and wants to get rid of some old machines, instead of throwing them away I would take one :D .
<Guest28>nckx: Good night. Going to bed as well, nearly 6am...
<Altadil>PotentialUser-35: yes, that rings a bell ! It’s a package, not a service, so you need to add it to the package field of your operating-system declaration
<PotentialUser-35>I have guix system with i3, but I am not sure how to configure autologin. The reference materials seem to talk about gnome-desktop-service or tty login, but I am not sure either of those is correct. I am just looking to autologin my user into i3. Any ideas? Thanks
<jpoiret>PotentialUser-35: auto login through which DM/greeter?
<PotentialUser-60>I tried to install triquel through net installer it showed console desktop environment. Can anyone please explain about console desktop environment I have never heard about it and i could not find any link/ webpage about it?
<jpoiret>PotentialUser-60: this is #guix, not #trisquel
<ardraidi>I have a question about licenses of a package
<ardraidi>It's supposed all the licenses in all the files in the package, right? For example, if I grep the repo and find 5 licenses or so, they're all supposed to be mentioned.
<next4th>ardraidi: i want to ask it too, yes i think all should be mentioned.
<apteryx>ardraidi: I like to think of the license field as the license of the whole project as it's distributed in Guix; for example if most of the project is GPLv3+ but there are some files marked as BSD-2 or other lesser licenses, then the effective license is GPLv3+.
<apteryx>(it could have also been a list of licenses with the detail in comments, but that's uninteresting and potentially misleading in the Guix UI: 'guix show $package' would show all licenses, I think)
<ardraidi>apteryx: Interesting take. I thought that might be the case, but I guess there could be legal implications, which I know nothing about.
<ardraidi>For example, the files might be considered effectively re-licensed. Not sure if that's a thing. I remember reading in passing that the Linux kernel has things with licenses other than GPLv2
<efraim>I've thought about it on and off for a few years, to keep some mapping about which licenses conflict with others and which subsume (is that the right word?) other ones to return the One True License™ of a package, or if it is FORBIDDEN
<efraim>and then I decided that it was a terrible idea
<efraim>well, not terrible, but very involved, so probably good, but full time work in itself
<efraim>we should probably add aliases to the end of the bashrc file, not to the top of it
<efraim>or we should place the guix-defaults? output at the top
<jab>efraim, nckx guix shell gtk:bin -- sh -c 'GSK_RENDERER=cairo gtk4-demo' worked for me.
<efraim>jab: I added GSK_RENDERER=cairo to my .bash_profile on my pinebook pro
<efraim>civodul: I'm testing it on a few architectures to make sure it builds
<efraim>civodul: it already has lapack as an input so it'll be hard to add it as an input to lapack also :)
<efraim>i'm also curious if there are bundled libraries, one of the folders is src/map/common/lapacksrc
<ardraidi>So (combined-work ...) is basically a codified lawyer? I guess even GuixGPT would struggle with that. However, I think a feature in 'guix lint' that detects known license texts in the source code and shows messages about them might be useful.
<civodul>not completely satisfying, but we need the fix
<nckx>We don't need to delete it to fix the failure.
<nckx>And this is the most trivial failure of them all.
<nckx>I'll accept that the tests run in diverse environments, and that this can be a feature, but I'm really not wild about not being able to assume that our own test-env state directory isn't even clean.
<civodul>fun fact: the on-line manual isn't getting updated because doc/build.scm refers has been updated to match the latest texlive changes, but the mcron job refers to the current 'guix' package, which is incompatible (some variables have different names, etc.)
<lispmacs[work]>hi all, I'm trying to compile some code that is looking for "gnome-doc-utils". Which guix package would that correspond to?
<bjc>civodul: i was going to object to it on the grounds that there's more than just $DISPLAY. things like $DBUS_*, or $XDG_* (specifically, $XDG_SESSION_TYPE), but on reflection, i think we can extend ‘home-dbus-session-type’, or the various other session types that set those variables to do something similar
<bjc>fwiw, wayland is straightforward: just wait for $XDG_RUNTIME_DIR/wayland-$num, and that's your value for $WAYLAND_DISPLAY
<bjc>i am marginally worried that this will make starting services more brittle, but that may just be fud talking
<civodul>bjc: i'll leave it up to you to propose a follow-up patch for Wayland then :-)
<civodul>"brittle", hopefully not; at least it will make it clear why services are started or not
<efraim>civodul: I'm running sway, I have the /tmp/.X11-unix directory (with X0 and X1 sockets) and a socket at /run/user/1000/wayland-1
<bjc>on reflection, for x, it would be problematic if you have multiple displays, like if you're using x forwarding for ssh
<bjc>not sure how much that impacts wayland, since that's not possible remotely, but locally, i *think* you're allowed to have multiple seats all with their own sockets
<bjc>say i've logged in twice, with a full login shell, with ssh+x-forwarding. there's no way to determine which display gets used in shepherd. moreover, i may want a full session on both, and that will definitely not happen
<bjc>does home-shepherd even support multiple simultaneous sessions?
<lispmacs[work]>is gnome-doc-utils something that still needs to be packaged, or part of some other package?
<akonai_>Wouldn't that x11-service cause problems for hypothetical display-server agnostic services? Since you'd need one version that extends x11-service and one that extends an equivalent wayland service.
<civodul>akonai_: i think you're right, but i'm biased towards incremental improvements here :-)
<civodul>if/when we encounter that situation, we can look for a better solution
<akonai_>you could make both x11- and wayland- services provide a generic 'display service (with the caveat that some services wouldn't extend either)
<akonai_>(or handle wayland and x11 in the same service rather than different ones)
<civodul>it's not super satisfying in terms of process because interested users typically can't learn about pending removals
<civodul>(not unless they're actually following guix-patches)
<bjc>hmm. might be nice to add a ‘:deprecated’ field or some such to services and package definitions
<elpogo>speaking of informing users about issues with packages, is there some flag i can add to guix that'll make it check if the profile/shell i'm about to create/enter might have any packages that are now known to be compromised?
<bjc>iirc there's a ‘guix lint’ option that'll check for cves, at least