***aya is now known as gyara
<Aurora_v_kosmose>Since the pandemic I've noticed my network quality has notably degraded and I'm sure I'm not the only one. <Aurora_v_kosmose>Or does such an option already exist and I'm just making a fool of myself? <jgart>We need an auto commit script for rust packages <jgart>Guix API provides the package name and file path and the commit message for upstream is generated for each package. <Aurora_v_kosmose>lispmacs[work]: The part about opinion or the part where it might already exist without my knowledge? <jgart>Would ease the barrier too packaging large rust packages with many crates <jgart>Should an nscd service not be required on a musl based system because there is no host glibc to begin with? <jgart>since the glibc packages would not class with the musl ones ***califax- is now known as califax
<podiki[m]>jgart: the yasnippets in the guix tree make it pretty quick in emacs/magit, could probably automate that for just package additions/version bumps <jgart>podiki[m], do you use the yasnippets without having to interpolate variables using tab to go through each one? <jgart>I'm looking for something more automatic than tabbing through each field or editing the commit message manually. <podiki[m]>I haven't used it a ton, but for adding or upgrading a package it is very quick (since it just like one field) <podiki[m]>I'm sure you could automate that or have a different snippet/setting for that purpose (I haven't use yasnippet before, always been meaning to) <podiki[m]>maybe just "add" then tab for the snippet, that's it? <jgart>I want to be able to not type anything. Imagine you have 400 package dependencies and you want to auto commit them all. <podiki[m]>I would guess there are tools (with git, emacs, something) for just this stuff, but I don't know <lilyp>podiki[m]: there's importers but if you can't use one tabbing is your best bet <podiki[m]>? you mean to jgart? I believe they were asking about doing all the commit messages, the importers don't help with that or is there something I missed? <lilyp>jgart[m]: if you're doing fairly normal stuff, etc/committer should have you covered, no? <podiki[m]>(though I'm listening to as I have a big chunk of haskell packages I'll need to do this for) ***iaeung[m] is now known as iung[m]
<alMalsamo>"The cinnamon-desktop package contains the libcinnamon-desktop library, as well as some desktop-wide documents." <jpoiret>alMalsamo: it seems to be mostly a library for some things in the cinnamon DE, far from the whole environment <jpoiret>and no packages in guix depend on it, so I don't think cinnamon's in Guix ***Andrew_ is now known as Andrew
<aadcg>what's the rationale behind prepending "%" to a variable in guile? <civodul>aadcg: hi! in Guix it's usually for global variables that are somewhat special <civodul>the meaning is a bit different elsewhere, in other Lisps in particular <aadcg>similar earmuffs in common lisp? <civodul>i find myself resorting to the monolithic texlive just for pdfjam <civodul>i couldn't come up with the relevant texlive-* package list in a timely fashion <abrenon>so I'm not the only one abandoning hope in front of the huge forest *abrenon thinks she still has to understand how to package a theme <civodul>yeah i've tried many times in different contexts <civodul>but often it's too daunting and seemingly endless <abrenon>last time I tried to overwrite beamerthemeCopenhagen.sty with my file, it worked (as in, I could check that the version in the output environment contained my theme) but pdflatex still produced slides with the actual Copenhagen theme <abrenon>I have no idea where it was loading it from <florhizome[m]>Is someone using sway or another wayland compositor ? Can you try using geparted? <vldn>when you want to run sudo apps on wayland you have to activate them <vldn>this enables sudo gui apps <vldn>xhost -si:localuser:root <vldn>try xhost on wayfire florhizome[m] <florhizome[m]>On these x sessions I get the wrong keyboard layout, though.. <vldn>just run in as a cli command within your wayfire/sway/or whatever session <vldn>"xhost si:localuser:root" <vldn>after that you can run sudo gparted just fine <vldn>you need the xhost package for that <florhizome[m]>I wonder if I just fail to type in my cryptsetup pass phrase correctly or if there is something mushy <vldn>it's somekind of security meassures if i understand it correctly <vldn>As put by Emmanuele Bassi, a GNOME developer: "there are no *real*, substantiated, technological reasons why anybody should run a GUI application as root. By running GUI applications as an admin user you are literally running millions of lines of code that have not been audited properly to run under elevated privileges; you are also running code <vldn>that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc. You are opening up a massive, gaping security hole [...]."[1] <vldn>Before Wayland, running GUI applications with elevated privileges could be properly implemented by creating a Polkit policy, or more dangerously done by running the command in a terminal by prepending the command with sudo; but under (X)Wayland this does not work anymore as the default has been made to only allow the user who started the X server <vldn>to connect clients to it (see the bug report and the upstream commits it refers to). <vldn>Avoid running graphical applications as root if possible, <vldn>xhost is just a workaround to do something stupid as the user :D <vldn>try adding the needed groups and changes to run gparted as your useracc, never done that because i'm too lazy.. :D <vldn>nope, standart wayland enforcement:D  love wayland so far with it few quirks here and there <florhizome[m]>I need some audio setup though I haven’t bothered with that atm. <vldn>haven't bothered with audio much, just install pipewire and pamixer/pavucontrol these days and everything works <vldn>much nicer than 10+ years ago :D <rekado_>vldn: is pipewire even used when you install it? <rekado_>I thought it was just used as a library by some applications <vldn>nope it replaces the whole and be compatible to alsa and pulseaudio apis imo <vldn>but don't know for sure.. <vldn>not much difference to just running pulseaudio <rekado_>I know what it’s used for, but I doubt installing the “pipewire” package into your default Guix profile has any effect <florhizome[m]>My problem is that I’m not transferring from pulseaudio or so and most tutorials are about that :D <florhizome[m]>wtf my screen just went black on me in the midst of expanding my partition <vldn>will look into it if i'm on my system:D  i think it runs wireplumber as a service but let's see ^^ <vldn>maybe monitor power save? <vldn>ctrl+alt F2-5 maybe try changing to term? <vldn>let's hope that the kernel not crashed:D <vldn>had a few kernel panics because of my intel gpu in the past <florhizome[m]>One thing with guix is that I’m almost more insecure into what I can do by hand since most things are handle through system reconfigure <vldn>mh my btrfs never crashed so far <florhizome[m]>What you said with the intel driver seems more plausible, hopefully <florhizome[m]>(I’m on 5.15x though, I don’t think guix has 5.16 yet, right) <florhizome[m]>Ok, it tells me “zstd data corrupted” when trying to decrypt the partition... <dcunit3d>if it's btrfs, the tools can repair a lot of situations <dcunit3d>i'm not sure about btrfs on encryption though. but if you're getting a zstd error and running btrfs, that could be after the compressed data is beginning to be returned. i don't know how encryption blocks work for LUKS though ***jmc is now known as jmcf
***jmcf is now known as jmc-f
<florhizome[m]><dcunit3d> "i'm not sure about btrfs on..." <- I still have a partition with manjaro around, hope to be able to fix it from there... <dcunit3d>definitely look at the btrfs docs. i have to run. i may be able to help you. i'm running into a similar issue with my guix configuration <dcunit3d>so i'm figuring that out for the first time <florhizome[m]>Should be possible to decrypt from another device and then proceed as normal though maybe? ***noobishGuixUser is now known as NoobishGuixUser
<jpoiret>florhizome[m]: wdym by proceed as normal? <jpoiret>encrypted partitions are only decrypted in memory <jpoiret>you can inspect their contents on another device, but you can't "decrypt once" and then reboot <jpoiret>fsck, btrfs tools and everything else will work <florhizome[m]>That was the basic question if the encryption changed anything for the other tools ;) <aadcg>I'm installing the guix system and I messed up the system config (didn't configure the file systems properly). So now the system goes directly to Guile (so called early boot). How can I edit my config from here so that I can issue guix system init? <jpoiret>it would be easier to boot the installation medium again and edit it from there <aadcg>it's ok, it's just that it will download lots of stuff again <jpoiret>if you use the cow-store service (in manual installation), you shouldn't have to iirc <jpoiret>as long as you don't reformat the partition that the store is on <aadcg>that part of the installation I still didn't quite understand. What exactly happens when /mnt gets populated? <aadcg>and what does this cow-store services do? <aadcg>thinking about it again, things make sense <jpoiret>aadcg: roughly, the store is copied to /mnt, and the basic skeleton of /etc, /var and such is created <jpoiret>the cow-store service basically mounts an overlayfs on /gnu/store with the lower_dir set to the installation medium's /gnu/store, and the upper_dir to /mnt/gnu/store <apteryx>how can I set environment variables to be honored by GDM on a foreign distribution? <jpoiret>If so you can use the env variables we patched in to add a custom wrapper <apteryx>no, it was Debian. Couldn't figure out how to unbreak the login, I rolled back to an old generation of Guix prior to installing a few packages (jami was one), and had to reboot. <apteryx>possible setting 'export XDG_DATA_DIRS=/usr/share:/usr/local/share:$XDG_DATA_DIRS' in /etc/profile could have done it following the reboot, but it didn't by forcing gdm to be respawned <apteryx>hmm, I can't test anymore at the moment (not my machine), but I'll try to investigate later in a VM <gbrlwck>i3-gaps fails to build on master -- how can i `guix system reconfigure` anyways? <lfam>gbrlwck: You can remove i3-gaps from the list of packages in your config.scm <lfam>gbrlwck: You could also use ci.guix.gnu.org to identify the latest revision of Guix where i3-gaps builds, and reconfigure based on that. However, I can tell from the CI interface that i3-gaps broke when we deployed a major update of core Guix packages. So, it's quite a long ways back in terms of code changes, although it's only about 6 weeks ago <lfam>If you click the "ID" of the interesting build, then the "Evaluation" number, you will land on a page that shows the Guix Git revision that corresponds to that build, and you can use that with `guix time-machine` or `guix pull` <lfam>But instead, I recommend either not using i3-gaps until it is fixed, or fixing the i3-gaps package :) <lfam>And even if you did want to go "back in time", you might trade one build failure for another. So it's better to fix i3-gaps or stop using it for now <lfam>I use i3, although not i3-gaps. So I kinda care about this package, kinda don't ;) <lfam>We can see from the build log that it fails in the configure phase, right away: <lfam>starting phase `configure' <lfam>ERROR: Neither directory contains a build file meson.build. <lfam>Our version of i3-gaps is also a few versions old <lfam>Maybe the bug is fixed in recent versions <apteryx>lfam: hello! did the latest version of the linux-libre config change looks OK to you? <lfam>Indeed, our version 4.18.3 doesn't use meson gbrlwck <lfam>apteryx: Can you share a link? <lfam>I'm seeing a lot of fallout from some other recent changes to the kernel configs that I okay-ed, so now I'm going to ask for a lot of testing <gbrlwck>lfam: yeah, i figured it didn't look too complicated ;) <lfam>gbrlwck: It's weird that our package uses meson but i3-gaps 4.18.3 doesn't... I wonder what happened there <lfam>It *looks* okay now apteryx. I'd like to see testing of each kernel series, at least on x86_64, via something like `$(guix system vm doc/os-config-bare-bones.texi)` <lfam>To clarify, that means running the VM :) <lfam>So, for each affected kernel series, tweak bare-bones.texi to use that kernel series <lfam>This is the most minimal level of testing that I do <lfam>Normally I do this on berlin, but it's currently collecting garbage <lfam>In the future, CONFIG_LOGO_LIBRE_CLUT224 will probably go back to the upstream variant of this option. But I think that's fine since it's not set anyways <lfam>That's because I do this work based on upstream sources <apteryx>yes, you mentioned this kind of change is kept for major changes of the kernel <lfam>But, we could use CONFIG_LOGO_LIBRE_CLUT224 via the Scheme interface to kernel options, and then it will be agnostic to the source of the sources <lfam>I think that's the best approach for cases like this <lfam>And anyways, that will make it easier to apply our logo / graphics <apteryx>it's a bit dangerous to stuff things in the Scheme interface, as kconfig dependency resolution doesn't happen then; but for simple things which do not have any dependencies, I think it's fine. <lfam>Yeah, I'm not familiar with the CLUT224 dependency graph, but hopefully it doesn't have one <lfam>Overall I'm wary of having two interfaces for configuring the kernel, but my knowledge of this stuff is still pretty thin. <lfam>Like, I only started doing this task because it hadn't been done in several months <lfam>I have no particular expertise here <lfam>Mainly applying "Chesterton's fence" since Mark did a great job before me <lfam>It hadn't been done in several months and I wanted to deploy a feature in a new kernel (wireguard) <lfam>So, it was purely self-motivated <apteryx>so after I've tested each kernel variant boots in a VM with my proposed changes on x86_64, are you OK with me pushing it? <apteryx>I've been running on the latest kernel for many days using the Audigy card with no issue. <lfam>I was going to say, please also reconfigure and reboot :) <aadcg>I installed guix 1.0.0 on a machine and guix pull gives me 'SSL certificate is invalid' - why is that? <apteryx>lfam: OK, I'll try to do it tonight perhaps. <lfam>aadcg: It's because Guix 1.0.0 is several years old, and the copy of the certificates that it includes will be obsolete now <aadcg>can I update the certificate? <lfam>aadcg: You can update the certificates manually, but it's not trivial. Do you know how to define and use custom packages? <aadcg>lfam: I think I see how I could go about it <aadcg>for now the url flag will do it <aadcg>I used this image since 1.3.0 didn't work for me <aadcg>my understanding is that that image lacks a partition that boots in old legacy BIOS mode <lfam>Hm, I don't know about that <lfam>I could boot the 1.3.0 installer on an old thinkpad. I don't know if that's "legacy BIOS" or not <aadcg>I will write a bug report about it eventually <lfam>aadcg: Okay. Remember to search existing bug reports first. 1.3.0 is also getting old and your problem might have been fixed since then <aadcg>are you on that old thinkpad now lfam> <lfam>It's running, but I'm not typing on it right now <Guest6>before I bug guix-devel@gun.org: is there a way to set the permissions for the symlinks guix-home makes? openssh won't recognize my ~/.ssh/authorized_keys because guix home created it with 777 permissions <aadcg>do you have a /boot/efi folder on that machine? <aadcg>hmm, so that implies you have a legacy BIOS too <apteryx>lfam: you can mark it as blocking the release if you deem it's critical (I don't currently lack the context) <lfam>Guest6: That sounds like a bug. I would report it to <bug-guix@gnu.org> <lfam>apteryx: Just done, and I'll follow up with a message to the progress tracking ticket. The context is complicated but there was consensus that we should do this <lfam>aadcg: The 1.3.0 installer *did* have many bugs. So although it boots for me, I can't say if it would complete the installation process successfully or not in all cases <gbrlwck>lfam: package i3-wm has a version field "4.20.1", i3-gaps inherits from i3-wm but has it's own version field "4.18.3". <lfam>There were releases between 1.0.0 and 1.3.0, however. It won't be trivial to upgrade your system to the current Guix from 1.0.0, although it's possible of course. <lfam>I see gbrlwck. Inheritance strikes again (I think inheritance is error-prone) <gbrlwck>i'm trying to compile guix to check whether that fixes anything but i'm having issues (gnu/packages/bison.scm fails to load) <lfam>You're building Guix from a Git checkout? <lfam>What do you mean by that? <lfam>Wait, you're reading a different section of the manual <lfam>Did you follow the instructions in Building From Git? <lfam>I know :) Just go the section Building From Git, it doesn't matter if you are using the 1.3.0 manual or the devel manual <lfam>You can start at the part that says to do `guix environment guix --pure` (from the 1.3.0 manual) or `guix shell -D guix --pure` (from the devel manual) <lfam>I will try to build a fresh checkout now, from the 1.3.0 manual <kaelyn>Hi #guix, I'm a bit new to the guix store internals, and I was wondering if I could get some pointers on where to start debugging intermittent errors from "guix subsitute". Basically I have several local systems running GuixSD with local substitute discovery enabled, and I periodically have commands like "guix pull" and "guix system reconfigure" encounter exceptions in the substituter. <gbrlwck>might be cool to have the "make clean-go" message appear when `make` fails, no? <lfam>It's rarely the solution to a compilation failure <lfam>Hi kaelyn, I think there have been some reports on the mailing lists about this recently <lfam>I recommend checking the archives of guix-devel, help-guix, and bug-guix (or issues.guix.gnu.org) <aadcg>lfam: even the 1.0.0 installer didn't work for me. but I can install it manually :) such tools are of course very important but hard to get right <kaelyn>I'll need to check the others, but I'm subscribed to guix-devel (and saw when a substitution fix for I th <kaelyn>think some "expecting exact integer" errors, but I'm getting two or three different errors with the latest from master) <lfam>So far, I think there are only hypotheses about this problem <kaelyn>Sometimes I get "Wrong type (expecting exact integer): #f", sometimes an unexpected path from the substituter, and sometimes an error parsing an HTTP 200 resoi <lfam>I think people suspect a timeout on the substitution server caused by slow I/O, that leads to a condition that is not handled by the client <lfam>But, as far as I can tell, we've only get hypotheses <kaelyn>I don't have that error at hand, but yeat it seemed messed up to me. :) <kaelyn>The machines I have are all fairly modern hardware, and have either sata SSDs or NVMe drives, and I haven't found anything consistent other than the one laptop on the wireless is more likely to hit errors (when it is on) than the others. <lfam>By "slow" I mean "too slow for our code". Not slow in an absolute sense <lfam>But, it's just a hypothesis <lfam>apteryx: Do you have a sense of the status of the current berlin GC? Like, are we planning to let it finish? Kill it again as we have often been doing? Etc <lfam>Also, how is the process of populating the new storage going? <kaelyn>Right now when one of these errors happens, the only information I have is what is printed out to the terminal. I haven't figured out where to find more details (e.g. on the serving side) or even the original error. The system logs in /var/log/ don't seem to have much in them. Basically, I don't know where to start in tracking it down since I don't have a reliable way to reproduce it on demand. <mrwater>Can't check signature: No public key <sneek>Welcome back notmaximed, you have 1 message! <kaelyn>lfam: also, thank you for the suggestions and hypothesis :) <mrwater>Somehow I'm not used to the public key straight up not being there. Usually I run verify and it says something about how the key can't be verified, but here's who it was so you can look em up <gbrlwck>lfam: i am able to build i3-gaps without a hassle. shall i post a patch to guix-devel? <lfam>mrwater: Yeah, there's always something with PGP / GPG <lfam>Anyways, you have to fetch the key, either from the canonical source on Savannah, or *maybe* from a keyserver <lfam>But since the keyservers are mostly defunct, it's becoming less likely to find keys there <gbrlwck>but first i have some questions: is it impossible to omit the (version "foo") field in a package that inherits? when i omit the field in i3-gaps compilation (i guess of wm.scm) fails <lfam>gbrlwck: The (source) field uses the VERSION, right? <lfam>Then you need VERSION :) <lfam>You could omit both the version and source fields, for example to make a package variant that changes some build options <lfam>But since this package uses a different source, you need a version to construct the uri <gbrlwck>but i3-wm uses the "official" one from their webpage. <lfam>I mean, it literally has a different (source ...) field <lfam>The hash is different, and maybe the uri <lfam>The Airblader repo is a 3rd-party <lfam>Anyways, that's not the point <gbrlwck>i see. i got confused bc the repos are both called i3 <lfam>You can't have a source field that references a version variable without defining the version variable, as you experienced <lfam>Even though the inherited package does have a version that is inherited, I guess the use of version in the i3-gaps source is made use of in a different way <lfam>It's a question for Scheme experts, of which I am not one <jpoiret>I was preparing a patch for that but I got lazy and just removed i3-gaps from my config since I wasn't using it anyways <jpoiret>basically, inherited fields can be considered as "appended if not present" so you can't reference inherited fields, yeah <jpoiret>it'd be better if you could also switch url-fetch to git-fetch as well <mrwater>is the guix graphical installer decent? <lfam>mrwater: There were a lot of bugs in the 1.3.0 installer. If you followed the "happy path", it did work, but complications around the bootloader, partitions, etc, could cause it to fail. Manual installation *always* works <kaelyn>just to close the circle a bit, I found https://issues.guix.gnu.org/53668 from a few days ago that looks to be the issue I'm seeing. I may see how challenging it is to roll out the updated guile-ssh package for testing. ;) <lfam>mrwater: We are putting a lot of effort into the graphical installer for the upcoming 1.4.0 release <lfam>It contains a lot of fixes since 1.3.0 <gbrlwck>jpoiret: out of curiosity: why is git-fetch considered better? <lfam>You can do some neat package transformations on Git sources <lfam>On the other hand, we have to be careful to stick to tarballs for packages that Git depends on <lfam>Git is a huge and complicated package <lfam>Probably one of the most complicated Guix packages <dongcarl>Would love to have mingw-w64 build working again at least before the next release (currently they are all broken) <lfam>Git sources can be waaaay bigger than tarballs, depending on the features of the Git server <lfam>dongcarl: We can make this a release blocker <lfam>We shouldn't release with major features that don't work at all <lfam>But, it will be a case where we either fix the feature or remove it <lfam>The fix looks simple though, so don't worry :) <dongcarl>lfam: Oh that'd be excellent. Yeah the current patch fixes it, I'm just wondering if someone would have the expertise to look deeper and look at the underlying problem. <lfam>I figure that would be you :) <lfam>Or else, you should contact the people who've touched this feature in the past and ask them for help <lfam>I guess this was broken in core-updates? <dongcarl>Perhaps it'd make sense to have the CI run a mingw-w64 build of the hello package for detection in the future? <lfam>dongcarl: I mean, the problem was introduced when we merged core-updates? <lfam>I'm trying to figure out when it broke <lfam>Like, `git log --grep enable-compressed-debug-section` returns a commit from December 17, and that's right around the end of the core-updates cycle <gbrlwck>lfam: should i submit the patch to guix-devel or guix-patches or both? <lfam>It's starting to look like you might be the only user of this code, but we can't be sure about that for 1 or 2 more months or no complaints <lfam>gbrlwck: guix-patches, of course! <lfam>Where else to send a patch? :) <apteryx>lfam: possibly the merge of the 1.4.0 branch; this is where the binutils-next was merged into binutils <lfam>Anyways dongcarl, you should solicit reviews directly from people you think might use this code or who understand it <gbrlwck>lfam: i earlier asked whether i should submit to guix-devel and you answered yes :) <lfam>Otherwise, I can tell you based on experience, your patch will probably not get reviewed <lfam>Okay, okay , mea culpa gbrlwck :) <lfam>Either place will work, but we prefer guix-patches <lfam>dongcarl: Can you say if your patch causes a mass rebuild of all packages, on non-mingw platforms? <lfam>That's something that reviewers will want to know and it's helpful, from a psychological perspective, if patch authors say so <dongcarl>lfam: Okay good to know, will post something. I don't think it will, because native packages are not dependent on the cross-base procedures at all <lfam>Okay. You can see how little I understand about this stuff, but I'm the person that is triaging the patch <dongcarl>I intentionally put it in cross-base to avoid mass rebuilds <lfam>So you ge ta sense of how much you have to "own" the review process <dongcarl>Of course! I will post something in the thread! <lfam>You will have to be the expert, or marshall past experts as I suggested :) <gbrlwck>is there an ETA of when this is merged into guix? *lfam feverishly refreshes their inbox <lfam>#guix is really busy, so we have a higher frequency of problems <lfam>Not sure if that's good enough for what you're missing, but they are linked to from there <vagrantc>i did miss it on contribute somehow ... i had figured it'd be easy enough to find from the main page :) <vagrantc>not sure i have a recommendation that would make better sense than contribute ... i did skim that page over <lfam>I wouldn't mind if Contribute was a top-level menu <lfam>Oh, there's a huge Contribute button above the fold <lfam>Still, it could be a top-level menu, too, maybe <lfam>Of course, it's perfectly clear, if you read <lfam>But we are talking about not reading ;) <vagrantc>i knew i could find it browsing sv.gnu.org, just figured it'd be easier to find it from the horse's mouth, so to speak *vagrantc has let u-boot lag a bit <vivien>I have a few patches that don’t directly apply anymore because someone wrote another package just before; fixing the conflict is trivial, should I send an updated version anyway? <vivien>(someone wrote another package just before in the same module) <apteryx>vivien: that could be seen as a gentle ping, and will make it more likely to be applied quickly, but it's up to you :-). <lfam>Agreed with apteryx. It's courteous to maintain your pending patches, as it's easier to rebase commits than to figure out how to apply stale patches <lfam>Generating the patches with the --base option can help, because it tells reviewers what revision your patches apply to <lfam>You can think of this as the first step in maintaining your packages <aadcg>lfam: passing the url to guix pull works but then the dependencies of compute-guix-derivation couldn't be built. does that make sense> <vivien>I forgot --base :S Next time I won’t omit it <apteryx>perhaps you can have it on by default in your global .gitconfig <nixo>Hi guix! Recently anki on guix stopped displaying text, anybody experienced the same issue? <vivien>apteryx, I think I configured it, with git config format.useAutoBase whenAble <nalaginrut>hi falks, anyone ever upgrade solidity with "guix refresh -u solidity" ? <nalaginrut>I got an error: guix refresh: error: mkstemp: Read-only file system <florhizome[m]>I actually went to the guix repo over the packages overview in the start to look things up^^ <florhizome[m]>(which, btw, would be so much greater with a search function...) <florhizome[m]><nalaginrut> "I got an error: guix refresh..." <- I had this after the core updates frozen merge... <florhizome[m]>I don’t remember exactly what fixed it, unfortunately, but I remember deleting guile’s cache directory... <mwette>^ by "flooded" I mean the page never completely loads; I had to kill the tab. <mbakke>nalaginrut: 'guix refresh' needs to be run from the guix git checkout, i.e. './pre-inst-env guix refresh -u foo'