Bug#934264: Please update (4.6.2?) and provide/switch to python3
On Tue, Dec 24, 2019 at 07:50:52AM +0100, Andreas Tille wrote:
> On Mon, Dec 23, 2019 at 11:59:03PM +0200, Adrian Bunk wrote:
> > On Fri, Aug 09, 2019 at 10:39:06AM +0200, Andreas Tille wrote:
> > > self._gen_get_methods(klass, out)
> > > File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 919, in
> > > _gen_get_methods
> > > if len(sig) == 1 and sig[0][1] is None:
> > > TypeError: object of type 'NoneType' has no len()
> > > E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1:
> > > /usr/bin/python3 setup.py build
> > > dh_auto_build: pybuild --build -i python{version} -p 3.7 returned exit
> > > code 13
> > > make: *** [debian/rules:10: build] Error 255
> > > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > > I: copying local configuration
> > > E: Failed autobuilding of package
> > >...
> >
> > This one seems fixed by removing the vtk_63.py patch.
> > Next comes some error that goes away with python3-traits (just passed NEW).
> > That's not sufficient for building, but a bit further.
>
> Thanks a lot for your investigation. I also made some steps further.
> It seems xvfb is needed for the tests and I added it. The current
> failure is:
>
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/mayavi2-4.7.1'
> xvfb-run --auto-servernum --server-args="-screen 0 1024x768x24" dh_auto_test
> I: pybuild base:217: cd /build/mayavi2-4.7.1/.pybuild/cpython3_3.7/build;
> python3.7 -m unittest discover -v
> QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/1454',
> please create it with 0700 permissions.
> QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/1454',
> please create it with 0700 permissions.
> dbus[368675]: D-Bus library appears to be incorrectly set up: see the manual
> page for dbus-uuidgen to correct this issue. (Failed to open
> "/var/lib/dbus/machine-id": No such file or directo; Failed to open
> "/etc/machine-id": No such file or directory)
> D-Bus not built with -rdynamic so unable to print a backtrace
> Aborted
> E: pybuild pybuild:341: test: plugin distutils failed with: exit code=134: cd
> /build/mayavi2-4.7.1/.pybuild/cpython3_3.7/build; python3.7 -m unittest
> discover -v
> dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
> ...
>
>
> Seems some dbus / systemd issue. Any ideas?
Works for me (with test failures later), but I am using plain chroot.
Problems related to running graphical tests are not something I would
care too much about right now, important would be that the package
builds and works.
After disabling the tests and dh_numpy -> dh_numpy3 in debian/rules the
package builds for me.
Trying to install the resulting package fails with:
E: Package 'python3-wxgtk3.0' has no installation candidate
E: Package 'python3-envisage' has no installation candidate
python3-wxgtk4.0 exists (not sure whether it also works with mayavi2).
python-envisage has not yet been converted to Python3 and seems to be required:
$ mayavi2
Traceback (most recent call last):
File "/usr/bin/mayavi2", line 464, in
from mayavi.plugins.app import Mayavi, setup_logger
File "/usr/lib/python3/dist-packages/mayavi/plugins/app.py", line 19, in
from .mayavi_workbench_application import MayaviWorkbenchApplication
File
"/usr/lib/python3/dist-packages/mayavi/plugins/mayavi_workbench_application.py",
line 13, in
from envisage.ui.workbench.api import WorkbenchApplication
ModuleNotFoundError: No module named 'envisage'
> Kind regards
>
> Andreas.
cu
Adrian
Bug#947235: port patches to gcc-10
I just uploaded cross-gcc-dev=241. A patch stack for gcc-10 is included. The patches apply (they come from a git tree, as all the other patch stacks). I have not actually attempted to build a compiler using these patches, and clearly I have not tested the output from such compiler. Please let me know if something doesn't work.
Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
Control: severity -1 serious On Mon, 23 Dec 2019 at 22:30, Dirk Eddelbuettel wrote: > I would be very surprised if these were not self-inflicted by us. I know CRAN > (much) better than BioC, but both of them are doing extensive self-tests (and > generally without any arbitrary restrictions, say about timing and versions) > we may impose. This situation reminds me of #877288, where I believe Debian's autopkgtests detected the problem before upstream. > I tried a quick test on a Debian testing machine I use for (extensive) > reverse dependency checks (at the upstream level) but it was incloncusive. Hopefully we get an answer from upstream BioConductor soon. > Still a pity that r-base is held back by this. This is better than allowing a package that breaks others to migrate into testing. If there is no progress for some time, Release Team may remove r-bioc-iranges and r-bioc-s4vectors from testing to allow r-base to migrate, as in any other transition.
Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...
* Ximin Luo [191223 12:58]: > dpkg and all other debian tools support it right now. It is only reprepro > with this artifical constraint, which makes it not work for packages that are > processable by dpkg and other debian tools. If it is artifical, then it is artifically high. It is 128 times more than what almost every single package needs and more than five times what the most absurd package before needed and twice what other tools are said to have had as limit there. I will increase it in reprepro (and maybe might make it configurable to some extent), but there will always be an upper limit. > Are you suggesting that dpkg and other tools have a concrete security problem? dpkg does not check checksums of index files, so it is likely uneffected. If apt has no limit then that likely makes some attacks needlessly easy (though it might have other mitigations in that regard, and there are less things apt has to care about the way it is typically used). Accepting absurd input without confirmation is never a secure way to handle things, though. Bernhard R. Link
Bug#940327: reopen: is not yet uploaded
Control: reopen -1 Sorry for the noise, Andreas.
Bug#947287: python3-certifi: ships useless cacert.pem file
On 24/12 00:19, Thorsten Glaser wrote: > While the package is patched to return the system location, > it still ships /usr/lib/python3/dist-packages/certifi/cacert.pem > which causes the .deb to be larger than it must. > > Furthermore it might lead people to believe using that bundle > is acceptable by hardcoding a path to it. That cacert.pm is 275KB, and I believe it's important that people have it readily available should they choose to run comparisons or what not with the upstream cert store. README.Debian describes this somewhat accurately I believe (although it could probably be rephrased, patches welcome) but at this point I don't think I want to remove upstream's cert store. Before tagging this wontfix, however, I'm of course open to hearing further arguments. Cheers, -- Seb
Bug#936165: autodocktools and mgltools-pmv are about to be removed from Debian
On Tue, Dec 24, 2019 at 01:27:23AM -0500, Sandro Tosi wrote: > On Tue, Dec 24, 2019 at 1:23 AM Andreas Tille wrote: > > I reassigned the old bugs (#936165, #937029) to ftp.debian.org since > > the packages should be removed from Debian. > > i dont think that was correct: a new bug should have been filed for > the RM and the old py2removal bugs should have been kept assigned to > their relative source packages. this keeps things clean and avoids > automations like this to fail because they cant find a bug where there > should be one. I assumed that the removal would happen way faster. Given that's not the case I agree with you that it was not the best idea. Kind regards, Andreas. -- http://fam-tille.de
Bug#934264: Please update (4.6.2?) and provide/switch to python3
On Mon, Dec 23, 2019 at 11:59:03PM +0200, Adrian Bunk wrote:
> On Fri, Aug 09, 2019 at 10:39:06AM +0200, Andreas Tille wrote:
> > self._gen_get_methods(klass, out)
> > File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 919, in
> > _gen_get_methods
> > if len(sig) == 1 and sig[0][1] is None:
> > TypeError: object of type 'NoneType' has no len()
> > E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1:
> > /usr/bin/python3 setup.py build
> > dh_auto_build: pybuild --build -i python{version} -p 3.7 returned exit code
> > 13
> > make: *** [debian/rules:10: build] Error 255
> > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > I: copying local configuration
> > E: Failed autobuilding of package
> >...
>
> This one seems fixed by removing the vtk_63.py patch.
> Next comes some error that goes away with python3-traits (just passed NEW).
> That's not sufficient for building, but a bit further.
Thanks a lot for your investigation. I also made some steps further.
It seems xvfb is needed for the tests and I added it. The current
failure is:
...
debian/rules override_dh_auto_test
make[1]: Entering directory '/build/mayavi2-4.7.1'
xvfb-run --auto-servernum --server-args="-screen 0 1024x768x24" dh_auto_test
I: pybuild base:217: cd /build/mayavi2-4.7.1/.pybuild/cpython3_3.7/build;
python3.7 -m unittest discover -v
QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/1454',
please create it with 0700 permissions.
QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/1454',
please create it with 0700 permissions.
dbus[368675]: D-Bus library appears to be incorrectly set up: see the manual
page for dbus-uuidgen to correct this issue. (Failed to open
"/var/lib/dbus/machine-id": No such file or directo; Failed to open
"/etc/machine-id": No such file or directory)
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=134: cd
/build/mayavi2-4.7.1/.pybuild/cpython3_3.7/build; python3.7 -m unittest
discover -v
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
...
Seems some dbus / systemd issue. Any ideas?
Kind regards
Andreas.
--
http://fam-tille.de
Bug#937449: severity of 937449 is normal, retitle 937449 to RM: RoQA: pygopherd, python2, not in testing ...
On Mon, 23 Dec 2019 09:30:55 + Dimitri John Ledkov wrote: > severity 937449 normal > retitle 937449 RM: RoQA: pygopherd, python2, not in testing > found 937449 > reassign 937449 ftp.debian.org > thanks > > > Dimitri, please do not reassign py2removal bugs to ftp.d.o for removal, but file new ones, otherwise we're just removing a valid bug from the source package view for no good reason. thanks
Bug#936165: autodocktools and mgltools-pmv are about to be removed from Debian
On Tue, Dec 24, 2019 at 1:23 AM Andreas Tille wrote: > I reassigned the old bugs (#936165, #937029) to ftp.debian.org since > the packages should be removed from Debian. i dont think that was correct: a new bug should have been filed for the RM and the old py2removal bugs should have been kept assigned to their relative source packages. this keeps things clean and avoids automations like this to fail because they cant find a bug where there should be one. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#936165: autodocktools and mgltools-pmv are about to be removed from Debian
Hi Sandro, I reassigned the old bugs (#936165, #937029) to ftp.debian.org since the packages should be removed from Debian. Kind regards Andreas. On Mon, Dec 23, 2019 at 10:43:00PM -0500, Sandro Tosi wrote: > Source: autodocktools > Version: 1.5.7-4 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests, in details: > > (source:autodocktools)Build-Depends->python > (binary:autodocktools)Depends->python:any > (binary:autodocktools)Depends->python:any > (binary:autodocktools)Depends->python-imaging-tk > > Please stop using Python2, and fix this issue by one of the following > actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#936992: maradns: diff for NMU version 2.0.13-1.3
Control: tags 936992 + patch
Control: tags 936992 + pending
Dear maintainer,
I've prepared an NMU for maradns (versioned as 2.0.13-1.3) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.
cu
Adrian
diff -Nru maradns-2.0.13/debian/changelog maradns-2.0.13/debian/changelog
--- maradns-2.0.13/debian/changelog 2016-08-09 22:39:43.0 +0300
+++ maradns-2.0.13/debian/changelog 2019-12-24 07:48:25.0 +0200
@@ -1,3 +1,11 @@
+maradns (2.0.13-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add upstream fixes to make bind2csv2.py compatible with Python 3,
+thanks to Sam Trenholme. (Closes: #936992)
+
+ -- Adrian Bunk Tue, 24 Dec 2019 07:48:25 +0200
+
maradns (2.0.13-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru maradns-2.0.13/debian/control maradns-2.0.13/debian/control
--- maradns-2.0.13/debian/control 2015-10-03 10:37:13.0 +0300
+++ maradns-2.0.13/debian/control 2019-12-24 07:48:25.0 +0200
@@ -4,7 +4,7 @@
Maintainer: Dariusz Dwornikowski
Build-Depends:
debhelper (>= 9),
- python-dev (>= 2.6.6-3~)
+ python3-dev
Standards-Version: 3.9.6
Homepage: http://maradns.org
Vcs-Git: git://anonscm.debian.org/collab-maint/maradns.git
@@ -17,10 +17,10 @@
duende (>= 1.4.12),
lsb-base,
${misc:Depends},
- ${shlibs:Depends}
+ ${shlibs:Depends},
+ ${python3:Depends}
Recommends:
- maradns-zoneserver,
- ${python:Depends}
+ maradns-zoneserver
Suggests:
maradns-deadwood
Description: simple security-focused authoritative Domain Name Service server
diff -Nru maradns-2.0.13/debian/patches/bind2csv2-py3.patch maradns-2.0.13/debian/patches/bind2csv2-py3.patch
--- maradns-2.0.13/debian/patches/bind2csv2-py3.patch 1970-01-01 02:00:00.0 +0200
+++ maradns-2.0.13/debian/patches/bind2csv2-py3.patch 2019-12-24 07:48:25.0 +0200
@@ -0,0 +1,437 @@
+Description: Upstream fixes to make bind2csv2.py compatible with Python 3
+Author: Adrian Bunk
+Bug-Debian: https://bugs.debian.org/936992
+
+--- maradns-2.0.13.orig/tools/bind2csv2.py
maradns-2.0.13/tools/bind2csv2.py
+@@ -1,6 +1,8 @@
+ #!/usr/bin/python
+
+-# Copyright (c) 2006-2007 Sam Trenholme
++# Note: As of 2019, this script will run both in python2 and python3
++
++# Copyright (c) 2006-2007,2019 Sam Trenholme
+ #
+ # TERMS
+ #
+@@ -173,7 +175,7 @@ class buf:
+ elif self.l == "/origin":
+ return "preorigin"
+ else:
+- print "Unknown directive " + self.l
++ print("Unknown directive " + self.l)
+ return "error"
+
+ # Add a current RR to a stream (private method)
+@@ -282,7 +284,7 @@ def process_comment(i,o):
+ z = 0
+ op(o,"#")
+ while z < 1000:
+- a = i.read(1)
++ a = i.read(1).decode('utf-8')
+ if is_newline.match(a):
+ return a
+ else:
+@@ -294,7 +296,7 @@ def process_comment(i,o):
+ # in next
+
+ def get_rr_type(rrname):
+- rrname = string.lower(rrname)
++ rrname = rrname.lower()
+ if rrname == "in":
+ return "error"
+ elif rrname == "a":
+@@ -357,7 +359,7 @@ def get_rr_type(rrname):
+ #return "rr_loc" # Complicated RR with variable # of fields
+ return "rr_variargs" # I'll just let the csv2 code parse this
+ else:
+- print "Error: Unknown RR " + rrname
++ print("Error: Unknown RR " + rrname)
+ return "error"
+
+ # Generic handler that handles parenthesis in a zone file
+@@ -366,10 +368,10 @@ def handle_paren(a,o,state,buffer):
+ if is_pstate.search(state):
+ paren = "_paren"
+ if paren == "" and is_newline.match(a):
+- print "Error: Premature termination of RR"
++ print("Error: Premature termination of RR")
+ return ("error", "", 1, paren)
+ if paren == "_paren" and a == "(":
+- print "Error: Parens don't nest"
++ print("Error: Parens don't nest")
+ retrun ("error", "", 1, paren)
+ if paren == "" and a == "(":
+ op(o," ")
+@@ -413,7 +415,7 @@ def postrr(a,o,state,buffer):
+ (state, buffer, paren, pstr) = handle_paren(a,o,state,buffer)
+ if paren == 1:
+ return (state, buffer)
+- print "Error: Unexpected character after RR " + a
++ print("Error: Unexpected character after RR " + a)
+ return("error","")
+
+ # After the first non-escaped newline at the end of a rr in the
+@@ -433,7 +435,7 @@ def pre_rr(a,o,state,buffer):
+ o.label_reset()
+ o.label_add(a)
+ return("dlabel",buffer)
+- print "Error: Unexpected character before RR " + a
++ print("Error: Unexpected character before RR " + a)
+ return("error","")
+
+ # In the whitespace before a default TTL ("/ttl 12345")
+@@ -445,7 +447,7 @@ def prettl(a,o,state,buffer):
+ op(o,a)
+ o.slash_ttl_set(a)
+ return ("sttl", buffer)
+- print "Error: unexpected character before TTL " + a
++ print("Error: unexpected character before TTL " + a)
+ return("error","")
+
+ # In a default TTL ("/ttl 12345")
+@@ -457,7 +459,7 @@ def sttl(a,o,state,buffer):
+ op(o,a)
+ o.slash_ttl_append(a)
+ return ("sttl", buffer)
+- print "Error: unexpected character in TTL " + a
++ print("Error: unexpected character in TTL " + a)
+ return("e
Bug#947304: RFS: golang-github-xanzy-go-gitlab/0.22.2-1 [ITP] -- Simple and uniform GitLab API for Go
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: Julian Gilbey X-Debbugs-CC: Sebastien Delafond X-Debbugs-CC: Dominique Dumont X-Debbugs-CC: debian...@lists.debian.org Dear mentors, This package is a prerequisite for two upcoming packages: git-lab (#898246) and citop (#947187). I am looking for a sponsor for my package "golang-github-xanzy-go-gitlab" * Package name: golang-github-xanzy-go-gitlab Version : 0.22.2-1 Upstream Author : Sander van Harmelen * URL : https://github.com/xanzy/go-gitlab * License : Apache-2.0 * Vcs : https://salsa.debian.org/go-team/packages/golang-github-xanzy-go-gitlab Section : devel It builds those binary packages: golang-github-xanzy-go-gitlab-dev - Simple and uniform GitLab API for Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-xanzy-go-gitlab Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-xanzy-go-gitlab/golang-github-xanzy-go-gitlab_0.22.2-1.dsc Changes since the last upload: * New upstream version (Closes: #906986) * Update d/copyright for new files * Bump debhelper to 12 * Use debhelper-compat. * Set Rules-Requires-Root: no * Set Standard-Version to 4.4.1. Regards, -- Felix Lechner
Bug#936829: lcm: diff for NMU version 1.3.1+repack1-2.3
Control: tags 936829 + patch
Control: tags 936829 + pending
Dear maintainer,
I've prepared an NMU for lcm (versioned as 1.3.1+repack1-2.3) and
uploaded it to DELAYED/15. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru lcm-1.3.1+repack1/debian/changelog lcm-1.3.1+repack1/debian/changelog
--- lcm-1.3.1+repack1/debian/changelog 2019-08-08 05:19:29.0 +0300
+++ lcm-1.3.1+repack1/debian/changelog 2019-12-24 07:22:19.0 +0200
@@ -1,3 +1,10 @@
+lcm (1.3.1+repack1-2.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove the Python2 bindings. (Closes: #936829)
+
+ -- Adrian Bunk Tue, 24 Dec 2019 07:22:19 +0200
+
lcm (1.3.1+repack1-2.2) unstable; urgency=medium
* Replace previous NMU with a new source-only upload.
diff -Nru lcm-1.3.1+repack1/debian/control lcm-1.3.1+repack1/debian/control
--- lcm-1.3.1+repack1/debian/control 2019-08-08 03:49:36.0 +0300
+++ lcm-1.3.1+repack1/debian/control 2019-12-24 07:22:13.0 +0200
@@ -5,7 +5,6 @@
Build-Depends: debhelper (>= 9), dh-autoreconf,
libglib2.0-dev, libtool,
liblua5.2-dev, lua5.2,
- python, python2.7-dev,
default-jdk-headless | java-sdk, libjchart2d-java, libhamcrest-java, junit,
doxygen
Standards-Version: 3.9.8
@@ -63,21 +62,6 @@
.
This package provides the lua interface.
-Package: python-liblcm
-Architecture: any
-Depends: liblcm1 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends},
- ${python:Depends},
- liblcm-bin
-Provides: ${python:Provides}
-Description: Lightweight Communications and Marshalling
- LCM is a set of libraries and tools for message passing and data marshalling,
- targeted at real-time systems where high-bandwidth and low latency are
- critical. It provides a publish/subscribe message passing model and automatic
- marshalling/unmarshalling code generation with bindings for applications in a
- variety of programming languages.
- .
- This package provides the python interface.
-
Package: liblcm-java
Architecture: any
Depends: liblcm1 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends},
diff -Nru lcm-1.3.1+repack1/debian/python-liblcm.install lcm-1.3.1+repack1/debian/python-liblcm.install
--- lcm-1.3.1+repack1/debian/python-liblcm.install 2019-08-08 03:49:36.0 +0300
+++ lcm-1.3.1+repack1/debian/python-liblcm.install 1970-01-01 02:00:00.0 +0200
@@ -1 +0,0 @@
-usr/lib/python2.7
diff -Nru lcm-1.3.1+repack1/debian/rules lcm-1.3.1+repack1/debian/rules
--- lcm-1.3.1+repack1/debian/rules 2019-08-08 03:49:36.0 +0300
+++ lcm-1.3.1+repack1/debian/rules 2019-12-24 07:22:19.0 +0200
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
%:
- dh $@ --with autoreconf --with python2
+ dh $@ --with autoreconf
override_dh_auto_build:
dh_auto_build
Bug#937449: Bug#947303: pygopherd: Python2 removal in sid/bullseye
Hello, I am actively working on a port to Python 3 for pygopherd. I expect to have it done in January. Please do not remove from sid. John On Mon, Dec 23 2019, Sandro Tosi wrote: > Source: pygopherd > Version: 2.0.18.5 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests, in details: > > (source:pygopherd)Build-Depends-Indep->python > (binary:pygopherd)Depends->python > (binary:pygopherd)Depends->python-simpletal > (binary:pygopherd)Depends->python:any > (binary:pygopherd)Depends->python:any > (binary:pygfarm)Depends->python-dictclient > > Please stop using Python2, and fix this issue by one of the following > actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#936966: londonlaw: Python2 removal in sid/bullseye
Am Sonntag, den 22.12.2019, 22:11 +0200 schrieb Juhani Numminen: > On Fri, 30 Aug 2019 07:25:11 + Matthias Klose > wrote: > > Package: src:londonlawVersion: 0.2.1-20Severity: normalTags: sid > > bullseyeUser: debian-pyt...@lists.debian.org > > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to > > removePython2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Hello Fuddl, > Do you think we should remove londonlaw from Debian?As far as I know, > there is and will be no python3 support, becauseupstream seems to be > gone.Fedora retired londonlaw in August. > https://bugzilla.redhat.com/show_bug.cgi?id=1731636 > > Regards,Juhani Hi Juhani, I'm fine with the removal of londonlaw due to missing Python 3 support. In case any upstream adds Python 3 support in the future I'll happily package it and upload it to NEW. Cheers - Bruno signature.asc Description: This is a digitally signed message part
Bug#947266: python3-geopandas: ships /usr/lib/python3/dist-packages/examples/*
Control: tags -1 moreinfo On 12/23/19 10:01 PM, Andreas Beckmann wrote: > python3-geopandas ships files with generic names at the generic location > /usr/lib/python3/dist-packages/examples/ causing file clashes (e.g. on > README.txt) with other packages doing the same wrong thing. > Moving this to /usr/lib/python3/dist-packages/examples/geopandas/ should > probably be OK. The packages doesn't install the examples there itself, it seems that pybuild does that without being explicitly told to. This seems to be a bug in pybuild not geopandas. Are you sure this is a bug in geopandas? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#938887: zfec: diff for NMU version 1.5.2-2.1
Sandro Tosi writes: > > I've prepared an NMU for zfec (versioned as 1.5.2-2.1). The diff > is attached to this message. Thanks Sandro. I've merged your patch into Git. Cheers, Vasudev
Bug#932747: there is no patch shared by the reporter and got the same error at my end too.
Dear all, At [1] the original reporter mentioned a patch but neither linked to a patch or anything else for that matter. I was hit by it today on bullseye . Sharing the details as under - Package: appstream Version: 0.12.9-1 Severity: normal -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-debug'), (100, 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages appstream depends on: ii libappstream4 0.12.9-1 ii libc6 2.29-3 ii libglib2.0-0 2.62.3-2 appstream recommends no packages. Versions of packages appstream suggests: ii apt-config-icons 0.12.9-1 ii curl 7.67.0-2 -- no debconf information I also saw this archlinux bug which had the same error [2] and to my horror I got a whole bunch of metadata ignored due to colliding ids to ignored component . Sharing an example of an ignored component. Please fix if possible. ** (appstreamcli:529457): DEBUG: 09:22:14.426: WARNING: Ignored component 'org.darktable.Darktable': The component is invalid. 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932747#5 2. https://bbs.archlinux.org/viewtopic.php?id=228129 3. #apptreamcli refresh-cache --force --verbose -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#919903: Package wxWidgets 3.1
Control: reassign 935141 libwxgtk3.0-0v5 3.0.4+dfsg-8 Control: affects 935141 wxmaxima It appears that my trouble with wxMaxima is probably fixed in wxWidgets 3.1.2 and I'd like to give it a try. > It's not ABI stable, so it's just not suitable for packaging. Every new > 3.1.x release would mean a transition for everything built against it. > Even if we only uploaded to experimental with the aim to support local > builds, a new upload would break everyone's locally built applications. Upstream appears adamant that it's ready to deploy: > Please notice that while 3.1.3 is officially a “development” version because > it is not fully compatible with the “stable” 3.0.x, the list of backwards > incompatible changes is very short, so you shouldn’t have any problems > updating to this version from 3.0.x in practice, and you’re encouraged to > use this release, including in production. I hope you'll reconsider uploading to experimental. signature.asc Description: This is a digitally signed message part.
Bug#947303: pygopherd: Python2 removal in sid/bullseye
Source: pygopherd Version: 2.0.18.5 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:pygopherd)Build-Depends-Indep->python (binary:pygopherd)Depends->python (binary:pygopherd)Depends->python-simpletal (binary:pygopherd)Depends->python:any (binary:pygopherd)Depends->python:any (binary:pygfarm)Depends->python-dictclient Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947262: ibus: Please omit ibus-tests binary package on Ubuntu/i386
On Tue, Dec 24, 2019 at 07:35:40AM +0900, Changwoo Ryu wrote: > Generally speaking, how about proposing a build profile for > compatibility only build, rather than checking Ubuntu/i386? I guess > ibus is not the only package having this issue and other distros have > (or will have in the future) the same issue. The exact set of binary packages being kept for i386 compatibility in Ubuntu is an Ubuntu-specific decision. Expressing this as a build profile would not be of any obvious benefit to others who were implementing their own compatibility-only i386 archive, and would also cause more work on the infrastructure side in order to have the autobuilders declare a build profile. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#947302: prompt-toolkit-py2: Python2 removal in sid/bullseye
Source: prompt-toolkit-py2 Version: 1.0.15-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:prompt-toolkit-py2)Build-Depends->python-all (source:prompt-toolkit-py2)Build-Depends->python-setuptools (source:prompt-toolkit-py2)Build-Depends->python-six (source:prompt-toolkit-py2)Build-Depends->python-wcwidth (binary:python-prompt-toolkit)Depends->python-six (binary:python-prompt-toolkit)Depends->python-wcwidth (binary:python-prompt-toolkit)Depends->python2:any (binary:python-prompt-toolkit)Depends->python2:any (binary:python-prompt-toolkit)Recommends->python-pygments Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947294: autodocktools: Python2 removal in sid/bullseye
Source: autodocktools Version: 1.5.7-4 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:autodocktools)Build-Depends->python (binary:autodocktools)Depends->python:any (binary:autodocktools)Depends->python:any (binary:autodocktools)Depends->python-imaging-tk Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947300: sparkleshare: Python2 removal in sid/bullseye
Source: sparkleshare Version: 3.28+git20190117-1 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:sparkleshare)Build-Depends-Indep->python-nautilus (binary:sparkleshare)Recommends->python (binary:sparkleshare)Recommends->python-nautilus Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947301: mgltools-pmv: Python2 removal in sid/bullseye
Source: mgltools-pmv Version: 1.5.7-3 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:mgltools-pmv)Build-Depends->python-all (binary:mgltools-pmv)Depends->python:any (binary:mgltools-pmv)Depends->python:any (binary:mgltools-pmv)Depends->python-zsi (binary:mgltools-pmv)Depends->python-pil.imagetk (binary:mgltools-pmv-test)Depends->python:any (binary:mgltools-pmv-test)Depends->python:any Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947296: mercurial-keyring: Python2 removal in sid/bullseye
Source: mercurial-keyring Version: 1.2.0-1 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:mercurial-keyring)Build-Depends->python-all (source:mercurial-keyring)Build-Depends->python-setuptools (binary:mercurial-keyring)Depends->python-keyring (binary:mercurial-keyring)Depends->python:any (binary:mercurial-keyring)Depends->python:any Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947299: hgsubversion: Python2 removal in sid/bullseye
Source: hgsubversion Version: 1.9.3+git20190419+6a6ce-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:hgsubversion)Build-Depends->python (source:hgsubversion)Build-Depends->python-subvertpy (binary:hgsubversion)Depends->python-subvertpy (binary:hgsubversion)Depends->python-subversion (binary:hgsubversion)Depends->python2:any (binary:hgsubversion)Depends->python2:any Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947295: cyrus-imapd: Python2 removal in sid/bullseye
Source: cyrus-imapd Version: 3.0.13-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:cyrus-imapd)Testsuite-Triggers->python-docutils (source:cyrus-imapd)Testsuite-Triggers->python-pygments (source:cyrus-imapd)Testsuite-Triggers->python-sphinx Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947298: ipython-py2: Python2 removal in sid/bullseye
Source: ipython-py2 Version: 5.8.0-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:ipython-py2)Build-Depends->python (source:ipython-py2)Build-Depends->python-backports-shutil-get-terminal-size (source:ipython-py2)Build-Depends->python-ipython-genutils (source:ipython-py2)Build-Depends->python-matplotlib (source:ipython-py2)Build-Depends->python-nose (source:ipython-py2)Build-Depends->python-pexpect (source:ipython-py2)Build-Depends->python-pickleshare (source:ipython-py2)Build-Depends->python-prompt-toolkit (source:ipython-py2)Build-Depends->python-setuptools (source:ipython-py2)Testsuite-Triggers->python (binary:python-ipython)Depends->python-decorator (binary:python-ipython)Depends->python-pexpect (binary:python-ipython)Depends->python-pickleshare (binary:python-ipython)Depends->python-pkg-resources (binary:python-ipython)Depends->python-prompt-toolkit (binary:python-ipython)Depends->python-pygments (binary:python-ipython)Depends->python-simplegeneric (binary:python-ipython)Depends->python-traitlets (binary:python-ipython)Depends->python2:any (binary:python-ipython)Depends->python2:any (binary:python-ipython)Depends->python-backports-shutil-get-terminal-size (binary:python-ipython)Depends->python-pathlib2 (binary:ipython)Depends->python-ipython Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947297: ipykernel-py2: Python2 removal in sid/bullseye
Source: ipykernel-py2 Version: 4.10.1-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests, in details: (source:ipykernel-py2)Build-Depends->python (source:ipykernel-py2)Build-Depends->python-faulthandler (source:ipykernel-py2)Build-Depends->python-ipython (source:ipykernel-py2)Build-Depends->python-jupyter-client (source:ipykernel-py2)Build-Depends->python-matplotlib (source:ipykernel-py2)Build-Depends->python-mock (source:ipykernel-py2)Build-Depends->python-nose (source:ipykernel-py2)Build-Depends->python-pickleshare (source:ipykernel-py2)Build-Depends->python-setuptools (source:ipykernel-py2)Build-Depends->python-tornado (source:ipykernel-py2)Build-Depends->python-traitlets (source:ipykernel-py2)Testsuite-Triggers->python-mock (source:ipykernel-py2)Testsuite-Triggers->python-nose (source:ipykernel-py2)Testsuite-Triggers->python-pytest (binary:python-ipykernel)Depends->python-ipython (binary:python-ipykernel)Depends->python-jupyter-client (binary:python-ipykernel)Depends->python-tornado (binary:python-ipykernel)Depends->python-traitlets (binary:python-ipykernel)Depends->python2:any (binary:python-ipykernel)Depends->python2:any Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#947293: libkate: autopkgtest failures due to libkate-tools removal
Package: libkate
Version: 0.4.1-10
Severity: serious
Tags: patch
Justification: autopkgtest regression
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Dear maintainers,
With the removal of libkate-tools in libkate 0.4.1-10, the libkate
autopkgtest consistently fails, because all of the commands it previously
attempted to run were in the libkate-tools package:
[...]
autopkgtest [12:55:24]: test test-cmd-tools: - - - - - - - - - - stderr - - -
- - - - - - -
/tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
25: kateenc: not found
/tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
31: katalyzer: not found
/tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
37: katedec: not found
/tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
40: errorunable to run katedec: not found
[...]
(https://ci.debian.net/data/autopkgtest/unstable/amd64/libk/libkate/3520793/log.gz)
I think the autopkgtest should simply be dropped, since there is nothing
left for it to do at present. Please see the attached patch.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libkate-0.4.1/debian/tests/control libkate-0.4.1/debian/tests/control
--- libkate-0.4.1/debian/tests/control 2019-11-26 16:03:42.0 -0600
+++ libkate-0.4.1/debian/tests/control 1969-12-31 18:00:00.0 -0600
@@ -1,2 +0,0 @@
-Depends: @
-Tests: test-cmd-tools
diff -Nru libkate-0.4.1/debian/tests/test-cmd-tools
libkate-0.4.1/debian/tests/test-cmd-tools
--- libkate-0.4.1/debian/tests/test-cmd-tools 2019-11-26 16:03:42.0
-0600
+++ libkate-0.4.1/debian/tests/test-cmd-tools 1969-12-31 18:00:00.0
-0600
@@ -1,49 +0,0 @@
-#!/bin/sh
-#
-# Test the kate command line tools to ensure they can run without
-# returning an error.
-
-set -e
-
-retval=0
-
-success() { echo "success:" "$@"; }
-error() { echo "error:" "$@"; retval=1; }
-
-cat > input.srt < 00:00:14,000
-This is a simple subtext block
-that will be encoded into an ogg file.
-
-2
-00:00:15,000 --> 00:00:16,000
-This is the second subtext block.
-
-EOF
-
-if kateenc -t srt -l cy -c SUB -o output.ogg input.srt ; then
-success "kateenc could encode an SRT file to OGG"
-else
-error "unable to run kateenc"
-fi
-
-if katalyzer output.ogg ; then
-success "running katalyzer worked"
-else
-error "unable to run katalyser"
-fi
-
-if katedec output.ogg ; then
-success "running katedec worked"
-else
-error"unable to run katedec"
-fi
-
-if KateDJ --version ; then
-success "running KateDJ worked"
-else
-error "unable to run KateDJ"
-fi
-
-exit $retval
Bug#947292: nyancat-server: package does not include needed systemd file
Package: nyancat-server Version: 1.5.1-1 Severity: grave Justification: renders package unusable Dear Maintainer, After installing nyancat-server and connecting to the socket, the client is disconnected and the following log entries are produced: nyancat-server.socket: Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Invalid argument nyancat-server.socket: Failed with result 'resources'. Found the package does not include the file /lib/systemd/system/nyancat-server@.service This file is in the source, and is included when rebuilding the package. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nyancat-server depends on: ii init-system-helpers 1.57 ii nyancat 1.5.1-1+b1 nyancat-server recommends no packages. nyancat-server suggests no packages. -- no debconf information
Bug#940332: RFH: syncthing
Hi Alexandre! On Sun, Sep 15, 2019 at 04:53:58PM -0400, Alexandre Viau wrote: > Package: wnpp > Severity: normal > > Hello, > > I haven't had enough time to keep up with Syncthing upstream updates for > the past months. > > I don't mind putting some time into the Syncthing packaging from time to > time but I can no longer handle it by myself. > > I would love for someone to help or take over! Note that I'd be willing > to give pointers of sponsor uploads if needed. > Thank you for recommending that I try Syncthing all those years ago After waiting a bit for it to mature, I'm now using it extensively and recommend it to friends and family :-) I'm not qualified to be the sole package maintainer, but would be happy to help out. Please ping me in February or March if someone with more golang experience hasn't stepped forward--I won't learn if I have the necessary free time to commit to comaintenance before then. Cheers, Nicholas signature.asc Description: PGP signature
Bug#947170: transition: botan
在 2019-12-22日的 14:11 +0100，László Böszörményi (GCS)写道： > On Sun, Dec 22, 2019 at 1:45 PM László Böszörményi wrote: > > But > > libqtshadowsocks doesn't and has a dead upstream for more than a year. > > I added its maintainer as Cc if s/he can fix it. > I was way too quick. There's a fix for botan support[1] already. > The question of keeping dead upstream packages in the archive still stands. Considering the upstream status of those projects, I am filing Removal requests for libqtshadowsocks and shadowsocks-qt5 to the FTP Masters. Thanks for noticing. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#570486:
I tried to contact you, but was unsuccessful. I need an urgent answer .. Am încercat să vă contactez, dar nu a avut succes. Am nevoie de un răspuns urgent
Bug#947134: MBF: make fdisk non-essential
Hi, I want make fdisk removable from an essential base system. The details are listed in #947134. Since fdisk currently is pseudo-essential, packages do not need to declare a dependency on it. When fdisk becomes non-essential, such dependencies become required. A lot of packages that use fdisk have since added the relevant dependency (see `apt rdepends fdisk`). To fix the remaining packages, I intend to perform a mass bug filing. I intend to use the following text as a mail template. --->8--->8--->8--- Subject: %(package)s should depend on fdisk explicitly To: mainto...@bugs.debian.org Package: %(package)s Version: %(version)s User: helm...@debian.org Usertags: nonessentialfdisk Dear maintainer, We want to make removing fdisk from installations possible. For standard installations this is not useful, but embedded applications and chroots benefit from such an option. For getting there, all packages that use fdisk must be identified and gain a dependency on it as fdisk currently is pseudo-essential. It was formerly coupled with util-linux. If you care about backports to stretch (oldstable) or older, your dependency should be: fdisk | util-linux (<< 2.29.2-3~) %(package)s was identified as potentially needing such a dependency, because it mentions fdisk in the following files: %(filenames)s Please investigate whether these cases are actually uses of cfdisk, fdisk or sfdisk. Care has been taken to shrink the number of candidates as much as possible, but a few false positives will remain. After doing so, do one of the following: * Add fdisk to Depends. * Add fdisk to Recommends. * Add fdisk to Suggests. * Close this bug explaining why fdisk is not used by this package. Once util-linux stops depending on fdisk, fdisk will no longer be pseudo-essential and this bug will be upgraded to RC severity. Thanks for your help Helmut ---8<---8<---8<--- Please find a dd-list of affected packages attached. There are only 33 binary packages left. In the absence of a discussion, I intend to file the bugs in early January. I'll review the list at that time for added dependencies. I do not intend to change the "Priority: important" or "Important: yes" attributes of fdisk. Helmut Adrian Vondendriesch resource-agents (U) Andriy Grytsenko system-tools-backends Andriy Senkovych salt (U) Antonio Terceiro cloud-utils (U) Apollon Oikonomopoulos ganeti (U) Aurelien Jarno qemu (U) Bastian Blank waagent Benjamin Drung salt (U) Daniel Baumann open-infrastructure-system-tools Daniel Manila weresync (U) Darshaka Pathirana recap Debian Cloud Team cloud-utils Debian Edu Developers debian-edu-config Debian Ganeti Team ganeti Debian Go Packaging Team easygen Debian HA Maintainers resource-agents Debian Libvirt Maintainers libguestfs Debian Live live-build Debian OpenStack ironic python-diskimage-builder python-ironic-lib python-os-xenapi zvmcloudconnector Debian QA Group partimage Debian QEMU Team qemu Debian Salt Team salt Dmitry Bogatov cdist Dominik George debian-edu-config (U) Dpkg Developers dpkg Eric Desrochers sosreport (U) Etienne Dublé debootstick Filesystems Group ecryptfs-utils (U) Franklin G Mendoza salt (U) Guido Günther libguestfs (U) Guido Trotter ganeti (U) Guillem Jover dpkg (U) Hilko Bengen libguestfs (U) Holger Levsen debian-edu-config (U) Iain R. Learmonth vmdebootstrap (U) Jean-Michel Kelbert opensvc Joachim Wiedorn lilo Joe Healy salt (U) Jonathan Carter calamares Laszlo Boszormenyi (GCS) ecryptfs-utils Louis Bouchard sosreport Luca Boccassi live-build (U) Luke Faraone snapd (U) Michael Hudson-Doyle snapd Michael Prokop recap (U) Michael Tokarev qemu (U) Michal Arbet ironic (U) Mike Gabriel debian-edu-config (U) Ondřej Nový salt (U) Petter Reinholdtsen debian-edu-config (U) Python Applications Packaging Team weresync Raphaël Hertzog live-build (U) Richard Jones libguestfs (U) Riku Voipio qemu (U) Riku Voipio mtd-utils Steve Langasek snapd (U) Steve McIntyre <93...@debian.org> vmdebootstrap Thomas Goirand cloud-utils (U) ironic (U) python-diskimage-builder (U) python-ironic-lib (U) python-os-xenapi (U) zvmcloudconnector (U) Tiago Ilieve cloud-utils (U) Tong Sun easygen (U) Unit 193 inxi Valentin Vidic resource-agents (U) Wolfgang Schweer debian-edu-config (U) Zygmunt Krynicki snapd (U)
Bug#947290: RM: libqtshadowsocks -- ROM; Upstream Dead;
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, Please remove package libqtshadowsocks from Sid. Its upstream has stopped maintenance thus it is no longer reasonable for Debian to keep it in the archive anymore. Besides, there are existing alternatives (shadowsocks-libev) available in the archive. This library package was used by shadowsocks-qt5, which is being removed as well. -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#947291: RM: shadowsocks-qt5 -- ROM; Upstream Dead;
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, Please remove package shadowsocks-qt5 from Sid. Its upstream has stopped maintenance thus it is no longer reasonable for Debian to keep it in the archive anymore. Besides, there are existing alternatives (shadowsocks-libev) available in the archive. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#947264: lintian: overly generic file name: /usr/lib/python3/dist-packages/examples/README.txt
On 24/12/2019 00.32, Felix Lechner wrote: > Hi Andreas, > > On Mon, Dec 23, 2019 at 1:00 PM Andreas Beckmann wrote: >> >> please add /usr/lib/python3/dist-packages/examples/README.txt (and >> possible variants thereof >> >> /usr/lib/python3/dist-packages/examples/[^/]* should be disallowed >> (but /usr/lib/python3/dist-packages/examples/.*/[^/]* should be OK). > > Should a README.txt not cover all examples, or should the file simply > have another name? A package built from src:python3.x or src:python3-defaults might ship such a file, but no ordinary python3-$MODULE package. (Maybe python3-examples could.) Maybe ask the python maintainers whether /usr/lib/python3/dist-packages/examples/ is a "namespace invasion". >> in case lintian uses some wildcards for this >> check) to the list of overly generic file names. > > Please forgive me. Lintian has a lot of tags. Would you please point > us in the right direction? > > $ find tags/ -name '*generic*' > tags/p/python-module-has-overly-generic-name.desc That is the one I meant, but maybe it is not the best for "namespace invasion". Andreas PS: the buggy packages now have #947265, #947266
Bug#947289: postgis: library linking error renders database unusable
Package: postgis Version: 3.0.0+dfsg-6 Severity: important Dear Maintainer, After an upgrade last night, my postgis enabled database is returning ERROR: could not load library "/usr/lib/postgresql/11/lib/postgis-2.5.so": /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1: undefined symbol: _ZlsRSoPK12__mpz_struct for all queries. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgis depends on: ii libc6 2.29-3 ii libgdal20 2.4.3+dfsg-1+b1 ii libgeos-c1v5 3.8.0-1 ii libpq512.1-1 ii libproj15 6.2.1-1 Versions of packages postgis recommends: ii postgis-doc 3.0.0+dfsg-6 ii postgresql-12-postgis-3 3.0.0+dfsg-6 Versions of packages postgis suggests: pn postgis-gui -- no debconf information
Bug#947264: lintian: overly generic file name: /usr/lib/python3/dist-packages/examples/README.txt
Hi Andreas, On Mon, Dec 23, 2019 at 1:00 PM Andreas Beckmann wrote: > > please add /usr/lib/python3/dist-packages/examples/README.txt (and > possible variants thereof > > /usr/lib/python3/dist-packages/examples/[^/]* should be disallowed > (but /usr/lib/python3/dist-packages/examples/.*/[^/]* should be OK). Should a README.txt not cover all examples, or should the file simply have another name? > in case lintian uses some wildcards for this > check) to the list of overly generic file names. Please forgive me. Lintian has a lot of tags. Would you please point us in the right direction? $ find tags/ -name '*generic*' tags/p/python-module-has-overly-generic-name.desc tags/p/privacy-breach-generic.desc tags/h/header-has-overly-generic-name.desc tags/m/manpage-has-overly-generic-name.desc Kind regards Felix Lechner
Bug#937809: python-hidapi: diff for NMU version 0.7.99.post21-1.1
Control: tags 937809 + patch
Dear maintainer,
I've prepared an NMU for python-hidapi (versioned as 0.7.99.post21-1.1). The
diff
is attached to this message.
Regards.
diff -Nru python-hidapi-0.7.99.post21/debian/changelog python-hidapi-0.7.99.post21/debian/changelog
--- python-hidapi-0.7.99.post21/debian/changelog 2017-12-11 03:27:02.0 -0500
+++ python-hidapi-0.7.99.post21/debian/changelog 2019-12-23 18:22:52.0 -0500
@@ -1,3 +1,10 @@
+python-hidapi (0.7.99.post21-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #937809
+
+ -- Sandro Tosi Mon, 23 Dec 2019 18:22:52 -0500
+
python-hidapi (0.7.99.post21-1) unstable; urgency=medium
* New upstream release.
diff -Nru python-hidapi-0.7.99.post21/debian/control python-hidapi-0.7.99.post21/debian/control
--- python-hidapi-0.7.99.post21/debian/control 2017-12-11 03:27:02.0 -0500
+++ python-hidapi-0.7.99.post21/debian/control 2019-12-23 18:22:41.0 -0500
@@ -5,15 +5,12 @@
Priority: optional
Homepage: https://github.com/trezor/cython-hidapi
Build-Depends:
- cython,
cython3,
debhelper (>=9),
dh-python,
libhidapi-dev,
libudev-dev,
libusb-1.0-0-dev,
- python-all-dev,
- python-setuptools,
python3-all-dev,
python3-setuptools,
Standards-Version: 4.1.2
@@ -37,23 +34,3 @@
file (per platform) and a single header.
.
This package contains HIDAPI for Python 3.
-
-Package: python-hid
-Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Provides: ${python:Provides}
-Description: cython interface to hidapi
- This has been tested with:
- .
- * the PIC18F4550 on the development board from CCS with their example program.
- * the Fine Offset WH3081 Weather Station.
- .
- It works on Linux, Windows XP and OS X.
- .
- HIDAPI is a multi-platform library which allows an application to interface
- with USB and Bluetooth HID-Class devices on Windows, Linux, FreeBSD, and Mac
- OS X. HIDAPI can be either built as a shared library (.so or .dll) or
- can be embedded directly into a target application by adding a single source
- file (per platform) and a single header.
- .
- This package contains HIDAPI for Python 2.
diff -Nru python-hidapi-0.7.99.post21/debian/rules python-hidapi-0.7.99.post21/debian/rules
--- python-hidapi-0.7.99.post21/debian/rules 2017-12-11 03:27:02.0 -0500
+++ python-hidapi-0.7.99.post21/debian/rules 2019-12-23 18:22:48.0 -0500
@@ -11,6 +11,6 @@
rm -f hid.c hidraw.c
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
Bug#947288: freshplayerplugin: FTBFS: No package 'libdrm' found
Source: freshplayerplugin Version: 0.3.9-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, freshplayerplugin cannot be built in a current sid environment any more: -- Checking for modules 'alsa;gio-2.0;x11;xrandr;xrender;xcursor;gl;libdrm;libevent;libevent_pthreads;cairo;pango;pangocairo;pangoft2;freetype2;openssl;icu-uc' -- No package 'libdrm' found CMake Error at /usr/share/cmake-3.15/Modules/FindPkgConfig.cmake:458 (message): A required package was not found Call Stack (most recent call first): /usr/share/cmake-3.15/Modules/FindPkgConfig.cmake:637 (_pkg_check_modules_internal) CMakeLists.txt:45 (pkg_check_modules) -- Configuring incomplete, errors occurred! Andreas freshplayerplugin_0.3.9-2.log.gz Description: application/gzip
Bug#947287: python3-certifi: ships useless cacert.pem file
Package: python3-certifi Version: 2019.11.28-1 Severity: minor While the package is patched to return the system location, it still ships /usr/lib/python3/dist-packages/certifi/cacert.pem which causes the .deb to be larger than it must. Furthermore it might lead people to believe using that bundle is acceptable by hardcoding a path to it. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages python3-certifi depends on: ii ca-bundle [ca-certificates] 20190604tarent1 ii python3 3.7.5-3 python3-certifi recommends no packages. python3-certifi suggests no packages. -- no debconf information
Bug#889925: valac is unusable for cross-compilation
On Tue, Dec 10, 2019 at 10:36:23PM +0100, Helmut Grohne wrote: > I've slightly updated the previous .debdiff and uploaded it to > delayed/10. It'll target experimental first to clear NEW. I'll upload to > unstable afterwards. Please tell if I should delay it any longer. I'm > attaching the updated .debdiff. The experimental upload hit the archive today. I've now uploaded the same package to unstable as a source-only upload with 10 day delay. Helmut
Bug#712503: hmmmm
From https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpd#PORTS ( with TCP and imcp port bits cut out:) Normally a DHCPv4 server will open a raw UDP socket to receive and send most DHCPv4 packets. It also opens a fallback UDP socket for use in sending unicast packets. Normally these will both use the well known port number for BOOTPS. ... For DHCPv6 the server opens a UDP socket on the well known dhcpv6-server port. ... When DDNS is enabled at compile time (see includes/site.h) the server will open both a v4 and a v6 UDP socket on random ports, unless DDNS updates are globally disabled by setting ddns-update-style to none in the configuration file. ,.,. Not best practice to listen on ports when not used .. should be part of the config -- but an upstream issue. Karl Schmidt EMail k...@lrak.net 3209 West 9th Street Ph (785) 979-8397 Lawrence, KS 66049 Life is so short, precious, and delicate. All we have is a bit of time. Best not to waste it. -kps Carpe diem -- Horace - from 'Carpe diem quam minimum credula postero'
Bug#947286: libkate: Please omit libkate-tools on Ubuntu/i386
Package: libkate Version: 0.4.1-10 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal ubuntu-patch Dear maintainers, In Ubuntu, we are in the process of moving the i386 architecture to a compatibility-only layer on amd64. We are keeping libkate on i386 because it's a build-dependency of vlc, but the libkate-tools package built from this source has dependencies on other packages that are not being kept as part of the compatibility library set (python-pythoncard). We would like to drop this binary package rather than keeping it around in the Ubuntu archive and uninstallable. Would you please consider applying the attached patch, or something like it, to omit building these binary packages on Ubuntu? Thanks for considering, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 5~ diff -Nru libkate-0.4.1/debian/rules libkate-0.4.1/debian/rules --- libkate-0.4.1/debian/rules 2019-11-26 16:03:42.0 -0600 +++ libkate-0.4.1/debian/rules 2019-12-23 17:02:56.0 -0600 @@ -5,5 +5,9 @@ DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk +ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386) + BUILD_PACKAGES += -Nlibkate-tools +endif + %: - dh $@ + dh $@ $(BUILD_PACKAGES)
Bug#947285: g2 FTCBFS: builds the perl extension for the build architecture
Source: g2 Version: 0.72-8 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs g2 fails to cross build from source, because the perl extension is built for the build architecture. The easiest way of cross building perl extensions - using dh_auto_configure - almost solves this, but - like any perl extension - g2 should build depend on perl-xs-dev. Please consider applying the attached patch. Helmut diff --minimal -Nru g2-0.72/debian/changelog g2-0.72/debian/changelog --- g2-0.72/debian/changelog2018-10-28 12:13:00.0 +0100 +++ g2-0.72/debian/changelog2019-12-23 22:40:33.0 +0100 @@ -1,3 +1,12 @@ +g2 (0.72-8.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_configure call Makefile.PL. ++ Missing Build-Depends: perl-xs-dev. + + -- Helmut Grohne Mon, 23 Dec 2019 22:40:33 +0100 + g2 (0.72-8) unstable; urgency=medium * debhelper 11 diff --minimal -Nru g2-0.72/debian/control g2-0.72/debian/control --- g2-0.72/debian/control 2018-10-28 12:13:00.0 +0100 +++ g2-0.72/debian/control 2019-12-23 22:40:33.0 +0100 @@ -8,6 +8,7 @@ libx11-dev, chrpath, libgd-dev, + perl-xs-dev, xutils-dev Standards-Version: 4.2.1 Vcs-Browser: https://salsa.debian.org/med-team/g2 diff --minimal -Nru g2-0.72/debian/rules g2-0.72/debian/rules --- g2-0.72/debian/rules2018-10-28 12:13:00.0 +0100 +++ g2-0.72/debian/rules2019-12-23 22:40:33.0 +0100 @@ -36,7 +36,7 @@ # clean up and build the shared lib -rm -f src/*.o src/*/*.o $(MAKE) PICFLAG="-fPIC" RVERSION=$(rversion) MVERSION=$(major) DEBCFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" shared - (cd ./g2_perl && perl Makefile.PL INSTALLDIRS=vendor LIBS="-L$(CURDIR) -lg2") + dh_auto_configure --sourcedirectory=g2_perl -- LIBS="-L$(CURDIR) -lg2" $(MAKE) -C ./g2_perl LD_RUN_PATH="" override_dh_auto_install:
Bug#947269: lintian: spelling mistake in no-dh-sequencer tag
Control: tags -1 + pending Hi Thorsten, On Mon, Dec 23, 2019 at 1:21 PM Thorsten Glaser wrote: > > I believe the “&@” is a misspelling (probably of “$@”), Thanks. It was addressed in Bug #947115 > and people might consider it line noise, too (ponder > whether this should be included in the message at all). New tag description is pending with: https://salsa.debian.org/lintian/lintian/commit/549f2aa8f8ec1e65eb38e12fc78d0430ed7e40e8 Kind regards Felix Lechner
Bug#936270: Any update? We'll remove python-routes soon
Hi Norbert, Sorry to be annoying, but is there any update on the Py2 removal situation of Calibre? When do you think your package will be ready? As I understand, Calibre itself is ready, but what about the plugins? Are the most important plugins ready? Could we imagine that we could just leave a few less important plugin behind for a short period, until the porting is done? Currently, we have the "routes" package affected by this bug: #938407 (ie: routes doesn't have py2 (build-)depends available anymore due to early removal of py2 in other packages)). Now, we have 2 alternatives: get routes py2 support removed, and then, calibre py2 removal bug becomes RC, or we attempt to reintroduce a few py2 packages like webtest and waitress. I don't think the later is reasonable at this point in time, it'd be going on the wrong direction. At the same time, having routes removed from testing means that about nearly all of OpenStack will be removed at the same time. This is *not* something I will let happen. I don't think we should wait for another 6 months to act here. Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#947279: apt SIGABRT's with `malloc(): unsorted double linked list corrupted`
On Mon, 2019-12-23 at 23:36 +0100, Julian Andres Klode wrote: > The coredump should be useless, as this sounds like a memory > corruption issue, which would need debugging in valgrind to find the > first illegal write. I can make available any of the following, should it help: Architecture, CoreDump, ExecutablePath, ProblemType, ProcEnviron, Signal, Date, ExecutableTimestamp, ProcCmdline, ProcMaps, Uname, DistroRelease, _LogindSession, ProcCwd, ProcStatus -- Kip Warner -- Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Bug#939095: RFS: axtls/2.1.5+ds-1 [ITP] -- Highly configurable client/server TLSv1.2 library
On Mon, Dec 23, 2019 at 03:17:36PM +0800, Yangfl wrote:
> Hmm clearly lua-bitop is lack of support for lua5.3. Have to remove
> the lua test part and hope everything will be fine...
It builds and passes tests now, but trying to run the example server fails
with:
axhttpd -p 8080
ERR: Couldn't bind to port 8080
With strace, I see:
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET6, sa_data="\37\220\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =
-1 EINVAL (Invalid argument)
or
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET6, sa_data="\37\220|\177\0\0\0\0\0\0\0\0\0\0"}, 16) =
-1 EINVAL (Invalid argument)
Same with -s, or on two other machines (amd64 and arm64).
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#528001: Checking syntax in d/source/include-binaries, pending
Control: tags -1 + pending Hi, > I have not > closed it because I assumed it was still open since there is no check > for (e.g.) d/source/include-binaries. Pending via: https://salsa.debian.org/lintian/lintian/commit/56fc5eef5fe936a3b230459e4afbf8a88ed399de Kind regards Felix Lechner
Bug#947279: apt SIGABRT's with `malloc(): unsorted double linked list corrupted`
On Mon, Dec 23, 2019 at 02:04:13PM -0800, Kip Warner wrote: > Package: apt > Version: 1.9.4 > > I experienced an unexpected SIGABRT signal being raised with apt(1). I > saw the following: > >$ sudo apt install trousers >Reading package lists... Done >Building dependency tree >Reading state information... Done >The following NEW packages will be installed: > trousers >0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. >Need to get 119 kB of archives. >After this operation, 369 kB of additional disk space will be used. >Get:1 http://ca.archive.ubuntu.com/ubuntu eoan/universe amd64 >trousers amd64 0.3.14+fixed1-1build1 [119 kB] >Fetched 119 kB in 0s (257 kB/s) >malloc(): unsorted double linked list corrupted >Aborted > > This appears to be a very difficult bug to reproduce. It only appeared > once and with the second invocation succeeding without issue. > > Fortunately apport managed to preserve the core dump. After unpacking > it with apport-unpack and loading the core dump with gdb, the full > stack trace is as follows: The coredump should be useless, as this sounds like a memory corruption issue, which would need debugging in valgrind to find the first illegal write. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#867123: [PATCH] mdoc: Update operating system release numbers
On Sat, Dec 21, 2019 at 02:51:23PM +0100, Ingo Schwarze wrote: > Consequently, i just pushed the patch to the upstream groff repository, > with the following tweaks: > > * I included the following versions which appeared to be missing: > - NetBSD 6.0.6 and 7.2 > - DragonFly 3.0.2 and 3.2.2 > > * I did *not* include the following releases because x.y.0 are not >included for any other DragonFly releases: DragonFly 3.6.0 and 3.8.0. >I'm not a DragonFly user and i'm not completely sure what would make >most sense for that system, so i just stuck to existing practice as >best i could. Thanks. I have no complaints with these - I wasn't completely sure what I was doing and am happy for the corrections. (There was a small typo, which I've fixed on master. It's very easy for one's eyes to swim when dealing with these macros.) -- Colin Watson [cjwat...@debian.org]
Bug#947262: ibus: Please omit ibus-tests binary package on Ubuntu/i386
Control: tags -1 pending 2019년 12월 24일 (화) 오전 4:27, Steve Langasek 님이 작성: > > Package: ibus > Version: 1.5.21-4 > Severity: minor > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu focal ubuntu-patch > > Dear maintainers, > > In Ubuntu, we are in the process of moving the i386 architecture to a > compatibility-only layer on amd64. We are keeping ibus on i386 because > ibus-gtk is relevant for legacy applications, but the ibus-tests package > built from this source has dependencies on other packages that are not being > kept as part of the compatibility library set (e.g. gnome-shell). > > We would like to drop the ibus-tests binary package rather than keeping it > around in the Ubuntu archive and uninstallable. Would you please consider > applying the attached patch, or something like it, to omit building this > binary package on Ubuntu? > > Thanks for considering, Applied in the git. Thanks for the patch. Generally speaking, how about proposing a build profile for compatibility only build, rather than checking Ubuntu/i386? I guess ibus is not the only package having this issue and other distros have (or will have in the future) the same issue.
Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile
Am 23.12.2019 um 21:36 teilte Seb mit: Hi Seb, >>> ii texlive-fonts-extra 2018.20190227-2 all TeX Live: >> This is a quite old version of the package. What happens if you run >> dist-upgrade? > > I'm tempted to say that running dist-upgrade has been a nightmare > sufficiently many times that I'm not even considering doing it to find > out what would happen to fourier-orns: sorry. > Well, then... Why do you report an issue for Package: texlive-fonts-extra Version: 2019.20191208-1 Severity: important ...if you don't have that version installed? > And last year is not *that* old, is it? > hille@sid:~ $ wget https://snapshot.debian.org/archive/debian/20190301T035241Z/pool/main/t/texlive-extra/texlive-fonts-extra_2018.20190227-1_all.deb hille@sid:~ $ dpkg-deb -c texlive-fonts-extra_2018.20190227-1_all.deb|grep -i Fourier|grep -i orns -rw-r--r-- root/root 1766 2016-11-25 19:31 ./usr/share/texlive/texmf-dist/fonts/afm/public/fourier/fourier-orns.afm -rw-r--r-- root/root 636 2016-11-25 19:31 ./usr/share/texlive/texmf-dist/fonts/tfm/public/fourier/fourier-orns.tfm -rw-r--r-- root/root 14399 2016-11-25 19:32 ./usr/share/texlive/texmf-dist/fonts/type1/public/fourier/fourier-orns.pfb -rw-r--r-- root/root 1677 2016-11-25 19:33 ./usr/share/texlive/texmf-dist/tex/latex/fourier/fourier-orns.sty hille@sid:~ $ At least there seems to be a relevant difference. ;-) Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#947283: network-manager: fails to connect via Wi-Fi with "selecting lease failed"
Package: network-manager Version: 1.22.0-1 Severity: important When connecting to a Starbucks Wi-Fi network (open Wi-Fi network with captive portal), Network Manager refuses to get an IPv4 address over DHCP with a message in the logs that says "selecting lease failed: 12". This machine has not previously been connected to this network. Downgrading to 1.20.8-1 causes things to work again, but 1.22.0-1 does not work even if I reboot and delete all the saved leases from /var/lib/NetworkManager. I don't see the problem on my home network, with uses WPA2-EAP with EAP-TTLS and PAP. However, I had connected to that network before installing 1.22.0, so it's possible that the issue is with new networks. Relevant portions of the logs from 1.22.0-1 and 1.20.8-1 are attached. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.16-2 ii init-system-helpers1.57 ii libaudit1 1:2.8.5-2+b1 ii libbluetooth3 5.50-1+b1 ii libc6 2.29-6 ii libcurl3-gnutls7.67.0-2 ii libglib2.0-0 2.62.3-2 ii libgnutls303.6.11.1-2 ii libjansson42.12-1 ii libmm-glib01.10.4-0.1 ii libndp01.6-1+b1 ii libnewt0.520.52.21-4 ii libnm0 1.22.0-1 ii libpam-systemd 244-3 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libpsl50.20.2-2 ii libreadline8 8.0-3 ii libselinux13.0-1 ii libsystemd0244-3 ii libteamdctl0 1.29-1 ii libudev1 244-3 ii libuuid1 2.34-0.1 ii policykit-10.105-26 ii udev 244-3 ii wpasupplicant 2:2.9-3+b1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1.1 ii iptables 1.8.4-1 ii modemmanager 1.10.4-0.1 ii ppp 2.4.7-2+4.1+b1 Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2 pn libteam-utils -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9758] dhcp4 (wlp0s20f3): state changed bound -> expire Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9759] device (wlp0s20f3): DHCPv4: 480 seconds grace period started Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9774] sup-iface[0x556830be74c0,wlp0s20f3]: connection disconnected (reason -3) Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9798] device (wlp0s20f3): supplicant interface state: completed -> disconnected Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.5802] manager: sleep: wake requested (sleeping: yes enabled: yes) Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.5803] device (enp0s31f6): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6639] device (wlp0s20f3): state change: activated -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6640] dhcp4 (wlp0s20f3): canceled DHCP transaction Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6640] dhcp4 (wlp0s20f3): state changed expire -> done Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6713] manager: NetworkManager state is now CONNECTED_GLOBAL Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6916] manager: NetworkManager state is now CONNECTED_LOCAL Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6923] device (enp0s31f6): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.8839] device (wlp0s20f3): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Dec 23 18:19:37 camp NetworkManager[219829]: [1577125177.1050] device (wlp0s20f3): set-hw-addr: set MAC address to DA:6B:EA:90:07:84 (scanning) Dec 23 18:19:37 camp NetworkManager[219829]: [1577125177.3101] device (F0:5C:77:DA:5B:F8): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Dec 23 18:19:37 camp NetworkManager[219829]: [1577125177.3125] device (p2p-dev-wlp0s20f3): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state:
Bug#938818: whatthepatch: diff for NMU version 0.0.5-2.1
Control: tags 938818 + patch
Dear maintainer,
I've prepared an NMU for whatthepatch (versioned as 0.0.5-2.1). The diff
is attached to this message.
Regards.
diff -Nru whatthepatch-0.0.5/debian/changelog whatthepatch-0.0.5/debian/changelog
--- whatthepatch-0.0.5/debian/changelog 2018-04-23 08:37:16.0 -0400
+++ whatthepatch-0.0.5/debian/changelog 2019-12-23 17:21:31.0 -0500
@@ -1,3 +1,10 @@
+whatthepatch (0.0.5-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #938818
+
+ -- Sandro Tosi Mon, 23 Dec 2019 17:21:31 -0500
+
whatthepatch (0.0.5-2) unstable; urgency=medium
* Bug fix: "Please drop override of
diff -Nru whatthepatch-0.0.5/debian/control whatthepatch-0.0.5/debian/control
--- whatthepatch-0.0.5/debian/control 2018-04-23 08:34:40.0 -0400
+++ whatthepatch-0.0.5/debian/control 2019-12-23 17:21:14.0 -0500
@@ -2,23 +2,11 @@
Section: python
Priority: extra
Maintainer: Reinhard Tartler
-Build-Depends: debhelper (>= 9), dh-python, python-all, python-setuptools, python3-all, python3-setuptools
+Build-Depends: debhelper (>= 9), dh-python, python3-all, python3-setuptools
Standards-Version: 4.0.0
Homepage: https://github.com/cscorley/whatthepatch
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
Testsuite: autopkgtest-pkg-python
-Package: python-whatthepatch
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: Library for parsing patch files (Python 2)
- What The Patch!? is a library for parsing patch files. Its only purpose
- is to read a patch file and get it into some usable form by other
- programs.
- .
- This package installs the library for Python 2.
-
Package: python3-whatthepatch
Architecture: all
Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru whatthepatch-0.0.5/debian/rules whatthepatch-0.0.5/debian/rules
--- whatthepatch-0.0.5/debian/rules 2018-04-23 08:34:40.0 -0400
+++ whatthepatch-0.0.5/debian/rules 2019-12-23 17:21:25.0 -0500
@@ -6,7 +6,7 @@
export PYBUILD_NAME=whatthepatch
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
# If you need to rebuild the Sphinx documentation
Bug#947216: yapps2: should this package be removed?
On Mon, Dec 23, 2019 at 06:42:00PM +, Colin Watson wrote: > On Sun, Dec 22, 2019 at 06:57:24PM -0500, Sandro Tosi wrote: > > Python 2 is end-of-life, and there are no more rdeps for python-yapps2, but > > python3-yapps2 seems broken beyond repair: #911753, #911752. > > > > I believe this is a good enough reason to have this package removed from > > debian. > > if i dont hear back within a week with a good reason to keep it, i'll file > > for > > its removal. > > Please don't - keymapper needs it and isn't itself useless, and I > successfully ported keymapper to Python 3 despite the bugs in yapps2. > The bugs (which I filed) are annoying but not fatal. I've made a DELAYED/10 NMU to fix these bugs, as well as removing the Python 2 binary package and fixing #911730. I think that gets things back into decent shape; will you withdraw this removal request? -- Colin Watson [cjwat...@debian.org]
Bug#938010: python-pbkdf2: diff for NMU version 1.3+20110613.git2a0fb15~ds0-3.1
Control: tags 938010 + patch
Dear maintainer,
I've prepared an NMU for python-pbkdf2 (versioned as
1.3+20110613.git2a0fb15~ds0-3.1). The diff
is attached to this message.
Regards.
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog
--- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog 2013-07-05 17:48:26.0 -0400
+++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog 2019-12-23 16:51:11.0 -0500
@@ -1,3 +1,10 @@
+python-pbkdf2 (1.3+20110613.git2a0fb15~ds0-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python3 support; Closes: #938010
+
+ -- Sandro Tosi Mon, 23 Dec 2019 16:51:11 -0500
+
python-pbkdf2 (1.3+20110613.git2a0fb15~ds0-3) unstable; urgency=low
[ Martin Pitt ]
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/control python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/control
--- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/control 2013-03-25 08:16:46.0 -0400
+++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/control 2019-12-23 16:51:11.0 -0500
@@ -4,36 +4,15 @@
Maintainer: Alessio Treglia
Build-Depends:
debhelper (>= 9~),
- python-all,
- python-setuptools,
+ dh-python,
python3-all,
python3-setuptools
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
XS-Testsuite: autopkgtest
Standards-Version: 3.9.4
Homepage: http://www.dlitz.net/software/python-pbkdf2/
Vcs-Git: git://anonscm.debian.org/collab-maint/python-pbkdf2.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/python-pbkdf2.git
-Package: python-pbkdf2
-Architecture: all
-Depends:
- ${misc:Depends},
- ${python:Depends}
-Description: Python RSA PKCS#5 v2.0 module (Python 2)
- This module implements the password-based key derivation
- function, PBKDF2, specified in RSA PKCS#5 v2.0.
- .
- PKCS#5 v2.0 Password-Based Key Derivation is a key derivation
- function which is part of the RSA Public Key Cryptography
- Standards series. The provided implementation takes a password
- or a passphrase and a salt value (and optionally a iteration
- count, a digest module, and a MAC module) and provides a file-like
- object from which an arbitrarly-sized key can be read.
- .
- This is the Python 2 version of the package.
-
Package: python3-pbkdf2
Architecture: all
Depends:
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python3-pbkdf2.install python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python3-pbkdf2.install
--- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python3-pbkdf2.install 2013-03-25 08:16:46.0 -0400
+++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python3-pbkdf2.install 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python3
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python-pbkdf2.install python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python-pbkdf2.install
--- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python-pbkdf2.install 2013-03-25 08:16:46.0 -0400
+++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/python-pbkdf2.install 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2*
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/rules python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/rules
--- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/rules 2013-03-25 08:11:43.0 -0400
+++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/rules 2019-12-23 16:50:52.0 -0500
@@ -2,30 +2,8 @@
export REPACK_SH=$(CURDIR)/debian/repack.sh
-PYTHON2=$(shell pyversions -vr)
-PYTHON3=$(shell py3versions -vr)
-
%:
- dh $@ --with python2,python3
-
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-test-python%:
- python$* setup.py test -vv
-
-override_dh_auto_test: $(PYTHON2:%=test-python%) $(PYTHON3:%=test-python%)
-endif
-
-build-python%:
- python$* setup.py build
-
-override_dh_auto_build: $(PYTHON3:%=build-python%)
- dh_auto_build
-
-install-python%:
- python$* setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb
-
-override_dh_auto_install: $(PYTHON3:%=install-python%)
- dh_auto_install
+ dh $@ --with python3 --buildsystem=pybuild
override_dh_auto_clean:
dh_auto_clean
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control
--- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control 2013-03-25 08:10:02.0 -0400
+++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control 2019-12-23 16:51:04.0 -0500
@@ -1,5 +1,2 @@
-Tests: python-pbkdf2
-Depends: python-pbkdf2
-
Tests: python3-pbkdf2
Depends: python3-pbkdf2
diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python-pbkdf2 python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python-pbkdf2
--- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python-pbkdf2 2013-07-05 16:07:24.0 -0400
+++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python-pbkdf2 19
Bug#947282: yapps2: diff for NMU version 2.2.1-3.1
Package: yapps2
Version: 2.2.1-3
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for yapps2 (versioned as 2.2.1-3.1) and uploaded it
to DELAYED/10. Please feel free to tell me if I should delay it longer.
Regards,
--
Colin Watson [cjwat...@debian.org]
diff -u yapps2-2.2.1/debian/changelog yapps2-2.2.1/debian/changelog
--- yapps2-2.2.1/debian/changelog
+++ yapps2-2.2.1/debian/changelog
@@ -1,3 +1,14 @@
+yapps2 (2.2.1-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop Python 2 support (closes: #938864).
+ * Write __future__ import before preparser (closes: #911730).
+ * Convert Scanner.print_line_with_pointer to Python 3 print syntax
+(closes: #911753).
+ * Port documentation and examples to Python 3 (closes: #911752).
+
+ -- Colin Watson Mon, 23 Dec 2019 22:05:40 +
+
yapps2 (2.2.1-3) unstable; urgency=medium
* yapps2 depends on python3-pkg-resources for the entry point wrapper
diff -u yapps2-2.2.1/debian/control yapps2-2.2.1/debian/control
--- yapps2-2.2.1/debian/control
+++ yapps2-2.2.1/debian/control
@@ -3,15 +3,15 @@
Priority: optional
Maintainer: Matthias Urlichs
Build-Depends: debhelper (>= 9~)
-Build-Depends-Indep: python-dev (>= 2.5.4-1~), python3-dev,
+Build-Depends-Indep: python3-dev,
dh-python,
hevea,
- python-setuptools, python3-setuptools,
+ python3-setuptools,
Standards-Version: 3.9.8
Package: yapps2
Architecture: all
-Depends: ${python:Depends}, python3-yapps (= ${binary:Version}), ${misc:Depends},
+Depends: ${python3:Depends}, python3-yapps (= ${binary:Version}), ${misc:Depends},
python3-pkg-resources,
Description: Yet Another Python Parser System
YAPPS is an easy to use parser generator that is written in Python and
@@ -31,20 +31,6 @@
- better error reporting
- reads input incrementally
-Package: python-yapps
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Replaces: yapps2-runtime
-Conflicts: yapps2-runtime
-Description: Yet Another Python Parser System
- YAPPS is an easy to use parser generator that is written in Python and
- generates Python code. There are several parser generator systems
- already available for Python, but this parser has different goals:
- Yapps is simple, very easy to use, and produces human-readable parsers.
- .
- This package contains the Python2 runtime support for parsers generated
- with yapps2.
-
Package: python3-yapps
Architecture: all
Depends: ${python3:Depends}, ${misc:Depends}
reverted:
--- yapps2-2.2.1/debian/python-yapps.README
+++ yapps2-2.2.1.orig/debian/python-yapps.README
@@ -1,11 +0,0 @@
-The Debian Package python-yapps2
-
-
-This package contains the new runtime Python code for the augmented
-yapps2 parser which is included in Debian.
-
-You need to depend on this package if you Debianize Python programs that
-contain a yapps2-built parser.
-
---
-Matthias Urlichs
reverted:
--- yapps2-2.2.1/debian/python-yapps2.dirs
+++ yapps2-2.2.1.orig/debian/python-yapps2.dirs
@@ -1 +0,0 @@
-usr/share/doc/python-yapps2
diff -u yapps2-2.2.1/debian/rules yapps2-2.2.1/debian/rules
--- yapps2-2.2.1/debian/rules
+++ yapps2-2.2.1/debian/rules
@@ -3,7 +3,7 @@
export PYBUILD_NAME=yapps
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
override_dh_auto_build:
dh_auto_build
@@ -13,7 +13,6 @@
override_dh_install:
mkdir -p debian/yapps2/usr/bin
mv debian/python3-yapps/usr/bin/yapps2 debian/yapps2/usr/bin
- rm debian/python-yapps/usr/bin/yapps2
dh_install
override_dh_auto_test:
diff -u yapps2-2.2.1/doc/yapps2.html yapps2-2.2.1/doc/yapps2.html
--- yapps2-2.2.1/doc/yapps2.html
+++ yapps2-2.2.1/doc/yapps2.html
@@ -554,7 +554,7 @@
class MyX(Xparser.X):
def printmsg(self):
-print "Hello!"
+print("Hello!")
4.2 Customizing ScannersThe generated parser class is not dependent on the generated scanner
@@ -645,7 +645,7 @@
{{ start = self._scanner.pos }}
a b c
{{ end = self._scanner.pos }}
- {{ print 'Text is', self._scanner.input[start:end] }}
+ {{ print('Text is', self._scanner.input[start:end]) }}
5.4 Pre- and Post-Parser CodeSometimes the parser code needs to rely on helper variables,
only in patch2:
unchanged:
--- yapps2-2.2.1.orig/doc/yapps2.tex
+++ yapps2-2.2.1/doc/yapps2.tex
@@ -795,7 +795,7 @@
class MyX(Xparser.X):
def printmsg(self):
-print "Hello!"
+print("Hello!")
\end{verbatim}
\mysubsection{Customizing Scanners}
@@ -924,7 +924,7 @@
{{ start = self._scanner.pos }}
a b c
{{ end = self._scanner.pos }}
- {{ print 'Text is', self._scanner.input[start:end] }}
+ {{ print('Text is', self._scanner.input[start:end]) }}
\end{verbatim}
\mysubsection{Pre- and Post-Parser Code}
only in patch2:
unchanged:
--- yapps2-2.2.1.orig/examples/calc.g
+++ yapps2-2.2.1/examples/calc.g
@@ -3,12 +3,12 @@
de
Bug#947281: inspircd: fails to start due to apparmor policy
Source: inspircd Version: 3.4.0-1 Severity: important Tags: patch Dear Maintainer, The AppArmor policy that is included with the unstable inspircd package specifies an incorrect path to the pidfile for the inspircd daemon. As a result AppArmor blocks inspircd from writing its own pidfile during launch, causing startup to fail. This can be reproduced with 'apt-get install inspircd' and then 'journalctl -u inspircd.service' on a fresh unstable machine (with AppArmor enabled). systemd[1]: Starting InspIRCd - Internet Relay Chat Daemon... inspircd[10533]: InspIRCd - Internet Relay Chat Daemon inspircd[10533]: For contributors & authors: See /INFO Output systemd[1]: inspircd.service: Can't open PID file /run/inspircd/inspircd.pid (yet?) after start: Operation not permitted systemd[1]: inspircd.service: Failed with result 'protocol'. systemd[1]: Failed to start InspIRCd - Internet Relay Chat Daemon. This issue appears to have been introduced in unstable when the pidfile path was changed from /run/inspircd.pid to /run/inspircd/inspircd.pid in all locations except the AppArmor policy. The fix is straightforward: Index: inspircd-3.4.0/debian/apparmor/usr.sbin.inspircd === --- inspircd-3.4.0.orig/debian/apparmor/usr.sbin.inspircd +++ inspircd-3.4.0/debian/apparmor/usr.sbin.inspircd @@ -22,7 +22,7 @@ /etc/ldap/ldap.conf r, # pidfile used by inspircd. - /run/inspircd.pid w, + /run/inspircd/inspircd.pid w, # we need to be able to write to the log file # and also the old log when logrotate happends Christian -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#733598: Detect PACKAGE_NAME in config.h when shipped under /usr/include
Control: tags -1 + pending Hi Daniel, > Specifically, situations arise > where config.h from A and B are both included in the same compiler > invocation and warnings are generated about redefinitions of PACKAGE_NAME Pending with: https://salsa.debian.org/lintian/lintian/commit/693b07f13120a5d7eb2941a0bc68c264198a4f13 Kind regards Felix Lechner
Bug#947279: apt SIGABRT's with `malloc(): unsorted double linked list corrupted`
Package: apt
Version: 1.9.4
I experienced an unexpected SIGABRT signal being raised with apt(1). I
saw the following:
$ sudo apt install trousers
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
trousers
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 119 kB of archives.
After this operation, 369 kB of additional disk space will be used.
Get:1 http://ca.archive.ubuntu.com/ubuntu eoan/universe amd64
trousers amd64 0.3.14+fixed1-1build1 [119 kB]
Fetched 119 kB in 0s (257 kB/s)
malloc(): unsorted double linked list corrupted
Aborted
This appears to be a very difficult bug to reproduce. It only appeared
once and with the second invocation succeeding without issue.
Fortunately apport managed to preserve the core dump. After unpacking
it with apport-unpack and loading the core dump with gdb, the full
stack trace is as follows:
#0 __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 16383, 9223372036854775808, 16383,
9223372036854775808, 16384, 0, 0,
18446742974197923840, 65280, 18446744073709551615,
18446744073709551615,
8317666021292143937, 110386773516660,
4629771061636907072, 4629771061636907072}}
pid =
tid =
ret =
#1 0x7fd1dde66899 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction
= 0x0}, sa_mask = {__val = {
0 }}, sa_flags = 0, sa_restorer =
0x0}
sigs = {__val = {32, 0 }}
#2 0x7fd1dded138e in __libc_message (action=action@entry=do_abo
rt,
fmt=fmt@entry=0x7fd1ddffa3a5 "%s\n") at
../sysdeps/posix/libc_fatal.c:181
ap = {{gp_offset = 24, fp_offset = 32764, overflow_arg_area
= 0x7ffc2ecb2010,
reg_save_area = 0x7ffc2ecb1fa0}}
fd = 2
list =
nlist =
cp =
written =
#3 0x7fd1dded94dc in malloc_printerr (
str=str@entry=0x7fd1ddffc508 "malloc(): unsorted double linked
list corrupted") at malloc.c:5332
No locals.
#4 0x7fd1ddedc4bc in _int_malloc (av=av@entry=0x7fd1de02bb80
, bytes=bytes@entry=26)
at malloc.c:3744
next =
iters =
nb =
--Type for more, q to quit, c to continue without paging--
idx = 3
bin =
victim =
size =
victim_index =
remainder =
remainder_size =
block =
bit =
map =
fwd =
bck =
tcache_unsorted_count = 0
tcache_nb = 48
tc_idx = 1
return_cached =
__PRETTY_FUNCTION__ = "_int_malloc"
#5 0x7fd1ddede304 in __GI___libc_malloc (bytes=bytes@entry=26)
at malloc.c:3058
ar_ptr =
victim =
hook =
tbytes =
tc_idx =
__PRETTY_FUNCTION__ = "__libc_malloc"
#6 0x7fd1de0f71d9 in operator new (sz=26) at
../../../../src/libstdc++-v3/libsupc++/new_op.cc:50
p =
#7 0x7fd1de2ca4bd in void std::__cxx11::basic_string, std::allocator
>::_M_construct(char*, char*, std::forward_iterator_tag) ()
from /lib/x86_64-linux-gnu/libapt-pkg.so.5.90
--Type for more, q to quit, c to continue without paging--c
No symbol table info available.
#8 0x7fd1de3a58a3 in
pkgCache::PkgIterator::FullName[abi:cxx11](bool const&) const ()
from /lib/x86_64-linux-gnu/libapt-pkg.so.5.90
No symbol table info available.
#9 0x7fd1de378e86 in pkgDepCache::writeStateFile(OpProgress*,
bool) () from /lib/x86_64-linux-gnu/libapt-pkg.so.5.90
No symbol table info available.
#10 0x7fd1de369980 in
pkgDPkgPM::Go(APT::Progress::PackageManager*) () from /lib/x86_64-
linux-gnu/libapt-pkg.so.5.90
No symbol table info available.
#11 0x7fd1de39d9f0 in
pkgPackageManager::DoInstallPostFork(APT::Progress::PackageManager*)
() from /lib/x86_64-linux-gnu/libapt-pkg.so.5.90
No symbol table info available.
#12 0x7fd1de44433f in InstallPackages(CacheFile&, bool, bool,
bool) () from /lib/x86_64-linux-gnu/libapt-private.so.0.0
No symbol table info available.
#13 0x7fd1de44a2bc in DoInstall(CommandLine&) () from
/lib/x86_64-linux-gnu/libapt-private.so.0.0
No symbol table info available.
#14 0x7fd1de306aaf in
CommandLine::DispatchArg(CommandLine::Dispatch const*, bool) () from
/lib/x86_64-linux-gnu/libapt-pkg.so.5.90
No symbol table info available.
#15 0x7fd1de4397d7 in DispatchCommandLine(CommandLine&,
std::vector > const&) () from /lib/x86_64-
linux-gnu/libapt-private.so.0.0
No symbol table info available.
#16 0x557faf17e3ea in ?? ()
No sym
Bug#947280: src:paraview: FTBFS on armel an mipsel: undefined reference to `__atomic_fetch_add_8'
Package: src:paraview
Version: 5.7.0-3
Severity: serious
Tags: patch
Justification: FTBFS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
The same error is spotted in the logs of failed paraview 5.7.0 builds for
armel[1] and mipsel[2]:
/usr/bin/ld: ../../../../lib/mipsel-linux-gnu/libvtkprotobuf-pv5.7.so.5.7:
undefined reference to `__atomic_fetch_add_8'
[1]
https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=armel&ver=5.7.0-3&stamp=1576169428&raw=0
[2]
https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=mipsel&ver=5.7.0-1&stamp=1570637214&raw=0
Please find attached a patch aiming to solve this problem. Not sure it'll
be sufficient to build successfully, but it should solve this issue at
least.
Thanks,
_g.
- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-
iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4BOnkACgkQ7+hsbH/+
z4Mb8gf/Zv+G/8fE0SNC1wR9l81HtcduHKpMzvaDV7cuk35kAMr/W60ieLqfaT7p
Z9PPgi3YD+CqElw317qbGwwxQI0VuMDxiSVKEXJsZePrg2Ff25wgy4pwSBpSjel+
9kljY0vTp0QxbO2ryZi846aH46PnQF9bppdhUocNg6igeSB/x9TUHICvyhVQ5ZNS
gKDnR5jcKlk5DIr2TRA9Xa/TEIONfoQAjGs+tNwWDYpLQnwYHQ+vT+9gL80U6MkO
jRnVKbHI0V7KQj4saoQf4eqSz2tX29hecrMQcut43YxCX3YDiomV9CxrWDWAbIOf
rzWBeG0mAHxtzdD55XqbtuN+R8jEQQ==
=z9To
-END PGP SIGNATURE-
diff -Nru paraview-5.7.0/debian/changelog paraview-5.7.0/debian/changelog
--- paraview-5.7.0/debian/changelog 2019-12-11 10:16:00.0 +0100
+++ paraview-5.7.0/debian/changelog 2019-12-23 22:33:43.0 +0100
@@ -1,3 +1,10 @@
+paraview (5.7.0-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * New patch libatomic.patch: tentative fix for FTBFS on armel and mipsel
+
+ -- Gilles Filippini Mon, 23 Dec 2019 22:33:43 +0100
+
paraview (5.7.0-3) unstable; urgency=medium
* Hard-code Build-Dep on python3.8-dev. This wasn't being pulled in correctly
diff -Nru paraview-5.7.0/debian/patches/libatomic.patch
paraview-5.7.0/debian/patches/libatomic.patch
--- paraview-5.7.0/debian/patches/libatomic.patch 1970-01-01
01:00:00.0 +0100
+++ paraview-5.7.0/debian/patches/libatomic.patch 2019-12-23
22:33:43.0 +0100
@@ -0,0 +1,22 @@
+Index: paraview-5.7.0/ThirdParty/protobuf/vtkprotobuf/src/CMakeLists.txt
+===
+--- paraview-5.7.0.orig/ThirdParty/protobuf/vtkprotobuf/src/CMakeLists.txt
paraview-5.7.0/ThirdParty/protobuf/vtkprotobuf/src/CMakeLists.txt
+@@ -312,10 +312,16 @@ if (CMAKE_SYSTEM_NAME STREQUAL "Linux")
+ endif ()
+ endif ()
+
++if ((DEB_HOST_MULTIARCH STREQUAL "arm-linux-gnueabi") OR (DEB_HOST_MULTIARCH
STREQUAL "mipsel-linux-gnu"))
++ set(ATOMIC_LIB atomic)
++else ()
++ set(ATOMIC_LIB "")
++endif ()
++
+ target_link_libraries(vtkprotoc
+ PRIVATE
+ ${vtkprotoc_no_as_needed}
+ vtklibprotoc
+ ParaView::protobuf
+-Threads::Threads)
++Threads::Threads ${ATOMIC_LIB})
+ add_executable(ParaView::protoc ALIAS vtkprotoc)
diff -Nru paraview-5.7.0/debian/patches/series
paraview-5.7.0/debian/patches/series
--- paraview-5.7.0/debian/patches/series2019-12-11 10:16:00.0
+0100
+++ paraview-5.7.0/debian/patches/series2019-12-23 22:33:43.0
+0100
@@ -2,3 +2,4 @@
security-format.patch
override-fix.patch
python3.8.patch
+libatomic.patch
diff -Nru paraview-5.7.0/debian/rules paraview-5.7.0/debian/rules
--- paraview-5.7.0/debian/rules 2019-12-11 10:16:00.0 +0100
+++ paraview-5.7.0/debian/rules 2019-12-23 22:33:43.0 +0100
@@ -73,7 +73,8 @@
-DPARAVIEW_ENABLE_PDAL=ON \
-DPARAVIEW_ENABLE_XDMF3=ON \
-DPARAVIEW_ENABLE_MOTIONFX=ON \
- -DPARAVIEW_PLUGIN_ENABLE_EyeDomeLighting=ON
+ -DPARAVIEW_PLUGIN_ENABLE_EyeDomeLighting=ON \
+ -DDEB_HOST_MULTIARCH=$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
override_dh_auto_configure:
dh_auto_configure -- $(extra_flags)
Bug#947220: Root cause
I just tested it and the problem is that the dm_cache_smq module is missing from initramfs. Adding it to "/etc/initramfs-tools/modules" and running "update-initramfs -u" addresses the problem. I guess that lvm2 should add dm_cache and dm_cache_smq to /usr/share/initramfs-tools/hooks/lvm2, just like it has dm_mirror and dm_raid.
Bug#934264: Please update (4.6.2?) and provide/switch to python3
On Fri, Aug 09, 2019 at 10:39:06AM +0200, Andreas Tille wrote:
>...
> On Thu, Aug 08, 2019 at 04:58:03PM -0400, Yaroslav Halchenko wrote:
>...
> but unfortunately the
> configure step fails with:
>
> ...
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3 setup.py build
> running build
> --
> Building TVTK classes... Traceback (most recent call last):
> File "setup.py", line 474, in
> File "/usr/lib/python3/dist-packages/numpy/distutils/core.py", line 171, in
> setup
> return old_setup(**new_attr)
> File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 145, in
> setup
> return distutils.core.setup(**attrs)
> File "/usr/lib/python3.7/distutils/core.py", line 148, in setup
> dist.run_commands()
> File "/usr/lib/python3.7/distutils/dist.py", line 966, in run_commands
> self.run_command(cmd)
> File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
> cmd_obj.run()
> File "setup.py", line 268, in run
> File "setup.py", line 254, in build_tvtk_classes_zip
> File "tvtk/setup.py", line 99, in gen_tvtk_classes_zip
> gen.generate_code()
> File "/build/mayavi2-4.7.1/tvtk/code_gen.py", line 131, in generate_code
> self._write_wrapper_class(node, tvtk_name)
> File "/build/mayavi2-4.7.1/tvtk/code_gen.py", line 221, in
> _write_wrapper_class
> self.wrap_gen.generate_code(node, out)
> File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 250, in generate_code
> self._gen_methods(node, out)
> File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 371, in _gen_methods
> self._gen_get_methods(klass, out)
> File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 919, in
> _gen_get_methods
> if len(sig) == 1 and sig[0][1] is None:
> TypeError: object of type 'NoneType' has no len()
> E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1:
> /usr/bin/python3 setup.py build
> dh_auto_build: pybuild --build -i python{version} -p 3.7 returned exit code 13
> make: *** [debian/rules:10: build] Error 255
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> I: copying local configuration
> E: Failed autobuilding of package
>...
This one seems fixed by removing the vtk_63.py patch.
Next comes some error that goes away with python3-traits (just passed NEW).
That's not sufficient for building, but a bit further.
> Kind regards
>
> Andreas.
cu
Adrian
Bug#947278: xmlelements: missing Build-Depends: dh-python
Source: xmlelements Version: 1.0~prerelease-2 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, xmlelements/experimental FTBFS: fakeroot debian/rules clean dh clean --with=python2,python3 dh: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/i386-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/i386-linux-gnu/perl-base) at (eval 13) line 1. BEGIN failed--compilation aborted at (eval 13) line 1. make: *** [debian/rules:35: clean] Error 255 Andreas xmlelements_1.0~prerelease-2.log.gz Description: application/gzip
Bug#947277: arriero: missing Build-Depends: dh-python
Source: arriero Version: 0.7~20161228-1+build1 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, arriero/experimental FTBFS: fakeroot debian/rules clean dh clean --with python3 dh: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/i386-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/i386-linux-gnu/perl-base) at (eval 10) line 1. BEGIN failed--compilation aborted at (eval 10) line 1. make: *** [debian/rules:9: clean] Error 255 Andreas arriero_0.7~20161228-1+build1.log.gz Description: application/gzip
Bug#947275: libblockdev: Please omit libblockdev-mpath*, libblockdev-plugins-all on Ubuntu/i386
Package: libblockdev Version: 2.23-2 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal ubuntu-patch Hi Martin, In Ubuntu, we are in the process of moving the i386 architecture to a compatibility-only layer on amd64. We are keeping libblockdev on i386 because it's needed for udisks2, but the libblockdev-mpath* and libblockdev-plugins-all packagen built from this source have dependencies on other packages that are not being kept as part of the compatibility library set (multipath-tools) and are not needed by udisks2. We would like to drop these binary packages rather than keeping them around in the Ubuntu archive and uninstallable. Would you please consider applying the attached patch, or something like it, to omit building these binary packages on Ubuntu? Thanks for considering, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru libblockdev-2.23/debian/rules libblockdev-2.23/debian/rules --- libblockdev-2.23/debian/rules 2019-10-19 04:39:45.0 -0500 +++ libblockdev-2.23/debian/rules 2019-12-23 15:29:17.0 -0600 @@ -13,6 +13,11 @@ BUILD_PACKAGES = -Nlibblockdev-nvdimm-dev -Nlibblockdev-nvdimm2 endif +ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386) + BUILD_PACKAGES += -Nlibblockdev-mpath-dev -Nlibblockdev-mpath2 -Nlibblockdev-plugins-all +endif + + %: dh $@ $(BUILD_PACKAGES)
Bug#947276: libspiro: CVE-2019-19847
Source: libspiro Version: 1:20190731-2 Severity: normal Tags: security upstream Forwarded: https://github.com/fontforge/libspiro/issues/21 Hi, The following vulnerability was published for libspiro. Although the problematic function is exported, there seem at least in Debian not to be any users of this (and it's not in the 'advertised' API). But just filling the bug for tracking the upstream issue mainly. CVE-2019-19847[0]: | Libspiro through 20190731 has a stack-based buffer overflow in the | spiro_to_bpath0() function in spiro.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19847 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19847 [1] https://github.com/fontforge/libspiro/issues/21 Please adjust the affected versions in the BTS as needed. Regards, Salvatore -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947211: Regression in libsoxr0 0.1.3-2 makes ffmpeg segfault
> (gdb) bt > #0 __memmove_avx_unaligned_erms () at > ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:416 > #1 0x706c6dcd in memcpy (__len=3556, __src=, > __dest=0x0) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 > #2 _soxr_interleave_f (data_type=, > dest0=0x556386c0, src=, n=889, ch=1, > seed=0x55635e00) at ./src/data-io.c:204 Interesting. It apparently calls a subroutine to perform an *unaligned* memmove on x86. I wonder whether this crash is x86-specific. Thanks for the reproducer, I will look at it after Christmas. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#947274: singularity: missing Build-Depends: python3-setuptools
Source: singularity
Version: 1.0a1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
singularity/experimental FTBFS in a minimal chroot:
fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py clean
Traceback (most recent call last):
File "setup.py", line 5, in
from setuptools import setup, find_packages
ModuleNotFoundError: No module named 'setuptools'
E: pybuild pybuild:341: clean: plugin distutils failed with: exit code=1:
python3.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:4: clean] Error 255
Andreas
singularity_1.0a1-1.log.gz
Description: application/gzip
Bug#901965: hid2hci.patch
Hi bluez maintainers, A person got in touch with debian-user-french people asking for help because she was facing the issue described in this bug report. I wonder if there is any progress on finding a solution ? For info, this problem is also mentionned in the bug report #889110 ([1]) (closed by Michael Biebl on 9 Feb 2018). And in the RedHat Bug 1563554 ([2]) suggesting a workaround by just adding in front of the line containing in the file /lib/udev/rules.d/97-hid2hci.rules. Can you, please, advice what is the best solution to, at least, mitigate the risk of being hit by this bug ? Specifying the ACTION like described in the RH bugreport or using the driver usbhid like in the Тут Root's proposed patch. And about further investigations, unfortunately, I cannot reproduce the bug and, then, I am not able to investigate further to know if it is really a driver or kernel bug. Regards, Jean-Marc https://6jf.be/keys/ED863AD1.txt [1] https://bugs.debian.org/889110 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1563554 pgpMRzCyEtr6N.pgp Description: PGP signature
Bug#946657: CVE-2019-19725 not fixed in 12.2.0-1
Hi Robert, On Mon, Dec 23, 2019 at 08:10:38PM +0100, Robert Luberda wrote: > Salvatore Bonaccorso writes: > > Control: reopen -1 > > Control: found -1 12.2.0-1 > > > Hi, > > > >> sysstat (12.2.0-1) unstable; urgency=medium > >> . > >>* New upstream stable version: > >> + fixes double free in check_file_actlst in check_file_actlst in > >>sa_common.c (CVE-2019-19725, closes: #946657). > > > > But this is not actually true I believe. > > https://github.com/sysstat/sysstat/commit/a5c8abd4a481ee6e27a3acf00e6d9b0f023e20ed > > is not applied in 12.2.0-1, and I do not see it applied as patch as > > I don't know why, but I've assumed that 12.2.0 fixed the issue :( > Thanks for noticing my mistake; I'll apply the upstream patch in -2 shortly. No worries and thanks for following up with the fix! Regards, Salvatore
Bug#947273: odhcp6c: FTBFS with GCC 9: error: '__builtin_strncpy' specified bound 16 equals destination size
Source: odhcp6c Version: 1.1+git20160131-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, odhcp6c FTBFS with GCC 9: [ 33%] Building C object CMakeFiles/odhcp6c.dir/src/dhcpv6.c.o /usr/bin/cc -D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/build/odhcp6c-1.1+git20160131=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -std=c99 -Wall -Werror -Wextra -pedantic -o CMakeFiles/odhcp6c.dir/src/dhcpv6.c.o -c /build/odhcp6c-1.1+git20160131/src/dhcpv6.c In file included from /usr/include/string.h:494, from /build/odhcp6c-1.1+git20160131/src/dhcpv6.c:22: In function 'strncpy', inlined from 'init_dhcpv6' at /build/odhcp6c-1.1+git20160131/src/dhcpv6.c:132:2: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~ cc1: all warnings being treated as errors Andreas odhcp6c_1.1+git20160131-1.log.gz Description: application/gzip
Bug#947121: on the doxygen exit code
I realized I had already reported in the past that doxygen may discard the exit codes of other commands it invokes. I have added a note about reporting this error here: https://github.com/doxygen/doxygen/issues/6653#issuecomment-568584189 Paolo
Bug#947272: blt: FTBFS with GCC 9: error: argument 'argv' doesn't match prototype
Source: blt
Version: 2.5.3+dfsg-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
blt/experimental FTBFS, most likely due to GCC 9 bieng the default
compiler nowadays:
x86_64-linux-gnu-gcc -c -Wall -g -O2 -fdebug-prefix-map=/build/blt-2.5.3+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -I. -I.
-I/usr/include/tcl8.7/tk-private/generic
-I/usr/include/tcl8.7/tk-private/generic -I/usr/include/tcl8.7/tk-private/unix
-I/usr/include/tcl8.7 -I/usr/include/tcl8.7/tcl-private/generic
-I/usr/include/tcl8.7/tcl-private/unix bltBgexec.c
In file included from /usr/include/tcl8.7/tcl.h:2383,
from bltInt.h:39,
from bltBgexec.c:30:
bltBgexec.c: In function 'DisableTriggers':
bltBgexec.c:1451:3: warning: passing argument 5 of 'Tcl_UntraceVar2' from
incompatible pointer type [-Wincompatible-pointer-types]
1451 | VariableProc, bgPtr);
| ^~~~
| |
| char * (*)(void *, Tcl_Interp *, char *, char *, int) {aka char *
(*)(void *, struct Tcl_Interp *, char *, char *, int)}
/usr/include/tcl8.7/tclDecls.h:3998:48: note: in definition of macro
'Tcl_UntraceVar'
3998 | Tcl_UntraceVar2(interp, varName, NULL, flags, proc, clientData)
|^~~~
In file included from /usr/include/tcl8.7/tcl.h:2383,
from bltInt.h:39,
from bltBgexec.c:30:
/usr/include/tcl8.7/tclDecls.h:800:34: note: expected 'char * (*)(void *,
Tcl_Interp *, const char *, const char *, int)' {aka 'char * (*)(void *, struct
Tcl_Interp *, const char *, const char *, int)'} but argument is of type 'char
* (*)(void *, Tcl_Interp *, char *, char *, int)' {aka 'char * (*)(void *,
struct Tcl_Interp *, char *, char *, int)'}
800 | int flags, Tcl_VarTraceProc *proc,
|~~^~~~
bltBgexec.c: In function 'BgexecCmd':
bltBgexec.c:1914:12: error: argument 'argv' doesn't match prototype
1914 | char **argv; /* Argument strings. */
|^~~~
bltBgexec.c:50:20: error: prototype declaration
50 | static Tcl_CmdProc BgexecCmd;
|^
In file included from /usr/include/tcl8.7/tcl.h:2383,
from bltInt.h:39,
from bltBgexec.c:30:
bltBgexec.c:2011:59: warning: passing argument 5 of 'Tcl_TraceVar2' from
incompatible pointer type [-Wincompatible-pointer-types]
2011 | if (Tcl_TraceVar(interp, bgPtr->statVar, TRACE_FLAGS, VariableProc,
bgPtr) != TCL_OK) {
| ^~~~
| |
| char *
(*)(void *, Tcl_Interp *, char *, char *, int) {aka char * (*)(void *, struct
Tcl_Interp *, char *, char *, int)}
/usr/include/tcl8.7/tclDecls.h:3995:46: note: in definition of macro
'Tcl_TraceVar'
3995 | Tcl_TraceVar2(interp, varName, NULL, flags, proc, clientData)
| ^~~~
In file included from /usr/include/tcl8.7/tcl.h:2383,
from bltInt.h:39,
from bltBgexec.c:30:
/usr/include/tcl8.7/tclDecls.h:770:23: note: expected 'char * (*)(void *,
Tcl_Interp *, const char *, const char *, int)' {aka 'char * (*)(void *, struct
Tcl_Interp *, const char *, const char *, int)'} but argument is of type 'char
* (*)(void *, Tcl_Interp *, char *, char *, int)' {aka 'char * (*)(void *,
struct Tcl_Interp *, char *, char *, int)'}
770 | Tcl_VarTraceProc *proc,
| ~~^~~~
make[3]: *** [Makefile:270: bltBgexec.o] Error 1
Andreas
blt_2.5.3+dfsg-5.log.gz
Description: application/gzip
Bug#946558: stretch-pu: package clamav/0.102.1+dfsg-0+deb9u1
On 2019-12-10 23:47:05 [+0100], To sub...@bugs.debian.org wrote: > This updates clamav to its latest version provided by upstream. The > import part is the fix for CVE-2019-15961. I slightly updated the package to - add the new `clamonacc' binary to the clamav-daemon package. - remove the `ScanOnAccess' option from the postinst/debconf script. The option is deprecated and the functionality moved into the clamonacc binary. Sebastian diff --git a/debian/changelog b/debian/changelog index f41cde8..f83f907 100644 --- a/debian/changelog +++ b/debian/changelog @@ -6,8 +6,10 @@ clamav (0.102.1+dfsg-0+deb9u1) stretch; urgency=medium - Let freshclam show progress during download (Closes: #690789). * Update symbol file. * Add libfreshclam to the libclamav9 package. + * Add the clamonacc binary to the clamav-daemon package. + * Drop ScanOnAccess option. The clamonacc provides this functionality. - -- Sebastian Andrzej Siewior Sun, 08 Dec 2019 22:05:51 +0100 + -- Sebastian Andrzej Siewior Mon, 23 Dec 2019 21:07:34 +0100 clamav (0.101.4+dfsg-0+deb9u1) stretch; urgency=medium diff --git a/debian/clamav-daemon.config.in b/debian/clamav-daemon.config.in index 60bef89..131336c 100644 --- a/debian/clamav-daemon.config.in +++ b/debian/clamav-daemon.config.in @@ -72,7 +72,6 @@ set_debconf_value daemon LogSyslog set_debconf_value daemon LogFile set_debconf_value daemon LogTime set_debconf_value daemon LogRotate -set_debconf_value daemon ScanOnAccess set_debconf_value daemon OnAccessMaxFileSize set_debconf_value daemon AllowAllMatchScan set_debconf_value daemon ForceToDisk @@ -327,13 +326,10 @@ while [ "$STATE" != "End" ]; do StateGeneric low clamav-daemon/LogTime LogRotate LogFile ;; "LogRotate") -StateGeneric low clamav-daemon/LogRotate ScanOnAccess LogFile -;; -"ScanOnAccess") -StateGeneric low clamav-daemon/ScanOnAccess OnAccessMaxFileSize LogFile +StateGeneric low clamav-daemon/LogRotate LogFile ;; "OnAccessMaxFileSize") -StateGeneric low clamav-daemon/OnAccessMaxFileSize AllowAllMatchScan ScanOnAccess +StateGeneric low clamav-daemon/OnAccessMaxFileSize AllowAllMatchScan ;; "AllowAllMatchScan") StateGeneric low clamav-daemon/AllowAllMatchScan ForceToDisk OnAccessMaxFileSize diff --git a/debian/clamav-daemon.install b/debian/clamav-daemon.install index 1ae9a50..ef63c2a 100644 --- a/debian/clamav-daemon.install +++ b/debian/clamav-daemon.install @@ -2,5 +2,6 @@ debian/script usr/share/bug/clamav-daemon/ debian/tmp/lib/systemd/system/clamav-daemon.service debian/tmp/usr/bin/clamconf debian/tmp/usr/bin/clamdtop +debian/tmp/usr/bin/clamonacc debian/tmp/usr/sbin/clamd debian/usr.sbin.clamd etc/apparmor.d/ diff --git a/debian/clamav-daemon.postinst.in b/debian/clamav-daemon.postinst.in index 77f7c2c..a51cf21 100644 --- a/debian/clamav-daemon.postinst.in +++ b/debian/clamav-daemon.postinst.in @@ -116,12 +116,8 @@ case "$1" in db_get clamav-daemon/BytecodeTimeout || true BytecodeTimeout="$RET" fi -db_get clamav-daemon/ScanOnAccess || true -ScanOnAccess="$RET" -if [ "$ScanOnAccess" = "true" ]; then - db_get clamav-daemon/OnAccessMaxFileSize || true - OnAccessMaxFileSize="$RET" -fi +db_get clamav-daemon/OnAccessMaxFileSize || true +OnAccessMaxFileSize="$RET" db_get clamav-daemon/AllowAllMatchScan || true AllowAllMatchScan="$RET" db_get clamav-daemon/ForceToDisk || true @@ -148,8 +144,6 @@ case "$1" in # Use the defaults instead of the bogus values created by that versions. db_metaget clamav-daemon/LogRotate default || true LogRotate="$RET" - db_metaget clamav-daemon/ScanOnAccess default || true - ScanOnAccess="$RET" OnAccessMaxFileSize="" OnAccessIncludePath="" OnAccessExcludePath="" @@ -327,7 +321,6 @@ SendBufTimeout $SendBufTimeout MaxQueue $MaxQueue ExtendedDetectionInfo $ExtendedDetectionInfo OLE2BlockMacros $OLE2BlockMacros -ScanOnAccess $ScanOnAccess AllowAllMatchScan $AllowAllMatchScan ForceToDisk $ForceToDisk DisableCertCheck $DisableCertCheck diff --git a/debian/clamav-daemon.templates b/debian/clamav-daemon.templates index 8b71902..0b8ea43 100644 --- a/debian/clamav-daemon.templates +++ b/debian/clamav-daemon.templates @@ -143,11 +143,6 @@ Type: boolean Default: true _Description: Do you want to enable log rotation? -Template: clamav-daemon/ScanOnAccess -Type: boolean -Default: false -_Description: Do you want to enable on-access scanning? - Template: clamav-daemon/OnAccessMaxFileSize Type: string Default: 5M
Bug#947271: RFS: filezilla/3.46.3-1 -- Full-featured graphical FTP/FTPS/SFTP client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "filezilla" * Package name: filezilla Version : 3.46.3-1 Upstream Author : [fill in name and email of upstream] * URL : https://filezilla-project.org/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/filezilla Section : net It builds those binary packages: filezilla - Full-featured graphical FTP/FTPS/SFTP client filezilla-common - Architecture independent files for filezilla To access further information about this package, please visit the following URL: https://mentors.debian.net/package/filezilla Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.46.3-1.dsc Changes since the last upload: * Team Upload * New upstream version 3.46.3 Note: Depends on libfilezilla 0.19.3-1 in mentors. Regards Phil -- *** Playing the game for the games sake. *** Twitter: @kathenasorg IRC: kathenas signature.asc Description: This is a digitally signed message part
Bug#947270: RFS: libfilezilla/0.19.3-1 -- build high-performing platform-independent programs (development
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libfilezilla" * Package name: libfilezilla Version : 0.19.3-1 Upstream Author : [fill in name and email of upstream] * URL : https://lib.filezilla-project.org/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/libfilezilla Section : libs It builds those binary packages: libfilezilla-dev - build high-performing platform-independent programs (development) libfilezilla0 - build high-performing platform-independent programs (runtime lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libfilezilla Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.19.3-1.dsc Changes since the last upload: * Team upload * New upstream version 0.19.3 Regards Phil -- *** Playing the game for the games sake. *** Twitter: @kathenasorg IRC: kathenas signature.asc Description: This is a digitally signed message part
Bug#947269: lintian: spelling mistake in no-dh-sequencer tag
Package: lintian Version: 2.42.0 Severity: minor For a package that does not use dh7-style debhelper, this is shown: […] N:The debian/rules does not use the dh &@ sequencer. […] I believe the “&@” is a misspelling (probably of “$@”), and people might consider it line noise, too (ponder whether this should be included in the message at all). -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils 2.33.1-6 ii bzip21.0.8-2 ii diffstat 1.63-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.37-6 ii gettext 0.19.8.1-10 ii gpg 2.2.17-3 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b1 ii libarchive-zip-perl 1.67-1 ii libberkeleydb-perl 0.62-1+b1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.44-1 ii libclass-accessor-perl 0.51-1 ii libclass-xsaccessor-perl 1.19-3+b3 ii libclone-perl0.43-2 ii libdigest-sha-perl 6.02-1+b2 ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.75-1 ii libipc-run-perl 20180523.0-2 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii libmldbm-perl2.05-2 ii libmoo-perl 2.003006-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.008000-1 ii liburi-perl 1.76-1 ii libxml-libxml-perl 2.0134+dfsg-1+b1 ii libyaml-libyaml-perl 0.80+repack-2+b1 ii man-db 2.9.0-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl]5.30.0-9 ii t1utils 1.41-3 ii xz-utils 5.2.4-1 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: ii binutils-multiarch 2.33.1-6 ii libhtml-parser-perl3.72-3+b4 pn libtext-template-perl -- no debconf information
Bug#947268: gnat-gps-common: ships /usr/share/javascript/prototype/prototype.js
Package: gnat-gps-common Version: 19.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships a file owned by libjs-prototype: /usr/share/javascript/prototype/prototype.js >From the attached log (scroll to the bottom...): Preparing to unpack .../gnat-gps-common_19.2-1_all.deb ... Unpacking gnat-gps-common (19.2-1) ... dpkg: error processing archive /var/cache/apt/archives/gnat-gps-common_19.2-1_all.deb (--unpack): trying to overwrite '/usr/share/javascript/prototype/prototype.js', which is also in package libjs-prototype 1.7.1-3 Errors were encountered while processing: /var/cache/apt/archives/gnat-gps-common_19.2-1_all.deb Andreas libjs-prototype=1.7.1-3_gnat-gps-common=19.2-1.log.gz Description: application/gzip
Bug#947267: ipxe: broken-symlink /usr/lib/ipxe/ipxe.efi -> /boot/ipxe.efi
Package: ipxe Version: 1.0.0+git-20190125.36a4c85-3 Severity: minor User: debian...@lists.debian.org Usertags: adequate broken-symlink Apparently, /boot/ipxe.efi is only pertinent on very few architectures. -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) -- no debconf information
Bug#936729: imgsizer: diff for NMU version 2.10-0.1
Control: tags 936729 + patch Control: tags 936729 + pending Dear maintainer, I've prepared an NMU for imgsizer (versioned as 2.10-0.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru imgsizer-2.7/control imgsizer-2.10/control --- imgsizer-2.7/control 1970-01-01 02:00:00.0 +0200 +++ imgsizer-2.10/control 2019-06-12 17:36:12.0 +0300 @@ -0,0 +1,25 @@ +# This is not a real Debian control file, though the syntax is compatible. +# It's project metadata for the shipper tool + +Package: imgsizer + +Description: Fill in WIDTH and HEIGHT attributes for IMG tags. + This tool auto-generates or corrects WIDTH and HEIGHT parameters + into HTML IMG tags, making page loading faster. + +XBS-Destinations: ubuntu-devel-disc...@lists.ubuntu.com + +Homepage: http://www.catb.org/~esr/imgsizer + +X-Repository-URL: https://gitlab.com/esr/imgsizer + +XBS-HTML-Target: index.html + +XBS-Debian-Packages: imgsizer + +XBS-Logo: crate.png + +#XBS-Project-Tags: HTML + +XBS-VC-Tag-Template: %(version)s + diff -Nru imgsizer-2.7/COPYING imgsizer-2.10/COPYING --- imgsizer-2.7/COPYING 2004-08-06 02:59:17.0 +0300 +++ imgsizer-2.10/COPYING 2019-06-12 17:36:12.0 +0300 @@ -1,340 +1,27 @@ - GNU GENERAL PUBLIC LICENSE - Version 2, June 1991 + BSD LICENSE - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. +Copyright (c) 2015, Eric S. Raymond +All rights reserved. - Preamble - - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software--to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Library General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - - GNU GENERAL PUBLIC LICENSE - TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION - - 0. This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this General Public License. The "Program", below, -refers to any such program or work, and a "work based on the Program" -means either the Program or any derivative work under copyright law: -that is to say, a work containing the Program or a portion of it, -either verbatim or with modifications and/or translated into another -language. (Hereinafter, translation is included without limitation in -the term "modification".) Each licensee is addressed as "you". - -Activities other than copying,
Bug#936924: Moving libsvm to Debian Science team
On Mon, Dec 23, 2019 at 03:06:37PM -0500, Chen-Tse Tsai wrote: > I have a quick question. Previously the python modules are installed to > /usr/share/pyshared/. Should I use /usr/lib/python3/dist-packages instead > if I change it to python3? I see this in the policy and this is also what > liblinear uses. Just want to double check. Yes, follow liblinear example. Thanks for your work on this Andreas. -- http://fam-tille.de
Bug#946557: buster-pu: package clamav/0.102.1+dfsg-0+deb10u1
On 2019-12-10 23:46:47 [+0100], To sub...@bugs.debian.org wrote: > It is unstable for 10 days now. It did not migrate to testing due to a > debci regression in pg-snakeoil. I opened a bug against pg-snakeoil, I > don't see anything wrong within clamav. In the meantime the package migrated into testing. I didn't manage to reproduce the ci bug. The pg-snakeoil package change its testsuite to avoid downloading the whole database on each test. I slightly updated the package to - add the new `clamonacc' binary to the clamav-daemon package. - remove the `ScanOnAccess' option from the postinst/debconf script. The option is deprecated and the functionality moved into the clamonacc binary. Sebastian diff --git a/debian/changelog b/debian/changelog index bca40e2..d3cd598 100644 --- a/debian/changelog +++ b/debian/changelog @@ -6,8 +6,10 @@ clamav (0.102.1+dfsg-0+deb10u1) buster; urgency=medium - Let freshclam show progress during download (Closes: #690789). * Update symbol file. * Add libfreshclam to the libclamav9 package. + * Add the clamonacc binary to the clamav-daemon package. + * Drop ScanOnAccess option. The clamonacc provides this functionality. - -- Sebastian Andrzej Siewior Sun, 08 Dec 2019 12:40:16 +0100 + -- Sebastian Andrzej Siewior Mon, 23 Dec 2019 21:04:45 +0100 clamav (0.101.4+dfsg-0+deb10u1) buster; urgency=medium diff --git a/debian/clamav-daemon.config.in b/debian/clamav-daemon.config.in index 60bef89..131336c 100644 --- a/debian/clamav-daemon.config.in +++ b/debian/clamav-daemon.config.in @@ -72,7 +72,6 @@ set_debconf_value daemon LogSyslog set_debconf_value daemon LogFile set_debconf_value daemon LogTime set_debconf_value daemon LogRotate -set_debconf_value daemon ScanOnAccess set_debconf_value daemon OnAccessMaxFileSize set_debconf_value daemon AllowAllMatchScan set_debconf_value daemon ForceToDisk @@ -327,13 +326,10 @@ while [ "$STATE" != "End" ]; do StateGeneric low clamav-daemon/LogTime LogRotate LogFile ;; "LogRotate") -StateGeneric low clamav-daemon/LogRotate ScanOnAccess LogFile -;; -"ScanOnAccess") -StateGeneric low clamav-daemon/ScanOnAccess OnAccessMaxFileSize LogFile +StateGeneric low clamav-daemon/LogRotate LogFile ;; "OnAccessMaxFileSize") -StateGeneric low clamav-daemon/OnAccessMaxFileSize AllowAllMatchScan ScanOnAccess +StateGeneric low clamav-daemon/OnAccessMaxFileSize AllowAllMatchScan ;; "AllowAllMatchScan") StateGeneric low clamav-daemon/AllowAllMatchScan ForceToDisk OnAccessMaxFileSize diff --git a/debian/clamav-daemon.install b/debian/clamav-daemon.install index 1ae9a50..ef63c2a 100644 --- a/debian/clamav-daemon.install +++ b/debian/clamav-daemon.install @@ -2,5 +2,6 @@ debian/script usr/share/bug/clamav-daemon/ debian/tmp/lib/systemd/system/clamav-daemon.service debian/tmp/usr/bin/clamconf debian/tmp/usr/bin/clamdtop +debian/tmp/usr/bin/clamonacc debian/tmp/usr/sbin/clamd debian/usr.sbin.clamd etc/apparmor.d/ diff --git a/debian/clamav-daemon.postinst.in b/debian/clamav-daemon.postinst.in index a4a3595..0770634 100644 --- a/debian/clamav-daemon.postinst.in +++ b/debian/clamav-daemon.postinst.in @@ -116,12 +116,8 @@ case "$1" in db_get clamav-daemon/BytecodeTimeout || true BytecodeTimeout="$RET" fi -db_get clamav-daemon/ScanOnAccess || true -ScanOnAccess="$RET" -if [ "$ScanOnAccess" = "true" ]; then - db_get clamav-daemon/OnAccessMaxFileSize || true - OnAccessMaxFileSize="$RET" -fi +db_get clamav-daemon/OnAccessMaxFileSize || true +OnAccessMaxFileSize="$RET" db_get clamav-daemon/AllowAllMatchScan || true AllowAllMatchScan="$RET" db_get clamav-daemon/ForceToDisk || true @@ -148,8 +144,6 @@ case "$1" in # Use the defaults instead of the bogus values created by that versions. db_metaget clamav-daemon/LogRotate default || true LogRotate="$RET" - db_metaget clamav-daemon/ScanOnAccess default || true - ScanOnAccess="$RET" OnAccessMaxFileSize="" OnAccessIncludePath="" OnAccessExcludePath="" @@ -327,7 +321,6 @@ SendBufTimeout $SendBufTimeout MaxQueue $MaxQueue ExtendedDetectionInfo $ExtendedDetectionInfo OLE2BlockMacros $OLE2BlockMacros -ScanOnAccess $ScanOnAccess AllowAllMatchScan $AllowAllMatchScan ForceToDisk $ForceToDisk DisableCertCheck $DisableCertCheck diff --git a/debian/clamav-daemon.templates b/debian/clamav-daemon.templates index 8b71902..0b8ea43 100644 --- a/debian/clamav-daemon.templates +++ b/debian/clamav-daemon.templates @@ -143,11 +143,6 @@ Type: boolean Default: true _Description: Do you want to enable log rotation? -Template: clamav-daemon/ScanOnAccess -Type: boolean -Default: false -_Description: Do you want to enable on-access scanning? - Template: clamav-daemon/OnAccessMaxFileSize Type: string Default: 5M
Bug#945660: closed by Sylvestre Ledru (Bug#945660: fixed in llvm-defaults 0.49~exp2)
> python-clang - transitional package to python3-clang > python-lldb - transitional package to python3-lldb i dont think that's how you're supposed to use python- packages - what's the reason for keeping them around as transitionals? people either gets them as a dependency or will need to migrate their code to python3 anyhow; i think it's better to simply remove them Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#947266: python3-geopandas: ships /usr/lib/python3/dist-packages/examples/*
Package: python3-geopandas Version: 0.6.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, python3-geopandas ships files with generic names at the generic location /usr/lib/python3/dist-packages/examples/ causing file clashes (e.g. on README.txt) with other packages doing the same wrong thing. Moving this to /usr/lib/python3/dist-packages/examples/geopandas/ should probably be OK. Andreas
Bug#947265: python3-lmfit: ships /usr/lib/python3/dist-packages/examples/*
Package: python3-lmfit Version: 1.0.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, python3-lmfit ships files with generic names at the generic location /usr/lib/python3/dist-packages/examples/ causing file clashes (e.g. on README.txt) with other packages doing the same wrong thing. Moving this to /usr/lib/python3/dist-packages/examples/lmfit/ should probably be OK. Andreas
Bug#947264: lintian: overly generic file name: /usr/lib/python3/dist-packages/examples/README.txt
Package: lintian Version: 2.42.0 Severity: normal Hi, please add /usr/lib/python3/dist-packages/examples/README.txt (and possible variants thereof, in case lintian uses some wildcards for this check) to the list of overly generic file names. This is currently shipped by python3-geopandas (0.6.2-1) and python3-lmfit (1.0.0-1) in sid. Looking at python3-geopandas/sid, /usr/lib/python3/dist-packages/examples/[^/]* should be disallowed (but /usr/lib/python3/dist-packages/examples/.*/[^/]* should be OK). Andreas
Bug#943923: (no subject)
Control: reassign -1 src:python-apptools 4.4.0-3
Bug#947263: python3-iniparse: missing Breaks+Replaces: python-iniparse
Package: python3-iniparse Version: 0.4-2.3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../python3-iniparse_0.4-2.3_all.deb ... Unpacking python3-iniparse (0.4-2.3) ... dpkg: error processing archive /var/cache/apt/archives/python3-iniparse_0.4-2.3_all.deb (--unpack): trying to overwrite '/usr/share/doc-base/python-iniparse', which is also in package python-iniparse 0.4-2.2 Errors were encountered while processing: /var/cache/apt/archives/python3-iniparse_0.4-2.3_all.deb cheers, Andreas python-iniparse=0.4-2.2_python3-iniparse=0.4-2.3.log.gz Description: application/gzip
Bug#943923: (no subject)
Control: found -1 src:python-apptools/4.4.0-3 Control: fixed -1 src:python-apptools/4.4.0-4 Attempting to get this package to migrate, which I think it failing because the python-apptools binary package is now gone.
Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile
Hi Hilmar, ii texlive-fonts-extra 2018.20190227-2 all TeX Live: This is a quite old version of the package. What happens if you run dist-upgrade? I'm tempted to say that running dist-upgrade has been a nightmare sufficiently many times that I'm not even considering doing it to find out what would happen to fourier-orns: sorry. And last year is not *that* old, is it? At least I have the file, using locate and ls -l Thanks, that's good to know! Kind regards, Sébastien.
Bug#891312: released new version
Hello, I did a new upload of jackson-core 2.10.1. Kind regards -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Bug#947211: Regression in libsoxr0 0.1.3-2 makes ffmpeg segfault
Control: fixed 944017 0.1.3-1 Control: reassign -1 src:libsoxr Control: forcemerge 944017 -1 On Sun, Dec 22, 2019 at 10:36:38PM +, Etienne Dechamps wrote: > Package: libsoxr0 > Version: 0.1.3-2 > Control: fixed -1 0.1.3-1 > > Steps to reproduce: > … > Segmentation fault (core dumped) Aye, this is bug #944017, merging. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
On 23 December 2019 at 12:43, Graham Inggs wrote: | On Sun, 22 Dec 2019 at 17:04, Graham Inggs wrote: | > On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel wrote: | > > On the other hand the ppc64 is one of 'blocking compilation' so it can't | > > really segfaults at tests. | > | > I don't know what that means, but both the r-bioc-iranges and | > r-bioc-s4vectors autopkgtests with r-base/3.6.2-1 on ppc64el showed: | > | > An irrecoverable exception occurred. R is aborting now ... | > Segmentation fault (core dumped) | | Looking closer, the failing tests above were with | r-base/3.6.2-1build1, which was uploaded by an Ubuntu developer and | included the PPC fix. | | No autopkgtests were run with r-base/3.6.2-1 in Ubuntu because it | didn't build on all architectures. | | Autopkgtests continue to pass with r-base/3.6.2-2 on ppc64el, and the | only diff between it and 3.6.2-1build1 is in the changelog [1]. | Autopkgtests continue to fail with r-base/3.6.2-2 on amd64, arm64, | armhf and s390x. I would be very surprised if these were not self-inflicted by us. I know CRAN (much) better than BioC, but both of them are doing extensive self-tests (and generally without any arbitrary restrictions, say about timing and versions) we may impose. I tried a quick test on a Debian testing machine I use for (extensive) reverse dependency checks (at the upstream level) but it was incloncusive. Still a pity that r-base is held back by this. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
