<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?
<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.
<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.
<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.
<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>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>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.
<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.
<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>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>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.
<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.
<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>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.
<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
<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.
<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.
<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`)
<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
<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 ... :)
<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
<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 ?
<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]>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]>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]>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.
<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
<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?
<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"
<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.
<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.
<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 :-)
<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>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
<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>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
<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
<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>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)
<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.