IRC channel logs


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>but not sure where
<vagrantc> has make-arm-trusted-firmware (updated to 2.0 locally) as well as arm-trusted-firmware-sun50i-a64 (the package i'm trying to build from a specific git commit)
<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
<vagrantc>which has had isses recently
<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
<brendyyn>although im not sure
<mbakke>brendyyn: What error are you getting?
<mbakke>It's almost certainly not due to an old daemon.
<brendyyn>1 sec
<brendyyn>The first time I ran guix pull it had all sorts of error but completed, running it again after produces this
<mbakke>brendyyn: That looks odd, can you report it to ?
<nand1>it looks like hydra is back online
<apteryx>nand1: good to know!
<g_bor>hello guix!
<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
<civodul>Hello Guix!
<rk4>hello backwards friend
<g_bor>hello :)
<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>I see hydra is back up
<efraim>Merge core updates, python3 update & merge and then on to GNOME and core-updates-next?
<g_bor>efraim: sounds like a plan.
<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>i got 872 for nss and nss-certs
<g_bor>Same here.
<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
<g_bor>Here is the mail where guix refresh reports much more rdeps for nss
<civodul>g_bor: sorry i haven't looked closely at this yet :-/
*civodul has to go to a silly meeting
<g_bor>civodul: later!
<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.
<g_bor>See here for an idea
<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.
<roptat>hi guix!
<kristofer>good morning
<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
<bitmapper>just installed guix on one of my laptops :D
<jonsger>bitmapper: congrats :)
<bitmapper>too bad i can't get libreboot
<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>dout of the command...
<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
<bavier>hi civodul
<civodul>howdy bavier!
<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.
<civodul>sure, np
<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
<nand1>I see
<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>Hi Guix
<rekado>I have finally awaken from my flu stupor
<apteryx>rekado: good to know you're well :)
<_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?
<jonsger>npm is...crap
<emacsomancer>hello, guix
<emacsomancer>I'm now having an issue with `mu` (mail util)
<emacsomancer>when I try to run it I get an error: mu: error while loading shared libraries: 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>lfam: $ realpath $(which mu)
<lfam>You'll need to make that store item "dead" — that is, make sure no profiles refer to it
<emacsomancer>I was using the berlin one
<lfam>Okay, thanks, I'll make sure it gets deleted from the server
<emacsomancer>lfam: would deleting old generations be good?
<lfam>emacsomancer: You'll need to remove any profile or generation that refers to this store item
<emacsomancer>thanks, I'll try that
<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))`
<emacsomancer>ah, I'll try that
<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
<emacsomancer>ok, I'll have to check on how to do this
<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>That works :)
<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?
<efraim>i was just suprised
<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
<emacsomancer>I need to play with doing roll-backs and such more