IRC channel logs

2020-05-22.log

back to list of logs

<reepca>is there no way to fix the tests?
<nckx>OK, that failed.
<nckx>I assume that's the point of all this.
<reepca>(referring to the guile-fibers tests)
<cbaines>reepca, as far as I know, the test failure is the sign of a real problem in Guile somewhere
<nckx>successfully built /gnu/store/c70j91pkiv8qyazpv357ccc2jfjz91yw-util-linux-2.35.1.drv
<nckx>Linux moloch.tobias.gr 5.4.42-gnu #1 SMP 1 x86_64 GNU/Linux
<nckx>6-‘core’ Contabe VPS saves the day.
<reepca>cbaines: where could I get my hands on a failing log of guile-fibers?
<mbakke>welp, there goes the kernel regression theory
<nckx>Ikr.
<civodul>reepca: i think rekado and wingo discussed those Fibers tests some time ago and came to some conclusion, though i'm not sure what conclusion :-)
<reepca>hmm, guess I can just search my email history...
<civodul>mbakke: in fact "ipcs -q" does little more than dumping /proc/sysvipc/msg apparently
<civodul>i see the duplicate key in there too
<cbaines>reepca, here's one copied from bayfront: http://paste.debian.net/1148206/
<mbakke>nckx, civodul: looks like this actually was a brief kernel regression: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.42
<mbakke>search for sysvipc_find_ipc
<nckx>Awesome sniffing.
<mbakke> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=05aae468d31ac562a10af407fbf80d6c70e8b611
<civodul>mbakke: oh nice, good catch!
<nckx>Really is. I'm going to update & reboot & test that promising hypothesis.
<reepca>wait, are all the guile-fibers tests being run in a single guile process?
<nckx>Oh noes
<nckx>it's build util-linux.
<reepca>cbaines: you may be interested in https://github.com/wingo/fibers/issues/36
<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>well, we'll have 3.0.3 hopefully soonish
<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>ah yes, definitely
<civodul>i mean, in general, one should really explicitly close file ports
<civodul>waiting for GC to happen isn't a good strategy
<reepca>indeed
<civodul>note that upon EMFILE, 'open-file' & co. run the GC
<civodul>but still
<reepca>ahhh, but pipe() doesn't, of course, and when that's called during the setup of a new thread it simply abort()s.
<civodul>indeed
<civodul>should there be a wrapper around pipe that GCs upon EMFILE?
<reepca>perhaps, though I'm unfamiliar with the details of guile's GC and whether it's feasible to invoke it at that particular point
<civodul>yeah, maybe it's unreasonable
<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
<civodul>reepca: ok
<civodul>reepca: IIRC Fibers master is quite different from the release we're missing
<civodul>perhaps it's fixed there
<reepca>unfortunately not, at least not a week or so ago
<civodul>bah
<civodul>so what would you suggest?
*civodul is amazed every time reepca deep dives into tricky issues
<civodul>really great!
<reepca>we could patch fibers. It's not a big change - just add one line that destroys the peer schedulers
<civodul>yes, sounds reasonable
<reepca>alternatively we could try to bug wingo into putting out a bugfix release
<civodul>we can do both :-)
<reepca>what format do we want for patches again?
<civodul>for those in gnu/packages/patches, it's just unidiff with a comment at the top explaining what it does and its upstream status
*civodul -> zZz
<civodul>happy hacking!
***apteryx is now known as Guest4530
***apteryx_ is now known as apteryx
<malaclyps>ignore me, sensible apps seem to be able to divine the dbus socket without the environment variables
<tho1efx> https://www.phoronix.com/scan.php?page=news_item&px=Fedora-33-AArch64-Code-Hard
<tho1efx> https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
<tho1efx>How does guix on arm stack up?
<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>tho1efx: Which package would that be?
<tho1efx>Qdirstat
<tho1efx>I'm working on cleanups right now, hopefully it's acceptable on the bat back.
<nckx>Sounds good. I'm unfamiliar with that expression.
<tho1efx>The return, the next go round :)
<nckx>Hah. Literally never heard that. Nor had the Web.
***jonsger1 is now known as jonsger
<RRedcroft>hey guys, how do i specify different console and xorg keyboard layouts?
<RRedcroft>i tried setting (keyboard-layout (keyboard-layout "uk")) inside xorg-config but get the following: Wrong type to apply: #<<keyboard-layout> name: "gb" variant: #f model: #f options: ()>
<nckx>RRedcroft: ‘Wrong type to apply’ means you're trying to call something that's not a procedure. Could you paste your entire configuration to paste.debian.net?
<RRedcroft>nckx: http://paste.debian.net/hidden/8397491e/
<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.
<RRedcroft>nckx: ah, awesome thanks
<nckx>You'll get used to it eventually, promise.
<nckx>Happy to help.
<RRedcroft>that works :) ty
<haha>Good morning everyone.
<haha>I am a little confused about guix offload. Does it send the source code of the build task when sending it to other machines?
<apteryx>haha: it sends the derivation script and all its inputs
<apteryx>IIRC
<haha>Thanks, i understand it
<fvr>I am trying to dual boot with guix, used rufus to burn the iso to usb. But unable to boot it's currently failing with "In procedure scm-error: failed to resolve partition ".3139....""
<fvr>Can some one help with this
<fvr>Before this it also display, unable to find device: 1970-01-01-19-49-46-83
<fvr>It currently entered into a guile prompt
<apteryx>fvr: the image can be copied directly to USB using dd; perhaps Rufus is interfering?
<apteryx>see info "(guix) USB Stick and DVD Installation"
<fvr>Earlier I used universal usb installer to use dd, but sadly that didn't work it looked like nothing was even copied
<fvr>The main os is windows on the system
<tho1efx>In packaging what does it mean for #:phases to return #t?
<fvr>copying with dd from Rufus seems to have helped. Thanks!
<malaclyps>what should GUIX_LOCPATH be set to on a Guix system (as opposed to Guix running over another distribution)? And where should it be set?
<apteryx>malaclyps: no need to set it, Guix System should take care of it for you
<malaclyps>my $GUIX_LOCPATH is insistent that it be /run/current-system/locale but I have some locale info in $HOME/.guix-profile/lib/locale
<malaclyps>huh
<malaclyps>unless I had lib/locale, my user-installed copy of guile3.0 complains
<PotentialUser-30>Jami works on my PureOS system but not on GuixSD. I can receive messages but not send them.
<PotentialUser-30>Also works on Parabola with the same version.
<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/
<apteryx>fvr: you used dd in a live usb session?
<fvr>Nope. I restarted my system formatted the usb and then used dd to copy the image
<apteryx>sneek: later tell PotentialUser-30 the jami build is currently foo (but not bar) on Guix.
<sneek>Got it.
<apteryx>fvr: did you do 'sync' after dd?
<apteryx>otherwise it may have just buffered the content, to be actually written to the device at the system's convenience
<fvr>I assume Rufus did that.
<fvr>It looks like it's not detecting my secondary storage, all I can see in fstab is the usb stick
<apteryx>fvr: I recommend you to follow exactly the procedure given in the guix info manual since you are not having luck
<PotentialUser-60>you manage to get Jami to work
<sneek>Welcome back PotentialUser-60, you have 1 message!
<sneek>PotentialUser-60, apteryx says: the jami build is currently foo (but not bar) on Guix.
<reepca>woah, sneek can track across multiple usernames? What dark magic is this?
<ryanprior>What in the world does "jami build is foo" Mean
<sneek>Welcome back ryanprior, you have 1 message!
<sneek>ryanprior, lprndn says: Ok, I'll look at #elementary in the next few days.
<apteryx>ryanprior: I meant it's broken. The daemon keeps crashing.
<apteryx>it's specific to Guix. I mean, Jami crashes on other OSes/platforms, but nowhere near as much as it currently does in Guix :-)
<apteryx>so we have something to improve
<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>dftxbs3e, I responded to your bug report in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39817
<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?
<marusich>dftxbs3e, I tried again to build it, but it failed. This is using commit f47e761a10675b05b07107035d5024618267a3ad of https://gitlab.com/lle-bout/guix - I expected it to build the same binaries as https://gitlab.com/lle-bout/guix-bootstrap/-/commit/8e464405c0ba76b29e11c3b60af4d6ea9c83c188
<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>bdju, did you check https://guix.gnu.org/manual/en/html_node/Keyboard-Layout.html ?\
<bdju>marusich: I guess not, I just checked my config and I haven't got any (keyboard-layout) things in there yet. Thanks, I will experiment with this soon.
<fvr>I ran `guix system init .. while installing and after a long time it failed with no space left on device. There is lot of space on the device. Where could this error be from?
<marusich>fvr, check the size of /tmp
<fvr>It's showing Used: 13G, Avail: 226G
<marusich>For /tmp?
<fvr>Yep, maybe I mounted things wrong?
<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.
<raghavgururajan>Hello Guix!
<fvr>marusich:
<fvr># df -h /mnt/tmpFilesystem Size Used Avail Use% Mounted on/dev/nvme0n1p5 251G 13G 226G 6% /mnt# df -h /tmpFilesystem Size Used Avail Use% Mounted on/dev/nvme0n1p5 251G 13G 226G 6% /mnt
<fvr>Sorry! https://paste.debian.net/1148238/
<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.
<boeg>marusich: alright
<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>What's the output of "which slock"?
<boeg>marusich: i have been doing that. The output is: /run/setuid-programs/slock
<marusich>OK, that's good. I think it's supposed to be setuid.
<marusich>fvr, is there nothing in /tmp?
<marusich>nothing mounted at /tmp i mean
<fvr>marusich: Nope, nothing at /tmp
<marusich>boeg, are you using Guix System, or Guix on a foreign distro? Are you using Xorg, or are you using something else like Wayland?
<boeg>if I manually do "loginctl suspend", the screen doesn't get locked. If I manually do "slock" it does, so seems to suspend doesn't activate lock
<boeg>i'm on guix "the system"
<boeg>i'm using xorg
<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?
<boeg>i can try
<fvr>marusich: https://paste.debian.net/1148241/
<fvr>There is one entry in it that is showing 100% usage
<marusich>That's sort of interesting. I wonder what's taking up the space in /? You can find out with "du -hax -d 1 /" but it might take a little while
<fvr>It is showing total only at 92K at /
<marusich>I guess the only other thing I can think to try is to run the command again, and watch the output of "df -h" to see what gets full.
<fvr>At 100% use is /home/guest mounted at /
<fvr>Ah I see, everything that's mounted at / is showing as 100% usage
<bdju>argh console-keymap is failing to build when I try to apply dvorak on my guix machine
<fvr>The command is instantly failing with no space left error
<marusich>fvr, did guix fill something up in there...?
<marusich>bdju, that sucks :( you might be able to retry it, or "guix pull" to a different version of guix to try again (though that will take time)
<fvr>I don't know if this relevant but top shows 51.9G/31.4G memory usage
<marusich>Can you remind me what command you're running? Does it say anything about where it is trying to write, and running out of space? It seems bad that / is full.
<marusich>I guess, more immediately, can you clean up anything in /?
<fvr>Okay, I have just restarted and rebooted into the usb again. After mounting my storage to /mnt just observed that without running anything usage in / is slowly increasing along with memory usage
<fvr>It's already at 44% and memory usage at 24G without even running any command
<marusich>What's taking up the space?
<marusich>log files, maybe?
<fvr>I haven't even run any command yet and it's at 72% usage now. And ps -aux isn't showing any command with > 0% mem usage
<fvr>syslogd is at 99% cpu usage
<bdju>marusich: yep I'm doing a guix pull now, but like you said it's taking some time
<fvr>Logs looks like, "du -h /var/log/" shows all of the usage (16G)
<marusich>Any idea which logs?
<fvr>Two logs /var/log/debug and /var/log/messages at 7.9G each
<marusich>What's spamming them up?
<marusich>You'll probably find lots of the same messages if you tail it
<fvr>Yep
<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>I meant: "while sleep 1; do echo -n > /var/log/debug; echo -n /var/log/messages; done"
<fvr>Logs all look like, "DateTime localhost vmunix: [ 1032.32523] nouveau 0000:26:00.0: disp: ctrl 00000080"
<marusich>They're all the same like that?
<fvr>Looks like it, the log number I guess keeps changing
<fvr>the one in [ ]
<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>but only on the right side though
<marusich>Sounds suspicious. I wonder if video will work? If it does, maybe you can reduce the spam more surgically by configuring the kernel to emit fewer messages. Something like: https://askubuntu.com/questions/97256/how-do-i-disable-messages-or-logging-from-printing-on-the-console-virtual-termin
<marusich>or: https://stackoverflow.com/questions/19757750/how-to-permanently-change-linux-printk-log-level
<fvr>I thought of late all nvidia cards have decent linux support as well
<marusich>If you're committed to trying Guix on this machine, I'd say try to install it and see what happens. But your /var/log/messages might still fill up because of this.
<marusich>Yeah, in theory nouveau should work fine, I think?
<fvr>I'm 5+hrs into this already, so I have to see what happens :)
<marusich>I mean, it could very well be a bug that is exercised on your combination of hardware and linux-libre.
<marusich>Give it a try, do guix pull, see if the problem persists. If it does, perhaps it's worth a bug report.
<fvr>Can I do guix pull even now? that is during the boot process as well
<marusich>Yes, you can.
<fvr>Alright! I'll try to zero out the log files and see
<marusich>If you do a guix pull now, you'll get the latest master branch of Guix by default, and then you can run 'guix system init' to install the most recent version of guix system onto the machine.
<marusich>You'll still have to run "guix pull" as an unprivileged user (or as root, if you want root to have a default profile, too) to install the most recent Guix in new system.
<marusich>The "guix" you install via "guix pull" now, before you run "guix system init", won't carry over into the new system.
<fvr>Ah okay, think I get it
<marusich>That's because it will be installed into somewhere like $HOME/.config/guix/current, which is not in /mnt. Anything outside of /mnt will not carry over.
<marusich>Assuming you're 'guix system init'-ing into the /mnt directory.
<fvr>Yeah that's what I am doing as the manual says
<marusich>good luck!
<bdju>how do I check if a usb wlan adapter will work with linux-libre out of the box?
<bdju> https://www.amazon.com/dp/B07J65G9DD/ I'm looking at this one, seems to use a GPLv2 driver ( https://github.com/cilynx/rtl88x2bu ), just unclear if it's built into the kernel
<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.
<marusich>bdju, hard to say. If it's USB, chances are it'll work. See also: https://lists.gnu.org/archive/html/help-guix/2016-03/msg00066.html
<marusich>People have had success with Atheros-based adapters. The RYF-certified ones are likely to work.
<rekado_>why are our Haskell packages so extremely large?
<rekado_>guix size $(guix build ghc-pandoc) tells me that the closure is 3GB.
<rekado_>just the ghc-pandoc item is 234M
<rekado_>on Fedora installing pandoc takes 17M
<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
<rekado_>what’s up with that?
<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>also I was sad sway was not a DE choice
<rekado_>bdju: the installer doesn’t offer everything that Guix supports
<rekado_>bdju: you can reconfigure later with sway as a DE
<bdju>yeah I chose no DE for now, but I probably have to solve the btrfs thing now
<bdju>ah I may have figured it out.
<bdju>What the! I've been sent back to the installer's start after saying yes to partitioning with btrfs
<fvr>marusich: Finally booted into guix, Thanks a lot!
<fvr>Video card problems still persist though, will try guix pull and see if that solves anything
<fvr>bdju: I faced the same issue in the morning, once I click on guided partition it would loop back to the start. Went with manual install at last
<bdju>I went through it again quick and made it further. That's a tad annoying.
<bdju>Hopefully it works now.
<bdju>This is still a lot friendlier than the first time I installed Guix System, at least. The installer seems pretty good.
<fvr>I couldn't make it any further it was looping every time. Have to file a bug but I doubt it will be easy to reproduce
<bdju>I think I chose guided install again but then manual partitioning the first time around
<fvr>Is anyone running with a RTX 2070?
<fvr>* on
<bdju>The install failed installing the bootloader now. Says no such file or directory. I think about /mnt/boot/efi
<bdju>Maybe just that I didn't bark the boot partition as one to be formatted. trying that now
<bdju>s/bark/mark
<bdju>now I got no such file or directory in relation to profile.drv
<bdju>Now the error is on loadkeys-static... what is going on here
<bdju> https://file0.s3kr.it/29f6524f2e24.jpg (picture of my monitor) Anyone have any ideas?
<fvr>Shouldn't /boot/efi be outside /mnt initially?
<fvr>I mean a separate partition
<bdju>It's just weird wording I think, it's mounted where the guided partitioning puts it, I just then switched to manual to set btrfs
<bdju>started the install over and still error out on loadkeys-static!
<bdju>Oh, this is related to using dvorak, isn't it?
<bdju>could be uncommon enough that no one else hit the bug maybe
<bdju>I wonder if it's worth commenting some stuff out related to dvorak
<rekado_>(I’m using dvorak but installed my system before we had the installer)
<bdju>oh my god... I commented out keyboard layout and now it's failing to find module-import-compiled
<bdju>I want guix system on this machine so bad but I just don't know what to do at this point. reaching my limits as a non-programmer
<lprndn>bdju: maybe you can share your configuration?
<bdju>I can try. One moment.
<bdju>Darn. I was going to take a picture, but the installer is only using a portion of my screen and it won't all show at once.
<bdju>I'll try to paste it somewhere from a tty with curl.
<bdju>ha... curl isn't installed
<lprndn>bdju: hum... maybe try 'guix install curl'?
<bdju>lprndn: good idea, although it spits out an error about glibc-utf8-locales when I try that
<bdju>also can't seem to ssh into the machine running the installer or maybe I could've grabbed the config with sftp or just been able to select the text to copy
<bdju>I'm attempting a guix pull now
<lprndn>bdju: if it works, probably don't bother with it for now.
<bdju>Another error, this time it can't open guile
<bdju>if what works? I'm mid-install and basically nothing is working, so...
<bdju>oh, it doesn't actually install curl as far as I can tell, in case that was unclear
<lprndn>bdju: yeah, I meant curl. hum...
<rekado_>did you check the signature after downloading the image?
<bdju>this is nuts... why would everything be this broken I wonder
<rekado_>you’re not supposed to get errors like that
<rekado_>perhaps the download is corrupt?
<bdju>no, I didn't actually. maybe it is corruption or something.
<bdju>Well, I'm stuck anyway, so that'll be my next thing to try. Re-making the installer.
<mbakke>bdju: you can start an ssh server with 'herd start ssh-daemon'
<bdju>that worked, although I can't seem to get the password right
<bdju>it's not "root", "guix", or the one I set myself
<mbakke>bdju: you can set a password for root with 'passwd'
<bdju>"authentication token manipulation error"
<bdju> https://paste.debian.net/hidden/2d85b010/ getting bad signature, but maybe I've just done something wrong
<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
<bdju>got good signature now
<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
<jeko>Hey Guixters !
<jeko>$ ./pre-inst-env guix build artanis
<jeko>guix: build: command not found
<jeko>Try `guix --help' for more information.
<jeko>does this sounds familiar to someone ?
***catonano_ is now known as catonano
<bdju>Things were looking good with the install on the re-made usb installer, but I hit an error again
<bdju>efibootmgr failed to register the boot entry: input/output error
<bdju> https://file0.s3kr.it/c98fd45d264a.jpg image
<bdju>Argh. I went back to partitioning and chose guided in case I'd done something wrong manually. Back to a loadkeys-static error again. I wonder if anything has changed.
<rekado_>is the USB drive failing…?
<rekado_>you should not get i/o errors
<bdju>I guess it's possible.
<lprndn>bdju: I'm not an expert but, just in case, did you boot the usb on EFI?
<bdju>it booted automatically because there's no OS on any drive in here currently
<sirmacik>anybody using modemmanager-qt package?
<bdju>I'll reboot and go to the boot menu.
<sirmacik>after install I don't see any new binaries o desktop entries
<sirmacik>so I don't know how to accesss it
<bdju>lprndn: I only see one boot entry with to mention of efi.
<bdju>s/to/no
<sirmacik>oh, nvm, I've found it ;f
<bdju>uefi is set higher priority in my uefi settings also
<fvr>Maybe you should reformat the hard drive and try go with a complete manual install
<lprndn>bdju: I think this is the problem. Do you have secure boot enabled?
<raghavgururajan>Hello Guix!
<raghavgururajan>Anyone familiar with this build error? https://bin.disroot.org/?8ccb9decee321a2c#HX92zBdU3GSPzA2SodK4itAxFN53PVVvJu28GCnKtXy5
<lprndn>hey! (no idea)
<lprndn>the installer should probably check if its booted in EFI and forbid its use if not. Instead of waiting for grub to fail... no?
<mbakke>bdju: it could be that your EFI firmware memory is full, see https://unix.stackexchange.com/questions/379774/grub-installation-failed
<bdju>lprndn: I have secure boot disabled actually
<bdju>mbakke: I just changed to a blank drive in this machine. or would it be something not on a hard drive, but some sort of chip on the motherboard?
<mbakke>bdju: indeed, EFI variables are stored on your motherboard
<bdju>ah, interesting. okay. I will look into that then
<raghavgururajan>Fixed it. \o/. It required appstream-glib.
<fvr>Hmm no end in sight for the errors lol http://paste.debian.net/1148271/
<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
<bdju>I will check for that file in a sec
<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?
<bdju>lprndn: that file does exist it looks like
<bdju>I'm also now attempting another install after deleting some dump files from my efi memory
<lprndn>mbakke: Indeed! :D
<lprndn>bdju: :/ I hope it's what mbakke suggested then.
<mbakke>boeg: perhaps Xorg modules loaded in the wrong order? can you inspect /var/log/Xorg.0.log and see if there are differences between good and bad boots?
<boeg>mbakke: I can try
<boeg>mbakke: doesnt seem like xorg is logging to /var/log
<boeg>mbakke: have to figure out hwere it logs to
<mbakke>boeg: oh, maybe it's in /var/lib/gdm
<boeg>mbakke: empty. There are some thingsi n /var/log/gdm/greeter.log. I'll check that if it happens again
<bdju>The install finally completed!!! I think mbakke was correct that my efi firmware memory was full
<mbakke>bdju: \o/
<lprndn>bdju: Nice!
<rndd>hi everyone! i cannot use my laptop camera on guix. is it because it is proprietory?
<jonsger>rndd: which laptop do you use
<rndd>jonsger: Acer Swift SF113-31
<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).
<dfeng>Sorry, hello guix.
<rndd>jonsger: yee, use icecat
<dfeng>Can we find for example a description of the Guix tree, the one located in the personal directory?
<dfeng>ls ~/.config/guix/current
<dfeng>At first glance, it has various directories.
<NieDzejkob>jonsger: I haven't managed to get cheese to work, but obs worked instantly
<pkill9>dfeng: ~/.config/guix/current/share/guile/3.0
<rndd>jonsger: actually it works in obs
<rndd>but... need in browser -_-
<jonsger>NieDzejkob: cheese works for me out of the box on a x250
<jonsger>rndd: maybe try chromium
<pkill9>dfeng: actually it's ~/.config/guix/current/share/guile/site/3.0
<rndd>jonsger: this idea is good. but also don't work
<jonsger>rndd: http://www.linuxintro.org/wiki/Set_up_a_Webcam_with_Linux
<dfeng>pkill9: ah yeah, but is there no document like the Filesystem Hierarchy Standard?
<pkill9>I'm confused about the question, do you mean a document explaining the structure of Guix? I think the source code itself is the only thing available for that, plus the Guix manual
<dfeng>pkill9: a document that gives an overview of the "Guix filesytem".
<pkill9>also you can create a system image with `guix system disk-image` and give it a guix system configuration
<pkill9>i don't know
<dfeng>pkill9: I see, but it would still be better to know the usefulness of repertories rather than browsing the tree at random. Maybe, I should file a bug report?
<pkill9>so you mean the structure of the source code?
<pkill9>it's just guile modules
<dfeng>pkill9: ah okay, seen in this way, it is clearer.
<dfeng>pkill9: thank you.
<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>rndd: I have /dev/video
<rndd>-_-
<rndd>but obs is able to use my camera 0_0
<rekado_>firewall problem update: IT says there is no traffic shaping for ci.guix.gnu.org, but they see duplicate ACKs for this IP (and not for the other server on the same subnet).
<rekado_>they see this both for internal and external connections, though, so I don’t know if this can be considered the most likely culprit
<jonsger>rndd: so you need to first find out which webcam you have? and then which driver/module it needs. Google will help you
<dfeng>See you soon!
<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
<rndd>?
<rekado_>CC=gcc
<rndd>rekado_:nope, still have this error
<NieDzejkob>rndd: not as a separate command
<NieDzejkob>make CC=gcc
<rndd>NieDzejkob: oh
<rndd>thanks
<sturm1>Anyone used Gnome Boxes to create a virtual machine? I'm getting a warning about not having virtualization extensions enabled in BIOS.
<sturm1>Non sure whether it's truly my machine or whether it might be a bug.
<dutchie>did you look in your BIOS settings for the virtualisation extensions?
<sturm1>I'm running Coreboot, so no
<sturm1>I'm not sure whether it supports the virtualization extensions or not - there's no BIOS menu unfortunately for this sort of thing
<dutchie>do you see the extensions in cpuinfo? e.g. grep -E --color=auto 'vmx|svm|0xc0f' /proc/cpuinfo
<sturm1>yep, I'm seeing vmx - thanks
<dutchie>hmm, odd that boxes doesn't see the extensions then. or is that working now?
<sturm1>no, I'm blocked at the "Review and Create" dialog after selecting a distro
<sturm1>have you used it by any chance?
<dutchie>neither coreboot nor boxes, i'm afraid
<rekado_>sturm1: perhaps it checks if the user has permissions to run kvm
<rekado_>is the current user member of the kvm group?
<sturm1>rekado_: thanks, yes user is in the kvm group
<boeg>tlp has an option "TLP_PERSIST_DEFAULT"[1] but I it doesn't seem to be available in `tlp-service-type`. Any idea why that is? [1]: https://linrunner.de/tlp/settings/operation.html#tlp-persistent-default
<boeg>TLP_PERSISTENT_DEFAULT*
<pkill9>does anyone know why this exits with status 1? guix environment --ad-hoc bash st bemenu -- st -e "bash -c bemenu"
<bdju>got a guix pull error telling me I found a bug and to report it, but I'm still working on getting a graphical environment going
<pkill9>(the guix environment doesn't affect the output, just makes it a one-liner anyone can copy+paste
<nckx>bdju: Is it this? <https://issues.guix.gnu.org/41457>
<bdju>nckx: yes!
<bdju>glad it was reported already
<nckx>There was a big change in that area (many external channels will need updating as well).
<bdju>why does texlive-texmf download at only ~495KiB/s?
<nckx>It's weird that I can pull from a local guix master + some unrelated patches just fine though.
<rekado_>what needs to change?
<nckx>bdju: From berlin? See above messages about rekado_ IT dept.
<nckx>*rekado_'s
<bdju>ah. fresh install so whatever the default is these days
<nckx>Right, that's ci.guix.gnu.org = berlin.
<nckx>It's a known mystery.
<nckx>So I'm pulling from d8feee9f18ede + some patches that have been on there for weeks, works fine; weird.
<rekado_>latest news is that it might be a layer 1 problem
<jeko>Hey guixters! do you know what is my problem ? https://write.as/wobmcths5c7a2o17.md
<jeko>or what could be* ^^
<rekado_>jeko: what happens if you stay inside of the environment?
<jeko>[dev]$ ./pre-inst-env guix build artanis
<jeko>substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
<jeko>The following derivation will be built:
<jeko>...
<jeko>seems to be working
<jeko>rekado_: I use Guix on Ubuntu
<rekado_>generally, when using a git checkout you need to make sure that you have a suitable environment to use Guix.
<NieDzejkob>pre-inst-env is supposed to work within guix environment guix
<rekado_>but there should be a better error message
<rekado_>NieDzejkob: it does work.
<NieDzejkob>you can do away with --pure if you want
<rekado_>jeko exited the environment before using ./pre-inst-env guix
<NieDzejkob>rekado_: as in, it's designed to work within it
<rekado_>right.
<rekado_>the lack of an appropriate error message is not good. Could you please submit a report to bug-guix@gnu.org? The error message should say what things are missing instead of printing a misleading error message about the package.
<jeko>of course I can!
<rekado_>thanks!
<jeko>rekado_: so if I get it, I should call "./pre-inst-env guix build artanis" inside the environment created by "guix environment [--pure] guix" ?
<rekado_>nckx: I’m also getting this “guix pull” error as in https://issues.guix.gnu.org/41457 now
<rekado_>what is this about?
<rekado_>oh… I see
<rekado_>c7d2dd69004b020de5d86898d2497ab3c8435c37 and related commits
<rekado_>but this seems like a really big breaking change
<NieDzejkob>ugh. Looks like I can't offload the build of `docker` to a non-Guix System machine due to kernel differences
<NieDzejkob>oh, right! Debian disables user namespaces by default
<rekado_>I find this puzzling. What is the new format for hashes then?
<rekado_>none of the hash fields in Guix proper have been changed
<rekado_>so why would this break channels?
<rekado_>civodul: are you around?
<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?
<janneke>hmm...
<rekado_>no, same problem
<rekado_>this happens while “Computing Guix derivation for 'x86_64-linux'”
*janneke runs guix pull -- using only %default-channels
<janneke>...that worked
<rekado_>maybe the Guix I have is too old…?
<jackhill>jeko: yes, I believe that's correct
<rekado_>janneke: what version did you use?
*jackhill also can't reproduce it. Previous guix was 37e5096df721ee6e9d2477471a277965d514cea0
<janneke>yeah, mine was pretty recent, last week or so
<rekado_>mine is from April (commit be0ecfb)
<janneke>may 17, ebbf915
<jeko>jackhill: cool cool cool
<kamil_>To anyone reading my previous message, I've fixed my problem by adding sway to the list of globally installed packages. Should this be reported?
<jonsger>NieDzejkob: maybe you should open a bug regarding this cheese ting
<jackhill>kamil_: I think it should be reported. We have some other font issues, so it would be good to get this one recorded too.
<kamil_>jackhill, what the title of a bug report should be? Something along these lines: "Font rendering broken for the Sway package installed in a user profile"?
<civodul>rekado_: yes! a problem?
<jonsger>kamil_: thats fine. the title could be changed later on. But it seems clear
*civodul looks at https://issues.guix.gnu.org/41457
<civodul>weird, i've just pulled and it works for me
<civodul>maybe it's been reverted or something?
<rekado_>perhaps it depends on the version of Guix used to pull.
<rekado_>janneke had success with a version from may 17
<rekado_>whereas I got the error with a version from april 15
<rekado_>I’m now doing a two-step pull
*civodul tries guix time-machine --commit=be0ecfb1787b9e6954bf745bceeb1b9d2669d51a -- pull -p /tmp/test
<rekado_>i.e. pulling to 1ad5209d904d471ded6cf53b4e29b64e963dea3f first and then once more to the latest version
<janneke>civodul: yes, that breaks
<civodul>damnit the new rules for syntax literals are terrible
<kamil_>jonsger, thank you. I'm composing a list of bugs I've encountered on Guix. I'll report them as soon as I can
<jonsger>kamil_: but please make one bug for one topic
<kamil_>Of course. I'm only doing it to not forget to report them
*rekado_ got a patch to reduce ghc-pandoc closure by about 180MB
<civodul>uh "guix size ghc-pandoc" seems to take forever
<bdju>when trying to launch sway, I get "XDC_RUNTIME_DIR is not set in the environment. Aborting."
<bdju>s/XDC/XDG
<civodul>rekado_: ah, that's like 5%, but it's already nice! :-)
<glat-agent2>Your GNU/Linux copy is not genuine. Purchase a license for $99 now.
<rekado_>ugh, someone kick glat-agent2 please
<bdju>heh
<rekado_>civodul: yeah, ghc-pandoc is huge. I’m trying to make it smaller.
***ChanServ sets mode: +oo civodul rekado_
***glat-agent2 was kicked by civodul (Kicked by civodul)
<rekado_>thanks!
*rekado_ has powers now
<civodul>superpower
***rekado_ is now known as rekado
<rekado>I don’t get the motivation behind this annoying spam. For a scam it’s much too clumsy. For satire it’s much too dull.
<drakonis1>its someone who used satire from 2007 as a way to scam people
<pkill9>what spam is this?
<civodul>yeah i don't get it either
<rekado>pkill9: there’s not much more to it, really
<civodul>and they insist
<wklew>what about writing a guile-pandoc
<pkill9>i don't see it anywhere?
<rekado>wklew: don’t tempt us!
<civodul>rekado: why does ghc-pandoc keep a reference to ghc?
<civodul>heh :-)
<rekado>civodul: I think it’s the GHC runtime
<pkill9>oh, glat-agent2
<rekado>every Haskell package needs it.
<civodul>rekado: can't we have a "lib" output, like for GCC?
<rekado>maybe we can move it
<civodul>because that's 1.3G
<drakonis1> http://www.linuxgenuineadvantage.org/ pkill9
<rekado>all the Haskell packages are weird
<rekado>they come with .a and .so files.
<civodul>and seriously, 1.3G, it's worse than Clang
<pkill9>hehe
<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"
<drakonis1>rekado: check how nix does it
<rekado>drakonis1: I will.
<rekado>for the doc outputs they don’t actually have a solution
<rekado>and the one that they discussed is seriously complex
<rekado>I’ll send in my patch tonight and let you all criticize it
<rekado>:)
<abralek>Hi, can I somehow get guix environment with libstdc++ available in libs?
<abralek>there is a crazy vpn client - Checkpoint SNX
<abralek>I think I am doing something wrong here λ guix environment -C -s i686-linux -P gcc-{objc,objc++}@5 --ad-hoc coreutils libx11 linux-pam strace bash --pure -- bash
<abralek>I probably need to build all those ad-hoc libs using gcc5
<civodul>hi abralek
<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.
*civodul tests a fix for https://issues.guix.gnu.org/41457
<civodul>hi marusich!
<marusich>Hello there!
<civodul>this command copies to closure of the .drv, not the closure of the output of the .drv
<marusich>Isn't that what I want?
<civodul>i don't know what you want :-)
<bdju>abralek: I am on guix system
<civodul>marusich: copying the .drv means that you can then build it on that other machine
<marusich>So, I have one machine that attempted to build sed.drv and failed. The fact that it built indicates that its inputs must have been valid, i.e., they are in the store and good to go.
<civodul>but it also means that you may have to build/download everything
<marusich>Right. I want to do that, but I don't want the other machine to download everything.
<civodul>how about using "guix copy"?
<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.
<civodul>it does
<reepca>the references of the .drvs are mostly just sources and other .drvs
<marusich>That's a good suggestion, but I don't have SSH set up right now.
<civodul>so you can copy the .drv like you did, but that means possibly having to rebuild/redownload things on the other machine
<civodul>or you can copy the build result directly
<civodul>roughly "guix archive --export -r sed"
<civodul>and then that to the other side
<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)
<marusich>OK. That makes sense.
<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"
<reepca>marusich: the relevant code is around here http://git.savannah.gnu.org/cgit/guix.git/tree/guix/store/database.scm?h=guile-daemon#n435
<reepca>although you've got --transitive to handle the file-closure portion
<reepca>marusich: you may find this snippet helpful: http://paste.debian.net/1148320
<reepca>(run from 'guix repl')
<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
<reepca>I can believe that
<marusich>I wonder if we should (or even can?) normalize /proc/filesystems
<marusich>I saw this error, and I read here that the build logic is controlled by the contents of /proc/filesystems, which is why I suspect that's why my sed.drv build failed: https://lists.gnu.org/archive/html/bug-sed/2019-06/msg00022.html
<marusich>So, I'm trying to test.
<reepca>could impersonating linux 2.6 help?
<marusich>I already confirmed that /proc/filesystems is different in the Guix build environment on Fedora, than it is in the Guix build environment on Guix system.
<marusich>I'm not sure.
<marusich>Can you tell Guix to do that on the CLI or something?
<reepca>you can tell the daemon to do it when you start it, aye
<reepca>with --impersonate-linux-2.6
<marusich>OK. I'll try that too and see how it goes. For now I gotta run
<marusich>thank you for the tips
<reepca>o/
<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.
<abralek>things*
<abralek>guix environment --system=i686-linux --link-profile --container --pure --ad-hoc gcc-toolchain@5 coreutils findutils bash -- find -L ~/ -iname "libst*"
<abralek>no libstc++ library =(
<bdju>well, sway won't start for me but on nixos it was fine without a display manager
<vagrantc>i needed elogind and maybe dbus?
<vagrantc>to use sway without display manager
<bdju>oooh
<bdju>vagrantc: can I just add them to my system packages or do I need to add some services?
<vagrantc>i needed services
<vagrantc>trying to dig up my config
<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
<bdju> https://waifupaste.moe/dIG here's my config, it's saying dbus-service-type unbound variable and asking if I forgot a use-modules form
<mbakke>bdju: uff, the dbus service is called just (dbus-service)
<kamil_>mbakke, this^ I was having the same issue before I realized I don't need "service" and "-type"
<bdju>removing -type gives a worse error
<bdju>ugh
<kamil_>bdju, it should look like in my message above. Remove "serivce" before "dbus-service" and "elogind-service".
<bdju>I removed that from all the lines and now it says tor-service is deprecated and to use tor-service-type
<bdju>and openssh-service has an unbound variable
<kamil_>bdju, you only needed to remove that for elogind and dbus. services with the name ending with "-type" need "service" before them
<bdju>I removed -type and service together
<bdju>anyway I've .ut it back for all but the last two and now it's doing something finally
<bdju>s/.ut/put
<mbakke>bdju: not all services have been migrated to service-types yet, sorry for the inconsistency :-/
<bdju>ah okay
<mbakke>bdju: migrating those services to the newer API would be a great beginner contribution ;-)
<bdju>Finally got Sway to start!
<bdju>mbakke: I'll keep that in mind
<bdju>had to reboot after adding those services and now "exec sway" works
<mbakke>\o/
<kamil_>Btw! I'm sure that you don't need swaybg in your config. I installed sway, without it, and the default wallpaper is there displayed.
<mbakke>I think swaybg is "hard coded" in the sway package, you can check with 'guix size sway | grep swaybg'
<bdju>ah, alright
<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"
<lfam>The socket does exist
<lfam>Is there anything I should be doing differently?
<lfam>The socket's permissions are srwxr-xr-x
<boeg>it doesn't seem like ufw is available - is there some other "blessed" firewall for guix?
<lfam>There's an iptables service
<lfam>It would be great to have something easier though
<boeg>yes indeed
<boeg>ufw is so damn simple to use
<lfam>Although, the imperative style of ufw is not really going to fit with Guix. I think the best solution would be a Guix-native abstraction of iptables with some simple rules pre-written available
<boeg>lfam: perhaps yes
<lfam>I assume that ufw can be used declaratively... I've just never looked into it
<lfam>There was a brief discussion on packaging ufw: https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00182.html
<boeg>interesting
<lfam>I think that it probably would not be difficult to package ufw, if it's all written in python
<boeg>lfam: right
<jonsger>boeg: I'm using iptables like this https://gitlab.com/jonsger/jonsger-guix/-/blob/master/config/guix-contabo.scm#L179
<lfam>jonsger: Would you consider adding a section to the cookbook about it?
<lfam>Hm, I guess the manual already has a clear example!
<jonsger>lfam: yes here http://guix.gnu.org/manual/en/guix.html#index-iptables_002dservice_002dtype
<jonsger>and the rest is really iptables doc
<lfam>Right, I don't think we need a recipe in that case, unless someone things we are missing some example that would be desired
<jonsger>and tbh I found it easier then with firewalld on openSUSE
<boeg>jonsger: thanks
<boeg>Often when I boot, xorg doesn’t load my trackpad (bcm5974) and then I can’t move my mouse and so on. Some times it works though. Can I somehow tell xorg to always load me trackpad ?
<lfam>I think it's supposed to!
<lfam>Sounds like a bug
<boeg>It looks like it thinks my Bluetooth is mouse
<boeg>I can share logs
<bricewge>boeg: It should be fixed https://issues.guix.info/35574
<bricewge>bcm5974 is the kernel module part, no?
<boeg>Yes I think so
<boeg>I can share the logs where it succeeds and where it fails. Maybe that will shed light
<boeg>2sec
<boeg>Success: https://0x0.st/ipsw.log
<bricewge>boeg: Then it should be fixed, usbmouse which was racing against bcm5974 has been blacklisted by default.
<boeg>Failure: https://0x0.st/ipst.log
<boeg>If you don’t mind checking the logs - it doesn’t look like it’s fixed
<bricewge>boeg: Looks like it come from a bluetooth module this time, can you share the full dmesg?
<boeg>bricewge: i added blacklist of usbmouse to my config and reconfigured my system, and it seems to fix it. Just gonna reboot 5 times and see if it holds true
<boeg>or if it fials before five times
<bricewge>It won't fixed it think, I don't see it in the logs
*janneke sends an email with at least 3 typos
<bricewge>boeg: Just check to see what is blacklisted /run/current-system/parameters
<boeg>3 times working
<boeg>bricewge: 5 times working
<boeg>i'm gonna save the link you sent, and if it suddenly doesn't work again, then i'll return to the issue, but seems to be working now
<bricewge>The patch has been merged 20 day or so ago, so the module should have been blacklisted already if you have an up-to-date system
<boeg>bricewge: should be up-to-date
<bricewge>Then they are false positives, share the file I just talked about
<boeg>bricewge: actually, maybe i'm not up-to-date
<boeg>i'm using nonguix for hardware support
<boeg>maybe it hasn't merged from upstream?
<boeg>bricewge: however i can share what you said
<boeg>bricewge: doesn't make sense for me to share /run/current-system/parameters since i have manually blacklisted usbmouse, does it?
<boeg>then i should undo that, and then check it right?
<boeg>i can do that
<bricewge>boeg: Please carefully read the README from the channel you are talking about: we can't help you with nonfree software here
<bricewge>Does usbkbd is blacklisted there too?
<boeg>bricewge: this is current blacklist from /run/current-system/parameters: modprobe.blacklist=bluetooth,btusb,uvcvideo,usbmouse"
<boeg>but note i have manually added all those things
<boeg>however i dunno if i manually remove usbmouse, if it will still be blacklisted as per the patch
<bricewge>There are no "merged from upstream" in regard to channels. You are using guix, in addition to your channels
<boeg>right, okay
<bricewge>boeg: Can you share the guix's commit returned buy “guix describe”?
<boeg>yes
<boeg>looks a bit weird
<boeg>bricewge: commit: 50ea3135e0948a042cd3b899e970f6ade291a0c2
<boeg>thats guix channel
<boeg>bricewge: should i try and remove my manual blacklist of usbmouse and then reconfigure and then check /run/current-system/parameters ?
<bricewge>Yes
<boeg>alright
<bricewge>You are updat date in regard to guix
<boeg>do i need to reboot before checking /run/current-system/parameters ?
<boeg>after reboot its not in the blacklist list
<boeg>after reconfigure *
<boeg>no reboot
<boeg>so maybe its because i'm manually setting the blacklist?
<bricewge>nope no need
<boeg>i have modprobe.blacklist=... as part of my kernel-arguments
<boeg>perhaps thats overriding the blacklist of usbmouse?
<bricewge>boeg: Ok I think I got it, if blacklisting usbmouse really fix your issue
<boeg>it seems to
<bricewge>Yes append %default-kernel-arguments
<boeg>5 boots
<rekado>Fedora seems to do without the .a files.
<rekado>I wonder if we could suppress their generation
<boeg>bricewge: alright
<boeg>bricewge: with that, i now also have blacklist of usbmouse and usbkbd
<boeg>so i was overriding it
<boeg>thanks a lot
<bricewge>Yes, and you'll get further update to this field if it's change in GUix
<bricewge>rekado: You mean from the build-systems?
<boeg>bricewge: thats good, thanks
<bricewge>boeg: You're welcome :)
<bricewge>rekado: Some package tests rely on them IIRC
<rekado>removing them could save so much space.
<boeg>do i need to do something other than install wireguard-linux-compat and wireguard-tools to have wireguard work? I get the following error: "Unable to access interface: Protocol not supported"
<rekado>I noticed that at least one of the packages failed when it can’t find a .a file of an input, but maybe that’s exceptional
<boeg>i'm trying with "sudo wg-quick up dk3" where dk3 is corresponding to a file /etc/wireguard/dk3.conf
<bricewge>boeg: We are missing doc regarding wireguard https://issues.guix.info/41080
<boeg>bricewge: thanks
<bricewge>You need the compat pacakge in kernel-loadable-modules and the service “(simple-service 'wireguard-module kernel-module-loader-service-type '("wireguard"))”
<bricewge>boeg: And reboot. If you want to use it with network-manager you'll need https://issues.guix.info/issue/41193#38 too
<boeg>bricewge: alright, thanks
<vagrantc>bdju: did you get sway working? i booted a machine where i have it working
<vagrantc>bdju: could share the parts of the config...
<lfam>Another cookbook recipe!
<janneke>lfam: silly question...but are you sure your herd command creates and later looks at the same socket file?
<lfam>janneke: Nope!
<janneke>just to rule out the most obvious case ;)
<lfam>I'm not sure how to find out...
<lfam>I have 'XDG_RUNTIME_DIR=/home/leo/run'. That variable is recommended in the Shepherd docs
<lfam>I don't really know anything about sockets so I feel lost
<janneke>ah, i was thinking in that direction, yes
<janneke>looking once in /run/xx/ and another time in ~/run or ~/.config or so
<lfam>I had trouble like that when I reinstalled, but then I remembered that I had to set XDG_RUNTIME_DIRS "custom" in my ~/.profile
<lfam>This used to work with an older shepherd. It's a regression since core-updates IIUC
<janneke>lfam: me neither...you could use lsof on the socket and look if the process lives, or if root can talk to it?
<janneke>lfam: ah!
<lfam>Good ideas, thanks. I will try
<boeg>bricewge: i'm not sure how to use that website - on what should that piece of configuration be?
<boeg>bricewge: to make wireguard work with network-manager
<bricewge>rekado: I tried the commenting feature of Mumi again to not let you alone eating dog food but I still get “There was an error submitting your comment!”
<bricewge>boeg: Do you redirect all your traffic trough wireguard, or just a subnet?
<boeg>bricewge: all
<bricewge>Then you need the patch series
<boeg>oh
<boeg>bricewge: when do you think it'll be merged in?
<bricewge>If you know git and how to apply patches, follow the chapter 14 of the manual and apply the patchset on top of guix
<bricewge>boeg: IDK I just pushed an updated version of the patch a few hours ago
<boeg>alright
<boeg>thanks
<bricewge>lfam: The test you suggested me to run for https://issues.guix.info/41080 is broken in master for >2 month
<bricewge>How should I proceed with the patchset?
<lfam>Can you remind me which bug ticket the discussion was in?
<boeg>bricewge: how do i download the patchset from that website? I cannot figure it out.
<bricewge>lfam: Arf wrong link https://issues.guix.info/issue/41193?comment-error#20
<bricewge>About the network-manager suite
<bricewge>update
<lfam>boeg: There's a little "download" icon in the upper right of each message box
<lfam>Do you see it?
<boeg>oh
<boeg>theres a box masking it
<lfam>It's a bit obscure...
<lfam>Weird!
<lfam>Like a "no font for this" box?
<bricewge>The gui-installed-desktop-os-encrypted test fail since ~9 april https://issues.guix.info/40790#4
<boeg>seeh ere
<boeg> https://usercontent.irccloud-cdn.com/file/QBadXYp1/2020-05-22_2560x1600.png
<boeg>cannot see the download icon :D
<lfam>Oh boeg :(
<lfam>I don't have the box
<boeg>:D
<bricewge>reduce the font size ;)
<boeg>yeah
<boeg>is there one of them that downloads it all?
<lfam>I see
<boeg>or do i manually need to go through each?
<boeg>yes, i guess so
<mbakke>lfam: there should not be any differences wrt XDG_RUNTIME_DIR since the core-updates merge, methinks
<lfam>Right
<lfam>bricewge: I replied on the mailing list to say "please push"
<lfam>Thanks a lot for working on this!
<bricewge>lfam: Thank you :)
<bricewge>boeg: Don't bother applying the patches I'll merge them
<boeg>bricewge: but isn't there a process or something before its ready? Like it takes a while - like days, right?
<lfam>After bricewge pushes the patches to our master branch, they are available instantly from `guix pull`
<boeg>oh, cool
<lfam>You will have to compile anything that isn't built yet on the build farm, and that should normally take minutes or hours
<boeg>lfam: ill give it a shot :)
<lfam>Basically, each time somebody pushes to the master branch, the build farm begins building the changes. In most cases it's done very quickly
<lfam>There are some outliers or problematic packages
<lfam>I deleted the socket file (it dated to February) and things seem to be working better now, janneke and mbakke
<boeg>lfam: cool!
<boeg>lfam: i just didn't know if guix was using "released" or what
<mbakke>is there a way to figure out what's holding the sqlite db lock? Berlin has been stuck more than an hour due to "SQLite database is busy"
<boeg>i guess i never checked :D
<boeg>releases*
<lfam>boeg: We do it as a rolling release, and then periodically do "real" releases so that people can get new installers and such
<boeg>lfam: good to know
<janneke>lfam: good!
<lfam>We actually would like to do real releases more often, because we do it so seldom that it's always a painful process
<boeg>interesting
<boeg>bricewge: can you ping me when its pushed to master?
<civodul>mbakke: "guix processes" should give you an idea
<civodul>if there are many different clients, then you're likely to hit that
<bricewge>boeg: Yes
<boeg>bricewge: thank you
<civodul>janneke: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cd5d5f53228fd5bf96d9f790aa2606ae71fa68d7 !
<civodul>thanks a lot!
<mbakke>right, there are quite a few processes fighting for the DB atm
<janneke>civodul: yw, thanks for nudging me
<mbakke>I think many of them are "stuck" on the deduplication stage
<janneke>hah, and you fixed a documentation bug; "sweet" i guess
*janneke should nah, *could* watch guile development more closely
<civodul>:-)
<civodul>mbakke: deduplication upon build/substitution completion is quick
<civodul>but yeah, they're stuck somewhere
<janneke>well, at least someone reads documentation -- even if it's after (not gonna say how many) years of using guile
<civodul>it could be that there's a couple of them stuck doing nothing
<civodul>but that in turn that keeps the db busy
<civodul>janneke: yeah i was surprised to see it was actually explicitly documented!
<janneke>yeah i was pleased with the excellent documentation when trying to avoid loadin sqlite3 :-D
<lispmacs[work]>how do I list the details of the previous guix generation?
<lispmacs[work]>guix describe doesn't seem to have an option for that, or I'm missing it
<lispmacs[work]>oh, nvm, I guess you have to get that info with guix pull
<vagrantc>looks like nix got accepted into debian ... finally need to dust off my guix packaging and upload it... :)
<janneke>you were waiting for nix?
*janneke chuckles about how that would translate to dutch
<vagrantc>janneke: not waiting, per se, but that it got through review means at least it's possible :)
<lfam>Does anyone what files to delete to work around the ABI change today?
<lfam>Rather than deleting all the .go files?
<janneke>vagrantc: right, that makes sense :)
<vagrantc>janneke: and feels like a nudge to get it updated ...
<vagrantc>although i think nix separates it's package repository from the core code?
<vagrantc>more than guix, anyways
<civodul>lfam: in this case, "make clean-go"
<civodul>because the ABI change is in <origin> and most of the files use that...
<civodul>but that's ok, you can enjoy the view or have a drink meanwhile :-)
<lfam>Ah, makes sense civodul
<lfam>Yes! It's almost 17 hrs here :)
<ryanprior>vagrantc: it seems like getting Guix accepted in Debian is pretty realistic? I was reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850644
<ryanprior>And I really appreciate all your work pushing that forward.
<vagrantc>last i checked, my branch more-or-less worked, but now i'm thinking i should update all the dependencies to guile3.x
<vagrantc>i think there were a few outstanding test failures
<civodul>vagrantc: hopefully rlb updated some of the packages to Guile 3?
<civodul>anyway, let us know how it goes!
<vagrantc>civodul: the core guile 3.x is in debian, but the various guile-* libraries aren't
<vagrantc>civodul: i'm the maintainer of most of them guix uses, so ... :)
<bricewge>boeg: Pushed, sorry for the delay I had to refresh my gpg key
<boeg>bricewge: no problem! thanks!
<rekado>bricewge: do you have cookies enabled on issues.guix.gnu.org?
<boeg>bricewge: shouldnt it be visible here? https://git.savannah.gnu.org/cgit/guix.git/log/
<rekado>there are a bunch of little annoying checks that I’m performing when a comment is submitted
<rekado>one of them is that a “reasonable” amount of time has passed since loading the page
<boeg>or perhaps there is a lack on when it appears on the site
<rekado>another is that the issue id in the signed cookie matches the current issue id
<rekado>etc.
<rekado>all that to prevent automated spamming
<rekado>you can get a list of all checks in the mumi sources (I think it’s controller.scm)
<rekado>but I’ll say that I see in the logs that other people besides me have successfully used the comment feature already.
<jonsger>why does CI not find http://ci.guix.gnu.org/search?query=icedove
<rekado>that’s a good question!
<bricewge>boeg: It took it's time but it's there now
<rekado>it searches for the nix_name in the database
<boeg>bricewge: ah yes!
<bricewge>rekado: Good catch, cookies weren't enabled because I was using http instead of https
<bricewge>Redirecting to HTTPS could be usefull there.
<rekado>I want to add an authenticated mode for people who fear they might be impersonated. Show a little “verified” tick mark next to their name.
<bricewge>Nice to hear that it's used now
<rekado>authentication via client cert; I’m a one-trick pony
<bricewge>Wow, that would be nice
<bricewge>rekado: BTW did you saw https://usercontent.irccloud-cdn.com/file/QBadXYp1/2020-05-22_2560x1600.png?
<bricewge>Download button is hidden, boeg had to decrease it's font size to access it
<rekado>oh, hmm
<rekado>the font size looks kinda big
<rekado>it’s much smaller here
<rekado>it’s not supposed to be that big
<rekado>does it look the same in icecat?
<bricewge>Yes it's fine on a large screen, for sure
<boeg>rekado: its 100% but yes, its a bit big, but it has probably something to do with me having trouble getting xorg and gtk and so on configured properly for my HiDPI display
<rekado>ah, HiDPI
<rekado>HiDPI is messy :-/
<boeg>yeah
<boeg>my cursor is also reaaaaaaly tiny :P
<rekado>and I don’t have any such screen, so I can’t test it
<rekado>if you have a magic CSS rule that fixes this in relation to HiDPI settings I’ll gladly add it
<boeg>dont think I have such a rule :D
<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
<lfam>Wireguard doesn't do ping
<boeg>i cannot load a website for that matter
<lfam>Ping uses ICMP packages but Wireguard uses UDP
<boeg>but i should be able to ping even connected with wireguard?
<lfam>s/packages/packets
<boeg>sure, but i should still be able to ping no?
<boeg>not over wireguard perhpas but in general
<lfam>wg-quick should not allow anything to go around wireguard
<boeg>ah okay
<lfam>You might have trouble with DNS, I dunno
<lfam>Check your network interfaces with `ip` to see what it did
<bricewge>boeg: Mixing netowrk-manager's wireguard and wg-quick doesn't mix well
<lfam>Well, maybe ping should work, not sure
<bricewge>wg-quick is a “quick and dirty script“ using nmcli is probably better
<lfam>wg-quick used to work for me but I've been home for months so I stopped using it
<boeg>bricewge: ah okay
<bricewge>lfam: Yes it work I'm just citing the author here https://git.zx2c4.com/wireguard-tools/tree/README.md#n47
<bricewge>boeg: Last time I mixed the two I had to reboot because the route weren't correct anymore
<boeg>good to know
<boeg>bricewge: cant get it to work unfortunately
<boeg>i just should import the connection with nmcli and then connect it right?
<boeg>should work?
<boeg>`wg` says i'm connected, but cannot load a page in a browser e.g.
<boeg>as soon as i `nmcli connection down xxx` i can
<bricewge>Yes it should
<bricewge>Let me try it again
<boeg>bricewge: Alright. This is what i have configured, bricewge: https://git.sr.ht/~boeg/home/tree/master/.config/guix/system/config.scm lines: 50 and 163
<bricewge>It work here, but putting the connection down don't resolve /etc/resolv.conf tho, I'll have to investigate that...
<boeg>bricewge: alright, i'm just trying to kick it a bit, maybe it'll help
<boeg>i think perhaps i forgot to reconfigure ... maybe i only pulled :/
<bricewge>boeg: nmcli --version?
<boeg>1.18.4
<bricewge>1.18 had the issue you reported
<boeg>so i forgot to reconfigure. Brilliant
<bricewge>I thought about asking you for the version of nmcli, but it seemed rude
<boeg>bricewge: talk to me like i'm 3
<boeg>:)
***jonsger1 is now known as jonsger