IRC channel logs
2025-12-01.log
back to list of logs
<apteryx>ACTION wonders why `make check-system TESTS=basic` still downloads the legacy isc-dhcp <csantosb>Good morning Guix ! Regarding `nextpnr` package, ci is building it or not ? <csantosb>Then, `guix weather nextpnr` seems rainy, and `guix install nextpnr` tries to build locally <untrusem>if I deleted my git repo from my filesystem, how can I push to a pr made using agit workflow? <csantosb>Create a new branch at pulls/pr/ID, and give it the name of the topic, then proceed as usual <sneek>civodul, you have 2 messages! <sneek>civodul, csantosb says: I just pushed emacs-xelb 0.22, in case you're still randomly crashing, hope that helps <civodul>apteryx: go-team was still pulling from Savannah, hence the Savannah link <kestrelwx>apteryx: I got 504, and now get 502 and 404 for `pkgblurbs.rec` with the gnu importer, is this all transient or 404 will stay later still? <kestrelwx>Maybe the 404 is for a different request, since I get to see it in browser. <janneke>ACTION has applied the first example from the manual... <janneke>...but although /var/log/secure is bombarded with login failures, fail2ban-client status sshd gives only 0s <janneke>interestingly, the fail2ban system tests only check on 0 failed attempts...well, i see that too :) <gabber>janneke: yes, but not very successfully <janneke>gabber: have you tried the second example from the manual, where it wraps the openssh-service-type? <gabber>i digged a bit into it but then just switched the ssh port number. since i exclusively allow pubkey auth i think i'm fine <gabber>janneke: let me consult the manual <gabber>i actually use the second example <janneke>yeah, i was thinking about doing that too, but we have some customers who use it and it gets just a bit awkward <gabber>after having tried the first one <janneke>right, have you ever seen any actual IP bans? <gabber>janneke: would you mind opening an issue? <janneke>gabber: sure, that's a good suggestion <PotentialUser85>I'm trying to build something in a guix shell which needs libraries in LD_LIBRARY_PATH. How can I define this in a guix shell? is there some easy way to do this that I haven't discovered? <ekaitz>PotentialUser85: if you use the shell with gcc-toolchain the LD_LIBRARY_PATH will be used properly <gabber>do we need a sysadmin or network-services team? <gabber>PotentialUser85: or are you talking about locally built libraries? <PotentialUser85>gabber: nope - it couldn't find something like libxkbcommon. now it can't find my gpu, but that's at least a different error. I'm not quite sure if it still is a LD_LIBRARY_PATH issue, and iterating on it is slow because of rust :/ <PotentialUser85>(which is why I'm guessing that it needs to be set manually). After adding gcc-toolchain, the LD_LIBRARY_PATH variable was still empty in the shell if that helps. <Rutherther>First of all using LD_LIBRARY_PATH for compilation is just wrong LIBRARY_PATH should be used and is what you will get provided with both gcc toolchain and the libraries. If the sw you are compiling really does use ld lib path, better to report it as an issue. Second, setting it globally in the shell can lead to various issues. Still if you really want to set it and use Guix for that, you would have to make a dummy package that outputs it as... <Rutherther>If you put such package to your shell along with the library, you will get the env var set. Having both in same shell is important, same for gcc toolchain & the lib to get LIBRARY_PATH <PotentialUser85>Rutherther: then I'm guessing it can't detect my gpu because of something else. Thanks for the explanation! <gabber>PotentialUser85: WDYM "detecting my GPU?" <PotentialUser85>bevy panics: "Unable to find a GPU! Make sure you have installed required drivers!". I'm guessing it's missing some package/dependency in the shell <gabber>PotentialUser85: is this GPU otherwise already in use by your system? <gabber>i am unable to reconfigure my system due to git-minimal failing to build https://codeberg.org/guix/guix/issues/4597 . but somehow i'm unable to bisect the exact change that broke git-minimal. i change to a pull checkout, try to reconfigure, this fails, i declare this guix commit as a BAD starting point for `git bisect` but somehow this is wrong. is it possible my `./pre-inst-env guix build git-minimal` does not yield the same build <gabber>results as my `guix system reconfigure`? <wizard>hihi guix, i'm trying to get ublock-origin installed, but it doesn't seem like just adding ublock-origin-icecat to my home config works. any ideas? <civodul>wizard: i think it should work that way <civodul>in “guix package -I ~/.guix-home/profile -A icecat”, i have a bunch of extensions like this one <wizard>hm... the packages are all there, but they aren't displaying in icecat regardless <ieure>wizard, I agree with civodul, having the browser extensions in your profile should Just Work. <wizard>I'm gonn try and restart my computer soon after a system reconfigure and see if that does anything <Rutherther>wizard do you have the browser in the same profile and did you relog in case you just installed first extensjon? <Rutherther>Then you cannot have the necessary environment variable for extensions <Rutherther>See if you do have it in ~/.guix-profile/etc/profile, its something like ICECAT_EXTENSIONS_DIR. assuming you are using guix install <wizard>everything's working after a relog, ty <icy-thou`>I know this might sound cursed, but how many here uses Nix in Guix for the missing packages? <t420`>Another one is when I open Wofi launcher, when I pull and reconfigure I get multiple versions of the same package eg. for the game 0ad i have 3 entries and so on <nckx>There is no separate source for the system. <nckx>(Most of the) package manager is in guix/, the packages in gnu/packages, (most of the) system stuff is in gnu/system. <nckx>‘Guix System’ is just a system built entirely with Guix, not a separate codebase. <nckx>basicnpc: As in, you can't delete guix/ without breaking gnu/system, or the other way around. It's one codebase. <basicnpc>?! Do you mean gnu/system contains the source code of shepherd and the OS? <nckx>The (code that builds) the OS. <nckx>The Shepherd is just an init system that Guix System uses. It is one of many GNU packages. <basicnpc>I didn't know one can write an OS with so few codes. <nckx>Apt doesn't bundle a copy of firefox. Pacman doesn't include the source code to systemd. Guix System is no different. <nckx>Guix downloads many different packages, builds them, and creates a bootable OS out of them. <basicnpc>I thought the OS part is complicated, in that it has to define processes, uid, pid, init.. etc. <basicnpc>Right, the OS just have to produce an interface to those entities? <ieure>The kernel has the interfaces to use kernel features. <ieure>basicnpc, Are you from the USA? <ieure>Ah, I was going to ask because it's probably necessary context for the metaphor I was going to use. <basicnpc>Where in the codebase can I read about how Guix interfaces with the kernel? (And it assumes linux kernels, right?) <nckx>And packages like GNU coreutils provide commands like chmod, echo, and our new favourite, du. That's another possible definition of ‘OS’. But it's also not one that Guix reimplements from scratch. Guix is a distribution of GNU, which is most of an OS. The Linux kernel is most of the rest. <ieure>basicnpc, In the USA, we have a fast food chain called Taco Bell. There's a sort-of-joke about how everything on the menu is made with the same five or six ingredients. Linux distributions are the same: the ingredients (kernel, shell, DE, browser) are all the same, the way they get combined produces the different distributions. <basicnpc>Haha I've been living in the States for 7 years. Never had taco-bell :-D <ieure>I don't recommend eating there, but it's useful for this metaphor. <basicnpc>Yeah, I'm just surprised that the 'nonexternal' part of an OS is so small. <nckx>basicnpc: One answer to that would be guix/build/syscalls.scm. That's the lowest level interface in Guix. But that doesn't mean that Guix reimplements everything above that itself, in Scheme. It hands tasks the existing GNU tools written in C. Or other packages like e2fsck. You get the idea. <basicnpc>Yes, it hands tasks over to 'external' tools. That's fine. <ieure>basicnpc, Modern software is incredibly bloated. I remember when a whole OS came on a handful of floppy disks. <nckx>ACTION inserted the boot floppy, then the root floppy, and was enlightened. <basicnpc>How do they separate gnu and guix in the codebase? <nckx>ACTION idly trying to find any documentation on that, rather than explaining it poorly on IRC. <meatoid>iirc it might be in the "tour of the codebase" chapter of the cookbook <nckx>Oh look, Info: (guix)Source Tree Structure exists. <nckx>I didn't check the cookbook, that might also be good, as it aims to be more of a tutorial for newer users. <basicnpc>Weird, that page doesn't show up with `info -f doc/guix.info "Contributing"`. <basicnpc>The codebase I downloaded may be outdated. <ieure>Guix should come with a copy of the version of the manual corresponding to your install. <nckx>The manual isn't all in one single file. <nckx>This part is in contributing.texi. <basicnpc>I got it from the official website (1.4.0). <meatoid>guix/build, guix/build-system, gnu/build... <nckx>basicnpc: The release is very old, sorry. <basicnpc>Ah ha, that's the problem. Thanks for pointing that out! <nckx>Either use the HTML /devel/ manual I posted above, or build from Git. I'm all for self-sufficiency but in this case I strongly recommend the HTML one 😛 <basicnpc>I remember seeing how pleasant the coloring for the lisp codes was. <basicnpc>Is guile scheme robust enough to write a mighty kernel? <nckx>It's reasonably mature and not… particularly buggy, if that's what robust means. Guile is ‘just’ a Scheme implementation. You could write anything, including kernels, in Scheme. However, Guile was designed to integrate well with C programmes as a high-level extension language, so that's what it's optimised for, not writing mighty kernels. <nckx>Then again, you might have noticed that GNU Guix isn't extending a C programme either. It's a general-purpose language. <ieure>basicnpc, Not sure Guile is a great tool to write a kernel, but who knows. Doesn't seem to be a lot of people clamoring for a new kernel, plenty of FOSS options out there already. <nckx>It's somewhere on the Brainfuck→C spectrum. <basicnpc>It would be really cool to hop into a repl that controls the kernel! <meatoid>You could probbably write hurd modules in scheme... <nckx>I don't think writing a unixy kernel in any Lisp plays to the strengths of either. <ieure>basicnpc, The Lisp Machines of the 80s and early 90s had that. Not sure anything else has managed it. <ieure>I would very much like a machine that ran Lisp down to the core, but I also think a new dialect should be invented for that usecase. <ieure>Yeah, I wouldn't aim for "unixy" at all. <meatoid>what about the unix way of doing things disagrees with lisp? <nckx>Yeah, that's what you'd want ☝ Not just ‘here are your favourite unix C syscalls and process model from the seventies but we promise that they were brought to you by Lisp™’. <meatoid>or rather, what way of doing things would leverage lisp most strongly <nckx>That's a valid question for which I don't have a readymade answer thought out. <ieure>meatoid, Many things. Some stuff just has better approaches: Unix permissions are overly simplistic and shouldn't be replicated in *any* modern system. Sharing data structures directly with shared memory is much more efficient than forcing every program to output and parse text. And if you lose that, most benefits of "everything is a file" start to evaporate, so may as well find some new abstractions. <nckx>I'm not saying it wouldn't work fine. But making your rich lispy kernel talk to your rich lispy userspace (or however your OS divides things) through a unix-shaped gloryhole that whispers in errno's (errno's!!!) and other… stuff is just… masochism. IMO. <basicnpc>It seems that all lisps must have automatic GC, but that would be a problem for kernels. We cannot have the whole kernel paused for GC every now and then. <ieure>Also "everything is a file" is a pretty leaky abstraction anyway, you have to screw around with ioctls in many cases. <basicnpc>By exposing memory control to the user makes a lisp inherently non-lispy.. <ieure>basicnpc, I'm not sure what modern Lisps are like, but the early Lisps were GC-less. I don't think GC is an inherent feature of Lisps. <basicnpc>By 'lisp' I mean lispy syntax + high interactivity. <ieure>basicnpc, I'm not sure your mental model of how memory management works is accurate. On current systems, the kernel manages whole-system memory, but doesn't care what programs do with it. GC is userspace, within the memory the kernel has allocated to the process. <basicnpc>lispy syntax is no problem, but to make it interactive, it seems we need to ditch manual GC. <meatoid>what would one do with this "interactive" kernel? Linux (the kernel) seems to be as interactive as it needs to be <basicnpc>I don't know. But the idea of hopping into a repl that controls the kernel feels /nice/. <ieure>All fun and games until you deadlock the input driver which lets you do anything in it. <basicnpc>Linux is interactive by exposing certain APIs. But that's still different from being able to redefining the functions and objects on the fly. <basicnpc>ieure In that case, just reboot and start again :-D <meatoid>ieure: the nice thing about "everything is text" is that text is practically the most universal way to structure data. if things were done by shared memory, the barrier to inter-operability for tools goes up <nckx>I'm veering into vibes territory but I don't think ‘having GC’ means ‘the kernel pauses every now and then to have a little nap’. Lisp machines *did* exist. They did not have a C kernel. Most of the ‘kernel’ was GC'd. AFAIK. <ieure>Yes, there are a variety of incorrect notions in this discussion, and "GC must pause" is one of the smaller ones. <meatoid>nckx: I would imagine hurd mitigates this by virtue of not being a monolith... each module can gc on its own time <nckx>Also, ‘all OSes have a thing called a kernel and it looks like unix’. <basicnpc>nckx Did the lisp machines pause every now and then? <nckx>Not problematically (by several definitions, my Linux machine ‘pauses every now and then’) in the sense implied (to me) by ‘We cannot have the whole kernel paused for GC every now and then’ above. <nckx>I've only ever played with emulations but I can't imagine that this was some insurmountable issue. And yes, these machines had GC. <identity>basicnpc: lisp machines had a toggle that let you turn off garbage collection for pointer juggling, not sure if that makes them inherently non-lispy <identity>«Did the lisp machines pause every now and then?» no, they would unpause every now and then instead :3 <meatoid>is powershell good? That's a system that doesn't use (linear) text as its base IPC medium... <basicnpc>It's still lispy but the user needs to clean up the garbage every now and then manually if the interactivity is maintained. <identity>basicnpc: as in, they were mostly garbage collecting/running non-interactively most of the time <FuncProgLinux>meatoid: I never got my head around powershell. It looks like an object-oriented shell to me :s <identity>FuncProgLinux: kind of because it is, fsvo object-oriented <identity>i guess strongly-typed and data-oriented are better descriptors for that <nckx>identity: Have you ever used a physical one? <FuncProgLinux>identity: You could argue bash is strongly typed if everything is typed to "string" xD <identity>nckx: no, but i heard a lot of tales and read some of the chinual <FuncProgLinux>identity: nvm, I just searched "OOP Powershell" and I got a tutorial creating CLASSES on a posh script ._. <identity>well, powershell is also tied to C# a bit. i am mostly thinking of Nushell <basicnpc>One thing I was sad about archlinux is that when debugging scheduled tasks, I need to go into the log, and it's not easy to read. <meatoid>nckx: are there any surviving physical, usable lisp machines out there? <basicnpc>I cannot change the behavior of systemd/journalctl either. <basicnpc>Would using shepherd make this issue go away? <identity>meatoid: yes, but they are mostly a museum/collector's kind of thing <basicnpc>I can hop into a repl to shepherd, and inspect what it is doing? <ieure>basicnpc, I'm not sure if it has such a facility, but it should be possible. <identity>basicnpc: yes, you can, but be careful, with great power comes great chance of crashing PID 1 <meatoid>supposedly there is a way to write and manipulate shepherd services on the fly, but the manual is dense <ieure>I guess it doesn't *really* matter, but I wish the shepherd package had a doc output. I often want to read its manual, but don't really need it in my profile. <meatoid>Someone should write a cookbook chapher on writing and testing guix services... I have ideas but I am so turned off by the concept of testing by configure/reconfiguring a whole guix system to test if it works right each time <identity>basicnpc: «But the idea of hopping into a repl that controls the kernel feels /nice/.» Haiku has some of that with its Kernel Debugging Land <identity>meatoid: you can use containers/vms for that instead of a reconfigure <FuncProgLinux>meatoid: I think the best way is to generate a VM image and load it into the virt-manager on Guix and just test there. <ieure>meatoid, It's usually fine, lol. Some are testable without doing that, but other times you have to, ex. if you're writing something that interacts with hardware which is difficult/impossible to access inside a VM. <meatoid>word, i'll do that. I wanna write some services for deploying web apps, I'm suprised there aren't more services for that <nckx>meatoid: I wouldn't know where to find a working one. I'd love to. You'll find mention of working ones in collections/museums on the Web but who knows how old those pages were when I read them. <ieure>I forget what the command is, `guix system vm'? There's one that takes an operating-system and prints a command to run it. <FuncProgLinux>meatoid: I think the preffered approach for now to the web-apps thing is to load an oci-container-service / home-oci-container-service AFAIK <meatoid>FuncProgLinux: but at that point why not just use debian and docker or w/e <FuncProgLinux>I don't remember if it was the Guix official site or another component but I remember seeing that one of those was a docker image generated with guix and then loaded as an OCI service <FuncProgLinux>meatoid: You could argue that's a way to semi-replace compose for scheme instead. It would also make easier to manage headless installations like CI/CD services on LAN :P <basicnpc>Suppose I use guix system, but I want a package to work, but I cannot package it and no one can help. How difficult is it to make it into a flakpack and run it from there? <meatoid>basicnpc: flatpaks work the same on guix as they do elsewhere, it shouldn't be any more difficult than making/running any other flatpak <identity>basicnpc: turn it onto a flatpak? no idea. run it as a flatpak? trivial <basicnpc>I was packing maestral 2~3 years ago and burnt out badly :-D <basicnpc>But that's just one example. To start usng guix system I need to make sure that I have a trivial way to back up to. <FuncProgLinux>I think you can use pyproject-build-system now for that, seeing that it's Python and such <ieure>basicnpc, Strongly recommend getting a secondary machine or dual-booting Guix until you have things worked out. <basicnpc>FuncProgLinux: I packaged it but still needed to package its dependencies.. and the work just seemed not to end. <ieure>basicnpc, I ran Guix on a secondary machine for 12-18 months before I had things in good enough shape to move my daily driver over. This included packaging a whole web browser and becoming a committer. :) <identity>basicnpc: i would imagine you can just ‹guix import --recursive› it <basicnpc>ieure: Well, I won't use guix system if I know I need to hop back to something else. <ieure>Still whittling away at some QoL things I want. Landed a proper autofs-service-type recently, close on some X11 stuff, maybe 50% done with a collectd-service-type. <basicnpc>identity: Some dependencies are not presented in the channels, so I had to write their pkg defns as well. <ieure>Secrets is still a missing piece. <FuncProgLinux>basicnpc: Been there with Go, with the vegeta tool. Reading the source for the program you need there's not much dependencies but I don't know python one bit :/ so idk if one of those uses rust or something similar <basicnpc>ieure: Good for you. After a few success, do you feel confident that you can package anything you need in the future without much mental load? <identity>basicnpc: which --recursive does for you <basicnpc>identity I forgot if I have done that.. it's been 2~3 years. Maybe I will try again. <ieure>basicnpc, Basically no. The actual packaging experience in Guix is superior to other Linuxen I've used (I'm a former Debian developer), but between bootstrapping and the huge dependencies many modern programs have, it can be dicey. <meatoid>it's blocked by my work network but also remember to check toys.whereis.social to see if it's packaged in a third party channel <ieure>basicnpc, Most common issue I've run into is Free Software which has a non-Free toolchain it builds with. <ieure>nckx, *Most* common, that *I've* run into. As with nearly everything about how I use computers, I wouldn't recommend extrapolating any large-scale trends. <nckx>ieure: Was just disappointed disbelief, not scepticism. <ieure>The alternate version of that is "toolchains which are difficult to bootstrap" <FuncProgLinux>I don't like a node_modules folder with lisp-knows-what software might be creeping on my system <ieure>You had me at "I don't like node" <basicnpc>Whoops. Snowing hard out there. Needa get back home before I'm stuck. <nckx>I know of one (1) major package that is blocked for that particular reason (VBox) and assumed that it was a weird edge case. As opposed to ‘nominally free ouroboros hellgraph’ etc. <meatoid>Does node allow "true" circular dependencies (i.e. not just reliance on older versions), or is it just the volume of packages that keeps it from being integrated? <basicnpc>Thanks folks for sharing! I will see you guys again 2 years later. <nckx>But I repeat, npm was already mentioned. <ieure>basicnpc, Will also say, rarely is the problem "I can't do X" or "I can't figure out how to do X." It's mostly "doing X would take time I'd rather use for something else." <ieure>Guix is very, very good at letting me "do X." It manages to be highly hack*able*, without feeling hack*y*. That's something pretty special IMO. <FuncProgLinux>meatoid: I don't get the circular dependencies thing, AFAIK for node the only "source of truth" is the node_modules directory where it always re-downloads the entire sources from the npm registry <basicnpc>ieure That's why I asked whether you feel you have finally 'get passed' the initial steep learning curve. <meatoid>I feel I am past it for everyday use <ieure>basicnpc, It gets easier. There are still parts of the code I haven't messed with, but for the stuff I care about, I feel proficient. <basicnpc>ieure Which part is it very very good, that you can't get from other distro? <FuncProgLinux>basicnpc: I'm relatively new to guix, but it took me like 2 months to learn how to package my own stuff. You could say it's as steep as Emacs lol <meatoid>Reliability. A system/program will always work the same way if you intend it to, *and* you can go back if you change something and it doesn't anymore <meatoid>Also, learning scheme is a transferrable skill, as opposed to the nix dsl <ieure>basicnpc, It's easier and more regular (ex. you have fewer tools with clearer usecases) to make packages. And also easy to run your own channel and have it treated as equal with the official one. <basicnpc>I guess I'm still not there because I haven't really seen the need. <ieure>basicnpc, Running your own Debian repository that works as well as the official one is quite difficult. There are basically "just make it work" type packages, like dpkg-scanpackages, which get you basic functionality, but lack things like package signing, arch handling, etc. <ieure>You can do more with a Guix channel, and more easily. <basicnpc>meatoid: A package that has been packaged will always work? <basicnpc>I remember having a counterexample.. but I cannot recall. lemme think.. <meatoid>basicnpc: As long as its inputs stay the same <meatoid>so when you upgrade, things might break, but it is trivial to go back to pre-upgrade times <ieure>basicnpc, I don't think "it will always work," but if the build is reproduceable, you can always rebuild (and hopefully run) it. Though you may need to use `guix time-machine' to do so. <basicnpc>What if two versions of the same package is writing to /tmp/output.txt? <FuncProgLinux>meatoid: The sad thing is idk about widely-used scheme implementations :( the most "complete" thing I've found was Racket, but for lisp-things I've read a lot that Common Lisp is the way to go (not sure how true is that, though) <FuncProgLinux>basicnpc: I think that conflict is not on the guix side AFAIK <meatoid>yeah, most software isn't designed to have multiple different versions of itself running at once <basicnpc>But guix aims to provide the user such thing right? If you have A B that depends on LOL1 and LOL2, then that should not be a problem. <FuncProgLinux>if it writes to /tmp at build/install time I think it would end up writing to /gnu/store/<hash>-program/tmp/output.txt <meatoid>basicnpc: yes, that is so, but guix doesn't make that promise for runtime state <meatoid>basicnpc: however you can containerize processes in their own virtual filesystem with guix shell <FuncProgLinux>basicnpc: Then the program is not designed to have two instances of itself running, whether it's an earlier or latter version <basicnpc>meatoid: Ok, in that case one would just have to not use that code, or write a scheme function that alters the code in the package. <FuncProgLinux>basicnpc: You could do that as well. (substitute* ) is your friend lol <basicnpc>How about this: the official channel is not going to save LOL1 LOL2 LOL3 for me.. <basicnpc>so I need to keep a copy of those definitions (and also their dependencies.. etc). <FuncProgLinux>basicnpc: You can point your checkout to the revisions where each one existed. Or if you need a modern revision but old packages I think there's a channel called guix-past for that <ieure>basicnpc, `guix time-machine' and inferiors let you pull package definitions from older Guix commits and build/run them. <nckx>They aren't free performance-wise, but they are time-machines for your dependencies, so they offer quite a bit of power in return. <Rutherther>the results are cached though, so as long as you pin the commits it's faster on subsequent runs <basicnpc>ACTION is on macOS and has been hating himself for a while. <ieure>Work only issues MacBooks to their engineers, I hate this thing. <Rutherther>should still be able to run guix system in a VM I believe :) <ieure>Rutherther, I've tried it, but it doesn't work very well for my usecase. <basicnpc>Rutherther: I could, and I did. But it's not going to be my daily machine. <Rutherther>ieure: please do share more insights. I am currently in the process of trying to prepare aarch64 iso and qcow2 so we can make them release artifacts <Rutherther>unless you mean that you do not like VM performance etc. <ieure>This hardware is <1 year old, cost $3300, and is a worse experience than Guix running on a $150 ThinkPad. It drains the battery dead flat overnight if I leave it asleep and unplugged. It'd have been returned if it was my money spent on it. <basicnpc>It drains the battery? Mine has very good battery power. <Rutherther>hm, I guess it ideally should hibernate after some time sleeping, but I don't really have experience with how Linux handles that <ieure>basicnpc, Yes, MBP with M4 Max. <basicnpc>Mine is macbook air 2022, still working fine. <basicnpc>I switched from archlinux to this back then, as zoom was a thing, and i embarrassed myself by using that old thinkpad. <basicnpc>Zoom was badly supported on linux, and that damaged my image in some professional online meetings. <Rutherther>ieure: and do you mean that with Mac OS the battery is drained overnight or with other OS? <FuncProgLinux>Thinkpads are nice :) I've got an X1 carbon 5th Gen from 2017 and it runs Guix quite smoothly <ieure>Rutherther, It runs macOS. It's unbelievably buggy. <ieure>Rutherther, I also got the early-2000s-Linux-with-broken-sleep experience of putting it into my bag and pulling it out to find it didn't sleep at all and was scorching hot. <basicnpc>ieure intereting. I wouldn't expect that either. <ieure>Yeah, me either. I don't know if it's OEM hardware, OEM software, the corporate spyware MDM junk, or all of the above. But it's a miserable, buggy experience, and a good amount of it is definitely Apple's fault. <ieure>ex. if I have a program fullscreen on the internal panel, then connect an external monitor, the program shows up full-screen, but cropped to the size of the laptop panel, in the upper-left corner of the big display. This has been a macOS bug for over two years. <basicnpc>happy christmas and happy new year and happy christmas and happy new year <ieure>Rutherther, Accessing files on the host FS from inside a VM on macOS is dirt slow, so I either have to consume a ton of space inside the VM disk and have all my work stuff trapped in there, or leave them on the host and have terrible performance. <ieure>Rutherther, The other issue with VMs is the only Free Software one for macOS is pretty terrible, and does things like crash the whole VM when the machine sleeps. And I haven't yet found one which lets me cleanly set up a Hyper modifier for Emacs in the VM, because neither macOS nor the USB HID have any notion of such a thing. <ieure>Tried Linux in a VM on a Mac a few times, have never gotten satisfactory results. But see also: I wouldn't recommend extrapolating anything (about how I use computers) to large-scale trends. <ieure>It doesn't work well for me, I'm sure it could work well for someone. <Rutherther>Yes, I get it. I just wanted to see if there are any points that were hard on getting Guix System to work in an aarch64 VM <ieure>No, it's pretty easy to get going. Substitute availability was the main thing, but these SoCs have so much raw performance that it hardly matters. Took something like 15m to compile the kernel. <ieure>Rutherther, I think I have a VM operating-system kicking around, if that'd be helpful. <ieure>I installed Debian into a VM, then Guix into that, then used it to make a system-image to boot the Guix VM. <meatoid>My first guix install was on my hand-me-down 2015 intel macbook... it worked pretty good <ieure>I have a pretty old MacBook Air I want to get Guix running on, purely for fun. <ieure>Installer runs fine, but I haven't gotten a bootable system after. <meatoid>I should dig it out and use it for some fleet-management experiments <Rutherther>ieure: btw I remember you were talking about arm64 thinkpad, have you gotten it after all and tried guix system on that one? <Rutherther>ieure: if you could send the operating system, that could potentially help me, yes <Ox1de>Hi, I'm trying to install a python package using pyproject.toml. I'm looking for an example doing this. Can you recommend me something? <Rutherther>Ox1de: if you mean that you want to package it through Guix, then there are plenty of examples in the guix source code, just search for build-system pyproject-build-system <ieure>Rutherther, I haven't gotten Guix running on the ARM T14s, except as on top of Ubuntu. Some folks have gotten Nix working, so I assume Guix should also work. I still want this, but the hardware support is still pretty poor, so it hasn't been a priority. <ieure>Rutherther, Audio, webcam, USB-C, and sleep are currently all unsupported. At minimum, I need working sleep for it to be a viable daily driver. <ieure>Yeah, I'm surprised it's taken so long to get this stuff sorted. I bought this around a year ago, didn't expect that power management would still be totally broken a year later. <ieure>Rutherther, If you need me to test the release on Ubuntu ARM, I could do that. <yelninei>hmm something is rebuilding gnutls, curl, cmake for hurd currently <yelninei>i guess it is 81d077053ed2dca22db85b9d9eb11109cd78d27d rebuilding libsd and p11-kit <Ox1de>Rutherther: thanks. Will check. <yelninei>ACTION is not happy about rebuilding cmake for 4h <ieure>Rutherther, The main issue with this ARM ThinkPad is it needs a kernel with some patches, and I haven't gotten the Guix kernel building stuff to cooperate. If I have that, I should be able to run Guix System. But the newer + patched kernel is important, lots of these patches haven't landed upstream, a vanilla kernel won't boot. <ieure>Was starting to mess with that some more recently, but have had other stuff come up. <Rutherther>ieure: testing would definitely be appreciated, but I think we can leave it for the release candidate. Would really like to find someone who would try Guix System on aarch64 with uefi, though. The only aarch64 I have are embedded that do not have uefi, like rpi, so I cannot really boot the iso I am generating other than in a VM <ieure>Rutherther, QEmu has arm64 with UEFI, probably the easiest way to test. Happy to try booting it on hardware, but I don't think it'll fully boot with the linux-libre kernel we have. <ieure>Okay, service question. I pushed autofs-service-type recently, but am looking at a few post-merge improvements. For the common case of using autofs for NFS mounts, it needs nfs-utils in the system profile, and nfs-service-type. <ieure>But, not every autofs config will use NFS, so these need to be enabled based on the config. This is easy to do for the nfs-utils package, by conditionally extending profile-service-type. Is there some way to *conditionally* extend services? <ieure>autofs-service-type has the service-extensions in it, and those call a function with the config, so they can change the extensions dynamically. But I don't see leverage to conditionally include a service, or not. <ieure>...I guess it's moot, since nfs-service-type isn't extensible. <ieure>So I can't use it as an extension at all. Hmph. <ieure>Well, if anyone has an answer, I'd love to hear it. It would be very nice if autofs-service-type could pull in nfs-service-type, but only if it actually needs it.