Bug 1737967

1) dblatex is written in Python 2, the code is around 19k lines in 100 files.


2) Upstream had its last code commit in 2017, I don't see any plans going forward.


2/3) I might a try a straight 2to3 port but don't see much sense in investing a lot of effort into converting a dead project. (I'm doing this investment for another project already.) In fact, the dependencies are the only reason to keep dblatex alive at all.

3) Since dblatex is about text processing the string type change may make this conversion non-trivial.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

The current plan is to remove packages with dependency on Python 2 from Fedora 32 in the middle of November 2019. If you want to keep your package in Fedora after that date and you cannot port it to Python 3 yet, you need to request a FESCo exception for the package and all its Python 2 dependencies (even transitive) [1]. If you don't want to maintain it anymore, please orphan the package.

If you're considering filing the exception request, let us know. We can help (for example, we can help find all the dependencies).

[1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions

While I don't have any personal interest in dblatex, the packagers of 14 packages which build-require it may, or the packagers of 153 packages which build-require asciidoc which build-requires dblatex.

But I ran dnf repoquery on F30, I'm sure everyone on F31 is off py2-based packages by November...

In fact, often dblatex is the "cheap" (simple) way to get PDF from asciidoc via docbook which is not cheap (compute-wise) at all. But typical upstreams change their doc tool chain only reliantly, because all these tool chains have their individual issues which you work around once to be done with it.

But I'll keep you posted on the 2to3 progress.

So, while I managed to port a different package to py3, I have to give up on dblatex.

To a large part, dblatex converts back and forth between different encodings when it parses TeX files and its support files. Due to the missing separation between strings and bytes in py2 dblatex can handle "strings with pending decoding" on the same footer as "decoded ascii" etc, which is not possible in py3. I've tried hard to get a clear picture on what are real strings and what bytes in the codebase and got some things to work, but not a fully working dblatex.

So I will let dblatex go its way in F32/rawhide. As I understand, this will be taken care of automatically in November.

If you want to orphan it, do it rather sooner than later so somebody interested may take it.

Update: Life signs on dblatex, various contributors for a port (more details on fedora-devel)

So for now please no automatic orphaning/killing until we see whether these porting attempts succeed. Should be clearer within a week.

FYI I've rebundled python-which in dblatex and retired python-which.

(In reply to Gwyn Ciesla from comment #9)
> FYI I've rebundled python-which in dblatex and retired python-which.

Have you?

You removed the patch which made dblatex use the external which. You removed the line which removes all bundled libs, which is more than just which.

Now, since we're discussing dblatex's future on fedora-devel and here and on dblatex-devel and are no dblatex maintainer I ask you: Is a pull request too much to ask for before pushing straight to master?

The solution for dlatex-py3 will be different, obviously.

Apologies. I was under the impression the disable-debian patch kept that piece inactive, and that the dbtexmf contents were unused.

Would you like PR removing the rest but leaving only which?

(In reply to Gwyn Ciesla from comment #11)
> Apologies. I was under the impression the disable-debian patch kept that
> piece inactive, and that the dbtexmf contents were unused.
> 
> Would you like PR removing the rest but leaving only which?

No, it's just that I'm somewhat under pressure getting everyone coordinated, the existing patches out in an appropriate form (dblatex just had a new release) and a package out for us to get tested against depending packages. An unexpected push to master is a bit of a trigger ;) 

Which will be replaced differently (shutil.which) so that nothing needs to be bundled.

There has been a thread on the devel mailing list:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KTBDW4M2K5NY72EFOKEWBE6XF6RCJEUX/#HJN76PLJRRRVMJPOCIV56WYOBFJ2ECRQ

I wonder whether we should do the switch in rawhide now?

(In reply to Miro Hrončok from comment #13)
> There has been a thread on the devel mailing list:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> thread/KTBDW4M2K5NY72EFOKEWBE6XF6RCJEUX/#HJN76PLJRRRVMJPOCIV56WYOBFJ2ECRQ
> 
> I wonder whether we should do the switch in rawhide now?

I'm fine with using rawhide as a test-bed. That's what it's for.

I've been holding back because discussions on the upstream list were somewhat slow (including mine), the last from a week ago read:

> Sorry too for the delay. Thank you very much for the patches that fix
> most of the things! Yet, I have been struggling with some cases that
> don't work, but I'm confident that I'm close to the end. Encoding,
> decoding, bytes and strings are more painfull with python 3. I guess
> there's a better method to address these features with the new
> language but I'll look for a more consistent solution later...

So while the end appeared to be near it hasn't happened yet. I'll push to rawhide what I have.

Thanks. We can always revert if it proves to be really broken.

bodhi submitted dblatex-0.3.11-2.fc32 to stable
        https://bodhi.fedoraproject.org/updates/FEDORA-2019-4dd6808ecd