<PotentialUser-52>Hi Guix! I recently reinstalled and ran a "guix pull". guix now appears to be rebuilding the world (things like emacs and ffmpeg and flac), even though those aren't in my config (using the default config + zsh, no extra packages or services, %base-services)
<PotentialUser-52>I'm guessing this is because of the default imports? Any way to avoid this?
<drakonis>its rebuilding because its in your profile?
<PotentialUser-52>ohh I think I know what it might be... I used a manifest as my user... but canceled the install (intending to install later)... so maybe the guix pull is finishing that?
<jackhill>hmm, `guix pull` should really only build the guix tools proper (and their dependencies). Is that the only command you ran?
<PotentialUser-52>I did a guix pull and then a guix system reconfigure /etc/config.scm... not sure which one it's on now
<jackhill>Also, if you enabled substitutes, it shouldn't be nessisary to rebuild everything (alhtough if you don't want to use sustitues, that's a resonable choice but will require building).
<jackhill>PotentialUser-52: ah! it's the reconfigure. I bet those are part of your operating system definition. So the question is why they are if you didn't mean them to be. Can you paste your config somewhere? (e.g. https://paste.debian.net)
<PotentialUser-52>I don't have curl installed right now.. can I install when the other one is going? otherwise I can describe it.. just nss-certs + %base-packages, and dhcp + %base-services, then zsh for my user's shell.. and some kernel params (nomodeset), and that's about all that differs from the minimal install
<lfam>There are some good tools in Guix for examining dependency graphs, both "up" and "down"
<lfam>It would be great to avoid using root here but for now it's the best option to isolate the build users. Unprivileged chroot / containers are not really an option in gnu/linux yet
<oriansj>PotentialUser-52: well it is possible to not depend upon guix's generated profiles but people generally warn against it as you'll be forced to manually update to keep up with guix changes
<PotentialUser-52>I think I'm going to try to get startx to work.. because of the recent gdm bugs (it wasn't starting for me and there was a discussion in here I think w/jackhill) about those.. ideally wanna sidestep any extra complexity.. especially that prone to breakage
<PotentialUser-52>lfam: so eventually it won't even need to be run as root? I take it running guix commands as an unprivileged user uses the root daemon (there's only one, right?), but (theoretically) doesn't have privilege escalation issues or anything like that.. right?
<oriansj>Speaking as someone who has opted for that route, it only works if you are comfortable feeling dumb in front of other people.
<lfam>PotentialUser-52: If the wide world of gnu/linux ever successfully implements unprivileged containerization features, then guix-daemon will not need root. But currently it's based on chroot and that requires root
<jackhill>PotentialUser-52: well the gdm problem is fixed now, yay! There also are sddm and slim services
<jackhill>lightdm is packages, but I don't se a service.
<PotentialUser-52>jackhill: has it otherwise been pretty stable for you? If so I'll try it out in a vm then use it. I don't really want to figure out startx... but I'd like as simple and stable a system as possible
<jackhill>PotentialUser-52: otherwise yes. I also use gnome-shell, so the integration between gdm and gnome-shell is nice for me.
<PotentialUser-52>lfam: but nothing to worry about as a normal user... right? eventually my plan is to notify users of updates... log in as root to pull those (needed to update the base system... right? or does guix pull as a normal user do that?), then just do everything else as a normal user
<lfam>PotentialUser-52: In general `guix pull` is per user
<jackhill>I can't commend on how it compares to sddm, but a nice thing about gdm is that it knows how to run the xserver as a non-privledged user. IIRC other display managers don't
<PotentialUser-52>sddm seemed a little complex for my liking... and froze in a vm, which I didn't take as a good sign (it was virtualbox though.. so maybe that doesn't mean much)
<jackhill>Oh, and the nice thing about guix, when the gdm problem cropped up, I just rebooted into my previous system generation until it could be sorted.
<PotentialUser-52>jackhill: so I'd run gdm as root in the services list... but could install (e.g.) gnome-shell as my normal user and go from there? that'd be great
<lfam>PotentialUser-52: So, each user can control their own profiles by doing, for example, `guix pull && guix upgrade`. But the "system" stuff needs root to do `guix pull && guix system reconfigure /etc/config.scm`
<PotentialUser-52>jackhill: I was wondering about that... that is super nice. I've definitely ran into breakage on other distros where that wasn't the case
<PotentialUser-52>lfam: got it. if I haven't changed /etc/config.scm... is guix pull enough to update? or should I still reconfigure? as you can tell I'm new to this... but I feel like I have the basics mostly down
<jackhill>PotentialUser-52: I have gnome-desktop-service installed system-level as well. I'm not sure how gdm finds which sessions it knows how to start/if it would find gnome shell if it was installed only as your user.
<jackhill>That sounds interesting, I should figure that out.
<lfam>PotentialUser-52: It's okay :) What distro are you coming from?
<lfam>You can think of `guix pull` as kind of like apt-get update. It basically updates the list of available packages, as well as the `guix` and `guix-daemon` commands. Then `guix system reconfigure` rebuilds the system-level stuff, whereas `guix upgrade` updates the packages the user has installed
<PotentialUser-52>ohh so would I `guix pull && guix upgrade` as root if I haven't changed /etc/config.scm? reconfigure to me feels like saying "I changed stuff... make it happen", not "update it for me"
<lfam>Not exactly. Each user can install their own packages that only they see. But there is also software running at the system-level. `guix upgrade` handles the user's packages, `guix system` the system stuff
<lfam>Work is not really "assigned" like in Debian
<PotentialUser-52>oh, another question I haven't found the answer to yet: do all guix packages sort of follow the same philosophy re features? e.g. enable everything or minimalist, or is that kind of all over the place?
<oriansj>PotentialUser-52: expect to be treated as an adult
<oriansj>No babysitters but there are nice and helpful people
<PotentialUser-52>oriansj: I appreciate that, though it probably means different things to different people. it's been awhile since I've used debian/ubuntu... but found those packages too heavily modified for my liking
<lfam>I think a lot of people in Guix feel that distros are not the place to do feature development in packages. We may package forks but they should be maintained independently from Guix
<oriansj>PotentialUser-52: there is no package in guix, you can't in 30 seconds modify to do something different
<oriansj>(if you take responsibility for that work)
<PotentialUser-52>is there any effort to avoid using (for example) too many different versions of gcc-toolchain (i.e. once something is updated... does guix try to move things towards the new version to avoid lots of different versions of the same package?). my gut says this is the wrong move, but I can't totally explain why. by new version I mean same version but d
<drakonis>that's easy for someone already using it
<apteryx>in any case, the error 'guix deploy' gives me ATM is: Throw to key `srfi-34' with args `(#<condition &store-protocol-error [message: "creating directory `/gnu/store/nix-18553-0': No such file or directory" status: 42] 7f38c61ecc90>)'.
<vagrantc>but yeah, an "official" live image would be nice
<oriansj>could someone please add an option to guix challenge to not download the binaries to determine the diffs; instead just show the different hashes
<vagrantc>i'm pretty sure that used to be the default behavior, and i didn't think the new --diff feature was default
<apteryx>anyone knows how to refer directly to /gnu/store items when booting the Guix installer image? The actual /gnu/store directory contains nothing.
<apteryx>OK, could understand how overlay works. There is a lower dir which gets shadowed by an upper dir. The lower dir when running cow-store is empty, everything gets written to the mount point that was passed as an argument to the cow-store service.
<apteryx>the cow-store service doesn't exist in my deployed image, so as it transfers its shepherd config and attempts to start it the cow-store service gets removed and stopped, which breaks access to /gnu/store IIUC.
*apteryx tries again to 'guix deploy' to an Guix installer target, without having enabled cow-store.
*apteryx gives up 'guix deploy' to installer running target and uses 'guix system init config.scm /mnt' directly.
<kirisime>Would it be possible to move a process into a guix environment by calling setenv from it with data from some guix interface?
<kirisime>As in, my ASDF system required libGL, would it be practical to write a simple ASDF helper that changes the lisp's environment to include the mesa package?
<leoprikler>What's with all the people wanting to hack environment variables into running processes lately?
<kirisime>Such a thing would be a bad idea on conventional systems where allowing a language package manager to interact with the system package manager in order to fetch native libraries would imply the language package manager needing or having the privilieges to modify the entire system but since that's not a concern with guix I think it could be done for great benefit.
<kirisime>leoprikler: It's a thought I had a long while ago but only now came to actually need.
<leoprikler>Is starting your asdf system in the right environment not enough?
<kirisime>leoprikler: It's the difference of having (setq inferior-lisp-program "sbcl") versus having a (setq inferior-lisp-program "guix envionment --ad-hoc dependencies -- export LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib && sbcl") or starting the lisp with such a command line every time you start one.
<leoprikler>okay, first things first: collect your dependencies into a package or a manifest
<kirisime>It doesn't even seem practical anyhow as according to dlopen's man page the $LD_LIBRARY_PATH needs to be defined at the time the program starts so hacking it together with the environment won't do.
<kirisime>leoprikler: It's also about possibly having the perfect system counterpart to loading systems with quickload on a whim.
<leoprikler>secondly, you can do guix environment --ad-hoc stuff -- emacs and then no longer worry about it
<leoprikler>plus emacs should already allow you to setq-local some variables to make things easier
<leoprikler>so in the worst case, you can set inferior-lisp-program to a wrapper script at the project root
<kirisime>I can also write myself a stupid little thing that extends the *foreign-library-directories* variable according to the package outputs from guix.
<wingo>hey! is it possible to use flatpak with gnome?
<wingo>i have the weirdest problem with my gobby from guix that it disconnects sometimes, and for some reason the flatpak that work publishes works and guix's doesn't
<wingo>but when i go to 'flatpak install gnome org.gnome.Platform 3.22' it fails
<raghav-gururajan>Cool, then you should also use '--user' for `flatpak install` and `flatpak run` commands.
<kmicu>pkill9: when we don’t GC, everything is pinned in the store. I know that’s a silly notion but e.g. creating a wrapper shell script called ‘icecat’ which invokes /gnu/store/hash/icecat gives us a pinned icecat 😺
<wingo>"flatpak install" seems to work fine without --user fwiw
<apteryx>I think if we don't use cow-store, nothing will get written to the actual drive, making the installation pointless. But cow-store is problematic with 'guix deploy', which has no knowledge of the actual, rw partition being mounted at e.g. /mnt instead of /. It's probably fixable by some remounting magic but I was too tired to keep investigating.
<apteryx>when you run 'guix system init config.scm mount-point', the last argument tells it where to install the files (e.g., /mnt), which is why it works.
<leoprikler>Correct me if I'm mistaken, but does 'guix deploy' not rely on an already existing guix installation (or some other infrastructure to make one)?
<waynedpj>is it possible to share the /gnu/store between Guix System and other Guix instances running on other installed OSs on the same machine? e.g. create a Btrfs subvolume for /gnu/store/ that is mounted for each OS. thanks.
<thomassgn>after upgrading emacs and removing emacs from my OS config (it's now only in my user manifest) I get a ton of errors like this "Warning: Lisp directory '/home/ton/.guix-profile/share/emacs/site-lisp/guix.d/ag-0.48': No such file or directory" for different modules it seems. It looks like most of them exist in /home/ton/.guix-profile/share/emacs/site-lisp/ though. Anyone know what's happening here?
<pkill9>worked out the issue, i imported (guix build download) instead of (guix download)
<daviwil>thomassgn: Within the last few months, EMACSLOADPATH logic has changed such that the guix.d subpath has been eliminated. you might check your EMACSLOADPATH to make sure it's not still referring to outdated paths
<daviwil>now .guix-profile/share/emacs/site-lisp has symlinks to generated autoload .el files
<daviwil>Ahh, that last part is wrong, it's symlinks to the actual package .el files
<lfam>Which package module should hold a QR code library?
<apteryx>leoprikler: you can describe what kind of "environment" the target is. Currently there exists only two supported environments, "managed-host-environment-type", which is a system reachable through SSH which already has Guix installed, and "digital-ocean-environment-type", which is for a VPS from that provider.
<apteryx>perhaps we could implement a new environment "guix-installer-environment-type" that would know the peculiarities of the Guix installer image (such as overlays used).
<apteryx>but I'm not sure this is a common enough use case. It was easy enough to 'herd start ssh-daemon', edit my config file there using Tramp in Emacs then issue 'guix system init my-config.scm /tmp'.
<lfam>I just set up a new server on digital ocean, it would be great to manage it with Guix
<daviwil>Side question, anyone actually using the digital-ocean-environment-type? I was looking to set up a Guix-based VM there but found conflicting info about the setup process, wondering if 'guix deploy' actually works there
<apteryx>well, to be fair, I had ^C it before restarting it then attaching (my bad), so this is happening while the message "substituting /gnu/store/4q1ffvk79np2jhaqbwfjczml5m4lgdlf-libpthread-stubs-0.4..." is print.
<apteryx>thomassgn: interesting. maybe you are using a fixed font? FWIW, I use the 'font-hack' package and put this in my ~/.emacs to configure the size: '(default ((t (:inherit nil :foundry "SRC" :family "Hack" :height 110))))).
<apteryx>err, (custom-set-faces ...) should encapsulate the above snippet
*apteryx finally resurrected a 14 years old machine to offload some builds to (Core 2 Duo Q6700, 8 GB RAM).
<thomassgn>it seems it doesnt find the fonts or something. Maybe another fontcconfig issue on my part, maybe a reboot would solve these things... :)
<apteryx>thomassgn: Are you running in a pure environment? Fonts may need some globally set environment variable to be found (unless you install the package responsible to set the search path in your environment itself).
<daviwil>thomassgn: I and others have hit this issue when using Emacs in a separate manifest. The solution for me was to add a fontconfig that includes the font path in the other profile where I install them
<daviwil>Alternatively you can install the font in your emacs profile too
<leoprikler>apteryx: I think you replied to the wrong person. You're basically echoing what I said, albeit with an important addition.
<daviwil>Here's what my .config/fontconfig/fonts.conf looks like:
<daviwil>hmmm, completely clean profile didn't fix it
<apteryx>if you are using a manifest or upgrading all teh packages in that profile at the same time, you shouldn't have byte compilation issues (all the emacs packages will be rebuilt against emacs 27).
<bandali>doesn’t that require re-byte-compiling all those packages for emacs 27?
<bandali>afaik, emacs-minimal currently is at 26.3
<bandali>(which is what is used to byte-compile emacs packages)
<leoprikler>bandali: you can rewrite those builds to use emacs-next, although it will trigger some bugs with certain packages
<daviwil>apteryx: Yeah, I think this must be an elisp loading issue of some sort. I'm hitting the max-lisp-eval-depth when I load my configuration and then have strange behavior from packages like Ivy. EXWM also fails to capture focus correctly when it starts. I think something unexpected must be happening when loading packages in the profile
<bandali>leoprikler, ha, rewrite them to use emacs-next instead of emacs-minimal?
<tigre200>Hello. I've just installed Guix with the GNOME desktop and am trying to configure the keyboard. I have a portuguese keyboard, but none seem to have the keys in the correct place. Is there a program to detect the correct keyboard configuration?
<mbakke>hmm, civoduls the gdb patch caused a huge rebuild, I wonder if we should revert it