<lfam>sailorTheCat: Can you try `guix package -p ~/.config/guix/current -l`? Please don't paste the output here. Look at the list of generations, specifically look at the generation that is before the current one
<lfam>And share the line that starts with "+ guix ..."
<dcunit3d>so i got all the way through the libreboot's Encrypted Guix guide for the first ime... and my password manager likes to do things like forget new passwords if you let it idle ... so it forgot the root password
<dcunit3d>SMDH ... the only problems i hadn't fixed yet were related to the slim login command AFAIK
<florhizome[m]><lfam> "It could also go in the cookbook..." <- I really don’t understand this cookbook thing. ^^ also more of a tradition. Not saying that there is not useful stuff in there.
<lfam>It's supposed to be kind of like the Arch wiki. Like, instructions for accomplishing specific tasks on Guix
<batalie>is anyone using anki with an up to date guix (system)? after an update all text has suddenly vanished (i.e. opening the "about" screen just shows a totally blank window).. possibly a qt or font problem?
<batalie>it's the only qt program i use so that might be it
<lfam>batalie: sailorTheCat just reported the same problem
<dcunit3d>i don't know. i wasn't sure if it was a problem with my system. it was only happening on one laptop, but affected most websites i would try to load. even the fonts for the devtools were missing. i didn't have time to look into it then
<dcunit3d>i tried `guix pull` and ensuring all fonts were installed, but didn't check much else
<lfam>So, if I use `guix time-machine` to try anki from that commit batalie, I see the same problem
<lfam>For example, `guix time-machine --commit=8fcf94759141 -- install anki`
<lfam>So, I think the problem must be somewhere else
<lfam>sailorTheCat: Thanks, I have both of them too
<lfam>I'm deleting them between tests of different Guix revisions
<florhizome[m]><podiki[m]> "florhizome: I would like to..." <- Could you not have some basic checks against that? I mean the commit field becomes basically useless, you could write *anything* in there..
<florhizome[m]>Is this possible: the source changes via git rebase, but the fetched commit stays the same; thus you would get a different hash but as long as you don’t notice this by yourself and the old derivation is in the store you stay with your old version.
<nckx>dissent: Guix is invoking the ./bootstrap script expecting it to set up the build environment (e.g., it could run autoconf/make to generate ./configure) but here ./bootstrap is a hand-written script that goes on a rambling conversation with a human. That needs to be avoided somehow.
<nckx>florhizome[m]: So you could still run into situations where you don't use it, and you just use, say, (git-file-name name version), and you don't update version, but only the (commit "…") field below it, *and* have already run Guix on your machine with an incorrect hash.
<nckx>It's pretty far fetched though. Unless I'm missing something.
<nckx>florhizome[m]: guix lint, as it currently exists, builds nothing. That's both its strength (known-reasonable run time cost) and limits what you can do as a linter.
<nckx>You could reimplement or simply call url-fetch etc. from the linter. However, we haven't even established how (if at all) guix lint would differ from guix build in this specific case, so agonising about whether we should is premature.
<nckx>The current argument seems to be ‘I prefer the prefix guix lint over guix build’ which is, sorry, not enough 😉
<nckx>I have to agree with lfam. This is going in multiple circles. It might fit better on the guix-devel@ mailing list, so the argument can more easily be split into pieces that can be discussed (and either accepted or discarded) in their own right.
<nckx>It should precede (/home/caleb/.guix-home/profile/bin.
<nckx>E.g. my PATH: /home/nckx/.local/bin:/run/setuid-programs:/home/nckx/.config/guix/current/bin:/home/nckx/.guix-profile/bin:/home/nckx/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin
<sneek>I think I remember abcdw in #guix 14 days ago, saying: jpoiret: I already did and tested them, now I want to get the code, which was actually committed, also I hope the substitutes for chromium-wayland is available too..
<florhizome[m]>i just have it set as screensaver but i don't think that changed much
<florhizome[m]>I have to test my idle, hibernate and sleep functionalities sometime
<nckx>sneek: botsnack, but also no pinging people.
<excalamus>I've been having issues with video on jitsi. People say they can't see my camera and I can't share my screen. My camera shows up for me and works with something like guvcview. I'm using unGoogled-chromium. Everything worked a few months ago, but with no real error messages I'm feeling in the dark
<excalamus>looking at my package history, I can see what version of chromium I was using when it last worked (92.0.4515.159-0.8164c91 ). If I understand correctly, I'd need to time machine the guix version so that I could rebuild the chromium version I want.
<excalamus>I'm thinking something like time-machine to get the guix version and then shell just to run it
<akirakyle>Yeah that's probably the right next step: update sway, seatd, and elogind to the latest commit and try again
<akirakyle>I'm on aarch64 so I'm compiling everything locally anyways so I'm not sure if this is an aarch64 specific issue. Was hoping someone could just tell me the latest guix version does or does not work with sway
<podiki[m]>hmm could be aarch64 if no one else has mentioned it recently on x86-64; things seem more difficult there
<akirakyle>Would someone here be willing to test that for me? It should be as easy as guix pull (or just have done it in the last week or two), guix install sway, then run sway on a tty (you might need to quit whatever other window manager/desktop manager system you have running)
<podiki[m]>I'm sure you'll find someone running (or able to update) the latest (I cannot, sorry)
<akirakyle>Might be better to try my luck earlier in the day here
<ns12>What are the minimum system requirements of Guix? Is it mentioned in the manual?
<ns12>I have a small 512 MB RAM computer. I don't think Guix can run on it. Is that correct?
<ns12>Yesterday, I tried to "guix pull" on a computer with 1 GB RAM + 1 GB swap, but ran out of memory.
<gnoo>it should, i think. my current memory usage is 627 mb with 1 empty browser tab. without it, it goes down to 420 mb (most of it is weechat's buffers)
<vagrantc>yeah, guix pull probably requires at least 2GB of ram
<vagrantc>well... some years ago i was able to guix pull with only 512MB of ram, but it was painfully slow (took tens of hours)
<gnoo>i just did guix pull and memory consumption jumped to 1.1 GB. so it took about 700 MiB
<gnoo>(with an error: TLS error in procedure 'write_to_session_record_port': Error in the push function.)
<ns12>Maybe it depends on the day. Maybe there is no consistency. I had been using 1 GB RAM + 1 GB swap for the last six months. I only had problems "guix pull" yesterday, which I solved by doubling the swap to 2 GB, giving me a total of 3 GB memory.
<ns12>Guix is probably not designed to be used on old low-end computers.
<libredev>Guix uses guile which is very slow i think
<libredev>I don't think people should write operating system on lisp.
<libredev>C is optimized to write operating system and its components
<attila_lendvai>libredev, in a proper lisp, you have trivial ways to hook into the compiler and even to customize the code generation. then you have staged computing to optimize way beyond what's possible in C with a reasonable effort. lisp is completely capable to be the base language of an OS.
<ns12>Perhaps the solution is to uninstall Guix from all computers. There should only be one computer (with large RAM) that has Guix installed. This computer would run "guix pack" to produce packages for all the other computers. This circumvents the huge memory requirements needed to run "guix pull".
<florhizome[m]>It’s also not like guix os is not still written majorly in c and c++ and guix Dämon is in c++
<ns12>As time goes by, I expect Guix to be unusable on most of my computers due to Guix's increasing system requirements. I think the "guix pack" solution will allow me to uninstall Guix. Are there alternative methods?
<libredev>Guix also uses Gnu Shepherd which is slow and written in guile
<ns12>I don't understand why some software would ever need more than one *billion* bytes of memory ...
<florhizome[m]>ns12 you can already offload builds on the local network so you don’t have to pack specifically
<vagrantc>florhizome[m]: yeah, but not all of "guix pull" can be offloaded
<porcupirate>guix isn't finding gdc-toolchain even though it is right there in the source.
<ns12>For "guix pack", what is the difference between --system and --target?
<florhizome[m]>i think guix pull can be further optimized. I think I saw some talk about it, also with guix servers. the initial communication can be spead up, more steps to download more asynchronous can be done...
<florhizome[m]>It has also gotten slower to me since cuf, at least in the first view steps.
<mothacehe>ns12 system uses QEMU transparent emulation while target cross-compiles
<ns12>If I am using x86-linux, and I want to produce a bundle containing software to be run on i686-linux, which option should I use? --system or --target?
<ns12>mothacehe: So the answer is to use --target?
<mothacehe>no that's a specific case. x86 can produce i686 binaries without resorting to emulation/cross-compilation
<ns12>So why would anyone want to use --system=armhf-linux on an x86-linux computer instead of using --target?
<gnoo>in case your compiler can't cross-compile to that, maybe
<mothacehe>yes the main reason would be that some of our packages/build-systems do not support cross-compilation
<mothacehe>or fail to cross-compilation because the package recipe are written in a way that prevents cross compilation, hardcoding gcc for instance
<allana>Hi! I am experimenting with guix home, and I am curious to know how to use only the profile generated by guix home. For example I have emacs 27 installed under my regular profile, but with guix home I only install emacs-next-pgtk.
<allana>In my case, when running emacs from a terminal emulator I get the emacs-next-pgtk version, but when launching emacs from gnome desktop I get the emacs 27 installed under my usual profile
<mothacehe>ns12: you can probably use --target=arm-linux-gnueabihf on the gnu/system/examples/bare-bones.tmpl but gnu/system/examples/desktop.tmpl will likely fail.
<ns12>If the compiler and build system supports cross-compilation for the target architecture, will --system and --target produce identical binaries?
<fproverbio>does anyone have experience with vfio pci passthrough? i was trying to surrender a raid controller to a virtual machine to retrieve some data but the device in question is still not grabbed by vfio-pci at boot time
<rekado>re memory requirements: this is a known problem with the Guile compiler. There’s little Guix can do (beyond what has already been done) to improve this.
<rekado>proclamations of dOOM for old machines are misplaced here.
<ns12>rekado: "Proclamations of dOOM for old machines" should be brought to #guile instead?
<florhizome[m]><ns12> "rekado: "Proclamations of dOOM..." <- If it's a well known thing I think it will be solved sooner or later.
<fproverbio>hi everyone, is there a way to skip python tests alltogether? i'm trying to package a big project and this dependency is getting in the way failing in the check phase (i defined it using guix import)
<abrenon>fproverbio: (arguments `(#:test? #f)) should help, but is it the tests failing or the sanity checks ? I had an issue a couple days ago packaging a python lib which was trying to write stuff to my homedir during the checks
<abrenon>phf-1: in any case, I see no particular trick to apply: it's just a package with a non-standard format that IIUC python is in the process of replacing pip with, so, yeah there's no sound importer (yet !) for guix, it just means more work because you'll have to script in guile what the promoters of that format require users to do in order to install their software
<abrenon>but I see no conceptual impossibility (except if there's something in the install process that explicitly imposes to write in a stateful way to some precise location like /usr/bin that can't be relocated to a different root)
<fproverbio>i'm gonna check, there's plenty of logs due to the continuous building :)
<xelxebar>So, package A installs /bin/baz-123, and I'd like to symlink that to /bin/baz. I created a dumb trivial-build-system package that does this, but that feels like a huge overkill. Is there a better or more canonical way?
<xelxebar>The /bin paths are really <profile-path>/bin, of course.
***aya is now known as gyara
***taylan2 is now known as taylan
<rekado>xelxebar: you can modify package A with a build phase like this: (add-after 'install 'symlink-executable (lambda* (#:key outputs #:allow-other-keys) (let ((bin (string-append (assoc-ref outputs "out") "/bin"))) (symlink (string-append bin "/baz-123") (string-append bin "/baz")))))
<PotentialUser-65>Is there any good laptop to run GUIX without NONGUIX? I am looking for a modern laptop having really a good processor with a good performance, with coreboot or libreboot support and good graphics (probably I should stick with AMD). I only know Tuxedo (with AMD), System76 and Purism selling Linux laptops, but don't know if they have proprietary
<PotentialUser-65>blobs or work with linux-libre. I want to buy a laptop that can run linux-libre but also has a good performance as well.
<rekado>PotentialUser-65: I’m typing this on a Librem 13v2
<attila_lendvai>#~ and #$ makes code substantially less readable to me. is there a way to avoid using gexps and this-package-input in place of %build-inputs?
<rekado>I had a few troubles with the machine over the years, but with the latest official coreboot image from Purism and a recent Linux kernel it all works pretty well now
<rekado>(or maybe I have mellowed enough to give up fighting it :))
<xelxebar>rekado: What do you mean by modify package A? Create a wrapper package with package/inherit?
<rekado>xelxebar: I meant: change the package definition. Then submit a patch.
<fproverbio>PotentialUser-65: i'm afraid there aren't many alternatives to what rekado said, the last affordable laptop (x86) that runs guix well is the thinkpad x220/x230 series. No blobs required (beyond neutered intel ME) and everything works out of the box if you change the included wifi card
<rekado>or is that something so peculiar that it shouldn’t be default?
<xelxebar>rekado: Oh. I see. Yeah, I'm thinking more personal, custom symlinks.
<rekado>xelxebar: if you only want a particular package output to be available in your profile under a different name there are alternatives: 1) you could use a shell alias or 2) if this is Guix System you can use special-files-service-type
<PotentialUser-65>rekado:, fproverbio: I wonder how the developers of the os or the kernel manage to compile software. Poor hardware takes around a day to compile Firefox or something.
<rekado>it was a bit more painful with my thinkpad x200s
<jpoiret>pretty often they have either beefy desktop machines or private CIs
<rekado>(I have neither, unless ci.guix.gnu.org is considered private ;))
<jpoiret>kernel is not that long though, and with incremental compiling it can be wayyyy shorter
<fproverbio>PotentialUser-65: you can offload compilation to more powerful computers or servers, it's pretty easy to spin a up a guix VPS and you don't even have to worry about linux-libre since it's qemu q35
<jpoiret>someone just submitted a 1.5k commits patch for the kernel to cut down compilation time by 70%
<attila_lendvai>is there a way to mark a package not to be built on the substitutes? context: i'm working on keeping Idris bootstrappable all the way down from GHC, and it requires 4-5 intermediate versions. these are not interested to anyone who just wants the most recent version (which can be boostrapped through a shortcut of checked in scheme files)
<fproverbio>jpoiret: i've read it too, glorious if it makes it to mainline ;)
<fiesh>PotentialUser-65: I'm quite happy with my librem14
<rekado>attila_lendvai: you can mark packages as not substitutable, but we don’t really use that much unless we really should not provide binaries
<xelxebar>rekado: A shell alias isn't ideal in this case, since I'd like `/usr/bin/env baz' to also work. The special-files-service-type is an interesting idea, though I'd prefer to keep the package in my user profile.
<fiesh>I'd give the hardware 4/5 stars, and the purism support 1/5
<rekado>(e.g. for atlas which tunes itself to the CPU of the building machine; or for zfs for legal reasons)
<PotentialUser-65>fproverbio by "powerful computers" do you mean which are open, or which are closed like Intel or AMD systems (like Dell, ASUS, etc.)?
<fiesh>PotentialUser-65: I found it pretty reasonably priced, like $1200 if I remember correctly, plus a bit now for 2tb nvm and 64gb ram
<rekado>attila_lendvai: users of the latest version won’t need to build the older ones when there’s a substitute, right?
<xelxebar>rekado: What I'm really doing is writing a package where the user might want multiple versions installed in parallel (like python), but it's also ideal to have a standard path, a la python-wrapper, but where the user can choose which version they want to point to.
<PotentialUser-65>rekado Can aarch64 really be "powerful'? I thought only x86 can be considered as powerful.
<fiesh>PotentialUser-65: no idea if tuxedo has intel me disabled etc.
<jlicht>on a tuxedo machine from 2017, intel me was still enabled
<fproverbio>PotentialUser-65: or just wait for asahi-linux to finish their effort lol
<rekado>attila_lendvai: you would also doom people who build the latest version from source to also build all the bootstrap versions locally
<fiesh>well anyhow, with purism, the infuriating part is *getting* your device... once you have it, it's quite nice to be honest
<rekado>PotentialUser-65: I’ve got three honeycomb LX2 machines sitting on my desk right now. They each have more cores than my laptop *and* they are quieter.
<attila_lendvai>rekado, the old binaries are not needed to compile the latest version, because the scheme compiler backend output files are checked into the Idris repo, and ChezScheme is used to compile them in a so called 'bootstrap shortcut'.
<rekado>attila_lendvai: I guess I don’t understand why the old versions exist at all then
<rekado>attila_lendvai: you can also hide packages
<rekado>they can still be built with ‘guix build -e '(@@ (gnu packages foo) bar)'’ but they won’t appear on the command line
<fiesh>if the librem supported a thinkpad-style cursor thingy, had no touch pad, had better speakers and had ECC ram, I think it would be 100% perfect to be honest
<rekado>(and if the display could be tilted just a tad more to the back, like the thinkpads)
<attila_lendvai>rekado, i can squeeze out some arguments wrt reproducibility/security, but it's mostly only for the geek value i guess.
<skn84>as far as i understand, this is part of the freebsd base system.
<asdf-uio`>>> <lfam> It's clear that the 'shadow' example was too obscure
<asdf-uio`>That's both my impression and a nice play on words. I had no idea how to find the correct package for setuid programs I wanted to add. I am not sure if I got the right way from examples or documentation.
<asdf-uio`>Maybe a simple example and a more complicated one, along with an explanation how to find the right package would be nice? Or a link to another section where a complete explanation is to be found?
<asdf-uio`>>> <podiki[m]> yeah, I noted search engines (or ddg at least) always give the "stable" old manual
<asdf-uio`>I also had that kind of problem. Once you know it, it's fine, but before that...
<asdf-uio`>Wouldn't a header with a big red warning like 'this is most probably not the right version of the manual if you are on a running system' and a link to the corresponding page in the current docs make sense in the online version of the manual?
<asdf-uio`>Regarding the low usage of 'guix lint' for submitted packages: If most people get started with packaging with the cookboot, wouldn't it make sense to add a sentence on 'lint' there?
<asdf-uio`>I don't see a way to lint a file. So I have to run 'guix pull' before 'guix lint', right? Is an option to lint a file planned? That would be useful for local channels.
<jpoiret>no one in their right mind would read the whole <origin> commit sha vs tag thread. I think it's about to surpass the node patchsets in number of replies :)
<skn84>> Is that location listed in CROSS_C_INCLUDE_PATH?
<skn84>unlikely: this is a file from freebsd, where it is located in `/usr/include/sys/_types.h`
<jpoiret>skn84: for sure. I don't think it would be an easy first contribution
<asdf-uio`>I am getting errors for inputs of common lisp systems I am trying to package, e.g. (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (sbcl-clack)) (value #f)). I assume I made some trivial mistake. The systems that resulted in these unbound-variable exceptions have all been available in guix, so far.
<jpoiret>well, you're trying to use the sbcl-clack variable without it being available
<nckx>asdf-uio`: Did you include the (gnu packages lisp-xyz) module?
<asdf-uio`>Thank you! I did not. And I got that thought when I saw jpoiret's answer. It's weird how the same information I saw in the error message suddenly clicks when it is given by a human being.
<jpoiret>i agree though that the way this exception is displayed is not very readable
<nckx>Guile's error messages are… the opposite of human, indeed.
<nckx>Guix does supply ‘hint: did you mean to import (gnu packages foo)?’ hints but they don't always trigger.
<jpoiret>here it stems from the automatic conversion from the old throw/catch to the exception system
<rekado>ngz: if you’re in a rush you could use wip-texlive already. It seems to be fixed there.
<rekado>pdflatex will generate the font in the requested DPI
<rekado>xelatex doesn’t use the bitmap fonts at all IIUC, so it works even without the most recent fix
<rekado>(it just required the directory recursion fix)
<asdf-uio`>Now I get this for lisp (and before that for lisp-xyz): (exception misc-error (value #f) (value "no code for module ~S") (value ((guix packages lisp))) (value #f)). Just after writing this I had another look at an existing lisp package and noticed that my mistake was using guix instead of gnu packages. Is this also something Guix could supply a hint for?
<ngz>rekado: I will give this branch a try in a while.
<rekado>ngz: I’m going to develop a few more fixes for texlive bugs that have accumulated
<rekado>eventually I’d also like to revamp simple-texlive-package
<florhizome[m]><jpoiret> "maybe you could look at how guix..." <- Doesn’t the Hurd use glibc, too? That’s a major difference, isn’t it?
<rekado>that whole file is too complicated and there are too many ad-hoc solutions
<rekado>florhizome[m]: it does indeed. The Hurd implementation is spread across a few projects, and glibc is one of them.
<jpoiret>florhizome[m]: oh, i had forgotten about that! For sure, that's going to be a major hurdle
<SeerLite[m]>Is there any way to make multiple versions of a package available in PATH? Like if I have openjdk 9 and 17, can I somehow make them available as java9 and java17 (in a package definition)?
<sash-kan>podiki[m]: no, i don't build guix. i'm trying to cross-compile package for freebsd.
<nckx>There's also $GUILE_AUTO_COMPILE but I don't know if it works post facto.
<podiki[m]>speaking of local checkouts, what do people like to do to keep it up to date? git pull and then make, or best to always do a make clean of sorts?
<nckx>I remake each time things get slow due to significant changes. Re-bootstrap when that's no longer possible (ABI changes etc.). Seldom anything inbetween (clean-go, etc.). I just launch a bootstrap & go do something else for a known stretch of time.
<jpoiret>i only make clean when something doesn't work :)
<rekado>I’ve often been annoyed when I debugged a build and had to manually apply the patching that the build phases prescribed
<rekado>I wonder if it still makes sense to discriminate against patching in the source field.
<jackhill>rekado: interesting idea. I have not particular opinion on that right now, but I have been wondering on-and-off for some time if we could perhaps provide some interface for running the build phases interactively on a directory tree…
<podiki[m]>hrmm...not sure what to do with this update:
<podiki[m]>I need dear-imgui 1.81 (we have 1.79) which coincidentally is the latest I see for the Debian makefile we use for it; not the latest for dear-imgui but okay for me
<podiki[m]>the only package I see that uses dear-imgui is Ogre (3d engine), but just the source
<podiki[m]>ogre is way out of date, but don't see a version that wants dear-imgui 1.81 source :/
<dcunit3d>when i run if i get an "error: symlink: file exists: /var/guix/profiles/per-user/my-user/current-guix"
<dcunit3d>when i run "guix pull" why am i getting that error?
<podiki[m]>and current Ogre version we have doesn't build with dear-imgui 1.81; should I just keep the older dear-imgui for Ogre and worry about full updates to both at a later time? (my goal is for a package I have ready to submit that needs dear-imgui 1.81)
<nckx>Don't use it but I've seen it, probably following your nick.
<the_tubular>Meh, I'm calling podman with he long path and everything seems to work for now
<nckx>lfam: What I didn't realise was that it could stand on its own, not just sudo -i COMMAND.
<lfam>Also, it's fine to work as root on Guix, I do it all the time. You just have to remember that managing packages with Guix is per-user, and act accordingly. If that's confusing, then I agree that you shouldn't log in as root until you grok it
<nckx>Keeps things interesting! Which is good. You don't want privilege escalation to be boring or predictable, that's how accidents happen.
<lfam>It so interesting to me, how old-school distros smoothed out most of the weirdness of these overlapping tools from different generations of UNIX
<SeerLite[m]>jpoiret: Yeah I need both java versions at the same time as inputs for a package which uses both at the same time. Doesn't matter anyway as I looked at the source and the places it looks for java are hardcoded for FHS, so I'll have to patch it
<fproverbio>does anyone have experience with vfio pci passthrough? i was trying to surrender a raid controller to a virtual machine to retrieve some data but the device in question is still not grabbed by vfio-pci at boot time, for completeness sake i tried both the etc-service-type and the kernel commandline in my config.scm but still no dice
<podiki[m]>I used vfio a long time ago, and not on guix. I know it is tricky with iomuu groups, bios options, etc.; do you know it can work not on guix?
<nckx>vagrantc: AFAICT I'm not addressed anywhere in that message either.
<fproverbio>podiki[m]: sure, as a matter of fact i ran proxmox on the very same computer and vfio worked on it (debian)
<fproverbio>to be fair, i can blacklist the driver so the commandline argument is working
<vldn[m]>i used it on nixos and it was a breeze with the declarative config
<fproverbio>i unfortunately didn't find any example on the net of such setup, just a reddit thread that is basically unresolved
<podiki[m]>hrm. I would check all the boot options, but that's all I can think of right now. somethign else must be grabbing it first
<podiki[m]>a search in the source for "libcrypto" might be good, or see if it is trying to use the ld cache maybe
<podiki[m]>but most often I see just a hardcoded path for the library
<asdf-uio`>It seemed to show a lot more than just openssl. I saw 'incudine' in there, which is a music live coding environment in common lisp.
<podiki[m]>it might have had a lot of paths if it was downloading/building dependencies of openssl; my earlier tip was more for when guix build <package> just spits out the store line (meaning it is already present)
<podiki[m]>probably if you ran it again it would be shorter, but openssl has a few things in it
<podiki[m]>good luck! I should take a guix break and then will send the mangohud patches
<asdf-uio`>Thanks, enjoy your break! I tried taking a break, too, but it wascut short because I want to fix this.
<opalvaults[m]>has anyone experienced troubles going to and from login/display managers? I have two computers A and B. The configuration on A is GDM, the configuration on B is SDDM. When I try to switch B from SDDM -> GDM, GDM does not load correctly and stops after the elogind is using pid blahblah message on the TTY
<opalvaults[m]>The configuration on computer A, is the one I'm using on computer B (with bootloader/uuid stuff changed obviously). So they are in essence the same configuration file.
<opalvaults[m]>Hardware is probably different in that one is a newer Dell and the other a newer thinkpad
<rekado>apteryx: that’s PCIe 4, but the server only has PCIe 3.
<akirakyle>opalvaults[m] okay there was a chance if they are different arches that it was due to a recent change where guix conditionally using gdm only on x86_64 but sddm everywhere else which has caused some issues for me on aarch64
<apteryx>PCIe 4 should be able to operate as PCIe 3, although with a loss in performance
<opalvaults[m]>akirakyle: just to make sure i double checked with uname -a and indeed both of these laptops are x86_64
<akirakyle>opalvaults[m]: to answer your question, guix is only reproducible starting from the same providence: so on both machines you'd need guix describe to output the same guix commit
<opalvaults[m]>the interesting thing is that I originally had GDM on this laptop before switching to SDDM. It breaks after attempting to go back to GDM. I've actually experienced this twice in trying to change SDDM -> GDM
<asdf-uio`>rekado: thanks. That's all over my head at the moment. But it turns out I don't have to figure that out for now: sbcl-cl+ssl is already provided by lisp-xyz. The reason I thought it wasn't is that 'guix search sbcl-cl+ssl' does not return anything. By chance I tried 'guix edit sbcl-cl+ssl' which showed me the original package instead of the one I was trying to create. I'll try to figure out the remaining errors tomorrow.
<rekado>apteryx: I’d like to use SSDs too. Reliability is a concern, though.
<apteryx>rekado: that's why I'm looking at intel; they are the toughest things on the market when it comes to reliability, SSD wise (samsung must come close too, but they don't seem to offer such as high capacity drive yet).
<opalvaults[m]>jpoiret: there is no gdm user on this system. I'm rolled back at the moment so it may be that it just isn't part of the configuration
<jpoiret> yes, if you rolled back there is no gdm user anymore
<apteryx>rekado: I don't see the benefits of RAID when using SSDs (unless you have money to throw on RAID 1)
<cbaines>I still think it's much easier to just have a small store, rather than try and throw money and hardware at the problem of having a large store
<jpoiret>but i don't think that's the problem. I suggest using (debug? #t) in the gdm-configuration
<akirakyle>opalvaults[m]: yes if you want your guix system to be the same on both systems, (at the very least) the commits should in guix describe should be the same. The fact they were both installed using the same guix installer won't matter if you have issued guix pull at different times on each machine
<opalvaults[m]>for transparency, here is the configuration file that I'm attempting to apply:
<nckx><I don't see the benefits of RAID when using SSDs, unless> I think RAID1 is a must either way. We all seem to have wildly different opinions on storage.
<cbaines>nckx, although I think no on machine redundancy is OK if you have multiple machines
<nckx>OK, that's a hypothetical alternative we could discuss.
<apteryx>cbaines: hi! I'd agree if the use case was purely serving files over HTTP, but here we're talking about having faster storage on the head node of the main build farm (berlin), which accumulates items from all workers.
<opalvaults[m]>jpoiret: what is the syntax for this addition of debug? I don't have a gdm-configuration declaration. this is a stock from installer services block
<cbaines>nckx, it's not hypothetical any more, that's the model now behind bordeaux.guix.gnu.org, the majority of the substitutes are stored on two machines (duplicated)
<nckx>cbaines: Are you working on such a thing, and if so, have you published an overview of what you're working on?
<cbaines>apteryx, it's avoiding that unnecessary and wasteful accumalating of files that I'm talking about. Why create a nar on a worker, send it to berlin, unpack it in to the store, only to go and create a nar again to serve?
<nckx>For a tiny project we sure have very many models of doing CI.
<vivien>Is there a way to run a cron job 5 minutes after boot, and not after that? I’d like to restart some network services after networkmanager has negociated all its IP addresses.
<nckx>cbaines: See, it was not immediately clear the first time I read this that it implied getting rid of the one true centralised store. More like something that sat *after* guix publish from a single source, and then after nginx.
<nckx>It's still not really clear to me now, but blame me, I'm sure :)
<cbaines>nckx, no worries, I still wonder if it's quite the right grouping of concerns.
<cbaines>you're also right in that it's an "after guix publish" thing, since it just imports narinfos+nars, and then can move the data around
<cbaines>but it's that functionality that enables having multiple machines store the same bunch of nars, whether for mirroring or for redundant storage
<nckx>So using it to tackle the humungostore implies running guix publish on each build node? Because I still don't see how this saves a ‘round trip’ just yet. It could reduce the time you need to keep live items on the head node, yes, if you actively poll its nginx and extract the nars as soon as they are ready, cache them somewhere else, then frequently GC the store.
<apteryx>the thing is we need something that allows 'guix gc' to work on Berlin in 2 weeks time, ideally, else we'll face running out of space. I don't really see how that scheme can fit in the current architecture of Cuirass to solve this, it'd probably need more thoughts and time. Equipping Berlin with SSD storage is something relatively inexpensive we can do that will have a long lasting positive impact
<opalvaults[m]>akirakyle: to your point about commits, I'd understand if it was a mismatch of package versions or something but this isn't the case. In the case of a caching error where artifacts are left behind on a read-only filesystem that leaves me unable to make reproducible changes even if it were due to that
<opalvaults[m]>jpoiret: it's just the usuall message about elogind already using PID X
<rekado>cbaines: bayfront is already among the default substitute servers
<jpoiret>and debug? #t only tells gdm to log things to syslog, if you rollback and inspect /var/log/messages, you'll see what GDM had to say
<opalvaults[m]>this is on a work computer unfortunately so I'll likely need to reinstall
<opalvaults[m]>it appears according to the debug log that GDM isn't really having any issue starting?
<apteryx>rekado: if we want 30 TB of storage you could add multiple smaller disks in a RAID 0, but that's RAID 0 (worst than one disk in terms of reliability). RAID 1 is twice the price; which is significant for SSD. We could have daily backups to slower storage.
<jpoiret>opalvaults[m]: could you also look at /var/log/debug and /var/log/greeter/*?
<opalvaults[m]>jpoiret: the one i linked is /log/debug but i'll do greeter as well
<fproverbio>apteryx: how about mergerfs with some custom policy?
<nckx>I've never got the theoretical numbers out of raid6 but that was probably crappy hardware more than anything.
<float>opalvaults[m]: I am actually doing something very similar, but I was running into an issue where when I added a package to an org-mode file handling my settings with org-babel it would want to overwrite my init.el file (I assume to edit custom-set-variables) but init.el was read only since it was generated in place by guix home reconfigure.
<opalvaults[m]>float: if you don't want org-babel-tangle to overwrite init.el, then make sure to not include :mkdirp yes in the source block
<opalvaults[m]>The way I have it set up is tangle configurations, and then run guix home reconfigure. It manages all of my dotfiles including emacs so mine overwrites and symlinks my init.el to .config/emacs/init.el
<opalvaults[m]>what guix home does is basically moves the current .config/emacs/init.el (or emacs.d/init.el) to a backup directory in your $HOME, and then replaces it with the new version
*podiki[m] listens to opalvaults for future guix home goodness (currently a literate dotfiles + stow life)
<nckx>Does it still assume everything starts with a dot?