IRC channel logs


back to list of logs

<lh>yeah I definitely had to go that route, (guix config) needs autoconf to be built from guix/
<Kolev>How do I unlist a user from GDM?
<Kolev>How do I do a version number for a package, when there are no releases in the Git repo?
<oriansj>Kolev: you can do a git commit but if there are not releases the version would just be 0.0
<lh>(git-version "0.0" revision commit) seems to be a common pattern https:/
<lechner>Kolev / in Debian folks often add a date string so there is a sense of age or modernity
<peanuts_>"golang-github-jacobsa-crypto - Debian Package Tracker"
<lechner>Franciman /
<peanuts_>"gcc-toolchain is missing"
<Kabouik>Is that normal if the "Building profile with 159 packages" takes forever after installing just two packages? It's been more than an hour I think. This was after a pretty stringent `guix gc --delete-generations=1d` though, because I needed space, so maybe it has to hardlink a lot of things?
<ulfvonbelow>that's quite strange. The actual profile-building part is basically just making a symlink union of a bunch of directories IIUC
<ulfvonbelow>you don't happen to be building this profile on... I dunno... magnetic tape, right?
<ulfvonbelow>I'd say find the builder in top and see what the cpu and memory usage is like
<ulfvonbelow>if it seems to still be spinning somewhat, attach strace for a little
<Kabouik>guix-daemon is using 55% CPU according to htop (I never remember if it's truly 55% or to be divided by the number of cores). Memory use is fairly low. It's not magnetic tape, but it's a phone (with the fastest kind of internal memory though).
<podiki>packages with lots of files in a profile, like icons, can be a bit slow. my "desktop" profile with about 70 packages on a fast desktop will take a few minutes sometimes (used to be slower, things have improved)
<Kabouik>It is pretty slow on my computer too, and I expected slower here, but it's getting excruciatingly long. Both packages are TUIs, so no icons, but perhaps the issue is their inputs.
<Kabouik>Grafts have been applied to a lot of packages in the process.
<ulfvonbelow>my understanding is that the "building profile with ... packages" is the very last step, and only shows up when it's just the directory union step remaining
<Kabouik>Yet it does seem to use space. I'm running a `watch df -h /` in parallel, and just that steps is eating several gigabytes already.
<ulfvonbelow>the gc shouldn't be affecting how long it takes to do deduplication - if anything it should speed it up
<ulfvonbelow>if a directory-union step is eating multiple gigabytes, something has gone horribly wrong
<Kabouik>Multiple meaning ~10 already.
<Kabouik>(Hence why I was monitoring in the first place, I knew it'd be night since I don't have much space)
<Kabouik>Free space is no longer decreasing as I speak though.
<ulfvonbelow>'union-build' in (guix build union) should only be making symlinks and directories
<ulfvonbelow>is there still a process running under guixbuild<n> for the profile, or is it just the daemon holding things up?
<Kabouik>Nope nothing :\
<ulfvonbelow>the only things the daemon should be doing at that point are reference scanning and computing hashes prior to registering the finished store item
<ulfvonbelow>given that it's all symlinks and directories, both of those should be very fast
<Kabouik>There is this though:
<ulfvonbelow>well, reference scanning might be a bit slower "per-byte", but the small total size should make it still quite fast
<ulfvonbelow>ACTION dreams of a future where 0x0 doesn't block tor
<Kabouik>Damn, sorry, this is the easiest upload script I had at hand
<ulfvonbelow>it'll do
<Kabouik>Ideally I would have pasted text anyway, but on a phone this is not always the most convenient, especially with many processes running.
<ulfvonbelow>unrelated, but I envy the existence of a 3G network near you
<Kabouik>I know what you mean. On the other hand, I envy 4G network too. :>
<Kolev>Is this free software?
<peanuts_>"GitHub - WeirdTreeThing/chromebook-ucm-conf: Alsa UCM configuration for chrome devices"
<ulfvonbelow>here it's all 4G at minimum, and it drops battery life to less than half of what you could get with a 3G device
<Kolev>It's 3-clause BSD license.
<ieure>Kolev, Yes, that's a free license.
<Kolev>I'm trying to package it. Here's what I have, but I'm scared to try building it.
<peanuts_>"debian Pastezone"
<ieure>Kolev, Why are you scared?
<Kolev>ieure, I'm always scared to build code I've written.
<ieure>Kolev, It won't hurt anything, give it a go!
<ulfvonbelow>Kabouik: maybe try stracing the guix client process?
<ulfvonbelow>if nothing's being built, and the daemon's snoozing, maybe it's something client-side
<Kabouik>I don't have strace installed unfortunately. Guix being busy, I could install it with apt, but am a little scared to do anything remotely intensive after >1h of compiling and another hour of "building guix profile"
<ulfvonbelow>I do recall a few instances where bash seemed to just delay printing the next prompt after a long guix command until I pressed enter
<ulfvonbelow>but I assumed that was some artifact of using an emacs shell buffer
<Kabouik>I did press enter already anyway
<Kolev>ieure, how do I build it? `guix build foo.scm`?
<ulfvonbelow>and I don't suppose you have gdb either then?
<ieure>Kolev, I think it's `guix build -f foo.scm' for what you have there.
<Kabouik>Yay it finished ulfvonbelow!
<Kabouik>So it just took forever, but worked. Odd.
<ulfvonbelow>good to hear, has the disk free space gone back up?
<Kabouik>So the `guix install nmail nchat` was run at 1.48 AM. It's 6.15 AM. I underestimated the duration a bit. `nmail` is quite fast to build, `nchat` on the other hand is fairly long because it also includes tdlib (Telegram) and I force it to disable parallel-building to save RAM, but the "Profile building" was a very significant part of all that.
<Kabouik>Usually guix installs on that same device take minutes, not hours.
<Kabouik>Re: disk space: no, not really. I think it ate like 7GB in the end, but I assume the build leftovers are still there until I gc?
<ulfvonbelow>yeah, they'll be there until you gc
<ulfvonbelow>what does 'du -h --threshold=5M $(readlink -f ~/.guix-profile)' say?
<Kabouik>Still processing, hold on.
<Kolev>I got it to build! I think it works.
<peanuts_>"debian Pastezone"
<Kabouik>Maybe I should uninstall Papirus. :|
<ulfvonbelow>I was actually surprised when I ran du on my own profile just now and found out it's apparently using 119MB
<ulfvonbelow>guix's symlinks seem to be hitting a rather pathological case in symlink space usage
<ieure>I want to build gnome-keyring without SSH agent support. I found this blog post, which has a package to do that, but something changed between 2018 (when it was written) and now, and it's broken.
<ieure>Error I get is: /gnu/store/l9vbdr7swpv8x5hlmp01azdvvlgpqgs3-gnome-keyring-sans-ssh-agent-42.1-builder:1:9134: Unknown # object: "#<"
<ulfvonbelow>according to, the threshold for "needs an entire block to store the symlink" is around 60 bytes
<Kabouik>Seems to be using a lot more space on my setup than yours
<ieure>If I call (package-arguments gnome-keyring-sans-ssh-agent), I see some #<gexp ..> objects; I think that's what the error message is about.
<ieure>Any thoughts on what the correct formulation for this package is today?
<ulfvonbelow>Kabouik: what does find $(readlink -f ~/.guix-profile) | wc -l say?
<ulfvonbelow>mine says 30026
<Kabouik>Erm. 1433296.
<Kabouik>And that is after a `guix gc --delete-generations=1d`.
<ulfvonbelow>ieure: this is due to the gexp change. Basically, while you can substitute old-style sexps into a gexp and it will work, and you can substitute gexps into a gexp and it will work, but you can't (usually? I feel like I remember some effort in (guix gexp) to try to accommodate this) substitute a gexp into an sexp and have it work
<ulfvonbelow>it should work to replace `(cons "--disable-ssh-agent" ,flags) with #~(cons "--disable-ssh-agent" #$flags)
<ulfvonbelow>Kabouik: note that 'guix gc --delete-generations' won't delete the current generation IIRC, and the current generation is immutable, so it can't affect the output of that command by itself
<ulfvonbelow>1433296 * 4096 = around 5.87GB, so it checks out more or less
<Kabouik>But I'm surprised there would be so many more lines in my case than in yours, with a single generation.
<ieure>ulfvonbelow, Thanks, that works. I haven't read up on gexps yet.
<ieure>I'm aware of them, in the way where I know I don't know what they are or how they work.
<ulfvonbelow>Kabouik: I'm curious what 'find $(guix build papirus-icon-theme) | wc -l' would say
<Kabouik>I am probably going to delete that package, I don't even use that many GUI apps. Since it's my phone, it is a foreign distro too, so I might be better off installing it with `apt` if I really want Papirus icons in my app launcher.
<Kabouik>Somehow that command makes me download papirus-icon-theme ulfvonbelow.
<ulfvonbelow>... huh. okay, scratch that command
<sner>ulfvonbelow: I didn't realize guix profile icon directories individually linked their icons, does guix not have any other mechanisms for munging directory structures than unpacking every single file to an individual symlink?
<Kolev>Now, my question is: What magic makes ALSA understand to look in /gnu/store/...?
<ulfvonbelow>'union-build' is supposed to symlink directories instead when there's only one
<ulfvonbelow>so I guess I'm wondering how you ended up with more than one share/icons/Papirus-Dark/48x48 directory being union'ed, for example
<ulfvonbelow>Kabouik: was there a phase before the 'building profile with ... packages' that mentioned gtk icon themes?
<Kabouik>Yeah, seems all Papirus subdirs are duplicated.
<ulfvonbelow>I suspect that may be what's causing it to not just symlink the directory and be done with it, but not sure
<Kolev>Now, how to install this system-wide?
<peanuts_>"debian Pastezone"
<Kabouik>I think so ulfvonbelow, there is always a "creating GTK icons blah blah".
<ieure>Kolev, What do you mean?
<sner>ulfvonbelow: I'm seeing similar behavior with the set of Delft icon themes
<Kabouik>"Creating GTK+ icon theme cache…", to be exact.
<Kolev>ieure, well, on a normal system, these files need to go into /usr/share/alsa/ucm2.
<ulfvonbelow>Kabouik: what does 'readlink /gnu/store/sazyjnf3brxnxykgw3hkmh0r9wrzz08x-profile/share/icons/Papirus-Dark/48x48' say?
<Kabouik>Nothing ulfvonbelow, no output.
<ieure>Kolev, Guix doesn't work like that, that directory doesn't exist. Guix's /usr only has one file in it, /usr/bin/env, which I think is so shell scripts don't break.
<sner>ulfvonbelow: ~150k symlinks in my guix-home profile, where each icon file is a symlink to gtk-icon-themes in the store, which itself links to each of the icon files in the store individually
<Kabouik>Same with /gnu/store/sazyjnf3brxnxykgw3hkmh0r9wrzz08x-profile/share/icons/Papirus-Dark/48x48@2x/
<Kolev>ieure, but you have the package alsa-ucm-conf, which does copy files like that.
<sner>ulfvonbelow, Kabouik: that file is likely a directory, each of the icon files are linked individually
<podiki>Kolev: just a guess but probably alsa looks in $XDG_DATA_DIRS
<ieure>Kolev, It copies them to those locations within its directory in /gnu/store.
<Kolev>ieure, right.
<podiki>ACTION night guix!
<Kolev>podiki, night. 🌃️
<Kabouik>sner: yes, but isn't that taking space unnecessarily if there's a way to link folders (see above)?
<ieure>Kolev, The store is what you actually use for everything. No files are ever put in /usr. There is no "system-wide" in Guix like in other distros.
<Kolev>ieure, but the system needs these files for audio to work.
<podiki>Kolev: and good luck! i think you basically got it; xdg_data_dirs is the likely way alsa finds things, and in guix that will be set to things like /home/<user>/.guix-profile/share
<podiki>or /run/current-system/profile/share for system profile
<sner>Kabouik: yes, this is almost definitely either a bug or an oversight, the entire profile/share/icons dir should be a single link (or at least each of its direct subdirectories)
<ieure>Kolev, Regardless; there is no "system-wide." Some software needs to know where some config files are. That doesn't have to be the same place they'd be on other distros.
<Kabouik>This also likely causes very long profile building, as found by ulfvonbelow
<Kolev>ieure, I **know** it's not in /usr/ but it has to be somewhere - in the system declaration, for example.
<sner>with only Delft icons installed I'm wasting 500MiB of disk space on my /home partition on symlinks, anything of the larger icon sets (i.e. Papirus) I can see how this would become a more serious issue
<efraim>my pinebookpro seems to know about the file in /var/lib/alsa/asound.state, but that's not the same exactly
<efraim>ok, I see in alsa-utils it's explicitly mentioned
<ulfvonbelow>I think it's an artifact of how profile hooks are done
<Kabouik>I got to get some sleep, thanks a lot ulfvonbelow. I'll catch up later if you want me to do some more testing or report a bug. The disk use this is causing is critical to me, as it oftens prevents any operation without a huge guix gc or even move of something else to my SD card.
<Kabouik>And the build time is another issue.
<Kolev>So now that I've packaged this, how do I... use it?
<Kabouik>You can `guix install /gnu/store/hash-your-package-version`, or better yet, make a package for your private channel or Guix channel.
<ulfvonbelow>it's because union-build is called with (append extra-inputs inputs), where extra-inputs is the directories produced by the build hooks, which are themselves produced from the manifest (which gets turned into 'inputs').
<sner>ulfvonbelow, Kabouik: this issue is particularly problematic as if the gtk-icon-themes profile package gets built, each of those symlinks are actually 2-links-deep (profile dir -> gtk-icon-themes -> icon package), which with >10^6 files is probably taking a massive toll on profile generation
<ulfvonbelow>so for example, if your manifest has papirus-icon-theme in it, union-build will be called both with papirus-icon-theme *and* with the result of running the gtk-icon-themes hook on papirus-icon-theme
<efraim>Kolev: you might need to create a custom alsa-lib with that package included too, like the other alsa-*-conf packages, and then probably use a graft to swap out one for the other.
<efraim>but first I'd try just installing it in your profile with your other packages that use audio and see if that is magically enough
<Kolev>efraim, hm. That sounds hard.
<Kabouik>Short term measure ulfvonbelow: I'm guix removing it while sleeping, and will install it with apt instead. But if this is worth a report, I'll do it (might need to ping you a bit to avoid reporting inaccurate information).
<ulfvonbelow>so basically, you have DIR1 = {a, b, c} and DIR2 = {a, b, c, d}, and (union-build (list dir1 dir2)) doesn't know that dir2 is a superset of dir1
<Kolev>efraim, `guix install /gnu/store/yp633fm8v9h3ir2i9s0h35x8g725y8i7-chromebook-ucm-conf-0.0-1.1328e46` did not work. Audio is still Dummy output.
<efraim>I don't know a lot about how audio works so I'm not sure if there's something you'd need to do to make it pick it up
<sner>Kolev: linux audio is a bit unconventional in how it handles configuration and pathing, given how many times the core systems have been retrofitted/built upon. For adding configuration to alsa files, if it can't be done with /etc/asound.conf (or something else under /etc), you're going to need to build a custom alsa-lib package.
<Kolev>sner, I don't know what to say. I'm very discouraged.
<sner>Kolev: this is a rough edge that you're not really going to run into outside of the audio stack. the combination of long history, limited clarity in upstream docs, and multiple separate but related audio systems makes it a bit of a nightmare to work with, especially on an unconventional distro like guix
<sner>however, you can actually get this working. if you take a look at the package definition for asla-lib, you can see that the directory you need to graft over is losted
<ulfvonbelow>anyone familiar with icon themes know whether gtk-update-icon-cache stores paths relatively or absolutely?
<ulfvonbelow>if it stores them relatively, we could be a bit cheeky and at the end of the gtk-icon-themes hook delete everything *but* the icon-theme.cache files
<sner>Kolev: defining a modified alsa-lib, inheriting from guix's, and modifying the ucm[2] symlinks to point to a union of your package and guix's alsa-ucm-conf shoudl yield you what you want
<Kolev>sner, I don't know how to do that. This chromebook-ucm-conf is the first time I ever made a package, and I don't remember how to inherit.
<Kabouik>Removing the icon theme changed everything ulfvonbelow. `find $(readlink -f ~/.guix-profile) | wc -l` dropped to 7910. From 1433296.
<efraim>I've almost got a building chromebook-alsa-lib
<sner>ulfvonbelow: would it possible to consider extending the behavior of union-build to detect when one is a strict subset of the other?
<Kolev>Now, this chromebook-ucm-conf package... Can I add it to linux.scm, where alsa-ucm-conf is?
<Kolev>efraim, ❤️
<sner>Kolev: this is a tough one because you're running up against a limitation of the build system. Typically packages aren't hard-coded to take configuration exclusively from a /usr/* directory. The best long-term solution here would probably be to modify guix's alsa-lib package definition to patch the default config dirs to be one that can be extended by a guix service (i.e., something under /etc)
<sner>If anyone here is aware of similar cases of packages hard-coding configuration dirs under /usr, it would be helpful to have a model to follow. In general, adding hardware-specific ucm config to alsa (ideally) shouldn't be as hard as it is currently
<peanuts_>"debian Pastezone"
<efraim>--with-graft doesn't take a path to the store, so the transformation would need to be in a manifest
<Kolev>efraim, so does this work if I build and install?
<efraim>Kolev: no, you're going to need to use it in a manifest to replace the other instances of alsa-lib
<sner>efraim: Kolev: I just had a look at the alsa-lib source tarball, it exposes an environment variable to configure the ucm lookup dirs
<efraim>that sounds even better
<sner>ALSA_CONFIG_UCM and ALSA_CONFIG_UCM2, set in the system profile to something under /etc, will get you the behavior you want
<sner>for posterity, alsa-lib/src/ucm/parser.c has the getenv() calls, and src/ucm/ucm_local.h has the #define's that set those env var strings
<sner>this is documented approximately nowhere
<efraim>so unless ALSA_CONFIG_DIR changes in Guix to %output/share/alsa then /usr/share/alsa/ucm{,2} should Just Work™
<sner>Kolev: using a search engine on those env vars, a half-decent example from nix comes up:
<peanuts_>"alsa-ucm-conf-asahi: Add support for audio confs by IonAgorria ? Pull Request #102 ? tpwrules/nixos-apple-silicon ? GitHub"
<efraim>#define ALSA_CONFIG_DIR "/gnu/store/icmd5wb0494flgwh1lmjwlaj6xhvx5xp-alsa-lib-1.2.4/share/alsa"
<ulfvonbelow>sner: it might be possible, though likely somewhat expensive, but the issue is that it's not immediately obvious how correct it would be in the general case.
<sner>efraim: from my reading the ucm stuff under alsa doesn't respect ALSA_CONFIG_DIR when either of the above UCM env vars are set
<sner>the snd_config_topdir function (which will read ALSA_CONFIG_DIR) is only invoked if the ucm getenv lookup comes back null
<sner>the long-term correct course of action here is likely to modify the alsa-service-type to add a session-environment-service-type (like pulseaudio's does in the same file), and make bind ucm lookup dirs to a mutable folder in /etc
<Kolev>I just want to be able to listen to music and watch videos. 😳️
<ieugen>elevenkb: hi, did you have time to check out the clojure-tools patch ?
<sner>Kolev: the proper way to do it is going to require you to get familiar with guix service definitions. For now, since the chromebook-ucm-conf package doesn't need to be built, you should be able to test it by directly modifying that environment variable in the shell. Can you try launching the audio stack with ALSA_CONFIG_UCM2="${path to chromium-ucm-conf}" set?
<Kolev>sner, what command is "launch audio stack"?
<sner>are you using pulseaudio? (auto-launched by apps)
<sner>kill everything that could try to restart pulse, and then kill the pulseaudio process by name
<sner>then launch an app that will try to use audio, with that env var exported
<Kolev>Hm, that sounds really hard. I'm using GNOME.
<iyzsong>well, alsa-lib also need a version update to support 'Syntax 6' in chromebook-ucm-conf
<Kolev>sner, efraim: If you have a quick fix, mail to me at Good night. 🌃️
<efraim>Kolev: night
<nutcase>when running wdisplays (on sway), I get "Couldn't open cannot open shared object file: No such file or directory" and wdisplays doesn't start. What is missing to have libGLESv2 available?
<indigo-oce>Can I create a channel just stored locally? I see the channels use 'url' to specify the location, can that just point to a local folder?
<mange>I just tried and using a file:// URL seems to have worked. Your channel folder will still need to be a git repository, and I expect it will only include committed files.
<indigo-oce>mange I just found in the Guix Cookbook manual a section that shows installing packages from individual .scm files...
<indigo-oce>Based on what you said (string-append "file://" (getenv "HOME") "my/channel") should work...
<indigo-oce>hmm it doesn't seem to be working... when does it update the channel list? does that happen with guix pull? or does it happen just on calling guix install/show?
<civodul>Hello Guix!
<mange>It only happens when you do a "guix pull".
<fproverbio>hey everyone, kinda new to guix in general. Is there a way to pass an existing file to hosts-service-type? reading the documentation it's clear that it expects a list of entries, but what about a prepackaged file?
<civodul>fproverbio: hi! there’s a deprecated ‘hosts-file’ field in ‘operating-system’ that lets you do that
<civodul>but yeah, it’s deprecated in favor of those host entries
<xelxebar>Hey civodul! You wontfixed a package of mine because upstream's code looked obfuscated to you. I replied, but it looks like that might have gotten lost in the wind. Would you mind reconsidering?
<peanuts_>"[PATCH] gnu: Add ngn-k."
<Kolev>nutcase, the workaround is to do `GSK_RENDERER=cairo wdisplays &` in terminal.
<civodul>xelxebar: apologies, hadn’t seen your reply!
<civodul>lemme see
<Kolev>nutcase, I have to do the same thing for running Dino.
<nutcase>Kolev: unfortunately, the error persists with GSK_RENDERER=cairo
<civodul>xelxebar: just replied!
<civodul>in short, i don’t see how those C files could qualify as “source”
<civodul>but i’m willing to hear what others have to say!
<peanuts_>"[PATCH] gnu: Add ngn-k."
<gabber`>do we have a service that grows a partition on system boot? the use-case is embedded systems that start from a $(guix system image) which may only be 2GiB in size -- but was flashed on some medium with way more space
<xelxebar>civodul: Thanks! I know. It's suuuper weird. I have talked to the developer before and can assure you that the code is hand-written.
<xelxebar>Basically, it's written in a style that's supposed to mimic the K language itself, which is super terse.
<xelxebar>The main K implementation is proprietary, but from talking to people on the inside, the commercial product's code base is supposedly also written like this.
<isaneran>not super familiar with APL but it does look similar to examples of it that I have seen
<isaneran>but it was many years ago that I looked at it for maybe just a few minutes :P
<xelxebar>Here's an example of a YAML parser in APL that I'm working on:
<peanuts_>"dayaml/Y.apln at master ? xelxebar/dayaml ? GitHub"
<isaneran>feels like a write only language to me. No offense intended
<isaneran>maybe you get used to it though
<xelxebar>I swear, it's brutally maximized for clarity and readability.
<isaneran>people say the same thing about lisp after all
<isaneran>or even math formulas haha
<isaneran>civodul: according to wikipedia rms used APL so maybe he can weigh in on this lol
<fproverbio>civodul thanks!
<civodul>xelxebar: to me it’s more than just “i don’t like the syntax of the language/coding conventions”
<migalmoreno>Hi Guix! Has anyone been able to run the Guix WSL image as of late? I've followed the steps here but I get an fstab error upon initial launch "<3>WSL (8) ERROR: CreateProcessParseCommon: 754: getpwuid(0) failed 2. Processing fstab with mount -a failed."
<migalmoreno>I'm on WSL and the kernel is on 5.15
<xelxebar>civodul: IIUC, you're concerned that it's the code that people are expected to hack on, or do you have wider concerns in mind?
<civodul>xelxebar: i’m looking at it from the angle of our policies: Guix provides only free software, which of course implies having access to “source code”, and i’m skeptical that those C files are “source code” (the .k files are commented and are plausibly source IMO)
<efraim>more errors with gnu/stubs-32.h :/
<civodul>trying to build with ‘-m32’ on a 64-bit system?
<efraim>trying to build a sysroot for rust, I have it cross-compiling from x86_64 to i686 and aarch64 but no other combinations
<efraim>I might need to look at the llvm wrapper in the crate in the rust sources, see if that has anything to do with it
<efraim>fun part is its the same error for ppc64le
<efraim>I wonder if removing llvm from the inputs and putting llvm-for-mesa for (%current-target-system) would help only target one system at a time and not try to be helpful
<attila_lendvai>civodul, is this true? in shepherd stuff written to the log-output-port is sometimes printed by herd to the user? i'm working on extending the logging in shepherd, and this piece is not clear to me yet.
<efraim>maybe I shouldn't have binutils-cross in the LIBRARY_PATH and only in CROSS_LIBRARY_PATH?
<civodul>attila_lendvai: yes, when a client (‘herd’) is connected, everything that goes to ‘log-output-port’ also goes to the client (typically messages like “Starting service …”)
<attila_lendvai>civodul, my issue is that i would like to add debug/info/dribble etc log statements to shepherd... but presenting dribble log to the herd/user doesn't sound like a good idea on first consideration. but maybe it's fine, if shepherd has been turned into high level of logging... dunno.
<saravia>excuse me, some know if is posible build a hyperbola like os, from guix environtment builder?, so-so how is that?
<saravia>first what I need? a list of packages and versions?
<ekaitz>efraim: there are many errors with cross-compileres
<civodul>attila_lendvai: having logging levels would be nice but yes, maybe not everything should go to clients
<civodul>maybe that’s not big deal though, dunno
<ekaitz>efraim: this issue I found too in some other way
<peanuts_>"encfs build fails: stdlib.h: No such file or directory"
<peanuts_>"arm-none-eabi-toolchain: stdlib.h not found"
<attila_lendvai>civodul, this is what's brewing on my side. if you see anything that you know you'll reject, then i'd welcome a heads up before i get too deep into that forest:
<peanuts_>"Commits ? attila-lendvai-patches/shepherd ? GitHub"
<cbaines>does this fail for anyone? guix build --substitute-urls= /gnu/store/b2sbqls6fg626qvdpqfp4z478idqq2g4-guix-system
<peanuts_>" Build farm"
<cbaines>(assuming you authorize substitutes from bordeaux)
<cbaines>I get Throw to key `lzlib-error' with args `(lz-decompress-read 4)'.
<cbaines>but I can't find anything wrong with the substitute
<efraim>cbaines: I get the same error
<cbaines>ok, good to know
<fnat>This online meetup is happening in about 2h, main topic today: "the patch-review process in Guix" :)
<peanuts_>"London Guix Meetup (Nov 2023) - Mobilizon"
<Manis>Hi. I need to check for the currently running operating system in a shell script. What is the recommended way to check for GNU Guix?
<Manis>test -f /etc/config.scm?
<mirai>Manis: no
<mirai>it's not guaranteed that it exists
<mirai>I think the manual mentions the existence of some specific files that you can use for the purpose
<Andronikos> has a experied ssl certificate since Mon, 20 Nov 2023 15:05:01 GMT
<cbaines>hmm, I'm confused, we don't seem to have Guix certbot configuration for
<cbaines>I'll have a go at writing some
<civodul>Andronikos: ouch, thanks for the heads-up
<mirai>I guess being super slow/timing out is related to this?
<civodul>cbaines: it’s tricky, due to the fact that we moved the web site
<cbaines>civodul, I've probably forgotten the details, was there a specific problem hit when trying to get bayfront to renew the cert though?
<mirai>I find this substitute downloading strategy to be a bit subpar: <>
<peanuts_>"Untitled - Pastebin Service"
<civodul>cbaines: ‘sudo certbot certonly -d’ should work
<civodul>followed by ‘herd reload nginx’ (or ‘herd restart nginx’ if that’s not enough :-))
<mirai>it always keeps trying the _just determined to be in poor shape_ substitute server instead of continuing with the second best option
<Manis>mirai: do you have a link by chance? I cant see anything obvious while scrolling through the manual.
<mirai>Manis: I don't remember exactly what file or where I read it
<mirai>but I surmise you could test for the existence of /etc/guix directory instead?
<Manis>Doesn't that also exist when the package manager is installed on another distro?
<cbaines>Manis, it's probably unwise, but looking at /etc/os-release is probably less worse than /etc/config.scm or /etc/guix
<cbaines>civodul, looks like there were two nginx's on bayfront, so I killed them all and restarted the service
<jpoiret>why is os-release not the proper answer?
<jpoiret>it's there for exactly this reason no?
<civodul>cbaines: perfect, thank you
<civodul>well, it’s not “perfect” that there were two nginx
<Andronikos>Certificates do work again for me.
<Manis>I didn't know Guix had os-release. My testing installation does not have it, but it is also a bit older (1.0.1l
<Manis>Other distros have some special version files. I take it that Guix doesn't have such a file (other than os-release which mine doesn't have)
<cbaines>how can I work out why guix package -u wants to build zig?
<cbaines>the normal --dry-run approach doesn't work
<civodul>cbaines: --dry-run --no-grafts maybe?
<civodul>or “guix graph --path -t references /gnu/store/…-profile.drv zig”
<cbaines>civodul, that still just tells me a list of package names and versions, not any derivation info
<cbaines>ah, I've found the issue, ncdu uses zig
<efraim>If you want the old c based ncdu it's there as @1
<cbaines>also I think I might have got the shepherd stuck in a weird state on milano-guix-1 (maybe again, as I think that's happened before)
<Kolev>Hello Guix.
<quanrong>Hi, I'm trying to run a binary that uses Qt from a guix shell container, but it is not able to connect to the display and crashes. I have preserved $DISPLAY and $XAUTHORITY. Anyone knows what could be missing?
<quanrong>(I'm on X11)
<fnat>we've just started
<peanuts_>"Jitsi Meet"
<Gooberpatrol66>is qemu-binfmt-service-type supposed to work with "guix system image" commands? i enabled the service and then got this error in a build: checking host system type... Invalid configuration `aarch64-linux-gnu': machine `aarch64' not recognized
<quanrong>What platform are you targeting? I read in the docs that 'aarch64-linux' is a supported platform, but 'aarch64-linux-gnu' doesn't seem to be: Maybe that's the issue?
<peanuts_>"Supported Platforms (GNU Guix Reference Manual)"
<Gooberpatrol66>guix system: error: 'aarch64-linux' is not a supported cross-compilation target
<Gooberpatrol66>hint: Did you mean `aarch64-linux-gnu'? Try `--list-targets' to view available targets.
<Gooberpatrol66> i think this is just a bug and i can't build this until it's fixed
<peanuts_>"aarch64 system cross compilation + pinebook pro image broken?"
<Franciman>thanks lechner i was able to solve by importing gcc-objc++
<Franciman>quanrong: did you also add --share="$HOME/.Xauthority"?
<Franciman>i think it is also needed
<apteryx>ah, we still have these:
<peanuts_>"Build log of build #2635272"
<apteryx>cannot build missing derivation ‘/gnu/store/mkrazsh3yh27csawh2hdw0qacrs4naa1-ecl-compiler-macro-notes-0.2.0.drv’
<quanrong>Franciman: for whatever reason I don't have ~/.Xauthority, but adding --expose="$XAUTHORITY" finally fixed it
<Franciman>oh nice
<Franciman>does anybody use pipewire on their guix system?
<Franciman>i am afraid i need it for my bluetooth headset :(
<Gooberpatrol66>Franciman: no, i'm waiting for this
<peanuts_>"[PATCH] gnu: home: Add support for home-pipewire-service"
<Franciman>oh, that would be glorious
<weary-traveler>i submitted a patch about a month ago (my first). if someone experienced has a moment to spare, i'd welcome feedback on this
<peanuts_>"[PATCH master 0/3] Add Tilda with D-Bus support (necessary for Wayland)"
<ieure>I made some changes to my system's xorg configuration, which caused the X server to fail to start. I was able to roll that back, but: how do I look at the config file which was generated to give to xorg?
<ieure>I found xorg wrapper in (gnu services xorg), but I'm not sure how to find the output of the derivation.
<ieure>Hmm. I just poked around the store for files ending in "xserver.conf" until I found it. Still would like to know if there's a better way.
<ieure>And I see the issue, which is that my (local-file "path/to/xorg-snippet.conf") is inserting the path to the file, not the contents. That's, uh, not great.
<ieure>Maybe I'm doing this wrong? On Debian, you can drop files into /etc/X11/xorg.conf.d and those all get picked up by Xorg. I have files which configure things like my input devices (setting scroll direction etc), enable tearfree on the video driver, etc. What's the Guix approach to this?
<ieure>I want to keep the configurations in files, so I can edit them more easily. I don't like config as strings in code.
<crole>I could make a joke, but in the interest of knowing, what is the difference between code in a file and configs in a file, as you state them?
<crole>While you answer that, I think my joke and illustration are clear: Code is config, and configs are code.
<ieure>crole, The Xorg configuration is normal 1980s text-based Unix config, the Guix system configuration is Guile. There is no provision in Guix's xorg support to represent the configuration (in the format Xorg expects it) as Scheme records, so it has to be written in Xorg's expected format. I would like to edit those using conf-mode in Emacs, which provices highlighting/indentation/etc -- you don't get those if it's a string embedded in
<ieure>Guile code.
<ieure>I've been programming Lisp for 10+ years, I understand the "data is code" thing, but that doesn't solve my practical issue.
<vivien>Maybe you want something like local-file?
<nutcase>Franciman: I use pipewire, but I'm not sure, if I can help, since I don't know it well
<apteryx>ieure: yubikey OTP codes?
<ieure>apteryx, Yes. Been a while since I accidentally hit it.
<ieure>vivien, When I use local-file, it puts the path of the file in the store into my Xorg config, instead of its contents.
<ieure>Which is why xorg fails to start.
<vivien>I don’t know how Xorg config files work, but doesn’t it have something like an “include” command?
<vivien>“don’t they”*
<apteryx>ieure: perhaps look at 'info "(guix-cookbook) Using security keys"', more specifically the 3.4.2 Disabling OTP code generation for a Yubikey bit
<apteryx>if you don't actually need that
<ieure>apteryx, If I disable the OTP codes, it doesn't work as a FIDO2 MFA device and I can't log into a bunch of sites.
<apteryx>ah? I haven't encountered such site yet.
<ieure>vivien, Yes, you can include files in the xorg configuration. But since the configuration it generates doesn't include one, I have a chicken-and-egg problem of "I don't want inline xorg configs," but would have to add an inline xorg config to add the line to include the file containing the snippet.
<ieure>The manual says extra-config is "...a list of strings or objects appended to the configuration file." My assumption was that "objects" includes "file-like objects," but, it doesn't appear to.
<trnry>ieure: I'm pretty sure that local-file copies the file to the store. It was a mistake I first made with Guix and I noticed I was putting a sensitive file into the store by using it
<trnry>Oh wait, you mean you need the file inlined, right?
<ieure>Well. I don't care if the contents of the file are included in the output or not; I just don't wish to inline the contents of the file in my system config.scm.
<ieure>If that makes sense.
<ieure>Just to make this a bit more concrete, here's the bit of my system config:
<peanuts_>"debian Pastezone"
<ieure>The referenced files are all xorg config snippets, ex. `Section "InputClass" ... EndSection'
<trnry>Then can you load the file via normal OS methods to get a list of config to pass to extra-config?
<trnry>It seems like that's what you're trying with local-file
<ieure>I don't know what the heck I'm doing!
<ieure>But the config file which gets generated from that config snippet has this line at the end:
<ieure>Which are the store paths of those local-files. Which is invalid, which is why Xorg can't start.
<ieure>Do I need gexps here? Does it need to be #~(list (local-file "xorg/radeon.conf")) or... something?
<trnry>Sorry, I don't mean to be dismissive. I also barely know Guile, but I believe what you want is to use open-input-file to open a port to that file and read the lines out. A g-expression would be for something that needs to exist after the config has been applied
<ieure>trnry, Okay, sure, yes, I could manually read the files and put those into the extra-config list.
<ieure>That seems pretty hacky, though.
<ieure>I really would like to know why local-file -- which I'm pretty sure I've seen making files' contents available in the way I want -- doesn't do that in this case.
<trnry>local-file copies an existing file into the store rather than loading its contents. Now that I mention it though, does Xorg.conf have a mechanism for importing a file? You could stick that in your extra-config
<trnry>local-file would copy the file into the store, return the resulting path, and you would import that path
<ieure>trnry, We covered that already, I'd have to inline the config which has the include line to the file. I don't want *any* configs inlined, and if I'm going to have to compromise on that, I'd put the contents in directly rather than adding a layer of indirection.
<ieure>So this part of the manual:
<peanuts_>"Getting Substitutes from Other Servers (GNU Guix Reference Manual)"
<ieure>Does the thing I'm trying to do: uses local-file to put the contents of a file in the config.
<ieure>Why does that work for that part of the config, but not this xorg part?
<ieure>Okay, I think the code for this is just very primitive.
<trnry>authorized-keys takes a list of file-like objects, while extra-config only takes a list of strings
<ieure>trnry, Manual specifically says "strings or objects."
<ieure>I agree with you that it doesn't appear to work with anything other than strings.
<ieure>Sure don't love it.
<trnry>Yeah I agree that it would make a lot more sense if the code to handle all that dumped any file-like objects given to it into xorg.conf.d, but that's why you're seeing the behavior that you are. G-expressions don't load content or anything like that, when they are lowered they become a store path and some things will do some additional niceness with that path
<trnry>But if xorg has syntax to load a file (I have no idea if it does or not), then I would expect this to work `(string-append "Import " ,(local-file "xorg/radeon.conf"))`