Currently, it is not clear how the statuses map to Bugzilla. Please add an explanation in a prominent place.

Currently we say attach the patch to bugzilla in http://fedora.portingdb.xyz/howto/

Maybe we want to say "open a Pagure Pull Request" instead?

The upstream for the entire stack of Obnam and its dependencies has indicated that currently he prefers not supporting Python 3 -- is there a way to mark this so that for the Python 3 porting page people do not waste their time either contacting upstream or working on the port?

http://listmaster.pepperfish.net/pipermail/obnam-dev-obnam.org/2015-October/000238.html

It is hard to figure out which yaml file I need to modify to indicate
that I am working on a package.
If each yaml file had comments at the top, that would make things a lot easier to figure out.

In the last update, packages like django or python-django-pipeline gained subpackages like python2-django-1.6.11.6-12.module_1f1233d9 and python2-django-pipeline-1.3.27-11.module_0b083f9b.

Let's just make portingdb ignore these. If a package needs Python 2, then I guess in the long term we actually want it to use python2 from a module. (And we don't want to maintain such a module.)

There's a libvirt-python3 package in Fedora which is supposed to replace the libvirt-python package. It's not listed on the portingdb app pages, though. it's a subpackage of the libvirt-python package (which provides both python2 and python3 subpackages.)

We could automatically find packages that provide 2 subpackages (for 2 and 3) but only the python2 subpackage has something in /usr/bin.

Than we could mark them as mispackaged.

I think we have plenty of those packages in Fedora. See for example https://bugzilla.redhat.com/show_bug.cgi?id=1323256

Bugs should be filed as packages' dependencies are ported. Portingdb has a script to detect these; currently we're at three:

$ python3 -m portingdb -v upstream-idle 

The following packages are both 'idle' and marked as 'released' upstream:

        autokey
        mpi4py
        wxPython

The statuses (I, P, ✔, X, B) are not explicitly explained. Please add an explanation to the top of the page.

We seem to track build time dependencies now. See how asciidoc has plenty build time dependent packages. Yet in our dependency graph there is no big cluster around it.

Could we please have a second, build-time dependency (possibly combined with runtime) graph?

There are some python-version-independent packages, where an unversioned python in the name is correct. #352 dealt with *-doc, but there are others. What to do with them?
Worth checking are:

python-django-bash-completion
python-matplotlib-data
python-matplotlib-data-fonts
python-qt5-rpm-macros
python-rpm-macros
python-sphinx-locale
python-srpm-macros
python-typeshed

as I've mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1311516#c5 the python-cli package is not supported anymore. So might be make sense to mark it as deprecated (I don't think it worth overtaking the project as it does not look very popular).
On the other hand it is marked as a dependency of openerp7, which, as stated in portingdb (http://fedora.portingdb.xyz/pkg/openerp7/), is also not interested in port to python3. But even here there is probably an issue with packaging, since requirements.txt of https://github.com/odoo/odoo/blob/10.0/requirements.txt do not contain python-cli package, was never in commit history, is not listed in the provided rpms (http://nightly.odoo.com/7.0/nightly/rpm/)

python-fedora has a subpackage set python3-fedora* where the bits that are useful for python3 are available for python3, but it is marked as not available for python3.

The 20180919.n.0 compose drops a bunch of packages I've retired due to the Mass Python 2 Package Removal, those are still listed on PortingDB. I'd really appreciate to get fresh data to (open bugzillas to) retire a next batch.

I guess #444 was done before the mirrors were updated. It has been couple days, so it should hopefully be there now.

Thank You.

https://pagure.io/fesco/issue/2262
https://pagure.io/fesco/issue/2263

Currently, the bars are proportionate in any case, which leads to small-number items being invisible (highlighted in the picture). Please add minimal width.

Packages qmtest and pacrunner seem to fail to build from source in Fedora for some time but they are not marker properly in portingdb.

Bugs lists:

• https://bugzilla.redhat.com/buglist.cgi?quicksearch=qmtest&list_id=10347096
• https://bugzilla.redhat.com/buglist.cgi?quicksearch=pacrunner&list_id=10347095

I am not sure why but audit-viewer package is in the portingdb marked as non-python package although it depends on a lot of python packages and it's written in Python.

https://src.fedoraproject.org/rpms/audit-viewer/blob/master/f/audit-viewer.spec

Create a separate status for Python 2 (sub)packages which are named python-foo instead of python2-foo (with provides) and should be renamed in the nearest future.

There are packages like this across all statuses, so suggestions on displaying those in portingdb can be added to comments.

Update:

• Name status should be a boolean field
• There should be 2 statuses: Correctly named and Incorrectly named
• Collect also information on cases like sympy (foo, python3-foo), which should also go into incorrectly named group

I've juts found out that one of my packages (openscad) requires python2 by accident.

I would like to check all of my packages and having a page at portingdb with my packages would be very helpful. See https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers for how to get the info.

I'm opening this here, because I want to coordinate somewhere. Portingdb doesn't necessarily need any changes.

We have some packages that depend on Python 2 packages. We should determine a way how to bother them, or else their maintainers (and users) will be surprised.

Imagine yakshaver uses (runs on) Python 2 and we track it.
@frenzymadness open a bugzilla and the yakshaver maintainers say "yeah, we don't care, let's retire it in November".

However, yakdashboard uses yakshaver. yakdashboard is written in JavaScript, so the maintainers don't have a clue about any of this. In November yakshaver disappears and the yakdashboard maintainers are surprised by this. All the yak farmers are sad...

How to deal with this kind of things?

These two applications:

http://caniusepython3.com/
https://python3wos.appspot.com/

poll PyPI directly to report if a Python3 version of a package is available.

The portingdb should report info from PyPI. This will allow people to see
if the Python3 package is available upstream, but the newer version is not in Fedora.
This will give people the idea that the focus should be on the Fedora packaging,
and not the Python3 code of the package itself.

Create a final porting status (name it Done, or suggest names in comments) for packages which are Python 3 only (do not have any Python 2 subpackages). Display them as dark green in a separate section (between released and blocked).

Adding this should not influence the calculation of ported packages percentage. This will provide information on how many packages are on a final stage of porting (i.e. dropped Python 2 support completely).

Currently the order seems somewhat random:

Idle, In Progress, Released, Blocked, Mispackaged, Dropped

I suggest a new order which roughly corresponds to how close the package is to being Released:

Released, In Progress, Mispackaged, Idle, Blocked, Dropped

I believe this would provide better overview at first glance. I'll happily try to implement the change.

I've found package datanommer-models which has a lot of dependencies in specfile [0] but in portingdb it has only two - for example, fedmsg is listed in specfile as build and runtime dependency but not in dependencies list in portingdb [1].

[0] http://pkgs.fedoraproject.org/cgit/rpms/python-datanommer-models.git/tree/python-datanommer-models.spec
[1] http://fedora.portingdb.xyz/pkg/python-datanommer-models/

This project recently got a lot of contributors, so I'll write down my plans to reduce the chance of duplicate work :)

I should get to these next week (starting 2015-11-16):

• Go through the mass bug-filing procedure to file Fedora bugs for unported packages
• Create a tracking bug for py3 porting
• Add all individual bugs to the tracking bug
• Start filing bugs for individual packages as needed

1. start working on package xyz
2. add it to yaml files as in-progress, assign bugzilla URL
3. the bug on bugzilla is closed, teh package pushed
4. it's still shown as in-progress, because yaml files say so

Some of the listed packages here have exceptions, but it is not visible just by looking at them here.

I'd like to see packages that are marked Python 3 only but have Python 2 dependencies.

If a separate new category is overkill, a summary page would do.

Usually this marks a big mistake in packaging. I've noticed we have a quite a few, when I've seen the graph from #491

Numpy and matplotlib have python3 packages for Fedora, so they should be marked as released.

Hello.

It seems that specifying --datadir doesn't work. For example, when I wanted to load a database from the data/ directory, I got the following strange error:

$ basename $PWD
portingdb
$ python -m portingdb --datadir data/ load
Traceback (most recent call last):
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1193, in _execute_context
    context)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/default.py", line 509, in do_execute
    cursor.execute(statement, parameters)
sqlite3.OperationalError: no such column: dependencies.run_time

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib64/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/lbalhar/Dropbox/Projekty/portingdb/portingdb/__main__.py", line 3, in <module>
    main()
  File "/home/lbalhar/Dropbox/Projekty/portingdb/portingdb/cli.py", line 19, in main
    return cli(obj={})
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/lbalhar/Dropbox/Projekty/portingdb/portingdb/cli.py", line 127, in load
    warnings = load_from_directories(db, datadirs)
  File "/home/lbalhar/Dropbox/Projekty/portingdb/portingdb/load.py", line 270, in load_from_directories
    key_columns=['requirer_name', 'requirement_name'])
  File "/home/lbalhar/Dropbox/Projekty/portingdb/portingdb/load.py", line 428, in bulk_load
    ignored_columns=ignored_columns))
  File "/home/lbalhar/Dropbox/Projekty/portingdb/portingdb/load.py", line 474, in bulk_load
    existing_rows = list(db.execute(sel))
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 1187, in execute
    bind, close_with_result=True).execute(clause, params or {})
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 948, in execute
    return meth(self, multiparams, params)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/sql/elements.py", line 269, in _execute_on_connection
    return connection._execute_clauseelement(self, multiparams, params)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1060, in _execute_clauseelement
    compiled_sql, distilled_params
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1200, in _execute_context
    context)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1413, in _handle_dbapi_exception
    exc_info
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/util/compat.py", line 265, in raise_from_cause
    reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/util/compat.py", line 248, in reraise
    raise value.with_traceback(tb)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1193, in _execute_context
    context)
  File "/home/lbalhar/.virtualenvs/portingdb/lib/python3.7/site-packages/sqlalchemy/engine/default.py", line 509, in do_execute
    cursor.execute(statement, parameters)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such column: dependencies.run_time [SQL: 'SELECT dependencies.requirer_name, dependencies.requirement_name, dependencies.id, dependencies.run_time, dependencies.build_time, dependencies.unversioned \nFROM dependencies \nWHERE dependencies.requirer_name IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) AND dependencies.requirement_name IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: ('abiword', 'asv', 'PyPE', 'PyDrive', 'capstone', 'claws-mail', 'R2spec', 'cherokee', 'bitlyclip', 'blktrace', 'boost', 'alacarte', 'blueproximity', 'cgit', 'assimp', 'Spawning', 'cfv', 'copr-rpmbuild', 'Pyrex', 'calibre', 'atomicapp', 'certmaster', 'audio-convert-mod', 'b43-tools', 'cinnamon', 'ailurus', 'OpenMolcas', 'bro', 'anki', 'catfish', 'PyYAML', 'cherrytree', 'chirp', 'NFStest', 'archivemail', 'comedilib', 'angrydd', 'WALinuxAgent', 'beaker', 'barry', 'copr-frontend', 'bmpanel2', 'bitten', 'calamares', 'bugyou_plugins', 'TeXamator', 'caribou', 'Singular', 'cantor', 'comix', 'configsnap', 'PyPAM', 'cairo-dock-plug-ins', 'bkchem', 'check-mk', 'certbot', 'cashe', 'apitrace', 'cas', 'carbonate', 'cppcheck', 'bugzilla', 'avahi', 'Zim', 'babel', 'bup', 'bluefish', 'PySolFC', 'cloudtoserver', 'cjdns', 'alignak', 'beecrypt', 'bibus', 'centerim', 'autotest-framework', 'PyRTF', 'Ray', 'PyGreSQL', 'PyXB', 'bacula2', 'ceph-deploy', 'avogadro', 'PyQwt', 'clang', 'airinv', 'cmdtest', 'VMDKstream', 'alsa-tools', 'Io-language', 'bodhi', 'captcp', 'brial', 'cobbler', 'belier', 'codemod', 'blueberry', 'ViTables', 'cassandra', 'chm2pdf', 'a2jmidid', 'byobu', 'asciidoc', 'createrepo', 'bpython', 'audit', 'childsplay', 'aubio', 'WebShell', 'bzr', 'RunSnakeRun', 'bitfrost', 'catkin', 'archmage', 'cachedir', 'cmpi-bindings', 'chromium', 'classification-banner', 'autodownloader', 'asymptote', 'GeographicLib', 'autokey', 'condor', 'bakefile', 'Cython', 'batti', 'ahkab', 'cracklib', 'contextkit', 'afflib', 'brotli', 'arandr', 'bleachbit', 'alot', 'airtsp', 'PyMca', 'SoapySDR', 'copr-backend', 'clustershell', 'PyQt4', 'asterisk', 'CheMPS2', 'ccnet', 'autocloud', 'airrac', '389-ds-base', 'cloud-utils', 'cmusphinx3', 'GitPython', 'antlr', 'coq', 'chameleon', 'stdair', 'python-acme', 'python-flask', 'pybluez', 'gpgme', 'python-sphinx_rtd_theme', 'xemacs-packages-extra', 'python-pmw', 'cherokee', 'pyliblzma', 'python-enchant', 'boost', 'python-zope-component', 'python-kitchen', 'kf5-ki18n', 'euca2ools', 'python-ply', 'python-httplib2', 'python-eventlet', 'python-requests', 'libxslt', 'mpich', 'sphinxbase', 'python-cheetah', 'Pyrex', 'python-pyrfc3339', 'python-send2trash', 'gnome-python2-desktop', 'libglade2', 'gtk2', 'python-paramiko', 'python-cssutils', 'python-feedparser', 'GConf2', 'python-docutils', 'python-jsonpointer', 'python-psycopg2', 'python-rpm-macros', 'python-websocket-client', 'python-cherrypy', 'PyYAML', 'python-setuptools', 'python-empy', 'python-cryptography', 'libxml2', 'trac', 'python-coverage-test-runner', 'python-pycurl', 'pyfribidi', 'pytz', 'python-nose', 'python-oasa', 'python-dateutil', 'pyxdg', 'python-urlgrabber', 'python-curtsies', 'tunir', 'python-retask', 'python-fedora', 'pygtksourceview', 'python-click', 'python-ttystatus', 'python-mock', 'python-lxml', 'gnome-doc-utils', 'python-oauth2client', 'python-gitdb', 'fuse-python', 'newt', 'vte', 'pyserial', 'python-urwid', 'mercurial', 'python-iniparse', 'python-redis', 'sip', 'dblatex', 'python-sqlalchemy-utils', 'python-josepy', 'wxPython', 'python-pytest-cov', 'python-mutagen', 'python-cassandra-driver', 'pygtk2', 'python-pillow', 'python-pexpect', 'python-remoto', 'python-parsedatetime', 'python-anymarkup', 'pyOpenSSL', 'python-apsw', 'python-sqlalchemy', 'libappindicator', 'pygame', 'python-zope-interface', 'gnome-python2', 'python-configargparse', 'file', 'python-urwidtrees', 'python-chm', 'python-netaddr', 'libevent', 'pylibacl', 'python-regex', 'epydoc', 'python-unittest2', 'yum', 'python-pep8', 'python-cliapp', 'pygobject3', 'python-prettytable', 'python-six', 'python-simplejson', 'python-BeautifulSoup', 'pycairo', 'python-freezegun', 'python-libpagure', 'python-greenlet', 'PyQwt', 'python-msgpack', 'python-rospkg', 'numpy', 'python-enum34', 'python-dpkt', 'future', 'cmdtest', 'pyaudio', 'python-distutils-extra', 'python-squaremap', 'odfpy', 'python-krbV', 'pyparsing', 'python-repoze-sphinx-autointerface', 'python2-matplotlib', 'pygobject2', 'python-twisted', 'python-setproctitle', 'python-munch', 'libsearpc', 'createrepo', 'rpm', 'rmol', 'python-html5lib', 'python-jedi', 'python-markdown', 'dbus-python', 'notify-python', 'python-netifaces', 'python-alsa', 'python-bitlyapi', 'pytest', 'python-suds', 'sevmgr', 'python-dns', 'python-qt5', 'python-pygments', 'pyxattr', 'python-sphinxcontrib-httpdomain', 'Cython', 'koji', 'python-mako', 'sugar-toolkit-gtk3', 'python-alembic', 'lilypond', 'python-beautifulsoup4', 'yum-metadata-parser', 'python-tables', 'deltarpm', 'python-sphinx', 'python-tornado', 'PyQt4', 'mod_wsgi', 'python-ethtool', 'airrac', 'python-configobj', 'python-html5-parser', 'fedmsg', 'python-mechanize', 'python-watchdog', 'python-markupsafe', 'python-mysql', 'python2', 'google-api-python-client', 'notmuch', 'python-jinja2', 'python-pbr', 'python-psutil', 'openmpi')] (Background on this error at: http://sqlalche.me/e/e3q8)

Doing the same in the data directory works:

$ cd data
$ PYTHONPATH=.. python -m portingdb load
{'bug', 'repo'}
{'bug', 'homepage', 'repo'}
overriding "legacy-leaf" status: fedora: cairo-dock-plug-ins
overriding "legacy-leaf" status: fedora: edk2

The same bug exists when a database is ready in data folder:

$ basename $PWD
portingdb
$ ls -1 data/portingdb.sqlite 
data/portingdb.sqlite
$ python -m portingdb --datadir data/ status
Database not filled; please run portingdb load

And it again works when executed in the data fodler:

$ cd data
$ PYTHONPATH=.. python -m portingdb status
 50.0% Upstream  (119 released, 7 idle, 5 dropped, 117 unknown) / 248
 74.4% Fedora  (257 legacy-leaf, 2453 released, 44 mispackaged, 912 idle, 68 dropped) / 3734

serve command is not affected

$ basename $PWD
portingdb
$ PYTHONPATH=. python -m portingdb serve
 * Serving Flask app "portingdb.htmlreport" (lazy loading)
 * Environment: production
   WARNING: Do not use the development server in a production environment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

It says it was recently registered at namecheap.

This link still works: https://portingdb-encukou.rhcloud.com/

I'm the developer of one of the packages listed in the database, rapid-photo-downloader. I'm porting it to Python 3 (and Qt 5 and a bunch of other packages). From either the main page or the page dedicated to the application, I can't figure out the best way to let whoever is responsible know for the database that the application is in fact being currently ported.

There is the statement "(Note that there might be false positives; if you spot one, please file a bug)". Is that meant to apply to cases like this?

python-cli is not buildable using python 3.5. A pull-request is submitted to upstream

http://fedora.portingdb.xyz/namingpolicy/ does not seem to consider Recommends. I haven't checked other soft dependency types.

For example, the git-bz package has Recommends: python-crypto at the moment, meaning the Python 2 version. python2-crypto is available, but git-bz is not listed in the naming policy page as a violator.

This list of packages has an approved exception now:

https://pagure.io/fesco/issue/2260

• email2trac
• python2-babel
• python2-genshi
• python2-jinja2
• python2-markupsafe
• python2-pytz
• python2-setuptools
• trac
• trac-CGit-plugin
• trac-accountmanager-plugin
• trac-batchmodify-plugin
• trac-blackmagictickettweaks-plugin
• trac-customfieldadmin-plugin
• trac-doxygen-plugin
• trac-git-plugin
• trac-iniadmin-plugin
• trac-mastertickets-plugin
• trac-monotone-plugin
• trac-navadd-plugin
• trac-privateticketsplugin
• trac-sensitivetickets-plugin
• trac-themeengine-plugin
• trac-tocmacro-plugin
• trac-tracnav-plugin
• trac-vatar-plugin
• trac-watchlist-plugin
• trac-workflowadmin-plugin
• trac-xmlrpc-plugin

This list has exception pending:

https://pagure.io/fesco/issue/2266

• python2-dns
• python2-crypto
• python2-pycryptodomex
• python2-typing
• python2-httplib2
• python2-oauth2
• python2-pillow
• python2-olefile
• python2-numpy

Track also packages that require Python or any Python package to build.

Create a new status (e.g "legacy leaf") that would display Released packages, whose python2 subpackages are not needed by anything.

Those are SRPMs which depend on one of SEED_PACKAGES. Add those packages to the database, and display SRPM python requirements on the package page above RPMs.

This is an initial overview of the requirement. @encukou let me know if you have other ideas regarding how they should be viewed.

http://fedora.portingdb.xyz/pkg/certbot/
says there is no work going on upstream. Since recently patches went in and they enabled their tests against Python 3.
Summary-issue to track their progress: certbot/certbot#3179

For example: http://portingdb-encukou.rhcloud.com/pkg/packagedb-cli/

In preparation for the porting fad this weekend, can we open up the group of people who can update the app some? This way, everyone can be a little more coordinated in their tasks and they can show off the fruits of their labor more quickly.. with less friction. We'll need people who can:

• push to github
• push to openshift

Can I request that myself and @abadger be added to the github group? For openshift, my openshift account is associated with [email protected] and @abadger is associated with [email protected].

• KDE
• Xfce
• LXDE
• MATE
• Cinnamon
• SoaS
• Design suite
• Games
• Robotics suite
• Scientific
• Security lab

See https://lists.fedoraproject.org/archives/list/[email protected]/message/Q225ZPP7R5OAI6MWDW7D5HUNMPIFV3EI/

On 10.8.2017 10:50, Juan Orti Alcaine wrote:

2017-08-10 4:52 GMT+02:00 Scott Talbert:

Where did your list of 'all python packages' come from? I fear that there
are some missing because wxPython should be in there.

I also miss pytorctl in the list.

cc @keszybz @swt2c @jorti

It seems an API change is coming to RH Bugzilla: large results will start to be paginated.
Since I don't use portingdb bug links too much, I intend to spend about an hour adapting to this change (after it goes live), and remove bug links from portingdb if I don't make it.
Let me know if I should put in more effort.

It seems that https://portingdb-encukou.rhcloud.com/pkg/python-dateutil15/ causes maintainers to mark both of the python packages that depends on it as dependencies unmet. However, dateutils15 is intended to be py2 only, and its Python3 port is maintain upstream as dateutils 2.x.

PS. Both packages that depends on dateutils have Python 3 support upstream:

• python-tgscheduler: Since https://pypi.python.org/pypi/TGScheduler/1.7.0.
• python-vobject: Since https://pypi.python.org/pypi/vobject/0.9.0.

Currently these are marked dropped, but that's not the right way to handle them:

• cairo-dock-plug-ins (#575)
• python-mecab
• skf

Vips package is marked as Idle (gray), but it has Python3.
http://fedora.portingdb.xyz/pkg/vips/

Can we somehow add python2-networkx package manually?

See https://bugzilla.redhat.com/show_bug.cgi?id=1634570#c3

My dnf is dnf-4.2.1-1.fc29.noarch

I have this:

/var/cache/dnf/rawhide-2d95c80a1fa0a67d/repodata/87aeb2d57689193867c476f3af2a7592a0f41f1a91337769d539a6e1ffdb5b0b-filelists.xml.zck

Instead of

/var/cache/dnf/rawhide-2d95c80a1fa0a67d/repodata/87aeb2d57689193867c476f3af2a7592a0f41f1a91337769d539a6e1ffdb5b0b-filelists.xml

I think we need to figure out how to unpack it.

Hi,

It looks like this project is almost complete, which is great to see.
A heads up I am using the fedora.json as a dataset for a list of Fedora python packages to use in testing of https://github.com/jayvdb/pypidb , which locates the SCM for PyPI packages. The methodology is to not rely on the links provided in the PyPI metadata, and it also doesnt include explicit mappings which would be brittle.

There are some packages I couldnt/didnt map to PyPI names in https://github.com/jayvdb/pypidb/blob/ba7740e/tests/datasets.py#L46 , and I am only currently looking at packages prefixed python[23]-* and py*. There is a mapping of Fedora names to PyPI names directly above that, which may be incomplete.

The list of those PyPI packages in Fedora that I do not yet find an SCM for is at https://github.com/jayvdb/pypidb/blob/master/tests/test_fedora.py#L50 . I suspect some of those will be missing mappings from Fedora names to PyPI names, which the team here might be able to spot quickly.

The resulting mappings to SCM might be helpful for this project in various ways, e.g.

• doing additional analysis (an area I would love to go into is checking whether downstream projects are running CI, esp on Python 3.8),
• remediation downstream (the obvious is updating setup.py/setup.cfg/etc to emit Python 3.x metadata), and
• linking directly to the SCM for packages which havent been ported yet.
• also checking whether .spec are using current URLs (the logic in pypidb is very often identifying readthedocs websites, but that isnt exposed via the API yet; c.f. jayvdb/pypidb#29).