***jonsger1 is now known as jonsger
<g_bor>Yesterday was the deadline to file Outreachy applications. We have the next deadline on intern selection on the 12th. <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... <efraim>i'm working on updating kodi to 18.0b5 *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) <roptat>vaab: have you run guix gc recently? <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. <roptat>not sure what the .lock file is, sorry :/ <roptat>but the issue could be that the substitute failed to record its references properly, so you can try to remove it from the store (guix gc -d $(realpath $(which bash))) and rebuild it locally <rekado>the lock file is created when a build is ongoing. <roptat>at least that was suggested for that bug yesterday <vaab>roptat: this similar report was on which medium ? I'm interested to read it. Any general suggestion to where to look for it would probably save me some time. <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... ***kensington_ is now known as kensington
*civodul found that hplip is blob-riddled <efraim>civodul: yeah, I saw the email, I'm going to check what debian is doing <efraim>vaab: I don't think there's anything wrong with the lock files, I just don't know what they're for <civodul>efraim: nice, that's probably better than reverting <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 <vaab>g behind the hood to see how far I can get. <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 <vaab>g_bor: I'm afraid that the issue I have is related to my special setup. I just need to find exactly what is happening to see if I can move forward. <g_bor>I see, and this is reproducible? <vaab>Does ``guix pull`` call the garbage collector at some point, or could it delete packages in the store ? <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 <civodul>i decided to go ahead a fix a bunch of annoyances we had noticed <civodul>rekado: i was planning to deploy it on berlin, but i think you're currently working on it, right? <civodul>snape: you were quick to deploy it :-) <snape>civodul: I have an efficient workflow <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> of guix mainstream workflow. <civodul>rekado: in the working tree on berlin, we're using linux-libre 4.14; do you remember the reason for this change? <rekado>civodul: it’s because that one kernel module disappeared in later versions <rekado>instead of trying to figure out what’s up with that I stuck with an older version of linux. <rekado>I forgot the name; I want to say “scchp”…? <civodul>rekado: yeah something like that :-) <civodul>i forgot the end of the story, the module is now built-in isn't it? <rekado>yes, but I think Mark changed the kernel config in the end so that it is built as a module again. <rekado>so using the latest version should be okay now. No need to adjust anything else. <civodul>actually from current master i still get: kernel module not found "shpchp" "/gnu/store/6mf4kwp9ck2fi32mq34v67axqhlyw7q1-linux-libre-4.19.1/lib/modules" <roptat>ah, that's probably the reason why I couldn't install guixsd on a server I have <rekado>Mark said that commit fe73352e8073ea0a0e6f6b5591f24395671998ab should have fixed this. <civodul>right, fe73352e8073ea0a0e6f6b5591f24395671998ab says it's built-in <civodul>so i can try removing that module from initrd-modules and use 4.19 <civodul>then we can reboot whenever is convenient for your rekado, in case you need to reboot it <roptat>where is berlin configuration again? <rekado>civodul: sounds good. You can reboot any time. <civodul>(the only reason to reboot is to make sure the new kernel works) <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>I'm getting a failed build for raw-initrd.drv, upon inspecting the build log, it says ERROR: in procedure delete-file permission denied <mbakke>vagrantc: What is the complaint? <mbakke>kristofer: This bug was fixed very recently, a `guix pull` should solve it. <vagrantc>mbakke: from memory, something like "you should consider running guix pull to make sure guix is up to date" or so <mbakke>vagrantc: Sounds like you have another Guix in PATH before `~/.config/guix/current/bin`. <vagrantc>mbakke: it definitely reports the version i'm expecting is pulled <vagrantc>mbakke: next time it happens, i'll try not to glaze over it and actually troubleshoot a bit <apteryx>vaab: wrong, libssh supports parsing .ssh/config <apteryx>but guix pull problably just uses http, not ssh (nor guile-ssh) (haven't read the sources) <vaab>apteryx: ah good news ! :-), thanks for the info. <reed>Hi all. I am on a relatively fresh install of GuixSD. I used the lightweight desktop config file (with i3). I just installed icecat and the text isn't rendering. Everything is a square <reed>ahh, I see. Is there a reason the font packages aren't an input to the icecat package? <mbakke>reed: Different users have different preferences :-) besides, adding all fonts to IceCat would be prohibitively expensive in terms of download size. <mbakke>civodul: Do you think it's okay to start a core-updates evaluation on Hydra? <efraim>I have a building hplib-minimal, now to test build hplib <efraim>i also have a working kodi@18.0b5 <efraim>ok, i'm cheating and testing hplip using python-pyqt-without-qtwebkit, I'd rather not build qtwebkit *rekado replaces more source URLs of the type github.com/foo/bar/archive/v1.2.3.tar.gz <bavier>efraim: cool, new kodi, thanks for working on it <thorwil>what does it try to do right after printing "1 package in profile"? <civodul>perhaps we should just remove this python2 variant? <civodul>thorwil: oops, i've just pushed a fix, thanks for the report! <civodul>i introduced the bug a couple of days ago <civodul>what happens here is that 'guix pull' crashes just before printing the list of new/upgraded packages <civodul>but it has already done the actual work <civodul>so the crash is harmless, but terribly ugly <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>it may be useful for live performances. <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 :) <lfam>I remember it worked fine with JACK <efraim>i pushed the hplip changes, i'll try to finish up kodi tomorrow <civodul>rekado: could you restart mumi on berlin? <rekado>I’ll continue work on mumi soon. <rekado>And then it’ll get a proper service. <rekado>looks like a message returned by debbugs has no subject and so there’s a comparison between a string and #F. <civodul>maybe that's because it's a merged issue? <rekado>we need to remout /gnu/store after booting linux. <rekado>I wonder if I could just declare a file system to be mounted at /gnu/store, without the “boot?” flag. <civodul>i was monitoring disk space because i felt it was going to happen <civodul>i didn't expect it to happen this soon <civodul>why do we need to remount the store? <rekado>but we cannot mount at boot time because the devices only appear after Linux has booted. <civodul>you mean they appear after udev has started? <rekado>I don’t know exactly when they appear, but I know that they are not there in the GRUB console. <civodul>i wonder if the intertubes could be of any help, but i guess you already tried <rekado>these are two HBA cards: LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02) <rekado>they use the mpt3sas kernel driver. <rekado>it was suggested that maybe they are not visible in GRUB is because we use legacy boot mode <rekado>I don’t know if I can just change this now. <mbakke>The ungoogled-chromium package from AUR does not actually apply any of the ungoogled patches, IIUC. <mbakke>Only unbundling and domain substitution. <pkill9>out of interest is anyone working on peer-to-peer distribution of substitutes? <mbakke>pkill9: I think roptat has been working on a BitTorrent implementation. <rekado>civodul: we have about 6GB left on berlin.guixsd.org right now. <rekado>civodul: I fixed the 500 error on issues.guix.info <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. <pkill9>it would be cool if that is possible <pkill9>I assume it is as long as the package is fully reproducible bit for bit