Unable to build "Ten Years Reproducibility Challenge" paper
Hi Guix, I am relatively new to Guix. I recently came across this blog post: <https://hpc.guix.info/blog/2020/06/reproducible-research-articles-from-source-code-to-pdf/>. In trying to build and run the evaluation as documented in <https://gitlab.inria.fr/lcourtes-phd/edcc-2006-redone>, I'm encountering the following error (both on Guix package on OpenSUSE distribution as well as on Guix system in a VM): #+begin_example $> guix time-machine -C channels.scm -- build -f guix.scm Updating channel 'guix-past' from Git repository at 'https://gitlab.inria.fr/guix-hpc/guix-past.git'... Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... ... building /gnu/store/vsvpi0cy4g3s5w7p9rj3ixnw16jllmr1-guix-config.drv... building /gnu/store/2igl2vvjmvg2qwizy5w0gvf63vsvb44x-guix-core.drv... building /gnu/store/0y3m9wj8qziblk743fjjxmn1iybm2zif-guix-config-modules.drv... building /gnu/store/0ny9586ypfm7d7k9ly3s4i60hb3wczlj-guix-core-modules.drv... building /gnu/store/cscfsg5hmznn5rgk3q8affwc5445fqcd-openssl-1.1.1g.tar.xz.drv... applying 6 grafts for pango-1.42.4 ... building /gnu/store/vvhn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv... / 'check' phasebuilder for `/gnu/store/vvhn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv' failed with exit code 1 build of /gnu/store/vvhn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv failed View build log at '/var/log/guix/drvs/vv/hn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv.gz'. applying 7 grafts for graphviz-2.40.1 ... cannot build derivation `/gnu/store/8adwgdgaf6xcyhyyc5z9nvrql7bkgvhy-libgit2-1.0.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/kml3x6f5arzsqbqcf9n77dpw1mwszybr-guile3.0-git-0.3.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/bgyz3mib0bvpmxl1j0jp9x4jqqhw6416-guix-cli.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/cjqbylp554mhwhl8895z5n74q5998waq-guix-extra.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/ql55k991hvz4x9splndhwyzq9apnasig-guix-module-union.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/s9j6wb6jzqhfcwb8isjbalf6msdqq83b-guix-packages-base.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/mf05ss7j1hh06vnrkywkswvlgdzv2i8k-guix-packages.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/x1ci1v82ncj679gipnk3s5sszshl66fi-guix-system-tests.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/pm8y6k5kzcddk170h0biarmqi278m0ww-guix-system.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/nnv3zac8hj40kdz5i4bwwbfzqq5j6bi9-guix-cli-modules.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/2xilwplb6mzqsh4p5yym52f1q4l14lmc-guix-command.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/9g1cw0wxwi0jm7akmrf48hx6rxswx4nn-guix-extra-modules.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/v9zjw4gphv900swc8z450hal3farykwd-guix-packages-base-modules.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/fjqv9nagdnda38l68x6f82qlradx18a7-guix-packages-modules.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/m5z9ba7gra3qml9gzl6vh4d8fcq4qn20-guix-system-modules.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/i37g4wlrgwcaq5v2c4zrkaysfnf95spy-guix-system-tests-modules.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/fp7isyvw7g8kr2vhqgw4p45yckz0srd9-guix-40fd909e3.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/x2fv84h6izjn8sh50nn55i2qp9h3hbzj-profile.drv': 1 dependencies couldn't be built guix time-machine: error: build of `/gnu/store/x2fv84h6izjn8sh50nn55i2qp9h3hbzj-profile.drv' failed #+end_example As can be seen in the attached build log, it seems some tests for openssl are failing. I'm speculating that these tests are non-deterministic and perhaps overly rigid. Is there a way to tell Guix to either skip the 'check' build-phase for a specific dependency (or perhaps for the entire build invocation)? Any guidance? -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain i
Re: Unable to build "Ten Years Reproducibility Challenge" paper
Julien Lepiller writes: > That's openssl failing due to a time-dependent test. Try making your system > time > something around 2010 and don't let ntpd set it back to today until openssl is > built. Thanks; that worked. > You could skip tests, but that would build a different derivation tree, so it > might affect reproducibility (probably not): --without-checks=openssl Did you mean: --without-tests=openssl -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
Re: Unable to build "Ten Years Reproducibility Challenge" paper
Simon Tournier writes: > Sadly, it is a known issue: > > ... > > https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-time_002dmachine Thank you for the reference; much appreciated! > For an immediate fix, you can do something along these lines: > > sudo timedatectl set-ntp false > sudo timedatectl set-time '2020-06-23 00:00:00' Thank you; that resolved the issue. > For a long-term fix, I have done a systematic review about what > happens in the worst case scenario: > > https://simon.tournier.info/posts/2023-06-23-hackathon-repro.html That was an insightful read. Are there related discussions/plans to better address some of the issues you point out in the post (over and above those that are linked from the post)? -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
Turning off tests leads to a different store item (was: Unable to build "Ten Years Reproducibility Challenge" paper)
Felix Lechner via writes: > On Tue, Oct 31 2023, Julien Lepiller wrote: > >> You could skip tests, but that would build a different derivation >> tree, so it might affect reproducibility > > Those shortfalls are a consequence of our packaging habits. In an ideal > world, would running a test suite ever build a different derivation? Tests can fail for a number of reasons. At times tests may have some failure modes that aren't so easily reliably overcome (as setting the system clock). By default, do we capture the test log and include it as part of the build artifact? I'm not asking rhetorically. If so, is there an existing discussion noting the pros/cons of that decision that I can read to be better informed? If not, why should skipping the tests result in a different derivation tree? And if it shouldn't, but does, is there an existing bug report for my reference? > Please bear with me as I again belabor the same point without > receiving public support. Building packages should be separate from > testing them. FWIW, I believe I agree with you. Perhaps following Simon's recently proposed (not yet accepted) RFC process could help in this regard: <https://issues.guix.gnu.org/issue/66844>. Is there an existing issue which notes some of the drawbacks of the existing approach and perhaps proposes some alternatives? I do not know enough to know how trivial or not it would be to alter the present behaviour (and what some of the unintended consequences might be), but I believe this is an important topic that needs some thought and consideration. -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
Re: Turning off tests leads to a different store item
Simon Tournier writes: > On Wed, 01 Nov 2023 at 17:52, Suhail wrote: > >> If not, why should skipping the tests result in a different >> derivation tree? > > The store path is different because it hashes all the inputs, included > the builder script; from my understanding. It certainly seems to be the case. Would you know the specific place(s) in the source code (in addition to guix/derivations.scm and guix/store.scm) that would be relevant for this discussion? On a related note, is Dolstra's phd thesis relevant for these aspects, or do you know if Guix diverges from Nix in some areas? > Well, from my understanding, get the same the store path for the same > package built with or without its tests ... would mean to have a > derivation for building and another derivation – referring to the > former – for testing. Yes, with the test derivation being something like a "fixed-output derivation". [[info:guix#Derivations][From the manual]]: #+begin_quote Operations such as file downloads and version-control checkouts for which the expected content hash is known in advance are modeled as fixed-output derivations. Unlike regular derivations, the outputs of a fixed-output derivation are independent of its inputs—e.g., a source code download produces the same result regardless of the download method and tools being used. #+end_quote The hypothetical test derivation leaves the build artifact unchanged, but does communicate some "side" information. It's like a fixed-output derivation carrying some metadata (further elaboration below). > Well, taking this direction, one could imagine a derivation for each > phases; somehow extend to all phases what it is already done for > fetching source, build and grafts (guix build --source && guix build > --no-grafts && guix build). Perhaps not all. The thing that sets the "check" phase (#:tests?) apart from the rest is that it's an identity transform with a side-effect. i.e., it simply reports on the state of its input (i.e., the build artifact) leaving the build artifact unchanged. The only other phase in the gnu-build-system that is similar to the "check phase" is the "validate-runpath phase". An alternative (possibly future) version of Guix might allow us to delay the interpretation/meaning associated with the following cases: - whether or not the tests were run, and - whether or not the tests, if run, passed To be able to do so, we need the "check derivation" be able to communicate two things (downstream): a summary of the test phase (could simply be a 3-valued datatype, like a 'Maybe Bool' in Haskell, but could also be something more elaborate), and the input build artifact (which remains unchanged). Similarly for the "validate-runpath derivation". I do not know what the best way to communicate the "side-effect information" (did the tests run and if so what was the conclusion) would be. Specifically, should the output of "check derivation" (similarly for "validate-runpath derivation") include the unchanged build artifact or not? Btw, is this still the appropriate mailing list (and more generally, forum) for this discussion? -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
Re: Turning off tests leads to a different store item
Greg Hogan writes: > On Thu, Nov 2, 2023 at 11:26 AM Suhail wrote: >> Perhaps not all. The thing that sets the "check" phase (#:tests?) apart >> from the rest is that it's an identity transform with a >> side-effect. i.e., it simply reports on the state of its input (i.e., >> the build artifact) leaving the build artifact unchanged. The only other >> phase in the gnu-build-system that is similar to the "check phase" is >> the "validate-runpath phase". > > Should this say "without side-effects"? No, I meant "with side-effect", but we have a notational difference. What is termed side-effect is context dependent, so I'll fix my terminology and make clearer what I meant. To me, the "check" phase is something that reports on the state of its input. Said report (i.e., whether or not the check phase was run, and if run what its output was) is what I was using the term "side-effect" for. Perhaps "test state metadata" would be a better term. > How does one guarantee that the test phase is free of side-effects? Translation to remove ambiguity of the term "side-effect": How does one guarantee that the test phase doesn't modify its input build artifact? This could be enforced using an overlay layer as you suggest, but we could also take a different approach. It would be sufficient to be able to distinguish well-behaved tests (those that don't alter the input build-artifact) from those that aren't (i.e., those that do alter the input build-artifact). > Alternatively, could we make it easier to record a timestamp in the > manifest for Guix to use as the build clock time? While that would address the original issue that motivated this discussion thread, it's not an alternative in the context of the current discussion. Regardless, I agree that having such a facility would be useful. While I do believe the defaults in gnu-build-system could benefit from revisiting our current treatment of the check and validate-runpath phases, advocating for that is not my primary goal with this discussion. As someone who's not well-versed in Guix internals, I am simply trying to understand what an alternate build-system (say, ds-build-system) would look like. One that allows the user/caller of a package to determine how to handle: - whether or not the tests were run, and - whether or not the tests, if run, passed Similarly for other such "phases". One application for such a build-system (which is of interest to me) would be to "package" the result of some "data"-dependent computations where the notion of what constitutes a "passing build artifact" is less clearly defined (e.g., models used for algorithmic decision-making). -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
Re: Turning off tests leads to a different store item
Simon Tournier writes: > On Thu, 02 Nov 2023 at 15:25, Suhail wrote: > >> Yes, with the test derivation being something like a "fixed-output >> derivation". [[info:guix#Derivations][From the manual]]: > > No, it cannot be a “fixed-output” derivation… > > …because we cannot know in advance the expected content hash of the > tests output. Yes, hence the "something like". It's similar, but also different in important ways. > And from my understanding, one solution would be to have something as > below. One “object” for building and another “object” for testing. > > ( Here, I am using the same object namely for the both; > just to make concrete the discussion. :-) ) > > The point is: we have two derivations; one for the build (without tests) > and another for the tests (without build). > > ... > > Somehow, we could have a “build” build-system and a “test” build-system. > And the “build object” would be an inputs of the “test object“. You are trying to reconcile our discussion with what you know about Guix internals which is both useful and necessary (eventually). However, since I have less knowledge of said internals at present, I am not able to meaningfully contribute to what the implementation may look like yet. What I can do, instead, is to articulate some invariances/properties that I believe are both desirable and reasonable (without considering how feasible or not they may be). First some notation. Let's say the "test metadata" captures the information of interest: were the tests run, and if so what was their outcome. A very simple (but sufficient for our purposes) datatype would be the union of null, #t and #f (where the test outcome is a boolean). It's possible that in practice, "test metadata" may have additional information (for instance a reference to the "build output" in the store), but we'll ignore that for now. I'll use "test output" to mean the combination of "test metadata" and "build output" where "build output" is also the input to the "thing that generates the 'test metadata'". So we have the property that the "test output" extends the "build output" by providing some companion information (i.e., the "test metadata"). The invariants of interest are about what things are considered equivalent. To my understanding this is captured in the Guix notion of what is and isn't considered a Substitute. 1. It should be possible to discard test metadata: We should be able to use "test output" as a substitute for "build output". I.e., a derivation that doesn't demand that we run the tests ought not to care whether or not we did. 2. "build output" can be used as a substitute for "test output" with null "test metadata". 3. It shouldn't be possible to vacuously manufacture test outcomes: "build output" cannot be used as a substitute for "test output" with either #t or #f "test metadata". If our hypothetical build system (say, ds-build-system) were to admit the above invariances, do you foresee some complications that may arise that need to be addressed? > Well, somehow perhaps some revamp of the record. Perhaps, but I am not quite there yet to consider how it might be implemented, because what "it" is is still not sufficiently clear to me. -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
Re: Turning off tests leads to a different store item
Simon Tournier writes: > On Thu, 02 Nov 2023 at 18:54, Suhail wrote: > >> If our hypothetical build system (say, ds-build-system) were to admit >> the above invariances, do you foresee some complications that may arise >> that need to be addressed? > > Instead of trying to answer to this question, what comes to my mind when > reading is: > > https://www.joachim-breitner.de/blog/743-Build_tool_semantic_aware_build_systems Thank you for that reference. Yes, that's in the right spirit. The motivational scenario (packaging data science applications) as well as other specifics are of particular interest to me. From the blog: > A build system like nix is designed around the idea that builds are > relatively cheap, and that any change in a dependency ought to trigger > a rebuild, just to be sure that all build outputs are up-to-date. In addition to the above assumption, software engineering makes another assumption that (at times) needs to be relaxed in data science. In software engineering, the tests are assumed to have a definitive notion of "pass" vs "fail". Whereas in data science applications, the "tests" may not have a definitive "pass" or "fail" semantics and/or may entertain multiple such interpretations. While I have been calling these tests so far, perhaps it may be better to call these something other than that. If so, "statistical report" may be more descriptive. Regardless, we reach the point where it would help us if we had some control over defining what is or isn't substitutable for another. While the blog post is considering this more generally via the use of "equivalence proxies" (e.g., treat A as being substitutable for B if the value of the proxy evaluated at A is the same as the value of the proxy evaluated at B), I am currently limiting myself to the more specific case where I want to be able to treat A as being substitutable for B when I am able to define a computation that takes A as an input and is able to generate B. Note that I am not requiring that I be able to generate A from B. So, in Guix, if I want to create a "type of substitute" which instead of downloading over HTTP/HTTPS runs some other computation how would I go about doing that? > and also the paper: Build à la carte > > https://dl.acm.org/doi/pdf/10.1145/3236774 Thank you for that useful reference. -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
Re: Turning off tests leads to a different store item
"Tomas Volf" <~@wolfsden.cz> writes: > On 2023-11-02 15:25:33 +, Suhail wrote: >> [..] >> >> The hypothetical test derivation leaves the build artifact unchanged, >> but does communicate some "side" information. It's like a fixed-output >> derivation carrying some metadata (further elaboration below). > > I am not aware of any, but I wonder if there are test suites that actually > modify the built binary, for example by patching a bool flag `was_tested' to > #t. > Runtime behavior could then differ based on the flag. Do you have some ideas > how to detect/deal with this? When you say "built binary" do you mean as an input to the "hypothetical test derivation", or the purported output of the test derivation which was supposed to be identical to the input but has been modified? If former, you'd need to ensure that the derivation has read-only access to the input (I believe/hope Guix already does this). If the latter, what's material is whether or not the original input can be recovered (with verification based on the comparison of some signature). To add more context, I am presently interested in situations where a "hypothetical test derivation" (say, A) passes its input (say, input_1 which was generated as the output of another derivation B) as part of its output (say, output_A), but adds additional metadata (say, metadata_A) in the process. I.e., let output_A = (input_1, metadata_A) I am also interested in being able to treat output_A as a substitute for input_1 given a function (say, f) which describes how to obtain input_1 from output_A and whose result matches the known signature of input_1. -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties.
Location of Guix manpages in foreign distribution
Hello all, When doing a binary installation via the [shell installer script] (with possible updates via "sudo -i guix pull"), where are the manpages installed? The info pages are linked and accessible from ~/.config/guix/current/share/info/ , but there's no corresponding ~/.config/guix/current/share/man . [shell installer script]: <https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh> -- Suhail
Re: Location of Guix manpages in foreign distribution
"Christina O'Donnell" writes: > If I'm not mistaken, ~/.config/guix/ is only for the environment that Guix > itself runs in. Yes, and the specific manuals (manpages instead of info) I was looking for were for the installed Guix version. It's unclear if the manpages for Guix were ever installed. It's possible they were, but subsequent updates through "sudo -i guix pull" didn't maintain them. Upon digging some more, I realized that "guix" doesn't have an output that only generates the manpages. So doing something like "guix install guix:manpages" was a no-go. Additionally, even if something like that had existed the version I would've gotten would have lagged behind the Guix installed on the system. Doing a "guix install guix" will get you access to the Guix manpages, but will also override the system Guix with a slightly older revision. The latter being undesirable for my needs. It turns out Guix, when built, generates the manpages via a tool called help2man which generates manpages from the --help and --version output. So a not-as-well-formatted alternative to something like "man guix-gc" is simply to invoke "guix gc --help". On Emacs, this can be made slightly more user-friendly via [noman]. [noman]: <https://github.com/andykuszyk/noman.el> -- Suhail
Re: Guix Days: Patch flow discussion
Felix Lechner via writes: > Another is that committers should commit what they think is right > rather than ask for revised patches. I could be mistaken, but I believe this does happen today at least some of the time. Is your position that 1. this never happens today and thus, should happen some times when warranted. Or that, 2. it happens far too rarely today, and should happen more often. Or that, 3. committers should never ask for revisions? -- Suhail
Re: Guix Days: Patch flow discussion
Steve George writes: > elsewhere in the thread someone mentions some tags we could use > consistently so maintainers can find patches that have been reviewed > easily. It seems on the [dev manual] we already have "reviewed-looks-good" documented. Thus, I'd like to propose the below *mutually exclusive* Debbugs tag set: - "not-yet-reviewed" :: automatically set for all submissions - "reviewed-needs-fix" :: set explicitly by the reviewer - "needs-another-review" :: automatically set if there's a revised patch, unless "not-yet-reviewed" (in which case no change) - "reviewed-looks-good" :: set explicitly by the reviewer In addition to the above, it might also help for there to be an additional tag of "might-not-need-review" (or simpler, "review-not-needed") which gets automatically set, provided we implement a way to label some changes (for some packages) as being "trivial enough that they're okay as long as build succeeds". On a related note, is it possible for a reviewer who isn't a committer to set debbugs tags? [dev manual]: <https://guix.gnu.org/en/manual/devel/en/html_node/Debbugs-Usertags.html> > It would be great to agree those - try them for a bit - and document > them in a 'howto' so that everyone uses the same process. In addition to documenting the tags in the "Debbugs Usertags" section of the manual, it would help for there to be a "howto" which focuses more on the transition between the tags (i.e., the contribution workflow). -- Suhail
Re: Guix Days: Patch flow discussion
Steve George writes: > The general opinion seemed to be, that it was better to fix small > issues and commit the change for new users, so they had the > satisfaction of their contribution making it into the repository. One > proposal was to do the 'fix', and to then reply back to the bug with a > diff - showing what was done. I see. Thank you for sharing. I believe being more didactic with "new users" would be good for the community. -- Suhail
Re: Building a Docker image for GitLab-CI
Ludovic Courtès writes: > Initially, I built an image with ‘guix system image -t docker …’ but > that doesn’t work because then the image’s “entry point” is shepherd, > but shepherd never returns. Did you try resetting the entrypoint in .gitlab-ci.yml using the image:entrypoint keyword? [1] [1]: <https://docs.gitlab.com/ee/ci/yaml/#imageentrypoint> -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties.
Re: Guix Days: Patch flow discussion
Clément Lassieur writes: >> It seems on the [dev manual] we already have "reviewed-looks-good" >> documented. Thus, I'd like to propose the below *mutually exclusive* >> Debbugs tag set: >> >> - "not-yet-reviewed" :: automatically set for all submissions >> - "reviewed-needs-fix" :: set explicitly by the reviewer >> - "needs-another-review" :: automatically set if there's a revised >> patch, unless "not-yet-reviewed" (in which case no change) >> - "reviewed-looks-good" :: set explicitly by the reviewer > > Would it makes sense to have a "does-not-apply" tag too? > > I believe that would help sorting old those old patches that don't apply > anymore. Agreed. A "does-not-apply" tag would be helpful. This tag would be explicitly applied, either by the QA mechanism or a reviewer. Assuming there aren't any objections to these tags, what are the next steps? If my understanding of Debbugs Usertags is correct it seems we can simply start using them? Though noting the above in the manual would be helpful. However, that still leaves open the issue of how the automated setting of tags is accomplished. Thoughts? -- Suhail
Re: You're invited to the first patch review session!
Tomas Volf <~@wolfsden.cz> writes: > On 2024-02-22 23:27:31 +, Steve George wrote: >> Hi >> >> We're going to run some online patch review sessions. The first one is on >> *Thursday, 7th March* and you can sign-up here: >> >> https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 >> >> ... >> >> Each session will be hour 1:30 and they are rotating through the week, so >> there should be plenty of opportunities to come along. We're using the Guix >> London's Meet-up and the sessions run on Jitsi. > > Will the Jitsi link be shared somewhere (here, irc, ...) for those of us who > are > not able to sign up on the page? Could the Jitsi link also be shared on the mailing list and/or noted on the libreplanet wiki? -- Suhail
Re: Is there any mechanism of Guix analog to, or trick in Guile to imitate Nix flakes?
rczb writes: > During evaluation, Nix will generate a JSON file named `flake.lock`, > which stores the exact revisions of the dependencies, just like the > output of `guix describe -f channels`. How would this be different from using, in Guix, say, a manifest file (using the specification syntax along with specification->package) with a channels.scm and then doing the build via guix time-machine? > The lock file is not mandatory. You can delete it whenever you want an > update, and the next invoking of `nix build` or something on the flake > directory will just generate a new one that conforms what's written in > `inputs` while being as up-to-date as possible to the upstream. How would this be different than updating the channels.scm file? -- Suhail
Re: Why are custom channels not available to guix repl?
Tomas Volf <~@wolfsden.cz> writes:
> Thank you very much, I can just stuff it into .guile for now.
For the benefit of others on the mailing list, something like the below
in .guile ensures that the customization runs only for guix repl:
#+begin_src scheme
(when (equal? (module-name (current-module)) '(guix-user))
;; `guix repl`-only init code
;; ensure custom channels are available in guix repl
(use-modules (gnu packages)) ;; <https://issues.guix.gnu.org/61343>
)
#+end_src
--
Suhail
Re: Packaging Proton Bridge: Progress Report #2
Marek Paśnikowski writes: > I would not be able to go this far without using random elements found > in other Go packages. It is unfortunate, that the build system > reference page is missing some key concepts in the Go process. > https://guix.gnu.org/manual/en/html_node/Build-Systems.html Please note that the snapshot version of the manual is available at <https://guix.gnu.org/manual/devel/en/html_node/Build-Systems.html> instead. As well, please consider submitting a patch to improve our existing documentation afterwards. -- Suhail
Re: How to create and maintain a personal Guix fork?
Tomas Volf <~@wolfsden.cz> writes: > Currently Guix uses *intersection* of keys from all parents. I would > like to suggest modifying the check to use an *union* of: > > 1. *Intersection* of keys from all parents (the current logic). > 2. Keys listed in $GUIX_AUTHENTICATE_EXTRA_KEYS. > > (and, if you are soft-forking Guix, you could also add your key to:) > > 3. Keys listed in new variable ((@ (guix git-authenticate) extra-keys). > > This, while much less elegant compared to your solution, seems much > easier to reason about. Agreed. I think it's important to not change 1. Adding an additional "allow list" is an effective approach to allow soft-forks without compromising security. > It still requires you to add the actual keys to keyring branch, but > that branch does not use authentication, so that should not be a > problem. +1 > It would *not* be an error to have a key listed in the environment > variable which does not have actual key material (on the keyring > branch), it would just be silently skipped. To be clear, when you say "silently skipped", it's as if said key had not been a part of 2 above? -- Suhail
Re: How to create and maintain a personal Guix fork?
Tomas Volf <~@wolfsden.cz> writes: > In other words, the additional whitelisted keys are added to the set > of valid keys for a commit only if the key material exists on the > keyring branch. Makes sense. -- Suhail
