Re: python-trezor: assistance with disabling or modifying a build test that requires network access
On Friday, September 27, 2024 4:48:58 PM MST Soren Stoutner wrote: > 1. Just exclude this test from autopkgtests and go on with my life (I assume > autopkgtest-pkg-pybuild has an easy way to do this). There are 111 other > tests that run successfully, this is a test that upstream should run with > every release, and it is testing the type of thing that is unlikely to work > for upstream but end up broken in Debian. Is there an easy way to exclude one test using autopkgtest-pkg-pybuild? -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: python-trezor: assistance with disabling or modifying a build test that requires network access
On Mon, Sep 30, 2024 at 08:50:27AM -0700, Soren Stoutner wrote: > On Friday, September 27, 2024 4:48:58 PM MST Soren Stoutner wrote: > > 1. Just exclude this test from autopkgtests and go on with my life (I > assume > > autopkgtest-pkg-pybuild has an easy way to do this). There are 111 other > > tests that run successfully, this is a test that upstream should run with > > every release, and it is testing the type of thing that is unlikely to work > > for upstream but end up broken in Debian. > > Is there an easy way to exclude one test using autopkgtest-pkg-pybuild? Yes, exclude it from the build-time tests. Why does it succeed there? -- WBR, wRAR signature.asc Description: PGP signature
Re: python-trezor: assistance with disabling or modifying a build test that requires network access
On Monday, September 30, 2024 8:55:38 AM MST Andrey Rakhmatullin wrote: > On Mon, Sep 30, 2024 at 08:50:27AM -0700, Soren Stoutner wrote: > > On Friday, September 27, 2024 4:48:58 PM MST Soren Stoutner wrote: > > > 1. Just exclude this test from autopkgtests and go on with my life (I > > > > assume > > > > > autopkgtest-pkg-pybuild has an easy way to do this). There are 111 other > > > tests that run successfully, this is a test that upstream should run with > > > every release, and it is testing the type of thing that is unlikely to > > > work > > > for upstream but end up broken in Debian. > > > > Is there an easy way to exclude one test using autopkgtest-pkg-pybuild? > > Yes, exclude it from the build-time tests. > Why does it succeed there? It turns out I had some misconfiguration that caused the testing behavior to act different than what I thought I had told it to do. It is now fixed. Thank you for prompting me to look again more closely. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: pytorch: FTBFS on ppc64el
Hi, On 2024-09-27 23:00, Aditi Mishra wrote: > Version: 2.1.2+dfsg-4 > > pytorch FTBFS on ppc64el: Open bug > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071655 > > This regression is still seeing more than a month. Can you provide any detail > about this? 2.4.1 was just recently uploaded, let's see if that fixes the issue. First, it needs to go through NEW though. Best, Christian
Re: python devs are planning to stop signing with gpg
Salvo Tomaselli writes: > On that thread they say that it is possible to verify signatures offline. But > the checker seems to need a number of dependencies. "TL;DR: Starting with the next release, --offline will also mean that sigstore-python performs no automatic trust root updates." Maybe I am wrong here, maybe this is similar to GPG, but regardless it made me a bit nervous. -- Brian May @ Debian
Re: python devs are planning to stop signing with gpg
Salvo Tomaselli writes: > I just saw this conversation > > https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058 > > Perhaps someone more expert than me at not making flamewars would like to > intervene? In what wee is this going to affect Debian? Do we actually verify GPG signatures for upstream sources? The replacement sigstore - verification is online only (at least as per comments in thread). Do we have a requirement to check signatures offline? Is there any other reason I am not aware of why sigstore is a bad solution? Somebody needs to post the answers to questions like these to the discussion thread. -- Brian May @ Debian
