<wingo>i see it like, we have guix the user-space package manager and guixsd for systems. guix-based docker is like the user-space guix -- a useful tool to get stuff done, and a vector for further guixification
<wingo>we don't really see guix and guixsd as competing with each other, so we shouldn't see guix-on-docker as competing with guix containers either
<kyamashita>So Red Eclipse binaries built by replacing DESTDIR with INSTDIR as used in its Makefile.
<kyamashita>But data won't extract to the installation folder...
<bavier>kyamashita: what do you mean? there's an error while extracting? or the data doesn't end up where you expect?
<kyamashita>I don't see the data folder in redeclipse's /gnu/store folder
<kyamashita>The data and config folders have to be with Red Eclipse or it won't launch.
<bavier>kyamashita: how are you handling the extraction? maybe you need to pass -C to tar?
<kyamashita>I'm passing "-Cdata" to tar, but I see no data folder... Perhaps I'm missing a copy step.
<bavier>kyamashita: "data" will probably extract into the build folder; which would need an additional copy to the installation folder. You might also do something like (system* "tar" (string-append "-C" %output "/data") ...)
<bavier>so that the data is extracted directly to the store
<mark_weaver>more precisely, SCM was derived from SIOD, and then Guile was derived from SCM
<lfam>htgoebel: If you change a package definition, you don't need to restart the daemon to get the updated package definition. You just need to do a `guix build foo` against some copy of Guix that has the new foo.
<lfam>To get the software provided by the updated package, do as I said. To get the updated package definition itself, you'll either use `guix pull` or you can also build against a copy of the Guix source tree in git
<htgoebel>davexunit: 3rd party packages have been the reason why I've put the aliases in. If these do not matter, simply drop that patch
<lfam>I wonder if anybody has ever not had this problem the first time?
<htgoebel>lfam: This is the section I tried to follow.
<htgoebel>lfam: Maybe this section should be restructured: Maybe 1) building from git with some guix already installed 2) ... without same guix already installed 3) Hacking the daemon
<lfam>htgoebel: I really think that section should be more descriptive. It would be helpful if you could review past discussions that mention 'localstatedir' on guix-devel, and then file a bug with an outline of proposed changes.
<lfam>I would not spend too much time writing the actual changes at first. Most likely you would need to revise them quite a bit.
<lfam>Oh, I see you want to change that section more broadly. Then, you'd probably want to search for more than just 'localstatedir' on guix-devel.
<lfam>I think the need to set localstatedir appropriately needs to be communicated more clearly in the manual.
<quiliro>> Estimado Frank Villarreal: > > Gracias por enviar su correo. Espero que algunos alumnos o docentes se > encuentren interesados. Por el momento estamos interesados en recibir > un pasante que sepa desarrollar aplicaciones para Android, si lo > tienen disponible. Ya tienen algunpasante para nosostros? > Además, me gustaría saber si ya tienen personas interesadas en los > otros proyectos que le he planteado. Ya se resolvio este ot
<htgoebel>Do we have a change getting a collaboration platform like gitlabs for guix? I find it extremely ineffective and tremulous updating the patches. With gitlab I'd simply push the updates to my merge-request - done.