<rndd>i'm getting this error "gcc: error trying to exec 'as': execvp: No such file or directory" when trying build my test program using trivial build system. i checked, as is presented in gcc-toolchain. and i included this package in inputs. maybe somebody had same issue
<roptat>No such file or directory might mean that 'as' is not in $PATH (trivial-build-system doesn't set any I think), or that one of its dependencies is not found
<the-catster2>I've been trying to setup EXWM to launch from GDM for the past many hours, and have made no progress. I installed minimal Guix originally, but later added the GDM service. I don't know if I'm supposed to add something to my main manifest, or if there is a package for the .desktop file, but I have had no luck in launching it. I have tried just from
<the-catster2>xinit, where it works but I cannot pass in any keyboard input, or from a custom .desktop, but I don't think that was picked up. Is there documentation for this, or what is the recommended method?
<MysteriousSilver>Hi! Tried using guix to manage third party elisp in emacs. I tried adding `~/.guix-profile/share/emacs/site-lisp` to load-path but emacs returns this error: http://ix.io/3n42 . How do i fix this?
<irfus>command-line transforms + the new --export-manifest functionality is so great for a guile-learning non-programmer like me! Thank you all who worked on this!
<MysteriousSilver>Hi! I ran `guix gc`, now why does guix reinstall stuff like curl, git, glibc, py etc when installing new packages?
<eyJhb>I would assume that. gc does not "often" remove too much, it only removes the stuff that isn't actice or does not have a gc root (I think it is called). At least that's what NixOS does, and I don't think they differ in that point.
<leoprikler>gc removes stuff, that's not reference, which affects many native inputs
***apteryx_ is now known as apteryx
<leoprikler>For instance, git is often only used to download packages, so it can freely be collected.
<eyJhb>leoprikler: but won't it still be in the store, as it most likely will be a dependency of some package somewhere?
<eyJhb>Coming from NixOS, I don't think I can get rid of git even on a base install.
<leoprikler>tbph I don't understand all of it either, at least libgit *should* be referenced somewhere
<davidl>Hi, I have installed gnome-passwordsafe on a foreign distro and can't get the window buttons to show properly. I have followed the application setup instructions but it has not fixed it. What can I do to troubleshoot the issue?
<davidl>Basically everything else works great, like I can run an xfce4-session etc, but some of the application buttons and the window buttons just won't show up.
<cronopio>hi, i recently installed guix on a clean ubuntu install
<cronopio>and i'm following this guide to set everything up
<tissevert>that's a question to ask Ubuntu : ) but I bet it will (there are usually post-install hooks in .deb packages that enable services in the distro's init system, you can check it afterwards by checking in systemctl — I assume ubuntu uses systemd, right ?)
<fnstudio>hi guix, i'd like to try and speed up the upgrade process by pinning texlive (2.6G) to its current version
<fnstudio>the idea would be to still upgrade texlive but on a slightly less frequent basis
<fnstudio>is there a recommended way of doing this?
<cronopio>davidl: the guide begins with the command «sudo sed -i 's/root/alice/' /etc/systemd/system/guix-daemon.service», but being ubuntu, should i change 's/root/alice/' for '/home/alice/' ? (where alice is my user name, obvs)
<tissevert>fnstudio: I don't know if that's exactly your use case but for «heavy» packages which latest version I don't always need, I install them «manually» with `guix package` instead of having them in my system's config.scm
<tissevert>that way they're not a burden when upgrading, and I can guix weather before upgrading my user packages to check there is a substitute, or at least to get a rough estimate of what time it should take
<davidl>cronopio: I don't understand why you would need to do that. You can just open /etc/systemd/system/guix-daemon.service and replace the word root with the word alice manually.
<cronopio>ah, i was just following the guide as literally as possible
<cronopio>but there's no 'root' word in my guix-daemon.service file
<davidl>cronopio: ok, well, regardless of what name was in there before, make sure your user's name is in there on whatever line you think root was on before.
<davidl>maybe you can paste the content of guix-daemon.service on paste.debian.org and paste the link to it here?
<tissevert>yeah, very simply I created a git repos where I put a file config.scm for my whole system and user-packages.scm which is only a manifest
<tissevert>and, when I feel like it's time to update the system I `sudo guix system reconfigure config.scm`
<tissevert>then, from time to time, if I'm curious about a new version on chromium or libreoffice (the two big shots for which I'm doing this, but my manifest also contains my dirty local packages that aren't ready / relevant to share), I `guix weather -m user-packages.scm --display-missing`
<tissevert>and if the output shows chromium and libreoffice have substitute, then I upgrade
<fnstudio>tissevert: cool, very interesting (any chance that repo is publicly available, if i may ask, or maybe any similar solution that you took inspiration from?)
<tissevert>the real repos I'm talking about is public, but it's published at the lab where I work under my legal name which I do not intend to link with my online identity (and I've seen user-packages.scm hasn't been committed yet, shame on me)
<tissevert>so anyway there wouldn't be much additional value if you already know what a config.scm is supposed to look like
<fnstudio>tissevert: that makes perfect sense, no prob, that's already of great help
<tissevert>as for the manifest, it's simply the output of guix package --export-manifest
<fnstudio>tissevert: this will make my upgrading process much better and less painful, thanks
<apteryx>civodul: Hello! It seems Makefile.am:716: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS gets printed everytime one touches the guix.texi manual; perhaps recursive make to avoid this warning is not that bad after all?
<roptat>fakhri, I would reboot, something's wrong with the shepherd on your system (I mean it should still be running or you'd have gotten a kernel panic, but its socket disappeared)
<djames>Looks like my fresh install of Guix hangs at Grub -.-
<fakhri>I did reset and reconfigure several times, still the same situation! yes, it's just a warning in reconfigure but after that nothing work! I get an error for the herd status command
<apteryx>fakhri: I think I've had that once. Perhaps a reboot could fix it, as roptat suggested?
<MysteriousSilver>Hi! Installing a 500kb binary package took like 7mins on a 5yr old hardware, is this expected? Running guix on a non-guix GNU/Linux distro.
<djames>I tried installing from the current ISO and this install hangs at Grub too
<apteryx>MysteriousSilver: do you have many packages already installed? The cost of creating a new profile increases a lot when the profile is big.
<drakonis>i mean that its a flag that only works on nightly builds, it isnt provided if you're not in the nightly channel
<roptat>depends what you want to update. for your user profile, no sudo required
<drakonis>gonna try and build the python package real quick to check it
<apteryx>is anyone having problems building disarchive 0.2.1? I have this derivation that fails; it's pulled by my operating-system declaration, and is *not* the same derivation as that of disarchive on master (not sure why that is)
<roptat>in case you didn't see, are you running the installer ISO?
<nckx>hwpplayer1: (guix-)install.sh is for installing Guix as a package manager on an existing installation of a ‘foreign’ distribution. It cannot directly install the Guix System. That's a totally different process, automated by the ‘installer’ that should start when you boot the installation ISO.
<hwpplayer1>could you please send the distribution install script https address again ?
<djames>Does anyone else here have issues installing an encrypted Guix install? I've tried both manually installing and doing the "graphical" installer. When doing an unencrypted install the OS boots fine.
<terpri>i don't hate it (and obviously use it), but i think it's unidiomatic for a gnu/$foo distribution (i even preferred GuixSD since it's reminiscent of FooBSD, and obviously distinct from running it on a foreign distro)
<terpri>it reminds me of apple's old System $n$ convention, actually
<nckx>This is the Internet, you hate it or you love it but what we won't tolerate is nuance.
<nckx>The only solutions are (a) to send Linus a friendly mail volunteering to rewrite and maintain a frankly revolting kernel subsystem (b) to switch to a userspace console. Maybe this will finally speed up the glacial development of the latter.
<apteryx>civodul: I think my questioning about cross-compiling is this: usually, attempting cross-compilation of a package is requested manually via the --target option; what and where in the case of the Hurd VM images specifies that the target should be i586-gnu?
<merazi>(this time it was not by accident, I swear)
<vivien_>Hi, there was recently an update from guile 3.0.2 to 3.0.7 and suddenly my code starts to SIGSEGV half of the time inside libguile :(
<vivien_>I guess I’m doing things wrong with the garbage collector, but this is so frustrating
<civodul>apteryx: the new image API allows you to define the image's cross-compilation target, and that's what (gnu system images hurd) does
<hwpplayer1>Do you think that system install tool is broken ?
<pineapples>Not to break the peace and detract your attention from more pressing quandaries, but would someone be willing to do homework for me by showing how to extend `/etc/pam.d/login' by a `*.so' module from `/gnu/store/linux-pam/lib/security'? :')