Re: onednn is marked for autoremoval from testing
Some additional hints:
libideep-dev wraps libdnnl-dev. And pytorch depends on libideep-dev.
Pytorch itself has unit tests for dnnl, and I use it as the second
sanity check for dnnl (onednn).
For now there are still some test issues unfixed for pytorch, so
the test result will be noisy. I should be able to fix it soon.
On 2021-11-25 08:53, Gard Spreemann wrote:
> Andreas Tille <andreas@an3as.eu> writes:
>
>> Am Wed, Nov 24, 2021 at 01:09:26PM +0100 schrieb Gard Spreemann:
>>> Ai ai, I see we now – post Andreas' upload – have an arm64-specific
>>> build failure because I overlooked the fact that an arm64-specific
>>> source file also needed patching. I've pushed 5efbe42a to salsa. It's
>>> *untested*, but based on a quick grep I *think* it's enough.
>>
>> Do you need any uploading help? I admit I have no idea how to test.
>> I would just build and upload if needed.
>
> Sorry, I should have been clearer: No, I could have uploaded, I just
> didn't wanna spam an upload that I'm "only" 95% sure would fix the
> issue. Especially since the buildds are busy churning through a bunch of
> transitions. So I decided to push the fix to Salsa, in the hope that
> someone else would have time to test it. If not, I'll give it a test on
> a porterbox this weekend (the test would just be "does it build with GCC
> 11 on an arm64 system now?"). Or, if you feel that the patch is likely
> to succeed (I think it is – all the other architectures built fine, and
> I *think* I found the only arm64-specific file affected), then feel free
> to upload :-)
>
> -- Gard
Reply to: