IRC channel logs
2018-11-06.log
back to list of logs
<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 <vagrantc>i can cut-and-paste and adjust the whole (orig (source ... section ... but that seems redundant *vagrantc is starting to suspect misplaced parens <vagrantc>ok, i guess make-arm-trustred-firmware doesn't set name <sirgazil>How do I know what substitute servers I'm using? <vagrantc>if none are configured, it's probably just using mirrors.hydra.gnu.org <brendyyn>Hmm my guix pull has failed and it think it may be due to not rebooting in a long time, my guix-daemon is old such that breaking changes were made <mbakke>brendyyn: What error are you getting? <mbakke>It's almost certainly not due to an old daemon. <mbakke>brendyyn: That looks odd, can you report it to bug-guix@gnu.org ? <nand1>it looks like hydra is back online <g_bor>ISTM that this python-minimal issue has just too many bugs allocated already. <g_bor>I think it would be wise to merge some. WDYT? <efraim>there's the memory leak, the bad test, something else too? <efraim>ISTM retitling some of them might also help keep track of them, but really depends on how simliar the issues are <efraim>is there a default port for guix-publish? <efraim>i see it in (gnu services base), port 80 <rk4>hello backwards friend <rk4>out of curiousity, is there any indication as to how many guix installs are out there? perhaps a minimum bound would be inferable from hydra's substitite traffic <g_bor>civodul: It seems to me that this python-minimal thing is getting slightly out of hand, I have seen at least 5 related bugs and 3 related patches. What should we do? <efraim>Merge core updates, python3 update & merge and then on to GNOME and core-updates-next? <g_bor>also, here is this other thing with nss, refresh -l reported around 800 rdeps here, but I've seen a mail from Björn when there were thousands of rdeps. I was confused. Can you clarify that? <g_bor>The python issue is indeterministic, but the nss issue is reproducible. <efraim>guile-ssh took 3 tries for the tunnel.scm test to pass on aarch64 on core-updates <efraim>looks like 'guix pack' is missing a 'list-formats' flag option <civodul>g_bor: sorry i haven't looked closely at this yet :-/ *civodul has to go to a silly meeting <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 <g_bor>Author: Tobias Geerinckx-Rice <me@saibot.rg> <g_bor>Date: Fri Nov 10 08:20:19 2017 +0100 <g_bor> gnu: curl: Add HTTP/2 support. <g_bor> * gnu/packages/curl.scm (curl)[inputs]: Add nghttp2. <snape>rekado: I think it would be useful that you type "herd stop cuirass && sqlite3 /var/lib/cuirass/cuirass.db 'update builds set status = 4 where evaluation = 1401' && herd start cuirass" <snape>to cancel all the builds that have been triggered by the c-ares evaluation <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 <civodul>vaab: did it print beforehand what was going to be downloaded? <bavier>vaab: the hello package contains a reference to gcc's "lib" output <bavier>and it may need some other packages to build the profile <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. <mbakke>civodul: Do you know which commit Hydra is currently evaluating? <civodul>mbakke: no, and the log of hydra-evaluator doesn't provide much info :-/ <nand1>is it normal to end up with stray *-guile-builder files in /gnu/store of recipes I haven't tried to build (like xonotic, for example) <nand1>what is the role of *-guile-builder files? <nand1>could it be because I cancelled some updates or my computer crashed mid-update? guix gc was able to clean out these dead store items <bavier>nand1: it's the guile code that derivations use to build a package <civodul>you need not worry about them: next time you run 'guix gc', they'll be deleted <nand1>I was just afraid my computer was compromised or something and was wondering when they were generated <rekado>I have finally awaken from my flu stupor <_tibbe>Hi, I have a problem getting the GuixSD installer running: I cannot get any kernel in the image booting. Grub refuses to load it because of an invalid magic number. <kristofer>_tibbe: does your machine have udma or some other sata-ide combined mode? <kristofer>there is likely a bios option to disable it. you might investigate some kernel options as well, I'm not really an expert <_tibbe>kristofer: Thanks for the hint... Bios options are a little bit difficult as the pc is libre booted. But why should that cause grub to not like the magic number of the kernel? <emacsomancer>when I try to run it I get an error: mu: error while loading shared libraries: libgmime-2.6.so.0: cannot open shared object file: No such file or directory <lfam>emacsomancer: I thought it was just me but I have a workaround <lfam>The issue is that the substitute failed to have its references recorded properly <lfam>What is the output of `realpath $(which mu)`? <lfam>And, which substitute server are you using? <lfam>The solution is to delete the bad store item and to rebuild it locally, until the bad substitute is deleted from the substitute servers <lfam>`guix gc -d $(realpath $(which mu)) && guix environment mu -- guix build --no-substitutes mu` <emacsomancer>/gnu/store/f0b97d5rh2hcmy9wn6h4g78x1npnhqaq-mu-1.0/bin/mu <lfam>You'll need to make that store item "dead" — that is, make sure no profiles refer to it <lfam>Okay, thanks, I'll make sure it gets deleted from the server <lfam>emacsomancer: You'll need to remove any profile or generation that refers to this store item <emacsomancer>lfam: I get "cannot delete path ... because it is alive" - is there a good way of figuring out which profiles or generations refer to this item? <lfam>You could grep the output of `guix package --list-generations` <emacsomancer>I see it in: "mu 1.0 out /gnu/store/f0b97d5rh2hcmy9wn6h4g78x1npnhqaq-mu-1.0" <emacsomancer>so I need to get rid of it in the current generation I suppose <lfam>emacsomancer: I forgot, but the best way is probably `guix gc --referrers $(realpath $(which mu))` <lfam>That's convenient that it's only in one generation <emacsomancer>but I get 30 different items when I run "guix gc --referrers $(realpath $(which mu))" <lfam>Of those results, you'll need to garbage collect the profiles <lfam>Or delete the profiles, and then garbage collect the mu store item <lfam>`guix package --delete-generations NNN && guix gc --delete /gnu/store/...-mu` <lfam>Where NNN is the number of a generation you wish to delete <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. <lfam>I tend to keep one month of old generations: `guix package -d 1m` <nckx>efraim: > when did c-ares become a dependant of everything! <nckx>efraim: Is this an actual problem or just surprise? <emacsomancer>lfam: I'll play with arguments and see whether -d 1m or 1w works or not in terms of space - it would be nice to have generations to fall back to <lfam>Yeah, when I noticed the mu problem I was glad I could do `guix package --roll-back`, since I needed to use mu at that moment