<lfam>I have a package definition for Prosody (the XMPP server) that builds fine but doesn't find any of the run-time dependencies. One part of the error output that seems relevant is "dynamic libraries not enabled; check your Lua installation". Has anyone had this issue while packaging Lua software?
<lfam>The other possibility is that I don't know how to properly import modules that are my private package tree. I have all the dependent packages in ~/pkgs and the module path is like "lfam packages package-name". I build with --load-path and everything seems to work.
<codemac>what is the cli for doing `guix environment --ad-hoc guix` but also add a package for guix environment where it only get's it's inputs?
<codemac>as in, `guix environment somepkg` + `guix environment --ad-hoc guix`
<wingo>why does dbus-updates have so many build failures that seem unrelated to dbus?
<wingo>did some package stop propagating inputs or something?
<efraim>it seemed like a good place to put some of the updates that would cause a bunch of rebuilds
<efraim>I'm trying to package stfl and in one of the headers it tries to include <ncurses/ncurses.h>. I've tried ncurses as a native input and as a propagated input, but it's still not happy. any ideas?
<efraim>since running that command this morning I haven't tried again yet to make a guix vm, but i'll have to do that once I plug into power again
<toothbrush0>Request for advice: if i have a whole bunch of commands to run as the test suite for a package, should i write a shell script and include it somehow, or just make a list of (system* ...) calls in Guix?
<davexunit>so your kernel, despite having the feature, disables user namespaces.
<taylan>really weird, some of the commands suddenly work now
<toothbrush0>“The situation is not significantly different from when this bug was originally closed. There are still multiple vulnerabilities every month and upstream is still not providing a way to enable this at runtime via a sysctl flag. Arch is not going to carry an out-of-tree patch to add the sysctl flag like other distributions, so I don't think it makes sense to leave this issue open. The feature is not going to be ready for
<Steap>taylan: I can't get an interactive sessions though
<civodul>toothbrush0: no i agree that it's suboptimal; i just wonder what should be printed exactly
<taylan>ugh, I'm getting the silent failures again ATM. I wonder if the kernel does something weird.
<civodul>toothbrush0: like it can be annoying if the thing prints out a whole page of info
<davexunit>In order to build a debian package for the Chef server, you need to create a new virtual machine with Vagrant, that starts from a base disk image of an OS, in my case Debian. Then, Vagrant installs Chef and runs the Chef run lists to install all the dependencies needed to build the package. Then, Omnibus builds the package by bundling up all of things that Chef Server depends on into one big ball of mud.
<Steap>I try to stay on the "dev" side of "devops"
<toothbrush0>okay, i'm misunderstanding something. I'm running `./pre-inst-env guix build froogle-bluh --keep-failed`. the build works, and the test suite fails. Now i want to poke around in /tmp/nix-froogle-bluh..., but i can't find any binaries there. Do i expect this or am i insane? :)
<efraim>(copy-file (string-append "libstfl.so." (version-major+minor version)) (string-append out "/lib/libstfl.so")) is giving me unbound-variable on version-major+minor
<keverets>the guix package of youtube-dl fails for me due to CERTIFICATE_VERIFY_FAILED. Looking up this error, it seems users on other systems re-installed openssl in order to get the right certs that youtube-dl checks against. Such a remedy does not seem to apply (or succeed) for my guix package
<keverets>is there a known solution to have youtube-dl properly verify the cert so I don't have to use the "--no-check-certificate" flag?
<efraim>i have guix utils and guix build utils in my #:use-modules but not in my #:arguments
<efraim>i haven't found one yet, but i'll ask in their irc channel
<davexunit>efraim: you need to import the right module.
<davexunit>keverets: configure SSL_CERT_FILE and SSL_CERT_DIR, I imagine.
<bavier>efraim: or alternatively unquote the call to version-major+minor
<bavier>keverets: do you have a certificate package installed?
<davexunit>efraim: the build side code you're looking at is a quoted s-expression. that s-expression is evaluated in an entirely different process. that is, it's not part of the package module.
<keverets>davexunit: as part of a rebuild? I just used the default "guix package -i"
<efraim>notice anything wrong with this line? :) Appending installation info to /gnu/store/i5q3grjxlss9iimxqnn64501x8jx9070-stfl-0.24/gnu/store/czs63sm4l0s4a56ab38dqvkx19yzylbq-perl-5.16.1/lib/perl5/5.16.1/x86_64-linux/perllocal.pod
<paroneayea>davexunit: did you post the guix environment container stuff to hacker news?
<davexunit>paroneayea: no. if you'd like to do that, you should wait a bit for me to get a news post on Savannah.
<lfam>Although it was pretty late so I will try again now. I never know what my brain will do when I am tired ;)
<lfam>Yeah, even with the Lua deps propagated, prosody still can't find them.
<davexunit>lfam: is there a search path that needs to be set?
<lfam>davexunit: The problem must be something like that. I've never worked with Lua before but I think it's an interpreted language, yes? So the interpreter needs to know where to look for the dependencies.
<davexunit>lfam: looks like prosody makes some assumptions about where files are found
<davexunit>assumptions that, of course, are not true on a distro that doesn't use the FHS
<davexunit>the FHS is global state. glad to be going another direction.
<lfam>davexunit: Yeah, and I'm not sure how to tackle this. I'm currently trying to set up my XMPP client so I can get in the prosody chatroom ;)
<davexunit>do all the lua libraries install to the same location, relative to their store directory?
<davexunit>if so, they can be propagated, and then you can use a prosody config that sets the proper path variable to $your_profile/share/lua or whatever.
<lfam>I'd have to check but I think so. I was looking at how Debian does it, and they put all the libraries into something like a Lua-wide library directory. So it ends up like lua > lib > luasocket, luafilesystem, etc
<davexunit>and it's the easiest free software conference in the world for me to go to so I have no excuse not to be there.
<paroneayea>Description: User freedom is threatened by the growing complexity of current deployment and packaging directions. Running software is becoming too hard for the average user, so many are turning to dangerous directions which involve relying on large corporations to do their computing for them. What can GNU do to turn the tide here? Enter GNU Guix and GuixSD! This talk will walk through Guix's unique positioning to provide totally
<paroneayea>free and reproducible systems. A path will be laid out on how Guix could be used as a foundation for easy to run and maintain computing for everyone, how you can get Guix and GuixSD running, and how to get involved in the most hacking-friendly package manager / distro duo ever!
<paroneayea>Description: User freedom is threatened by the growing complexity of current deployment and packaging directions. Running software (especially server/networked software) is becoming too hard for the average user, so many users are turning to the dangerous path of relying on large corporations to do their computing for them. What can GNU do to turn the tide here? Enter GNU Guix and GuixSD! This talk will walk through Guix's unique
<paroneayea>positioning to provide totally free and reproducible systems. A path will be laid out on how Guix could be used as a foundation for easy to run and maintain computing for everyone, how you can get Guix and GuixSD running, and how to get involved in the most hacking-friendly package manager / distro duo ever!
<davexunit>wingo: hmmm sorry I end up just using stmp via emacs
<wingo>davexunit: seems no mta service is packaged for guix. oh wel...
<paroneayea>David Thompson is an FSF alumnus and Guile Scheme hacker. David works on system deployment tools for Guix, develops a functional reactive game engine called Sly (it's cool, you should check it out!), and is frequently found nose-deep in his copy of SICP. He lives in the Boston area.
<davexunit>wingo: maybe libesmtp won't be too hard to package?
<wingo>prolly not, i always need to patch it tho and was wondering why that was
<davexunit>paroneayea: hehe, that is very nice. thanks!
<ennoausberlin>@davexunit I saw your message too late yesterday. Baby was crying. So before I try to build lambdanative as a package I will start with something smaller. But good to know nobody is working on that so far.
<lfam>Looks like our build recipe should use MYCFLAGS instead of CFLAGS. MYCFLAGS is for situations like ours. Right now, we are overriding all the CFLAGS that are set by the Makefile
<HotLava>nvm, reinstalling the ordinary libguile fixed it
<lfam>Here's a dilemma: How can I build packages in my private load path (guix build -L) against an altered lua package in my Guix source tree? It seems like it will be a pain to make a private lua package, alter all the module paths, and then start testing. Especially since I don't know lua, so I might not be able to tell if the problem is with my lua stuff or with the Guix stuff.