I'm a co-maintainer for the python-sphinx package. There's a bug [1] I'd
like to address, but I'd like some input on what I was thinking. There was
some discussion about this on FPC ticket [2], but nothing workable really
came out of that. I also attempted to get input [3] from the Sphinx
community, but didn't receive a response.
For background, python-sphinx is available for both Python2 and Python3. It
is primarily a library, but provides four commands for convenience:
sphinx-build, sphinx-quickstart, sphinx-apidoc, sphinx-autogen. Here's an
example of how these commands are currently made available to the user:
/usr/bin/sphinx-build -> sphinx-build-2
/usr/bin/sphinx-build-2 -> sphinx-build-2.7
/usr/bin/sphinx-build-2.7 (#!/usr/bin/python2)
/usr/bin/sphinx-build-3 -> sphinx-build-3.4
/usr/bin/sphinx-build-3.4 (#!/usr/bin/python3)
It should be noted, all of these commands are just used to call entry
points and don't have any of their own logic. Here are their equivalents:
sphinx-build python -m sphinx
sphinx-quickstart python -m sphinx.quickstart
sphinx-apidoc python -m sphinx.apidoc
sphinx-autogen python -m sphinx.ext.autosummary.generate
Sphinx itself isn't Python version specific and maintains compatibility
regardless of what Python version you are using or if you switch back and
forth. Potentially there are some Sphinx extensions that are Python version
dependent, but I am not aware of any.
Use cases for Sphinx are all over the place. For example, I rarely use the
commands and call sphinx through setuptools 99% of the time. Other people
use the commands exclusively, and still others use the makefile created by
sphinx-quickstart as their primary way to call it.
It's this last one is where we are seeing the biggest problem and is
described in the bug. Essentially, sphinx-quickstart-3 is used to create a
makefile which lists sphinx-build as the build command. But sphinx-build is
currently linked to the python2 version, which may not be expected, and
won't necessarily be installed.
It was suggested the makefile should be changed so the Python version that
was used for sphinx-quickstart should be used for sphinx-build.
Unfortunately, that would make the file less portable.
I have two possible fixes:
The first would be to decouple the commands from the libraries. Since the
package name sphinx is already taken by the search engine, something like
python-sphinx-bin may be appropriate. Once separated, the command would
default to python3 since the packaging guidelines say it Python 3 versions
should be preferred when equivalent.
The second option would be to retain the multiple versions, but to manage
the links with alternatives so the unversioned commands will default to
whatever version is installed and again, Python 3 would be preferred if
both were installed.
Does anyone have any preferences, thoughts or alternative approaches?
Avram
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1321413
[2] https://fedorahosted.org/fpc/ticket/612
[3] https://groups.google.com/forum/#!topic/sphinx-dev/vdFeOEj4EKg
I just pushed the button to request a new package in pkgdb. I have
gotten into the habit of ignoring the namespace dropdown at the
bottom, since it has only had one option. But I happened to glance at
it, and I'm glad I did, because it said "docker". There are two
choices now, "docker" and "rpms". Is it really a good idea for the
default to be "docker"?
Also, has something been sent to the list about the difference between
the 2 namespaces? If so, I missed it.
--
Jerry James
http://www.jamezone.org/
Hi,
I recently packaged and pushed an update for fedmsg-meta-fedora-infrastructure
to bodhi and exactly 40 secs[1] later I got a +1 to the update. I am sure that
testing a package surely takes more than 40 secs. This makes me really curious
that are the packages really being tested before giving out the karma.
After going through messages in datagrepper[2][3], I found that few people are
giving out karma in one go (4-5 packages under a minute). If these packages
really are not-tested and the karma are given out randomly then I am sure that
this sure going to affect the release, infrastructure and our users.
Does anybody know what is going on?
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2016-f2331b2c8b
[2] https://apps.fedoraproject.org/datagrepper/raw?user=buvaneshkumar
[3] https://apps.fedoraproject.org/datagrepper/raw?user=prakashmishra1598
--
Sayan Chowdhury <https://sayanchowdhury.dgplug.org/>
Senior Software Engineer, Fedora Engineering - Emerging Platform
GPG Fingerprint : 0F16 E841 E517 225C 7D13 AB3C B023 9931 9CD0 5C8B
Proud to work at The Open Organization!
Attached is a little script I use when doing a mock build with gcc or
g++, to see what warnings the compiler emitted. I usually ignore
-Wunused* warnings, as those aren't usually dangerous, but I pay
attention to -Wstrict-aliasing, for example. This is a way for me to
quickly see if any "dangerous" warnings were emitted, and has led to
several patches being sent to upstream projects. Sent here in the
hope that it will help other packagers. Regards,
--
Jerry James
http://www.jamezone.org/
Hello,
Liveusb creator can't start and crash with this output in the terminal.
file:///usr/lib64/qt5/qml/QtQuick/Controls/ComboBox.qml:560:5: QML Menu: Binding loop detected for property "__selectedIndex"
Segmentation fault (core dumped)
I can't test it again but I think it was working with Nouveau and not with Nvidia proprietary drivers that I use.
https://bugzilla.redhat.com/show_bug.cgi?id=1356677
Thanks !