Hi,

In stable, the file utility (5.34) does not recognize byte-compiled
python3 binaries, even though they were generated by the default
python3 for that release (3.7.3). The version currently in unstable
(5.38) should work. Will you please provide a backport or a security
upload?

If the first point is not enough, Lintian depends on the
identification via 'file' to provide the tag
'source-contains-prebuilt-python-object'. Without it, Lintian cannot
test the tag on stable and would likely drop it.

Lintian has to stop using python2, which is being removed from Debian,
to generate test binaries and must instead rely on python3 even on
stable. Lintian cannot resort to python2 on stable alone, because
python3 stores byte-compiled binaries in a different location
(__pycache__).

Kind regards
Felix Lechner

Felix Lechner wrote...
But assuming you have good reason for your request, I could also use a
detail of what you're asking for:

(1) The buster version of file should be available in stretch-backports.

(2) The buster version of file should be available in stretch, i.e.
    the rather seldom case of bringing a completely new version to
    stable.

About (1), I am be happy to provide and extensively test such a
backport, but will not upload for non-technical reasons. If somebody is
willing to do this, and on a regular base, please drop me a line and
we'll arrange things.

About (2): This is a big change. Breakage is not likely but *if* it
happens the impact will be huge, so the anger created. Let me propose an
alternative approach, almost risk-free: Cherry-pick the applicable
commits from upstream and upload to stable-proposed-updates. With
backing from the lintian team, the release team will certainly not
object.

    Christoph

Hi Christoph,

The service lintian.d.o runs on stable (buster). Without a backport, I
don't think Debian's infrastructure can detect the tag
'source-contains-prebuilt-python-object' for any package in Debian
(for python3 byte compiled binaries). Many other services, such as
tracker.d.o, link to the results. We strive to offer the full set of
tags on the Lintian website.

Lintian could perhaps use custom magic files as described in the file
(1) manpage under --magic-file, but given the scope and purpose of
'file' I do not think that is reasonable.

For the lesser problem in the test suite, I could constrain the
affected test with 'Test-Depends: file (>= 1:5.38)' although it does
not solve the problem above.

I am hoping to see the version from bullseye (testing) in buster
(stable). Isn't stretch the previous stable release (old-stable)?

Please see (1).

Does this complexity still exist in view of my comment above?

Also, is this recommendation still applicable in view of my comment above?

Thank you for maintaining 'file'. Lintian could not run (or exist)
without your work!

Kind regards
Felix

Felix Lechner wrote...

Understood, that bit of information was missing.

Yeah, off-by-one.

So, rephrasing, what are you asking for?

(1) The Debian 11 ("bullseye") version of file should be available in
    the backports for Debian 10 ("buster").

(2) The Debian 11 ("bullseye") version of file should be available in
    the main archive of Debian 10 ("buster), i.e. the rather seldom
    case of bringing a completely new version to stable.

This is what I had in mind, and so the consequences are as written:

Yes.

So which option have you been reqesting. If really (2), what about my
suggestion?

    Christoph

PS: Please leave it to me when I consider the "moreinfo" requirement
    fulfilled. Since so far it ist not, and I don't think ping-pong is a
    nice game.

Hi Christoph,

A backport is sufficient. I tried to indicate that in the bug title,
but perhaps it was not clear.

In my original filing, I raised the possibility of a security upload
only because you provided them previously (and I saw no backports to
any release). I thought perhaps 'file' was in a class of system
utilities that only received security uploads. A backport is fine.

Lintian's updates also appear in backports and can comfortably depend
on 'file' there.

Please let me know if the technical reasoning needs further explanation.

Thank you for that comment. We use the same tag for Lintian bugs but
allow reporters to unset it. The associated ping-pong always bothered
me, too. Maybe Lintian should likewise ask reporters to leave the flag
untouched, although it is probably a battle I cannot win.

For a moment, I thought about reinstating the 'moreinfo' tag. That
should be your privilege.

Kind regards,
Felix Lechner

Felix Lechner wrote...
just want to understand what I do.

One more idea: After checking the upstream sources: The file package as
in Debian 10 ("buster") is supposed to detect "python 3.7 byte-compiled"
but the magic is plain broen. So I will cherry-pick the fix¹ for the
next stable point release anyway. Out of curiosity, was that sufficient
for your request as well, or will you need support for Python 3.8 as
well², now or at least before the Debian 11 ("bullseye") release?


About a backport:

The technical part shouldn't be a problem - creating backport-friendly
packages is one of my major objectives in packaging. I just need
someone who is willing to do the upload.

All the best,

    Christoph

¹ https://github.com/file/file/commit/ca3bb5a0b1545d7bfe5e38c8b7f0d8975e7ec731
² Which is not available yet but that will certainly change soon.

Hi Christoph,

Please do not worry. Thank you for maintaining such an important
package. Lintian could not exist without you.

There are advantages to having support for Python 3.8. For example,
lintian.d.o could issue tags related to those binaries. The Debian
community relies on that service, which runs on stable, for packages
uploaded to unstable and experimental (which are most likely to see
newer Python versions).

I do not have those privileges but know people who do.

Kind regards
Felix

Hi Christoph,

Given the passage of time, it is okay if Lintian detects Python3 files
only in unstable. Unfortunately, the file(1) program in unstable does
not detect files byte-compiled by the Python3 version in unstable,
which is 3.8. (file 1:5.38-5 detects only 3.7.) Would you please
provide a version that does? Thanks!

Retitling this bug accordingly.

The fix blocks the removal of Python2 from Lintian. Thanks!

Kind regards
Felix Lechner

[ re-visiting my backlog ]

Felix Lechner wrote...

Since this bug here was also about a backport: I have requested
according upload rights and await the response. Then this will
eventually happen as well.

    Christoph