<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
<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 :-)
<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 <email@example.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 ;-)
<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.
<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]: 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.
<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.
<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>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.
<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>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>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
<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. 👍
<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>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.
<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
<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?
<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
<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.
<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 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 :)
<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
<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.
<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...