<nckx>I'm not going to make any pronouncements on theory (because I'm a non-cryptographer and we have a poor track record of saying stupid shit about cryptography), but in practice things like encfs, ecrypts, etc. see significantly fewer qualified eyeballs and maintenance. And are harder to get right. And tend to leak more metadata even when working as intended.
<nckx>Since you're doing this for peace of mind, why compromise.
<Guest28>Ah, so you may committed it on 02 July but pushed it upstream yesterday? Therefore it says 6?
<RavenJoad>What is the "minimal" program to use for a service/daemon that wants to use a mail command?
<nckx>Guest28: It's true that git commit dates can differ greatly from when they were actually pushed, but no, I mean I literally fake the time on all my commits to ‘last Sunday’ regardless of when they are authored, signed, or pushed: https://paste.debian.net/plainh/1c7ce3f3 . That's just me. Other committers are not so silly.
<nckx>I've restarted Cuirass on berlin and it is now evaluating.
<singpolyma>RavenJoad: ssh to mailserver, when that's an option
<RavenJoad>singpolyma: In this case, mail is called by scripts which are run when a UPS event happens. The daemon fails on trying to mail something right now.
<DigitalKiwi>plot twist: script works fine but the router isn't on the UPS
<RavenJoad>As funny as that would be, that is also not the case. apcupsd runs on a standalone computer and monitors messages from the UPS. So the mail comes from the computer. But I just need a package that provides a reasonable mail command without blowing up the closure size.
<oriansj>nckx: that a nondeterministic computer will behave: nondeterministicly. Well yes, otherwise we couldn't use that to do random number generation (The basis of all crypto deployed these days).
<ulfvonbelow>so a strange thing happened just now. I gave a huge list of things to build to 'guix build' with --keep-going, and it built a ton of stuff up to and including ungoogled-chromium, but one build failed, and I just now gave it the same list of things to build again (haven't run guix pull or anything like that) and now it's building bootstrap binaries. I haven't told it to run 'guix gc' at any point, and 'guix graph --type=derivation' tells
<ulfvonbelow>me that the things it successfully build just a little while ago definitely depended on the exact same derivations as are now being built.
<ulfvonbelow>I wonder if this has anything to do with this being done on a system that has itself as a substitute server
<PotentialUser-78>@frog Thanks for the heads up. That's a great catch. But I don't want `guix build...` to run the 'test or 'check phase to begin with.
<jpoiret>janneke: did you report the hurd gnulib test problems upstream?
<jpoiret>also, i'm considering adding a job on CI for hurd
<jpoiret>i'd need to add a new manifest though that would be like release-manifest.scm but with only cross-builds to hurd
<jpoiret>uh, actually since we shouldn't change the derivations of the other archs I can just keep the release manifest 🤔
<janneke>jpoiret: no, i haven't reported those yet
<frog>PotentialUser-78: adding #:tests? #f to the arguments of a package only disables tests for that one package. you disabled tests for python-dirsearch, but that doesn't affect python-pyspnego. if you want to try build python-pyspnego without tests, you can either (option 1) define a package inheriting from python-pyspnego that has tests? as #false and use that as a dependency of python-requests-ntlm, or, (option 2) add
<frog>--without-test=python-pyspnego to your "guix build" command. alternatively, you can update the python-pyspnego package to the latest version and that will fix the tests iirc.
<anemofilia>(I said GSoC just because it really helps some projects in terms of resources, even guix, with the thing of parameterized packages, though I really dislike google and proprietary software in general, just to clarify)
<anemofilia>Anything capable of make guile-emacs active again would be welcome, IMO
<jpoiret>that was discussed recently on #guile and people close to the project said that guile-emacs shouldn't be too hard to update up to where emacs is now
<nckx>I can't even parse what ‘[a] list of “cgit-repo” records to use with config’ is trying to say.
<pjals>it is a (list) of (repository-cgit-configuration)s to use with the (cgit-configuration)
<pjals>By the way, has anyone packaged cwiid for Guix?
<pjals>I got it to configure and build but it seemingly fails at the linking phase, with ld: /gnu/store/qz5knhmckxyss8ybgqv7wagc4402qsn7-bluez-5.66/lib/libbluetooth.so.3: error adding symbols: DSO missing from command line, and I'm really not sure if this is a Guix quirk or not, it seems like a lack of use of pkg-config.
<pjals>I got cwiid to build and link and all that cool stuff! But it seems like it fails at vaildate-runpath: `/gnu/store/mc1ma0cgbv321v7ak1z5fyi23qgjfl0z-cwiid-fadf11e/bin/wminput: error: depends on 'libcwiid.so.1', which cannot be found in RUNPATH ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib" "/gnu/store/qz5knhmckxyss8ybgqv7wagc4402qsn7-bluez-5.66/lib"
<pjals>"/gnu/store/4hym7qzn43kiqszyvjy6z519s1jkdxi8-python2-2.7.18/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../..")`. `libcwiid.so.1` indeed exists in the /lib directory of cwiid, so I'm not sure why it errors.
<nutcase[m]>jpoiret: thank you for that snippet. Although I'm not using dmenu / bemenu, it's nice to know that there is a way to configure xdp-wlr. What I have in my sway config is an `exec dbus-update-activation-environment --all` similarly to what is described in xdp-wlr's README.md
<jpoiret>right, but depending on your DE XDG_CURRENT_DESKTOP might not be set at all
<jpoiret>so you have to make sure that is also the case
<jpoiret>and even if you're not using dmenu / bemenu, I think you *need* a chooser
<nckx>Here it's set, but empty, so I guess that's an option too.
<janneke>jpoiret: you've seen my netdde.static remark, right?
<Guest28>On ARM architecture cat /proc/cpuinfo only returns mips, how would I get the current clock rate?