***Server sets mode: +Ccntz
<nckx>I.e. ‘beinq’; cut-off timestamps. <lfam>Fonts are terrible on GNU / Linux <lfam>Sometimes it works right, sometimes not, and we'll never understand why <drakonis>i dont think the font cache is refreshed whenever guix install is done <drakonis>or is it just cleaning it up to only take effect only when hurd is concerned? <nckx>Sweet lord. If that even half-works I'm impressed. <nckx>I don't think you can plausibly abuse a macro that way, no matter how you shuffle quotes about. <nckx>It looks like you're trying very hard to avoid rebuilds, but since you mention c-u: why not just use a more conventional if around 2 substitute*s? <dongcarl>nckx: Oh yeah I was just trying very hard to avoid 2 substitutes and learn more about Guile in the mean time haha <nckx>dongcarl: Now I see where & who you got apply from, and the confusion :) Yes, the problem is that it's not a ‘real’ procedure. <nckx>Feels weird to say about a lisp, but I can't think of a way to do this with a macro. <nckx>Without going full eval insanity. <lfam>Now there's an idea for a tshirt <mitzman>hmmm bash-mesboot0 uses no config.guess? <raghavgururajan>> nckx: raghavgururajan: Corruption runs rampant-ish in your store! Did you add ,repair? <raghavgururajan>Not sure why 'xorgproto' appears there, as I removed it using `guix gc -D`. <raghavgururajan>nckx: After `guix gc -D PATH` and `guix gc --delete-generations`, `guix gc --verify=contents,repair` show no errors. But '/gnu/store/6yn16h7la1cj64gm5gvklhijcd4k1zgb-cups-2.3.3/lib/libcups.so.2: file too short' still appear. I am gonna guix pull and upgrade, to see it replaces those store items. <apteryx_>lfam: rust question; what is rust-rav1e useful for? Does rav1e not provide the Rust library component as well? <danderson`>So, tried installing guix from the iso, but installing to /mnt it ran out of space, telling me it needs 5G but only has 1G free. I'm confused, because the target partition is 8G, and only has 2G used. What am I missing? <lfam>apteryx_: I don't remember what it's for now <ix>nckx: lfam: and anyone else important, i reckon the guix install <ix>*er might be setting /var/lib to 700 <lfam>apteryx_: I remember that ngz had a reason for it <ix>Forgot, figured i should flag that up with someone <ix>Since it caused me so much grief <ix>(i did `guix system init` from a liveusb) <danderson`>drakonis: but, `df -h` says the partition has 5G free. Where does guix conclude that there's only 1G? <danderson`>I followed the graphical installer. It didn't have me do anything about store mounting. <drakonis>Is it mounted on the usb instead of the target? <ix>danderson`: if you df -h, is there *any* partition in that tree running low? <danderson`>anything in particular? Or is that just a generic "RTFM" ? :) <danderson`>ix: lowest is a bunch of tmpfsen from the installer, all >3G free <danderson`>Being a VM, I quadrupled the disk size, and giving it another go. I guess if it was the disk being too small, I'll find out once everything's redownloaded one more time. <sneek>ngz was last seen in #guix 2 months ago, saying: Hello Guix.. <drakonis>danderson`: no it's not, but i've done my installations manually <danderson`>okay, well, back to setting up /mnt, but again, not enough space. So, this must be something other than the target partition... <drakonis>However i think guix's installer no longer simply outputs a config in the end <ix>danderson`: maybe some ramdisk thing? <danderson`>... okay, well, it is /dev/sda3 running out of space, but seemingly because it once again plopped down a 6G partition instead of using the entire disk. Weird. <drakonis>Are you using the installer to partition? <danderson`>I am. Seems like the graphical guided partitioning is choosing to not use the entire disk, for some reason. <danderson`>Letting it fail now, then I'll cfdisk it to the right shape <danderson`>okay, well, the graphical installer won't do anything but recreate a 6G partition on a 32G disk. And if I try to mkfs.ext4 by hand, it tells me the partition is in use by the OS, even though it's mounted nowhere. <danderson`>So... Not looking great for guix, if I'm honest. <danderson`>brb, third run through the installer. Let's see if I can make it less confused. <drakonis>i dont think i've ever used the graphical installer <drakonis>let me just try to do a install here real quick for good measure <danderson`>okay, well, this time around, it seems to have grasped that the disk is 32G and that I want to use all of it <drakonis>you can also use the existing qemu image but i dont think that's what you want to do right now <danderson`>yeah, this is a test drive for putting it on real hardware, so I want the full installer experience. <drakonis>the other alternative option is to drop into the CLI for the process <danderson`>okay, no warnings this time, looks like I'll get past this stage of the install. Onwards. <apteryx_>the cargo-build-system doc says "Regular cargo dependencies should be added to the package <drakonis>i got into the point where the install takes place <apteryx_>[...]definition similarly to other packages. What is a "regular cardo dependencies"? On that ends up as a binary? <drakonis>sometimes it can get held up by other things <drakonis>danderson`: well, i got it to work the first time around <drakonis>graphical installer and guided partitioning <apteryx_>ah; that's the single thread problem; if you sleep in a service for 20 s, the world halts for 20 s. <ixmpp>drakonis: shepherd's still pretty barebones eh <ixmpp>And not in the good way like runit or s6 <drakonis>adding missing functionality isnt a big deal <drakonis>one of the things on the TODO for shepherd is to add fibers to it <drakonis>i should go get a mail server working tho <ixmpp>drakonis: say i want to modify a service <ixmpp>Like, the service, not the configuration <ixmpp>Just redefine it and inherit shit? <ixmpp>Ok so i have some prereqs for that then, i'll do it later <ixmpp>Wireguard service isnt up to scratch <ixmpp>Somehow yeah, but its not plumbed by the service <drakonis>ah, okay, you can feed a whole configuration file to the service <ixmpp>Do you guys not like trapdoors like "extra-config" <drakonis>also doing that with guix is pretty trivial honestly <drakonis>as i was in a bit of a hurry to set up my nginx server <drakonis>you can just override the function that generates the files in wireguard's case <drakonis>it provides an escape hatch in the form of config-file <ixmpp>How odd, its not in the manual <drakonis>that's because the manual is for 1.3.0 i think? <ixmpp>Its just an inconvenient interface <ixmpp>I would use it more, i should <ixmpp>Maybe i will once i get emacs up to speed <raghavgururajan>sneek, later tell nckx: Finally was able to get rid of the errors/issues by doing [1] `guix pull -d` (as root and user) [2] `guix package -d` (as root and user) [3] `guix system -d` (as root) [4] `guix gc -d` (as root) [5] `guix pull` (as root and user) [6] `guix upgrade` (as user) [7] `guix system reconfigure` (as root) [8] Repeating steps 1 to 4. <papaya-salad>How can I reduce inode usage with guix? I've never run into a problem with no remaining in odes w other distros ***jackhill is now known as jackhill[m]
***jackhill[m] is now known as jackhill
<drakonis>papaya-salad: have you invoked guix gc to collect garbage? <apteryx_>lfam: do you know if ffmpeg is a sensitive dependency to update? From 4.3.2 to 4.4, say? <raghavgururajan>sneek, later tell civodul: Since you recently made Guix Days logo, did Guix.svg opened fine on Inkscape? I get "Failed to load the requested file". <sneek>Welcome back mothacehe, you have 1 message! <sneek>mothacehe, apteryx_ says: yes that'd be a good improvement already :-) <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, raghavgururajan says: Since you recently made Guix Days logo, did Guix.svg opened fine on Inkscape? I get "Failed to load the requested file". <civodul>raghavgururajan: i think it opened fine <mothacehe>fine thanks :) I'll try to have a look to the Guix discovery bug you reported yesterday! <mothacehe>the keep-alive patch seems to bring improvements, which is nice <mothacehe>I have a small follow-up to improve it further <mothacehe>yes it should improve performances, but i'm mostly monitoring substitutes connection timeout errors on the build farm <mothacehe>now that every workers opens more or less one unique connection, I hope those errors will go away <mothacehe>nckx: I killed two GC processes on berlin owned by yourself. They were blocking Cuirass builds. <civodul>mothacehe: those connection timeouts are pretty bad <tissevert>raghavgururajan: well, since they are indeed XML files, maybe that's a weird preference setup somewhere ? but I can open then just fine here too <tissevert>for what it's worth the installed version seems to be in /gnu/store/zz2fmgq40m… but I suppose it depends on the exact time when I last `guix pulled`, doesn't it ? <tissevert>oh, I didn't know there were extra black'n'white verisons in Guix.svg outside the frame <tissevert>I use Inkscape 1.0.2 (e86c870879, 2021-01-15 with Pango version: 1.44.7 <raghavgururajan>Same issue when I do it via `guix environment --pure --ad-hoc inkscape` <tissevert>ok from the URL it looks like a raw download, was there some kind of problem during the download ? mine is from a cloned repos <tissevert>f48c4a45f5633d9a6345d38e9811575072be4417e51936f75bfe629dc6bf869b8926fff8b93343e1534c456d827f7b7c328e683031d9e5b9c8d03a5829ccbfae Guix.svg *raghavgururajan tries cloning <tissevert>(or simply sha512sum the file you already have, to see if that could be the reason) <tissevert>well I didn't do anything only reassure you it was supposed to work <tissevert>(I'd be curious to see the actual XML file you got though) <apapsch>building with `guix system image -L . config-builder.scm` works fine, though booting fails (root device not found). I originally had sda/sda1 devices and changed it to vda/vda1 (just guessing here). `guix system image` still produces the same image, hash does not change <mothacehe>apapsch: hey! you may want to produce a qcow2 image here, by running `guix system image -t qcow2 -L . config-build.scm` <mothacehe>did you try to boot the image locally using qemu? <apapsch>no I went straight to ovh, wanted to test if I can get it to boot <mothacehe>if it works, then maybe OVH has some special requirements <tissevert>but that link is a link to the page that previews the file in the repos <tissevert>that is, the same link but with s/tree/plain/ <jonsger>hm, node-10.24 fails with "error: ‘FALSE’ was not declared in this scope" on core-updates <apapsch>local qemu works fine. guix sets a root disk uuid in grub config. how does it match the disk created by qemu? is it a magic number established by qemu? <apapsch>it gets weirder in OVH: `ls -l` in grub shell shows me the device with the magic UUID, but guix cannot find it ***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<mjw>Is there an easy way to view the svg visually? <tissevert>I saved the mail to txt, edited it to extract the svg and saved it as .svg, then opened it with my default image viewer <mjw>right, so no pointy-clicky there it is? :) <tissevert>there possibly is a way but I don't know it ^^ <tissevert>but the format of the patch is different from the one we usually have in guix-patch, I think <tissevert>I could not find a proper «patch» file to save and then apply on the repos <tissevert>(this would lead to a clean pointy-clicky solution) <mothacehe>it would be nice to also create a page on the website to advertise them <tissevert>hmmm re-reading my mail now it sounds awfully negative <tissevert>raghavgururajan: I forgot to tell the most important thing: they look cool 👍 <tissevert>mjw: I was mistaken, the «text body» of the mail is actually a git comment so the whole message is a proper patch <jonsger>nice, found a a patch for nodejs on core-updates <tissevert>just save it as a local file in your mail client, then git apply the file (that's not pointy in itself but if you use a clicky git tool then maybe ?) <tissevert>et voilà, file appears in your local copy of guix-artwork/logo <mjw>raghavgururajan, nice <mjw>raghavgururajan, may I suggest to remove the word "using", I think it is implied, and then you have a bit more space for "Deploy and Manage" <mjw>random opinion though, feel free to ignore if you think the current design is more clear <tissevert>+1, that concurs with my remark issue about the volume of text <raghavgururajan>mjw: Thanks. Wouldn't 'Deploy and Manage GNU Guix' grammatically mean something different? May be 'Deploy with GNU Guix'? <tissevert>manage can be vague, the big plus of Guix to me is clean (and reproducible) deployment <tissevert>oh, I get it now, my remark about GuixSD is completely wrong <tissevert>the badge is for software, software is deployed using guix, regardless of wether it's running on GuixSD or another distro <raghavgururajan>yeah, also the term 'GuixSD' has been deprecated and replaced with 'Guix System'. <mjw>raghavgururajan, I don't think it really needs to make grammatically sense <jonsger>hm, it's seems like one need to import (guix store) to use (patches (search-patches... <mjw>raghavgururajan, but if you want, then I think "Deploy with" is a good (short) alternative <jonsger>neither (use-modules (guix store)) nor #modules ((guix store...) in the package definition nor a combination of both does help <jonsger>hm, thats now even with `guix build node`. Maybe I broke guix... <sgibb>Hello, I use guix pack to build a singularity container. I can't figure out how to set an entry-point with arguments --entry-point=bin/R --vanilla is not working, nor --entry-points="bin/R --vanilla", nor with ' or backticks. <jonsger>ah got it, it's due to my fancy combinations between guix + additional channels + pre-inst-env et.al. <sgibb>I also added glibc-utf8-locales to the manifest that is used for `guix pack` but R can't find the correct locale; According to `singularity exec --cleanenv container.sif env` there is neither LOCPATH nor GUIX_LOCPATH set. If I set it manually in an interactive `singularity shell container.sif` environment to `LOCPATH=$PATH/../lib/locale` everthing works as expected. Is there anyway to tell `guix pack` to set LOCPATH? <nefix>Hello! I'm trying to write a derivation for tree-sitter (for building neovim-nightly), but I'm struggling with this error: 'error: manifest path `/tmp/guix-build-tree-sitter-0.19.5.drv-0/source/Cargo.toml` is a virtual manifest, but this command requires running against an actual package in this workspace'. Does anybody have a clue? Thanks! <tissevert>that sounds like some sort of template ? weird. I was giving neovim-gtk a try yesterday and the Cargo.toml there seemed just fine <tissevert>yeah, when you give Cargo.toml (in tree-sitter) a look, it certainly looks empty <tissevert>two `members`, "cli" and "lib", that looks like the structure of tree-sitter itself, not a proper source for its dependencies <tissevert>how did you write your derivation ? using the importer ? maybe some choice between using Cargo.toml vs. Cargo.lock ? <tissevert>I don't know a thing about Rust so I really couldn't help here but it's the general direction I'd go searching in <Noisytoot>mjw, "Deploy and Manage GNU Guix" is also valid and means something different to "Deploy with GNU Guix" or "Deploy and Manage using GNU Guix" <nefix>tissevert: I wrote it myself <apapsch>Guix now boots in OVH (openstack)! The magic was "--property hw_disk_bus=virtio" to `openstack image create`. OVH defaults to scsi. I'm not sure which kernel module to add, "virtio_scsi" was unsuccessful <ix>Can i get error build logs to the console by default? <ix>Having to bzcat a store path is inconvenient for iteration <ix>roptat: can that work for guix pull <ix>build of /gnu/store/1nmm1dzx6f6358ifcvg3q8r7dicb279p-rc.drv failed <ix>View build log at '/var/log/guix/drvs/1n/mm1dzx6f6358ifcvg3q8r7dicb279p-rc.drv.bz2'. <ix>Ah, v6 worked for pull <ix>So i'll binary search <papaya-salad>Is the typical way to run guix gc simply with no arguments, or is there a better way? <tissevert>nefix: hmmm I really have no idea, it builds in a local clone of tree-sitter and I don't see how the cargo-build-system is doing anything else than `cargo build --release` <nefix>tissevert: yeah, I don't get it either. In the Nix package they do a manual 'make install' though. But I'm not sure how to adapt it into Guix's syntax <tissevert>raghavgururajan: I don't see much difference with v2 except the size of the files so I'm still as enthusiastic : ) <raghavgururajan>the border. v2 has the page border and shadow in the background. I removed them in v3. <tissevert>oh Oo wait that is visible in the rendered svg ? <tissevert>nefix: so shouldn't the gnu-build-system work ? ^^' <roptat>nefix, to run "make install", you can change the phases and do something like (replace 'install (lambda _ (invoke "make" "install"))) or similar <dstolfa>sneek: later tell ssouth: so the Morello boards are free via applying for some project only in the UK, it's unclear what criteria they have to distribute them and there should only be around 100 of them. outside of the UK, one would have to buy it from ARM directly and they cost around 4000GBP, so i don't think that's the best investment considering QEMU already exists to run CHERI-y and morello things. i <dstolfa>should have a board available for personal projects and software bringup so at least i'll be able to smoke test guix on it and patch it up if i find any issues <papaya-salad>Does anyone here have experience with machine learning in Guix? Does anaconda play well with guix, or should I try to only create environments with guix environment <fnstudio>papaya-salad: if the question is specifically about machine learning with python (since you mention anaconda), my experience is that you can find many major libraries in guix already, so i have a part of my projects handled that way, however... <fnstudio>in other cases, for less popular libraries, you may need to create a guix version yourself or switch over to a different setup (e.g. a virtualenv) <zap>hey guix! I ran 'guix pull' on one of my vms and it is now building tcc-boot0.... <zap>is it trying to bootstrap everything? Is it normal? <zap>aaah I see! "ACL for archive imports seems to be uninitialized, substitutes may be unavailable" <zap>Never gotten this before <rekado_>you need to authorize the substitute server <zap>rekado_: yep thank you. This happed after I authorized my machine for offloading <zap>anyone has experience with inferiors? I was building mongo from inferior and it failed. But there was no output and no even a link to bz archive to check... <mitzman>weird semi-offtopic request - can someone please "touch /tmp/smth" then write a small c program that does a sys/stat.h stat call, and prints out the returned stat.st_mode as an int? <mitzman>i want to compare with what i have because what i get is incredibly weird and might be related to 45165 bug <roptat>raghavgururajan, do you have a url where we could see the badges you want to add to the website? <raghavgururajan>roptat: The patches doesn't add to the guix website as a content. They add svg files as source and png files to static. *raghavgururajan is looking to create a webpage about badges, as mothacehe suggested. :) <drakonis>dstolfa: the message was cut up so sneek will only send a portion of it <dstolfa>sneek: later tell ssouth: should have a board available for personal projects and software bringup so at least i'll be able to smoke test guix on it and patch it up if i find any issues <ssouth>dstolfa: I'm actually here right now. Sounds good. <sneek>Welcome back ssouth, you have 2 messages! <sneek>ssouth, dstolfa says: so the Morello boards are free via applying for some project only in the UK, it's unclear what criteria they have to distribute them and there should only be around 100 of them. outside of the UK, one would have to buy it from ARM directly and they cost around 4000GBP, so i don't think that's the best investment considering QEMU already exists to run CHERI-y and morello things. i <sneek>ssouth, dstolfa says: should have a board available for personal projects and software bringup so at least i'll be able to smoke test guix on it and patch it up if i find any issues <ssouth>It'd be nice to have this stuff incorporated into Guix early. <dstolfa>ssouth: yeah, i agree. i'll aim to poke it with guix whenever i get access to it and try to get a board that i can have for personal use rather than just work use early <civodul>roptat: oh, frama-c & why3, great job! <roptat>yeah, I wanted to use frama-c, but in the end we went with something else <roptat>so I didn't test it too much, but it seemed to be working, I managed to run the first few examples from the documentation <civodul>well, it's better to not write C in the first place, but still ;-) <roptat>he talked about the history of frama-c, and what's behind frama-c/wp <zap>roptat: can you share what did you use instead frama-c? <zap>btw gtk iterface is a separate project? <roptat>I'm writing my own analysis, based on a C parser called frontc <roptat>had to fix frontc, made a few pull requests ^^' <sneek>maximed, you have 2 messages! <sneek>maximed, amirouche says: use fibers issues and ping @amirouche <sneek>maximed, amirouche says: and/or ping me here <roptat>zap, and I don't know about the gtk interface <dstolfa>i see matrix has been struggling a bit <qyliss>because netsplits never happen between IRC servers? <ixmpp>qyliss, do you use guix by the way? <ixmpp>there's a couple of nix folk here now <qyliss>I think I'm too invested to switch <ixmpp>i reckon eelco switching would be ...odd <ixmpp>and john switching would at least turn heads ***lukedashjr is now known as luke-jr
<drakonis>John switching might be possible anyways <drakonis>he's interested in keeping touch over adding CAS to guix <drakonis>his motivation to switch would have to hinge entirely on the organizational structure and any technical reasons <drakonis>technical issues that cannot be fixed without significant alterations <drakonis>civodul: what's the policy for dealing with people who're interested in guix but have difficulties acquiring the necessary hardware for getting linux-libre to work to its full potential, ie: wifi and nvidia? <drakonis>also with regards to making the channel a bit more approachable, i've had a few reports of people not wanting to try guix because of that <ixmpp>current convention seems to be PM them to join the "other channel" <drakonis>because they feel unwelcome to even giving it a shot despite the lack of hardware <drakonis>currently guix's repos are analogue to that of debian main without contrib or nonfree <ixmpp>i just realised, since my channel depends on other channels, does that mean i can't mention it here? <drakonis>its largely a policy of how to discuss these things <drakonis>the matter is how to actually discuss this without throwing the baby with the bathwater <drakonis>i think there's some folks that want to run software that explicitly needs dotnet, which currently lives on third party repos <drakonis>as dotnet itself isnt very bootstrappable <dstolfa>drakonis: from my experience, i think simply saying "you are free to add any other channels and use the system as you wish" is sufficient, as guix doesn't actually endorse any non-free software but you're free to use it yourself if you want to. guix is a bit stricter than debian when it comes to that because even having "official" packages for your distro is already endorsing non-free software. again, just <dstolfa>my experience/thoughts, wait to see what other people (who are actually affliated with guix) say <ixmpp>drakonis: no i reckoned it would be discouraged since there's literal references to nonguix in there <drakonis>trying to bridge the middle ground here to finally bring an end to this problem <drakonis>v. tired of hearing people talk about avoiding guix due to feeling unwelcome due to the stances <ixmpp>i think the correct solution is continue with packages as they are now, it's a fine solution, and you can have only freefree stuff in the main repo, but stopping the moratorium on discussing external repos is essential <ixmpp>that said, deja vu on nixpkgs not wanting people using any other repo but nixpkgs <drakonis>i'm looking for the existence of a contrib repo at least, so the stuff that isnt completely fit for baseline guix is available for those who need it <roptat>if you're thinking free software that's hard to package, I agree <dstolfa>roptat: yeah, that would actually be nice, and give an easy way to gradually upstream $COMPLICATED_STUFF <ss2>drakonis: that'd be grand. It would be nice if there would be some way or another to give hardware support, that, saddly relies on non-free firmware. <drakonis>split nonguix into two halves, contrib and nonfree <roptat>rather, have a channel under guix's namespace, if that's free software <ixmpp>i would say just have an entirely separate channel for contrib <ixmpp>it needs to move faster than the other two ***lukedashjr is now known as luke-jr
<qyliss>The main thing that does appeal to me about Guix is the high bar it sets for package inclusion <dstolfa>FWIW i think that guix-contrib channel would be quite nice for free software that is perhaps a bit unstable, hard to package, etc. basically doesn't meet the quality requirements but is usable in some way. it would give a direct way to get these things upstreamed and polished for mainline guix <drakonis>which is why i'm proposing to keep it split <drakonis>retain the high bar for the mainline repository <drakonis>leave contrib and nonfree for the things that are very difficult or impossible to meet the standards <ixmpp>qyliss: yeah honestly i thought i'd hate that but it's growing on me. it's not like nix where package inclusion depends on the weather forecast and your power in the community and yet all packages are still pretty low quality <drakonis>nonfree will obviously have to live outside of the official repos due to the gnu endorsement <ixmpp>if it's restrictive, but the packages benefit from that, i reckon that's sensible <drakonis>there's nothing that can be done about this if the goal is to be a free distro <qyliss>I spent so much time trying to get other Nix people to care about bootstrappability, and I've basically given up getting them to care about freedom <ixmpp>sounds like you'd like guix :p <qyliss>I probably would, but I have a lot of investment in Nix <dstolfa>i probably wouldn't end up here if guix wasn't a GNU/FSDG thing. when i turned off my nvidia card i thought: "well this is the last non-free thing i need, so..." <ixmpp>oh i meant to keep an eye on that <drakonis>honestly, i'd like to see spectrum on guix instead. <qyliss>I mean more, I have everything set up right, and a lot of standing in the community and stuff <drakonis>one of my long term goals is to steal as many people from the nix community as possible :v <dstolfa>qyliss: well hey, you don't have to abandon other projects to contribute to or use another one! :P <dstolfa>qyliss: my dayjob and funding is for FreeBSD, but i still spend free time on guix <ixmpp>technically i'm split-brain too right now <ixmpp>but mainly because that's gonna be a TASK <drakonis>dstolfa: i thought i had already ranted a few times about guix on irc before you actually decided to jump ship <dstolfa>drakonis: no, i found out about guix through FSDG :D <ixmpp>drakonis, you think? you clearly haven't read my config <ixmpp>let me send you pstree for my server right now <drakonis>i've seen your tree on github and its pants on head flaming insane <drakonis>flakes does not conduct towards sane tree structuring <jonsger>hm, nss test suite fails with one test on core-updates. I wonder if it makes sense to update it instead <ixmpp>but containers made it a bit more civil <qyliss>dstolfa: heh, one of my main interests at the moment is Nix on BSD <ixmpp>so yeah, migrating that will be a several-months task <ixmpp>ooh, there's a minecraft server on there <ixmpp>didn't realise. i'd spawned another one locally a few months back lol <ixmpp>see not even i know what's on that box anymore <ixmpp>it's actually relatively tidy <ixmpp>hosts/zeta/default.nix it's well defined <ixmpp>everything in neat containers <ixmpp>only the reverse proxy, tor, and minecraft(???) toplevel <ixmpp>one man's clown fiesta is another's... <ixmpp>anyway, that can stay nixos until i grow the balls to sort it out <drakonis>qyliss: dstolfa has so many words on the matter <drakonis>we'd probably spend half a day on it and he wouldnt run out of words <dstolfa>ixmpp: no, the bsds don't have a glibc <ixmpp>darn. dropped a hard dependency on systemd, gained one on glibc <ixmpp>ah well. nowhere near as bad <dstolfa>drakonis: unsure then, i remember there were some odd issues <roptat>(but that's because android has a linux kernel, I'm cheating) <drakonis>getting shepherd and mcron would probably take some effort <dstolfa>i can't see that the BSDs would care much for a GPLv3 system <dstolfa>we're talking about systems that decided to stay on an ancient version of gcc because of GPLv3 shift <dstolfa>so uh, doesn't fill me with confidence <qyliss>(although they're certainly not GPLv3 fans) <dstolfa>i prefer the GPL in any case personally <ixmpp>oh i was just stashing some code away <ixmpp>i had plans to integrate guix deeper <ixmpp>anyway, i'm on the live branch now <jonsger>I thought we had an option for `guix build` to disable tests, but it seems we have not... <roptat>you can see it with --help-transform <drakonis>hmm, i should draft an email for guix-devel later <drakonis>to get the repo topic into the mailing list <jonsger>ah, merci roptat never saw this sub-help-option <drakonis>i'll run it through here first just to make sure i dont forget anything <roptat>it's relatively new, we added it with a bunch of transformation options <drakonis>i am almost certain that someone in the mailing list might be opposed to it in some way or another <drakonis>also a fine way to actually push me to finish setting up my email server <dstolfa>drakonis: everyone will have their opinion, but the question is how does guix become most accessible to a wide variety of people without compromising on not endorsing any non-free programs and respecting FSDG <ixmpp>does it not suffice to not have nonfree stuff in the gnu guix repo? we all know nonguix exists <danderson`>new around here, but: being allowed to say "that's offtopic here, see #nonguix" would address the onboarding sadness I encountered. It's strange to me that SOP right now is "sorry we can't help you" in public combined with a private message to point at nonguix. <danderson`>In practice, people are being told about non-free sources from here, it just happens out of sight. I wonder why that's better than being upfront about it. <katco>hey, i'm having some trouble using the guix install image over serial->usb. it boots to grub, i briefly see "welcome to grub!" and then just a blank screen forever. i plugged a keyboard into its usb port and can't Ctr-Alt-F{3,4,5,6} or anything. anyone have any ideas? this is a pcengines apu2d4 <drakonis>danderson`: out of sight out of mind was it? <dstolfa>ixmpp: What would be unacceptable is for the documentation to give people instructions for installing a nonfree program on the system, or mention conveniences they might gain by doing so. <ixmpp>oh so that's where this stuff comes from <ixmpp>ok, well i reckon i'll still carry on with my plan <ixmpp>that i mentioned in #nonguix yesterday but i assume is illegal to mention here <roptat>katco, the keyboard wouldn't do anything to the serial console <danderson`>according to those guidelines, the unacceptable thing is encouraging people to install nonfree software. That seems very reasonable. I wish the policy were more "educate and redirect", e.g. "this is offtopic here, and see $doc for why you should try to prefer free software, but see #other-place if you want to continue down that path" <katco>roptat: i plugged one in so i could easily issue FN comands that don't conflict with my terminal program <katco>roptat: you can control what you see on the serial console by using hardware plugged into the machine <roptat>yeah, but the serial console is not one of the ttys, so it has no effect <roptat>what you see on screen is tty[1-7], but the serial is ttyS0 or something <roptat>ah maybe I've always had weird hardware, it hasn't been my experience <katco>at any rate, the install image behaves as i described. any ideas? <roptat>maybe it's booting linux, but not showing it on the serial? <roptat>I think last time I tried (that was with u-boot on an arm board), I had to add console= something to make it print to the serial port <katco>hrm. that seems possible... where did you add the console option? <roptat>I think it was a u-boot thing, but with grub, I'd try to add it as part of the linux arguments <roptat>try and see if you can stop grub from starting immediately, and edit the menu entry <katco>yeah i don't know if i can do that; it happens so quickly. this is just the standard install image from the website. i was trying to avoid building my own iso <roptat>I don't really know how to stop it from loading immediately, sorry <katco>well, at least you've given me an idea to pursue. thanks, roptat <ixmpp>guile reflection seems unreliable <ixmpp>i wanted to do something funky with module reflection to programmatically get my hosts like i do in nix <ixmpp>but it seems to really not be a good idea <ixmpp>modules resolve, but only sometimes? and are usually empty, but not always! <rekado_>ixmpp: if you can share what you’re doing perhaps we can help <rekado_>ixmpp: it’s certainly not unreliable <rekado_>“rekado” is fine, but “christ” will do in a pinch :) <rekado_>we’re using module lookups in Guix itself ***balbi` is now known as balbi_
<ixmpp>something along those lines. i then have (rc system delta) for my current system, and (rc system epsilon) for another, each exporting 'os <ixmpp>which is a function returning <operating-system> <ixmpp>that way i can add a file <hostname>.scm to rc/system/, and it should appear in (rc system) too <drakonis>rekado_: if possible, could you give me your thoughts on the discussion that took place an hour ago? <drakonis>regarding creating new channels for the repo <rekado_>drakonis: I’m not really firmly seated in front of the keyboard right now; maybe in two or three hours. <drakonis>collecting opinions for a guix-devel email <rekado_>I’d appreciate a link to whatever you want me to comment on; time’s in limited supply these days, unfortunately, so I won’t be able to read the whole backlog <rekado_>ixmpp: I’ll take a look later, thanks for the link ***thecatster is now known as thecatster_
<ixmpp>i have my config.scm as just `((@ (rc system delta) os)` now <ixmpp>but if i put that into a repl <ixmpp>"Module has no public interface" <roptat>doen't that mean it can't be found? <roptat>like, it's not in the search path? <ixmpp>it should be, it's in my channels, and shows up in guix describe <ixmpp>how odd. if i access something in another module first, it works fine <roptat>I guess I don't know guile well enough to understand that <ixmpp>hmm, yeah, if i ',m gnu' first, works fine, ha <katco>roptat: aha! if i'm fast, i can strike `c` which gives me an invisible `grub>` prompt from which i can enable serial console output. then i can edit the boot menu item to output to serial console, and i'm away. thank you! <roptat>I'm glad you found a solution :) <katco>well, it looks like it got me one step closer at least. i can see it booting, but that appears to freeze at some point too. <ixmpp>reflection only works for modules known to exist <thecatster_>When I try to save a hidden network with WPA2 Enterprise in `nm-connection-editor` it crashes, saying `Settings schema 'org.gnome.nm-applet.eap' is not installed .` What package is that? <ixmpp>you can't search for ones not already loaded somehow <thecatster_> * When I try to save a hidden network with WPA2 Enterprise in `nm-connection-editor` it crashes, saying `Settings schema 'org.gnome.nm-applet.eap' is not installed .` What package is that in Guix? <roptat>ixmpp, could it be rather that loading (gnu) runs some code that extends the GUILE_LOAD_PATH? <ixmpp>but even with ,gnu the submodule reflection thing is odd <roptat>so without it, GUILE_LOAD_PATH doesn't know about your module because it doesn't contain the channels, but loading (gnu) will extend the load path <roptat>I don't know, it seems to work relatively well for me <roptat>although I'm not trying with your modules <roptat>actually no, it doesn't seem to work as expected... but it's not documented either in the guix manual <roptat>so maybe it's just not what we think it is <ixmpp>i think i'll just do this the easy non-magical way <roptat>I guess you'd have more luck on #guile <ixmpp>xmpp:#guile%irc.libera.chat@irc.hmm.st <civodul>drakonis: this project builds upon and focuses on software that guarantees user freedom <civodul>but Guix as a project does not develop packages for non-free software <civodul>i mean, everyone can choose to use non-free software, it's just that it's not what this project is about <civodul>so usually people kindly explain that and that's it, i think <civodul>we should make it so that people don't feel unwelcome at any rate <ixmpp>does guix store links to the current channel repo checkouts somewhere? <civodul>ixmpp: checkouts are kept under ~/.cache/guix/checkouts, but for "internal use" only <ixmpp>would be nicer if they were in the store too <civodul>well it ends up in the store, too, at some point <ixmpp>oh, but that's fine. i was just hoping for a way to get at those programmatically so i can link them out via /run/current-system or something <civodul>the (guix git) module provides the API to deal with that <ixmpp>e.g. in nixos i had each of my flake inputs mapped to /run/current-system/flake/inputs/<input name> <civodul>also, note that all your channel instances end up in ~/.config/guix/current/ by default <civodul>you can use 'guix edit' to view package definitions <civodul>that's one way to peek at your channel contents <ixmpp>they get merged into share/guile <ixmpp>that's ...probably better, actually <drakonis>civodul: i understand the stance but i dont represent everyone <ixmpp>drakonis: so i'm trying the channels architecture. one immediately annoying thing: i can't iterate on my config without doing a guix pull each time <ixmpp>civodul: i'm complaining. but my rationalisation of the state of affairs is that guix applies the same level of filtering to people as it applies to packages, i.e. it actively discourages people who aren't already heavy on the freedom bandwagon <ixmpp>i also assume that's unlikely to ever change <danderson`>yeah, that. As someone who has to deal with the reality of needing non-free software, the responses I've seen here said to me "we don't want you in our community" - as polite as some of them were. <roptat>well, you can always use guix on a foreign distro, that doesn't require guix to provide non free firmware <danderson`>If that's indeed the goal, then working as intended, no problems. <roptat>I don't think we can blame people for needing/wanting non free software, we can only blame the people who are advocating for them (your school/university/employer/laptop vendor...) <ixmpp>im quite curious how emacs, being also a gnu project, ended up so much more lax about this all <danderson`>So I gather. I'm describing how it came across when I first lurked here. <ixmpp>(i spend a lot of time in #emacs) <roptat>danderson`, and I get that it can come across like that, but I'm not sure how to address the issue... <vagrantc>i remember when i first came to guix and found it surprisingly easier than some distros to enable installing *whatever* software you wanted through making custom package definitions <danderson`>I can only speak for myself, but modifying "we won't help you, but someone else might" to "here's where to go for your question" would be a big improvement <danderson`>(i.e. being allowed to mention the non-free guix source that must not be named) <roptat>not sure that's a solution, that's really the same as advocating for nonfree software <vagrantc>danderson`: but i think that's the crux of the problem <vagrantc>you can't both direct people to it, and not direct people to it at the same time <roptat>I think the issue is this "we won't help you" <danderson`>roptat: I don't think it is - or rather, it depends on how you phrase it. "yes! Go here for your proprietary things, which we encourage!" vs. "non-free software is offtopic here and we don't encourage its use, but #other-chan might be able to help you" <danderson`>I guess it comes down to whether pointing in a direction counts as an endorsement <roptat>if it's a policy to redirect people to #otherchan, then it's an endorsement <danderson`>as I said earlier: empirically, even though the response on-channel is "we won't help you", that seems to be paired with a /query pointing people to the other place anyway <danderson`>so, in practice, #guix _is_ directing people to non-free software, just doing so secretly. <roptat>which is not great either, maybe we should have a policy for these questions <ixmpp>so in essence, i was right, you want people to not even go to that channel, which *does* cut out the majority of your potential users and scares off a good many of the rest <danderson`>I think it'd be better to turn that into something that can be said publicly, because it then lets #guix control that message as it pleases (e.g. pair it with links to education about free software, sites listing libre alternatives to popular software, etc.) <vagrantc>i've found how guix handles this issue to be very interesting, coming from Debian where there's a formal place for those non-free bits <vagrantc>well, formally informal, which has it's own weirdness <dstolfa>i wonder if the right thing to do is just point people to the documentation on how to specify their own packages for any of their needs? another potential solution to this is to simply get appimages working easily through a service, and then telling people they could use appimages for anything they desire? <roptat>danderson`, well, users are free to go to that channel, but we don't want to point them to it <dstolfa>that way you don't redirect people or endorse anything <vagrantc>but technically i find guix makes it relatively easy to package anything, and channels makes it easy for people to share what packages they find interesting <danderson`>roptat: then, frankly, I don't see how to improve the image that #guix projects. The current response is as good as you can do if you refuse to be specific. <danderson`>(i.e. "no, but you can specify other sources/build rules as you please" - which is carefully omitting the fact that people have already done all that work) <ixmpp>i just come from emacs, where there's still a clear separation and nonfree stuff is shunned to all hell, but ..not like this <dstolfa>given that emacs is a project dear to GNU, it might be a good example? <roptat>yeah, maybe the best answer would be something like that... "we focus on free software and don't have any non-free software, but we won't prevent you from packaging your own stuff if you want to" <vagrantc>emacs may also predate some of the policies around these sorts of issues <dstolfa>roptat: one could also say separately that users are encouraged to share their own work in separate repositories that others can find <dstolfa>and then one could go off and search for said repositories <dstolfa>doesn't redirect or endorse anything and simply states facts of guix <dstolfa>and then if someone comes in and asks about using mainline linux for non-free firmware, you can simply point them to that and follow it: "other people may have done the work already, maybe you should look into it" <ix>dstolfa: they have the dedicated free repo, for all gnu-advocated fully-free stuff. it's a bit small, but it's got all the general stuff that's fully signed off on. you can add other repos (marmalade, melpa) that contain also nonfree stuff, it's not a secret, it's discouraged, but it's well known and doable for those who want to <ix>and in the irc channel, there are no rules against speaking about nonfree stuff <ix>(honestly i was surprised how lax they are about that, they went the complete opposite direction of this place) <roptat>but emacs doesn't follow the fsdg, it's not a distro (yet? :p) <ix>you're clearly not a vim user <ix>something something emacs is an operating system <iskarian>is the idea that by not making it easy for people to rely on the non-free options, it will be more likely that people will develop free alternatives? <civodul>ixmpp: surely there are people who prefer distros that come with non-free software, if that's what you mean by "filtering" <civodul>it's just that it's not what Guix is about <roptat>iskarian, I don't think so. To me the fsdg is making a moral point that you shouldn't advocate for non-free software, not that it's immoral or a goal that people stop using non-free software <danderson`>reading the FSDG, I don't think "don't advocate for nonfree software" means "refuse to point to it at all". Other communities I'm in say something like "there's this other thing, but use at your own risk, no warranty, help or endorsement from us" <civodul>we all make personal choices, no judgment here <danderson`>You can point at non-free software without encouraging its use, IMO. Although I understand that we're now getting into details of personal conviction. <civodul>into details of what "encouraging" means, too :-) <civodul>and again, it's not so much "personal conviction", but rather about setting a direction for the project IMO <civodul>we're a bunch of humans coming together and pouring time and energy into something <danderson`>yeah. I see it as roughly 3 points on a spectrum: "you can do it but we won't tell you how", "here's where to go, but we don't encourage or endorse it", and "yes, we support and love nonfree software!!1" <danderson`>I see a distinction between the latter two, and I think that's where some folks here disagree? <iskarian>"<danderson`> ... pair it with links to education about free software ..." might be more the way to go then? IME people are more likely to change their moral stance based on education than being "forced" to <roptat>iskarian, again the "moral" thing is on us, not on users <civodul>nobody's being forced or even judged <danderson`>and again, to be clear: I'm new around here and barely starting to use guix. "Guix isn't for you, you're at odds with our community values" is a perfectly fine answer as well. I don't want to walk in and demand that people change their convictions. <civodul>danderson`: is that the message you got? that you're unwelcome? <danderson`>civodul: yes. Although that's been modified since then, but my initial impression was "wow, better not admit how I use computers here" <ixmpp>> it's just that it's not what Guix is about <ixmpp>thats fine. Thats a shame, cause i love free software, but i also have things i cant otherwise avoid, so if i followed that principle, i shouldnt even be using guix. Thats what i mean by filtering users. And people who witness such a thing, wont be encouraged to join this commuity either, hence scared off <civodul>ixmpp: by that i meant Guix as a project, not Guix the software <civodul>Guix-the-tool can install non-free and even private software, it won't judge you, really :-) <danderson`>I'm glad that something like guix exists, and tries really hard to work with only free software. I want to be in that world (e.g. when I built my latest desktop, I specifically picked radeon over nvidia because of the OSS drivers), but in practice, my OS can only be 99% libre and still do what I need. <roptat>except maybe it won't have a license to show when you print the package info :p <ixmpp>So we should then make a channel for guix-the-tool >_> <roptat>that's already what we have in the main repo <roptat>but it would still depend on the guix project, so the policy would be the same <danderson`>anyway, as I said, it feels weird to show up and demand changes right out the gate. Hopefully my early experience with #guix is helpful in figuring out how to be more welcoming and grow the guix community the way y'all want it to grow :). On that note, back to work for me, so I can have time later to poke more at guix as a user. <civodul>danderson`, ixmpp: it's okay if you need non-free software, really; my recommendation is to meet the communities who actually work on this aspect <civodul>you'll find that #guix folks can support you on some things and other communities will help you on these non-free software issue <civodul>that doesn't mean you're unwelcome here <danderson`>civodul: which is what I did, after being privately messaged re: where to find them, because #guix wouldn't say :( <vagrantc>also, various different people in #guix may have different degrees of tact regarding how to relay the message <danderson`>I understand why that's the current position. It's still weird as a newcomer. <vagrantc>admittedly, i specifically am drawn to guix because of it's commitment to free software :) <civodul>perhaps i/we should read the backlog to better understand how the reply you initially got made you feel unwelcome <dstolfa>vagrantc: that's what attracts me to it as well actually, it was the combination of 100% free software and the ability to hack on it without any use of proprietary software or platforms <civodul>perhaps we can learn from fellow Debian folks, too *civodul looks around :-) <dstolfa>but yes, it is absolutely undesirable that someone feels like they're being looked down upon if they need to use some non-free software <danderson`>civodul: I have a couple snippets from my logs that are the interactions I remember here, if that helps. Not posting it widely, since that'd be pointless drama and fingerpointing, but if you want examples, I have them. <PurpleSym>Does that mean we can finally mention nonguix here when someone asks and not refer to obscure “other communities”? <danderson`>And maybe reading them your conclusion is that I was wrong to feel weird about them, and that'd be fine. <vagrantc>well, nobody can dictate how you feel :) <civodul>danderson`: you can PM me the links to the log, if you want <danderson`>vagrantc: sure, but as a newcomer to a community, misinterpreting things can happen. And if that's the case, well, TIL :) <roptat>at least, we haven't reached any conclusion, have we? <vagrantc>debian's take on free software is a bit of a weak stance, in my opinion ... basically, it proclaims all of debian is free software, and it provides repositories for contrib (things that depend on non-free toolchains) and non-free (e.g. freely redistributable but not free in various other ways) <PurpleSym>roptat: I was hoping civodul’s +1 implied that ;) <danderson`>(for example, my first impression of being unwelcome is clearly wrong) <vagrantc>but Debian basically declares that contrib and non-free are not part of debian <dstolfa>vagrantc: yeah i was never personally a fan of how that whole thing plays out in debian <dstolfa>danderson`: i still think this is really useful feedback <roptat>PurpleSym, I interpreted the +1 as "newcomers should not feel unwelcome because they use nonfree software", not "we should point them to non-free channels" <vagrantc>dstolfa: it was a pragmatic compromise struck decades ago :) <roptat>but really I still don't know how to react properly when someone asks how to use a proprietary driver for instance <PurpleSym>roptat: Probably true. It’s just really awkward to randomly PM people the forbidden stuff. <dstolfa>roptat: i think it's worth just saying that guix allows one to specify their own channels, package their own software and share their work with others, explain that using non-free software breaks any guarantees guix might give you and is strongly discouraged, and maybe explain that someone might have done the work already and they can look into it? <vagrantc>if we had a "standard message" maybe someone could teach sneek to relay that message with a command or something ? <vagrantc>that way we don't get caught up in a bunch of improvised spur-of-the-moment personal takes on the issue <roptat>yeah, a "standard message" would be very helpful <vagrantc>and it can be refined and improved over time with feedback ... <iskarian>I think maybe going more the way of "we focus on Free software here (and here's why: <>)" over "using guix with nonsoftware is strongly discouraged" might be more welcoming? <roptat>yeah, "strongly discouraged" is maybe not very welcoming <roptat>let's focus on the positive rather than the negative :) <dstolfa>iskarian: yeah i don't have a strong opinion on the wording, it was just an initial take on the idea. i agree that your changes are likely much better :) <iskarian>dstolfa, it's not your specific wording, but I feel like the "strongly discouraged" vibe is more the norm, which is why i called it out *vagrantc notices vagrantc starting to say "we" when referring to guix more and more and doesn't quite know when that happened :) <vagrantc>parens aside, i pretty much was thrilled with guix from the get-go <civodul>i was thrilled when i watched your DebConf talk back then! <civodul>it felt like there was a possibility for mutual understanding between these two communities <danderson`>oh right, you had a talk I was told I should watch <vagrantc>i've always been impressed by how generally welcoming guix is (the trickiness with non-free stuff aside) ... definitely more consistently welcoming than debian ever was <roptat>guest-with-quest, which modules? the ones from guix (like (guix licenses)) or the ones you created ((my-hello) in the example)? <guest-with-quest>Trying to test an updated package for fossil-scm, pretty much copied from the guix channel repository with an updated version. <vagrantc>i suspect coming out of an era in which at least some thought was put into codes of conduct is part of it ... gently and caringly setting boundaries without being too harsh about it <dstolfa>vagrantc: that's been my experience too. i've interacted with a good amount of communities and guix from day one felt very approachable <roptat>the name of the module should be the name as the path to the file, relative to $GUIX_PACKAGE_PATH (which is not recommended anymore btw, we should update the cookbook) <roptat>so if you have a file like $GUIX_PACKAGE_PATH/my/modules/myfoo.scm, the module name should be (my modules myfoo) ***colemickens[m] is now known as colemickens
<roptat>that's what you'd call it in the (define-module ...) form <roptat>hope that makes sense, need to go, but others will be able to help I'm sure! good luck! <roptat>so if GUIX_PACKAGE_PATH=$HOME/MyPackages, your module should be called (fossil) <roptat>and you get an error saying (fossil) is not found? <guest-with-quest>I have that but I have some extra modules like "#:use-module (guix package tls)" for the dependencies <roptat>it's (guix packages tls) (note the plural) <roptat>I really need to go now, see you! <mitzman>is there a possibility, instead of specifying (replacement ...) to let a package be replaced, to use something like (replaces ...)? <mitzman>seems natural to specify (replaces ...) in case of own patches <civodul>mitzman: you mean you'd like to specify replacement the other way around, right? <civodul>that's not possible right now, and i would find it awkward (how would Guix know that a package needs to be replaced?) <ss2>hey civodul; I just tried it again to reconfigure with this weird commit that I posted the other day. <mitzman>that is true, the only way I see it happening is a symlink but i don't know how well it would work in practice. i'll try the guix build --with-graft=a=a-r a <ss2>the system didn't switch this time. :/ I wonder how I came up to claim that it did go through. <civodul>ss2: oh ok; i've been meaning to redo the experiment but in a VM rather than on my laptop :-) <civodul>also i really have no idea how the backtrace and the commit relate to one another <ss2>yeah, I haven't pushed this into a VM either. <ss2>have you managed to reproduce it yet? <civodul>i guess i should set up a VM, pull that commit, and reconfigure ***xgqtd_ is now known as xgqtd
***xgqtd is now known as xgqt
***rekado_ is now known as rekado
<bauermann>hello! I'm interested in helping get core-updates ready for merge. I looked at https://ci.guix.gnu.org/jobset/core-updates and saw that texlive-latex-amsmath was failing to build in the latest job. But when I tried it locally, it worked. is there something else I can do? <civodul>perhaps you can reproduce it with --check <civodul>great that you're helping on core-updates anyway, we need to get it off the ground! <bauermann>well, I want to. let's see if I can actually manage it. :-) ***xgqtd is now known as xgqt
<bauermann>you're right, texlive-latex-amsmath is indeed affected by bug 48064. I just had a build error with luatex failing with signal 6 and the `realloc(): invalid next size` message. <bauermann>it's not so easy to reproduce though, most builds pass. I was able to hit it when I used `guix build --check --rounds=10 texlive-latex-amsmath` <bauermann>now let me look into this signal 6 (SIGABRT) problem