IRC channel logs
2024-06-12.log
back to list of logs
<apteryx>sneek: re the too many opened files when processing the man-db hook with zstd compressions; I don't remember seeing that one <wolfdog>since attempting to run a virtual machine for an aarch64-linux system ends up failing to build a `linux-modules' derivation because `linux-libre-arm64-generic' does not have a `cirrus' module <wolfdog>i guess it could be in general expanded to better support arm, since there's only a few special cases for running riscv64 virtual machines <wolfdog>I'll see if I can submit a patch soon. <freakingpenguin>wolfdog: I've noticed that services don't seem to have a way to confirm that the kernel has X config option enabled. There's probably some tuning that could be done there. <freakingpenguin>It's particularly annoying when using -generic kernels. They have more options enabled for SoCs but don't have all the options services expect. <meaty>when you "make install" a clone of the guix repo, does that tree get treated exectly like the read-only one the OS normally uses <meaty>i.e. it gets updateed with "guix pull", "guix edit" pulls it up, you can remove the old one from the store, etc. <meaty>the manual is a little ambiguous <mange>I don't know about "guix edit", but I'm pretty confident that "guix pull" won't update it. It will install a new version of guix into ~/.config/guix/current which is a symlink into the store. <brendn>What is the best way to access private git repos in a package definition? Right now I just have a private access token in the url but I think it's typically recommended to be passed in the headers. Is there a way to specify headers used with git-fetch? <wigust>brendn: I think the best is put under a self-hosted git, e.g. cgit service, which can be protected from the internet with generic tools and make them real private :-). AFAIK git-fetch cannot, unless you would like to extend it :-) <andreas-e>Hello! Can anyone tell me how to connect to the cuirass database on berlin? With this information, I might be able to answer the question on the types of queued builds I just asked on the mailing list. <dariqq>Is there more info somewhere why qa failed on applying my (rather simple) patch? It works for me using "mumi am" without prolems <cbaines>dariqq, there should be some information there on the page. Can you link to the issue? <cbaines>dariqq, if it's not applying to the latest commit, it should retry <cbaines>I've added some extra information about the base commit being used in any case <dariqq>cbaines: It seems to be still failing, not sure what the problem is. <cbaines>well, now the message includes the base commit, it's clear it's too old <dariqq>lets hope it will sort itself out once it catches up :) <juli>DO NOT go into the Guix Matrix right now some literal Nazi posted snuff/gore in there and is spamming <juli>for those to whom it is relevant, eientei.org are known bad actors, Nazis of the channer troll variety <cbaines>dariqq, the data service is setting cache-control headers incorrectly, so maybe that's related <dariqq>cbaines: Now it was able to apply the patch. I guess it caught up? <jfred>I don't suppose there's a way to run `guix lint` recursively against a package and its dependencies? Was just thinking it'd be useful to be able to run the cve checker against that set of packages. There's an argument that lets you pass an expression but the help text reads like it only wants a single package as the result rather than a list <gnucode>hey friends! You know how guix says, "Your guix installation is 5 days old. You should run 'guix pull' to get security updates." <gnucode>It would probably be a good idea for it to also say (if running on a foreign distribution), "Also update your guix daemon via <gnucode>'sudo -i guix pull && sudo systemctl restart guix.daemon' <vagrantc>depends on how you are running it on a foreign distribution... <sneek>vagrantc, you have 1 message! <sneek>vagrantc, rekado says: Thanks for the hint! I've run it manually and successfully authenticated 74k commits. (I ran "guix git authenticate -k keyring 9edb3f66fd807b096b48283debdcddccfea34bad BBB02DDF2CEAF6A80D1DE643A2A06DF2A33A54FA".) But the error on "git push origin master" remains. <vagrantc>rekado: i guess ... i would manually remove that from your .git/hooks and file a bug? <vagrantc>although not sure what added it in the first place... <vagrantc>i admit i actually git push from a non-guix machine after having what i am pushing on a Guix System machine <vagrantc>slightly error prone, but i am fastidiously careful around it <gnucode>vagrantc: what do you mean it depends? "guix pull" on a foreign distribution does not update the guix daemon right? <vagrantc>gnucode: correct, but you do not always need to update the guix daemon ... e.g. using the debina-packaged guix daemon is possible. <vagrantc>in which case, the proposed instructions would not even work <gnucode>how often is that debian packaged guix daemon updated I wonder. And also, how about this then...After a user runs guix pull, and if it's a foreign distribution && the foreign distribution is not debian (if it is debian see if apt show that the guix daemon is packaged), then output to the user "please do this up update the daemon 'sudo -i guix pull && sudo systemctl restart guix.daemon" <gnucode>I reason I mention this is that I am running guix on a foreign distribution...and the guix daemon is really outdated. sudo -i guix pull doesn't work. So I have to somehow build guix from source to update the daemon...as far as I can tell. <vagrantc>gnucode: almost never updated ... did do an update for the recent security issues <vagrantc>gnucode: basically, those instructions will only work if your instructions match your system ... it would need pretty sophisticated logic to not emit those messages needlessly or even eroneously <podiki>the guix daemon isn't updated so often i think; the recent ones have been for security issues and notified via guix pull, mailing lists, and website <podiki>in the past few years I can only think of security issues (recently) and maybe once for what types of downloads/compression was supported (after very long deprecation period)? <vagrantc>heh. pretty hard to "git log --grep=guix" in a useful way to find exactly which commits. <podiki>maybe look for changes to C files only :) <vagrantc>git log --grep='gnu: guix:' works pretty well to see how often it was updated <podiki>does that always include the daemon itself? or it is separate from the guix version? <vagrantc>there are a handful of commits that match that aren't relevent, but overall it tells you which commit it updated to, and goes affect the guix-daemon that you would get from the "guix" package <meaty>is there a way to transparently make the main guix tree the OS uses an editable git clone <meaty>i.e. "guix pull" still pulls the latest from the remote, "guix edit" allows editing, etc. <civodul>meaty: unfortunately that’s not possible so far, but it would be great!