***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. <lfam>wget from Debian does something similar <lfam>It must be handy for analyzing bug reports <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 <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? <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>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 <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. ***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? <Noclip>Why is it then used for high performance computing? <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. <Noclip>That's why I said "software that has been installed with guix". <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. <Noclip>leoprikler: I already had to learn that installing packages with guix can be very slow even if nothing has to be build. <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>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 <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 :( <Noclip>You could also do "guix pull" and then wait a few hours before "guix upgrade", right? <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 šļø ***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
<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>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>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 <rekado_>KimaprOnPhone: canāt you boot the installer image and use a shell there? <efraim>serf-1.3.8 from the 0.12.0 release FTBFS on mips64el <apteryx>jonsger: there's already a bug about it <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 :-) <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. *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. <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 <Kimapr>i wonder if that is fixed already <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 ;-) <nckx>raghavgururajan: I already fixed OpenCV on master yesterday. <sneek>Welcome back nckx, you have 3 messages! <sneek>nckx, raghavgururajan says: Never mind about the OpenCV. Danny pushed my build-fix patch to master. <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. <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 :) <nckx>raghavgururajan: It's OK, I'll revert it. <nckx>git: error: ...: object corrupt or missing: .git/objects/87/... <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>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. <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: 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 <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? <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 <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>Basically, all the shiny. <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. <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. <vivasvat>thanks nckx and butterypancake for the help <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 <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 <butterypancake>If you're really curious about when merges happen I made a think for you <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 *rekado_ types more slowly now <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>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>no wait, I did something very very wrong. I'm not sure what. But it's very wrong <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. <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. <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>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 <nckx>So it's the ābaseā or ātemplateā service. <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. <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>nothing in my ~/.config for dino :( <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 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: How did you set your gtk-theme to lxappearance? Did it change vaules in config files or ~/.config/gtk-x.y? <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 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!! <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. <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 <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>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. <lfam>I asked if we should enable zswap unconditionally for the 5.7 upgrade, but decided not to do it <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 <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 <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>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. <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>In some ways, it's unfortunate that aarch64 contains such a large range of performance <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 . <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. <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. <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>I don't think you can put 64 Intel chips on a single board <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>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>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. <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. <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>Good night raghavgururajan. <nckx>Your vulnerabilities haven't been released yet. <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_>They haven't been discovered by project zero <nly>nckx i don't see any --system option in "guix system disk-image" <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) <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) <rekado_>on node 29 lscpu says CPUs: 96, threads per core: 2, cores per socket: 24, sockets: 2, NUMA nodes: 8 <nckx>rekado_: I ssh'd into the first machine in machines.scm, which was 7551P. <nckx>I thought they were all the same. <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 <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 <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>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. <nckx>I never new bash/readline even supported C-s. <nckx>I'm a heavy C-r user, guess I've just taught myself never to make typoes then. <apteryx>which seems more handy than flow control for my usage (I use scroll lock to stops autoscroll without interrupting the process). <nckx>apteryx: Scroll Lock? OK grandpa desktop keyboard. š *nckx looks longingly at where their numpad used to be. <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. <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? <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>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 ā¹ <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 <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? <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 <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). <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. <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 šŗ) *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_>I believe they are in Hong Kong, based on their mention of HKT (Hong Kong time zon) <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 <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 <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. <lfam_>If that made the internet slow then we wouldn't have netflix <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>because its probably not the guix software <vivasvat>and probably not my network because on my host distrobution package manager I get excellent speeds <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. š¤·) <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 <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 <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>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. <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 *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 <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. <str1ngs>we have good healthcare in NA, just not in the US :P <nckx>God damn compose-stealing Wayland. <str1ngs>I wonder how hard it would be to add wayland support to Emacs. <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: Plenty of vim users here but disproportionally emacs, because GNU and lisp. <nckx>Maybe emacs-guix too, but it's not won me over yet. <nckx>An emacs interface to Guix. <str1ngs>I really like emacs-guix, but I'm always fighting with it on guix foreign <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. <vivasvat>hmm, I'm the opposite, I'm use emacs for everything except possibly email :P <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. <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>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 š <str1ngs>it is an input. I wonder if the user news to just restart the session <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 <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 <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. <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. <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 <kmicu>vivasvat: I selfhost and itās ok. No issues with spam here with rspamd and it fits under 128MB of RAM xD <nckx>Also not *that* hard as is often implie. <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. <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 <kmicu>You could even use those predefined solutions like FreedomBox* where setup takes minutes and can be hosted on a SBC. <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.) <nckx>The most important thing IMO is to get yourself a reputable IP from a reputable provider. <vivasvat>how do you know if an IP itself is reputable <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. <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. <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 š <pkill9>how easy is it to run your own DNS server? <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>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 <kmicu>vivasvat: yes, it would be insightful. <nckx>(When I updated IceDove, the source mirror itself was quite slow too.) <kmicu>vivasvat: could you also paste its hash? <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 <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... <nckx>I just found it strange that the derivation doesn't exist on berlin. But never mind. 
