Re: Python 2 support for Bullseye
> On 10/16/20 8:04 PM, Moritz Mühlenhoff wrote: > > There will be few core packages build-depending on Python 2 (for tests > > or building) which won't be ready for Python 3 for Bullseye (Chromium, > > qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very > > small set of support packages like setuptools/jinja) to build and > > run their tests. > > > > Apart from those there's only a handful of packages still in testing > > which have a run time dependency on Python 2 packages (and most are > > actively being worked on (e.g. Xen)). > > > > All packages (and their test suites) shipped in Debian are trusted > > anyway (and consequently don't need any kind of updates during the > > bullseye cycle), so a lack of updates/upstream EOL doesn't matter. > > > > As such, I'd propose to include Python 2 (plus the small set of > > support packages) in Bullseye > > ok. I think you should explicitly name all these packages. I'll file a bug against debian-security-support to list cython, python2.7 and python-stdlib-extensions as unsupported except for building (these are Py2-only and debian-security-support only operates on source packages, so we can't mark binary packages like python-setuptools, but that's fine. In addition I'm planning to submit the following for release notes: | Debian Bullseye includes a version of Python 2.7 (and a short list of | related packages like setuptools still built Python 2 packages). However, these | are only included for building a few applications which still require | Python 2 as part of their build process. Python 2 is not supported for | running applications and there won't be any security updates for Python | 2 in Bullseye. Cheers, Moritz
Re: FYI: Python 3 migration of distributuion
On Tue, Nov 19, 2019 at 10:43:49PM +0900, Osamu Aoki wrote: > On Sun, Nov 17, 2019 at 02:28:44PM +0900, Osamu Aoki wrote: > > Hi, > > > > On Wed, Nov 13, 2019 at 11:11:43AM -0600, Charles Cazabon wrote: > > > Osamu Aoki wrote: > > > > > > > > Currently, getmail is a candidate for removal from the upcoming Debian > > > > release if it is not updated to support python 3 by someone (not > > > > necessary by upstream). > > > > > > Thanks for the update, Osamu. I have actually been playing with a > > > prototype > > > refactoring of getmail to not just support but require a recent Python 3.x > > > version. Such a project would give me the opportunity to remove a lot of > > > historical cruft and backwards-compatibility code that getmail has > > > accumulated > > > over 20+ years. > > > > That's great. (I thought you rejected idea to move to 3.0.) > > > > I tried to do it around getmail 5.5 days. (I didn't finish it) > > > FYI: I found this repo > https://gitlab.com/dkg/getmail/commits/python3 > I think this is better work than my local work. Hi Osamu, given that a Py3-compatible version is now available as src:getmail6, let's go ahead and remove getmail? Cheers, Moritz
Python 2 support for Bullseye
There will be few core packages build-depending on Python 2 (for tests or building) which won't be ready for Python 3 for Bullseye (Chromium, qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very small set of support packages like setuptools/jinja) to build and run their tests. Apart from those there's only a handful of packages still in testing which have a run time dependency on Python 2 packages (and most are actively being worked on (e.g. Xen)). All packages (and their test suites) shipped in Debian are trusted anyway (and consequently don't need any kind of updates during the bullseye cycle), so a lack of updates/upstream EOL doesn't matter. As such, I'd propose to include Python 2 (plus the small set of support packages) in Bullseye but exempt it from support (and then remove it for good after the Bullseye release): - Mark src:python (plus related support packages) as unsupported in debian-security-support and with a README.Debian in the source package (and given how prominent Python is, also in the release notes) - Bump the severity of the few remaining packages in testing to RC state (and force them out testing if auto removals were blocked for some reason) Thoughts? Cheers, Moritz
Joining Python Modules Team
Hi, I noticed that subliminal is not in Buster due to various RC bugs and would like to take care of it going forward, can you please add me to the Python Modules Team project on Salsa? I'll upgrade it to the latest version (along with babelfish, guessit and python-rebulk which also need more recent releases and are maintained by PMT), local build is working fine for me. I'll also drop Python 2 from the packages. Cheers, Moritz
Re: Growing file lists after python2.7 rebuild
On Thu, Mar 13, 2014 at 09:42:04PM +0100, Moritz Mühlenhoff wrote: Thanks a lot for your analysis. I'll make a test build tomorrow and follow up. Seems to have worked. python2.7 DSA will be released tomorrow. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140316165248.GB4736@pisco.westfalen.local
Re: Growing file lists after python2.7 rebuild
On Wed, Mar 12, 2014 at 12:47:18AM +0100, Jakub Wilk wrote: [This is a copy of what I sent to #702005 (after unarchiving it), which didn't show up on bugs.d.o yet.] According to python2.7-minimal's README.Debian, the _ssl and _hashlib are supposed to be included in the -minimal package. python2.7-minimal_2.7.3-6_amd64.deb indeed includes them both, but on every other architecture they are shipped in python2.7. Worse, if you rebuild wheezy's src:python2.7 in a clean environment, the modules move to python2.7, likely leading to upgrade problem similar to that reported a while ago: Urgs. I'll contact the people doing archive rebuilds; file lists could be compared for successful builds. There are several Java packages in Wheezy which have broken file lists after a rebuild. * Vincent Lefevre vinc...@vinc17.net, 2013-03-01, 17:00: Unpacking replacement python2.7 ... dpkg: error processing /var/cache/apt/archives/python2.7_2.7.3-7_amd64.deb (--unpack): trying to overwrite '/usr/lib/python2.7/lib-dynload/_hashlib.so', which is also in package python2.7-minimal 2.7.3-6 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) I believe the bug lies in the following part of debian/rules: DH_COMPAT=2 dh_movefiles -p$(p_min) --sourcedir=$(d) \ usr/bin/python$(VER) \ usr/share/man/man1/python$(VER).1 \ $(foreach i,$(MIN_MODS),$(scriptdir)/$(i).py) \ $(foreach i,$(MIN_PACKAGES),$(scriptdir)/$(i)) \ $(foreach i,$(MIN_ENCODINGS),$(scriptdir)/$(i)) \ $(scriptdir)/config/Makefile \ usr/include/$(PVER)/pyconfig.h \ $(scriptdir)/site.py \ $(shell cd $(d); for i in $(MIN_EXTS); do \ test -e $(scriptdir)/lib-dynload/$$i.so \ echo $(scriptdir)/lib-dynload/$$i.so; \ done; true) The culprit appears to be that make expands $(shell ... ) too early, when no *.so files exist yet. Replacing $(shell ... ) with $$( ... ), and then adding appropriate Breaks+Replaces should fix this bug. (I haven't tested the proposed fix in practice yet.) Thanks a lot for your analysis. I'll make a test build tomorrow and follow up. It still don't understand why this bug didn't trigger for the amd64 package. Perhaps the build log could shed some light on it. Unfortunately I don't have the build log for the deb7u1 upload, the amd64 version was the one I uploaded and I didn't save the log. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313204204.GA3222@pisco.westfalen.local
Re: Growing file lists after python2.7 rebuild
On Tue, Mar 11, 2014 at 07:26:55PM +0100, Jakub Wilk wrote: * Moritz Muehlenhoff j...@debian.org, 2014-03-11, 18:30: I prepared a security update for python2.7 in stable-security fixing CVE-2013-4238 and CVE-2014-1912. But rebuilding the package caused changes in the file list which are not obvious to me: In python2.7-minimal: +/usr/lib/python2.7/lib-dynload/_hashlib.so +/usr/lib/python2.7/lib-dynload/_ssl.so In python2.7: +/usr/lib/python2.7/lib-dynload/_hashlib.so +/usr/lib/python2.7/lib-dynload/_ssl.so Unexpected migrations of these modules between python2.7 and python2.7-minimal have been observed in the past: #702005. Turns out that sweeping the problem under the carpet, instead of fixing it properly, wasn't the best strategy… Does anyone have an idea what's going wrong? debian/rules has some commented entries for lib-dynload/_bsddb.so, so this seems to be a generic problem? No idea yet, but I will look into it. Thanks! This happened both for my local build and on the buildd. Source package and build log are on http://people.debian.org/~jmm/ “You don't have permission to access /~jmm/python2.7_2.7.3-6+deb7u1_i386-20140305-1206.gz on this server.” Doh, fixed. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311190907.GA2960@pisco.westfalen.local
Re: Enabling hardened build flags for Wheezy
Nikolaus Rath nikol...@rath.org schrieb: Moritz Muehlenhoff j...@debian.org writes: Hi, dpkg-buildflags allows a uniform setting of default build flags for code written in C and C++. Using dpkg-build-flags in your rules files has a number of benefits: [...] Should packages of Python extensions written in C and using distribute/setuptools worry about this, or will the debian setuptools package be patched to use dpkg-build-flags? I haven't looked into C-based Python modules yet (it's still on my TODO list), but we should strieve for a generic solution. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjl221c.jlm@inutil.org
