IRC channel logs


back to list of logs

<wdkrnls>Dear Guix, is there a concept of breaking out to a jitsi channel for support?
<wdkrnls>I feel like being in "Monkey see monkey do" mode would really help me move pass some blocks.
<wdkrnls>(conceptual blocks)
<wdkrnls>I guess I just dream about having a science cafe in English.
<mirai>Ugh, I've underestimated the effort to clean the old-style services from guix
<sneek>vagrantc: Greetings!
<ellysone[m]>also does anyone knows how to output colors on the terminal from a regular guile program?
<lechner>ellysone[m] / regular terminal escape sequences do not work?
<mirai>lechner: did you report the issue of the non-guix managed mounts hanging the shutdown sequence?
<lechner>mirai / i didn't. that's your baby. is it not just the networked ones?
<mirai>I think it affects any mount that depends on "something"
<mirai>the something being anything that herd shuts down
<mirai>it sounds like a init/shepherd bug to me
<mirai>it shouldn't hang the shutdown/reboot sequence
<lechner>okay, do we have any other report of that happening? i have used NFS for over ten years, and often had related issues, so it would be nice to confirm your hypothesis, if it is still unconfirmed.
<mirai>apteryx experiences something similar
<mirai>but in either case, shepherd shouldn't be hanging itself during the shutdown, no matter the case
<lechner>it's not shepherd. it's the kernel
<mirai>it simply makes rebooting or shutting down impossible
<mirai>without a manual power-cycle
<lechner>it's a blocking syscall
<mirai>it could be the kernel or some other component but it matters little
<mirai>this is a real bug in some component
<mirai>we should be able to have the system shutdown, either nicely or forcefully after some grace period
<acrow>Hello everyone, I've just refreshed one of my guix systems. eg.. guix pull && guix package -u && sudo guix system reconfigure <config.scm> do I also need to run guix home reconfigure <home-config>? Doesn't package -u get things up to date? I'm wondering how to verify this.
<iyzsong>you need do 'guix home reconfigure' too, guix package only operate on ~/.guix-profile
<apteryx>rekado: oh! interesting; I didn't factor that "limitation" in; the one that 'guix pull' bootstraps itself from the existing guile, which can be arbitrary old
<apteryx>so I guess I should remove raise-exception and add (srfi srfi-35) (or 34, can never remember)
<crepe-suzette>"SRFI 35: Conditions"
<apteryx>and use just the overloaded 'exception'
<acrow>iyzsong: Thank you. When the configs have not changed it's a long dance.
<acrow>following the home reconfig is there a herd restart to allow me to avoid another reboot?
<bjc>many services should restart themselves, but for the ones that don't, a relog should suffice
<bjc>everything you install via home won't need root, so i can't think of what would need a reboot
<osvarcha65>Hello someone from here I managed to configure Qemu with KVM to use it as a normal user, I am trying to run virt-manager qemu/kvm but it tells me that it is not available only when I am with "superuser" kvm is enabled for me.
<nckx>ACTION → 😴💤, but are you in the "kvm" user group?
<acrow>bjc: Thanks, that makes sense.
<osvarcha65>If you already change the user group of /dev/kvm and restart the service with herd restart libvirtd but the same thing, in addition to each restart the user group of /dev/kvm is lost
<unmatched-paren>hello guix :)
<mekeor[m]>hi :)
<Kolev>How do I install Guix packages with Ansible?
<AwesomeAdam54321>Kolev: Can Ansible run commands? If so, you can instruct it to run guix install -m manifest.scm
<nckx>osvarcha: That is expected. /dev is temporary, not persistent.
<AwesomeAdam54321>sorry, I meant guix package -m manifest.scm
<abrenon>hey guix
<qzdlns[m]>keep bungling a fresh install of guixSD; using grub-efi-bootloader with an encrypted root (using pbkdf2), but on booting, grub seemingly doesn't have cryptodisk module available, and can't insmod it either -- grub sees all devices as ~filesystem unknown~; don't wish to be a help-vampire with these sparse details, but does this ring a bell for anyone?
<qzdlns[m]>never had the same trouble on 2 other guixSD machines (thinkpad, xps), and I'm thinking maybe uefi just isn't the move here, so will try the init again targeting a legacy bios
<elevenkb>Hey y'all's i'm trying to set up a substitute server, and I'm almost done.
<elevenkb>I'm using `guix publish`
<elevenkb>the issue is that I have to specify the port manually for example.
<elevenkb>is there any way to get rid of the port number.
<ngz>Hello. Is it me or hasn't been refreshed recently?
<elevenkb>ah i see i would have to use `httpd` or similar.
<elevenkb>too lazy.
<andreas-e>ngz: is from 9 hours ago. The next patch from 5 hours ago is not yet there. So it depends on your definition of "recent".
<crepe-suzette>"[PATCH] gnu: lightning: Update to 2.2.1"
<andreas-e>Notice that the patches are from oldest to newest in their respective colour group.
<jpoiret>qzdlns[m]: this is a known issue
<jpoiret>the next grub release should fix that, but in the meantime you can either put your /boot on an unencrypted partition, or use luks1
<jpoiret>i personally put my /boot on the efi partition itself
<jpoiret> should track the upstream patches
<crepe-suzette>"[PATCH 0/4] LUKS1/2 testing in fs-tester and LUKS2 support in grub-probe"
<qzdlns[m]>jpoiret: thanks for the heads-up! with luks1 I'm assuming I can still do `guix system init` with my encrypted root on /mnt and /boot on /mnt/boot, or should I put boot to /boot? will read the threads, go with the gut and see what goes bang -- thanks again
<ngz>andreas-e: You're right. I was under the impression that something was wrong.
<ngz>andreas-e: It may be the order in which the patches are picked up that surprises me.
<jpoiret>qzdlns[m]: it's one or the other, you don't need to do both
<jpoiret>note that you can (iirc) upgrade from luks1 to luks2 in place
<andreas-e>I suppose reviewers are enticed to look at the oldest patches first!
<qzdlns[m]>jpoiret: good to know re:luks, and will be sure to only mount /boot one time haha
<jpoiret>the thread is mostly just patches, it's not tracking the bug itself. Basically grub-probe dosen't have support for luks2 so doesn't know it should embed the cryptodisk module as well as the ciphers in the grub image, and since the /boot is encrypted it can't just read from there
<ngz>andreas-e: I always struggle against enticement ;) Anyway, oldest patches are either complicated, or waiting for an answer, so there is not much to do with them.
<jpoiret>so, GRUB claims to support luks2, but that support is only having the cryptodisk module understand luks2, a lot was missing
<qzdlns[m]>ah right, i thought it was suspicious that the crypto modules were pared, but working mostly in userland I'm just sat here blinking at my bootloader in confusion
<qzdlns[m]>yeah I saw from the patches that basic support is missing for v2 uuids
<qzdlns[m]>so pretty wild to claim support for v2, all told
<qzdlns[m]>thanks for the guidance, will crack on with the journey!
<efraim>sneek: later tell futurile we now have a rust-team branch, feel free to check it out
<efraim>sneek: botsnack
<sneek>Welcome back efraim :)
<AwesomeAdam54321>sneek: botsnack
<graywolf>How does guix system init work? Which version of guix does it install? I boot up the 1.4.0 install disk, guix pull and run guix system init config.scm /mnt/install. During that I see new-style progress bars. guix --version also claims I'm using a new guix (c81d2d448c...). However when I reboot into the newly installed system, I see 1.4.0-3.d5fece6 as guix --version. Why? I would expect it would
<graywolf>install the c81... version.
<AwesomeAdam54321>graywolf: guix system init uses the guix its invoked with
<graywolf>AwesomeAdam54321: well during the guix system init I see the new-style progress bars, so I am pretty sure it uses the new one
<jpoiret>graywolf: guix system init simply instantiates your guix configuration. The system-wide guix that's installed by guix configurations comes from the guix package, and not from the usual `guix pull` mechanism, and that package is updated irregularly (usually only when changes affect installs)
<jpoiret>the installer image overrides the default <guix-configuration> to point to (current-guix), which basically re-builds guix from its own running version. It's a bit of a hack tbh
<jpoiret>this is so the guix present on the install image is the same as the one used to produce it, but that doesn't extend to the new system install produced by the installer
<jpoiret>(in the past, important changes to guix required two updates to the guix package in a row so that the new version would reach new installs)
<graywolf>Hm, so that fact that the newly installed system has the same version of guix as the install medium is expected? And that holds regardless if I do guix pull before the guix system init or not?
<jpoiret>oh, no. Basically, the installation medium has the same version as the guix which produced it, but the installed system has the version of the guix package
<jpoiret>guix pull'ing in the installation image may upgrade the guix package in guix, but that's about it
<jpoiret>(yes, it's complicated)
<graywolf>Right, so to restate: system A creates a guix install image B. A and B have the same guix version. Then I boot up B, do guix pull, and guix system init system C. System C will have what guix version? Same as A or whatever was result of guix pull on running B?
<graywolf>I would expect "whatever was result of guix pull" but I am observing "Same as A". So before I try to find out what am I doing wrong I wanted to check what is actually expected.
<opty>hello, i'm trying to start elogind inside an lxc container but i'm getting "Cannot determine cgroup we are running in: No data available" followed by "Failed to allocate manager object: No data available", strace didn't show any hints
<opty>on debian 11.6 (bullseye), though
<opty>do i have to reboot?
<gabber>opty: sorry, i have never worked with such containers. but rebooting might be worth a try if it doesn't cost you anything :)
<gabber>(how) can i get a --pure shell with sudo capabilities for something like wireshark?
<gabber>nvm, got it
<opty>gabber: reboot didn't help :(
<ellysone[m]><lechner> "ellysone / regular terminal..." <- Idk I tried with a simple (format #t "~a" "\n_\033[1;36m3) FOO\\033[0m\n") and a (display (format #t "~a" "\n\\033[1;36m3) BAR\\033[0m\n"))
<gabber>that's a bummer. have you configured cgroups correctly on your machine? where is the error coming from? this might be a hint towards where the configuration went wrong
<opty>gabber: not sure :) the errors come from elogind daemon
<sneek>wb AwesomeAdam54321!!
<opty>gabber: i suspect that it doesn't like systemd in "cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,name=systemd)" but not sure again
<opty>gabber: it looks different on slackware: "cgroup on /sys/fs/cgroup/elogind type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/elogind/elogind-cgroups-agent,name=elogind)"
<opty>gabber: bad thing that new logins get 25 seconds timeout :/
<opty>gabber: on debian, elogind exists as a symbolic link to systemd and on slackware the other way round so who knows
<jpoiret>graywolf: system C will have the version of the guix package that's defined inside the guix of system B
<jpoiret>crucially, that guix package cannot have the same version as system B's
<gabber>opty: are you sure this is the right channel to ask these questions?
<ellysone[m]>can you give guix system image an operating-system definition on the command line or do you really need to create the file containing the os definition?
<opty>gabber: unfortunately #elogind doesn't seem alive
<gabber>i mean because you seem to refer to debian and slackware - this might not be a guix issue
<opty>gabber: i came here because says that "Elogind has been developed for use in Guix System, the OS distribution of GNU Guix." so i thought you might know :)
<crepe-suzette>"GitHub - elogind/elogind: The systemd project's "logind", extracted to a standalone package"
<ngz>Hmm, it appears that doesn't include colored patches anymore… Something wrong is going on.
<gabber>opty: huh! didn't know that. sorry! seems like you have come to the right place, then :)
<opty>gabber: np, we'll see :)
<cbaines>ngz, that probably means the qa-frontpage has got a bit stuck, I've run herd restart qa-frontpage on bayfront so hopefully it'll come back shortly
<Kolev>AwesomeAdam54321: I did not know you could install from a manifest. I thought you could only run. Thank you.
<nckx>opty: You're right about the ‘name=’ part: — I guess you fixed that and the 25s delay happens afterwards? elogind was originally extracted for & by Guix, but I'd wager that the current maintainer doesn't use Guix at all. They use Gentoo, all open issues are for Gentoo, and their CI builds on Ubuntu for some reason. :) By the power of sheer numbers you might get more eyeballs in #gentoo.
<crepe-suzette>"elogind/def.h at main · elogind/elogind · GitHub"
<nckx>I mean, in addition to #guix.
<ngz>cbaines: Aaahhh fixed. I feel better now. Thank you.
<graywolf>How can I create /var/guix/profiles/per-user/$USER? Should I just mkdir it? Or is there some guix command to do so?
<gabber>i think this is created when $USER does `guix install` or `guix home reconfigure`
<nckx>Or ‘guix pull’.
<graywolf>I tried the guix home reconfigure and got `guix home: error: while creating directory `/var/guix/profiles/per-user/wolf': Permission denied`.
<graywolf>Installing anything random package did fix the error, but that does not seem like proper solution.
<gabber>you didn't `guix pull` first?
<graywolf>I did not realize I should. Will try it with doing guix pull first.
<nckx>graywolf: Oh, interesting.
<gabber>i'm not sure if you should have to. but usually one does `guix pull` as an unprivileged user first and `sudo guix system reconfigure` next
<graywolf>this is about guix home reconfigure though
<nckx>This sounds like ‘guix home’ is trying to create the directory itself (i.e. running as you), rather than through the daemon (running as root) like happens for all the other modes.
<graywolf>I found this so it's possible guix home was overlooked? Should I make a bug report for this?
<nckx>Yes please.
<graywolf>Will do ^^
<nckx>It's going to be rare because you're assumed to want the shinyshiny and guix pull first, but it should either not be mandatory or the error message should be more helpful.
<nckx>Thank you for doing weird things. Please continue.
<graywolf>Uff thanks for that, I started to feel bit bad about how I keep breaking it in weird ways :D
<gabber>you should never
<nckx>Don't! And this was not *that* weird :)
<lechner>Let's keep Guix funky!
<lechner>ellysone[m] / what kind of terminal are you in, please?
<irfus>pipewire users, what do you do to get working sound in a FHS-container?
<opty>nckx: i was looking at that but no fix yet, i was also thinking about #gentoo first then github or another git? brought me here :)
<nckx>You're very welcome here. Whether we'll be useful is another matter.
<lechner>ellysone[m] / this does bold and underlined in a Guile REPL in Eat in Emacs. The colors do not apper to work there (display (string-append (string #\033) "[1;4m" "Hello\n" (string #\033) "[0m"))
<nckx>We use elogind in a specific way that's different from most other ‘standard’ distroes, where it has to fill a more snugly systemd-sized hole.
<lechner>ellysone[m] it also works in Eshell, but no color there either
<lechner>ellysone[m] / in vterm (again, in Emacs) this adds the color red, but blinking does not work (display (string-append (string #\033) "[1;4;31m" "Hello\n" (string #\033) "[0m"))
<nckx>ellysone[m] <guix system image>: Does -e suit your desire? It has some limitations, like (IIRC) the requirement to wrap everything in a single sexp. There's also the classic | … /dev/stdin hack that seems to work.
<irfus>that's the guix shell incantation I'm using right now, and pipewire and a user dbus session are started by guix home.
<mirai>lechner: maybe blinking simply doesn't work?
<qzdlns[m]>jpoiret: thanks for everything -- clean booted into my third guixSD machine!
<mirai>not all escape codes are supported by the varying terminal implementations
<XADE[m]>ACTION uploaded an image: (45KiB) < >
<nckx>Most VTEs don't support blink (5 & 6), and frankly that feels sane.
<XADE[m]>XADE[m]: i'm getting these notes every time
<XADE[m]>and it takes very very long
<nckx>lechner: See, my threats of feature-length DoS's were not idle ones!
<nckx>ACTION starts uploading Bee Movie.
<mirai>I remember devising some crappy M4 macros to markup text with escape sequences
<graywolf>If I plan to start Xorg by running startx, do I actually need elogind for anything? It seems to create XDG_RUNTIME_DIR, but if that is all what I need it for, it seems like a bit large dependency.
<mirai>and the special codes would either not work or do unexpected things
<gabber>graywolf: the easier and less painful way is to let GDM handle that for you
<gabber>(or some other DM)
<mirai>I barely recognize this pile of M4 code now
<irfus>gabber: GDM handling that wouldn't still require elogind?
<mirai>(code? macro? I'm not confident enough to call m4 'code')
<graywolf>Yeah I don't plan to use DM at all
<irfus>graywolf: I had a DM-less setup but recently enabled slim because I couldn't figure out how to start home shepherd services before sx started the X sesison
<gabber>irfus, graywolf: i'm almost sure it *is* possible, and i guess (though i have not really a clue) there would be elogind involved. i'm just saying it is so drastically less painful to go the DM route that people (like myself) have given up and are happily using GDM now ;)
<irfus>graywolf: I was using greetd and sx for my dm-less setup. However I still had elogind running because I don't know any other way to set certain power related settings for my laptop (sleep on lid close, etc.) without it on guix
<graywolf>I guess acpid would be the way (at least that was my plan)
<Arjanhehim[m]>I am running Xorg as regular user using startx, but it requires me to include modules in the server package or else they would not load
<Arjanhehim[m]>system currently does have elogind because docker requires it but will try without
<irfus>graywolf: is there an acpid service for guix system?
<graywolf>irfus: There is acpid package, but that is how far I got, I'm just getting started :)
<patched[m]>`guix shell --container --preserve=^DISPLAY$' xeyes -- xeyes`
<patched[m]>Running this yields "Error: Can't open display: :1"
<patched[m]>I also tried running the example in the manual for ungoogled-chromium, which errors similarly.
<patched[m]>How can I make the display available for programs in a guix container?
<nckx>Coincidence, or recent change…
<Arjanhehim[m]><Arjanhehim[m]> "system currently does have..." <- Xorg does run without elogind but it seems to be unable to use input devices
<lechner>the coconut is a giant nut, if you eat too much you get very fat
<patched[m]><nckx> "Hmm." <- Adding --share=/tmp:
<patched[m]>"Authorization required, but no authorization protocol specified"
<macaroon>"guix IRC channel logs"
<nckx>Then I'd try ‘xhost +’ before manually invoking ‘xeyes’ in the interactive container (so no ‘-- …’).
<nckx>ACTION away.
<nckx>(No time to look up which package provides xhost, sorry.)
<patched[m]>There is a package named xhost :)
<patched[m]>Allright, xhost + made it work
<irfus>patched[m]: `guix shell --preserve=="^DISPLAY$" --preserve="^XAAUTHORITY$" xeyes` works for me
<irfus>huh, but so does what you tried.
<irfus>what does the bracketed portion in " For containers, ‘--expose’ (resp. ‘--share’)" mean?
<irfus>are --expose and --share euivalent?
<Arjanhehim[m]>share is writable and expose is read only
<irfus>Arjanhehim[m]: thanks
<wdkrnls>Dear Guix, can anyone suggest an example where someone generates an origin object programmatically?
<wdkrnls>I want to automatically get the appropriate hash for a new URL.
<wdkrnls>Specifically, I am obsessed with getting at older python-3.x versions in Guix.
<wdkrnls>I guess I am overreaching here.
<wdkrnls>I will just focus on getting one to work :)
<cbaines>wdkrnls, how will you know what the hash is?
<nckx>wdkrnls: That sounds prohibitive. Even if you get it to work, *any* time Guix needs to know the hash of any of these special packages, it will have to download the source code again.
<nckx>Just to say ‘ah, yes, this is the same file you downloaded 42 seconds ago in the previous guix invocation’. Etc.
<nckx>So you'd build your own caching layer from scratch and regret many things.
<nckx>irfus: Interesting, I don't have XAUTHORITY set (Xwayland). But thanks, that was a valuable keyword I was missing.
<nckx>I guess creating ~/.Xauthority and sharing it (read-only?) would also work?
<wdkrnls>nckx: I agree. You wouldn't be able to rely on the hash unless it could be serialized.
<wdkrnls>It's just that the python package is so ponderous.
<nckx>Oh, I'm sure I sympathise.
<wdkrnls>I'm trying to get comfortable with treating package records as data structures that can be modified.
<wdkrnls>I feel comfortable getting data out of them. I'm just not comfortable yet with changing that data.
<apteryx>hm, building a guix pack (rpm format) with nss-certs, I get: find-files: ./gnu/store/1klwvqm3njp070h982ydcix1gzf2zmdl-nss-certs-3.81/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny.pem: No such file or directory
<apteryx>and it causes the rpm to be corrupted, I think
<apteryx>(because the file is not added to the header)
<nckx>nss-certs continuing to remain the premier Unicode test suite. 👍
<nckx>What locale is your RPM generator running in?
<nckx>Could it be fixed?
<apteryx>It's using other derivations that use the #+(set-utf8-locale profile) trick in their builder
<apteryx>which sets LC_ALL to en_US.utf8
<apteryx>(and augments GUIX_LOCPATH for it)
<apteryx>I think the problem occurs in the find-files call from generate-header
<apteryx>in the final rpm pack builder
<apteryx>so I tried this:
<macaroon>"debian Pastezone"
<apteryx>but it doesn't seem to do it
<apteryx>wait, perhaps I lousily tested
<nckx>Oh, OK, I was looking at directory->file-entries.
<apteryx>it seems to work in the end
<apteryx>I had forgotten to source my in-testing ~/src/guix/pre-inst-env ;-)
<apteryx>I'll test the resulting pack, and if it stops throwing 'cpio: Bad magic' cryptic errors, I'll call it a day
<apteryx>(rpm is not very good/accurate at error reporting...)
<nckx>Is there no way to handle file names as toxic opaque bytevectors or similar in Guile, for cases such as this one? …actually, that would apply to almost all cases, so maybe there's a good reason that they're strings.
<nckx>(My background's Very Unix, so ‘everything but NUL and /’ sounds almost sane to me. I'm recovering.)
<nckx>Still… shouldn't it be impossible to create invalid RPMs like this? A file that couldn't be found should not make it into the header either, or (IMO) simply fail.
<lechner>file names should not be strings. i encountered that issue in my new website, as well.
<nckx>Sorry, I know I'm hinting at more work.
<lechner>it's also why we will switch from JSON to cwebber's syrup as a transfer format in short order
<lechner>file names could be strings if we, as a distribution, were to enforce a valid UTF-8 encoding but that might render a random USB pen drive unmountable
<apteryx>nckx: I'm still getting an error trying to install the pack
<apteryx>error: unpacking of archive failed: cpio: Bad magic
<nckx>lechner: I agree but I feel terribly biased in a way I can't well articulate. I didn't grow up in the light of Lisp Machines or Scheme textbooks, but in the dark trenches of Unix, and it shows.
<bjc>torvalds has been pretty adamant that linux will never enforce encoding on filenames
<apteryx>I'll try to extract a minimal reproducer, I'm guessing nss-certs as a rpm pack
<nckx>I would be really weird if that succeeded, so yes, please fail.
<mirai>forcing a particular encoding won't play nice on systems that use alternate encodings
<apteryx>nckx: you'll find string->utf8 at some places in (guix rpm)
<nckx>lechner: Oof, missed your UTF-8 distro comment. That was not what I was replying to. I don't think *that* could work or that we should do it, wholly distinct from whether it's a good idea in theory.
<lechner>wait, maybe unix strings are byte vectors, and what we call "strings" is really something different
<nckx>File names are binary data (that you get to string search for ‘/’! Fun!) and we're stuck with that.
<bjc>old school unix/c strings are byte vectors. they long predate sensible encoding
<nckx>lechner: Also yes. C char arrays != Guile (or almost any) strings.
<gabber>Thank Progress!
<nckx>ACTION out for the evening. o/
<irfus>re: sound in a guix shell container with pipewire, adding "--share="/run/user/{uid}"" worked
<apteryx>so the the file name comes out ok from 'rpm -ql $(guix pack -f rpm nss-certs) | grep Arany' -> /gnu/store/1klwvqm3njp070h982ydcix1gzf2zmdl-nss-certs-3.81/etc/ssl/certs/NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem
<apteryx>nckx: o/
<apteryx>indeed: nss-certs fails to be extract from the 'guix pack -f nss-certs' produced rpm archive: "error: unpacking of archive failed: cpio: Bad magic"
<apteryx>so something about the accents in that file name 'NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem' seems to be causing it
<apteryx>ah, perhaps the cpio code lacks utf-8
<apteryx>in (guix cpio)
<mitchell>Hello guix! Can someone explain the rational from the guix side to enable ptrace_attach? There is a comment which pointed me to the linux rational for disabling such functionality and to me it seems quite compelling. What are the counter arguments to the alleged security benefits?
<gnucode>hey guix friends!
<gnucode>I got a nextcloud set up and running on guix system. That's kind of cool.
<mitchell>did you write about it?
<gnucode>mitchell what are you working on today?
<gnucode>mitchell I am editing the blog post now. :)
<gnucode>should be up inside an hour.
<mitchell>I am working through getting guix to boot a xilinx zynq7000
<mitchell>its not exactly kosher but yocto is a pile of shit
<mitchell>I've got it all working except the image generation which is the topic for today (and likely tomorrow)
<gnucode>mitchell are you blogging about the process?
<mitchell>I don't have a "blog" per se but I am writting about it. Hopefully it can contribute to the cookbook
<gnucode>mitchell: the reason I blog, is because I do something cool, then I forget how I did what I did. The person who probably uses my blog the most is me. :)
<mitchell>Earlier last year I did a lot of work porting the ZephyrProject to guix to replace their "west" tool. My ultimate goal is to demonstrate using `guix deploy` for distributed embedded systems. I'm not sure if this is appropriate to contribute back to guix proper though.
<gnucode>mitchell that's excellent work though. I think guix could use some love at working on smaller systems with limited RAM. That's why I don't want to run guix on my pinephone.
<mitchell>gnucode: exactly! But I do not know how to set up a blog in a freedom respecting way and I haven't had the time to learn about it. I see some people using haunt which looks cool but I'm not sure how to get it going
<mitchell>I went through a lot of pain getting it going on my pinebook
<mitchell>It still doesn't work quite like I want. A big thing for me was doing everything via cross-compilation which is tough
<gnucode>mitchell: I will happily set up your blog, and host it for you. :) also would you consider a github hosting your static website a freedom respecting way?
<mitchell>I thought the pinebook, since it was supported, was a good early test on how much of the system could be cross compiled and deployed to resource restricted devices
<gnucode>mitchell how hard was it to get it on the pinebook? oh, you're talking guix system...
<gnucode>also, I do have some videos of my setting up my haunt website via guix.
<gnucode>that might be helpful.
<mitchell>gnucode: Yea, its an arm64 which is not as restricted as something like a beaglebone. I wanted to cross-compile the installation image which would run a program to partition/encrypt the disks and then install a pre-compiled os onto that. But I never got that working. I only got the cross compiled installer working and the pinebook had to build the rest
<mitchell>I would love any and all information you have about setting up haunt. The worst thing i can imagine is dying without getting all this information out of my head
<gnucode> that is a playlist where I try to learn haunt.
<gnucode>mitchell it also depends on how you want to spend your time. If you time is better spent hacking at guix, and you are ok with me creating a simple site for you. I'm ok doing that. :) Just let me know. It also might just be easier to set up a github account and they will host a static website for you.
<mitchell>gnucode: I am okay with you doing that! I've been keeping everything as org documents that i've been sharing with my poor collegues.
<gnucode>mitchell org is amazing! :) Let me know if you want me to host your blog.
<unmatched-paren>hello guix :)
<unmatched-paren>anyone got any feedback on <>?
<mirai>gnucode: you wrote a guix service definition for nextcloud?
<mitchell>gnucode: where should I send stuff?
<lechner>mitchell / Hi, can I 'guix deploy' to something like this? I have the 1 GB RAM version
<macaroon>"[OpenWrt Wiki] Askey RT4230W REV6 / RAC2V1K"
<lechner>Hi, can Guix package definitions cherry-pick commits?
<apteryx>they sometimes do, as extra patches, if it fixes something important
<mitchell>lechner: Probably! If you can get guix running on it in the first place (which is possible). The beaglebone only has 512MB. As long as you never make it build anything itself. Thats where guix deploy comes in since it comes up with the derivations itself and copies them to the target.
<gnucode>mirai: I did NOT write a service definition for nextcloud. :)
<gnucode>I just got a docker image running on guix system. the blog post is coming soon ish.
<gnucode>mitchell what domain name do you want?
<mirai>configuring nextcloud "manually" looks tough
<gnucode>mirai: that's why the docker image was much simplier.
<gnucode>unmatched-paren I think you did a great job on the blog post.
<mirai>I tried just getting it to run under nginx, didn't succeed
<mirai>had to do nginx->their docker image
<mirai>which runs apache
<mitchell>I wrote a guile-mcumgr which can talk to the zephyr bootloader and update signed firmware from the store over whatever transport. The idea is to get something like the zynq7000 to run guix and be deployed to and have a service which will then update the really embedded stuff to the right firmware.
<peterpolidoro>hi. I submitted a package patch named kicad-7.0.0 and it was accepted and pushed. I just noticed a flaw in my patch. when i submit a fixed patch, do i keep the same name kicad-7.0.0 since kicad is still at version 7.0.0 or does the version number need to change to indicate it is a different package definition?
<sneek>peterpolidoro, you have 1 message!
<sneek>peterpolidoro, nckx says: Yes, relative --expose file names are supported.
<gnucode>mirai yup me too. It might not be a bad idea to create use the docker image that doesn't include the database. that way we could use guix's database.
<apteryx>ACTION back in gdb
<gnucode>mitchell: go ahead and buy a domain name. Or tell me what one you want and I'll buy it for you.
<gnucode>mitchell: actually can you message me privately? We should probably talk some logistics.
<peterpolidoro>sounds like an awesome project mitchell
<lechner>i can't wait to read that blog
<mitchell>Is that an IRC thing? I know how to join this channel and thats it
<lechner>which thing, please?
<mitchell>private message
<unmatched-paren>mitchell: /msg gnucode [...]
<lechner>don't forget the leading slash. it is essential for privacy
<lechner>you can also type it in your IRC connection window, which is probably smarter
<gnucode>unmatched-paren I do want to talk to you about your post, because it is truly epic.
<gnucode>I'll find some time later. :)
<peterpolidoro>should I submit a fixed patch to a closed debbug number or create a new one?
<mirai>peterpolidoro: create a new one and no need to change version number
<lechner>peterpolidoro / i might reopen
<lechner>debbugs control server
<peterpolidoro>ok thanks. what should I use as the commit message and email subject? "gnu: kicad: Update to 7.0.0." Or something else?
<apteryx>hm, I guess RPM has no support for such fancy encoding; the file name they package is renamed NetLock_Arany__Class_Gold__F__tan__s__tv__ny.pem
<apteryx>(they being actual RPM-based distro)
<lechner>apteryx / why do you think that, please?
<apteryx>just based on observation, although I've now read that which suggests otherwise
<macaroon>"Fedora Packaging Guidelines :: Fedora Docs"
<gnucode>mitchell: are you ok with me putting your irc nick on the blog post so that others can contact you if they have questions?
<mitchell>gnucode: Better to use email since I do not "own" this username and there is no password
<mitchell>Allow me to edit before you post. I wrote those over a year or so ago and I've discovered/fixed some bugs
<mitchell>Plus it's probably best to have a git repo available
<wdkrnls>Dear Guix, please help me pattern match. I am looking for functionality like: (modify-origin origin-record (version "new-version") (uri "path/to/new/uri") (sha256 (base32 "foo")))
<wdkrnls>Is this possible with Guix records?
<wdkrnls>Maybe I could write it myself by just extracting each part.
<mitchell>What are you trying to do?
<mitchell>Why not inherit the package and define a new source?
<mitchell>`(package-variant (package (inherit package) (source new-source)))`
<wdkrnls>Because then I have to specify everything.
<wdkrnls>I am not so Herculean to do that.
<mitchell>you can define a function which returns the origin given the meta data you are willing to provide
<wdkrnls>Yeah, that is what I'm looking to do. I found the definition in guix/packages.scm
<mitchell>You can look at the definitions in `gnu/packages/linux.scm` to see how they use functions to return source origins
<wdkrnls>thanks! I will have a look
<mitchell>and functions which define package variations
<wdkrnls>I definitely was inspired by gcc-toolchain for example.
<wdkrnls>Honestly, I don't understand when @ gets used in versions :/
<mitchell>Ha! that is a complicated place to start
<wdkrnls>For me I hope necessity is the mother of invention!
<mitchell>that is used from the command line user interface.
<mitchell>when you refer to packages on the command line it is package-name@package-version
<mitchell>when you refer to them in scheme code it is variable name
<mitchell>for example "linux-libre@5.15" vs "linux-libre-5.15"
<wdkrnls>that makes sense
<wdkrnls>it's presumably just reaching into the version slot in the record.
<mitchell>if you define a package in a channel and you want it to take priority over the one packaged by guix you can do (string-append (package-version package) ".1") as your version
<mitchell>then yours will be the most updated one guix selects by default
<wdkrnls>those examples in the linux.scm are really helpful!
<old>is there a way to disable the new progressioing bar?
<old>I like the `#' better. Is this configurable via an environment variable?
<lechner>mitchell / gnucode / which domain name did you all settle on, please?
<mitchell>lechner: they will be posted to his domain once I update and publish some companion code
<lechner>apteryx / nckx / actually, per the link above it looks like Fedora enforces UTF-8 in file names by asking maintainers to convert non-compliant names in the "%install" script
<lechner>mitchell / is it just pinebook for now?
<apteryx>lechner: isn't /gnu/store/1klwvqm3njp070h982ydcix1gzf2zmdl-nss-certs-3.81/etc/ssl/certs/NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem a UTF-8 file name? How can I tell what character set it's encoded with?
<mitchell>Oh I have not finished that one yet! I wrote about toolchains and build systems and what it took to get guix to build zephyr based firmware without west.
<apteryx>ACTION gdb self note: b fsm.c:937 if ! (int)strncmp("988a38", fp->fpath, 6)
<apteryx>seems the cpio unpack error occurs processing that "etc/ssl/certs/988a38cb.0: symbolic link to NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem" symlink
<lechner>apteryx / was it encoded twice by mistake?
<wdkrnls>sometimes you can see the encoding with the unix utility file
<wdkrnls>I feel like there was another command which I also used, but I'm drawing a blank.
<wdkrnls>I am think I was just using iconv to convert from whatever it said to something sane.
<lechner>these types of things can be extremely hard to debug, because the tool used to inspect and the terminal may likewise convert, correct, translate or interpret
<wdkrnls>Does anyone understand the sha256 hash?
<wdkrnls>I'm pretty bewildered.
<lechner>which one?
<wdkrnls>The one in all the package definitions.
<wdkrnls>Not the one in the store.
<mirai>wdkrnls: imo I have the same question
<lechner>i think it's produced by 'guix hash'
<wdkrnls>But, my confusion is how to get the byte vector.
<wdkrnls>I see guix has a module for it.
<mirai>I never understood exactly what kind of hash it is
<wdkrnls>But it gives me a different string.
<lechner>you mean which encoding?
<wdkrnls>(bytevector->base32-string (content-hash-value (origin-hash (package-source python-3.9))))
<wdkrnls>,use (guix byte32) (gnu packages python)
<mirai>apteryx: do you really have to "guess" the original encoding?
<mirai>the process isn't guaranteed to always work
<lechner>wdkrnls / mirai / "If the --format option is not specified, guix hash will output the hash in nix-base32. This representation is used in the definitions of packages."
<macaroon>"Invoking guix hash (GNU Guix Reference Manual)"
<wdkrnls>lechner: that's the one :)
<wdkrnls>That worked better.
<mirai>apteryx: I recommend you this link in case you haven't read it <>
<apteryx>thank you, I'm sure it'll be useful
<mirai>it's full of interesting and non-intuitive facts about the topic
<lechner>the important thing to remember is that string->bytevector is the encoding step. Decoding is when you transform an on-disk representation of what we usually call characters, but what are really unsigned bytes, into Unicode codepoints.
<lechner>Hi, how may I use the fields in this define-configuration in a service stanza, please?
<macaroon>"debian Pastezone"
<lechner>it does not work like i would expect
<lechner>I get Invalid keyword: "/var/cache/fscache" when i try to do this
<macaroon>"debian Pastezone"
<mitchell>That looks correct to me
<mirai>you can do away with that let by using match-record
<mirai>and I see no /var string
<mirai>how exactly are you testing this?
<lechner>i am happy to take your review now. i put it in my config and deploy, using stock guix
<mirai>what's the configuration you're feeding it
<lechner>I change (maybe-string %unset-value) to (string "/var/cache/fscache") and just call (service cachefilesd-service-type)
<lechner>but it's not right. there should be no default value
<lechner>it's the only required value
<mirai>maybe-types are used differently
<lechner>please tell me how. it's my first service
<mirai>see mpd-configuration from audio.scm
<mirai>for an example
<mirai>I think it covers most of the patterns you're looking for
<lechner>mirai / i see a lot of naked maybe-strings, but how is this different from what i am doing, please?
<macaroon>"guix/audio.scm at master · guix-mirror/guix · GitHub"
<mirai>you have (maybe-string %unset-value)
<mirai>that's redundant
<lechner>do i also need the whole my- thing?
<mirai>simply maybe-value (without parenthesis) will suffice
<mirai>what my- thing?
<lechner>mympd-configuration etc
<mirai>mympd-configuration etc is for a service that's named mympd
<gnucode>unmatched-paren Your latest blog post was pretty ambitious! Explaning a monad is really hard to do! My understanding is that a monad allows you to transform stateful operations in a more functional way.
<lechner>oh no
<mirai>if you mean things like mpd-configuration?, mpd-configuration-package, mpd-configuration-user, etc. those are accessors
<mirai>they should be exported in order to be able to do introspection
<lechner>i don't think i have that issue right now. it's in the same file
<mirai>right, what field are you using that value on
<gnucode>for those that are interested, I did finish my blog post about setting up nextcloud on a guix system server:
<lechner>mirai / also, did i not include /var strings everywhere?
<mirai>not in that paste
<lechner>under the defines, you mean? sorry, i thought you meant just the fields
<mirai>and your (define (serialize-cachefilesd-configuration configuration) procedure is incorrect
<mirai>you want this
<mirai>(define (serialize-cachefilesd-configuration configuration) (mixed-text-file "cachefilesd.conf" (serialize-configuration configuration cachefilesd-configuration-fields)))
<lechner>I still get Invalid keyword: "/var/cache/fscache"
<lechner>although I kept the string-append with the comment
<lechner>so i only changed to mixed-text-file
<mirai>can you paste the (service cache.... (cachefilesd-configuration ....)) you're using
<mirai>lechner: no, don't do that
<mirai>it doesn't work
<mirai>serialize-configuration returns gexps
<mirai>you cant string append to a gexp
<mirai>you could instead do
<mirai>(mixed-text-file "filenamehere" "string1" "string2" (serialize-configuration ....)))
<mirai>it will auto append
<wdkrnls>How do you think about debugging failed patches?
<wdkrnls>It makes sense to me that a patch would fail if it includes some version number newer than the distribution you are patching..
<lechner>mirai / okay, but isn't that still mixing strings with the output from serialize-configuration, which is a gexp?
<mirai>mixed-text-file takes care of that
<lechner>what i had worked by the way
<wdkrnls>But it would be nice to be able to "mount" the system and run the process step by step.
<lechner>mirai / how do i mix in the part that is commented out then, please?
<lechner>i am clarifying the change of the API with the author. the user space still recognizes them but newer kernel modules complain
<mirai>you can just put it after the serialize-conf... procedure
<mirai>check out mixed-text-file in the manual
<lechner>but get rid of the with-output-to-string
<mirai>its under G-Expressions
<lechner>i am
<mirai>any argument after the second one will be added to the file
<mirai>as long they're either strings or gexps (well, gexps that contain strings)
<lechner>okay, I still get Invalid keyword: "/var/cache/fscache"
<mirai>is that really the first error?
<mirai>you don't have a serialize-string to begin with
<mirai>ah, nvm
<mirai>you're using a custom serializer
<lechner>here is the full backtrace
<macaroon>"debian Pastezone"
<mirai>can I get the config.scm as well
<macaroon>"debian Pastezone"
<lechner>the earlier paste is being added via load near the top
<mirai>btw why format #t
<mirai>what about format #f
<mirai>I don't think it fixes this but with #f you get the string as output
<lechner>i am a beginner, and in way over my head. wait until you see my PAM stuff and my upcoming kernel module