<vagrantc>so, i'm trying to make a variant of arm-trusted-firmware that uses the make-arm-trusted-firmware function to inherrit most of the package definition, but need to change which git commit it pulls in ...
<vagrantc>i basically need to change the (source ... sections produced by make-arm-trusted-firmware, but i don't want to duplicate all of them
<vagrantc>i can't simply inherrit from it, because make-arm-trusted-firmware isn't a function
<vagrantc>basically just need to change the git commit and corresponding hash
<vaab>In case I share the /gnu files and /var/guix with different docker instances, each of them having their own 'guix', is there a correct locking mecanism (filesystem based in /gnu or /var/guix) that will prevent messing things up ?
<g_bor>vaab: /gnu/store is shareable. I don't know about the rest.
<g_bor>I guess the easiest setup is to use one daemon, that manipulates the store and configure the guixes to connect to that.
<vaab>g_bor: well, I'm concerned about the sqlite db that is syncronised with the store I guess. But it is in /var/guix, and this is also shared amongst instances. So the only thing that is required, is to ensure locking between addition to the store and updating the sqlite db.
<vaab>g_bor: thanks for the link about the shared lone instance, it's interesting ! In my setup, I won't be able to do that, and it seems that (at a quick first glance), guix should/could support multi-daemon sharing only /var/guix and /gnu ...
<vaab>g_bor: I'm separating concerns in my setup: one docker with the builders (running guix-daemon), one docker with guix command-line using only substitute and offload... managing a gnu store that is local to the VPS , one docker for subsititute (guix publish). Each VPS would run a set of those 3 profiles depending on their specs or usage... a combinat
<vaab>ion of the 3 being totally possible in master servers. I'm in the POC phase now, and quite new to guix/nix, so I might fall on obstacles that I didn't foresee quite quickly.
<efraim>when did c-ares become a dependant of everything!
<vaab>Does 'guix publish' publishes it's own public key in some special URL to ease the authorization process ? Or do we have to get it from other means ? Is it easy to add this behavior to the current server ?
<g_bor>efraim: I believe this happened on htis commit: commit 1300e4ee5bf97e7687aa0fa5497d87cf1afaa813
<vaab>I did a ``guix package -i hello`` ... substitute seems reachable as the command obviously download a lots of things, but why is it loading ``gcc`` and all these packages ? Am I missing something ? I would expect it to download glibc and hello package... that's all. Is one of these packages missing in substitutes ? If yes it is not obvious in the st
<vaab>civodul: sorry, my bad, still quite confused by guix. I think I understand that I forgot authorization for my substitute. It says something about substitute that *may* be unavailable due to ACL. I didn't do the ``guix archive --authorize`` bit. I'm still unsure if it was looking for "hello" substitute and it was not found so it decided it would bui
<vaab>ld it... because now with the authorization done, it downloads directly on my server lots of dependencies (gcc-5.5). Sorry for my beginner's questions, and many thanks for your insights.
<lfam>Since the mu store item is in your current profile, you'll need to remove it by making a new profile generation `guix package --remove mu`
<lfam>Sorry that my advice has been a bit unclear...
<emacsomancer>no, it's been very helpful - I wasn't sure even how to procede before, and I've still been a bit uncertain about profile/generation management
<lfam>generations are just old profiles, and they are managed with `guix package`
<emacsomancer>I've generally just been doing `guix package --delete-generations` with no argument and getting rid of all old generations. I know that's probably not ideal, but I tend to run low on disk space otherwise.