<abrenon>ohhhh I see, ok so definitely not the same thing ^^
<abrenon>I think I commonly use one for the other, I'll pay attention to that
<abrenon>although re-reading the logs I did write partial application, to my greatest astonishment
<abrenon>I manage to convey confusion without even writing it down
<vivien>The confusion that I experienced was mostly my fault: my IRC client has a tiny font on a large monitor so I am barely able to read the end of the chat lines. I should switch to something better.
<surfit>hi #guix, I'm having trouble understanding how to build a specific version of python, akin to pyenv; I have located the commit in the guix source tree associated with the python version I'm after, and `guix time-machine --commit=d37d975b748f65a1ace4b2434d04e30ed558a7a8 -- build python` fails to build my a profile due to a perl dependency build
<surfit>should I cleanbuild the whole stack here? what are some troubleshooting steps you would take in this situation? (I am currently running the previous command as `--pure`, with a `--root` specified, and it's just building everything from guile 2.0.12 to guile 2.2.4, including all libs like glib, gcc, groff
<civodul>surfit: hi! could be that you stumbled upon a commit where that Perl dependency was broken, although it should be hard to find a commit where Python or its dependencies don't build
<civodul>re "clean build", all builds are always "clean", in the sense that they are stateless; the build result does not depend on what's on your disk, what you did previously, etc.
<apteryx>hello! Should mcron check if the user home directory exists before chdir into it? I have an mcron job runnning as the user 'nobody' on my system, and it would fail attempting to '(chdir "/nonexistent")'.
<civodul>i think it could (catch 'system-error (lambda () (chdir ...)) (lambda _ (chdir "/")))
<apteryx>uh, paste.debian.net thinks my Scheme diff is spam
<apteryx>seems we should host our own paste service
<apteryx>civodul: wouldn't 'system-error catch too much, hiding perhaps valid failures that the user should be made aware? I was thinking simply checking with (when (directory-exists? home-directory) (chdir home-directory))
<ix>There's no point putting that arbitrary boundary
<dstolfa>ix: i guess it's not really a purity argument, but rather what happens to users who use this, and then upstream changes underneath guix and suddenly things stop working. also, what happens when people use time-machine and the likes. we'd want this to fail gracefully rather than give backtraces and the likes :)
<ix>Yeah, fair second point. Though on the first, i was just thinking have it as a last resort, not to replace concrete packages
<ix>E.g. i have just generated every package in melpa
<ix>But having done that, i realise i won't use a good half of them, so something lazy would have been nicer
<rekado_>what do you mean by “wildly impure”? It certainly is not in the sense that it’s purely functional package management.
<ix>rekado_: i mean the package manager itself is editable code, i can pull an http stream while evaluating my config. Nix refuses to allow you to even check the time while evaluating, let alone while building
<rekado_>you can’t access the network on the build side.
<rekado_>well, I don’t agree with the conclusion “it’s impure by default”, but I won’t argue semantics.
<apteryx>ix: impure-by-default sounds a bit too strong? I'd say Guix is pure where it matters for reproducibility (build side)
<ix>I mean it is a semantic disagreement i think yeah, im coming from nix where purity is understood as "pure from the first eval"
<ix>Sandboxed is what they would use for this definition of pure
<ix>I do think their terms make sense, nix configs are pure in that they deterministically evaluate a-la pure functions, guix configs trivially don't by depending on the filesystem/time/network (outside builds)
<roptat>oh, and note in the guix commit message, the first line needs to be separated from the rest with a blank line. Usually, you would have a one line title, a blank line, some free-form explanations, a blank line and the changelog format
<roptat>you can't have a list with - in the changelog part, instead you should do something like * path/to/file (procedure): what changed.\n(procedure2): what changed here to.\n...
<roptat>maybe one of the error reporting procedures from (guix ui)?
<abrenon>I first saw the (leave …) function and it looked great but I couldn't get my file to compile with it so I was a little bit puzzled
<roptat>in update-repository-at, I see a begin after a let, which is useless, a let can be followed by a body: (let ((var val)) instr1 instr2 ...)
<abrenon>then I noticed the use of a throw in master's version, and I thought I'd do the same, and maybe we'd properly catch in scripts/opam to print a nice translated string for each error case (which is why I attached relevant values to the exception)
<roptat>podiki[m], usually we remove them and add an input to use our version instead
<roptat>abrenon, also in update-repository-at, you use (and (some-condition) (do-something)) Since you don't use the return value of that one, you should use (when (condition) (do-something)) instead
<podiki[m]>roptat: that would include patching a makefile to include the input source then?
<podiki[m]>(okay I think the package I'm looking at mostly does that for their windows build, so shouldn't be too bad....)
<roptat>usually there's a switch in the configure script to use the system version
<roptat>abrenon, I see in get-opam-repository that you compute (opam-cache-directory (uri-host source)), but if it only depends on the host, you can't get more than one repository from the same host. coq.inria.fr for instance has multiple repositories we might want to use, and because of caching it might not work as expected
<abrenon>yeah, absolutely, I thought of that and hoped it wouldn't be a big limitation
<abrenon>but we can change that: a hash ? or simply replacing all / in URL by %2f and storing the full path, scheme included ?
<abrenon>hmm just as I thought ! now that my get-opam-repository accepts a local path, we can get rid of its mock in the unit tests
***Kimapr8 is now known as Kimapr
<abrenon>so, about the throw occurrences, what would be more appropriate ? you mentioned (guix ui) but it seems to reexport (guix diagnostics) if you're meaning either report-error or leave, shouldn't I import that directly instead ?
<abrenon>also, the strings should be translated, shouldn't they ?
<abrenon>and you said I should document the fact that local repositories are now supported, what did you mean exactly ? in the manual ? in the CLI --help message ?
<roptat>char, so I suppose you uploaded it, but can't listen for it? maybe it's your router configuration?
<lfam>I don't know Fare. `man 8 mount` says "The filesystem types which are currently supported depend on the running kernel. See /proc/filesystems and /lib/modules/$(uname -r)/kernel/fs for a complete list of the filesystems"
<lfam>And there is no "bind" in /proc/filesystems on Debian
<Fare>lfam: interestingly, your suggestion makes `mount /nix` work, yet during the guix system reconfigure I still get: `In procedure mount: mount "/nixos/nix" on "///nix": No such device`
<char>ropat: I'm connected via openvpn, and i was able to upload it (only accessable through vpn), so I think the router would not matter
<muradm>there is no MIT license in (guix licenses) ?
<Fare>lfam: it works fine on NixOS, and I'm pretty sure it at least used to work fine in Debian.
<Fare>(I don't actively use Debian anymore except as a chroot under NixOS)
<Fare>maybe the Linux kernel has changed recently? My NixOS is at 5.12.12, and my GuixSD is at 5.13.8. That sounds like a doubtful explanation, though. Or maybe some kernel configuration option? or mount source code option? Is mount from the same source code on Guix as on other distributions?
<Fare>I tried adding a comment to https://issues.guix.gnu.org/issue/35472 — this time it said success, but didn't update the page. So I sent email instead. The page still doesn't see any of my comments. Perhaps in a few hours it will see many iterations of said comments...
<Fare>Or maybe it didn't like all my `foo` and ```bar``` in my comments?
<roptat>Fare, your first email needs to be reviewed by a human, so it can take some time (usually less than a day)
<lfam>muradm: Basically, send an introductory email to <firstname.lastname@example.org>. You will get an email back telling you your ticket number
<lfam>Then, you send your patches to <$email@example.com>
<lfam>You can create the patches with a command like `git format-patch origin/master`. That will generate a patch series of all the changes between your current Git branch and the master branch on Savannah
<lfam>There is also the `git send-email` command, which works the same way but also sends the patches for you. To intall it on Guix, use `guix install git:send-email`
<lfam>muradm: If you are not working in Git, or can't use `git format-patch` or `git send-email` for some reason, that's fine. It's okay to send your code in whatever method you are comfortable with to guix-patches. Reviewers will sort it out for you, although we prefer you use the Git tools :)
<lfam>The bug-foo thing is a GNU standard, although it does feel a bit weird at first
<muradm>lfam: yes i use git send-mail, but it sends the thread, however in documentation it said that acquire ticket no, and send remaining to another ticket specific email
<dstolfa>lfam: heh, i did that once with the wrong git config and ended up with 20something new tickets :). in my defense, gmx locked me out of my email because of git send-email for some reason and i had to move .gitconfig files across machines and i ended up moving a fully permissive one :(
<lfam>I think it will create a new ticket for each patch, which is not the right thing
<lfam>I did it multiple times a couple days ago. Out of practice
<Fare>interestingly, the return message said it couldn't deliver to firstname.lastname@example.org ... would email@example.com work, instead of firstname.lastname@example.org ?
<muradm>ok, thats is the issue i wanted to clarify and be sure :)
<dstolfa>bug-guix is the correct one, not guix-bug (i think?)
<podiki[m]>I guess someone could write a little helper that sends an initial message, then gets the bug/patch# from the response to send the patches....(though would need access to reading incoming mail)
<Fare>what I mean is: is the @debbugs.gnu.org instead of @gnu.org necessary? If so, THAT error message itself is misleading.
<lfam>Fare: I let your email through. The first messages from a new person are held for moderation
<lfam>Fare: It's still not clear to me in what context "/nixos/nix /nix bind defaults" is expected to work for fstab. It doesn't work in either Guix or Debian nor is it documented to work
<lfam>I'm not an expert on dealing with file systems in Guix
<lfam>The documentation of "device" in our manual says this: "This names the “source” of the file system. It can be one of three things: a file system label, a file system UUID, or the name of a /dev node."
<muradm>i was not super fan of it on nix, and not super fan of it on guix, just want to see if it will bite me in some way
<drakonis>well, it can be done better in guix by virtue of being better integrated with guix itself instead of being third party
<drakonis>plus it can be changed and the improvements will propagate to everyone
<drakonis>its a small victory compared to something like home-manager
<muradm>i don't know, it is not trivial task, if let's say system config is more or less the same for most people, after your login manager drops you to your session it could be so wild, also i prefer to abstract my self from system i run on, these home managers introduce very tight coupling
<muradm>if the goal to run shepherd as user service manager you can do it now also
<muradm>packages are managed by profiles out of the box on guix
<muradm>what else, configuration? that is whole different story, i understand mapping configuration of services/os etc to guix guile scheme
<drakonis>its for managing user level configuration i believe
<muradm>but attempting to map everything under .config/* and around it is a night mare
<drakonis>user level services and configuration, as well as anything else that comes up
<drakonis>it isnt trying to map everything under .config/*
<muradm>from link above: "All software can be configured in one language (Guile Scheme), this gives users to ability to share values between configurations of different programs and other benifits."
<roptat>maybe... guix refresh already does almost all of the job
<NicholasvonKlitz>yeah, that's why I find it an interesting opportunity to explore. It seems we're already so close to get there
<roptat>but even with it, it's not trivial to update packages, because conflicts, new failures, ...
<roptat>but maybe it would make sense to automatically push some updates, but I think you'll meet some resistance from the community if you don't come with numbers and show that it works well
<roptat>(like, is there a risk it could break guix somehow? it should not push updates to master if they have too many dependents, ...)
<NicholasvonKlitz>I can see that for packages which aren't explicity versioned can cause conflicts, but for versioned packages (like crates or other compile-time dependencies for example) I don't see how just adding a new package version would break anything
<roptat>ah, no, but we try to keep the number of versioned packages under control...
<NicholasvonKlitz>I just see that some packages are taking forever to be reviewed and merged (ex. nheko update has been unmerged and not reviewed for 3 months despite being perfectly fine). I just think if the maintainers would need to bother less with all the "simple" packages, then they could focus more on the "bigger" packages
<leoprikler>If an update is perfectly fine, but no reviewer is there to verify, is it really fine? :P
<podiki[m]>What can average users do to help? Try out patches to test? Submit the simple upgrade patches? Donate money? (The package transformations are awesome, just saw they get reflected in exported manifests, very nice)
<leoprikler>I just had a look at the nheko patches and it seems they all stuff patches to several packages into a single message?
<leoprikler>I'm not even sure if those are multiple commits.
<leoprikler>Okay, looking closer at least 46012 is a series, but still single-message