<davexunit>heh, just proposed a small documentation patch to docker/libcontainer <daviid>davexunit: so guix does not use the [old?] guile internal test-suite but stricktly srfi-64 ? <davexunit>hmmm, the guix activation script writes to /sys <davexunit>paroneayea: just realized that you shouldn't have to propagate gdbm in that package you wrote. <davexunit>since you've patched the source to include an absolute path <rekado>I suspect this RUNPATH problem is related to a missing install target. CMAKE_INSTALL_RPATH is apparently only set when installing via CMake. <rekado>with an install target the validate-runpath phase does indeed pass, but ldd on the installed file still shows broken references to libraries. <rekado_>pfft, that's because I set the INSTALL_RPATH to my *current* LIBRARY_PATH instead of the value of LIBRARY_PATH at build time. <rekado_>success! Had to override CMAKE_INSTALL_RPATH with a manually constructed list of paths from all %build-inputs. Will try the same approach on the other package. <amirouche>Héllo, paroneayea I saw some message about a db quiz, what is it about? <amirouche>what does `guix environment --ad-hoc` is supposed to do? <rekado_>amirouche: it's used to spawn an environment in which the specified packages are available. <rekado_>before that you would have had to write a package definition with the inputs you want to be available in the environment. <amirouche>what is the correct commandline to create an environment and setup path environment? <amirouche>what is the difference between guix package -l and guix package --ad-hoc -l <rekado_>"guix package -l" lists generations. <rekado_>"guix environment --ad-hoc guile guile-sdl -E guile" runs guile in an environment where guile and guile-sdl exist. <rekado_>the feature is documented in the latest version of the manual. <davexunit>what creates /dev/null, /dev/zero, /dev/full, etc. on guixsd? <davexunit>I need to populate a container's device tree with the essentials <civodul>davexunit: there's some code in linux-boot.scm IIRC <civodul>and then udev takes care of the rest <davexunit>and the OS activation script has to be tweaked slightly <davexunit>the blocker right now is that it writes to /sys <davexunit>which is mounted read-only within a container <davexunit>it isn't good for a container to be able to write to the global /sys <davexunit>so I plan to add a #:container? keyword arg to this procedure <civodul>perhaps these could silently ignore EACCES <civodul>the Hurd has "sub-hurds" and "neighborhurds" *davexunit feels something fly just over his head <davexunit>my boss showed me this Docker "base image" put together by a company called Phusion, and they wrote their own minimal init system in bash! I think it would be cool to replace it with dmd instead. <davexunit>point still stands. dmd is surely better than this little python script. <davexunit>this page does a good job of explaining why you need an init system, even if you only want to run a single process within the container <davexunit>but then they decide to write their own minimal one in python instead of using systemd or something <davexunit>systemd *is* aware that it is running in a container, and our dmd just doesn't care. <Phlogistique>15:19:19 < davexunit> systemd *is* aware that it is running in a container <- well, more or less <Phlogistique>some parts of the code just assume that there are in a container if some mechanism (like mount --bind) fails <davexunit>Phlogistique: cool, thanks for the clarification. <davexunit>I'm not actually familiar with systemd's implementation. <paroneayea>amirouche: just looking into options for some stuff I'm working on <paroneayea>I saw you had the guile-wiretiger stuff, was interested in it <civodul>davexunit: dmd is ridiculously small and lacks some of the niceties of systemd, but it's definitely ok for a container <davexunit>civodul: yes, the small-ness is why I think dmd could replace that tiny Python script that Phusion wrote <jackdaniel>how dmd compares to runit (I have very little experience with either) <amz3>paroneayea: I saw your message on identica (and guix logs). You want to do a AcitivityStream application preferably with a graph database <amz3>atomspace looks awesome, slib too <amz3>from my noob perspective <paroneayea>I'm starting "as stupidly simple as possible" with gdbm <amz3>my plan is to create a graphdb on top of wiredtedtiger <amz3>it's good to start simple <paroneayea>I'm planning on building an activitystreams based MUD <paroneayea>maybe eventually if I add something like the above, then use gnunet or telehash or something <paroneayea>partly because I think such systems are interesting in proving a number of properties of a system <amz3>what wingo describe seems to have landed as BEP 44 in bittorrent protocol, that's what is used in gittorrent. It implements key/value pairs that are mutable (ie. that can be modified/updated) *amz3 can't run #PRISOM even with proprietary drivers :( <amz3>other argue that PPSP live stream and merkel tree jazz is the way to go... <amz3>for instance with BEP 44, one can update the content torrent file after the initial announcement, the leechers will receive the new entry (without pooling) for the same "key" in the DHT, no need to download all the things again <amz3>I mean download another torrent with the new entry <amz3>simply said: BEP 44 adds a concept of revision to a key's value (and it's signed) <amz3>by the way paroneayea wiredtiger only works on amd64 <paroneayea>amz3: I'd be interested in talking more about this stuff with you as I put more activitystreams stuff in place if you're also interested <paroneayea>amz3: ah that makes wiredtiger not too interesting <amz3>paroneayea: AS is a microblogging protocol, isn't it? <amz3>but got diverted into fiddling with code. <paroneayea>it's a general Subject Predicate Object serialization with a core but extensible vocabulary <paroneayea>you could use it to express microblogging, but also normal blogging, or updating games, or a distributed bookmark system, etc <paroneayea>we're using it for federated stuff in mediagoblin *amz3 tried gmg, the server did not want to start *amz3 should try a release tarball <amz3>paroneayea: tell me what you think, if you try #PRISOM! <paroneayea>as it turns out, I'm working on a new release right now <paroneayea>but the distribution setup... it's not great. I'd like to make a guix package, and that'll be a good proof that mediagoblin is in a better space <paroneayea>it's hard though for both legacy reasons and also because both the python and javascript packaging worlds have problems <amz3>I prefer python packaging :) <amz3>javascript distributed+bigmoney makes keeping things sane impossible <amz3>s/impossible/difficult ? <paroneayea>amz3: nearly impossible given each library having its dependencies bundled recursively <amz3>paroneayea: do you know mez breeze, one of the author of #PRISOM? <amz3>it's a game about privacy: «#PRISOM is a Synthetic Reality Game where a player is set loose» <amz3>in a Glass City under infinite surveillance. <davexunit>civodul: in order to properly use cgroups within a container, I need to launch dmd, force it to wait to read a pipe, add it's pid to the cgroups, then write to the pipe such that dmd knows it can continue. I don't suppose there's any easy way to make this happen currently, is there? <civodul>davexunit: you could do that from its configuration file <civodul>not particularly elegant, but it should work <davexunit>not at that point yet, but looking ahead at potential road blocks. *paroneayea package --delete-generations && gc *paroneayea kills all packages not being used, goes from 5 gb -> 209 MB \\o/ *davexunit imagines a command that unpacks a package's source tarball and creates a build environment within a container. *amz3 imagines a command that will suggest package to install that provide the binary <amz3>paroneayea: late reply, yes I'm interested to talk about privacy, activity stream, p2p, mediagoblin and guix <paroneayea>amz3: cool. Maybe a good time to speak will be in a couple of weeks when I get my activitystuff repo so that you can do Actual Fun Things with it (hopefully) :) <amz3>civodul: not very intersting right now, given gsd users. It's an utility program than runs in bash when you type a command that is not found in $PATH <davexunit>if I type 'git' without the git package installed, it will suggest that I install it. <paroneayea>ubuntu also has metadata on where stuff *will* be installed <paroneayea>we'd probably want to crawl the substitutes as some post-hydra-build operation or something to do that <davexunit>that would make us dependent on another server <davexunit>the best we could do right now is check package names <davexunit>this data could be encoded in the packages themselves, but seems like a waste of effort. <amz3>it can be a tarball downloaded as part of guix pull <davexunit>amz3: the problem is that the only way it can be produced is by building the entire dependency tree <davexunit>which will force people to rely on a third party <amz3>guix pull is already relying on a centralized server, no? <davexunit>well guix pull would be entirely the wrong place for this <davexunit>you can't know this information just by rebuilding the guix source code <amz3>what if you unpack the substitutes? <davexunit>we only have 2000 packages right now, but that is still too much to expect each user to download <davexunit>point is: metadata must be encoded in the package definitions <davexunit>building the entire dependency tree in order to scrape the names of binaries is unacceptable, IMO. <amz3>package definitions? the .scm that define how to buidl the package? <amz3>davexunit: it's very useful :)) <amz3>on debian, there is a command with which you can query *any* file not just /usr/bin/* <davexunit>that's for files already installed onto the system, which is trivial. <davexunit>since files in guix profiles are just symlinks, you can just read the symlink and know where it came from *amz3 crashed its main station (@debian) & installed guix on it too <amz3>why is the symlink starts with the hash instead of the package name? ***yang_ is now known as yang
<civodul>amz3, davexunit: ah right, it's "command-not-found" IIRC, right? <civodul>the thing is, we need to build a database of available binaries somewhere <civodul>i just checked and on NixOS, there's an sqlite database for command-not-found that gets downloaded alongside "channels" (the equivalent of "guix pull") <davexunit>civodul: do you see a problem with such a thing? <davexunit>it seems like an unnecessary reliance upon a third party <rekado>the problem with adding this kind of metadata to packages is that it could get out of date when updating a package. <rekado>maybe the linter could suggest a list of executables that can then be added to the package definition. <rekado>I'd rather not rely on hydra any more than necessary while distribution over GNUnet is not yet here. <rekado>quick question: I don't have /dev/snd/seq on my system and I cannot seem to load the snd_seq_midi kernel module (nothing happens). Can anyone reproduce this issue? <rekado>I just packaged a new tabulature editor that supports my ancient stash of powertabs and it segfaults because it cannot open /dev/snd/seq. <civodul>davexunit: right, that's not great; you would suggest encoding the name of binaries in package definitions? <civodul>rekado: the problem is that insmod/modprobe from kmod silently fail <civodul>you need to "insmod $(find $LINUX_MODULE_DIRECTORY -name snd-seq-midi.ko)" <davexunit>civodul: I wouldn't say "recommend" but the package definitions have been *the* place for metadata. <davexunit>I think maintaining that stuff by hand is gross, personally. <davexunit>but I don't like the precedent set by having the build farm supply the info <davexunit>of course, the user *could* build it themselves, but that's asking so much more than building any subset of the packages for themselves. <civodul>but so, to summarize, you're saying both solutions suck, did i get it right? :-) <paroneayea>we don't know where users might supply packages from, how about we include all available packages as input to a command-not-found package, build from all packages, and then install that back into the user's profile after removing all the packages again :) <davexunit>but the by-hand approach is a lot more acceptable to me. <rekado>bleh: "insmod: ERROR: could not insert module /run/current-system/kernel/lib/modules/4.0.3-gnu/kernel/sound/core/seq/snd-seq-midi.ko: Unknown symbol in module" :( <rekado>davexunit: especially when there's support from the linter. <davexunit>it would be trivial to add it to the linter. <rekado>but it would only work after building the package. <rekado>the linter currently works without having to actually build anything. <davexunit>does that violate the sanctity of the linter? <paroneayea>btw with the gnunet gsoc project which (I think?) got accepted, does that mean there is or will be gnunet guile bindings somewhere? :) <paroneayea>that is relevant to my interests *waggles eyebrows* <civodul>paroneayea: unfortunately the student has been unresponsive so far <paroneayea>civodul: at some future point maybe I'll see how hard it is to put together something with gnunet and the ffi <civodul>yeah that was supposed to be his first task :-/ <civodul>well it's still early, let's cross fingers <paroneayea>civodul: dealing with something similar, but I've dealt with similar things in the past... sometimes they turn around, sometimes they don't *civodul .oO( if alezost were here, i would suggest adding pcomplete support for the guix commands in Emacs... ) <efraim>if you've done guix archive --authorize is there a way to unauthorize? I didn't see anything in the documentation <civodul>efraim: you have to edit /etc/guix/acl by hand <civodul>there's no command-line option for that 