<apteryx>even defining the virtual-machine os with graphic? #f and commenting out '-nographic' from make-marionette, it still runs in terminal mode
<shareni>Hi! Can someone help me out? I've been trying to install guix as an OS in virtualbox, and followed the SystemCrafters video about it. The first time it worked, but when i started updating the system it hung while compiling the new kernel (nonfree). After a few hours I C-c'd and restarted it a few times, but to the same result. After that I've rebooted the VM, and it wouldn't work past grub. Following that I've deleted the vm, and tried
<shareni>reinstalling guix multiple times, following the same steps, but during login it shows the following error: "Sep 20 02:20:59 localhost elogind: /gnu/store/wi0wljc58pf1h2dsgrkw1wksxmz34ljx-logind.conf:11: Failed to parse handle action setting, ignoring:" and it becomes unresponsive.
<ulfvonbelow>graphic? #f? I'm no expert, but that sounds like "off" to me
<zamfofex>shareni: Does it work well with Linux Libre as the kernel? Because if so, then maybe you should ask for help in the forbidden channel. (Proprietary software is not appropriate here.)
<ulfvonbelow>the "Failed to parse handle action setting, ignoring" line is something I've seen before on startup, I think it's caused by an option being set of the form "SomeOption=" - that is, no value set. I think it's fairly benign.
<shareni>zamfofex: i haven't tried it. Is it allowed to say the name of that channel?
<shareni>ulfvonbelow: I've tried googling it but couldn't find any results with that error message. Got any tips where I should look?
<ulfvonbelow>you could look at the file in question and see what's on line 11
<ulfvonbelow>assuming you have some way to access the guest file system from the host
<GNUtoo>shareni: why do you need a nonfree kenrel in a VM? It's probably way easier with the official installer
<GNUtoo>shareni: Also we have interesting alternative to virtualbox, like virt-manager for instance. It's not a drop in replacement though
<GNUtoo>Though it probably have better support for some of the hardware (like USB). The downsides are things like 3D acceleration only working under GNU/Linux.
<shareni>ulfvonbelow: thank you, i'll try to chroot into it
<shareni>GNUtoo: Yeah, but I'm trying it out as my new main distro, and need proprietary drivers for wifi on my laptop. I just picked virtualbox since it first came to mind.
<shareni>GNUtoo: but thank you for the suggestion, i'll have to check it out at some point. Virtualbox really doesn't like i3wm for some reason
<GNUtoo>OK, in the case of virt-manager there are the choice to emulate a wide variety of GPUs (things like "VGA" "cirrus" "virtio", etc) so there is often a way around issues like that
<GNUtoo>Usually the virtio virtual hardware is more efficient though
<shareni>Good to know, but in this case the UI is really buggy. Like when I try to fullscreen it it goes black and unresponsive until I spam i3 fullscreen keybinding and it goes back to the original size. Scaled sort of works, but stretches everything out. It's a mess, but hopefully good enough to figure out installing guix. Def trying out virt-manager next time i need a vm
<shareni>ulfvonbelow: it was "HandleLidSwitchExternalPower=". I've added suspend and ignore, now it's freezing without an error message.
<shareni>same results with the libre kernel. time to try out virt-manager i guess
***Xenguy_ is now known as Xenguy
<shareni>it was virtualbox all along... virt-manager shows the same error, but follows it up with the login screen. Thanks for the help
<apteryx>is 'make check-system TESTS=lightdm' failing for anybody else?
<lechner>for some reason that last version fails to build with Throw to key `match-error' with args `("match" "no matching pattern" #<procedure inputs (a)>)'.
<lilyp>lechner: you still need %build-inputs in make-flags
<lilyp>also you shouldn't refer to (guix build utils) inside (gnu packages) – the (search-input-directory ) call needs to be evaluated at build side IIUC
<ulfvonbelow>lechner: the difference between this-package-input and search-input-directory is, basically, when they are run. this-package-input searches the input labels of the package's inputs and propagated-inputs fields, and returns a corresponding <package>. search-input-directory searches an association list of (label . store-path) pairs for a store-path with a given directory, and returns that directory. in https://www.pastery.net/rydpgy/ whe
<ulfvonbelow>you invoke (search-input-directory inputs ...), the 'inputs' there refers to the <package> field of the same name. If you dropped the #$ in front of (search-input-directory ...), it would instead be evaluated at build-time, in a context where no variable named 'inputs' is bound. %build-inputs, however, is globally-visible at build-time, so you can use that instead.
<ulfvonbelow>the first version you sent (https://www.pastery.net/mxhzae/) would have the same problem we ran into before, since 'this-package-input' still uses input labels to find the package in question, and the input label being searched for is still hard-coded while the fallback input label is still taken from the package name. Note that in that version, you could replace #$(this-package-input "xkeyboard-config") with just #$xkeyboard-config an
<tschilptschilp23>Hi guix! I just noticed a detail -- how can it be that vlc from android sees an (well, not accessible) sftp share on my laptop, while I don't have an ssh-server configured, while nmapping it from another device shows all ports closed? Also, 'netstat -tulpn | grep -i listen' from inside does not report anything?!
<da77a>Hi. Guix seems a good idea. Ive been trying to install guixsd from the 1.3.0 ISO as a virtualbox vm hosted on windows 10. I get errors during the download/install of packages - "substitute .. TLS ... Error in the push function" . This aborts the install but I can resume from the config selections (last step) and it seems to make some progress / get
<da77a>further each time. Any idea what this means/how I can avoid this?
<jpoiret>da77a: I'd suggest using the latest installer instead of the 1.3, that version is now pretty old and we've got a couple of bugfixes on master
<jpoiret>no guarantee that this will resolve your specific problem though
<jpoiret>also, virtualbox is less supported than say QEMU
<jpoiret>anyone know if we have the libc manual in guix?
<jpoiret>ah, i'm stupid, i don't have the glibc package installed, that's the reason
<da77a>jpoiret: I installed the version I found at https://guix.gnu.org/en/download/ - you are saying using latest development build is a "good idea"? As to the platform - for (corporate) reasons I'm running on a windows host and unless things have improved radically QEMU is just too slow on that host. My interest is in running on metal and windows vms as
<da77a>the majority of targets - but its a place to start and a way to have a "dev" host that is usable.
<jpoiret>right, i was just pointing out that you might have issues with that kind of host
<jpoiret>and yes, i am saying that the latest installer should work better than the point release
<ArneBab>I just discovered --tune for guix package. Nice!
<ArneBab>(I’ve been wishing for something like that)
<GNUtoo>seer: later tell gnucode: I've managed to try gnome-clocks on Guix on my X200 (working to fix the i686 breakaga also made it possible for me to try gnome-clocks) and I've the same error than you ("Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory")
<GNUtoo>seer: later tell gnucode: maybe it doesn't work because that library is dlopened somehow
***wielaard is now known as mjw
<florhizome[m]><florhizome[m]> "what does that mean? I don’t..." <- And everything that depends on it 😭
<dgcampea>how does guix manage its network connections by default? I'd like to configure some DHCPv6 DUIDs and IPv6 tokens (this is due to dynamic prefixes from ISP).
***Server sets mode: +Ccntz
<pkill9>somethign we don't see is live demos on web pages for software, using an embedded vnc instance
<lechner>ulfvonbelow: thanks for the explanation! i am inclined to go with #$xkeyboard-config, but would that go against lilyp's position that all input requirements should be "searched" for using relative paths, for an effective decoupling?
<ulfvonbelow>¯\_(ツ)_/¯ I'm not familiar with packaging guidelines, I mostly just package stuff for myself. Using search-input-directory with %build-inputs makes sense, I guess, as long as you know there won't be another input with the same directory that hides what you're actually looking for. Makes it work better with transformations, too (I assume package transformations don't apply to gexp-inputs?)
<lechner>Hi, are there contribution guidelines for core-updates? Which style should be used? Also, guix seem to recompile every time i run 'guix build'
<Reventlov>Hello. Is there something to make guix pull a little bit faster ? I mean, on an up-to-date channel, it takes 2 minutes doing "nothing" (for some definition of nothing)
<lechner>ulfvonbelow lilyp: just replacing inputs with %build-inputs, i get error: %build-inputs: unbound variable
<ulfvonbelow>right, that's because the ungexp #$ is causing it to be evaluated at the same time as the gexp is evaluated instead of being quoted now and evaluated later during the build
<lechner>rekado: this occurs every time i re-enter the enviroment (but without any git checkouts in between). please ignore the errors in the log. i also know, per lilyp, not to include (guix build tools)
<ulfvonbelow>I would think the patch replacing the assoc-ref with search-input-directory would be acceptable, but again, I'm not familiar with the guidelines. Regarding the test failure, I have no clue; only way to know for sure is to see whether it happens without the changes in question.
<fnstudio>hey, i just tried 'guix shell --container guile guile-readline coreutils' and i was surprised that 'ls' shows all files in my home folder... anything i'm missing? shouldn't i be given a clean, isolated environment?
<apteryx>I agree that in general we want to keep things there to avoid re-fetching things all the time, but in the full drive situation we are, I think starting from a clean slate is a good thing to do
<apteryx>then we can recover our unallocated blocks, we verify that zstd compression is enabled, put that balance mcron job and forget about it