<jab>frick...I may have broke my letsencrypt settings by accidentally changing the owner of the /var/lib/letsencrypt directory...
<jab>and now ssh-ing into my server is super slow all of a sudden...
<iskarian>rekado, so I've learned some things! Apparently with pep 517 there *is* no direct installation. You *must* build a wheel and then install the wheel. PEP 517 also requires build isolation by default, which is why neither pip nor build see local dependencies!
<iskarian>You can disable build isolation with "pip --no-build-isolation" or "build --no-isolation"
<iskarian>With the latter I'm getting inscrutable "ZIP does not support timestamps before 1980" errors
<iskarian>Ah, (setenv "SOURCE_DATE_EPOCH" "315532800") solves that (taken from another package)
<iskarian>I think the python-build-system really needs to be updated
<oriansj>minor bug report for meld on non-guixsd systems: guix environment --ad-hoc meld gtksourceview --fallback always fails to display a valid diff but guix environment --ad-hoc meld firstname.lastname@example.org --fallback works just fine. So the current package definition needs to be revised to correct the current issue.
<singpolyma>If I guix archive --import an archive with a version of guix and dependencies in it, would that be enough to make guix pull take less time?
<raingloom>singpolyma: well, you could work from a local checkout. but guix needs to evaluate all package modules when it searches for a package by name, so there is not much point in delaying that work.
<singpolyma>raingloom: hmm, well in my context (CI build for specific package) I don't think any package lookups by name will happen
<attila_lendvai>raingloom, i haven't seen any excessive memory usage. my laptop has 16 gigs, -6 for the browser, and i was never getting close to the limit. IIRC i began this on a 8gig laptop, and i didn't even notice
<raingloom>dang. maybe Idris1 had some improvements while I wasn't looking. well, i'm hoping to see idris2 in guix soon. :3
<attila_lendvai>iskarian, i lack knowledge to make sense of "compile it such that the RUNPATH is set correctly". can you point me to an nice example in the guix repo?
<singpolyma>Hmm, it seems this fix http://issues.guix.gnu.org/43739 is not in even the debian unstable version of guix yet. Given the way that guix is packaged for debian, I don't think there's a way to update the daemon is there?
<iskarian>attila_lendvai, that seems like a pretty good overview
<iskarian>in Guix, we have modified our ld to (essentially) add a RUNPATH entry for every library linked
<attila_lendvai>iskarian, not sure it'll be easy, because idris emits scheme, and it is then compiled with chez
<jab>hey guix people! I now have my prosody server serving my XMPP account email@example.com Feel free to say hello!
<jab>I have not entirely fixed the buggy certificate issue. it works for now, but I'm not certain if it will work after a restart. Or reboot. Or in a few months when the letsencrypt certificate gets updated.
<apteryx>ah, found it. info '(guix) Channels with Substitutes'
<iskarian>sneek, later tell atilla_lendvai: the nixpkgs idris2 doesn't do a bootstrap chain; it uses the git checkout and chez to bootstrap. am I missing something as to why the bootstrap chain is necessary?
<civodul>so, core-updates-frozen is still not in a great shape
<jbv1[m]> Hi guix! I try to make modifications to the julia-build-system on my local checkout of the guix repository but somehow when I do ./pre-inst-env guix build julia-uri (for example) the last version of julia-build-system.scm does not seem to be loaded? Any clue what I am doing wrong?
<attila_lendvai>iskarian, ouch! the binary generated by chez is a #!/path/chez --script followed by some binary data; i.e. it's not an elf binary with RUNPATH
<sneek>attila_lendvai, iskarian says: the nixpkgs idris2 doesn't do a bootstrap chain; it uses the git checkout and chez to bootstrap. am I missing something as to why the bootstrap chain is necessary?
<attila_lendvai>sneek, it's not necessary, but i want to keep it alive as an option. that's why it's not ready for submission: i want to be able to build both paths and compare the end results.
*makx should figure out how to get hacking on guix properly; except for the excessive compilation wait times for aarch64 I am pretty sold on it (being a scheme person i prefer guix over nix ;))
<civodul>i liked that "ah ha!" moment when i thought about that trick
<gyps>Dear all, im just trying to install guix and so far it went really smooth. Great!
<gyps>But now I'm trying to set up my emacs/EXWM config. For that I need to compile pdftools and this is done using gcc.
<gyps>Somehow if I install the gcc-toolchain package the gcc complains "ld: cannot find crt1.o: ..."
<gyps>If I use package gcc-bootstrap this error does not appear. Any Idea what could be wrong here?
<jlicht>gyps: unrelated to the actual issue you ran into, but we should have an emacs-pdf-tools package that already takes care of compiling epdfinfo
<gyps>OK. I'll try that package. But somehow strange that gcc-toolchain doens't work.
<apteryx>eh, 'guix pull' took 3h 17m on an NXP i.MX6 quad core (ARM)
<apteryx>I'm trying to set it up a TS7970 board as an offload armhf machine; got Guix installed on it, but so far offloading returns: 'guix offload: error: remote command 'guix repl -t machine' failed with status 127' so probably I have to add Guix to the PATH
<roptat>looks like the services field is closed just before the modify-services form
<roptat>so remove one closing parenthesis at the end of line 13, and put it on line 18 instead
<roptat>which reminds me, I should work on that "invalid specifier" patch of mine
<roptat>Soheil[m], I don't know which editor you're using, but any good editor should highlight the corresponding parenthesis when you're on an opening or closing parenthesis, that should help you find where groups don't match what you expect
<jab>nckx: how hard is it to do that on guix? use bcachefs?
*jonsger-laptop would jump in as XFS beta tester :)
<nckx>The nckx answer would be ‘oh, not hard at all! great fun!’ and then slowly remember all the weird hoops I actually jumped through & weird code I had to write, over the course of the next half hour.
<nckx>Well, you'll be running the bcachefs kernel fork, for one, which *can* be combined with the Linux-Libre processes but it's work I've chosen not to do. And you need to make sure your /boot is not-bcachefs, because GRUB still lacks support, and a separate /boot isn't yet supported natively by Guix. But apart from that I honesly think I've upstreamed everything needed to boot Guix on it.
<nckx>jonsger-laptop: Thanks! I'm going to end up adding it simply because I don't want to have to rebase a huge patch I have queued up that touches all of this fs stuff 😉
<jab>nckx: can you translate that technical jargon for me? Is he saying it "technically does support" multiple domain names via the same signing key?
<nckx>He's saying, and I think this applies to you as well, ‘multiple domains don't mean what you think they mean’. Are you aware of any service providers or spam filters that will actually punish you for sending mail from foo.bar signed with a buz.biz key?
<nckx>I'm not, but I haven't been deep into e-mail practices for quite some time.
<nckx>Me agreeing with Martijn doesn't imply either of us is right. :)
<jab>There was a recent discussion about it on the mailing list...Apparently they are trying to figure out how to merge/intermingle system services with home services. Apparently a fetch-mail home service will start automatically even if there is no internet connection, which is kind of odd.
<jab>Also will home services/system services have the same code? It seems like it is hard for them to share code.