On Mon, 2023-08-14 at 09:30 +0200, Frédéric Martinsons wrote: > > > On Sun, 13 Aug 2023 at 17:05, Richard Purdie > <richard.pur...@linuxfoundation.org> 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 > > > <richard.pur...@linuxfoundation.org> 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. > 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185925): https://lists.openembedded.org/g/openembedded-core/message/185925 Mute This Topic: https://lists.openembedded.org/mt/100715215/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
