<Guest53>To the Cuirass inclined, when I run `cuirass register --specifications guix-cuirass/examples/hello.scm` I get an error that goes `In procedure mkdir: Permission denied`. Have any of you seen that before?
<vivien>Hello, each time I add a domain to the list that gets certified by letsencrypt, it seems that certbot creates a whole new certificate and drops the old one. So, I get an email saying that the old list of domain names is going to expire, and then that it is going to expire soon, and then that it has expired. Is this normal?
<vivien>I mean, I imagine it has to change the certificate, but I’m not sure I should receive the emails.
<vivien>Also, there has been 2 commits (87178ed29ef519d8680062beacc3b9b178c10134 faltergeist, and f9ed753c7b3349e7c2160a4ae4bae9e5b11bd34e sdlpop), I don’t know how legal it is to include them. Did you check?
<lilyp>vivien: it seems that one certificate request is made for a large number of domains
<lilyp>I'm not sure how letsencrypt handles those internally
<JosefMoore666>i installed guix for the first time. The manual "Unless you’re on Guix System" could perhaps be highlighted
<alphapapa[m]>Hi, is there a way to limit the number of threads that the guix-daemon uses in the Guile process? The --cores option only seems to apply to the build process, not to the Guix Guile process, so e.g. if I use --cores=4 to limit the build to 4 jobs, the Guix Guile process may still use as many threads as my CPU has cores before it gets to the build process, which may saturate my system for a while.
<vivien>Hi, maybe that’s because guix uses guile futures, that use as many processors as possible. I don’t know how to limit them, and it’s possible that you are facing another problem.
<vivien>(To be clear, I don’t know if guix uses futures)
<vivien>So musicpd-shepherd-service should be a function that takes a <musicpd-configuration>, and use (musicpd-configuration-package config) instead of mpd to compute the executable file name
<vivien>(and return a list with 1 shepherd-service instead of a shepherd-service)
<ss2>well, so far I'm just avoiding to use any config file. Kind of. But I'm just trying to get it basically working.
<vivien>So, pass #f in your system configuration and ignore the configuration value in musicpd-shepherd-service
<ss2>Although it looks like that most service definitions have some sort of config file provided.
<vivien>Maybe it will work for a function with no arguments, I have never experimented
<ss2>hm, it helped to wrap (shepherd-service ..) inside a list.
<efraim>Has anyone used shepherd services inside guix home yet?
***stikonas_ is now known as stikonas
<attila_lendvai>why is it that guix environment -l guix.scm gets me an older clang-toolchain than guix environment --ad-hoc clang-toolchain? i mean, i kinda know why, but is there something i can do? do i need to explicitly pick firstname.lastname@example.org in the package?
<civodul>attila_lendvai: hi! it depends on what's in guix.scm :-)
<civodul>there are several clang-toolchain packages
<attila_lendvai>civodul, just a package with clang-toolchaing listed as an input
<attila_lendvai>IOW, clang-toolchain means something else on the input side, and on the --ad-hoc side
<civodul>attila_lendvai: on master, the 'clang-toolchain' *variable* corresponds to clang-toolchain@9
<civodul>but you can refer to the 'clang-toolchain-12' variable, for instance
<attila_lendvai>civodul, oh, so basically the difference is between the scheme variable, and that --ad-hoc picks the latest version, right?
<attila_lendvai>civodul, that leads me to a different question: what's the logic of which version to pick as the scheme variable?
<attila_lendvai>can i somehow decide about the entire source block of a (package ...) form? i have a function that makes a package object with a (package ...) form, and i want to decide about the source based on the function's arguments.
<nckx>vivien: <each time I add a domain to the list that gets certified by letsencrypt> Yep, that's how their system works. The list of domains is the identifier they use to send those mails, since nothing else about ‘renewed’ certificates is constant by default.
*attila_lendvai goes to learn more about match, because that is his curlpit
<attila_lendvai>it works now, but... these errors are not very useful: guix build: warning: source expression failed to match any pattern
<yoctocell>attila_lendvai: looking at (guix scripts environment), it tries to get the inputs of the package by calling `package->bag', which calls `make-bag' with the `build-system' and some other stuff. `make-bag' then tries to pattern match on `build-system', but fails because its #f.
<yoctocell>but yeah, the error messages aren't very useful
<attila_lendvai>my issue was using the wrong type here: (match foo (($ git-checkout))) instead of <git-checkout>
<attila_lendvai>yoctocell, thanks for the help! working in guix is still so much more pleasant than nix! i'm glad i jumped the sharks after a couple of months on nixos...
<yoctocell>attila_lendvai: You are welcome! Yeah, I also prefer Guix over Nix, hopefully I will switch from NixOS to Guix System soon
<civodul>attila_lendvai: the variable points at what looks like a good default internally at a given point in time
<civodul>whereas the CLI takes the latest version of the given package
<makx>yoctocell: raingloom idris2 supports at least racket as backend as well (which is a bit of a non-alternative now as racket uses chez as well); It is possible to use other schemes as long as they are r6rs
<nckx>Unless the -git-checkout directory happens to contain the full commit in its file name, there's no way to exctact it after the fact. .git is completely removed from the checkout that ends up in /gnu/store. If the -checkout file name does happen to contain the hash, just use explicit string manipulation to make it clear that you're being clever with something that's not (and won't be) API at all :) But I'm still not sure what you're trying to do so might be way
<nckx>attila_lendvai: Ah! Now I get you. There's no Guix helper for that but you code looks nice enough without one IMO.
<attila_lendvai>nckx, yeah, but it took me like half an hour. i need to work on my environment... still fooling around in guix repl, and lack completion in emacs
<nckx>Noisytoot: It allows passing the ‘config-file’ field from yggdrasil-configuration to Yggdrassil. It seems they otherwise support only one file. Judging by the default file name for config-file, "/etc/yggdrasil-private.conf", it might be that simply including its text verbating in the main (store) configuration file would be a big no-no. That's all just from reading the code, though; I don't use Yggdrassil.
<nckx>attila_lendvai: My condolences, but it seems out of scope for Guix to wrap what is all host-side ‘native’ guile-git code.
<apteryx>the install script currently says: [1630588052.448]: [ FAIL ] Could not obtain list of Guix releases.
<abrenon>roptat "good practices" question: should "tag" be entered to the glossary as terminology ? it certainly is so in the "Git" context (I checked it was already kept as "tag" in french in the existing manual) but can we assume that's the only context it would appear in or do you think it's too bold an assumption ?
<maddo>The question is: vapoursynth on its own is mostly useless, and it needs plugins to be compiled against it. While a possible solution would be to package each and every plugin for vapoursynth, is there a quick&dirty method to let compilers on a foreign distro find guix-installed vapoursynth?
<apteryx>by the way, the bordeaux key is not automatically authorized as part of guix-install.sh (when answering yes to the suggestion of enabling binary substitutes)
<nckx>I did. It didn't break anything here. I think it prints an extra line of output now (2021-09-29 17:10:21 URL:https://ftp.gnu.org/gnu/guix/  -> "-" ) but I didn't immediately find a way to disable that.
<abrenon>lilyp: thanks ! so I see, same as in french ^^ too bad the people it triggers can't see that their being triggered is the best proof some change is needed
<lilyp>roptat: for context, we do use "le terminer" in --max-silent-time=SECONDES
<lilyp>true, but there's also the valid counter argument that the generic masculine erases the gender of a male <something>, which the generic feminine also does
<lilyp>Plus, it's plain wrong to apply it in certain contexts, particularly when complaining about decisions made by predominantly white cishet men in high-ranking positions (whether it'd be politics or business).
<abrenon>what do you mean ? using the generic feminine in those cases is wrong ? doesn't it still demonstrate that plainly asserting "no but it's generic" so that's fine and proceeding to use an arbitrary gender is wrong ?
<lilyp>The problem is that you're drawing up an image in which evil women ruin everyone's daily life if you do so (which is exactly what reactionaries believe).
<lilyp>And if you don't, then you're the "female good, male bad" stereotype feminist.
<nckx>Hm, I should make $host local as well. Will do on my end.
<abrenon>do we generally translate "example dummy names" ? like, there's this code snippet in the documentation that demonstrates a package named "foo", which looks like a really good name for an english dummy name, but isn't as meaningful to a native french speaker, who would probably expect more something like "truc" or "machin"
<lilyp>According to Wikipedia, the metasyntactic variable of French choice is "toto" (don't ask me why)
<apteryx>nckx: crazy thought; our install script could be a minimal posix script that requires just wget/tar/gz; then it'd first download the guix-binary, which shoud include all the tools needed to do the configuration, and rexec itself (then running the Guile body)
<lilyp>our install script could be a minimal posix script that starts with hex0 :)
<nckx>One argument for the current one is auditability, although in the end you always end up with ‘exec guix’, either in code or by the user.
<abrenon>vivien: I'd say a and b, also, sometimes it can be a name reflecting the type, with, I'm ashamed to admit it, a digit suffix
<nckx>‘exec $(wget …)’ will trigger a lot of negative ‘curl | bash’ pattern recognition whether justified or not.
<nckx>apteryx: But technically your suggestion is absolutely, probably, better. 😉
<jackhill>nckx: re: the p11-kit and flatpak issue. I'm not sure if the probebly is easily fixed by having flatpak depend on a differnt p11-kit since flatpak talks to the p11-server process which may have been started by something else.
<abrenon>but it's interesting to notice that I actually write so little of it (because automatic `deriving` in Haskell, and the rest of the time point-free style), that I found no occurrence in my current code repos to support my claim
<abrenon>the only instance of Eq I found was in a dependency, and it used x1 and x2
<nckx>Hmm, you sure you're pinging the right nick, jackhill? Otherwise you'll have to kick my memory refresh chip; it's broken…
<apteryx>nckx: about your patch, I got: ./guix-install.sh: line 500: ~root/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub: No such file or directory (exit status 1)
<nckx>apteryx: I think at worst it's a kind of TOCTOU race we didn't have before (but we might have others): the user could download/‘obtain’ guix-install.sh, spend a week-end auditing it, then run it, and assuming they already have and trust Ludo's key, not have to trust TLS during installation. But that's quite a what-if situation.
<nckx>Also, this assumes the current script is in any way secure, which is dubious, because it is bash.
<awb99>I am trying to create my first package. I essentially download a .tar.gz from github, then run tar -xvf on it. And the binary file that comes out of it "bb" is the app that should be accessible.
<awb99>I am getting the error that "tar" is an unbound variable.
<nckx>Aside: that approach is not a good easy way to get started, if you thought so… Guix is not designed to run random binaries without modification.
<nckx>awb99: Anyway, tar is in (gnu packages base).
<nckx>You also have a spurious / after /v in the URL. Your Guix won't try to redownload the file because you already have it, but it will fail everywhere else.
<roptat>nckx, well, with the binary-build-system it would work
<nckx>If you try to run the resulting ./bb you get a confusing ‘No such file or directory’ because it hard-codes /lib64/ld-linux-x86-64.so.2 which doesn't exist on Guix. You can run patchelf on it to point it to that file's location in the store. See ghc-7 for an example.
<dstolfa>maximed: well, those are pull requests to be approved by the copyright owner. that's different from you making modifications and redistributing it
<nckx>Submitting a PR upstream is not redistributing a modified work.
<dstolfa>nckx: i guess that makes sense, it's just unfortunate
<viaken>Looks like specification->package+output lets you do per-package "lookups", while specifications->manifest covers the whole manifest?
<nckx>Although, doesn't GitHub strongly push a publicly-fork-then-submit PR model? I guess you're technically making a modified work publicly available, possibly unintentionally, but of course enforcement is at the discrection of the copyright holder in any case.
<maximed>dstolfa,nckx: These pull requests aren't only visible to the original copyright holder
<nckx>viaken: Greetings hashbang person. I've never used spec->man and don't know if it supports outputs.
<nckx>I know there's a ““reason”” for this but it's why I stay clear away from guix archive.
<singpolyma>yeah, guix archive -t not working on that archive, but import works
<nckx>singpolyma: So how are you listing the contents of the archive? And there's a ‘>’ redirection implied after guix archive, right?
<singpolyma>I'm not able to list the content. I can look through it in an editor to get a sense of what is there (don't see any of the contents of files for known dependencies for example) but the main outcome of interest is that guix install --no-grafts -n -L. jmp-register on the same scm after an import wants to download/build stuff
<nckx>Yeah, debugging (hell, even listing) is sorely lacking.
<singpolyma>also the archive file is hella small, usually my recursive archives are like 500MB
<nckx>So it's specific to this package/method of creating the archive? Because my experiments here all result in a archive that is exactly ‘guix size PACKAGE’ big, as expected.
<nckx>I use that module and by sheer (mis)fortune haven't had time to upgrade that one box in a while.
<ngz>Hello. I get undecipherable error messages ("undefined reference to symbol 'xmalloc'" and "error adding symbols: DSO missing from command line") when trying to build the package at <https://paste.debian.net/1213781/>. Does anyone know where the problem could come from?
<nckx>To begin with, binutils being an input is extremely suspicious. Do you have a version I could just build? Having to re-add all your module imports would be tedious.
<nckx>Why is binutils an input, and could you fix the (presumed) error you get without it any other way?
<nckx>o_O /gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/lib/libbfd.a(pei-x86_64.o): undefined reference to symbol 'xmalloc'
<nckx>Why the hell is a 2D space game statically linking to libbfd.
<dstolfa>nckx: well, you see, a 2D space game needs to understand obscure linker formats to relink itself for those platforms. it *must* be able to do this. it's absolutely critical. and it bundles it for ABI reasons.
<nckx>…because naev.c is littered with explicit bfd_ calls.
<nckx>dstolfa thought they were joking but joke's on them.
<nckx>mekeor[m]: You don't, and it's currently not supported anyway 😉 Guix expects GRUB to load all boot-related files directly from the encrypted ‘root’ partition. The drawback is that you have to enter you passphrase twice during boot. The advantage and reason it's currently the only option is that it's dead simple to implement.
<podiki[m]>I've got to run, but I'm sure you're in better hands here. otherwise following the installation manual instructions is not so bad if you need to partition manually