<lle-bout>o_O - that looks like too many patterns for a cat <nckx>This one uses emacs, that's for sure. <guix-vits>rndd: i think "no", i think the repo should be switched to commit, and then `guix pull`. Though idk if that will solve any troubles. <guix-vits>rndd: good luck with that strange issue. Such things are a heck annoing, but, funniest thing is that there is an error somewhere. Maybe you can just make a fresh clone for that repo (or reboot) and it's gone? <rndd>guix-vits: well, i clonned again, and then it works -_- <bdju>anyone here using the kitty terminal emulator? when I set the terminus font, it uses a different font... <bdju>I have emacs using terminus for comparison, so I can see stuff like the 0 being different. I suspect it's falling back to monospace maybe <bdju>neofetch unhelpfully displays my terminal font as whatever is in the config file, even if it's not what it's really showing <bdju>ugh... kitty apparently refuses to support bitmap <bdju>part of why I switched away from termite is because pango broke bitmap fonts. this is terrible! <bdju>did anyone look at the log I posted yesterday of emacs-general failing to build? I'm updating again now, so when it fails again I'll post it again <PotentialUser-61>Hello, I just updated and I've got an error in hexchat: Connection failed (unable to get local issuer certificate.? (20)) - nss-certs is inside /etc/config.scm <reepca>PotentialUser-61: what does 'env | grep CERT' say? <bdju>is there a way yet to update everything in a manifest except one thing? <bdju>I'm using the `guix package --upgrade . --do-not-upgrade foo` method now, but then it won't remove anything I took out of my manifest and so on ***catonano_ is now known as catonano
<reepca>I guess the declarative equivalent to upgrade-everything-but-this would probably be to pin the specific package to a certain version <PotentialUser-61>There's also this issue where é character isnt being displayed correctly over ssh or sudo, without sudo or ssh it works fine <reepca>what does 'guix package -p /run/current-system/profile -I cert' say? <reepca>'grep "cert" /run/current-system/profile/etc/profile'? <NieDzejkob>it contains lots of .pem files on my Guix System <PotentialUser-61>reepca: to be exact, grep -i cert /run/current-system/profile/etc/profile returns nothing, for case-insensitivity <reepca>I guess hexchat isn't looking in /etc/ssl/certs by default? <reepca>what happens if you run 'SSL_CERT_DIR=/etc/ssl/certs hexchat'? <reepca>might need to set SSL_CERT_FILE too, in which case it'd be 'SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt SSL_CERT_DIR=/etc/ssl/certs hexchat' <PotentialUser-61>reepca: that worked, but now, it used to work like an hour ago, so why did it stop now? <reepca>PotentialUser-61: was hexchat upgraded recently / had it been a long time since you upgraded it? <PotentialUser-61>reepca: maybe it got upgraded, I don't know, but I installed the system I have now just two days ago <reepca>for what it's worth I get the same issue when I try to reproduce it in a guix environment with SSL_CERT_DIR and SSL_CERT_FILE unset. <PotentialUser-61>reepca: note that curl doesnt work either without these set, it's not only hexchat <PotentialUser-61>right now all my system is broken besides icecat that has its own cert list *reepca is out of the loop <PotentialUser-61>but the symptoms don't make sense, since SSL_CERT_DIR / SSL_CERT_FILE fixes it.. <reepca>apparently the only reason it works for me is that I happen to have programs that use the SSL_CERT_* variables in my system profile <reepca>it's really not my area of expertise; hopefully someone else knows more ***sneek_ is now known as sneek
<lle-bout>reepca, so it seems it only happens when I use sddm >.> ***sneek_ is now known as sneek
<bdju>is the example config for alacritty not shipped on guix? I ran some find command searches in /gnu/store and I can't seem to find anything but the terminfo stuff <bdju>I'm looking for the equivalent to this: /usr/share/doc/alacritty/example/alacritty.yml *apteryx pushes inkscape@1.0 to master <poet>Hello. I received this error after running 'guix pull:' <lle-bout>poet, hello! it seems that you or the official GNU Guix substitute server are having network issues, try again? <apteryx>nckx: nevermind about the middle click paste issue... it *is* a hardware problem apparently; I plugged another mouse I had and that one is not affected. Weird that it seems to come and go... time to get a new mouse. <poet>lle-bout: Okay, trying again now. Thank you. <lle-bout>sneek later tell marusich now I'm at a point where there's something that makes libsqlite3 fail in the context of the subversion test suite, trying to figure out why by running the tcl test suite which tests sqlite and is a libre test suite compared to some others that are proprietary apparently <lle-bout>sneek later tell marusich turns out downgrading Gawk version isnt a requirement anymore with latest Glibc <lle-bout>nckx, hey, if you are the author of sneek, the other day, marusich received messages sent in #guix in #guile - maybe correct that behavior? <lle-bout>also, is it a better idea to replay messages when the user first talks or when it joins the channel? <lle-bout>sneek later tell marusich I disabled subversion tests and disable git-svn tests in git as well. subversion is largely ancient software anyway. <lle-bout>sneek later tell marusich now, fontforge tests failing <bdju>is pdftotext available from guix? <bdju>tried that and got no results, was just wondering if maybe it was part of another package <bdju>I'm now searching on other distros and I think it may be part of poppler-utils, which doesn't seem to be packaged <lle-bout>if nothing, then it's probably not there <lle-bout>bdju, I just grepped the sources for you, no occurence of either pdf2text or pdftotext <bdju>so how do you grep the sources? <bdju>yeah I noticed that. but at least on debian, poppler-utils is separate from poppler, so it probably doesn't have the right command <reepca>(located via find /gnu/store -name 'pdftotext') <bdju>although what I was trying to do is still not working now. I wanted to use an nnn plugin that depends on it <bdju>I get "Config Error; No paper information available - using defaults" but it doesn't do anything after that <lle-bout>sneek later tell marusich LuaJIT isnt ported to powerpc64 so I disabled it in the various LateX packages because it was causing build errors *lle-bout is glad of the fact that this channel is logged to a searchable archive allows him to record permanent notes of what he has done during this porting process <lle-bout>sneek later tell marusich I could successfully run $ guix environment --pure guix --ad-hoc git vim - to rebuild GNU Guix using GNU Guix on powerpc64-linux and get a full-featured build with all the best dependencies. I'll try running cuirass next! <lle-bout>feels weird to be patching the guix's GNU Guix package with a patch that is basically $ git diff --staged o_O <lle-bout>and it's for a good reason, because cuirass references the guix's package - I wonder if there's a way to reference a guix package that is the tree I'm currently working on without modifications <lle-bout>o_O - File gnu/packages/base.scm is read-only; trying to patch anyway <lle-bout>I'm so glad GNU Guix's core-updates was merged not too long ago, it felt horrible trying to port to another architecture while everything was in flux <mbakke>crossing fingers for pp64 support in the upcoming round :-) <lle-bout>mbakke, some GNU Guix test fails weirdly, tests/syscalls.scm and the trace says PASS o_O <lle-bout>FAIL as the header, PASS as the footer with correct expected value <mbakke>lle-bout: can you paste tests/syscalls.log ? <lle-bout>Ah nevermind, it's add-to-entropy-count that fails <lle-bout>I didnt realize syscalls.scm was a group of test rather than a single one <mbakke>I got confused too, even though I've read such logs 100s of times :P <lle-bout>I don't understand what this test actually tests, or if it's bug-free (the test) - at all <lle-bout>mbakke, it seems that on this system I can write to /dev/urandom without an issue - it's Gentoo ppc64 <mbakke>lle-bout: huh, are you on kernel 5.7 or something? <lle-bout>Linux gentoo-ppc64 5.4.38-gentoo-ppc64 #1 SMP Mon Jun 1 00:04:54 CEST 2020 ppc64 POWER9 (architected), altivec supported CHRP IBM pSeries (emulated by qemu) GNU/Linux <mbakke>lle-bout: can you try "./pre-inst-env guix repl", and then: (use-modules (guix build syscalls)) (call-with-output-file "/dev/urandom" (lambda (port) (add-to-entropy-count port 77))) <lle-bout>mbakke, hmm it says: In procedure add-to-entropy-count: Invalid argument <lle-bout>mbakke, some syscall near that in strace: ioctl(13, _IOC(_IOC_READ, 0x52, 0x1, 0x4), 0x3fff73c65ef0) = -1 EINVAL (Invalid argument) <mbakke>lle-bout: I think the docstring is somewhat misleading and refers to the open-output-file docstring, which says "If the file cannot be opened, an error is signalled. If a file with the given name already exists, the effect is unspecified." <mbakke>lle-bout: maybe some assumptions made in add-to-entropy-count from (guix build syscalls) are wrong on your system <mbakke>can you (use-modules (system foreign)) and verify that (sizeof int) and (native-endianness) are sane? <mbakke>well sizeof int is 4, from that trace at least... should it be? <mbakke>lle-bout: the 0x3fff8ae4aef0 pointer is suspicious <terpri>thank you ArneBab. i am strong and resourceful, and will get through this myself, but am heartbroken for those who will not. the situation worsens by the hour <joshuaBPMan>Hey #guix! Slightly off topic...I'm getting tangled in the pursuit for the "best programming language"... I've watched a couple of videos about Zig. The guy is claiming that most lisps cannot be used to create truly reliable software. Essentially most lisps assume that memory allocation will never fail.... <reepca>most programs that use dynamic allocation in general assume that memory allocation will never fail <joshuaBPMan>reepca: I guess I never knew that. The Zig author basically says that languages that do that...means that you cannot use that software when writing plane software, or kernels...etc. <reepca>either that or they do a basic check that immediately kills the program if it does fail <joshuaBPMan>I did know that no one ever planned to write a kernel in guile. Guile is not designed to be used in kernels. <reepca>fundamentally, if the problem to be solved requires more states than your machine has, you can't produce correct output in the general case <reepca>but you can sometimes produce less-catastrophic results if you can more directly control when allocation happens and how your program reacts <joshuaBPMan>reepca: I guess on the other hand, I just prefer to not worry about memory allocation. It is a pain to try to figure that out. <reepca>personally I like the idea of memory allocation that is mostly-invisible by default, but that under the hood has consistent, predictable semantics for when you need to reason about it. <reepca>not really, no. The reason being that the precise semantics of memory allocation / garbage collection, and how those interact with a language, are typically tied more to implementations than languages. <joshuaBPMan>gotcha. I do kind of like the ideas that the author of zig has. It's essentially a faster and leaner C. <joshuaBPMan>The author makes a fairly good case that zig is a better C compiler that C. <dlowe>isn't it C on the backend right now? <dutchie>$ guix environment --ad-hoc --pure udunits python -- python3 -c 'import ctypes; ctypes.CDLL("libudunits2.so.0")' # any tips on getting this command to work? <civodul>dutchie: i think you have to have libudunits2.so in $LD_LIBRARY_PATH <civodul>or rather, you can patch the thing that loads this .so to refer to it by absolute file name <dutchie>LD_LIBRARY_PATH works, but I suppose patching is the proper way to fix <dutchie>maybe i'll post my WIP patches to guix-devl <dutchie>because I'm not really sure how to get the path to the so or what the best way is to patch it <apteryx>nckx: oh, there's actually a way to verify channel news (other than pulling from the local repo): make check-channels-news (documented under the "Commit Access" node). <nckx>lle-bout: Hah, no, I wish. That's dsmith of #guile. I can see cross-channel message delivery being useful & intentional but maybe it's not. <civodul>apteryx: i added it after the discussion the other day :-) <civodul>it had been bothering me for a while already <nckx>apteryx: I hadn't seen that, and now I know why. Thanks civodul. <apteryx>nckx: also, the new pre-push hook that civodul pushed runs 'make check-channels-news' as well as make authenticate out-of-the-box. <apteryx>so you'll want to 'cp etc/guix/pre-push .git/hooks/' if you haven't already <nckx>That's a common mistake for some reason. *nckx runs guix push again. <nckx>apteryx: The hook still needs some fixing before it can be used here. <nckx>apteryx: Assuming you've switched to the new hook, does that mean you run ‘git push’ (nailed it) from a guix environment now? <apteryx>nckx: I just tried running 'make authenticate check-channels-news' without being in a 'guix environment guix' environment, and it worked. Perhaps you only need a boostrapped and built tree. <nckx>apteryx: Sounds like you've guix installed guix's dependencies. <apteryx>I have guile-ssh guile-sqlite3 guile-readline and guile in my user profile <nckx>Well, I'll find out soon enough. <nckx>The hook currently hard-codes origin/ and while it's probably trivial to fix that I haven't had time to do so yet. I did have time for ‘rm .git/hooks/pre-push’. <nckx>(Well, I have, but not actually tested that it doesn't break other things.) <apteryx>perhaps it could honor an environment variable... or use git to find what origin is configured with the correct remote url? Or not use a named remote in the first place if that's at all possible. <nckx>Sorry, busy. apteryx: The interface isn't the problem. Git passes the remote as $1, we just weren't doing anything with it & hard-coding "origin/" in git-authenticate.scm IIRC. Like you I'm not entirely sure if a named remote is necessary (edge cases?) so I kept it explicit. <nckx>So $1 → make variable → command-line argument to a Guile script: our git hook is a bit more over-engineered than is, I suspect, average 🙂 <bricewge>Rereading... Yes I'll merge it with some tweak. <bricewge>Related to this I have still an issue using network-manager with wireguard: disabling a full routing connection won't restore /etc/resolv.conf, I end up with a empty file. <bricewge>I need to run "nmcli general reload dns-rc" for /etc/resolv.conf to be restored. Probably an upstream issue they did not encounter since we aren't using systemd contrary to them. <efraim>Connman apparently has wireguard support, I kept seeing the messages while working on new display managers <gnutec>I have this feeling that Guix store/ with profile is safe in a point that we don't need install iptables or SELinux/Apparmor. Am I correct? <sneek>marusich, you have 9 messages! <sneek>marusich, lle-bout says: I was curious what you were rabbit-holing - and to respond - AFAICT the only patch needed on current master to *build* the bootstrap binaries is the one adding: ((string=? system "powerpc64-linux") "/lib/ld64.so.1") - otherwise, to use the bootstrap binaries, glibc and binutils-final changes are required. <sneek>marusich, lle-bout says: now I'm at a point where there's something that makes libsqlite3 fail in the context of the subversion test suite, trying to figure out why by running the tcl test suite which tests sqlite and is a libre test suite compared to some others that are proprietary apparently <sneek>marusich, lle-bout says: turns out downgrading Gawk version isnt a requirement anymore with latest Glibc <sneek>marusich, lle-bout says: I disabled subversion tests and disable git-svn tests in git as well. subversion is largely ancient software anyway. <sneek>marusich, lle-bout says: now, fontforge tests failing <sneek>marusich, lle-bout says: LuaJIT isnt ported to powerpc64 so I disabled it in the various LateX packages because it was causing build errors <sneek>marusich, lle-bout says: I could successfully run $ guix environment --pure guix --ad-hoc git vim - to rebuild GNU Guix using GNU Guix on powerpc64-linux and get a full-featured build with all the best dependencies. I'll try running cuirass next! <nckx>sneek: sugar-free botsnack <marusich>Man, I don't know what it is, but using Wayland on Fedora on my x200 is just so painful now. <marusich>It's the only combination of distro and window manager I can get to work with my external monitor, but it's super, super slow. Like, only 1 frame per second when moving the mouse... Even when typing in terminal. <marusich>It's like being connected to a sattelite. <nckx>gnutec: No, not up to that point. Guix systems are less vulnerable to most (semi-)automated attacks simply because they're different, and that difference also makes it harder to implement SELinux or copy other distros' firewall services. <nckx>*That's* why they're missing, not because anyone decided they were less needed on Guix System. <nckx>marusich: ‘Now’ as in regression? <marusich>It's totally unrelated to Guix, but I suspect it's just that the x200 cannot perform calculations fast enough to handle a high-resolution external monitor. I have heard that Wayland also renders things on a single thread, or something like that, which apparently contributes to its very chunky feel on lower end systems. <marusich>I'd switch back to Xorg, but I can't use my external monitor when I do that. It's probably a local issue...it used to work fine, but now no X-based desktop manager successfully switches to the external monitor, which sucks. <nckx>The i915 driver's somewhat notorious for regressions like this, but it sounds like it really is Wayland's fault here. <nckx>The performance that is. <marusich>Without evidence, I suspect that the Xorg problem I described is really probably triggered by my hardware somehow. <marusich>This x200 works but it is old, and its ethernet port already soft-failed (lights go on, link goes up, but it sometimes just doesn't work), so I would not be surprised if it had other funky issues. <marusich>I am getting a new desktop soon, and the day cannot come soon enough <marusich>When used as a laptop, the x200 is still fine. But throw an external monitor into the mix and it jus sucks. <marusich>I'm gonna put Guix System back on the laptop once I have my desktop. <nckx>marusich: Have you checked temperatures and (if possible on your hardware) frequencies? Maybe the thermal paste has given up and you're running hot & slow. Just a guess though. I've had the chipset in a different laptop and it suffered from severe thermal issues. <marusich>I should try opening up my laptop sometime <nckx>guix install lm-sensors && sudo sensors-detect && sensors <nckx>But I don't know what an x200 even reports. <guix-vits>marusich: not a trolling: did you'd tried sway on Fedora? Last time i'd check (this year) it was OK (through my external monitor was 1680x1050. <marusich>guix-vits, I thought about it, but I realized I would need to learn not only sway but tiling window managers in general <marusich>I saw that setting up the external monitor would require invoking some crafted script, and I got impatient. It seems like a good alternative. <marusich>Righ tnow...I need to focus on finishing the work for lle-bout <guix-vits>marusich: from default config, Example configuration <guix-vits># output HDMI-A-1 resolution 1920x1080 position 1920,0 <guix-vits>displays can be switched off within the config, also. <marusich>It's a good suggestion; thank you for mentioning it. <marusich>I tend to yak shave more than I need to, and I know sway is going to eat up like a day or two of my time <apteryx>anyone using ibus & anthy here? I'm wondering if it's normal that the "Preferences" button when the input method selected is 'Japanese - Anthey' in ibus-setup is greyed out? <gnutec>Ubuntu come without any firewall police enable for default too. <gnutec>Just wait for a Guile shell and GNU Hurd. <marusich>apteryx, I've set up ibus and anthy on guix system before. I haven't done it in many months. I don't know the answer to your specific question, but it is (or was) possible to get the input method working. <apteryx>marusich: hey :-) Thanks for tipping in. It's working here as well, but I got curious as to what were the key strokes configured to switch between the hiragana and katakana modes, and whether it's configurable. <guix-vits>gnutec: They, afaik, do have a "ufw" which can be enabled with a cli-interface. Aren't it has some default policy? <guix-vits>gnutec: afaik: in Guix nftables-service do have some default policy. <lispmacs[work]>if I run command "sudo guix system reconfigure /etc/config.scm" is that using the guix commit my own user is on, or the one the root user is on? <apteryx>lispmacs[work]: your Guix user is on <apteryx>because PATH is preserved when using the default sudo policy on a Guix System <apteryx>(note that's not necessarily true for the default sudo policy on other distributions) <roelj>For two distinct packages I get build errors that contain errors like this: /gnu/store/...-gcc-5.5.0/include/c++/cmath:102:11: error: ‘::acos’ has not been declared. I think this is due to either an upgrade in GCC or an upgrade in GLIBC. Has anyone run into something similar, and perhaps found a fix? :) <apteryx>marusich: I've found the dialog, but had to start it manually: /gnu/store/7i2czdb8mw3qgz9abg99knv2zm09fr5a-ibus-anthy-1.5.9/libexec/ibus-setup-anthy <apteryx>perhaps something can be improved in our ibus package <guix-vits>roelj: did you tried to log off, then log in? <roelj>guix-vits: What do you mean? I know this package built before the core-updates merge, but doesn't anymore now. <leoprikler>I've added both it + dictionaries to GNOME system-wide and it seems to work just fine. <kamil_>Hi guix. I've successfully built dependencies of my package. They're build, but none of them is installed in the sense that if they were standalone apps, I wouldn't be able to type their name in CLI and hit enter to run them. How do I reference these dependencies in "#:use-module ()" in "(define-module (gnu packages my-package)*)" so that they're used by Guix when building my-package? <apteryx>leoprikler: manually. I've installed ibus, anthy and ibus-anthy in my profile, and I have an ibus-daemon user service, + some env vars exported in my ~/.bash_profile <leoprikler>Btw I just triggered a weird bug in some component, so I'm restarting Polari. <apteryx>leoprikler: by "it seems to work just fine", do you mean that the "Preferences" button in ibus-setup for the "Japanese - Anthy" input method works for you? <apteryx>leoprikler: by "it seems to work just fine", do you mean that the "Preferences" button in ibus-setup for the "Japanese - Anthy" input method works for you? <leoprikler>Well, apart from the fact, that I'm not using ibus-setup, I can configure Japanese – Anthy to work with GNOME. <apteryx>OK. Works for me as well, except that 'Preferences' button in ibus-setup. <lle-bout>mbakke, (native-endianness) is unbound and sizeof int is 4 - also this is a big endian machine, so what makes you think the pointer is suspicious? <rndd>hi everyone! which package contain libgtk-x11-2.0.so.0 ? -_- <leoprikler>apteryx: so you can get ibus-anthy to show its preferences from GNOME, but not from ibus-setup? <apteryx>rndd: confirmed with find `guix build gtk+@2` -name 'libgtk*' <rndd>is there way to install both in same profile? <apteryx>leoprikler: yes, I can access anthy's preferences from GNOME (just tried it on a 2nd machine) <leoprikler>yep, IIRC ibus-setup does not reflect your GNOME setup and vice versa <apteryx>leoprikler: note that I don't use GNOME on the 1st machine (I use ratpoison) <apteryx>leoprikler: can you reproduce my problem using ibus-setup ? <marusich>I've noticed that the formatting in gnu/local.mk of variables with very many entries, such as dist_patch_DATA, is kind of funky. We use tabs and end each line with a backslash, but by default Emacs doesn't render the backslash in the same column for me. Do people care about this formatting? IMO the ideal formatting is to avoid tabs and just put one space, followed by one backslash, at the end of each line. <marusich>I'm not going to change the existing lines, but I was just curious if people cared about that stuff... I am going to switch a smaller variable from a horizontal list to a vertical list, since it is getting larger, and I don't really want to use tabs. <apteryx>leoprikler: OK, I'll report a bug against it, as IMO it should just work. <leoprikler>Normally, Emacs tries to align the backslashes (e.g. in C macros), but if you add tabs, then everything explodes. <marusich>leoprikler, in fact, some of the lines have spaces and tabs mixed together after the last text and before the ending \ on each line. Heh. <mbakke>lle-bout: do you have 64 GiB of memory? the address was just eerily close to that <marusich>Yeah...my personal opinion is that attempting to maintain horizontal alignment is not a great idea. <marusich>So specifically in this case, I don't much care where the backslash goes, but it's weird to have it aligned, sometimes not aligned, etc, and I personally think it's best to just give up and put a single space and a single backslash after the text on each line. <leoprikler>I personally prefer aligned style, but we'd have to fix all the lines. <mbakke>lle-bout: wait a minute, that pointer is ~64 TiB, not GiB <marusich>leoprikler, alignment is nice but horizontal alignment of end of line entries is very hard to maintain, so IMO it's better style to avoid it entirely. <mbakke>lle-bout: does the test pass if you substitute (native-endianness) with 'big ? <lle-bout>mbakke, with virtual addressing and ASLR, comparing with physical addresses should be meaningless <leoprikler>in my personal experience it just depends on tooling <lle-bout>nckx, I could've gotten sneek kicked for excess flood :O <leoprikler>though admittedly Emacs <TAB> is just plain wrong here <lle-bout>mbakke, I had to do: (use-modules (rnrs bytevectors)) - and now it says big <lle-bout>mbakke, and there's 62.9G of RAM in that VM <lle-bout>In reality, I intended to give 64GB of RAM to that VM, but somehow it reads otherwise from inside it, probably due to alignment losses <lle-bout>kernel: Linux gentoo-ppc64 5.4.38-gentoo-ppc64 #1 SMP Mon Jun 1 00:04:54 CEST 2020 ppc64 POWER9 (architected), altivec supported CHRP IBM pSeries (emulated by qemu) GNU/Linux <marusich>lle-bout, are you the same person as dftxbs3e ? <lle-bout>marusich, yes, different machine, different accounts <marusich>Also, is the glibc-ldd-powerpc64.patch required for building functional bootstrap binaries, or only for using the bootstrap binaries (built without using glibc-ldd-powerpc64.patch) to build more things? <lle-bout>marusich, the bootstrap binaries I am currently using are built without that patch <mbakke>lle-bout: I tried tracing it on an x86_64 machine, it looks very different: <mbakke>ioctl(13, RNDADDTOENTCNT, [77]) = -1 EPERM (Operation not permitted) <marusich>OK. If that's the case, I think we should just merge the one-line change necessary to build the bootstrap binaries, and then double check that the bootstrap binaries can be built reproducibly, and then add them. Then we can work out the bugs related to building other packages, like GNU Hello. <lle-bout>mbakke, FYI, I do everything as root in that VM, though, I set up build users and I set guix-daemon to use them so it should be <mbakke>lle-bout: that test should be skipped when run as root though <lle-bout>mbakke, yes, so it's not being run sa root <mbakke>lle-bout: right, you are getting this with 'guix build guix'? <marusich>By the way, would you prefer your name to be included as Leo or Léo? <marusich>I see you've created commits using both forms. <lle-bout>if that's not too annoying to type for you <leoprikler>you first search for ´, then you write e after that ;) <lle-bout>leoprikler, I don't have that forward quote thing <gnutec>guix-vits, Yes! ufw have a policy but is disable by default. You have my point when you talk about nftables-service, but I just want a know. I do not want to use it. Was just a question. <leoprikler>hmm, there are probably no accents on US keyboards <gnutec>guix-vits, But now I'll see about nftables. I didn't know about it. <lle-bout>èé - I can type those directly but not compose them <lle-bout>mbakke, I skipped the test for now, FYI - it's building again <guix-vits>gnutec: btw, the nftables-service doesn't enabled by default too. <mbakke>lle-bout: let's see what else crops ups, maybe we'll get a clue :-) <lle-bout>mbakke, breaks you mean? well I've had guix offload test break but I'm unsure what the cause is <lle-bout>was getting this error specially: error: unknown error while sending files over SSH <marusich>mbakke, do you know if adding an entry for powerpc64 (not modifying an existing entry) to glibc-dynamic-linker in gnu/packages/bootstrap.scm will trigger rebuilds? I think it won't, since this procedure will return the same value for all existing systems. <mbakke>marusich: I don't think so, but it's good if you test it ;-) <marusich>If it works and does not rebuild the world, I think I will just merge it into master, since it is a one-line change and lle-bout and I have been discussing it here for a few days. Is that OK? <marusich>It'll be followed up by a patch series adding the powerpc64 bootstrap binaries. But it would be nice if everyone can build the bootstrap binaries first. <narispo>Talking about nftables, I'm happy that came with atomic transactions on firewall rules. iptables was vulnerable to race conditions when it served a critical role for security, or you would need to disrupt network momentarily to be safe <marusich>I'll bet you have the record for the biggest time difference between author date and commit date in our Git history so far. <marusich>I do, but I haven't committed in recent months, so I'm just very paranoid about making a mistake <lle-bout>marusich, oh cool that you do! It feels very limiting when you want to contribute and do not have such access. The overhead of proposing a change is limiting. <marusich>The next steps will be to add commits that actually add the bootstrap binaries. So although it's tedious, we should both build them from that commit, verify that they are in fact the same, and then go ahead and store that copy somewhere, like in your gitlab place <lle-bout>Also git email workflow.. wholly unfamiliar with that <marusich>I think the frequent committers often do not submit patch series via email, and I did not in this case. <marusich>But for complicated things, or when feedback is more warranted, they do. <marusich>I will submit a patch series for adding the bootstrap binaries, to give anyone who wants to do it a chance to reproduce them <lle-bout>I wish GNU Guix hosted a sourcehut instance or something <marusich>that's why I did not want to include all the changes at once, since it would be difficult for someone to reproduce the bootstrap binaries we are trying to add, during the review. <lle-bout>marusich, nckx: is nested virtualization enabled in the powerpc64[le] VM from OSUOSL? <lle-bout>It would be great to add that as a builder to Cuirass <lle-bout>I realize you don't know, but I've been initially intending to include more things into the message so you were concerned as well :S <marusich>For now, as long as your GitLab place remains reachable by anyone, it's probably fine to put them there. The important thing is that we independently build the bootstrap binaries, verify their contents are the same, and publish an affirmation of that fact, along with their hashes, to somewhere permanent like the email list. <marusich>The content hash which will be checked into Guix will ensure that anyone who grabs the binaries from anywhere, really, will get the right ones. <lle-bout>okay! Gitlab supports Git LFS and has an HTTP gateway so that should be great <lle-bout>Gitlab Page would guarantee that even if Gitlab site URLs changed, that would still work <marusich>Cool. It's easy to change the location of the binaries later <lle-bout>marusich, I made a relocatable pack of GNU Guix with GNU Guile 3.0.2 on powerpc64-linux <marusich>nice! So a lot of things are working now, eh? <lle-bout>so that even if Gentoo is broken; we can run GNU Guix <joshuaBPMan>Hey guix, why does guile code include "_" underscores a lot? I see it in macros everynow and then... <joshuaBPMan>If you see an underscore is that a clue that bit of code is a macro? <marusich>The single underscore is probably just a name, chosen by convention to be the underscore, which is ignored. <marusich>For example, if you are forced to bind something to a variable and give it a name because of the form you are using, but you don't really want to use it, you would conventionally use the underscore or maybe a variable named "ignored". I guess underscore is more common because it's succinct. <marusich>But, if you have a specific example, it might be good to ask about it, in case we're thinking of different things. <jonsger>lle-bout: nice progress. I'm away from my machine right now :( <lle-bout>jonsger, mostly thanks to recent core-updates merge making things more consistent overall! <joshuaBPMan>but in guix's code I am seeing "_" in system.scm inside a (match ) <marusich>For example, if you match against a record, you must name its fields, so you might see some underscores for unused fields. <marusich>Also, for some reason Hexchat is hiding my underscores....they look like spaces... weird. <marusich>anyways, i'm gonna "guix pull" the latest master branch, "guix gc", and then "guix build --rounds=2 --no-substitutes --target=powerpc64-linux-gnu bootstrap-tarballs" and see what happens. <lle-bout>powerpc64-linux GNU Guix pack: http://[2a01:e0a:2a2:1590:c070:2383:7e16:dc1d]:8000/kmxwkj9k9dnbid8ryybp0idjp6kwnhwm-tarball-pack.tar.gz -- sha256: 994b046ae5fa035d3beff83b409ca997cc07ad793816b8a7abe3b2ea3c9c1552 <lle-bout>which is built from GNU Guix master @ 91c8b23e571b90e2d263194c9fbb2b05c0475dc1 with http://[2a01:e0a:2a2:1590:c070:2383:7e16:dc1d]:8000/guix-powerpc64-linux.patch (sha256: a27cf0b036ee0a2f222959d635dfdd7ada969b09888295567a2725f7b87854a9) <lle-bout>using command: $ ./bootstrap && ./configure --localstatedir=/var --with-courage && make -j$(nproc) && ./pre-inst-env guix pack --relocatable guix <guixer>Hej guix! How can I add a custom config to /gnu/store/<hash>-somepackage/etc/custom-config.conf when installing via profile manifest? <guixer>If that would not work, I can also install it system wide and add the custom config there. <ruffni>my guix is unable to `system reconfigure` --> "guix system: error: getting attributes of path `/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory". i'm puzzled about where this specific bash is referenced and why the system does not just pull (this or another) bash..? <roptat>guixer, modifying the store directly would break the assumptions in the package management model guix uses, so we try to prevent that. Instead, you should call applications in a way that they read from a configuration outside of the store (or in another store item that you built separately) <roptat>we usually do that with services: a service will run said service and pass it an option to read the configuration that was specified by the user. That way, no need to modify a store item or build a special variant of a package just to include a custom configuration <roptat>ruffni, you could try to run "guix gc --verify=repair" <guixer>roptat: hmm. okay. I already have custom configs for services.. but for the package I like to configure is afaik no service definition. So how can I configure it then? The package does not provide a -c flag or so to deliver a user config <ruffni>thanks! i think that was what i was looking for! <roptat>guixer, if there's no option to pass a custom config, maybe it uses an environment variable? if there's no other way for it to look at configuration, I would send a bug report or a patch to make it look in /etc ***jonsger1 is now known as jonsger
<roptat>guixer, I don't know that software specifically, but if it needs to read in /etc and you have no other way, then patch it to read in /etc (in the package definition, there should be a compilation option to change) or create a bug report to ask for someone to do it. You can create files in /etc out of band, but it's best to use the special-file service types so that the file is managed by guix (in your guix config) <guixer>roptat: I think I'll try the extra-special-file way first, and then I'll consider the other options. Thank you :) <lle-bout>marusich, well! cuirass built! I'll have to figure out how to run it now! <andi->Did the TLS certificate for issues.guix.gnu.org just expire? <marusich>I'm still building the bootstrap binaries from source. <apteryx>Does shepherd "block" until all service launching commands return (such as the make-forkexec-constructor one?). <nckx>civodul, rekado_: I had to shut down nginx on berlin for a minute and run certbot manually. The automation was broken. It was trying and failing to bind to ports itself. How is that supposed to work? *nckx crawls back into their hole. <civodul>nckx: looks like you eventually managed to restart it, right? <civodul>would be good to see why the automation is failing <civodul>katco: this is weird; glibc 2.28 is old, could it be that you're mixing different glibc versions here? <nckx>I just ran herd stop nginx && certbot me baby && herd start nginx. <civodul>nckx: i was wondering why about nginx "failing to bind to ports itself" <civodul>certbot is just supposed to drop a file under /var/www, which is served by nginx <katco>civodul: this is on an alien dist. is it possibly finding that glibc? <nckx>Hm, something erased my scrollback 😒 <civodul>katco: could be! could you check whether --pure had the intended effect by checking $PATH, $CPLUS_INCLUDE_PATH, etc. <andi->civodul, nckx: back in the days certbot also supported running it's own HTTP server for services that were not / are not running on 80/HTTP <andi->likely a misconfiguration of certbot? <nckx>I've only ever used DNS-01. <andi->It is likely doing HTTP-01 in that special mode. Do you have a repository with the hosts configuration somewhere? I am happy to take a look. <katco>civodul: it looks like it did. `C_INCLUDE_PATH` includes something i put in my `.bashrc` manually, but other than that a grep for `/usr` is clean. <nckx>andi-: So that's what I thought, but now ‘certbot renew --force-renewal’ (we'll live) runs fine. <katco>maybe i should try a container <sneek>dftxbs3e, you have 1 message! <sneek>dftxbs3e, efraim says: just reading through the backlog now, I'd love access to a ppc64 VM :) <nckx>Ugh, I specifically used ssh over mosh so I'd have scrollback, now it's gone. <dftxbs3e>efraim, send me your SSH public key in PM <nckx>andi-: Indeed, it was trying to authenticate in ‘standalone’ mode. <nckx>2019-02-02 00:00:11,363:DEBUG:acme.standalone:Failed to bind to :80 using IPv6 <katco>civodul: this is looking happier i think! :) <nckx>Oh, I of course ‘renew --force-renewal’ works now, authorisations are probably cached. 🤦 <nckx>It still says ‘Plugins selected: Authenticator standalone, Installer None’ so it will happen again in 90 dayz. <nckx>How could this suddenly change? <nckx> /etc/letsencrypt/renewal/issues.guix.gnu.org.conf → authenticator = standalone 🤔 <andi->What distro is that on? Maybe an update to the certbot packager broke it? They "recently" (over 6 months?) pushed for clients to migrate to their new API <nckx>andi-: Guix System of course 😉 <andi->Thought you said alien earlier ;) <nckx>civodul: Do you remember if we were using the ‘nginx’ or ‘webroot’ authenticator before? Or something else? <andi->(me I fresh to Guix, long term Nix user.. just trying to get my feet wet) <nckx>andi-: You confused me for a sec, but katco used the word alien above. <nckx>No, thanks for trying to help. <nckx>I haven't used certbot for years (dehydrated ftw) and never used any of the automagical plugins. <nckx>Sooo, help very welcome. <andi->I've migrated all my systems to NixOS and there we recently migrated to lego. Don't have any system where I could have a look anymoore :/ 