<moesasji>The percentage % is typically used for read-only global variables in the build stage. <anadon>localstatedir was set to "/var/guix" when it should have been "/var". <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' <lfam>Is that going to be okay? <lfam>It's not really clear to me what those packages are for, compared to e.g. linux-libre-5.4 <lfam>For example, it seems like the only difference between linux-libre-arm64-generic-5.4 and linux-libre-5.4 is this CONFIG_RTC_DRV_RK808 option <lfam>Am I misunderstanding it? ***evhan is now known as Guest97139
<anadon>It wasn't hard at all. Man I can be slow. <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 <nij>Finally got Guix System working T__T Happy New Year.... <nij>1. Is it normal for the live USB to take 45 minutes to install Guix System? I chose exwm.. so it pulled emacs. But I didn't expect it to take so long. <nij>2. How to configure emacs so it behaves the same as on my arch machine? <atw>nij: nice! re 1, do you know which command accounted for 45 min? re 2, my solution is to keep the same set of emacs packages installed on different computers, and copy my init.el etc <atw>and on guix, I install emacs packages using guix instead of package.el <nij>atw: it take so much time pulling down stuff.. <nij>atw: I'd like to achieve completely reproducible setup. Is it fine with emacs? I remember it's harder to do in my NIXOS experience. <vagrantc>nij: it might be somehow your substitutes were disabled? <vagrantc>or the substitute servers are lagging is another plausible explanation <nij>vagrantc: At some point it did pull down some substitutes @@ <nij>Usually how long does it take for you? <leoprikler>You still have to bootstrap the entire config, which takes time. <leoprikler>I suppose less so in Emacs vs. full GNOME desktop, but still. <leoprikler>I scheduled about 1h per rebuild attempt when I was still experimenting. <nij>Oh no. I'm using the emacs distro doom, but it seems that it isn't well supported yet @@ <nij>That's going to gimme a very hard time as I cannot think without emacs. <leoprikler>But I've also had worse. On one machine just building the kernel took two or three hours. <nij>@@ leoprikler did you find out why? <leoprikler>It is a rather slow machine and it couldn't substitute the kernel. <leoprikler>I knew the former even before I switched to Guix. <leoprikler>And I painfully found out about the latter after desperately trying to make it work.. <leoprikler>Ironic, my fast machine gets substitutes for free :) <nij>How do you configure programs that have an rc file? <nij>And worse.. programs that have an "rc file" and runs its own package manager.. like emacs? <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>vagrantc: Thanks for the answer <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>it's happened to me numerous times over the course of the years and i prefer to fight other battles ... almost never have that problem with the defconfig based kernels <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? <vagrantc>but i think it's only an accident that the arm64-generic is so similar to the guix-maintained linux-libre arm64 kernel config <lfam>`git log -p` is not very helpful for checking on the history of the configs :/ <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 <lfam>I started handling it in August 2020 ... I can't believe it's only been that long <vagrantc>lfam: at one point, i had noticed that they were very similar (maybe even identical) and i tried to figure it out and was exhausted by the end of it <vagrantc>lfam: huge thanks for maintaining that key package! <atw>spudpnds: just in my default profile. I should probably use separate profiles more <atw>but I have not felt an acute need <lfam>You're welcome! It's not really that bad, just a good days work every couple months. Mostly I want to understand it better to see if it can be improved <lfam>Right now I'm just treading water <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>I'm asking these questions now because I'm thinking of buying an $arm-sbc to replace an old laptop I have on home server duty. But I realized that it's not obvious how to use it with Guix System <lfam>For Intel-type chips, there's no question about what kernel to use and how to set things up <vagrantc>could always go with a foreign distro for the core operating system and guix for all the interesting bits <vagrantc>but yeah, picking an arm board can be tricky <atw>good luck spudpnds :) my approach remains to make a best-effort to do stuff idiomatically, but accept hacks that I can clean up later. Using profiles is one of those things <lfam>I usually do that, but this computer is already using Guix System and I'm used to it <lfam>And, I'm in a good position to improve how this stuff works, if I can learn more <vagrantc>i admiteddly mostly only ever used a foreign distro to get to the point of running "guix system init" :) <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 <lfam>So, should I infer that the distro-config kernels don't really work? <vagrantc>lfam: oh, they definitely do sometimes ... e.g. it works fine on the novena <vagrantc>although i've fallen pretty behind on testing arm/arm64 devices on guix ... new version of u-boot in january will probably get me to do some testing again ... <ryanprior>is somebody building Guix System for the Pinebook Pro? <vagrantc>not recently, but i've got a month-or-two-or-three old build <spudpnds>I notice that all the files in /gnu/store have a literal "1" epoch for mtime. Interesting that this has to do with a caching hack that nginx uses. <dissoc>in make-linux-libre shouldnt config->string support int as well? ***ChanServ sets mode: +o lfam
***ChanServ sets mode: +q nick!username@host
***ChanServ sets mode: +q *!*@bras-vprn-ckvlon0125w-lp130-02-174-89-20-211.dsl.bell.ca
***ChanServ sets mode: -o lfam
<GNUtoo>profmakx: I bugreported for the lime2 and it turned out that I didn't use guix system disk-image <GNUtoo>profmakx: the correct usage is guix system disk-image --target=arm-linux-gnueabihf -t arm32-raw ./file.scm <GNUtoo>If I do that with my minimal lime2.scm and I dd the result on a microSD it boots fine <GNUtoo>The thing is that under the hood it works fine because the partition with the sylinux.conf is the first partition <GNUtoo>(as defined by the distro boot protocol which u-boot uses it either try partitions that have the bootable flag or the first partition) <GNUtoo>So I'm unsure if your board which used a Rockchip SOC is 32bit or 64bit but you might want to check out the various -t options <GNUtoo>On my side since that works I'll be able to try to fix the rest of the boards and add the boards I have as well <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 <GNUtoo>Do you know about the pinebook pro? <GNUtoo>I'd be interested to know what doesn't work without the nonfree dptx firmware <GNUtoo>Also there might be a way to add an ath9k in it <GNUtoo>vagrantc: someone made an adapter for WiFi modules, I've documented it a bit in the libreplanet wiki <GNUtoo>It's some nonfree firmware that seem to be needed for external displays <vagrantc>i've only used the usb wifi and usb ethernet adapters for my various pinebooks <GNUtoo>ok nice, so there is only the external display connector that doesn't work right? <vagrantc>but yes, i have one ... and pushed some commits to the wip-pinebook-pro branch on guix, but it still needed patches to the kernel <GNUtoo>And thinkpenguin probably has compatible ath9k <GNUtoo>It probably need to be tried as I'm not familiar with theses ngff formats <GNUtoo>(the NVMe is connected through PCIe so it probably has DMA access to the RAM, and DMA engines are typically not configured correctly) <GNUtoo>I've checked the schematics and there is only PCIe being exported to the NVMe adapter <GNUtoo>(The SOC pins don't seem to be able to be reconfigured to something else like SATA) <vagrantc>dangerous as in a malicious NVMe device might compromise the system? <vagrantc>same could be said of a wifi device or any PCIe device, no? <GNUtoo>It'd be easier for an NVMe as it has an internal nonfree firmware <GNUtoo>So the hardware could still be malicious <GNUtoo>vagrantc: btw, what is missing with the upstream kernel? <vagrantc>GNUtoo: take a look at the wip-pinebook-pro branch ... admittedly i think it is a couple versions behind (maybe linux-libre 5.8) <vagrantc>GNUtoo: newer kernels might not need all of the patches, but i did not get the impression everything was upstreamed yet <GNUtoo>Some are probably not strictly needed though as the functionality is not critical <GNUtoo>like this one for instance: %D%/packages/patches/pinebook-pro-03-firmware-Add-Rockchip-SIP-driver.patch <vagrantc>i tried to pare it down less than that and never quite succeeded <vagrantc>would be happy for someone else to try :) <GNUtoo>I don't have a pinebook unfortunately <GNUtoo>And If I'd have one I wound't use it as it doesn't have enough space on somewhat "safe" storage <vagrantc>the keyboard firmware is also probably an issue ... i've gotten silence when asking to get the source for it <GNUtoo>+ I use the Tor browser which isn't ported on ARM and probably need more modifications to be in FSDG distros (like disabling the add-on repository) <GNUtoo>so the ec is probably nonfree as well <GNUtoo>It's probably less horible than x86 with ME at least <GNUtoo>but EC can become keyloggers.... <GNUtoo>users can probably live without pinebook-pro-01-leds-Add-support-for-inverted-LED-triggers.patch <GNUtoo>ah the SPI patch probably needs to be kept in <GNUtoo>It's needed for power management purposes <GNUtoo>it's a free fimrware that handles power management <GNUtoo>pinebook-pro-02-soc-rockchip-Add-rockchip-suspend-mode-driver.patch can probably be removed if the u-boot is recent enough and handles it instead <GNUtoo>for pinebook-pro-04-tty-serdev-support-shutdown-op.patch you'd need to look what driver really uses that <GNUtoo>maybe people can live without bluetooth <GNUtoo>this only affect the internal wifi which doesn't work anyway: pinebook-pro-07-mmc-core-pwrseq_simple-disable-mmc-power-on-shutdown.patch <GNUtoo>pinebook-pro-08-regulator-core-add-generic-suspend-states-support.patch looks strange <GNUtoo>pinebook-pro-09-usb-typec-bus-Catch-crash-due-to-partner-NULL-value.patch is fixed upstream according to the patch description <GNUtoo>pinebook-pro-10-usb-typec-tcpm-add-hacky-generic-altmode-support.patch I'm unsure what things are exported on the USB C alt mode <vagrantc>i maintain ATF in debian and guix, for the most part :) <GNUtoo>Ah probably USBC host / device + external display (which doesn't work without dptx.bin AFAIK) <GNUtoo>so it's probably acceptable without it <vagrantc>GNUtoo: i agree many of those shouldn't be necessary ... but many of my attempts to remove them resulted in a non-booting kernel ... which isn't to say i did it correctly <vagrantc>i've also listened to my boot logs on speakers ... makes some interesting squeals :) <GNUtoo>this looks strange but important: pinebook-pro-13-sound-soc-codecs-es8316-Run-micdetect-only-if-jack-s.patch <vagrantc>it was interestingly useful to at least know there was output on the console :) <GNUtoo>the commit description doesn't seem to match what the code does <GNUtoo>it looks like code to prevent a NULL pointer <vagrantc>there appears to be a v5.10 branch, at least ... i should refresh the patches <GNUtoo>ah pinebook-pro-14-ASoC-soc-jack.c-supported-inverted-jack-detect-GPIOs.patch could probably be replaced by a dts patch instead <GNUtoo>like the GPIO can be active high or active low <GNUtoo>there is even a define for that that is commonly used in dts <GNUtoo>it's probably also wise to backport that: pinebook-pro-16-arm64-dts-rockchip-enable-earlycon.patch *GNUtoo is unsure that word exists <GNUtoo>Do you know if their ATF patches are really needed? <GNUtoo>In this 5.8 there are many patches that can be droped (the ones I mentioned above ) <vagrantc>there's also dropping the patch, but then having to rebase all the subsequent patches <vagrantc>that might have been enough of a blocker <GNUtoo>ah that's usually fast if they don't depend on each other <GNUtoo>The leds patch is probably standalone for instance <vagrantc>when i next boot my pinebook pro, i'll try to refresh the branch <GNUtoo>the tty/bluetooth ones seem to go together <GNUtoo>The issue is if you can drop the power management / ATF ones or not <GNUtoo>The altmodes ones can probably dropped too <GNUtoo>It'd be interesting to have more ARM laptops <vagrantc>this is the first one i've found that's both affordable and not horrifically slow <GNUtoo>In Parabola some people added a chromebook but it's in a similar situation and they don't have UART on it... <vagrantc>though i used the earlier pinebook as my primary machine for the better part of last year <GNUtoo>like they depended on a custom kernel and then probably abandonned I'm not sure <GNUtoo>Whereas if it can be somewhat usable with mainline at least it could be kept for a very very very long time <GNUtoo>(people can understand why it doesn't boot if it's some simple stuff) <vagrantc>or at least getting the patches on 5.10, which will be an LTS kernel <GNUtoo>As for slow there are probably benchmarks *GNUtoo ported phoronix-test-suite to Parabola <GNUtoo>Though it was done through a horrible hack <GNUtoo>but at least we can have some benchmarks with that <GNUtoo>like basic compilation benchmarks *GNUtoo guesses that ARM computers would be quite fast with that but would be slower in other situations with IOs <GNUtoo>(less cache, slower busses and so on) <GNUtoo>Like between a Thinkpad X200 and a Pinebook PRO, the pinebook might be faster to compile things in some specific configurations *GNUtoo badly need to go to sleep <GNUtoo>Thanks for all the infos on that device *GNUtoo updated the libreplanet page <GNUtoo>feel free to fix any mistakes if any or improve it <wleslie>I solved my bison woes: turns out I had checked in a build artifact v____v; <ride>Does anyone here use pipewire on guix system? I am interested in the ability to use programs requiring both jack and pulseaudio. I have had issues with jack in the past. <raid5atemyhomewo>I defined my own zfs package with a custom #:linux using linux-libre-5.4, which got ZFS compiling and installed for me <raid5atemyhomewo>but when I use `zpool create tank vda3` inside a QEMU container, it gives "cannot mount 'tank': Input/output error" <raid5atemyhomewo>I've tried reformatting the same partition as EXT4 and mounting it and had no problems with it <ryanprior>I've managed to panic my kernel a few times running jack and pd :\ <ryanprior>I haven't tried pipewire yet but I'm interested <leoprikler>raid5atemyhomewo: At the very least there's no config.scm support for ZFS ,so that's that. <leoprikler>Don't know if people were able to successfully mount a partition otherwise. <raid5atemyhomewo>supposedly ZFS will auto-mount detected partitions at boot so does not need file-system support <raid5atemyhomewo>but I can't even get a newly-created pool to mount, never mind checking ZFS at boot <leoprikler>Are we talking about expected ZFS behaviour in Guix System here or are we talking about what ZFS would normally do if it were running on a different system? <raid5atemyhomewo>I added the module to kernel-loadable-modules and created a service to modprobe it as well <raid5atemyhomewo>so it's loaded and the userspace ZFS tools are at least not complaining about ZFS module not existing <raid5atemyhomewo>and when I look in partition editors the partition did get marked as a zfs <raid5atemyhomewo>has there been anyone at all who has managed to get ZFS working on Guix? <ryanprior>If I have a patch in my own repo and I'm building a package by putting my repo on the load path (eg guix build -L/path/to/my/repo) how do I get Guix to find it? <leoprikler>ryanprior: either put it at the root or define your own search-patches <raid5atemyhomewo>leoprikler: given that `guix install zfs` leads to compilation errors nowadays due to guix using 5.10 by default, I don't know if there even *is* an expected ZFS-on-guix <leoprikler>once again, Guix certainly doesn't come with config.scm support for it <ryanprior>leoprikler: thanks, putting it in the root worked fine. <raid5atemyhomewo>but it *does* have a zfs package, so I expect it's possible to get ZFS loaded somehow and at least mountable *after* boot <leoprikler>the sad state of the matter is, that not all packages in Guix are working all the time <raid5atemyhomewo>yes, so that is why I'm asking if anyone has managed to get ZFS working in the past <raid5atemyhomewo>so maybe I can try using older versions of packages that were current at around that time <ryanprior>raid5atemyhomewo: if you don't get an answer you might post to the mailing list, I imagine more people will see it that way. <ryanprior>you might also look at git blame and see who's touched the zfs package in the past (I can help with that if you aren't handy with git blame) <raid5atemyhomewo>as far as I understood it, Efraim Flashner just packaged it without actually testing it <raid5atemyhomewo>because I trawled older IRC logs and that's the gist of what I understood <ryanprior>ah okay, if he did that then maybe he was being optimistic about how much time he'd have to test it & get it working '=D <raid5atemyhomewo>ha! strace showed that `zfs mount` was secretly calling into `mount`, with a special option `zfsutil` to suppress the normal warning if using `mount` directly <raid5atemyhomewo>so looks like there is a missing patch in the compilation, where we have to give the `mount` executable somehow. <raid5atemyhomewo>so that the compiled `zfs` tools will access the correct `mount` location <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? <raid5atemyhomewo>hopefully somebody tries out actual disks in an actual non-virtual env and sees if ZFS works on Guix now <abcdw>How to make geiser-edit-symbol-at-point go to definition of operating-system? It works on (format #t "str"), works on (gnu system), but doesn't on operating-system :/ <moesasji>would be great if someone could take zfs to the point guix could boot from it. <abcdw>moesasji, it's just two separate lines. seems fine to me <abcdw>but comparing to commands above, it laks $ prompt, which can be confusing <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? <oiur>I will look into the mailing list, thanks <moesasji>oiur: not a problem I've had, but the thread I posted removed something from a service. <oiur>Thanks I will try it. Btw do I have to restart after `guix system reconfigure`? <NieDzejkob>Hmm, guix download considers all certificates invalid on bayfront <oiur>mdevos: It worked! Thanks :) Should I open an issue or something to remove synaptic from the default modules? <NieDzejkob>oiur: Most changes will take effect immediately, but if you want to get an updated kernel, for example, then you'll need to restart <mdevos>oiur: seems a good idea! I'll reconfigure my system without xf86-input-synaptics, perhaps that's the reason I couldn't modify the pointer speed <davidl>janneke: hi, the config is very simple: (service hurd-vm-service-type <davidl> (disk-size (* 20000 (expt 2 20))) <davidl> ;;(disk-size (* 12 (expt 2 30))) ;12GiB <profmakx>GNUtoo: biggest problem with image creation for rockpro/pinebook-pro seems to be that it doesn't use the correct image layout by default, though the code seems to be there <janneke>davidl: maybe we need a bug report... <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 / ? <janneke>davidl: resizing a childhurd vm is not possible, as it lives in the store and thus is read only <apteryx>rekado_: re texlive package names, that is useful. I found out I can install 'texlive-base' to have the tlpdb command line useful to query the database. <apteryx>any idea why 'kpsewhich -var-value=SELFAUTOPARENT' returns /gnu/store? <davidl>janneke: but changing the size in the config should generate a new hurd-vm with a different size, right, such that next time you connec to it, it would have a different size? <janneke>davidl: indeed, new config, new image <davidl>thats what doesnt' seem to happen unfortunately. <davidl>or at least not a new one with a different size <apteryx>about SELFAUTOPARENT; that's how its defined (grandparent directory of the executable) <roptat>Rovanion, what if you add -C (--container) to the guix environment command-line? <nij>How do you configure emacs in GUIX System? Or have you seen any great example? <Rovanion>roptat: Builds fine inside the env and runs outside it. (Doesn't run inside due to the lack of X.) <rekado_>nij: I just install all my Emacs packages with Guix into a separate profile. <nij>rekado_: Are all emacs packages packaged in Guix ?! <nij>Hmm.. seems that many of them are packaged already. <nij>Not sure what's the "right way" (if any) to handle emacs package here.. <nij>Should I stop using Melpa? <barbanegra>nij: I am not saying /you have to/, but I did because everything I need is on guix <roptat>I'm trying to build it locally, but guix needs to build opencv first; can you share the complete build log somewhere? <nij>barbanegra == rekado_ ?? <nij>barbanegra: Oh. Thank you! <nij>I ask because I don't really know how it works.. like maybe GUIX has a magic lifter that handles all emacs package on the fly. <Rovanion>roptat: Just made a fresh clone and it built in the container. Do you want the build log from a guix package run or from a guix environment run? <guixy>It looks like nss certs are outdated. <roptat>Rovanion, from a guix package run <tecosaur_>Hi All! I'm having issues packaging two pieces of software (gitea and dendrite) and I'm somewhat stumped. Where would the right place to ask for help be: Here? Guix-help? Guix-devel? <Rovanion>I'm receiving help here right now about packing Nomacs. Have also gotten help on guix-devel. Not sure if its the right places though :) <gnutec>I did upgrade my guix system to kernel 5.10.4 and everything goes right. :-) <janneke>guix system: error: gnu/packages/glib.scm:181:2: glib@2.62.6: build system `meson' does not support cross builds <gnutec>guix pull then sudo guix system reconfigure /etc/config.scm <janneke>davidl: oh the irony, it appears the childhurd service is broken on master? <anadon>Wait, glib switched to meson? I mean, I wouldn't expect that to cause problems but that particular change surprises me. <gnutec>janneke, how do I know that I using meson? <gnutec>janneke, Got it! I did not pay attention to the update menssage. <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 <sneek>I last saw lfam in #guix 15 hours ago, saying: Which is what we have. <raid5atemyhomewo>is there some way to define a service that starts *before* root-file-system? <mdevos1>raid5atemyhomewo: perhaps you can do what you need to do in the initrd? (note: I'm not familiar with ZFS) <mdevos1>sneek: later rell raid5atemyhomewo: perhaps you can do what you need to do in the initrd? (note: I'm not familiar with ZFS) <raid5atemyhomewo>it now requests for password at a "quiet" time before other service start spamming the console <mdevos1>You're trying to make it possible to boot from an encrypted root / that's partitioned as ZFS, correct? <raid5atemyhomewo>I'm trying to mount an encrypted ZFS filesystem in an ordinary mountpoint /tank/fs <raid5atemyhomewo>so at the ZFS-loading service (which modprobes zfs and then does `zpool import -a -l`), it now pauses <raid5atemyhomewo>`zpool import -a -l` will prompt for a passphrase for each encrypted ZFS filesystem it found <raid5atemyhomewo>normally `zpool` will print something like "Enter passphrase for 'tank/fs':" <raid5atemyhomewo>if I mistype the passphrase then `zpool import -a -l` prints an error message saying it can't open <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. <raid5atemyhomewo>it seems to pause at the "correct" point in the boot sequence, i.e. when / is already mounted <raid5atemyhomewo>otherwise I'd have to go make a statically-linked variant of the ZFS tools and that sounds even scarier... <mdevos1>sorry, I've no ideas to offer anymore <raid5atemyhomewo>I mean does system* propagate the (current-input-port) of guile to the child process? <mdevos1>try guile -c '(system* "cat" "/dev/stdout")' <mdevos1>and type some text, it will be echoed back <mdevos1>(at least in a GUI terminal I opened) *mdevos1 afk, I've some other things todo, <raid5atemyhomewo>trying to use (with-output-to-port (current-error-port) (system* #$zpool "import" "-a" "-l")) doesn't work, zpool still won't print to console <raid5atemyhomewo>gnu/build/file-systems.scm: 'current-output-port' is typically connected to /dev/klog (in PID 1) <philipper905>I get error: unsupported manifest format when trying to run guix install <raid5atemyhomewo>no, I was using with-output-to-port and with-output-to-file incorrectly, it needs a lambda wrapper!!! <philipper905>is there some command to return guix to some working state? <raid5atemyhomewo>I'll leave the ZFS-on-root when I have like a whole three months of free time <mdevos1>philipper905: perhaps look at /var/guix/profiles/per-user/$SOME_NAME/current-guix-$NUMBER-link/bin/guix if you need a working guix? <tecosaur_>anyone got experience packaging something which uses node/npm? <mdevos1>also, apparently (at least on Guix System), ~/.guix-profile isn't created on install. Perhaps you could ‘mv ~/.guix-profile ~/guix-profille-borken’ and install packages again? <philipper905>mdevos: yeah I have access to guix executable the problem is that it error when trying to run guix insall, guix package... <mdevos1>I don't know why the error happens, but the ~/.guix-profile directory could just be moved aside, and you could install packages afresh? (note: I haven't tried) <tecosaur_>Also, should I go to guix-devel or guix-help with an issue like this? <mdevos1>tecosaur_: I would think guix-devel. At guix days, there was a talk about npm, node and etc. Apparently, it's a complicated situation, but I don't know the details. But before you do: <mdevos1>guix tries to make builds of packages reproducible, so packages aren't supposed to contact the network. <tecosaur_>metalune[m]: I think it depends o your hardware <mdevos1>metalune[m]: It's working fine for me, though your mileage may vary I suppose <metalune[m]>I guess I'll have to buy a new wifi chip and then flash my bios <mdevos1>It depends on your laptop I suppose. <raid5atemyhomewo>most laptop wifis won't work, you could try looking for open USB wifis elsewhere <ryanprior>raid5atemyhomewo: big congrats on getting it working <metalune[m]>but I'll need to flash my bios so I can remove the wifi card whitelist <Rovanion>Huh, now I have to build OpenCV on my own machine. Has that always been a thing? <atom`>I'm in the process of making a bug report for my issues with U2F in IceCat in Guix (which are not present in ungoogled-chromium). I wanted to try to see if the same issue is there in Firefox. <mdevos1>also, downloaded binaries are unlikely to work on guix, as guix hardcodes the library path (a long /gnu/store/... in Guix), which can help with using multiple versions of the same package <ryanprior>atom`: did you try running "guix environment icecat" and then running the binary again? <atom`>ryanprior: I will give it a try <ryanprior>You might also try running Firefox in flatpak <atom`>I'm not sure if U2F would work with Flatpak. I'm really just hoping to see if U2F works there to see if there may be something wrong with the IceCat package <ryanprior>I run Firefox in a flatpak and U2F works for me. I'm not on Guix System though. <atom`>ryanprior: Same problem with the executable in "guix environment icecat" <atom`>OK I will install Flatpak and try that version <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! <ride>ryanprior: It sure does. 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.. <ryanprior>nij: to get more detail than the manual provides, you'll have to read the source code for the build systems. Check out the "guix/build" and "guix/build-system" directories. <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? <nij>ryanprior: Thanks for the tip :D <atom`>When defining a recipe with (method git-fetch), how do you find the base32 sha256 hash? <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 <mdevos>(Note: I've upgraded guix with guix pull on both machines) <constfun>cbaines: ah, wish i had seen your message earlier, ended up pushing the repo an all that, it reports 347mb <cbaines>mdevos, have you authorized substitutes from the machine you're trying to fetch them from? <cbaines>constfun, OK, so as described earlier, if you want to reduce the size of the pack, I'd reduce the size of the closure for the package store item (that's what guix size is telling you) <mdevos>(That's an example from the log output) <mdevos>the exact command I'm running: ‘guix build -L . -f system-config/twinkling-star.scm --substitute-urls=http://butterfly.local:8080 --sources=transitive --no-substitutes' <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? <constfun>cbaines: thank you very much! ill dig in <playing>So what is that freedom everyone is cared so much? <playing>I think greatest things are simple. And if you cant explain something short and simple - its probably wrong. <Rovanion>I think you may be wrong or trolling, then. <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>Sorry, didnt find in docs so far. Here is just short question: is Guix System uses Hurd? <leoprikler>You can configure Guix to use the Hurd in some capacity, but it's a bit far away from last year's April Fools. <leoprikler>As far as I am aware, one has yet to roll it out on actual hardware. <playing>Is guess i can choose in declaration config between Hurd and Linux? *profmakx tried it the other day ***lfam_ is now known as lfam
<leoprikler>tfw you garbage collect the environment you used for compilation <leoprikler>but you can gc stuff, that's only referenced in files <ryanprior>It there any way to register a manifest file as a gc root? <leoprikler>ryanprior: how would that even work? A GC root is a directory normally. <lfam>`guix environment -m manifest --root=/tmp/my-root` <lfam>Is that the kind of thing you meant? <leoprikler>playing: as far as documentation goes, it says that you can choose a different kernel, but it's currently best to have linux-libre[-VERSION] <ryanprior>Ah okay, so if I want to gc without trashing what's in my manifest, I can do that and then unlink /tmp/my-root later if I don't care about that manifest anymore? <lfam>Yes, but it will be the result of the manifest that is protected from garbage collection <lfam>I think that's what you wanted, right? The manifest file itself is not subject to garbage collection in any case <ryanprior>No right for sure. I meant its specified contents. <efraim>I normally use 'guix package --list-profiles' <lfam>I believe they are all linked in /var/guix/gcroots, which that command should make use of <ryanprior>Only 240 things linked in /var/guix/gcroots though <leoprikler>iow you have like 100 generations worth of content <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! <cbaines>jonsger, I prefix the command I'm running with PATH="/gnu/store/6843f93hfr54ds5zzl7ik3h5njgicy0w-opensmtpd-6.6.4p1/sbin:$PATH" so I use an older working version <leoprikler>building systems from a specification is a wild and outlandish idea, that has never been done before <jonsger>cbaines: I'm trying to setup opensmtpd but it refuses to start as service. Don't have any error message at hand, so it was more a guess <cbaines>hmm, I think I'm running the service fine, at least smtpd