IRC channel logs

2025-08-11.log

back to list of logs

<lfam>'owdy
<lfam>Does anyone know a tool that I can use to search for files that contain a lot of entropy. That is, to search for binary blobs?
<lfam>I packaged up this entropy scanning tool: https://paste.debian.net/1390790/
<ynzoqn>Is advent of code day 14 part 2 (find christmas tree) related to entropy scanning?
<lfam>ynzoqn: No, I was trying to scan for blobs in a Guix package
<lfam>I mean, maybe advent of code is related too, I haven't checked.
<sham1>I wouldn't put it past Topaz to be honest
<sneek>ekaitz: wb!!
<ekaitz>sneek: botsnack
<sneek>:)
<ekaitz>hi all
<andreas-e>Hello!
<efraim>o/
<apteryx>I just noticed about: https://codeberg.org/guix/guix/commit/f361e7fa4af8190701cb5326b4b046cdb5c91a12; I'm not sure about retrying tests by default. I'd rather catch the non-reproducibilities and report them upstream.
<efraim>I would definately rather rerun the tests again. I had been thinking about for years rerunning the tests without parallel-tests if they failed the first time
<andreas-e>Could it be set to #f by default, and then be a stop-gap measure to make builds pass? We already have a certain practice of just disabling failing tests, in particular on everything that is not x86_64, because often upstream does not seem to care enough for quality code.
<tetris11>Hi Room, I searched through the logs but couldn't seem to find an answer to my queries. Three parter: 1. Does anyone know what the status of guix producing static builds is? (e.g. harder than just adding a few flags to every C recipe at build time, or plans to have a seperate set of package recipes for it, or none at all, or..?) 2. I quite like
<tetris11>relocatable binaries with guix pack being an option, but any update on when the --target flag will work with it? 3. Is there a tool that can rewrite all the /gnu/store/xyz prefixes in a pack to a local dir, which could then be deployed anywhere as a tarball? Sorry for the long text
<dcunit3d>... um there's no keyring branch?
<ieure>dcunit3d, In what context? There definitely is. https://codeberg.org/guix/guix/src/branch/keyring
<dcunit3d>i'm having to run a bunch of software that's tough to pkg, so i'm trying nix and i'm just surprised how different they were. i tried it a long time ago. the users i've encountered are all about flakes (and most of the code/repos). except a lot of the more core/infra devs.
<dcunit3d>I'm not really trying to perpetrate though
<dcunit3d>in slang terms
<dcunit3d>i feel like the channels approach leads to more consistent reproducibility and consolidates the infrastructure required, but i don't have the experience to know in depth
<dcunit3d>i've kept my emacs on guix, but there are some problems updating the guix channels if you use services.guix.enable to configure it on nix. there's some problem with how it links profiles so `guix pull` ends up finding links that already exist. it's a combination of a few things, but i'm not sure.
<dcunit3d>i used their package to boot up the store (some of which ends up in /nix/store before bootstrapping /gnu/store). so if you do that and pull, it takes forever bc for some reason it doesn't recognize any of the git history (it pulls like 100,000 commits or something)
<dcunit3d>i need to submit an issue for it. i figured out a workaround though.
<dcunit3d>i probably should've just used the guix installer. however, the nix services to automatting manage guix daemon, builds, channels, subs and gc seem to require sourcing the executable from a nix package. i'm pretty sure that it would fail if i disabled that. without those settings, setting up guix is difficult on a reproducible system =/
<jherm>Hi, I've just installed Guix. I have an RX 5700 XT GPU, I noticed in some places amdgpu driver is blacklisted (installer kernel cmdline), is it usable without nonguix?
<jherm>I tried to use my nvidia card in slot closest to the CPU, which kind of worked, except I could barely read any text in GNOME. There was a yellow tint to the entire screen. So I updated, and then completely lost access to anything graphical...
<identity>jherm: it should work fine without nonguix from what i know
<jherm>Thanks
<jherm>Is imperative installation of packages the recommend way? If I want to replicate my configuration on another system, am I better off adding packages to config.scm instead?
<jherm>I'm coming from NixOS, where imperative installation is generally not recommended.
<dcunit3d>jherm: it depends on the contexts in which you want to access packages
<dcunit3d>but i would recommend against using the basic `guix install` without profiles
<dcunit3d>jherm you can use `guix gc --list-roots | sort | uniq | tree -a --fromfile .` to get a feel for where the roots are (the uniq is redundant)
<dcunit3d>i'm just now getting into learning nix and expected that it would be organized similarly, but it's quite different
<jherm>Ah, OK, there's `guix shell foo` for temporary environments. That's mostly what I need.
<jherm>dcunit3d I'm just getting into guix and I had the same expectation, same
<dcunit3d>jherm you may want to look into this discussion https://forum.systemcrafters.net/t/using-make-to-manage-guix-home-and-system-profiles/307 and this one on codeberg https://codeberg.org/guix/guix/issues/431
<dcunit3d>where users are discussing how to use make to lock & update a set of channels for a project. the manifest ends up being a little bit like a flake. channels are also somewhat different than in nix. they're easier to lock (which is what I'm trying to figure out in Nix currently)
<dcunit3d>but with guix you need to create a profile to get a GC root.
<jherm>Thanks, it's helpful. In Nix, you either update channel data through nix-channel command, or use flakes with `nix flake update`. I think you can update one input at a time if you want to be more granular
<dcunit3d>the makefile stuff can help but if you're not used to it, it may be a distraction
<jherm>I probably will avoid using Make but the commands are helpful, worst case I'll add them as shell aliases
<dcunit3d>to manage sets of packages, the cookbook discusses GUIX_EXTRA_PROFILES. if you use guix-home, that's easier. GUIX_EXTRA_PROFILES needs to load in .profile separately or these can be loaded by direnv as needed. eventually you'd want a service to help manage loading them https://guix.gnu.org/cookbook/en/guix-cookbook.html#Guix-Profiles-in-Practice
<dcunit3d>** to help manage updating them.
<dcunit3d>loading .guix-extra-profiles requires thinking about load order and the package dependency graph. i keep a GC root for my emacs and i used to have one for texlive/etc. but this could cause issues
<dcunit3d>when you get to learning about guile scheme, you'll want to read chapters 3 & 4 of the manual. it covers the load path, the expression syntax -e '(@@ (some module packages) a-private-package)' and things like~/.guile, which if you change can cause some issues.
<dcunit3d>anyways i gotta get back to work
<jherm>Is it normal for init to segfault on boot? The system still boots fine...
<jherm>[    0.537217] init[1]: segfault at 3fff00 ip 00000000004d4953 sp 00007ffd9e987c00 error 4 in guile[d4953,401000+201000] likely on CPU 20 (core 36, socket 0)
<jherm>[    0.537260] Code: 8b 05 d1 ec 34 00 48 83 c4 28 c3 0f 1f 40 00 48 8b 05 c1 ec 34 00 48 2d 00 01 00 00 48 89 05 b4 ec 34 00 48 8b 05 ad ec 34 00 <0f> b6 38 e8 65 a5 ff ff 48 8b 44 24 08 48 8b 15 99 ec 34 00 48 05
<jherm>Of course it's not normal, I'm just surprised to see that when booting up :p
<Deltafire>Its the New Normal
<jherm>I guess I'm just holding it wrong
<dcunit3d>interesting. are you running on x86? i think "error 4" generically refers to reading unmapped memory (according to this anyways idk) https://utcc.utoronto.ca/~cks/space/blog/linux/KernelSegfaultErrorCodes
<jherm>Yes, x86.
<dcunit3d>i think it's failing at memory access https://shell-storm.org/online/Online-Assembler-and-Disassembler/?opcodes=8b05d1ec34004883c428c30f1f4000488b05c1ec3400482d00010000488905b4ec3400488b05adec34000fb638e865a5ffff488b442408488b1599ec34004805&arch=x86-32&endianness=little&baddr=0x003fff00&dis_with_addr=True&dis_with_raw=True&dis_with_ins=True#disassembly
<jherm>er, well, x86_64
<dcunit3d>yeh but i think it's still running 32b code? it shows pid1 i think
<dcunit3d>i've always kinda wanted to learn more about that
<Deltafire>i wonder what line of source code corresponds to guile[d4953,401000+201000]
<Deltafire>i get that error too btw, and a few others have also mentioned it
<Deltafire>like i said, it's the new normal..
<ieure>The GNU/Normal
<Deltafire>hehe