IRC channel logs

2022-01-10.log

back to list of logs

<dissoc>im guessing the provisions need to be unique at least
<KarlJoad>When working on a channel, I feel like there should be a way to specify that the channel is stored locally. I know there exists a way to do it, but I am not finding it in the manual right now. Can someone point me in the right direction?
<nckx>KarlJoad: You mean by using a local URL?
<nckx>(file:)
<KarlJoad>nckx: Pretty much, yes. Use (file <path>) instead of (url <github>)? Is there somewhere in the manual I can see an example?
<nckx>No, (url "file:///home/you/stuff")
<nckx>Not (file "/home/you/stuff")
<nckx>This answer specifically for channels, not valid for (origin …) derivations ☺
<KarlJoad>Ahh... So (url <path>) actually accepts any kind of URL, including local... Interesting...
<nckx>Well, in theory, but only a very few are implemented. No ipfs://… magnet://… but file:// was rather cheap to implement.
<KarlJoad>I also noticed a few typos in the manual. I assume there is a set of guidelines for that.
<KarlJoad>nckx: Interesting. Good to know!
<nckx>KarlJoad: WDJM guidelines?
<KarlJoad>I am not quite sure. But I imagine minor typographical fixes should have some special process. I don't really know what I am saying yet. I am not yet experienced enough to contribute back to Guix.
<opunix>ok i figured out how to start the shepherd in userspace .. but i get a warning .. https://pastebin.com/7DT9Fx5c .. is that ok, can i just ignore it ...or is there something wrong with the configuration https://gitlab.com/guix-home/configs/-/blob/main/opunix.scm ?
<nckx>KarlJoad: Not really. One can submit a patch using the exact same process one'd use for code, or one could open a bug report, or… In this case, if it's all right with you, just tell me the typos & I'll fix them.
<KarlJoad> https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-hash.html#Invoking-guix-hash
<nckx>opunix: Looks harmless.
<KarlJoad>Under -S git, "has" -> "hash" and I think the git example should be updated to use the new serializer option, rather than the deprecated -r option
<nckx>Ah, ‘must the name’.
<nckx>Oh.
<nckx>More!
<nckx>Fun fact: -r and --serializer=nar return different results here. That's a fixed bug, but it's still scary.
<nckx>‘alias for type sets to nar’
<nckx>This is like hunting duck with a bazooka.
<nckx>KarlJoad: Done, thanks.
<KarlJoad>"Hunting duck with a bazooka" that's a good one. I like it.
<KarlJoad>No problem.
<KarlJoad>Is ci.guix.gnu.org down? I cannot seem to get those substitutes.
<nckx>Not here.
<KarlJoad>When running a ping I get destination host unreachable.
<KarlJoad>Then
<KarlJoad>Then again, I might be running into issues on my side.
<nckx>The host had network problems y'day. Maybe they are still latent.
<KarlJoad>Traceroute shows that the packets are being lost on the receiving end, not on my part of the hops.
<nckx>I have no idea what this means: https://paste.debian.net/plainh/ca052adf
<nckx>Is only allowing even pings a German thing?
<nckx>Uneven numbers are disorderly and must be disallowed.
<nckx>Otherwise, yes, I surmise berlin's still havin' troubles.
<KarlJoad>Ok. At least I am not the only one having issues right now. I will try a guix pull without using substitutes.
<The_tubular>Same, still down for me :(
<The_tubular>Been messing with direnv, been having fun though!
<nckx><without using substitutes> I sincerely unrecommend this. There's a server with about 75% of substitutes last I checked that you're losing that way. Use --substitute-urls=bordeaux.guix.gnu.org instead.
<nckx>Oh, also, there's https://berlin.tobias.gr — a dodgy and wholly unofficial nginx proxy some idiot set up for situations like this.
<nckx>Allegedly.
<nckx>It might work.
<nckx>Seems to. I forgot an =https:// in my bordeaux example above, though.
<nckx>So still an idiot.
<char>Does anyone know why the bluetooth in gnome settings does not work, but blueman works perfectly?
<KarlJoad>nckx: I did not think about changing the substitute priority. But I am working on mes-boot right now so...
<phf-1>And that's how we get GuixSD on a DigitalOcean VPS with a firewall made with nftables serving content with Nginx: http://159.89.22.216/ published through rsync from org-mode files. :)
<phf-1>using emacs of course
<phf-1>Rough but well, so far it works. Too bad packaging Python is such a pain.
<phf-1>Python app
<mekeor[m]>phf-1: nice :D btw, guixSD isn't called guixSD anymore. it's called "guix system"
<Kolev>I wish `emacs-guix` worked.
<Kolev>Guix System.
<sophrosyne>What doesn't work with emacs-guix?
<KarlJoad>Just out of curiosity, why are the two big substitute servers in Europe?
<nckx>Because that's where Guix was born & raised.
<mekeor[m]>e.g. civodul is from france, afaik
<KarlJoad>Fair enough.
<phf-1>mekeor[m]: ok, will change that now, thanks!
<nckx>Hence bordeaux, and Ricardo works next to the berlin servers.
<sophrosyne>I am looking at the source code for some guix packages and I am noticing that some of them use (assoc-ref %build-inputs "source"), so the source directory of a package is kept in its build-inputs?
<sophrosyne>I ask because I am trying to create a package for a font, and that directory is giving me an error when I try to use chdir on it in the builder.
<nckx>sophrosyne: The (source …) field is just another input, yes.
<nckx>It's only a directory if it was created as a directory, e.g., with git-fetch. It can just as well be a tarball. The default 'unpack phase is responsible for unpacking it if it is, and chdir'ing into it.
<sophrosyne>ahhhh that might actually explain why I am getting an error. I am using the trivial-build-system, but I fetched a tarball and didn't unpack it before I chdir into it.
<sophrosyne>How would I go about unpacking it if I am using the trivial-build-system?
<nckx>First of all, I don't recommend using trivial-build-system.
<nckx>(Second time I've said to today 😛)
<nckx>There's a font-build-system, why not use that?
<The_tubular>nckx to be fair, the proximity shouldn't be the biggest criteria on a repo's choice IMO
<nckx>Nobody said it was.
<sophrosyne>I tried to use it but it was giving me strange errors. And the font I am install is very simple, there isn't a make file or anything just .pcfs and .psfs
<sophrosyne>I am installing*
<The_tubular>Well that's the reason you gave, so it was a part of the criteria at some point :P
<nckx>The_tubular: That said, we do need remote hands, and we couldn't afford to pay for them. We still wouldn't be able to pay for the equivalent of berlin (hardware + hosting + hands) today.
<nckx>The_tubular: I don't see the connection.
<nckx>There were no ‘criteria’.
<nckx>Someone manages to convince their employer to give us a 2.4k core build farm, there are no other criteria 😉
<The_tubular>Damn, dumb question : I am a member of FSF, do guix take a part of that fee for hosting ?
<The_tubular>Ohh I see ^^
<nckx>The_tubular: Nope, although we do accept donations through the FSF and got a good chunk of cash through the Handshake cash dump, it's not taken from FSF membership fees, only explicit donations.
<nckx>The relative lack of a reliable income stream is one of the reasons we prefer not to spend 100s of $/€ monthly on less-volunteer hosting.
<The_tubular>"Handshake cash dump" ?
<The_tubular>Yeah, that's understandable
<nckx>I don't remember the details. This crypto thing gave the FSF a ridiculous amount of (real) money and Guix was earmarked for a weirdly huge amount.
<The_tubular>sophrosyne You have a guix.scm in your root directory and an .envrc in your directory as well that says "use guix", which makes direnv create a shell for you based on the environment variables needed in the package of your guix.scm file whenever you enter that directory for your project automatically. ; What's the location of guix.scm?
<The_tubular>Damn, that's good to hear nckx!
<nckx>You may not remember Handshake from: Handshake. You may remember Handshake from: the guy that took over Freenode last year and ran it into the ground.
<nckx>So, weird, and crypto things in general are weird to me, but all we ever got was no-strings-attached real monies, so all good.
<The_tubular>Ohh yeah, I remember that
<The_tubular>Did some project stayed on Freenode, or it turned to a ghosthouse ?
<nckx>A truly very, very tiny amount did. Almost literal handful. The ones that decided not to migrate to Libera (new name for Freenode, honestly) moved elsewhere far more than they stayed on Freenode.
<The_tubular>Where else did they moved ?
<nckx>I'm still connected to it through a bridge. It's not quite a ghost town, but it's *weird*, and unrecognisable. Imagine 4chan in IRC form, but without the base level of admin competence that the actual 4chan in IRC form, Rizon, has.
<nckx>The_tubular: OFTC, Rizon, some off IRC entirely into Matrix etc.
<natewrench123456>or discord
<The_tubular>From IRC to discord ...
<nckx>The non-free projects might.
<The_tubular>That's sad
<The_tubular>I was surprised to hear that FSF had a twitter
<nckx>If any free software projects (for which Freenode was run) moved their official channel to Discord, honestly, fuck 'em. That is sad.
<Kolev>The_tubular: The Discord thing is certainly a problem.
<nckx>The_tubular: It's the eternal ‘do we cede enemy territorry to the enemy, or remain as a voice to sing dissent’ dilemma.
<nckx>I can see a project who just used Freenode as free-beer-hosting move to Discord, because their beer is just as free, and they don't get the difference.
<nckx>But Freenode was never for them, really.
<natewrench123456>Freenode was for warez
<nckx>Nono that's usenet.
<The_tubular>Freenode was huge
<natewrench123456>Freenode was the beginning of IRC
<nckx>Not really true.
<Kolev>I thought it was EFNet.
<natewrench123456>well IRC was created in Finland around 1991
<nckx>And Freenode almost a decade later.
<nckx>There was a lot of IRC before Freenode.
<natewrench123456>I think BBCs
<natewrench123456>BBSs
<nckx>No, IRC. Really. Freenode was really not one of the first major networks at all.
<nckx>Freenode/OPN, whatever.
<nckx>Before there was OPN it was a single channel on EFnet. The name EFnet alone implies years of drama & history which I shall not rehash here 😉
<sophrosyne>nckx: These are the errors I get when I use the font-build-system https://pastebin.com/3A4ct1Pe, I am not sure why it would be giving me a hard time about locales or the store location. It could be the way I am installing it with guix package though since i just added it by modifying GUIX_PACKAGE_PATH.
<nckx>sophrosyne: Thanks, I take a look when I return.
<nckx>(By ‘not quite a ghost town’ I don't mean Freenode's lively. It is almost empty. It's just also very weird. Anyway, enough IRC nerdery from me. :)
<nckx>sophrosyne: Can you share the complete file? Easier to work with.
<nckx>sophrosyne: The problem is that font-build-system uses a hard-coded list of file extensions, and was written with only scalable fonts in mind (TTF, OTF, …): https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/font-build-system.scm#n48
<nckx>It's not even configurable. So yes, it's a good idea to use a different build system, but I recommend the gnu-build-system (and deleting the 'configure and 'build phases, and rewriting 'install) over the trivial-b-s.
<nckx>The trivial-b-s is not a more pure way of writing packages or a good way to get started. It's like buying a ship, sight unseen, that you have to go pick up yourself in the Philippines.
<nckx>It *can* be great if you know what you're doing but it's not for most people.
<kozo[m]>That just about describes the one time I tried to use TBS. Well said.
<sophrosyne>nckx: Ah yeah i figured I'd go with trivial given it wasn't configurable only needed to do a relatively small amount of changes but I think you may be right.
<nckx>Yeah, the name seems to be misleading, judging by the number of people who fall into that trap.
<nckx>And yes, the gnu-b-s provides a ‘bloated’ number of phases that will do absolutely nothing here, but they'll do so in less than a second, it's fine.
<nckx>kozo[m]: Thanks :)
<nckx>sophrosyne: Let me reconsider that: use the font-build-system, and override its 'install phase instead. That makes… a great deal more sense.
<sophrosyne>nckx: I'll try that now. Just not sure why it's even giving me an issue in the first place.
<nckx>sophrosyne: In the code snippet I linked above, you'll see the (rather primitive) default 'install phase: it looks for anything with a .ttf, .otf, etc. extension, and copies that to #$output. Your source tarball contains a bitmap font, which has different extensions (.psf IIRC?) that don't match any of the hard-coded ones. So 'install installs nothing. Then the build phase because there's no output.
<nckx>I'd (replace 'install …) with a version of the above code that uses the extensions .pcf & .psfu instead.
<nckx>I'm not sure what the correct target directory for those types is.
<sophrosyne>Yeah I see, makes sense to me.
<sophrosyne>I know them from the README that comes with it
<nckx>/usr/share/fonts/misc/ I think?
<nckx>Some distroes seem to put them in /usr/share/fonts/termsyn but I'm not 100% X/fontconfig/whatever will find them there.
<nckx>Sounds risky & non-standard but what do I know.
<nckx>Nix puts *.pcf into /share/fonts (I think …/misc is safer) and *.psfu into /share/kbd/consolefonts (which sounds good).
<sophrosyne>it said for .pcf to install to /share/fonts/local and for .psfu to install to /share/kbd/consolefonts
<sophrosyne>heh I actually wrote that package for termsyn for nix
<nckx>It's odd for a distro package to install in local. That's conventionally for user-installed packages.
<nckx>sophrosyne: Oh 😃
<Kolev>nckx: I thought local/ was for non-distro stuff.
<sophrosyne>hmm I see, it's strange because the README mentions to do that too for a systemwide install, which is probably why in the nix package it's only /share/fonts (someone must've corrected me)
<nckx>Kolev: We agree.
<nckx>sophrosyne: By ‘user install’ I mean the old-school ‘user/admin runs make && sudo make install instead of using the distro package manager’.
<nckx>I dunno. It's probably irrelevant in the grand scheme of the dying universe.
<nckx>We'll know at the end.
<nckx>There's at least one bug report of fonts not being found because they were installed to /usr/share/fonts/termsyn (Gentoo) so let's stick to something standard.
<sophrosyne>So just to be clear, should I do /share/fonts or /share/fonts/misc for the .pcf files?
<Kolev>nckx: But I have a distinction between 'base system' and 'whole distro', though.
<Kolev>I should have said 'base system', sorry.
<nckx>sophrosyne: The more I read the more confusing it becomes. X has different rules from Freetype, etc. Let's go with local and if that does break people will blame upstream and not me and that is good.
<nckx>I doubt it matters.
<sophrosyne>And if someone tries to blame me I'll just link to the log of you blaming upstream :)
<nckx>Well, I just found the person you referred to earlier: <https://github.com/NixOS/nixpkgs/pull/120128#discussion_r619635890>
<nckx>This applies to Guix as well.
<nckx>So both are good, you do whatever.
<sophrosyne>Hmmmmm, then I'll just redo what I did in the nixpkgs version.
<nckx>M-hm.
<KarlJoad>If I define a channel for my user in ~/.config/guix/channels.scm, I should be able to use (use-modules (channel packages specific)) in my guix deploy specification, right? Or do I need to do -C stuff for channels?
<podiki[m]>you can use it if you did guix pull with it, for example
<KarlJoad>That's what I thought
<KarlJoad>But ice-9 cannot resolve the interface for (channel packages specific) for me.
<podiki[m]>and you followed the path so that e.g. (channel packages specific) is yourchannel/channel/packages/specific.scm?
<KarlJoad>(synnax packages personal-website) = ~/synnax/packages/personal-website.scm
<KarlJoad>And the personal-website.scm has (define-module (packages personal-website))
***califax- is now known as califax
<sophrosyne>nckx: hmmm I am having issues replacing that install phase. I am getting build log errors telling me that the cut proc they use is an unbound variable. I tried using all their modules they used as well and it still throws me that error.
<nckx>cut is in (srfi srfi-26).
<nckx>Are you importing it into the build environment, not at the top of the file?
<sophrosyne>ah I did import it at the top, do I pass the #:modules keyword to argument for that?
<sophrosyne>it seems like they just used #:use-module though for (srfi srfi-26)
<podiki[m]>KarlJoad: the paths should be subdirectories of the top of the channel, so I'm assuming from your path the channel base is ~/ ?
<nckx>Yes sophrosyne . You should be able to write https://paste.debian.net/plainh/b682bcf7 but that's untested.
<podiki[m]>KarlJoad: i.e. to include your channel, you added it to channels.scm with a path to ~/
<KarlJoad>podiki[m]: The channel is named synnax, in ~/. So directory structure is ~/synnax/packages/personal-website.scm. I included it from GitHub in my channels.scm. I can build the site using `guix build` on the command-line.
<KarlJoad>The (use-modules (synnax packages personal-website)) is causing the issue.
<podiki[m]>what I mean is that (gnu packages something) looks in <git url>/gnu/packages/something.scm for the module where the file has (define-module (gnu packages something)); as an example
<podiki[m]>but beyond that all lining, up not sure what the issue is
<KarlJoad>Got it to work, but not how I wanted it to. Your explanation just lined up with what I did.
<podiki[m]>I don't know the specifics, but something about module naming and the path it is found is the rule
<podiki[m]>what did you change it to?
<KarlJoad>(use-modules (packages personal-website)) which refers to ~/synnax/packages/personal-website.scm
<KarlJoad>And synnax is defined in my channels.scm file, and is available after the guix pull (as shown by guix build working for it).
<podiki[m]>right, so that means you pull form ~/synnax not ~/
<podiki[m]>(i.e. the root of the git directories is ~/synnax not ~/)
<SeerLite[m]>What you probably want is to have it like ~/synnax/synnax/packages/personal-website.scm though
<SeerLite[m]>Or I mean that's how guix and some other channels do it
<KarlJoad>Yeah... I am thinking that might be the right thing to do. I want to make it clear that the personal-website package is coming from the synnax channel, so that might be the best way to do it.
<podiki[m]>any rofi users here? trying to figure out the best way for guix rofi to load plugins
<podiki[m]>by default it searches <prefix>/lib/rofi I think, since that is a store directory we can use env variable ROFI_PLUGIN_PATH
<podiki[m]>however I don't think there is a good way to set that globally that makes sense; maybe just note in package that this variable should be set to where plugins get installed, like ~/.guix-profile/lib/rofi
<podiki[m]>(I don't think we have any plugins packaged, but I have at least one)
<sophrosyne>nckx: So I've tried that approach you showed me for adding srfi-26 to the modules, but when I do that it for some reason starts complaining about each of the phases that the font-b-s is supposed to have already deleted.
<sophrosyne>nckx: And if I redelete all those phases then it gives me a weird output where it's complaining about me put a #t at the end of a let* even though the font-build-system.scm file does the same thing.
<sophrosyne>weird error* not output
<nckx>Hm. The #t is obsolete, drop it, but the rest sounds bad.
<nckx>Could you share the file?
<sophrosyne>sure give me one second
<sophrosyne> https://pastebin.com/Z2V42bkM
<sophrosyne>excuse the name and all the stuff left over from the hello package tutorial examples in the docs :P
<char>what is the way to get the hash of a git repository. guix hash -rx . does not seem to work anymore.
<Kolev>How do I use `guile-gi` or `g-golf` examples on Guix?
<sophrosyne>char: I believe guix download can be used for that?
<sophrosyne>that's the way I usually get the hashes for the source field of a package.
<char>sophrosyne, sure, but if I already have the respository cloned, I should not need to download it again.
<nckx>sophrosyne: Thanks.
<nckx>char: guix hash -rx . still works. It is an alias for ‘guix hash -x --serializer=nar .’
<nckx>guix download cannot, unfortunately, clone git repositories yet.
<nckx>char: Note that the git repository must be pristine. No files that would be present, absent, or different in a clean checkout.
<char>nckx, hthat is what I thought, I was just double checking.
<nckx>If you get a different hash, *something* is different.
<char>just to confirm that is a hash that can go inside (sha256 (base32
<nckx>Yes.
<nckx>The default --hash=ALGORITHM is the ‘nix-base32’ dialect expected there.
<char>cool. Another thing while I'm here. How can i make sure that the packages I make can be updated with guix refresh?
<KarlJoad>char: That is actually something I was interested in asking too.
<nckx>sophrosyne: https://paste.debian.net/plainh/c25e8867 — (1) I'm not sure why %font-build-system-modules didn't work (really: resulted in %standard-phases being assigned the unmodified gnu-build-system value), but I have a suspicion, but it doesn't matter (2) I removed the obsolete #t (3) you were missing a ‘lambda’ to create an actual procedure, so you would have got an error like ‘cannot call #<unspecified>’. Take care!
<nckx>char: Is easier to answer that answer in the ‘why won't guix refresh update this package’ non-hypothetical form ☺ I can't immediately formulate an answer besides ‘look at each updater and see how it works’, sorry.
<nckx>But that's also because I'm falling asleep. Good night Guix.
<char>Have a good sleep nckx
<nckx>Thanks. Y'all too, when the night comes.
<sophrosyne>nckx: Thank you very much! I am going to take a look at it in a minute. Have a good night!
<apteryx>everytime I try to write 'samba' it comes out as 'sambda', thanks to guile
<char>I'm trying to use guix shell to test a package. It is telling me that the hash is wrong. I susspect that the re is some cachcing going on. How to I remove the cache?
<sophrosyne>does passing --pure put you in an environment that doesn't use the cache?
<char>I thought pure just made it so the host environment cannot interfere.
<sophrosyne>Hmm you're right actually. I am not sure where the cache is stored or how to delete it, I only know you can rebuild it with --rebuild-cache and such.
<char>I tried that too, to no avail
<apteryx>char: I don't follow; the hash of what? of the package under test?
<sophrosyne>How did you generate the original hash that it's saying is wrong?
<apteryx>if someone else gets tired about not being able to login in gitlab with icecat, consider visiting https://gitlab.com/gitlab-org/gitlab/-/issues/345328 and asking for status or even just adding a thumb up ;-)
<char>apteryx, yes
<char>sophrosyne, just lik n c k x said: guix hash -xS nar . with the correct commit checked out (have have tripple checked this)
<apteryx>did you follow nckx's suggestion? 'guix hash -rx .'
<apteryx>in a pristine (git clean -xfdd) git clone of the project?
<char>apteryx, yes the hashes are the same
<apteryx>if you did anything in it (checkout another branch, touched file, etc) it'll mismatch
<char>apteryx, thanks! I did not know about git clean. I though "nothing to commit, working tree clean" meant it was good.
<gnoo>how can i add user services on guix?
<gnoo>i think there should be a shepherd daemon that starts for a user automatically and then a config for that so it then starts all other services?
<dumbdemic[m]>gnoo: guix home?
<gnoo>dumbdemic[m]: no, guixSD i've not yet gone into guix home territory yet :)
<podiki[m]>there's user shepherd, like https://guix.gnu.org/blog/2020/gnu-shepherd-user-services/
<gnoo>podiki[m]: thanks! that looks great.
<gnoo>but, how do i start shepherd? with a shell script on ~/.bash_profile ?
<daviwil>Hey Guix! Having a weird issue building a C project in a `guix shell --pure` environment. I'm pulling in "gcc-toolchain@11" as part of my manifest but somehow I end up linking to libraries using glibc 2.31 even though gcc 11 uses glibc 2.33. Here's one of the errors I get when I try to launch the application after building:
<daviwil>./build/run-tests: /gnu/store/...-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/...-libtiff-4.3.0/lib/libtiff.so.5)
<daviwil>Using CMake to generate the Makefiles if that makes a difference. It could be that CMake is the problem, just trying to rule out something I'm doing wrong with Guix first
<xelxebar>daviwil: Are you sure the linker on PATH in the env is the one you want? One quick sanity check could be to try building in a --container env instead.
<daviwil>OK, I think CMake is resolving things strangely, it somehow picked up two different versions of the SDL2 library even though only the newer one is in this profile (using `guix shell --pure`)
<daviwil>Trying --container now
<dumbdemic[m]>Anyone know how I can fix this error during `guix system init $file /mnt`... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/79dfefb75d3baa0b36bda4dfceb046b4d231c3e3)
<dumbdemic[m]>s///, s/For some reason grub is looking in `i386-pc` folder for `modinfo.sh` when it exists in `x86_64-efi` folder instead and I haven't found any docs on how to correct the location./For some reason `grub-install` is looking in `i386-pc` folder for `modinfo.sh` when it exists in `x86_64-efi` folder instead and I haven't found any docs on how to correct the location./
<dumbdemic[m]>Also if anyone knows how to chroot into /mnt during a guixSD install that would be great. When I try I'm getting `Segmentation fault` 😄
<podiki[m]>gnoo: I don't have anything special, I think anyway you want to start programs (once) is fine
<podiki[m]>dumbdemic: sorry, not sure exactly but there some instructions people have mentioned on the devel or help mailing list
<The_tubular>Why are there packages in in guix repo's that are by default in emacs ?
<dumbdemic[m]><podiki[m]> "dumbdemic: sorry, not sure..." <- ok thanks gonna try to google-fu it
<dumbdemic[m]>s/ok thanks gonna try to google-fu it/ok thanks gonna to duck-it some more 😄/
<podiki[m]>dumbdemic: good luck! i'm sure in the busier hours someone can help you out with it
<tissevert>hello guix
<PurpleSym>The CI failed to build librsvg due to a bug: https://ci.guix.gnu.org/build/295907/details Can someone restart that build?
<daviwil>Turns out the problem I had was due to some stale CMake files...
<sneek>Yey! robin is back :D
<tissevert>sneek: botsnack
<sneek>:)
<civodul>Hello Guix!
<mothacehe>hey civodul!
<cbaines>morning o/
<asdf-uiop>Hello civodul !
<tissevert>hi everyone who popped in
<AwesomeAdam54321>hello
<asdf-uiop>Since yesterday, 'guix system reconfigure' has been freezing at the check phase of mutter-41.0. Is anyone else experiencing this?
***Reventlov1 is now known as Reventlov
<asdf-uiop>Probably not, I just checked https://www.mail-archive.com/search?l=guix-commits%40gnu.org&q=mutter and there haven't been any recent changes
<asdf-uiop>so I guess the problem lies somewhere else
<tissevert>is there anything particular required on a guix system to make NFS work ?
<civodul>tissevert: it depends if you're talking about mounting NFS, or exporting it
<tissevert>trying to mount a share with this command hangs forever: sudo mount -t nfs myserver.local:/mnt /mnt
<civodul>ah
<tissevert>client, sorry, client
<civodul>i'd say nothing's needed locally?
<tissevert>I've seen a service in the doc, but IIUC it's for a server
<tissevert>nothing ? Oo
<civodul>yes
<tissevert>hmmm : /
<cbaines>maybe try using an IP address, rather than .local
<tissevert>why is it not working
<tissevert>: S
<tissevert>ok thanks !
<cbaines>that will potentially help to separate DNS issues from NFS issues
<tissevert>yes, and apparently my DNS is fine (it's hosted on the same router and I was confident in that, but at least now we know for sure)
<tissevert>it's not failing, it's hanging, what could it be waiting for… ?
<tissevert>server does have port :2049 + a couple other around :32700 for RPC open to my host
<tissevert>so permissions I guess : S
<tissevert>but that UsedToWorkISwear® before trying with guix
<tissevert>where are the man pages for nfs ? they're not there when I enter a shell with man-db
<asdf-uiop>Where can I find the log of a current build process?
<tissevert>wow, I had never noticed the root device was mounted twice, both on / and on /gnu/store
<tissevert>is that even possible ?
<efraim>hello guix!
<mothacehe>hey efraim!
<efraim>I think I have a working gitea package.
<efraim>bad news is about 300 go packages
<civodul>efraim: quite an achievement!
<efraim>haven't touched the javascript side yet, but it would be nice to start the upstreaming process
<jpoiret>tissevert: it's entirely possible
<jpoiret>you can remount parts of a mount read-only for example (which is what's happening here)
<jpoiret>you can mount the same device multiple times, for example i mount a btrfs subvolume on /, and the full btrfs at /btrfs (so I can look also at /btrfs/guix_root/) to see my root :p
<tissevert>Oo
<tissevert>but mine is ext4
<tissevert>also, what is the point of mounting the a device over a subdir of itself
<tissevert>I can't even make sense of it
<tissevert>where are the data in the end ?
<jpoiret>well, it's just an alternative to LVM
<jpoiret>I can have multiple roots on a single filesystem, and mount whichever one I want
<tissevert>noatime
<tissevert>hmmm that's why, it allows to tell the kernel to handle a part of the filesystem differently regarding mount options ?
<jpoiret>For example I have /guix_root and /arch_root on the BTRFS filesystem,
<tissevert>ok
<tissevert>how can I know the "real" root of the FS ?
<tissevert>do you mean that if I mounted it from a live system or something I'd see /guix_root and /gnu_store at the root of it ?
<jpoiret>no, no, it's just my own BTRFS scheme, it's not Guix doing that
<jpoiret>your ext4 filesystem looks like your root most likely
<jpoiret>it's just that you can remount parts of it with different mount options
<jpoiret>bind mounts are another example
<jpoiret>ie I have my EFI partition (FAT32) mounted at /esp, and /esp/EFI/Guix bind-mounted at /boot
<tissevert>yeah I'm comfortable with bind mounts, but there it looks like a regular mount if I'm correct
<jpoiret>bind mounts look like regular mounts too
<tissevert>no, but I mean in lsblk, it shows the device itself, that's not the case with bind mount IIRC
<tissevert>wait what
<tissevert>ok it does
<tissevert>don't remember it doing that
<tissevert>is it just a bind mount ?
<tissevert>ok findmnt reassures me that the folder is mounted on itself
<tissevert>jpoiret: thanks for the clarification : )
<asdf-uiop>I aborted my system reconfiguration to start 'guix mutter build' and see whether it gives me any more information on why it freezes. I get this error: https://paste.debian.net/1226574/
<asdf-uiop>Shouldn't an error stop the process?
<opunix>does anybody know how to handle nginx with shepherd i could not find any hints in the documentation how to configure nginx as a shepherd service
<jpoiret>opunix: https://guix.gnu.org/en/manual/devel/en/html_node/Web-Services.html
<opunix>jpoiret, yes that is exactly were i searched ... as far i understood ... shepherd needs a shepherd-service definition and there is only a nginx service definition how do i need to mix them?
<jpoiret>you do not need a shepherd-service definition, it's already part of nginx-service-type
<rekado_>FYI: IT confirmed that there have been site-wide firewall problems since Saturday
<civodul>rekado_: oh, thanks for letting us know
<opunix>rekado_, thx!
<jpoiret>basically, services in Guix can denote two different things: 1) Abstract features you add to your OS definition 2) Shepherd services, ie processes that run in the background
<jpoiret>1) often includes 2)
<civodul>texlive-latex-oberdiek used to have a file called ix-utf8enc.dfu, but newer texlive-oberdiek doesn't have that file
<civodul>anyone has a clue?
<opunix>jpoiret, ok .. but i tried to put the nginx service into the shepherd configuration and get back: In procedure shepherd-service-provision: Wrong type argument: #<<service> type: #<service-type nginx
<jpoiret>you only need to add it to the (services ) field of the operating-system declaration
<opunix>jpoiret, ok .. i will give it a try ... :)
<rekado_>civodul: should be in inputenx
<civodul>rekado_: thanks, i'll see if i can define it
<tissevert>according to strace, it is the mount call itself that is blocking
<opunix>jpoiret, what is a activation target for nginx?
<jpoiret>what do you mean by activation target?
<jpoiret>if you're talking about classical init targets, we don't have those
<opunix>well i got an error .. no target of type activate for the service nginx
<jpoiret>oh. Can you paste your whole configuration at paste.debian.net (redacting what's needed)?
<opunix>jpoiret, http://paste.debian.net/1226577/
<jpoiret>ohhh, you're using guix home! should've said so from the beginning
<opunix>sorry. my fault ... ;-)
<jpoiret>nginx-service-type is not really compatible with guix home currently (although I'm no specialist, maybe someone will contradict me)
<jpoiret>maybe there's an equivalent one in guix home, or someone has a definition somewhere
<opunix>jpoiret, may i use apache?
<jpoiret>i don't think so
<jpoiret>roughly, all services in the manual that aren't under (guix home) aren't compatible with it (except some specific) cases
<opunix>ok, so in this case service != service
<jpoiret>imo for guix home to be successful, there should be a big factorization of existing service code, but we'd need additional abstractions and mechanisms
<opunix>jpoiret, so what would be needed to get them running .. as far i understand .. you can write a webserver let's say in GO and then let it run as long you can bind to the port all is fine
<jpoiret>you'd need to write a version of nginx-service-type which is compatible with (guix home). That shouldn't be too hard, it's just that it assumes a couple of things currently, off the top of my head:
<jpoiret>1) it can extend activation-service-type to create the runtime dirs, and in /run/nginx or similar. You'll need a user-owned runtime dir instead, and create it without activation-service-type (maybe there's an equivalent thing in guix home)
<jpoiret>2) it assumes it can run under a different user, nginx, which it creates. You'll have to get rid of that as well, but I don't think you'll need to replace it.
<jpoiret>I know these aren't very simple steps, but once you get acquainted with how Guix works internally, it's pretty easy to do whatever you want :) in any case, good luck
<jpoiret>you can also ask on the mailing lists if something of the sort already exist, and if not ask for help with it
<opunix>jpoiret, ok, thx! :-)
<civodul>i think nginx is not really meant to run as an unprivileged user
<opunix>civodul, well it runs as apache does with the rights of the user defined in the configuration, dropping privileges should be made for security reasons
<opunix>civodul, just the binding to every port <1024 needs more privileges
<jpoiret>civodul: because of port 80?
<jpoiret>iirc there's CAP_NET_BIND_SERVICE for that
<civodul>jpoiret: more generally, its defaults very much assume it's started as root
<civodul>i suppose most or all are overridable
<civodul>but you can tell it's not the intended use
<jpoiret>I've always found nginx to be a little, ehm, obtuse anyways. Always use it in containers tbh
<jpoiret>I think it's time for me to switch to Guix-managed servers though :)
<civodul>for sure :-)
<jpoiret>civodul: by the way, about the installer and (ice-9 popen), open-pipe and friends don't let you have stdout and stderr redirect to the same pipe
<jpoiret>but I ended up using it in the end by telling open-pipe* to not redirect anything, but with the default ports already redirected for that invocation
<jpoiret>i'll have a v2 with a few more additions too
<civodul>jpoiret: ah good
<civodul>and yes, you can redirect current-error-port the normal way to a file port before invoking open-pipe
<civodul>and open-pipe will honor that
<jpoiret>yes, but you have to duplicate-port first to avoid https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52835
<civodul>oh i hadn't seen that one
<tissevert>I've just built wine to use in guix shell, and I was wondering how to prevent guix gc from removing it one day; reading about guix gc --list-roots, I was surprised to find it already among the roots
<tissevert>do all the programs open with guix shell end up being preserved from garbage collection ?
<tissevert>(I didn't use build --root)
<civodul>tissevert: no, but once https://issues.guix.gnu.org/53034 is merged, "guix shell" will automatically register a GC root
<civodul>it'll remove it once it hasn't been used in a while
<civodul>(that's already the case when using -m or -f)
<tissevert>oh it's because I've just used it ?
<tissevert>and I could make it permanent by asking to build the package again with --root option ?
<tissevert>I've emptied my .cache recently, and I notice there are dead links in /var/guix/gcroots/auto pointing there
<civodul>yes, you could make the GC root permanent by running "guix build -r ~/path/to/wine-gc-root wine"
<civodul>yes, the dead links are expected and fine
<civodul>"guix gc" will take care of them next time you run it
<tissevert>great : )
<civodul>the goal IMO is to make it so users don't have to manually fiddle with GC roots
<tissevert>wait, the -r option needs a path ?
<civodul>yes
<civodul>with the patch above, "guix shell" will DTRT so that things you use frequently don't have to be redownloaded, rebuilt, etc.
<tissevert>sounds great !
<tissevert>ahhh, is that because --root expects a profile, while "wine" once "installed" is just some directory in my /gnu/store ?
<civodul>"--root" takes a file name; it'll create a symlink at that name
<civodul>and the symlink will point to wine in the store
<civodul>i hope that's clear
*tissevert can't figure out why she'd want a symlink
<civodul>those symlinks are used as "indirect GC roots", under the user's control
<tissevert>I just want to be able to guix shell wine again and for it to be fast
<civodul>but see, that's also why we'd rather automate GC root management :-)
<efraim>if I only need something to exist until reboot I'll add a root for it in /tmp
<tissevert>I see yes : )
<civodul>so yes, the patch above will help
<tissevert>efraim: that's enlightening and sounds like a very cool feature to be able to do meaningful like this
<tissevert>s/o m/o something m/
<civodul>rekado_: "guix import texlive datetime2" bails because it can't find a description, but there evidently is one somewhere: https://ctan.org/pkg/datetime2 (it's even marked up)
<civodul>could it be that there are several ways to convey package descriptions in texlive?
<efraim>what's the minimal version of guile we support in guix?
<efraim>guix/ui uses default-optimization-level, which wasn't added until 3.0.3
<civodul>efraim: per configure.ac, it's 3.0.0
<civodul>with some exceptions: there's a few files that are used when building bootstrap packages, using Guile 2.0
<civodul>(guix build utils), (guix build profiles), (guix build compile)
<efraim>I'm using 3.0.2 on powerpc-linux, it's unhappy with guix/ui.scm:230:13: error: default-optimization-level: unbound variable
<rekado_>civodul: the new importer doesn’t look at ctan
<rekado_>it only checks the tlpdb
<rekado_>that said, datetime2 exists in the tlpdb
<rekado_>I’m getting the same error for datetime2-french
<rekado_>I’ll investigate
<rekado_>(BTW: I’ve got a fix for a bug in the importer; doesn’t matter here, but it manifests itself in some packages)
<civodul>efraim: ah, so it might be that in fact we require something slightly newer than 3.0.2
<civodul>should adjust configure.ac accordingly
<civodul>rekado_: i've also noticed cases where it'd fail to pass #:trivial? #t, such as for "textcase"
<efraim>we should check who has 3.0 but not 3.0.3. powerpc-linux is a special case, my exact version according to debian is 3.0.2be32
<efraim>so I think that would be powerpc, hppa and mips?
<civodul>you mean on Debian?
<efraim>yeah
<efraim> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214 looks like the other arch is m68k, not mips
<rekado_>civodul: actually, this is exactly the thing I fixed locally
<rekado_>the problem is with subdirectories. SVN refuses to checkout path/to/this when it has already checked out path/to/this/inside.
<rekado_>so the fix is to remove subdirectories if a parent directory’s prefix already exists in the list of locations.
<rekado_>I’ll push the fix in a few minutes
<rekado_>will take a look at #:trivial? next
<rekado_>pushed the importer fix
<rekado_>re #:trivial?: when there are files listed as source files in the package (and not just ‘run’ or ‘doc’) then the importer considers the package to be non-trivial.
<rekado_>since the build system doesn’t make any attempt to generically build from .dtx or .ins files a human is expected to change the generated output to build from source.
<rekado_>that’s something I wanted to work on on the wip-texlive branch
<rekado_>(I’m still debugging font loading in lualatex, so this will take a little while longer)
<florhizome[m]>Does guix have some concept of the session dbus? It seems no?
<civodul>rekado_: thanks for the fix and explanations!
<civodul>BTW, i'm using wip-texlive right now
<civodul>though i keep adding packages i need
<civodul>florhizome[m]: hi! dbus on Guix is like dbus elsewhere, so there's the "system bus" and the "session bus"
<florhizome[m]>civodul: but guix doesn’t seem to have a concept of dealing with it?
<florhizome[m]>how is the session dbus started especially?
<rekado_>on this gnome system it’s the display manager that starts the dbus daemon, same as on other distros.
<florhizome[m]>But that’s not an automatic thing
<rekado_>what do you mean?
<florhizome[m]>I don’t know if gdm does it automatically
<florhizome[m]>but I guess it’s a thing that some gnome–session script does
<rekado_>I haven’t manually started dbus-daemon, if that’s what you mean
*rekado_ fixed the lualatex font problems
<florhizome[m]>so, how is the session dbus started if you don’t use gnome?
<florhizome[m]>i know that if I want to run wayfire or sway in a dbus session I need to start them with dbus–run–session.
<rekado_>are you using gdm to start sway?
<rekado_>the display manager starts it — but I don’t know if something else must tell it to do so.
<efraim>guix build foo; notify-send "finished building foo"
<zimoun>is something down? “guix pull” leads to «guix substitute: error: connect*: Connection timed out»
<zimoun>I am doubtful it would come from my network, since I am at Univ. and all the rest works fine. :-)
<rekado_>PurpleSym: there are quite a few failures at https://ci.guix.gnu.org/jobset/wip-python-pep517
<rekado_>do you know if they are caused by the pep517 changes, or if they are only accidental?
<PurpleSym>rekado_: Most are probably caused by my changes, yes. But as far as I see most issues are with test suites and it takes an awful lot of time to clean that up.
<PurpleSym>Also all python2-* packages are broken (kind of intentionally).
<florhizome[m]><rekado_> "are you using gdm to start sway?" <- No, until recently that wasn’t even possible. Using sddm.
<florhizome[m]>I think that’s not such a trivial thing that you can just implicitly assume
<apteryx>florhizome[m]: dbus is relied on by GNOME components, so it is started automatically. I think it is automatically started on demand if it isn't already running.
<apteryx>I don't use GNOME and haven't needed to start it manually, yet it is running (dbus-monitor attaches to it).
<apteryx>I have this process: "dbus-launch --autolaunch=c096feaf19ce3a0a450915775e7ec8e3 --binary-syntax --close-stderr" and also "/gnu/store/5s6iz5f777rh23q4kv8gvqrsyy61cbjh-dbus-1.12.20/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session" which were started by my user run shepherd process. Could have been requested by ibus-daemon, which is one of my user services.
<florhizome[m]>apteryx: what are you running?
<florhizome[m]>I think ibis is adifferent thing
<florhizome[m]>*ibus
<apteryx>I know, I'm saying it probably needs dbus hence caused it to be autostarted
<rekado_>florhizome[m]: I’m not following. What’s not trivial, so I shouldn’t assume it?
<apteryx>florhizome[m]: is there a specific problem you're trying to debug?
<rekado_>zimoun: five minutes ago I received an email from IT that says that the network interruptions are ongoing.
<florhizome[m]>Yes you can run dbus–launch to explicitly launch an application within? a session bus
<florhizome[m]>I’m not entirely sure what the difference is between dbus–launch and dbus–run–session — dbus–launch seems to be used for single applications, dbus–run–session for, well sessions
<zimoun>rekado_: thanks.
<florhizome[m]>apteryx:
<florhizome[m]>well it’s been an ongoing process.
<florhizome[m]>Generally I’m aware that it’s advised to start single wayland compositors like sway, or wayfire, which I’m using, with dbus–run–session and run another command after that so that gtk applications find some specific information they are looking for, otherwise causing lag.
<florhizome[m]>the last few days I’ve been figuring out how to run this app https://github.com/FedeDP/Clight which needs a connection to the session bus (it has a system bus interface counterpart). Predictably, it only works prepending dbus–launch in my regular session. so I was wondering again, if there was an explicit way to make sure a session is started with the dbus, and that’s why I asked here, bc I haven’t found it.
<gnoo>florhizome[m]: i actively want to avoid dbus and yet it automatically starts. there are 4 dbus processes (i've just logged in) and one of them is started with --session
<apteryx>florhizome[m]: I'm wondering why Clight wouldn't be able to cause it to autostart like the other processes
<florhizome[m]><apteryx> "florhizome: I'm wondering why..." <- I‘m wondering why other processes autostart dbus^^
<gnoo>ok so somehow root shepherd is making 3 different dbus processes and yet one other process (started by root shepherd) creates another dbus process
<gnoo>at-spi-bus-launcher. what even is this???
<gnoo>florhizome[m]: i'm betting that's because they use glib and glib atuostarts dbus as a "feature"
<florhizome[m]>apteryx what are you running? login/display manager; desktop environment or wm?
<florhizome[m]>I‘m not entirely sure what at–spi... does, something with accessibility. You will find it with most gnome based DEs.
<florhizome[m]>No, I don’t think glib autostarts dbus.
<apteryx>florhizome[m]: it's just ratpoison
<florhizome[m]>apteryx: how do you login?
<apteryx>slim
<florhizome[m]>hm ok.
<abrenon>hello
<florhizome[m]>you say you think that any package that installs a configuration file in the right directory (I guess somewhere in share/dbus–1/ )should autoconnect to dbus if invoked?
<florhizome[m]>have you tried running sway or another wayland compositor? Maybe that’s x specific.
<nckx>Morning, Guix.
<florhizome[m]>Morning nckx^^
<abrenon>hi nckx
<nckx>o/
<vldn3>moin
<abrenon>ohhh moin ! : ) I love this word
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix ⚠️ ci.guix.gnu.org data centre firewall troubles ⚠️ | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<abrenon>moin moin to you too vldn3
<nckx>Always reminds me of MoinMoin.
<ggoes>me too
<civodul>good ol'times!
<pinoaffe>nckx: MoinMoin as in the wiki engine? or is there something else called MoinMoin
<nckx>TBH I had to look it up because all I remember was ‘MoinMoin’.
<nckx>Had you asked me before I thought it was one of those vanished 2000-sites like digg & co. Wrong.
<florhizome[m]>the Development of Wikis is pretty sad
<nckx>Wait, digg still exists!? Shows, well, stuff.
<nckx>Seems to be a Buzzfeed clone now.
<florhizome[m]>seems to have stalled in terms of new ideas such as federation. ikiwiki was pretty much the most featureful and interesting thing I found when I was searching but it’s from ˋ11 and requires a bunch of very old perl modules
<florhizome[m]>> <@florhizom:matrix.org> you say you think that any package that installs a configuration file in the right directory (I guess somewhere in share/dbus–1/ )should autoconnect to dbus if invoked?
<florhizome[m]>> have you tried running sway or another wayland compositor? Maybe that’s x specific.
<florhizome[m]>this was for apteryx
<nckx>florhizome[m]: Do you know if the Guix package still works?
<florhizome[m]>I haven’t looked at it yet
<florhizome[m]>When I tried it I still used manjaro. I think by the end of that tenure it was deprecated there
<abrenon>civodul: thanks for the answer regarding translations and sorry for the noise : )
<florhizome[m]>but why not, it doesn’t seem to move much.
<apteryx>florhizome[m]: I haven't tried no
<florhizome[m]>nckx if I would pursue a type of career that includes IT I’d probably begin hacking together guile modules towards something similar in guile.
<florhizome[m]>hopefully able to integrate with activitypub and GNUnet to some degree.
<nckx>Neat.
<florhizome[m]>apteryx: This would be interesting.
<florhizome[m]>Or I try ratpoison/another xwm
<florhizome[m]>ikiwiki is cool in that you can use it as an ssg for simple usage or with a cgi. if you want even more „transformability“, having something like guix is pretty perfect to be able to deliver the needed components.
<vldn3>!uptime
<lisbeths>Is there any laptop on the planet that will allow me to be a saint in the church of emacs with greater than 2 gb of ram?
<phodina[m]>Hi,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a7771c7df94b069cc3bcbff9f1dd4d17383079e4)
<apteryx>are connection times a possible fallout of the firewall troubles at the data center?
<apteryx>timeouts*
<apteryx>such as "guix substitute: error: connect*: Connection timed out"
<nckx>Yes.
<nckx>How should I make this more clear.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix ⚠️ ci.guix.gnu.org is having network trouble ⚠️ | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<nckx>‘ci network bad not good’.
***ChanServ sets mode: -o nckx
<apteryx>hehe
<nckx>:)
<apteryx>I don't know :-)
<abrenon>^^
<nckx>I typed too much once & we lost half our topic, so now I keep things short.
<apteryx>that's usually a good thing
<abrenon>assuming I've successfully installed a beamerthemeTheThemeName.sty in a package in /gnu/store
<abrenon>how would I go about letting pandoc find it and use it to produce PDFs ?
<florhizome[m]>apteryx: I remember I have openbox installed since lxqt delivers that by default so I will reconfigure (for some changes in the clight package to work) and try on openbox.
<florhizome[m]>where do you get dbus monitor from? I know dbusctl
<florhizome[m]>*busctl
<civodul>abrenon: i think pandoc invokes "pdflatex" or similar; if you have texlive-base and a bunch of texlive packages in the same profile, "pdflatex" will find all the .sty that those packages provide
<abrenon>yes it invokes pdflatex by default although other backend can be called if memory serves
<abrenon>my question was more along the lines of "what makes a package a 'texlive' package" ?
<abrenon>I can't help but suspect some magic variables à la GUIX_PYTHONPATH at play again here
<abrenon>the examples I've found in guix' source all inherit the same "simple-texlive-package" package
<abrenon>that is different from all architectures I've found so far on guix so I'm a bit cautious and fear to make mistakes
<abrenon>are there "virtual" packages ?
<civodul>there's a texlive "profile hook" that recognizes packages that provide "texlive things" and merges them somehow (i'm no expert, but that's the high-level view :-))
<abrenon>ok, so is this "hook" the kind of thing that plays with guix/search-paths and friends to end-up as variables in the profile ?
<abrenon>you've shown a handy way to look at the current environment during the HPC Café, but I can't remember what it was sorry
<abrenon>was that just "env" ?
<abrenon>ok I think I want GUIX_TEXMF
<nckx>tr '\0' '\n' < /proc/$PID/environ ?
<abrenon>thanks !
<nckx>If you use the wonderful htop, you can just press ‘e’ on the process whose environment you wish to view.
<nckx>Or ‘s’ to strace it if you have strace installed. I recommend trying it out if you haven't.
<abrenon>🤩 that's wonderful
<nckx>…or maybe you just meant ‘env’, I dunno :)
<abrenon>thank you so much
<abrenon>I think it was a mere env, but I know the htop thing will prove useful in the long term
<apteryx>civodul: there's no longer unions needed for texlive, AFAIK. Now texlive trees are found via the GUIX_TEXMF search path.
<abrenon>that's so practical ! I'm always clueless when I try to fix my bash_profile and xsession, never being sure what my GUI apps see or don't see
<abrenon>I usually spawn strace shells upon need, but it'll probably make it to my permanent user profile if that allows to pull this stunt
<apteryx>civodul: correction, there's a union used to provide a updmap.cfg file, but that's not a profile hook (perhaps it should?)
<civodul>apteryx: ah see, i got lost somewhere on the road :-)
<apteryx>hehe, it's on of the changes brought by last core-updates merge
<apteryx>one*
<apteryx>is the 'guix package --profile' option equivalent to 'guix shell --root' ?
<civodul>yes
<apteryx>OK, thanks
*apteryx pushes a refresh of the version-1.4.0 branch
<abrenon>oh noo : ( simple-texlive-package is not exported
<abrenon>so I can't just create a guix.scm file somewhere using it : (
<apteryx>hmm, I should have rebased the branch on master before pushing it...
<nckx>abrenon: (@@ (gnu packages tex) simple-texlive-package) ? With the usual disclaimer of ‘ew, gross’.
<abrenon>Oo what is this ?
<nckx>A way to forcefully extract variables from modules against their will.
<nckx>And nature.
<abrenon>that looks so useful
<abrenon>gross, but useful
<nckx>Exactly.
<abrenon>thank you !
<civodul>abrenon: you can write (@@ (gnu packages tex) simple-texlive-package)
<opunix>is there a way when i run a service in guix-home and i do a reconfigure that the service is gonna be restarted? if the service config changed?
<civodul>i did that earlier today :-)
<civodul>ah yes, what nckx wrote
<abrenon>: )
<civodul>opunix: you have to run "herd restart theservice" to stop the old version and start the new one
<abrenon>don't worry, twice is better than none, + the delay between both your answers gave me time to figure out the "output" of this was no longer a module, but the particular value I was extracting, so it belonged to my (let …) statement, not to the (use-modules …) : )
<opunix>civodul, i tried to define a pid-file because i thought it needs that to be restarted but the problem with that is .. because it is a service running in foreground it does not restart it fails starting
<apteryx>civodul: re --profile vs --root: slightly different it seems; --root doesn't seem to overwrite a previously existing link: guix shell: error: symlink: File exists: "/home/maxim/.config/guix/profiles/x"
<opunix>is there a way to do something like service& so that it will be sent to the background .. or how does this work with shepherd?
<opunix>i am using the make-forkexec-constructor
<abrenon>I wonder if using the gross (@@ ) and then inheriting a simple-latex-package would be more or less advisable than to have a mere copy-build-system package and somehow figuring out how to cons its out to GUIX_TEXMF 🤔
<civodul>apteryx: interesting; as discussed with abrenon earlier today, the goal is to arrange so users do not have to fiddle with roots, especially when using "guix shell"
<civodul>see https://issues.guix.gnu.org/53034
<civodul>profile caching should just happen automatically
<apteryx>I see, that's neat!
<civodul>what to do when a postgres client gets "FATAL: remaining connection slots are reserved for non-replication superuser connections"?
<cbaines>civodul, you can increase the max_connections for PostgreSQL
<cbaines>assuming this is Cuirass related, I saw this change go past recently https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=1bd6f5c272aef1949090fcddb9f729920e6cd8e4
<civodul>cbaines: ah thanks!
<gnoo>i just created a user shepherd service and it was super easy
<gnoo>idk why the shepherd manual has to be so complex, even the example is not complete
<phodina[m]>What's the code to concatenate 2 files into one in Guile? Something like
<phodina[m]>`cat file1 file2 > file3`
<phodina[m]>I tried the invoke command, but issue is redirection as it's passed in quotes and cat thinks it's a file :-/
<cbaines>phodina[m], redirection is a shell feature. If you want to run a shell command including cat from Guile, then use the system procedure
<cbaines>You could also just use Guile to write to file3 the contents of file1 then file2
<phodina[m]><cbaines> "phodina, redirection is a..." <- Thanks, the system call works but native Guile implementation would be more suitable solution. Could you point please some example?
<cbaines>phodina[m], this isn't #guile, but here are the docs for File Ports https://www.gnu.org/software/guile/manual/html_node/File-Ports.html
<cbaines>there's also a dump-port procedure within guix that you might find it useful to look at https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/utils.scm#n997
<rekado_>FYI: IT is working with the switch vendor support to try to figure out what’s wrong with the network. Still no leads.
<the_tubular>Something is pulling : gnome-backgrounds-40.1  47.7MiB on my system, how do I know which packages has this as a dependency ?
<nckx>2352 packages do. Everything that has gsettings-desktop-schemas as input, for one.
<nckx>I'm not sure which guix command would answer that question directly, if there is one.
<nckx>Of those I know ‘guix graph’ comes closest but requires some work.
<the_tubular>Yeah, I know about guix graph
<the_tubular>I was trying to slim down my install as I plan to try it on a limited space device soon.
<nckx>Good luck.
<the_tubular>And I don't see why I'd need 50mb of random wallpapers on that machine :P
<the_tubular>Could I just inherit that package, and delete the files directly while the package is building then ?
<the_tubular>"building"
<nckx>I wonder why g-d-s has bleedin' gnome-backgrounds as an input.
<nckx>To “Provide the correct file name of the default GNOME background, 'adwaita-timed.xml'.”
<zimoun>nckx:: by chance, do you have the source of ImageMagick-6.9.10-68?
<nckx>Redonkulous.
<nckx>zimoun: I already checked all my machines, and Guix's :)
<nckx>Sorry.
<nckx>It's very hard to find on-line, isn't it. Somewhat unusual.
<mbakke>uh oh, python-cryptography now needs Rust, 'setuptools-rust', and about 100 crates
<zimoun>nckx, ah! That’s bad… Nothing on your machine or all Guix ones? It would mean ~2000 packages from 2020 are not rebuildable.
<nckx>I know :(
<nckx>I thought a negative result was implied by my lack of a reply to your mail, but alas: none found.
<nckx>Rather sucks.
<_73>is it common to use guix as your main package manager on a linux distro other than GNU Guix?
<zimoun>nckx: I though you were busy elsewhere. :-)
<nckx>Both can be true! 😛
<the_tubular>You guys checked on software heritage right ?
<nckx>zimoun: I did mean to reply, it's just… when do you give up and admit failure? I wasn't ready yet.
<nckx>the_tubular: That doesn't apply in this case (.tar.xz), unfortunately.
<the_tubular>Darn
<the_tubular>Also would my idea above work nckx ?
<nckx>.xz support is very close to landing so it will, one day, work.
<apteryx>mbakke: I think even if our cross-built rustc is not clean (statically built), it may work with some patchelf magic revived from the days we were using upstream binary rust seeds
<zimoun>nckx: .xz more or less already work. But I did not know if samplet has already processed all or not yet.
<nckx>the_tubular: Create an empty g-backgrounds package? It would ‘work’, it's a bit extreme. The *only* way it gets in, other than installing the ‘gnome’ package (duh), is through gsettingsd-desktop-schemas. It's cleaner to modify that instead.
<nckx>s/gsd/gs/
<nckx>zimoun: Oh, wonderful.
<the_tubular>I meant, use the same package, but just use (with-directory-excursion (for-each delete-file-recursively))
<the_tubular>And delete the files like this
<nckx>Which is a bit extreme and silly IMO.
<the_tubular>How is it extreme ?
<mbakke>apteryx: I'm more concerned about packaging all those crates, and combining cargo-build-system with python-build-system
<zimoun>Damned! I am waiting the next one who will explain me that url-fetch is better than git-fetch. And that extrinsic referencing is better than intrinsic one. :-)
<nckx>You're breaking the package instead of removing the only place it's an input.
<apteryx>mbakke: yeah :-/
<nckx>For no discernible reason than, apparently, spite.
<the_tubular>My reason is slimming an image
<nckx>I gave you the better solution above.
<nckx>If you insist on asking my opinion on the silly one, well… :)
<apteryx>I'm seeing this one for the first time: guix pull: error: Git error: unable to parse OID - too long
<apteryx>ah, that's my commit ID which got appended one extra character in the copy-paste process
<nckx>zimoun: Who has argued that in the past few years? I'd be surprised.
<apteryx>I think we've been using release tarballs preferably to git checkout in some cases, such as cutting the dependency graph of Autotools-based project
<mbakke>zimoun: would it make sense to keep 'guix hash -r' as a non-deprecated alias for 'guix hash -S nar' ?
<mbakke>also, 'guix hash' could use a --list-serializers or something along those lines :)
<zimoun>mbakke: yes, civodul should push it.
<nckx>apteryx: That's true. That's a very specific (and defensible) use not comparable to ‘url-fetch is better than git-fetch’, though.
<zimoun>mbakke: or if you are faster :-)
<mbakke>zimoun: oh, didn't realize it was already on the tracker, nice :)
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix ⚠️ CI status: https://logs.guix.gnu.org/guix/2022-01-10.log#184220 ⚠️ | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<zimoun>mbakke: no, it is not in the tracker. It is one line and civodul said they will do it.
<apteryx>nckx: true. The other arguments would be that it's lighter and often are signed with upstream's PGP key.
<nckx>PGP is a good point.
<zimoun>apteryx, yes but that info is not stored in the Guix package definition.
<apteryx>sure, but our tooling does it automatically for us (guix refresh --update)
<zimoun>I am doubtful that someone will check all the signatures from 2020 when using time-machine.
<nckx>apteryx: Not to over-analyse your point, but I wonder if significantly more upstreams sign releases than sign Git commits.
<nckx>And (I never use guix refresh, shame shame &c.): does it check Git commits too?
<zimoun>apteryx, I agree when we look forward. I disagree when we consider backward.
<apteryx>I don't think so. It's not even able to update the hash.
<nckx>Then I shall stick with my artisanal updates.
<apteryx>I think someone made a patch to allow it to do so though, we should review it
<apteryx>zimoun: I'm missing how going backward changes anything?
<zimoun>because we are checking PGP and related at packaging or reviewing time. When we add things.
<zimoun>AFAIK, no PGP-related is check by Guix itself.
<civodul>mbakke: i just made -r non-deprecated :-)
<civodul>i'll push shortly
<zimoun>apteryx: “guix time-machine --commit=1ac4004502 -- environment --ad-hoc coq -- coqc foo.v”, bah I am doubtful it makes sense to check all the PGP of this stack. And I bet that no one would ever do it.
<zimoun>I think the point is: if you want security, do not use code from 2 years ago. Therefore, we could ask why check PGP signatures in these cases.
<mbakke>civodul: that was fast, thanks! :)
<mbakke>zimoun: found it! the original tarball can be extracted from here http://vault.centos.org/7.9.2009/os/Source/SPackages/ImageMagick-6.9.10.68-3.el7.src.rpm
<apteryx>zimoun: why would you want to (re)check the GPG signatures of packages from past Guix revisions?
<apteryx>they were hopefully checked at the time the package was updated in Guix, and from there on your insurance that this is correct (in current or past revisions) is the hash, no?
<zimoun>apteryx: yes. I agree. You said url-fetch because GPG and I said GPG is because forward and not backward. You asked why I said that.
<zimoun>My point is url-fetch is fragile for going backward. Even when using Disarchive.
<zimoun>mbakke: thanks. I am giving a look. But I hope it is not the in-place replacement. :-)
<florhizome[m]>So my system updates now fail, too with the mutter 41 build hanging in check phase
<apteryx>zimoun: OK; I lack knowledge about Disarchve to understand why having a Guix hash wouldn't be a good enough warranty to retrieve the original matching tarball.
<apteryx>Disarchive*
<sneek>Welcome back notmaximed
<nckx>zimoun: BTW, do you know if this tarball was yanked because of a CVE? It's odd there are seemingly random releases still up on both sides of this one.
<notmaximed>sneek: botsnack
<sneek>:)
<notmaximed>FWIW I have responded to that bug report with a link to a tarball (hash checks out!)
*apteryx has pushed a rebased version-1.4.0 against master
<nckx>I think it's been found but thanks!
<zimoun>apteryx, on the paper, it is enough. asically, Disarchive does 2 things: 1. creates a map from sha256 to swh:id and 2. store metadata (GPG stuff for instance) to be able to rebuild the exact same content = data+metadata. The #1 is about lookup and #2 is because SWH stores only the “data” removing the “metadata“.
<zimoun>nckx: I do not know. I just tried to build ’hs-to-coq’ using on old version of Coq from 2 years ago.
<zimoun>initially, I thought that I missed something. That’s why I asked on guix-devel :-)
<zimoun>Maxime provided the link: guix download
<zimoun> https://git.centos.org/sources/ImageMagick/c7/ed27964d872abc81dc2388d333874766058a9b5d :-)
<notmaximed>WDYT of letting (guix build download) guess the package name + version, looking it up in CentOS / Debian / ... source code archives and downloading it, as a fallback?
<notmaximed>Seems weird to use other distros' archives in Guix though.
<zimoun>notmaximed: yes, it appears to me a good idea.
<nckx>notmaximed: How did you find that?
<notmaximed> zimoun,apteryx: New version of 'check-tests-true' patch for Emacs packages, + related fixes: https://issues.guix.gnu.org/50299#65
<nckx>notmaximed: Nah, it's an excellent idea, not weird at all.
<notmaximed>nckx: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00167.html
<lfam>For the 5.16 version of the kernel, what do we think about <https://cateee.net/lkddb/web-lkddb/ZERO_CALL_USED_REGS.html>?
<nckx>There are a few steps in there that sound like ‘you just have to know or randomly try this’ but fair enough.
<lfam>I've been using this feature for a couple weeks and I haven't been tearing my hair out over the perf loss
<nckx>lfam: I think it's great, and have enabled it on my kernels.
<lfam>Glad to hear that
<nckx>lfam: If you claim to notice a <1% performance loss you are legally required to run Gentoo.
<lfam>Tbh I don't really notice much
<lfam>I have 500 tabs open in firefox
<nckx>A kernel-heavy workflow for sure.
<nckx>(I should hold my tongue, a move to put browser tab isolation into the kernel is probably being pondered somewhere as we speak.)
<lfam>Does anyone else have any thoughts about that config flag?
<nckx>I should add I only run x86_64.
*nckx AFK.
<lfam>The description says "At the end of functions, always zero any caller-used register contents. This helps ensure that temporary values are not leaked beyond the function boundary. This means that register contents are less likely to be available for side channels and information exposures."
<lfam>With associated performance penalties
<lfam>So, it's a marginal security improvement
<lfam>Also, I'm looking for opinions on the upcoming retirement of the 4.4 kernel series: <https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00020.html>
<lfam>It will be removed soon. Most likely in February
<batalie>i'm sure this probably gets asked a lot (and i know ci is currently down), but is there a way to only use substitutes and never build, for low-spec machines? i know about only using substituted package definitions, but i mean the builds
<notmaximed>lfam: FWIW, since I'm on Debian (foreign distro) now, I always used a variant of linux-libre or linux-libre-lts and never had to switch to old versions
<batalie>my x200 just tried to build chromium :)
<lfam>batalie: You could use this: <https://guix.gnu.org/manual/en/html_node/Channels-with-Substitutes.html>
<notmaximed>That's only for the package definitions of guix, not the packages theirselves
<batalie>right, that's what i thought
<notmaximed>See discussion at <https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00142.html> e.g.
<lfam>I see
<vagrantc>i would guess the only big loss to linux-libre 4.4.x would be compatibility with various android devices that are stuck on old kernels ... but i'd be surprised if they work well with linux-libre anyways
<lfam>I didn't realize that
<notmaximed>Also: https://issues.guix.gnu.org/26608
<lfam>What I didn't realize is the thing about channel-with-substitutes-available
<lfam>batalie: My advice is to use a Guix revision that is about 5 days old
<lfam>That will minimize the building
<notmaximed>vagrantc: Does anyone install Guix System on android devices?
<batalie>yeah, good call
<singpolyma>Any ideas why guix shell --pure then env would be radically different from guix shell -- env ?
<lfam>vagrantc: Yeah, it's true. I did some ersatz monitoring of substitute requests and I don't think anyone is doing that
<lfam>At least, if they are, they aren't using substitutes
<vagrantc>notmaximed: that's where my "i'd be surprised" comes in :) ... e.g. probably not
<lfam>singpolyma: Yeah, I have an idea. Basically, the latter doesn't include the --pure option :)
<lfam>singpolyma: The --pure option removes all existing environment variables before starting the new shell
<vagrantc>i've always been amazed how many concurrent kernel version guix generally keeps available
<singpolyma>lfam: sorry, that's a typo
<lfam>Oh
<singpolyma>in my case the former gets me the env vars I want, the latter is not working
<notmaximed>with some exceptions like DISPLAY, HOME, ...
<singpolyma>would guix shell -- command maybe not use the default guix.scm file ?
<lfam>vagrantc: Tbf, we don't test them all thoroughly. And so, it's really quite easy
<vagrantc>i think 4.4 was the last version i had working on the asus-c201, but ... it was so broken that i suspected hardware failures
<vagrantc>a.k.a. veyron-speedy
<lfam>What I learned from my metrics is that people use the current series and the LTS series, and maybe one or two people use anything else
<vagrantc>but that's armhf too, and it doesn't really have working sustitutes either ...
<lfam>Besides people who don't use substitutes or run their own substitute mirror, which would obscure demand from our server... ahem ;)
<zimoun>apteryx: to end my comment, it is fragile because using url-fetch, the archiving work is now splitted: index for SWH lookup, Disarchive-DB for metadata and SWH for data. Therefore, more “probability“ to go wrong (bug, etc.).
<lfam>I think that armhf will probably be removed from the distro this year, unless we can make our aarch64 machines build for it. But, I think that work should be done by people who want to use armhf. Otherwise it would waste a lot of compute capacity for what I predict would be no demand
<vagrantc>indeed
<singpolyma>so, to rephrase: should I expect guix shell -- build-my-shit to use the default guix.scm file and work? Because I seem to be getting an empty environment instead
*lfam studies the manual
<lfam>Let's find out
<notmaximed>What do you mean with "default guix.scm"
<notmaximed>The "guix.scm" from the current working directory?
<vagrantc>singpolyma: i think you have to tell it which directories it is allowed to import the guix.scm from
<lfam> https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html
<lfam>Yeah, see the note about "~/.config/guix/shell-authorized-directories"
<lfam>I'm not sure the details of this mechanism
<notmaximed>"guix shell" warns you (errors?) if it's not authorised
<singpolyma>vagrantc, notmaximed: yeah, it's authoized because just guix shell work fine. I only have a problem using the -- command version
<notmaximed>what is "build-my-shit" here?
<notmaximed>If it includes "$STUFF", it's unlikely to work
<notmaximed>Because $STUFF will be expanded by the shell before guix shell runs
<singpolyma>ghc -dynamic -package monads-tf -o cheogram Main.hs
<notmaximed>What's guix.scm here?
<singpolyma>if I run that in the interactive shell after running guix shell it works. but if I do it with -- then nope. And if I just use env then I don't see the needed vars when using -- env vs running env in the interactive shell
<singpolyma>notmaximed: guix.scm: https://paste.debian.net/1226669/
<apteryx>zimoun: that seems more of a shortcoming of the approached pursued by SHW than inherent to tarballs, though, from someone who knows nothing about SHW.
<apteryx>from the perspective of*
<notmaximed>singpolyma: I don't what's going on here.
<zimoun>apteryx, yes I agree. civodul raised many times to SWH folks this issue about tarballs and as they reported: «there’s a tension between making SWH a “canonical” representation of VCS repos and making it a faithful, bit-for-bit identical copy of the original, and there are different opinions in the team here»
<zimoun>Other said, we more or less dependent on the archivers. :-)
<singpolyma>Hopefully tarballs just stop being a thing soon :)
<lfam>Aside from the low level packages needed to build Git, of course ;)
<SeerLite[m]>singpolyma: guix shell will only source guix.scm and manifest.scm when invoked interactively, according to the manual. If you want to call it like that you'll have to manually use the arguments -f guix.scm
<singpolyma>SeerLite[m]: oof, ok. That's pretty unintuitive, but thanks for the find :)
<lfam>Bah
<lfam>With kernel 5.16:
<lfam>gnu/build/linux-modules.scm:257:5: kernel module not found "framebuffer_coreboot" "/gnu/store/fffl383am3si0f1brb5azyqcnrnp5rj3-linux-libre-5.16/lib/modules"
<lfam>I'll have to come back to this later
<nckx>lfam: Post your WIP.
<nckx>If you like.
<lfam>Check the Savannah branch "wip-linux-libre-5.16"
<nckx>lfam: Thanks.
<lfam>The usage of ZERO_CALL_USED_REGS is inconsistent, but otherwise I felt like it was ready for testing
***emacsen- is now known as emacsen
<the_tubular>Why is there a package for let's say "tramp" that already comes with emacs ?
<the_tubular>Is it just a more recent version ?
<robin>the_tubular, i think so, yes. 2.5.x on elpa vs. 2.4.x in emacs 27.2
<opunix>is there a way in guix-home to run a command like herd restart x? do i need to define a service for that, that is executed once?
<the_tubular>Thanks, robin
<the_tubular>The command exist, opunix but I don't remember it
<lfam>nckx: I rewrote that branch. The only change is that CONFIG_ZERO_CALL_USED_REGS is "y" on all platforms
<lfam>It shouldn't change x86_64 at all
<nckx>Thanks.
<nckx>Which build caused that error?
<Guest7381>Should the uuid of mapped-device be the uuid of the /dev/mapper/cryptfoo or the /dev/sda2?
<lfam>nckx: `./pre-inst-env guix system vm --no-grafts doc/os-config-bare-bones.texi`, with the bare-bones template amended to include (kernel linux-libre-5.16)
<nckx>👍
<lfam>I also add nss-certs to the template, to test that HTTPS / networking works, but that shouldn't affect this
<lfam>Guest7381: Are you trying to set up a mapped-device of type luks-device-mapping?
<Guest7381>Yes
<nckx>Guest7381: ‘cryptsetup luksUUID’ <- that one.
<lfam>I don't have experience with mapped devices, but the manual suggests finding the UUID of the /dev/sdX device
<lfam> https://guix.gnu.org/manual/devel/en/html_node/Mapped-Devices.html
<Guest7381>Thanks
<lfam>The part that reads "Alternatively, to become independent of device numbering, one may obtain the LUKS UUID (unique identifier) of the source device by a command like: [...]"
<sophrosyne>Hello guix, today I am having an issue using guix home to write a config file for fontconfig. It keeps giving me an error saying "Wrong type (expecting exact integer): #<&formatted-message format: "duplicate '~a' entry for files/\n" arguments: ("config/fontconfig/fonts.conf")>"
<sophrosyne>I have a feeling it may have to do with me downloading fontconfig in home, which creates a fonts.conf file symlinked already, then I am trying to overwrite it with a separate fonts.conf file.
<sophrosyne>I have no idea how I would go about overwriting the one generated by the fontconfig package in my home config.
<civodul>sophrosyne: i think it means there are two Home services providing fonts.conf
<lfam>nckx: Now I'll go build this latest 5.16 kernel on berlin so there's a substitute for it
<sophrosyne>civodul: Yeah I believe you're right. How would I go about prioritizing the one I want to add? Is there a simple way to overwrite a config file with another?
<lfam>nckx: I do see that the 5.16 config is missing the options you enabled in bc09e7ab5 "gnu: linux-libre: Support the Coreboot framebuffer." However, I don't think I did that on purpose. I wonder if my setup doesn't make them available for some reason
<lfam>I'm doing the configs within `guix environment linux-libre --ad-hoc gcc-toolchain`
<nckx>lfam: Right, that's why I volunteered to take a look at them.
<lfam>It gives me gcc-toolchain@11 instead of version 10 (the default)
<lfam>Yeah, just filling in some details
<nckx>*Newer* GCC shouldn't normally be an issue…? Guess we'll see.
<nckx>I'm deblobbing on berlin BTW.
<nckx>Might be your derivation, might not, but be prepared if yours mysteriously blocks.
<lfam>Sure, sounds good
<vagrantc>/29/29
***mark_ is now known as mjw
<sophrosyne>Hmmm so it seems like .config/fontconfig/fonts.conf is generated by guix home because of the font packages I declare in my home config, but I am still not sure how to go about overwriting that file in my home config without getting the duplicate entry error...
<sophrosyne>So I am looking at gnu/home/services/fontutils.scm and someone correct me if I am wrong, but it seems as though the home-fontconfig-service-type is using a hardcoded config file with add-fontconfig-config-file? I am not very familiar services but looking at other service types it seems like there is no way to change which config file is used.