On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Mon, Aug 14, 2023 at 02:06:42PM +0000 schrieb Scott Kitterman: > > >Before I upload I'd like to ask for reviewing this patch and opinions > > >about the test suite errors. While these possibly occure in previous > > >versions (which I did not tested) we might consider ignoring just the > > >failing tests. I need to admit that I did not went through the list of > > >single failures - may be there is a chance of easy fixes for some of > > >them. I simply wanted to discuss the reintroduction of the artifacts > > >and my patch first. > > > > With the exception of future_fstrings > > I think there is also the souce for demo included. > > > those are all binary without source. That's a problem. > > Given your role as ftpmaster you definitely have more experience than I > in this field. I personally was thinking more in the line of binary > data we can not avoid in some cases. This is a bit in the line with > Rdata decision[1] where those binary data files are documented in > debian/README.source. > > My point is just: If we remove those data files (which are IMHO harmless > since these are not executd but used as input in tests - please correct > me if I'm wrong) we can not test the package. Removing the files > prevents testing and thus we can not know whether the package we deliver > will work. I've actually shown that not all tests are working but > stopped investigating this further. Even if they are used as data (I didn't check), they are, in fact, binary blobs of code by our definition and that requires the corresponding source. > > It's probably okay if you add the corresponding source somewhere in the > > package. > We probably have some source packages inside Debian - may be in > different versions. I need to admit that I intended to do a "quick fix > of a simple bug that affects some Debian Med packages" but realised that > I'm possibly opening a can of worms. The simplest solution to fulfill > my needs would be probably to revert my change to run the tests and be > done. However, I'm not sure whetherr this is in the interest of the > users of this package. I'm absolutely not able time-wise to povide > sources and reconstruct all those *.whl files *and* in addition track > down the test suite errors. This is a team package and if the team > decides we should go without testing I can do an according upload. > However, my prefered path would to document the issue of some binary > data properly an test what upstream expects to be tested. i think this is definitely more complicated than you want to take on casually. I don't think it's required to actually rebuild the wheels. If you provide the source, the DFSG is happy. You have to be able to rebuild it, but you aren't required to do it. It might, however, be simpler in the long run to just depend on those packages and build wheels from those (a Debian binary package has enough in it generally to build a wheel from it). I agree it'd be better in the long run to run the tests, but that may be more than you want to take on right now. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.