IRC channel logs
2023-01-16.log
back to list of logs
<gcbehavior>Hi. I'm using the "guix gc" command to free up some space. But the problem is that when I use it, the next operation I do with Guix, even "guix package -r <some_package>", makes me re-install package. <gcbehavior>I only want to delete orphaned packages, not packages that are useful to Guix, but "guix gc" seems to delete all package that I don't used recently <mekeor[m]>hello. in emacs on guix system, when i run M-x magit, i get messages like "error invoking gcc driver". what's wrong? http://ix.io/4lo0 <gcbehavior>So do you know a command to only delete orphaned packages? Or an option to not force re-download packages when running "guix package -r" <oriansj>mekeor[m]: you may wish to install magit with guix package -i emacs-magit <mekeor[m]>oriansj: i did. but maybe i also had installed it via builtin package.el once. let me remove some directories in ~/.emacs.d <oriansj>I also am a magit user and I can share my setup (procedures and configuration) if it might be of help <oriansj>hmmm, yeah that looks like --debug-init might be useful for tracking down the problem <oriansj>mekeor[m]: I am guessing gcc-toolchain and/or gcc is not in your guix profile <mekeor[m]>oriansj: gcc-toolchain is in my profile. are both gcc-toolchain and gcc required for emacs to work? if so, why are they not propageted inputs? <mekeor[m]>oriansj: which output of gcc should i install? <mekeor[m]>oriansj: i get the same behaviour (same warnings, same backtrace), when i have gcc (default output) (and also still gcc-toolchain) in my profile <mekeor[m]>i guess it's because i use emacs --with-branch=emacs=emacs-29 <oriansj>possibly as the default emacs is currently emacs 28.2 <apteryx>sneek: later tell vagrantc hi! I managed to get #60224 in good shape, so long as #60802 is applied first. Thanks for the comments so far! <podiki[m]1>telmo: yes I'm aware of the toot š but I don't understand what you were saying or asking <apteryx>mbakke: thanks for your input re libtomcrypt; I found out the package was using a custom make-based build system, perhaps at cause <apteryx>updating it to the latest commit, where a CMake build system is offered, fixes the problem <apteryx>is it me or 'guix build -m manifest.scm' doesn't work? I get: guix build: warning: no arguments specified, nothing to do <apteryx>ah, probably my manifest returns an empty list or something <cel7t>Question: why is the librewolf web browser not packaged in Guix? <cel7t><cel7t> "Question: why is the librewolf..." <- If there is no conflict with the FSDG (I don't think there should be) and it's still unpackaged, I'd like to try packaging it <f1refly>What is guix using to automatically build its substitutes? <f1refly>I looked around in the wiki a bit but didn't find anything? <jpoiret>tbh icecat is nice but not that mainained while librewolf is, just because there are more people working on the latter <jpoiret>at the same time i'm not sure about the quality of the project itself <f1refly>yes, cuirass is what i was looking fo <cel7t>Yep and Librewolf comes with a bunch of privacy-focused settings switched on by default. It's probably one of the safest ways to browse the web right now if you're concerned about your privacy <f1refly>I consider defining builds at my workplace as guix packages and put the ci on a machine for testing purposes <f1refly>I think the cuirass configuration manual in the general guix manual should be good enough to set it up <unwox>hey! does anyone know if it is possible to convert "var" object from fold-module-public-variables* into location from (guix diagnostics)? i tried using source-properties + source-properties->location but source-properties always gives an empty list for every argument i pass to it <efraim>civodul: dropped another 39MB from my custom mesa by compiling with '-Os' instead of '-O3' <civodul>efraim: -Os should be a last resort though, because that can be pretty bad for performance i suppose <efraim>this is specifically for my custom gparted image, so I figure it wouldn't be a problem <sneek>Welcome back zimoun, you have 1 message! <sneek>zimoun, rekado says: Iāll try to add hierarchical edge bundling to the d3 graph output. Itās clearer than the chord diagramme. <zimoun>civodul: did you tweak something about the website in guix-artwork? <civodul>zimoun: nope; did you run "GUIX_WEB_SITE_LOCAL=yes haunt build"? <zimoun>it builds fine. It is about serving. <zimoun>anyway, I will give a look later. Probably a bug between my chair and my keyboard. :-) <Wurt>unwox: Did you use the first argument on the proc that you pass to `fold-module-public-variables*`? Maybe you could use `module-filename` to get the filename and append the path from the correct item on %load-path. I do not understand your question and I am a novice using guile so it is probable that I am speaking nonsense. Something like `(fold-module-public-variables* (lambda (mod sym var ret) (cons (list (module-filename mod) sym <Wurt>(variable-ref var)) ret)) '() (list-of-modules))` is a start. <Wurt>Is there any recomendation for testing a custom channel package before commiting to the git repository? I could not find a tutorial for that and loading from a file using the "-l" flag seems wrong. <unwox>Wurt: thank you for your help. i know how to extract filename from module, but i'd also like to know the line number where variable is declared <unwox>Wurt: you can add needed guix channel to your GUILE_LOAD_PATH <unwox>"guix shell -L . PACKAGE_NAME" in channel git directory <f3n1x>HaĆ³ guixers of the world...when '$ guix home reconfigure'... 'guix home: cannot determine provenance of current system' : Huh...What are we missing here ?Thanks,thanks, thanks <civodul>f3n1x: hi! it means that "guix home describe" is unable to tell you which commits your current home was built from <f3n1x>hi civodul ,oh... marvelous! I've just learnt that 'guix home...' operates aiming at such 'a system harmony' spirit may i say ? Uhu... should i worry about making those in sync with each other ? <f3n1x>If yes, "you should work on that, god sake! :D " how to... ? <f3n1x>bonjour - buenos dĆas mirai ! <f3n1x>yeha,..'guix home: error: build of `/gnu/store/06i91mws7lhs59vlbv19cpqaw4psjssy-calibre-5.36.0.drv' failed. Any hints ? thanks, thanks, thanks <f3n1x>ACTION it has to do with, as civodul just pointed ... guix home not knowing "which commits your current home was built from" ! Now what ? <f3n1x>Where do go from here ? Merci, merci, merci <mirai>how can I "error" out nicely in guix? I'd like to use it in a match-lambda as a better way of signalling malformed input rather than a cryptic backtrace <civodul>mirai: you can (raise (formatted-message ...)) <mirai>the system configure should fail here <mirai>but preferably with a nicer message <civodul>a good example here may be <network-address> <civodul>so in the end you might need to use define-record-type* to get sanitizers :-) <civodul>(you can still expose a more concise interface though) <civodul>mirai: ok; a sanitizer would actually be a bit nicer because it would guarantee that one cannot build a <host> record with invalid fields <mirai>What does the (thunked) do and when does it matter? <civodul>"thunked" means the field value gets wrapped in a thunk (zero-argument procedure) <civodul>like (host (ip xyz)) would expand to (make-host name (lambda () xyz)), if 'ip' is thunked <mirai>and while on the subject of records, is it possible for a serialize procedure to retrieve another field when using define-configuration? Say that to serialize field 'foo' I have to append it with the value of field 'bar' (I've got a service definition that's been gathering dust for a while now as it looks way too ugly to send as is) <civodul>that's a define-configuration question, right? <civodul>i think serializers there only get the value of the relevant field <mirai>hmm... so for interdependent field, we'd have to serialize the usual way first and then "reserialize" it? <f3n1x>hahĆ³. Can i move sections (say 'xfce4-desktop-environment ' for instance ?) from my system 'config.scm' to home-config seamlessly ? thanks,thanks,thanks <lilyp>GDM for example often can't read your home directory, therefore doesn't know about XFCE if you only install it there <lilyp>There might also be home-specific limitations, but the basic goal is that you can reuse bits <tremon>is there an easy way to get guix to give me a shell with the patched sources for $pkg? I know about guix shell -D, but it doesn't prepare the package source <tremon>to clarify, I want guix to run the unpack and patch-* phases of a build, then drop me to a shell <civodul>tremon: nope, that's not possible currently <civodul>but you can do: tar xf $(guix build -S PKG) <civodul>cbaines: hey, thumbs up on the qa-frontpage service! <lilyp>In commit 8d813a7eba5c47f29e5f5571483db96b7acde286, why was h264 disabled for webrtc? <mirai>is it possible to use nntp instead of subscribing to the guix mailing list? <jpoiret>mirai: there's public-inbox with a mirror at yhetil.org <lechner>now this should show more info even with the trailing comma 8d813a7eba5c47f29e5f5571483db96b7acde286, <mirai>jpoiret: thanks, this looks interesting <CoinCoinME[m]>how to use the podman? it just keep say hybird cgroups can't use it, how to enable only cgroupv2? <mirai>a pity Thunderbird (?) seems to choke on the accented characters <mirai>I'm getting mojibake on ludo's last name but the http browser page shows it fine <lechner>sneek / later ask rekado / Hi, are search results in Mumi sorted in any particular way? <lechner>Hi, if any committers are reading this, Greetd released a new version after accepting a patch I need locally. My configurations would shrink a little if someone were to commit the patch in #60798. Thanks! <civodul>cbaines: i see, i'll keep monitoring it :-) <civodul>for a little while it showed "Comparison unavailable", but maybe that's because the Data Service didn't respond in a timely fashion or something? <cbaines>civodul, yeah, perhaps. The information on the page when that happens needs improving <jonsger>what is the reason to have <...> around those links. When opening from Thunderbird the ">" at the end stays breaking the link... <lechner>sneek / later ask jonsger / Hi, are the angle brackets in the output from the bot causing problems for you, please? <mirai>it's used in markdown to mark links for instance <mirai>the angle brackets don't cause troubles in hexchat here <lilyp>lechner: separate cosmetic and non-cosmetic patches, use one patch per package <lechner>sneek / later tell jonsger / the angle brackets are now gone. thanks for your contribution! <lechner>Hi, what is the format of commit messages in Guix, please? I find them some of the strangest little things. They repeat a lot of clerical information but offer no original insights or reasoning, and incorporate no references to other material. Is there a guide how to write them? <vivien>If you use magit, you can press "C" with the cursor in the chunk to add a line to the message of the commit that is being created <podiki[m]1>you can also include more explanation in the text (after the summary line before the changelog) and/or reference an issue that the commit relates to <podiki[m]1>it is a bit weird at first but does make searching for particular things very easy <podiki[m]1>also, each commit is meant to do a single thing, so they should be short and towards a singular change as much as possible <podiki[m]1>there's also yassnippets and templ for emacs that will generate a lot for you <lechner>thanks for all those hints. i really meant the repeated references to variables, and the word 'gnu' in every commit, at least once. <lechner>aren't many of those things evident from the diff? <podiki[m]1>the leading gnu is to name the module/tree where the change is, if I understand your question <lechner>do we have any tools that use that information? <podiki[m]1>sure the diff has everything, but often you'll want to search by commit log <lechner>okay, thanks. how do i annotate non-functional changes as requested by lilyp above, please? <podiki[m]1>e.g. if I want to find changes to a package I can search the log for "gnu: <package>" rather than just the package name and find where it is context of an unrelated diff <podiki[m]1>i find that quick for example when searching on savannah's cgit interface <lilyp>Typically you'd do something like gnu: PACKAGE: Use new package style <podiki[m]1>is this comments on a particular patch? what's the number <lilyp>and then describe the changes in the commit <vivien>lechner, at some point I thought I would need to separate a module to extract a package in its own module to break cycle dependencies. It turned out to be useless, but preserving copyright information for a large module is impossible with just the git log, whereas you can easily grep for "package:" in the git log and know who contributed to that particular package <lilyp>if it's reindentation or some such, then you need to get a little more creative in the message <vivien>So you can keep only the relevant copyright (C) lines in what remains of the module, and move the relevant one to the new. <lilyp>For reindenting "Reindent" works, but that's not the only style change not done by guix style :) <lechner>i am not trying to be critical by the way but rather understand. i have written thousands of public commit messages, usually over twenty lines each and would like to improve my performance in Guix. not a single patch is accepted without comments, which slows down reviews <lechner>lilyp / following your advice i no longer use guix style. i now use tab in Emacs <mirai>lechner: what I do is search for past commits and "copy" <lilyp>ideally, we'd fix the bug in guix style tho <mirai>there's bound to be a commit that does something similar to your current patch <lechner>lilyp / last time i looked at it, that seemed a ways off <podiki[m]1>yes, I'm also not a fan of certain stylistic choices in guix style (width vs length in some cases) <lechner>mirai / you want me to search 106,000 commits to properly document a non-functional change (tongue-in-cheek) <podiki[m]1>but yes, most of the time for non-trivial changes I look at past commit messages and adapt <mirai>gitk, punch in keywords for your commit like you'd do with a search engine <lilyp>It's typically good if you describe your change in what it does. A reviewer can always find a catchy title afterwards. <lechner>lilyp / i thought it was now standard to replace old-style inputs. i am so surprised this raises any eyebrows <lechner>next time i just might not do it. is that the goal? <mirai>the idea is to have commits that can be built <lilyp>at least, that's the style I use, others have less trouble with the dirty way <lechner>i am happy to conform and also like clean, but the commits really end up being tiny <lechner>doesn't that also tax the build machinery? <lechner>anyway, i am done arguing. sorry about the noise <mirai>you could adapt "incrementally" if you're worried about making stylistic but non-functional patches <mirai>that is, when you update a package or fix it, also adapt to the new style <lechner>well, then reviewers respond saying i should switch to gexp at the same time <mirai>yes, might as well do it :)) <mirai>I tend to do this for packages I end up patching <mirai>it's also an excellent chance to really review the package build steps <mirai>some might be no longer necessary, etc. <lechner>lilyp / In #60798, is it acceptable to bundle the addition of the variable 'rust-nix-0.26' with the upgrade of greetd to 0.9.0 in one commit, please? <rekado>lechner: nowadays the results are sorted by relevance according to whatever Xapian considers relevant <sneek>rekado, lechner says: / Hi, are search results in Mumi sorted in any particular way? <rekado>there still are some problems since we removed the implicit āANDā between query terms, though <lechner>rekado / thanks! would be open to sorting by bug number or by the date of the most recent bug comment instead? <lechner>Or, is the idea of using Xapian to offer a full text search? <lechner>i use the interface primarily to see if anyone already submitted an update i hope to prepare. in that case, the search term is a single word <lechner>or am i supposed to type "update greetd", for example? <apteryx>rekado: what do you think of using wrap-script for pyproject-build-system instead of wrap-program, for its wrap phase? <apteryx>that'd mean having to replace bash with guile as an input to a few places... but perhaps that's OK <lilyp>lechner: don't worry about the CI, it tests series as a whole <lilyp>and no, shadow updates are not okay <lilyp>we're not in the German government trying to pass laws here <lechner>lilyp / thanks! what's a shadow update, please? <lechner>also, i wasn't worried about the CI test but rather the substitute builders <mirai>lechner: from context I'd say including unrelated changes in a new patch revision <mirai>you could also think of 'smuggling changes' in <lilyp>two patches, one series is okay; two changes one patch not so much :) <lilyp>CI and substitute builders are the same thing really <mirai>lilyp: any updates regarding socket activation with shepherd? (#54986) <lilyp>v3 is still the most current one on that end <lilyp>did you resolve your pulseaudio issues in #59866 yet? <mirai>I haven't reworked it yet though I have a locally patched revision that stripped that env variable away <mirai>but it's not improbable that we might see mpd-service needing to be spun off into a system and a home version <mirai>and I've yet to move the "activation part of the service" into its service constructor (or a one-shot) <mirai>rather not abuse activation-service-type for file/dir creation <lilyp>isn't that what activation-service-type is used for, though? <mirai>if you replace "used" with "abused" for that purpose, yes and it is full of sharp corners (#60657) <mirai>tldr; activation-service-type doesn't care about your system mounts or shepherd-requirements <mirai>this causes things to work after a system reconfigure and fail miserably at reboot <mirai>(it also makes shepherd-graph extremely misleading) <mirai>#57589 is one such papercut (and the remedy is #60756 which has some commentary) <mirai>lechner: bot isn't handling multiple issue numbers in the same message :) <lilyp>mirai: hmm, rather than an ad-hoc solution, a more generic pattern should probably be used if it affects that many services <nckx>lechner: Why would substitute builders care about the number of patches pushed at once? (Rhetorical; they don't.) Combining unrelated changes OTOH increases reviewer burden. That doesn't mean just the one person replying to your patch; it's everyone who reads the log. Seeing someone trying to sneak in an extra input along with switching to gexps and updating the version means all those people have to stop, think, and check you're not being sneaky. ;-) More <nckx>seriously: then it's not clear which changes belong together. If you practice good hygiene, it is. <mirai>shepherd one-shots or moving into the constructor is some of the ideas discussed briefly here <nckx>ACTION fully embraces mail-over-IRC. <mirai>though that's a far larger yak that I'm willing to shave for mpd <lilyp>fair enough, it's also not a thing I want to review right now <dryya>Hey there, I have a question about propagated inputs and guix gc. I ran guix gc for the first time earlier today, and my next reconfigure then had to redownload most of texlive (which surprised me). I took a look at the texlive package definition and it seems like, eg, texlive-texmf is an input but not a propagated input for it. Just to check my understanding, if it was propagated would it not have <dryya>been removed by guix gc, and are there other pros/cons to propagating package inputs? <lilyp>dryya: texlive is a native-input to guix itself (for documentation) <lilyp>since no reference to it is kept, it is removed by guix gc <lilyp>but then, the next guix action probably requires it, so it is downloaded once again <lilyp>this has little to do with propagation <lilyp>propagation only affects profiles ā or roughly, what ends up in your $PATH, etc. <lilyp>if a package propagates texlive, all of pdflatex etc. will be in your $PATH <nckx>A being a propagated-input to B simply means that installing B will also act exactly as if you had installed A alongside it. <lilyp>if it doesn't, but has it as a normal (native) input, you will still download it, but not have it in $PATH <nckx>Apart from that difference, it is identical to a regular input. <dryya>Ok I think that makes a bit more sense, thank you. My confusion was probably coming from thinking that not being propagated would mean nothing would refer to it, making it possible to be removed by guix gc. <reyman>hum, i'm alone with the fact that clang-toolchain-13.0.1 failed to compile with 1.4 of guix when i reconfigure home ? <dryya>But if I understand correctly, inputs won't be removed, only native-inputs, in most cases <nckx>If it's not propagated and it's up for removal, it means it's unused anyway, so yes, GC'ing it is just and good. (Ab)using propagation to signal 'hey I like this one keep it around a bit longer' would not be appropes. <evilsetg[m]>Is there a way to access documentation or source code of a function from the guile repl? Also finding from which module a binding comes from would be handy. I haven't found anything about this in the guile manual. <nckx>dryya: Inputs are only directly relevant to building, they are not meaningful to GC. <nckx>GC looks at references (embedded store file names). There is no such thing as an input after a build is over. Only references. Not all inputs become those. <nckx>A reference can (sometimes erroneously!) be kept to any 'type' of input. <dryya>Thank you for bearing with my misunderstandings! that does make more sense <nckx>I don't mean to sound bearing :-) It's not obvious at first. <dryya>so then maybe going back to the beginning - running guix graph -t references texlive shows me that a reference was kept to texlive-texmf. So why might it have happened that my machine ended up deleting then redownloading it on the next reconfigure after guix gc? <nckx>Lots of people think 'oh they must have chosen silly words for run-time/build-time and "dependencies" like other PMs have, I'll substitute that' then get hopelessly stuck. <nckx>dryya: Taking what you say at face value, it should not: if texlive refers to texmf and texlive is, er, live, texmf will NEVER be GC'd. So there's more to the story. I'm not familiar enough with TexLive to say what off-hand. For example, what exactly is the reference, and what exactly was GC'd? <reyman>i have this error "No such file or directory: "/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11"" <dryya>do you know where I might find a log of past GC operations? I'm not actually 100% sure. I do have the output of the last reconfigure to cross reference <dryya>not 100% sure what was GC'd, to be clear* <nckx>I'm afraid I'm not aware of such a thing existing and doubt that it does. <lilyp>dryya, nckx: guix gc collecting old (and active) texlives is very normal <apteryx>rekado: implemented the idea (use wrap-script) as #60868, which adds guile directly to the inputs of the pyproject build system <nckx>lechner: Every Real Project has an issue #1 that stays unresolved forever. <nckx>lilyp: We have a different definition of active then? <lechner>nckx / i just need rekado's help with irregex, i think <nckx>Unless you're saying there's a serious bug in Guix and I've dodged a bullet by never learning TeX :-) <lilyp>"active" as opposed to "live" meaning that it's the texlive currently packaged <lilyp>the texlive package isn't live, because no reference is kept <lilyp>but it's active in the sense that it'll be downloaded as soon as you need to build something <nckx>OK, that subtlety is (still) lost on me then. I'm referring (heh) to the 'current' as in 'live' as in 'installed' texlive, not some version string. <lechner>nckx / i think i respectfully disagree with your use of the word "unrelated" and recognize that, in Guix, nothing is related <dryya>hm, I might be misunderstanding here, but since I think I never specified - I do have texlive declared as a package in my home-environment, and that's why it explicitly got pulled in by the reconfigure <dryya>that's a bit of an important detail, apologies for not explicitly mentioning it <lilyp>to be fair, I could have used better terminology <nckx>lechner: You'll have to rephrase that for me to attempt to form words and not just very confused faces. Guix redefines many things but not 'related changes' IMO. <lechner>Updating a package definition includes a wide gamut of possible changes, which in Guix are considered separate <lilyp>dryya: your personal texlive and the texlive used for builds are probably not the same; guix uses a smaller one for builds <dryya>lilyp: that seems to explain it, thanks! the hash for the derivation that was built (and pulled in the large download) is difference from the hash referenced by my personal texlive <nckx>lechner: Updating foozilla to 2.0 and adding the newly required foolibz input is what the manual calls one logical change, i.e. two related changes: neither makes sense without the other. But combining this patch with 'let's switch to the new input style now that we're changing inputs anyway' *is* conflating two unrelated changes. <nckx>I say 'manual calls' but this is not Guix jargon, it's widely considered good practice. <nckx>'Smallest non-broken change' is another. Of course common sense applies: fix 23 docstring typos in one commit, not 23, but don't also add new docstrings in that same commit. <nckx>I'll stop flogging this horse, but I hope it's more clear what I meant. <nckx>There are also plenty of 'bad' examples in the log, and plenty by yours truly :-) <lilyp>I'mma build some webkit real quick, see y'all in a day soonest <apteryx>bah, my geiser-guile session in emacs always end up not being able to show the prompt <dryya>also, thank you all for the explanations! <apteryx>it's been ongoing for a little while <lechner>nckx / you make it sound so easy, yet it is not clear to me where this flexible boundary is drawn. let's talk about #60798, please. i promise your time will be well spent. the patch is tiny. the changes are minimal by all contribution standards and fall logically under "updating the package definition of greetd to 0.9.0" when also considering that new-style inputs are now the norm. is it okay to introduce the new variable <lechner>'rust-nix-0.26' in that commit, or are the new-style inputs the only deal breaker? <lechner>i'll point out that, due to the particulars of Rust packaging in Guix, the rust-memoffset changes was not needed until greetd was built, i.e rust-nix-0.26 built fine without it <evilsetg[m]>apteryx: Are you talking about the geiser repl buffer? Does it throw an error? <nckx>ACTION wishes you could trivially pinch-to-zoom-out on mobile browsers but nope, 3-lines-per-line word-wrapped patches. Ugh. <lechner>ACTION does not know how nckx does it <nckx>Yes you do, I do it by grumbling about it here to cope. <lechner>i can help you set up your laptop if needed <nckx>My baby's 50km from here, and powered off. <lechner>maybe you should be doing something else right now <lechner>it's possible to be addicted to a software project, you know <nckx>Sleeping, in fact, but here I am. <lechner>let's continue our conversation another time, please <nckx>Anyway, my short touchscreen answer is that 'updating inputs style' is not at all related to 'updating greetd to 0.9.0'. Both are totally independent. <lechner>i got that already. how about the guix-nix-0.26 variable, please? <civodul>comrades, i no longer see my laptop's mic under "Input Devices" in pavucontrol <nckx>I was getting to that, and you explictly said that you thought style changes being the norm justified their inclusion. So I answered. <lechner>i just doubled up for a moment, but i always give in at the end <nckx>lechner: Didn't you add the brackets due to someone else's feedback in the first place? <lechner>nckx / yeah it was unmatched-paren but that day the bot got trashed from all sides so i simply gave in. the angle brackets did not work for someone here earlier today. the final bracket became part of the hyperlink somehow, and did not resolve <podiki[m]1>civodul: when in doubt I kill pulseaudio and let it get restarted <patched[m]>Is it possible to have emacs packages installed from guix take effect without restarting emacs? <nckx>lechner: Rust packaging in Guix *does* have quirks that prevent several best practices across the board. But, would not updating r-m mean that *any* user of r-n would fail to build even if r-n itself 'built'? (Which I gather might be a meaningless term in current Guix+Rust land.) <lechner>jess / hi, and thanks for all the hard work on the network! <lechner>nckx / unfortunately, i do not know the answer to your question. <nckx>The new variable: I would have added it separately, because I don't think having an exported variable be 'unused' between commits qualifies as a broken state. <civodul>podiki[m]1: i suspect there's a Deeper Problem here <nckx>But I think I started all this specifically talking about mixing style changes with version bumps, for example, which IMO should never happen, not the finer points of style which IMO this variable question's about. <nckx>And I mean that in a good way. <civodul>cbaines: good to see the new commit policy in place! <cbaines>indeed, I should probably send a quick reply to the message I sent to guix-devel a while back... <nckx>lechner: <> is a *very* common convention, including in plain text mail as you discovered, and solves the real problem of https://tobias.gr/thruth.png. Oops, 404! If you simply remove them, you'll probably reintroduce that 'bug'. <nckx>I know I'm weird for using punctuation here but there are dozens of us. Dozens! Anyway, time to slep. <nckx>ACTION perches atop jess. <bumble[m]>I'm looking for information on "fontconfig-file-system-service" used in some guix system config files would anyone share any info about it? <FlaminWalrus>`guix pull` is giving me a bus error: I was out of internet for a while and am updating from guix ac09fcb <apteryx>bumble[m]: $ mount | grep fontconfig -> none on /var/cache/fontconfig type tmpfs (ro,relatime) <apteryx>it's to guard against corrupted or otherwise problematic cache files, I think <lechner>nckx / your link to 'thruth.png' was not surrounded by angle brackets <rekado>civodul: check the Configuration tab <rekado>when the selected configuration is output only (e.g. āAnalog Stereo Outputā) instead of duplex you may not see any input devices <rekado>apteryx: I was forced to reboot recently and since then I canāt seem to start Geiser <rekado>(but itās far from the only Emacs problem Iāve been having since then) <lechner>FlaminWalrus / Hi, a "bus error" relates to something on your motherboard and not the internet superhighway. Can you try that pull again, please? <mirai>nckx: I'm not sure if > is allowed in links (unless urlencoded) <mirai>but yeah, <> is very common, hexchat handles them fine for instance <mirai>lechner: what's this irregex business that's plaguing the bot? <lechner>i'll continue to monitor the mailing lists, but after some initial research i think we will serve hyperlinks without angle brackets <lechner>mirai / we modified the bot from extended POSIX regexes with which I was familiar to the cool Irregex library. it is extremely elegant, even though it is also a bit slower <lechner>it was then that the bot lost the ability to recognize more than one bug per message <mirai>lechner: you can try to get further matches when you use irregex-match-substring <apteryx>rekado: can't start geiser at all? that's a different problem; here it starts, can provide navigation capabilites to my Scheme buffers, yet its REPL doesn't return to the prompt upon evaluating something <apteryx>(though it completes, so it seems something fishy with how it matches the prompt) <rekado>no, it starts but thereās no prompt <bumble[m]><apteryx> "bumbleę·±ćå·ć: $ mount | grep..." <- thank you <rekado>no prompt after submitting something to evaluate, I mean <apteryx>rekado: does navigation (or checking docstring with C-d d on a symbol) still work though? <mirai>the first snippet resembles nested for-loops <apteryx>rekado: the most surprising thing in my case is I think it works for a short time after a reboot, and then it re-enters this pathologic situation <mirai>lechner: I'm not too sure myself, haven't used that library but I'd fire a REPL and see what happens <mirai>btw, did rsync break for everyone or is it just me <apteryx>mirai: it only "breaks" for me when I forget to add a trailing '/' to the source ;-) <mirai>it doesn't seem to do or print anything (--help or --version) <mirai>-1 ENOEXEC (Exec format error) <mirai>not on this target machine, no <mirai>and I did a guix install rsync just now <mirai>it also does exec format error <mirai>the system-wide install is... 0 byte <mirai>yeah, something's incredibly out of whack <mirai>ok... so the store went haywire 