IRC channel logs
2023-05-25.log
back to list of logs
<rekado>I have no details yet, but would any of you be willing to do a workshop? <civodul>there's the possibility of a Guix-HPC event in Montpellier (South of France) in Oct. <civodul>yet to be confirmed, but that would have to be taken into account in one's agenda <rekado>yes, at the MDC in Berlin-Buch (northern tip of Berlin) <PurpleSym>Hm, the “building package cache...” phase of Guix pull is consuming an absurd amount of memory (~80GB) during guix pull when adding guix-cran 😕 <civodul>rekado: are you planning to be there? <civodul>can you send a bug report, including the size of the resulting .go file? <PurpleSym>I can try if it actually finishes. How can I find the resulting .go file, civodul ? <civodul>3.0.9 improved on assembler/linker memory usage, but we still find ourselve with one or two copies of the ELF file in memory :-/ <civodul>the resulting file is ~/.config/guix/current/lib/guix/package.cache (or similar) <rekado>civodul: yes, I was approached by one of the organizers. They are interested in a workshop or talk. <civodul>rekado: excellent, i didn't know they'd started contacted people <PurpleSym>civodul: It finished after about 30 min. Which file’s size do you need in the bug report? <civodul>PurpleSym: the size of the package.cache file <civodul>i pulled guix-cran on my laptop a couple of months ago, and it has "only" 16G of RAM <PurpleSym>Well, RSS cannot be more than system memory, which is just 64G. But the system was paging like hell. <PurpleSym>Actually, it “finished” through the hands of the OOM killer. And no package.cache was ever written to disk. So I’m guessing guix search will be quite slow without that. <civodul>we could implement an proactive OOM strategy (i.e., leave out the cache when there are too many packages) <civodul>'guix search' doesn't benefit from the cache <civodul>'guix package -A' does, likewise for lookups by name <zimoun>that’s an issue for my eyes. ;-) <rekado>I think it’s because we provide fira sans, but only in the bold variant <rekado>the second is the rule for “.settitle, .top, .chapter, .section, .subsection, .subsubsection” <rekado>this affects not just the headings but all sections <civodul>so first we should add a second @fontface for the regular weight, right? <zimoun>civodul: how many time is the website requiring for being rebuilt? <civodul>that doesn't make any difference though <zimoun>fast, nice. I was asking because I do not see any difference after refreshing. Propagation to some cache? <rekado>the “.settitle, .top, .chapter, .section, .subsection, .subsubsection” rule should be disabled <rekado>or at least the “font-weight: bold” line. <rekado>because this applies to all elements in those sections, not just the headings <civodul>still i wonder why it suddenly went wrong <rekado>it’s a difference in generated HTML <rekado>the new HTML wraps sections in divs <rekado>and those divs have the .subsection or .section classes <rekado>previously the HTML was not as structured; just tag after tag <rekado>and the only things with .section or .subsection classes were headings <rekado>so for the new HTML the rule is too broad <rekado>oh dear, just found a special snowflake bioinfo package: needs Python 2.7 … and Rust. <civodul>Python 2.7 and Rust, that's quite an unusual mixture of vintage and cutting-edge software <zimoun>thanks rekado and civodul. My eyes are now happy with the manual. :-)