<nckx>For some reason, grafting a #:tests? #f variant feels so much dirtier than a totally different minor version.
<reepca>so on a machine with 32 cores each run-fibers invocation would leak 31 * 3 = 93 file descriptors.
<civodul>reepca: OTOH there's normally only one such call, right?
<reepca>for long-lived server processes along the lines of spawning a fiber for each client, aye
<reepca>for the fibers tests, on the other hand... I count 11 calls to run-fibers in tests/basic.scm prior to the failure at https://paste.debian.net/1148206/. (* 11 93) = 1023, and the limit is typically 1024. So it would absolutely make sense that that resource leak is what's causing the test failures.
<civodul>reepca: oooh, got it, that sounds plausible
<civodul>would be interesting to run the tests against current master
<reepca>actually something that's been puzzling me is that close-port, when called explicitly, ignores the port-revealed count. There's a guardian set up in (fibers epoll) that should be explicitly closing all the file descriptors used using close-port/close-fdes. That suggests to me that even if the port-revealed counts are fixed, it would still take long enough for the fds to actually be closed that the tests would likely still fail.
<civodul>first we should make sure (fibers epoll) explicitly closes FDs
<reepca>also, running the gc doesn't actually guarantee that any arbitrary dead object will be collected. For example, I just ran a test where I had to run (gc) twice before the guardian actually got an object to be finalized.
<reepca>well, (fibers epoll) closes them explicitly, the issue is that run-fibers in (fibers) doesn't explicitly delete the peer schedulers
<reepca>so since destroy-scheduler isn't called, epoll-destroy isn't called
<malaclyps>ohh i'm in too deep now... I'm running wayland via sway, and launching from sddm (which uses elogind). Everything works okay, but I'm not getting the DBUS environment variables set correctly
<malaclyps>i guess i could hack a workaround by using dbus-launch to start sway, but sddm should be managing that
<malaclyps>honestly i can't help feeling sddm is overkill for this (it pulls in qt and postgresql!) but i think this is a bug
<nckx>tho1efx: Which versions of GCC (etc.) and Linux-Libre enable this? There'd be your answer. It's not a distro-specific thing.
<nckx>tho1efx: Would you like to work on this in Guix?
<tho1efx>I'd like to work on a lot of things I don't know how to do but I'll stick with getting this package finished and upstream for now.
***catonano_ is now known as catonano
<nckx>tho1efx: Seems like I was overly optimistic too (I'd been reading about this but not closely, I'm years away from owning such hardware): the GCC default for -mbranch-protection isn't ‘standard’… but ‘none’. :-/
<nckx>One can only hope that such bizarre naming means it will become the default some day.
<nckx>RRedcroft: Replace your slim-service-type's ‘(xorg-configuration’ with ‘(xorg-configuration (xorg-configuration’ [sic] and all will be well.
<nckx>The outer one is the field name (in the slim-configuration record), the inner one is a record constructor — the procedure Guile was trying to call, when it found keyboard-layout and tried to call that.
<malaclyps>GUIX_LOCPATH is defined in /etc/environment on my machine as /run/current-system/locale -- is there somewhere else where ~/.guix-profile/lib/locale should be added? Or should GUIX_LOCPATH not have a value at all on Guix Systems?
<apteryx>malaclyps: I haven't touched it on my system, and it's defined to /run/current-system/locale
<apteryx>but that means my system locale is being used for any profile, so my system profile and my user profile must stay relatively in sync
<malaclyps>apteryx, yeah -- at the very least, I have guile 3 in my user profile, which uses a different glib, so the locale info isn't in /run/current-system/locale
<malaclyps>(or it is, but it's under a different glib version directory)
<malaclyps>I'm going to try to upgrade my system via guix system reconfigure, see if that fixes it
<apteryx>another strange thing happened after updating my machine to core-updates and *not* rebooting: domain name resolution started to fail in docker
<fvr>In the graphical installation, everytime I click on anything in the partitioning menu it loops back to the first step of the installation
<apteryx>'sudo herd restart containerd' wouldn't help
<apteryx>s/core-updates/master post core-updates merge/
<ryanprior>I use the Jami Debian package currently. It's been the most stable in terms of reliability during calls.
<ryanprior>I've tried the Guix package and the Snap and they were both disasters.
<bdju>Anyone use btrfs on a personal laptop? I might do so for my upcoming Guix System install, but I heard it's slower than ext4.
<xelxebar>bdju: I use btrfs. Both btrfs and ext4 are comparable speed-wise for "general use." The reason I use btrfs is for some of its features. Using subvolumes I can multi-boot distributions without the need for hard partition divisions.
<xelxebar>Also, the transparent compression is nice.
<bdju>xelxebar: thank you. it will be my first time using btrfs and I feel better about it now
<xelxebar>bdju: Well, I'd recommend doing some research first. There are some gotchas for users, like the output of df and du not being accurate do to the btrfs data model, compression, etc.
<xelxebar>Also, it pays to learn a bit how to use the btrfs cli tool.
<marusich>I tried building the bootstrap binaries myself, and it failed to build a dependency (sed). I'm trying again; maybe it was a nondeterministic failure on my end. I am going to try to set up a Fedora installation on a VM using qemu-system-ppc64; it might be useeful.
<marusich>Curiously, my reply doesn't show up in the web interface. But I think maybe you'll see it in email, or if you check debbugs via Emacs?
<bdju>Does anyone know how to configure the keyboard layout for the TTY and/or display manager on Guix System?
<bdju>So that I can have dvorak straight from booting.
<marusich>I am using a x86_64-linux system (my x200 laptop) to build this by the way. I got the dependencies using 'guix environment --pure guix' using guix version 5e3d169945935b53325e6b738a307ba286751259, and then I built your guix manually. Then I ran './pre-inst-env guix build --target=powerpc64-linux-gnu bootstrap-tarballs'
<bdju>NixOS has "console.keyMap" and "services.xserver.xkbVariant" where I've set dvorak...
<marusich>I ask because on some systems like Fedora, /tmp is a tmpfs, and depending on RAM size, it can be quite small.
<marusich>If Guix says it ran out of space, it probably means it ran out of space in /tmp (or wherever your TMPDIR env var points), or in /gnu/store. I'd check both. And just because it ran out of space when the problem occurred, doesn't mean there will be no space left now.
<marusich>This is because when Guix fails to build something, it may clean up the build artifacts that failed, unless you told it to keep them around, like with --keep-failed for example.
<fvr>When I rerun the command it immediately fails
<marusich>Maybe the destination of your "guix system init" command is full?
<marusich>Without seeing details it's hard to say. It would be helpful to see exactly what command you ran, what the error was, and what the output of something like "df -h" is.
<fvr>Okay, it's on a different system. So hard to copy it here.
<marusich>Could you show me the output of just "df -h"?
<marusich>I see that /mnt/tmp lives in /mnt, but if you are using Guix to install something into /mnt, it is probably going to be using /tmp, not /mnt/tmp, to build stuff.
<fvr>I am following the manual installation instructions to install
<fvr>just "df -h", has tmpfs at 16G mounted on /dev/shm
<boeg>I have installed slock and added `(screen-locker-service slock "slock")` to my list of services in my operating-system config, but my screen is not locked after suspending and then waking up my device again. Any idea why?
<fvr>and there is a "none" filesystem mounted at /gnu/store with 6% usage
<boeg>do I need to do something more than those two things?
<marusich>boeg, I'm not sure. I haven't set it up before, myself.
<marusich>Oh wait, you're asking about the screen lockers... I have set up the xscreensaver locker before... I recall there is some extra stuff you have to do. For slock, I'm not sure. I suggest you search the guix-devel and help-guix email lists for the keywords "screen-locker-service" and "slock".
<marusich>OK. I recall the screen locking was tricky to get right for me. But yeah...I'm not sure. I don't know what slock requires, haven't used it before. Does "xlock" work if you try the documented stuff in the manual?
<fvr>That's how it looks like ocasionally there is some service has started message
<marusich>To unblock yourself, you could do something like "while sleep 1; do echo -n > /var/log/debug; echo -n /var/log/message" (as root probably), and maybe you'll be able to run "guix system init". And then maybe the problem won't occur when you reboot into the new Guix system. But...what is the message?
<marusich>Weird. Maybe linux-libre isn't interacting well with your video hardware.
<fvr>That might be it. There is flickering on the right side of my screen continuously
<marusich>I had a problem with a machine a while back where linux-libre frequently logged info about my wifi card, since it wasn't supported... It spammed up /var/log/messages, and ultimately I just didn't use that laptop with Guix System.
<fvr>"guix pull" is taking a lot of time. Is this expected?
<jojoz[m]>fvr: Like really long without apparent progress? I had an issue like that a couple of weeks ago. When I canceled with Ctrl-C it had broken the Guix binary. This is my filed issue in case it's the same for you https://issues.guix.gnu.org/41158
<marusich>fvr, it can take a long time. Progress should be made. If it sits for more than an hour without appearing to do anything at all, it's suspicious. Usually guix pull takes only minutes.
<rekado_>our pandoc includes statically linked stuff like this 51M file: /gnu/store/g6yzx6h1jrlxvn3nwx39anrnaxym49wl-ghc-pandoc-2.7.3/lib/ghc-8.6.5/pandoc-2.7.3/libHSpandoc-2.7.3-LYkkrawZQEL5OFii32JPAh.a
<fvr>I canceled it after 40 mins, it looked like it was doing something the first few minutes (disk increase) but then nothing for the rest 30 mins. So I cancelled and am just running init, it's downloading and installing a lot of packages
<fvr>rekado_: Haskell programs are in general very large, unless built otherwise. Haskell ide engine is 171M on my system
***CustosLimen_ is now known as CustosLimen
<rekado_>I think we’re including too much in the build output, though
<rekado_>each of the packages I looked at includes that oddly named static library, which we probably shouldn’t include
<rekado_>for Haskell packages with lots of dependencies this adds up quickly
<rekado_>I’ll look at the build system to see what we can do here.
<fvr>rekado_: The libHSpandoc is probably mostly essential though, it should contain the core functionality minus any executable related stuff like cmd line parsing and the like
<rekado_>we’ve got both a shared object *and* a statically linked one
<fvr>Usually Haskell packages are built with static linking, that can be avoided I think. I guess Fedora is doing the same thing
<rekado_>we may also want to split the documentation to a separate output by default
<fvr>Oh, that's like the default build style if use cabal. I'm new to guix, can you point me where to look at the code that builds haskell packages
<rekado_>guix/build/haskell-build-system.scm and guix/build-system/haskell.scm
<rekado_>the build system splits things when multiple outputs are provided
<rekado_>I’ll just add a few to those packages that have more than 2MB documentation
<bdju>I'm doing a guix system install and it never asked me a file system, but I see in the config file preview it says ext4. how do I choose btrfs? do I hit exit?
<bdju>or can I just edit the file to say btrfs and then apply it?
<bdju>the wget command to import the key wasn't working so I manually saved the file and then imported it
<bdju>oh wait, ignore that, I had done open with by accident at first and extracted the iso, then started downloading normally, then paused it. this is the unextracted thing I'm verifying so it's half-downloaded
<fvr>Bringing down the refresh rate to 120 Hz from 144 removed the flicker on the screen. It's still logging the error message though and scrolling and any movement is not smooth. Looking at nouveau's FeatureMatrix it doesn't look like my GPU has support yet
<lprndn>bdju: just in case. it seems one can check if they booted as EFI checking if /sys/firmware/efi exist. Otherwise, your configuration is probably fine as bootloader/grub happens atthe very end of the install phase.
<bdju>I'm so far not editing the generated config much, also I've started over entirely a half dozen times already
<mbakke>lprndn: I think the installer does exactly that to determine whether to use grub-efi-bootloader or not
<mbakke>not sure why it goes wrong so often, based on IRC feedback
<boeg>50% of the time when I reboot, my cursor (in xorg) doesn't work properly. Its stuck moving only vertically. The other half it works fine. It's not "reconfigure and reboot", it just reboot, no reconfigure, no changes. Any ideas what is going wrong?
<jonsger>rndd: which software did you use for testing your webcam? a browser, cheese?
<dfeng>My main computer is a Raspberry pi 4. It seems to me that this type of equipment is considered private. In short, I would have liked to have a description of the Guix tree structure in order to be able to develop a system image adapted to this device. Currently, I have vague Scheme notions because I'm still busy learning Emacs Lisp (I'm temporarily trying to avoid mixing the two languages as much as possible).
<rndd>jonsger: thank you for this link. i installed cheese, but still no device found. next step in the article is "ls -ltr /dev/video*" . but i don't have any /dev/video. article says that troubleshooting higly depend on distribution i use. did anyone has such problem
<rndd>jonsger: i need hwinfo command. but dont now how to install it
<sturm1>Has anyone had linphone working? It doesn't seem to connect to the SIP server for me.
<NieDzejkob>jonsger: huh, that might be because I got it from `guix environment --ad-hoc cheese` and I don't use gnome
<sammich>hey, i made a guix pack of emacs/emacs-vterm so i could use it on a remote environment, whenever i run anything that invokes root i get 'sudo: effective uid is not 0, is sudo installed setuid root?' How should i work around this?
<rndd>what to do if i have error "no cc comand found" when i'm vuilding from source
<rekado_>the lack of an appropriate error message is not good. Could you please submit a report to email@example.com? The error message should say what things are missing instead of printing a misleading error message about the package.
<janneke>the commits say that a recompile is needed because the record ABI changed
<rekado_>but “guix pull” does a fresh compilation of all channels
<rekado_>or do I need to pull without my channels, then re-enable them, and then pull again with the new Guix…?
<kamil_>Hello! Is anyone a Sway user here? Font rendering is broken out-of-box on Sway; I installed some ttf fonts, but swaybar and sway itself still do not text properly, and displays boxes, with random numbers in them. Am I supposed to add something to my configuration.scm, or install Sway globally using my config?
<civodul>we could have a "static" output as well, maybe
<civodul>though all this is easier said than done i guess...
<rekado>and before my patch all the doc outputs were still referenced by the other outputs, so you’d have to download them anyway
<rekado>I wanted to split pandoc’s bin and the library, but annoyingly there’s a reference loop
<rekado>four files in the “lib” output would reference “out”
<rekado>because there’s a binDir variable somewhere…
<boeg>anyone here use zathura on guix? I have installed zathura and zathura-pdf-mupdf for pdf support, but when i try to open a pdf file, i get the error "error: could not open plugin directory: /gnu/store/v2slkn931lb3bss7qmfbbwp11nig971k-zathura-0.4.5/lib/zathura"
<civodul>abralek: you should add "gcc-toolchain" to the environment
<abralek>civodul: Thanks, I did try to do it as well, but find -L ~/.guix-profile -name "libstdc*" returns nothing anyway
<bricewge>gui-installed-desktop-os-encrypted test is failing since 10 of april.
<bdju>how do I set my xdg runtime dir? I don't remember doing this on other machines
<abralek>bdju: Do use use GuixSD or some foring repo?
<marusich>I ran 'guix archive --export --recursive /gnu/store/h2cx61lnpxbnl6gmjbq59jicr7fyw406-sed-4.7.drv > archive.nar' on one machine where the derivation had run and failed, and then ran 'guix archive --import < archive.nar' on another machine. I expected all the inputs to the derivation, transitively, to be copied over, but to my surprise Guix began downloading tons of inputs. How can I copy over the inputs?
<marusich>What I mean is, after running 'guix archive --import < archive.nar', I ran 'guix build /gnu/store/h2cx61lnpxbnl6gmjbq59jicr7fyw406-sed-4.7.drv', and I expected it to just start building the sed derivation, without downloading inputs.
<marusich>I want to copy all of the things required to run the .drv file - I thought "guix archive --export --recursive" would include all the references, transitively, of the .drv file. I thought that would include all the things needed to build it.
<marusich>If "guix archive --export --recursive" puts the transitive closure of references of the .drv file into the archive, then why on the second machine would Guix try to build the inputs?
<civodul>because like reepca wrote, the .drv is basically just "source"
<civodul>you can see that with: guix gc -R $(guix build sed -d)
<civodul>there's glibc.drv, for instance, but not glibc itself
<abralek>bdju: Do you run sway using .xsession or use gnome-session for that? I use stumpwm, and XDG_RUNTIME_DIR comes from gdm-x-session
<marusich>OK, I see what you mean. However, for example, in that list I see /gnu/store/8p93rj3n2isd9v6sgjvkw4nqlgg4c11q-perl-5.30.0-guile-builder. This file contains the Guile code like this: ("libc" . "/gnu/store/mln97mq23x1n42dladmnalvz55fysyzk-glibc-2.29")
<marusich>However, I see that "guix gc --references /gnu/store/8p93rj3n2isd9v6sgjvkw4nqlgg4c11q-perl-5.30.0-guile-builder" prints nothing. Why is "/gnu/store/mln97mq23x1n42dladmnalvz55fysyzk-glibc-2.29 not considered to be a reference of that store item?
<reepca>the daemon registers references after a derivation build completes, and only searches for the hashes of its inputs
<reepca>this is why, for example, sed.drv can contain the hash of its own output without breaking the store invariant (anything referenced must exist)
<reepca>(and when I say searches for the hashes of its inputs I mean more precisely "the specified outputs of the specified input derivations")
<marusich>I misunderstood the situation. In that case then, I can see why the transitive closure of references of sed.drv doesn't contain all the things I thought it did. I want to be able to build sed.drv on this second machine, while minimizing the amount of things I have to copy into its store. Besides, "guix copy", what might be a good manual way to do it?
<reepca>hmm, I'm not sure if there's an elegant command-line way of doing this
<marusich>Maybe I can run "guix gc --references /gnu/store/h2cx61lnpxbnl6gmjbq59jicr7fyw406-sed-4.7.drv", take the .drv files, build them to see their outputs (on the first machine, where they're already built), and add to that list the other non-.drv files that show up in g'uix gc --references /gnu/store/h2cx61lnpxbnl6gmjbq59jicr7fyw406-sed-4.7.drv'
<marusich>and then do 'guix archive --export --transitive $those_files'?
<reepca>what we want is basically what I've got in my WIP code as all-transitive-inputs, that is, the set of all specified input-derivation-outputs and all their *runtime* dependencies
<civodul>roptat: i tried "make download-po" but there's a typo in guix-manual.fr.po: "@comand" instead of "@command"
<marusich>Thanks reepca. I'll see if I can figure it out. Worst case, I guess I can let Guix repeat all the builds... BTW, the reason I'm looking at this is because I suspect this sed derivation fails on one system but not on another, depending on whether selinux is mentioned in the kernel's /proc/filesystems
<marusich>Apparently /proc/filesystems is different within the build environment on Fedora compared to Guix System, and it's probably because /proc/filesystems is leaking info about the kernel into the build environment
<bdju>abralek: I was just running "sway" or "exec sway" from a TTY. That's what I'd done on NixOS before.
<bdju>On my other Guix System machinu I was using SDDM, but I'm not a fan of it at all (and GDM is even worse)
<abralek>I understand, I am also not a big fan of GDM and GNOME, but the stack of GNOME apps it pretty big and it has good integration with other subsystems like notification,keyring, dbus, etc. So what I end up doing is to run my WM withing the gnome-session. I basicaly replace gnome-shell with Stumpwm.
<abralek>bdju: In general, session manager is responsible for XDG_ and thinks like that, not the window manager. Please someone correct me if I am wrong.
<boeg>Does wireguard on guix come with service files like on systemd systems so one can activate an endpoint with something like "herd start wg-quick@XXX" ?
<kamil_>bdju, I can confirm that elogind is needed. Dbus is a nice addition, but it might not be needed by Sway. I'm not sure. Here's a snippet of my config: (services (append (list (elogind-service) (dbus-service)) %base-services))
<kamil_>you will also need: (use-modules (gnu services dbus))
<bdju>my services section is a bit different-looking and I can't seem to get it to work
*mbakke wonders how many workarounds there are on foreign distributions because Mesas dlopen("libGL.so.1") substitution had become ineffective
<lfam>So, I am using unprivileged shepherd on Guix System. I log in remotely over mosh and start shepherd, and then log out / close the terminal window. Later, when I want to do e.g. `herd status mpd` or `herd restart mpd`, I get "error: connect: /home/lfam/run/shepherd/socket: Connection refused"
<rekado>bah, I just finished rebuilding up to ghc-pandoc after making what looked like really promising changes to the haskell-build-system … and the closure is 200MB larger now :(
<boeg>bricewge: I'm not having luck with wireguard still. So i have the wireguard-linux-compat in kernel-loadable-modules, i have the simple service you pastet, and I'm connected via network manager, and when i `sudo wg-quick up dk3` it seems to work, but i cannot ping anything