***ykaelig is now known as yann-kaelig
<sadiq[m]>Hi. can someone update the glib package to 2.54.0 in staging branch? ***Piece_Maker is now known as Acou_Bass
<fredmanglis>After running a `guix pull` and `guix package --install=guix` as root, the issues I was having with running update/install and pull as a normal user have disappeared <fredmanglis>I also pointed the systemd service to the newer one, using the same ideas in the manual <fredmanglis>It isn't exactly explicit that you need to do this in the manual: should one need to do this? Should it go into the manual? <efraim>sneek: later tell ng0 when I `git fetch' your guix repo my terminal prints in German: remote: Zähle Objekte: 140, Fertig. <efraim>looks like our binutils is safe from CVE-2017-14729 <rekado>ACTION just received new servers and 60+TB storage for Guix <rekado>tomorrow and next week we’ll begin installing the new hardware; will also add more build servers to berlin.guixsd.org <rekado>but first we need to clear out the racks <jonsger>rekado: nice. what kind of hardware? <rekado>it’s storage + storage head, and an extra build server (Dell PE R630), so that at least one of the build servers is covered under warranty <rekado>all the other build servers are old Sun hardware; I think we can go up to 30 nodes for berlin.guixsd.org until we run out of space. <rekado>but we also have additional racks with extra nodes that are currently unused. But before spreading to other racks I’d like to have a sane way to manage GuixSD on all these servers. <thomasd>rekado: I still wanted to say that berlin.guixsd.org really improved my life :D <htgoebel>thomasd: Yes :-) What's missing now is some /etc/guix/substitutes config file, so I do not need to pass this every where <thomasd>htgoebel: you can configure it in your system config <sadiq[m]>Whom should I ping to get glib updated to 2.54? The dependencies are too huge, so I fear touching it. <rekado>yes, you can make this a daemon option. <rekado>sadiq[m]: has it not been updated on the core-updates branch yet? <htgoebel>thomasd: I' not using guixsd, but guix on a foreign distro. <rekado>erm, above I meant: “you can pass this as a guix-daemon option” <rekado>sadiq[m]: whenever “guix refresh -l” reports a very large number of packages that would be affected by an update we perform that update on the core-updates branch <htgoebel>rekado: ACK, but this hides the config in come .service file :-( And this feels clumsy <rekado>sadiq[m]: for a medium-sized amount of packages affected by an update we push the upgrade to the staging branch. <htgoebel>Any recommendations how to speed up the compile-test cycle for *huge* packages? <htgoebel>I need to work on the test for kwin, but compiling takes 20 Minutes (or so). Too long for testing every change of the check-phase. <sadiq[m]>I have a few GNOME packages to be updated, but depends on glib 2.54. <rekado>htgoebel: guix package -K foo; cd /tmp/guix-build-foo…; guix environment foo; make check <htgoebel>rekado: I already do something similar. This works find for "simple" setups. But as soon as I need to add dependencies, it become complicated. E.g if I want to try dbus or shared-mime-info, which require additional config vars. <rekado>htgoebel: I forgot to mention “source environment-variables”; <rekado>all the vars that are set at build time are recorded there <htgoebel>rekado: I just notice that you are using "guix environement". This might do the trick. I'm using plain bash <efraim>how many of the old sun machines are sparc and how many are x86_64? <thomasd>htgoebel: if that still doesn't work (I had this problem for kdevplatform: tests run in the "guix environment", but not in the build environment), you could also 1) build the package with guix environment 2) create a new package with (source (local-file "your/local/build" #:recursive? #t)) 3) in this new package, only run the test phase. I haven't actually tried this yet, but it should allow quick experimentation with the test phase <thomasd>(environment variables etc). This was my next idea to finally fix those kdevplatform tests <htgoebel>thomasd: This is a cool trick :-) I'll try that <rekado>texlive-union should behave the same as the big texlive-texmf package, but it doesn’t <rekado>with texlive-union it builds fixed-size font files in $HOME, but with texlive-texmf it does not. <rekado>it shouldn’t need those files — they are not part of texlive-texmf, and all variables are set such that it can find the metafont source files as well as the compiled tfm files. <rekado>I really don’t like texlive and how it is managed; confusing perl scripts, plain text files as databases, automatically run tools triggered by kpathsea… <htgoebel>thomasd: For the trick with the new package I assume you deleted phases configure and build? <thomasd>htgoebel: as I mentioned, I didn't actually try it myself yet, but yes, I'd just run 'install and 'check (for those KDE packages which will only run their tests after every object is in its target location) <rekado>looks like even the new emacs 25.3 leaks memory in shell buffers. <rekado>since version 25.1 shell buffers leak memory as they accumulate output. The memory is not freed when the buffer is killed. <jlicht>I found a small typo in the commit that added tklib; the description contains an unclosed @code{tooltip, with no closing } <jlicht>currently I am not in an environment where I can fix this, so if someone else could pick it up, that'd be swell <Apteryx>Ah, no more disk space. Time to migrate to latex-minimal that rekado worked on! <Apteryx>rekado: Is it really *leaked* or does it just accumulate because of not truncating buffer history? <Apteryx>I noticed high memory usage by Emacs as well, but it's already slower than xterm so I just went back to that. <Apteryx>(at least when doing a guix system reconfigure or guix package -u . ;) <mekeor>do you have to install ghostscript in order to print with CUPS? <mekeor>i think the important part is "sh: gs: command not found" <mekeor>well, i guess it's because the PPD file which i downloaded (from openprinting.org) contains the line "*FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -dNO&&" <Apteryx>Is there a way to find the git commit corresponding to my current 'guix pull'd guix? <Apteryx>I'd like to work in my ~/src/guix tree which matches my 'guix pull'd version. <efraim>If you look in the cache will it tell you? <Apteryx>So I went there: ~/.cache/guix/pull/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq$ and issued 'git log -1'. The result is: a9925374b0691eb551b0383ec88f110fc54f9fae, which makes sense (I guix pull a day or 2 ago). <nickdee>Has anyone reported issues with guixsd 0.13.0? <nickdee>i tried running it twice last night per the instructions on the site, but it failed both times in different places <nickdee>the first time, it couldn't build ghostscript because it was missing a few .o files <nickdee>the second time, it continued past that but couldn't install grub because it couldn't find mkinfo.sh <nickdee>(at least, I think that was the file name, it was some mk*.sh file) <nickdee>if folks do have workarounds, i'm happy to perform them, otherwise I'll try to investigate later this week. <nickdee>got to run, but I'll check the logs later. thanks for your help #guix! <noob>hello i need to install grub with blockchains i have use --force option but now the computer prompt to grub rescue <noob>file normal.mod not found <Apteryx>uh uh. Throw to key `parser-error' with args `(#<input: string 37f9770> "@item must be within a table environment" code)'. This when doing 'guix package -s texlive' <Apteryx>probably due to the missing } spot by jlicht <niebie>Is it strange to anyone else that the libreoffice package definition doesn't have any font packages as propagated-inputs? <niebie>I had to install font-gnu-freetype-ttf in order to get most things to display anything other than the rectangles used when a font is missing <niebie>I would think that adding this package as a propagated-input would smooth over installation <wigust>niebie: I asked here about similiar issue with ‘desktop-service’. And the responce was that we don't need to require fonts in ‘desktop service’. I guess the same with packages. <wigust>So, fonts need to be in your desktop environment service as I understood. <niebie>The difference for my case is that libreoffice is non functional without this package installed <niebie>The menus themselves are missing fonts, which means you just guess at what buttons do <niebie>I understand why you wouldn't propagate for desktop-service, since that makes no assumption on the system you are using to login <niebie>for instance, I use dwm and don't need that font package <niebie>but since libreoffice is usable in any desktop and requires this package to render its menus, i don't see why propagating would be bad <wigust>niebie: If you make a package with ‘pack’ for another distro, you don't need fonts to be included. <rekado>Apteryx: it actually leaks. Killing the buffer does not free memory. <wigust>niebie: And as I remember ‘font-gnu-freetype-ttf’ required for other graphical applicatoins too. So it's first thing after installing GuixSD without desktop environment service. <niebie>LibreOffice is the only application I run that required it to function <niebie>icecat needs it for some particular web pages, but the gui works without it <niebie>The three graphical applications I have installed right now are emacs, icecat, and libreoffice. For emacs, it doesn't need this font package at all. For icecat, it improves some webpages by having it. And libreoffice needs it for all menus. <wigust>I think ‘lightweight-desktop-service’ for Window Managers would be great. <wigust>Instead of propagating packages with fonts. <niebie>So the main argument I heard against this is that you don't want to include the fonts when packaging libreoffice for other systems <niebie>OK. I'm going to email the guix-devel mailing list to see what others think <niebie>Or maybe this is better in guix-help, not sure <wigust>niebie: Also there was an issue with icons in GTK+ applications and dialogs. I installed Adwaita icons manually. So, again instead of propagating it everywhere in GTK+ applications, just make a ‘lightweight-desktop-service’. <niebie>wigust: To me it makes sense that if you want a 'pack'ed package to be completely self contained that fonts would be included <niebie>wigust: from what I understand, that is their main use - to create a completely standalone, system independent package <Apteryx>is using gexps already supported in build package definitions?