Package: python3-html5lib
Version: 1.0.1-3
Severity: normal
Currently with python3.7 or 3.8:
DeprecationWarning: Using or importing the ABCs from 'collections' instead of
from 'collections.abc' is deprecated, and in 3.9 it will stop working
from collections import Mapping
When we get python3.9
On Monday, May 11, 2020 4:18:45 PM EDT Emmanuel Arias wrote:
> El lun., 11 de may. de 2020 a la(s) 17:10, Antoine Beaupré
>
> (anar...@debian.org) escribió:
> > On 2020-05-11 14:53:29, Scott Kitterman wrote:
> > > On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wro
On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wrote:
> On 2020-05-11 15:18:53, Emmanuel Arias wrote:
> > Hi,
> >
> > The upstream and pristine-tar branches are not generated on salsa for
> > any particular reason.?
>
> I'm not sure what question you are asking here. This package doesn't
On Thursday, May 7, 2020 2:00:58 PM EDT peter green wrote:
> I got a failure too when I cloned that branch and tried to build it, but
> once I added in the changes from the previous NMU it built fine. I would
> push that addition back to the branch but i'm not currently a member of the
> python
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
* Package name: python-tomlkit
Version : 0.6.0
Upstream Author : Sébastien Eustace
* URL : https://pypi.org/project/tomlkit
* License : Expat
Programming Lang: Python
Description : style
On Fri, 10 Apr 2020 02:40:07 + Scott Kitterman
wrote:
> This is not a bug. Python2 is no longer supported upstream and we are in
the process of removing it.
For anyone coming along looking for additional information, as of pip 20.1,
which as I write this is about to be uploaded to Deb
On May 2, 2020 4:17:20 AM UTC, Drew Parsons wrote:
>> pybuild will want to support it
>
>Some discussion has started on the mailing list,
>
>https://lists.debian.org/debian-python/2020/04/msg00061.html
As mentioned in the thread, there's a pybuild plugin for packages that use flit
to build
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
* Package name: python-resolvelib
Version : 0.3.0
Upstream Author : Tzu-ping Chung
* URL : https://github.com/sarugaku/resolvelib
* License : ISC
Programming Lang: Python
Description : module
According to the prelude web site:
Prelude OSS is the open source edition of Prelude SIEM . Prelude OSS is aimed
for evaluation, research and test purpose on very small environments. Please
note that Prelude OSS performances are way lower than the Prelude SIEM edition.
What testing have you
I do have something that might address this, but I'm reluctant to promise
anything until I test it.
Scott K
Additional feedback from pip upstream:
> what pipx is doing is actually a bit more interesting than I
> thought they're actually running pip via the command line as
> expected, but they're sort of creating a weird custom installed version in
> a way
> they're creating a virtual environment
On Friday, April 24, 2020 12:08:46 PM EDT Shengjing Zhu wrote:
> On Fri, Apr 24, 2020 at 11:44 PM gregor herrmann wrote:
> [...]
>
> > > Could this wiki page be more useful?
> > > https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list
> >
> > Not really; the lists we are talking
Thanks.
I don't have a good solution to the overall problem. I'm mostly concerned
about not having to fix packages with wrong maintainer addresses due to people
trying to fix this 'issue'.
Personally, I think it's inclusion is premature, but as long as the priority is
lowered, I guess I can
...
> lintian (2.67.0) unstable; urgency=medium
> .
>* Summary of tag changes:
> + Added:
...
>- mailing-list-obsolete-in-debian-infrastructure
...
What is the recommended action to resolve this warning?
For lists that aren't suitable to transition to lists.debian.org there
Package: src:kineticstools
Version: 0.6.1+20161222-1
Severity: serious
Justification: Policy 2.1
All versions of kineticstools in the archive include a non-free data
file:
doc/whitepaper/kinetics.tex
The file includes the following statement:
For Research Use Only. Not for use in diagnostic
On April 21, 2020 1:09:47 AM UTC, Vlad wrote:
>Please keep these drivers. They work as just fine, and many people
>still use them. They have not been dropped by upstream X.org, and there
>is no reason to drop them from Debian. Without these drivers, it will
>make running Debian desktop on this
Actually I was slightly wrong about the changes due to the upcoming policy
change. A copy of the license will still be needed in debian/copyright for
pkg_resources/_vendor/pyparsing.py:
setuptools/_vendor/pyparsing.py:
pkg_resources/_vendor/six.py:
setuptools/_vendor/six.py:
It's only the
=medium
+
+ * Add lintian overrides for source-contains-prebuilt-windows-binary
+to document why these files are acceptable for Debian (Closes: nn)
+
+ -- Scott Kitterman Mon, 20 Apr 2020 10:39:00 -0400
+
setuptools (45.2.0-1) unstable; urgency=medium
* New upstream version, Python3
Package: src:python-setuptools
Version: 40.8.0-1
Severity: serious
Justification: Policy 2.3
While reviewing src:setuptools in New, I noticed a number of omissions
from debian/copyright which apply to this package as well.
Copyright and license information from the following files is missing.
On Monday, April 20, 2020 8:51:10 AM EDT peter green wrote:
> On 20/04/2020 08:57, Thomas Goirand wrote:
> >> Option 1: fix all four packages to be python 2 free.
> >>
> >> Option 2: Remove python2 stuff from traceback2, python-funcsigs and
> >> numba. Break the dependencies of nipype in sid.
>
On April 20, 2020 2:36:00 AM UTC, peter green wrote:
>(using -quiet aliases where multiple involved packages have the same
>maintainer listed.
>
>Hi
>
>I have just been running some self-contained buildability tests on
>bullseye and these tests indicated that the python-linecache2 and
On April 19, 2020 1:55:20 PM UTC, Luke Kenneth Casson Leighton
wrote:
>On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System
> wrote:
>
>> #958166: python3-all: python3 can't import gmpy2
>> Python3.7 is no longer supported in Debian Unstable and Testing and
>will be removed shortly.
>
Alternately, you could just update python3-gmpy2 to the latest version of the
package, which is built to support python3.8:
https://packages.debian.org/sid/amd64/python3-gmpy2/filelist
Python3.7 is no longer supported in Debian Unstable and Testing and will be
removed shortly.
What you are
On April 18, 2020 10:03:01 AM UTC, Adrian Bunk wrote:
>On Mon, Mar 23, 2020 at 09:43:19PM +0100, Paul Gevers wrote:
>> Source: pythonmagick
>> Version: 0.9.19-6
>> X-Debbugs-CC: debian...@lists.debian.org
>> Severity: serious
>> User: debian...@lists.debian.org
>> Usertags: regression
>>
>>
Package: tpm2-tools
Version: 4.1.1-1
Severity: serious
Justification: Policy 3.3
Policy requires a valid maintainer email address. Please see below:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
Package: clang-tidy-6.0
Version: 1:6.0.1-14
Severity: serious
The clang-tidy-6.0 package depends on python-yaml, which is now NBS and
will be removed from Testing at some point. I understand that llvm 6.0
is sticking around to support ghc, but is clang-tidy needed for that?
If that binary could
Package: python-reclass
Version: 1.4.1-3.1
Severity: serious
Python-yaml is now NBS and will be removed from Testing at some point.
Python-reclass either needs to drop the python-yaml depends (I haven't
investigated if this is feasible) or move to python3 and depend on
python3-yaml.
I'm aware
The proposed change in https://github.com/yaml/pyyaml/pull/394 resolves this
issue.
Scott K
signature.asc
Description: This is a digitally signed message part.
> The new version of kubernetes is not a reverse build-dependency anymore.
> There are individual RM requests for the remaining blockers: #956741 and
> #956743. I removed the moreinfo tag to signal that the FTP masters can go
> ahead and remove golang-github-docker-engine-api in the same batch
Still a problem:
File "/usr/lib/python3/dist-packages/yaml/__init__.py", line 114, in load
return loader.get_single_data()
File "/usr/lib/python3/dist-packages/yaml/constructor.py", line 49, in
get_single_data
node = self.get_single_node()
File
On Tuesday, April 14, 2020 9:22:37 AM EDT Mattia Rizzolo wrote:
> On Tue, Apr 14, 2020 at 08:41:01AM -0400, Scott Kitterman wrote:
> > The package python-pip-whl is a special case of a Python package built
> > to work with either python or python3. Currently python3-vert
Package: lintian
Version: 2.65.0
Severity: normal
The package python-pip-whl is a special case of a Python package built
to work with either python or python3. Currently python3-vertualenv
gets the following lintian warning:
W: python3-virtualenv:
Actually nevermind. Once I decrufted uswgi it was fine.
Scott K
signature.asc
Description: This is a digitally signed message part.
Looks good.
Scott K
signature.asc
Description: This is a digitally signed message part.
Package: wnpp
Severity: wishlist
* Package name: python3-sphinx-better-theme
Version : 0.1.5
Upstream Author : Steve Johnson
* URL : https://pypi.org/project/sphinx-better-theme
* License : Expat
Programming Lang: Python
Description : modified version
On Tuesday, April 7, 2020 7:18:42 PM EDT Guillem Jover wrote:
> > +#. the distribution license for those files requires that copyright
> > + information be included in all copies and/or binary distributions;
>
> I'm assuming the entire list is supposed to hold at the same time? If
> so perhaps
Package: sabnzbdplus
Version: 2.3.6+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag since it is the closest one we have.
sabnzbdplus depends on python-cheetah, which is not longer built by
cheetah.
What's the status on getting this fixed? This is causing quite a backlog on
Testing migration.
requests Migrates after: datalad-container
python-urllib3 Migrates after: requests
python-certifi Migrates after: requests
python-pip Migrates after: python-certifi, python-urllib3, requests
Those I
On Fri, 3 Apr 2020 21:55:04 +0200 Lucas Nussbaum wrote:
> Source: python-tablib
> Version: 0.13.0-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed
On Sat, 04 Apr 2020 14:36:57 -0700 Sean Whitton
wrote:
> Hello Scott,
>
> On Thu 26 Mar 2020 at 03:01PM -04, Scott Kitterman wrote:
>
> > On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote:
> >> 4. License requires copyright notice but doesn't specify
On Mon, 12 Mar 2018 14:53:11 +0100 Bernhard Reiter
wrote:
> Package: python3-pip
> Version: 9.0.1-2
> Severity: normal
>
> Hi Maintainers,
>
> according to `pip help install`::
>
> --user
> [..]
> On Debian systems, this is the default when running outside of a
> virtual environment and
On Fri, 10 May 2019 19:30:58 +0200 =?UTF-8?Q?Josu=c3=a9_Tille?=
wrote:
> Package: python-pip
>
> Hello,
>
>
>
> Debian version : 9.9
>
> probable package : python-pip 9.0.1-2+deb9u1
>
>
> I detected that since some days the install of package with pip fail
> randomly with this stacktrace:
On Friday, April 3, 2020 10:57:10 AM EDT Jörg-Volker Peetz wrote:
> Package: python3-pip
> Version: 20.0.2-3
> Severity: wishlist
>
> Dear Debian Python Modules Team,
>
> this package is one of two on my system which still depends on
> python3.7. When is the shift to dependency on python3.8
Package: dh-python
Version: 4.20200315
Severity: important
Currently (with python3.7 and 3.8 supported and python3.8 as default),
dh_python3 generates a python3.7 dependency for python3-pip. This is
not needed and actively harmful.
Please see the attached verbose dh_python3 log. It shows the
On Tue, 31 Mar 2020 15:03:30 -0400 Scott Kitterman
wrote:
> On Fri, 27 Mar 2020 08:50:28 -0400 Scott Kitterman
> wrote:
> > On Fri, 27 Mar 2020 01:39:04 -0400 Scott Kitterman
> > wrote:
> > > On Fri, 27 Mar 2020 01:25:28 -0400 Scott Kitterman
> >
On Tue, 30 Oct 2018 21:50:36 +0100 Ben Wiederhake
wrote:
> Package: python3-pip
> Version: 9.0.1-2.3
> Severity: normal
> File: /usr/bin/pip3
>
> Dear Maintainer,
>
> I'm having trouble running this command:
>
> pip3 list --outdated
>
> Expected behavior: A list of outdated, local
On Tue, 17 Mar 2020 10:38:23 -0400 Scott Kitterman
wrote:
> On Fri, 10 Jan 2020 00:02:12 -0800 Nye Liu wrote:
> > this bug is now more than a year old.
> >
> > Please update python3-pip and python-pip packages to >19.1
>
> The same problem still exists with
On Tue, 31 Mar 2020 14:31:40 +0200 Christoph Reiter
wrote:
> Package: python3-pip
> Version: 20.0.2-2
> Severity: important
>
> Dear Maintainer,
>
> (Note: This doesn't affect upstream pip, only the Debian/Ubuntu version)
>
> pip in Debian (and Ubuntu focal) fails to install Python packages
Package: src:python-bleach
Version: 3.1.2-0+deb10u1
Severity: important
Tags: security
Once again with a python-bleach security issue...
https://github.com/mozilla/bleach/security/advisories/GHSA-vqhp-cxgc-6wmm
Title
regular expression denial-of-service (ReDoS) in
(Closes:
+#954478)
+
+ -- Scott Kitterman Sat, 28 Mar 2020 17:45:23 -0400
+
python-pbkdf2 (1.3+20110613.git2a0fb15~ds0-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control python-pbkdf2-1.3+20110613.git2a0fb15~ds0
On Wed, 25 Mar 2020 22:18:52 -0300 eamanu wrote:
> Hi,
>
> I attach a NMU patch. Please, consider apply it.
I intend to sponsor this.
Scott K
signature.asc
Description: This is a digitally signed message part.
On Wed, 25 Mar 2020 22:01:38 -0300 eamanu wrote:
> Hi,
>
> I attach a NMU patch. Please, consider apply it.
RC bug with no maintainer response for 7 days, so I intend to sponsor this.
Scott K
signature.asc
Description: This is a digitally signed message part.
On Wed, 25 Mar 2020 14:16:23 -0300 eamanu wrote:
> Hi,
>
> I attach a NMU patch. Please consider apply it.
RC bug with no maintainer response for 7 days, so I intend to sponsor this.
Scott K
signature.asc
Description: This is a digitally signed message part.
On Wed, 25 Mar 2020 11:07:49 -0300 eamanu wrote:
> Hi,
>
> I attach a NMU patch. Please, consider apply it.
RC bug with no response from the maintainer for a week, so I intend to sponsor
this.
Scott K
signature.asc
Description: This is a digitally signed message part.
On Friday, March 27, 2020 12:53:41 PM EDT Benjamin Drung wrote:
> Hi,
>
> Am Dienstag, den 17.03.2020, 09:47 -0400 schrieb Scott Kitterman:
> > Package: src:salt
> > Version: 3000+dfsg1-3
> > Severity: serious
> > Justification: Policy 2.2.1
> >
>
On Fri, 27 Mar 2020 01:39:04 -0400 Scott Kitterman
wrote:
> On Fri, 27 Mar 2020 01:25:28 -0400 Scott Kitterman
> wrote:
> > I can replicate this with the current pip in unstable (which is the
current
> > upstream release). We kept pep517 at version 0.7.0 because tha
On Thu, 19 Mar 2020 12:20:05 + Scott Kitterman
wrote:
> Thanks. The virtualenv package needs updating following the recent pip
update. I'm working on it.
I can still replicate this with the new virtualenv. Here's the verbose
version for posterity:
Installing collected packa
On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote:
> 4. License requires copyright notice but doesn't specify anything about
> source or binary (didn't look for an example, but I can totally see this
> happening): I think this case is unclear with your revise
mmary of what the FTP Team require when
>it
>comes to copyright information, and as another FTP Team member, I
>concur
>with his assessment of the consensus within the team:
>
>On Thu 26 Mar 2020 at 10:32AM -04, Scott Kitterman wrote:
>
>> I think you assume we're looking fo
Package: azure-cli
Version: 2.0.81+ds-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it is the closest one we have.
Now that humanfriendly is fixed to provide the missing files, azure-cli
has what
Source: dateparser
Version: 0.7.2-1
Severity: normal
The current pip based install for the test includes two module not in
Debian:
jdatetime==3.1.0
umalqurra==0.2
As a result, 7 tests are skipped. Presumably this means that related
functionality isn't available to users of the Debian package.
Package: python3-dateparser
Version: 0.7.2-1
Severity: important
While investigating what the minimal package set that python3-dateparser
needs to run its tests, I learned that adding python3-convertdate to the
test environment causes 107 additional test cases to run. This seems
like it's an
Package: python3-convertdate
Version: 2.1.3-2
Severity: normal
When installing python3-convertdate in Unstable, where python3.8 is the
default python3, the following warning is emitted:
Setting up python3-convertdate (2.1.3-2) ...
/usr/lib/python3/dist-packages/convertdate/utils.py:27:
Package: python3-dateparser
Version: 0.7.2-1
Severity: normal
While investigatin a resolution for #954147, I noticed the following
warning being emitted. Presumably this will turn to an error in the
future and should, at some point, be addressed:
2019-10-05 21:50:32.0 -0400
+++ python-stem-1.7.1/debian/changelog 2020-03-24 16:47:02.0 -0400
@@ -1,3 +1,10 @@
+python-stem (1.7.1-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add fix from upstream to fix dictionary key error (Closes: #953863
+
+ -- Scott Kitterman
@@
+ariba (2.14.4+ds-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build for all supported python3 versions to fix test failures in complex
+Python environments and ease python3 transitions (Closes: #951944)
+
+ -- Scott Kitterman Tue, 24 Mar 2020 11:14:59 -0400
+
ariba (2.14.4
Source: kopanocore
Version: 8.7.0-7
Severity: important
Currently kopanocore is failing tests with python3-defaults that has
python3.8 as default + Testing to test python3-defaults migration.
Additionally, kopanocore can't migrate from Unstable to Testing before
python3-defualts.
The reason for
@@ -1,3 +1,10 @@
+lintian (2.59.0+) UNRELEASED; urgency=medium
+
+ * Update old and ancient python-version-field tag text to suggest also
+checking for incorrect use of py3verions -r
+
+ -- Scott Kitterman Mon, 23 Mar 2020 20:55:28 -0400
+
lintian (2.59.0) unstable; urgency=medium
[ Chris
The problem here is that py3versions -r falls back to supported versions when
no X-Python3-Versions header field is present in debian/control and pythonmagic
is only built for the current version:
https://packages.debian.org/sid/amd64/python3-pythonmagick/filelist
(shows only python3.8
Package: src:xapers
Version: 0.8.2-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The following autopkgtest log extracted from [1] should be enough to
show the problem. It is currently showing up as a regression for
python3.8 as
Package: release.debian.org
Severity: normal
Python-pip is actually ready to migrate, but there are problems that
will take manual intervention to address:
1. Autopkgtest regressions marked against doit and logbook:
Both tests are RC buggy (and bugs filed). It's true that updating pip
Package: lintian
Version: 2.59.0
Severity: normal
Is recently discussed in a thread on debian-devel [1] there is a common
error in python related auotpkgtests where py3verions -i is used to loop
over 'installed' python3 versions. This is currently causing a
substantial number of failures since
Package: src:pyx3
Version: 0.15-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults
Package: src:wand
Version: 0.5.9-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:python3-proselint
Version: 0.10.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:python-tinyrpc
Version: 0.6-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:python-jsonext
Version: 0.4.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:python-pynvim
Version: 0.4.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:python-pbkdf2
Version: 1.3+20110613.git2a0fb15~ds0-3.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of
Package: src:python-jsbeautifier
Version: 1.10.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:pystemd
Version: 0.7.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:python-h2
Version: 3.2.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:python-daemon
Version: 2.2.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:pysha3
Version: 1.0.2-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag since that's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:pyethash
Version: 0.1.27-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag since that's the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:pyrlp
Version: 0.5.1-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag since it's the closes we have
This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults
Package: src:pydbus
Version: 0.6.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it's the closest one we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:editorconfig-core-py
Version: 0.12.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Used FTBFS as a tag, since it's the closes we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:m2crypto
Version: 0.31.0-9
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using FTBFS as a tag since it is the closest we have.
This package failed a recent autopkgtest and this is one of the blockers for
Package: src:ariba
Version: 2.14.4+ds-2
Followup-For: Bug #951944
This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration. It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.
Autopkgtests should
Now that I see PAPT is the maintainer, I guess it would be a team upload, not
an NMU. In any case if someone has a plan other than dropping the tests,
please say so in the bug.
Scott K
signature.asc
Description: This is a digitally signed message part.
Package: src:tox
Version: 3.13.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using FTBFS to cover autopkgtest failure as it is a rough
equivalent (package can't migrate to testing).
The python-virtualenv package can no
On Sat, 22 Feb 2020 10:54:23 +0100 Kay Hayen wrote:
> Hello,
>
> this is not explained in the FAQ, but the way I have done it is like this
> (in build-depends, removed irrelevant parts):
>
>python (>= 2.6.6-2) | base-files (>= 11),
>python-all-dbg (>= 2.6.6-2) |
On Thursday, March 19, 2020 6:24:22 PM EDT Salvatore Bonaccorso wrote:
> Hi Scott,
>
> On Thu, Mar 19, 2020 at 12:20:25AM -0400, Scott Kitterman wrote:
> > Upstream's 3.1.2 release had just the security fix in it. I propose
> > updating buster with it (I put 3.1.3 in uns
On Tue, 17 Mar 2020 17:34:06 -0400 Scott Kitterman
wrote:
...
> As I mentioned in the automake-1.16 bug, these are the last two packages
that
> use python-virutalenv, so I'd really like to see them updated to unblock
other
> work.
>
> Thanks.
>
> Scott K
It's now
On Tue, 17 Mar 2020 17:24:25 -0400 Scott Kitterman
wrote:
...> Automake-1.15 and automake-1.16 are the last two packages using python-
> virtualenv in Debian Testing. We would like to move forward with the
removal
> soon as it blocks other work. As a result, I'm going to bump
I know this is marked py2keep, but I don't think we can. Our virtualenv is 5
years old and really needs updated. The brings in a requirement for pip in
the base virtualenv which then needs a wheel for ipaddr (which is already out
of testing) and python-pip, which has already been dropped.
I
I'm about to upload this with python2 restored. Python-automat, which is a
dependency of python-twisted-core (which is not close to being removed)
depends on this and currently can't migrate to Testing because of the lack of
this package.
This is entangled with the python3.8 as default
On Thursday, March 19, 2020 7:14:12 AM EDT you wrote:
> Package: ftp.debian.org
> Followup-For: Bug #953942
>
> Wow. Gone in 4 days.
> While I can understand that ftpmasters are triggerhappy due to the py2
> removal, that seems excessive.
>
> As for the "no upstream activity", that tends to
Thanks. The virtualenv package needs updating following the recent pip update.
I'm working on it.
Scott K
301 - 400 of 3028 matches
Mail list logo
