<NicholasvonKlitz>dstolfa: Apparently guix can handle circular dependencies? Just set minium rust version to 1.51 to avoid the resolver issues and both packages build without any issues.
<dstolfa>NicholasvonKlitz: but do you need circular dependencies in guix itself? as i understand it, one is a build dependency for the other, but not a runtime dependency. also, does `guix install ...` work?
<morgansmith>Hello! I want to create an origin snippet that turns a subdirectory into the root directory. Some silly project made a "v2" directory in their project when they switched versions. I was looking at scandir and delete-file-recursively but I couldn't think of a good solution.
<bmk>Well, I've just proven it's not an issue with the disk, but anyways:
<bmk>I've got a fairly normal guix setup. Sometimes: programs will be unable to load and open certain files for apparently no reason, instead acting as if they are not there
<bmk>For example, a program not being able to load it's sounds, claming they're missing, but i can go to the path and mpv them fine. A script claiming it can't find a program in the same directory, even though it is thier
<cehteh>another thing ... additionally to install medium and qemu image it would be nice if there would be a tarball that could be used as image for usermode linux or lxc containers, but thats just a brainfart
<bricewge>cehteh: Have you looked into "guix system container" or do you mean something else?
<cehteh>bricewge: something else, runnin debian for example and want to download a guix container as image from the website i can start with lxc or uml, the idea here is that guix may provide such an image, guix container may be able to generate that
<cehteh>makes me wonder why the CI isnt staged to begin with, everyone pushing to some branches which are not published before CI gives green light .. and then maybe (or maybe not) automerged to master
<leoprikler>If you always wait on CI, some things will never be pushed to master
<cehteh>you may even provide different channels some bleeding edge for developers where the devs push too pre-CI and some stable channel for users who prefer not so bleeding stuff which is gone past the CI (or some other system)
<cehteh>voluntary CI in a pre-commit hook or some formalism "works-for-me:" in the commit which make it past the CI may be already better than the current state where one can 'accidentally' break a lot stuff
<podiki[m]>right, some different branches with levels of how close it is to being merged to main, would be easier to patch and test than huge core-updates
<podiki[m]>(we just got a haskell branch to deal with all those packges, which is also in the CI; nothing like compiling GHC on your own all the time)
<cehteh>i mean errors happen, i have no bad feeling about that, but removing the footguns would be helpful
<cehteh>i just gone by the docs there is a sysctl service type with that parameter
<lispmacs[work]>with the openssh server service, do users have to be members of a particular group to login remotely, like dialout? I couldn't see, in the service configuration, and obvious way to restrict login to a particular user or set of users
<cehteh>why does system-reconfigure to a lot compilations when i didnt do a guix pull? just changed the the simple-service thing above
<bricewge>You only need to run "guix pull" when you want to get to the latest guix version
<bricewge>Probably some package haven't been build by the CI yet
<cehteh>i just installed the system earlier and it was all up to date
<cehteh>not that i care yet, but i thought a 1line change in the config.scm would be fast :D
<cehteh>anyway this 'system going to sleep' is still problem, have to hard reset and no idea where that is configured
<bricewge>lispmacs[work]: You don't need to be a member of dialout. For restring access, `openssh-configuration` doesn't expose such options so use the `extra-config` with standard sshd_config(5) configuration such as `AllowGroups` or `AllowUsers`.
<leoprikler>clemens3: stuff like that can happen, you should try `guix challenge` and perhapsreport a reproducibility error
<lfam>The key expiration is not relevant for code signing
<lfam>If key expiration was taken into account, Guix would break when the keys of people who left the project eventually expire
<lfam>Some have argued that key expiration isn't relevant in any context, but that's a lesson learned with decades of hindsight since PGP was designed
<Noisytoot>Couldn't it verify that the key didn't expire before the date of the commit?
<leoprikler>so letting my key expire never was the right choice all along? Nice
<dstolfa>leoprikler: until you lose it, which happened to me due to disk failure. now there's a public key in the void that literally nobody has (not that it matters that much)
<lfam>Noisytoot: Key expiration dates can be changed (I need to change my key's expiration date but need to wait a couple weeks until I'm able to). So, it's not clear what the benefit of that would be
<leoprikler>Even in that case, automatic expiry does little to address it.
<lfam>People used to say that the risk of not setting an expiration date was that your key could be stolen and then used to impersonate you. Those decades of hindsight make it seem rather far-fetched in my opinion
<leoprikler>Let's say you create a key for the duration of one year and on day 2 of the year your disk is hosed.
<dstolfa>PGP was designed in a... different world than today :)
<leoprikler>Now that key is up in the ether for the rest of the year
<dstolfa>leoprikler: well, at least it would expire in a year. mine's been out there for close to a decade now