IRC channel logs


back to list of logs

<ulfvonbelow>if you pastebin your work in progress to e.g., I might be able to give more advice
<spiderbit>it complains that it don't know file-append now
<spiderbit>do I have to put that in front
<spiderbit>error: file-append: unbound variable
<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':
<spiderbit>error: file-append: unbound variable
<spiderbit>with that use-modules
<ulfvonbelow>oh, I see now
<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>(sorry to interrupt)
<snape>you can just use bash instead
<snape>the package
<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>but it works now
<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
<spiderbit>or symbol
<ulfvonbelow>that's why it can be slow if you're not already doing that elsewhere
<ulfvonbelow>#~ is like `, #$ is like ,
<ulfvonbelow>#$@ is like ,@
<ulfvonbelow>there are also #+ and #+@, which are like #$ except that they represent a "native" input, which matters when cross-compiling
<spiderbit>ahh ok yes
<spiderbit>, was it
<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>XHC0      S4    *disabled  pci:0000:03:00.3
<spiderbit>XHC1      S4    *disabled  pci:0000:03:00.4
<spiderbit>it did it :D
<spiderbit>without that resume is extremely buggy like 50% systemcrash
<spiderbit>I assume somehow bad usb-hub or something
<spiderbit>it's a deskmini
<spiderbit>ulfvonbelow: so yes thanks!
<ulfvonbelow>yer welcome
<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>it's like 0.3s
<snape>(on my computer)
<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>("XCOMPOSEFILE" . "$HOME/.XCompose-nonGTK")
<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)
<peanuts>"SRFI 209: Enums and Enum Sets"
<apteryx>any idea?
<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
<apteryx>works now
<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>or wait
<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>the ungrafted version, that is
<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> if anyone wants to take this thing for a spin. I've been using it often since I packaged it and fixed up a good number of things last week. Going to send in an updated patch series soon.
<peanuts>"atomized-guix/atomized/packages/librewolf.scm at main - ieure/atomized-guix -"
<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
<ulfvonbelow>btw the guix daemon flag is --gc-keep-outputs=yes
<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
<podiki>(just the hash i mean)
<ulfvonbelow>was the ungrafted version shown in --list-dead?
<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
<ieure>Okay, I see.
<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
<dcunit3d>when I try to download the source for a package using guix.el, i sometimes get this error:
<the_tubular7> seems down again
<klm`>I can't get guix package -p myprofile -i gcc-cross-avr-toolchain to work. it can't compile anything: Is everyone else seeing this? Installing it into a profile like that should suffice, no?
<peanuts>"debian Pastezone"
<klm`>peanuts: excuse me?
<peanuts>klm`: Hi, for comments please contact my maintainers at
<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 . How can we fix gcc-cross-avr-toolchain so that its search-paths includes those of its cross-gcc?
<peanuts>"debian Pastezone"
<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 :-(
<jpoiret>Guest12: probably not
<jpoiret>at least not the nvidia card
<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>you can join a team ;-)
<apteryx>or create one
<snape>apteryx, what do you mean/
<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?
<snape>or what kind of team?
<lechner>dthompson / Hi, is &nbsp; absent here for a reason? Thanks!
<dthompson>lechner: uh i dunno maybe? :) 2015 is a long time ago
<dthompson>I have some html handling code in haunt
<dthompson>not sure if I handle nonbreaking spaces there. why do they need special handling?
<lechner>dthompson / it's used in Mumi and NBSP is causing mojibake there
<peanuts>"[PATCH v2 0/4] Have udevadm look in /etc/udev/rules.d"
<peanuts>"mumi/mumi/web/sxml.scm at ba4750f0d12fedbbc9439c31715f95d0007dce8d - lechner/mumi -"
<dthompson>lechner: maybe worth checking out haunt's current implementation
<peanuts>"html.scm ? haunt - haunt - Static site generator for Guile"
<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
<dthompson>my solution was to always use utf-8 instead
<lechner>dthompson / well, it's a bit hard to see without prettified page sources, but i think Mumi already does that
<lechner>dthompson / maybe i'm looking at missing Unicode->UTF-8 conversion. M-x describe-char says octal \240, which looks like Unicode and not the UTF-8 byte sequence C2 A0
<peanuts>"Non-breaking space - Wikipedia"
<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
<apteryx>OK, that's great!
<snape>apteryx, do you know how mumi got the debbugs database?
<lechner>dthompson / you are saying that i should, in fact, go with the good old sxml->xml here, right?
<peanuts>"mumi/mumi/web/render.scm at ba4750f0d12fedbbc9439c31715f95d0007dce8d - lechner/mumi -"
<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?
<lechner>you mean "any"
<lechner>instead of "some"
<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
<dthompson>yeah sorry it wasn't clear
<dthompson>typing too fast today and making mistakes
<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
<snape>lechner ^
<lechner>snape / you can get the bug-specific mboxes from the web interface but rsync is more efficient for duplication between servers
<lechner>rekado / you mentioned locales in the Jabber channel but I'm not sure NBSP is locale specific. Isn't that just a missing conversion to UTF-8 byte sequences here (and also five lines above)?
<peanuts>"mumi/mumi/web/view/utils.scm at ba4750f0d12fedbbc9439c31715f95d0007dce8d - lechner/mumi -"
<lechner>i'm looking there because the mojibake occurs only in the colored diffs
<lechner>rekado / should this read "LC_ALL=en_US.UTF-8" instead (caps). Otherwise, what is deficient, please?
<peanuts>"guix/gnu/services/web.scm at bf7991a8c767abd32cfb2c92e3d57665a7cabf00 - lechner/guix -"
<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:
<peanuts>"View paste 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, glad it worked!
<snape>jmes: files that are args of `local-file` are resolved in a different context, and it's complicated
<snape>jmes: the logic is here:
<snape>it depends and whether it's a litteral string, etc
<peanuts>"gexp.scm\guix - guix.git - GNU Guix and GNU Guix System"
<jmes>snape: Good to know... I'll probably have to grok that eventually. Thanks again :)
<snape>(`local-file` is a macro)
<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?
<snape>it's just text right?
<jmes>snape: hah! I mean a colour for applications which use colour somehow. Like a window manager an application launcher :P
<snape>oh, ok!
<jmes>Normally these configs aren't easy to unify. But guix home gives us a nice opportunity to pre-process them.
<cbaines>I've restarted mumi on berlin
<apteryx>it seems to keep getting hung recently
<apteryx>I had restarted it twice last week
<alethkit>If I want to upgrade my drive, is there any specific preparation to do beforehand?
<apteryx>backup your data :-)
<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>Ohhh, good point
<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
<alethkit>oh, right
<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>apteryx: hey! what would it log?
<civodul>i tend to be wary (prolly too much) of logging statements infecting otherwise nicely functional code :-)
<jonsger>looks like is a good candidate for my broken system. It's like 8 commits after the last working system generation :P
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<civodul>hey jonsger! ssdm’s login screen doesn’t show up?
<civodul>is that reproducible in ‘guix system vm’?
<jonsger>ACTION tries that
<apteryx>civodul: I'm debugging cycles
<apteryx>so I'm placing a few debug level logs here and there
<jonsger>there is an upstream bug for the sddm issue, which looks a bit like mine:
<peanuts>"sddm-helper fails to take control of TTY ? Issue #1456 ? sddm/sddm ? GitHub"
<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
<apteryx>hindrance to what?
<civodul>readability and maintenance
<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>oh yes, that i agree
<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
<sham1>Like in the list
<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>s/guys/people/ :-)
<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)))
<Groumf>yup gotcha
<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 my browser tells me: “The byte stream was erroneous according to the character encoding that was declared. The character encoding declaration may be incorrect.”
<peanuts>"[PATCH v2 0/4] Have udevadm look in /etc/udev/rules.d"
<jonsger>works for me (in firefox)
<rekado>there should be a few “�” in the patch block
<jonsger>ah yep, I have them as well...
<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
<rekado>it’s all fine when it’s added
<spiderbit>Do I have to upload it to a git server or can I use a local directiory?
<spiderbit>-f, --install-from-file=FILE
<rekado>lechner: this patch should fix it:
<spiderbit>I guess that should be enough?
<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>$ git clone git://
<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?
<spiderbit>or installed in the user / bin
<spiderbit>ahh that's better I guess
<rekado>uhm, I don’t follow
<rekado>I don’t quite understand what you want to do with that “guix build guix” thing
<spiderbit>well I looked under package transformation
<rekado>but you wanted rofi, no?
<spiderbit>yes that is the example
<spiderbit>I did not change it yet for my package :D
<Groumf>damn guix pull is super slow. Is there a better time to do it?
<spiderbit>guix build rofi --with-git-url=rofi=
<spiderbit>rekado: that did fail
<jonsger>ACTION reported the sddm issue as It tells a few nice things about guix
<peanuts>"sddm does not start after update to 0.20.0"
<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
<spiderbit>but why does guix need it for git?
<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>it’s not *guix* that needs it
<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>or I generate it in a checkout
<spiderbit>and then make a transforamation from that folder?