<podiki[m]>nckhexen: the comments were only about some style (moving all the setup stuff to a separate function) and adding tests; no functional changes that I heard <cyberkefir>hi guix! i have a problem. i am trying to install guix as a system manually using latest image. as i see there is no mkfs.ext4 command. but as i see tui installer still formats in ext4. is ext4 deperecated in guix if not how to use it in latest image, if yes what to use now? <nckhexen>That is very surprising, but I can't deny it offhand… just… are you sure? *nckhexen is building an installer VM in the background, but that'll take a while. ***jesopo is now known as jess-o-lantern
<cyberkefir>nckhexen: it returns different things, but no .ext's <nckhexen>It's an oldish patch, but it was pushed yesterday, which is why it's affecting today's latest image. <civodul>podiki[m]: re FHS yes! i'm sure that'll make a number of people happy :-) <nckhexen>cyberkefir: You should check whether /gnu/store/*e2fsprogs*/sbin/mkfs.ext4 exists. <nckhexen>Otherwise, it's not on the ISO (and the graphical installer would fail too). <nckhexen>guix is taking forever to tell me if it would be pulled in, so you might as well just look, that'll be faster. <cyberkefir>but it would be great to have symlinks of this in my user profile <nckhexen>That's what that patch tries to do, cleverly, but it (oh, familiar refrain) was a bit too clever and hey — this ISO uses an ISO file system! It doesn't need ext4 tooling available by default! <cyberkefir>i guess, (list e2fsprogs) needed in gnu/system.scm <cyberkefir>but that my guess, not familiar with guix internals <nckhexen>Hah, the ISO just finished building. Now a useless thing. <nckhexen>cyberkefir: Correct(ish), maybe a good first patch? :) Bye! o/ <ae_chep>Considering `guix build -K glib` lists "/gnu/store/....-bin", and that directory has a bunch of binaries I want, why would those not be in my default profile when I do a `guix install glib` ? <antipode>nckxhexen: See PM for connection information <ae_chep>I think right now `pacman` is the only pkg I'm not pulling from guix. <mroh>pkill9: thx for the bugreport concerning celluloid. I haven't recognize this while converting the pkg to meson-build-system. Lesson learned ;) <podiki[m]>civodul: yes, it is quite handy, when you don't have other options :) I found it worked well for some freelance development work, relying on web automations set up with python's poetry shell <podiki[m]>nice work ae_chep, haven't gotten that far on my arch machine yet <podiki[m]>civodul: also think it helps round out guix shell/container as able to do so many things very easily <ae_chep>podiki[m]: I will see within the next week/month what I failed to migrate. There are also a number of things (eg. "steam") that I haven't setup properly yet <Kabouik>vainfo (from the libva-utils package) errors out on my laptop with only a 11th generation Intel GPU chipset. I have intel-media-driver, mesa and libva installed. Am I missing something else? <sneek>Kabouik, you have 1 message! ***maximed is now known as antipode
<shcv[m]>I feel like I've had this issue before, but my "sudo guix system reconfigure ..." is complaining about modules not having code that should be in the latest version of guix, and I just pulled it. I also tried `guix install guix`, `sudo guix install guix` etc.... What am I missing to make sure it has the latest guix source? guix time-machine -- system reconfigure works... <shcv[m]>lechner: hmm; I don't have an encrypted home though <lechner>shcv[m]: yeah, i did not think so. i just pointed it out because it shows different guix versions. your issue may be elsewhere <podiki[m]>guix install guix and sudo guix install guix might be a problem, I would rollback both of those <podiki[m]>and then guix pull and make sure guix is current (see maybe which guix) ***rgherdt_ is now known as rgherdt
<unmatched-paren>shcv[m], podiki[m]: yep, you should absolutely never install ``guix'' with ``guix package'' <mekeor[m]>shcv: could you paste and share the error messages of guix "complaining about modules not having code that should be in the latest version of guix"? <mekeor[m]>any ideas why "guix upgrade" fails while grafting texlive-texmf with "in procedure fport_fill_input: Input/output error"? <nckhexen>That's not something others can say. Does dmesg give any answers? <mekeor[m]><nckhexen> "That's not something others..." <- yes, there are some io-errors from my ssd-disk :o <mekeor[m]>i guess, i should asap backup my data and try fixing the ssd and probably order a new one, huh <nckhexen>‘Unrecovered read error - auto reallocate failed’ does not bode well. What it's literally saying is too much flash has died to recover. Now, there might be ways that could be a mis(self)diagnosis, but that's grasping at straws, frankly, and hardly increases confidence in the thing. Sorry… <nckhexen>I guess I'd run a smartctl test on the thing, and look at smartctl stats in general, but just out of curiosity. I'd still order a new drive. <abralek>efraim: Hi, I was wondering do have any riscv64 substitute server? <efraim>abralek: I run a substitute server at k7muufoychzetmq7evsv6gcq4sxq4olxo3uy2zlhek5fkfvl5uscbgyd.onion which does have my riscv64-linux substitutes <efraim>although be aware that it's actually my home computer with a slowish upload, so probably not what you should put as the first substitute server <efraim>and the key: (public-key (ecc (curve Ed25519) (q #5711CA127D5AE4E2BC8414224EEE042776DE4F76A53D71615D344819575921DC#))) <abralek>efraim: Aha! Tor. Nice. Let me try it =). <efraim>it was the easiest way to get it setup :) <abralek>efraim: I am building an image for PolarFire, the one I got from Pjotr. cross-compilation and binfmt for now. <efraim>abralek: does it have upstream u-boot support? <abralek>efraim: Yes. It runs PolarFire(R) SoC Hart Software Services which eventually loads u-boot (2020.01). <efraim>Looks like it's been in for a while. I found it in boards/microchip/mpfs_icicle (asusming I got the right one) <abralek>yes, that is the one. I got an extra sd card where I plan to put the image. For now. <Kabouik>I just get this nckhexen: https://0x0.st/o47A.txt I have tried with mesa, libva, intel-media-driver installed, and also with i915-firmware (nonfree) installed on top of that <pkill9>how do you stop gnome shell automaticlaly installing a particular package? <pkill9>and packages to prevent installing <pkill9>I think epiphany creating a mimeapp.cache file may be overwriting the one generated by a profile and preventing gnome shell from seeing other applications possibly, or maybe not <pkill9>hmm weird, XDG_DATA_DIRS doesn't have my additional paths added <pkill9>why does fish shell not inherit environment variables?? <nckhexen>Kabouik: And that error ‘just’ explains everything, which is why it's always good to share it from the start. It's looking in a bogus place (mesa) for the driver, which means LIBVA_DRIVERS_PATH isn't set, which means you didn't install the right collection of packages. I could never have guessed that. <nckhexen>Make sure mesa, libva, i-m-d share a profile. ***Dynom_ is now known as Guest5501
<nckhexen>pkill9: All processes inherit them, it's not a choice. Maybe it's resetting them, or the variables are gone by the time fish is actually started. <nckhexen>You can inspect its parent processes' variables and compare. <Kabouik>I am not sure what you meant by "make sure mesa, libva and intel-media-drivers share a profile" nckhexen. How do I do that? <Kabouik>They're all installed but I don't know how to assign them a profile <unmatched-paren>Kabouik: they're all installed with a regular ``guix install mesa libva i-m-d'' or guix home, right? <unmatched-paren>if the former, they're all in the ~/.guix-profile profile; if the latter, they're all in ~/.guix-home/profile <pkill9>how does the locale command work? in a bubblewrap sandbox it reports "POSIX" as the locale, outside it's utf8 locales, where does it find out these values? I'm trying to get the sandbox to use the utf8 locales <Kabouik>They're all installed with guix install unmatched-paren; so far I have not dived into guix home <Kabouik>And I only have one user on the machine, so I would guess they already share the same profile <Kabouik>But indeed LIBVA_DRIVERS_PATH does not seem to be set, as nckhexen pointed out. <unmatched-paren>it's possible to install into different profiles with ``guix package -P'', but I thought it would be unlikely that you did that <unmatched-paren>strange. can you show ~/.guix-profile/etc/profile and ~/.guix-profile/manifest ? <nckhexen>Kabouik: It is possible (even likely) that mesa is in your system profile. I don't know about the rest. *nckhexen was away, sorry. <nckhexen>‘guix install’ operates on a different profile than ‘guix system’. <nckhexen>Everyone using Guix System has at least two profiles, excluding the weirdoes who put *everything* in their operating-system packages. I did that for a while, so I can say that :) <lilyp>okay, but most people have three profiles <nckhexen>If you mean guix-current, you are the best kind of korrect, but also irrelevant. Otherwise, I genuinely forgot one. Which? <lilyp>Nah, I meant guix-current, a.k.a. the "pull profile". You can get up to 4 with guix home <Kabouik>So adding libva and intel-media-drivers to my system config and reconfiguring could be a way to make the three packages share the same profile? <nckhexen>Plz do not install mesa into guix/current. Puppies die. <Kabouik>For what it's worth, mesa is not in my system config.scm file <nckhexen>lilyp: True. I wonder at what point guix home will be ‘most users’. I don't think we're there yet. Obviously we need telemetry! <lilyp>It won't be all users until it addresses the point I have with multiple profiles. <lilyp>I refuse to use yet another thing if it won't solve my problem. <pkill9>what is that lilyp? the multiple profiles <nckhexen>pkill9: <locale> It's based on the environment variables that it prints, with fall-back (each LC_* is usually not explicitly set—that's good) & override (LC_ALL) rules. POSIX is the fallback; it means nothing was set. <lilyp>pkill9: managing ~/.guix-profile like profiles and their sourcing order <pkill9>nckx: how does it determine what to fall back to? I don't have LC_* set <pkill9>rekado: do you know how to remove gnome packages from being automatically installed? <unmatched-paren>pkill9: surely you can just remove the gnome service? is that what you mean? <pkill9>unmatched-paren: I don't want to remove the gnome service, I want to remove some of the packages it installs along with it <pkill9>like calendar and epiphany (web browser) <nckhexen>The rest is just precedence/default rules, but it's all based on what you see (& the code I linked to). <lilyp>pkill9: it takes a gnome package, that you can strip down or extend as much as you want <nckhexen>You wouldn't usually set LC_*, unless (1) you want to change specifically how currencies are formatted, say, or (2) you want to use the big LC_ALL hammer to force everything to one value. <pkill9>nckhexen yea it was just missing LANG <pkill9>oh nice, the gnome package is just a bunch of propagated inputs <lilyp>tis jus me or is savannah down? <minima>hi, is anyone using passmenu under wayland (eg sway)? it fails to start on my system with error 'dmenu-wl: command not found' <pkill9>nice, btop was added only 4 days, just in time to find it <nckhexen>minima: dmenu-wayland isn't packaged for Guix yet. <nckhexen>It doesn't look hard to package, if you're interested, but I can't promise that. <minima>oh, i just found out that this can be fixed with a symlink, eg 'ln -s $(which dmenu) .local/bin/dmenu-wl' <nckhexen>Yeah, I use the regular dmenu (with a ‘history’ wrapper script) on Sway, works fine, if impure. <minima>nckhexen: yeah, i think packaging it would be a good exercise for me - although it seems that a simple symlink can solve(?) the issue <pkill9>unmatched-paren: thanks, where does that go? just in (gnome-desktop-service (gnome-configuration ...)) ? <pkill9>well, gnome-desktop-service-type * <Maya[m]1>okay so I just found a bug in qtbase-5 when building it on newer gcc, this is super obscure <pkill9>i like success stories of obscure bugs found by guix <Maya[m]1>element doesnt like angle brackets apparently, ThreadEngineStarter[void] - ThreadEngineStarter <Maya[m]1>pkill9: i have one more, but I havent had the energy to tackle it yet, it has to do with dynamic loading of vulkan libraries in mesa, and thats a mess <f3n1x>hi unmatched-paren ! the newbie i am is especulating with the idea of working in two different git branches of the same repository simultaneously. Would super 'guix shell' help me on that ?! <lilyp>f3n1x: probably maybe, but you still need two git checkouts (or worktrees maybe) <pkal>Does anyone have a link to some public collection of system.scm files I could read for inspiration? <Guest89>Friends, could you point me to any documentation on how to use the ublock-origin-chromium package with ungoogled-chromium? I have pulled both but chromium does not detect (on its own) that ublock is on the system <pkal>Guest89: Doesn't ungoogled-chromium disable plug-ins by default? Have you checked their own documentation on this? <Guest89>I don't think so, I can browse to the "extensions" location in the chromium settings and it seems to be enabled. I toggled developer mode and it showed me that I could load unpacked extensions; but the presence of the ublock-origin-chromium package in the guix store makes me think that I can install it from there rather than loading the .crx <Guest89>I confirmed that I can load the unzipped package from the ublock origin github and that the extension behaves as expected; I'd still like to be able to specify loading that extension "the guix way" if anyone has a suggestion <PotentialUser-2>Does anyone have the problem of "invalid magic number, you need to load the kernel first" when installing Guix system on aarch64 VM on MacOS (UTM)? I built the iso from the official Guix repo. <Guest89>Can anyone recommend a "correct" way to install the haskell toolchain? I see that cabal-install is in the free repo but not stack; should I use that? <florhizome[m]>just wanted to iterate lilyp guix home not managing one User Profile but any seems very useful. And maybe Desktop Environments can be Home Services with their own profile then 😌 <lilyp>hmm, I'd make them meta-packages still, not profiles <ae_chep>Guest89: It really depends on how you want to work with haskell. Most people I know either use nix or stack, and not cabal directly. I would go about trying to replicate the nix workflows on guix (which means go with cabal-install) <Guest89>I see, thank you. I'll give it a try and report back <djeis>Anyone around who happens to be familiar with the magic inside the new emacs native comp support? I'm using a patched emacs package, but I'd like to make use of the pre-native-comp and it seems just doing an input rewrite of emacs-minimal with my patched emacs package isn't enough for everything (in particular, pdf-tools). <djeis>It's not my patches either, because the same thing happens if I try to build pdf-tools replacing emacs-minimal with the normal emacs package. <florhizome[m]>lilyp i would think it's best to avoid overlap. but maybe, yes. <djeis>i.e. guix build emacs-pdf-tools --with-input=emacs-minimal=emacs produces a build failure on the native comp step, at least for me. <lilyp>djeis: mine produces a fine old natively compiled package <lilyp>note that the native-comp thing takes place locally on your machine, so you get all the fun arch-exclusive bugs <florhizome[m]>as long as i can have different package and service compositions for the different DE entries ... <djeis>Running that exact command? Odd... <djeis>I'm pretty sure it's not a local compilation problem, because I forced a local rebuild using emacs-minimal and that went through without issue. <lilyp>emacs-minimal does no native compile <PotentialUser-2>Does anyone know if there is an up to date tutorial of how to install Guix system on aarch64 with qemu? I got error "invalid magic number, you need to load the kernel first". Thanks. <djeis>native-comp is the default on recent emacs, IIRC, and if it doesn't then why does it depend on libgccjit? <djeis>My point is emacs-minimal also depends on libgccjit, explicitly. I'm looking at the package def rn. <djeis>Ah, something must have been patched in the last day or so, sorry to bother everyone. <lilyp>ahh, yeah, my mistake, those extra inputs are actually not needed <djeis>(problem goes away if I time-machine --branch=master, but I definitely pulled a day or so ago... sometimes I forget how fast things move) <lilyp>I'd rather not push a fixup right now, it'll cause a rebuild of all emacs-* packages <Maya[m]1>can a CC-BY-NC-SA work be distributed with guix? <lilyp>yes in "yes, you can place CC BY-NC-SA work in your channels" <lilyp>no in "no, you can't upstream these to guix" <Maya[m]1>lilyp: i was asking about upstreaming, thank you <Maya[m]1>im submitting an issue to one project that i want to include in guix upstream and I wasnt sure <shcv[m]>unmatched-paren: funny you say that; I had thought the same but someone recommended it here I think, which is why I did it. How would I undo? Just uninstall? Or rollback generations? <pkal>dominicm: Thanks, but that isn't what I am looking for. I want a few basic configurations to compare how they work, without too many custom procedures and modules. <dominicm>pkal: Ah, got it. In that case, have you checked out the example system.scm files built into Guix? <pkal>No, I haven't. It that part of the guix repository? <dominicm>Yup, let me try and find where they are again <pkal>dominicm: Perfect, thank you! <pkal>The desktop.tmpl looks like what I was looking for. <lilyp>djeis: Pushed a fix to staging. <podiki[m]>TIL you can use languages like emacs lisp and ecmascript directly from guile (compiler tower) <viivien>It’s so sad that emacs does not use guile <viivien>There are plenty of good software for guile that I would love to have in emacs, and lots of wonderful things written in emacs lisp that would be fabulous to have in guile <viivien>As far as I understand, there are still minor incompatibilities, and emacs’ native compiler is way better than guile’s <drakonis>fabulous indeed but backwards compat beckons <viivien>(at least, way better for editor tasks) <drakonis>at this point, the next best thing to emacs is nyxt <drakonis>also i had a link but odds are it will derail the channel for hours <Kabouik>Anyone succeeding downloading torrents with aria2? Direct links work but not magnets, in my case. I reckon it's a port forwarding issue but I never found how to open ports in Guix. <the_tubular>If the torrent is popular you shouldn't have to open ports. <the_tubular>Only either the seeder or the peer needs to have a port open, so I'd be surprise you can't meet this condition in 5000 seeders <Kabouik>The same magnets work well in qbittorrent, I only face this issue with aria2 <Kabouik>I was not sure both would use the same ports, but if they do, yeah the issue must be somewhere else. It's still weird that aria2 works well with direct links though; perhaps it's an issue with the aria2 package for Guix? I was checking if it was an issue isolated to my machine or a more general one with the package <the_tubular>Guess you are right, they might be using different ports. <antipode>Kabouik: Port forwarding happens on the router, not in Guix (unless you run Guix on a router) <antipode>You may need to edit the router settings. <Kabouik>Meaning all ports are open by default on a Guix machine? Thanks, that's also useful for an issue I was having with ssh'and thought was due to a port closed in Guix <the_tubular>Dumb question, I'm trying to learn rust and was wondering how does guix handles everything happening with cargo? <unmatched-paren>the_tubular: cargo has a flag to use a directory as the crate registry instead of a website <unmatched-paren>so all the sources of the cargo-inputs are unpacked into a guix-vendor/ directory <unmatched-paren>and then cargo is passed a flag to use that directory instead of crates.io <unmatched-paren>then i'm pretty sure you can just do ``cargo build'' etc and it will Just Work... <unmatched-paren>It's all a massive, power-wasting hack, which will be replaced with antioxidant when the time comes <efraim>in theory you can set the vendor directory to $GUIX_ENVIRONMENT/share/.../something and be able to use guix shell with cargo, but it's not fully fleshed out <lilyp>to be fair, Rust itself is a massive, power-wasting hack :) <efraim>but currently, if you want to use rust from guix your best option is to just use cargo and then worry about packaging later <efraim>there;s a lot of redundant packaging, we're still hoping the rust folks upstream decide to work in a per rust version stable ABI so we don't need to recompile every scrap of code for each individual crate and library and binary <efraim>there's a lot of wasted compiling <efraim>we can make do without dynamic linking, but I want my minimally stable abi <unmatched-paren>i vaguely remember there being some optimisation-related reason for the lack of an ABI <unmatched-paren>something about optimising structure/tuple layout, i seem to recall? <lilyp>Rust isn't just wasting computational resources in the CI. It also wastes everyone's collective time as distributions have to figure out how the fuck to do shared libraries with anything depending on it. <lilyp>Cue the good old "but Rust can produce shared libraries, it's just Cargo that can't" <mekeor[m]>... any swap partition or file. but suspending works fine. how come it works? and should i use a swap partition so that my ssd lives longer? <lilyp>you probably have enough RAM or oom silently kills stuff behind your back <sektor[m]>The thing that kills processes off when your RAM is low. <sektor[m]>It's a lot of fun when it decides to kill the screenreader. <mekeor[m]>yes, i think my memory/ram is enough but i read that swap is required for suspending/hibernation <efraim>we have an oom service, you can tell it to not target certain targets first <efraim>or to target certain things first <efraim>I tell it to target my compilations before my desktop stuff <lilyp>only for hibernating, suspend uses ram <mekeor[m]>anyway, i have some ssd issues, and i wonder if it's also because i don't use a swap partition. because i read that it can even improve/reduce disk-io <lilyp>having swap on an SSD is imho ill-advised <mekeor[m]>ah! hibernate is suspend to disk! ugh, i should use that! it saves power... <lilyp>there's a reason why /tmp no longer goes to disk <efraim>I haven't used suspend or hibernate on purpose for many years, I make sure to at least have some swap even on my 64GB of RAM system *efraim has build machines for aarch64 and riscv64 using SD cards <clever>mekeor[m]: my swap is on luks, and i have zfs for a rootfs, i think both of those cause issues with hibernation for me <efraim>mekeor[m]: I was convinced that the machines start fast enough with an SSD that I'm not missing anything with hibernation, and web browsers remember their tabs so I'm not really losing anything <efraim>* I was convinced by the arguments that it was probably just as fast to open everything fresh as to reload it from swap to RAM <clever>efraim: my browser takes ~5 minutes to restore all tabs, booting itself is basically instant <lilyp>I think modern browsers might invalidate the latter one, but yeah, booting is not the issue hibernation solves <mekeor[m]>lilyp: "disk" meant hdd/ssd in your last message, right? does that happen automatically, on guix system? <lilyp>For me, it's basically undone work I want to remember the next day. <efraim>I try to keep under 15 tabs, everything else can go into history autocomplete or favorites for later <efraim>or I leave my machine on and just come back to it later <clever>efraim: yeah, thats what i tend to do, just never shutdown <mekeor[m]>anyways, which settings do you recommend for ssds? <mekeor[m]>in the guix manual, i only found the 'discard?' setting for swap spaces... <efraim>I try to reboot weekly to switch to the new kernel, that's about it, otherwise I normally leave my machine on or off <efraim>I haven't figured out subvolumes for different mounts still, otherwise I'd have compress-force=zstd for /var/log <efraim>IIRC default zstd compression is level 3 <efraim>its not a bad choice, I'm just not worried about wearing out my SSDs <efraim>my first machine with an SSD was a Lenovo x120e, with an SSD it was CPU bound at boot <vagrantc>had the impression discarding on the filesystem level created needless wear and tear ... <efraim>bought that machine in 2011, I think after ~5 years smartctl reported the SSD was at 91% health <vagrantc>e.g. better to discard weekly or so, depending on usage <efraim>vagrantc: I think discard is a byproduct of when the kernel didn't have a good solution for occasionally cleaning dirty blocks <cbaines>efraim, where do you see that percentage? <mekeor[m]>debian seems to be shipped with a "fstrim.timer" service to regularly run TRIM... does guix have such a service or so? <vagrantc>but i'm also unfamiliar with btrfs and whatnot <efraim>cbaines: definately somewhere in smartctl, I forget where though <cbaines>I'm looking at replacing one of the SSDs in the Honeycomb systems, as I think it's wearing out, but I don't have much to go on other than I/O errors <vagrantc>yeah, i burn through a lot of SSDs on a (non-guix) build farm i maintain <efraim>with btrfs I try to keep under 80% disk usage <efraim>noatime and using zram for swap will definately decrease writes to an SSD if you're worried about that <efraim>Assuming I read smartctl correctly for my desktop machine, after ~2 years I've used ~12% of the drive, in terms of health <mekeor[m]>efraim: smartctl does not report such percentage numbers for me. coult you share the command, too? <clever>[root@amd-nixos:~]# smartctl -a /dev/nvme0n1 <efraim>guix shell smartmontools -- sudo smartctl /dev/nvme0 -a <clever>i think it varies with drive firmware too <clever>oh yikes, my laptop is pretty high <efraim>I think the suggestion was that one would replace the SSD with a larger capacity device before the device died <efraim>mekeor[m]: just makes a tmpfs for /var/guix/tmproots, which is used as a staging ground for guix evaluations, and a tmpfs for /tmp <efraim>no-suid means no set-uid binaries should be found here, no-dev for no /dev files and no-exec for no executables <efraim>it definately started more as a case of experimenting with what I could do with an OS config <efraim>because my main machine has 64GiB of RAM and I wanted to use it for something <efraim>the last time I came close to running low I had ~5 copies of GHC unpacked in /tmp <mekeor[m]>would you recommend this setting with 8gb ram? <efraim>I would probably use both, and then unmount /tmp if it became a problem <efraim>you could always unmount /tmp, start a build that needs more space, and then remount it <efraim>even if its unmounted it doesn't drop the contents of the file system <mekeor[m]>and while /tmp is mounted, i'd save ssd-io, right? <efraim>same if you start a build on /tmp backed by a physical device and then remount a tmpfs /tmp on top of it, the bujild would continue <efraim>mekeor[m]: right, and a tmpfs is faster than the ssd <mekeor[m]>essential quote: "/tmp on tmpfs is a nice hack (I use it myself!), but it's a terrible default." <efraim>IMO it depends on how you deal with running out of space on /tmp <efraim>when building, it immediately fails and frees some space (unless you build with -K) <efraim>otherwise it doesn't happen that often with the larger ram sizes <lechner>civodul: thanks for #57960! regarding lilyp's point, i have been using the tab-on-region trick in emacs elsewhere (but forgoing 'guix style') and will submit separate formatting patches in the future <mroh>ne1 else getting "failed to compile 'guix/build/clojure-build-system.scm'" on core-updates? <mekeor[m]>wow, my ssd has an firmware update with the release note "Fixed corner case causing some drives to become unresponsive". that sounds pretty frightening actually :o *mekeor[m] does not use core-updates 
