<nckx>rekado_: Left ncdu -qx /gnu/store running while I was out. It's at 470 GiB and still counting hard. Explains where that terabyte went!
<nckx>NieDzejkob: It could be ‘memory’-related in that your cache is filled with gigabytes of useless data. Guix could use something like fadvise to say ‘I'll won't be re-reading this stuff; throw it away’, assuming that's true.
<hendursaga>rekado_: Quicklisp still won't recognize it, sadly, even though libssl.so is there :/
<jgart[m]><str1ngs "jgart: but you need to do more t"> Thank you for sharing the example. What is the other work that I need to do to get it to work?
<jgart[m]>I'll share my test.scm since I feel the bug might be in what I am trying to load:
<jgart[m]><str1ngs "jgart: okay, it might be better "> Ok, will do
<vits-test>on Guix, in man ls, ls --color: "'always' (default if omitted)," .. "Using color to distinguish file types is _disabled_ both by default".
<vits-test>str1ngs: Why in nomad it's named (M-x) terminal instead of "shell"?
<alchemi>been doing my first guix package install since last night. mes-boot is taking a while on an M1 invocation (I guess because it's building up a trusted reproducable chain of compilers) but that's okay I'm excited :)
<cheim0>Is the X.509 certificate expired for ci.guix.gnu.org or is it just me? I haven't seen X.509 explicitly mentioned by name in the irc logs or guix issues
<drgibbon>Is Guix a rolling distribution? If running Guix as a distro, is there any distinction between upgrading to the latest release of packages, and upgrading to a new OS release (say 1.0.0 to 1.1.0)?
<nckx>drgibbon: It is entirely rolling, releases are simply (better-tested) snapshots. There's no difference.
<nckx>drgibbon: On Guix System, you configure services (including openssh) through a Scheme file which contains your entire configuration. You then run (say) ‘guix system reconfigure /etc/guix/system.scm’ to apply that configuration. You wouldn't generally touch files in /etc yourself, although in practice, things not yet handled by Guix are.
<nckx>drgibbon: ‘$ guix pull’ (similar to apt update) and ‘$ sudo guix system reconfigure’ (update the system) + ‘$ guix package -u’ (update user packages).
<drgibbon>ok interesting, I'm on Slackware at present, testing guix as a package manager (I installed from binary and did a `guix pull`, it's currently building gcc).
<lfam>You can effectively use the unprivileged single-user's profile for the system-level stuff by doing e.g. `sudo --preserve-env guix system reconfigure /etc/config.scm`, which the --preserve-env being the important part
<rekado>I’m sure it’s big. We were around 90% disk usage when the external storage array became usable.
<rekado>later we also migrated the caches to the storage array
<nckx>drgibbon: Anyway, Guix also does basic deduplication using hard links, so even if you had 1.5 TiB of data in /gnu/store, a lot of it would probably be redundant (many different versions of the same package with many identical files between them) and only stored once.
<nckx>I see free space is at 137G now (nice!) so that lowers the bound. Probably more like half, instead of almost, a terabyte.
<ul22>I've been getting a SHA256 hash mismatch when I try to install racket-minimal. Is this a problem with the package, or is there something I can do on my end to fix this? Tried guix pull to no effect.
<brendyyn>ul22: It's not your issue. It means the upstream racket release has changed unexpectedly
<roptat>the expected version doesn't seem to be in ci's cache
<brendyyn>ul22: Actually, it looks like a mistake was made. The racket package was updated without updating racket-minimal as well.
<drgibbon>what does `guix pull` do on a non-guix distro? I freshly installed guix package manager, did guix pull... and it's building a lot of stuff (might be from the `guix install hello` that I started and then aborted?)
<brendyyn>it does the same thing it does on guix sd. it builds the latest version of guix its self
<ul22>brendyyn: thanks, bug diagnosis is beyond me
<brendyyn>ul22: The reason was that the package definition for racket-minimal inherits from racket, so when racket's version was updated t 7.8, so was racket-minimals, but the updater forgot about that.
<roptat>brendyyn, ul22, pushed. You can now run "guix pull" and racket-minimal will build
<brendyyn>pretty good customer service here at #guix
<drgibbon>roptat: ahh, I didn't change any settings, I'll look into substituions then.
<drgibbon>roptat: yes I was thinking to build everything from source, but I didn't grasp how the whole thing works, I thought I could just install packages one by one, and it would use my local gcc or whatever.
<Noclip>Haha, I think I solved the mystery of my broken guix: Looks like my original assumtion of a corrupt store is totally right:
<Noclip>"path `/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31' disappeared, but it still has valid referrers!"
<Noclip>I already assumed that it had something todo with glibc as basically everything related to guix was totally broken and glibc is the one package that is needed by everything ...
<drgibbon>roptat: much faster with substitutes, thanks :) Is there a way to see all substitutes?
<Noclip>Everything else in the store seems fine. How the hell is it possible that glibc just disappeared from my store?
<ul22>brendynn, roptat: successfully built racket-minimal, thanks again
<drgibbon>just curious, on a new install after running `guix pull` everything was OK, tested `guix pull` again and it says: "Authenticating channel 'guix', commits 9edb3f6 to a2ebc74 (5,153 new commits)..."
<vits-test>efraim: Since this board is 1GB RAM, probably You know how to run Emacs in framebuffer, on tty: but with images working?
<vits-test>links -g works, but Emacs has no images.. That's pity.
<efraim>I don't use emacs and I've been having a suprisingly harder time building native debian packages than I do on ppc, or with using pkgsrc, so I've been letting it work on re-bootstrapping guix using previous versions of guix
<efraim>If it does work out I'll probably just try to create an image to flash to a HDD
<PurpleSym>I’m trying to get our SSSD package into shape. Is there any way to tell glibc to look for libnss_sss.so in a different path built in already? It must work somehow for mdns, right?
*raghavgururajan experienced weired system-wide crash in guix system, reported as #43132
<efraim>raghavgururajan: looks like you're out of space or out of inodes
<leoprikler>Auf der CI bauen zur Zeit Pakete basierend auf emacs-minimal, bei denen scheint aber kein Fehler aufzutreten.
<leoprikler>Ob das für emacs selbst mit allen Abhängigkeiten gilt, weiß ich aber nicht.
<civodul>PurpleSym: yes, you'll need to add sssd to name-services
<PurpleSym>civodul: Done that and nscd loads libnss_sss.so, but name resolution is still not working. No idea what’s missing now :(
<civodul>then you also need sssd running with a proper config, and that i'm not familiar with
<PurpleSym>Got all of that from a working Ubuntu install. Weird.
<alextee[m]>civodul: nckx : re: zrythm, i updated the policy to allow all fsf-approved distros to make any changes needed. i'm just waiting for a meson update to send in the new patch (need 0.55.0 or above)
<peanutbutterandc>civodul, Oh hey Mr. Courtes... yes, grub-install is what the entire process has been getting stuck in... with linux mint, mx-linux, everything... so I'm guessing it's stuck with guixSD too
<peanutbutterandc>..... which probably means that if I am to install a gnu system on this machine, this is no other way but to flash the firmware of this machine. (It only supports UEFI boot and not legacy mode, for some strange reason.... and it's actually in `efibootmgr` call (from within `grub-install`) that this failure occurs: that is what I have been able to gather so far
<peanutbutterandc>Also, if it keeps on getting stuck at this point.... and I kill the machine.... is guixSD already installed? Just without grub?
<brendyyn>peanutbutterandc: my friend had a similar issue, but then it magically solved its self when he plugged in a bootable usb device, because it made it change the boot order
<peanutbutterandc>brendyyn, I have tried everything. Disabled secure boot. Manually copied contents of efi partition, everything.... nothing works
<brendyyn>"everything" is quite a lot more than that
<peanutbutterandc>brendyyn, Yes.... you are right. I've tried everything I could possibly think of (except for flashing the firmware)... It seems UEFI just does not work at all. And Legacy BIOS is just not an option.
<vits-test>peanutbutterandc: I hope You can just return this machine to the store? To not play with this (like me with my ex-videocard).
<peanutbutterandc>vits-test, It's someone else's, and it's already out of warranty, it seems. They used windows so far... so yeah....
<pkill9>what do people think of a way of upgrading a package in a profile such that the inputs of the old version are grafted onto the new version if the version(s) of the old input(s) is the same as the version(s) of the new input(s)? or maybe if the minor version changes. I think it would be pretty neat
<nefix>hello! Is there any way to disable building packages in the local machine and always grab the latest version in the ci?
<c4droid>janneke: I just look the backtrace, the variable `tramp-own-remote-path' is not defined
<nefix>maybe I'll write a script to get the last commit from yesterday or something like that
<apteryx>in theory you could check for substitutes coverage in your channels.scm file, and find the most recent Guix commit that has substititues for all your packages, but I don't think that's easy to do.
<c4droid>janneke: Ok, I just move the push under tramp's :config section, now it worked.
<nefix>it would be really nice to be able to do 'guix weather --commit=<commit>' :(
<tsmish[m]>https://paste.debian.net/1162003/. More atrocious patches. This one allows you to specify a list of trusted keys in channel record that are valid as signing keys for all commits in channel, allowing you to have some local changes without breaking authentication.
***caleb_ is now known as KE0VVT
<simendsjo>I've installed the guix binary using the installation script on Manjaro. Some operations will print `/gnu/store/..-bash-minimal-5.0.7/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)`. What's happening here?
<str1ngs>sneek: later tell vits-test. I will see what I can do about *Messages* buffer. thanks for testing it's appreciated.
<str1ngs>you don't even need to roll-back as lfam mentioned
<lfam>I think so drgibbon. At least, I never was able to do it until I got involved with Guix. The process for Debian (my other main distro) is just not possible to use unless you make a multi-year commitment
<roptat>True, the bootloader allows you to boot any older generation that you haven't deleted yet
<nckx>You can disable Guix's re-installation of GRUB on every reconfigure if you like, and be responsible for installing GRUB yourself, so you're not surprised by breaking GRUB updates either.
<lfam>For Guix, one can follow the steps in the Contributing chapter of the manual, send a patch, and see it deployed on the same day
<bluekeys>Hi guix. I'm trying to install guix system onto an x200. Are there any known issues with installing with wifi? I'm trying to use a tl-wn722n, which I think has libre drivers (I'm normally pretty good about checking these things). The select wifi network dialog gets as far as letting me choose a network, but doesn't ask for a key and then seems to hang. Am I doing it wrong?
<drgibbon>are there any nice systems for making it easy to push updates? Say in the case of a version bump with minimal package changes?
<lfam>bluekeys: I'm sorry but I think there is a wifi bug like you describe in that version of the installer. I believe there is a "latest" installer, like a "nightly" build. Does anyone know the URL? Otherwise, you could use the manual installation. It's not too hard and we can help you with it
<lfam>"One could" cherry-pick the fix for this to the release branch and issue a 22.214.171.124 release
<vagrantc>makes me thing the download/latest page should also have a source tarball to make sure "make dist" keeps working
<lfam>But, I've heard that the process is not easy or fast
<lfam>drgibbon: Can you clarify what you mean? Like, which signatures? :)
<vagrantc>there were rumours of trying to get a new version out ~September a while back
<vagrantc>which might be worth moving that forward instead of patching an old release
<lfam>Perhaps, but it really depends on what's possible. We are seeing people with this wifi problem all the time
<lfam>Doing a new release might not be feasible within 30 days
<vagrantc>drgibbon: typically upstream signatures are checked by the person updating the package, and guix has it's own verification hashes of the source code
<lfam>drgibbon: The `guix pull` mechanism verifies signatures on the Guix code, and the Guix code is what defines packages and includes the hashes of upstream source code. So, it *should* be solid. But, I haven't heard of anyone attacking it as an adversary
<lfam>Eventually we will want to have some work like that performed
<drgibbon>ok right that's what I was getting at, it's assumed that the packager does the upstream signature checking.
<bluekeys>OK. I seem to have more problems. I am being given no options when greeted by please select a disk for partitioning... There is another distro that needs to be overwritten. I think it's trying to hold on... Resistance is futile!
<vagrantc>and recent versions of guix check the integrity of the commits since the last release, essentially
<lfam>Also drgibbon, if you already have a substitute for that chessx build in your /gnu/store, Guix won't want to build it again. You can either use `guix gc -D /gnu/store/...--chessx` to delete it, or use the --check or --rounds arguments to `guix build`
<lfam>It's useful for debugging machine-specific bugs in my experience, vagrantc
<nckx>jitwit: That's how it typically works 😉 You wait. It can take a while. We're very sorry about that. Eventually, someone will review and/or push your patch. If nobody responds within a week or 2, feel free to, well, what you just did ☝
<jitwit>Ah good to know, wasn't sure of the timeline. There's no rush and apologies if I got too antsy!
<nckx>It's a fair question and nobody thinks the current situation is ideal.
<lfam>jitwit: I did read your patch but didn't reply yet. From a code review perspective, I thought it was basically fine, no major feedback. The main question I have is how the J language is implemented. Is it a case where it's written in another language (like C), and then compiled? Or is it written in an older version of J, and needs a "pre-compiled" J to build it?
<lfam>Well, they say they support raspberry pi, so there must be some degree of ARM support
<jitwit>It will work for arm as well, but not as the definition is written at the moment
<lfam>I've always heard of J in the context of high-performance work, so I figure it wouldn't be so useful on most ARM hardware
<lfam>jitwit: I recommend replying to the patch ticket saying that it's in C and asm. I'm sure that any reviewer will be wondering. Since the package itself is kinda complicating, it can be demotivating to wonder about
<jitwit>Will do! I was also wondering about the right way to do libraries/addons. I wrote it so that the 'profile.ijs' file points to '~/.guix-profile/share/j/addons' so that they can be added independent of J
***meow is now known as jess
<nckx>The Guixy way is probably to use native-search-paths. If J can check an environment variable at run time instead of a hard-coded directory?
<jitwit>An environment variable could be bolted on? It uses a local variable set during initialization to point to where to find things
<nckx>The J equivalent of (define librarydirs (string-split (getenv "J_LIBRARY_PATH") #\:)) at start-up would be ideal.
<lfam>simendsjo: The error message means that it can't find the implementation of (gcrypt hash), which is from guile-gcrypt
<lfam>The pre-inst-env script changes your environment, and in this new environment, guile-gcrypt is not available
<lfam>I just keep guile-gcrypt installed in my profile to improve the development workflow
<simendsjo>lfam: Thanks. But if it's a requirement of quix, and I have quix installed, why doesn't I have guile-gcrypt installed? Why is it added when running `guix environment guix`, but not when "running" `guix install guix`?
<lfam>You're not using the Guix that you have installed when you use pre-inst-env (pre-installation-environment)
<lfam>I don't know why guile-gcrypt isn't made available by default in this context
<lfam>In general, you shouldn't do `guix install guix`. That's not recommended or supported
<vagrantc>well, it works ... it just has some really curious side-effects :)
<vagrantc>notably, each time you do it, you get an older version of guix
<vagrantc>as each version of guix only has the previous version of guix available to install
<str1ngs>simendsjo: it's because you are on guix foreign distro. you can get around it by installing all of the guix depends.
<str1ngs>depending on your distro that can be tedious.
<str1ngs>simendsjo: to get around it do guix environment guix. the use pre-inst-env
<str1ngs>you might need to ad-hoc a few things though.
<joshuaBPMan>so weird. My guile website is running locally just fine, but it doesn't seem to run remotely. It compiles remotely, but I'm getting an error "Too few values to continuation", but I do not get that error locally.
<joshuaBPMan>I guess the guile versions are slightly different. guile 3.0.2 vs. guile 3.0.4
<janneke>civodul: after we've been using guix for 3 years i still get basic beginners quetions and find some (pretty intelligent) people just want to be told what to do and seem happy to stay "in the dark" about what's going on -- so weird
<str1ngs>janneke: hello, I think I finally got this emacy prompt issue fixed. at least I grok it better \o/
*vagrantc is very much a "how do i use it" first kind of person
<civodul>janneke, vagrantc: OTOH i think it's a natural reaction: the first thing you want to know is how to use it :-)
<civodul>and it's true that the manual wasn't doing a great job at it
<civodul>but OTOH, it's also true that we're just adding more text just because people want to read less