zjn8sh50nn55i2qp9h3hbzj-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'
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 unt
osts/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 evidenc
(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 definiti
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 underst
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 it
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…
>
>
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?
>
> Inste
"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
ig/guix/current/share/man .
[shell installer script]:
<https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh>
--
Suhail
uot;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
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
n/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
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
? [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
p
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
sions 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
nerate 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
(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
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
t; 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
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
22 matches
Mail list logo
