<apteryx>MAKEINFO=true as a make variable for a quick hack
<khimaros[m]>Am I missing something or is the GuixSD documentation suggesting `guix pull && sudo guix system reconfigure /etc/config.scm` incorrect? When I do this on a fresh 1.0.1 install, it is trying to read the latest inputs from /root/.config/guix/current/ which ends up downgrading my system.
<khimaros[m]>The documentation implies that `sudo guix system ...` will preserve the environment of the calling user, but this does not seem to be the case unless called with `sudo -E`
<khimaros[m]>I'm happy to submit a patch to fix the documentation, but want to be sure my understanding is correct..
<ScaredySquirrel>ok when the operating sytstem is initializing under /mnt and it's populating the whole grub efi installer fails
<ScaredySquirrel>error: '/gnu/store/*-grub-efi-2.02/sbin/grub-install --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /boot/efi' exited with status 1; output follows:
<ScaredySquirrel>what is seeming to be happening is some kind of RTNETLINK answer that says it's unavailable but that seems bogus
***ayerhart_ is now known as ayerhart
<khimaros[m]>Kudos! I'm really enjoying GuixSD; experimenting with it in QEMU/Boxes. The install went very smoothly and I'm finding it fascinating to use. There have been a few quirks with the documentation but overall the experience has been very positive.
<raghavgururajan>Folks! I was trying to package 'gnome-characters'. Phases configure and build went fine. But phase installed ended with an error. In the build log, the only line with the word 'error' is this:
<raghavgururajan>FileNotFoundError: [Errno 2] No such file or directory: 'gtk-update-icon-cache': 'gtk-update-icon-cache'
<thomassgn>anyone running wayland/sway and have their mousepointer stop responding to touchpad input?
<brendyyn>did you touch a Fn key combo that locks it?
<thomassgn>not that Im aware of, don't think I have a touchpad lock on this thing. I've just got out of bed and stopped my alarms on the computer.And then went to check on the weather but the mouse doesn't move... :)
<thomassgn>Ah, checking dmesg it says : ... bcm5974: bad trackpad package, length 8
<thomassgn>fixed it. re-registering the bcm5974 module did the trick. 'sudo rmmod bcm5974 && sudo modprobe bcm5974'
*civodul attempts to clean up the MPI mess he's introduced yesterday
<gnutec>vertigo_38: Nop! Return that I forgot "(use-modules (gnu packages cups))". It's a different return when I add "cups" with other services "(use-service-modules desktop networking ssh xorg cups)". This change I can do, but add to much "use-modules" scare me.
<civodul>but it does that using the same technique as "guix pull"
<civodul>so in practice, it often has little or nothing to rebuild
<apteryx>I see! Hmm, still not familiar with how 'guix pull' does its new magic... Seems it break Guix in multiple units (groups of packages, say), then fetches or reuse pre-built version of those, which minimizes the amount of things getting rebuilt?
*efraim is building icecat with the libc crate replaced with our packaged one
<Deee-2>I have a question regarding the Guix packages (or what they're called within Guix). So, as I understood it, all the packages and their definitions are stored in the guix-git (=channel?), so then i submit a guix pull, the channel gets read (like some sort of git pull) and the packages (which have been updated there) get updated on my system by
<alextee[m]>you can look in ./gnu/packages, they're all there
<efraim>does a shepherd service need one-shot? and respawn?
<Deee-2>what I have read is, that, when a program gets anupdate, say, Firefox 69 -> 70, the package definition gets changed to reflext the dependencies of version 70 and the previous version 69 is erased from the package
<Deee-2>before a guix pull it had one entry, say version A. After a pull it still had one entry, version B. So the definition, what version A was made of, was lost and I could not re-install version >, not even with "<package>@A"
<alextee[m]>Deee-2: yes, i think that's how it works, it gets overwritten
<alextee[m]>unless there are 2 packages in your channels, one for each version, you can't install an older version
<alextee[m]>but it's easy to do if you really want to, just inherit the upstream package and change the version parameter (if it builds), then you can install both at the same time
<alextee[m]>for "gtk+" for example there's gtk 2 and gtk3 available upstream, but no older versions of gtk2 or gtk3
<alextee[m]>it would be nice if there was a system to keep like the latest 3 changes in each package so you can easily go back per-package. but you have rollbacks in guix so you might use those to go back i guess
<leoprikler>Also IIRC you are not forced to upgrade packages.
<alextee[m]>having such a system would complicate things though, not sure if it's desirable
<leoprikler>And there are inferiors if you're using manifests.
<oriansj>Deee-2: one doesn't even have to depend upon what is in guix to have guix provide a package; pull the old gtk definition from the git history and put it into a file and do guix package -f gtk.scm to get the exact version you want with all the tweaks you desire and it will work forever
<Deee-2>At least on Windows I can keep the old installer files in case I want to switch versions...
<Deee-2>oriansj: wouldn't it be easier to just add the new versions to the package, leaving old (maintained) versions within?
<Deee-2>that way a history of older versions accumulates and the users can select the versions they need
<leoprikler>That would significantly grow the code with no benefit though.
<oriansj>Deee-2: well officially we don't support older versions that are not required for either a package a developer cares about or is of some value to the project
<Deee-2>as you say it is possible by selecting the desired time in the git repository when that old version was available, so it strikes me as a workaround for a problem that already has a perfect solution (no dll-hell)
<Deee-2>I understand you al have valid reasons and updates to packages are important to fix bugs etc.
<oriansj>Deee-2: most people don't depend upon old versions
<oriansj>and only when there is a real need do we deal with that special case
<Deee-2>oh, our CentOS/Solaris admin would beg to differ :-D
<oriansj>Deee-2: and it is trivial for them to keep the old versions for exactly the packages they care about
<oriansj>there is nothing stopping someone from creating a guix repo with ALL of the old package definitions either
<Deee-2>well, I understand, it seems to me just like a good additional "but Guix can!" goodie for no real cost
<Deee-2>a full history of every program, some sort of archive.org for opackages - and they are guaranteed to work because they specify their dependencies and the oldish libs won't even break the system! wow
<Deee-2>to make it work i have to scroll through the git, select the correct commit, reset to that, then guix-y it. It feels hackish and error-prone
<oriansj>Deee-2: but is a cost that no guix developer has taken the time to absorb
<leoprikler>You just need to point an inferior to that commit.
<Deee-2>oriansj: what is that cost? the package definition of the verion A has already been written. 3 months in, version B arrives, copy-paste it on top, modify dependencies (like youhave to do anyway for a new version), A+B available
<leoprikler>Granted, we will eventually run out of commit hashes, but that is a long time.
<Deee-2>oriansj: like I said, I am very new to Guix and was just wondering because I thought it would work that way. Thereare good reasons only the last vesion is supported and I am just too thick to understand :)
<oriansj>and that isn't hard but tedious and no one wants it bad enough to do that work
<oriansj>Deee-2: well; it would be possible to start that feature rather easily. Simply start with a handful of package definitions and root them back to the bootstrap binaries and simply add when there are new releases
<oriansj>leoprikler: you are absolutely correct but as an opt-in cost; it might be worth it to those that need it
<leoprikler>ScaredyS1uirrel: add (swap-devices '("/path/to/swap-device")) to your (operating-system ...)
<leoprikler>oriansj: to me inferiors still seem to be the superior solution, though
<leoprikler>and the better the implementation of inferiors becomes, the superior it will be
<leoprikler>with constant opt-in cost, mind you, because you're only opting in to those versions that you need
<leoprikler>a separate repo would continue to grow and grow in size
<Deee-2>I've read the articleabout inferiors and I am none thw wiser :-( I just want that version X I know about and not what sounds like a sub-guix within a guix to merge versioned stuff... I am not sure I understood it
<oriansj>leoprikler: true but perfect reproducible binaries forever might be worth it for some Enterprise environments
<Deee-2>leoprikler: sure it will increase in size, you keep the old stuff around, but it's mostly redundant text which compresses well
<oriansj>especially in a few Government agencies I know
<malaclyps>so I have a Guix system that's not accepting keyboard input in X -- I've pinned it down to libinput not loading because it can't load libwacom -- and it can't load libwacom because the shared library is zero bytes long
<leoprikler>and which one produces 1iy0fwk1hmvangichipg9kh9pwynl40y?
<leoprikler>I'm not an esper. By which method do you tell your guix versions apart?
<malaclyps>leoprikler, well i am selecting between a working version on boot, and a non-working version. The working version (which I am using right now), is I guess the 5th generation system. The non-working version is the 6th generation system. (Also, I know you are not an esper. I am trying to explain my problem as precisely as I can, and asking you for questions when you I do not understand how best to answer your questions. I appreciate the time you
<malaclyps>are spending, but the esper comment could be perceived as hurtful or dismissive.)
<malaclyps>so my *guess* for determining the difference would be to look in /var/guix/profiles/ and follow the links there.