***rekado_ is now known as rekado
<apteryx>rekado: currently things are as we left them last time -- we'd need to edit the GRUB menu entry manually to return to the current generation. <apteryx>Perhaps I can revert the last failed bits pushed for the config that were supposed to transition it to the new RAID10 array, reconfigure, and then we should have something rebootable without this kludge <PotentialUser-59>Is there a way to have grub-efi-bootloader install to `boot/bootx64.efi` instead of `Grub/grubx64.efi`? My systems bios forgets efi entries often <atari_database>What are the minimum hardware requirements for installing 64 bit Guix? <kitty2>atari_database: I'm not sure, but I don't think it requires much at all given how many people here use old laptops <kitty2>with wifi and GPU drivers assuming you use those :P <atari_database>kitty2 What are the specs on your machine, and does it run well? memory, processsor, speed, hd capacity? <kitty2>I'm on a reasonably modern computer ; when doing most tasks I only use like 1% of my CPU lmao , I don't think guix takes any more than any other linux distro so I guess it just depends on what you do on the computer, yknow? <kitty2>that is, apart from making sure everything works well with linux-libre <kitty2>np ; if you have any more specific questions hopefully someone who knows more could answer haha , I haven't exactly tried guix on a large amount of hardware, just through it onto my desktop lmao <kitty2>threw it on* like, a bit over a year ago I believe? <atari_database>I'm buying a used laptop soon...buying specifically for using Guix, so just want to make sure it's powerful enough <Christoph[m]>I tried guix shell --pure ghc@4.08.2, and guix shell does a great job hiding everything else. So well that when I try to use ghc, it tells me that it cannot find cat and rm. How can I find out which package contains rm and cat? <jackhill>Christoph[m]: they're in coreutils. What I did was follow the symlinks from a different profile where they were present (in my case /run/current-system…) <jackhill>Christoph[m]: out of curiosity, what are you doing ith ghc 4? Ordinarily, the fact that it doesn't retain a reference to corutils could be a bug, but I think we have it primarily for bootstrapping, so it's probably ok <Christoph[m]>jackhill: I'm actually interested in ghc 8.10.7, which is the latest one packaged in guix. But that one cannot find gcc. So I looked up previous versions of ghc to see where it stopped working... <jackhill>Christoph[m]: ah, I think you might find a newer one works, althougth they may all have that bug? I remember running into something like that before I got distracted… Anyway, the history is that our GHCs where bootstrapped from a 6.x or 7.x binary for a while. 4.x was added reletively recently. <Christoph[m]>Is there no way to ask guix for packages that contain a given command? ghc@7.10.2 asks for as, which I don't have in my profile, so there's no symlink to follow. <jackhill>Christoph[m]: maybe someone can correct me, but I don't think that exists yet. With `as` you'd probably be fine poking around /gnu/store with find (althoguh maybe not efficiently), but in the general case you might want to find stuff that you don't have locally, so the ci server could build some sort of index. I think it's been discussed a number of times but not build. <jackhill>Guix seems to be a little bit more fluid that e.g. debian which I suppose complicates the problem a little bit. <jackhill>Christoph[m]: you're welcome, good luck on your adventure! <Christoph[m]>I tried guix shell --pure without any packages, and guix printed the empty environment warning twice. <Christoph[m]>Then I typed ls and got 'command not found', of course. So I type 'exit', and now guix shell complains that it cannot find bash. <jackhill>oh, interesting, but exit works if you don't ls first. My guess is that guix is looking at the exit code of the shell when it exits, and bash is massing on the command not found code from the ls try. <jackhill>not 100% sure that's what's going on, but sounds good to me :) <zamfofex>I have noticed someone in the mailing list has recently shown interest in updating glibc. <zamfofex>I was wondering if it would be possible for me to somehow help start an effort towards it. What would be the recommended approach to start? <zamfofex>Say I update glibc locally and manage to get it to build, what would be a good way to verify how much it ends up breaking? <zamfofex>And suppose I manage to reduce breaking changes enough, would it be sufficient to send a patch? Or are there any other protocols that need to be followed? <MaNI>hi, I'm trying to use guix but keep getting "operation not permitted" mount errors, is there an easy way I can get more info on why this is happening? <MaNI>guix environment: error: mount: mount "/etc/nsswitch.conf" on "/tmp/guix-directory.nKI6sg//etc/nsswitch.conf": Operation not permitted <xelxebar>MaNI: What does `ps u $(pgrep guix-daemon)` output for you? I'm guessing the daemon might not be running as root? <MaNI>sadly it is root, "root 4822 0.0 0.0 8820 4884 ? Ss 08:10 0:00 /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild" <xelxebar>MaNI: Okay. Can check that one off the list. And do the perms on your /tmp look reasonable? <abrenon>MaNI: what is the context ? are you using Guix System or guix on another distro ? Is it the first time you're trying containers environment ? <MaNI>guix on another distro (gentoo specifically) and yes its the first time trying it <MaNI>xelxebar, permissions for tmp are (drwxrwxrwt) which is AFAIK normal <abrenon>does that bind mount work on its own ? (as in, can you create a file down in /tmp and mount --bind /etc/nsswitch.conf on it as root ?) <xelxebar>Yeah, does tmpfs take some (security) options to prevent mounting inside? On Guix System, I know /tmp is mounted without noexec. <Nazar>Hello there, does anybody konw is there ability to use pipeware in guix ? <PaulePanter>I installed Guix on Debian sid/unstable with `sudo apt install guix`, but when I run `guix install r` it installs 4.0.4. <civodul>PaulePanter: hi! that's because the Guix package on Debian is relatively old <civodul>you'd find need to run "guix pull" to update it <civodul>and from there, "guix install r" should give you the latest version currently packaged <civodul>there's the default "guix" channel, and there are additional channels providing more packages <PaulePanter>So, I could access r 4.1.3 also by adding the channel, and not updating guix? <civodul>no, because r is part of the "guix" channel, which is the set of channels that come with Guix <civodul>IOW, the package manager and its collection are not decoupled as apt and Debian are <abrenon>I had never thought of it that way, why this design ? <MaNI>abrenon, yes mounting works fine if I just do "sudo mount --bind /etc/nsswitch.conf /tmp/footest" <PurpleSym>Is there an example somewhere how to use gexp inside a nginx service declaration? I’m trying to define a server root based on a package. <civodul>MaNI: what about "touch /tmp/foo && unshare -mrf mount --bind /etc/nsswitch.conf /tmp/foo" as non-root? <civodul>PaulePanter: did you run "hash guix" etc. as advertised? <MaNI>civodul, it runs without error but I don't see a mount afterwards <PaulePanter>“Consider” in “hint: Consider setting the necessary environment variables by running: <PurpleSym>civodul: Ah, thanks. So it seems I’ve been using #~ at the wrong “level”. For an nginx-location-configuration’s body the gexp must be a list element. <civodul>oh, maybe wording is suboptimal here <PaulePanter>Generation 1 Apr 08 2022 10:11:04 (current) guix 1d4f2cd <civodul>MaNI: so that suggests user namespaces work as expected, so i'm not sure what's going on <abrenon>I suppose all that can go wrong is located in the code handling containers ? so it should fail exactly the same way trying guix shell instead of guix environment <civodul>guix doesn't have a "load-profile" command; you're looking at unofficial documentation <civodul>PaulePanter: to start r, you can run: "guix shell r -- r" <PaulePanter>I didn’t do . "$GUIX_PROFILE/etc/profile", as I missed the path changed. <PaulePanter>Unrelated, so to manage different versions of the same package, it’s not so easy with guix either? <PaulePanter>Our scientists would like to have access to different version of R, for example. Or would they just manage that using the right profile paths? <civodul>PaulePanter: users can "pin" channels to a specific revision; so for instance, you could do "guix time-machine --branch=version-1.3.0 -- install r" to install the "old" R version, with its old dependencies <MaNI>civodul, I did see that but as its a year old and theres a fix in the thread, and given I only installed today, I assumed that I must already have whatever fix that was (so presumably not the same issue) <civodul>MaNI: yeah, it was apparently fixed before 1.3.0 <civodul>to be sure, could you try with the latest & greatest? <civodul>like so: guix time-machine -- shell -C coreutils <civodul>MaNI: if that doesn't work, could you email bug-guix with the same kind of info found in the bug report above? <MaNI>this seemingly works, or at least it lands me up in a shell (I don't know if theres something else I should test after that) <civodul>MaNI: ah; you can check that that shell indeed runs in a container <civodul>for instance, apart from $PWD, very little should be shared with the host system <civodul>your home directory should be empty except for $PWD, and so on <MaNI>this appears to be the case yes ***wielaard is now known as mjw
<MaNI>given the above, any idea how I can get from there to it working without specifying "time-machine"? <AwesomeAdam54321>MaNI: Since the guix time-machine command you ran used the newest guix, I think getting the newest guix by `guix pull` should work <MaNI>AwesomeAdam54321, yes I thought so but I did "sudo -i guix pull" and then restarted the systemctl daemon and still the same issue <AwesomeAdam54321>MaNI: That's because you upgraded guix and guix-daemon for root, not your user <MaNI>I ran"guix pull" as user as well <civodul>MaNI: then make sure "type -P guix" points to ~/.config/guix/current/bin/guix <civodul>normally you got a hint explaining how to do that at the end of "guix pull" <MaNI>yes, it does point there <xelxebar>Ew... the freerdp package propagates openssl and wayland. That smells like a bad workaround. Currently, I cannot have both freerdp and openssl packages in my manifest because of it. <civodul>uh indeed, those propagations should be removed in favor of a better fix <civodul>PaulePanter: BTW, if you're using Guix in a scientific or HPC context, you might be interested in joining the guix-science mailing list or #guix-hpc IRC channel: https://hpc.guix.info/about/ <MaNI>oh wait it is actually working now, the pull did fix it, okay thanks for the help! <PurpleSym>Is it possible to add more supplemental groups to an existing (system) user provided by a service, i.e. “nginx”? <fiesh>hmm after a pull and system reconfigure, I now get like 20 to 30 "nothing to read on input" (or similar) messages instead of the password prompt for my luks home device <allana>Hi #guix! Say that I am using a variant of python that I call python-alpha. Is there a nice way on the command-line to enter a guix shell like "guix shell python-alpha" with other python packages that use a graft to my python variant? <allana>Nevermind! "guix shell --help-transform" <civodul>jonsger: it could be that the Xapian indexer has not running for a while <allana>Nevermind about my nevermind. It turns out that just building a custom python interpreter is not enough to get other libraries. looking at ways of setting my own default-python <civodul>jonsger: according to mcron.log on that machine, indexing seems to be happening as expected <civodul>allana: you could try --with-input=python@X.Y=python@A.B, though it may be very expensive <allana>I used this, but python build system seems to try to install to the wrong site-packages. For example I built python 3.11 (alpha) and when replacing inputs I see 3.9 in the site packages path <allana>Or at least I did somehting similar -- let me see if the @ syntax has an effect <apteryx>nckx: soon we'll be able to build many fonts from source I think :-) ***ZhuZihao[m] is now known as ZhuAisi[m]
<f1refly>is pipewire supported as audio service for guix? <ZhuAisi[m]>There's a plan to replace pulseaudio in %desktop-services with pipewire <f1refly>so it'll come automatically eventually? <zamfofex>Hello, Guix! At the expense of sounding repetitive, now that there are more people online, I wanted to ask once again about updating glibc. Here is some context: <https://logs.guix.gnu.org/guix/2022-04-08.log#060309> TL;DR: I wanted to help update glibc, but I’m afraid of starting the wrong way. Is it sufficient to update the package definition and submit a patch? How do I test whether it breaks too many packages? <civodul>zamfofex: hi! testing 20K packages is not feasible, unless you have a build farm at home :-) <civodul>but it'd be great if you could at least test core packages <civodul>as in: ./pre-inst-env guix build coreutils grep sed guile <zamfofex>I see! That’s fair enough. I suppose I thought maybe there would be some way to determine a (larger) subset of packages that would be a good indication of potential issues. <zamfofex>Also, is it correct to assume that I should apply the update to the ‘core-updates’ branch? <apteryx>so the font data files are produced with FontForge it seems <zimoun>civodul, the cost of --with-c-toolchain=python=gcc-toolchain@7 is not the same as “build -m manifest.scm” where manifest contains the transformation. A different default? Or a bug between my chair and my keyboard? <apteryx>civodul: well done for fixing the LUKS issue swiftly! <civodul>zimoun: oh? i'd need more details, i'm not sure i understand <kitzman>just so i make sure - i'm trying to provision a hurd VM with guix deploy (building stuff on a hurd VM is not feasible). the only way to do this would be to use another i586 vm running linux, right? <zimoun>civodul: Using the manifest, it almost rebuilds the world. From the CLI, it seems doable. To be concrete, I did using CLI, done, then redid using manifest and… kill before the end. Maybe I am doingg something wrong, since the inspection is something, the first question is: is it the same default? (deep? etc.) I mean maybe it is well-known by it is the same default. :-) ***KimJongWell is now known as discoking
<civodul>zimoun: that sounds bad; but yes, there's a one-to-one mapping between the CLI and 'options->transformation' <zimoun>civodul: let me check my next remote meeting. ;-) Ok, I will investigate more next week so. <zimoun>ekaitz: Thanks! The best example ever I know about a really simple code using only integer and returning different values depending on the compiler version https://godbolt.org/z/PfYMje7ee Now the question, where do these binary compilers come from? :-) <ekaitz>zimoun: the compilers come from the fairies of the forest <ekaitz>they were created at the beginning of the times <PaulePanter>Hi. With R from Guix, the user reports, that installing R packages does not work. <PaulePanter>I would have thought, it’s a network problem, but just wanted to make sure Guix doesn’t prevents installing R libraries somehow. <ss2>Which is more customary for sending v2 patch series? Do I open a new issue, or do I send it to the same issue that contains v1 of patch series? <flaminwalrus[m]><PaulePanter> "I would have thought, it’s a..." <- "guix import cran pkgname" <flaminwalrus[m]>The nature of guix means certain package managers, which output files to XDG paths, break. That command should give you a .scm package definition to start from. <ss2>sending to same issue. <fiesh>hmm yeah, so I get 32 times "Nothing to read on input." after a system update now instead of the prompt for my home's luks password <fiesh>(is there some nice way to git bisect the change that led to this?) <zimoun>ekaitz: hehe! That’s just gcc-toolchain@4.8 fails on my machine and 4.7 is not available with Guix, for instance. <ekaitz>zimoun: I opened an issue with that at Guix, they both exist. The 4.7 is a hidden package but you can unhide it using a manifest (LOL), but also fails. That happens (I think) because we updated the libc and those compilers are not compatible with our libc version. <ekaitz>As I said, I added an issue, but nobody seemed to care about it :) <apteryx>which in guix is in the expat package <civodul>mbakke: -O2 in nginx, well done! i think we've been unwillingly doing -O0 builds in a number of places... <fiesh>hmm I'm baffled how hard this is... everything's git, but I can't manage to bisect. Is there no support for this at all? <zamfofex>civodul: glibc 2.34 and 2.35 don’t include ‘libdl.so’ anymore, only an empty ‘libdl.a’ and an empty ‘libdl.so.2’, so building Bash fails with a missing ‘-ldl’. Should I make it create symlinks to the ‘.so.2’ file like there used to be, or should I instead ensure there is also a ‘.a’ file in the non‐‘static’ output too? (Likewise for the other now empty files too.) <zamfofex>sneek: later tell civodul: glibc 2.34 and 2.35 don’t include ‘libdl.so’ anymore, only an empty ‘libdl.a’ and an empty ‘libdl.so.2’, so building Bash fails with a missing ‘-ldl’. Should I make it create symlinks to the ‘.so.2’ file like there used to be, or should I instead ensure there is also a ‘.a’ file in the non‐‘static’ output too? (Likewise for the other now empty files too.) *vagrantc eagrely awaits C.UTF-8 locale in glibc 2.35 <zamfofex>fiesh: You could just clone the repository and verify the changes manually, though, no? <mbakke>fiesh: there are ways to bisect, but not currently integrated with Guix <mbakke>fiesh: you can use gits bisect machinery and do e.g. 'sudo -E ./pre-inst-env guix system reconfigure ...', or 'sudo guix time-machine --commit=$(git rev-parse HEAD) -- reconfigure ...' for each step <fiesh>zamfofex: no I was talking about some actualy git bisect process integrated into guix <fiesh>mbakke: ah ok, thanks.. where's this pre-inst-env? <fiesh>mbakke: thanks. that would mean I still have to do the bisect process in a separately cloned repository, right? <mbakke>zamfofex: providing the empty .a files in the default glibc output SGTM <fiesh>I think I underestimated how long this bisection will take for its approximately 11 steps :-) <fiesh>can I simply delete entries from /var/guix/profiles, or is there a correct way to do this? <mbakke>fiesh: 'guix gc' is the correct way to clear old entries, but it will make bisection even slower (because you may be throwing away store items that you need at a later step) <mbakke>some steps should be less computationally expensive though <fiesh>mbakke: oh I thought system delete-generations was for the profiles!? <fiesh>(and gc would only remove things that were in no profile any more) <mbakke>fiesh: oh right, 'guix system delete-generations' and 'guix package -d' are indeed better tools (guix gc -d can emulate the latter and do gc in one step) <fiesh>mbakke: anyway, thank you for the short primer, my bisecting process is working smoothly albeit obviously slowly and tediously as is any manual bisect, and even worse one with the reboot of an actual hardware device <Cassio>I'm about to try using `guix home`, but I need to understand something I couldn't sort out from the documentation. My home environment will set a new profile, appart form my user's `.guix-profile` or my home configuration becomes my default profile? <bjc>from what i can tell, profiles and home environments coexist <bjc>you'll have .guix-home *and* .guix-profile <bjc>at least that's how it is for me <Cassio>does that mean that when I log in I log into my original profile, and then I need to call `guix home` to enter my home environment? <bjc>no, guix home sets up your environment much like the profile does <bjc>so you just log in, and all the stuff in .guix-home is added to the path, etc <Cassio>So I can delete my original `.guix-profile`, right? <bjc>i uninstalled all my packages, but i didn't delete the directory <bjc>you can still use that for packages installed the old way, not managed through home <Cassio>OK. I was thinking that if I deleted my old profile then the corresponding store would be able to be garbage-collected... <bjc>i'm not sure you can delete your default profile <bjc>but if you uninstall everything, or rollback to gen 1, it'll get gced <Cassio>I don't plan to install anything imperatively anymore, so I think I won't need to `guix package -i` <bjc>it doesn't hurt to leave the directory there, and i'm not sure what happens when you remove it <bjc>(it might be harmless) <bjc>the docs suggest using ‘guix package’ in home scenarios for testing things to see if you want them in your home settings <bjc>so a quick install to try stuff out, then uninstall later after you've either decided you don't like it, or add it to your home config if you do like it <Cassio>Thanks then, bjc, you cleared up all my doubts. <podiki[m]>docker-compose build fails with the pyyaml update (too new) <podiki[m]>I think that is folded into newer docker than what we have guix <apteryx>docker-compose can perhaps be updated to work with it <kaelyn>I also just discovered awscli fails to build because of the pyyaml update (in addition to hitting the issue building docker-compose) <podiki[m]>docker looks like a beast to update, but newer version I think has the more recent docker-compose tool folded in? <planglois>I also don't know much about docker though, I'm not sure how the main package interacts with the docker-compose package <podiki[m]>I guess "docker-compose" vs "docker compose", a v2 <planglois>podiki[m]: I see, so in Guix we only have the older docker-compose python implementation, and they must have moved other to a new one built in Go? <podiki[m]>seems like it, not sure the use cases or if it makes sense to keep both or only the newer "docker compose" v2 (part of docker not a separate package?) <podiki[m]>if you have your locally built docker update, you can see if "docker compose" is a command <planglois>I'll check! There's some mention of docker plugin packages, so we might have to package plugins if those are useful <podiki[m]>I see arch has a "docker-compose" package too, so maybe can build it separately still <planglois>plugin systems can be tricky to package, I wonder how docker finds the plugins <planglois>ah yeah, arch has it, it seems to install a /usr/lib/docker/cli-plugins/ dir <podiki[m]>planglois: right, and hopefully some env variable we can use as a search-path <podiki[m]>well the importer with -r is taking quite a while.... <podiki[m]>error on finding some tag for some dependency :( <singpolyma>Yeah, every time I use the go importer I find a new bug to report or patch to submid <singpolyma>Actually I think the tag one is fixed, but my patch isn't merged <podiki[m]>does it make sense to have pyyaml v5.x as a hold over? or will modifying a package to accept v6 in requirements be okay? <rekado>podiki[m]: it’s tricky because of propagation <rekado>when we have packages that use version 5 and use them in environments that use version 6 Python will get confused and just pick the first it encounters <rekado>so ideally we would not keep pyyaml 5 anywhere <podiki[m]>oh right, forgot about python and propagation for libraries <singpolyma>rekado: shouldn't normally propagate all the way to environment yeah? Because tools will wrap <rekado>problem is not with the user’s environment but with whatever the python process ends up loading <ss2>Has something changed in regards to offloading? <ss2>an updated host now refuses connections. <kitty2>Yknow, this is far less important , but a while back I remember someone asking some questions relating to their attempts at running Guix/Hurd on real hardware ; wonder how they are going ***mark_ is now known as mjw
<vldn>guix runs just fine on real hardware.. don't know much about hurd @ kitty2 <vldn>maybe lot of driver problems <kitty2>vldn: Yeah ; thats why I am curious how they are going, given Hurds ghastly never-quite-alike yet never-quite-dead nature :P <kitty2>its, kind of a shame there isn't more attention on projects outside of linux; wish BSDs, Hurd, and slightly less posix things like plan9 etc. had more attention lmao , suppose the BSDs are fairly used but sadly nothing guix/nix like on those yet as far as im aware... <Guest28>civodul: how about implementing guix package -u --only-substitutes ? (similar to -no-substitutes) Would be useful for guix's version of an unattended-upgrades service. on help-guix there's a subject: "guix pull; guix package -u; sudo guix system reconfigure /etc/config.scm" which complains about 6hrs to complete. <sleepydog>i don't see why it couldn't. perhaps the sandboxing features wouldn't work out of the box <vagrantc>Guest28: it has been proposed for years, but i suspect hard to actually implement in a way that actually does what people expect it to do <vagrantc>the closest thing is the hooks that pull to a revision with a set of desired packages <kitty2>sleepydog: as far as I am aware no ; although ngl I would really like to see it. <Guest28>In the thread on help-guix someone answers: "guix weather `guix package -- <Guest28>list-installed | cut -f1`". If it says 100% substitutes are available, <Guest28>I run "guix package -u", otherwise, I wait a few days and do "guix <Guest28>pull" and "guix weather `guix package --list-installed | cut -f1`" <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, zamfofex says: glibc 2.34 and 2.35 don’t include ‘libdl.so’ anymore, only an empty ‘libdl.a’ and an empty ‘libdl.so.2’, so building Bash fails with a missing ‘-ldl’. Should I make it create symlinks to the ‘.so.2’ file like there used to be, or should I instead ensure there is also a ‘.a’ file in the non‐‘static’ output too? (Likewise for the other now empty files too.) <Guest28>vagrantc: right. it shouldn't need to be that awkward is all Im saying. <civodul>zamfofex: "everything" depends on -ldl; what is Bash specifically failing? <zamfofex>civodul: It is failing because it is early on the bootstrapping process. <civodul>still, you're saying there *is* libdl.so, right? <zamfofex>Note that I followed mbakke’s advice and made it keep the ‘.a’ libraries in the default output too, and now GCC 10 has recently finished building. <zamfofex>civodul: ‘libdl.so’ was removed in glibc 2.34 (along with some others like ‘libpthread.so’) and added into ‘libc.so’ directly. <zamfofex>They kept empty ‘.a’ files so builds wouldn’t break, and also an empty ‘libdl.so.2’. <civodul>well i guess this upgrade is going to be more difficult than usual <alextee>hi, i installed guix using the parabola (arch linux) package but it throws an error when i tell it to install something <alextee>guix install: error: failed to connect to `/var/guix/daemon-socket/socket' ***spk121_ is now known as spk121
<alextee>do i need to start a service or something? <vagrantc>what version is the guix package in parabola/arch ? <alextee>apparently I had to start the service, but i also have to set up the groups and stuff <vagrantc>alextee: i was going to say that should be documented on the wiki page you were following, only to see it is :) <alextee>hmm guix pull says: guix: pull: command not found <alextee>and when i try to install something it says: no code for module (gnutls) <alextee>zamfofex, that won't mess up my current system right? <vagrantc>when was the switch from guile 2.2. to guile 3.0 ? ... that might cause some difficulties <zamfofex>alextee: It shouldn’t. Though now that you have the older version partially installed, it might not work well. <alextee>zamfofex, i can remove it. actually i see it was from AUR, let me try reinstalling the AUR package then it says it's 1.3.0 <alextee>nvm it looks like parabola packages the old version.. i removed that, let me try the binary installation <alextee> [ FAIL ] A previous Guix installation was found. Refusing to overwrite. <zamfofex>alextee: Can you try to remove the Guix files from ‘/var’? <zamfofex>Make sure the daemon you had installed before isn’t running anymore too. <alextee>zamfofex, it's not, the service is stopped <alextee>what other files are there to delete? <alextee>btw I'm trying to update gtksourceview to version 5 <alextee>the current plain "gtksourceview" is on version 4 <PotentialUser-59>After my system shows the console welcome message and login, it takes 30 additional seconds before GDM starts. Is this a known issue? demesg does not have any relevant info. Is there a way I can get more logs out of shepherd? <alextee>should I declare the package as gtksourceview-5? <alextee>note that version 5 uses gtk4 and version 4 uses gtk3 so it should probably be a separate package <zamfofex>Is it a library or an application? If it is an application, I’d imagine it’d be fine for the package name to stay the same. <zamfofex>alextee: Note that you’ll eventually need to build Guix from source to be able to make and test changes to packages. Though it is easier to set up an environment to work on it once you already have it installed. <alextee>I used to do that before but i forgot how <zamfofex>Basically, ‘guix shell -D guix’ then ‘./bootstrap’ then ‘./configure --localstatedir=/var’ then ‘./pre-inst-env guix build hello’ for example. <alextee>should probably run pull and `package -u` before attempting shell <zamfofex>civodul: I was able to build GNU Hello with the updated glibc! Now I’m trying coreutils and the other packages you asked for me to try out too. <bjc>i'm running into an issue with ‘guix home reconfigure’: Cleaning up symlinks from previous home at /gnu/store/k9r1d...4knq-home. <bjc>if i use ‘container’ instead of ‘reconfigure’ things start up fine <bjc>i've tried rolling back to previous generations, and the roll-back is fine, but trying a subsequent reconfigure still fails <bjc>the store directory exists, so i'm not sure what the problem is <zamfofex>I’m not too familiar with ‘guix home’, so take my advice with a grain of salt, but do you have write permissions to the appropriate symlinks that it might be referring to? (I assume in ‘~/.guix-home’ or something.) <bjc>on a somewhat related note: it'd be nice if the ‘--verbosity’ flag values were documented in ‘--help’ <zamfofex>(Or rather, to the directory the symlinks are in.) <bjc>i don't know what symlink it's trying to deal with or clean up. and i can't figure out how to get that informatino <bjc>however, i successfully ran a home reconfigure an hour or so ago after a pull. i only ran into this after adding a couple packages to my config <bjc>(and yes, i put back the old config -- still broken)