IRC channel logs

<mirai>nvm, that changes the value accepted by the service

<mirai>it accepts plain-file

<mirai>though it should be more intuitive to accept lists of services instead

<mirai>nckx: Have you read about this? <https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/>

<mirai>read/heard

<mirai>same thing

<mirai>I haven't done any check to the package sources but it might be prudent to keep an eye on this

<nckx>I hadn't heard of this latest occurrence. Thanks for the poke.

<mirai>or even have CI flag "incorrect" links

<mirai>np

<lechner>wow

<nckx>We don't accept such generated source tarballs in Guix. That doesn't mean none can slip in, but we're not one of the projects who apparently ever thought this was a good idea.

<nckx>They've changed in the past. They'll change again.

<nckx>mirai: ‘guix lint’ already does this.

<mitchell>I thought github's tarballs were just things the authors uploaded

<mitchell>I didn't know they were generated

<nckx>A quick grep returns ~20 potentially sus github.*/archive/ links, mostly in java.scm (somehow, fitting) if anyone wants a low-barrier but not unimportant task.

<nckx>mitchell: The generated ones are generated. The ones uploaded by authors are not 😉 There's no overlap, really.

<nckx>You can easily tell them apart.

<nckx>(BTW, this is not a GitHub issue—most git forges do this. Some call them snapshots, but it's the same thing.)

<mitchell>i see

<nckx>Not sure why I didn't suggest ‘guix lint -c source-unstable-tarball’ rather than an awkward grep.

<nckx>I wonder what it is about java, or did we just miss some enormous patch set…

<nckx>ACTION has to work though. Thanks for the link! This is a nice low-hanging fruit so I'll let it dangle a bit longer…

<vagrantc>guix lint, a nice theory! :)

<mirai>(gnu services base) has been rid of old-style services (on my local branch)

<mirai>only desktop left and a few scattered ones around

<mirai>hopefully should be done by the end of the month

<gnucode>permission to ask a slightly off topic question?

<gnucode>May I have permission?

<vagrantc>i don't think anyone can grant blanket permission ... but if it doesn't go off the rails or consume the whole channel indefinitely, it might be fine :)

<vagrantc>sometimes it comes down to quantity

<gnucode>sweet. So I have a friend and I am lending her a laptop GNU/Linux laptop. I will probably set it up with GNU Guix, because I want to convince her to fall in love with it too. However, as much as I love guix, it's not super user friendly compared to elementary OS.

<gnucode>anyway, to keep the question mostly on topic...what can I do to make it super easy for her? I'm basically saying that she rarely has to type in commands, but can click a button to update and such.

<gnucode>Actually, is there a channel where I can install either dthompson web front-end for the guix command. Or the guix graphical gui wip guix?

<sneek>AwesomeAdam54321: wb

<vagrantc>gnucode: sort of a "running guix and you don't hardly notice" sort of environment?

<gnucode>I am currently thinking something like xfce. That is a fairly lightweight and easy to use desktop environment

<gnucode>vagrantc: pretty much. How do I convince a computer illiterate person that guix system is their best option?

<vagrantc>i would worry with a system like that that they might only see the guixy parts when things break, and not when it is running smoothly

<gnucode>vagrantc: what desktop environment would you suggest?

<vagrantc>i do not know that i would try to do that with any system ... more inclined to help people already interested for some reason ... :)

<gnucode>gnome ? My only issue with that is that it takes a fairly long time to update. I suppose that I could just install xfce-destop-service & gnome-desktop-service and let her pick the one she likes.

<gnucode>let's be saleman vagrantc :)

<gnucode>salesmen

<vagrantc>i played the evangelist many years ago, and eventually realized it often worked against my goals

<lechner>for such a friend, i might offer a free support contract

<gnucode>vagrantc: can you tell me about your experiences as an free software evangelist?

<gnucode>lechner: that's a good idea!

<lechner>vagrantc brought me to guix! https://debconf18.debconf.org/talks/99-my-crush-on-gnu-guix/

<vagrantc>gnucode: the short of it is i tried to convince people to use various systems, and whenever anything was broken or unusual or weird to them, they learned that free software was sub-par. even though many of the things it did worked quite well ... it is too easy to focus on what goes wrong ...

<gnucode>vagrantc: looks like you have a second chance at being an evangelist!

<vagrantc>the talk lechner referenced is me saying "this is what i like about it, maybe you will like it to, and here are some warts that you should know about"

<vagrantc>some of which have since been fixed :)

<gnucode>vagrantc: honestly that was my fear when I sold a used computer to my father. I could not in good conscious sell him guix system. I had to sell him elementary OS instead. (though I installed guix on top of it).

<vagrantc>i mostly came to guix for the integration of reproducible builds and the commitment to free software ... :)

<vagrantc>and the people keep me coming back :)

<gnucode>vagrantc: I came because it seems like the coolest free software project out there. And "The Emacs of distros" really sold me.

<gnucode>vagrantc: I feel like a big selling point right now, is that I will be selling her a laptop for about $250

<gnucode>or $300 that'll last for 10 years easily.

<gnucode>that is if she decides to buy it.

<vagrantc>i think being honest about the challenging bits up front helps, that way they are not as surprising when they happen.

<vagrantc>e.g. substitute availability issues, disk space usage, etc. of guix can sometimes be surprising... still surprises me now and then when it installs the Nth copy of some program for some seemingly unrelated update

<gnucode>I don't think disk space will be too big of an issue. I'll set up a cron job to periodically delete some stuff.

<gnucode>but that is true. She won't really know how to run guix update, guix package delete-generations, guix system delete-generations.

<gnucode>and guix gc.

<bjc>guix is *weird*. when things go wrong, the internet is unlikely to help you, even less so than a “normal” linux desktop

<gnucode>bjc: in my personal experience, guix is hands down the most stable distro I have ever used. What things have gone wrong for you?

<bjc>as something you opt into, i think it's a great system, but it's not something i'd spring on someone without them being enthusiastic about its ideas

<gnucode>since I have heard this a few times now, if not guix system what should I set up for my friend. As a non-literate computer user she probably will not care about becoming a saint in the church of emacs.

<bjc>stability isn't so much the issue. it's not going to crash. it's going to be "why can't install rust" or "my wifi doesn't work" or "how do i use wine" or "the instructions for setting up podman don't work"

<bjc>and as soon as you start to scratch at the surface of that, everything becomes a dark art that very few can help you with

<gnucode>the wifi will probably be a big sticking point...

<gnucode>I will let her try guix system for a week or so, and probably blog about the issues that she has.

<bjc>there are countless examples. this channel gets, on a regular basis, questions about why "obvious" things don't work

<gnucode>I could also try to get my silly server set up and have a substitute server set up in my apartment. Since we live in the same town a substitute server would help her out.

<mroh>it also "why can't I run brave-browser" (for my $gf).

<bjc>it's a great system if you can positively commit to its trade-offs, but it's definitely not for everyone, and it doesn't try to be

<gnucode>mroh: what is your current computer's hostname...? I feel like we have had this conversation before...

<gnucode>i guess I could also take a look at what other companies are doing that pre-install linux distros on their laptops. They probably pick those distributions because they are user friendly.

<mitchell>gnucode: Just bind a hotkey in the system that runs `guix package --roll-back`

<mitchell>it'll be great

<lechner>i see a lot a lot of Mint

<bjc>and pop_os

<mitchell>i started with mint

<mitchell>mint in a vm

<gnucode>mitchell: that's a really goo idea!

<lechner>mint has gnome 2 i think. she will probably want Guix when given a choice later, with that slick Gnome 3 skin

<gnucode>haha.

<iyzsong>i started with a live system (slax), a guix based live system at the level of puppylinux would be great..

<vagrantc>a live system ... with /gnu/store on tmpfs? :)

<lechner>a minimal /gnu/store !

<iyzsong>it can be, usually mounted from a read-only squashfs (can be copy to mem for faster speed), and changes upon / can be managed (save/discard).

<gnucode>iyzsong[m]: what makes puppylinux so great? light on resources?

<gnucode>vagrantc: is there anyone running guix system with /gnu/store on tmpfs?

<iyzsong>gnucode: it have many useful gui applications builtin (browser, editor, player, package management), and wizard for setup (network, language, keyboard, etc). and it's hard to break

<vagrantc>iyzsong: sure, i know how live systems generally work ... more commenting on how impractical it would be to maintain a guix live system doing regular updates ... (you could rebuild the image, i gues ...)

<iyzsong>vagrantc: yes, rebuild the whole system image should works..

<vagrantc>though you would need a lot of ram to do even that

<gnucode>now that I think about it...rde might be a good idea. Sway is fairly light on resources. and rde might have a mac OS like horizontal bar on the bottom of the screen.

<gnucode>oh onto another topic. I have the Hurd set up and running on real hardware a T52 or something...It only has 2GB of RAM. What's the process of installing guix on it? Would the installer script work?

<AwesomeAdam54321>gnucode: Wow! It's cool that you have the HURD running on real hardware

<AwesomeAdam54321>There's two ways to install guix, building it from source or using a curl | bash script

<gnucode>AwesomeAdam54321: It was actually really easy! I chose the netinstall option, and it had a couple of hickups during the install, but it installing the base OS worked really well.

<gnucode>That laptop is currently running doom emacs. Though Doom emacs can be fairly hard to use...it's responsiveness is really slow at times.

<AwesomeAdam54321>Would the installer script work? <- I think it should

<gnucode>I guess it should. The Hurd tries to be POSIX compliant.

<dcunit3d>if i'm running emacs-guix, how do i associate a particular buffer to the running Guix REPL?

<dcunit3d>when i run commands from guix-devel-mode, they expect a running geiser repl, but if i just start a geiser repl, it doesn't have the same context as a Guix repl, so it doesn't do things like jump to definition or provide autocomplete or allow most of the guix-devel-mode functionality.

<dcunit3d>i've set the geiser repl for a buffer manually before, but i feel like there's a simpler way to do this.

<dcunit3d>it's possible that i'm conflating my past experiences where my GUILE_LOAD_PATH/etc wasn't set up properly, so if i try it now, then maybe everything just works

<lechner>Hi, which is better and why, please? #$(file-append cachefilesd "/sbin/cachefilesd") or (file-append #$cachefilesd "/sbin/cachefilesd")

<gnucode>lechner: gexp are still confusing to me...

<AwesomeAdam54321>lechner: (file-append #$cachefilesd "/sbin/cachefilesd) is better because only the cachefilesd variable needs to be dereferenced at build time

<lechner>AwesomeAdam54321 / thanks!

<lechner>gnucode / thank you for sending your empathy!

<lechner>Hi, i am writing a new service. Anyone know what to make of this backtrace? https://paste.debian.net/1271921/

<tres-leches>"debian Pastezone" https://paste.debian.net/1271921

<lechner>wrapped https://paste.debian.net/1271922/

<tres-leches>"debian Pastezone" https://paste.debian.net/1271922

<lechner>sneek / later tell mirai / i found my bug. in the service-extension it has to read (compose list ...) instead of just the service

<sneek>Okay.

<bumble[m]>might anyone here know of way to show notifications in wayland without dbus? something like https://github.com/phillbush/xnotify, but for wayland?

<tres-leches>"GitHub - phillbush/xnotify: read notifications from stdin and pop them up on the screen" https://github.com/phillbush/xnotify

<winter>hey nckx, a while back (~November?) I was talking about a weird issue wrt booting the install image with ARM64 EFI. I believe it may be due to the kernel image being (zlib) comprised, and GRUB not having it enabled. happen to know if this could be the case? thank you!

<lechner>i don't think so. i believe the decompression code resides in the kernel. that's also why the kernel can function as an EFI stub

<winter>i'm really unsure why grub would be throwing "invalid magic number" when trying to load the kernel, then. :/

<lechner>wrong arch or byte order?

<winter>i mean that's possible, but i don't expect it to be the case -- i built an aarch64-linux kernel on an aarch64-linux build syste

<winter>m

<lechner>that's what you think!

<winter>not really sure how to work around that (i just ran `guix system image -t iso9660 gnu/system/install.scm`)

<lechner>just for the record, i am assuming the magic number GRUB is complaining about is different from the magic numbers usually associated with the kernel https://docs.kernel.org/process/magic-number.html

<winter>all the drvs built or substituted were aarch64-linux, hrm

<winter>and this is definitely LE aarch64

<lechner>Are you seeing this? Error: Invalid Magic Number Error: You need to load the kernel first

<lechner>or this error: invalid magic number alloc magic is broken at 0xb7855240: b779dc00 Aborted. Press any key to exit.

<winter><lechner> Are you seeing this? Error: Invalid Magic Number Error: You need to load the kernel first <-- this, yup

<lechner>can you boot manually in grub shell?

<mroh>winter: is the root fs on btrfs with zstd compression? (I thing, some versions of the grub btrfs module had trouble with it)

<sneek>Welcome back mroh, you have 1 message!

<sneek>mroh, lechner says: / i found my bug. in the service-extension it has to read (compose list ...) instead of just the service

<lechner>mroh / sorry that was intended for mirai

<winter>lechner: nope, same error

<winter>mroh: nope, it's just the install image

<winter>so it's trying to read from an iso

<lechner>winter / i think your paths are potentially broken you can inspect with 'e' in the menu

<mroh>lechner: ok, np.

<winter>lechner: that's certainly a valid store path being pointed to in grub.cfg, and a manual invocation of `linux ...` confirms it

<lechner>winter / or your device ordering/detection is different now

<lechner>how about 'root'

<winter>sorry, root what?

<apteryx>cool, I think I've fixed the non-ascii problem in (guix cpio)

<lechner>is the drive setting in set root=?? what it should be

<lechner>apteryx / how?

<apteryx> https://paste.debian.net/1271925/

<apple-pie>"debian Pastezone" https://paste.debian.net/1271925

<winter>this is the install image, lechner, so yes it looks about right at a glance

<apteryx>I now assume the strings are either ascii *or* UTF-8

<lechner>winter / this is installation media, or after?

<winter>this is the install media, lechner

<apteryx>or rather, I support that file names may have Unicode characters

<lechner>your usb stick is broken?

<winter>it's a VM :)

<lechner>apteryx / multi-byte UTF-8 sequences?

<lechner>winter / on any other linux i'd copy kernel and initrd to / as well as a static shell executable and then run the kernel with init=/bin/sh not sure how to help you there. grub cannot find the kernel

<lechner>sometimes it's just a little number that is off

<winter>grub can find the kernel though

<lechner>really?

<winter>which is evident if i change the path to gibberish

<winter>it throws what i'd expect: "file ... not found"

<lechner>winter / maybe it's time to inspect your kernel https://wiki.osdev.org/Multiboot

<apple-pie>"Multiboot - OSDev Wiki" https://wiki.osdev.org/Multiboot

<lechner>grub-file --is-x86-multiboot2 myos.bin

<winter>is x86 multiboot still used on aarch64?

<apteryx>lechner: yes, I always convert a string to utf-8 before writing it to disk

<apteryx>and I always take the length of a string in bytes via (bytevector-length (string->utf-8 "the-string"))

<lechner>apteryx / my question was, are you supporting ascii and Unicode characters or ascii and utf-8?

<apteryx>utf-8 supports any Unicode character, no?

<apteryx>utf-8 can encode, I should say

<lechner>yes, but most importantly utf-8 is a simple superset of ascii

<apteryx>so it's OK to say it now supports any Unicode character?

<lechner>well, not simple

<lechner>yes, but the conditional you mentioned appeared ficticious

<lechner>fictitious

<apteryx>it was, sorry for the confusion

<lechner>winter / good catch, how about --is-arm64-linux https://manpages.org/grub-file

<apple-pie>"man grub-file (1): check file type" https://manpages.org/grub-file

<lechner>apteryx / thank you for working so hard on such an important problem!

<apteryx>I don't think it was "that" important, but it was blocking the integration of RPM guix pack in the Jami's build pipelines, so a good itch to scratch.

<lechner>apteryx / i prevented much frustration downstream

<lechner>it

<apteryx>I hope so!

<apteryx>I sent the patch with patman, and it ping'd the core team, so we'll see what they say

<winter>lechner: file confirms that it is a valid kernel image

<winter>it's just grub that hates it for some reason i guess :(

<lechner>it's the same grub that comes with our official installation media

<lechner>?

<winter>yes, this is straight from guix system image

<lechner>it's like an agatha christie novel

<winter>okay, notable thing:

<winter>after extracting the ISO, the store path differs than the one on my machine

<lechner>that's okay

<winter>sorry

<winter>not the path

<winter>the content of the *same path*

<lechner>please explain

<winter>as in, `sha256sum /gnu/store/.../Image` and `sha256sum /iso/gnu/store/.../Image` differ

<winter>so i suspect it's the ISO generation process

<winter>(where ... is the same store path)

<lechner>to my knowledge that should never happen in Guix, should it

<lechner>it's plainly not reproducible

<winter> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n323

<apple-pie>"image.scm\build\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n323

<winter>so this is faulty

<lechner>i am not sure. shouldn't the kernel just be copied?

<lechner>it's the same path!

<winter>let me test something

<lechner>i think it used to be possible to embed some start up values in the kernel, but i have not seen that in a very long time

<winter>hang on, autoconfing...

<winter>if this works i'll send a patch up to see if this is desired at all

<winter>or if the issue lies with the kernel build not producing a bzImage

<winter>would be nice if pre-inst-env was picking up my changes :/

<winter>nope

<winter>I edited https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm, ./bootstrap && ./configure, but ./pre-inst-env guix system image isn't building a different derivation.

<apple-pie>"image.scm\build\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm

<winter>can't tell what I'm doing wrong :/

<lechner>as to guix, this may be above my pay grade

<winter>at least i found the bug :) thank you!

<winter>now just need my changes to actually be picked up >_>

<lechner>what was it, please?

<winter> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n335

<apple-pie>"image.scm\build\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n335

<lechner>how do you know you got it?

<winter>this is the list of things not to compress when building an ISO

<winter>my kernel derivation is building Image, not bzImage

<winter>so it was being compressed

<lechner>i don't believe it. guix cannot compress the kernel

<lechner>never mind

<lechner>you are saying that Image should be exempt?

<winter>correct

<winter>but if I edit that file to make it exempt, pre-inst-env guix system image ... isn't building a different drv

<winter>so not sure what i'm doing wrong

<winter>the derivation should be different

<winter>so hopefully someone knows what i'm doing wrong 😅

<lechner>winter / was the uncompressed Image equal to the other Image?

<winter>not sure, couldn't get it to decompress by piping gz header + data to gzip, but can try later

<lechner>winter / it's a special format. i think you may need zisofs-tools http://fileformats.archiveteam.org/wiki/Zisofs

<apple-pie>"zisofs - Just Solve the File Format Problem" http://fileformats.archiveteam.org/wiki/Zisofs

<winter>yeah, but logging off for the day ^^

<lechner>me too

<winter>o/

<lechner>see ya

<winter>just going to post this again so it doesn't get lost in the backlog: I edited https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n320, ./bootstrap && ./configure, but ./pre-inst-env guix system image -t iso9660 gnu/system/install.scm isn't building a different derivation. Compression is enabled by default, so I also tried to set

<winter>the default of compression to false on line 257, but that also doesn't build a different drv.

<apple-pie>"image.scm\build\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n320

<winter>What am I doing wrong? I see Guix being compiled, so... not sure.

<winter>Thanks!

<unmatched-paren>hello guix :)

<TristanCottam[m]>Hi unmatched-paren !

<TristanCottam[m]> * Hi unmatched-paren !

<TristanCottam[m]>And hi everyone!

<TristanCottam[m]>I'm setting up a home server to host multiple online services using Guix System. After some research, I've narrowed my options down to`guix shell`, `guix system`, and `guix system container`, each used in conjunction with Guile modules, and have decided to keep a separate Git repo for each online service. `guix system` would be used for the core system configuration in any case.

<TristanCottam[m]>Can anyone offer me guidance on which approach would best suit managing dependencies and configurations for each online service in a clean and efficient way?

<TristanCottam[m]>Thanks for you time!

<civodul>hi TristanCottam[m]! in general you would use Guix System to manage services as part of the configuration of your server

<civodul>i'm not sure what you mean by "a separate Git repo for each online service"?

<user_oreloznog>hello guix!

<TristanCottam[m]>I'd like to keep each online service (i.e. web service, not "service" in the Guix jargon) in a separate Git repo, and keep core system configuration in yet another repo, as opposed to having everything in a single repo. Could you help me in understanding what problems `guix shell` and `guix system container` are trying to solve?

<TristanCottam[m]>By online services, I mean things such as Nextcloud, Mastodon, Git, game servers, etc.

<civodul>efraim: hey! an HPC colleague says they're happily running RISC-V VMs built with "guix system image --target=riscv64-linux-gnu", crazy stuff :-)

<efraim>civodul: nice!

<civodul>the enthusiasm about RISC-V seems to be propagating

<efraim>looks like I'll need to actually figure out booting on riscv hardware. I think I have another dead SD card in my hifive unmatched board

<efraim>vagrant says u-boot -> grub-efi is supposed to work, but needs testing

<apoorv569[m]>What can I add as a input for a package I'm making that requiressystemd as a dependency?

<apoorv569[m]>I get this error while compiling,

<apoorv569[m]> https://0x0.st/Hswv.txt

<AwesomeAdam54321>apoorv569[m]: You can add eudev as an input

<AwesomeAdam54321>For the systemd dependency, you could try and patch to make it optional

<AwesomeAdam54321>I'm not really sure why it requires systemd "for AMDGPU and INTEL support"

<florhizome[m]><TristanCottam[m]> "I'd like to keep each online..." <- guix shell is like a virtual environment (or nix' direnv i think), while guix container starts a linux container. you can add packages in the command, also a guix.scm in the directory will be evaluated. thats as far as i can say. more info and examples should be found in the manual and cookbook

<florhizome[m]>or peoples online repos, fosdem talks, etc

<TristanCottam[m]>I checked the cookbook, but I'm not sure I checked the manual, I'll give that a try

<apoorv569[m]>The package is nvtop I am not sure why the dev has a dep on systemd.

<florhizome[m]>both have a wide range of cli options and support one off commands after a '--'

<TristanCottam[m]>I think I understand how they differ in function, but I'm unsure about the use case for each

<TristanCottam[m]>And which would best suit my needs

<florhizome[m]>there are plenty of usecases :)

<TristanCottam[m]>Yes, but I'm not entirely clear on which fits which scenario

<florhizome[m]>i guess this really is about the level of isolation you want to have and thats something i cant speak on

<TristanCottam[m]>Okay, I'll check the manual, thanks for your help!

<florhizome[m]>also guix container --emulate-fhs could be handy for getting things to run that expect a normal lfs

<TristanCottam[m]>I'd seen that option, but didn't understand exactly what it meant. I'll look into it.

<florhizome[m]>it simulates a standard linux filesystem

<TristanCottam[m]>As opposed to?

<florhizome[m]>the one guix has ;)

<TristanCottam[m]>Oh ok I get it

<florhizome[m]>guix doesnt have /usr /lib and other directories

<TristanCottam[m]>Yup yup

<TristanCottam[m]>Thanks again!

<florhizome[m]>np :)

<apoorv569[m]>Where can I get support for Guix the question here gets lost so fast with no response.

<AwesomeAdam54321>apoorv569[m]: I checked, and it doesn't require systemd if libudev is used

<TristanCottam[m]>My strategy consisted in waiting for no one else to be active

<florhizome[m]>apoorv569[m]: imo here is still the best place, but just be persistent and stay nice

<AwesomeAdam54321>you can set USE_LIBUDEV_OVER_LIBSYSTEMD=ON in the build system

<apoorv569[m]>AwesomeAdam54321: AwesomeAdam54321: Thanks.

<florhizome[m]>but i think a matrix community with some more specialized rooms would be a very good idea

<florhizome[m]>i think the fsf even has an own server

<apoorv569[m]>florhizome: I understand, but this IRC pretty sure half of the people can't really see the history. And most people won't scroll back chat to see if they can find a question to answer. Its better to have a dedicated channels for specific kind of topics. Like General for general chat helpdesk for support and all.

<TristanCottam[m]>AFAIK #guix:matrix.org is basically al there is

<TristanCottam[m]>I'm not aware of a Guix Matrix space

<TristanCottam[m]>florhizome[m]: Really? I can't find any mention of it online.

<TristanCottam[m]>s/al/all/

<apoorv569[m]>I know. I am just learning about for 2 weeks straight now and because of lack lisp knowledge I keep struggling a bit. And its just frustrating at times.

<TristanCottam[m]>I feel you, I've been learning about computers on my own since I was 15, I'm 21 now, and having been at it for a few weeks, learning Guix and Guile with no prior Lisp or Scheme knowledge proves to be quite the learning curve

<TristanCottam[m]>s/the/a/, s/learning curve/challenge/

<TristanCottam[m]>Wanna team up in tackling this beast?

<apoorv569[m]>That's nice.

<apoorv569[m]>Sure.

<apoorv569[m]>BTW where did you find USE_LIBUDEV_OVER_LIBSYSTEMD=ON?

<apoorv569[m]>I don't see it anywhere in their repo.

<AwesomeAdam54321>apoorv569[m]: In nvtop/src/CMakeLists.txt

<AwesomeAdam54321>I used grep to find references to the word systemd

<apoorv569[m]>Can you share line number? I can't see it with CTRL + F..

<apoorv569[m]>Ah! nevermind inside the src

<apoorv569[m]>I was looking at the root CMakeList file

<Guest6>Hi ! I'm trying to write a import script for julia packages.

<Guest6>I want to serialize a stream of an ini file to an alist, if possible without using the package guile-ini.

<Guest6>I've written the following function, but can't get it to work, it this king of pattern matching possible ?

<Guest6>(define (ini-list->alist lst)

<Guest6> (match lst

<Guest6> ((attribute '= value ooo ...)

<Guest6> `((,attribute . ,value) ,@(ini-list->alist ooo)))

<jbv1[m]>Guest6: I cannot help you with this, but I have an hackish importer written in julia if you're interested?

<civodul>Guest6: hi! i was about to say something similar: i think zimoun has a Julia importer, or prototype thereof :-)

<civodul>you folks should join forces :-)

<Guest6>Yes I am ! Where can I find these ?

<jbv1[m]>I'll put it on gitlab, just a sec

<clar14>Hello! How modify a line in a file....for example...how change umask without touching /etc/profile ?

<jbv1[m]>Guest6: here it is https://gitlab.com/vjb/guix.jl

<apple-pie>"Jean-Baptiste Volatier / Guix.jl · GitLab" https://gitlab.com/vjb/guix.jl

<jbv1[m]>civodul: Yes we should ;) It also seems to me that the interop between Julia package manager and Guix is not working as well as it was since the last Julia update. But I did not have time to investigate deep enough to make a bug report.

<civodul>jbv1[m]: i think zimoun & efraim are those msot familiar with this, let's see

<civodul>thanks for sharing your code!

<Guest6>Thanks ! I'll take a look and try to work with it in the afternoon.

<Guest6>Still interested if someone knows if the pattern matching I was trying to make can work;)

<zimoun>civodul, Guest6: about the importer, yes I tried an importer in Guile but I think it is the wrong path: we are reinventing the wheel for almost no value. Instead the importer should use the builtin from Julia. As jbv1[m] does or Nicoló too.

<zimoun>We discussed that with Nicoló at Guix Days in Brussels.

<zimoun>From my point of view, the best would to write an extension wrapping something similiar as jbv1[m] or Nicoló importer using Julia itself.

<jbv1[m]>I think so as well. for example the dependency solving is very valuable and quasi impossible to reproduce

<zimoun>yes, I agree.

<zimoun>And for instance, the Haskell importer reimplementing many Cabal thing in Guile is hard to maintain.

<zimoun>Having in mind how fast the Julia ecosystem is moving, it would be hard to have an importer in Guile that follows their breaking changes. ;-)

<zimoun>Thanks jbv1[m], I was not aware about your importer.

<civodul>i guess it all depends on what it is that needs to be implemented

<civodul>for PyPI, CRAN, CPAN, etc., having our own stuff works remarkably well

<civodul>and it's available out of the box with Guix, which is nice

<jbv1[m]>On a similar note, I think we could do something simpler for the julia-jll packages (the one that wrap a binary)

<jbv1[m]>Currently we are patching the source to replace the paths to our binary in the store, but we could use the Overrides mechanism that julia provides

<jbv1[m]>I have tried it for some projects and it works very well

<zimoun>civodul: many things needs to be implemented. You need to parse many things. Then you need to reimplement a kind of resolver. Yes, it could be to have in Guile, but I think the effort is not worth.

<zimoun>civodul: Well, reinventing the wheel and write many parsers can be fun. But there is little value, IMHO. And it costs for maintaining it.

<zimoun>Anyway! That’s does not cook the rice. ;-)

<civodul>"many parsers" sounds problematic, indeed

<zimoun>bah I am from the South of France, so I am exagerating a bit. ;-)

<zimoun>Guest6: about the pattern matching, I think it missing the base case of the recursion.

<zimoun>(define (ini->list lst)

<zimoun> (match lst

<zimoun> ((? null? _) '())

<zimoun> (((attribute '= values ...) rest ...)

<zimoun> (append

<zimoun> (list `(,attribute . ,values))

<zimoun> (ini->list rest)))))

<zimoun>something like that, I guess.

<clar14>It is possible to change the default umask through config.scm?

<zimoun>Guest6: Or instead the append, the splice ,@ as you wrote. :-)

<zimoun>Guest6: https://paste.debian.net/1271944

<apple-pie>"debian Pastezone" https://paste.debian.net/1271944

<lechner>Hi, in a service is it better to use #~(format $f "~d" #$one) or just straight (format #f "~d" one) ? in the former, i get an error about simple-format not knowing about ~d

<lechner>and why does the same referral to (ice-9 format) not happen here? https://github.com/guix-mirror/guix/blob/master/gnu/services/audio.scm#L357

<apple-pie>"guix/audio.scm at master · guix-mirror/guix · GitHub" https://github.com/guix-mirror/guix/blob/master/gnu/services/audio.scm#L357

<lechner>i guess it doesnt use ~d

<lechner>why does Guile need to "format"s anyway?

<lechner>two

<lechner>i guess it's number->string for me

<ngz>Doesn't #$whatever always return a string?

<lechner>ok, that's interesting! i'm new

<lechner>ngz / thanks! that worked

<gnucode>mitchell: your post is live by the way. :)

<gnucode> https://gnucode.me/building-toolchains-with-guix.html

<winter>gnucode: are the codeblocks supposed to be ~unreadable with the stylesheet? 😅

<winter>feels like a bug ^^

<lechner>kinda dark

<gnucode>winter :( yeah. It's something that needs to be fixed. Someone who knows how to use haunt a bit better...I would love you tips on how to fix that. :)

<gnucode>lechner the code examples are dark? I agree.

<gnucode>but you guys gotta admit... mitchell's post here is absolutely stellar!

<lechner>i can hardly read it

<lechner>it's all done in plain css. the code blocks don't even use ids or classes

<gnucode>lechner: I agree it is really hard to read! Do you know how to use haunt to get highlighting on code snippets?

<gnucode>That's something that I have wanted to do for a while, and I am not entirely certain how to do it...

<gnucode>alternatively, lechner we could just put mitchell's blog post on guix.gnu.org/blog .... ?

<civodul>gnucode: nice post indeed! (perfectly readable in eww :-))

<lechner>haha

<civodul>and yes, this sort of blog post would be welcome on guix.gnu.org IMO

<lechner>gnucode / for haunt, let's track down dthompson. look at the code blocks here for comparison https://dthompson.us/issues-with-object-oriented-programming-in-guile.html

<gnucode>civodul hahaha!

<civodul>oh, GNU was accepted as a participating org for GSoC

<civodul>time to refine your project proposal, comrades :-)

<civodul>*proposals

<winter>👀

<gnucode>lechner yeah, I know. David's a genius in setting up haunt blogs. He and cwebber actually encouraged me to get haunt to support org-mode files (via an emacs script).

<civodul>winter: wanna be a GSoC intern, for a change? ;-)

<gnucode>civodul I will go ahead and email mitchell and tell him that you said you want his blog post on guix.gnu.org. I bet that would make his day!

<winter>civodul: "for a change?"

<civodul>to change topics, i mean

<winter>ah

<winter>maybe next year, doing something similar (as a mentor) for NixOS :D

<civodul>oh didn't know

<winter>though i don't think GSoC is open to experienced OSS folks

<civodul>prolly not ;-)

<lechner>i'm new

<civodul>(maybe you're not the person i think you are actually, who knows)

<winter>probably not

<winter>i've gotten that a bit on libera

<winter>seems that i may have stolen someone's username, though nobody's reached out

<civodul>heh

<civodul>did we chat at FOSDEM?

<winter>nope, definitely not me :)

<civodul>ok :-)

<lechner>Hi, does this three-liner look like a reasonable service definition in a config file? http://paste.debian.net/1271946

<apple-pie>"debian Pastezone" http://paste.debian.net/1271946

<winter>I edited https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n320, ./bootstrap && ./configure, but ./pre-inst-env guix system image -t iso9660 gnu/system/install.scm isn't building a different derivation. Compression is enabled by default, so I also tried to set the default of compression to false on line 257, but that also doesn't

<winter>build a different drv.

<apple-pie>"image.scm\build\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n320

<civodul>winter: so are you involved in Summer of Nix?

<gnucode>civodul: I will wait for mitchell to say yes to you to put up his post on guix's site. He has another post too that he wants to share at some point. But in case he does say yes, the code for his post is here: https://notabug.org/jbranso/gnucode.me/src/master/posts/building-toolchains-with-guix.md

<apple-pie>"jbranso/gnucode.me: The code for gnucode.me. - NotABug.org: Free code hosting" https://notabug.org/jbranso/gnucode.me/src/master/posts/building-toolchains-with-guix.md

<winter>civodul: tentatively, but yup

<civodul>cool, that looks like a nice program

<winter>yeah i've seen really good things from it

<winter>can't tell if I'm using pre-inst-env wrong or not, but it doesn't seem like it -- i see the Guile compilation logs and such...

<civodul>there were discussions about what we (Guix) should do wrt. internships, onboarding newcomers and marginalized people

<winter>this function is definitely called to build the ISO, too

<lechner>you guys are talking past each other

<civodul>re ISO compression, i don't know

<civodul>it should definitely build a different derivation if you change (gnu build image)

<winter>yeah, hence my confusion -- guess i'll take a closer look at it

<zimoun>winter, about Summer of Nix, do you know which entity runs it? Managing the legal stuff etc.

<lechner>winter / now you owe civodul something on the internships

<lechner>a remark

<winter>zimoun: I believe it's the (NixOS) foundation who handles that, as there's no entity that really would other than them.

<civodul>yeah, that's my understanding

<civodul>lechner: thanks for following through :-)

<lechner>thanks for giving in!

<zimoun>winter: thanks

<gabber>does anyone know of a good example where cmake is patched so that it doesn't download stuff through git but uses Guix' inputs?

<sneek>gabber, you have 1 message!

<sneek>gabber, civodul says: you can view what command a service run with "guix system edit SERVICE"

<gabber>civodul: thank you very much!

<winter>hm yeah so compression is evidently always true, it's not overridden in scripts/image

<winter>wonder why changing it to false didn't do anything -- is there a printf equivalent in Guile I could just add to the function to make sure it's being called?

<winter>(or I could throw an error or something... :-)

<gabber>civodul: although i was less interested in editing the service file itself (i was already patching it) but interested in the actual process invocation done through herd. i am in the process of patching dnsmasq (to include more options) but when it started it failed saying only something along the lines of "wrong command line arguments" -- and i wondered how exactly my patch was parsed. then i found the relevant .scm file in the store

<gabber>containing the `make-forkexec-constructor`. it's not really human-readable but i think i can work my way up from there :)

<lechner>Hi, what is the default value for (compose) in (service-type), please, and how is "append" different from "compose"?

<gabber>lechner: isn't compose a Guile default Higher-Order Function?

<lechner>sorry "concenate" maybe?

<gabber>ah

<lechner>gabber / i'm looking at this https://github.com/guix-mirror/guix/blob/master/gnu/services/cups.scm#L1038

<apple-pie>"guix/cups.scm at master · guix-mirror/guix · GitHub" https://github.com/guix-mirror/guix/blob/master/gnu/services/cups.scm#L1038

<gabber>are you sure it's not described in Guile's Higher-Order Functions page in the manual?

<winter>oh, `raise`, hm

<lechner>gabber /.yeah, it's part of a record from what i can tell, but i probably don't have to use it https://github.com/guix-mirror/guix/blob/master/gnu/services.scm#L174

<apple-pie>"guix/services.scm at master · guix-mirror/guix · GitHub" https://github.com/guix-mirror/guix/blob/master/gnu/services.scm#L174

<apteryx>winter: you can use 'pk' (undocumented), like (pk 'something something)

<apteryx>it stands for 'peek'

<lechner>anyway, why would my carefully crafted service for cachefiled accept no record modifications in the service stanza in config.scm? Invalid keyword: "/var/cache/fscache"

<lechner>this is on a maybe-string

<winter>apteryx: why's it undocumented? :o

<lechner>does this look like a reasonable service stanza? (service cachefilesd-service-type (cachefilesd-configuration (cache-directory "/var/cache/fscache")))

<apteryx>winter: no idea, but that'd be a good first contribution to guile's manual :-)

<lechner>what is the mechanism by which this service accepts record modifications to cachefilesd-configuration, please? http://paste.debian.net/1271950

<apple-pie>"debian Pastezone" http://paste.debian.net/1271950

<winter>apteryx: so did you find out about it through word-of-mouth? :D does it just print whatever to stdout?

<winter>wonder if that would actually show up in a guix invocation given the fancy progress stuff

<civodul>pk is the expert's tool, and experts like to keep it for themselves while others naively struggle with breakpoints and whatnot ;-)

<winter>i see

<winter>lol

<winter>i really don't understand why changing this code doesn't result in a different drv, hopefully it's obvious if i poke at it more

<winter>it's definitely the code that generates the ISO...

<lechner>change something drastic

<winter>yeah, that's what i'm going to do

<winter>though now that i look at it, not even sure if this is being run as a g/sexp

<lechner>delete the thing

<winter>maybe it is in scripts/system oops

<ngz>Hmmm. I get the following error "no code for module (guix ui)" when I try to use the etc/teams.scm script in repository. What am I doing wrong?

<lechner>with pre-env-inst?

<ngz>lechner: It way better, now I get "no code for module (git)" ;)

<lechner>maybe you ought to reboot

<ngz>ewww

<ngz>What about my emacs-uptime?

<lechner>it's so tempting with guix because it is so ultra stable

<lechner>or log in again

<ngz>Why would this have an effect, BTW? I'm not sure to understand.

<zimoun>ngz: is it “./pre-inst-env ./etc/teams.scm help” inside “guix shell -D guix” and after “./bootstrap && ./configure --localstatedir=/var”?

<lechner>ngz / you should go with zimoun. something about your environment variables is off

<ngz>zimoun: Ah! "guix shell -D guix" was the missing step. Thanks to lechner and you.

<attila_lendvai>how can i get a guix shell with the latest guile commit? i need a fix that has not been released...

<ngz>Hmmm, No texlive team.

<lechner>attila_lendvai / make a copy of the stock package definition and adapt it?

<lechner>also, if you forgive the curiosity, which fix?

<attila_lendvai>lechner, i think there's some --with-source or --with-latest, or some way, no? it's the fix to spawn https://git.savannah.gnu.org/cgit/guile.git/commit/?id=5b42f8c154906584455a4989038406c88b723cb0

<apple-pie>"guile.git - GNU Guile" https://git.savannah.gnu.org/cgit/guile.git/commit/?id=5b42f8c154906584455a4989038406c88b723cb0

<lechner>attila_lendvai / not sure

<lechner>Hi, is it possible to get the benefits of define-syntax-rule constructs like define-configuration when a draft service is being included via Guile's "load" instead of use-modules plus exports?

<lechner>the records fields show up as unbound variables

<attila_lendvai>lechner, it should be: guix shell --with-commit=guile=9d339ea1a95c3b2d04a88aa6b116f997349fc4f4 guile, except "guix shell: error: the source of guile@3.0.9 is not a Git reference"...

<attila_lendvai>ACTION pings civodul... :)

<lechner>Hi, how may I use a modified Git check out of Guix to reconfigure my system with custom channels, please?

<ngz>efraim: In commit e36ac715518387686bd8165e1724ce54984ee0ee, I added texlive-fancyvrb and left texlive-latex-fancyvrb untouched to avoid a massive number of rebuilds. Is there anything to do on the core-updates branch to make the merge easier?

<apple-pie> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e36ac715518387686bd8165e1724ce54984ee0ee

<attila_lendvai>civodul, FYI, https://issues.guix.gnu.org/61750

<apple-pie>"[PATCH 1/2] gnu: shepherd: Build Shepherd from git." https://issues.guix.gnu.org/61750

<apteryx>are debug symbols supposed to include information for the source line of the symbols?

<apteryx>*corresponding source location/line

<lechner>Hi, does 'guix shell -f guix.scm' invoke 'guix build -f guix.scm' when the build is not available?

<civodul>apteryx: in general yes, but "debug symbols" is used in a broad sense so it depends on the details of what's kept (symbol table, .debug section, etc.)

<civodul>lechner: i think so

<lechner>civodul / okay, thanks! still learning...

<apteryx>civodul: hi! I'm trying to debug jami, so I've installed it with: 'guix install jami jami:debug libjami:debug pjproject-jami:debug ffmpeg-jami:debug', but somehow I get poor symbol coverage in a backtrace: https://git.jami.net/savoirfairelinux/jami-daemon/uploads/b4f7c665e84110d3e48a082fecadb011/gdb.txt

<civodul>uh, how many threads in that process? :-)

<civodul>apteryx: most likely debug-file-directory is not pointing to the right locations

<apteryx>also my colleague wonders what's going on with the threads created - threads closed vs thread shown in 'taas bt' mismatch

<civodul>IIRC it should Just Work if you do, say, guix shell gdb jami jami:debug

<civodul>(a change you made, right?)

<civodul>as a last resort, you can add the right "set debug-file-directory ..." command in ~/.gdbinit manually

<apteryx>civodul: I think the debug symbols are located correctly (it loads them), but perhaps I'm facing #48907.

<apteryx>oh, apple-pie's gone

<apteryx> https://issues.guix.gnu.org/48907 (Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB)

<apteryx>can I do 'guix install --no-grafts ...' ? that may help

<civodul>the backtrace doesn't even have debug info for glibc

<civodul>so it's quite clear that glibc:debug/lib/debug isn't on debug-file-directory

<apteryx>I haven't added glibc:debug

<apteryx>I thought that'd be too low level to be interesting

<civodul>ok

<apteryx>but I'll add them just to check :-)

<civodul>then it's hard to tell, but with a self-contained "guix shell" command as suggested above, it should be easier to check what's going on

<civodul>you can also use --with-debug-symbols for things that don't have a "debug" output

<civodul>er, --with-debug-info

<apteryx>OK. I see at least: Reading symbols from /gnu/store/7v68yjqr31zn8z88n1vs7rpwg3adc31r-jami-20230206.0/bin/.jami-real... and Reading symbols from /gnu/store/9hivfps50w25m7jbqnrpnf7i4nwhajmk-profile/lib/debug//gnu/store/7v68yjqr31zn8z88n1vs7rpwg3adc31r-jami-20230206.0/bin/.jami-real.debug...

<apteryx>civodul: it's spawing a lot of threads and leaking files somewhere, only reproducible on my end so far, eh.

<dthompson>gnucode: hey I heard you might need some haunt help?

<civodul>apteryx: "Reading symbols" is a good sign

<apteryx>arg how do I umount a NFS shares that wen't offline; it's stuck

<apteryx>sudo umount /var/cache/jami -> hangs

<apteryx>ah, I reconnected to the VPN and it could proceed...

<bjc>‘umount -f’ may work as well, if you get bitten in the future

<guix-person>hi, I'm trying to set up rootless podman on Guix, and I have run into an issue assigning the subuid and subgid values

<guix-person>what is the correct approach on Guix? I can't seem to find any documentation on the issue

<civodul>guix-person: hi! this has been reported before and it seems there's no easy solution to this yet

<guix-person>oh okay, thanks

<civodul>Guix System doesn't set up subuids

<civodul>this is something we should fix

<guix-person>so are there any known workarounds to get rootless podman working?

<civodul>not known to me, but i don't actually use podman

<guix-person>okay, thanks anyway

<civodul>yw

<bjc>iirc, cgroups need work for rootless podman as well. i've tried just creating subuid/gid, but it's not enough

<bjc>there's also cni services that need to be created for network access, but i have solutions for that which should work

<bjc>also: i'm not sure how relevant the subuid/gid files are these days. i haven't looked too deeply into it, but i think there are ways to autoconfigure it now

<winter>what would Guix System even touch wrt cgroups bnf?

<winter>*bhc

<winter>*bjc

<mirai>apteryx: lazy umount

<mirai>umount -l

<bjc>winter: there are default mounts for it set up, and elogind (and maybe greetd?) also mess with them

<ekaitz>nckx: did you work on "Disabling unprivileged BPF by default in our kernels"?

<ekaitz>i mean I have no idea of what bpf is but some people had a discussion on help-guix about guix having vulnerable kernels (spectre v2) and there was some configuration against that

<ekaitz>this is the relevant thread: https://lists.gnu.org/archive/html/help-guix/2023-02/msg00009.html

<ekaitz>i'm interested because the proposed solution was not persistent :( and it would be interesting to have that configured in the config.scm

<nckx>Work is a big word for https://git.savannah.gnu.org/cgit/guix.git/commit/?id=017f1779e937a85e525debdb89807592b35f55ea

<nckx>I don't think making people put ‘make the securities now please’ in their system configuration is acceptable, at least not without serious trade-offs.

<nckx>If this option is enabled in your kernel (/run/current-system/kernel/.config) and you still get these warnings, poke me.

<nckx>Hey winter! GRUB doesn't decompress kernels on sane^Warchitectures I'm familiar with. The mere idea would be silly on x86. Is this handled totally different in ARM land?

<nckx>ACTION AFK though, be back later.

<mitchell>Does GRUB normally run in arm land? usually its u-boot

<ekaitz>nckx: looks like my kernel doesn't set that because it comes from *somewhere else*, is there any way to set it in the config.scm?

<ekaitz>or in general to customize things in the config.scm?

<ekaitz>oh, maybe even if I have a corrupt kernel the config comes from Guix?

<mitchell>If you know which kernel options you are after you can specify a kernel like `(customize-linux ... #:configs '("CONFIG_BLHA=y"))`

<ekaitz>I don't know what's going on

<ekaitz>oh mitchell that sounds good!

<mitchell>ekaitz: You are talking about the file you pass to `guix system reconfigure` right?

<ekaitz>now I want to know where does my kernel come from!

<ekaitz>mitchell: yes!

<mitchell>It is a default option in `operating-system` record

<mitchell>you can specify a different one if you want but if you don't specify anything it just pulls the default

<nckx>ACTION back.

<nckx>ekaitz: What does ‘uname -r’ say?

<mitchell> https://guix.gnu.org/manual/en/html_node/operating_002dsystem-Reference.html

<nckx>If you didn't specify a custom (kernel FOO) anywhere, you're using Guix's Linux-Libre.

<ekaitz>6.1.9 but I'm using the forbidden one, the question is where does the config of the forbidden kernel come from

<nckx>mitchell: Both. U-boot's more for embedded devices.

<nckx>‘Boards.’

<ekaitz>they don't have any .config file in their repo is it coming from ours?

<nckx>You'll have to ask them.

<mitchell>nckx: My pinebook runs u-boot

<nckx>They recently overhauled their kernel a bit.

<nckx>mitchell: Yeah, stuff like that.

<nckx>Pinebook's a clunky flip phone.

<nckx>(☺)

<ekaitz>mitchell: I can't find any reference to `customize-linux` in the guix docs

<mitchell>It's not there

<mitchell>Are you using emacs?

<mitchell>It's defined in gnu/packages/linux.scm right at the top

<ekaitz>oook! thanks!

<nckx>ekaitz: That's very unfortunate. https://git.savannah.gnu.org/cgit/guix.git/tree/etc/news.scm#n161

<mitchell>you can use it to customize any kernel

<ekaitz>oh thats cool

<ekaitz>will it force my computer to build it by hand?

<nckx>…any kernel that follows that API.

<mitchell>likely

<ekaitz>i mean, no substitutes?

<nckx>Yes.

<mitchell>It's not likely the build system is going to have a build for your new config

<nckx>ekaitz: If you change the kernel, how could it be substituted.

<mitchell>You might be able to do it as a kernel module if you really can't spare the build time

<ekaitz>i was afraid of that, yeah :(

<mitchell>but its way trickier and more fragile

<nckx>mitchell: Not this.

<mitchell>unfortunate

<nckx>(Also, yeah, don't, as implied by mitchel.)

<nckx>*l

<ekaitz>hmmm now i want to know where is my current config coming from

<nckx>ekaitz: Ask the people who provide your kernel :)

<gnucode>dthompson: yes please. Maybe we should chat in the guile irc room though.

<ekaitz>looks like it comes from "linux-module-database", and that comes from guix?

<nckx>Looks like they've recently switched to customize-linux. (‘Recently’ = since I checked, so maybe not that recent 😛)

<nckx>linux-module-database is generated from your kernel, not the other way round.

<ekaitz>this level of complexity is too much for my small brain LOL

<ekaitz>in any case, my question is more than solved, than you both for the assistance :)

<nckx>It's complex, and IMO still overly so, but it's comprehensible.

<nckx>Despair not.

<ekaitz>:)

<nckx>But heed my advice to ask about how they make their software in their channel. We can't answer these questions for them.

<nckx>Like, literally.

<nckx>It's not maintained by Guix.

<mitchell>Your .config comes from the configure phase when the build system calls `make defconfig`. If you want to know what config is currently active you can look at /proc/config.gz

<nckx>Or the above /run/current-system/kernel/.config

<gnucode>mitchell: are you ok with your blog post going on guix.gnu.org/blog ?

<nckx>No need to load a module.

<ekaitz>i checked that, and it was coming from a reference to linux-module-database which is only mentioned on guix's source code, that's why I thought it was obtained from guix

<mitchell>gnucode: Indeed I am, I'm going to start the process shortly

<nckx>ekaitz: 6.1.9? That's old, no?

<ekaitz>btw I just guix pulled and now we have really cool progress bars!

<nckx>ekaitz: Could it simply not predate my commit above?

<ekaitz>i'm reconfiguring just in case

<nckx>Yes, I'm reading out of order, it's a great idea that leads to excellent results.

<nckx>ekaitz: 👍

<nckx>I think that's all you need to do.

<gnucode>mitchell awesome. Let's still be friends when you get rich and famous!

<nckx>mitchell: Nice.

<ekaitz>probably it's because my system is old so your commit doesn't appear yet, and maybe the kernel i'm using is inheriting the config from the one we ship or something

<nckx>gnucode: *Especially* then.

<nckx>ekaitz: Ding.

<gnucode>nckx: hahahah. :) I think I could spend a happy and content life chatting with the people in this channel. :)

<ekaitz>so asking here was a good idea after all :)

<nckx>Eh :)

<lechner>sneek / later ask mirai / for the bot, i don't think a 'HEAD request returns the HTML page title

<sneek>Will do.

<nckx>lechner: It doesn't.

<nckx>It returns the HEADers.

<lechner>there goes an idea to avoid 'GET

<nckx>You could try sending a ranged GET request… some servers will honour it. Then hope the <title> was in those bytes. Why were you trying to avoid GET?

<nckx>ACTION not actually recommending ranged requests, mind you, I don't think it's a necessary optimisation.

<lechner>one some URLs, such as our one-page reference manual, the GET takes a moment, plus it all happens in memory

<nckx>You could just close the connection if someone sends you a 10MiB page, no? Or do you have to buffer the whole thing first, the way things are written?

<lechner>that depends on Guile :) i don't think it's lazy

<nckx>If you could just search a stream and close it as soon as you have what you want, that would be ideal.

<nckx>Yeah. No idea. I've used (web client) for cheap hacks but never had to optimise it.

<ekaitz>nckx: HA! pull & reconfigure was all I needed!!!

<ekaitz>nckx: thanks for fixing this thing, btw :)

<nckx>You're weclome. Sorry for my ignorance about your kernel.

<nckx>And, apparently, spelling.

<nckx>ekaitz: Are there any other lscpu vulnerabilities still unmitigated?

<mvnx>Is there a recommendation for/against running `guix system reconfigure` in a (m)cron job? Is it best to leave this as a manual process? Or what are some things I should take into consideration to decide for myself? I'm on a personal laptop and a reboot in the middle of the night is almost never a concern if required

<lechner>civodul / Hi, when I update a commit hash in a guix.scm file, and then run 'guix shell -f guix.scm' no rebuilding happens. Is that meant to be like that?

<winter>hey nckx! so, I figured out the issue, but for whatever reason, pre-inst-env... is not working, so I can't test the change.

<nckx>mvnx: Guix provides an unattended-upgrade-service-type (see manual) that I think answers your question.

<nckx>winter: Are you running it within ‘guix shell -D guix’? (Yes, even after building this is still required.) If you are, define ‘not working’ more verbosely :)

<winter>so basically when building the ISO, all files are compressed, except for a certain few: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/image.scm#n335

<nckx>Ah… yes…

<winter>I edited this list, and then tried to pre-inst-env guix system image, but the exact same drv was built.

<winter>(from within a guix shell, yeah)

<nckx>I wrote that… uh oh.

<mvnx>nckx: Perfect thanks!

<winter>So I'm not really sure what I'm doing wrong, would love to test and send the patch upstream :(

<nckx>ACTION phone

<lechner>winter / why are you building an uncompressed kernel image, by the way?

<winter>lechner: not sure! this is a stock Guix tree

<lechner>maybe that's your bug

<winter>i mean the bug is that the list is wrong too, as it should support uncompressed kernel images all the same

<nckx>I only now realise what you meant by zlib-compressed. I thought you meant kernel compression. You meant zisofs compression.

<lechner>yes

<lechner>they want to exempt the kernel image in either form

<nckx>winter: The list was written by the same person who (jokingly) called non-x86 weird above, so there's your answer 😉

<nckx>lechner: Yes.

<winter>haha

<winter>But yeah I'd love to test it and send the patch.

<winter>Just not sure why the change isn't sticking

<nckx>I'll try to reproduce your weirdness.

<winter>Cheers

<nckx>What's the g s i command you're running, for completeness?

<nckx>(With ./pre-inst-env.)

<lechner>nckx / yes to which item, please?

<nckx>‘they want to exempt the kernel image in either form’

<lechner>ah

<nckx>This was clear, but when winter & me were chattin' earlier I said some things that only made sense in my interpretation of zImage-style compression.

<lechner>i had that same affliction last night

<nckx>Horrible things. No, worse, irrelevant things.

<lechner>right

<lechner>why doesn't guix shell build when needed?

<nckx>My answer would be ‘it does’ so there's something more here.

<nckx>Since you asked above.

<lechner>beats me

<winter>nckx: guix system image -t iso9660 gnu/system/install.scm or whatever that file name is

<winter>same drv with and without pre-inst-env, assuming that list is edited

<nckx>lechner: ‘guix shell’, like all guix-something-this-package, falls back to building a package when it needs it. That's all I can say. I'd need to know more about your expectations/results to say more.

<nckx>winter: Thanks.

<nckx>Mmm, that subglyph progress bar is so viscerally satisfying.

<winter>by the way, why does computing the derivation for that command take a while?

<lechner>I took this file and ran guix shell -f guix.scm -- guix-helper-bot --nick=hot-potato --channel='#guix' https://codeberg.org/lechner/guix-helper-bot/src/branch/history/guix.scm

<winter>is Guile that slow?

<winter>or what's the bottleneck(

<winter>*?

<lechner>then i updated the commit hash to the latest in that repo, and ran the command again

<winter>or maybe it's just my VM being slow :D

<nckx>Guix isn't *fast*. The image generator also uses a ‘subguix’ (not sure if it's an inferior exactly, but something like that) rather than the calling Guix, which is slower even when it doesn't need to build it first. Which it is currently doing here.

<winter>Oh, interesting. I thought it was just staging a drv and then going?

<lechner>nckx / ok the bot should now be immune to your pictures. can you please post one?

<winter>Based on scripts/system

<nckx>When I am king URLs ending in .scm that are not .scm but HTML will be illegal.

<nckx> https://www.tobias.gr/guix.jpg

<lechner>why not just run them?

<lechner>thanks

<nckx>lechner: Too sad. Run what?

<lechner>actually, it croaked too

<lechner>run URLs ending in .scm

<nckx>lechner: Guix didn't like running HTML.

<lechner> https://img.huffingtonpost.com/asset/5bd8712f240000a602579aec.jpeg

<nckx>When I see foo.scm, I assume I can curl -L it and be happy.

<nckx>It is my fault for being trusting in this world.

<nckx>peach-cobbler: https://www.tobias.gr/thruth.png

<lechner>okay, thanks! it's not working

<nckx>What did you try?

<lechner> http://d2o0t5hpnwv4c1.cloudfront.net/511_http/request_header.png

<lechner>that worked in my test channel! checking for text/html

<winter><winter> Oh, interesting. I thought it was just staging a drv and then going? <-- using the store monad, i mean.

<lechner> http://d2o0t5hpnwv4c1.cloudfront.net/511_http/request_header.png

<winter>or is that recursive since it runs in a build because something something daemon?

<nckx>lechner: → ‘building /gnu/store/cbbhmbd3p6z8qdj4birifir74b4vv25i-guix-helper-bot-0.0-0.25381c4.drv...’ … ‘applying 1 graft for guix-helper-bot-0.0-0.25381c4 ...’

<lechner>srfi 39

<peach-cobbler>"SRFI 39: Parameter objects" https://srfi.schemers.org/srfi-39/srfi-39.html

<nckx>Did I misunderstand your question?

<lechner> https://www.tobias.gr/thruth.png

<lechner>i will never understand guix

<nckx>peach-cobbler: 🎉🎊

<lechner>everything is find when i go into a guix shell -D -f guix.scm and run the bot with GUILE_LOAD_PATH=/lcl/lechner/guix/guix-helper-bot/git/scm:$GUILE_LOAD_PATH scm/guix-helper-bot.scm --nick=peach-cobbler --channel='#guix'

<lechner>but guix shell without -D and calling the installed (and wrapped script) bombs

<nckx>☝ that was me.

<nckx>Using your guix shell -f guix.scm -- guix-helper-bot --nick=hot-potato --channel='#guix', no other steps.

<nckx>I didn't even notice the first time :) Expected it to fail.

<lechner>wait, what happened?

<nckx>I accidentally your bot.

<nckx>> hot-potato (~hot-potat@2a02:a03f:881a:1500:2825:426d:cc56:d364) has joined

<lechner>does it crash on images, though?

<nckx>I don't know, I tried to join again, now it did die.

<nckx>Throw to key `irc:network:eof' with args `("Unexpected EOF, closing session.")'.

<lechner>did guix shell -f rebuild when you changed the commit hash?

<nckx> https://tobias.gr/guix.jpg

<nckx>#61234

<peach-cobbler>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<hot-potato>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<peach-cobbler>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<hot-potato>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<peach-cobbler>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<hot-potato>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<peach-cobbler>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<hot-potato>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<peach-cobbler>"[PATCH] gnu: emacs-biblio: Update to 0.3." https://issues.guix.gnu.org/61234

<nckx>Jesus.

<bjc>oh no

<lechner>haha

<nckx>lechner: Told you this would happen one day.

<lechner>please roam freely. i quit mine

<nckx>I assume litharge was just about to pull the trigger.

<lechner>we can try

<nckx>I've bumped the commit, let's see.

<nckx>Indeed, no rebuild.

<nckx>This is a caching problem.

<nckx>If you remove ~/.cache/guix (haven't tested which subdir yet), it will rebuild.

<lechner>it's not cached the version you or i were asking for

<lechner>also, https://codeberg.org/lechner/guix-helper-bot/issues/3

<nckx>winter: Conversely, when I change (gnu build image), ‘./pre-inst-env guix system image -t iso9660 gnu/system/install.scm -d’ does detect the change.

<lechner>nckx / how can it be a caching problem. i am having a crisis. isn't this the whole point of guix?

<nckx>winter: There's a poorly understood failure mode where pre-inst-env will stop picking up local changes when the ‘build’ gets out of sync. Try ./bootstrap && ./configure --localstatedir=/var && make to see if that ‘helps’.

<nckx>lechner: Oh, I agree with you. This is caching at a very high level (‘I see you're running the same command you ran earlier, let me be fast for you’), not something fundamentally Guix-breaking (Guix is still very good at hashing things), but it's still unacceptable.

<lechner>i'd like to turn that off, please

<nckx>I understand. However, your route to finding out how is equal to mine: reading the code to see what is hashed where and how. I don't use ‘guix.scm’. Not going to say I dislike it, but it's never been my jam, and bugs like this don't help.

<lechner>how do you develop?

<nckx>I'm technically working so hunting it down now is not an option :)

<lechner>thank you, i can do the work. but this contradicts a basic expectation, as illustrated by civodul's polite but curt response on the subject earlier. do you have some advice where to start looking? (done ranting)

<nckx>lechner: With other guix commands than ‘guix shell’. I guess I've been lucky. I expected this as little as you did.

<nckx>ACTION away a bit.

<lechner>nckx / okay thanks for confirming. we will find it

<lechner>and sorry to take valuable time away from your employer

<lechner>winter / maybe this bug affects you, too. change code, run old version

<ellysone[m]>hi guix

<jonsger>ACTION not sure how I should like those fancy unicode progress bars. At least in a longer download list with my colour theme it looks bulky...

<lechner>i also feel ambivalent about them.

<lechner>maybe we should show ads instead

<lechner>jesting aside, i also think they divert too much attention

<jonsger>yes, it looks like a censor bar. If they are in multiple lines directly together...

<lechner>right. maybe we need rainbow colors, like Perl's TAP Harness2

<apteryx>is there something better to use in configure/make flags argument to access inputs than the magic variables such as %build-inputs?

<apteryx>cross-building perl-gd fails because %build-inputs is '() in that case (no native inputs)

<apteryx>this-package-input I guess?

<lechner>jonsger / it would be even more dazzling https://youtu.be/uyqP6Prsq38?t=1779

<lechner>or maybe we should gradually paint mona lisa in ascii art while the downloads are happening

<nckx>winter: For later: what's the name of your kernel image? I see no need to postpone adding it upstream, it's an obviously correct change. My own kernel has this list of possible kernels: "^(bz|z)Image$" "^Image\\.gz$" "^vmlinu[^x](|-.*)$" but, since I made that list, it might be inaccurate or incomplete.

<jonsger>lechner: uff, doesn't look healthy watching that stuff...

<lechner>nckx / looks right to me

<lechner>jonsger / i think when push comes to shove you and i feel the same way

<nckx>I wonder what I was anticipating with that [^x]…

<bjc>i was wondering the same thing

<nckx>ACTION away, or their employer will not let them have dinner.

<lechner>i am afflicted with sarcasm, or something similar

<lechner>too loud

<lechner>nckx / vmlinubz2 ?

<jonsger>how do you folks reboot your Guix System servers? "sudo reboot" doesn't work really good for me in the past months and weeks. It throws you out of the SSH session but fails to do a proper reboot...

<lechner>jonsger / can you do it on a terminal?

<lechner>your network may get shut down too early, which can leave some processes stuck in blocking syscalls in the kernel, i think. i have that issue with NFS client

<jonsger>lechner: you mean a virtual console of the BMC/iLO or virtual machine?

<lechner>yeah

<ellysone[m]>would someone be kidn enough to test this?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/3fbea23fd8000b25b96877b8f4230e4aa9ab6d73>)

<lechner>jonsger / it may not tell you that much but i would do it at least once

<winter>nckx: Image

<nckx>Thanks!

<jonsger>mhm, need to try that. It's at least tricky for Hetzner bare metal as you need to request the console via support...

<lechner>ellysone[m] / it produces this error locally https://paste.debian.net/1271986/

<linzer-torte>"debian Pastezone" https://paste.debian.net/1271986

<lechner>jonsger / maybe ask nckx. i only have one linode, and not for much longer

<ellysone[m]>lechner: same thing for me

<nckx>ellysone[m]: Can confirm failure, and success with curl. User-agent sniffing? Probably not deliberate, but seems like the server doesn't like something about Guile…

<nckx>jonsger, lechner: I use ‘sudo reboot’… 🤷

<winter>nckx: Any clue *why* the image isn't bzipped on aarch64?

<ellysone[m]>I have no idea

<ellysone[m]>if i do

<ellysone[m]>the same ocmmand

<ellysone[m]>but with subprocess-tee

<ellysone[m]>it works for the first two packages

<ellysone[m]>then it poops itself

<nckx>You done pooped the channel. Try to send each message separately as you type it.

<lechner>nckx / they can't figure out why they reboot gets stuck. do you recommend doing it over a terminal once instead of SSH?

<nckx>jonsger: What kind of console is this?

<lechner>no console

<nckx>VNC? Serial?

<nckx>> you need to request the console via support

<lechner>i guess "in a console" would have been the proper wording\

<nckx>If you have to request it again for *each boot* while you dial in, say, the console=ttySX to use, that'll get very tedious fast.

<lechner>wow, is that for security?

<ellysone[m]>funny it seems like the python server poops itself every time you try to download more than 2 packages

<ellysone[m]>this works

<ellysone[m]>guix import pypi --recursive pytest-html

<winter>nckx: can you explain the recursive Guix thing? looks like it's just using the store monad?

<ellysone[m]>s/packages/files/

<nckx>So, I use Contabo, which are kind of old-fashioned and at time janky—which I *like*. They give me (virtual) box, not some cloud-inited phantom, with a VNC connection that literally shows the ‘screen’ and whatever was printed to the console hours ago. Also, ‘sudo reboot’ works, which is apparently a premium extra.

<lechner>sudo reboot works on linde

<lechner>linode

<nckx>winter: Some other time. But I didn't mean it wasn't using the store monad.

<jonsger>nckx: for physical machines yes, for VMs of course not...

<jonsger>everything has its price :)

<lechner>i see

<nckx>jonsger: ?

<lechner>it's a real reboot

<lechner>yours

<jonsger>uf, contabo was horrible. Their I/O was bascially not existant, the VM was not usable at all...

<nckx>Yeah mine is great. I use it to offload Guix builds. It's really weird.

<nckx>Maybe I'm the reason everyone else's VM is horrible, but mine's great.

<nckx>But if you think VMs ‘of course’ don't support reboot, I don't know what to say.

<nckx>lechner: If you mean me, no, this is a VPS.

<apteryx>hm, so propagating native inputs may fail for cross-compilation, perhaps

<jonsger>nckx: ehm, of course I can reboot the VM via some button. But why shouldn't that be possible via SSH? I tried it again, this time it worked. Some timing/shepherd whatever issue. Never had that with other distros...

<lechner>nckx / are you sure?

<lechner>jonsger / do you use static networking on that node?

<nckx>jonsger: I think you misunderstood me. I meant, of course you can reboot VMs over SSH, this is ‘just’ a bug.

<lechner>yes, the question is which one

<nckx>jonsger: I've had this on bare metal too, but (1) headless (2) only about ~monthly, so impossible to reasonably debug. ☹

<nckx>lechner: I mean, not at the (Li)node level; ours.

<jonsger>lechner: nope, not on the VM. Didn't got it working...

<nckx>Do you use NFS?

<nckx>Another known shutdown freezer.

<jonsger>nope

<nckx>Drat.

<lechner>jonsger / can you share your config? mirai and apteryx may also have to say something about that

<jonsger>nckx: the virtual console was full of "kex_exchange_identification: banner line contains invalid characters" messages before I rebooted hard via the VM console button

<apteryx>ACTION is trying to make perl-gd cross-buildable

<jonsger>lechner: https://gitlab.com/jonsger/jonsger-guix/-/blob/master/config/baebia.scm

<linzer-torte>"config/baebia.scm · master · Jonathan Brielmaier / jonsger-guix · GitLab" https://gitlab.com/jonsger/jonsger-guix/-/blob/master/config/baebia.scm

<lechner>jonsger / https://serverfault.com/questions/1015547/what-causes-ssh-error-kex-exchange-identification-connection-closed-by-remote

<nckx>jonsger: Failed SSH bot login attempts.

<lechner>or that

<jonsger>okay, they seem to nowadays also try at port 2123 :(

<nckx>Heh, was that some big provider's ‘new, secure’ non-default customer SSH port? :)

<nckx>lechner: Yours was more accurate, I was sloppy & typed ‘login’ out of habit, should have been ‘connection’.

<apteryx>we need 'propagated-native-inputs' ;-)

<nckx>>:(

<nckx>Is the core-updates bootstrap expected/likely to succeed at this point on x86_64?

<nckx>As in, anyone done it?

<nckx>I don't quite have the resources to ‘just try’ but if it's likely to work I would.

<lechner>jonsger / nothing stick out at me. i might try network-manager (or connman) instead of dhcp-client-service-type. against my better judgment, i have had most success with that, although it will pull in a lot of extra stuff.

<jonsger>on my bare metal server I have/had this problem as well. There I'm already on static-network. Need to check if the problem still occurs there...

<lechner>jonsger / is everything getting started (or mounted) at boot?

<mirai>ass connection

<sneek>Welcome back mirai, you have 1 message!

<sneek>mirai, lechner says: / for the bot, i don't think a 'HEAD request returns the HTML page title

<mirai>spectacularly bad today

<lechner>mirai / hello!

<lechner>we have another case with networking problems on shutdown. please meet jonsger

<lechner>sorry about your day

<mirai>lechner: indeed, that was a mistake

<mirai>though you can get the mime type I think>

<mirai>what was this NFS thing that got mentioned above?

<lechner>mirai / i did https://codeberg.org/lechner/guix-helper-bot/commit/e785372b5f600a9e60f4a19d4f73150b0460815b

<linzer-torte>"Try to get page titles only from Content-Type: text/html. · e785372b5f - guix-helper-bot - Codeberg.org" https://codeberg.org/lechner/guix-helper-bot/commit/e785372b5f600a9e60f4a19d4f73150b0460815b

<mirai>probably missed the convo

<lechner>no NFS, but problems shutting down

<lechner>i said it's the network

<lechner>other theories involve shepherd more generally

<mitchell>I sent a patch with the blog post to guix-patches@gnu.org and got a confirmation email but it hasn't shown up in the mailing list... Should I just be patient?

<mirai>lechner: the idea of http-head is that you could skip fetching the body if the mimetype is uninteresting

<ellysone[m]>is there documentation or something to install guix on a remote dedicated server from rescue mode?

<ellysone[m]>I currently have a kimsufi box and I wanted to dl the guix binary and install the system as if it was like other machine

<lfam>mitchell: It usually appears shortly

<mirai>ah, about NFS

<ellysone[m]> * is there documentation or something to install guix on a remote dedicated server from rescue mode?

<ellysone[m]>I currently have a kimsufi box and I wanted to dl the guix binary and install the system as if it was like other machine

<ellysone[m]>I know I could juste the guix iso from that mode, but I'm looking for something automatable

<mirai>here's my current incantation

<ellysone[m]> * is there documentation or something to install guix on a remote dedicated server from rescue mode?

<ellysone[m]>I currently have a kimsufi box and I wanted to dl the guix binary and install the system as if it was like other machine

<ellysone[m]>I know I could just use the guix iso from that mode, but I'm looking for something automatable

<lfam>zram users: what do you think about this new kernel option "enable multi-compression streams"? https://cateee.net/lkddb/web-lkddb/ZRAM_MULTI_COMP.html

<linzer-torte>"Linux Kernel Driver DataBase: CONFIG_ZRAM_MULTI_COMP: Enable multiple compression streams" https://cateee.net/lkddb/web-lkddb/ZRAM_MULTI_COMP.html

<ellysone[m]> * is there documentation or something to install guix on a remote dedicated server from rescue mode?

<ellysone[m]>I currently have a kimsufi box and I wanted to dl the guix binary and install the system as if it was like other machine

<ellysone[m]>I know I could just use the guix iso from that mode, but I'm looking for something automatable

<ellysone[m]>basically I'm asking for an unattended install, a preseed or smth

<bjc>ellysone[m]: please stop spamming the channel

<ellysone[m]>bjc: what? I just asked a question

<lechner>it appeared three times

<mirai>bjc: I think its the message editing

<bjc>in 4 lines, 3 times. maybe your matrix client is broken

<ellysone[m]>I'm on the web app of matrix

<mirai>when you edit the message with matrix it resends it for IRC

<lechner>ellysone[m] / maybe this helps https://guix.gnu.org/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html

<linzer-torte>"Running Guix on a Linode Server (GNU Guix Cookbook)" https://guix.gnu.org/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html

<lfam>The answer is "not really", ellysone[m]. You need to make some choices about filesystems and partitioning, and that can't be automated

<ellysone[m]>oh sry was not aware of that

<lfam>Instead, you could build a Guix System image and just boot that on your server, rather than "installing" it

<mirai>lechner: apteryx : try this https://paste.centos.org/view/6a32bfa2 NFS incantation

<mitchell>If you can do a manual install with the iso then you might think about creating a new operating system declaration from it which installs the payload os

<linzer-torte>"Untitled - Pastebin Service" https://paste.centos.org/view/6a32bfa2

<mitchell>It is a bit more involved and there are not any examples of how to do this. I've been trying to create such a thing for my self

<mirai>lechner: apteryx : note that #61587 makes the whole network manager business unnecessary

<linzer-torte>"[PATCH 0/8] networking services refactoring" https://issues.guix.gnu.org/61587

<jonsger>ACTION not sure if he likes linzer-tore other then issues.guix.gnu.org

<lechner>mirai / love the snipped. what's holding up the bug merge?

<lechner>snippet

<mirai>a review

<ellysone[m]>lfam: kimsufi does nat have bring your own device feature :(

<lfam>jonsger: Same

<mirai>it has some potential for controversy among some of the commits but the whole series is cherry-pickable

<lfam>jonsger: A bit spammy IMO

<lechner>ellysone[m] / i bet that can work

<jonsger>e.g. "Untitled - Pastebin Service" https://paste.centos.org/view/6a32bfa2 isn't that helpful

<linzer-torte>"Untitled - Pastebin Service" https://paste.centos.org/view/6a32bfa2

<jonsger>"[PATCH 0/8] networking services refactoring" https://issues.guix.gnu.org/61587 is helpful

<linzer-torte>"[PATCH 0/8] networking services refactoring" https://issues.guix.gnu.org/61587

<lfam>ellysone[m]: I see. Yeah, it's not so easy to install the OS automatically. Maybe we could implement some logic in the installer about guessing about the partitions. It would require some thought / advice from interested users. That's you! :)

<lechner>jonsger / it was meant for me

<lechner>ellysone[m] / you install debian and then pivot as in gnucode's post

<lechner>mirai / what would i do with those cherry-picks?

<lechner>always run the git clone instead of stock guix?

<ellysone[m]>lechner: well that's what I was doing but if feels kinda meh

<mirai>lechner: I meant that the patch-series doesn't have to be merged in its entirety

<ellysone[m]>lfam: basically this but in scheme https://www.debian.org/releases/buster/example-preseed.txt , I'll try a hack when I get enough time

<lfam>I'm curious, do other distros make this possible, ellysone[m]? Maybe we could just copy what they do

<mirai>maintainers could selectively skip some of them if they're too taboo for guix

<lfam>Thanks!

<lechner>mirai / which parts do you perceive as controversial?

<ellysone[m]> https://paste.debian.net/1271995/

<ellysone[m]>This is what I have currently

<linzer-torte>"debian Pastezone" https://paste.debian.net/1271995

<mirai>lechner: the canonical-name ones are likely to raise some eyebrows

<mitchell>lfam: The installer is implemented as a list of lambdas, so-called install steps. The newt based installer currently runs the nice GUI that helps you step through the installation. I think it should be possible to make another installer which doesn't require user input but can be staged with a desired file system layout and make it happen before calling guix system init to instantiate a prestaged operating system

<mirai>the rest I believe shouldn't raise any issues

<mirai>it doesn't break workflows afaik (it actually fixes the nearly worthless 'networking service)

<bjc>an automated pxe/usb-based installer would be pretty nice

<lechner>mitchell / i'd love to see that for my openwrt routers. they should be powerful enough for Guix

<mirai>it's not completely worthless because static-networking can actually make that thing "work"

<ellysone[m]>My goal was to deploy everything from guix, but currently I have a colllection of shell scripts/guile and pulumi config + some ansible which is a shame.

<mitchell>ellysone[m]: it's tough out there

<mirai>anything else and you might as well use 'loopback

<lechner>mirai / right

<mirai>its been broken for a long time afaik, judging some threads and bug reports in guix MLs

<mitchell>lechner: I would love for guix to replace openwrt on my router. I installed that thing like 3 years ago and I can't figure out how to update it short of downloading a new iso and starting from scratch.

<mirai>though it makes things right for NM users, connman users = no idea

<mirai>it doesn't break connman but a cursory search didn't reveal any similar feature to nm-online

<mirai>so that one remains "potentially" broken

<lechner>mitchell / get a more recent version and then run opkg upgrade auc luci-app-attendedsysupgrade https://fabianlee.org/2023/01/09/openwrt-more-convenient-sysupgrade-using-attended-sysupgrade/

<lfam>mitchell: You didn't ask, but you can update OpenWRT relatively easily by downloading the sysupgrade file and then using it via the web interface

<lfam>It's not too bad

<mitchell>thanks for the tip!

<mitchell>still guix would be nice

<lechner>+1

<lfam>The truth is you won't get good performance with Guix, since consumer routers require proprietary firmware in order to achieve high performance

<mitchell>I set this network up a while ago and it's kind of complicated and I don't remember all that I did

<mitchell>If I had a router.scm for it life would be great

<lechner>yeah

<lfam>There's a reason you can push gigabits per second through these 5 watt CPUs that are clocked in megahertz

<lechner>i could invest some time. i always buy used routers, and last time i bought two

<mitchell>It's true but I am a firmware engineer so if it gets annoying enough I might do something irrational

<lfam>Magic sauce

<lfam>Oh, then you understand

<lechner>maybe you can recommend a cheap JTAG

<mitchell>jlink edu is pretty good. Like $50 last i checked some years ago

<mitchell>Just don't do anything proprietary with it!

<mitchell>There are some LPC boards which can be made to act like jlinks which are around $20 but they are way jankier

<lechner>my router has u-boot and a usb port. i have an extra box for experiments.

<lechner>mirai / can i run a Git checkout with my own channels?

<jonsger>does this command keep-going for you: https://paste.debian.net/plain/1271998 for me it stops always with "guix build: Fehler: build of `/gnu/store/a6sj63shblc5kd63d3dhfc35jxslpgjb-rcas-web-0.1.0.drv' failed" instead of keep going and trying the other packages to build...

<lechner>mitchell / thanks! have you seen this paper about reusing old phones? how about Guix? http://parallel.princeton.edu/papers/hotcloud17-paper-shahrad.pdf

<bjc>i wouldn't buy a jtag, tbh. for almost everything you can use a cheap stlink or some other daplink debugger for a few bucks which will work on almost all arm boards

<bjc>if you really need jtag, bitbang it with openocd on an rpi. i have an original rpi that does it just fine

<mitchell>bjc: this is correct! Many of my collegues get by just fine using this method

<mitchell>I only ever needed the more expensive stuff when my code got too complicated and i had to debug really subtle timing issues. But don't write bad code and you'll be fine!

<bjc>i've never used an official jtag debugger, so i'm curious how it helps with timing issues. when i need to figure that stuff out i use a cheap sigrok

<mitchell>High speed traces

<mitchell>they can just get data off the chip faster

<mitchell>It can be handy when you are dealing with stuff running on an fpga for example. JTAG can have multiple chips chained together so you can get data from all of them over the same bus

<mitchell>Plus they come with licenses for pr*prietary software which some people find useful.

<nckx>jonsger: That is prohibitive to try, but could it be related to grafts? Does it happen with --no-grafts?

<bjc>ah. that's definitely above my pay grade. i only ever debug with one chip at a time, and i still haven't messed with fpgas. maybe one day

<mitchell>bjc: Me too, what I learned while going down this route is it's a mistake to begin with. Use the JTAG to do the boundry scan to make sure the hardware works, but there are many ways to debug these more complicated systems and it begins with writing software you can actually debug

<nckx>ellysone[m]: <rescue mode … dl the guix binary and install the system as if it was like other machine> is how I install all my Guix System VPSes. I've never messed with the installer or automation, though.

<bjc>sound advice, regardless of domain =)

<nckx>ellysone[m]: Beyond ‘binary installation’, then following the installation steps in the manual (adjusting for things like no cow-store), I'm not sure what more documentation you need?

<ellysone[m]>nckx: I was just looking for best practices

<nckx>I don't think we have those…

<mitchell>lol

<mitchell>Whatever you do make sure you write it down so when it comes time to make best practices we have stuff to compare

<nckx>Now that's a truth.

<lechner>there may be some find points regarding the bootloader. For example, Linode provides a direct hook into grub.cfg

<apteryx>mirai: nice hack for the centos link

<bjc>didn't i see some traffic on the ml a bit ago about guix+cloud-init?

<nckx>lechner: Oof, but also the least evil way you could bypass the customer's boot loader. I'll allow it.

<nckx>Kimsufi is discount OVH, right?

<lechner>it scared me initially but it it works really well. i think it was a customer service decision

<ellysone[m]>anyone looked at sourcehut, packaging it? I gave up when I saw there was go(IIRC the sgo importer still needs work) and python, and so I've gone back to alpine for that

<nckx>I used Guix System on OVH *looong* ago. I don't remember any weirdness like skipping the bootloader. But that was at least a generation of machines ago.

<lechner>i have never seen it elsewhere

<ellysone[m]>nckx: yes sir

<bjc>iirc, sourcehut has a *lot* of dependencies and inter-related services who's relationships are not well specified

<lechner>hence (installer #~(const #true)) here https://guix.gnu.org/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html

<linzer-torte>"Running Guix on a Linode Server (GNU Guix Cookbook)" https://guix.gnu.org/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html

<bjc>i looked at it a while back and the docs were basically a giant shruggie

<apteryx>mirai: is there a precedent for the shepherd-requirement naming? otherwise perhaps shepherd-requirementS would be better

<apteryx>(it's a list)

<mirai>apteryx: there is, nginx, opensmtpd, mpd? I think are some of them

<ellysone[m]>bjc: yeah, it's a shame cuz I do really like it, but I feel like the easy way is to just go gitea, someone packaged it for guix IIRC

<apteryx>mirai: OK!

<bjc>there's codeberg or whatever now that gitea has gone rogue

<bjc>i just host all my stuff in cgit, because i hate making things easy for other people =)

<apteryx>gitea has gone rogue?

<ellysone[m]>bjc: how so?

<bjc>yeah, a few months ago there was a big stink because the guy who owned the trademark staged a coup

<bjc>not, like, a real coup, but a hostile takeover of the project

<florhizome[m]><bjc> "iirc, sourcehut has a *lot* of..." <- Sourcehut services are a mixture of python, go and js

<florhizome[m]>I stopped working on a package for the core service when I noticed I needed a bunch of js stuff injected somewhere in there and I was not sure how to do it

<mitchell>lechner: I think many of these low-power phones they are talking about purchasing for their computing power are perfect targets for zephyr. Zephyr can be a unified target which spans the hardware discrepancies between the high and low ends of mobile market. I have some code which can deploy the firmware produced by the zephyr-build-system to applications running the zephyr smp server over some interface. I have the beginnings of a

<mitchell>service definition which can ensure the right firmware is deployed and take action to correct it. This can be extended by another service which actually implements the distributed computing algorithm

<lechner>i'd be happy just to see the pile boot. that would be the pile next to me, even though i don't even use cell phones personally

<bjc>zephyr uses meson+ninja, right?

<mitchell>zephyr using cmake and whatever you tell it to. A lot of people like ninja but I use make in the build system

<mitchell>plus a handful of python scripts

<bjc>hmm. ok. i never wrapped my head around its build system

<mitchell>you might enjoy my next blog post then

<bjc>lemme know when it's out. i've always been mildly curious about it

<bjc>for the most part, my embedded projects are rust. but there's no ble library for rust that you can actually use

<mitchell>the code for it is here https://github.com/paperclip4465/guix-zephyr

<linzer-torte>"GitHub - paperclip4465/guix-zephyr: GNU Guix zephyrRTOS integration" https://github.com/paperclip4465/guix-zephyr

<bjc>ah, right, "west"

<mitchell>I have not got around to rust yet. It seems like C is here to stay for a while, at least in my section of the universe

<bjc>the advantage of it being a hobby is that i can use whatever i want =)

<lechner>mitchell / why were some folks surprised earlier that your repo is public, please?

<mitchell>who was surprised?

<mitchell>Why shouldn't it be public?

<lechner>it though nckx was, but i may have misunderstood. it's a common occurrence between us since we were separated at birth

<nckx>I don't remember this either.

<lechner>ACTION is going to clean his dentures and watch some TV

<nckx>If you're referring to <https://logs.guix.gnu.org/guix/2023-02-23.log#201859>: I sent the message asking whether the repository mitchell was troubled with was public, right before they pasted the URL. It arrived after. My connection was, as someone more articulate than I has written, ass.

<mitchell> https://docs.zephyrproject.org/3.2.0/build/cmake/index.html

<linzer-torte>"IRC channel logs" https://logs.guix.gnu.org/guix/2023-02-23.log#201859

<nckx>lechner: ‘…and I'm taking my bot with me!!’

<mirai>does the bot use 'fibers'

<mirai>it'd be a nice fit for it (or erlang)

<nckx>It would be ironic for a pastry-themed bot.

<lechner>the bot is currently 55 lines of code or so, so the answer is: no yet

<lechner>we can do veggies

<mirai>have the "parser" and the irc client run in its own bubbles

<nckx>ACTION bran-flake has joined.

<nckx>lechner: Do you know what caused this crash, assuming it was a crash?

<mirai>there's quiche aux épinards ?

<nckx>ACTION is very tempted to have (gnu build image) import (gnu system) and (guix packages) but it feels like a bad idea. Is it?

<lechner>yeah, an HTML entity in the title. An emdash, to be specific

<nckx>Typography strikes again.

<mirai>the title can contain arbitrary characters after all

<lechner>actually, i think SXML should provide conversion to text, but i cannot find it https://codeberg.org/lechner/guix-helper-bot/src/branch/history/scm/scan/generic-urls.scm#L48

<mirai>in arbitrary encodings as well =)

<lechner>here is the backtrace https://paste.debian.net/1272002/

<nckx>This is how a 55-line bot starts. ‘Oh, right, we need to parse the encoding header, and probably the HTML meta one just in case…’

<lechner>btw, can you folks paste unicode via debpaste-paste-buffer ? https://codeberg.org/akib/emacs-eat/issues/39

<nckx>TIL debpaste.el.

<nckx>guix install emacs-debpaste → guix install: error: path `/gnu/store/ga2kklnyir3sbkv42si7l94m4kr2ps5w-nmap-7.93' is not valid

<nckx>Might've borked my store again.

<lechner>send it to me

<nckx>What kind of dump are you asking for, anyway? Can I just ‘find /gnu/store’ and PM it to you?

<nckx>I won't do it on this machine, since it contains non-Guix (!nonguix) packages, but I could do it elsewhere.

<lechner>i will take anything. we can clean the data later

<lechner>it's easier on the database level i think

<nckx>Oh.

<nckx>Well that's the thing that's corrupted, so joke's on you.

<apteryx>ugh, search paths cannot be conditionalized upon %current-target-system, as they are not thunked

<apteryx>ACTION tries making them thunked

<civodul>better avoid thunking one more field

<civodul>cause it's multiplied by 22k packages

<apteryx>does it cause more memory to be used?

<civodul>more memory, more work in general

<apteryx>OK. Hm. Then I'm out of ideas for fixing cross-compilation of perl-gd

<apteryx>which I think recently got dragged in with the use of unifont

<civodul>oh i was looking at it

<civodul>apparently it got pulled in some system dependency?

<lechner>nckx / it's a little annoying right now http://paste.debian.net/1272006

<lechner>nckx / my Pg database

<apteryx>civodul: that was my idea so far: https://paste.debian.net/1272007/

<ekaitz>nckx: (i missed your last message) looks like all the other things are mitigated

<apteryx>to avoid propagating pkg-config

<bjc>does guile have a srfi-64 or srfi-78 testing library?

<nckx>ekaitz: Great.

<apteryx>civodul: yes, I'm guessing by the use of unifont in TTYs (01334a61c7541d8ae29c5252e2e5b3ed7a59c552)

<nckx>lechner: Thanks. I'll take a look later.

<nckx>ACTION notes the expiry deadline of the paste.

<nckx>Clever trick.

<apteryx>bjc: it does (srfi-64)

<bjc>ah, i thought i already looked and didn't find it

<bjc>great!

<lechner>ACTION recommends guile-tap, which is unfortunately not srfi compliant

<bjc>honestly, i don't really care *that* much what's used. because my next quistion is: how much teeth pulling would it take to get shepherd's unit tests out of bourne shell and into something reasonable? =)

<bjc>i'm willing to do the work, but my track record with getting anything but trivial patches into guix and shepherd is not great

<lechner>i have use TAP for billions of tests in Perl and recommend it warmly

<bjc>(and even some trivial ones)

<apteryx>civodul: guix graph --path font-gnu-unifont perl-gd confirms it

<bjc>maybe i should ask the mailing list instead

<lechner>this one is complex, because it creates the tests dynamically https://codeberg.org/lechner/guile-naptcha/src/branch/history/scm/test/naptcha/pseudo-random.scm#L26

<apteryx>civodul: instead of thunking things, could we defer global evaluation of packages until %current-target-for-system is set?

<apteryx>then the pkg-config syntax could be used reliably anywhere, not just as inputs

<civodul>wait, to fix the perl-extutils-pkgconfig situation, the natural solution would be to use the same trick as for pkg-config, no?

<apteryx>mimick the syntax pattern?

<apteryx>*mimic

<civodul>yes

<apteryx>that'd work I guess!

<apteryx>yeah, since one is syntax the other one must be syntax too

<civodul>that said, an even better option would be something local to perl-gd

<civodul>or get perl-gd out of the way, somehow :-)

<civodul>apparently it became a problem recently for people cross-compiling systems

<civodul>as in "guix system image --target=..."

<apteryx>yep, that's what I was trying

<civodul>do you know how that got pulled in?

<apteryx>I think it out to be cross-compilable in any situation, so a fix seems a welcome improvement

<apteryx>yes, read back what I wrote above :-)

<civodul>ah, lemme see

<civodul>oh, lots of things in https://paste.debian.net/1272007/

<civodul>hmm

<winter><nckx> winter: There's a poorly understood failure mode where pre-inst-env will stop picking up local changes when the ‘build’ gets out of sync. Try ./bootstrap && ./configure --localstatedir=/var && make to see if that ‘helps’. <-- Running this now -- was I supposed to run make before ever using pre-inst-env? Manual only mentions

<winter>bootstrap and autoconf...

<nckx>Uhm. Yes, yes you were.

<winter>Oh.

<mitchell>lol

<winter>in my defense the manual never mentioned it, either that or i missed it the 3 times i went back and read t

<winter>s/t/it

<nckx>I've heard that claim before about the manual. I don't think it's true, but I guess there's some path you can take that leads you past make?

<winter>lemme show you:

<mitchell>More runnable examples are always a good thing

<nckx>Or I'm misremembering.

<mitchell>describing them will never do it justice

<winter> https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html#Running-Guix-Before-It-Is-Installed

<flan-de-leche>"Running Guix Before It Is Installed (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html#Running-Guix-Before-It-Is-Installed

<winter>> To do that, you first need to have an environment with all the dependencies available (see Building from Git), and then simply prefix each command with ./pre-inst-env (the pre-inst-env script lives in the top build tree of Guix; it is generated by running ./bootstrap followed by ./configure).

<lfam>It is true that the manual doesn't say `run make`, but the experience of using 'pre-inst-env' without running `make` is so slow that I think most of us just do it anyways

<lfam>Like, this manual section comes after the section "Building From Git", so it's assumed that you have "built Guix"

<winter>speaking of, I think the shell examples in Building from Git probably shouldn't pass --pure -- it, IME, breaks pre-inst-env

<mitchell>An outsider who has never used something like `pre-inst-env` might not understand what it is or where it comes from though

<nckx>‘Finally, you can build Guix’ … → make

<mitchell>great!

<lfam>One problem is that these sections are separate, and many don't read the prior section

<nckx>So yeah, if you don't follow the ‘To do that, you first need to have an environment with all the dependencies available (*note Building from Git::)’ link, you can get into this situation.

<winter>I wonder if pre-inst-env could be fixed to detect this failure mode.

<nckx>It is *technically* user error but we should not make it so easy to skip.

<winter>87%

<winter>wee

<nckx>Either repeat ‘make’ here, or say, no, bud, you really NEED an environment… etc.

<winter>If pre-inst-env is slow without running make (why?), wouldn't it make sense to just run make in pre-inst-env?

<lfam>Yeah, it's a bit too confusing for new users

<lfam>There are reasons, winter

<mitchell>It's a tough balance to strike between repeating yourself too many times and not assuming the person read anything before in their life

<unmatched-paren>winter: it's slow because you'll be running guile in interpreter mode :)

<nckx>winter: That's not the point of pre-inst-env, and/or would be too suprising unwanted.

<nckx>Bias: I wouldn't always want this.

<lfam>But overall, remember that this is a tool for developers, and as such for people who are assumed to have some know-how in this area

<unmatched-paren>make just compiles all the .scm files into .go files first

<winter><nckx> Either repeat ‘make’ here, or say, no, bud, you really NEED an environment… etc. <-- ah, misread

<lfam>Know-how can be acquired by asking here :)

<lechner>what if ./bootstrap issued 'make'?

<mirai>lfam: reducing the bus factor is a good thing

<lfam>Like, I think that 99% of us learned how to use 'pre-inst-env' by asking here

<apteryx>civodul: I meant the IRC scrollback

<nckx>winter: Oh, I can totally see how. Hence the big fat *technically*. 😉

<apteryx>civodul: font-gnu-unifont

<lfam>There's a lot of good things

<nckx>Also explains why I remembered it being documented perfectly cromulently, and you didn't.

<winter><nckx> winter: Oh, I can totally see how. Hence the big fat *technically*. 😉 <-- I meant I misread your message as having pre-inst-env repeat (run) make, or throw.

<nckx>We all take different paths, in Texinfo as in life, and some of those paths suck a little.

<unmatched-paren>i think we should add -j$(nproc) to all the examples telling you to use ``make'', too

<unmatched-paren>it's *excruciatingly* slow otherwise, for the obvious reasons :)

<lfam>'pre-inst-env' is definitely a hack that took a life of its own

<lechner>you can just use make -j

<winter>yeah

<unmatched-paren>lechner: wait really? huh

<lechner>the scheduler is pretty good

<lfam>It's fragile and not very Guix-y

<mirai>fun fact

<winter>> Git error: cannot locate remote-tracking branch 'origin/keyring'

<lfam>'pre-inst-env' that is

<winter>That'sa a newone

<mirai>make -j8 check "works" but gets you a strange message that you don't get with plain "make -j8"

<nckx>lechner: That launches unlimited jobs.

<winter>i just nuked `~/.cache/guix` too

<mirai>make: INTERNAL: Exiting with 361 jobserver tokens available; should be 8!

<nckx>Great if it works for you, not so great if it doesn't.

<lfam>`git checkout --track origin/keyring && git checkout $wherever_you_were`

<lechner>nckx / like i said, linux has a scheduler. and they are not unlimited. it's just many

<nckx>-j$(nproc) can still lead to nasty suprises but at least cores are generally corrolated with RAM.

<apteryx>ACTION tests a solution

<winter>oh this is also in the manual

<winter>god damnit

<winter>lol

<nckx>lechner: Unlimited does not mean infinite, it means as many as possible.

<winter>sorry, i should just nuke my checkout and read it top to bottom

<lechner>my exec-env kernel module will get rid of pre-inst-env

<nckx>I think we're all familiar with Linux's scheduler and hence weary of dumping unlimited jobs onto it.

<civodul>apteryx: there are several issues: pkg-config isn't designed with cross-compilation in mind, to cross-pkg-config is a hack (a conventional hack) to work around that; the perl-extutils-pkgconfig invokes "pkg-config", not "TARGET-pkg-config", so it won't benefit from cross-pkg-config anyway

<winter>I wonder why I never got the keyring error when doing pre-inst-env without building Guix first

<apteryx>civodul: I've patched it in above diff

<apteryx>now combined with macrology

<lechner>i also plan to propose a technology that will make pkg-config obsolete for much of Guix's prerequisite handling

<unmatched-paren>lechner: sounds exciting :)

<winter><winter> I wonder why I never got the keyring error when doing pre-inst-env without building Guix first <-- maybe some pre-inst-env detection magic? hm.

<apteryx>civodul: it made it to link (cross-build): ld: cannot find -lgd

<apteryx>probably because the build system doesn't expect CROSS_*

<civodul>apteryx: looks like that's because it invokes gcc instead of TARGET-gcc

<apteryx>so it's down to perl-build-system not supporting cross-compilation

<apteryx>nix as some "experimental" support for it, but i can't seem to find the module

<winter>ooh, something i can help with

<civodul>not sure, i'd say it's this one package that has problems

<civodul>or at Perl packages with C code

<civodul>s/at/

<apteryx>civodul: yes, perl with native extensions

<apteryx>it's written as not supported in our perl.scm

<civodul>oh ok

<civodul>well, confirmed :-)

<apteryx>"it is currently not known how to tell Perl to properly cross-compile"

<winter> https://github.com/NixOS/nixpkgs/blob/988cc958c57ce4350ec248d2d53087777f9e1949/pkgs/development/interpreters/perl/default.nix#L216 apteryx

<flan-de-leche>"nixpkgs/default.nix at 988cc958c57ce4350ec248d2d53087777f9e1949 · NixOS/nixpkgs · GitHub" https://github.com/NixOS/nixpkgs/blob/988cc958c57ce4350ec248d2d53087777f9e1949/pkgs/development/interpreters/perl/default.nix#L216

<winter>maybe this'll help a bit?

<winter>we use a fork(?) of Perl when cross-compilin

<winter>g

<civodul>same here, but that's for Perl itself, isn't it?

<apteryx>there's some crossCompiling conditional patching/inputs going on

<winter><apteryx> nix as some "experimental" support for it, but i can't seem to find the module <-- where did you see this?

<apteryx>in nix's doc

<civodul>apteryx: so looks like the system cross-compilation regression comes from 01334a61c7541d8ae29c5252e2e5b3ed7a59c552

<flan-de-leche> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=01334a61c7541d8ae29c5252e2e5b3ed7a59c552

<apteryx>bottom of perl.section.md

<apteryx>civodul: yes, that's the one

<apteryx>so I think I've got part of the puzzle covered, the other part would be making our Perl cross-compiling aware

<jonsger>nckx: nope, --no-grafts doesnt help

<apteryx>could try a perl-for-cross-compiling and ajust the perl cross-builder

<winter>apteryx: https://github.com/NixOS/nixpkgs/commit/306d5cdf03ad6375861a20b8885ef38699ca3c23

<flan-de-leche>"perlPackages: Add cross-compilation support. · NixOS/nixpkgs@306d5cd · GitHub" https://github.com/NixOS/nixpkgs/commit/306d5cdf03ad6375861a20b8885ef38699ca3c23

<winter>hmm, now pre-inst-env Guix is trying to connect to a nonexistent daemon socket, but normal installed Guix works fine.

<winter>notably i'm not in a pure shell, so... not sure what's up

<winter>ah, --localstatedir

<civodul>apteryx: hey look: https://paste.debian.net/1272015/

<flan-de-leche>"debian Pastezone" https://paste.debian.net/1272015

<civodul>after all, we don't need to cross-compile the font, right?

<apteryx>:-D

<apteryx>awesome!

<civodul>it seems to work, right?

<apteryx>I guess it will! I'll try it.

<apteryx>there's another reference as #$ too

<apteryx>for "kmscon virtual terminal"

<apteryx>line 2578

<civodul>ah right, we can change it too

<patched[m]>How can one go about finding which package one has that depends on another package? I want to get rid of gcc from my profile, I have removed gcc, gcc-toolchain, g++... But gcc persists, and it is located in a gcc package in the store.

<mitchell>is it libgcc?

<mitchell>shouldn't be in the profile though

<apteryx>civodul: I'm building the image, it's proceeding further

<civodul>apteryx: actually there's an even better fix, already used in a few places: disable cross-compilation of font-gnu-unifont altogether

<civodul>testing...

<patched[m]>mitchell: No libgcc found in my profile

<civodul>we should probably do that more often

<mitchell>there is a way using guix graph

<winter><civodul> actually there's an even better fix, already used in a few places: disable cross-compilation of font-gnu-unifont altogether <-- as in stopping it to built entirely, or just plucking the output from a native build?

<mitchell>to find which package is causing another to be included but I do not know it off hand

<winter>*build

<civodul>winter: taking the output of a native build, since we know it's the same

<winter>neat

<civodul>hmm actually no because font-gnu-unifont also ships binaries

<civodul>so, back to the initial #+ fix :-)

<winter>isn't that still taking the native build output?

<civodul>it is, but only for the font bits (not the "bin" output)

<patched[m]>mitchell: Thanks, I will look into it tomorrow

<winter>ah, font output is default?

<civodul>that package has many outputs, and "bin" is one of them

<winter>i understood

<winter>oh, `pst`

<winter>*psf

<winter>hm, wonder why "Updating channel guix from Git repository at /my/local/checkout" is receiving objects and completely reauthenticating things. guessing the daemon is doing it now

<winter>though you'd think it would have it cached after a guix pull

<civodul>it's cached under ~/.cache/guix/authentication

<winter>right, but it was before this

<winter>and `guix authenticate` previously exited instantly on same HEAD

<winter>hm now it's rebuilding a bunch of stuff (e.g. guix-packages-base), did a lot of things get updated in the last 24h or something

<winter>or glibc i guess

<winter>lol

<winter>hm, nothing stands out from the log

<winter>wonder what happened

<winter>maybe because i touched guix itself

<alextee>hi, someone sent a patch to update zrythm: https://issues.guix.gnu.org/61423

<flan-de-leche>"[PATCH 0/6] gnu: zrythm: Update to 1.0.0-beta.4.5.62" https://issues.guix.gnu.org/61423

<alextee>LGTM, other than updating carla to an unreleased commit. perhaps that should be a separate package definition

<alextee>would be appreciated if someone has time to look at it, current zrythm version on guix is ancient

<civodul>alextee: hi, long time no see! ;-) also, would you recommend waiting until a non-beta version is available?

<sharlatan>Hi!

<civodul>howdy sharlatan!

<sharlatan>Who is familiar with Guix QA?

<alextee>civodul, hi! I'd say it's pretty stable already (certainly way more stable than the guix alpha version) so it can be merged. don't have an ETA yet for non-beta

<civodul>alright

<civodul>sharlatan: depends; ask your question and we'll see :-)

<winter>cool, now the kernel loads, but it can't find the partition...

<winter>hm.

IRC channel logs

2023-02-24.log