<vagrantc>i know i'm late to the party, but happy new year folks!
<spudpnds>vagrantc: Woot, happy new year, here is to a Guix filled 2021.
<spudpnds>I'm installing guix in a bunch of virtual machines, and I notice the guix iso I'm using (GNU Guix System 1.2.0) is like 10,000 commits behind the current master branch. I wonder if there is a way I can do a "git pull" prior to
<spudpnds>the actual "guix system init /mnt/etc/config.scm /mnt" that gets run.
<lfam>You would do `guix pull`, not `git pull`. It can be done but it will be less tested than if you install 1.2.0
<vagrantc>i've had to run guix pull from the installer on systems that were not yet supported by the version of the installer ... worked fine, takes a bit more ram from the running system ... and be sure to guix pull on the installed system again before doing anything
<lfam>vagrantc: I'm planning to move the extra-options from linux-libre-arm-generic and linux-libre-arm64-generic into the config files stored in 'gnu/packages/aux-files/linux-libre'
<vagrantc>sneek: later tell lfam linux-libre-arm-generic had a very different config, last i looked. the original linux-libre on arm64/aarch64 was based originally on debian's arm64 kernel configuration, and at some point (i suspect accidentally) appears to have been synced with the defconfig for arm64
<sneek>lfam, vagrantc says: linux-libre-arm-generic had a very different config, last i looked. the original linux-libre on arm64/aarch64 was based originally on debian's arm64 kernel configuration, and at some point (i suspect accidentally) appears to have been synced with the defconfig for arm64
<lfam>I guess my real question, do we need both of them? I think I've tried to understand this before but it's not really clear for me
<vagrantc>lfam: the other reason i like the configs based on defconfigs is they get maintenance upstream where a hand-managed config may require manual intervention between versions
<spudpnds>atw: I'm in the process of trying to convert my init.el to not download from melpa, but just use "use-package" as a handy configuration macro. Do you still use use-package in your setup?
<vagrantc>lfam: it can also sometimes be a huge time sync to keep track of the changes necessary to keep the module list the guix initrd consumes in sync with the upstream module names, and guix's handling of modules needed for rootfs requires a bit too much manual intervention on more obscure platforms
<vagrantc>so i think the guix-maintained kernel configs should probably be highly modular configs, while the defconfigs tend to be more built-ins ...
<vagrantc>but maybe my debian biases are coming through here :)
<lfam>I don't really have much cultural understanding of kernels, distro kernels, etc
<vagrantc>one of the things i liked about guix was that it actually had some arm defconfig based kernels out-of-the-box
<lfam>And, those would be the *-generic kernels, right?
<atw>spudpnds, that's a good question but unfortunately I've never used use-package...if you have an emacs package installed via guix, does use-package think that the package is already installed? I take it from your question that it doesn't?
<lfam>What makes you think the "distro config" got synced with the defconfig?
<spudpnds>atw: I think you can say ":ensure nil" to tell it not to attempt download, that it's already installed. So your init.el just has a bunch of (require 'somepackage) statements to bring in packages that are installed by guix?
<spudpnds>Or is there something that automagically loads them?
<vagrantc>if i had to maintain the kernel in guix, i'd go with some sort of overrides system for configuration options rather than a hand-crafted configuration ...
<vagrantc>lfam: because the original arm64 config in guix was literally based on me dropping the debian kernel config in place and building it on guix
<vagrantc>lfam: which is definitely not anything like the defconfig
<atw>yeah, my config just assumes that stuff is available. And on not-guix, I just do, like, package-install-selected-packages and everything works after that
<vagrantc>lfam: i vaguely recall tracking down when it happened at one point ... it was a year or two ago
<lfam>You observed that it changed in a way that implied it changed to using defconfig?
<vagrantc>lfam: i think someone updated the kernel config and accidentally ended up with something based on the defconfig
<spudpnds>atw: Cool. Do you like have an emacs manifest file with all your packages, or do you just use your default profile?
<lfam>Right, but I'm asking why you think that? You saw the changes in `git log`? Or the kernel started behaving differently?
<vagrantc>lfam: i manually inspected the git logs and saw when it went from being a hand-crafted config to something almost identical to the defconfig
<vagrantc>lfam: i think something like "make config" done with the wrong architecture configured somehow might do that ... e.g. it realizes that all the configuration options are inappropriate and stards with the defconfig
<lfam>Frankly, by the time you manually decide about the hundreds of new questions for each architecture, one is tired and prone to mistakes
<lfam>It really should be done a little bit at a time during the RCs
<vagrantc>lfam: honestly, i'd switch to exclusively using the extra-options and using defconfigs for the defaults for all the kernels ... then you maintain a list of features you want and features you don't want, and apply them to the defconfig
<spudpnds>atw: Trying to start off the guix way, but profiles still confuse me a bit.
<lfam>vagrantc: I think it might end up being more lines of Scheme than I want to deal with. At least the kernel has some tools for handling it
<lfam>This computer needs to "just work" because it is library of the hifi
<lfam>Regarding the defconfig-ed distro configs... if it works, it works. But if it isn't working I can change it
<lfam>Anyone can change it, really. Patches welcome
<spudpnds>vagrantc: Heh, that's cool, I didn't realize you could destroy the host OS with guix system init.
<spudpnds>I'll have to try that on one of my ubuntu test boxes.
<lfam>This is how the first Guix System was installed
<vagrantc>lfam: and i did for a while, just eventually got tired of troubleshooting the kernel from the emergency guile shell in the initramfs ... and so switched enthusiastically to the defconfig based kernels :)
<vagrantc>and what i like about guix is it can reasonably support both approaches to the kernel configuration, actually. it's nice to be able to have both
<lfam>I should buy the arm board just so I can test this stuff
<vagrantc>i have yet to try using the new (at least to me) "guix system disk-image" to generate a bootable image for arm boards ... been meaning to create one for pinebook since it works pretty much out of the box
<raid5atemyhomewo>pools are not autodetected yet but I can at least mount zpools seamlessly
<raid5atemyhomewo>okay, so basically in the zfs package I need to change ("util-linux" ,util-linux "lib") to two inputs ("util-linux" ,util-linux) and ("util-linux-lib" ,util-linux "lib")
<raid5atemyhomewo>Then to get the automounting behavior of ZFS from other OS's, I just need to figure out how to execute "modprobe zfs" and "zpool import -a" in a service, what's the best reference for that?
<oiur>Hi everyone. I want to remove the xf86-input-synaptic module from the xorg service since it seems to conflict with libinput and the touchpad settings in gnome are not working because of this. Can someone help me with modifying the xorg service? (I'm new to guix and don't know how to do it)
<moesasji>likely to confuse someone not that familiar with linux
<mdevos>oiur: what do you mean with ‘conflict’ here exactly?
<mdevos>You mean profile collisions, or something else?
<profmakx>GNUtoo: i.e. install-rockpro-rk3399-u-boot would write idb and u-boot in the correct place, but the partition layout in the created image isn't correct; i am still fiddling through how this code is invoked to see how one would make it play ball
<davidl>janneke: yeah I think so. Are you also not able to resize the hurd-vm via the configuration and see a change after restart/connect when running df -h / ?
<efraim>raid5atemyhomewo: re zfs, indeed, I'm sorry for any trouble it caused. As I'm guessing you noticed I packaged it to prove that it was acceptable to include in Guix, and I hoped that someone who wanted to use it would appreciate it being almost all the way there.
<raid5atemyhomewo>well, with my patch it gets 90% of what I need, and works well enough if you just want to have some large ZFS storage for data, not necessarily for / or /home yet
<raid5atemyhomewo>probably ZFS modprobe and import -a should be done earlier, I will figure it out
<raid5atemyhomewo>just need someone to merge my patch into guix and I will see what I can do to get ZFS importing earlier in shepherd
<raid5atemyhomewo>my current pain point is encrypted ZFS means I need to add -l to zpool import -a -l command
<raid5atemyhomewo>but the prompt that ZFS prints for the passphrase is lost in the noise of other shepherd services spamming the console
<raid5atemyhomewo>but not the raw "Enter passphrase for 'tank/fs':" message that it presumably outputs on stdout
<mdevos1>An encrypted ZFS root / seems simpler to me, I don't think Guix has much support for unlocking encrypted partitions post-boot. At least, that's my impression with an encrypted BTRFS root. I haven't actually tried to have an additional, say, encrypted BTRFS /tank/fs. I could be wrong.
<ryanprior>But to try it out on your machine you will have to do that as well I think.
<ride>How do you source zsh-autosuggestions on guix system? On a normal OS you source /usr/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh. Do you just source the file in /gnu/store?
<atom`>ryanprior: Thanks. It works fine the Flatpak version of Firefox using the setting you suggested.
<ryanprior>Yay, I'm glad you got that much working. I hope we can get it fixed in Icecat too.
<atom`>Yes. I will send a bug report, and can hopefully use it with IceCat soon. Might have to use the Flatpak version for the meantime.
<ryanprior>ride: it might create a zsh subdirectory in your Guix profile that you can source?
<constfun>Hello folks, I could use some help. I packaged some code of mine and am trying to use guix pack to create a tarball that I can send to a friend (no guix there). My package has only native-inputs, and the project (built using ocaml dune) produces a statically linked binary already. My expectation is that the resulting pack should be virtually empty,
<constfun> however, it for some reason includes libx11 and many other things and unpacks to 1gb of stuff. My question is two fold, native-inputs are build time dependencies for my project and I don't want them to be included in the pack, am I doing it wrong? Second question is how do I figure out what is looping in x11 (for example) which I don't expect to s
<constfun>ee as a dependency of this project at all? Thank you!
<ryanprior>constfun: native-inputs will not be built for the target architecture if you are cross-compiling. But if the package holds a reference to a native input, then it will be included in the pack.
<ryanprior>constfun: possibly your package is linking against some common x11 library even though you specified a static build. I am pretty ignorant about ocaml but I have seen this in golang builds for example.
<ryanprior>Go creates "static binaries" which for most purposes are static, but they do link against libc unless you pass a bunch of flags to make it really truly static
<constfun>ryanprior: hmmm... is there a way to specify build time only dependencies and not have them be included when running `guix pack`? I'm not specifying anything special for the target architecture since its the same as the build system.
<ryanprior>constfun: It's not about what you specify (to Guix) it's about what it observes in the actual build artifact.
<ryanprior>If there's a reference embedded in the package output to /gnu/store/some/other/package then Guix considers that other package to be a runtime dependency whether you declared it or not.
<nij>How to see the details of each build-system? For example, what's the detail of the emacs-build-system? In the manual there's only a short description of it..
<constfun>ryanprior: ah, that's illuminating, thank you. does guix inspect the actual binaries/libs to figure that out? or you mean something else by "package output"? i was trying to get into a --container environment to do more testing, but then the project doesn't build since shell scripts are not patched in that environment as they are during guix build,
<constfun> if that makes sense... a bit of a chicken and egg situation.
<constfun>im still not sure how to produce a pack that includes only runtime dependencies and not build dependencies
<ryanprior>You can add more packages (like bash and coreutils) to a Guix container environment using --ad-hoc flag
<constfun>i have an that seems to work, but its the fact that build scripts (waf also in there) include references to /usr/bin/env which are normally patched automatically when you run guix build
<ryanprior>I don't know either, there may need to be some change in the dune-build-system, or maybe some special flags or options, or extra steps. I am too ignorant about ocaml to offer any specific suggestions :\
<constfun>with guix environment those are not patched, so i cant build the project once im in the shell
<constfun>ryanprior: thank you for the tips anyway, I may look at the code for dune-build-system next
<ryanprior>Ah right, yeah you would have to patch those yourself. It would be nice if there was a utility for that.
<constfun>yea, im going to have to think of a way, maybe something with direnv... or maybe just modify the project to not use /usr/bin/env
<cbaines>constfun, what does guix size say about the size of your package?
<apteryx>rekado_: I have yet another TeX Live question: is there another tool than tlmgr that can be used to query the texlive.tlpdb database on Guix?
<constfun>cbaines: guix size complains "no available substitute information for" which makes sense since I am building with --with-source transformation, ill have to make all the commits/push remotes/etc and try again
<cbaines>I think guix size only falls back to substitute information if the relevant thing hasn't been built locally
<constfun>that explains it, it likely can't find the local build because i used the transformation, however with-source is not an option that guix size accepts
<constfun>what was your motivation for asking though? perhaps it will give me ideas
<ryanprior>atom`: you clone the repo, checkout the relevant commit, and then run guix hash -rx /path/to/the/repo
<ryanprior>atom`: If you do this often and happen to use Emacs, you can automate this by installing guix-packaging.el and running M-x guix-packaging-hash-git
<cbaines>constfun, guix size can take an item in the store, so build your package with the transformations, and then run guix size on the resulting store item
<mdevos>I'm trying to upgrade a computer A without Internet access (the ‘no internet’ ’ is intentional on my part). It's connected via ethernet cable to a laptop B with Internet running Guix System. I've downloaded all required sources via 'guix build --sources=transitive -f computer-A.scm'. Now on computer B I'm trying to upgrade the system. I've pointed guix system build at lapop-B --with-substitute-urls=http://laptop-b.local:8080. But it
<constfun>cbaines: that makes sense, but im not sure how the closure is calculated, also the size is dominated by ocaml at 250mb but it is not a runtime dependency, same for gcc, im not sure how to exclude those
<cbaines>mdevos, I think substitute servers can provide files by hash, but I'm guessing the list of sources is in the Guix source
<cbaines>mdevos, substitutes can be fetched for fixed output derivations, but that requires authorization
<mdevos>cbaines: oops, I did authorize the computer with network access. I forgot about that
<mdevos>cbaines: I have a git clone of guix on the computer I'm trying to upgrade. I'll try to modify that locally for now
<mdevos>though I believe substitute servers should be used as content-addressed mirrors as well (but perhaps this is not yet implemented)
<cbaines>constfun, the closure is computed by looking at the store items, if you want to find out why something is included, look for references to it, I've put some example commands for the hello package here https://paste.debian.net/plain/1179453
<cbaines>mdevos, looks like it's hardcoded in the (guix download) module. Does it look like guix is attempting to fetch substitutes from the machine that has them?
<playing>Did you think that only thing holding other seoftware from being free is just humans laws?
<playing>Like, when someone publish MS Windows source code, doesnt its eventually become free? It is, you cant keep knowledge hidden forever.
<ryanprior>It depends how they publish it. If Microsoft (or a legal copyright holder) publishes it, then eventually the copyright may expire in the US. Our constitution says that copyrights may be secured "for limited times to authors"
<ryanprior>But the US government can keep raising that limit, and people have said that's exactly what they intend to do is keep raising the limit repeatedly, such that copyrights last "forever, minus a day"
<mdevos>As MS Windows doesn't have a free license (think of being allowed to modify your copy of the source code and share it), it is considered non-free. Your definition of ‘freedom’ may vary of course, but me myself finds being forbidden by law rather inconvenient.
<ryanprior>If somebody steals the source code and publishes it, then that might not not start the copyright clock.
<ryanprior>If you wanna talk more about software freedom you can join #gnu :) this channel is for discussing Guix software.
<mdevos>Technically, I suppose I could just violate the law, and modify and share the source code, but going to court, paying fines, and depending on the jurisdiction going to prison is not really on my todo list
<mdevos>Also, I don't want to give an excuse to people writing proprietary software (and/or their companies) to violate the terms of the GPL, a software license that aids in preserving software freedom
<playing>Well yes, you probably better be point me at #gnu, than anwsering.
<playing>Thanks for answers. I am impressed in the idea of building whole system like brick house from single config and rebuilding it like LEGO constructor. This defenitely worth efforts put in it. I see future in this. Now i am leaving, my dear priests of knowledge!