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

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: