<lfam>We don't go out of our way to rename things (change the API) but we explicitly do not maintain any sort of promise of naming stability for channels. Linux-style. If one wants stability for the stuff on a channel, it needs to be part of Guix
<nothingmuch>any preference re patching compiledb vs. just removing the python2 variant of shutilwhich? a small substitute* seems cleaner to me but most of the other patching i see is more strictly concerned with environment compatibility
<nothingmuch>the main reason i think substitute* is cleaner is since it's completely redundant with a whichcraft, which in turn is kind of needlessly depended on by cookiecutter and nothing else
<nothingmuch>will go with that for now, less code = better code. thank you for the feedback so far!
<nothingmuch>when is it appropriate to substitute* in a snippet vs. new phase after unpack?
<lfam>nothingmuch: Snippets are just for fixing freedom issues in upstream source code, so that `guix build --source` returns freely distributable source code
<lfam>We need to avoid the Guix tools offering nonfree code to users
<goldenshimmer>Hi! I'm trying to figure out the basics of writing a package definition. I started with the example from the manual, and have put my new module in a git repository, and added it as a channel. I'm now trying to debug it by editing it, then running "guix pull" (it has a syntax error).
<goldenshimmer>Can I skip the "Computing Guix derivation" step when pulling? It makes trial-and-error debugging quite slow. Is there a better way to debug? Can I get more verbosity in the .drv.bz2 file in /var/log (mainly looking for a line number)? Thanks!
<lfam>goldenshimmer: It's easier to build from Git and described in the manual section Contributing
<lfam>After you're sure your package is good, you can move it back to your channel (or, ideally, contribute it to Guix)
<lfam>It will take a few minutes to build the development environment but subsequent work will be more efficient
<goldenshimmer>Got the Git environment all set up. Way past my time for bed to poke at it much, but running the package build using ./pre-inst-env in the git repository worked! Evidently the problem was with my channel configuration or something, rather than the module itself. This seems like it will be a much easier way to work, indeed. Thanks again!
<apteryx>bandali: No news from that issue I opened with Emacs. So I sent a message today in one of the related thread that we should just proceed with the workaround (and life) :-)
<guix-vits>jstierhof: Please, use paste.debian.net (pastebin is behind Cloudflare's captchas)
<guix-vits>Above paste is "I try to build software which requires libx11 and the Intrinsics.h from libxt, however, they are not found by default and I can only specify --x-includes for one directory. Does anyone know how to deal with that? Thanks!"
<Kimapr>did anyone tried installing guixsd on real hardware through qemu?
<dongcarl>So I've thought a bit about the mingw-with-pthread vs mingw-without-pthread thing... And I think that it is reasonable to expect the default toolchain to have C++ threading support if C++ is indeed supported... So maybe I'll switch the default
<dongcarl>Will probably make people's experiments cross-compiling to windows go much smoother as well
<dongcarl>Also, for those who cross-compile to windows: I'm going to test mingw-w64 7.0.0 locally then bump it in Guix. The _FORTIFY_SOURCE feature might be useful
<mfg>Hi guix o/ I was just trying to `guix pull' and got: Migrating profile generations to '...' -- guix pull: error: symlink: File exists: '...'. Why does guix try to migrate my profile generations?
<jsoo>mfg: I think it might but fish is not posix compliant so you there is a function called fenv that is defined in fish-foreign-environment that would allow the sourcing of the profile. I haven’t been able to test it because fenv doesn’t seem to install correctly
<efraim>can I feed user shepherd an s-expression for a start command?
<jvshahid>Hi everyone. I'm trying to use a binary on GuixSD that is linked against libgcc_s.so.1. gcc-toolchain doesn't seem to be linking this library in my guix profile, desptite the fact that the gcc package in /gnu/store has it. Is that intentional?
<cbaines>jvshahid, what does ldd say about the binary?
<cbaines>you might need to set the LD_LIBRARY_PATH for libgcc_s.so.1 to be found
<jvshahid>It finds a bunch of libraries but the following two "libgcc_s.so.1 => not found" and "libstdc++.so.6 => not found"