IRC channel logs
2026-10-22.log
back to list of logs
<dlowe>uh, ci.guix.gnu.org isn't in php by any chance is it? <ieure>dlowe, I don't think so, it's just unreliable. <sham1>TBF ci/berlin being unstable could be literally anything else <ieure>We might be running nginx, which had a bunch of vulns this week, too. <ieure>It's been a really, really terrible week for internet security. <dlowe>ACTION weighs pros/cons of just building php. <ieure>Build it into a containment vessel like the Fukushima reactors. <dlowe>it's a shame there's no trustworthy way to shard this out to volunteer systems <dlowe>looks like building it was the right call, but at least it was easy :D <complicatetmess>Hi, how is the i686 support currently for gnu guix? I have 2 T43 which I would like to install and tinker around with. <ste5e>complicatetmess: it's roughly fine, I have an S10e with Guix. Not a whole lot installed on it currently. Happy to answer questions in private. <mra>didn't know that you run on ZFS now <mra>I've been trying to install on top of ZFS for a while, but unfortunately without much luck <gnufairy>Sometimes on GNU Guix System when I try and run guix pull or doas guix system reconfigure (after a guix pull), I run into a git error: SSL error : syscall failure : Reasource Temporarily unavaliable. <gnufairy>What can I do about this other than wait <kaelyn>mra: I use ZFS as well, but with a lot of hacks in a local channel to get ZFS working as my root fs. <hako>dlowe: test failure due to file system difference is a common packaging issue <mra>kaelyn: yeah! I was hoping to use hako's contributions, but unfortunately the installation image seems to not work on my PC for no especially obvious reason <untrusem>hako: would disabling those two tests work? <hako>untrusem: I think it's because of the utf8only=on property, ZFS has many configurable options and they may affect reproducibility. I'll mention this property in the ZFS PR as well. <mra>btw hako, both the niri and the minimal Rosenthal live ISOs that you provide segfault when booted into on my PC. I'm going to try with the official Guix system ISO to see if there's a problem with them too <olivial>hmm... so I'm trying to package something with a transitive dependency that vendors minified plotly.js javascript. I see that there are a few packages in guix already with a similar problem, where they are pulling "bundled" js artifacts out of the plotly repo and then minifying them (eg r-iheatmapr) <olivial>that seems not optimal, it's moving from a vendored artifact in a dependent repo to a build artifact checked into the upstream repo <olivial>however, actually building plotly.js from source looks like it would be quite involved. there are a whole bunch of npm dependencies <untrusem>mra: I don't think official iso will work, if you use the installer, might need to do manually <olivial>so, how reasonable would it be for me to just do the same thing that r-iheatmapr is doing? <olivial>(I am planning to submit this package to guix) <untrusem>olivial: jlicht will be able to give input on thin <mra>untrusem: I'm actually having a baffling issue. so I am able to boot the installer, but looking through the kernel logs, I see a line that reads "init[1]: segfault at 3fff00," which is the same segfault that I was having when trying to use hako's images <mra>but in the official installer, it seems to just keep booting in spite of this segfault? <mra>whereas the installer provided by hako seems to hang when it encounters this <mra>untrusem: yeah, I have seen a few ZFS configurations, but I'm stuck on the installation phase, not the configuration phase <jlicht>AFAIK I have the/a workaround for brotli vulnerabilities on the javascript-team branch; could someone cherry pick to master, after verifying? <jlicht>no clue why folks reported the vuln for Node.js instead if *the universe*, but here we are xD <jlicht>I won't be able to today due to a sick child that that needs my attention for the day <jlicht>Firefox (and co) may or may not have a vendorred copy too <jlicht>untrusem: I pushed brotli-affecting-node to javascript-team; I just worry that the brotli issue could also impact more dependents of brotli. (which needs verification) <efraim>Do we have the CVE number for the certificate issue? I want to reference it in some commits <efraim>untrusem: Thanks. I ended up using the RUSTSEC number <efraim>now I'm trying to figure out how to use modify-inputs in rust-crates to create a mapping of replacements so we can use grafting to rebuild rust packages in a semi-automated way <gerogaga>Hi. For package definitions, is the github-generated source tarball or a git-reference preferred? <amrit_>Are there any cool guix or guile projects to check out? <stampede_>for service configuration, is `define-record-type*` preferred or `define-configuration`? <stampede_>amrit_: the spritely institute has some cool stuff, like Hoot, which is a scheme->wasm compiler written in guile. Allows you to make websites with scheme. <stampede_>beside that, i'm not really well versed in the guile ecosystem <amrit_>That sounds neat, I'll check it out <cnx>stampede_, define-configuration is better as type checking will be done at reconfig time <efraim>I seem to have figured out adjusting the packages, bad news is I'm back to some manual dependency resolution as the cost of trying to just replace the vulnerable versions of packages <efraim>* for using newer versions of rust crates for grafting <old>it's me or the first page of Guix PR is just monopolize by a big slop update <old>this is a problem. If a single user can literally pollute the PR that way, imagine with 10. Do we have budget to buy vertical monitors? <ieure>You can turn any monitor vertical. <ieure>old, Not sure what you mean by "big slop update," the PRs look fairly normal to me. <ieure>Lot of package bumps from one user, but that's not atypical. <Heterochromium>My curl is still resolving the compromised eMudhra certificates. Does anyone know how to fix that?