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. > 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 do think it's odd that pdm would need poetry-core in its test suit. At least there is poetry_core-1.3.2-py3-none-any.whl which might mean that poetry-core is used for testing. Kind regards Andreas. [1] https://lists.debian.org/debian-devel/2013/09/msg00332.html -- http://fam-tille.de
