Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 15, 2023 1:51:54 PM UTC, Jeroen Dekkers wrote: >On Tue, 15 Aug 2023 15:08:11 +0200, >Scott Kitterman wrote: >> >> On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: >> > Hi Scott, >> > >> > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: >> > >> > > 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. > >They are zip files containing python source code. It is possible to include >compiled C extensions in wheels, but I checked and these wheels are all pure >python, so no binary blobs are included. In Debian terms, it's not the preferred form for modification, so it's not source. In this regard DFSG goes farther than some software licenses. Scott K
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Tue, 15 Aug 2023 15:08:11 +0200, Scott Kitterman wrote: > > On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: > > Hi Scott, > > > > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: > > > > > 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. They are zip files containing python source code. It is possible to include compiled C extensions in wheels, but I checked and these wheels are all pure python, so no binary blobs are included. Kind regards, Jeroen Dekkers
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Mon, Aug 14, 2023 at 02:06:42PM + 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 signature.asc Description: This is a digitally signed message part.
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
Hi Scott, Am Mon, Aug 14, 2023 at 02:06:42PM + 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
