<davexunit>ACTION pushes environment container patch to master <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` <codemac>because I'm working on a package definition, I want it's inputs & some ad-hoc debugging stuff like strace <davexunit>codemac: the CLI doesn't work like that... yet. <lfam>codemac: I haven't tried to do what you are trying to do, so I might not understand your question. But can't you just list everything you want after --ad-hoc? <davexunit>lfam: that's what we want to change it to do. <davexunit>right now, --ad-hoc says *everything* is ad-hoc. <davexunit>when I brought up how I didn't like this and didn't know how to improve the interface, civodul threw out the idea of making --ad-hoc positional. <davexunit>so, sorry lfam. the bright side is that I know it sucks and want to fix it. <lfam>Hm, I'm not sure I understand what the limitation is. By "*everything* is ad-hoc", do you mean that you have to manually list all the packages, because dependencies aren't included? <lfam>I see. Your way will be better ;) <davexunit>what I'd like is something where --ad-hoc affects only the operands that come after it <lfam>So in that case, would strace's dependency on perl be handled, or would you also need to name perl on the command-line? <davexunit>lfam: all propagated inputs are taken into account <davexunit>the commenters seem generally uninterested in Guix or Nix, and think Snappy is better. <Steap>davexunit: $ ./pre-inst-env guix environment --container python <Steap>warning: failed to install locale: Invalid argument <Steap>guix environment: error: clone: 2099380241: Invalid argument <Steap>am I doing something wrong ? <Steap>davexunit: nah, I'm running Guix on top of Debian <Steap>what version of the kernel should I have ? <davexunit>user namespaces require a more recent kernel <davexunit>I should write a patch that performs some reasonable test for this and prints a more helpful message. <lfam>Seems to work fine when downloaded from that URL by `guix build` <lfam>Can anyone recommend an example of patching absolute paths like '/bin/rm' to relative paths like 'rm' in a package definition? <efraim>lfam: (subsitute* "in_which_file" "/bin/rm" (which rm)) <efraim>or if its a couple (substitute* '("fileA" "fileB") "/bin/rm" (which rm)) <lfam>efraim: Thanks. I had figured it out by looking in existing packages. <efraim>yeah I saw that was a couple of hours ago :) <lfam>I'm trying to get an XMPP server packaged. Switching between Prosody and ejabberd as I get sick of working on each one. I guess the first one to be finished is the one I will submit. <wingo>so is dbus-updates just broken? :) <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? <wingo>probably just needs to be a normal input <wingo>perhaps with (string-append "--with-ncurses=" <wingo> (assoc-ref %build-inputs "ncurses")) <efraim>turns out there is no configure for this program <taylan>and I imagine Guix still has some way to go to be usable on a relatively typical touch-screen smartphone :) <efraim>"(string-append front (assoc-ref inputs "libxpm") "/include"))" does this mean its exposing /gnu/store/...libxpm/include? <efraim>fairphone looks interesting, but far too expensive for me :) <taylan>efraim: not sure what you mean with exposing but that will indeed evaluate to a string containing /gnu/store/...libxpm/include, appended to the value of 'front' <taylan>so depending on where that form appears... <taylan>what does it mean to "expose" header files? <efraim>i should really just look at gnu/packages/xfig.scm <efraim>i mean i have some packages that look for headers from other packages and trying to work with that is driving me crazy <efraim>mplayer has a couple of hardcoded libraries that i want to patch the headers from our packaged libraries <efraim>ncurses/ncurses.h might need to change to /gnu/store/...ncurses/include/ncurses.h if I can't just tell it to look at the inputs for ncurses/ncurses.h <taylan>when libxpm is in the inputs, the guix builder should automatically add /gnu/store/...libxpm/include to the CPATH env var. isn't that sufficient for the configure script of MPlayer? <efraim>I could be doing something wrong, but currently it expects the libraries to be in the top directory of mplayer <efraim>needed lambda inputs & outputs, and switching ncurses/ncurses.h to /gnu/... like i had above <efraim>looks like we may get newsbeuter soon afterall <rekado>sneek: later tell lfam Prosody is on my list of things to package. It shouldn't be very difficult as we already have Lua packaged. <toothbrush0>davexunit, do you know anything about MIPS, ARM, and/or Racket? <toothbrush0>I'll wait for one of the exotic-platform gurus to show up. <iyzsong>hi! davexunit, great to see environment within containtar! <davexunit>much more work to do, but hopefully now that there's a tool to actually use, maybe some other people will join in on the hacking. <iyzsong>sure, I'd like to use it every day :-) <davexunit>I built a piece of software at work with it last week. <davexunit>which reminds me that I have a bunch of packages to upstream from that experiment. ***pksadiq` is now known as pksadiq
<taylan>davexunit: running 'guix environment foo --container' gives me 'guix environment: error: clone: 2099380241: Operation not permitted' <davexunit>I intend to detect this and respond with an error message saying as such. <davexunit>in particular, you need a kernel that supports the user namespace <davexunit>without it, non-root users cannot create containers <taylan>hmm, 3.16 is out though, on Debian. upgrading... <taylan>well, "3.16.0-4" so maybe it's just a Debian patch update <efraim>there was a code snippet on planet debian about userland cloning and it being disabled in the debian kernel <efraim>`sudo sysctl -w kernel.unprivileged_userns_clone=1` will fix it <taylan>now: make: /bin/bash: Command not found <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? <efraim>(substitute* "Makefile" ("/bin/bash") (which bash)) <taylan>so 'guix environment foo --pure' really wasn't pure this whole time? <efraim>it only cleared environment variables <taylan>hmm, maybe just need to rerun autoreconf <taylan>or at least ./configure, because somehow "SHELL = /bin/bash" seems to have ended up in the Makefile <taylan>but also e.g. 'guix environment guile --container -- guile' gives me 'In execvp of guile: No such file or directory'. seems pathes aren't set right? <toothbrush0>davexunit: i'm running into the same error as taylan, except i'm on Linux 4.2.3-1-ARCH #1 SMP PREEMPT Sat Oct 3 18:52:50 CEST 2015 x86_64 GNU/Linux <toothbrush0>sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory <taylan>well that worked for me and I'm on 3.16. <taylan>davexunit: I'll sum up the problems I'm facing on the ML <davexunit>taylan: okay, but really this isn't a problem of 'guix environment' <taylan>davexunit: after the sysctl line, it seems to work <taylan>just getting errors from within commands I run with it <davexunit>taylan: and the /bin/bash thing, it's because it's a container: /bin/bash isn't available <taylan>well, maybe it simply does some things wrong instead of giving me a clear error, so later other thinds error? <taylan>the contents of /proc/self/ns is: ipc mnt net pid user uts <davexunit>taylan: and yes, it was 'pure' in the sense that it cleared the process' environment <davexunit>it purified the environment, but didn't provide isolation. <davexunit>taylan: and 'guix environment guile --container -- guile' fails because 'guix environment guile' creates an environment with the *inputs* of guile <davexunit>thus the guile executable is not on your PATH <davexunit>use the --ad-hoc flag for adding packages directly <taylan>'guix environment --ad-hoc guile --container -- guile' should work? it silently exits with code 1 <davexunit>something is amiss with your computer. does this yield strace output? guix environment --container --ad-hoc guile strace -- strace guile <taylan>FWIW 'guix environment guix --container -- bash' works fine. let me try that one. <davexunit>taylan: can you get to a shell maybe? guix environment --container --ad-hoc guile strace -- /bin/sh <taylan>nope, also silent exit code 1 :\\ <davexunit>taylan: throw a 'strace -f' in front of the whole thing <toothbrush0>davexunit: what if i'm getting the same error ("guix environment: error: clone: 2099380241: Invalid argument") but on Linux 4.2.3? <davexunit>toothbrush0: what is the output of 'ls /proc/self/ns'? <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 <davexunit>I'll make sure that before the next release there will be an automated version of this test that runs before 'guix environment' tries to spawn the env. <toothbrush0>will have to move to GuixSD then, yet another reason :p <davexunit>unprivileged user namespaces are a bit bleeding edge, but I think the security issues seem to be overblown. <davexunit>the alternative is running containers as root, which seems more dangerous. <davexunit>the Docker team has been hesitant to add user namespace support, whilst all their users run containers as the root user. <taylan>it seems I'm hitting bugs unrelated to --container, or maybe PEBKAC. 'guix environment --pure guix --ad-hoc autoconf -- sh' leads to 'In execvp of sh: No such file or directory' <taylan>I realize the '--ad-hoc autoconf' part is redundant because it's already a dep of guix, but still, that should work, no? <taylan>it works when I remove that part <davexunit>taylan: it's because you've turned ad-hoc mode on. <taylan>oh, I thought 'guix environment foo --ad-hoc bar' is like 'guix environment foo' plus 'guix environment --ad-hoc bar' <taylan>ahh, you sent that patch but it didn't get applied yet :) <davexunit>yes, just wait a bit longer for it to make it through the review process <taylan>I had skimmed over it in the ML earlier today and thought "neat" and just assumed I can already do it :) <taylan>I guess that explains all, sorry for the trouble! <davexunit>hehe don't have faith in the patches I write just before I go to sleep. ;) <civodul>davexunit: thumbs up and everything for containers! <civodul>davexunit: would you like to post a news entry on Savannah? <davexunit>civodul: sure! just sum up the features and the work we want to do in the future? <davexunit>I'll try to write something up over lunch break. <toothbrush0>civodul: i forget btw, when was 0.9 slated for release? <civodul>wip-container was one of the big things i wanted to get in <davexunit>still a few patches hanging around in there. <davexunit>not sure if I want to introduce 'guix container' yet <davexunit>maybe once I've fleshed that one out more with, say, a management daemon. <toothbrush0>btw, this has probably been discussed 100 times already, but what about making `guix` by default output the same as `guix --help` instead of the rather obtuse "Try using `guix --help`"? <davexunit>but, on the other hand, if I add 'guix system container', it would be convenient to use 'guix container' to insert processes into the running container. <civodul>davexunit: 'guix system container' should be pretty much ready, from what i remember? <davexunit>it makes sense if we look at it as a "developer preview" feature <davexunit>I want to reserve the right to drastically alter 'guix container' when it's purpose becomes more clear. <davexunit>but for now, the container attachment feature is useful to folks playing with 'guix system container' <civodul>we could mark it prominently as experimental and subject to change <davexunit>I'll test out those patches and push them if they are good. <davexunit>recently the gnu/system/linux-container.scm module has generated compilation warnings, so I imagine some procedures got shuffled around and I need to import another module or something. <davexunit>I'll clean it all up and test. I haven't run a GuixSD container in awhile. <davexunit>next steps are to figure out cgroups and building virtual network bridges <davexunit>cgroups are more within my grasp. networking always gives me headaches. <civodul>toothbrush0: re --help, good point, why not? <civodul>mthl would know what the Right Thing is ;-) <toothbrush0>i would argue that all commands (e.g., also `guix environment`) should output their --help if they're invoked without the required arguments <davexunit>ACTION wrestles with trying to build chef-server packages for debian using Omnibus, Chef Test Kitchen, and Vagrant. <civodul>toothbrush0: i think the GNU convention is to print a short usage message rather than the full help output in those cases, not sure <civodul>davexunit: an intimidating combo ;-) <davexunit>I'm totally biased of course, but it's incredible how much complexity Guix is able to simply eliminate. <toothbrush0>because consistently, when i see that short summary, my next action is to invoke --help <toothbrush0>also, i'm curious as to mthl would be the Right-Thing-Guy? :p <Steap>taylan: I have similar issues <Steap>not sure why /bin/bash is even called <taylan>Steap: probably a default. providing an explicit command will do. if bash is in the environment, then just 'bash' (not absolute) will also do. <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. <efraim>or you could download a random debian image from the dockerhub and build on top of that <efraim>vagrant, chef, etc are all so last year <davexunit>yes, that replaces chef+vagrant with docker, but the evil that is omnibus is still around. <Steap>davexunit: honestly, all that devops stuff is killing me <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? :) <taylan>ew, so many closing parentheses! ;-) <paroneayea>civodul: doesn't so far off from what using Wisp looks like and using Guile :) <civodul>the NixOS column in the comparison table seems a bit off <davexunit>on my "is this software good?" check list, one of the items is "configuration is code" <davexunit>let me guess, this project has over a thousand stars on github <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" <keverets>bavier: I have the guix package of openssl 1.0.2d installed, as well as the ubuntu (host system) ones <keverets>davexunit: ok, I'll give that a shot. Thanks! <davexunit>keverets: I have the following variables set: <davexunit>SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt <davexunit>SSL_CERT_DIR=/etc/ssl/certs/ca-certificates.crt <davexunit>GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt <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. <davexunit>it won't have the Docker jabs that will make HN argue, though, <paroneayea>davexunit: I can reference that in the comments :) <keverets>davexunit: setting SSL_CERT_FILE works. Thanks muchly. I wonder, though, if your SSL_CERT_DIR is correct as listed? Shouldn't that be the directory and not the file? <davexunit>I am on a non-GuixSD machine at work and had my laptop next to me <keverets>no worries. I've done similar myself not too long ago <paroneayea>davexunit: nice compliment from paulproteus / asheesh in #userops :) <davexunit>yes, we do seem to clash. glad it's not 100% of the time. :) <paroneayea><asheesh> Thanks paroneayea , that post is great for explaining what's great about guix containers! <davexunit>heh, yup. I'm sure a lot of people are feeling the pain of these settings. <lfam>Has anyone tried to package Lua software with Lua dependencies? For some reason I can't get this program to find its dependencies. <sneek>lfam, rekado says: Prosody is on my list of things to package. It shouldn't be very difficult as we already have Lua packaged. <civodul>davexunit: we need to make sure the manual mentions this, as well as the minimum kernel version required <lfam>rekado: I need to clean up the my work tree a little, then I will make my WIP prosody packaging public and you can take a look. <wingo>i don't understand why so many things fail to build on dbus-updates <davexunit>wingo: I think patches that in retrospect shouldn't have been added there got added there and broke some stuff. <davexunit>but I'm not working on that branch, so I don't have all the details. <wingo>it's frustrating because apparently that's the branch i need to properly package elogind's pam stuff which seems to be at the the bottom of this tree of things <davexunit>we should prioritize fixing dbus-updates, then. <lfam>rekado: You can check out my WIP prosody package here: https://github.com/lfam/pkgs . It builds but prosody can't find the dependencies at run-time. It's driving me nuts ;) <lfam>rekado: Please forgive the sloppiness of the packages as they are now. It's just the "staging" branch. <lfam>rekado: Any help would be appreciated <davexunit>lfam: those lua libs probably need to be propagated <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>the prosody documentation should hopefully have some clue <lfam>I don't really know how to approach this. <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>if that works, then you can begin to think about how to fix this. <davexunit>would be nice if prosody respected an environment variable or something <davexunit>then 'guix package' could inform the user about it. <davexunit>or rather, since this makes sense to be run as a dmd service, the default prosody config could be generated with the correct search path. <lfam>So, is there a way to set these variables when installing Prosody? <davexunit>LUA_PATH and LUA_CPATH should probably be added to lua's native-search-paths package field <davexunit>so that when lua is in a profile, 'guix package' will tell you about needing to set them. <lfam>Ah, no way to set them automatically? <lfam>Can you recommend an example module to learn how to use native-search-paths? <davexunit>keep in mind that prosody is probably not something a user will install into their profile typically. <paroneayea>aeva: btw, you might want to see the updated info in the "Application Setup" section of the manual about locales <davexunit>which would be a guixsd system service, and that service could ensure that the environment variables are properly configured. <paroneayea>from earlier> aeva: btw, you might want to see the updated info in the "Application Setup" section of the manual about locales <paroneayea>I wonder if I should ask for commit access for guix now <paroneayea>since I'm doing minor updates like updating versions and stuff <aeva`>that is pretty cool that you've been hacking on guix <paroneayea>yeah I've been pushing small things... I haven't gotten time for the really big stuff I've wanted to do though... <paroneayea>I've gotten tied up in a lot of stuff around standards work recently <paroneayea>davexunit: is that basically, "ask on list for commit access"? :) <davexunit>paroneayea: there's a form to fill out on savannah <davexunit>so that savannah has a commit access request that we can approve <davexunit>and then savannah will DTRT to give you write access <davexunit>that will get approved soon enough, probably by civodul <paroneayea>always thrilling to get commit access in a project :) <efraim>I did a little happy dance around my apartment when I got commit access :) <efraim>has anyone gotten guix system vm to work on debian? <efraim>my system seems to be missing something <efraim>i keep on getting Could not access KVM kernel module: Permission denied ***aeva`` is now known as aeva
<davexunit>paroneayea: I suppose we've got to get a talk proposal for GNU Guix in soon. <paroneayea>Title: Solving the Deployment Crisis with GNU Guix <civodul>it'd be great to have the two of you talking there! <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! <paroneayea>davexunit: great, I'll submit that with the notes that this will be co-presented by David Thompson and Christopher Allan Webber <wingo>does anyone use mailutils as a local outgoing-only mta? <wingo>i currently use libesmtp but it's not packaged and i was wondering what the right thing might be <wingo>i want to be able to use sendmail offline, ideally as a user i guess though i could use a full-fledged system mta if that's the right thing <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! <wingo>mailutils is gnu but somehow intimidating... <davexunit>we need more services. we need to do a sprint of just servicifying things. <davexunit>paroneayea: thanks so much! when I asked the question I didn't anticipate you just doing the whole damn thing. impressive. <civodul>wingo: would be nice to have an MTA service, indeed <wingo>i am not a mail admin so prolly i am not the one to do such a thing... <paroneayea>I figured might as well type it out and get it done before I forget, anyway :) <wingo>looking forward to the new service stuff landing btw :) <wingo>i tried to build that branch but was stymied by the unrelated failures <wingo>that's what i get for hubris <davexunit>thanks to civodul, head of air traffic control. <davexunit>I want to save it until I get the 'guix system container' patch in, too. <davexunit>paroneayea: when I get to hack on guix next + an hour or two. <wingo>ah i think the dbus-update has some service-related things there <paroneayea>davexunit: maybe I can also submit a post to lwn.net or opensource.com or something. <wingo>i don't see those service things on master anyway <davexunit>patch is approved. just needs to be dusted off, tested once more with a new OS config, and pushed. <civodul>davexunit: i wonder if it might be clear to explicitly add "compared to Docker" after "The most notable difference" <civodul>otherwise it sounds like "The most notable difference compared to you-know-what", but the reader may not know <davexunit>I was going to avoid mentioning them explicitly, since the differences actually apply to most other container systems. <wingo>"compared to other container implementations such as Docket" <davexunit>CoreOS rkt and LXC/LXD are similar in that they manipulate disk images <efraim>opensmtpd is supposed to be easy to work, in terms of "lets get an mta NOW" <civodul>ACTION adds 'guix system list-generations' <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. <HotLava>is there an way to download debug symbols for a guix package? (in particular libguile) <davexunit>alright, patch finally sent for 'guix build --file' <lfam>I've made some progress with Prosody, but now it seems that our Lua is compiled without dynamic library support. <lfam>Steap: I saw you have worked on the lua package, do you have any advice? <HotLava>hm, so whats the syntax to force a specific hash for a package? my guile-debug:2.0.11 has different hash than guile:2.0.11 <Steap>lfam: I really do not know Lua at all :( <Steap>I just packaged Lua because I wanted to package the Awesome window manager back then <lfam>Heh, same here, I just want an XMPP server <civodul>lfam: i think Sleep_Walker worked on it a while bakc <lfam>I'm getting some help from the Prosody XMPP chatroom and if that doesn't work then #lua <civodul>ISTR something about dynamic libraries not being built <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. <HotLava>although i'm not sure if it's desired that you can have the different outputs of a package in different versions, or is it a bug? <lfam>I wish that `git blame` gave me IRC handles <lfam>In other news, I had to hook my normally-headless armhf computer up to a display so that I can figure out why `guix pull` always ends with a loss of network connectivity. <civodul>HotLava: try: guix package -i guile guile:debug <civodul>HotLava: that should select the current Guile and its associated debugging symbols <HotLava>civodul: yes, that's what i did and it solved the issue <HotLava>but is it a feature or a bug to allow this inconsistent versions in the first place? <civodul>'guix package' doesn't know about the connection between these two things <civodul>so it happily installs debugging symbols that do not match the binaries <HotLava>it doesn't? 'guix package --list-available' shows them as two outputs of the same package <civodul>but yeah, maybe the manual should mention it? <civodul>but once it's installed in the profile, it's a "dead" object <lfam>How do I handle the quoting in this string? "MYCFLAGS=-fPIC -DLUA_USE_LINUX MYLIBS="-Wl,-E -ldl -lreadline -lhistory -lncurses"" <civodul>HotLava: i see it's quite confusing, tho <lfam>Just put it in like that? Paredit is uncooperative ;) <civodul>it depends on what the build system does with $MYCFLAGS <civodul>but it's unlikely to ever work as expected ;-) <lfam>I think that MYLIBS needs all that stuff quoted <lfam>Should I build it up with (string-append)? <civodul>but MYLIBS is not a valid CFLAGS anyway <lfam>That's copied and pasted from the lua makefile. <HotLava>civodul: thinking about it, this actually makes it impossible to install symbols for a running binary if the package hash has changed in the meantime, no? <civodul>lfam: can't you do: #:make-flags (list "MYCFLAGS=..." "MYLIBS=...") ? <civodul>HotLava: right, at least not easily so <HotLava>but i guess you can just get something "close enough" and set the paths in gdb manually :D <civodul>not because debugging symbols include a CRC <HotLava>the symbols itself are hashed? Ok, also good to know ;) <civodul>right, the binutils manual explains the details, IIRC