<dcunit3d>when i'm running `guix pull` i can't seem to up the commit or url for the 'guix channel <dcunit3d>it just pulls from the same `6f75565` commit everytime which is preventing other channels from updating. i <dcunit3d>i've tried changing the commit hash to something more recent and the url to a local copy of the savannah repo with file:/// <dcunit3d>for other channels, i can specify these things fine. <necrophcodr[m]>dcunit3d: are you specifying those in ~/.config/guix/channels.scm? <dcunit3d>yeh, well that or ~/.config/guix/base-channels.scm and `guix pull --channels` <necrophcodr[m]>because you could also just try removing the commit specified in your channel configuration for the guix channel and see if that does it <necrophcodr[m]>then add it back in afterwards with the commit guix shows with `guix describe` iirc <dcunit3d>either way, it only pulls the 6f75565 config <dcunit3d>if i change any of the other channels, those updates are shown when i run `guix pull`, but when i change the guix channel definition, it doesn't show <dcunit3d>i think it might be that another channel is pinning the commit. i just removed the guix-past and gn-bioinformatics channels and it's updating correctly <necrophcodr[m]>i think your mind is in the right place. it probably is specified somewhere somehow. i don't know enough about the internals to know where it could look though. <necrophcodr[m]>dcunit3d: ah, i was not even aware that was possible, but that's a VERY good point <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. <necrophcodr[m]>Yeah I wasn't even aware those things were possible haha, but it's definitely good to know! <dcunit3d>well it seems to be working now. it's been like this for about 2 weeks, so i was worried something was corrupted <dcunit3d>thanks. i gtg. i'll be back on later though <ulfvonbelow>anyone know how to make a container where the loopback interface isn't accessible but other network interfaces are? <jorge[m]><jorge[m]> "this is happening in the..." <- Please help me I couldn't solve this <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 <koorosh>when I run guix package -f guix.scm there is no error but it never terminates and starts using a lot of ram <rekado_>koorosh: what is your intention with that native-inputs field? <rekado_>why should this package be an input to itself? <rekado_>and why should a string be an input? <rekado_>if it’s supposed to be a label (note: we don’t use those any more) then you need to use an alist <koorosh>to be honest I don't know how my native-inputs should look like the guix manual says that packages build with guile-build-system should provide a guile package in their native inputs <rekado_>koorosh: this means the “guile” package, not just any package using guile :) <rekado_>use (native-inputs (list guile-3.0)) <rekado_>you need to set GUIX_EXTENSIONS_PATH <unmatched-paren>rekado_: My pre-inst-env does that, but I thought guix pull would set that itself? <rekado_>sadly the variable is not set automatically <rekado_>jpoiret: looks like it’s not actually documented <rekado_>unmatched-paren: the search path mechanism fails us here <rekado_>unmatched-paren: the “guix” package has a native search path for that variable, but you won’t ever install that package <rekado_>jpoiret: it’s a package that provides a Guix extension <rekado_>unmatched-paren: gwl doesn’t set the variable <jpoiret>right right, I was comparing that with a guix channel that's pulled <unmatched-paren>Would a patch to automatically set GUIX_EXTENSIONS_PATH be accepted or is there some reason not to? <jpoiret>i think we'd need to add a field to the .guix-channel file <jpoiret>but with that added it shouldn't be too hard imo <rekado_>unmatched-paren: it was always my intention to have it set automatically <rekado_>would be nice to have a mechanism that works both for channels and for packages. <jpoiret>i didn't get an ack for my teams patch <oriansj>Not_Leader: no more than paying taxes makes one an adult <unmatched-paren>hmm, why is `./pre-inst-env guix pull --url=file://(pwd) --profile=/tmp/guix` taking so long? <jpoiret>it's got to update its local checkout of that url, which will be a different cache than the usual guix one <jpoiret>you're basically fetching the whole guix repo again <jpoiret>did you disable authentication also? :) <jpoiret>well, you've got local commits that aren't signed, right? <jpoiret>it'll just error out later, no worries <unmatched-paren>I've added an extension-paths field to <channel-metadata>; I guess I should add a test for it in tests/channels.scm? If so, what exactly should I test? <efraim>does setting '#:parallel-build? #f' change the derivation? <unmatched-paren>I guess I should test deserialization of the field from channels.scm <unmatched-paren>rekado_: Seems like guix extensions are managed as services, is this correct? <unmatched-paren>aha, looks like i need to modify guix/ui.scm (extension-directories) <unmatched-paren>I'm not sure how I'd get the extension directory from the <channel-metadata> to (extension-directories) though. <Not_Leader>is guix home recommended for user–level package management? <PotentialUser-84>jpoiret: Thank you. I will keep doom for now until I am more familiar with the needed packages <jpoiret>unmatched-paren: rather, i'd suggest modifying guix/channels.scm <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>Right now my Guix machine is a bit dormant but my ultimate goal is still to use Guix on my main computers <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. ***wielaard is now known as mjw
<Kabouik>I would be happy to do that but I think luck is not the only thing I'd need, I'm not sure I'm skilled enough for the task :< <Kabouik>I know bash (kindof) but not guile, and am not familiar yet with where libraries are organized in the Guix filesystem <Kabouik>That's the script I linked above I think, so I starred it already and hopefully will give it a go at some point, but I am not sure I can translate it into Guix <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 <jpoiret>hmmmm, right, but then you're not really using guix system then <jpoiret>i don't think it'd be too hard to package the arch install scripts for example :) <ric342[m]>Yeah upon a closer look it looks like this is kind of installing it onto the system <jpoiret>the example you gave doesn't let Guix build the OS, it just provides the installer programs <jpoiret>to let Guix build the OS would be too hard, we'd need bindings to the target package manager <ric342[m]>I'm thinking as in like, bootstrapping an OS, and maybe from there finishing it in a vm <ric342[m]>As I seen GUIX talking about that on the blog, although maybe I'm misunderstanding <podiki[m]>on the FHS chroot front, I have a modified fhs-container (from that other channel) that I've just been using to try out some development stuff <podiki[m]>eg. rustup, poetry, npm, stuff that likes to downloads binaries sometimes; think I got a lot of it working, all in an isolated container <podiki[m]>although obviously it helps run binaries, would a guix shell command to provide an fhs environment have its place in guix? i feel like it would, useful development tool <podiki[m]>esp for ecosystems like js that we don't have much in guix (node will download binaries) <ric342[m]>I tried out the onion substitutes section from the cookbook, however, when I do a guix install it just hangs or fails the tls <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 <zimoun>from REPL, how ,use is from (use-modules) ? <ric342[m]>I didn't put anything different into (use-modules) <ric342[m]>Is there something I am suppose to add to that? <zimoun>ric342[m], no no. I do not know. It is my question because I am blocked. Not an attempt to answer you. Sorry. :-) <apteryx>podiki[m]: it would; --fhs has been on my TODO list for a long time <apteryx>it'd need to implicitly pull --container <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]>I want to make 100 printed copies and donate them to public libraries across USA. I guess my audience is beginners to intermediate users. <unmatched-paren>jgibbons[m]: it should be fairly straightforward to figure out build systems from the source code <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]>Personally I usually read digital before deciding to get a paper copy <ric342[m]>But if it's something that has a new revision every few years I probably wouldn't get paper <ric342[m]>The donation model seems nice, but it's up to you if you think it will adequately reward you, but in combination with a crowdfund may be workable <unmatched-paren>jgibbons[m]: Hmm, I guess you'd have a website with an introduction to the book that isn't actually part of the book, right? <unmatched-paren>Crowdfunding sounds like a good idea :) A chapter for each milestone, maybe? <jgibbons[m]>Some of the planned chapters were requested on this IRC. <apteryx>podiki[m]: I was thinking about 'guix shell --fhs' ***Dynom_ is now known as Guest9321
<ric342[m]>btw does anyone know about using the onion substitute server? <jgibbons[m]>ric342: I suppose you'd need to configure guix to use the onion daemon as a proxy. Have you tried that? <jgibbons[m]>I don't know how to do it, could be documented in manual? ***mark_ is now known as mjw
<ric342[m]>jgibbons: I tried following the example in the cookbook <ric342[m]>hen I do a guix install it just hangs or fails the tls <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?) <podiki[m]>yes, but lsome will need to be different in the fhs container; some you'll want to preserve though <jgibbons[m]>G2g. I'll come back at a different time to report my book's progress. <johnjaye>ok. is it like a python2/3 situation where the new version totally ruins existing code? <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. <johnjaye>by the way did anybody know the error I got when trying to install earlier? <johnjaye>i'm stuck in virtualbox until i can get this resolved <unmatched-paren>that's pretty bizarre. it's not normal to have that many issues with installation <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... <rekado_>keyboard and screen works for me on the rockpro64 <ric342[m]>Are there any substantial hurdles to running a guix system with musl instead of glibc? <vagrantc>ric342[m]: i suspect this is one of those "theoretically no, practically speaking lots" sort of issues <ric342[m]>I wonder if you can look at a os that uses musl and convert the packages over? <ric342[m]>It might be nice for a device with low resources, even if it has very few packages available <ric342[m]>this kind of flexibility might be an advantage the guix way of doing things could offer <vagrantc>ric342[m]: it would pretty much be a completely different system <ric342[m]>why? to me if it's using the guix specific utilities and managed through scheme it is just extra modules <ric342[m]>guix even supports an entirely different kernel <vagrantc>because all the existing packages indirectly depend on glibc, rebuilding anything that low on the chain will result in an entirely different system ... possibly using similar methods <ric342[m]>that's true, but couldn't the guix package manager be utilized to resolve the different c libs as like a different dependency option for the packages? <vagrantc>as i said, theoretically it should work, practically sounds like a project surely full of surprises :) <ric342[m]>i e both package definitions exist in the channel or have variable for it effected by which clib is chosen in the main system config.scm? <vagrantc>you'd need to rebuild the bootstrap chain ... unless you used glibc to bootstrap your musl <ric342[m]>maybe so, but maybe guix can be a very universal base so different distros can base on it and re-do the same things less <vagrantc>sure, in the sense that guix is "just" a software building tool <ric342[m]>sounds easier for collaboration between different groups too <ric342[m]>i suppose using glibc to bootstrap it is okay <ric342[m]>whatever makes the most sense as a bootstrap with the most support <ric342[m]>im still new to guix but I'm hoping as a base it can become very widespread like how debian is <ric342[m]>it seems pretty challenging right now but there's a lot of things that can be built on it to make it feel like a more user friendly os <unmatched-paren>but with nix "TeH sYnTaX" is even worse, so maybe guix has a better chance than it <ric342[m]>the average user doesn't necessarily need to see that at all <ric342[m]>the role of a distro maintainer can be to write those for them as well as tools that can make basic adjustments to it <gnucode>is there an easy way to apply a patch from debbugs-gnu to my local guix repository? <gnucode>unmatched-paren that seems very tedious... <gnucode>It would be nice if I could apply the patch from emacs and debbugs...just my 2 cents. <morganw>I think there is an Emacs package which can apply git patches that are in a mail message. <unmatched-paren>I use aerc which allows me to download and apply the mbox automatically, not sure whether $EMACS_MAIL_CLIENT can do that <gnucode>unmatched-paren are you using mbox to read the guix email achives? <gnucode>ok. Maybe I should give aerc a try. I keep wanting to use emacs for most of my email and everything needs. But I have a really hard time figuring out how to use it. <gnucode>I used to be able to send email via emacs...now I can't. <unmatched-paren>gnucode: I'm afraid my patch adding aerc hasn't been merged yet though <morganw>It believe that if you use Gnus there is also a built in command to send the message buffer to a pipe and so something with it. <morganw>Or possibly it was built into message mode, I think I tried it once but I don't remember the exact process. <rekado_>gnucode: I use mu4e (which uses gnus message mode to display emails) and wired up the mu4e-action-git-apply-mbox action. <rekado_>I dog-food mumi / issues.guix.gnu.org <ric342[m]>I'm new to emacs and so far I'm liking doom emacs for org mode editing some scheme code, it's been easy enough to get started since I'm used to vi bindings <ric342[m]>But about the meme of emacs being an operating system, I wonder is it really a good idea to view email, rss, matrix etc and more within emacs from a security perspective? <ric342[m]>I feel like going beyond general text editing, or at the most beyond offline only uses, it sounds like it would be hard to maintain security. <gnucode>ric342[m]: use it for what makes sense to you. I have given up on using emacs as a web browser. It is not a very good web browser in my opinion. <ric342[m]>Also maybe guix can be leveraged to improve the security model of emacs? <gnucode>by the way, it seems like I was able to apply patches. Which is kind of cool. <ric342[m]>(note I dont know hardly anything about the security model of emacs, I'm just wondering things) <apteryx>rekado_: hi! any news about accessing iDRAC via node 129? <rekado_>apteryx: oh, that… You needed a free IP on the management network, right? <apteryx>I'm kind of clueless as to *what* I need, but I suppose yes. I had tried to set up an IP next to the one Berlin is using that seems to be used to route to iDRAC, but in vain <rekado_>that management network is pretty full <rekado_>I’ll have to check out docs to see if there’s an unused IP we could assign <apteryx>OK! I think I had sent some nmap scan result or partial result to guix-sysadmins, not sure if that's useful. <rekado_>looking at your email I think you got the netmask wrong <fnstudio>hi :) is it possible to run shepherd/herd on a foreign distro? e.g. in order to run services such as cups from guix as a non-root user? <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