IRC channel logs
2025-12-26.log
back to list of logs
<PotentialUser-73>Great! Does anyone know why tab completion doesn't work on Git only? For example, attempting tab completion on "git add ./.gi" results in "git add ./gibash: awk: command not found". I was able to type the rest of "gitignore" on the next line of the shell, however. Tab completion is fine on other commands. <PotentialUser-73>Did someone respond to my message by chance? I left my computer, so I'm not sure if I disconnected in the meantime. <JackleBells>I'm new to Guix and already have git from my distro repo, so I can't answer <meaty>Are there any packagers in right now? I'm having some trouble updating ppsspp but I don't wanna make yet another WIP help-wanted PR for a playstation emulator yet <meaty>specifically, it's having trouble compiling because its code imports a header from sdl2-ttf which itself wants to import a header from sdl2 (specifically SDL.h), but it can't find it even though I have sdl2 in the inputs <meaty>This is a tricky situation because I can't patch sdl2-ttf since it's an input, and I'm not sure if I should be <meaty>I'm reluctant to start patching ppsspp's build system, too, since I've un-de-vendored it for now and it should "just work" <benjaminwil>hm, i have been having trouble `guix pull`ing today... is it just me? my channels on codeberg.org result in "guix pull: error: Git error: the SSL certificate is invalid" but channels elsewhere are working just fine. <benjaminwil>at first i also thought i had a NTP issue because i am travelling... but i reconfigured the system with my new local timezone and the issue persists. <newguixbie>hi #guix … I’m trying things like building a system-agnostic version-1.4.0 source fixed output derivation suite, and it looks like \ if I want to cover all the systems I need a hurd builder setup <newguixbie>I’m on i686 running version-1.4.0 , and after adding hurd-vm-service-type I get secrets errors and the vm is killed right after it launches … `qemu-system-i386: Slirp: Failed to send packet, ret: -1` `secret service: invalid handshake #<eof>` <newguixbie>hey I saw 1.5.0 was released on the 23rd. awesome sauce, new realities pend <Arsen>(or can I locally make that change somehow) <Arsen>libdebuginfod maybe shouldn't be a big issue <newguixbie>if you clone the guix repo you can edit package files easily <newguixbie>there’s also a section in the manual on contributing although I haven’t gone through it yet myself <Arsen>newguixbie: I'd need to re-do that for each machine where I clone my guix-home setup though <newguixbie>I am also engaging such frustrations patching my guix to get i686 to work better but not having a stable system yet to contribute and am curious the right way to do it. <newguixbie>the matroska backend tests in gst-plugins-good are failing on i686 breaking everything that uses gstreamer, matroska should be disabled in gstreamer on i686 so that systems build <Arsen>in theory it should be very simple indeed <Arsen>... but I don't see a way to change configure-flags easily :( <newguixbie>usually a build argument, which one depends on the build system, can find examples in other packages <newguixbie>I’ve been finding the simplest approach is to get the source with —source or —keep-failed, modify it to do what I need, and pass —with-patch, simply because —with-patch works on command line and in manifest files <Arsen>I don't see a build arg for --disable-libdebuginfod though , nor an easy way to just override it with inherit. but I also need to add new inputs to this one (curl, json-c) <newguixbie>hrm I guess you’d use a guile function to remove it from the string list in the #:configure-flags argument. I think (delete item lst) does this … <gabber>our test suite does *not* run gnu/tests by default, right? <gabber>how do i run tests under gnu/tests? `make check TESTS=gnu/tests/avahi.scm` does not seem to run any tests <gabber>and `make check` alone does also not run them <Rutherther>And you run system tests with check-system target <gabber>i got to think so (after scrolling down my info-reader a notch) <gabber>unfortunately system tests fail kinda fast with "gnu/system/image.scm:1020:10: error: missing root file system" <gabber>and i have not (yet) figured out if and/or how i could run a single test from there <gabber>i guess more like: any of them (: <gabber>what change(s) of yours would you suspect breaking the tests? <gabber>but i don't understand. you clearly add an fs with mount-point "/" before everything else at image.scm:1042 <gabber>i clean my .go files and try again <Rutherther>gabber: I think the issue is in operating-system constructor itself somehow. One of the operating systems indeed does not have a root file system <gabber>yes, cleaning up and re-testing yields the same result <Rutherther>See the issue for what part of my commit to revert <Rutherther>Feel free to do it. I wont get to my computer for few more hours <gabber>i think you made a mistake with the closing parens <gabber>the let* in (operating-system-for-image) closes without a body <gabber>ah... no? but it is formatted this way <gabber>i'm confused, not in a hurry and think i'll do some exercise before giving this any more thought (: <luca>Yeah, pretty much exactly what the nixpkgs section describes <Arsen>the issue in the nix section isn't unique to package managers <gabber>Rutherther: seems like this is an edge case hit after a few successful system tests <gabber>can we include/exlude system tests? <Arsen>the gcc repo is multiple gigabytes also (not 83G, but that's a reflection of the level of activity) <Arsen>this is true for all software in version control though? <Arsen>really people just shouldn't be cloning git repos very frequently, using tarballs instead (wisdom from the 90s at it again), but that seems orthogonal to package management <Arsen>I doubt guix or nix wouldn't be able to cope with daily-updated tarballs <luca>Sure. But nixpkgs happens to have a lot a lot of activity. gcc is not on github afaik, so they probably aren't getting anywhere close to 80gb. I think the "The Pattern" section is a bit more relevant, where it says having a lot of files is bad (overly simplified), and something guix doesn't do by categorising stuff in giant files (for example messaging.scm for all messaging apps) <Arsen>well each change to any package in a single .scm incurs a new copy of that .scm in the git object store <Rutherther>gabber: no, what I broke should be fixed, I know what the issue is already <Arsen>gcc is on github as a mirror (fun fact: we have no idea who owns that mirror. people keep sending PRs to it. we can't take those PRs. it's weird) <luca>Other distros use multiple repos for each app or category (debian or arch), which I suppose could help with this in principle? But yeah, nixpkgs / guix have actual code, not just metadata like other package managers <Arsen>same goes for gentoo and managarm (both of which I work on) so I can definitely sympathize <luca>I assume gcc doesn't have 20k forks. And personally I've avoided forking guix as it's pretty big, and prefered to use agit instead <Arsen>well we can't take PRs so any forks are just personal development branches <nikolar>also having a billion forks isn't exactly nixpkg's fault <nikolar>git wasn't meant to be used like that <luca>What's special about nixpkgs / guix (as opposed to gentoo) is that users interact with the git repo directly, as opposed to interacting with indexes and repos. Which leads to guix pull being slow, especially for first installs <Arsen>well no, the gentoo repo is also a git repository and many users (myself included) sync it with git (but we also do provide rsync servers updated every 15 minutes) <Arsen>and the repo provides ebuilds, one per version per package (+ a bunch of metadata) <gabber>i guess `make check-system TESTS=avahi` or `make check-system TESTS=avahi.scm` SHOULD work, but i get "Selected 0 system tests..." for either invokation <luca>oh my bad, I thought gentoo worked more like arch <Arsen>nws; but, anyway, my point is that package managers aren't *that* special here, it's just that delivering stuff via git when you don't intend to, yknow, collaborate, brings the overhead of VCS also <Arsen>if every gcc user pulled the gcc repo daily I bet the overseers would be angry at us <Arsen>it's a cheap way to do delta updates, but it's only cheap because the cost is externalized to someone else :^) <luca>It's a cheap implementation, but high compute maybe? <Arsen>certainly costs the providers :^) <Arsen>but it's also a lot of disk overhead really <luca>I'd say this is a known issue with git and monorepos. Google and facebook have their own in house implementations of a VCS for example. And Microsoft is trying really had to move to git from their own in house thing :P <nikolar>git is great for what it's meant to be used for <nikolar>obviously suboptimal at other things people want to use it for <luca>git was meant to be used for linux kernel development. Anything else is suboptimal :P <nikolar>*distributed collaborative development <untrusem>ohh we are having a convo about this stuff <guixer>Since a few days, dmesg -T time jumps for as long as the laptop's been sleeping. system time is correct, but dmesg time is ahead <guixer>i do not see an issue about it on codeberg. kernel is 6.17.12 <guixer>eventually wifi won't connect after waking up, possible also connected to time weirdness <guixer>I'm wondering if anyone else has seen this <gabber>Rutherther: please ping me when you get to it—love to gain some insight in the topics (: <Rutherther>gabber: what's an example of a failing system test with this? <gabber>not sure i understand. since commit efc32c6684f755 we get the message above ("missing root file system"), before that tests run. but apart from that i can't really test my original goal of reviewing #4955 since i can't select a single test (avahi.scm in that case). when i pass TESTS to `make system-check` (as described in some mailing list threads) i get "Selected 0 system tests..." <gabber>this also makes it somewhat harder to debug the issue introduced with your commit, since *some* system checks still seem to work (or at least some images are instantiated *with* root fs), but some don't. and it would really help finding at least one case of each outcome to start disecting, since your patch *looks* rather harmless <Rutherther>You definitely can. I have ran the foreign install tests fine <Rutherther>Are you aware that the parameters to check-system arent files, but individual tests, right? <gabber>guess we should update the section in the manual <Rutherther>My patch is not harmless for the case where root file system is missing, then uuid is tried to be computed, but that fails due to the missing fs <yelninei>gabber: the avahi test is called "nss-mdns" <gabber>yelninei: thanks, i figured that out by now (: <gabber>Rutherther: than i'd argue this step should not fail silently <Rutherther>gabber: not sure I understand, what step and how does it fail silently? <gabber>you said: "that fails due to the missing fs". <gabber>ahh, is this some sort of recursive bootstrapping issue? <gabber>we can't calculate the uuid of the os without the root fs being a part of the os definition? <Rutherther>Yeah, currently it relies on it in some way. It seems a bit strange but it is like that <gabber>or: it only works on a dummy root-fs (with a wrong UUID), then we replace that fs with the "real UUID" one which in turn falsifies the uuid...? <Rutherther>There is no dummy root-fs anymore and that is exactly the problem. I have removed the dummy root fs that was used in cases where the operating system doesnt have root fs. <gabber>which is why generating the UUID now fails (IIUC) <Rutherther>There is no possibility for the 'uuid' to be falsified, the uuid is not recomputed afterwards <Rutherther>The solution is just reverting the correct part of my commit <Rutherther>The one that removes the placeholder/dummy root fs <gabber>Rutherther: we could also fixing it by adding a root fs to all the images that need one (e.g. %hurd-vm-operating-system) <gabber>or rather %hurd-default-operating-system <Rutherther>gabber: true that's maybe more appropriate, however, it's not completely clear to me that can't leave more issues somewhere else <Rutherther>gabber: this would mean the UUID is still computed from original's operating system's file systems, which I think is better, because it means two systems different only in root fs definitions will have different UUIDs. I think the main reason for the UUIDs is that we do not want to be in situation where one ends up with two disks on one machine and has the same UUID. But on the other hand we need them deterministic so that the images are sort of... <gabber>you could define the os, then calculate the uuid, then replace the root-fs with an fs with the correct uuid, no? <gabber>no, right now you are calculating the uuid from an os definition where the root fs is missing (this is what throws the error). <gabber>when you calculate the uuid you need an os *with* a root fs <Rutherther>because my change is just wrong. I thought it is not being used at all, I was wrong <gabber>but maybe it's only used in the least of cases? which would moving that code to that specific case improve it. <gabber>anyhow, have fun with it, i'm gonna be afk (: still curious about the solution you'll come up with <Rutherther>even though it's only in a few cases, I would rather not introduce such a major change in the assumptions of the images. Who knows how many people rely on this <Rutherther>I wouldn't have done this change if I realized there was the call to root-uuid from this os, I have somehow missed that line <radhitya>is 1 gb ram enough to run guix? my need kind of lightweight: irc client, web server.. enough <Rutherther>it is not enough to run Guix itself. Or at least not withut swap and with swap it's going to be slow. However you can still deploy Guix System to the machine from more powerful one if you have one, with Guix installed. <radhitya>i mean, i only use binary.. why i cant use it on 1gb ram? <radhitya>i mean, how guix works which make me unable to use on 1gb ram? <radhitya>not "unable", but the experience will be not good <Rutherther>you never just use a binary, you will be evaluating scheme code, compiling scheme code, building profiles and so on <Rutherther>that is if everything else is substituted. It can also happen it won't be substituted and you will have to build other sw <Rutherther>I wouldn't use anything less than 8 GB. Also Guix packages can take more space since you will have multiple versions in the store, you need at least twice the space that your system takes to be safe. And even with that you might struggle if you don't manage it well <Rutherther>to be honest it seems the policies for freezes don't really work that well, so I have begun thinking that I will just cherry pick some commits from master rather than to base the final release on latest master like the GCD's plan was. And if I do that it doesn't matter too much if it goes to master or not <Rutherther>we do have a version-1.5.0 branch now based on master as was 3 days ago, so that might be the latest 'regular' commits from master that get there. (hopefully we should send an e-mail later tonight with the artifacts that are already built for it) But I don't know, I am open for discussions <Rutherther>This is just a release candidate for now. And it's already became clear that there should be couple more fixes in the actual release <redacted>I'm trying to debug an intermittent failure during transfer when running guix deploy. How can I get more debugging output from the ssh connection guix deploy creates? <redacted>If I was connecting directly I could do `ssh -vvv' <ieure>Rutherther, Oh, I guess lilyp did merge it. Nevermind! <loquatdev>Hello, everyone. How does one go about running a `guix home reconfigure` as root but for another user? I'm aware that you can set a user's home configuraton from the system configuration; I tried to look into its code to understand how it works, but I struggled to understand it. <loquatdev>I'm looking to manually reconfigure another user's home from the command line. <Rutherther>what guix-home-service-type does is that it executes the guix-home activation script as the target user <loquatdev>It uses the root user's guix version though, right? That's the main thing confusing me. <Rutherther>ie. something akin of "sudo -u target-user $(guix home build /path/to/config.scm)/activate". Note that it is not equivalent to a reconfigure. It doesn't change the profiles under /var/guix/profiles/per-user, so it does not affect any generations <Rutherther>no, guix-home-service-type does not use 'root's' version, it uses whatever guix version was used for guix system reconfigure <Rutherther>if you want to use root's guix, ie. the one you would guix pull to as root, just do /var/guix/profiles/per-user/root/current-guix/bin/guix home reconfigure ... <loquatdev>Right, that's what I meant, about the version being used for the system reconfigure command. My apologies. <loquatdev>Thank you very much. I think I understand now. I was thinking about it the wrong way. <loquatdev>So `guix home reconfigure` is basically the same as `guix home build` except it runs the generated activate script afterward? <Rutherther>it does that, yes. But not only that, it also updates the profile at /var/guix/profiles/per-user/$USER/guix-home. Which means you get a new generation and can later switch to previous generations, you can see those generations through guix home list-generations <loquatdev>That would be why home configurations installed by guix system don't show as home generations, right? <Rutherther>doing the profile switch means: look for the highest number in the /var/guix/profiles/per-user/$USER for guix-home-X-link, create guix-home-{X+1}-link as a symlink to what guix home build gave you and lastly, update the /var/guix/profiles/per-user/$USER/guix-home to point to this new symlink <loquatdev>Alright. Thank you so much for the info! God bless