<gnucode>sweet. So I have a friend and I am lending her a laptop GNU/Linux laptop. I will probably set it up with GNU Guix, because I want to convince her to fall in love with it too. However, as much as I love guix, it's not super user friendly compared to elementary OS.
<gnucode>anyway, to keep the question mostly on topic...what can I do to make it super easy for her? I'm basically saying that she rarely has to type in commands, but can click a button to update and such.
<gnucode>Actually, is there a channel where I can install either dthompson web front-end for the guix command. Or the guix graphical gui wip guix?
<vagrantc>gnucode: sort of a "running guix and you don't hardly notice" sort of environment?
<gnucode>I am currently thinking something like xfce. That is a fairly lightweight and easy to use desktop environment
<gnucode>vagrantc: pretty much. How do I convince a computer illiterate person that guix system is their best option?
<vagrantc>i would worry with a system like that that they might only see the guixy parts when things break, and not when it is running smoothly
<gnucode>vagrantc: what desktop environment would you suggest?
<vagrantc>i do not know that i would try to do that with any system ... more inclined to help people already interested for some reason ... :)
<gnucode>gnome ? My only issue with that is that it takes a fairly long time to update. I suppose that I could just install xfce-destop-service & gnome-desktop-service and let her pick the one she likes.
<vagrantc>gnucode: the short of it is i tried to convince people to use various systems, and whenever anything was broken or unusual or weird to them, they learned that free software was sub-par. even though many of the things it did worked quite well ... it is too easy to focus on what goes wrong ...
<gnucode>vagrantc: looks like you have a second chance at being an evangelist!
<vagrantc>the talk lechner referenced is me saying "this is what i like about it, maybe you will like it to, and here are some warts that you should know about"
<gnucode>vagrantc: honestly that was my fear when I sold a used computer to my father. I could not in good conscious sell him guix system. I had to sell him elementary OS instead. (though I installed guix on top of it).
<vagrantc>i mostly came to guix for the integration of reproducible builds and the commitment to free software ... :)
<vagrantc>i think being honest about the challenging bits up front helps, that way they are not as surprising when they happen.
<vagrantc>e.g. substitute availability issues, disk space usage, etc. of guix can sometimes be surprising... still surprises me now and then when it installs the Nth copy of some program for some seemingly unrelated update
<gnucode>I don't think disk space will be too big of an issue. I'll set up a cron job to periodically delete some stuff.
<gnucode>but that is true. She won't really know how to run guix update, guix package delete-generations, guix system delete-generations.
<bjc>guix is *weird*. when things go wrong, the internet is unlikely to help you, even less so than a “normal” linux desktop
<gnucode>bjc: in my personal experience, guix is hands down the most stable distro I have ever used. What things have gone wrong for you?
<bjc>as something you opt into, i think it's a great system, but it's not something i'd spring on someone without them being enthusiastic about its ideas
<gnucode>since I have heard this a few times now, if not guix system what should I set up for my friend. As a non-literate computer user she probably will not care about becoming a saint in the church of emacs.
<bjc>stability isn't so much the issue. it's not going to crash. it's going to be "why can't install rust" or "my wifi doesn't work" or "how do i use wine" or "the instructions for setting up podman don't work"
<bjc>and as soon as you start to scratch at the surface of that, everything becomes a dark art that very few can help you with
<gnucode>the wifi will probably be a big sticking point...
<gnucode>I will let her try guix system for a week or so, and probably blog about the issues that she has.
<bjc>there are countless examples. this channel gets, on a regular basis, questions about why "obvious" things don't work
<gnucode>I could also try to get my silly server set up and have a substitute server set up in my apartment. Since we live in the same town a substitute server would help her out.
<mroh>it also "why can't I run brave-browser" (for my $gf).
<bjc>it's a great system if you can positively commit to its trade-offs, but it's definitely not for everyone, and it doesn't try to be
<gnucode>mroh: what is your current computer's hostname...? I feel like we have had this conversation before...
<gnucode>i guess I could also take a look at what other companies are doing that pre-install linux distros on their laptops. They probably pick those distributions because they are user friendly.
<mitchell>gnucode: Just bind a hotkey in the system that runs `guix package --roll-back`
<iyzsong>it can be, usually mounted from a read-only squashfs (can be copy to mem for faster speed), and changes upon / can be managed (save/discard).
<gnucode>iyzsong[m]: what makes puppylinux so great? light on resources?
<gnucode>vagrantc: is there anyone running guix system with /gnu/store on tmpfs?
<iyzsong>gnucode: it have many useful gui applications builtin (browser, editor, player, package management), and wizard for setup (network, language, keyboard, etc). and it's hard to break
<vagrantc>iyzsong: sure, i know how live systems generally work ... more commenting on how impractical it would be to maintain a guix live system doing regular updates ... (you could rebuild the image, i gues ...)
<iyzsong>vagrantc: yes, rebuild the whole system image should works..
<vagrantc>though you would need a lot of ram to do even that
<gnucode>now that I think about it...rde might be a good idea. Sway is fairly light on resources. and rde might have a mac OS like horizontal bar on the bottom of the screen.
<gnucode>oh onto another topic. I have the Hurd set up and running on real hardware a T52 or something...It only has 2GB of RAM. What's the process of installing guix on it? Would the installer script work?
<gnucode>I guess it should. The Hurd tries to be POSIX compliant.
<dcunit3d>if i'm running emacs-guix, how do i associate a particular buffer to the running Guix REPL?
<dcunit3d>when i run commands from guix-devel-mode, they expect a running geiser repl, but if i just start a geiser repl, it doesn't have the same context as a Guix repl, so it doesn't do things like jump to definition or provide autocomplete or allow most of the guix-devel-mode functionality.
<dcunit3d>i've set the geiser repl for a buffer manually before, but i feel like there's a simpler way to do this.
<dcunit3d>it's possible that i'm conflating my past experiences where my GUILE_LOAD_PATH/etc wasn't set up properly, so if i try it now, then maybe everything just works
<lechner>Hi, which is better and why, please? #$(file-append cachefilesd "/sbin/cachefilesd") or (file-append #$cachefilesd "/sbin/cachefilesd")
<gnucode>lechner: gexp are still confusing to me...
<AwesomeAdam54321>lechner: (file-append #$cachefilesd "/sbin/cachefilesd) is better because only the cachefilesd variable needs to be dereferenced at build time
<winter>hey nckx, a while back (~November?) I was talking about a weird issue wrt booting the install image with ARM64 EFI. I believe it may be due to the kernel image being (zlib) comprised, and GRUB not having it enabled. happen to know if this could be the case? thank you!
<lechner>i don't think so. i believe the decompression code resides in the kernel. that's also why the kernel can function as an EFI stub
<winter>i'm really unsure why grub would be throwing "invalid magic number" when trying to load the kernel, then. :/
<lechner>winter / on any other linux i'd copy kernel and initrd to / as well as a static shell executable and then run the kernel with init=/bin/sh not sure how to help you there. grub cannot find the kernel
<lechner>sometimes it's just a little number that is off
<TristanCottam[m]>I'm setting up a home server to host multiple online services using Guix System. After some research, I've narrowed my options down to`guix shell`, `guix system`, and `guix system container`, each used in conjunction with Guile modules, and have decided to keep a separate Git repo for each online service. `guix system` would be used for the core system configuration in any case.
<TristanCottam[m]>Can anyone offer me guidance on which approach would best suit managing dependencies and configurations for each online service in a clean and efficient way?
<TristanCottam[m]>I'd like to keep each online service (i.e. web service, not "service" in the Guix jargon) in a separate Git repo, and keep core system configuration in yet another repo, as opposed to having everything in a single repo. Could you help me in understanding what problems `guix shell` and `guix system container` are trying to solve?
<TristanCottam[m]>By online services, I mean things such as Nextcloud, Mastodon, Git, game servers, etc.
<civodul>efraim: hey! an HPC colleague says they're happily running RISC-V VMs built with "guix system image --target=riscv64-linux-gnu", crazy stuff :-)
<AwesomeAdam54321>I'm not really sure why it requires systemd "for AMDGPU and INTEL support"
<florhizome[m]><TristanCottam[m]> "I'd like to keep each online..." <- guix shell is like a virtual environment (or nix' direnv i think), while guix container starts a linux container. you can add packages in the command, also a guix.scm in the directory will be evaluated. thats as far as i can say. more info and examples should be found in the manual and cookbook
<apoorv569[m]>florhizome: I understand, but this IRC pretty sure half of the people can't really see the history. And most people won't scroll back chat to see if they can find a question to answer. Its better to have a dedicated channels for specific kind of topics. Like General for general chat helpdesk for support and all.
<apoorv569[m]>I know. I am just learning about for 2 weeks straight now and because of lack lisp knowledge I keep struggling a bit. And its just frustrating at times.
<TristanCottam[m]>I feel you, I've been learning about computers on my own since I was 15, I'm 21 now, and having been at it for a few weeks, learning Guix and Guile with no prior Lisp or Scheme knowledge proves to be quite the learning curve
<jbv1[m]>civodul: Yes we should ;) It also seems to me that the interop between Julia package manager and Guix is not working as well as it was since the last Julia update. But I did not have time to investigate deep enough to make a bug report.
<civodul>jbv1[m]: i think zimoun & efraim are those msot familiar with this, let's see
<Guest6>Thanks ! I'll take a look and try to work with it in the afternoon.
<Guest6>Still interested if someone knows if the pattern matching I was trying to make can work;)
<zimoun>civodul, Guest6: about the importer, yes I tried an importer in Guile but I think it is the wrong path: we are reinventing the wheel for almost no value. Instead the importer should use the builtin from Julia. As jbv1[m] does or Nicoló too.
<zimoun>We discussed that with Nicoló at Guix Days in Brussels.
<zimoun>From my point of view, the best would to write an extension wrapping something similiar as jbv1[m] or Nicoló importer using Julia itself.
<jbv1[m]>I think so as well. for example the dependency solving is very valuable and quasi impossible to reproduce
<zimoun>And for instance, the Haskell importer reimplementing many Cabal thing in Guile is hard to maintain.
<zimoun>Having in mind how fast the Julia ecosystem is moving, it would be hard to have an importer in Guile that follows their breaking changes. ;-)
<zimoun>Thanks jbv1[m], I was not aware about your importer.
<civodul>i guess it all depends on what it is that needs to be implemented
<civodul>for PyPI, CRAN, CPAN, etc., having our own stuff works remarkably well
<civodul>and it's available out of the box with Guix, which is nice
<jbv1[m]>On a similar note, I think we could do something simpler for the julia-jll packages (the one that wrap a binary)
<jbv1[m]>Currently we are patching the source to replace the paths to our binary in the store, but we could use the Overrides mechanism that julia provides
<jbv1[m]>I have tried it for some projects and it works very well
<zimoun>civodul: many things needs to be implemented. You need to parse many things. Then you need to reimplement a kind of resolver. Yes, it could be to have in Guile, but I think the effort is not worth.
<zimoun>civodul: Well, reinventing the wheel and write many parsers can be fun. But there is little value, IMHO. And it costs for maintaining it.
<zimoun>Anyway! That’s does not cook the rice. ;-)
<winter>hm yeah so compression is evidently always true, it's not overridden in scripts/image
<winter>wonder why changing it to false didn't do anything -- is there a printf equivalent in Guile I could just add to the function to make sure it's being called?
<winter>(or I could throw an error or something... :-)
<gabber>civodul: although i was less interested in editing the service file itself (i was already patching it) but interested in the actual process invocation done through herd. i am in the process of patching dnsmasq (to include more options) but when it started it failed saying only something along the lines of "wrong command line arguments" -- and i wondered how exactly my patch was parsed. then i found the relevant .scm file in the store
<gabber>containing the `make-forkexec-constructor`. it's not really human-readable but i think i can work my way up from there :)
<lechner>Hi, what is the default value for (compose) in (service-type), please, and how is "append" different from "compose"?
<gabber>lechner: isn't compose a Guile default Higher-Order Function?
<lechner>Hi, is it possible to get the benefits of define-syntax-rule constructs like define-configuration when a draft service is being included via Guile's "load" instead of use-modules plus exports?
<lechner>the records fields show up as unbound variables
<attila_lendvai>lechner, it should be: guix shell --with-commit=guile=9d339ea1a95c3b2d04a88aa6b116f997349fc4f4 guile, except "guix shell: error: the source of firstname.lastname@example.org is not a Git reference"...
<lechner>Hi, how may I use a modified Git check out of Guix to reconfigure my system with custom channels, please?
<ngz>efraim: In commit e36ac715518387686bd8165e1724ce54984ee0ee, I added texlive-fancyvrb and left texlive-latex-fancyvrb untouched to avoid a massive number of rebuilds. Is there anything to do on the core-updates branch to make the merge easier?
<apteryx>OK. I see at least: Reading symbols from /gnu/store/7v68yjqr31zn8z88n1vs7rpwg3adc31r-jami-20230206.0/bin/.jami-real... and Reading symbols from /gnu/store/9hivfps50w25m7jbqnrpnf7i4nwhajmk-profile/lib/debug//gnu/store/7v68yjqr31zn8z88n1vs7rpwg3adc31r-jami-20230206.0/bin/.jami-real.debug...
<apteryx>civodul: it's spawing a lot of threads and leaking files somewhere, only reproducible on my end so far, eh.
<dthompson>gnucode: hey I heard you might need some haunt help?
<civodul>apteryx: "Reading symbols" is a good sign
<apteryx>arg how do I umount a NFS shares that wen't offline; it's stuck
<nckx>ekaitz: Are there any other lscpu vulnerabilities still unmitigated?
<mvnx>Is there a recommendation for/against running `guix system reconfigure` in a (m)cron job? Is it best to leave this as a manual process? Or what are some things I should take into consideration to decide for myself? I'm on a personal laptop and a reboot in the middle of the night is almost never a concern if required
<lechner>civodul / Hi, when I update a commit hash in a guix.scm file, and then run 'guix shell -f guix.scm' no rebuilding happens. Is that meant to be like that?
<winter>hey nckx! so, I figured out the issue, but for whatever reason, pre-inst-env... is not working, so I can't test the change.
<nckx>mvnx: Guix provides an unattended-upgrade-service-type (see manual) that I think answers your question.
<nckx>winter: Are you running it within ‘guix shell -D guix’? (Yes, even after building this is still required.) If you are, define ‘not working’ more verbosely :)
<winter>nckx: guix system image -t iso9660 gnu/system/install.scm or whatever that file name is
<winter>same drv with and without pre-inst-env, assuming that list is edited
<nckx>lechner: ‘guix shell’, like all guix-something-this-package, falls back to building a package when it needs it. That's all I can say. I'd need to know more about your expectations/results to say more.
<nckx>Guix isn't *fast*. The image generator also uses a ‘subguix’ (not sure if it's an inferior exactly, but something like that) rather than the calling Guix, which is slower even when it doesn't need to build it first. Which it is currently doing here.
<winter>Oh, interesting. I thought it was just staging a drv and then going?
<lechner>nckx / ok the bot should now be immune to your pictures. can you please post one?
<lechner>everything is find when i go into a guix shell -D -f guix.scm and run the bot with GUILE_LOAD_PATH=/lcl/lechner/guix/guix-helper-bot/git/scm:$GUILE_LOAD_PATH scm/guix-helper-bot.scm --nick=peach-cobbler --channel='#guix'
<lechner>but guix shell without -D and calling the installed (and wrapped script) bombs
<nckx>winter: Conversely, when I change (gnu build image), ‘./pre-inst-env guix system image -t iso9660 gnu/system/install.scm -d’ does detect the change.
<lechner>nckx / how can it be a caching problem. i am having a crisis. isn't this the whole point of guix?
<nckx>winter: There's a poorly understood failure mode where pre-inst-env will stop picking up local changes when the ‘build’ gets out of sync. Try ./bootstrap && ./configure --localstatedir=/var && make to see if that ‘helps’.
<nckx>lechner: Oh, I agree with you. This is caching at a very high level (‘I see you're running the same command you ran earlier, let me be fast for you’), not something fundamentally Guix-breaking (Guix is still very good at hashing things), but it's still unacceptable.
<nckx>I understand. However, your route to finding out how is equal to mine: reading the code to see what is hashed where and how. I don't use ‘guix.scm’. Not going to say I dislike it, but it's never been my jam, and bugs like this don't help.
<nckx>I'm technically working so hunting it down now is not an option :)
<lechner>thank you, i can do the work. but this contradicts a basic expectation, as illustrated by civodul's polite but curt response on the subject earlier. do you have some advice where to start looking? (done ranting)
<nckx>lechner: With other guix commands than ‘guix shell’. I guess I've been lucky. I expected this as little as you did.
<lechner>or maybe we should gradually paint mona lisa in ascii art while the downloads are happening
<nckx>winter: For later: what's the name of your kernel image? I see no need to postpone adding it upstream, it's an obviously correct change. My own kernel has this list of possible kernels: "^(bz|z)Image$" "^Image\\.gz$" "^vmlinu[^x](|-.*)$" but, since I made that list, it might be inaccurate or incomplete.
<jonsger>lechner: uff, doesn't look healthy watching that stuff...
<jonsger>how do you folks reboot your Guix System servers? "sudo reboot" doesn't work really good for me in the past months and weeks. It throws you out of the SSH session but fails to do a proper reboot...
<nckx>So, I use Contabo, which are kind of old-fashioned and at time janky—which I *like*. They give me (virtual) box, not some cloud-inited phantom, with a VNC connection that literally shows the ‘screen’ and whatever was printed to the console hours ago. Also, ‘sudo reboot’ works, which is apparently a premium extra.
<apteryx>hm, so propagating native inputs may fail for cross-compilation, perhaps
<jonsger>nckx: ehm, of course I can reboot the VM via some button. But why shouldn't that be possible via SSH? I tried it again, this time it worked. Some timing/shepherd whatever issue. Never had that with other distros...
<nckx>I don't quite have the resources to ‘just try’ but if it's likely to work I would.
<lechner>jonsger / nothing stick out at me. i might try network-manager (or connman) instead of dhcp-client-service-type. against my better judgment, i have had most success with that, although it will pull in a lot of extra stuff.
<jonsger>on my bare metal server I have/had this problem as well. There I'm already on static-network. Need to check if the problem still occurs there...
<lechner>jonsger / is everything getting started (or mounted) at boot?
<lfam>ellysone[m]: I see. Yeah, it's not so easy to install the OS automatically. Maybe we could implement some logic in the installer about guessing about the partitions. It would require some thought / advice from interested users. That's you! :)
<mirai>lechner: the canonical-name ones are likely to raise some eyebrows
<mitchell>lfam: The installer is implemented as a list of lambdas, so-called install steps. The newt based installer currently runs the nice GUI that helps you step through the installation. I think it should be possible to make another installer which doesn't require user input but can be staged with a desired file system layout and make it happen before calling guix system init to instantiate a prestaged operating system
<mirai>the rest I believe shouldn't raise any issues
<mirai>its been broken for a long time afaik, judging some threads and bug reports in guix MLs
<mitchell>lechner: I would love for guix to replace openwrt on my router. I installed that thing like 3 years ago and I can't figure out how to update it short of downloading a new iso and starting from scratch.
<mirai>though it makes things right for NM users, connman users = no idea
<mirai>it doesn't break connman but a cursory search didn't reveal any similar feature to nm-online
<mitchell>jlink edu is pretty good. Like $50 last i checked some years ago
<mitchell>Just don't do anything proprietary with it!
<mitchell>There are some LPC boards which can be made to act like jlinks which are around $20 but they are way jankier
<lechner>my router has u-boot and a usb port. i have an extra box for experiments.
<lechner>mirai / can i run a Git checkout with my own channels?
<jonsger>does this command keep-going for you: https://paste.debian.net/plain/1271998 for me it stops always with "guix build: Fehler: build of `/gnu/store/a6sj63shblc5kd63d3dhfc35jxslpgjb-rcas-web-0.1.0.drv' failed" instead of keep going and trying the other packages to build...
<mitchell>they can just get data off the chip faster
<mitchell>It can be handy when you are dealing with stuff running on an fpga for example. JTAG can have multiple chips chained together so you can get data from all of them over the same bus
<mitchell>Plus they come with licenses for pr*prietary software which some people find useful.
<nckx>jonsger: That is prohibitive to try, but could it be related to grafts? Does it happen with --no-grafts?
<bjc>ah. that's definitely above my pay grade. i only ever debug with one chip at a time, and i still haven't messed with fpgas. maybe one day
<mitchell>bjc: Me too, what I learned while going down this route is it's a mistake to begin with. Use the JTAG to do the boundry scan to make sure the hardware works, but there are many ways to debug these more complicated systems and it begins with writing software you can actually debug
<nckx>ellysone[m]: <rescue mode … dl the guix binary and install the system as if it was like other machine> is how I install all my Guix System VPSes. I've never messed with the installer or automation, though.
<bjc>yeah, a few months ago there was a big stink because the guy who owned the trademark staged a coup
<bjc>not, like, a real coup, but a hostile takeover of the project
<florhizome[m]><bjc> "iirc, sourcehut has a *lot* of..." <- Sourcehut services are a mixture of python, go and js
<florhizome[m]>I stopped working on a package for the core service when I noticed I needed a bunch of js stuff injected somewhere in there and I was not sure how to do it
<mitchell>lechner: I think many of these low-power phones they are talking about purchasing for their computing power are perfect targets for zephyr. Zephyr can be a unified target which spans the hardware discrepancies between the high and low ends of mobile market. I have some code which can deploy the firmware produced by the zephyr-build-system to applications running the zephyr smp server over some interface. I have the beginnings of a
<mitchell>service definition which can ensure the right firmware is deployed and take action to correct it. This can be extended by another service which actually implements the distributed computing algorithm
<lechner>i'd be happy just to see the pile boot. that would be the pile next to me, even though i don't even use cell phones personally
<lechner>ACTION is going to clean his dentures and watch some TV
<nckx>If you're referring to <https://logs.guix.gnu.org/guix/2023-02-23.log#201859>: I sent the message asking whether the repository mitchell was troubled with was public, right before they pasted the URL. It arrived after. My connection was, as someone more articulate than I has written, ass.
<lechner>ACTION recommends guile-tap, which is unfortunately not srfi compliant
<bjc>honestly, i don't really care *that* much what's used. because my next quistion is: how much teeth pulling would it take to get shepherd's unit tests out of bourne shell and into something reasonable? =)
<bjc>i'm willing to do the work, but my track record with getting anything but trivial patches into guix and shepherd is not great
<lechner>i have use TAP for billions of tests in Perl and recommend it warmly
<winter><nckx> winter: There's a poorly understood failure mode where pre-inst-env will stop picking up local changes when the ‘build’ gets out of sync. Try ./bootstrap && ./configure --localstatedir=/var && make to see if that ‘helps’. <-- Running this now -- was I supposed to run make before ever using pre-inst-env? Manual only mentions
<winter>> To do that, you first need to have an environment with all the dependencies available (see Building from Git), and then simply prefix each command with ./pre-inst-env (the pre-inst-env script lives in the top build tree of Guix; it is generated by running ./bootstrap followed by ./configure).
<lfam>It is true that the manual doesn't say `run make`, but the experience of using 'pre-inst-env' without running `make` is so slow that I think most of us just do it anyways
<lfam>Like, this manual section comes after the section "Building From Git", so it's assumed that you have "built Guix"
<winter>speaking of, I think the shell examples in Building from Git probably shouldn't pass --pure -- it, IME, breaks pre-inst-env
<mitchell>An outsider who has never used something like `pre-inst-env` might not understand what it is or where it comes from though
<nckx>lechner: Unlimited does not mean infinite, it means as many as possible.
<winter>sorry, i should just nuke my checkout and read it top to bottom
<lechner>my exec-env kernel module will get rid of pre-inst-env
<nckx>I think we're all familiar with Linux's scheduler and hence weary of dumping unlimited jobs onto it.
<civodul>apteryx: there are several issues: pkg-config isn't designed with cross-compilation in mind, to cross-pkg-config is a hack (a conventional hack) to work around that; the perl-extutils-pkgconfig invokes "pkg-config", not "TARGET-pkg-config", so it won't benefit from cross-pkg-config anyway
<winter>I wonder why I never got the keyring error when doing pre-inst-env without building Guix first
<patched[m]>How can one go about finding which package one has that depends on another package? I want to get rid of gcc from my profile, I have removed gcc, gcc-toolchain, g++... But gcc persists, and it is located in a gcc package in the store.
<winter><civodul> actually there's an even better fix, already used in a few places: disable cross-compilation of font-gnu-unifont altogether <-- as in stopping it to built entirely, or just plucking the output from a native build?
<mitchell>to find which package is causing another to be included but I do not know it off hand