<excalamus>same thing when I try to run guix shell after the -- <excalamus>let me rephrase my original question: is there a way to set up a shell which is running a previous version of guix <excalamus>I guess I could just run guix time-machine --url... --commit... --branch...before every command in the blog post. I could probably assign an alias to it to that it was less cumbersome <M6piz7wk[m]>Is there any solution in guix that allows me to track youtube subscriptions? <mekeor[m]><lilyp> "Olivetree, mekeor: The proper..." <- no, thank you. i trust a compiler more than myself, concerning memory safety <excalamus>I can do `guix time-machine --url=https://git.savannah.gnu.org/git/guix.git --commit=c55a64cb7e82e88e26c26995f983fc9675b6276e --branch=master -- shell` which gets me into a build environment, but `guix describe` still shows my system guix commit. I guess it's working? <excalamus>M6piz7wk[m], looks like it's developed by a company. You might try them? But otherwise, my guess is no <singpolyma>I don't know if my company is ready to start advertising for Guix specific work yet, but maybe we would eventually <M6piz7wk[m]>hmm O.o kinda has to be integrated within the project who should do the save guard for the bug bounty <M6piz7wk[m]>and like it's great and ethical source of income for both developer and project 🤔 <Olivetree>lilyp: sure, that would go a long way, but what about aliasing? also, C++ is such a behemoth that I don't think it deserves to be considered a single language anymore <singpolyma>M6piz7wk[m]: that only works if someone inside is also a freelancer or whatever <M6piz7wk[m]>or more like hired contractor or devs also do that on their companies sometimes <excalamus>hmm, if I declare guix within my shell, I get a different commit hash. No clue which commit it is, but it's different <lilyp>Olivetree: you mean with the different standards or with the different frameworks people use? <excalamus>weird, the commit it takes me to is older than the one I specified in the time-machine argument <M6piz7wk[m]>What's the theory behind guix's packaging? Is it like Gentoo where it creates a sandboxed environment and everything installed in an `image` directory will be merged in the system? <Olivetree>Any chance to build/install a package in a channel but changing the version of the package definition? <Olivetree>Or do I need to make my own channel with that single package and change? <lilyp>you can build from file or sometimes even use transformations (--with-latest) <KE0VVT>Guile Emacs is fun, but it is not stable. <the_tubular>I'd also like to trim down emacs, I don,t see why I'd need tetris and whatever emacs doctor is called <the_tubular>This tool is for work, and everything else that is just there for fun shouldn't be there <jgart>the_tubular, try guile-studio <the_tubular>jgart definetly looks interresting if I go by the description <Olivetree>lilyp: I want a previous version, so with-latest won't work, but build from file does the job. Let's see if my idea holds up <jgart>the_tubular, it's essentially an opinionated emacs for doing guile development <jgart>KE0VVT, we're planning to have a docs meetup if you'd like to join to improve them <jgart>but I'll announce it here and on #guix-devel <jgart>KE0VVT, I host a packaging meetup on the last Sat of every month at 2 ET <jgart>that's been going on since Feb. 2021 <jgart>the_tubular, not sure I understand what you mean <singpolyma>Maybe it works so doesn't need much changing? :) <jgart>I know people who are using "older emacs stuff" by choice <jgart>older than guile-studio for sure <singpolyma>Sure, of course. Not everything needs to "update" all the time <the_tubular>I'll definitely check it out, I don't know if it meets the criteria I wanted though <jgart>the_tubular, what's the criteria you're looking for? <the_tubular>I don't mind configuring emacs, I already have a small org file that is for configuring emacs <the_tubular>I just want to cut a lot of bloat that emacs has, so I can install it pretty much everywhere <the_tubular>Some machine I have are 16 gb, so size is important, If I can cut down on useless stuff, I'd be ahappy <jgart>I use emacs-no-x package with it <jgart>I mostly use vis editor though <jgart>what do you want from emacs? <the_tubular>I guess I can just not install it and edit with tramp remotely, but I'd like to have a small fork of emacs in case I need it <the_tubular>jgart I'm still very new to emacs, but I,ve been liking the environement <Noisytoot><jgart> but I'll announce it here and on #guix-devel <jgart>right, without the hash I meant <jgart>I might announce it on #guix <Olivetree>lilyp: almost had it!! glxinfo now complains about X Error of failed request: BadValue instead of the swrast driver <the_tubular>I guess what I'd like is emacs with barely no package installed, and I'd use guix to install the packages <KE0VVT>Well, this is vague — Then relabel the file system with restorecon or by a different mechanism provided by your system. <jgart>the_tubular, what do you absolutely need that's an external elisp package? <jgart>you might want evil-collection also <jgart>if you want evil dired bindings <jgart>and if you want evil everywhere else <jgart>emacs-better-defaults is an essential package for me <jgart>I might fork it though and add a few more better-defaults <the_tubular>But is there a package on guix that is basically emacs with no pacakge installed ? <jgart>if you don't want gtk or whatever <jgart>there's emacs-minimal but I'm not entirely sure of the difference between it and emacs-no-x <KE0VVT>restorecon -vR /gnu: restorecon: Could not set context for /gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2/share/terminfo/z/z29a-kc-bc: Read-only file system <jgart>I just default to emacs-no-x when I don't want a gui <the_tubular>And edit remote file with tramp, no need to install it on remote boxes <mbakke>KE0VVT: the store is mounted read-only by default, you need to 'mount -o remount,rw /gnu/store' first <mbakke>KE0VVT: those are options to the mount command (-o); you should run the same command with ro instead of rw afterwards to make it read-only again <ajarara>Success! I got `guix deploy` to use my sk-ed25519 ssh key. It needs some unreleased changes in libssh. Once those are in a tagged build, how do they land to guixers? libssh is in the dep tree of the guix binary itself... so does it need to be merged to core-updates or something first? <ajarara>spoke too soon :) while building 'acl' guix attempts to read-file the ssh key pulled from the agent. <apteryx>guix uses guile-ssh, which wraps libssh <apteryx>so you'd bump libssh and supposing guile-ssh builds fine, it should work <apteryx>according to 'guix refresh -l libssh' only 28 packages depend on libssh <apteryx>it's unfortunate that we can't 'guix shell -D guix' in the guix checkout <apteryx>(there's a guix.scm file that has nothing to do with guix shell) <sneek>civodul?, pretty sure was seen in #guix 7 days ago, saying: i can apply the patches, changing the variable name as i go. <apteryx>awesome, the mrustc author is working on support to build rustc 1.54 directly <lilyp>the_tubular: people who claim not to need emacs doctor at work are exactly those who need it the most... or potentially can afford a real therapist <lilyp>jgart: I won't say anything except that the usual three-or-less letter package complaint applies <jgart>what should it be called instead? <jgart>maybe similar to golang naming scheme? <lilyp>dunno, might be a bit too verbose <jgart>I imagine it should also be updated to support `guix shell` now. <rekado>one of the aarch64 build nodes (10.0.0.4) seems to be unresponsive. <rekado>and the builds of r-updates are stuck since a day or two. <PurpleSym>Do we have a toml parser in Guile somewhere? `cargo-build-system` seems to use cargo to converts .toml files to json and `julia-build-system` does some regex magic. <rekado>rovanion: there is no network access during the build. So use a native-input instead and *copy* the files in a build phase. <florhizome[m]><lilyp> "the_tubular: people who claim..." <- I saw a repo working on an actual virtual assistant in emacs^^ can’t remember the name rn unfortunately <florhizome[m]><the_tubular> "There's emacs-min, emacs, guile..." <- I use emacs-pgtk-native-comp from the flatwhatson channel ^^ <florhizome[m]>though you could probably replicate it easily yourself since emacs 28 is released. but right now for me it’s ok to not have to configure this stuff myself. <florhizome[m]><podiki[m]> "curios also, as having to run my..." <- that seems to be a default recommendation. <florhizome[m]>also running a command to systemd to import the user environment (systemctl import —user I think) <florhizome[m]>again I think a generic functional desktop environment service would be kinda neat. home doesn’t really cover that. <lilyp>Emacs 28 is out? Quick, let's upgrade our package and fuck everyone's system! <lilyp>(Haha, jk, I'm pretty sure this won't happen with this version bump) <GNUHacker>"apt update" is like "guix pull" or is like "guix package -u"? <mekeor[m]>GNUHacker: btw, you can also run "guix upgrade" instead of "guix package -u" afaik. (that's also more similar to "apt upgrade".) <mekeor[m]>lilyp: emacs-28 is not really released yet, is it? <ajarara>apteryx: thanks for the `guix refresh -l $package` tip' <nckx>Emacs 28 is not released and Arch is on emacs 27.2-1, the latest upstream release. <yewscion>Hello All, I'm trying to run GNU Cuirass locally, since I have an always-on comp in my apartment that has a lot of free cycles to spare, and would like to build everything myself if possible. <yewscion>However, I'm running into an issue where even though Cuirass will have 100+ jobs scheduled, it doesn't actually build anything for multiple hours. Is there some kind of more comprehensive guide somewhere other than the main site, or can someone with more experience than I shed some light as to why this might be happening? <rovanion>rekado: My brain is not working optimal at the moment, so figuring things out is hard. You don't happen to know of an example in the code where a store item is created only to be consumed as a native-input to a build/test? I'm only finding copying of resources within a source tree :/ <nckx>(Should probably be native- style-wise but that aside.) *nckx meant to write: python-clf? <nckx>Also: editorconfig-core-c? and vis? ☺ <rovanion>Oh, right, its just names/symbols and values and in python-clf the input is just declared anonymously. <nckx>For some value of anonymous. <nckx>I don't know your preceding context. <nckx>yewscion: ‘doesn't actually build anything for multiple hours’, as in, it eventually does? <yewscion>When I left for work this morning, it had completed 5/254 scheduled builds after being left for 8 hours, with no currently active build. <yewscion>The last build had been completed >100 minutes ago. <yewscion>nckx: And the processor is strong enough that that is an unreasonable amount of time for builds to take (AMD Ryzen 5 1600). <nckx>rovanion: Thanks. Copyright aside (are test suite videos ‘functional data’? no idea), should be trivial to check out the ‘resources’ branch with git-fetch in an in-line origin, yes. <nckx>It shouldn't take 100 minutes on a Core 2 Duo. I haven't had luck with Cuirass either, and the main Guix build farm is almost completely idle most of the time, indicating some unsolved bugs. <yewscion>nckx: Copy that, so it's not just me. Good to know, thanks! <nckx>rovanion: And note that ‘non-functional data’ just means we can distribute it according to the FSDG (GNU), not the law. There is no way that goldeneye.mp4 doesn't infringe on copyright of people who are extremely prone to legal action. <nckx>yewscion: Wish I could be more useful ☺ <yewscion>nckx: Nah, that was helpful enough. Once I get more settled into Guix, maybe I can help hunt down some of those bugs! Looking forward to it. <PurpleSym>How can I add a secondary default output to a build system? I’ve tried `cons`’ing it in `lower`, but it’s not carried over apparently :( <xelxebar>"Unikernel experiments." "Bare metal Scheme experiments." <nckx>‘I could pa’—oh, it's already in Gu—‘I could update that!’ <nckx>Thanks for the hype atw. <bavier[m]>I like that the loko website includes a screenshot of it running in cool-retro-term <nckx>Where Guile needs many lines to print a completely incomprehensible error, Loko Scheme efficiently manages with one: <nckx>Exception in assembler: Unknown label with irritant $ <singpolyma>Less bytes, equally informative, seems like a win <nckx>Oh, I only now noticed it's AGPL ♥ <nckx>I wish everything were AGPL. <KE0VVT>↑ Current status of trying to get Guix to work on a SELinux system. ***hexteetx is now known as hexteex
<nckx>‘does not point to the correct location for the file’ | find -name guix-daemon.cil → ./etc/guix-daemon.cil <KE0VVT>nckx: I could not find an etc/ with a .cil in it. <KE0VVT>nckx: The docs did not say anything about that. It just said etc/. <nckx>Why's it not installed in ~/.config/guix/current/share? Weird. <KE0VVT>“/gnu/store/0iii8i1lc4wg3wccs1db7y7d8lg80i04-guix-1.3.0/share/selinux/guix-daemon.cil” was the only path. <KE0VVT>nckx: I am on a foreign system. I have not been able to get the Guix daemon to run. No “~/.config/guix/” exists. <nckx>Which Guix is used on a foreign system? <nckx>KE0VVT: Thing is, I'd suggest suggesting $(dirname $(which guix))/../share/selinux/guix-daemon.cil in the manual for those not building from git, but it seems to work only if you haven't pulled. <KE0VVT>nckx: I just used guix-install.sh… <nckx>If you could just quickly share whether that file exists it would save me running guix-install.sh ~in my mind~. <KE0VVT>nckx: [caleb@bender ~]$ $(dirname $(which guix))/../share/selinux/guix-daemon.cil <pranavats>jpoiret: I was able to install Guix on LVM on Luks1. My SSD needed a firmware upgrade before Grub could recognize it. <KE0VVT>bash: /usr/local/bin/../share/selinux/guix-daemon.cil: No such file or directory <KE0VVT>pranavats: Are you Pranav from the vegan MUC? <pranavats>KE0VVT: Glad to see you finally gave Guix a spin on your Thinkpad. Or have I got the wrong person? <KE0VVT>pranavats: I just use the package manager. I don't want to use it as my system, because it is a completely different system from most GNU/Linux distros. <KE0VVT>I can't figure out how to do ANYTHING on that thing. <nckx>pranavats: <firmware, GRUB> Interesting, that's a new one! <KE0VVT>And half the time, I have to get something packaged. It sucks. <KE0VVT>OK, I'll shut up now. Bottom line, I'm just using the package manager. <pranavats>jpoiret: Still some problems with swapfile, and I have to enter the password 3 times. Need to look into how to setup a keyfile to pass to initrd(?). <jpoiret>twice rather? 2x LUKS 1x your session <jpoiret>and yeah, swapfile doesn't swapon on boot right? <jpoiret>as to the initrd contents, I haven't looked that much into customizing it, but it should be pretty doable <jpoiret>it should (we don't use mkinitcpio though) <nckx>mkinitcpio is an Arch script. <nckx>But you can try to ‘do the equivalent thing’… <nckx>Guix's initrd isn't modular though. You might have to fork it to make your changes. <jpoiret>you can look into gnu/system/linux-initrd.scm, gnu/build/linux-{initrd,boot}.cfg <KE0VVT>Arch claims to be vanilla and then has all these custom scripts. Heh. <jpoiret>i mean, you have to have scripts to build your initrd <jpoiret>talking about that, I was thinking of making the initrd more modular recently, runinng shepherd in it rather than just a simple boot script <jpoiret>but i think that'd be tough, reworking all of this. But big gains: we could use the usual shepherd services rather than hardcoded pre-mount actions <nckx>jpoiret: I haven't forgot about your swap patch, by the way, in fact I'm ‘using’ it now — it just doesn't work yet :-/ This may well have nothing to with your patch, and is tied to a few other possible (Linux/bcachefs/I'm not quite sure) bugs which I need to disentangle first. <jpoiret>oh! no worries :) what kind of bugs? <jpoiret>bcachefs! now that's living on the edge <jpoiret>people already look at me weird when i tell them i use btrfs <jpoiret>also, shouldn't we try to "compartimentalize" the kernel-specific things? I notice that the Hurd boot process is a big workaround. Shouldn't we let-system the corresponding shepherd services start and stop instead? <jpoiret>that was my impression while looking at swap services (and they currently don't support the herd) <jpoiret>maybe something like guix/target/{linux.scm,hurd.scm} (instead of the guix/build/syscalls.scm for example) <nckx>We should, jpoiret. The current system isn't that way because it's considered ideal or even good ☺ (E.g., see commit 68b219b for a good groan). <nckx>jpoiret: I'm not even sure which bugs yet ☺ Somewhere between Linux 5.13 and 5.15. bcachefs is great. It is not at all like running btrfs at the same age. <nckx>jpoiret: What I mean by that commit is that the current situation grew organically, we *will* grow (a very poor implementation of) ‘hooks’ whether we want to or not, and hooks are bad anyway: we should be using real services instead, so I love hearing someone suggest that! <nckx>I don't think it's well-supported or -maintained. <tschilptschilp23>I'm just trying to package a python-module (spacy) which kills my laptop's memory in return (better said guix package -f spacy.scm quits after a while stating 'killed') . I think it's because many of the dependencies are not yet in guix and so I define them in the same .scm file. Does anyone have an idea , how to 'nice up' this process? <tschilptschilp23>I already started taking things apart, but it seems that building one of the bigger dependencies 'thinc' has higher memory needs than what my computer here can do (5/8GB RAM free). <singpolyma>How many packages are you building in that scm file? I have done many that way for ruby without issue <nckx>tschilptschilp23: Does this happen during an actual package build or while Guix is ‘calculating’ stuff beforehand? <nckx>If it's during a real build, adding --{max-jobs,cores}=1 might help. <nckx>Oh, and make sure your /tmp is not tmpfs, because (1) it's often quite limited in size (2) means you're storing all the sources & intermediate build results in RAM as well. <davidl>KE0VVT: a recent version of guix-install.sh had a bug in it that made it not create ~root/.config/guix or anything in that directory. Idk if it's been fixed or not - check the git commit log of the file - otherwise, you can just remove the quotation marks from all instances of "~root..." inside guix-install.sh, remove /gnu and /var/guix, then rerun the installer. <tschilptschilp23>nckx: Thank you -- it's stating 'installing PACKAGE' and then becomes non-verbose and gets killed after memory is up at 7.7GB -- I'll try the flag. mhm, not sure about /tmp, looks like a normal directory. I do have a few tmpfs mounts /run/user/* and /dev/shm which are obvious. I honestly don't know how these interact though... <nckx>This sounds like a circular dependency (at the Guile language's module level, not in packages), i.e. an infinite loop. <nckx>That would eventually run out of memory on anything. <KE0VVT>davidl: You mean you publish versions of guix-install.sh without checking if it works correctly? Agh! <nckx>These are hard to debug :-/ <nckx>KE0VVT: Did you mean to ping me? <KE0VVT>Whoever publishes guix-intall.sh <nckx>Never mind, I missed davidl's message. <nckx>Yeah, that was an unfortunate bug that shouldn't have made it to master, but mistakes happen. <davidl>KE0VVT: idk what tests exists for guix-install.sh if any, but yeah it is bad with such a bug as it's the first impression of guix :-/ <davidl>it does manage to install the guix binary, maybe that has confused a test? <tissevert>I'm still a bit lost about what's recommended to install in system and user profile <tissevert>so I'm giving i3 a spin, so I added that plus dmenu to the %base-desktop-services <tschilptschilp23>nckx: that sounds logical (these packages are not so huge I think)! yes -- the 'subdependencies look a bit circular. I will try to take it apart further. <nckx>I can't imagine there being a dmenu service, and doubt there's an i3 service. <tissevert>ohh, yeah, sorry, I mixed up the packages and services <tschilptschilp23>singpolyma: it's about 20 packages -- the one I need depends on 13 which are not in guix, and these tree up to about +7 other ones again. <tissevert>it's called %desktop-services, and yeah of course you're right, I didn't touch that <nckx>tissevert: Okido, it just would have been a very easy ‘well there's your problem’ ☺ <KE0VVT>davidl: so my guix didn't even install correctly? but i'm doing "guix pull" <nckx>tissevert: It really seldom matters. <tissevert>I don't really have a problem yet (or I don't know it yet) <tissevert>I used to install everything system-wide (browser, file manager, text editor…) <tissevert>so I'm trying both: i3/dmenu and fixing that bad habit by putting them back into my user profile <nckx>Like, there aren't many (if any?) packages that will only work in one or the other, and if that is the case it's likely a bug. It's more about user preference, and how long you want to have to wait to run ‘guix system reconfigure’ (i.e., a new kernel is out, yay, time to upgrade, oh no you also put chromium and icecat in your system packages and there's a new rust out, guess we won't be booting that new kernel this week). <tissevert>but now dmenu can't find them, so I'm a bit confused as to how people do it <davidl>KE0VVT: yeah it does install the guix binary even with that bug, u should probably verify the content of guix-install.sh to look for quoted ~root <davidl>u won't get the keys that authorizes using buildfarm substitutes for example if you are affected by the bug. <jpoiret>tissevert: how are you launching i3? <neutral>(i am using modesetting driver for my nvidia 1650 card as i cant get nouveau to function. (glxinfo | grep OpenGL) shows im using Mesa. The problem is xonotic game is running on very low fps and sometimes stutters. Any advice) <davidl>"~root/.config/guix/current/lib/systemd/system/guix-daemon.service" will not expand to the root's homedir <KE0VVT>It worked a year ago! Why does it not work! This is crazy. <tissevert>I simply log in, and since it's the thing that looks the most like a desktop environment, it gets run ? I suppose ? <tissevert>something like a .desktop in …/share/xsessions IIRC ? <neutral>davidl: are you a youtuber. (system crafters) <jpoiret>tissevert: yes, that should be it. Is your PATH ok inside your session? <tissevert>sorry, I turned that machine down in between <tissevert>I'm testing on a very similar system in a qemu machine (that's persistent and not a read-only USB) and I can't reproduce <tissevert>so I guess it must be a matter for dmenu to be able to populate its list of known program beforehand ? <tissevert>I tried logging out and back of course but it didn't fix it <tissevert>hmmm wait, it doesn't work either in the VM now ? <jpoiret>No idea. Can you check your PATH inside the session? <tissevert>from a terminal, it looks good (setuid-programs, ~/.config/guix/current, ~/.guix-profile and /run/current-system/profile <tissevert>but I don't know how to check what dmenu sees <tissevert>.bash_profile sources .bashrc and none seem to touch the PATH <tissevert>guix shell --check doesn't complain so I guess it's at least sane <jpoiret>If you log in using a tty, is your path also ok? Usually bash profile shouldn't source bashrc, they have different use cases (i think that bashrc gets sourced as well as bash profile in login shells) <tissevert>yeah, they're not supposed to be for the same thing, I set that correctly on my work laptop but here this is the default I found after a fresh guix install <tissevert>anyway, after a reboot, my newly install programs (in user profile) are found so… ? I guess this is just how it's supposed to work, although I find it counter-intuitive <jpoiret>Maybe dmenu caches something? I use rofi and it picks them up instantly *tissevert doesn't know about rofi <davidl>KE0VVT: Im sorry it's frustrating. Guix is an awesome project, and this bug is a very unfortunate one as it hits new users and I hope it does not lead you away from the project overall. Now I imagine what's happened is something like: shell users are recommended to use quotes "when in doubt" as a "safe" way to use quotes, but in this particular instance with ~user it actually it is not the correct way. This probably led someone to include this <davidl>commit. Still though, the change should have been tested, flagged as a fault and fixed quickly - apparently did not happen. You are also free to submit a bug report or a patch yourself though. <nckx>I agree that the tone is not worth responding to. However, I'm to blame for the bug still being present in master: someone brought it up, I didn't feel like I had the time to fix it, so I simply pinged the author of the original bug (☺) here without following up. <nckx>One reason that I didn't fix it is that I agree that changes should be well-tested & I'm not set up to test guix-install.sh. <nckx>"guix-install.sh: Please the shellcheck linter." <nckx>Let's just take it as a lesson that linters are vastly overblown, because this aligns nicely with my personal biases & beliefs. <nckx>There, pushed, now someone can yell at me next. <nckx>By the way, this bug was only reported in the past week, so it can't be that old. <davidl>nckx: true, I reported it here only a few days ago - old is relative. I didn't send an email with a bug report either. <jpoiret>i think i'm going to write a mail for guix-devel about the changes i'd like to make to the init process (and maybe to operating-system as well). Does anyone know if there's been a recent discussion on that subject that i could read/reply to? <jgart>how can I get a guix container to remember my command history? <jgart>jpoiret, what are the changes you're proposing? <jpoiret>moving to a shepherd-based initrd, centered around services for more modularity <jpoiret>ie moving away from the hardcoded boot-system from build/linux-boot.scm <jpoiret>that'd make it easier to have a dual Linux/Hurd approach, as well as customizing for more complex boot setups (also one idea i had along these lines is to create a minimal linux EFISTUB bootloader with it, to bypass grub's limitations) <jgart>would be cool to eventually move away from nix daemon fork and implement that in guile also... <jgart>It'd be great to open discussion about that though for sure <drakonis>having a guile based daemon can open up some pretty good doors <jgart>Does any one understand how to build a nix daemon more or less? <jpoiret>r-xr-xr-x permissions are a big drawback of the store for now. There's potential for managing secrets if we end up supporting other permissions <drakonis>the source for what's left of the daemon is in the git repo <jgart>the general idea/concept so that it can be reimplemented in guile <jpoiret>biggest example: if you embed a LUKS keyfile in your initrd, that keyfile is going to be world-readable <drakonis>there's also a branch containing some rewritten components in guile <jgart>drakonis, I've looked at it before <jgart>but still don't understand it <jgart>maybe I should read edolstra's thesis again <drakonis>the easiest first step is to port the c++ code to guile and start testing it against the existing builds <jgart>or maybe we should rebuild it instead of porting? <drakonis>hmm, it'd be cool and good if it was done <jgart>do we really need a daemon? that's another approach possibility for the future also <drakonis>ie: guix deploy no longer has a dependency on ssh to function <drakonis>you can just talk to the guile daemon to get it done <drakonis>hermes does not have system management, right? <jgart>that is inspired by guix/nix <drakonis>but that's not particularly relevant to the problem at hand <drakonis>since that can be done without the daemon <jgart>system management can't be done without the daemon? <jgart>so why don't we implement something that is daemon-less? <jpoiret>you could build as yourself using namespaces, right? <drakonis>well, i don't think anyone has put enough time on doing that yet <jgart>let's exercise the nix daemon from guix <jgart>I think it would simplify maintenance <drakonis>basically, the reason to get rid of it would be to have something else more flexible take its place <jgart>or something more maintainable by the community <drakonis>use the rewritten daemon for multi-user build scheduling <jgart>but that can still manage what we need <drakonis>you'd be able to have single user guix with just the binary <drakonis>have the daemon run for multiple users not unlike how nix does these days <jgart>maintaining guile in 20 years time will be difficult enough <drakonis>there's a lot of room to build something <jgart>elephant in the room: does anyone understand how the guile vm works enough to maintain it after the current maintainer is not active anymore? <drakonis>but first, replace the nix daemon before that <jgart>we should try to understand that too <jpoiret>jgart: the documentation on that point is pretty good <jpoiret>wdym by multi-user build scheduling? if it's about resource management (CPU time), i think it's out of scope <drakonis>guile's docs arent at the same degree as racket's but its nice <jgart>I'd love to go through it then with y'all at some point and talk about it <drakonis>the nix daemon is used for build scheduling iirc <jgart>I'd cast my vote on finding a simpler solution than the daemon approach of nix in the future <jgart>maybe we can do some exploratory programming to that end <jpoiret>maybe we could also have some layering à la docker for build phases <jpoiret>i kinda hate re-unpacking source every single time i want to build qt or gtk <jgart>Is it possible to produce container images from guix containers? <jgart>maybe a better question is, are guix containers images looking to be OSI compatible to some degree? <singpolyma>jgart: IIRC both guix pack and guix system can produce docker images <jgart>singpolyma, I mean the container image format of a guix container <jgart>guix shell --container --network <jgart>for example, what would it mean for guix to upload container images to a registry? <jgart>by container in the above I mean guix containers <jgart>instead of guix produced docker containers <singpolyma>Well, the docker image format doesn't need to be docker specific. Lots of tools can use that same format, even for things that aren't containers (like firecracker VMs) <jgart>singpolyma, Do you happen to know if there is a spec for the docker image format? <jgart>I haven't looked into firecracker VMs yet <singpolyma>Hmm, I do not know how well documented it is off hand. At least docker, firecracker, and podman have all implemented it so it can't be that bad? <jgart>> Firecracker has a minimalist design. <cbaines>from memory, Guix produces v1 Docker images <jgart>cbaines, thanks. that's good to know <jpoiret>hmmmm, now that we're talking about the daemon, it's still the one thing supposed to be able to mount the store rw <jpoiret>since you need immutability at some point <drakonis>what if you're in a system with multiple users and they all want to build something? <singpolyma>jpoiret: the main issue isn't immutability but atomicity of writes to the store, no? <jgart>this might be a silly question but how is cuirass different from laminar besides guile implementation and emphasis on building guix packaged software <jgart>maybe the better question is, why couldn't laminar do cuirass' job? <jgart>besides that conceptually we want to build the whole world in guile <cbaines>jgart, in my opinion, even though Cuirass is labeled as a "CI" tool, it has little to do with continuous integration <cbaines>while Laminar is a pretty typical tool to assist with CI <jgart>cbaines, how would you describe cuirass then? <jgart>mekeor[m], Railfreight Interchange Investment Group <jgart>to be acurate TIL of RIIG. I still don't know what it means. <cbaines>jgart, my perception is that it's a partial re-implementation of Hydra (from Nix). It builds derivations to provide substitutes and to determine if they build or not. <singpolyma>mekeor[m]: sorry, bad joke. People use RIIR for the Rewrite It In Rust meme. So... In Guile <mekeor[m]>did you just propose to rewrite guix in rust? =) <jgart>cbaines, oh yes. I remember reading something along those lines somewhere... <jgart>I just want guile/guix to kick ass at packaging all the other languages I want to use to build that next app/tool <singpolyma>What I *actually* want is to achieve the promise of polyglot guile and then people can extend guix in other guile languages like js or Python <jgart>maybe that's the conservative approach and I should really be striving to RIIG <jgart>we need a guile->nix compiler/interpreter <singpolyma>Right? Nix lang for guile with guix binding. Poof <jgart>I want to write nix expressions in guile/guix APIs <jgart>there's something like it already for purescript <jgart>I want to transpile guile code to nix <jgart>I also want to transpile guile code to vanilla javascript <singpolyma>Right. I want the opposite: more languages that guile has ingests for in the compiler tower, and bindings so they can all call guix APIs <jgart>singpolyma, that would be cool too <singpolyma>The C ABI is too low level to still be the universal library glue. The guix compiler tower could be another way <jgart>access guix APIs from bbc basic <jgart>mekeor[m], that would be great <jgart>I just upgraded the python language server <jgart>the version in guix is unmaintained <jgart>I'll send a patch later today <mekeor[m]>singpolyma: before 2021-edition, there have been 2018 and 2015 editions. so it's 3y-cyclus, i guess? <jgart>does anyone want to work on updating the python-build-system to 2021? <mekeor[m]>jgart: but isn't it easy to upgrade rust as there's a `rust-bootstrapped-package' function defined in gnu/packages/rust.scm? <jgart>not sure, I haven't tried upgrading rust before <lilyp>Isn't there already an update pending in the ML? <jgart>I've worked on other rust packages only <lilyp>tell me you're about to go insane without telling me you're about to go insane :) <jgart>building takes long but compiled software runs fast. I guess they couldn' have their fancy rusty cake and eat it too <jgart>I'd like to have rust as up to date as needed for building helix editor <jgart>mekeor[m], I might start helping soon with that <jgart>let me know how we can divide our efforts <mekeor[m]>jgart: i gave up on packaging rust@1.56.1 because my machine is too slow and i'm not patient enough at the moment. i simply created this file in my channel http://ix.io/3EkZ and got the already-mentioned error <the_tubular>Yeah, there's a few pacakge that I've tried, mostly written in go, that I'd like to see for guix :/ <ngz>The Go importer made a lot of progress lately. But there are still some hiccups. <tissevert>how do GTK theme get added to a system ? is there a variable like PATH to tell GTK apps where to look for ? <singpolyma>For big things like rust maybe we need some way to share dev access to some heavier metal. <tissevert>should they be installed system-wide and not in user profiles ? <lilyp>GTK themes are usually user profile things <GNUHacker>I search gzip path (example /bin/gzip ) where is in guix? <lilyp>They're picked up by XDG_DATA_DIRS <nckx>GNUHacker: It's in $PATH. <singpolyma>GNUHacker: in guix things don't have a fixed path, so if you're not packaging you always need to do a lookup <singpolyma>If you're on guix system and you need a fixed path for something globally I think the word to look for in manual is "special file" <singpolyma>Otherwise install into a profile and that will also create a fixed path <shtumf[m]>Hello Guix ! ext4 or btrfs for guix system ? How do I choose ? <the_tubular>I'M not sure guix has anything do to with your choice <singpolyma>shtumf[m]: word on the street is btrfs or xfs for Guix, ext4 you may run into limits <the_tubular>If you are feeling courageous, you could try bcachefs I suppose <singpolyma>I don't run guix system (I run on foreign), I just read things people say in here a lot. <lilyp>I don't think you're that limited on ext4, but you do have to ignore some misleading warning about large_dirs <lilyp>That said, I think most btrfs users are happy with their setups. <tissevert>hmmmm… XDG_DATA_DIRS looks fine and contains the theme I installed… why won't it show up in lxappearance ? 🤔 <the_tubular>Yeah, I've got burned once with btrfs, I've got no interest with it since <nckx>the_tubular: As the one and likely only Guix/bcachefs user (would love to learn otherwise) I won't recommend that *just* yet ☺ <jgart>singpolyma, what foreign distro are you on? <lilyp>tissevert: is it compatible with LXDE? <nckx>shtumf[m]: One data point: Guix/Guix System itself doesn't use any special btrfs features. It's not like you get better/more rollbacks with btrfs. So your decision rests solely on what you yourself want to do with your file system. <jgart>I was considering switch to latest stable devuan <lilyp>There's some themes that only work for GTK3 ***Inline_ is now known as Inline
<tissevert>oohhhh I think it is, I've been using it for years on two other distros and LXDE <tissevert>except, that was the package from that distro and not from guix <singpolyma>jgart: yeah, devuan is probably the way to go. I basically never interact with my init system so I haven't had a huge reason to leave Debian yet, but I think about it <tissevert>(also, why do the paths in my XDG_DATA_DIRS appear twice ?! ^^) <jgart>singpolyma, runit lowers the barrier to interacting with your init <lilyp>sometimes they get expanded multiple times <jgart>fun to hack with init scripts now <singpolyma>jgart: I just never have reason to interact with my init beyond incanting /etc/init.d/blah restart <lilyp>particularly if you run gnome-terminal, there's a few that are tacked on several times <nckx>the_tubular: I have, but only a few thousand to test the feature. I don't actually have a real use case for it (my back-ups are an hourly rsync to a server that uses snapshots already — btrfs ones :). <tissevert>hmmm, gtk-2.0, gtk-3.0, index.theme, everything looks familiar, I don't see why it shouldn't work <lilyp>that's an icon theme then, no? <the_tubular>Yeah, I use ZFS on my datapool and support for guix is ... limited <lilyp>no, wait, I'm missing something <singpolyma>nckx: IME doing an hourly rsync from a non-snapshot results in corrupted data in the backup <tissevert>(the icon theme is found, by the way, hmmm curious) <lilyp>yeah I'm p sure lxde looks for neither of the directories you have <tissevert>so it would be LXDE specific ? possibly, I haven't tested yet with another theme manager <the_tubular>Any idea on a time frame until it's considered stable nckx ? <nckx>Kent just sent out a few mails this week about that, let me find them. <nckx>Stability I mean. Performance is excellent. <nckx>singpolyma: Not knocking your experience but it's fine, WFM, etc. You're right in certain situations I really don't care about. <GNUHacker>can I do a symbolic link from bash path to /bin/ ? <lilyp>okay, I think you might be needing the gtk2 theme, plus it could be that there's a need for an engine <nckx>But yes, I will use snapshots as soon as I consider the feature stable enough to not be an unnecessary stress-test. <lilyp>(gtk2 themes typically require those) <lilyp>So, this might be a cursed question, but can one simply upgrade ext4 into btrfs? <nckx>(bcachefs will also support something like that; it's a relatively cheap yet cool party trick especially for CoW fs'es.) <nckx>Kent is a bit of an optimist about that IMO but that's good. I'm sure it will make it in eventually. <tissevert>maybe the engine, yeah… ^^ I'll get it right someday ^^ <nckx>All this has prompted me to upgrade our xfstests package ☺ Thanks for the reminder. <drakonis>so, i'm fiddling with getting btrfs subvolumes to work correctly <florhizome[m]><lilyp> "So, this might be a cursed..." <- Well, I managed it. It should. ^^ <tissevert>well, I still haven't figured it out but I spent enough time on it for today so : ) <drakonis>i'll play around with subvols some other time <florhizome[m]>I tried to mount a distinct partition (home) as a sub volume but I think that’s the wrong approach <drakonis>rather, there's two options, move my boot partition to another location or reinstall grub <florhizome[m]>you probably need to reconfigure your etc/fstab, too, if not on guix, and on guix change file system declaration I guess <drakonis>the problem is that grub wasnt finding what it needed to boot <drakonis>ah well, i can always just have a boot entry for the other distributions, right? <drakonis>i'll figure out how to get around that later