guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#33066] [PATCHv3] gnu: rust: workaround rust 1.25-27 reproducibility


From: Nikolai Merinov
Subject: [bug#33066] [PATCHv3] gnu: rust: workaround rust 1.25-27 reproducibility issues
Date: Sun, 21 Oct 2018 12:28:04 +0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi,

Finally whole rust build chain 1.23-1.29 was built on my machine with next 
commands:
> guix pull --url=/path/to/guix-f9a8fce10/with/patches 
> --commit=<commit-with-patches>
> for v in 1.2{3..9}; do echo guix build -K --rounds=2 address@hidden || break 
> ; done
and all builds were reproducible.

Regards,
Nikolai

Nikolai Merinov <address@hidden> writes:

> Hi,
>
> Sorry, ignore my previous mail. There was wrong patch
> export. Re-attached patches.
>
>
>
>
> Regards,
> Nikolai
>
> Nikolai Merinov <address@hidden> writes:
>
>> Hi Danny,
>>
>> I fixed patches according to your comments. Also I updated rust 1.29.1
>> to 1.29.2 and fixed test issue in 1.27: as I mentioned before I tested
>> reproducibility of each package previously only in private my private
>> repo where I disabled `check` phase for 1.25 and 1.27. I have pretty
>> slow machine, but currently I already checked reproducibility with
>> suggested patches for 1.23-1.26 releases. 1.27-1.29 in progress.
>>
>> Both updated patches attached.
>>
>> Danny Milosavljevic <address@hidden> writes:
>>
>>> Hi Nikolai,
>>>
>>> On Tue, 16 Oct 2018 02:32:11 +0500
>>> Nikolai Merinov <address@hidden> wrote:
>>>
>>>> * 
>>>> gnu/packages/patches/rust-mdbook-Support-reproducible-builds-by-forcing-window.search.patch:
>>>
>>> Nitpick: No big "S" (file names are easier to find if they are all lower 
>>> case).
>>>
>> Fixed.
>>
>>>> patch that make "searchindex.js" reproducible in rust 1.27 and newer.
>>>
>>> "New file".
>> Fixed.
>>
>>>
>>>> * gnu/local.mk (dist_patch_DATA): Add new patch file.
>>>> * gnu/packages/rust.scm (rust-1.19): Use system libssh2 library
>>>
>>> Hmm, I'm not sure about doing this in the same commit.
>>> Is it also related to reproducibility?
>>
>> Looks like it should not, but still I started investigation with
>> non-reproducible "libssh2" and "libgit2" rust libraries I made libssh2
>> related changes at very beginning and never tested wihtout it. I not
>> sure that it's good idea to remove it now.
>>
>>>
>>>> during cargo build. Note: libgit2 still builded as part of cargo build,
>>>> because cargo tests assume specific libgit2 minor release.
>>>
>>> What does this mean?  Does it mean "bundled"?
>> Yes. Rust used bundled sources for "libgit2-sys" rust library (used by 
>> cargo).
>>
>>>
>>>> (rust-1.23): inherit native-inputs from previous package.
>>>
>>> Ok.
>>>
>>>> (rust-1.25): switch back to llvm 3.9.1 as workaround for
>>>> https://github.com/rust-lang/rust/issues/50556 issue.
>>>
>>> Please add the reasoning as a comment inside the source code instead.
>> Added comment for rust-1.25 package.
>>
>>>
>>>> (rust-1.27): apply patch to make "searchindex.js" files reproducible.
>>>
>>> Maybe add "[source]".
>> I repharase this comment and added source URL to patch file itself.
>>
>>>
>>>> -             (add-after 'configure 'enable-codegen-tests
>>>> -               (lambda _
>>>> -                 (substitute* "config.toml"
>>>> -                   (("codegen-tests = false") ""))
>>>> -                 #t))
>>>
>>> I think I had reproducibility problems when enabling codegen tests and
>>> parallel tests.  Is that not the case anymore?
>> Neither me nor Joe Hillenbrand in
>> https://lists.gnu.org/archive/html/guix-devel/2018-10/msg00292.html got
>> reproducibility issues with this tests.
>>>
>>>>               ;; FIXME: Re-enable this test if it's indeed supposed to 
>>>> work.
>>>>               ;; See <https://github.com/rust-lang/rust/issues/54178>.
>>>
>>> Note to myself: I think the issue comments indicate that the newer gdb 
>>> output
>>> is better - so we should create a patch similar to
>>> rust-1.25-accept-more-detailed-gdb-lines.patch to accept the newer output.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]