[data] released: numpy, matplotlib

[sYnfo]

Fixes #6

Both of these have provided Python 3 subpackages for a while now, I wonder why the py3query script didn't find them?

[rkuska]

Looking at the code it probably calculates the python3 readiness by the count of rpms produced. (len(python2rpms) == len(python3rpms)) <=> python3ready.

And rpms listed for numpy from the fedora.json:

      "numpy-1:1.10.0-1.fc24",
      "numpy-1:1.10.0-1.fc24",
      "numpy-f2py-1:1.10.0-1.fc24",
      "python3-numpy-1:1.10.0-1.fc24",
      "python3-numpy-f2py-1:1.10.0-1.fc24"

This is just wild guess and I am probably completely wrong :-)

[sYnfo]

srpm_names = {}
by_srpm_name = collections.defaultdict(set)
for pkg in progressbar(python_versions.keys(), 'Getting SRPMs'):
    srpm_name = hawkey.split_nevra(pkg.sourcerpm).name
    srpm_names[pkg] = srpm_name
    by_srpm_name[srpm_name].add(pkg)

It looks like the pkg that gets added to by_srpm_name is sometimes such that it has the same name, epoch, version, release, etc. (everything that format_rpm_name cares about) as one that's already there, but differs in something else [0], which then leads to the duplication that @rkuska pointed out above and the relevant srpm is then sometimes wrongly identified as "idle". I think.

[0] I'm having a hard time debugging the script without access to print and pdb

Modifying the is_ported function as such:

def is_ported(pkgs, python_versions):
    num2 = len(set([p.name for p in pkgs if python_versions[p] == {2}]))
    num3 = len(set([p.name for p in pkgs if python_versions[p] == {3}]))
    return num3 >= num2

leads to 11 additional packages marked as "released", all of which actually seem to have python3 support in rawhide.

[encukou]

Sorry! I read the issue, and then fixed offline without seeing this pull request. Now each unique RPM name is counted only once.

[encukou]

numpy

Picked up as released by the script now

python-matplotlib

The Python 3 version does not provide equivalents for:

• python-matplotlib-gtk
• python-matplotlib-wx

If these subpackages are to be dropped, it needs to be recorded manually
(with an appropriate note)

cantor

$ dnf repoquery --enablerepo rawhide --repoid rawhide --requires cantor | grep py
libpython2.7.so.1.0()(64bit)
libpython3.4m.so.1.0()(64bit)

Doesn't look fully ported.

dbus-python

Picked up as released by the script now

dnf-plugin-spacewalk

$ dnf repoquery --enablerepo rawhide --repoid rawhide --requires dnf-plugin-spacewalk | grep py
python(abi) = 2.7
python(abi) = 3.4

Doesn't look fully ported.

libcap-ng-python

$ dnf repoquery --enablerepo rawhide --repoid rawhide --requires  libcap-ng-python | grep py
python(abi) = 2.7
python(abi) = 3.4

The python2 version requires python3. The script thinks this is a badly ported
python3 package (like cantor).
If this is the intended state, it needs to be recorded manually,
with an appropriate note.

libtdb

Picked up as released by the script now

pitivi

$ dnf repoquery --enablerepo rawhide --repoid rawhide --requires  pitivi | grep py
python-setuptools
pygobject3
python3-numpy
pyxdg
python3-canberra
python(abi) = 3.4
pycairo >= 1.0.0
pygtk2 >= 2.17.0
python3-gstreamer1 >= 1.4.0

Still depends on pygtk2

unbound

$ dnf repoquery --enablerepo rawhide --repoid rawhide --requires unbound | grep py
libpython2.7.so.1.0()(64bit)
libpython3.4m.so.1.0()(64bit)

The bindings are ported, but the main package still drags in Python 2.

[encukou]

If any of these are incorrect, please open individual issues/PRs.

[sYnfo]

Cool, thanks for double checking :)