<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> /gnu/store/*-grub-efi-2.02/sbin/grub-install: error; failed to get canonical path of `/boot/efi'. <pkill9>i mount my boot partition to /boot/efi <pkill9>so i would think that would fix it <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. ***jonsger1 is now known as jonsger
***chipb_ is now known as chipb
<sneek>mogom, str1ngs says: I suspect you want to use guix system build . not guix build <sneek>mogom, str1ngs says: after actually reading your definitions. you need to add the package the end of the file you would like to build. the build with guix build -f ./rockpi4.scm <mogom>after some advice in group , i write this .scm to instantiate of my guixsd for RockPi4 board <mogom>with this "guix system disk-image rockpi42.scm" <mogom>but i encounter this unrecognizable error. <mogom>ERROR: In procedure cons:Wrong number of arguments to #<procedure cons (_ _)> <str1ngs>mogom: (initrd-modules (cons %base-initrd-modules)) looks wrong to me <str1ngs>maybe this should be (initrd-modules %base-initrd-modules) <str1ngs>mogom: or maybe you are are attempting to add a module to the initrd. in which case you might want (initrd-modules (cons* <module-name> %base-initrd-modules)) <mogom>(initrd-modules (cons* %base-initrd-modules)) <str1ngs>that doesnt do anything useful from what I can tell <str1ngs>initrd-modules uses %base-initrd-modules by default <mogom>str1ngs: it's again error this: <str1ngs>this is useful if you want to add a module to the %base-initrd-modules like (initrd-modules (cons* foo %base-initrd-modules)) <mogom>error: arm-trusted-firmware-rk3399: unbound variable <mogom>in line 77, is it about parenthesis or something? <str1ngs>guix has a u-boot-rockpro64-rk3399 package <mogom>str1ngs: my board is rockpi4 and it's similar to rockpro64 <mogom>str1ngs: the error was for packages firmware it's ok now :) <str1ngs>mogom: you need to add (gnu packages firmware) to modules <mogom>is there any idea with this error: error: substitute-keyword-arguments: unbound variable line 61 <mogom>solved! it was about add (use-modules (guix utils)) <mogom>Suppose we want build u-boot for a specific board and run "just" u-boot image on board. <mogom>So we need a way to generate "u-boot image" with guix. <mogom>suppose i just want u-boot image and want to test it without OS. <mogom>I think, it's possible by guix, but i'm not sure how. <mogom>possibly "guix build u-boot-*" or "guix build install u-boot-*" or ... <grumbel>How do I make guile not cut of the backtrace after 80 columns and shorten strings with ellipses? <wingo>grumbel: i am not sure if it works but try export COLUMNS=400 in your shell <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' <leoprikler>sneek later tell raghavgururajan gtk-update-icon-cache is part of gtk+:bin, but most packages actually substitute it with true, because it doesn't do anything useful outside profile hooks <mogom>"guix build u-boot-* " generate "u-boot.img" and "idbloader.img" and "u-boot.bin" <mogom>i think these can easily run on board. <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 *smithras still has trouble sending emails <gnutec>How I start the Cups to install a printer? <civodul>bandali: MPI is the "Message Passing Interface", a standard used for distributed computations in high-performance computing <bandali>civodul, ah, gotcha; thanks for explaining :) <demotri>Is libzip really on master? "guix refresh -l" gives only a handful of dependencies, but I really can't believe that. <gnutec>civodul: I did in guile repl, but return something like: ;;; <stdin>:5:0: warning: possibly unbound variable `services' ;;; <stdin>:5:80: warning: possibly unbound variable `cups-filters' ;;; <stdin>:5:80: warning: possibly unbound variable `escpr' ;;; <stdin>:5:80: warning: possibly unbound variable `hplip-minimal' <unnamed port>:5:0: erro: services: variável não vinculada <civodul>we'd need to see exactly what you typed, but you probably want to do that in your /etc/config.scm file <civodul>it's not convenient to do at the REPL <gnutec>civodul: Wait! I forgot something. <gnutec>civodul: Ok! I use (use-modules (gnu packages cups)) and the variables was add, but not "service". <civodul>if you do that in your config file and run "guix system reconfigure" on it, you'll get hints if there are errors :-) <gnutec>civodul: Yeh! I read config.scm right know. The script call for "(use-service-modules desktop networking ssh xorg)" too. Let me see this. <gnutec> (list (service gnome-desktop-service-type) <gnutec> (service xfce-desktop-service-type) <gnutec> (list cups-filters escpr hplip-minimal)))) <gnutec> (keyboard-layout keyboard-layout)))) <gnutec>civodul: So now is like "sudo guix system reconfigure /etc/config.scm" <gnutec>civodul: With the new config.scm <ScaredyS1uirrel>how may I list a package to remove in my /etc/config.scm system configuration file? <gnutec>ScaredySluirrel: try "sudo herd status". Don't use config.scm all the time. <ScaredyS1uirrel>I viewed the log file and it says that I have an error of weston-test-client-helper.c:921: create_client: Assertion `client->wl_display' failed. <ScaredyS1uirrel>it says also that move_client frame_callback_wait_nofail((client, (&done)) failed <gnutec>civodul: Nop! Comand returns "/etc/config.scm:52:12: erro: cups-service-type: variável não vinculada hint: Você se esqueceu de uma forma `use-modules'?" <gnutec>civodul: I need change big stuff of config.scm. I'll wait until someone show me how to do with "herd" or "guix" comand. Much better. <vertigo_38>gnutec: for my limitted portuguese/spain literacy that sounds like you also have to add ~cups~ to ~use-service-modules~! <ScaredyS1uirrel>ok guys how do I use the herd command? I need to fix the weston build error before it installs <gnutec>vertigo_38: Ok! let me try this. <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. <vertigo_`>gnutec: I'm not sure if this is absolutely necessary, but I also put "lpadmin" and "lp" into my user's ~supplementary-groups~. <gnutec>vertigo_: Yes! I install cups using guix install, but somebody told me there we no need that. I have this commands. <leoprikler>you should add the CUPS service to the services field of your operating system <gnutec>leoprikler: I don't want edit config.scm and something goes wrong. <leoprikler>if the new config breaks, roll-back is always possible <gnutec>leoprikler: I did. But are you sure there is not a command to add the service? <leoprikler>services in Guix are instantiated according to config.scm <leoprikler>so no, manipulating that and reconfiguring is all you can do <gnutec>leoprikler: Ok! I try again other day. I need relaxy my mind. *apteryx managed to have a current-guix/pre-built package that "builds" under a minute compared to 20+ for the purpose of iterative dev and testing with (gnu tests install) :-) <apteryx>I just grab everything which is already built in the developer's Guix checkout, and run make install on that (that's the simplified explanation ;-)) <apteryx>it's not "clean", so I'll make this behavior happen only when the dev sets the "GUIX_DEV_HACKS" environment variable. <civodul>at least the motivation is the same :-) ***Deee is now known as Deee-2
<apteryx>civodul: I'm looking at it, seems the intent is shared indeed! <apteryx>one small thing that puzzled me, why is the select? of the interned-file macro not simply (const #t)? Seems the intent is that this catches all. <civodul>apteryx: when you have a "dirty" working tree, you'd rather make sure you don't include untracked files <apteryx>but the .go files aren't in git, so how does it reuses those? <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 <Deee-2>downloading/compiling. So far correct? :) <oriansj>Deee-2: depends if you enabled binary substitutes or not <alextee[m]>Deee-2: sort of. guix pull just git pulls and doesn't actually perform an upgrade <Deee-2>okay, so in principle this is how it works <Deee-2>the package definitions are stored in the savannah git (channel) <oriansj>Deee-2: the most it does it upgrade your guix; guix package -u is required to update any of your packages <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 <sneek>raghavgururajan, you have 1 message. <sneek>raghavgururajan, leoprikler says: gtk-update-icon-cache is part of gtk+:bin, but most packages actually substitute it with true, because it doesn't do anything useful outside profile hooks <Deee-2>why is that so? the power of guix is to be able to run all kind of different versions side-by-side as their libs won't collide <Deee-2>so why remove the old package definitions? It is one of the main selling points from what I can see... <alextee[m]>Deee-2: i think that only works when there are explicit packages for each version, otherwise it just picks whatever's in git (the latest) <oriansj>one can always specify exact versions if so desired <alextee[m]>oriansj: can you install say an older version of gtk3? like gtk 3.20? <Deee-2>IIRC "guix package -A <package>" gives me a list of all available version of <package> (I am not sure about the exact parameters there, sorry) <alextee[m]>i think you would need to make a separate package for it first (correct me if i'm wrong) <efraim>based on 'user-homes' it looks like no <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 <Deee-2>but version A was fully working so why remove it. It even specifies what it needs to run and Guix can host different versions of the same lib so no dll-hell <Deee-2>I just don't understand why it is like this :) <alextee[m]>maintainability i guess, guix kind of like arch, all packages are at their latest versions, unless there's a good reason to have extra versions <Deee-2>Sometimes it is necessary or preferred not to have the mosrt recent version running (see the Chormium 80 disaster) - or - to have it running in parallel to see if it's okay *Deee-2 king of typos today... <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>leoprikler: hmmm.. what is a "inferior"? <oriansj>Deee-2: to completely do that, you actually need to rewrite those old definitions to point to the old package dependency versions and do the same all the way down the graph <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 <Deee-2>oh, it's 1.0.1 stuff so a pretty new concept <Deee-2>oriansj: it would have been a usecase for me, so I thought I ask people that know how Guix's concepts work <Deee-2>oriansj: so take it as field-feedback from a newbie :) <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 <Deee-2>sounds like a job for a git hook <oriansj>leoprikler: usually isn't a problem if the binary is the primary concern and you are willing to go from the bootstrap binaries <oriansj>and those are going to be frozen forever after mes-m2 is ready for the spotlight <oriansj>leoprikler: only applies if it is in the main git branch and not in a seperate tree or repo <leoprikler>Sure, but that separate tree or repo (which you'd have to check out as channel, I assume), would suffer from the same problem, would it not? <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 <malaclyps>so I presume there's either a bad substitute or a bad compilation in general <oriansj>heck one could make a forest repo; which the opt-in only includes a single program and the packages it depends upon to the bootstrap binary <malaclyps>what should I do next to help debug this? I'm not sure I know enough yet to file a bug report, and I'd like to help work on this bug <leoprikler>malaclyps: first of all, find out which of those libwacoms is the current one <leoprikler>I think `guix build libwacom` should output the directory <malaclyps>leoprikler, do you mean for the non-working system, or my current working system generation? <malaclyps>it's /gnu/store/1iy0fwk1hmvangichipg9kh9pwynl40y-libwacom-1.1/lib/libwacom.so.2 for the non-working install, /gnu/store/z2zazz1xkb09r5d1ycz7fzgc62bm7av7-libwacom-0.33 for my working setup <leoprikler>I currently have /gnu/store/1iy0fwk1hmvangichipg9kh9pwynl40y-libwacom-1.1 <malaclyps>leoprikler, what does ls -l /gnu/store/1iy0fwk1hmvangichipg9kh9pwynl40y-libwacom-1.1/lib/libwacom.so.6.1 give you? <leoprikler>I think you want that one: -r-xr-xr-x 2 root root 62K 1. Jan 1970 libwacom.so.2.6.1 <malaclyps>okay, I'm going to try sudo guix build --verbose --repair libwacom <Deee-2>civodul: just "keep it simple" the most advanced and far-out tech is just fancy and academic if it's not usable by the mayority of users (and blokes like me) <malaclyps>nope, sudo ~/.config/guix/current/bin/guix build --debug=2 --repair libwacom just checks the path and okays it <leoprikler>btw. does anyone know of an option to use substitutes for all but the thing you want to build? <malaclyps>the new build (/gnu/store/8ij7avb9vf9wp12fjc73sh2l6yjrcyhw-libwacom-1.1) has a non-zero sized libwacom.so.6.1 <malaclyps>but i'm not sure how to get my setup to use the correct one <malaclyps>(I guess I could copy over the file but that would be IMMORAL obviously) <leoprikler>Can you rebuild your operating-system with that guix? <malaclyps>leoprikler, I'm not sure what you mean. (I am looking at guix gc now, btw) <leoprikler>btw. for reference /gnu/store/8ij7avb9vf9wp12fjc73sh2l6yjrcyhw-libwacom-1.1/ is already included in your paste <leoprikler>btw. does the non-working one produce 8ij7avb9vf9wp12fjc73sh2l6yjrcyhw? <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. <leoprikler>I hadn't thought about symlink following as a debug method for a second :) <malaclyps>leoprikler, i don't know a better way to find what's being used when, but I'd appreciate finding one out! <leoprikler>Well, I thought you were running /path/to/working/guix and /path/to/non-working/guix separately <leoprikler>Now that that misconception has been cleared up, do you know which guix you used for generating the 6th generation? <malaclyps>leoprikler, ah! i understand! I believe it's the one in ~/.config/guix/current/bin/guix -- though I would have used "sudo" with that <malaclyps>(tbh I am confused as to which guix I should use in various tasks -- right now I'm defaulting to that, rather than say /run/current-system/profile/bin/guix ) <leoprikler>sudo should not affect which guix you're running if you just do "sudo guix", i.e. it should resolve to ~/.config/guix/current/bin/guix <leoprikler>then check whether that system has a non-empty libwacom <malaclyps>my paths are currently set so that /run/current-system/profile/bin/guix is found first, let me fiddle with those so that's not the case