<dongcarl>Question: What would happen if I'm on a machine with no subversion derivations built, then do `guix build --no-substitutes --sources=transitive <package-with-subversion-source>`? Would that fail?
<lispmacs[work]>okay, thanks. somebody must have been working on the build problem in these last few days
<mbakke>dongcarl: it would try to build subversion locally
<dongcarl>mbakke: Okay so it'll build subversion locally then use it to get the source of package-with-subversion-source?
<brown121407>Hi! Is there an easy way to respond to a thread from the mailing lists? When I click the "Reply via email to $NAME" it only fills in the address of the person who sent the mail, but not the thread address, which I'm more interested in.
<jlicht>the cuirass rss feed is a wonderful feature \o/
*mothacehe is fighting a Cuirass memory corruption with valgrind, fun.
<allana>Hi guix! question, is anyone having certificate authority issues when dealing with microsoft sites? I upgraded my guix system yesterday and now I can't access microsoft services due to certificate issues.
<allana>actually it seems like cert issues all over the net -- hmmm -- did anyhting change related ot how certs are handled in guix over the past week or so? I upgrade every week.
<leoprikler>assuming you have the nss-certs installed on your system like any upstanding citizen, things *should* be fine
<allana>leoprikler: thanks. I do have nss-certs and have been using this machine daily for years. I update at least once a week. Going to do some digging :-)
<leoprikler>allana: the latest release seems to be 3.62 while we're stuck on 3.59
<leoprikler>can you check whether using 3.62 fixes the issue for you?
<allana>I think that I have something else going on. Thanks for the help leoprikler .
<leoprikler>for the record, it has 581 dependencies, so chances are it's alredy fixed on staging and we just don't have it yet
<atom`>ngz: Yes but I would like to modify the "content" field of %default-nftables-ruleset rather than create a new configuration "from scratch" (I was planning to just mash some strings into the middle of it). Would this not be possible?
<pkill9>i like how you can create queries by making a directory using the name of the query
<ngz>atom`: Ah. I misunderstood your request. You could simply copy copy the contents of %default-nftables-ruleset in your plain-file declaration. There might be a smarter solution, tho.
<atom`>ngz: Which commands can be used to retrieve the contents of the contents field from the ruleset? I'm not experienced with Guile.
<ngz>You can look at the source, or from a terminal, call guix repl, then (use-modules (gnu services networking)) and finally %default-nftables-ruleset
<atom`>Ahh sorry if I was not clear. I would like to copy the text in the "content" field programatically (such that if it changes in the future, my code is still applicable), then modify that string by adding a few rules (text to the string), then create a new plain-file object with this updated string, which is used as the ruleset for the nftables-configuration. From a G-expr "object", how can I retrieve only the "content" field? Is there a
<atom`>"get" function of some sort that is applicable?
<rekado_>AFAIU I also need to build every module separately, so the first one I picked is the cli module.
<rekado_>and that’s where my problems begin: I set import-path to "github.com/oniony/TMSU/cli" and the go-build-system doesn’t find any code.
<rekado_>it says: can't load package: package github.com/oniony/TMSU/cli: no Go files in /tmp/guix-build-go-github-com-oniony-tmsu-cli-0.7.5.drv-0/src/github.com/oniony/TMSU/cli
<rekado_>and indeed: there’s some weird nesting going on; here’s one of the target files that the go-build-system has copied: /tmp/guix-build-go-github-com-oniony-tmsu-cli-0.7.5.drv-0/src/github.com/oniony/TMSU/cli/src/github.com/oniony/TMSU/common/path/path_test.go
<dftxbs3e>whew git history manipulations are so time-consuming/error-prone/stressful going back and forth rebasing ensuring everything is right before pushing.
<rekado_>I get a later error (progress!) with #:import-path "github.com/oniony/TMSU/cli" and #:unpack-path ".."
<apteryx>rekado_: the import path needs to match how the source code refer to the library internally, I think
<roptat>for those who didn't follow: camlboot is a bootstrap compiler for OCaml
<roptat>it contains an OCaml interpreter written in a small subset of OCaml, miniml, and a compiler for miniml written in Guile. The interpreter can interpret the compiler compiling itself. We even managed to check that the resulting compiler is bit-to-bit identical to what is obtained from the binary bootstrap included in the sources after another pass of compilation
<pkill9>rekado_: the tmsu package has tmsu in all caps, and also it has the src directory in the output path
<roptat>though it's a slightly modified OCaml 4.07.1 for now
<roptat>later versions require menhir (a parser generator written in OCaml), so they are not really good targets for the bootstrap. We can build the latest menhir with the bootstrap 4.07 though, so there's hope, but we might have to change the interpreter to be able to interpret the latest OCaml
<rekado_>pkill9: including the source directory is probably not good (is this what the go-build-system does?), but TMSU being all caps… I don’t know why that is.
<pkill9>in atleast some other go packags, i think the src directory has to be explicitly deleted maybe
<pkill9>yea i wonder why, maybe their makefile corrects it
<apteryx>roptat: seems OK: packages=$(./pre-inst-env guix package -A '^go-' | cut -f1); guix refresh -l $packages -> Building the following 80 packages would ensure 248 dependent packages are rebuilt [...]
<jlicht>sneek: later tell mothacehe: thanks for cleaning up my mess. `http-parser' did not show up in the RSS feed, so I was not at my laptop :/
<jlicht>rekado_: it's a caching daemon that takes away many pain points for a closely integrated development experience with nix-shell, based on direnv
<alextee[m]>well i found a workaround for the gdk pixbuf thing. i created the cache file elsewhere by passing `GDK_PIXBUF_MODULEDIR` so it finds the svg loader and then I use `GDK_PIXBUF_MODULE_FILE` to point my app to the file
<alextee[m]>seems like auto-detection is broken in recent guix commits
<dongcarl>I think `guix time-machine` works very much like `guix pull` :-)
<jlicht>dongcarl: I know that message when working with a git checkout, and then a "fetch all remotes" takes care of that ill
<dongcarl>Ah gotcha, perhaps I need to find where `guix` checks out my repo and do a manual fetch
<dongcarl>Aha! Found it... it's in ~/.cache/guix/checkouts... manually fetching the keyring branch fixes it!
<dongcarl>If anyone knows if this has been fixed in master already or not: please let me know :-)
<lfam>It's not clear what's wrong, so hard to see if it is fixed
<dongcarl>lfam: So I first did a `guix time-machine` to a commit on my repo, it failed because I'm missing some keys on my keyring branch, so I got those keys into my keyring branch and did a `guix time-machine` again, but it still fails.
<dongcarl>It seems like the problem was that the second `guix time-machine` assumed that there were no updates to the keyring branch, and thus did not try to fetch it again
<dftxbs3e>I think we can use bwrap (flatpak's unprivileged sandboxing utility) so emulate some of that desktop emulation of Flatpak on GNU Guix (I heard installed packages could have "runtime wrapper options" in the future, so this might allow it).
<dftxbs3e>sipa, if it is still alive it means it's used somewhere in a profile, so remove all profiles that use the package or something, but maybe GNU Guix itself uses libarchive indirectly too, so ..
<dftxbs3e>pkill9, ansible's a mess, GNU Guix declarative whole-system configuration is much much better, ansible is very very verbose and messy since it alters and checks machines that could be anything
<jackhill>jgart[m]: I don't think I'll be able to make it today, but I like the idea, and hope y'all will do it again in the future, and I'll be able to join then. I'm in the right time zone at least (North Carolina)
<jgart[m]>jackhill: We'd love to have you! We'll be hosting this meetup at least once a month. We often have impromptu meetups to work on stuff together. Just reach out at #libremiami:matrix.org or here. We have an xmpp bridge set up for the matrix room if you prefer xmpp. I'll be making asciinema recordings of the meetup sessions available in a git repo at gitlab.com/libremiami Stay tuned! I'll also post a livestream link of the tmate