<NodeGuy>Hi, I'm new to Guix and just got it running successfully in Docker! I'm trying to install my first package and am stuck.
<NodeGuy>When I do it via the CLI, it works: "guix package -i gtk+". But when I put it into my config.scm (http://lpaste.net/350325) I get the error "guix/profiles.scm:196:8: Throw to key `match-error' with args `("match" "no matching pattern" "gtk+")'."
<mange>Remove the quotes from around it. In scheme code it's a symbol, which isn't quoted. To get it working you'll also need to add gtk (unquoted) in the (use-package-modules ...) at the top of that file.
<Helius>I am trying to install an R package from inside R, the package is XML, I have install with guix (0.12.0) guix package -i guix pkg-config libxml2 r, R finds pkg-config and xmk2-config but later returns checking for xmlParseFile in -lxml2... no
<rekado_>Helius: users who care about reproducibility will opt for installing everything with Guix.
<rekado_>Helius: those who don’t just use whatever R version the system provides.
<rekado_>they can also use a shared profile in which the GCC toolchain from Guix is available, but it’s a little too much friction for these odd cases.
<rekado_>importing packages from CRAN to Guix is a mere matter of minutes.
<Helius>rekado_: For me is not just a matter or reproducibility but also a fatc of portability where I can use the same software on different installation, our cluster is not completely homegeneous. Btw I still have problems with certificates, is it possible to “import” a package with from a R/package .tar.gz file ?
<rekado_>Helius: currently, the importers for CRAN and bioconductor take a package name only and look up additional info on the web.
<rekado_>Helius: we could change them to also support URLs (including file:// URLs)
<Helius>the build process start and apply the shebang to the files of the package, but the install process enters a directory which contains an archive. The system unzip it and the configure script into the archive has not been shebanged
<Helius>short story, there is a gzip that is unpackaed after shebang and a configure is called without shebang
<nliadm>does it unpack it even if it's already been unpacked?
<Helius>for me, that my R package unpack an inner archive that needs to be shebang otherwise it will run the standard /bin/sh, I guess I need to unpack the archive shebang it and repack to make it follow its own destiny
<nliadm>I mean, you can add phases: (arguments `(#:phases (modify-phases ...
<ng0>I'm not really sure if I understand you correctly, if it's possible for you and your intention is inclusion in guix master, can you prepare a patch with git format-patch and send it to firstname.lastname@example.org for quick review?
<nliadm>ng0: I think he's just trying to package something that has a weird configure script that's unpacking another archive
<nliadm>I figured out how to do it by reading source because I can't work emacs for shit
***bhenc_ is now known as bhenc
<nextos>Im planning to migrate to guix on a workstation i have, and i need CUDA drivers to do some GPU computing. How do Guix users generally deal with proprietary drivers and non-free software (which I don't support!)?
<nextos>I've seen e.g. rekado has a repo for some non free bioinformatics stuff
<nliadm>I'm building something that requires curl, but libtool bombs out during compilation if cyrus-sasl isn't also an input. this is surprising
***GrimKriegor_ is now known as GrimKriegor
<ng0>nextos: it's undocumented and off topic for obvious reasons but if you search not very long with the right terms you can find how to get certain drivers to work and even the linux instead of linux-libre
<ng0>The store is immutable, if I do chmod u+s /some/files in a service activation, it won't be possible and I need to do this in the package definition, correct?
<ng0>including a typo where it's not client but clien
<rekado_>sneek: later tell Helius rhdf5 is a bit anomalous. I would patch the libhdf5ForBioC.a target in src/Makevars to not unpack the tarball and unpack it in an extra build phase (after “unpack”). It’s pretty unusual to have modified upstream sources bundled as tarballs. I’m surprised this passed bioconductor peer review.
<rekado_>jmd: is there a complication you didn’t mention? After the merge you can just “git push origin final”.
<jmd>If there are n changes in the other branch, I'll have to sign them all.
<taylan>is it possible to have a package build in an environment where TMPDIR isn't and doesn't begin with /tmp? Leptonica's issue where TMPDIR="/tmp/foo" causes failures has been fixed upstream but the patch can't be applied to 1.73 so I'm pondering how to just work around it for now during build. (the bug also affects users I think, but I wish not to spend time trying to adapt the patch to 1.73 so I
<taylan>hope not many people use a subdirectory of /tmp as TMPDIR...)
<taylan>absolute worst case I'll disable the test suite
<rekado_>jmd: if the n changes in the other branch are not your own you wouldn’t sign them (they should be signed already). You would only sign your merge commit.
<rekado_>another thing that was unexpectedly manual was generating the official announcement. We already have code snippets in release.org that could be tied together to generate a decent announcement without having to copy, adjust, and eval the snippets one by one.
<rekado_>the NEWS file is another thing that took time, but it wasn’t really *that* bad.
<rekado_>some more problems were my inexperience with gnulib and the fact that our build-aux directory doesn’t contain all the things that are needed to make a release.
<rekado_>I’d like to discuss these things at FOSDEM (which will also be close enough to the time of the next release)
<jmd>Sounds like the ./bootstrap script needs attention.
<baconicsynergy>greetings guix :) I just installed guixsd on my cr-48 chromebook as my main driver now :)))))
<rekado_>updating the website was a little painful too, but I think that’s because I didn’t expect CVS to behave the way it did.
<rekado_>(it didn’t add all the new manual pages, but updated those that had changed only)
<rekado_>I actually think it would have helped me a lot if release.org were a literate programme
<taylan>is there a reason the About page <http://www.gnu.org/software/guix/about/> states that GuixSD is a "GNU/Linux distribution" rather than a GNU distribution (that uses Linux-libre by default)? a certain anti-GNU zealot on Wikipedia seems to use it for justification to call GuixSD a "Linux distribution", since Wikipedia has a policy to call GNU/Linux distributions "Linux distribution".
<rekado_>it’s good that it’s not fully automated (because it made me double check my actions), but it would be great if I could read a section and then run its associated scripts to get that step mostly done.
<rekado_>taylan: I don’t know if changing this would help with Wikipedia zealots.
<taylan>it might help a certain zealot *cough cough* to counter-zealot them :P