sudo apt-get install gobby-infinote gobby-infinote * Python 3 support: what can we do to add more python3-foo packages? pybuild talk on Saturday. pybuild makes it really easy to support py2+py3, but maybe it could still be made easier. Some libraries don't have support, but a lot do, and still no packages are there. Bottlenecks: stacks of dependencies, bin-NEW roundtrip time * ?Not a problem: NEW round trip for new Python3 binary is usually very short List of python3 upstream supported libraries w/o python3 debian packages? * PyPI not always up-to-date * Ubuntu spreadsheet only for the base images for mobile, server and desktop, not a comprehensive list of all the packages in the archive. Let's start with all the DPMT packages. (see action items) An interesting page with some Python3 support list: https://wiki.openstack.org/wiki/Python3 A good guide on how to fix Python3 issues: http://docs.pythonsprints.com/python3_porting/py-porting.html If upstream doesn't have support, ask for it upstream or go on the python-porting mailing list (https://mail.python.org/mailman/listinfo/python-porting) for help. No need to add it yourself if you don't want to. Migration from python-foo to python3-foo when python-foo provides a /usr/bin script: * The better solution is to ship a "foo" binary package that ships the /usr/bin script. Hopefully ftp-masters will accept it. Packages which I identified as real blockers for Python3 support, with lack of Python3 support upstream (please add yours...): - memcached - eventlet - wxwidgets / wxpython * Getting rid of Py2 in the base install Not realistic for jessie (most importantly reportbug uses a Py2-only SOAP library). To be revisited (and done!) for Jessie+1. * python-support removal in Jessie, is it possible? Should we focus on this? dh-python2 is The One True Way to build python (2) packages. python-central is gone from the archive and python-support is deprecated. Likewise dh-python{3,pypy} (move this below?) The documentation could use a go-over to ensure the proper packaging philosophy is consistent. - wiki/Python - wiki/Python/Packaging - wiki/Python/LibraryStyleGuide - Python Policy, Appendix B Please do link the pages that need updating :) stdeb has been updated to use dh_python2 https://lintian.debian.org/tags/dh_pysupport-is-obsolete.html Let's start updating with DPMT, and consider doing a MBF once that is done. Finally, have ftp-masters add an autoreject for the last push. * PyPy3, how can we help Stefano? It's a crazy complicated package. Help is needed. PyPy3 has now been released, so we should start to support it. The complication is on C extensions, but you shouldn't really be using those with PyPy anyway. * stuff pybuild / dh_python* lacks: - what can be automated? - nose / pytest / testrepository+subunit by default? + No metadata to specify which testsuite to use + pybuild could have a look at build-dependencies to guess which testsuite to run - Build-Depends requirement for egg/PyPI/Python distribution Depends translation? - more build plugins? * Jessie+1 plans? - namespace PEP? - Py2 removal in the base install * DPMT/PAPT's move to git git > svn - need to agree on branch names and tags. - Up until now it's "everybody in the same VCS" and that prevents us from migrating - relax the svn requirement? Have a default team git repository and start migrating packages progressively? - notes on workflow in README.Source? - full-source in the repo vs debian-only? Perl team use full-source and mr to manage all the repos. Also nice tools for setting up new packages/repositories (dpt) and good documentation about the workflow -> http://pkg-perl.alioth.debian.org/git.html - ad-hoc session at 15:30 ACTION ITEMS: ------------- * piotr to help with a list of packages that lack py3 support in Debian. * barry to help with scripting python3 addition for DPMT packages. * piotr to sponsor uploads for dh_pysupport->dh_python2 transition in DPMT. * git move ad-hoc session at 3:30pm. MIGRATION TO GIT: ----------------- full source / debian only ------------------------- git-buildpackage supports --merge-with-upstream, which allows for a debian-dir-only repo. An option is to only have the upstream branch, tracking upstream tarballs only, rather than having complete upstream git history. It sounds like the best solution is to track full upstream source (one way or another) for >90% of the packages, and debian-source only if necessary, because a repo is huge. Problem with the full history in git: size of checkouts for people that want to keep all the team repos checked out. It is still possible to do a shallow checkout if you really need to optimize for volume. Or we could have separate branches with only the debian dir, generated from the main branch, for people who have everything checked out for QA. Sounds pretty hard to use those to interact with the main repo, though. What about packages without an upstream tarball? If we use pristine-tar for all of these, then we have a consistent approach across the team. svn history, do we keep it? with git-svn, or with the kde git-svn-import, each tag becomes a branch which is a pain. One possible solution is to use git-import-dscs to grab all the Debian history from snapshot.d.o. History can be left for now. There is git-replace, which grafts history into a repo, later. Or do a magic merge to introduce history. quilt-only (patches in git) / git-dpm / gbp-pq: dpm is local-only. as is gbp-pq. CONVERTION FROM SVN TO GIT - History: - Tag names: * Use the normal pristine-tar upstream/ for upstream tags * For debian tags corresponding to uploads: debian/ as "debcommit -r" does (please use "git tag -s" and sign your tags) - Branch names: * debian packaging branch names: o sid or experimental -> master o wheezy -> wheezy o wheezy-backports -> wheezy-backports * upstream packaging branch name (only a single branch): o sid or experimental -> upstream * pristine-tar - Workflow: * pristine-tar * tag based orig file ONLY if upstream do not publish tarballs. In this case, generate it, then import it in pristine-tar * Decide later if we use git-buildpackage, git-dpm or gbp-pq, give team members time to try - Schedule: * Prepare the migration from SVN to Git, but we don't do it before the freeze. * Decide if we use git-dpm or gbp-pq on the 6th of December, at which point mass migration can start. * If you want play with a couple of packages before the freeze, do that. Say one with dpm, and one with pq, and report back.