IRC channel logs

2020-08-14.log

back to list of logs

***dingenskirchen1 is now known as dingenskirchen
<joshuaBPMan>so I just did a ran "wget --version". It's an interesting out put on Guix system. It says how wget was compiled.
<joshuaBPMan>I've never seen that before.
<lfam>wget from Debian does something similar
<lfam>It must be handy for analyzing bug reports
<joshuaBPMan>lfam: I bet it is very handy.
<brettgilio>Is texlive-texmf failing to substitute for anybody else?
<apteryx>pkill9: ah, I get that pulseaudio behavior in ungoogled-chromium as well (it seems to bypass it unless I start it before chromium launches)
<apteryx>my workaround is usually launching pavucontrol before launching chromium
<pkill9>yea
<pkill9>is it binding to ALSA?
<apteryx>I wonder what could be done to fix this annoying behavior, and whether it's Guix specific
<apteryx>it only seems to happen on my work desktop (perhaps I have some application making use of pulse at home at all time, not sure)
<apteryx>pkill9: how do I check if it's binding to ALSA?
<pkill9>no idea
<pkill9>but i assume it is
<pkill9>since the audio still works
<apteryx>I tried starting 'chromium' from home via ssh -Y (x11 fowarding), but it won't display after a couple minutes, eh.
<apteryx>well it seems something is keeping pulse alive (perhaps jami, or linphone, both are running)
<apteryx>so I don't know how launching pavucontrol would help the situation
<apteryx>the best issue match I've encountered so far is this: https://bugs.chromium.org/p/chromium/issues/detail?id=968540&q=microphone%20pulseaudio&can=1
<apteryx>if pulseaudio stream gets closed for some reason the audio capture will fail working
<apteryx>on my home system it seems to work alright (chromium registers with pulse)
<apteryx>the above bug could cause an issue if pulseaudio crashes (I was puzzled that chromium couldn't detect my mic before, that bug can explain that)
<apteryx>pkill9: do you have a repro for chromium not starting pulse by itself? seems to work for me
<apteryx>it will create it only when it requires access to sound
<apteryx>pkill9: I answered on the bug thread
<telior>howdy! anyone here using pass? I'm having some issues migrating from arch, usually I just need to copy my .gnupg and .password-store folders to home, but now I get errors both from pass and from gpg: if I run `pass` it lists all my keys, but when I ask for a specific foo key I get `gpg: WARNING: unsafe permissions on homedir
<telior>'/home/telior/.gnupg'gpg: decryption failed: No secret key`. When I run `env` GPGHOME doesn't appear, yet gpg --help does show my Home folder as it should. I'm guessing it was to do with how Guix handles permissions, but I'm not sure
<blackbeard[m]1>telior: hi, where you able to solve it?
<apteryx>eh, guix copy returns a segmentatino fault
<jackhill>apteryx: I think there may be a bug report open about that, but I can't find it now.
<rndd>hi everyone!
<klys>hi
***lukedashjr is now known as luke-jr
***apteryx is now known as Guest78459
***apteryx_ is now known as apteryx
<Noclip>Is software that has been installed with guix faster than the binary packages from most other distros like debian?
<slyfox>probably not
<Noclip>Why is it then used for high performance computing?
<raghavgururajan>sneek, later tell nckx: Here is the patch to fix build failure of OpenCV. https://git.disroot.org/raghavgururajan/guix-wip-desktop/commit/79fdf5d1087bfadc6894e34b37fad038fb60c032.patch
<sneek>Got it.
<leoprikler>Noclip: HPC does not mean "I get to install Thunderbird really fast".
<Noclip>leoprikler: I'm not talking about the install time here but about the speed of the already installed programm itself.
<leoprikler>Oops, read that sentence wrong.
<Noclip>That's why I said "software that has been installed with guix".
<Noclip>Ok
<leoprikler>The thing is I read "installed with guix faster than binary packages"
<leoprikler>so my brain added a "there" after the initial "Is" to make sense of it.
<Noclip>Mhh, interesting 😂. I hope slyfox didn't also read it wrong.
<raghavgururajan>/leoprikler needs coffee
<raghavgururajan>xD
<leoprikler>I just woke up and don't drink coffee.
<leoprikler>Shocking, I know.
<Noclip>leoprikler: I already had to learn that installing packages with guix can be very slow even if nothing has to be build.
<raghavgururajan>o.o
<Noclip>But I think I can life with that as I don't plan to install a new package every five minutes.
<leoprikler>To answer your question, HPC is not just about HP. While performance is critical, how software is installed is rarely critical for perfomance.
<Noclip>leoprikler: That still doesn't seem to answer my initial question.
<leoprikler>At worst, you get some penalties from Guix and similar solutions when it comes to resolving symlinks at startup.
<leoprikler>Now, the big issue where Guix/Nix/what-have-you can help HPC is in the area of reproducibility.
<leoprikler>HPC is done for the sake of *science* and reading a paper ten years later you can't really be sure whether their results add up much of the time.
<Noclip>Why is reproducibility so important for HPC?
<Noclip>Mhh, that makes sense.
<PurpleSym>What’s your use-case Noclip?
<Noclip>PurpleSym: I'm just interested in general.
<leoprikler>If you look at hpc.guix.info, you actually get two other reasons as well in per-user packages/environments
<PurpleSym>↑ This. And if you really wanted speed you could probably fiddle with CFLAGS somehow (override the build system?) and skip binary substitutes.
<leoprikler>you can define your own package and override e.g. #:make-flags to fiddle in some CFLAGS or add phases to patch the build system files
<leoprikler>At that point you will no longer have substitutes, though, since your custom packages won't build on Guix CI.
<Noclip>Well I really do want substitues xD
<leoprikler>In that case using Guix weather and not using `guix pull` with commits, that are a couple of hours old is usually the way to go
<leoprikler>not using => using
<Noclip>Do you know why there hasn't been an ungoogled-chromium substitute for the last days?
<leoprikler>I wanted to say not using `guix pull` to pull directly from HEAD :(
<leoprikler>Because it fails to build on CI, unfortunately.
<Noclip>You could also do "guix pull" and then wait a few hours before "guix upgrade", right?
<leoprikler>Meaning it is likely to fail locally too.
<leoprikler>That is correct
<Noclip>"Meaning it is likely to fail locally too."
<Noclip>Good to know. Then I don't have to let my pc go up in flames if it will fail anyways.
<Noclip>How do I know if a package failed to build on CI?
<leoprikler>Chromium was never that efficient at HPC anyways 😋️
<leoprikler>There's a web interface at ci.guix.gnu.org
***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
<raghavgururajan>sneek, later tell nckx: The correct link is https://git.disroot.org/raghavgururajan/guix-wip-desktop/commit/79fdf5d1087bfadc6894e34b37fad038fb60c032.patch
<sneek>Will do.
<str1ngs>leoprikler: Hello based on your feedback I've much improved Nomad's ibuffer. https://bufio.org/images/2020-08-14-035028_2044x2117_scrot.png . Though since I use C-n C-p I was not aware emacsy does not support <up> <down> . So I'll need to fix that in emacsy.
<leoprikler>screenshot-wise that looks pretty nice
<str1ngs>still need work on formatting. and marks do not work. though d will kill the buffer on the line. short term stop feature.
<leoprikler>baby steps :)
<leoprikler>It's sure nice to see, how nomad will make emacsy mature as well.
<str1ngs>Though this will probably be inferior ibuffer. And later ibuffer will be done with Gtk controls. The nice thing inferior will work with any toolkit that has a text-buffer.
<jonsger>I get sometimes segmentation faults with `guix copy` does it work for others?
<KimaprOnPhone>Hello guix, killed my system again :)
<KimaprOnPhone>Now it's a bit different
<KimaprOnPhone>I deleted (backing it up onto another partition of course) my home partition (mounted as /home/kimapr) as i'm on MBR and already had my partition limit reached
<KimaprOnPhone>so i could create an extended partition and reinstall guix system there
<KimaprOnPhone>Everything went good until my computer rebooted because our electricity provider is crap which cant give stable voltage
<KimaprOnPhone>Hmmm, maybe i can create a dummy partition with same label as my home partition
<KimaprOnPhone>Or just relabel existing one
<KimaprOnPhone>And oof will have to do that on windows
<KimaprOnPhone>I definitely need an actual OS for these incidents...
<rekado_>KimaprOnPhone: can’t you boot the installer image and use a shell there?
<KimaprOnWindows>can't
<efraim>serf-1.3.8 from the 0.12.0 release FTBFS on mips64el
<guix-vits>o o ------------------
<guix-vits> V \ Hello, world!/
<V>guix-vits: what
*guix-vits hides
<apteryx>jonsger: there's already a bug about it
<apteryx>it has to do with guile-libssh
<apteryx>this one: http://issues.guix.gnu.org/42740
<butterypancake>Does anyone else get tired of their hardware not working super well on libre distributions? Like idk if I could even get working Bluetooth without it being a USB adapter (would prefer to use a Bluetooth WiFi combo card), the lack of firmware for graphics cards means any modern GPU is really not that useful (no hardware video acceleration or video games for me), and I can't get my work yubikey to work even after installing the u2F udev
<butterypancake>rules (I guess the firmware I need is in the non-libre Linux kernel but I can't seem to figure it out). Don't get me wrong, I love libre because I can (in theory) trouble shoot any problem and customize literally everything. I just really wish I could go out and buy hardware that actually works on libre :/
<apteryx>We'll need to get serious at free hardware at some point :-)
<Kimapr>okay i'm able to boot now
<apteryx>wow, 331 patches landing in master for the GNOME rework of raghavgururajan!
<rekado_>butterypancake: are you using the pcscd service for your yubikey?
<apteryx>raghavgururajan: congratulations, and thank you!
<rekado_>I also have a yubikey, but I haven’t yet taken the time (for about a year now!) to configure it.
*rekado_ notes that the pagination on ci.guix.gnu.org is weird again.
<rekado_>butterypancake: a GPU from 2010 is no longer modern, is it?
<apteryx>I thought some people had success with yubikey. I think ambrevar.
<apteryx>is there no cookbook entry yet for it? :-)
<rekado_>on ci.guix.gnu.org I again see lots of builds that are marked as failed where the logs show that the build completed successfully.
<rekado_>there should be one!
<rekado_>someone’s gotta write it
<raghavgururajan>apteryx: Thank you! :-)
*raghavgururajan is not done yet
<vivasvat>is there any way to do the declarative system management with guix when using it on a host distrobution?
<vivasvat>Nix has 'homemanager' if I recall which allows you to do such
<raghavgururajan>sneek, later tell nckx: Never mind about the OpenCV. Danny pushed my build-fix patch to master.
<sneek>Will do.
<Kimapr>why doesn't guix system reconfigure seem to alter the existing users on machine?
<Kimapr>i once altered the `comment` part of my user and it didn't actually update it
<jonsger>ah merci for the hint apteryx
<Kimapr>i wonder if that is fixed already
<apteryx>de rien!
<raghavgururajan>jonsger, OpenCV is fixed now. :-)
<apteryx>Kimapr: even after re-login?
<telior>hi blackbeard[m]1, I saw your answer on the logs, no, not yet :c.
<Kimapr>when logged out the new `comment` doesn't show up in gdm
<Kimapr>and i actually inspected passwd to see what was wrong and it was indeed old `comment`
<telior>Also, forgot to mention that running `gpg -d foo.gpg` gives back `gpg: WARNING: unsafe permissions on homedir '/home/telior/.gnupg'gpg: encrypted with 4096-bit RSA key, ID myKeyID, created 2020-06-09 "Telior <mail@mailserver.com>"gpg: public key decryption failed: No pinentrygpg: decryption failed: No secret key`
<vivasvat>also does anyone know when emacs 27.1 will be available in the repos
<apteryx>as soon as someone gets to updating it ;-)
<apteryx>which I reckon should be soon
<nckx>raghavgururajan: I already fixed OpenCV on master yesterday.
<sneek>Welcome back nckx, you have 3 messages!
<sneek>nckx, raghavgururajan says: Here is the patch to fix build failure of OpenCV. https://git.disroot.org/raghavgururajan/guix-wip-desktop/commit/79fdf5d1087bfadc6894e34b37fad038fb60c032.patch
<sneek>nckx, raghavgururajan says: The correct link is https://git.disroot.org/raghavgururajan/guix-wip-desktop/commit/79fdf5d1087bfadc6894e34b37fad038fb60c032.patch
<sneek>nckx, raghavgururajan says: Never mind about the OpenCV. Danny pushed my build-fix patch to master.
<apteryx>vivasvat: there's something similar for Guix, maintained as a channel: https://framagit.org/tyreunom/guix-home-manager
<apteryx>homemanager and declarative guix system are different things though. One is to manage your home files as a Guix profile, the other to manage your system.
<raghavgururajan>nckx: Oh!
<apteryx>home files and user services I guess. I've yet to try it (shame!).
<butterypancake>rekado_: I thought installing the U2F udev stuff was enough. When I have time I'll look into pcscd. If I get any success maybe I'll add my findings to the guix-cookbook :)
<vivasvat>wow very cool apteryx
<vivasvat>ill check it out
<nckx>raghavgururajan: It's OK, I'll revert it.
<nckx>git: error: ...: object corrupt or missing: .git/objects/87/...
<nckx>Yay, good morning Guix.
<apteryx>good morning, nckx
<butterypancake>so I want to package searx. Well I mean I have a working searx patch ready to go. The problem is that it uses some odd python requirements.txt thing to specify the exact version it want of all of it's depencies. As that's really annoying, I did a search and replace on the file to turn those versions in to minimum version requirements instead of exact. But it wants a more modern python-lxml than we have. So I packaged the new
<butterypancake>python-lxml. But that made it into core-updates instead of master :/ so should I: a) use the older python-lxml and pray it works (it seems to), b) package an older version of searx (seems pretty lame), or c) put searx into the core-updates branch (also seems pretty lame)
<apteryx>a) seems a decent option
<apteryx>especially if it comes with a test suite that gives us confidence it really works
<butterypancake>searx is a self hosted search engine so it'll run on servers and should probably be reliable btw
<butterypancake>but it does seem to have a test suite, so it should be fine I guess
<vivasvat>whenever I try to install anything, I get ``substitute: guile: warning: failed to install locale'' error. I have set GUIX_LOCPATH and installed glibc-locales, but the error keeps recurring :(.
<butterypancake>vivasvat: same. but I don't think I every bothered to set GUIX_LOCPATH. I did install glibc-locales
<nckx>butterypancake: Choose d) package a new python-lxml-x.y & use it only for Searx.
<Kimapr[m]>does guix support btrfs as root partition?
<nckx>Yes.
<vivasvat>any fix you know of butterypancake? :p
<butterypancake>nckx: oh, that's a really good idea. I should send that as a patchset with one patch for python-lxml and one for searx right?
<vivasvat>wait what sould be the downside of packaging a newer version? nckx?
<Kimapr[m]>nice, does btrfs use copy-on-write by default for everything?
<butterypancake>vivasvat: ignoring it is currently my solution
<butterypancake>vivasvat: if the newer version is pushed, 1500 packages will need a rebuild. so it'll be pushed in a few months instead with lots of other packages that cause many rebuilds
<vivasvat>ohh
<nckx>Kimapr[m]: Yes, which can ruin some databases' performance, so you might want to chattr +C (=disable CoW) on some directories before installing Guix. That's not related to Guix though.
<nckx>butterypancake: Sounds good.
<vivasvat>so basically the idea is to push all the new rebuilds into a later date butterypancake?
<nckx>vivasvat: Yep.
<Kimapr[m]>And does it save the old versions of files after writing forever (until i decide to delete them)?
<vivasvat>that way people only have to spend time compiling stuff once and get everything out of the way than every day
<nckx>vivasvat: Even better, we let the CI build the core-updates branch before it's merged into master.
<butterypancake>it's written in detail in the guix manual contrib section. We have a staging branch for medium sized rebuild changes and a core-updates for big ones. I think they merge on the build server a few days ahead of time so there substitues avliable
<apteryx>Kimapr[m]: not unless you take snapshots
<Kimapr[m]>nckx: can't i use the chattr *after* installing Guix in running Guix System?
<nckx>Kimapr[m]: ☝ btrfs is not a versioned/log file system. Linux has one or two of those but Guix System can't boot from them yet.
<nckx>Kimapr[m]: It only takes effect on empty files, or files created in a directory with that attribute already set.
<vivasvat>butterypancake: so essentially different branches equivalent to like 'testing' and 'stable'
<nckx>So doing it after means tedious semi-manual copying.
<butterypancake>vivasvat: nah, they're not more or less stable. They just use slightly newer dependencies
<vivasvat>ohhh ok, makes sense I guess
<apteryx>Kimapr[m]: I haven't bothere chattr +C files on any of my systems, and I haven't felt any pain yet.
<vivasvat>why wouldn't I be following the most up to date branch then?
<nckx>Kimapr[m], apteryx: I think btrfs's behaviour has improved in recent years (after I stopped using it for most things); it now more actively defrags things or at least has a mount option to do so (autodefrag).
<butterypancake>vivasvat: those branches don't get the updates that are pushed to master I think? (I'm not the one to say how this works :P) so master is actually more up to date than those. Also master has substitutes and those branches, maybe don't? (again, ask someone who knows :P)
<nckx>But in 2015 Cow absolutely did murder guix performance through insane /var/guix/db fragmentation.
<Kimapr[m]>I just want a filesystem that can tolerate unexpected shutdowns of the machine as my electricity services are bad and computer's power block is not powerful enough to go through sudden voltage changes without rebooting
<nckx>On a rotating drive, at least, it became unusable.
<apteryx>Kimapr[m]: also not that disabling CoW on some files removing the ability to snapshot them (duh), and also the ability to detect data corruption using checksums.
<nckx>And compression.
<nckx>Basically, all the shiny.
<vivasvat>alright makes sense I guess, thanks!
<butterypancake>vivasvat: so like, master has more up to date programs that you're likely to use. and the other branches have more up to date dependencies, but the programs themselves are a few updates behind. (someone plz correct me if I'm spitting misinformation)
<apteryx>upstream recommendation is usually: unless you have a benchmarked performance reason to do so, leave CoW on.
<apteryx>to *not* do so
<nckx>butterypancake, vivasvat: That is correct. master will see (say) hundreds of updates while core-updates receives relatively a few ‘deep-reaching’ ones like GCC etc, but the leaf packages are left outdated.
<butterypancake>nckx: Thanks, I just like to hear myself talk so getting someone actually knowledgeable to confirm makes me happy :)
<apteryx>but master can be merged into core-updates at any time, so core-updates can be considered a superset of master, in my view.
<nckx>apteryx: It ‘can be’. 😛
<nckx>It's not merged often enough to call it a bleeding-edge branch IMO.
<nckx>It's what it is: core updates.
<butterypancake>last merged july 23rd
<apteryx>we could have a cron job ;-)
<vivasvat>thanks nckx and butterypancake for the help
<vivasvat>is all this information in the manual
<vivasvat>To be honest the manual is like a forest and a bit intimidating, I'm just trying to learn information bit by bit right now :p
<bavier[m]1>the different branches are discussed briefly the 'Submitting Patches' section
<nckx>butterypancake: It's merged whenever a c-u commit relies on/reverts a master commit, so it can be merged twice in one week, or not for a whole month.
<bavier[m]1>the manual is great, it's worth at least going over the high-level sections
<butterypancake>vivasvat: it's a wonderful manual, but you really have to keep revisting it over and over again. I need to remind myself to go over the pre-patch submission checklist more. I've wasted some peoples time by not doing that :P
<vivasvat>I've been planning on reading it in depth, I'm just very new to this and haven't been too honest with doing the reading material (YET!) :p
<bavier[m]1>vivasvat: no problem, glad to have you here!
<nckx>apteryx: Sorry to take what was probably a joke seriously, but: automated merges would create lots of (unguixy) merge commits for no reason, so no 😛
<butterypancake>vivasvat: I highly suggest just going for it a bit too. Getting feedback on patches is a huge help. Sure you could have made it a little better with a lot more reading, but using someone else's time to save you a lot of time is often worth it
<butterypancake>vivasvat: like read a bunch and do your best, but it won't be perfect anyways, and that's what makes it fun anyways :P
<vivasvat>Alright, will do :D
<butterypancake>git log --merges | grep '\(^Date\|Merge branch\)'
<butterypancake>
<butterypancake>Date: Thu Jul 23 21:43:06 2020 +0200
<butterypancake> Merge branch 'master' into core-updates
<butterypancake>Date: Mon Jun 22 02:56:22 2020 +0200
<butterypancake> Merge branch 'master' into core-updates
<butterypancake>Date: Sun Jun 14 16:24:34 2020 +0200
<butterypancake> Merge branch 'master' into core-updates
<butterypancake>If you're really curious about when merges happen I made a think for you
<vivasvat>oh thats cool
<vivasvat>seems fairly often
<vivasvat>just one more clarification, in the manual it says core-updates gets merged every 6 months or so
<vivasvat>but in the git log you sent, it seems to be a lot more often, right?
<rekado_>that’s master merged into core-updates, not the other way around
<butterypancake>that was run from the core-updates branch. so that master -> core-updates but you're talking about core-updates -> master
<vivasvat>ohhhhh I see
<butterypancake>damn, ya'll need to stop typing faster than me :(
<vivasvat>that actually makes perfect sense
*rekado_ types more slowly now
<butterypancake>:D
<apteryx>nckx: the cron job AI required to write meaningful commit messages and resolve the potential conflicts is left as an exercise to the reader ;-)
<butterypancake>git log --merges --grep="Merge branch '[[:alpha:]]*'$"
<butterypancake>run that on master to see when we merged other branches into master
<butterypancake>it might not be quite right. I was trying to filter out merges from master into other things
<butterypancake>git log --merges --grep="Merge branch '[[:alpha:]]*'$" | grep '\(^Date\|Merge branch\)'
<butterypancake>same thing but less info
<butterypancake>no wait, I did something very very wrong. I'm not sure what. But it's very wrong
<butterypancake>fixed it!
<butterypancake>git log --merges --grep="Merge branch '[^']*'$"
<butterypancake>I made a big booboo in assuming branch names are made of alphabetical characters
<butterypancake>If my regex and calculations are correct, there are 3 months before the next core-udpates merge. So I should probably just do the thing nckx suggested for searx
<butterypancake>there's guile git bindings right? it'd be cool if you could run make next-merges and it would be like: core-updates last merged XXXX, next merge due XXXX and the same with staging
<nckx>butterypancake: I vaguely remember chatter (mbakke?) that the next c-u merge would be, by now, within the month. Of course these things have a way of slipping. There's certainly no schedule anywhere near ‘next merge due XXXX’ accuracy, sorry.
<butterypancake>nckx: I understand and respect that. When to do something is more complicated than it seems. It would just a fun little thing for people to use as a rough estimate. I meant "due" as in like someone should probably get around to doing it around then. not due as in it will be done by then.
<bdju>anyone here use the Dino xmpp client? I want to make it use a dark theme, but it doesn't appear to have the setting. I've got adwaita-dark as my selected gtk theme so if it uses that, it should just be dark. I even found mention of it having dark theme support while browsing issues.
<janneke>nckx: release first, merge after?
<butterypancake>bdju: looking at dino, one of the dependencies is gsettings-desktop-schemas. I have no clue what that is but maybe a dark theme is a desktop-schema? idk, just spit-balling
<Kimapr[m]>how do you add a device into swap-devices by label?
<nckx>Kimapr[m]: That's not supported yet.
<bdju>butterypancake: thanks for looking into it. I'm not really sure what a desktop schema is myself.
<Kimapr[m]>nckx: maybe uuid?
<nckx>I want to change swap-devices to take records (like file-systems).
<nckx>You can't currently specify priorities either.
<nckx>So you're stuck without striping.
<Kimapr[m]>are "/dev/sdXY" pointers stable if i don't mess with partitioning and devices?
<nckx>Often.
<Kimapr[m]>"Often"? When may it change?
<nckx>It's unlikely, but if you're unlucky your BIOS/controller will mix it up once in a while to keep things fresh.
<raghavgururajan>nckx: What is difference between foo-root-service-type and foo-service-type?
<nckx>It's happened to me before.
<raghavgururajan>I wonder why there is dbus-root-service-type instead of dbus-service-type. While there is both shepherd-root-service-type and shepherd-service-type.
<Kimapr[m]>Will it not boot if it can't identify the listed partition as swap?
<Kimapr[m]>And is it safe to just brute-force all partitions into the swap-devices list?
<nckx>raghavgururajan: I don't know if it's consistent across all services, but IME the ‘root’ service is the ‘root’ of the extension tree. It's meant to be extended and ‘collect’ all the services that do so.
<raghavgururajan>bdju: Does Dino have option to change gtk-themes under settings? If not you will have to manually edit config file in ~/.config/gtk-3.0 or ~/.config/gtk-2.0
<raghavgururajan>nckx: Ah I see.
<nckx>So it's the ‘base’ or ‘template’ service.
<raghavgururajan>nckx: Gotcha!
<raghavgururajan>bdju: The gtk-theme changing options in any application settings, will technically modify the values of config files under those above-mentioned directories. If an application does not have that option in settings, but the application is gtk-based, then you can manually edit the config files.
<bdju>raghavgururajan: there are barely any settings at all in Dino unless I'm missing something. There's a little pop-up with like 3 options.
<raghavgururajan>bdju: Oops!, I meant to type ~/.config/application-name/gtk-X.Y
<bdju>raghavgururajan: also I have my gtk theme set is lxappearance. isn't that a global thing then? my pcmanfm is themed dark, for example
<bdju>ohh didn't know about that
<bdju>I'll take a look
<bdju>nothing in my ~/.config for dino :(
<raghavgururajan>~/.config/gtk-X.Y is global
<raghavgururajan>Oh!
<raghavgururajan>> bdju‎: raghavgururajan: there are barely any settings at all in Dino unless I'm missing something. There's a little pop-up with like 3 options.
<raghavgururajan>So Dino does not have option and does not use canonical method to gtk-theme configs. I ran out of ideas.
<raghavgururajan>> raghavgururajan: also I have my gtk theme set is lxappearance. isn't that a global thing then? my pcmanfm is themed dark, for example
<raghavgururajan>That is correct. When applications are set to use global values, they read from ~/.config/gtk-x.y
<raghavgururajan>But Dino doesn't seem to read from there.
*raghavgururajan installs Dino
<bdju>Yeah, it's a confusing situation. Let me know if you find anything out.
<telior>hi! I still haven't solved my pass/gpg issue, but it seems an emacs/guix user managed to solve it by altering the permissions. Any idea on how to go about it, or where in the manual could I read more on the subject? I tried searching there and on the mailing lists but can't seem to find what I need to solve my problem
<raghavgururajan>bdju: There is not much in the settings. Very minimal interface.
<raghavgururajan>bdju: You can ask around in chat@dino.im
<raghavgururajan>bdju: How did you set your gtk-theme to lxappearance? Did it change vaules in config files or ~/.config/gtk-x.y?
<raghavgururajan>If not, try using gnome-tweak-tool to set global gtk-theme.
<bdju>raghavgururajan: when I said "is" earlier I meant "in". I ran lxappearance and then in there I chose adwaita-dark. and I'm not sure what files it changed. I can look
<bdju>my ~/.config/gtk-3.0/settings.ini shows the gtk theme and icons I picked in lxappearance so yeah it changes those files
<nckx>I just noticed that Guix has a ZRAM service now. I wonder why it's more popular than zswap. Simply because it doesn't require a swap device (which isn't a clear win IMO) or are there other benefits?
<nckx>See how I cleverly made it on-topic for #guix. 👍
<raghavgururajan>bdju: It seems there is an environment value for gtkv3. GTK_THEME
<raghavgururajan>bdju: Try executing `GTK_THEME=Adwaita:dark dino` from terminal
<raghavgururajan>bdju: It works here. `GTK_THEME=Adwaita:dark dino` nicely open dino in dark mode.
<nckx>Oh, ZRAM also has writeback support now, but Guix doesn't expose it.
<bdju>raghavgururajan: fantastic! that works for me. thank you very much!!
<raghavgururajan>bdju: Glad!
<apteryx>nckx: compressed RAM? sounds useful to my old machines
<nckx>apteryx: It is. Zswap + zstd is almost magic. I'm sure zram is too but I haven't used it.
<apteryx>nckx: zstd for RAM is already a thing in the kernel Linux?
<nckx>It's pluggable through the crypto API (which is also the compression API nowadays). If you have CONFIG_CRYPTO_ZSTD=y you can use it there and in several other places (e.g. btrfs).
<nly>how to build an installation image?
<sneek>Welcome back nly, you have 1 message!
<sneek>nly, str1ngs says: take-a-selfie saves to the current working directory aka M-: (getcwd) . It was a quick hack I'd like to switch to using GdkPixbuf so that there is no need scrot or any dependencies.
<nly>thanks str1ngs
<nckx>It allows me to build things that need gigabytes of swap on an 8 GiB machine with a single-digit-% slowdown, vs. close to the 99% (well, that's what it feels like anyway 😛) that real swap on rotating drives used to eat.
<nckx>nly: guix system disk-image --file-system-type=iso9660 gnu/system/install.scm, which is part guix.
<nckx>I'm sure this command is in the manual too, but not where.
<apteryx>nckx: I'm already using it for Btrfs, so I trust it is enabled out of the box in Guix
<nly>thanks ncks
<nckx>apteryx: I see that Guix only provides CONFIG_ZSWAP_ZPOOL_DEFAULT_ZBUD=y, which hard-limits compression to 2x, even if you choose a better algorithm than the default LZO. Zstd often compresses 3-4x here (with same-page dedup enabled) so ideally you want zsmalloc.
<nckx>I will submit a patch for this.
<lfam>We can change that
<lfam>I'd like for the kernel build-time configuration to be done more collaboratively anyways
<nckx>I just take it as a sign that few if any Guixers use zswap seriously.
<nckx>That's OK.
<lfam>I asked if we should enable zswap unconditionally for the 5.7 upgrade, but decided not to do it
<nckx>Oh?
<nckx>Why not?
<lfam>I'm not sure if there are any downsides. These algorithms are known to be faster than I/O
<str1ngs>nly: on problem. I need to rework that function but to busy with important things. ibuffer is grealy improved now BTW
<str1ngs>nly: greatly*
<lfam>Because I'm taking a conservative approach, nckx. But I am open to suggestions
<lfam>Maybe certain platforms are too slow to benefit, IDK
<nckx>lfam: Vastly.
<apteryx>nckx: ah, that zram thing is only useful in the context of swap? I was thinking it'd apply to all my RAM use. Perhaps that's madness.
<lfam>I don't know (or recall) exactly what the option was. I don't remember now if it was for swap or live RAM too
<lfam>Send patches!
<lfam>Tested patches, and ideally benchmarked
<nckx>apteryx: I was talking about zswap, I've yet to try zram (I want to, but I don't really grok it -- seems like there's such a huge overlap between the 2, why have both? OTOH I wouldn't give up zswap, maybe zrammers are equally intransigent).
<lfam>Personally I don't see a reason not to compress both RAM and swap
<nckx>lfam: I don't think we need benchmarks to enable sane features unless they are made the default.
<nly>looks good? guix system disk-image --file-system-type=iso9660 ~/git/guix/gnu/system/install.scm --target=aarch64-linux-gnu
<str1ngs>umm if you have a really slow CPU. there is overhead to compression.
<lfam>True nckx
<Kimapr[m]>description for the zram service says it creates a zram swap device
<lfam>Right str1ngs, as I acknowledged before
<lfam>We might not enable it for armhf or i686
<str1ngs>lfam: sorry just came in on the tail end of the thread :)
<lfam>:)
<nckx>Kimapr[m]: Yes?
<lfam>In some ways, it's unfortunate that aarch64 contains such a large range of performance
<str1ngs>blame nly, he highlighet me!
<lfam>It's difficult to make choices about it
<Kimapr[m]>nckx: > description: Creates a zram swap device.
<str1ngs>aarch64 is really good for power consumption at least .
<Kimapr[m]>from `guix system search zram`
<nckx>I don't really understand your point.
<nckx>I know what it does, not why I should use it over zswap.
<lfam>Right str1ngs, although I wonder how much less hungry the really fast chips are? The slow cellphone chips like the Cortex A53 are very efficient but really not that fast, especially for a platform like Guix
<lfam>They are even in-order, which is not great for compiling things
<nly>ah, i see the msg now. thanks str1ngs
<lfam>But, I do fantasize about a totally off-grid computing setup
<lfam>Sounds like a fun challenge
<nckx>nly: I've never used --target for that. I'd go with --system, but that requires some set-up if you don't have the qemu-binfmt service yet.
<nly>i have qemu-binfmt
<lfam>Does anyone know where `guix lint` puts the CVE database now? My ~/.cache/guix/cve doesn't appear to have the most recent years
<nckx>nly: --target will cross-compile everything. Which may well work, but it's quite the test suite for cross compilation support.
<nckx>nly: Then go with --system IMO.
<nly>ah
<nly>gotcha
<str1ngs>lfam: I think it's the use of big and little cores that helps the power consumption so much.
<lfam>That is a cool system. I do think the faster chips are, to some degree, because they are able to put 64 of them on a single server
<lfam>I mean, I think they are to some degree more efficient, with lower TDPs
*lfam is distracted
<lfam>I don't think you can put 64 Intel chips on a single board
<lfam>Has anybody tested the latest kernel-updates branch? <http://ci.guix.gnu.org/eval/15738>
<lfam>The CI interface is not helping me evaluate the fitness of the branch as much as I'd like
<nckx>Not sure what you mean by chips. 64 packages? Not without glue. But Intel puts 64 cores in a package just fine.
<nckx>Not even that unusual, I think.
<lfam>Oh, I didn't know that
<lfam>It must require some serious power and cooling
<nckx>Don't all 25 berlin nodes have 64 cores now? Or are they mere 32-core SMT weaklings.
<lfam>Shows what I know
<lfam>I'm still using 2 cores with hyperthreading
<nckx>If the average ARM laptop has 64 cores now, that is of course impressive (unless they're slow, oh wait, it's ARM). But in the server space that's pretty unimpressive.
*nckx has bought 0 servers lately so take with salt grain.
<str1ngs>in the server space though that could add upto quite the saving in power consumption/heat etc.
<nckx>lfam: I was mistaken about the nodes. AMD EPYC 7551P 32-Core Processors. So is berlin now, but I could have sworn it was an Intel box (with a broken NIC) before.
<nckx>No, berlin is AMD EPYC 7451 24-Core Processor, but 2 of them.
<lfam_>Nice
<nckx>I think. It's too hot for basic arithmetic.
<lfam_>I'm on a train so will be intermittently connected, due to IRC
*nckx applies the thermal paste to forehead.
<str1ngs>I only got 12 cores :(
<nckx>I've got 2 ☹
<str1ngs>you can offload atleast :)
<nckx>My offload box has an impressive 6. 😛
*raghavgururajan + zopiclone = zzZ
<nckx>However: lscpu | grep -c Vulnerable → 7
<nckx>Now that's an impressive number.
*nckx feels better now.
<nckx>Good night raghavgururajan.
<str1ngs>I get 0, but mines a ryzen
<nckx>Your vulnerabilities haven't been released yet.
<str1ngs>o.O
<nckx>I must point out that I've purposefully disabled mitigations on this box, because it's not publically accessible and runs only free software builds.
<lfam_>Oh, they have been released, probably a decade ago. They just haven't been discovered yet :)
<nckx>So I'm crazy but I'm not crazy.
<nckx>lfam_: Somewhere, a bored analyist cracks a dry smile.
<nckx>I meant publically released. 😉
<lfam_>Yes, of course
<lfam_>They haven't been discovered by project zero
<nly>nckx i don't see any --system option in "guix system disk-image"
<nly>built the first one
<nly>i'm illiterate
<nckx>It should work, it's a ‘generic build option’. But if it's not documented, feel free to file a bug.
<smithras>hello everyone, its been a while! Is ci.guix.gnu.org in a degraded state? I'm getting around 50kb/s right now
<lfam_>smithras: I've noticed it does that sometimes (I'm in the US)
<smithras>lfam_: ahh ok, thanks for the info
<bavier[m]1>for me too, depends on the particular things being substituted
<smithras>I'll be optimistic and believe that it's because more and more people are using guix :)
<telior>ok, I fixed the pass issue :D it was a really simple solution, just had to run `chmod +r` on my private keys folder, inside .gnupg. Not sure why that wasn't necessary in arch, but at least pass works now :D
<lfam_>telior: That added read permissions to the folder?
<lfam_>(I always use numeric chmod)
<telior>it did :)
<rekado_>on node 29 lscpu says CPUs: 96, threads per core: 2, cores per socket: 24, sockets: 2, NUMA nodes: 8
<rekado_>that’s AMD EPYC 7451
<nckx>rekado_: I ssh'd into the first machine in machines.scm, which was 7551P.
<nckx>I thought they were all the same.
<rekado_>most of them are 7551P
<rekado_>I think we have … six(?) 7451
<rekado_>but not all of them are online, unfortunately
<rekado_>one of them was shipped with bad memory
<nckx>Oh, are they donations/otherwise unwarrantied?
<rekado_>no, but the return process is lengthy
<rekado_>you also have to demonstrate that it’s really a hardware problem
<nckx>Hm.
<rekado_>and we have a company in between Dell
<rekado_>so we talk to them, they talk to Dell, …
<nckx>Why are there at least 2 different configurations? Just curious.
<rekado_>we thought that the 7551P would be fine for most builds
<rekado_>but I also wanted to have fatter 2U machines in the rack, so we picked a couple of the 2 CPU servers as well
<nckx>Ah 🙂
<rekado_>we did a few tests with vaguely similar configurations (not the same CPU but fast single CPU vs somewhat slower dual socket) and thought a little diversity in the build farm could be a good idea for some builds
<telior>another quick question, regarding fonts: neither icecat nor emacs are able to access my downloaded fonts (for example, font-fantasque-sans and font-sil-gentium). I've downloaded fontconfig and ran `fc-cache -rv` as suggested in the guix manual, but it doesn't seem to work
<nckx>Meanwhile, elsewhere on berlin: https://paste.gnome.org/plmrkn6is
<nckx>This is the tunnel to dmitri, which was down, now it's back up and the tunnel was broken so I restarted that, now it fails with this.
<nckx>SSH'ing into the machine I can find nothing wrong.
<nckx>Also, whoever commented out the Russians: 1) thank you 2) please ping me, they were down for ages without my knowledge 🙂
<nckx>Unfortunately they make just as much noise idle as busy.
<apteryx>is someone else using xterm as their terminal emulator? does C-s (control S) work when you search in the history (initiated by C-r) ?
<nckx>No, its suspends the terminal (which is what I thought was the expected behaviour but I've never used C-s within C-r).
<nckx>Unless that's what you mean by ‘work’, and then, yes, it works 😛 Unlikely.
<apteryx>nckx: right, that's what it does for me to (suspend the terminal, I must press C-q to resume it)
<nckx>Right. It does the same in Alacritty and Termite so I'm not sure what you're expecting.
<nckx>That's what C-s/C-q have always done IME.
<apteryx>nckx: I think if we disable control flow (xon) readline would do what I expect (emacs-like C-r/C-s). I'll test.
<apteryx>flow control*
<nckx>I never new bash/readline even supported C-s.
<nckx>TIL
<apteryx>I'm not sure yet
<nckx>I'm a heavy C-r user, guess I've just taught myself never to make typoes then.
<nckx>C-s would be nice then.
<apteryx>apparently it does support C-s: https://www.man7.org/linux/man-pages/man3/readline.3.html
<apteryx>which seems more handy than flow control for my usage (I use scroll lock to stops autoscroll without interrupting the process).
<nckx>stty -ixon
<nckx>This is great.
<apteryx>awesome
<nckx>apteryx: Scroll Lock? OK grandpa desktop keyboard. 🙂
*nckx looks longingly at where their numpad used to be.
<apteryx>'fn l' on a HHKB
<apteryx>err, 'fn o'
<nckx>Wow, just those colours alone are making me nostalgic in a way I was not expecting. https://images-na.ssl-images-amazon.com/images/I/61ECiYo2heL._AC_SL1280_.jpg
<nckx>Looks clicky.
<bdju>how do I check what version of GTK is installed?
<leoprikler>Usually you wouldn't install gtk userwide, but `guix package -l` is your friend.
<rekado_>I got me the rubber-dome variant of the HHKB long ago when I was a vim user (I think)
<nckx>To augment leoprikler's answer: ‘guix gc --references $(realpath ~/.guix-profile/bin/foo)’ for the conventional-distro of ‘installed’, ‘it's present on my system’. Of course /gnu/store/bar can refer to a totally different GTK at the same time.
<nckx>bdju: ☝
<rekado_>I had no idea what to expect then.
<bdju>leoprikler: I was asked for a bug report so I just... have to check. what's the syntax for guix package -l? I tried `guix package -l gtk` and it didn't work
<nckx>s/distro/distro definition/
<nckx>Did you mean guix package -I?
<nckx>(Uppercase i.)
<bdju>I didn't
<bdju>oh I run package -l without args to get a list and then I can search it in less I guess. hm
<nckx>Then it takes no argument.
<bdju>I'm not trying to install gtk, I want to know what version I have, just to clarify again
<nckx>-I does.
<nckx>e.g. guix package -I gtk.
<nckx>bdju: That doesn't clarify the very ambiguous ‘have’ 🙂
<bdju>ah, I see. I worried you were telling me to install it
<rekado_>bdju: the version depends on the package in question
<bdju>so now the problem is I get 0 results for gtk in any of these commands
<bdju>rekado_: ah, the package is dino
<nckx>bdju: Because you didn't install it with ‘guix install’.
<apteryx>rekado_: I think all HHKB are Topre based (switch brands), which are a hybrid between rubber dome and mechanical switches.
<bdju>nckx: so -I just lists explicitly installed stuff then?
<nckx>Different installed packages can depend on totally different version, so can generations, you probably ‘have’ many GTKs. You can only say which GTK a particular *package* pulls in.
<nckx>I think you misunderstand how Guix works.
<nckx>And I'm afraid I have to go just now, sorry ☹
<nckx>o/
<bdju>I uh... I know about multiple versions and whatnot
<bdju>sorry, just stressed and trying to respond to a bug report but blocked on this guy's question I don't know how to answer
<bdju>I guess I'm just gonna give up, thanks anyway
<rekado_>I just did this: guix gc -R $(guix build dino) | grep gtk
<rekado_>for this older version of Guix it says /gnu/store/s0isxmplbynsmmk27sss5cr04qyqlp38-gtk+-3.24.20
<bdju>thanks, rekado_. looks like 3.24.20 then. I already responded to the report, but maybe I'll tack that on now.
<bdju>It's a shame (to me) that the command to find that out is so complicated
<bdju>well, maybe gtk is a special case. I was thinking on arch I'd use `pacman -Qs`, but I probably didn't install gtk itself there either, so maybe it wouldn't show
<rekado_>“guix gc -R” shows you all references of any store item
<rekado_>on systems that install things globally you don’t have this problem at all
<rekado_>most of the parts of the above composite commands are necessary to get the store item corresponding to the application you run.
<rekado_>“readlink -f $(which dino)” does that for the executable “dino” that happens to be first on PATH
<bdju>why is the garbage collect command used here? also I get no output guisg `guix gc -R` without other arguments
<lfam_>That's expected bdju
<lfam_>It requires an argument
<bdju>s/guisg/using
<rekado_>“-R” is short for “references”
<rekado_>you gotta tell it for *what* thing you want to see references
<bdju>okay, and typing "gtk" isn't enough. does it need exact store paths? is that why the build command was used?
<lfam_>Correct
<bdju>interesting, okay.
<rekado_>you don’t want the references of “gtk”
<rekado_>you want the references of (the store item for) dino
<rekado_>in Guix a program will not just ask for any arbitrary “gtk” library that happens to be installed on the system
<kmicu>apteryx: xterm dosen’t even support C-r.
<rekado_>it will ask for *one* very particular variant
<rekado_>and that variant is determined at build time
<rekado_>(before the build even)
<bdju>that makes sense. less breakage that way
<rekado_>to be sure that it will always use just this particular variant and never anything else we embed the full absolute file name to every library
<rekado_>that’s what we call a “reference”
<rekado_>the job of the garbage collector is roughly to remove everything that isn’t referenced
<rekado_>that’s why this option is part of the “guix gc” command
<rekado_>if you don’t care about the “ground truth” and just want to know what dependencies there would be if you installed something you could use “guix graph” (and then look at the version number as specified in the package definition).
<apteryx>kmicu: it does
<kmicu>apteryx: that’s probably your shell’s input method. Dash in (u)xterm doesn’t react to that.
<apteryx>the history search is handled by theh readline library, which Bash uses. I doubt dash uses readline, given it aims to be minimalistic.
<kmicu>It does not indeed. Even dash’s libedit is very minimal. In xterm’s manpage there’s ‘default key binding’ paragraph.
<apteryx>that's a good reference
<kmicu>Wow, you are using scroll lock‽ Like for real?
<kmicu>(Don’t get me wrong, that’s super amazing to meet you. ScrollLock users are extremely rare nowadays 😺)
<str1ngs>all hail ~/.inputrc !
*kmicu admits “Use stty stop undef and stty start undef. This way, C-s and C-q are being freed for other purposes, but ScrLock still controls flow.” feels like an ancient incantation.
<vivasvat>This is somewhat unimportant, but are there any future plans for a US based substitues server. Dont get me wrong, I like Guix and its amazing, but sometimes/often download speeds drop to 10KiB/s or less which kills me :/
<lfam_>vivasvat: There are no plans, but if somebody wanted to work on the problem, it would be welcome
<lfam_>I'm not sure it's clear what is causing the issue
<lfam_>Like, is it a problem with the transit? The source datacenter? Our cache?
<vivasvat>Idk, I've assumed its due to distance or something
<vivasvat>because isnt the build farm located in europe (germany?)
<lfam_>There's no reason it can't be fast, and sometimes it is :)
<lfam_>Yes, it's in Berlin
<lfam_>Here is a message about it: https://lists.gnu.org/archive/html/help-guix/2020-06/msg00195.html
<vivasvat>yea thats pretty similar to me
<vivasvat>I wonder where that user is located
<lfam_>I believe they are in Hong Kong, based on their mention of HKT (Hong Kong time zon)
<lfam_>time zone
<vivasvat>oh wait I must have missed that, sorry
<vivasvat>ahh I see it now
<vivasvat>Wont it be slower if a user half way across the globe vs if user is in Germany?
<vivasvat>like is it a bug or just the result of geography
<apteryx>str1ngs: ha ha!
<lfam_>vivasvat: You could expect a higher latency but overall speed could still be quite fast
<lfam_>Like, the transatlantic connections are not expected to be 10 kbps
<vivasvat>hmm ok
<kmicu>(It could be a result of NSA sub tapping into Atlantic lines and checking what’s inside ;)
<apteryx>vivasvat: that's weird to get such low speed. I seldom get such low speeds, on the same continent as you.
<vivasvat>uh oh
<lfam_>If that made the internet slow then we wouldn't have netflix
<lfam_>Or zoom
<vivasvat>Well I assume netflix has servers in every continent to deal with latency i guess
<lfam_>Anyways, surveillance is either 1) not the issue or 2) nothing we can change
<lfam_>And the connection from NA to Berlin is sometimes super fast, so I don't think it's purely a matter of serving things from NA
<lfam_>We did use a global CDN for several months but decided to discontinue the service
<vivasvat>I wonder where the issue stems from
<vivasvat>because its probably not the guix software
<vivasvat>and probably not my network because on my host distrobution package manager I get excellent speeds
<vivasvat>so like \_('.')_/
<kmicu>vivasvat: are you able to download Guix ISO with high speed during that slowdown?
<vivasvat>well the guix install script also was very slow to download
<vivasvat>but isn't it from different servers anyway, like savanahh.gnu.org vs ci.guix.gnu.org
<spudpnds>vivasvat: I see it here in the US as well. What's weird is that one substitute will have downloads measured im MiB/s and then every now and then one gets stuck at KiB/s.
<spudpnds>My thought that there was a machine in the build farm that was either overloaded, or had a misconfigured network port or something.
<vivasvat>but in that case wouldn't the issue effect everyone?
<vivasvat>it seems to be selectively effecting a few people
<spudpnds>Indeed, other folks would be bound to notice this.
<kmicu>The question is whether we can replicate the issue and it’s not a transient network hiccup.
<lfam_>If you can really get one file quickly, and another slowly, at the same time, it's likely a cache issue at the build farm front-end
<apteryx>spudpnds: ah, isn't that the nginx caching issue, where not yet cached items get served at slow speed (occurs for the first user of a substitute)
<spudpnds>I honestly have no idea how the infrastructure that serves the substitute works.
<kmicu>If that’s true then we could test it by using e.g. week old guix revision during pull (all subs should be ready).
<kmicu>(Unless the cache is really small. 🤷)
<vivasvat>what do you guys mean by cache issue?
<lfam_>If the file you requested is not cached, it might take a while to retrieve it, or it may be retrieved slowly
<lfam_>It could be stored on a disk that is already very busy, for example
<lfam_>I'm not familiar with the details of our build farm so I can't give concrete examples
<apteryx>ah, the issue I had on mind was apparently resolved: http://issues.guix.gnu.org/26201
<nckx>bdju: I'm back. Sorry about that. Did guix gc --references help you on your quest?
<nckx>spudpnds: The ‘infrastructure’ is just one box running nginx in front of guix publish. No CDN, no different nodes, but the pipe is at least 30 MiB/s fat (tested from my server in Germany) and it looks more like a network/peering issue to the US.
<nckx>lfam_: Good guess but it's very unlikely that this is I/O or otherwise machine bound.
<spudpnds>nckx: Aaah, good to know, not sure why I imagined it to be much more elaborate ;)
<apteryx>spudpnds: see: http://issues.guix.gnu.org/26201#31: "The bandwidth issue reported at the beginning of this thread should bemostly fixed: serving a narinfo or nar URL is now just sendfile(2),which is the best we can do; 404s on narinfo should be immediate.", and "[...] when the machine is overloaded, we’ll still experienceincreased latency and lower bandwidth, but that should be less acutethan with
<apteryx>the previous setting.".
<kmicu>vivasvat: could you when experiencing the issue stop the update and check e.g. after an hour whether the very same package is still slow? That would help narrow the issue.
<lfam_>I do figure it's ultimately a peering issue (why would the research center need amazing service to the US?)
<vivasvat>kmicu: alright I will do that
<vivasvat>lfam_: if it is indeed a peering issue, is there anything we can do to resolve it?
<lfam_>I expect there would be nothing we could do to fix the peering, but perhaps we could set up a mirror in NA
<nckx>lfam_: Yeah, that occured to me as well. Guix's traffic is (very graciously) hosted by the German Research Network (I forget their real name), I'm sure their priorities are high-quality intra-institute traffic, not intl.
<lfam_>Hosting a mirror would require funds and attention
<kmicu>(It could be a QoS issue, e.g. when someone saturates web downlink then slow the rest of traffic down, not to mention that now USA can prioritize traffic.)
<nckx>It's also papering over the problem. Not that that isn't valid, but it's like our idleness issue: wasting what we already have because we don't have gifted debuggers to fix it.
<nckx>I for one am clueless.
<lfam_>It wouldn't require much money or attention, but it would need some. I would consider using a CND instead, since people in other continents will have the same trouble
<nckx>(Big news.)
<vivasvat>are most of you located in europe?
*kmicu [joke] changes status to WONTFIX: Recommendation: move to EU.
<str1ngs>I rather like the idea of community P2P hosting. using something like ipfs or gnunet
<vivasvat>time to move to EU ig
<lfam_>I would guess that Guix contributors are split somewhat equally between Europe and North America. I don't know about Guix users
<nckx>vivasvat: I don't know about most, but we're definitely EU-heavier than your average free software project which skews heavily towards US.
<nckx>s/heavily/disproportionally/
<nckx>kmicu: Come for the healthcare, stay for the traffic.
<vivasvat>hahahaha
<vivasvat>sad reality
<str1ngs>we have good healthcare in NA, just not in the US :P
<nckx>Touch'e.
<nckx>God damn compose-stealing Wayland.
<str1ngs>I wonder how hard it would be to add wayland support to Emacs.
<str1ngs>XWayland is crappy
<vivasvat>anyways, I wonder if there are enough NA/international people who'd be interesting in a NA/international mirror in which case I wonder if it would be possible to set up a mini project to gather funds via donations or something...
*kmicu enjoys nckx’s wayland journey.
<vivasvat>wait do guix users happen to also disproportionally use emacs? :P
<str1ngs>vivasvat: yes, a good candiate network might be something like OSU Open Open Source Labs
<nckx>vivasvat: Definitely.
<str1ngs>err one OSUOSL
<str1ngs>who does'nt use Emacs?
<nckx>vivasvat: Plenty of vim users here but disproportionally emacs, because GNU and lisp.
*str1ngs gasps
<vivasvat>'laughs in ERC'
<nckx>Maybe emacs-guix too, but it's not won me over yet.
<vivasvat>what is emacs-guix?
<nckx>An emacs interface to Guix.
<str1ngs>I really like emacs-guix, but I'm always fighting with it on guix foreign
<vivasvat>nckx: as opposed to command line?
<nckx>Not that there's anything wrong with it! I'm just not into emacs that way, we're just friends, but I don't do me IRCing in emacs either for example.
<nckx>That said I do use it for mail, hm.
<nckx>vivasvat: Yes.
<str1ngs>I'm totally into Emacs :P
<vivasvat>hmm, I'm the opposite, I'm use emacs for everything except possibly email :P
*str1ngs hugs his crush.
<blackbeard[m]1>hello
<blackbeard[m]1>I am having problems with emacs-magit
<blackbeard[m]1>seems like I can't see the diffs
<blackbeard[m]1>ERROR: Symbol’s value as variable is void: transient-current-command
<blackbeard[m]1>error: There was a problem with the editor '/gnu/store/gc9i25842509nnnzvv4scc562i47lbb8-emacs-26.3/bin/emacsclient --socket-name=/tmp/emacs1000/server'.
<str1ngs>vivasvat: only thing I don't use Emacs for is browsing. mu4e is good for mail.
<vivasvat>is transient installed?
<blackbeard[m]1>vivasvat: i don't know!
<nckx>vivasvat: What do you use?
<str1ngs>blackbeard[m]1: are you using magit from emacsclient?
<nckx>blackbeard[m]1: guix install emacs-transient, and if that fixes things it's probably a bug.
<vivasvat>nckx: what do I use for what?
<blackbeard[m]1>str1ngs: yes! installing emacs-transient now
<nckx>mail.
<blackbeard[m]1>I never had that bug before so I didn't know I needed that
<blackbeard[m]1>thanks :)
<vivasvat>blackbeard: its probably a dependency problem
<nckx>Well, I'm not sure, it's just a good first guess based on that error message.
<str1ngs>hmm should not emacs-transient be a input for emacs-input?
<nckx>That would be the bug 🙂
<blackbeard[m]1>ok let me log out see if I can fix it
<nckx>str1ngs: Is it not?
<nckx>I didn't check.
<str1ngs>err emacs-magit
<vivasvat>nckx: for email I use evolution
<nckx>Wowee. The anti-mu4e.
<str1ngs>it is an input. I wonder if the user news to just restart the session
<str1ngs>needs8
<vivasvat>wait I probably should switch though, I've just never bothered to figure emacs in mail out
<nckx>Or just restart the daemon.
<str1ngs>depend if if search paths are needed I guess
<blackbeard[m]1>It wasn't fix by installing emacs-transient
<blackbeard[m]1>But I am rebooting just in.case
<str1ngs>vivasvat: smtp out is pretty easy to setup.
<nckx>vivasvat: I love mu4e; that said, it's surprisingly janky for such a popular package.
<str1ngs>vivasvat: though I use offlineimap. with a local maildr
<nckx>Press a key too late or too early (and mu4e decides when that is, not you), bam, stuff happens in the wrong buffer.
<vivasvat>str1ngs: to be honest, I kinda wanna self host mail, but I haven't gotten to it jus tyet
<blackbeard[m]1>OK I am getting the same error
<kmicu>Magit from Guix propagates ("emacs-transient" ,emacs-transient)
<vivasvat>blackbeard[m]1: if nothing else works, you can try the vanilla way of installing emacs packages with 'M-x package-install'
<nckx>vivasvat: The good news is that Guix System provides *almost* everything you need to self-host a modern mail server.
<str1ngs>vivasvat: not worth the headache, unless you are into system administration. you have to deal with spam and routing it's a real PITA
<nckx>Only a DKIM service is missing.
<nckx>Well, everyone's different.
<kmicu>blackbeard[m]1: I would check whether in magit command shell git diffing works and then I would check with emacs -Q whether that’s not a config issue.
<vivasvat>str1ngs: I've heard a lot of conflicting opinions, but I just wanna move away from google
<vivasvat>str1ngs, not sure what other options may be
<str1ngs>I think emacs needs to be restart with fresh shell variables for propergation.
<str1ngs>blackbeard[m]1: ^
<str1ngs>vivasvat: I hear ya.
<nckx>I understand where str1ngs is coming from, but don't like how memefied that opinion has become. ‘Don't even think about self-hosting!’ Er, no, it's really not that hard if you enjoy the process.
<blackbeard[m]1>vivasvat: thanks, now I know it was my mistake
<blackbeard[m]1>I had emacs-magit-popup installed from melpa
<blackbeard[m]1>Removed and installed from guix :)
<str1ngs>self hosting a mail server is no joke.
<vivasvat>str1ngs: I've heard that the set up is hard, but after initial set up it becomes much easier
<nckx>Fun, not funny.
<kmicu>vivasvat: I selfhost and it’s ok. No issues with spam here with rspamd and it fits under 128MB of RAM xD
<blackbeard[m]1>Yes fixed :D
<nckx>Also not *that* hard as is often implie.
<nckx>*d
<blackbeard[m]1>Thank you everyone :)
<blackbeard[m]1>٩(◕‿◕。)۶
<vivasvat>I know about rspamd, spamassasin, and postfix, and dovecot
<vivasvat>thats what I'll probably start setting up with
<nckx>I forgot that Guix System is missing a spam filter.
<nckx>Which tells you how much spam is a problem for me.
<str1ngs>I self host many domains. neither of which I host DNS or mail. that requires some more redundant infrastructure then just a couple of piddle servers.
<vivasvat>so 'not a problem?'
<kmicu>Literally hour of work.
<vivasvat>thats not ad at all
<vivasvat>bad
<nckx>str1ngs: ‘Self’-hosting mail *for others* is an immense responsibility and source of sleepless nights. No disagreement there! But self-self? Eh. Overspookied.
*kmicu is also talking abous selfhosting aka personal emails.
<vivasvat>i'm not a sysadmin so i don't have to ever host for someone else
<vivasvat>it would be my personal email
<kmicu>You could even use those predefined solutions like FreedomBox* where setup takes minutes and can be hosted on a SBC.
<vivasvat>^^ oh yeah ive heard about those
<vivasvat>but a friend recommended I don't do that because it installs a lot of uneccesary stuff
<kmicu>(Email is nukeproof, just keep server up hour a day and it will work fine.)
<kmicu>vivasvat: so like Guix? xD
<vivasvat>guix/nix tho is genius
<vivasvat>email is the past
<vivasvat>nix/guix is the future
<nckx>The most important thing IMO is to get yourself a reputable IP from a reputable provider.
<kmicu>^^
<vivasvat>I have a static IP rn
<str1ngs>also you need reputable DNS :)
<vivasvat>how do you know if an IP itself is reputable
<nckx>str1ngs: How so?
<vivasvat>yes I have a Domain already whic I use to self host git and stuff
<str1ngs>some one high jacks your DNS there goes your MX records. and your mail.
<str1ngs>and you defiantly don't want to host mail on the same server as the DNS server.
<vivasvat>oh reaally?
<vivasvat>why?
<nckx>vivasvat: You can check the big RBLs, either using dig for maximum 1337 but there are plenty of ‘query all RBL’ Web sites where you just plonk in an IP and they check it for you.
<str1ngs>because if your mail server goes down, so does your MX records.
<nckx>str1ngs: Well, true, but you need reliable DNS for everything. There's no higher bar for mail than for other services. If your DNS goes down, so does your Web site/anything else.
<str1ngs>right, that's why you reliable DNS.
<str1ngs>you need*
<vivasvat>is there an advantage to self hosting DNS vs using a popular domain server
<nckx>Things on the Internet need reliable DNS, but e-mail neither more nor less.
<apteryx>ah, my thinking that guix-set-emacs-environment was broken was PEBCAK: you must give it the root of the profile, not the etc/profile file it contains.
<apteryx>i.e., (guix-set-emacs-environment "~/.guix-profile") works.
<nckx>vivasvat: Again, fun and that same feeling the type of person who likes self-hosting e-mail gets when self-hosting DNS 😉
<nckx>Mainly the latter.
<pkill9>how easy is it to run your own DNS server?
<vivasvat>ahhh :)
<nckx>Easier than mail, no multiple moving parts.
<kmicu>Runing it it’s easy, keeping it up is the issue.
<str1ngs>pkill9: it's easy to run both a dns and email server. the question is how redundant and fault tolerant are they :)
<vivasvat>in my not so experience opinion, self hosting anythiign is fine and easy until you have to do it on a large scale
<pkill9>just for myself
<pkill9>would be the intention
<pkill9>unfortunately my itnernet isn't so great so maybe not worht it
<vivasvat>ok ive been installing icedove onguix and its going at 50KiB/s
<vivasvat>sould I C-c and wait an hour?
<nckx>vivasvat: From?
<vivasvat>substitues server
<nckx>
<kmicu>vivasvat: yes, it would be insightful.
<vivasvat>ok ill wwait an hour and get back
<nckx>(When I updated IceDove, the source mirror itself was quite slow too.)
<kmicu>vivasvat: could you also paste its hash?
<nckx>
<nckx>I'd like to test it from the EU.
<bdju>nckx: Yeah, found the GTK version (of Dino specifically) via the guix gc -R command.
<vivasvat>5535c32n033k3s5pvd04jh0gny3w7wgf-icedove-68.10.0.drv
<vivasvat>thats what you are looking for right?
*kmicu 😴
<nckx>Eh, weird, that doesn't exist on berlin.
<nckx>vivasvat: Could you just paste the URL?
<nckx>Good night kmicu; happy to hear that bdju.
<vivasvat>wait I pasted the hash of the derivation
<nckx>At least I was of some help...
<vivasvat>not the substitues URL
<vivasvat>which one o=do you want?
<nckx>I just found it strange that the derivation doesn't exist on berlin. But never mind.