IRC channel logs
2024-02-05.log
back to list of logs
<ulfvonbelow>if you pastebin your work in progress to e.g. paste.debian.net, I might be able to give more advice <spiderbit>it complains that it don't know file-append now <ulfvonbelow>if it's complaining about not knowing what file-append is, odds are you need to add a (use-modules (guix gexp)) <ulfvonbelow>aside from that, your service looks good to me. it could be simpler if it used guile instead of invoking sh, but that's fine <spiderbit>guix system: warning: exception caught while executing 'eval' on service 'root': <ulfvonbelow>put a #$ in front of the file-append form, so it looks like #$(file-append ...) <ulfvonbelow>this "ungexps" it, substituting the value returned by the file-append form instead of just leaving the form unevaluated until it gets to shepherd <snape>(specification->package "sh") is kinda slow and overkill <snape>you can just use bash instead <snape>(the variable referring to the package) <ulfvonbelow>also come to think of it, I don't think we even have a package named just "sh" (though of course bash provides a file under that name) <snape>and replace (gnu packages) with (gnu packages bash) <spiderbit>I don't load only (gnu packages) I have (gnu) and (gnu packages ...) but not with bash <spiderbit>is (gnu) bad does it slow down the reconfigure or something? <spiderbit>ulfvonbelow: is the #$ what in elisp is the ` <ulfvonbelow>specification->package works by looking through every package guix knows about to find one with a matching name (though IIRC after the first time this package name mapping is cached) <spiderbit>so run a procedure inside a quoted string or something alike <ulfvonbelow>that's why it can be slow if you're not already doing that elsewhere <ulfvonbelow>there are also #+ and #+@, which are like #$ except that they represent a "native" input, which matters when cross-compiling <spiderbit>`(bla ,(myfunc)) or something alike not done to much lisp for a while <ulfvonbelow>also note that guile does have the usual ` , and ,@ but they're used specifically for lists, while gexps have extra bookkeeping attached under the hood <spiderbit>without that resume is extremely buggy like 50% systemcrash <spiderbit>had to copy paste that into a terminal everytime I rebootet. <snape>well the slow thing is specification->package, more than loading the module <snape>oh I just read ulfvonbelow it just has been said mb <spiderbit>today I wrote a special XCompose file so that the nonGTK apps don't use it <spiderbit>so that I can write my changes in the normal one <spiderbit>because gtk or gtk3 does ignore this env variable <spiderbit>the original goal was to just XCOMPOSEFILE="..." firefox <spiderbit>sthe nonGTK just loads the defaults and is otherwise empty <ryan77627>Hi all, quick question. I noticed that BlueZ is woefully out of date (5.66, from 2022!) and has been a bit buggy for me and my headphones. I've gone ahead and updated to the latest upstream (5.72) and would like to contribute the patch after testing for a bit. Is BlueZ considered one of those "core" packages that need to be contributed a special way rather than the regular patch request emails? <ryan77627>All indications point to no, but I wanna double check <ieure>Every time I `guix gc', then `sudo guix system reconfigure' or `guix home reconfigure', it redownloads/rebuilds a ton of stuff. Is there some way to like... gc... without deleting things that are clearly needed? Is this a bug? <ieure>gc deleted almost 40gb of stuff, so clearly there was some garbage there. But just as clearly, it deleted stuff that I needed. <apteryx>I'm trying to build guix using a locally built guile, but getting: ice-9/eval.scm:293:34: no code for module (srfi srfi-209) (my locally built guile has such module) <apteryx>I've 'ln -sf /path/to/src/guile/meta/guile ./guile', as well as added '. /path/to/src/guile/meta/uninstalled-env' before the GUILE_LOAD_* environment variables in pre-inst-env <apteryx>ieure: that's because of grafts, I'm not sure why it's not considering what grafts need when cleaning stuff, I think grafting require sources but no references to those are retained, so they are cleared each time <apteryx>I hacked $(GUILE) in Makefile in guile-compilation-rule to be just ./guile <ieure>apteryx, Hmm. So any package with a graft anywhere in its upstream dependencies will get gc'd and need to be rebuilt? <ulfvonbelow>ieure: 'guix gc' only considers reference edges (that is, runtime dependencies). So if you don't have substitutes enabled (or they're lacking) and you have a gc root that includes a rust package, running a 'guix gc' will still nuke the compiler unless it is referenced via some other route. <ulfvonbelow>and in the no-substitutes case, that means rebuilding 15 or so versions from scratch <ulfvonbelow>if I remember correctly there was some option to make it treat derivation inputs as being referenced by derivation outputs, but it was for guix daemon and applied to the entire thing <ieure>ulfvonbelow, So the specific case thing that's grinding my gears is that I packaged the LibreWolf web browser, which I have installed via Guix Home, and `guix gc' removed. Since this is a personal package, I don't have substitutes, so my laptop is unusable for the ~70 minutes it takes to recompile it. <podiki>ryan77627: guix refresh bluez -l says about 2300 dependent packages, so it would need to go on a branch. i might take it on mesa-updates next round, hopefully in a few weeks <ulfvonbelow>a good example of this is that if you reconfigure your system, then run guix gc, then try to run 'guix system roll-back', it will start downloading grub so it can reinstall the bootloader <ieure>ulfvonbelow, Is that because some package in the librewolf dependency tree has a graft? Or because `guix gc' can't see the Guix Home profile? Or something else? <ieure>And how can I make it... not do that <podiki>ryan77627: in any event, good to submit a patch! i'll try to remember (for mesa-updates) but i usually put out a call on guix-devel (and here) to get anything relevant <ulfvonbelow>if it's in your guix home profile and it got gc'ed, that's a bug <ulfvonbelow>ahh I think I understand what was meant by the grafts thing now <ulfvonbelow>but if the grafted version didn't get gc'ed, I don't know why it would end up being rebuilt... <ulfvonbelow>ieure: what did you do that triggered the rebuild of librewolf after the gc? <ieure>Okay, realizing that I may have brought this upon myself. The exact sequence of events was "guix gc" "guix pull" "sudo guix system reconfigure" "guix home reconfigure". I suppose the guix pull could have caused one of the inputs to librewolf to change, necessitating a rebuild. <ulfvonbelow>hmm, actually, I suppose if the situation was such that an applicable graft was added or removed between when 'guix gc' was run and the rebuild-triggering command, the with-grafts derivation may have changed <ryan77627>podiki: Thank you! I'll test it out for a week or so and if nothing huge comes up I'll send one in <ieure>After this thing finishes its rebuild, I'll see if gc wants to remove it again. <ieure>Was able to unbundle everything except libnss, because the version in Guix is too old. <podiki>ieure: you can also check references to a derivation, if you haven't already explored "guix gc" to investigate derivations/what will get gc'ed <ieure>podiki, So, I did run `guix gc --list-dead' and specifically check to see if the current librewolf package was in that list; it wasn't. <ieure>I think that's further evidence that the `guix pull' gave me an update for one of librewolf's inputs. <podiki>you can roll back guix pull too, btw :) and check the derivation you get for librewolf <ieure>ulfvonbelow, So, I'm not really sure what you mean by "ungrafted version." <podiki>btw, if you have a patch for nss (or maybe just a version bump is good?) do submit that. guix refresh doesn't find nss versions, so that is one reason it might be missed <ieure>podiki, It's bundled with glibc or binutils or something like that, it's not a simple version bump. <ieure>ulfvonbelow, My package definition neither contains a graft, nor is grafted onto anything. Some of its inputs might, but the package itself isn't doing any grafty things at all. <ulfvonbelow>the way grafts work is that a package is built with ungrafted versions of all of its inputs, then a second derivation takes the output of the original derivation and patches it to reference the grafted versions of its inputs. This is why 'guix build --derivations' can give different results depending on whether you pass '--no-grafts' or not <ulfvonbelow>so the initial derivation would be what you get with 'guix build --derivations --no-grafts librewolf', and the grafting derivation would be what you get with 'guix build --derivations librewolf' <ieure>podiki, Okay, I was wrong, it's a standalone thing. Maybe I was confusing this with a different thing. <podiki>ieure: no worries, was just looking myself. but was not updated on core-updates. you can always have an nss-next and nss-certs-next for newer versions. but yeah we should update nss, important! <podiki>it does have a ton of dependents, of course <ieure>podiki, I was confusing this with nss the nameservice switch thing, but it's actually "network security services," a Mozilla thing. <ulfvonbelow>for what it's worth I use a system that doubles as a personal substitute server + offload machine and has a ton of disk space, and thanks to the offloading everything I build gets stored there <podiki>yeah, notably, certificates one needs to for internet services <ulfvonbelow>so I get to 'guix gc' relatively freely since I have a speedy LAN connection to whatever gets gc'ed <ryan77627>My two cents on the whole gc thing, I know that I avoid GC'ing unless I'm going to be updating anyways since I also have a lot of packages that get rebuilt as well. I doubt anything would be changing, I pin my channels to commits and don't run pull between something like `guix gc` and `guix home reconfigure <path>` <ryan77627>I need to take the time to set up a personal cuirass instance at some point for my personal packages <podiki>i only gc if i really need disk space :) <podiki>and also never in the middle of working on big branches, if i've build ghc, rust, etc. locally anytime recently <ryan77627>That's fair, it seems that's the best way to go about it. Though I may look more into offloading at some point, that may serve as a good stop-gap solution for me <podiki>very basic, but fits my needs. i don't have intensive local packages to build, only if i'm working on some updates here, which is not all the time <ulfvonbelow>truly crates are a mystery. maturin 1.4.0 demands a rust-url of at least 2.5.0, while at the same time a ureq *newer than what it depends on* demands an exact match of rust-url at 2.3.1, and this obviously causes a conflict. <ieure>ulfvonbelow, Yeah, this is a thing I need to set up. <ieure>An offload/substitute server. <ulfvonbelow>it doesn't even need to be very powerful as long as it can be a sacrifice to allow the user-facing computer to keep running smoothly <klm`>I can't get guix package -p myprofile -i gcc-cross-avr-toolchain to work. it can't compile anything: https://paste.debian.net/1306341/ Is everyone else seeing this? Installing it into a profile like that should suffice, no? <Guest12>Hi, does anyone have any idea if "NVIDIA RTX™ A500 Laptop GPU 4GB GDDR6" will play nice with the libre kernel directly from guix? <klm`>When I include CROSS_* , avr-gcc finds all the things it needs https://paste.debian.net/1306343/ . How can we fix gcc-cross-avr-toolchain so that its search-paths includes those of its cross-gcc? <klm`>or, of course perhaps a better solution, somehow fix gcc-cross-avr-toolchain's cross-gcc to not need them. <klm`>I'm pretty sure the latest gcc-cross-avr-toolchain package is broken, but I'm afraid I'm not in a position to fix this myself :-( <snape>ieure: it would be great to first review the wasm packages <snape>they come from non-guix, the guy doesn't reply <snape>I just don't want to include code on which no one has responsability <apteryx>I was replying to "I just don't want to include code on which no one has responsability" <apteryx>in the end it's up to all of us to stand behind what we're adding to the collection <snape>apteryx: I agree, but how a team helps here? <dthompson>lechner: uh i dunno maybe? :) 2015 is a long time ago <dthompson>not sure if I handle nonbreaking spaces there. why do they need special handling? <dthompson>my memory is fuzzy but I think I realized that all that special escape sequence handling was unnecessary and error prone as you've seen <dthompson>oh right, those escape codes are only necessary for non-utf8 encodings <lechner>dthompson / well, it's a bit hard to see without prettified page sources, but i think Mumi already does that <lechner>dthompson / anyway, is you recommendation to drop that code from Mumi?> <dthompson>my recommendation is to generate utf-8 encoded html pages by using <!DOCTYPE html> on the very first line so that no special escaping is necessary. <apteryx>snape: etc/teams.scm; helps to be informed of what patches are sent for a subset of packages (hopefully helping people keeping track of what's to review) <snape>apteryx, oh ok, well I'm in the mozilla team <snape>apteryx, do you know how mumi got the debbugs database? <dthompson>lechner: no html needs some special handling when serializing due to irregularities compared to xml <dthompson>like elements that have no closing tag: <br>, <meta>, etc. <dthompson>(haunt html) has served me well and seems to be working well for many others as I haven't heard from anyone about buggy behavior :) <lechner>dthompson / thanks! would you mind rephrasing the sentence that started with "no html needs some ..." please? <dthompson>I meant: no, you shouldn't use sxml-xml because serializing sxml to html requires some special handling of tags. <lechner>dthompson / okay, thanks! i have poor vision and can easily miss a comma or a period <jpoiret>ah yes, transient test failures in GHC <jpoiret>snape: mumi has a special private access to debbugs i recall, not something that's available for the general public <lechner>snape / jpoiret / please ask if you need access <rekado>lechner: what locale is active here? What locale-relevant environment variables are set? <snape>jpoiret: thx, I don't, I just was curious <lechner>snape / you can get the bug-specific mboxes from the web interface but rsync is more efficient for duplication between servers <lechner>i'm looking there because the mojibake occurs only in the colored diffs <janneke>rekado: offtopic -- the book's title is "Free at Last: The Sudbury Valley School" -- i only read the dutch translation <singpolyma>Is there a good way to pass a string on stdin to (invoke) ? <jmes>Hey, I'm trying to run some code that accesses files relative to my guix home config, but I'm missing something. Here's a snipped explaining what's going on: https://bpa.st/NY3Q <jmes>Note that if I simply remove the untemplate call it works so I dunno what the error is on about. <jmes>Also if I replace untemplate with something simple like (format #f "hello") then that will run correctly. <jmes>Oh and untemplate works independently of guix home. <snape>jmes, try to use an absolute path maybe <snape>(untemplate "/absolute/path/to/your/file") <snape>I agree the error message is wrong <snape>the path should be relative to where you call guix <jmes>snape: Thanks, I guess I should have tried that, it worked. I'm just confused why I can use relative paths elsewhere in my home config (for example with calls to local-file). <snape>jmes: files that are args of `local-file` are resolved in a different context, and it's complicated <snape>it depends and whether it's a litteral string, etc <jmes>snape: Good to know... I'll probably have to grok that eventually. Thanks again :) <jmes>The intent was to be able to insert the result of some arbitrary scheme code in my XDG_CONFIG_HOME files before they get saved to the store and linked to my profile. <jmes>Just some simple pre-processing to add unified colour schemes or what have you. <jmes>Now I can write directly in an application's config file "bg_col=|(col 'bg-main #:alpha #xdd)|" and guix home will process it for me <jmes>In this case I have some code to track an `active-theme' so you can change that and it'll update every config file you've "templatized" <jmes>I think Andrew Tropin's RDE does something fancier (probably better) but I haven't tried it out yet. <snape>jmes: sorry dumb question, what does it mean to add colour to a config file? <jmes>snape: hah! I mean a colour for applications which use colour somehow. Like a window manager an application launcher :P <jmes>Normally these configs aren't easy to unify. But guix home gives us a nice opportunity to pre-process them. <apteryx>it seems to keep getting hung recently <alethkit>If I want to upgrade my drive, is there any specific preparation to do beforehand? <apteryx>otherwise not really. Guix System makes migration easy by encapsulating most system config in your config.scm <snape>alethkit, most importantly, backup your private keys <alethkit>does that mean I only have to worry about my home partition, and can essentially throw away most of /gnu/store? <snape>if you are using Guix System, you might have data in /etc too <jmes>Depends where your system config lives and how much non-guix-y stuff whose state you care about. <snape>there should be nothing to backup from /gnu/store indeed <apteryx>anyone else not being able to send with 'git send-email' due to gmail "Too many login attempts, please try again later" error? It was my first submission of the day. <apteryx>it resumed... big brother must have been watching <jonsger>hmpf, sddm and the "graphical stuff" doesn't start anymore on my PC. Choosing an older system generation from 2024-01-07 still boots correctly <apteryx>I'd like to plug a global '--log-level' guix CLI option in a WIP; any idea where that should go? perhaps run-guix-command, but that doesn't currently parse arguments; it hands off to each scripts IIUC <apteryx>I guess I'll pick --log-level from args and remove it from there, as I need its value early, in run-guix-command <civodul>i tend to be wary (prolly too much) of logging statements infecting otherwise nicely functional code :-) <civodul>hey jonsger! ssdm’s login screen doesn’t show up? <civodul>is that reproducible in ‘guix system vm’? <apteryx>so I'm placing a few debug level logs here and there <apteryx>civodul: I put one in coalesce-duplicate-inputs for example, printing the input being set-cdr! <ieure>podiki, I tried upgrading nss, the new version takes like two hours to build and has test failures. sigh <podiki>oy, yeah nss has a long test suite, i remember that <podiki>feel free to post a WIP patch for others to continue, or maybe someone here has looked at nss in the recent past? <civodul>apteryx: yeah, that’s typically a place where i’d rather not have logging <civodul>i mean, one might need logging as a way to understand/debug it, but having it permanently would be a hindrance IMO <civodul>i’d rather have tests and quickcheck and whatnot than permanent logging <civodul>it’s a pure function so it can definitely be tested <apteryx>in that case perhaps! but having a way to say "be verbose about what you're doing" is valuable I think <civodul>but that’s more like imperative things, or operations that might take time, things like that <apteryx>enabling the right log level is a good way to do this; --log-level=debug <sham1>Does the extra-config option for xorg-configuration take file-like objects <Groumf>Hello guys. Do you know if anybody has worked on the topic of composing system definitions? <civodul>Groumf: hi! composing on what sense? <civodul>sham1: the manual says ‘extra-config’ is a list of strings <sham1>It also says that it's a "list of strings or objects" (emphasis mine) <sham1>And I'm wondering just what objects those would be <Groumf>Well I typically have quite a few things in common in all of my systems. Let's say, my pager of choice and it's configuration. <sham1>Pager stuff sounds like it'd be up the alley of a home configuration <Groumf>It would make sense to have that base system and to build upon it for my various specific needs. <Groumf>sham1 that is where it lies but let's keep the discussion simple, I should not have talked about config :) <sham1>Yeah, you can absolutely do that <Groumf>(sorry about the guys/people thing not a native speaker, I have no idea what the difference is) <civodul>sham1: re objects, right; looking at the code, those objects could be numbers and such, but not file-like objects (only their file name would end up in the config, not their content) <sham1>Oh that's a shame. The docs could have been clearer about that <civodul>Groumf: you could (define base (operating-system …)) and then (define custom-os (operating-system (inherit base) …)) <civodul>not sure if that answers your question <sham1>I do wish it could have taken file-like objects so I wouldn't have to embed my touchpad configuration as a string in the system config file(s) but instead as a file fragment on my git repo <sham1>Oh well, might have to send email about that at some point <Groumf>civodul well it does but how would I go aout extending these. <sham1>You inherit from your base OS and then you can do things such as add more packages based on whatever you got from your base <Groumf>Hmmm ok I think I see how I can do that. I will dig in that direction. Thanks. <sham1>e.g. you might say in your extending operating-system definition: (packages (cons* package-1 package-2 (operating-system-packages base-os))) <sham1>I'm thinking about abstracting my configs like that, but I need to get the motivation to actually write the code <rekado>janneke: thank you, I had just looked for it yesterday <rekado>lechner: I’ll try to reproduce this in a smaller example <rekado>lechner: I see that a literal non-breaking space ends up as \xa0 in the sxml output of “prettify” <rekado>and feeding that sxml to sxml->html leads to HTML that includes a literal non-breaking space <rekado>when I visit https://mumi.juix.org/63508#4 my browser tells me: “The byte stream was erroneous according to the character encoding that was declared. The character encoding declaration may be incorrect.” <rekado>there should be a few “�” in the patch block <rekado>lechner: looks like string->escaped-html doesn’t handle the non-breaking space correctly, even though it has a case for it. <spiderbit>I need a either new package a plugin for rofi or a variant with the latest git... because both have a filebrowser variant that shows hidden files <spiderbit>I think creating a newer variant of rofi should be easier <rekado>lechner: correction: there is no case for nbsp <spiderbit>Do I have to upload it to a git server or can I use a local directiory? <rekado>spiderbit: you might be able to use a package transformation to get the latest rofi from git without having to define a package variant <ieure>podiki, I'm going to dig into the situation a bit more, presumably there's a way to run only the failing bits of the test suite. Once I figure out what those are, in the multi-megabyte output of everything. <spiderbit>$ guix build guix --with-source=guix@1.0=./guix <spiderbit>ulike that I guess? but is it then in a path or only as binary? <rekado>I don’t quite understand what you want to do with that “guix build guix” thing <Groumf>damn guix pull is super slow. Is there a better time to do it? <jonsger>1) Choosing different system generations in GRUB is nice <jonsger>2) Able to pull to the past and build a `guix system` is cool to reproduce stuff <spiderbit>In execvp of autoreconf: No such file or directory <jonsger>3) Our commit messages really help researching stuff like this: entering sddm as search term directly led to the broken commit :) <jonsger>4) I have a potential solution in my inbox 7 minutes after I reported the bug: kudoz to Feng Shu alias tumashu! <spiderbit>command "autoreconf" "-vif" failed with status 127 <rekado>that means there’s no autoconf input <spiderbit>rekado: do I have to install all build dependencies <rekado>the rofi package doesn’t need it, but when building from git it’s required. <rekado>spiderbit: no, installing things won’t change the build environment; that’s by design <rekado>the reason why you need autoconf when building from git is that rofi releases include generated files that make up the build system <rekado>the git repo just doesn’t include generated files whereas the release tarballs do <spiderbit>so is that still doable with transformation or do I need a variant then? <rekado>probably easier to define a variant in this case <rekado>(it’s on my wishlist to have a transformation that injects extra inputs) <spiderbit>and then make a transforamation from that folder?