Le lun. 14 août 2023, 10:46, Richard Purdie < [email protected]> a écrit :
> On Mon, 2023-08-14 at 09:30 +0200, Frédéric Martinsons wrote: > > > > > > On Sun, 13 Aug 2023 at 17:05, Richard Purdie > > <[email protected]> wrote: > > > On Sun, 2023-08-13 at 17:00 +0200, Frédéric Martinsons wrote: > > > > On Sun, 13 Aug 2023 at 16:53, Richard Purdie > > > > <[email protected]> wrote: > > > > > > > > > > and a reproducibility failure: > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3355/steps/13/logs/stdio > > > > > > > > > > which leads to: > > > > > > > > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230813-z_b2j3ha/packages/diff-html/ > > > > > > > > > > > > > > > > > Argh, this makes me remember > > > > of https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090 > > > > Do you know if any of cargo based recipe is reproducible ? > > > > Should I add EXCLUDE_FROM_WORLD in cargo-c ? > > > > > > At some point we're going to have to dive in and fix the > > > reproducibility issues so I'm reluctant to take more patches with > > > that > > > set... > > > > > > > > > It will hardly be doable to correct the reproducibility of rust > > packages since rust/cargo > > itself have issues upstream. I take a look and there are lot of open > > issues > > cargo: > > https://github.com/rust-lang/cargo/issues?q=is%3Aissue+is%3Aopen+labe > > l%3AA-reproducibility+ > > rust: > > https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label > > %3AA-reproducibility > > I believe there is one problematic reference left which causes problems > for core rust. Fixing that issue would be the best place to start and > then we can work from there. > > We do already have a lot of good reproducibility pieces in the > toolchain so not every upstream bug will apply to us. > I'm afraid I do not see what is your point, can you elaborate please? What is the "problematic reference left which causes problems for core rust" you refer to? > > There was an RFC accepted back in may > > (https://github.com/rust-lang/rfcs/pull/3127) and implementation > > progress have a tracking issue in cargo > > (https://github.com/rust-lang/cargo/issues/12137) and in rust > > (https://github.com/rust-lang/rust/issues/111540). > > > > Don't know if it will fix our root issue > > (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875) but I don't > > see how to workaround all of that without this upstream work. > > > > For cargo-c specific issues, I'll try to make things better (the > > TMPDIR in debug symbols) but I'm wondering > > something, reproducibility is desirable for all generated artifacts > > or is it only for target ones ? I mean, > > the cargo-c is used in native so I'm wondering if making it native > > only would be acceptable ? > > That would certainly avoid this issue. It would also make on target > testing of the functionality not possible. > The test I added is on the final binary generated (rust-c-lib-examble-bin), not cargo-c itself. So the target test would still be valid. I tested a release build with a custom patch that strips debuginfo (strip="debug info" in Cargo.toml) and I do not have build path leaking in debug symbol anymore. I'll dig this up more and see if I can upstream that. But the reproducible issue remain despite that. > Cheers, > > Richard > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185928): https://lists.openembedded.org/g/openembedded-core/message/185928 Mute This Topic: https://lists.openembedded.org/mt/100715215/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
