<lfam>In my experience, it already is. <vagrantc>because people are just using cellular data plans in many places? <lfam>My jobs is "live event technology". I handle technological components of events involving hundreds to thousands of people. 5 years ago, it was common to need to worry about wifi at events. Everyone needed the wifi password. Now, we never get asked about wifi, and many venues do not offer it. Everyone is using LTe <lfam>It's more reliable and you don't need a password <pkill9>wired broadband is still a lot faster than mobile <lfam>Of course, but it's not an option for guests at an event <lfam>Laptops have LTE modems now <pkill9>ah yea, it will probably fade at events <lfam>(Not to mention smartphones) <lfam>And very few laptops have ethernet ports <vagrantc>and mobile networks have much better coverage in many parts of the world where there's little to no broadband at all... <lfam>But, people are online *everywhere* you go. They are using LTE <nckx>Not events, all public places that offer wi-fi. <lfam>So, the free software movement must not allow itself to fade into irrelevance over this <drakonis>lfam: it has been playing the wrong game all this time <lfam>What do you think would have been a better approach? <drakonis>the better approach would've been to not let innovation slip through their fingers in the name of "freedom" <drakonis>which has happened in multiple occasions <lfam>Okay, sure :) But in order to progress we need to know exactly where to land the next step <drakonis>gcc lost its lead because it was built in a way that prevented people from building on top of it <lfam>That is a sad story, although GCC has been innovating like crazy since then <drakonis>hmm, the next step, would be to aim for attracting new users <lfam>IMO, GCC actually lost its lead because the FSF decided not to accept the donation of LLVM <lfam>It was offered to the FSF. Did you know that? <lfam>It does seem to have been a communication problem <lfam>They offered it to the FSF under a free license <lfam>The message is in the archives but it was not noticed at the time :/ <lfam>Although, it may not have been accepted anyways. <lfam>Who knows. What's done is done <drakonis>aim towards not having weird stances that lead to people being pushed away from the project <nckx>GCC lost its lead because it was GPL. Extensibility was never a significant issue. Just a handy noise generator. <nckx>Anyway: I've spent an hour trying to update alacritty. Is Rust packagaging supposed to be the most soul-destroying tedium imaginable? <drakonis>i'm pretty sure llvm being extensible gave it a huge boost <drakonis>people wrote all kinds of languages with it <drakonis>i hear a lot of horror stories about gcc's internals <lfam>nckx: I don't think it's *supposed* to be <lfam>I recommend the recursive crate importer <bavier[m]1>apple funding probably would not have come if llvm had been copyleft <drakonis>gcc, for the longest, was designed to not be extensible <drakonis>the problem was gpl v3 coming 3 years later <nckx>lfam: Is there automation? <nckx>And I don't mean copy-pasting guix import. <lfam>nckx: I lasted used an in-progress version of it, before it was added to Guix, but it's `guix import crate --recursive $PACKAGENAME` *lfam looks at the refresher <nckx>This is still horrible, but sweet lord is it ten times better than I was doing. <lfam>You might try the recursive crarte refresher <lfam>I imagine it should "do the right thing" with existing packages <lfam>I do find Rust packaging to be very hard <nckx>git stash the bodies && guix refresh times. <nckx>Hmno, let's not do that for now. <nckx>Let's see if the recursive importer is clever enough to omit existing packages. <lfam>I think it's interesting how different systems have optimized for the packaging systems they grew up with, and the feedback loop between language ecosystems and deployment technologies <lfam>As well as the social systems that arise as a result <lfam>I think it could make for an interesting FOSDEM talk <nckx>The answer is ‘maybe, I can't even read this’. <lfam>You need to be well-rested for Rust packaging. Maybe try training for a few weeks with Python, then a few weeks of Go <nckx>Well, it's weird (to me): guix import crate --recursive rust-smithay-client-toolkit produces 3 packages. So I guess Guix knows the rest is packaged? (I did not verify this.) But now it still expects me to add -X.Y to every single input? If it doesn't have that information, how can it know what not to import? If it does... whyy?? <nckx>The problem is definitely that I didn't know what I was getting into. <lfam>I look back at work I did packaging rav1e and... I can't believe it happened <necrophcodr>Hi everyone. I've been trying to do a `guix pull` on a SBC system with 1GB of RAM, and while I know very well that this is NOT the ideal situation and use case of guix, it is nonetheless something I wanted to give a shot. <necrophcodr>Does anyone know of a way to optimize RAM usage of Guix? <nckx>Python can be nerve wracking because absent test it's a run-time crap shoot, but it is in no way close to this. I quite enjoy wrangling the snake. <lfam>Then you need to try Go, nckx ;) <lfam>It's a nice middle ground <necrophcodr>And if it's not really doable, is there a way to build something for a different architecture, and load it up into the store on a different device? (Such as building applications on a server, and trasfering the outs to the SBC?) <nckx>Bah 🙂 lfam wants me to complete the hazing ritual first. I just wanted a shinier shiny terminal. <lfam>necrophcodr: First, I can confirm that you'll need a little more than 1 GB for that, and swap will work, although it will be slow. You can build on another machine and move the results over, using `guix copy`. If the two machines are not the same CPU architecture it's a little more complicated but still possible <lfam>Finally, we know it's an issue and are working to reduce the RAM usage in the context of `guix pull`, although I don't know the exact status of that work <nckx>necrophcodr: The latter is definitely possible, using --system on a more powerful machine (it doesn't even need to be the same architecture). <nckx>lfam: Thanks for the help/therapy. I'm going to stash this mess for now and ruminate on things. <vagrantc>and there's also offloading to a more powerful machine ... though even still, guix pull is quite slow <necrophcodr>Thanks to both of you! I will be looking into manually building and guix copy'ing stuff around for the meantime. I don't mind the slowness of guix pull all that much, I'm usually not in a hurry if I'm running updates :) The RAM usage isn't a problem on any of my other devices, but for a "low-power" SBC (not actually low-power, just lower-power really), it's a bit big <necrophcodr>vagrantc, I know about offloading, but does that work with other CPU archs like x86 vs ARM? <nckx>Yes, if you set up the qemu-binfmt service (see manual). <nckx>A month ago I would have recommended it as magic but it's been unreliable for me lately. But that's probably not Guix's fault, it's just not very fault-tolerant of bad networks. <vagrantc>i did briefly run guix on a wandboard solo with 512M of ram ... but have too many higher spec machines to fight with it *nckx was unclear: *offloading* troubles. qemu is as reliable as ever. <necrophcodr>Thanks again for the info, I've noted it, and will be looking at it at a later date, when it isn't night anymore :) <lfam>I have one on my fridge :) <fnstudio>it's cool, i was looking for exactly that <brettgilio>Debating on when I'm going to compatibility check my config, because I use guile to generate my whole emacs lisp config <branjam>Oh wow, how does your setup contrast with a pure emacs elisp config? ***catonano_ is now known as catonano
<bandali>nice. someone should get in touch with them and ask to have guix support added to builds.sr.ht out of the box <joshuaBPMan>What does it mean to have guix support added to builds.sr.ht? Are you talking about continuous integration? <str1ngs>well don't use format when ~ is in a uri 🤦 <bandali>joshuaBPMan, yeah. adding a guix system image for builds.sr.ht build CI <jurlerci>hello, im thinking about moving to guixsd, coming from nixos. i was wondering what the advantages of guixsd over nixos would be, im interested in reproducible environments for building software, especially pinning libraries and whatnot <apteryx>One of the differences between Guix and Nix that I know is that in Guix everything is free software. <pkill9>jurlerci: for me the advantages are, better commandline interface, better language (in my opinion), more organised package definitions e.g., no capitals in the package names <jurlerci>how far does that extend? i dont have an atheros wireless card so will i not be able to use wireless? <apteryx>to me that's a benefit; I want my distro to be as pure as possible and not be tricked into installing software whose sources I can't access should I want to study it. <pkill9>everything is built from source, there are no package definitions that just get a prebuilt binary and wrap it <apteryx>jurlerci: it comes at the price of reduced hardware support, but that hasn't really been a serious hindrance (I've got a USB dongle to plug in the machines whose WiFi chips aren't supported by free firmware) <jurlerci>hmm ok, i want to get an atheros card eventually but until then no wireless is a bit of a deal breaker, i only really work at libraries <apteryx>I reckon another advantage is good documentation that covers Guix, as an info manual. After you've learned the basics of an info reader, you won't be depending on the browser as much to find the information you need. <apteryx>then, there's one (powerful) language to bind everything together, from your system to your package definitions. <jurlerci>im big on racket so having my system in /a/ lisp is fun sounding ***terpri__ is now known as terpri
<pkill9>yay i fixed my domain's ssl issue, just needed to restart nginx <pkill9>i keep thinking some esoteric problem i've encountered in guix that i'm going to have to work out, but then the problem is simple <raghavgururajan>I need help with syntax for, declaring a configure-flag "--disable-java-bindings", if current-system != supported systems of openjdk14. <leoprikler>raghavgururajan: (member system (package-supported-systems openjdk)) <leoprikler>because you'd need openjdk as an input to build the bindings in the first place, no? <raghavgururajan>leoprikler, AH! I am looking for the opposite. Java Bindings are enabled by default. So I wanted to pass "--disable-java-bindings" as configure-flag, if the current-system is not supoorted by openjdk. <leoprikler>you can do something like (if check '() '("--disable-java-bindings")) <raghavgururajan>Alsom I already have the snippet to add openjdk as native-input, if the current-system is supported by openjdk. This snippet is almost similar to what you pasted above. <leoprikler>First have whatever-package-minimal, which does not have java bindings <leoprikler>then have whatever-package which inherits from minimal, has all the jdk stuff <leoprikler>you don't need to encode the (transitive) supported systems afaik, Guix should do that automatically <rekado>we build with jack1 because that’s sufficient <rekado>a package built with jack1 will have JACK support; doesn’t matter if the server is jack1 or jack2 <rekado>we build everything with the same variant of jack, and this just happens to be jack1 for simplicity (fewer inputs than jack2). <rekado>this really shouldn’t be an obstacle at all <rekado>I don’t understand why you’d need to set LD_LIBRARY_PATH <janneke>omg "wxwidgets-minimal@3.0.5.1: build system `glib-or-gtk' does not support cross builds" <janneke>wtf, did we lose cross-build support? <janneke>oh, i had a derivative package that just inserted: (build-system gnu-build-system) <janneke>this does not seem to work anymore...hmmm <rekado>since glib-or-gtk is only minimally different from gnu I think we can inherit cross-build support from gnu. <necrophcodr>I'm runnning Guix on a "foreign" distribution, and I've set up channels in /etc/guix/channels.scm to be able to upgrade guix itself using only `sudo guix pull --fallback`. <necrophcodr>This _appears_ to work, and it even says "x new packages: ..." when finished, including "entr-git", a package I've added to my own channel, specified in the channels.scm file. <necrophcodr>However when I run `guix show entr-git` it simply errors out that the package does not exist. <necrophcodr>Note that previously I had the same setup, but I would have a ~/.config/guix/channels.scm file setup, and run `guix pull --fallback` as my local user, not as superuser. <necrophcodr>So my question is if this is fixable? Is it possible to run guix upgrades (guix pull) only as root, with all channels defined only for root, but still have ordinary users be able to install packages? <rekado>necrophcodr: as far as Guix is concerned the root user is just some user. Its packages or settings don’t affect other user accounts. <rekado>you can make the root user’s Guix available globally by linking it to a global location (e.g. /usr/local/bin). <necrophcodr>rekado, but then surely the above should work, when on a foreign distribution the `guix` binary is available as a symlink in /usr/local/bin/guix and points to the root users current guix version? <rekado>you need to make sure that /usr/local/bin appears on PATH before ~/.config/guix/current/bin <necrophcodr>I've removed ~/.config/guix/current symlink entirely. <rekado>okay, and readlink /usr/local/bin/guix gives you the root user’s Guix? <necrophcodr>yes: /var/guix/profiles/per-user/root/current-guix/bin/guix <rekado>okay, does “guix describe” work? <rekado>do you want to disallow “guix pull” for regular user accounts? Or is it just about specifying channels globally? <necrophcodr>I've performed a readlink on /var/guix/profiles/per-user/root/current-guix/bin/guix and it points to a binary in the /gnu/store, and I compared this to what under root /root/.config/guix/current/bin/guix points to, and it's the same. <rekado>I think recent versions of Guix respect /etc/guix/channels.scm <necrophcodr>I mean that's where I've specified my channel stuff, and it appeared to work when pulling, but not after that. <necrophcodr>But channels don't matter during normal usage right, they only matter for the pull process? <rekado>when you remove the symlink and let the unprivileged user account run “guix pull” it should also get the same variant of Guix. <rekado>the channels file is only read on “guix pull” <rekado>the result is a variant of Guix that has access to these channels <rekado>I don’t know what’s wrong in your case; this should work <necrophcodr>I know, I can simply do the same with the normal user accounts, but I'd prefer to only do `sudo guix pull` so as to have only one variant available. <necrophcodr>That way I know that the daemon is running the same version etc <rekado>when the user runs “/root/.config/guix/current/bin/guix describe” – does that work <rekado>does “/var/guix/profiles/per-user/root/current-guix/bin/guix describe” work? <rekado>“guix describe” looks at itself to determine its origin <rekado>perhaps it should first attempt to follow any symlinks <necrophcodr>Yeah, using `/var/guix/profiles/per-user/root/current-guix/bin/guix` instead of `guix` works and finds my channel-related stuff <necrophcodr>and `/var/guix/profiles/per-user/root/current-guix/bin/guix show entr-git` as mentioned previously works fine <necrophcodr>(despite /var/guix/profiles/per-user/root/current-guix/bin/guix being a symlink too) <necrophcodr>but perhaps the issue is that /usr/local/bin/guix is a symlink to a symlink <rekado>it shouldn’t really matter because profile generations are symlinks to symlinks <rekado>could you please email bug-guix@gnu.org with a short description of the problem? <necrophcodr>i'll gather up the data i've gotten here and i'll write an email, yes <necrophcodr>thanks for the help, at least i have a workaround for now, and some information for possible bug hunting :) <rekado>janneke: the only problem is that this would need to go to core-updates <janneke>rekado: yeah -- also i took a quick look -- i don't saw how to do it without a lot of duplication -- so added the package-inherit workaround again for now ***terpri_ is now known as terpri
<Formbi>does anyone know how to use mcron? <nckx><raghavgururajan> --enable-authentication-scheme=[pam/crypt/shadow] <nckx>I'm not going to dive into what each one is/was but Guix uses PAM, so enable that. <Formbi>I'd like to run something every half an hour between 11 and 22 <nckx>peanutbutterandc: <disclaimer: never used srfi-64, blah blah> but what happens if you replace ‘define’ with ‘set!’? <nckx>peanutbutterandc: I see you've asked in #guile, I think you're more likely to get an answer there. <peanutbutterandc>nckx, I have tried both channels... wow. I didn't know srfis actually came from their own repo. I thought guile devs implemented an implementation of the srfi... <pkill9>rekado: I dunno, guitarix can't connect to jack2 without LD_LIBRARY_PATH set <pkill9>and pulseaudio needs it too to switch seamlessly <pkill9>also rakarrack fails to start when using jack2 (with LD_LIBRARY_PATH set as well, without that set it doesn't find jack) <rekado>clang-runtime-3.5 fails to build <nckx>peanutbutterandc: How about (module-define! (resolve-module '(srfi srfi-64)) 'test-log-to-file #f) ? <pkill9>the rakarrack thing is probably just a bug <pkill9>rekado: maybe the protocol is the same but the way it's accessed is different? idk <pkill9>some comment somewhere said they tried to make jack2 ABI compatible with jack1 but failed <raghavgururajan>This error seems to be independent of package I am building, because there is no mention of "pkexec foo" in source files. <nckx>raghavgururajan: That's basically the equivalent of using ‘sudo’ in a Makefile. Can you paste the offending (even if innocent) package? <rekado>pkill9: something is wrong. The problem is not with the API, I think, but is something to do with the name of the socket file. <rekado>our programs that have been built with jack1 try to access the jack socket file at /dev/shm/jack-1000/default/jack_0 (or similar) and fail because jack2 doesn’t provide it. <rekado>we should check if there’s a configure option to tweak that <pkill9>cool, that will make things easier <nckx>raghavgururajan: Even on bayfront? <raghavgururajan>nckx: Ah, you can build in bayfront. But comment-out the gnome-bindings input. <raghavgururajan>nckx: I wanted to ask you about another error. In the git repo you pulled, if you try to build mutter with tests enables and commenting-in the 'custom-check phase, there will be an error "Cursor not found". I spent hours fixing the mutter tests and fixed most of the errors, but this supposedly last one is notorious. I even tried setting XCURSOR_PATH. Didn't work. Can you have a look? <rekado>pkill9: we need to use the variant of libjack.so that the running server expects. We can’t use the JACK1 libjack.so with a JACK2 server. <rekado>so it seems that setting LD_LIBRARY_PATH to swap out libjack.so is correct here. <reepca>what's a command that I can use as a no-op to replace ldconfig? <rekado>pkill9: I guess other distros use an alternatives mechanism to globally decide on the libjack.so variant. <rekado>for Guix System we could probably find a way to make this a little nicer. <brettgilio>Me: I have many years of experience in OCaml, Scheme, Haskell, and monadic effects. I am a compiler developer at heart, but can apply rigorous mathematical structures to programming for type safe and algebraically effectful results! I also know proof assistants! <brettgilio>Job search: That's great! I don't know what you said. Have you heard of CSS3 and Swift? *nckx was once asked if they had experience with low-level languages like PHP. <dlowe>what's a high level language, then? <raghavgururajan>nckx: Please leave me messages regarding gnome-shell and mutter, via sneek. Gonna sleep for a bit. *raghavgururajan + zopiclone = zzZ <Kimapr[m]>So currently i'm booting guix with efi-grub. But my computer runs BIOS so i have to use something like DUET to actually boot it, which adds another booting step. When i try to install GRUB as non-efi it fails to boot complaining "unknown filesystem" <nckx>raghavgururajan: I just got back. I think the bayfront build has frozen. I'll try again. <nckx>Ikr. PHP is more of a systems language. <nckx>(A high-level language was something that compiled to JavaScript. PHP runs on servers, close to the metal, and is scary. I didn't take the job.) <efraim>I bet input rewriting for package-with-jack2 would work <guix-vits>Kimapr[m]: Do You use btrfs with compression, maybe? I once had this: install, update, then add compression. <sneek>Welcome back guix-vits, you have 1 message! <efraim>Which reminds me, I should submit the one I have for native tensorflow. I heard it's much faster than our generic one <nckx>Kimapr[m]: Using zstd by any chance? <Kimapr[m]>if that's any use my root partition is on a usb drive <nckx>This sounds like your first stage GRUB is installed without the file system driver required to load the rest of GRUB (modules under /boot). Which means grub-install is very confused & thinks the partition containing them is a different file system type than it actually is. <nckx>Kimapr[m]: Do you get a rescue prompt? <Kimapr[m]>but it says "unknown filesystem" about every filesystem available to ls <nckx>Right. I've had exactly this happen but it was *years* ago and I don't remember how I fixed it. <nckx>I think basically invoking ‘grub-install --force-include-more-stuff=the-file-system-driver’. <nckx>Looking at the docs, maybe ‘--modules=ext2’. <nckx>There's nothing magical about Guix's GRUB, you can call grub-install manually as much as you want without touching Guix's grub.cfg. <Kimapr[m]>hmm, so i may still leave "grub-efi-bootloader" and have reconfigurations not touch bios grub ***jonsger1 is now known as jonsger
<rekado>efraim: I think rebuilding packages with jack2 is overkill. <rekado>we *can* swap out the implementation <Kimapr[m]>uh, so which --target in grub-install is bios x86_64? <Kimapr[m]>alright, i'm trying i386-pc with --modules=usb <nckx>Kimapr[m]: i386-pc. And GRUB just uses the ‘devices’ exposed by your BIOS, it does not use its own USB (or SATA) driver by default. Including usb probably won't hurt but I think you should look at file systems (e.g., ‘ext2’) instead. <lfam>There are some new features related to hibernation in linux-libre 5.8. Maybe it could be useful for integrating hibernation support in Guix System <nckx>All that's missing is me finally merging my patches. Ahem. ***ezzzc7 is now known as ezzzc
<lfam>Something I don't really understand about configuring the kernel build is that it offers options that don't seem to make sense. I'm configuring for armhf and I have to decide if I want to enable SPI drivers for AMD chips <lfam>I guess that AMD did make some ARM devices <jonsger>lfam: at least we have some of those :) <lfam>I recall they made some 64-bit chips, but this would be for 32-bit <jonsger>lfam: oh, eh armhf is 32bit. I'm not aware of something. At least their security chips are ARM based AFAIK <vagrantc>lfam: speaking of configuring the kernel ... i noticed somewhere along the way (maybe 5.x?) the arm64 kernel configs started looking more-or-less like hte defconfig for arm64 ... <lfam>Does it mean that something is missing? Or some things should be disabled? <vagrantc>i should probably confirm this myself before going down this rabbit hole <lfam>I haven't done an exhaustive survey but I have tended to notice that the Intel-compatible configs enable most device drivers, like you would expect for a distro kernel. But the ARM configs tend not to <vagrantc>but i looked at the config difference between linux-libre-arm64-generic and linux-libre and it looked very similar ... which means a lot of effort for very little gain ... back when i introduced the arm64 kernel it was based off of the Debian arm64 kernel config <vagrantc>so many things were enabled as modules rather than built-ins <lfam>Most things should be modules, right? <vagrantc>i would say so ... e.g. you only need to use the relevent drivers for the running system <vagrantc>there are some things that are harder to modularize, but generally... <lfam>Do you have changes you want to see with the ARM kernel configs? <vagrantc>i've just been using the -generic configs as i got weary of playing whack-a-mole to enable the right modules <vagrantc>so, there are probably changes worth doing ... but it's a lot of work to track them down <lfam>Well, suggestions are welcome :) <lfam>Since we don't have any metrics on substitute usage yet, we don't know how many people are using each architecture. But I expect that it's probably about 90% x86_64, and 5% aarch64 <lfam>So, we won't necessarily get bug reports <lfam>I expect aarch64 usage to increase in the future *vagrantc stares at the currently refusing to boot pinebook pro ... :/ <lfam>There is a lot of synergy between aarch64 and the free software / open hardware movements <vagrantc>probably drained the battery down to nothing accidentally <lfam>I get the sense that people are willing to sacrifice convenience and performance to use aarch64 <lfam>And in a few years there may not be any performance differential <vagrantc>it's *almost* to the point of being usable with things like the pinebook pro ... and there are a few other candidates too <lfam>Unless the ARM ecosystem collapses due to mismanagement of the IP <vagrantc>but there have been many *almosts* for many years now... and yeah, ARM ... ugh. <lfam>Well, Apple has surpassed "almost", but they don't sell their chips <lfam>And some of the servers are interesting *vagrantc has seen a few savvy engineers at ARM getting jobs elsewhere lately... <lfam>nckx: I'm concerned about the future of ARM, because the company recently put itself up for sale. To me it indicates that they don't see a bright future for ARM <lfam>But, it's owned by softbank, and they are not exactly the smartest <vagrantc>start a crowdfunding platform to buy it :) <lfam>I can offer about three fifty <rekado>does anyone have a package for Emacs 27.1? Can we just promote emacs-next? *rekado updates all CRAN packages again… <rekado>I wonder what the status of the Gnome upgrades branch is <rekado>I think it’s not a good look for us to be so far behind with Gnome. <happycorsair>Hello, everyone! Is there a mechanism in Guix that works like update-alternatives in Debian-based distros or eselect in Gentoo? My problem is that ctags is provided both by emacs and universal-ctags, and I'd like to use the latter <jackhill>I've heard back that treepy thing that they've fixed the problem, and treemacs is investigating. <bandali>yeah, the emacs-next i'd contributed should be a good starting point, thanks for working on this jackhill <bandali>i'm super busy at the moment, but i'll probably come back around and bump emacs-next once emacs is upgraded to 27.1 <mroh>jackhill: your patch worked well for me for rc1. There was one issue in the list you made (thank you!) where I thought, it might make sense to comile emacs with --with-gmp <jackhill>mroh: cool, thanks for testing. Yes, I think we may want to update the cofigure options. Would you mind writing to the ticket so I/we don't forget? <leoprikler>happycorsair: it is possible, but a somewhat hidden functionality <leoprikler>build-profile uses union-build internally, which merely warns you about duplicate filenames and picks the first one <leoprikler>so if you put universal-ctags before emacs you should get the one you want <jackhill>I wonder if we'll still need the emacs-wide-int variant. <mroh>jackhill: may I make a treepy patch or are you already in progress? <apteryx>is someone else having issues getting chromium recognize their microphone? <happycorsair>leoprikler: oh... nice hack, thank you very much!!! Gonna test it. <apteryx>seems I have to start pavucontrol to get a bit more chance of getting the sound to work <leoprikler>you mean sound as in output or as in the chromium mic thing? <vagrantc>whew. pinebook pro boots again after installing the correct bootloader :) <apteryx>after reconfiguring my system: guix system: error: exception caught while executing 'start' on service 'file-system-/sys/kernel/debug <apteryx>Throw to key `match-error' with args `("match" "no matching pattern" ("none" "/sys/kernel/debug" "debugfs" () #f #f #f))'. <nckx>Mounting /s/k/d is a relatively new addition; guess the first time isn't handled too well. *nckx looks at the patch queue... eheh. <lfam>Is this a new filesystem in linux-libre 5.7? <nckx>No, not at all, that's why I don't quite understand what's going on. <nckx>Was CONFIG_DEBUGFS (or whatever) only enabled for Guix in the same patch? <lfam>It was already enabled in 5.4, at least for x86_64 <nckx>apteryx: Does it give any more info about which match clause is failing? <nckx>Unhandled matches really are Guix's Achilles heel... :-/ <nckx>Is this a cultural Guile thing or just a Guix thing? <apteryx>it's a nice feature to fail when you couldn't match anything... but the exceptions need to be handled somewhere to present it nicely I guess <pkill9>does there exist an appstream metadata file for guix? <pkill9>this would be a good addition to the guix data service <pkill9>each appstream file can be associated with each revision of guix