<mbakke>NieDzejkob: haven't tried, I think the big 64-core Berlin nodes use 30-40 minutes, so bayfront maybe two hours? <ss2>nckx: thanks! Got that eventually. <mbakke>civodul: oooh, great, I'm sure many newcomers get confused by that whole build plan *mbakke wonders if it's time for a Guix configuration file to control things like verbosity without needing the CLI argument <NieDzejkob>(also discussed before: --allow-downgrades for guix pull, git-like aliases such as guix env) <mbakke>ah yes, GUIX_BUILD_OPTIONS will likely work for now <civodul>mbakke: yeah i realized i got used to scrolling over pages of somewhat useless stuff <roptat>guix is being weird, it's taking a lot of time doing apparently nothing <roptat>I just ran "guix build gnucash" and it prints nothing, taking no CPU *mbakke pushes the optimized chromium to somewhat paper over the performance issue ***nckx is now known as nckx-
***nckx- is now known as nckx
<mbakke>guix kind of gives it a run for the money :) <mbakke>I think we've uncovered more than a few Guile bugs <bhartrihari>Hello, I tried to install the texlive package recently but it failed because of lack of free space (apparently 8.2GB wasn't enough). It downloaded a 2.6GB archive which I don't want to download again. Is there a way to make guix gc not delete that archive? <bhartrihari>I mean, is there a way to run guix gc without deleting that archive? <jackhill>bhartrihari: The basic idea is that you can create a gc root for it. I think you can do that with `guix build -r keep-texlive-root $(guix gc --derivers /path/to/texlive)` <jackhill>I haven't tested that, but it will create a keep-texlive-root symlink that tells garbage collecter to treat the path as alive. <jackhill>yes. You can undo it by remving the symlink. <bhartrihari>Where is the symlink located? Or is there some dedicated command to delete that? <jackhill>ordinary guix package operation create symlinks under /var/guix/gcroot. This one would be treated just like those. I beleive it can reside anywhere the guix-daemon process can see it. <bhartrihari>So I would be able to delete it with a simple rm command, right? <jackhill>deleting is just a regular rm. For the automatic ones that guix package, guix pull and company create those commands also manage the cleanup, for for manually created ones, the cleanup is manual as well <jackhill>also, if you're tight on disk space, you may consider the texlive-packagename packages instead of the full thing to just install what you need. You may run into some remaining bugs with the "modular" texlive, but reports are welcome. <riddochc>Hi, folks. New to guix, been using linux a rather long time (23 years, feeling old now saying that) <riddochc>Still figuring things out here. Like what to do with the "profile contains conflicting entries for zlib", where both ruby and erlang want zlib 1.2.11 but there's apparently a different hash value in the path... <riddochc>Been puzzling over this one for a while. Somehow I thought that ruby and erlang could each use a different version of zlib, if necessary, but it doesn't *seem* to be necessary, but there's apparently some sort of conflict anyway. <jackhill>That almost sounds like a bug to me. I wonder if ruby and erlang really need to propogate zlib into the profle (I see that ruby does it directly, but for erlang it must be from one of its other propagated-inputs). <jackhill>Without the propagation, the different versions would be fine because they wouldn't conflict. Would you mind opening a bug report? <pkill9>yes they are conflicting because they are propagating inputs <jackhill>as a workaround you could use ruby and erlang in separate profiles <jackhill>at the very least, now you'll get to learn some more guix concepts :) <riddochc>Yeah? I notice the erlang package is relatively old... And sure, I'm willing to file a bug report, Oh, I hadn't tried out using separate profiles yet, so yes, good excuse for that. <riddochc>Reading a bit about propagated inputs now. If possible, I'd like to offer a patch with my bug report. <riddochc>Oh, an easier question... the docs say KDE isn't currently in guix, but it looks like there are a fair number of kde-based packages present when I search? <riddochc>There's plasma-framework, which looks like a pretty substantial portion of it. <jackhill>riddochc: it is a work in progress. I'm not sure how close we are. <jackhill>Hartmut has also one of the people doing a lot of the KDE work, so it looks like you share some interests. <riddochc>I was just looking at the erlang-related parts of the guix git repository. Seems I've got some code to read. And more documentation, I'm only about a third of the way through it... <riddochc>Whoever's working on the documentation: thanks, it's very appreciated, and a couple notches better than what I've come to expect out of most software. <nckx>riddochc: The docs, like the rest, are a group effort. Usually by the same people who submitted the code. Glad to hear you like them! I agree. <bavier[m]1>could we possibly get a scheme syntax highlighter running on savannah's cgit interface? <nckx>bavier[m]1: Ask in #fsfsys. <bhartrihari>Hi, doed anyone know which package (except texlive) provides the latexmk command? <bavier1>bhartrihari: the texlive-bin package does have latexmk; see e.g. ls $(guix build texlive-bin)/bin <dadinn>I removed the comments "-*-" from it not knowing what it was for, and now my Emacs doesn't recognise the correct scheme-mode for it... just figured I would need those comments back :P ***apteryx is now known as Guest7517
***apteryx_ is now known as apteryx
<zimoun`>civodul: I am a bit confused with the verbosity level and –quiet <zimoun`>civodul, ok. Well, I do not know if I like all the new defaults, especially if there is no spinner. <civodul>it's only the show-what-to-build bit that changes; spinners, progress bars, etc. from (guix status) are unchanged <civodul>mbakke: re lld-as-ld and all, doesn't it introduce a cross-module top-level reference? <civodul>nice blog post, thanks for sharing your work & experience! <civodul>the post sounds like your modest about your achievements :-) <civodul>i think you did great, esp. given the complexity of the software stack here <danjelalura>Thank you so much! :D I have to mention that cbaines has been a great mentor and that has made my experience even smoother. :) <civodul>danjelalura: heh, awesome, kudos cbaines :-) <civodul>unfortunately it's not sorted by date <bhartrihari>Hello, I installed texlive-base, texlive-latex-base, texlive-bin, and a few other packages but I need a format file pdflatex.fmt. Does anybody know which package can provide that? <bhartrihari>While invoking latexmk to create a pdf from tex file, mktexfmt gives me the following error "I can't find the format file `pdflatex.fmt'!". Is it a configuration error or does any package provide such a file which I can install? I'm using the modular texlive install. <zimoun>Naive question: I have a local definition and the local source. The package uses git-fetch. I tweak the source then I rebuild with "guix build -L . --with-git-url=file:///path/to/". But I need to commit my changes each time which is annoying. I remember discussion about that but I do not find it. Basically, I would like to do "guix build -L . --with-source=." for any source method. What is the trick? <DivanSantana>I want to use guix time-machine but install the outputs to a profile/directory. How can I do that? <zimoun>DivanSantana: guix time-machine -C -- package i foo -p /path/to/profile <zimoun>DivanSantana: modulo typing mistake. :-) <zimoun>I answer to my naive question: '--with-source=pkg=file:///' :-) <kmicu>bhartrihari: it’s possible that’s an issue with latexmk. Do you have a minimal *.tex file that reproduces the issue and you could share? <kmicu>(You could also try compiling without latexmk (you could find what that tools does by investigating latexmkrc file)) <bhartrihari>kmicu: actually the problem seems to be with mktexfmt which is run by kpathsea. I generated a few pdfs using latexmk recently so I don't think that is the problem. I should try and install the entire texlive package I guess. <bhartrihari>How do I delete unused packages from /gnu/store? I have 2 copies of ghc in the store taking up 2.6GB while none of my users have it installed. guix gc doesn't delete it, it seems. <efraim>it may be referenced from other generations of your profile <bhartrihari>Hmm. Can I mark it dead somehow? Any commands to find out what generations refer to them? <civodul>bhartrihari: you can try "guix gc --referrers /gnu/store/xyz" to find out what refers to this item <bhartrihari>Thanks civodul. Any way to delete an item and all its referrers? --delete option to giix gc doesn't work. <NieDzejkob>bhartrihari: If 'guix gc' doesn't delete it, then it means that there's a path from a GC root to the item. An operation like "remove with all referrers" is almost never the right idea, you want to delete the old generations of your profile that refer to GHC, instead. <NieDzejkob>if you installed ghc previously with 'guix package -i' or 'guix install', you're looking for 'guix package --delete-generations=1month', or something similar *NieDzejkob wonders if/when their messages will arrive, since Quassel doesn't really like the network conditions <bhartrihari>NieDzejkob: I have deleted all the old generations with guix package -d <civodul>bhartrihari: the spirit in general should be: let the GC do its job :-) <civodul>when it determines that /gnu/store/xyz can be deleted, it'll delete it <civodul>you can run "guix gc --list-roots" to make sure you're not retaining "GC roots" unwillingly <civodul>but apart from that, the GC should DTRT <mbakke>civodul: re #$lld top-level reference you're right, I guess we don't notice because nothing uses (gnu packages chromium) -- should I create a 'make-lld-wrapper' instead? <civodul>mbakke: yeah, somehow make sure 'lld' is not referenced from the top level <civodul>so wrap it up in a procedure or something like that <mbakke>it's a bit sad that we can't use gexps in package modules :-) do you think the circular module imports issue can be solved at the Guile level eventually? <civodul>we could come up with a trick to force gexps to delay references... ***dingenskirchen1 is now known as dingenskirchen
<civodul>hmm what's the include dir for Fortran? <civodul>in gfortran, we set CPATH for include/ <civodul>but then gfortran apparently ends up picking up all sorts of non-fortran headers <civodul>hello Kimapr_on_phone, how did it die? :-) <civodul>mbakke: in custom-gcc, we should prolly remove extra files, like C/C++ headers and libraries <civodul>we should just not build them in the first place actually <Kimapr_on_phone>There was a voltage jump and filesystem with my user dir died or something and now it fails to boot <Kimapr_on_phone>Would be real sad if it isn't as i don't have anything bootable but windows <nckx>Kimapr_on_phone: I recommend booting the Guix installer ISO or a similar rescue system. You can pass --repl on the kernel command line before booting for a spartan Guile REPL. <nckx>At least (I assume) you can use Windows to create said live/rescue system. <nckx>I think I've used a USB keyboard in the initrd before but honestly, you're not missing much. I don't use ‘spartan’ lightly. <Kimapr_on_phone>I used it in the bournish when root partition had unexpected inconsistency <Kimapr_on_phone>Is there a reason why usbmouse and usbkbd are in modprobe.blacklist? <nckx>Try an older generation. <nckx>They aren't the USB keyboard/mouse drivers you think they are. <nckx>There is no device on the market that does not work with the ‘real’ ones. <nckx>Kimapr_on_phone: TL;DR it's not a useful driver, the real ones are already in the initrd, these are blacklisted to prevent people seeing ‘usb keyboard’ and thinking they want it. <nckx>What you actually need is usbhid. <nckx>No. ‘Bournish’ isn't a separate thing, just a different REPL syntax for Guile. <nckx>It *is* the REPL. And Guile doesn't handle keyboard input, the kernel does. You won't be able to type anywhere. <nckx>Hence my suggestion to try an older generation's --repl, if you've typed successfully in the past. <nckx>It must be a regression either in the kernel/initrd or your system configuration. <bonz060>In guix, how do you look up documentation? I'm trying to figure out how `substitute-keyword-arguments` works... I've always relied on the online manual but for this case, I can't seem to find anything <nckx>bonz060: ‘info guix’ or ‘info guix [topic]’, but I doubt that s-k-a is documented. In such cases I grep guix for ‘define.*substitute-keyword-arguments’, see that it's in guix/utils.scm, and read the docstring. <nckx>Users of advanced emacs magic will surely frown at this but it's good enough for me. <nckx>Yeah, that thing. Geiser was unusable on my old (slow) laptop. Perhaps I should give it another chance. <nckx>Does it really save you that much time/keystrokes, civodul? <civodul>it's not so much in terms of keystrokes but rather about having a live development environment <civodul>well that's for hacking more than for packaging tho <nckx>I can't seem to see the light of interactive Scheme hacking. I want to! <nckx>People doing it always seem so blissfully content, lost in a flow I cannot reproduce. <civodul>nckx: that suggests we should have a "skill share" session (as they say) in the next Guix Days :-) <civodul>in other news, gfortran fails to build with --disable-libstdcxx <civodul>has anyone fiddled with that before? <nckx>That's because CONFIG_KEYBOARD_ATKBD=y (built-in), while CONFIG_USB_HID and CONFIG_HID_GENERIC=m. <nckx>…I'd guess, anyway, which is all we can do at this point. <nckx>You can lsmod now (or cat /proc/modules if that's too much of a pain) to see if hid_generic/usbhid are loaded in the initrd. <nckx>Assuming you care about debugging this side-quest. <nckx>Oh. Well that's a recipe for breakage. <nckx>I've used my USB keyboard in a REPL but it was probably on spawned later, after an error, not by --repl. <nckx>On the kernel command line in GRUB. <nckx>I even have a forgotten ‘TODO: swap??’ note about this very issue. <Kimapr_on_phone>doesnt matter where? There are a bunch of other options passed to kernel <nckx>Kimapr_on_phone: Can you try (mount "none" "/dev" "devtmpfs")? <nckx>Oh, no, the problem is going to be modules again. <nckx>Yes. I'm looking up the procedure. <nckx>I'll paste the whole thing. <nckx>Or are linux-module-directory etc. bound in the REPL? <nckx>I have to go for now. By the way, I still recommend booting a Guix installer live USB instead. <ArneBab>The freenet installer fails with NullPointer "FontConfiguration.getVersion(FontConfiguration.java:1262)" — do you have an idea why? <ArneBab>yes, I have almost all font packages installed — most of them in my system config <nckx>Try creating a fake fontconfig configuration file as suggested in that thread. <mroh>also, you could try another jdk, e.g. 11 or 14 <nckx>mroh: If you know anything about Java please elaborate. <jonsger>5 hours and still no disk-image. Hopefully will get better with my new desktop build machine :P <jonsger>does more packages installed lead to "bigger" derivations or something like this? <ArneBab>jonsger: I get much longer build times when there’s no substitute <jonsger>ArneBab: you use even slower hardware then me or how? <civodul>jonsger: hmm disk-image should take a few minutes <jonsger>civodul: yeah building itself, but it built fdisk, squashfs and everything before <ArneBab>jonsger: I use a system with 6 cores, all clocked down to 1.2GHz (saves 70% of power consumption) <jonsger>last 2 weeks or so are pretty bad with substitutes for me <ArneBab>civodul: can it happen that due to the system configuration with different versions there is no substitute? <ArneBab>I got out of that two times by explicitly writing down all packages I have installed and installing them via guix package -m <file-with-packages> <ArneBab>guix upgrade is somehow not the same as freshly installing all installed packages <civodul>Arjan: of course if that entails building libreoffice, it can take several hours :-) <civodul>but i mean, assuming you're not building any package from source, it should take a few minutes <civodul>otherwise it's worth reporting a bug <rovanion>My Intel i7-8550U never seems to clock down from ~3.9GHz on any of its four cores, according to cpufreq-info. Its running quite hot while it seems to be doing not much according to htop. Its running with Intel pstate as its governor. Any ideas on how to get it to throttle down? <nckx>rovanion: Which governor are you using? See cpufreq-info (cpufrequtils package). <nckx>Or: (cd /sys/devices/system/cpu/cpufreq/policy0; grep .*) <nckx>(cd /sys/devices/system/cpu/cpufreq/policy0; grep . *) <rovanion>nckx: Huh, I've used `sudo cpufreq-set -g powersave` before to set it to powersave. But cpufreq-info still lists the governor as "performance". <nckx>I've noticed Hexchat doesn't play well with the primary selection, it's often outdated or empty. <nckx>rovanion: You need to -c <n> it for each core, in my experience. <nckx>And for unclear reasons. <nckx>I have a script that does for i in $(seq 0 $((`nproc`-1))) … cpufreq-set -c $i :-/ <lfam>nckx: I've also noticed that Hexchat is weird in that regard <rovanion>nckx: Thanks. That seems to have put the governor to powersave according to cpufreq-info, but the frequencies remain high :/ <nckx>Higher than you'd expect or pegged at max? <nckx>Not that I have ideas in either case but it might be useful info. <rovanion>Higher than I'd expect, not pegged at max. <nckx>I've never had a CPU that new (mine's a i7-3520M, I'm sure it's completely incomparable thermally). <nckx>It clocks nicely to the minimum using pstate. <rovanion>Yeah, my last one was around the i7-4xxx range and it worked fine. <lfam>Looks like I broke `guix pull` <lfam>Why did this not happen with `make` <lfam>Not sure what's wrong here... <bavier1>lfam: I think make can succeed if it did not rebuild all go objects, but a 'make clean-go; make' might uncover such a thing <ArneBab>roptat: those intel CPUs can sometimes fail for that — the only way I found to keep the speed down is to enforce that in a regular cron-script: <ArneBab> ;; Set the governor to powersave every minute, except for the time <ArneBab> ;; between 3 and 5 to permit rebuilding. This reduces my <ArneBab> ;; power-consumption from 120W to 30W. <ArneBab> #~(job "* 0-2,5-23 * * *" ;Vixie cron syntax <ArneBab> "cpupower frequency-set -g powersave -u 1200000")) ;; use powersave governor with a maximum frequency of 1200MHz <jonsger>lol I bought a mainboard with a Realtek network device which isn't supported by linux mainline :P <lfam>sneek: later tell linka: There was a problem with my fix for Krita so I reverted it <ArneBab>nckx: yes, but at work we have the same problem (though with laptops) <ArneBab>some don’t speed up, others don’t slow down <ArneBab>including lots and lots of fonts :-) <nckx>I've heard about machines that ‘forget’ their setting after suspension, but this is something else. <ArneBab>I’m not sure whether this is the perfect config, but it’s as small as I got it and does the things I need. Including to circumvent pulseaudio for alsa, because that broke audacity <lfam>I don't understand how it could fail to find qtbase from from within the kde module <lfam>ArneBab: Are you on another distro? I'm curious about your Audacity issue <lfam>It's known to be broken on foreign distros but I thought it should work on Guix System <nckx>lfam: I've learnt to (e.g.) put qtbase-for-foo in qt.scm instead of kde.scm, but not why this happens. <ArneBab>My sound input from my stage microphone fails (is much too quiet) — and this has already been the case 2 years ago when I was still on Gentoo. <ArneBab>I now found out that this goes away when I stop alsa from using pulseaudio as backend <lfam>That sounds a different kind of issue than what I had in mind <jonsger>good that I have a spare network card :) <ArneBab>this kept me from doing any high-quality recording for years; next step is checking whether my usb audio system now works, too. <lfam>ArneBab: I have noticed some surprising microphone gain settings in alsamixer when using Pulseadio <lfam>There are "mic boost" options on alsamixer <lfam>But, for me they made the mic too loud and caused distortion <lfam>Audio on Linux is still such a pain <ArneBab>I’m not happy with pulseaudio — it is convenience traded for correctness. <lfam>I'm pretty happy with it overall <ArneBab>If you look at the original programmer of it, you’ll start to see patterns. <lfam>I still use a Mac when I need to do professional work <lfam>Eh, I like his work in general. I also like systemd a lot <ArneBab>I don’t: it goes the same route as pulseaudio, just more extreme: redo everything, play over the periphery to get people to adopt it, add subtle breakages that incur a cost for everyone who does something slightly out of the expected. <lfam>That's what I hear, but I started using GNU/Linux when Debian was still using sysvinit, and I couldn't successfully host custom services with it. When they switched to systemd it became super easy <ArneBab>I used to like pulseaudio when it came out, but the errors I hit over the years that typically could only be fixed by black magic (as in "I don’t actually understand what this does, but it works") got me quite unhappy. <lfam>Now I deploy services quite easily, and I find it reliable and just sophisticated enough. <lfam>I guess that people will always dislike change, and there are social components of the situation too <nckx>~$ guix pull → guix pull: error: mkdir: Permission denied <nckx>I would like more information, Guix. <ArneBab>I’ve been using Gentoo, and there writing a service was already easy. OpenRC does what SystemD does, but without the NIH. Instead of writing a whole new managing daemon that does everything, they defined a declarative language via bash functions that allows you to go down to scripting if you need to, but you usually don’t. <nckx>cannot [install strace]: 1 dependencies couldn't be built <lfam>Right, other distros besides Debian had already started on another path <lfam>The other thing I like about systemd is journald. It's a big pain point for me on Guix to be missing that <lfam>I'm looking forward to Shepherd growing this kind of functionality <lfam>Changing the subject, building Guix from scratch after `make clean-go` did not reproduce the error :/ But I am going to use `guix pull --url` to make sure I have it right this time <jonsger>now it's working. Did I already mention how lovely the installer is? <lfam>It always trips me up that you have to do (hidden-package (package ...)) <lfam>I expect that (hidden-package ...) would work <nckx>Yeah. I find the name doesn't help (if it were hide-package it would make sense). <lfam>But that would not be declarative <lfam>Maybe we can improve hidden-package to do this <lfam>Or... we could let it go <lfam>I see. hidden-package accepts a package <leoprikler>since we already have package/inherit, I think this would be a good fit for some syntactic sugar ;) <ArneBab>lfam: it’s not like the features offered by systemd are bad. As with pulseaudio it gives powerful features that are great until a subtle error prevents you from using your recording equipment for years, because you’re not able to find a reliable solution. Basic functionality breaks, quality is degraded, and that’s too big a price for convenience. <ArneBab>but now I ranted enough; I found a solution for audio (tell alsa not to use pulseaudio; luckily documented for Guix!) and just stick with Guix :-) <ArneBab>though I’m pushing the work into the night *nckx points out ‘package/hide’ for consistency would still be imperative. >:) <dustyweb>ArneBab: pretty well... I have a lot of writing to do <dustyweb>but I am making progress on the distributed programming things <dustyweb>multiple independent processes talking over captp today <dustyweb>still looking forward to getting Goblins ported to Guile... soon, soon, soon ;) <ArneBab>then I’ll have to look into using it with wisp :-) <ArneBab>hey, I know Freeform Universal :-) (though I have not played it yet; have my own free RPG system) <pkill9>i have a vision of one day being able to download all the .desktop files from every package built by the build farm