<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 -_-
<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 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>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 ?
<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>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.
<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 🙂
<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: 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!
<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.
<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.
<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>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>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
<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.
<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.
<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, ) = -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
<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.
<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 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>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
<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!
<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
<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?
<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?