IRC channel logs


back to list of logs

<cmiller>Maybe not Guix but Linux Libre. maybe they can help?
<peanuts>"::[FSFLA]:: GNU Linux-libre project"
<lispmacs[work]>but they just add Scripts to the kernel right... not provide support
<Tadhgmister>is there any database for hardware that works with free kernel drivers? I'm certain several exist for specifically wifi cards but I'm wondering if theres somewhere that also covers CPUs that you could consult
<cmiller>lispmacs[work]: Actually I don't know. I may thought they have some IRC channel as well since as I said, I doubt that Linux is helping if you have a complete modified kernel that throws away tons of drivers that may be needed.
<peanuts>"home -"
<Kolev>cmiller: Linux Libre has an IRC channel: #gnu-linux-libre
<cmiller>lispmacs[work]: Maybe ask on the IRC channel Kolev mentioned?
<lispmacs[work]>cmiller: I might do that. I'm see first if I can narrow down the driver. It was working on linux libre 6.7 so must have been a driver that was dropped or modded in 6.8. Installing libre-linux source to look for a change log or something
<lispmacs[work]>the Web site news shows:
<lispmacs[work]>"Dropped cleaning of upstream-removed drivers atmel, hermes, orinoco_usb, libertas_cs, zd1201. Cleaned up drivers for Intel qat_420xx, Imagination PowerVR, Intel Xe, Chips&Media Wave5, Intel VSC, Aquantia PHY, Realtek rtw8922a. Updated cleaning up of coda. Cleaned up blob names in new ARM and AArch64 devicetree files. Adjusted wording in .deb packaging. Attempted fix for i915."
<lispmacs[work]>for 6.8
<efraim>looks like we don't have a list for 64bit-system
<efraim>for the purposes of correctness, is there a flag I can pass that will force an architecture to interpret an int as twice as big?
<Tadhgmister>efraim: why? if there was a way after compilation it'd break every code that does `sizeof(int)` so it'd have to be before build time
<efraim>oh, I found %64bit-supported-systems in guix/packages
<efraim>Tadhgmister: before I mark this software 64-bit only I wanted to see if I could force it to build without writing a large patch
<Tadhgmister>ahh, gotcha
<Tadhgmister>in the guix docs section 12.3.1 Btrfs file system there is a sentence "The Guix System produces a bootloader configuration using the operating system configuration as its sole input; it is therefore necessary to extract the subvolume name on which /gnu/store lives" can someone confirm this means "it is done automatically" and not "you have to
<Tadhgmister>specify it somewhere or everything will break"
<festerdam>I'm following the packaging video tutorial on the official website. When I run «guix build package-name», it fails saying it can't it can't find «linux/errno.h». Am I missing some input in my package definition?
<festerdam>*«./pre-inst-env guix build godot»
<festerdam>Sorry wrong again
<festerdam>*«./pre-inst-env guix build my-package-name» Godot was only a test to see if that works.
<Tadhgmister>you are following this video and doing it for the package they mention or your own?
<festerdam>Tadhgmister: Yes, that video, but I'm doing it on a different package not currently present in the guix channel.
<festerdam>Note that I'm also not using an import template, so I most likely did a mistake somewhere, I'm just wondeing what could cause linux/errno.h not being found.
<Tadhgmister>yeah, I know I've run into this issue I just can't remember how I solved it
<Tadhgmister>I just went looking for references to linux/errno.h in the guix packages but it only shows up in .Po files in the nix directory
<Tadhgmister>it is likely need a native-input that has it as linux/errno.h instead of just errno.h,
<festerdam>Tadhgmister: It is a C preprocessor error, not a guix error, so the string won't be found in the guix source code.
<Tadhgmister>yes but I think I fixed it with a text substitution to strip the `linux/`, that isn't done anywhere in the source code so it was probably the wrong fix :P
<festerdam>Tadhgmister: Not important since I'm not planning to change the source code to get it working, but out of curiosity: If I'm reading the error message correctly, errno.h includes bits/errno.h which in turn tried to include linux/errno.h. Wouldn't sed'ing it create a loop?
<festerdam>Since bits/errno.h would go back to including errno.h
<Tadhgmister>I think it is `linux-libre-headers`, I initially thought that but disregarded it as I figured those were for kernel headers
<festerdam>Tadhgmister: I don't see any package definition using it in its inputs. Is this supposed to be added as an argument to guix environment?
<Tadhgmister>I have no idea, all I do know is that I tried `guix shell -D audacity` then did `echo | gcc -E -Wp,-v -` based on the internet telling me how to print include paths, the one for the profile has a `linux` symlink to linux-libre-headers
<Kolev>Does Guix's Audacity spy on you?
<Tadhgmister>wait.... `guix shell gcc-toolchain` has it as well....
<festerdam>Tadhgmister: I imagine if those header files are missing other C(++) programs also won't compile, but «./pre-inst-env guix build gmp --no-substitutes» which also uses errno seems to be compiling fine.
<Tadhgmister>it would probably be part of the implicit build inputs for nearly every package that includes c compiler stuff which is why it isn't an explicit native-input, actually you may want to try to do `guix shell -D your_package` and do the same inspection I did to see if they are in the typical place
<Tadhgmister>(`-D` includes all the packages needed to develop the specified package) and there is probably a more direct way to reference the generated profile with a manifest but I'm not sure how to do that
<festerdam>Tadhgmister: Should I run that within the environment with ./pre-inst-env?
<Tadhgmister>btw there are probably guix veterans looking at my suggestions in horror, there are almost certainly better ways to debug but I am unaware of them
<festerdam>Tadhgmister: The development guix-shell within the guix environment downloaded some stuff and after it finished running I ran «./pre-inst-env guix build my-package» within that shell, but it resulted in the same error of linux/errno.h not being found.
<festerdam>Kolev: Looking at the package definition its source code is fetched from, but its configuration flags include "-Daudacity_has_networking=off", so it shouldn't be sending anything. But in any case, Guix also has Tenacity.
<peanuts>"GitHub - audacity/audacity: Audio Editor"
<Kolev>festerdam: Thanks.
<Tadhgmister>festerdam: to clarify guix shell gives you a shell with the packages used by the build process, you could then cd to the directory with the source code and run what ever command they typically want you to run to build the project (like `make`)
<Tadhgmister>running `guix build` from the shell won't do anything differently than without the shell since it is getting a build daemon to setup a pure build environment
<festerdam>Tadhgmister: Ah, so I should copy the source code into the environment and try to build it?
<festerdam>*manually build it
<festerdam>Tadhgmister: Manually compiling with the development guix shell also fails with the same error, but I'm going to stop for now since I'm developin quite a rather painful headache. Goodnight. Thanks for you help!
<festerdam>I may come back tomorrow.
<Tadhgmister>what gives?? when I use `luks-device-mapping-with-options the grub config no longer tries to load the proper root?
<Tadhgmister>what ever calls the configuration file generator doesn't identify it as a device needing cryptosetup
<KE0VVT>I'm concerned about the inclusion of LibreWolf. They support DRM.
<KE0VVT>Never mind. I see Guix builds LibreWolf without EME.
<JonRob>Hey - I'm continuing my journey to learn Guix by trying to get all my daily tools setup on the platform. Quite a few aren't packaged. I've hit an issue trying to package It's written in Go, but the repository is setup in an odd way and the makefile does quite a lot of copying, setting paths etc. I've
<JonRob>written this package definition - - which runs make, but it fails on a shell script that tries to run `go get ...goimports` - this makes sense because the build environment won't have network access. I tried to crudely hack around this by disabling the checkstyle script with the `substitute*` function applied to the
<JonRob>makefile, but I get lots of permission denied errors - e.g. Don't suppose anyone is able to make any suggestions?
<peanuts>"(define-module (packages aws) #:use-module (guix gexp) #:use-module (guix -"
<peanuts>"phase `fix-home-directory' succeeded after 0.0 secondsstarting phase `build' -"
<msavoritias>hey. i am trying to deploy an nginx and certbot config to a server. but it seems that the domains defined in certbot and the domains defined in nginx conflict
<msavoritias>if the domain field and the nginx server name field that is have the same domains i get
<msavoritias>conflicting server name i am looking bayfront server declaration to get some pointers but im not sure
<msavoritias>is it something to do with scheme namespaces thing or is it just a certbot service bug?
<JonRob>I did figure out my issue in the end - seemed to be a problem with gopath and the makefile setting that. This package definition worked in the end. - feels a bit hacky, probably far from the right way of doing it.
<peanuts>"(define-module (packages aws) #:use-module (guix gexp) #:use-module (guix -"
<graywolf>Is there a way to guix copy a result of guix pull? My intention is that the machine doing guix pull would do just the "computing guix derivation ..." step, but no actual building.
<civodul>graywolf: the easiest way is to run ‘guix publish’ and enable auto-discovery among the machines, assuming they’re on the same network
<graywolf>civodul: Thanks for the tip, I will keep that for phase two (once there are actually enough server to being able to justify dedicating one to this function), for now I will just accept the carbon footprint :)
<civodul>new post!
<coyote>woohoo :-)
<civodul>dunno if it’s nice, i feel quixotic at times :-)
<jpoiret>civodul: sorry for the delay, I'm currently pushing the cleaned-up core-updates branch in place of the old one (i've moved it to old-core-updates in case we need it for reference)
<jpoiret>is that fine? haven't pushed it yet
<civodul>jpoiret: sure, sounds good to me
<civodul>though the real gatekeeper is futurile :-)
<civodul>(which was not an easy task until now, but hopefully will get better if we agree on the new branch!)
<CRLas>I have a quick question. Sorry if it’s already been asked. I just hopped on the channel. I’m doing a fresh install of Guix System after pulling the most recent commit, but it keeps failing on installing cairo-1.18.0.
<CRLas>I initially thought it might be related to the open issue about redundant grafts sometimes causing breakages, and I already tried the suggested solution of setting —disable-deduplication as an extra option, but it still fails to build at the same step
<CRLas>I’m wondering if anyone has encountered a similar issue with a recent install
<jpoiret>CRLas: what's the actual error/build log? you can paste it at
<CRLas>Wait, I just tried building cairo-1.18.0 and acl-2.3.1 individually and both completed, so now I’m thinking it might be a simple issue with my configuration. I’m gonna follow that thread and see where it leads, but I’ll post that error log if it happens again
<CRLas>Thanks, and have a good day
<jab>guix system still doesn't support power9 does it?
<lispmacs[work]>is there a trick to tell emacs-guix to refresh its package cache, other than restarting Emacs? After running guix-pull, the package cache is not updated, so package search commands only yield old packages
<lispmacs[work]>I tried restarting the guix repls but that doesn't do it
<jpoiret>civodul, apteryx, futurile, cbaines: just pushed the cleaned-up core-updates after testing it a bit
<jpoiret>It's missing updates to glibc though so you might incur some world rebuilds if you start working on it now
<jpoiret>Can't write a mail about it rn, will do later
<janneke>jab: last i heard it was in "technology preview" and many packages didn't build, not sure what the current status is
<jab>ah. gotcha.
<janneke>possibly efraim or nckx knows more about the actual power9 status
<efraim> ~87% of the packages build. currently there's issues with grub building, so it's not currently installable as guix system
<efraim>I haven't worked on it as much as aarch64 or riscv64 so I'm not sure beyond that
<janneke>i heard the other day that gnumach boots on aarch64
<apteryx>jpoiret: thanks
<cmiller>Someone using Virtual Machine Manager and noticed that booting VMs takes quite long since updating GNU Guix?
<cmiller>don't know why but the VM takes a bit in SeaBIOS till it boots from the disk
<a13x5>Hey everyone!
<cwebber>hm, I wonder how /var/lib/certbot/renew-certificates got set up
<cwebber>I did a guix reconfigure with new domains and it doesn't look like it got updated
<cwebber>but I don't remember how I even knew that
<a13x5>Did anyone researched how can Guix could be used in the cloud? Specifically using cloud-init mechanism. cloud-init inself doesnt really fits IMO. Maybe there are some alternatives?
<rekado>a13x5: we don't have any cloud-init support, but I want it.
<rekado>a13x5: on AWS we could then have a basic AMI with basic cloud-init support enough to reconfigure the image on first boot.
<rekado>cloud-init is what is needed to configure Guix System on AWS without requiring another reboot.
<rekado>(an alternative is to use userdata.txt to configure the machine and reboot it, but it's very clunky)
<a13x5>Yep that's what I thought, since I couldn't find any info regarding cloud-init in Guix
<a13x5>And without it it's pretty hard to do initial setup
<dthompson>rekado: in all my years using was I really grew to dislike cloud-init. are you talking about launching a non-guix image and then installing guix on it?
<dthompson>using aws*
<a13x5>I mean the cloud-init itself is pretty bad really, but mechanism of initialization using user-data is fine
<dthompson>I never got the opportunity to do guix + aws but my strategy would be to build a guix AMI and launch that in ec2
<dthompson>no cloud-init. shepherd services could start on boot that queried the instance metadata service for any runtime config.
<dthompson>likewise secrets manager could be queried for things like database credentials
<dthompson>at my previous job we used ubuntu server on aws. I used one-shot systemd services for any config that couldn't be known at image build time.
<a13x5>Actually I was thinking about writing some custom guile script to do several things cloud-init does
<a13x5>Most features cloud-init provides are irrelevant for Guix
<a13x5>I'm just curious maybe someone here did some research on that. If not it will be a nice weekend project))
<zeropoint>iirc you mostly need to setup network interfaces and disks
<zeropoint>I looked into this a bit at some point
<zeropoint>I hadn't decided what I thought a good strategy would be
<zeropoint>and possibly merge into os configuration
<dthompson>someone should try to make a basic guix AMI if that hasn't been done yet
<a13x5>zeropoint: Yep it's pretty much resizing image (if EBS is used), networking and ssh keys
<a13x5>We're also using cloud-init on ubuntu/rocky images to pass some configuration for our services
<h4>$ guix shell --container --emulate-fhs --share=/ -- Documents/file.AppImage\nguix shell: error : mkdir : Permission denied: "/tmp/guix-directory.hash/real-root"
<a13x5>dthompson: Interesting, I didn't know that nobody tried it
<h4>$ ls -l /\ndrwxrwxrwt 5 root root 4096 tmp/
<dthompson>a13x5: maybe someone has! I really don't know. the guix community is so big these days that it's very likely I missed something.
<a13x5>Sure! In any case I'm going to tinker with it. Honestly that's the only major thing which is stopping me from using Guix on my labs/PoCs, since they're all cloud based
<dthompson>last year I figured out how to make images for linode so I could just boot directly into guix rather than start from some other OS so I'm sure the same can be done for AWS
<seasharp>Oh sweet, I figured that out a couple weeks ago. Made things much comfier in linode
<seasharp>I'd like to get a linode api implementation of the steps someday perhaps
<apteryx>jpoiret: to make sure, only the 847b2a7ceb commit needs to be reverted, to return to good old pkg-config as default ("gnu: pkg-config: Alias to pkgconf-as-pkg-config.")
<apteryx>and then "gnu: mpv: Propagate most libraries." will need to be reinstated
<apteryx>for the time being
<rekado>dthompson: building a new AMI for every task is a big hurdle
<rekado>it would be nice to have a basic AMI with Guix System and a service to reconfigure according to a config file passed in via cloud-init
<rekado>so far I've only ever used "guix pack" to push things to AWS EC2 instances
<rekado>(and those instances ran Amazon (GNU+)Linux or Ubuntu)
<jackhill>rekado: oh, I like that idea of having an image the reconfigures on cloud-init data on first boot.
<dthompson>rekado: hmm idk I guess it just doesn't really suit the way I do things. I certainly wouldn't want to rely on anything that was launched that way.
<dthompson>for production servers I'd want an AMI per type of server I needed
<a13x5>dthompson: I see that the style of deployment which rekado is describing when AMI is using user-data on launch is much more common
<dthompson>in production environments? I doubt that
<a13x5>I used immutable AMI images before kubernetes took over. Now it's basically some container runtime and kubelet is running everywhere, so it's make sense to configure them when instance is launching
<dthompson>that's entirely different
<dthompson>I have luckily avoided kubernetes
<dthompson>and all its crazy complexity
<a13x5>Sure it depends on what type of workloads you have an what you need
<dthompson>but presumably we're not talking about setting up ec2 instances just to run kubernetes here
<dthompson>but rather to set them up to actually do stuff besides a host for yet another layer of virtualization
<dthompson>building an ami doesn't take very long, updates are infrequent, and you know you're getting the same machine every time you launch an instance.
<KE0VVT>Why does Guix System's GNOME use X11?
<dthompson>this is particularly valuable for autoscaling groups where you want all the servers to be exactly the same
<dthompson>KE0VVT: it defaults to wayland now, iirc
<dthompson>if that's what you were getting at
<KE0VVT>dthompson: Oh, OK.
<dthompson>I only read that so maybe I'm wrong.
<dthompson>but I thought that was one thing that happened when the gnome updates branch was merged recently
<KE0VVT>dthompson: Windowing System: Wayland.
<KE0VVT>I'm happy to learn that LibreWolf was indeed built in such a way that it does comply mith the GNU FSDG.
<jackhill>dthompson: what about for setting things like IP?
<a13x5>dthompson: Of course there are multiple approaches on how you do infrastructure. From my perspective I see cloud-init used a lot, even outside of a cloud in BM provisioning. And yes it's in production.
<jackhill>speaking fo k8s: any examples of running the Guix daemon there? Would be cool to build by k8s images in k8s :)
<jackhill>agree it's definitly overly complex, but when it's the hammer you have (or you lack the patence to encode everything in Guix)
<dthompson>in my experience cloud-init is abused to inject a bunch of scripts that could have been one-shot system services. had enough painful debugging sessions trying to figure out what happened to a server when the problem was some script fed in via userdata.
<dthompson>but like the status quo of devops is to use the worst possible solution, but with guix we can go a different way :)
<jackhill>+1 for doing things better. I guess I'm part of the problem, but it seems almost insurmountable to move all our stuff to guix at this time.
<jackhill>maybe eventually.
<dthompson>well I didn't move anything to guix at my last job either ;)
<rekado>my short term goal with Guix is to use S3 as a substitute cache
<a13x5>dthompson: oh, yes it is abused and a lot sometimes))
<jackhill>my idea was to have one-shot scripts consume the cloud-init data. Do you build a new image for every machine you deploy?
<rekado>this makes it much cheaper to pull and install things on EC2 instances where a stale Guix has been installed
<jackhill>dthompson: hehe, well, I'm more excited about your current job too :)
<rekado>it's not a lot of work to make that happen
<jackhill>hmmm, looks like the Linode Cookbook entry is due for an update
<KE0VVT>jackhill: How much of MBOA uses Guix?
<jackhill>KE0VVT: 👋🏼 I don't know (I'm not on aff there), but some of it is I think. Rollbacks on deployment are great!
<dthompson>jackhill: yeah I built one ami per type of server and rebuilt them periodically
<jackhill>dthompson: how do you set machine-specific stuff like IP address. SLAAC and DHCP?
<dthompson>for me I really want control over when the systems update. I don't want to be paged at night because a service is failing due to a transient issue
<dthompson>jackhill: I forget exactly how ip stuff worked but I think it was just dhcp and aws handled it
<dthompson>but generally per-machine stuff uses things like the metadata service or secrets manager
<dthompson>those are potential sources of transient issues but those are all internal network things
<jackhill>ah super. I've needed to deploy in some networks that don't have that, which is how I became worried about it. I also don't want to use services that I don't run :)
<Guest11>Hi, I have a LUKS encrypted Guix system on an SSD that I've just plugged in to a new motherboard. The boot partition is not recognized by my new Asus UEFI BIOS (but the device is). What should I try next?
<Guest11>Sorry it's not exactly Guix related, but I used Guix to configure the system on that device.
<Guest11>Perhaps booting a liveusb and chrooting + a system reconfigure would sand the rough edges magically?
<ieure>Guest11, Disable secure boot in your BIOS / set the device boot order to try your
<ieure>...Guix SSD first
<Guest11>ieure: I've disabled secure boot but no bootable devices are found to choose from or change the order.
<Guest11>The drive shows up in the BIOS, just not as bootable media.
<ieure>Guest11, Make sure the UEFI/Legacy BIOS mode is the same on the machine it's in as the one you did the install on.
<ieure>If that doesn't do it, I don't know.,
<freakingpenguin>dthompson: I like "the status quo of devops is to use the worst possible solution". Can't wait to share that with my devops friend hehe!
<vagrantc>ACTION reads this while running upgrades through a for loop across a bunch of machines :)
<dthompson>freakingpenguin: I'm just *a little* snarky about it because I did it full-time for like 7 years
<dthompson>but like seriously why do devops people love yaml so much??? ahhh