<ryanprior>I guess I'm lucky that I haven't had this happen before that I can recall, but damn now I know I can't trust it. I'll either figure out a way to constrain its memory & cpu usage or I'll just run it in a VM and offload to the host system.
<ryanprior>Guix apparently interprets "use all the cores" as "you have permission to peg every core to 100% at highest priority, indefinitely" which has gotta change.
<bdju>yeah using the machine can become hard while updates are running
<ryanprior>It wouldn't accept hardly any keyboard input even
<bdju>well, without quotes it either worked or bombadillo didn't fail this time
<bdju>just ran upgrade without holding back anything but with --dry-run on the end and it says bombadillo and syncthing would upgrade, so I think it worked
<bdju>I will maybe use single quotes in the future just to be safe, though. glad to know that would work
***catonano_ is now known as catonano
<apteryx>ryanprior: you're basically complaining about how linux sucks at handling resource exhaustion (that's not really Guix specific). That's why boilted-on solutions such as earlyoom exist (hint: there's a service for it in Guix, and it'll save you more than once).
<ryanprior>I'm definitely looking into more of these things! But Guix is not entirely faultless. dpkg has never soft-locked my system in 12+ years of updates.
<apteryx>dpkg doesn't build anything from source to install packages on your system :-)
<ryanprior>True but beside the point. Running a normal routine guix command can soft-lock your system, and that's an implication of Guix's design
<apteryx>I think the best way to handle this for users would be to allow a way to updates via substitutes only; some guix pull that'd use the knowledge from the Guix data service to pull the commit which has 100% substitutes coverage of you package collection, then the updates would be entirely binary.
<apteryx>there's not much you can do when a package such as webkitgtk+ wants 12 GiB of RAM to build.
<ryanprior>To get even more sophisticated, we could gather information about typical build times of packages and upgrade without substitute for packages that only take a short time.
<kozo[m]>I ran into the same issue and as pkill9 said, I will add cores=total-1 to prevent that brutal softlock
<kozo[m]>also running a local publish server has helped a ton
<ryanprior>Whenever I upgrade I do a dry-run first, and then I add --do-not-upgrade flags for big packages if it wants to build them. That's not very user friendly, and it's a buzzkill to have to describe that process to people.
<ryanprior>And in this case today I neglected to do that (I actually did the dry-run but misread the output) and then couldn't even back out.
<ryanprior>Defaulting to cores-1, or to only upgrade from substitutes, sound like reasonable options to avoid that happening.
<apteryx>default to cores-1 would make builds slower for everyone, while not guaranteeing to prevent resource exhaustion, so I'd much prefer option #2. It seems the technicalities already allow for it, we just need someone motivated to implement it. You seem to be that person ;-)
<apteryx>I agree the user experience is not the best right now unless they have a good grasp of the build farms and other details (e.g., guix pull now and update in 12 hours will probably allow me to get better coverage)
<ryanprior>I would love to implement #2. My Guile knowledge is pretty low-tier, and my guix data service knowledge is pretty bottom basement (I know it's run by cbaines, written in Guile, and uses Postgres, that's about it)
<vagrantc>since "guix pull" is essentially a codified list of all available software in theory
<apteryx>as I wrote it could be smart and use your user and system profile when you don't hint at anything else
<apteryx>(and it could also allow you to pass extra profiles or manifests to get these included in the coverage)
<vagrantc>seems more like something that guix weather would do
<vagrantc>yeah, i'd think you'd want manifests or something, but implicit is not generally very guix ... being a functional package manager :)
<vagrantc>but you'd get interesting quirks, such as when packages disappear or are renamed (although there's some mechanism to check for renames)
<apteryx>vagrantc: I was thinking of implicit upon using 'guix pull --with-coverage', to make it as easy as possible for users. Not everyone manages their user profile with a manifest.
<vagrantc>yeah, i'm pretty ad-hoc about using manifests
<vagrantc>it doesn't seem appropriate for guix pull, though.
<apteryx>since you need guix at a specifically choosen revision to update with 100% substitutes coverage, it seems natural to provide a UI on 'guix pull' to do so, since git pull is about fetching a installing a Guix revision.
<vagrantc>apteryx: if you're itching to implement, probably worth discussing on the list ... possibly even a bug report already about that sort of thing
<apteryx>sure, perhaps guix pull could rely on the internals of 'guix weather'. That's an implementation detail. I was thinking in terms of UI only.
<xelxebar>Oh nice. I've had guix cripple my (~8 yo) laptop several times---X stuff all gets paged out, etc. Finally decided to spin up a build offload vm just to keep from hitting the oom kiss of everlasting wait.
<apteryx>xelxebar: also consider using the earlyoom-service-type
<apteryx>it removes the everlasting wait from the equation ;-)
<apteryx>congrats for the successful offload setup! Did you hit some bumps configuring it?
<xelxebar>apteryx: Cheers. Just read the discussion above and saw mention of earlyoom and memlockd.
<xelxebar>apteryx: Thanks! Offload setup was pretty straightforward. It went almost without a hitch. For some reason guix offload test was failing to start guile at first.
<xelxebar>I fiddled with the config a bit, but after returning the settings to what I had originally, it just started working for some reason :/
<wleslie>does anyone know how to generate a Makefile.in within newlib? automake says "error: support for Cygnus-style trees has been removed"
<wleslie>cygnus being the group that wrote newlib before being acquired by hedrat
<apteryx>xelxebar: did it fixed itself without intervention (the guile not starting issue)?
<apteryx>ah, just read your last message, seems it fixed itself automagically, eh
<apteryx>there's a transient issue where sometimes offload complains about guile not found, perhaps that's what you had
<wleslie>or maybe... can guix give me an older version of automake? the package list doesn't say anything about different versions, and only includes 1.16.2
<xelxebar>Anyone here a neovim user? How are you providing the python(2) "neovim" module(s)?
<apteryx>wleslie: if guix show automake doesn't list many versions, you'd have to git log --grep='gnu: automake', pick the guix revision with the version you like, then 'guix time-machine COMMIT -- guix environment --ad-hoc automake'
<refcfar>Hi, I'm exploring Guix (as a current Nix user) and am not terribly well-versed in the arts of Guile/Scheme. How do I write a by-label getter function for a list of records in Guile? Use case is to list all `%desktop-services` by name (or something).
<civodul>refcfar: hi! it may be that "guix system extension-graph /your/config.scm | xdot -" will give you the info you're looking for
<civodul>otherwise, if you use Emacs and Emacs-Guix, there's M-x guix-default-services
<civodul>last, you can run "guix repl" and do (map (compose service-type-name service-kind) %desktop-services)
<refcfar><civodul "last, you can run "guix repl" an"> This I think is what I was looking for. I wasn't aware of `guix repl` (I just ran `guile` and then a bunch of `(use-...)` like it's done in the config.scm file), thanks.
<mfg>so i now found out why gdb doesn't load debugging symbols even though it's configured to look into the correct path... It seems the .gnu_debuglink that gets embedded into the object files point to inaccessible locations...
<mfg>yesterday i looked into how the .debug file genreations works in guix and where it is placed but i couldn't find out how it works...
<mfg>so i thought the cmake build system supports debug outputs, it creates a separate debug output yes and it conatins all .debug files, but those are either created after the debugging symbols have been stripped from the object files or the debug files themselves are also stripped. The resulting .debug files don't conatin a .debug_info section.
<zimoun`>rekado_: Hi! I was giving a look at the texlive package, trying to understand why the PDF table of contents is wrong for French and German, at least. And the big texlive does not have source. Where does it come from so?
<Zambonifofex>Hello, Guix! I’m currently getting an error trying to use a Git repository I set up from `channels.scm`. The error I get is `invalid content-type: 'application/octet-stream'`
<Zambonifofex>Note that the only file Guix seems to be trying to fetch is `info/refs`, and although it *is* sent as `application/octet-stream`, it contains the expected contents. It works with `git` itself, even!
<Zambonifofex>It would be (really) inconvenient for me to change the content type, so I was wondering if there is any way to get it to work as is.
<divoplade>Zambonifofex, guix uses libgit, not git. There are a few things that git supports and that libgit does not. For instance, you cannot have your git repo as a static "simple" repo and have guix pull it, you need the more complex setup with CGI and stuff
<zimoun`>Chinesse speaker here? What is the texlive and co to get the correct fonts?
<roptat>civodul, I tried using texi->stexi on my manual, but first it fails with (#f "Unknown command" detailmenu), and after removing that, with Wrong type argument in position 2 (expecting character): #<eof>
<civodul>roptat: yeah the parser is not capable of handling whole documents, but not far from it i think
<civodul>so i think it would make sense to invest time in reaching parity with the "official" parser
<jackhill>wondering about https://issues.guix.gnu.org/43795#2 (stockfish). Do we have a policy on pre-trained neural networks? It does't look like source to me, but I also don't know of another way. This machine learning stuff puts free software in an unfortunate place.
<hadi>Hi guys. I'm a trisquel user. I heard about GNU/Guix. I researched it on the internet but did not find out exactly what it is. Is it a GNU distro or a package manager!? will you please tell me. Is it worth installing? what it is exactly? thanks...
<vagrantc>hadi: it's a package manager, and also a distro
<vagrantc>hadi: the package manager can co-exist with other package manages on other distros ... or you can install a fully guix system that only uses guix packages
<hadi>vagrantc thanks for reply. Is it easy to install? Is the environment graphical?
<rekado_>zimoun``: re fonts: that depends on the variant of TeX you use.
<zimoun``>jackhill: it is still an open question… well AFAIK, no policy on pre-trained neural networks.
<vagrantc>i'm mostly familiar with the guix commandline ... i think there's a emacs interface for it...
<rekado_>lualatex has a font loader that allows you to use your existing OTF fonts
<rekado_>xelatex has something similar, but weirder
<vagrantc>hadi: there's a script you can download that will install it ... haven't used it much myself
<rekado_>pdflatex doesn’t, so you need special font metrics and all that stuff
<rekado_>I can’t say I know this stuff well at all, but I know that fonts and LaTeX are frustrating.
<rekado_>it’s especially bad in the modular TeX Live because I’m sure we’re missing something somewhere.
<rekado_>I’m still trying to fix an important lualatex package so that we can actually recommend using it.
<zimoun``>rekado_: thank you for explaining. For the PDF manual, by default it currently uses pdftex, right? LuaTeX would be nice to have.
<jackhill>zimoun``: yes, and I see why there isn't one. It's not clear to me what the right policy should be.
<zimoun``>and yes we are missing something somewhere…