<fnstudio>hi! anyone knows how i can have readline support in my bc? i see this https://issues.guix.gnu.org/issue/44977 that seems to indicate a --with-readline option, but that doesn't seem to be available on my guix machine (guix on foreign distro)
<jpoiret>after `guix environment --ad-hoc bc` it seems to have readline support
<nckx>florhizome[m]: As a packager I usually like CMake simply because it spells less torture ahead than most other build systems, but ‘PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE’ — come tf on.
<nckx>jpoiret: Aside, do you know: does conv=sync with dd's teensy default .5K block size absolutely obliterate flash with today's huge erase block sizes, or is firmware (or Linux?) cleverer than that?
<florhizome[m]>I'm just witnessing some dev people switching to meson, there seems to be frustration
<nckx>Just wondering since you advise against it above.
<M6piz7wk[m]>1.1MB/s and the iso is +-650MB so 650/1.1=590sec right
<nckx>florhizome[m]: I cannt for the life of me understand the appeal of Meson but can't tell the vast number of people switching they're ‘wrong’. Sure, some of it it mindless hype, but there's something there.
<jpoiret>nckx: I was advising against it mostly because having io error when writing an install image seems like a lost cause to me
<nckx>I'd toss the drive, sure. Can't keep betting you'll aim your files around the hole.
<nckx>I was wondering if it would force a full erase (with blocks being, what, 1M nowadays?) for every 512 bytes written, which could mean that every single block is rewritten 2048 times during the dd alone. I don't actually know if that's how modern flash works, but having seen the stuff sold, I'm not optimistic.
<nckx>jpoiret: That is quite possible! My answer is still based on current master, I should really join the c-u-f cool kids club…
<jpoiret>what seems weird to me is that primitive-load's error should be caught by the call-with-error-handling in the linux boot
<florhizome[m]><nckx> "jpoiret: Here, %outputs, (the..." <- That is bc you need to use Lambda* anyways amiright
<nckx>You don't strictly need to (you could use a plain λ and still refer to %outputs) but λ* is considered better style in Guix, hence encouraged. (Another ‘applies to current master’ answer; I haven't tried c-u-f yet.)
<jpoiret>in fact it does catch that error, so it might not even be it
<nckx>Fine. Since tomorrow's a holiday, today will be the day that I rebase my truckload of already-broken patches that already fail to boot on c-u-f, and try to boot it 😛 It's spooky. It will probably take all night. It's apt. 🎃
<jpoiret>their news are quite interesting i've noticed
<nckx>Unless $7.00 is a lot of money I'd say it is, jpoiret.
<nckx>I can't decide that for you but the quality is there.
<gbrlwck>i am trying to `guix pull` on a RISC-V ubuntu machine but this process hangs while building 9xnyrapxcfk7mi4id3wf7g54m8hrrdgd-python-minimal-3.9.6.drv. i count 71 zombie "[python] <defunct>" processes. https://termbin.com/j01x
<gbrlwck>how can i inspect what generates the issue? should i just kill the zombies and hope for `guix pull` to finish anyways?
<vivien>OK, so how did you install packages within the guix installer?
<vivien>Normally the installer does not ask you to install packages, I’m confused.
<gabr000>i ask that because i was having trouble with emacs-exwm installed during boot installation (i marked the boxes of emacs-exwm)
<vivien>OK, so each user should be able to run EXWM
<gabr000>and for that packages i couldnt install emacs-guix
<gabr000>i needed install emacs again for the user
<vivien>Since EXWM is just emacs, the emacs binary is that of the system (the same for all users), and I think you need to extend that to all your emacs packages. The installer should have written a file named /etc/config.scm, that details the system configuration. You should see an emacs entry in the packages list, and if you put all the other emacs- packages in the same place, you will be able to use them.
<vivien>I don’t have an EXWM system anymore, so I’m telling this from what I remember.
<attila_lendvai>is there some machinery to check the signature of an archive that gets downloaded by (origin (method url-fetch) ...)? i'm working on a binary downloader package (to be inlucded somewhere else), and for now i'm invoking gpg in the build phase on a keyring assembled from a text constant. but it's... not beautiful.
<attila_lendvai>or authentication completely relies on the content hash? the upside of checking the gpg signature is that when the package is upgraded, then only the version needs to be incremented. no need to manually check the signature and the content hash.
<vivien>attila_lendvai, I’m sure it would be useful for source code distributions too.
<vivien>But, if the signature matches, without knowing the hash, how do you know it’s not a downgrade?
<vivien>(how do you check that the thing you downloaded is of the same version as what you defined in the module)
<attila_lendvai>vivien, i wouldn't get rid of the content hash. i think the only benefit of the source signature check is that it's easier to update the package to a new version: just edit the version, fire the build, replace the hash with the new one from the error message. no need to manually check the signature.
<attila_lendvai>vivien, i'm not sure about it either. i think the content hash does everything the signature does. and i don't readily see an attack vector that is closed by the signature check, but not the content hash. yet, for some reason it *feels* useful.
<fnstudio>do you think that hints at some problem with my guix setup?
<vivien>attila_lendvai, maybe you could make a gpg importer: you would pass it the URL for the downloaded thing, the URL for the signature (it could heuristically find it IMO) and it would tell you the hash after checking it.
<attila_lendvai>vivien, and where would the key itself come from? the invoking user's ~/.gnupg keyring?
<vivien>attila_lendvai, yes, but first it would try to refresh the key from a key server
<attila_lendvai>vivien, am i right to assume that the key refresh operation is safe for man in the middle attacks?
<vivien>attila_lendvai, not really, if someone makes you download an old version of a revoked key, you might validate the signature.
<attila_lendvai>i.e. if the initial import was done well, then key refresh is safe because key updates are self-signed.
<florhizome[m]>So gala wants libmutter 6-9 , but guix only has Mutter 3.34 which ships with libmutter 5 :D
<vivien>florhizome[m], on core-updates-frozen, mutter is version 40.5, and it will be merged into master Really Really Really Soon
<florhizome[m]>thoughts and prayers to all ppls doing gods work on c-u-f ;)
<vivien>I hope they manage to do it and not drown under the amount of merges to do between master and the various core-updates :(
<florhizome[m]>vivien: yeah I suspected that. it just looked very bleak “can’t find libmutter 6. ...;7...;8....;9”
<florhizome[m]>they seem to have put in a lot of work between gtk 3.34 and 40
<florhizome[m]>At this point I am v curious to reading the blogpost after the merge
<rekado>bah, I have no idea how to get these Honeycomb LX2 boards to work
<nckx>Something for me to look forward to, I guess.
<attila_lendvai>if i want to specify a make target in the build phase, then my best bet is (replace 'build (lambda ...)...) and copy-paste the (apply invoke "make" ...) from build/gnu-build-system.scm?
<attila_lendvai>note that #:make-flags doesn't work because it's passed to make install, etc
<nckx>attila_lendvai: Yes. And agreed: #:make-target is better. It's #:test-target after all, although I've written #:check? and #:check-target after a holiday… Consistency is my crutch.
<attila_lendvai>nckx, now that i think about it a bit more... it's the name of the target that should be used in the build phase, so build-target is probably a better name than make-target. after all, `make test` is a make target, too.
<attila_lendvai>hrm... or maybe not. but it rebuilds the whole world, so i'll leave it alone on this laptop anyway... :)
<nckx>attila_lendvai: Hehe, I think we're trying too hard to divine hidden logic where there is none (not that it matters :)
<nckx>#:build-target makes it clear that, unlike #:make-flags, it applies only to build. Oh whatever. If you do submit this patch, choose whatever you prefer!
<attila_lendvai>nckx, i think it actually matters a lot, because good names are crucial for an efficient teamwork (where me two weeks later is another team member)... my dismissive attitude is because i'm new to guix, and i don't want to mess with world rebuilding changes just yet.
<attila_lendvai>i'm seeing this "WARNING: Could not find qmake spec 'default'" from lrelease (it's a qt thingy to compile language files). there's nothing on the web about this (besides a heisenbug), so i think this may be a guix packaging issue of qttools
<drakonis>a rfc process can be good when it is done correctly and isnt used like a cudgel
*M6piz7wk[m] solved his problems with flatpak to get nextcloud and vscodium
<M6piz7wk[m]>felt bad for them since one else had the sanity to deal with their problem
<M6piz7wk[m]>and you can't even like chroot and easily reinstall that thing
<nckx>It's obviously aimed at folks who don't know what a chroot is or how you're supposed to cook it, but yeah, that means it's not allowed to break or show scary errors. That's kind of the deal. Pity.
<rekado>nckx: I tried booting Ubuntu, and Linux tells me that there are I/O errors. Even before that, though, when I boot the default u-boot image and run “scsi reset” it sometimes works and sometimes just times out.
<mekeor[m]>jgart: why would you transpile purescript to guile/guix? :D
<M6piz7wk[m]>it's like early-alpha at beast in terms of "not allowed to break" last time i checked it