app-text/sigil: version bump to 0.9.13

[arthurzam]

Please note that the package needs a new maintainer, based on what this page shows, and I will gladly take over as a Proxy Maintainer - but I don't know the procedures.

[gentoo-bot]

Copyright policy change

Please note that on 2018-09-15 Trustees have approved new Gentoo copyright policy. All contributions made to Gentoo need to follow this policy. If you include the Signed-off-by line in your commit message, you indicate that you have read the policy and agree to its terms. For more detailed explanation, please see the new Gentoo copyright policy explained article.

Pull Request assignment

Submitter: @arthurzam
Areas affected: ebuilds
Packages affected: app-text/sigil

app-text/sigil: @gentoo/proxy-maint (maintainer needed)

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[juippis]

I will gladly take over as a Proxy Maintainer - but I don't know the procedures.

Edit the metadata.xml file, adding yourself and the proxy-maint project there. See example from already proxy-maintained packages :)

You need a bugzilla account with that email you add to the metadata.

[arthurzam]

@juippis Is it better to force push or create a new commit in this pull request?

[juippis]

If you have the knowledge to rebase and force-push, do that please.

So fix the ebuild, make a new commit, rebase and squash and that commit into your first commit so there is only one commit with version bump, then make a new commit updating metadata.xml file.
So in the end there are 2 commits, one with version bump, one with metadata.xml update.

[arthurzam]

@juippis Big thank you for your help!

[juippis]

Sorry I missed few things in the initial round, but overall it's looking good!

EDIT: The error above seems to be from dev-python/cssutils not being updated for python3.7 yet. You can update this ebuild to be compatible with python3.6 max, or investigate, test and update cssutils to support python3.7 before this gets merged. You can put the python3.7 bump to this PR, or make a new PR for that. You can also wait for this to get merged with python3.6, then make a new PR to update cssutils, and after that is merged, make a new PR to add python3.7 to this package. That's probably the best way.

[arthurzam]

Sorry I missed few things in the initial round, but overall it's looking good!

EDIT: The error above seems to be from dev-python/cssutils not being updated for python3.7 yet. You can update this ebuild to be compatible with python3.6 max, or investigate, test and update cssutils to support python3.7 before this gets merged. You can put the python3.7 bump to this PR, or make a new PR for that. You can also wait for this to get merged with python3.6, then make a new PR to update cssutils, and after that is merged, make a new PR to add python3.7 to this package. That's probably the best way.

Thank for your comments.
I put a bug in bugzilla. Is it better to put a pull request?
About the version check, after looking in dev-util/electron ebuild, I found the ver_test from EAPI 7, which I think is better.

[juippis]

I put a bug in bugzilla. Is it better to put a pull request?

It's good, the python project should be pretty active both in bugzilla and Github. Whatever is best for you, as long as you can track the progress. EDIT: Pull request might speed it up a little bit, but as said, python project should be pretty active with these things.

About the version check, after looking in dev-util/electron ebuild, I found the ver_test from EAPI 7, which I think is better.

Yes it should work too. You can choose the implementation yourself, whatever you find easier and more to your liking. Bear in mind, using ver_test still requires you to inherit toolchain-funcs for gcc-version.

[arthurzam]

The problem with dev-python/cssutils python3.7 support was fixed.

Upstream version was updated to 0.9.13 - updated this PR.
Added missing call for xdg_desktop_database_update from xdg-utils.eclass
Moved dev-qt/linguist-tools:5 into BDEPEND, as done in other Qt projects.
Changed SRC_URI to use .tar.gz - removed app-arch/unzip dependency.

[arthurzam]

@gentoo/proxy-maint Could someone check and maybe merge it?

[arthurzam]

• Removed bundled in package mathjax (now depends on dev-libs/mathjax)
• Removed bundled hunspell dictionaries
• Added readme.gentoo-r1
• Changed the install patch to use GNUInstallDirs. Spoke with maintainer about including the patch upstream, they are against because they are afraid to break other distribution's packages. But they said they are planning to integrate a way to select at least lib -> lib64 (which is what we need for this package).

Another question:
The package includes some python modules for sigil. How (and if) should I python_optimize (I saw it in some other ebuilds but haven't understood how)?

[mgorny]

You can find eclass documentation either inside the files, in eclass-manpages package or in devmanual.

[mgorny]

Oh, and python eclasses are also documented in detail on wiki, in Project:Python.

[arthurzam]

@mgorny I hope I have done it right (no that sure about python_optimize - mainly about the passed argument).
Also fixed license (internal gumbo is licensed under Apache-2). Is it correct set in ebuild?

[arthurzam]

@mgorny Done.
Never thought about the download name and extracted name. Everyday you learn something new and interesting :)

[mgorny]

Thanks. Please give me some time to build qtwebkit.

[mgorny]

You seem to be missing some deps still:

Traceback (most recent call last):

  File "/usr/share/sigil/python3lib/xmlprocessor.py", line 6, in <module>
    from sigil_bs4.builder._lxml import LXMLTreeBuilderForXML

  File "/usr/share/sigil/plugin_launchers/python/sigil_bs4/builder/_lxml.py", line 26, in <module>
    from lxml import etree

ImportError: No module named 'lxml'

[arthurzam]

You seem to be missing some deps still:

Traceback (most recent call last):

  File "/usr/share/sigil/python3lib/xmlprocessor.py", line 6, in <module>
    from sigil_bs4.builder._lxml import LXMLTreeBuilderForXML

  File "/usr/share/sigil/plugin_launchers/python/sigil_bs4/builder/_lxml.py", line 26, in <module>
    from lxml import etree

ImportError: No module named 'lxml'

Interesting, as dev-python/lxml[${PYTHON_USEDEP}] is a dependency.

[mgorny]

Ok, there's something really wrong going on here:

 0x0000000000000001 (NEEDED)             Shared library: [libpython3.4m.so.1.0]

So it's ignoring PYTHON_SINGLE_TARGET completely.

[arthurzam]

@mgorny Well, that is really weird as I haven't touched anything about the python usage. I guess it came from the previous ebuilds. I think I know where to check and fix it. Will take some time.

[arthurzam]

@mgorny I hope I fixed (but I ask you to recheck it).
I added a call to python_fix_shebang.
Somehow until now the check in cmake worked with some python wrapper magic (well I have no idea how but it found somehow the correct version). But to be sure I now explicitly pass as an argument the correct python executable.

[mgorny]

There's still something wrong with it:

-- Found PythonInterp: /usr/bin/python3.7 (found suitable version "3.7.3", minimum required is "3.4") 
-- Found PythonLibs: /usr/lib64/libpython3.4m.so (found suitable version "3.4.10", minimum required is "3.4") 

app-text:sigil-0.9.13:20190429-132026.log

I don't see anything useful in CMakeOutput.txt.

[arthurzam]

@mgorny First of all, sorry for all this trouble. I sincerely am apologizing for wasting your time.
I found the culprit! In this line, if python3.4 is installed it wins the previous configuration of using PYTHON_EXECUTABLE.
Haven't found this bug previously as I don't have installed python3.4 and I tries various changes with 3.5 and 3.6 (main system uses 3.7). I managed to reproduce your report by installing python3.4.
Fixed with passing all needed python configurations.
I sorry again to ask it, but please check it again.

[mgorny]

No need to apologize. Cool you found the culprit. FWICS it built fine this time and runs, so I'll merge it. Thanks!

[mgorny]

For the future, I'd suggest:

set directory=~/tmp,/var/tmp

This will stop vim from making .swp files in current directory, and you from committing them ;-).

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2019-04-29 14:42 UTC
Newest commit scanned: 6d4dc71
Status: ✅ good

No issues found

[eli-schwartz]

Changed the install patch to use GNUInstallDirs. Spoke with maintainer about including the patch upstream, they are against because they are afraid to break other distribution's packages. But they said they are planning to integrate a way to select at least lib -> lib64 (which is what we need for this package).

(This is now merged to master, with a suitable changelog message.)

BTW a bunch of these modules have never been a hard dep (in my Arch packaging I use an optional dependency for many of the python modules) but cssutils has been essentially dropped in favor of css-parser. I've confirmed with Doug and Kevin that for my distro packaging purposes it's fine to rm -r src/Resource_Files/plugin_launchers/python/css_parser/ and depend on the python-css-parser package instead -- you may want to do the same.