<g_bor>I feel that the rating system on the Outreachy site is not in alignment with what we have been communicating, so we should rate based on communication skills instead of number and "complexity" of contributions, whatever that supposed to mean in this context...
*rekado updates all Bioconductor and CRAN packages
<vaab>I have a "Error relocating bash: __mbrlen: symbol not found" on a "ldd bash" in my /gnu/store... preventing simple bash scripts from working. What could have happened to lead to this situation ? How can I investigate further ?
<vaab>It seems that I'm missing a package in the /gnu/store (this bash is linked to a glibc-2.27 that is not in the store for some reason)
<vaab>Oh, I got a file, instead of the expected directory in /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/ ... I have a ".lock" file: /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27.lock
<vaab>roptat: no, I never ran guix gc on this test install.
<roptat>I think I've seen a similar report yesterday
<vaab>When these lock file are supposed to appears in the guix processes ? I'm in a very special setup that might be out of normal use cases, so I can't claim that this is a legit bug, but I need some insights about what could I've done wrong in my setup.
<vaab>Of course, if this is a known bug somewhere, this would definitively disculp my setup, and save me some time figuring what subtle process or assumption I've broken.
<vaab>roptat: ok, I'll definitively try this also.
<vaab>rekado: thanks, that's interesting (regarding my setup).
<vaab>Hum, I have a lot of these /gnu/store/*.lock everywhere even on my other guix installs... Do you have some on yours ? Is that normal ?
<efraim>I have a bunch too, if you want to get rid of them I run 'guix gc -C 1'
<efraim>It clears 1 byte from the store, so all the 0 byte files and 1 real thing
<vaab>efraim: thanks, that could be useful. But isn't it showing that something is going wrong on guix side ? Who is locking, why the locks are still there ? Will that have a consequence ? I'll go see the source code...
<g_bor>I've seen a conversation eariler about missing store items.
<g_bor>I had the same problem, but that manifested in more serious consequences.
<g_bor>It broke my guix, I had to get a store item manually in, the I could guix gc --repair.
<g_bor>It took me a few days to get this figured out.
<vaab>g_bor: well, my guix is all broken also... this manifests after a ``guix pull`` (that ends up failing) on a fresh 0.15.0 ... the profile gets modified to a new profile that requires a inexistant glic. I don't get obvious warning that any went wrong meanwhile. As a reminder, my setup is *very* experimental, just trying to understand what is happenin
<g_bor>It happened to me on guixsd, and I've found that the guix in the system profile could be recovered.
<g_bor>after that I could guix pull to core-updates, but not to master...
<vaab>hello g_bor ! no I'm heavily using dockers and trying to get a nice setup for my use case... Which is more devops related and quick deployment of VPS. I'm using a simple alpine server with guix 0.15.0 binary tar as a start. As this is docker, I can reproduce everything at will. My current experiment involves running the guix-daemon on a separate do
<g_bor>If it does delete packages then I guess that is a bug.
<rekado>vaab: it does not delete packages nor does it call the garbage collector.
<vaab>rekado: thanks ! ;-) I've something very weird happening then. because starting with the 0.15.0, I have /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27 ... but while doing ``guix pull``, it gets deleted. I'll see what can explain this in my setup... for now it is far from being obvious.
<g_bor>vaab: I guess only the daemon should touch files in the store, so you might get a bit closer if you strace the daemon.
<vaab>Well, strace is formal, guix-daemon is deleting (unlink all files and then rmdir) the whole "/gnu/store/xxx-glibc-2.27" directory recursively. This seems to be done in the main process that gets to manage the new connection to the daemon.
<snape>civodul: very nice, your changes on Cuirass
<snape>and it's even faster with the shepherd changes
<vaab>In the current implementation, is it possible for guix to live only on substitutes (and not building anything) provided that substitutes are available for all components required ?
<davexunit>I don't think so. lots of things are non-substitutable
<davexunit>usually very small things like the hooks that run when building a new profile generation
<davexunit>but if there was some way to distinguish package derivations from those and only accept substitutes for those, that would be cool.
<vaab>davexunit: I'm not sure I follow you (I new to guix and/or nix). Do you mean profiles are not substituable even if the same profile was built on the substitute server ?
<kristofer>can o' worms be damned. you might as well teach a CS course on guix.
<vaab>davexunit: are these "lots of things non-substitutable" require a lot of heavy dependencies (do they have to be compiled, and requires guile, gcc, and whole build-only deps ?)
<bavier>vaab: substitute servers typically do not build profiles, since those are particular to a user; the contents depend on the combination of packages in the profile
<bavier>vaab: once the packages are available, building a profile is not resource-intensive
<vaab>bavier: I completely understand that, of course. But in my case, profiles will be the same, and I'm making my own substitute server (guix publish). Is there still some things that require builds ?.
<vaab>bavier: ... thing that would be unsubstitutable.
<kristofer>vaab: you might be able to guix archive --export in your situation
<kristofer>from section 3.8 in the guix manual "Invoking guix archive"
<kristofer>the fourth code example is how a complete user profile might be tranferred from one machine to another
<vaab>kristofer: well, I've seen that option, but it doesn't seem to apply to my case : I'm interested into downloading only the required substitutes that are missing locally. I want to avoid any local build for simple reason: these are VPS that are often very tight on ressources.
<vaab>kristofer: the missing substitutes will vary greatly depending on the list of docker-guixes services are already deployed locally on the VPS.
<vaab>kristofer: I'll make sure (if that's an option) to build before-hand every substitutes they could need (a quick deployment/update of the services is the target here). I know about offload builds and this will also part of the setup. I'm just trying to understand more about guix.
<davexunit>vaab: some derivations are marked such that they can never be substituted, but I don't know all of the things that are not substitutable.
<roptat>it copies items like guix archive --export, but first it queries the target to only send the required store items
<davexunit>vaab: since you are running your own substitute server you should be able to have good control of what gets substituted.
<davexunit>and those small virtual machines won't have to do much at all.
<vaab>roptat: yes, I've seen this one also, that's indeed much closer to what I want. I was digging into using the normal "package -i" because it seemed possible... and as @davexunit put it, if I have control of my substitute server, I hope to control what gets substituted. The "copy" solution seems to duplicate here something that should be done automat
<vaab>ically (according to the imperfect knowledge I have now of guix).
<rekado>civodul: I just copied /gnu/store to the external storage. Nothing important.
<rekado>civodul: you can go ahead and reboot it if you need
<davexunit>vaab: yeah, you should be able to make it "just work". though I think there is certainly room for improvement in guix to support this case better.
<davexunit>I used to do something similar and spent many hours trying to figure out why something was being built from source that was already built on the substitute server.
<davexunit>grafts, at least the early versions of grafts, caused me lots of headaches.
<vaab>in case of rapid deployment, you are root and have full control on the machines, guix-daemon to provide access to /gnu/store seems useless, and a straight access without having a dangling service could be appreciated. It is true that there is then not much difference with ``guix copy`` which I keep as a fallback solution after my little exploration
<vaab>I'm trying to use my own guix git repository in git pull, problem: it requires an identity files. Is there some trivial way to make this work that I didn't catch (I went to see guile-ssh docs, guile pull docs, read things about channels proposal...) ?
<vagrantc>does it not support an ssh-agent or standard identify files in ~/.ssh/id*.pub ?
<vaab>vagrantc: well openssh works very well and is already configured, but implementation of ".ssh/config" is not in libssh to my understanding, and thus guile-ssh doesn't use it. Not sure for the git module of guile. I'm very new to all this. What is sure is that "git pull" bails out.
<mbakke>vaab: An ugly workaround is to clone the repository locally and use --url=/path/to/repo.
<mbakke>I don't think `guix pull` has SSH support currently, but that would be nice.
<vagrantc>heh. yeah, i use such an ugly workaround ... though i've noticed guix complains about running guix pull recently
<vagrantc>i think it's because it assumes guix is out of date because it's not pulling from the default master or something
<kristofer>my studio machine broke. I'm not sure what happened, but now that I have to put another one together, does anyone have some guidance on setting up guix with realtime kernel for audio production? My typical setup would include jack server, ardour, a wide range of plugins, hydrogen drum machine, sooperlooper, etc.. I have been using avlinux in the studio for years prior to a few days ago
<lfam>kristofer: Not sure, but rekado may have advice
<rekado>kristofer: for studio use I don’t think a realtime kernel makes any sense.
<rekado>the consensus seems to be that JACK is sufficient to get really low latency.
<rekado>if you want to get a realtime kernel anyway, though, it shouldn’t be too hard with Guix.
<rekado>you would need to create a package that inherits from linux-libre (maybe pick the LTS version to avoid rebuilds) and modifies the source field to add the rt patches.
<rekado>civodul: oh, I’ll try to fix it. The version I upgraded to is the last to support Python 2.
<lfam>In order to avoid rebuilds I would also specify the version in your custom package. The kernel configuration should remain valid within a release series, so you don't need to update your custom kernel each time Guix's linux-libre package is updated
<kristofer>rekado: do you use sooperlooper? how does it perform without the RT kernel patches?
<rekado>kristofer: I’m not using it. I tried it many, many years ago, with Ubuntu Studio which did use an RT kernel.
<lfam>I enjoyed sooperlooper immensely on OS X about 10 years ago. Great memories :)
<pkill9>my idea is for the user to add trusted people, and those trusted people sign the magnet link, so that anyone else who builds that derivation can distribute it (or parts of it) via torrent without the user having to add their key to trusted users.