<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Ole,<br>
<br>
<div class="moz-cite-prefix">On 04.11.23 11:05, Ole Streicher wrote:<br>
</div>
<blockquote type="cite"
cite="mid:abf8912c-ab1d-408a-9ba2-c708f718d1d2@debian.org">I am
aware of this. It is just a warning, nothing more. The Debian <br>
package adds a specific "ignore" to pytest, so that the warning
does not <br>
let the tests fail. This was discussed with upstream to avoid the
need <br>
of updating the package. <br>
</blockquote>
<br>
do you mean the leap-second-patch? <br>
<br>
<blockquote type="cite"
cite="mid:abf8912c-ab1d-408a-9ba2-c708f718d1d2@debian.org"> <br>
<blockquote type="cite">Actually to avoid this warning, there is
some auto update mechanism
<br>
that downloads new data periodically. So in order to work, parts
of
<br>
astropy depend on external data, which is the definition of
<br>
"contrib".
<br>
</blockquote>
<br>
The package works well without this update, so there is no "need"
to do this. And there is no "auto-update" mechanism in the binary
package. There is a mechanism to automatically create a new
upstream package with updated data every week. But this is how
upstream organizes their work, not what happens in the Debian
package. <br>
</blockquote>
<br>
I am afraid we are talking past each other. Am I right that you mean
the current version of astropy in Debian? As you mentioned that
astropy-iers-data is an upcoming dependency of python3-astropy, I
had a look at that new version. In this version <span
style="font-family:monospace"><span
style="color:#000000;background-color:#ffffff;">astropy/utils/iers/iers.py</span></span>
contains a config option "auto_download" and a function
"download_file()".<br>
So while the current version of astropy in main is fine, the
upcoming version might have a problem ...<br>
<br>
<blockquote type="cite"
cite="mid:abf8912c-ab1d-408a-9ba2-c708f718d1d2@debian.org"> <br>
The data *are* useful, at least if you don't need the maximum
accuracy wrt. IERS data.</blockquote>
<br>
Ok, that is your call as a maintainer, so please reupload the
package.<br>
<br>
<blockquote type="cite"
cite="mid:abf8912c-ab1d-408a-9ba2-c708f718d1d2@debian.org"><br>
If the updates are considered relevant for many use cases, the way
to update would be either backports, or (if the data in stable are
considered worthless now) with an "important" bug and a subsequent
upload to stable-updates; there is no need to deviate from this
standard Debian workflow. <br>
</blockquote>
<br>
But keep in mind that there is more than backports, which for
example is closed for the LTS versions.<br>
<br>
<blockquote type="cite"
cite="mid:abf8912c-ab1d-408a-9ba2-c708f718d1d2@debian.org">The
update_data.sh script is not even part of the binary package, and
it is also not called during build. So it cannot be used as an
argument. <br>
</blockquote>
<br>
*blush* you are right.<br>
<br>
<blockquote type="cite"
cite="mid:abf8912c-ab1d-408a-9ba2-c708f718d1d2@debian.org"> <br>
And, BTW, from the Debian policy 4.6.2, I don't see why dependency
on external data would make the package not suitable for main: <br>
<br>
* it does not require software outside of main to function (this
requirement is restricted to software, and data is not software),
<br>
</blockquote>
<br>
The GR 2004-3 amended the DFSG to be not only valid for software but
also for other content. So I think this part of the policy needs an
update.<br>
<br>
<blockquote type="cite"
cite="mid:abf8912c-ab1d-408a-9ba2-c708f718d1d2@debian.org"> <br>
A similar case is the "Gnome Maps" application, which is useless
without external map data, and which is in Debian main. <br>
</blockquote>
<br>
I don't use this package, but according to the description the main
purpose of it is to display maps. So if you create your own maps,
you can use the software without downloading external data. This
sounds different to a script whose sole purpose is to download
external data.<br>
<br>
Thorsten<br>
</body>
</html>