<milll>i'm trying to do an encrypted install and playing around with settings in the /etc/config.scm; since i'm getting stuck in grub boot, i want to just make a few changes to /etc/config.scm from the livecd and then reinstall the bootloader - can i do this w/o redownloading all packages (e.g. without guix system init).. i'm trying 'guix system reconfigure -r /mnt /mnt/etc/config.scm' but that seems to not recognize
<milll>e.g. can i use guix reconfigure from livecd with a target without chroot?
<milll>or how do i even chroot in livecd since chroot doesn't understand symlinks?
<apteryx>milll: the /gnu/store should exist on the partition you are trying to install to; unless you erase this partition, it should be preserved and when you guix system reconfigure the items there should be reused instead of redownloaded built. Think of /gnu/store as a cache.
<milll>apteryx: thing is when i re-run the init command i can see it re-downloading all the packages, maybe it's a bug, basically i did one init as per the manual and then realized my boot config was messed up and now im trying to fix it without doing a full reinstall/init
<apteryx>milll: ah, maybe a new init would do that, but after you've init once, you should use reconfigure instead, which should preserve you /gnu/store and /var/guix
<milll>yeah but 'guix system reconfigure -r /mnt /mnt/etc/config.scm' doesn't seem to recognize the root?
<quiliro>perhaps that is included in the graphical installation...but nothing on the manual installation
<wednesday>the (gnu system keyboard) stuff was only added a few days ago if that's what you're talking about, and about that stuff, for the keyboard-layout wont work for grub or the operating-system definition, also I think that update broke sddm because mine was starting with no x config
<th-end>how do i transfer my current build of icecat to another pc with guix-sd installed? assuming no internet connection (i.e. with a usb drive)
<quiliro>wednesday: thank you for the info... you mean that you suggest not to use it?
<quiliro>i was told binaries are generated at most 5 minutes after someone has asked for them with guix package -i
<th-end>where would i be able to see the latest builds of these binaries
<quiliro>i think the best is to search the manual and if not found, report on the mailing list with all the info you have researched...that would provide the best support
<quiliro>th-end: i do not know enough about guix to answor that question...what i would do is run guix package -i icecat... if it does not output an error and ask for adding --fallback, then it is using the binary
<quiliro>i asked about binaries some days ago...it must be on the guix chat log
<nckx><quiliro> i was told binaries are generated at most 5 minutes after someone has asked for them with guix package -i
<reepca-laptop>It'd be nice if our test logs gave useful information beyond the error type, like, say, where it occurred. For example, tests/pack.scm is failing for me (branch-local thing), and all I get in the log is that a wrong-type-arg error was caused because... something... was expecting its second argument to be a string and it wasn't.
<reepca-laptop>also, I get the feeling that "make" isn't properly detecting when go files need to be recompiled, as sometimes I'll do a "make clean-go" and wait an hour or so for everything to get rebuilt and then tests will pass that were previously failing
*kmicu hopes that’s not a typo in modules/variables names xD
<reepca-laptop>quiliro: to answer your question, (modify-services ...) returns a list of services. So you can treat that entire form the same as %desktop-services. e.g. (services (cons* extra-service-1 extra-service-2 (modify-services %desktop-services <modification form go here>)))
<quiliro>reepca-laptop: so modify-services goes inside cons* ?
<sarg>Hi, all. I'm completely sold to try guix after ambrevar's post. I've got it installed on top of my debian and now I'm moving my apps into guix one by one. I've typed `guix package -i flameshot` and was dazed that it tried to install `mariadb` and `postgresql`. I've looked at `guix package -i flameshot` and was deeply shocked how big is the dependency diagram. So I'm curious, how do I tell guix to install only absolutely necessary
<kmicu>quiliro: Yes, you can put it inside cons*. ‘(modify-services …)’ takes services and returns them (modified) so you can put it in any place with services list like e.g. ‘%desktop-services’.
<quiliro>reepca-laptop: or is it rather like this?: (services (cons* (gnome-desktop-service) (xfce-desktop-service) %desktop-services (modify-services %desktop-services <modification form go here>)))
<kmicu>‘(modify-services %desktop-services …)’ can be safely dropped in place of ‘%desktop-services’
<quiliro>kmicu: so it is not as i said but rather as reepca-laptop said: (services (cons* (gnome-desktop-service) (xfce-desktop-service) (modify-services %desktop-services <modification form go here>)))
<reepca-laptop>sarg: well, assuming that qtbase can work properly for some applications without mariadb and the like, there's the simple issue of checking every single package that depends directly or indirectly on qtbase to see if it works without those features.
<reepca-laptop>AFAIK, no, we just use package variants. It's as simple as (package (inherit some-package-minimal) (name "some-package-not-minimal") (inputs (append `(("cool-new-dependency" . ,cool-new-dependency)) (package-inputs some-package-minimal))))
<reepca-laptop>... which doesn't look all that simple when it's forced on one line like that, but oh well
<reepca-laptop>in summary, it's not so much an issue of "can it be done", but rather of "who's gonna do it?".
<reepca-laptop>there's also the issue that qtbase itself (not including dependencies) is 67.7MiB, and a qtbase-minimal would probably not be much less (just less dependencies), so if you ended up using both qtbase and qtbase-minimal, that'd be a significant amount of extra space.
<reepca-laptop>Blackbeard[m]: I'm not sure that's strictly accurate, I think the issue here is that the latest rust depends on older rusts for bootstrapping. As far down the history of rust as substitutes aren't available, they'll have to be built all the way from there in order to get the latest, even if the latest is the only one that ends up being used
<wednesday>nckx: can you check if the recent keyboard stuff all works heh, with the boot loader keyboard-layout I would end up with the keyboard not working, and my sddm kept starting with no x config heh
<wednesday>also the keyboard-layout in the operating-system definiton was giving me syntax errors or something heh
<atw>hard to say, but after rebooting and running guix pull, I get messages like error: executing `/gnu/store/vhx3sg5sqj0mnv4inkjhf7c8xvlmjhxh-guix-0.16.0-11.f970946/libexec/guix/substitute': No such file or directory
<atw>guix pull: error: unexpected EOF reading a line
<apteryx>There was a change in the way 'guix pull' works, and the transition from the old mechanism to the new one is not without bumps. I already forgot if 0.16 was released with the old way of doing 'guix pull', but I have a feeling it was.
<atw>apteryx: re at least it boots: yeah! small victories! I have already learned a few things, like the necessity of removing Debian's /etc/ssl /etc/pam.d /etc/skel
<apteryx>atw: hehe, you can probably wipe /etc/ clean without much problems, as the essential things there should be populated at boot, when the operation system configuration is "instantiated" :-)
<atw>re where does my guix come from: it should be ~root/.config/guix, but let me reinstal and try again. I will also try wiping Debian's /etc in entirety
<reepca-laptop>hmmm, do module-imports check if the file has been changed? I changed a file in my guix checkout, but no matter how much re-configuring, make clean-go, rebuliding, and ultimately running of make check I do, a test always fails because a module-import-compiled keeps on using old broken sources.
<atw>guix pull in the installed system is looking good! Thank you efraim and apteryx!
<reepca-laptop>now the module-import-compiled is failing by saying that %make-hash-table* isn't bound... but the only time it's ever even directly used is in the same module it's defined in! I am so confused.
<reepca-laptop>civodul: You wouldn't happen to know of any steps I need to do other than cut+pasting parts of (guix store) and (guix derivations) into (guix store files) and (guix store derivations), respectively, adding a define-module at the top of both of those with the right modules, changing (guix store) and (guix derivations) to use them and re-export the same bindings, and changing (guix store database) to use them, would you? I've done that
<reepca-laptop>and I'm getting bizarre errors in the test case where seemingly random variables end up unbound when they really shouldn't be.
<civodul>reepca-laptop: the unbound variable errors may stem from circular dependency among the new modules you introduced
<civodul>you need to make sure there are no cycles there
<civodul>i could take a closer look if you post the patch that you have
<apteryx>atw: nice :-). So what did you end up having to do, exactly? One guix system init, then one guix system reconfigure?
<atw>I skipped the guix system init altogether and instead did a reconfigure. The resulting system does not break on guix pull
<reepca-laptop>civodul: (guix store files)'s only guix dependencies are base32, base16, config, and memoization, none of which cause circular dependencies, and (guix store derivations)'s only guix dependencies are base16 and memoization, which again don't cause circular dependencies.
<ngz>Hello. I often encounter the same issue while packaging stuff. I wonder if there's a common solution. So, let say the executable "fooexe" of a package "foo" is only in $out/share/foo/fooexe. I want it in $out/bin/ too. One solution is to symlink fooexe in bin/, but it messes with CWD, and the symlink may not find data in share/foo/.
<civodul>reepca-laptop: yeah sounds good; it's hard to tell more without looking at the code though
<civodul>ngz: share/ (aka. $datadir) is for platform-independent files
<ngz>I think I could create a script in bin that basically pushd "share/foo/", exec "fooexe" and popd thereafter. However, I don't think any packages does it.
<civodul>so there shouldn't be any binaries in there, normally
<ngz>civodul: as I said, it is an issue I often encounter, so we have to deal with it anyway.