On 11.12.23 19:55, Julian Gilbey wrote:
On Mon, Dec 11, 2023 at 04:34:17PM +0100, Matthias Klose wrote:
On 11.12.23 16:19, Julian Gilbey wrote:
On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
[...]
You could package a non-conflicting cython-legacy, however that would
require
On 11.12.23 08:12, Matthias Klose wrote:
On 10.12.23 14:06, Rebecca N. Palmer wrote:
Is this an acceptable amount of breakage or should we continue to
wait? Bear in mind that if we wait too long, we may be forced into it
by some transition further up the stack (e.g. a future Python or
numpy
On 11.12.23 16:19, Julian Gilbey wrote:
On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
[...]
You could package a non-conflicting cython-legacy, however that would
require more changes, also how to build it.
Hi Matthias,
Unfortunately, at least some of cython3-legacy doesn't
On 11.12.23 08:09, Matthias Klose wrote:
On 10.12.23 21:32, Andrey Rakhmatullin wrote:
On Sun, Dec 10, 2023 at 09:30:03PM +0100, Andrey Rakhmatullin wrote:
I find that there's also a significant issue with relying on
cython3-legacy: it conflicts with cython3, meaning that it will be
impossible
On 10.12.23 14:06, Rebecca N. Palmer wrote:
I'd like to move forward with the pandas 1.5 -> 2.1 transition
reasonably soon.
Given that pandas 2.x is *not* required for Python 3.12 (but is required
for Cython 3.0), should we wait for the Python 3.12 transition to be
done first?
These are
On 10.12.23 21:32, Andrey Rakhmatullin wrote:
On Sun, Dec 10, 2023 at 09:30:03PM +0100, Andrey Rakhmatullin wrote:
I find that there's also a significant issue with relying on
cython3-legacy: it conflicts with cython3, meaning that it will be
impossible to simultaneously install packages
as a supported version. If you see
builds failing because of a missing 3.12 extension, please just wait a
few days until all the binNMUs are done.
For the progress, see (ignoring the 'unknown' status)
https://release.debian.org/transitions/html/python3.12-add.html
Matthias
On 07.11.23 11:27, Matthias
On 07.11.23 14:06, Thomas Goirand wrote:
When 3.12 because an available version, it would help a lot to have
someone like Lucas Nusbaumm to rebuild all reverse dependencies of
Python. Is that something planned?
No. A test rebuild with a stack of 12 dependency levels doesn't make
much sense.
Python 3.12 was released a month ago, and it's time to prepare for the
update in unstable, first adding 3.12 as a supported version.
There s a tracker for adding 3.12 as a supported version [1], also there
are the first bug reports filed for issues related to 3.12 [2].
As usual, it's
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a tracker to add python3.12 as a supported python3 version. This is
non-blocking, as packages can migrate on their own once
while we have not an 100% agreement to go ahead, I think we should aim for 3.11.
The following steps would be:
- accept the current python3-defaults into
testing (adding 3.11 as supported)
- ask for a transition slot to upload (see #1026825)
python3-defaults with 3.11 as the default
-
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a transition window for python 3.11 as the default python3 version.
A tracker is setup at
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a transition window for python 3.10 as the default python3 version.
A tracker is setup at
On 9/14/21 8:36 AM, Matthias Klose wrote:
> On 9/13/21 4:02 PM, Scott Talbert wrote:
>> On Fri, 3 Sep 2021, Matthias Klose wrote:
>>
>>>> Python 3.8 upstream now has a common ABI for normal and debug extension
>>>> builds,
>>>> so it is technical
On 9/13/21 4:02 PM, Scott Talbert wrote:
> On Fri, 3 Sep 2021, Matthias Klose wrote:
>
>>> Python 3.8 upstream now has a common ABI for normal and debug extension
>>> builds,
>>> so it is technically possible to load a debug extension in the normal
>>>
On 7/6/20 8:33 PM, Matthias Klose wrote:
> Python 3.8 upstream now has a common ABI for normal and debug extension
> builds,
> so it is technically possible to load a debug extension in the normal
> interpreter, or to load a normal extension in the debug interpreter. In
>
As Stefano wrote, we had some discussion around Python packaging in Linux
distros. While the linux-sig is/was very dormant the last years, we'd like to
coordinate on this list, so if you're interested in cross distro issues, please
subscribe to
On 5/16/21 1:52 PM, Luke Kenneth Casson Leighton wrote:
>> * One 3.x version at a time. Doesn't line up with cpython's support terms.
> numpy and sci-py, the two "best known" debian python software
> packages, have known about this for a long, long, time. they
> quietly solved it by adding
On 3/3/21 6:56 PM, Andrey Rahmatullin wrote:
> On Wed, Mar 03, 2021 at 05:39:04PM +, Stefano Rivera wrote:
>> You need python3.8-venv.
> Which doesn't exist, at least in the current repos.
you rebuild it from python3-stdlib-extensions. but yes, the binaries don't exist
in the archive.
I am appending the following two sections to the python policy chapter 2,
documenting what currently is in testing. There are different opinions, no
perfect solutions, and if we disagree, we should delegate the final decision
whether to include or to not include the binary packages
On 2/12/21 2:08 PM, Julien Palard wrote:
> Hi,
>
> As far as I understand, the divergence between "Python upstream" and
> Debian is:
>
> - It looks like Debian target users consuming software, users just
> install a package and it works, no venv needed obviously, it always just
> work, it's
On 1/20/21 8:39 PM, Stephen Kitt wrote:
> Hi,
>
> I’ve come across a situation which doesn’t seem to be addressed by existing
> policies: the python-ptrace source package only ships
> architecture-independent content, but it works on a small number of
> architectures (currently, 32/64-bit x86,
On 11/9/20 10:19 AM, Matthias Klose wrote:
> On 10/23/20 1:07 PM, Matthias Klose wrote:
>> On 10/18/20 12:13 PM, Matthias Klose wrote:
>>> Python 3.9 as a supported Python3 version is now in unstable, and all
>>> binNMUs
>>> are done (thanks to Graham for th
On 11/11/20 3:27 AM, Michael Hudson-Doyle wrote:
> On Mon, 9 Nov 2020 at 22:20, Matthias Klose wrote:
>
>> On 10/23/20 1:07 PM, Matthias Klose wrote:
>>> On 10/18/20 12:13 PM, Matthias Klose wrote:
>>>> Python 3.9 as a supported Python3 version is no
On 10/23/20 1:07 PM, Matthias Klose wrote:
> On 10/18/20 12:13 PM, Matthias Klose wrote:
>> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
>> are done (thanks to Graham for the work). Bug reports should be all filed
>> for
>
On 11/5/20 1:03 PM, terce...@debian.org wrote:
> On Thu, Nov 05, 2020 at 09:28:56AM +0100, Thomas Goirand wrote:
>> On 11/4/20 9:27 PM, Novy, Ondrej wrote:
>>> Hi,
>>>
>>> Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
Could you ellaborate? Maybe we should have a discussion in the
On 10/23/20 1:07 PM, Matthias Klose wrote:
> On 10/18/20 12:13 PM, Matthias Klose wrote:
>> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
>> are done (thanks to Graham for the work). Bug reports should be all filed
>> for
>
On 10/18/20 12:13 PM, Matthias Klose wrote:
> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
> are done (thanks to Graham for the work). Bug reports should be all filed
> for
> all known problems [1], and the current state of the 3.9 addition
Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
are done (thanks to Graham for the work). Bug reports should be all filed for
all known problems [1], and the current state of the 3.9 addition can be seen at
[2] (a few of the "bad" are false packages with b-d n
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
On 10/15/20 10:03 PM, Alastair McKinstry wrote:
> On 15/10/2020 08:13, Giovanni Mascellani wrote:
>
>> Hi,
>>
>> Il 14/10/20 15:52, Alastair McKinstry ha scritto:
>>> I maintain the package "ecflow" which uses libboost-python-dev. Now
>>> with the transition to python3.9, ecflow will support
On 7/6/20 9:04 PM, Matthias Klose wrote:
> Starting with Python 3.8, Python upstream changed to a time based yearly
> release
> schedule, targeting the first release of a major Python version (3.x) for
> October of each year. For the transition to 3.8:
>
> - we add 3.8 as sup
On 9/17/20 3:04 PM, Nicolas Dandrimont wrote:
> Hi Matthias, others,
>
> On Thu, Jul 9, 2020, at 15:26, Matthias Klose wrote:
>> As written in [1], bullseye will not see unversioned python packages and the
>> unversioned python command being built from the python-defaults pa
block 967209 by 967157
thanks
sorry, that's due to uninstallability of libglade2-dev.
On 8/4/20 2:49 PM, Dirk Eddelbuettel wrote:
>
> Hi doko and Python folks,
>
> On 4 August 2020 at 09:29, Matthias Klose wrote:
> | Package: src:rgtk2
> | Version: 2.20.36-2
> | Severity:
On 7/13/20 6:23 PM, Fabrice BAUZAC-STEHLY wrote:
> Hi,
>
> Another solution would be to simply use the update-alternatives system
> to manage /usr/bin/python. python3 would have a higher priority than
> python2. Users would still have the possibility to switch
> /usr/bin/python to python2
As written in [1], bullseye will not see unversioned python packages and the
unversioned python command being built from the python-defaults package.
It seems to be a little bit more controversial what should happen to the python
command in the long term. Some people argue that python should
On 7/9/20 1:45 PM, Scott Kitterman wrote:
> On Thursday, July 9, 2020 7:21:45 AM EDT Matthias Klose wrote:
>> The removal of packages still depending on Python2 looks good [1], however
>> we have a bunch of packages that still require Python2, and where
>> maintainers exp
The removal of packages still depending on Python2 looks good [1], however we
have a bunch of packages that still require Python2, and where maintainers
explicitly asked to keep those in the distro [2]. Among those are pypy and
pypy3 which need Python2 for bootstrapping. I'm going to keep the
Starting with Python 3.8, Python upstream changed to a time based yearly release
schedule, targeting the first release of a major Python version (3.x) for
October of each year. For the transition to 3.8:
- we add 3.8 as supported in November
- made 3.8 the default in March
- dropped 3.7 in
Python 3.8 upstream now has a common ABI for normal and debug extension builds,
so it is technically possible to load a debug extension in the normal
interpreter, or to load a normal extension in the debug interpreter. In Debian,
debug extensions are shipped with a different name, and only loaded
On 4/30/20 5:28 AM, Scott Kitterman wrote:
> I think Python policy changes should be discussed. I accidentally committed
> a
> change to git [1] (I didn't realize I still had access, I thought it would be
> a merge request) to allow Python 3 only wheels for packages that require
> wheels, but
On 3/30/20 1:24 PM, Emilio Pozuelo Monfort wrote:
> Hi,
>
> We've just finished the transition to python3.8 as the default python3
> interpreter, which was a bit difficult due to some autopkgtest regressions in
> a
> few rdeps, and to the fact that many modules only build their extensions for
>
On 2/3/20 8:22 PM, Simon McVittie wrote:
> On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote:
>> I think this is now in shape to be started.
>
> Please can this wait until the remaining bits of the libffi7 transition
> and the restructuring of the libgcc_s packaging
On 2/2/20 5:53 PM, Rene Engelhard wrote:
> On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote:
>>> On 17-01-2020 23:28, Matthias Klose wrote:
>>>> Please add a transition tracker to switch the python3 default to 3.8.
>>>> It's not
>>>
Control: tags -1 - moreinfo
On 1/18/20 9:30 PM, Paul Gevers wrote:
> Control: tags -1 moreinfo
>
> Hi Matthias,
>
> On 17-01-2020 23:28, Matthias Klose wrote:
>> Please add a transition tracker to switch the python3 default to 3.8. It's
>> not
>> yet ready
On 24.01.20 20:00, Scott Kitterman wrote:
> I started looking into updating pip to the current release
thanks for doing that.
> packaging
the recent version is in the archive but ftbfs. it's a dh-python issue.
Matthias
On 22.01.20 02:18, Nicholas D Steeves wrote:
> I don't think this is an assumption. Debian adheres to PEP 394, which
> until recently said that /usr/bin/python is supposed to be Python 2, for
> backwards compatibility. When I discovered this I felt increased trust
> in Debian and its developers
On 09.12.19 11:46, Andreas Tille wrote:
> Hi,
>
> I have upgraded python-datrie in Git[1] to latest upstream version
> (0.8). It shows the same issue - so I admit I have no better clue than
> reporting the issue upstream which I'd rather leave to the official
> Uploader of the package.
>
> BTW,
On 02.12.19 20:28, Paul Gevers wrote:
> Hi all,
>
> On 01-12-2019 22:45, Sandro Tosi wrote:
>> Paul, this is the thread i was talking about.
>>
>> you were copied in the original email:
>> https://lists.debian.org/debian-python/2019/10/msg00098.html
>>
>> if there is something the RT wants to
On 26.11.19 11:02, Ole Streicher wrote:
> Hi,
>
> I am currently updating the "casacore" package to the latest upstream
> version. Doing this, I discovered that it is not marked as part of the
> Python 3.8 transition, and was also not binNMUed for this, although it
> has the package
On 12.11.19 23:39, Matthias Klose wrote:
> On 07.11.19 15:08, Matthias Klose wrote:
>> This weekend, I am planning to upload python3-defaults, adding python3.8 as a
>> supported Python3 version. This may introduce some churn in unstable until
>> the
>> basic bi
On 07.11.19 15:08, Matthias Klose wrote:
> This weekend, I am planning to upload python3-defaults, adding python3.8 as a
> supported Python3 version. This may introduce some churn in unstable until
> the
> basic binNMUs are available as well.
>
> Details for the addition
On 11.11.19 11:43, Yves-Alexis Perez wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2019-11-11 at 10:33 +0100, Ondřej Nový wrote:
We are going to raise the severity of the py2removal bugs to "serious"
in several steps. In the
first phase we are going to raise severity of the
This weekend, I am planning to upload python3-defaults, adding python3.8 as a
supported Python3 version. This may introduce some churn in unstable until the
basic binNMUs are available as well.
Details for the addition can be found at [1], known issues and patches are filed
[2]. There was
On 06.11.19 22:04, Nicholas D Steeves wrote:
Brian May writes:
Stéphane Blondon writes:
Perhaps there is a doubt how to read it?
- do not (remove python-foo-doc or rename it to python3-foo-doc)
- (do not remove python-foo-doc) or (rename it to python3-foo-doc)
Would it be better if we
On 03.11.19 15:09, Neil Williams wrote:
On Sun, 3 Nov 2019 15:00:17 +0100
Matthias Klose wrote:
[discussing this outside the bug report on the ML]
On 03.11.19 14:39, Neil Williams wrote:
Actually, that's a good catch. I was mixing up the defaults package
with the general advice on python3
[discussing this outside the bug report on the ML]
On 03.11.19 14:39, Neil Williams wrote:
Actually, that's a good catch. I was mixing up the defaults package
with the general advice on python3 migration to not remove
python-foo-doc just to rename it to python3-foo-doc.
where did you read
On 03.11.19 02:20, Paul Wise wrote:
On Sat, Nov 2, 2019 at 6:04 PM Matthias Klose wrote:
At this point I'd ignore any Python2 related package, and concentrate on Python3
stuff only.
Yes, I was referring only to python3-* module packages.
Byte compilation is an optimization, speeding up
On 02.11.19 04:22, Paul Wise wrote:
Hi all,
I run adequate on my system, which means I notice when Python module
packages don't bytecompile when they are installed. So far I've just
been ignoring the warnings that adequate prints.
https://salsa.debian.org/debian/adequate
In addition I
On 02.11.19 09:05, Hugo Lefeuvre wrote:
Hi Matthias,
I see that you just raised the severity of this bug to serious, and
Bleachbit is now to be removed on 16.11.
I don't think this is the way to go. Upstream is actively working on this.
We have recently managed the GTK3 migration, meaning that
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2keep;users=debian-python@lists.debian.org
doesn't show show too many packages yet, which is good. Not sure if we should
tag the dependencies of these packages with a different tag, e.g. py2keep-dep
for python-setuptools.
Im unsure if I
On 26.10.19 22:09, Rebecca N. Palmer wrote:
What should be done with modules where Python 3.8 compatibility requires moving
to a new upstream release that doesn't support Python 2, but the Python 2
package still has dependencies (so can't be removed yet under existing rules)?
- Split them
For Python2 packages, dh-python 4.20191017 now rewrites any python shebang to
/usr/bin/python2 and generates dependencies on python2 instead of python.
The py2removal bugs have a section
"""
- If the package has still many users (popcon >= 300), or is needed to
build another package which
Paul Gevers from the release team pointed out that the Python2 removal is
causing some uninstall-ability issues in testing because some packages
apparently are removed too early, but never the less are migrating to testing.
He suggested to make the removal plan more concrete and having a
On 11.10.19 18:27, Christian Kastner wrote:
Hi,
python-cachetools provides modules for Python2 and Python3.
The Python2 module as two reverse dependencies, both with low installed
popcon:
python-cachetools: 302
mopidy-podcast: 109
mopidy-internetarchive: 95
This
On 12.09.19 17:01, Ian Jackson wrote:
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
https://python3statement.org/ is a site documenting the projects which
are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge*
On 10.09.19 20:31, Richard B. Kreckel wrote:
On 10.09.19 11:29, Matthias Klose wrote:
Please read the instructions, they mention to check dependencies, build
dependencies, and test dependencies ...
I have read https://wiki.debian.org/Python/2Removal and the linked
pages. Are there any other
On 01.09.19 21:48, Martin Kelly wrote:
Hi,
I maintain python-gmpy and python-gmpy2, which need to transition to Python 3.
However, they have several packages that have Suggests or Recommends (not a hard
dependency) pointing to python-gmpy/python-gmpy2. These other packages appear to
be
confident simply uploading someone's else package.
Best would probably be if Matthias Klose, one of the current Uploaders,
agrees to that and uploads the current package thus passing over
maintainership.
Matthias?
did you see my comment in #936270?
Please file Python2 removal bugs with the appropriate attributes.
It's
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
- It's NOT "Usertag". Usertag is only recognized by the bug server.
- It's NOT "py2-removal". It's "py2removal".
See
On 24.08.19 07:03, Scott Kitterman wrote:
> On Thursday, August 15, 2019 8:08:41 AM EDT Thomas Goirand wrote:
>> Hi there!
>>
>> According to the daily graph I built here:
>> http://py2graph.infomaniak.ch/py2.7.deps.svg
>>
>> we can work on Python 2 removal for the below packages. Note that I have
On 25.08.19 00:08, Thomas Goirand wrote:
> On 8/24/19 10:38 AM, Neil Williams wrote:
>> How is that graph turned into a list of packages? It's too large to
>> scan manually.
>
> Well, I did it manually... and this is only a short list, as a
> suggestion for a todo list, so nothing exhaustive... I
On 13.08.19 15:30, peter green wrote:
> IMO python-monotonic should be reinstated until it's reverse dependencies are
> sorted out.
I agree with that.
On 16.07.19 17:31, Julien Puydt wrote:
> Le 16/07/2019 à 17:21, Andrey Rahmatullin a écrit :
>> Python 2 is included in buster and so will be supported for several
>> years.
>>
>
> The starting point of the thread was :
> 1. Ok, buster has Python 2 so even if upstream drops it, we will still
>
On 13.07.19 23:18, Emmanuel Arias wrote:
> Hello everybody,
>
> Next week will start the DebCamp and then DebConf. I would like to know
> to any debian python team member :-)
>
> Exist any plan for debian packaging during the DebCamp/DebConf?
>
> Unfortunately, I will arrive to Curitiba on 18th
On 07.07.19 16:55, Drew Parsons wrote:
> On 2019-07-07 22:46, Mo Zhou wrote:
>> Hi science team,
>>
>> By the way, when do we start dropping python2 support?
>> The upstreams of the whole python scientific computing
>> stack had already started dropping it.
>
> Good question. I think it is on
On 24.01.19 00:16, Ben Finney wrote:
> Howdy all,
>
> What is a ‘py3versions’ (or alternative) command that can be run in
> AutoPkgTest, to query the Python versions that are installed on this
> machine *with* their standard library?
>
> The ‘pythonX.Y-minimal’ packages can be installed
On 14.12.18 12:48, Simon McVittie wrote:
> Control: forwarded -1
> https://salsa.debian.org/ci-team/autopkgtest/merge_requests/42
> Control: tags -1 + patch
>
> On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote:
>> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7.
>
> This
On 05.11.18 10:32, Matthias Klose wrote:
> On 05.11.18 09:17, Michael Hudson-Doyle wrote:
>> On Mon, 5 Nov 2018 at 21:09, Thomas Goirand wrote:
>>
>>> Hi there!
>>>
>>> During Debconf, we decided we would not decide yet, and see in November
>>&
On 05.11.18 20:31, Jerome Kieffer wrote:
> On Mon, 05 Nov 2018 12:26:41 -0500
> Scott Kitterman wrote:
>
>> I only found out about it due to an upstream bug report on OS X. No one in
>> Debian (or Ubuntu) reported it.
>
> I got one also in fabio:
> https://github.com/silx-kit/fabio/pull/243
>
On 05.11.18 09:17, Michael Hudson-Doyle wrote:
> On Mon, 5 Nov 2018 at 21:09, Thomas Goirand wrote:
>
>> Hi there!
>>
>> During Debconf, we decided we would not decide yet, and see in November
>> if we think it's reasonable to allow Python 3.7 to reach Buster. Time
>> has passed, RC bugs have
sorry, I never replied to that email.
On 10.06.2018 13:59, Piotr Ożarowski wrote:
> [Matthias Klose, 2018-06-08]
>> from my point of view this doesn't address:
>>
>> - being able to de-install the python command for buster, if
>>people don't use it. Most dependen
On 14.09.2018 05:30, Joseph Herlant wrote:
> Hi guys,
>
> It's probably a mistake on my side but I'm looking for the package
> that provides the python policy locally.
>
> In https://packages.debian.org/testing/amd64/python/filelist I can see
> that the python package provides the files in the
>
On 16.07.2018 09:44, Bastian Venthur wrote:
Hi,
sorry if this question has been asked before. What is the currently recommended
way to make `python` point to `python3`? I'd like to have it set on a system
default level if possible.
There is none. Maybe in the far future when Debian doesn't
The Python 3.7 beta 5 packages are now in testing, and experimental has
python3-defaults packages which add 3.7 as a supported version. The release
candidate is expected next week, only adding Unicode 11 support, and the final
release is expected at the end of June.
I would appreciate it, if
On 19.05.2018 07:24, Stuart Prescott wrote:
Matthias Klose wrote:
The distro should get
out of the way of using the python symlink, and giving users the freedom /
choice what to do about the link.
I think I understand your rationale to stop shipping /usr/bin/python and
once the unversioned
On 04.06.2018 06:34, Scott Kitterman wrote:
On Sunday, June 03, 2018 09:26:58 PM Scott Talbert wrote:
Hi,
I've got a package (wxpython4.0) that builds modules for both Python 2.7
and Python 3. When I rebuilt the package in early May, I started getting
the lintian warning
On 18.05.2018 19:24, Piotr Ożarowski wrote:
>> A bit disappointed about this style of communication, Matthias
>
> same here (you want us to do something without explaining reasons)
> EOT for me.
well, I thought I explained in the first message. The distro should get out of
the way of using the
On 18.05.2018 18:14, Scott Kitterman wrote:
> On Friday, May 18, 2018 11:31:37 AM Matthias Klose wrote:
>> On 18.05.2018 05:19, Piotr Ożarowski wrote:
>>> [Matthias Klose, 2018-05-17]
>>>
>>>> PEP 394 [1] saw an update in April 2018 [2], the diffs at [3].
&
On 18.05.2018 19:02, Piotr Ożarowski wrote:
>> who said, that we should rename packages? The only packages being dropped are
>> the python defaults packages.
>>>
>>> I refuse to do that work!
>>
>> There is no work in renaming the packages. It's about the dependency
>> generation
>> and the
On 18.05.2018 05:19, Piotr Ożarowski wrote:
> [Matthias Klose, 2018-05-17]
>> PEP 394 [1] saw an update in April 2018 [2], the diffs at [3].
>>
>> The most important change from my point of view is
>>
>> -* It is suggested that even distribution-specific pa
PEP 394 [1] saw an update in April 2018 [2], the diffs at [3].
The most important change from my point of view is
-* It is suggested that even distribution-specific packages follow the
- ``python2``/``python3`` convention, even in code that is not intended to
+* It is strongly encouraged that
S because of
> it. :(
>
> python-setuptools (39.0.1-2) unstable; urgency=medium
>
> * Make the PKG-INFO output reproducible (Chris Lamb). Closes: #894215.
> * Stop shipping the easy_install scripts.
>
> -- Matthias Klose <d...@debian.org> Mon, 02 Apr 2018 11:46:01 +0200
On 22.04.2018 21:31, Matthew Woodcraft wrote:
> I noticed that profile-guided optimisation and link-time optimisation
> have both been unconditionally disabled in Buster's Python 3.6 and 3.7
> packages, though 3.5 in Stretch had them both enabled (on common
> platforms).
>
> Can anyone tell me
On 27.03.2018 18:39, Piotr Ożarowski wrote:
> [Matthias Klose, 2018-03-27]
>> On 26.03.2018 19:32, Piotr Ożarowski wrote:
>>> Hi,
>>>
>>> Here's a list of packages that will FTBFS soon if dh-python will not be
>>> added to Build-Depends (it's time
On 26.03.2018 19:32, Piotr Ożarowski wrote:
> Hi,
>
> Here's a list of packages that will FTBFS soon if dh-python will not be
> added to Build-Depends (it's time to drop dh-python from python3's
> Depends and old version of dh_python2 from python package).
>
>
On 07.02.2018 10:12, Ghislain Vaillant wrote:
> 2018-02-07 8:58 GMT+00:00 Matthias Klose <d...@debian.org>:
>> On 07.02.2018 08:37, W. Martin Borgert wrote:
>>> Hi,
>>>
>>> how about moving the Python team(s) to salsa?
>>> And how about merging
On 07.02.2018 08:37, W. Martin Borgert wrote:
> Hi,
>
> how about moving the Python team(s) to salsa?
> And how about merging the modules and apps teams into one?
>
> Moving git packages (modules team) is very easy using
> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git
>
>
On 10.01.2018 17:06, Ole Streicher wrote:
> Hi,
>
> I am the maintainer of the "python-astropy" package, that currently
> creates packages for both Python 2 and Python 3. Both packages have a
> number of reverse dependencies.
>
> Recently, upstream announced a new version 3.0 of astropy, which
>
On 14.12.2017 14:38, Piotr Ożarowski wrote:
> Hi,
>
> I plan to prepare new dh-python upload soon and hence a question about
> a bit controversial change: should dh_python2 (as we discussed during
> last DebConf's Python BoF) replace /usr/bin/python shebangs with
> /usr/bin/python2?
+1
1 - 100 of 383 matches
Mail list logo