<necrophcodr[m]>> In order to maintain stability, the guix-bioinformatics channel depends on a specific commit of upstream Guix. So, it is recommended to isolate use of the guix-bioinformatics channel in a separate guix pull profile.
<rekado_>gabber: the patch looks good to me. I can apply it later and fix a few problems before pushing it.
<rekado_>there are a few problems with formatting and style, but I don’t think we need to delay this by asking you to send a revised version.
<PotentialUser-84>Hello. I am interested to replace my doom-emacs setup (although it works fine) with emacs packages managed by guix. Basic functionality I want to keep is which-key, evil-everywhere, magit, projectile or equivalent and a basic python setup (at my workplace). Are there any pointers or does someone already reaches a similiar setup?
<jpoiret>PotentialUser-84: i think that while you'll have the packages installed by doom, you'll be missing all the doom glue
<jpoiret>that's how the guix pull profile is constructed
<jpoiret>guix/self.scm is for guix's own build process when being guix pull'd
<Kabouik>Hey there, has anyone heard about any success running appimages on Guix system? I know it's like the opposite of the philosophy of Guix, but I depend on one appimage and yet I'd like to get as close to the Guix philosophy as I can. Last time I checked was around Xmas and pkill9 had some kind of proof of concept but I failed to use it for my appimages (https://gitlab.com/pkill-9/guix-packages-free/-/issues/3), and there is also
<Kabouik>The appimage I need is rather complex too: it depends on the GPU or iGPU, streams video (cloud computing), conveys mouse/keyboard inputs, and grabs the mouse within window borders; I suppose all this are even more reasons it'd fail
<civodul>Kabouik: i suspect it's the same problem as with other ELF binaries: they probably need to be patched to refer to the "right" ld-linux.so, no?
<Kabouik>Anyone made appimages work with this? That's interesting, would be cool if a simple path patch would fix it all
<NinjaTrappeur>Kabouik: if you're up to get your hands dirty, you could mimick what's done in NixOS on Guix. The overall idea is to unsquashfs the appimage before linking some libraries to the entry point (AppRun).
<NinjaTrappeur>The NixOS appimage tool generates a chrooted FHS with the usual suspects in terms of libraries. It's a solution that'll work 90% of the time.
<NinjaTrappeur>This script is meant to be used as an entry point. You won't necessarily have to translate it to guile to start working on that.
<NinjaTrappeur>I think the first step would be to create something analogous to the NixOS fhs chroot. Either by creating a FHS chroot yourself, either by patching the appimage entry point and injecting the right libraries.
<NinjaTrappeur>(I'm not skilled enough with Guix either to provide further help ><)
<ric342[m]>I'm curious, has anyone created an example scheme file that can build (and maybe also configure) an OS other than guix from guix? Such as a debian vm?
<jpoiret>ric342[m]: i'd say it'd be way too out of scope
<ric342[m]>I think gnutoo made one for arch though, not sure if he got it to fully work or not though
<ric342[m]>Well, without the configuration part, which definitely sounds hard
<podiki[m]>apteryx: great, I'll take a look at how to extend container maybe; the hard work was already done by others for a non-free package
<podiki[m]>apteryx: but just using that wrapper for something like bash gets you most of the way, needed some env variables and it is mostly there
<unmatched-paren>jpoiret: Seems like I need to make a %extension-path variable. Should I add this in gnu/packages?
<podiki[m]>apteryx: any discussions on guix-devel about design decisions before? or maybe I'll start a thread, see what would be useful baseline
<jgibbons[m]>Hi guix! I have 19 chapters planned for my book, including a chapter each on package definitions, using a development cycle with guix, build systems, the test suite, scripts, contributing upstream, guix home, virtual machines, services, deploying, building an offload server, channels, and time-machine. I'm also considering writing about configuring a secure system. Are there any other topics I should add to the outline?
<unmatched-paren>And maybe a chapter about the API it provides for extensions and scripts.
<unmatched-paren>with information like how to manipulate the store, how to build a derivation, et cetera, things that might be useful when writing an extension or script
<vagrantc>jgibbons[m]: not sure how you wrote it, but there has been discussion about making changes to the development cycle process for staging and core-updates ... not sure if it will go anywhere, but might be good to not hard-code too much in a "book"
<vagrantc>jgibbons[m]: foreign distro installations vs. Guix System ?
<vagrantc>jgibbons[m]: curious what the target will be, as a lot of that is covered in the manual
<jgibbons[m]>vagrantc: I already have a chapter mostly complete on installation.
<jgibbons[m]>I haven't written any of the chapters I said I have planned.
<jgibbons[m]>I want to provide a more in-depth look at all those topics. For example, I'm going to include a Dockerfile to build and install guix from source on a Debian system without relying on guix bootstrap packages.
<jgibbons[m]>I already have working instructions on running guix in docker.
<jgibbons[m]>I'm also going to try to provide a guix-built guix Debian package.
<jgibbons[m]>vagrantc I'll walk through the baby steps for defining packages and constructing services. There are a lot of services I suspect guix users might want like minetest, infinoted, and drawpile. Not to mention the many other networked games and utilities already available without matching services.
<jgibbons[m]>Does the manual include a section on how to define a build system? Last I checked it only lists what's available. Same with scripts.
<ric342[m]>not sure if in a usable enough state but, jgibbons what about reduced binary seed bootstrapping?
<jgibbons[m]>ric342: I'll include a chapter on the reduced binary seed bootstrapping if I can.
<ric342[m]>Will you also be posting it online? Maybe I will read it, sounds cool
<jgibbons[m]>unmatched-paren: my book will be an alternative to using the source.
<jgibbons[m]>ric342: I would like to get some money from my book because a lot of time is going into my research. I've considered crowdfunding prior to release. I've also considered releasing it under GNU FDL and including a plea for crypto donations in an invariant section.
<unmatched-paren>jgibbons[m]: be aware that some (many?) consider invariant sections to be non-free
<jgibbons[m]>Some who have shown interest have said they prefer digital
<ric342[m]>Connecting to the onion site in firefox works, so I think the tor daemon is working
<ric342[m]>I also tried replacing localhost with 127.0.0.1 but it also did not work
<jgibbons[m]>Oh, I could try planning a chapter on building a system for arm SBCs. There is something forked from uboot that lets distros design with a UEFI bootloader. Mobian is encouraging its use with pinephone. I can work out how to make a generic guix arm efi image and describe how that works.
<ric342[m]>Yup definitely, gnutoo has some examples for that on his gitlab jgibbons
<ric342[m]>(not EFI though I think, just regular u boot)
<podiki[m]>apteryx: meaning with this option the shell spawns in a container with an FHS setup for given inputs? I think it might be helpful to have some default package lists, since it can be a lot for an isolated container to get anything to work
<jgibbons[m]>I don't know how blobby it is so I won't discuss it further here.
<jgibbons[m]>I've never been able to get u-boot to build with guix no matter what architecture I'm using.
<apteryx>podiki[m]: yes, guix shell spawned in a container with the given inputs. Why would it need a default packages list? I'd prefer users with large environments to manage to use a manifest.scm file.
<apteryx>so they could 'guix shell --fhs --manifest=manifest.scm'
<podiki[m]>yeah sure, maybe a cookbook or other entry for useful starting manifests
<podiki[m]>e.g. doing web/js development, or some language; though might need to set some env variables as well, right now doing that manually as not sure how search-paths interact here
<podiki[m]>(wasn't there some discussion here the other day about guix shell and setting env variables?)
<johnjaye> honestly if they left the print instead of print() syntax in i think it would have gone more smoothly
<unmatched-paren>> It seems that developers have become wary of 2-to-3 transitions for programming languages. Fear not! Switching from Guile 2 to Guile 3 turned out to be an easy task. In fact, very little changed in the language itself; what did change—e.g., semantics on fine points of the module system, support for structured exceptions—is either optional or backwards-compatible.
<vagrantc>jgibbons[m]: regarding EFI, u-boot can also do that, that's where tow-boot got it's EFI from. The main differences as i understand it is that tow-boot is usually installed to something other than the boot media (e.g. flash on spi or the special emmc partitions used for exactly this purpose)
<vagrantc>jgibbons[m]: it also apparently has enabled and/or added functionlity to interact with it from a menu on the screen
<vagrantc>really surprised you can't build u-boot ...
***aeka` is now known as aeka
<stikonas>vagrantc: provided that keyboard and screen works in u-boot... Which I was not able to get working
<vagrantc>admittedly i've mostly used u-boot with serial consoles ... but definitely a few notable exceptions (the computer i'm using now)
<stikonas>yes, I had more luck with serial consoles but I wasn't able to get keyboard/screen to work on rockpro64...
<apteryx>I've tried with /26 but I still get channel 3: open failed: connect failed: No route to host\nchannel 4: open failed: connect failed: No route to host upon attempting to access iDRAC via node 129