Bug#955534: gdal-bin on debian SID - unmet dependencies
Package: gdal-bin Version: 3.0.4+dfsg-1+b1 When I invoke `apt-get install gdal-bin' i get the following error: ``` Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gdal-bin : Depends: python3-gdal (= 3.0.4+dfsg-1+b1) but it is not going to be installed Depends: libgdal26 (>= 3.0.0) but it is not going to be installed E: Unable to correct problems, you have held broken packages. ```
Bug#951265: autopkgtest is passing with new upstream release
Control: done -1 2.0.17-1 Tracker now shows "Required age reduced by 3 days because of autopkgtest" indicating autopkgtest now passes.
Bug#955533: gcc-9: -fsanitize-coverage=trace-pc causes undefined reference to __sanitizer_cov_trace_pc
Package: gcc-9 Version: 9.3.0-8 Severity: minor Dear Maintainer, $ gcc-9 -fsanitize-coverage=trace-pc hello.c /usr/bin/ld: /tmp/ccre6iuY.o: in function `main': hello.c:(.text+0xa): undefined reference to `__sanitizer_cov_trace_pc' /usr/bin/ld: hello.c:(.text+0x25): undefined reference to `__sanitizer_cov_trace_pc' collect2: error: ld returned 1 exit status The same symptom is also observed in gcc-10 package. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-45-generic (SMP w/4 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-9 depends on: ii binutils 2.34-5 ii cpp-9 9.3.0-8 ii gcc-9-base9.3.0-8 ii libc6 2.30-2 ii libcc1-0 10-20200324-1 ii libgcc-9-dev 9.3.0-8 ii libgcc-s1 10-20200324-1 ii libgmp10 2:6.2.0+dfsg-4 ii libisl22 0.22.1-1 ii libmpc3 1.1.0-1 ii libmpfr6 4.0.2-1 ii libstdc++610-20200324-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages gcc-9 recommends: ii libc6-dev 2.30-2 Versions of packages gcc-9 suggests: pn gcc-9-doc pn gcc-9-locales pn gcc-9-multilib -- no debconf information
Bug#951624: webdis: diff for NMU version 0.1.4+dfsg-1.1
Control: tags 951624 + patch Control: tags 951624 + pending Dear maintainer, I've prepared an NMU for webdis (versioned as 0.1.4+dfsg-1.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru webdis-0.1.4+dfsg/debian/changelog webdis-0.1.4+dfsg/debian/changelog --- webdis-0.1.4+dfsg/debian/changelog 2018-08-26 15:30:36.0 +0300 +++ webdis-0.1.4+dfsg/debian/changelog 2020-04-02 09:09:21.0 +0300 @@ -1,3 +1,10 @@ +webdis (0.1.4+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Skip tests that require python-msgpack. (Closes: #951624) + + -- Adrian Bunk Thu, 02 Apr 2020 09:09:21 +0300 + webdis (0.1.4+dfsg-1) unstable; urgency=medium * New upstream version 0.1.4+dfsg diff -Nru webdis-0.1.4+dfsg/debian/control webdis-0.1.4+dfsg/debian/control --- webdis-0.1.4+dfsg/debian/control 2018-08-25 10:53:40.0 +0300 +++ webdis-0.1.4+dfsg/debian/control 2020-04-02 09:08:29.0 +0300 @@ -10,7 +10,6 @@ libmsgpack-dev, redis-server, python-unittest2, -python-msgpack (>= 0.3), pkg-config Standards-Version: 4.2.0 Vcs-Git: https://salsa.debian.org/debian/webdis.git diff -Nru webdis-0.1.4+dfsg/debian/tests/control webdis-0.1.4+dfsg/debian/tests/control --- webdis-0.1.4+dfsg/debian/tests/control 2018-08-25 10:53:40.0 +0300 +++ webdis-0.1.4+dfsg/debian/tests/control 2020-04-02 09:09:12.0 +0300 @@ -1,4 +1,4 @@ Tests: webdis Depends: @, redis-server, build-essential, libevent-dev, - python-unittest2, python-msgpack, net-tools + python-unittest2, net-tools Restrictions: isolation-container, allow-stderr
Bug#949863: Info received (#949863: please enable CONFIG_NET_SWITCHDEV)
Ben Hutchings writes: > On Mon, 9 Mar 2020 13:58:38 +0200 Tzafrir Cohen wrote: >> Hi, >> >> > Also: please consider this change for inclusion in a stable update, if >> > possible. >> >> I see that this was merged into git. Thanks. What are the chances of >> this fix getting included into Debian 10.4 to allow OVS off-loading there? > > I think it's reasonable, but will need to consult with the release > team. In case this should only happen after the change has gone into > unstable and testing. Wanted to update my findings on Buster with this patch. We use Mellanox Connect-X5 series nic (dual port) and have a bonded setup. Both ports are bonded with 802.3ad and the bond device is put on a bridge (br0) and br0 gets the IP address. In this setup with CONFIG_NET_SWITCHDEV enabled bond0 is not placed on br0 and I see a message: ifup: can't add bond0 to bridge br0: No data available This happens with Mellanox inbox driver in Kernel but if I install latest OFED there is no issue. So I'm not sure how other NIC's behave with this option enabled. Cheers,
Bug#955532: Deprecation warning in Ruby 2.7: URI.escape is obsolete
Package: puppet Version: 5.5.19-1 Severity: wishlist Hi, Running a fresh sid install with ruby 2.7, I get a few deprecation warnings, but mostly this one: /usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is obsolete Puppet still works, but that line is repeated at least 100 times and it's pretty annoying. It makes understanding anything that is happening very hard, as everything just gets buried... I had a look at the puppet 6.4 code [1] and this hasn't been fixed. There is a ticket upstream though: https://tickets.puppetlabs.com/browse/PUP-10391 It would be great if there was a way to silence those warnings? I don't think it's worth patching it properly in Debian (as it seems to involve quite a bit of work). Cheers, [1] https://github.com/puppetlabs/puppet/blob/605187329a42e200d011cbccfd9e79eb4de02145/lib/puppet/util.rb#L463 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#955290: maven-archiver version 3.5.0 is out
On Sun, Mar 29, 2020 at 02:49:13PM +0200, Mathieu Malaterre wrote: > Source: maven-archiver > Version: 3.2.0-2 > > It would be super nice to have maven-archiver 3.5.0 in archive. Please > package it. Hi Mathieu, I'm working on updating the build-dependencies. maven-archiver needs a newer plexus-archiver, which in turn needs a newer plexus-io (which I have just uploaded). And there might be a few more... Cheers, tony
Bug#955531: llvm-10-toolchain: mesa/intel-opencl-clang fails to build with llvm-10: undefined reference to `getPollyPluginInfo()'
Package: llvm-10-toolchain Severity: important Hi, The final release did not help getting mesa built, and now that I tried to migrate the Intel OpenCL stack I bumped into the same bug: /usr/bin/ld: /usr/lib/llvm-10/lib/libclangCodeGen.a(BackendUtil.cpp.o): in function `(anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr >)': (.text._ZN12_GLOBAL__N_118EmitAssemblyHelper30EmitAssemblyWithNewPassManagerEN5clang13BackendActionESt10unique_ptrIN4llvm17raw_pwrite_streamESt14default_deleteIS5_EE+0x1f15): undefined reference to `getPollyPluginInfo()' collect2: error: ld returned 1 exit status
Bug#937671: python-crypto: diff for NMU version 2.6.1-13.1
Control: tags 937671 + patch
Dear maintainer,
I've prepared an NMU for python-crypto (versioned as 2.6.1-13.1). The diff
is attached to this message.
Regards.
diff -Nru python-crypto-2.6.1/debian/changelog python-crypto-2.6.1/debian/changelog
--- python-crypto-2.6.1/debian/changelog 2019-11-16 04:46:30.0 -0500
+++ python-crypto-2.6.1/debian/changelog 2020-04-01 23:40:18.0 -0400
@@ -1,3 +1,10 @@
+python-crypto (2.6.1-13.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #937671
+
+ -- Sandro Tosi Wed, 01 Apr 2020 23:40:18 -0400
+
python-crypto (2.6.1-13) unstable; urgency=medium
[ Sebastian Ramacher ]
diff -Nru python-crypto-2.6.1/debian/control python-crypto-2.6.1/debian/control
--- python-crypto-2.6.1/debian/control 2019-10-22 15:21:34.0 -0400
+++ python-crypto-2.6.1/debian/control 2020-04-01 23:36:36.0 -0400
@@ -6,8 +6,6 @@
debhelper-compat (= 12),
dh-python,
libgmp-dev,
- python-all-dbg,
- python-all-dev,
python3-all-dbg,
python3-all-dev (>= 3.3.2-5~)
Standards-Version: 4.4.1
@@ -16,42 +14,6 @@
Homepage: http://www.pycrypto.org/
Rules-Requires-Root: no
-Package: python-crypto
-Architecture: any
-Depends:
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends}
-Provides:
- ${python:Provides}
-Description: cryptographic algorithms and protocols for Python
- A collection of cryptographic algorithms and protocols, implemented
- for use from Python. Among the contents of the package:
- .
- * Hash functions: HMAC, MD2, MD4, MD5, RIPEMD160, SHA, SHA256.
- * Block encryption algorithms: AES, ARC2, Blowfish, CAST, DES, Triple-DES.
- * Stream encryption algorithms: ARC4, simple XOR.
- * Public-key algorithms: RSA, DSA, ElGamal.
- * Protocols: All-or-nothing transforms, chaffing/winnowing.
- * Miscellaneous: RFC1751 module for converting 128-bit keys
-into a set of English words, primality testing, random number generation.
-
-Package: python-crypto-dbg
-Section: debug
-Architecture: any
-Depends:
- python-crypto (= ${binary:Version}),
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends}
-Provides:
- ${python:Provides}
-Description: cryptographic algorithms and protocols for Python (debug extension)
- A collection of cryptographic algorithms and protocols, implemented
- for use from Python.
- .
- This package contains the extensions built for the Python debug interpreter.
-
Package: python3-crypto
Architecture: any
Depends:
diff -Nru python-crypto-2.6.1/debian/python-crypto-dbg.install python-crypto-2.6.1/debian/python-crypto-dbg.install
--- python-crypto-2.6.1/debian/python-crypto-dbg.install 2017-11-07 15:10:21.0 -0500
+++ python-crypto-2.6.1/debian/python-crypto-dbg.install 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2.*/*-packages/Crypto/*/*_d.so
diff -Nru python-crypto-2.6.1/debian/python-crypto-dbg.preinst python-crypto-2.6.1/debian/python-crypto-dbg.preinst
--- python-crypto-2.6.1/debian/python-crypto-dbg.preinst 2015-12-06 08:31:53.0 -0500
+++ python-crypto-2.6.1/debian/python-crypto-dbg.preinst 1969-12-31 19:00:00.0 -0500
@@ -1,10 +0,0 @@
-#!/bin/sh
-set -e
-
-# handle symlink to directory conversion (#700778)
-DOCDIR=/usr/share/doc/python-crypto-dbg
-if [ -L $DOCDIR ] ; then
- rm $DOCDIR
-fi
-
-#DEBHELPER#
diff -Nru python-crypto-2.6.1/debian/python-crypto.docs python-crypto-2.6.1/debian/python-crypto.docs
--- python-crypto-2.6.1/debian/python-crypto.docs 2017-11-07 15:10:21.0 -0500
+++ python-crypto-2.6.1/debian/python-crypto.docs 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README
diff -Nru python-crypto-2.6.1/debian/python-crypto.install python-crypto-2.6.1/debian/python-crypto.install
--- python-crypto-2.6.1/debian/python-crypto.install 2017-11-07 15:10:21.0 -0500
+++ python-crypto-2.6.1/debian/python-crypto.install 1969-12-31 19:00:00.0 -0500
@@ -1,6 +0,0 @@
-usr/lib/python2*/*-packages/*.egg-info
-usr/lib/python2*/*-packages/Crypto/*.py
-usr/lib/python2*/*-packages/Crypto/*/*.py
-usr/lib/python2*/*-packages/Crypto/*/*/*.py
-usr/lib/python2*/*-packages/Crypto/*/*[!_][!d].so
-usr/lib/python2*/*-packages/Crypto/SelfTest/*
diff -Nru python-crypto-2.6.1/debian/python-crypto.pydist python-crypto-2.6.1/debian/python-crypto.pydist
--- python-crypto-2.6.1/debian/python-crypto.pydist 2015-12-06 08:31:53.0 -0500
+++ python-crypto-2.6.1/debian/python-crypto.pydist 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-pycrypto python-crypto; PEP386
diff -Nru python-crypto-2.6.1/debian/rules python-crypto-2.6.1/debian/rules
--- python-crypto-2.6.1/debian/rules 2019-10-20 08:55:57.0 -0400
+++ python-crypto-2.6.1/debian/rules 2020-04-01 23:36:46.0 -0400
@@ -6,7 +6,7 @@
endif
%:
- dh $@ --with=python2,python3 --buildsystem=pybuild
+ dh $@ --with=python3 --buildsystem=pybuild
override_dh_clean:
# Keep LEGAL/copy/LICENSE.orig
diff -Nru python-crypto-2.6.1/debian/tests/control python-crypto
Bug#955530: tomcat9: ipa-server-install fails due to servlet crash
Source: tomcat9 Severity: important Hi, ipa-server-install (from freeipa-server) started failing within the last few weeks, I don't know exactly when but it's a regression in sid, Ubuntu focal is still fine. Redhat folks said this would've been due to openjdk-8-jre being built with gcc10, but the latest version isn't anymore, and I've tried older versions from snapsho.d.o and they didn't help. I've also tried downgrading dogtag-pki but that didn't help either. 2020-04-01 14:35:35 [main] SEVERE: Unable to start CMS engine: null java.lang.NullPointerException at com.netscape.ca.CRLIssuingPoint.initConfig(CRLIssuingPoint.java:764) at com.netscape.ca.CRLIssuingPoint.init(CRLIssuingPoint.java:497) at com.netscape.ca.CertificateAuthority.initCRL(CertificateAuthority.java:2304) at com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:633) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:824) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:799) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:791) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:468) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:113) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1134) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1089) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:983) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4871) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5180) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:631) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1831) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:526) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:425) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.i
Bug#955529: RM: python-backports-abc -- ROM; python2-only; backport of a python3 module; no rdeps
Package: ftp.debian.org Severity: normal
Bug#955528: buildd.debian.org: add read-only mirror of buildd.d.o git repositories on salsa.d.o
Package: buildd.debian.org Severity: wishlist It would be nice to have a read-only mirror of the buildd.d.o git repositories on salsa.d.o so that folks can directly link to individual files within those repos or browse the repos without using git. https://buildd.debian.org/git/ DSA is another team that has a read-only mirror of their repos on salsa: https://salsa.debian.org/dsa-team/mirror/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#936731: incremental: diff for NMU version 16.10.1-3.2
Control: tags 936731 + patch
Dear maintainer,
I've prepared an NMU for incremental (versioned as 16.10.1-3.2). The diff
is attached to this message.
Regards.
diff -Nru incremental-16.10.1/debian/changelog incremental-16.10.1/debian/changelog
--- incremental-16.10.1/debian/changelog 2019-12-27 07:48:06.0 -0500
+++ incremental-16.10.1/debian/changelog 2020-04-01 20:51:18.0 -0400
@@ -1,3 +1,10 @@
+incremental (16.10.1-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #936731
+
+ -- Sandro Tosi Wed, 01 Apr 2020 20:51:18 -0400
+
incremental (16.10.1-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru incremental-16.10.1/debian/control incremental-16.10.1/debian/control
--- incremental-16.10.1/debian/control 2019-12-27 07:48:06.0 -0500
+++ incremental-16.10.1/debian/control 2020-04-01 20:50:43.0 -0400
@@ -4,9 +4,6 @@
Priority: optional
Build-Depends: debhelper (>= 9),
dh-python,
- python-all (>= 2.6.6-3),
- python-setuptools (>= 0.6b3),
- python-twisted-core,
python3-all,
python3-setuptools (>= 0.6b3),
python3-twisted,
@@ -16,20 +13,6 @@
Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/incremental.git
Vcs-Git: git://anonscm.debian.org/python-modules/packages/incremental.git
-Package: python-incremental
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Recommends: python-twisted-core
-Provides: ${python:Provides}
-Description: Library for versioning Python projects.
- Incremental is a small library that versions your Python projects.
- .
- This package provides the Python 2.x module.
- .
- The incremental.update functionality requires the click module which is
- no longer available for python 2 in Debian. If you require this functionality
- we suggest using python 3.
-
Package: python3-incremental
Architecture: all
Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru incremental-16.10.1/debian/rules incremental-16.10.1/debian/rules
--- incremental-16.10.1/debian/rules 2019-12-27 07:48:06.0 -0500
+++ incremental-16.10.1/debian/rules 2020-04-01 20:51:03.0 -0400
@@ -2,10 +2,6 @@
export PYBUILD_NAME=incremental
-# Don't test python 2 because python-click is not available anymore.
-export PYBUILD_DISABLE_python2=test
-export PYBUILD_DISABLE_python2-dbg=test
-
# XXX Unit tests seem to leave cruft around, for some reason
export PYBUILD_AFTER_TEST=rm -rf {build_dir}/incremental.tests.*
@@ -15,4 +11,4 @@
export LANG=C.UTF-8
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
diff -Nru incremental-16.10.1/debian/tests/unit-tests-2 incremental-16.10.1/debian/tests/unit-tests-2
--- incremental-16.10.1/debian/tests/unit-tests-2 2016-11-03 13:40:25.0 -0400
+++ incremental-16.10.1/debian/tests/unit-tests-2 1969-12-31 19:00:00.0 -0500
@@ -1,4 +0,0 @@
-#!/bin/sh -e
-
-cd $AUTOPKGTEST_TMP
-trial incremental
Bug#955527: kernelshark: Crash (SIGSEGV) when pressing the "+" button
Package: kernelshark Version: 2.8.3-5 Severity: grave X-Debbugs-CC: sudipm.mukher...@gmail.com Dear Debian kernelshark (trace-cmd) maintainer, When I perform the following actions in kernelshark in Debian Sid, kernel shark will crash: 1. Open kernelshark 2. Click the "+" button Partial traceback is as follows: === Thread 1 "kernelshark" received signal SIGSEGV, Segmentation fault. 0x76d77918 in ksmodel_zoom (histo=0x7fffde60, r=, mark=, zoom_in=) at ./kernel- shark/src/libkshark-model.c:693 693 ./kernel-shark/src/libkshark-model.c: No such file or directionary. (gdb) bt full #0 0x76d77918 in ksmodel_zoom (histo=0x7fffde60, r=, mark=, zoom_in=) at ./kernel- shark/src/libkshark-model.c:693 range = min = max = delta_min = delta_tot = #1 0x76d77d0a in ksmodel_zoom_in (histo=, r=, mark=) at ./kernel-shark/src/libkshark-model.c:722 No locals. #2 0x77f591ba in KsGraphModel::zoomIn (this=0x7fffde50, r=0.01, mark=-1) at ./kernel-shark/src/KsModels.cpp:473 No locals. #3 0x77f6bb41 in KsTraceGraph::_updateGraphs (this=0x7fffd930, action=KsTraceGraph::GraphActions::ZoomIn) at ./kernel- shark/src/KsGLWidget.hpp:72 k = 0.01 bin = #4 0x775bc4e8 in QMetaObject::activate(QObject*, int, int, void**) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 No symbol table info available. #5 0x77aa358d in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 No symbol table info available. #6 0x77aa3c6d in QAbstractButton::mousePressEvent(QMouseEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 No symbol table info available. Let me know if more information is needed to debug this issue. Thanks! -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#955526: live-task-standard: add usbutils
Package: live-task-standard
Version: 11.0.1
Severity: wishlist
Dear Maintainer,
With pciutils already included in live-tasks-standard it would be great
to also include usbutils. This is usefull to check which hardware is in
a computer.
I attached a patch. You can find this also on
https://salsa.debian.org/txt.file-guest/live-tasks/-/tree/patch-1
kind regards
Vieno
>From 6b0408b91b1477f4e3748bd7a675049c97d81e2f Mon Sep 17 00:00:00 2001
From: Vieno Hakkerinen
Date: Thu, 2 Apr 2020 02:00:36 +0200
Subject: [PATCH] Add usbutils to live-task-standard
As pciutils is already included usbutils should also be included. This
makes it easier to figure out the build-in hardware in a computer.
---
debian/control | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/control b/debian/control
index 3a8bef2..6e3bc45 100644
--- a/debian/control
+++ b/debian/control
@@ -408,6 +408,7 @@ Depends: ${misc:Depends},
telnet,
traceroute,
ucf,
+ usbutils,
wamerican,
wget,
xz-utils,
--
2.11.0
Bug#938637: Status of telepathy-gabble and telepathy-salut IRT py2removal
> I've just requested access to the telepathy team in salsa, so that i > can push my changes there. for now, attached the patch for the just uploaded package diff --git a/debian/changelog b/debian/changelog index 1550f7159..e398df2c1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +telepathy-gabble (0.18.4-2) unstable; urgency=medium + + * Remove gobject, openssl, twisted from b-d, part of py2removal effort + + -- Sandro Tosi Wed, 01 Apr 2020 20:03:42 -0400 + telepathy-gabble (0.18.4-1) unstable; urgency=medium * debian/watch: Verify the gpg signature of the upstream tarball diff --git a/debian/control b/debian/control index 8a632adb7..d7efe5efb 100644 --- a/debian/control +++ b/debian/control @@ -17,9 +17,6 @@ Build-Depends: debhelper (>= 10), libsoup2.4-dev (>= 2.42), libtelepathy-glib-dev (>= 0.19.7), python, - python-gobject, - python-openssl, - python-twisted, xsltproc, libsqlite3-dev, libnice-dev (>= 0.0.11)
Bug#950684: Debian Bug #950684
Hi, Quoting Gilles Filippini (2020-03-21 15:28:32) > On Wed, 26 Feb 2020 19:59:20 +0100 Johannes Schauer wrote: > > On Sat, 22 Feb 2020 17:45:36 +0100 Johannes Schauer > > wrote: > > > Quoting Jörg Frings-Fürst (2020-02-22 17:36:10) > > > > Am Samstag, den 22.02.2020, 17:17 +0100 schrieb Johannes Schauer: > > > > > Control: severity -1 important > > > > > > > > > > Quoting Johannes Schauer (2020-02-22 17:05:47) > > > > > > Quoting Jörg Frings-Fürst (2020-02-22 16:48:52) > > > > > > > > please show me evidence of that. > > > > > > > > > > > > > > > > Setting a bug severity to serious means that sbuild will be > > > > > > > > removed from > > > > > > > > testing in March. You should have evidence before such a > > > > > > > > drastic measure is > > > > > > > > taken. > > > > > > > All packages that directly or indirectly have systemd as build > > > > > > > depend can no > > > > > > > longer be compiled. I think that is reason enough. > > > > > > > > > > > > Indeed I now see the problem myself. > > I've just been bitten by this while building stimfit into a fresh > unstable sbuild chroot. > > Setting once and for all the correct permissions using sbuild-shell > fixed the problem for this chroot: > $ echo "/bin/chown root:root / && /bin/chmod a+rX /" | \ > sudo sbuild-shell I may have a theory... All you who have this error (Jörg + Gilles), did you use a command line with sbuild-createchroot that has "$(mktemp -d)" in it? Depending on what your $TMPDIR is, the problem might be that the create directory has permissions 700. This means that the root directory of the tarball that is created will only be readable by root which kills it for most applications. Debootstrap doesn't care but mmdebstrap explicitly does a "chmod 0755" on the root directory which is why you might not see the problem with mmdebstrap but only with debootstrap. So could you please confirm the following: - try doing "tar -tvf /srv/... | head" on the chroot tarball and have a look at the permissions of ./ -- what are they? - the problem only occurs when you use "$(mktemp -d)" when running sbuild-creatchroot and it goes away if you use any other directory outside $TMPDIR as temporary directory like for example ~/tmp. So for example create your chroot like this: $ sudo sbuild-createchroot --make-sbuild-tarball=/srv/... unstable ~/tmp - if the answer to above question is "yes": when you use "$(mktemp -d)" then the directory that is created has permissions 700, right? This is just a hunch. I still am unable to reproduce the problem you guys are having so, please support me in finding the cause of this issue. Thanks! cheers, josch signature.asc Description: signature
Bug#954831: RM: gcc-8, superseded by gcc-9
Hi doko, On Tue, 24 Mar 2020 08:33:55 +0100 Matthias Klose wrote: > Please remove gcc-8, gcc-8-cross and gcc-8-cross-ports. superseded by gcc-9 unfortunately I have to veto the removal of gcc-8 since we still need it for nvidia-cuda-toolkit. There is no strict dependency on gcc-8 since it is ored with clang-X (with X <= 7), but the package sitting in NEW will change that. The uninstallability of gcc-8 has shown that this ored dependency is not really helpful for packages in contrib Build-depending on nvidia-cuda-toolkit since clang is not a drop-in replacement. (I noticed eztrace-contrib to FTBFS, I expect all other reverse build-depends of nvidia-cuda-toolkit to do the same.) The situation does not seem to resolve with the cuda tookit 10.2 (not yet packaged), since (third-party) documentation suggests that still only gcc <= 8 is supported: https://gist.github.com/ax3l/9489132 If it needs be, I'll have to step in and adopt a stripped down src:gcc-8 (only gcc and g++ frontends, only amd64 and ppc64el) after all non-cuda rdepends are gone to keep it around until a newer CUDA release supports current compilers. Andreas PS: I don't mind if gcc-8-doc goes away
Bug#938645: Status of telepathy-gabble and telepathy-salut IRT py2removal
> I've just requested access to the telepathy team in salsa, so that i
> can push my changes there.
for now, here's the diff for the just uploaded package
diff --git a/debian/changelog b/debian/changelog
index 80a92e6..df7282e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-telepathy-salut (0.8.1-6) UNRELEASED; urgency=medium
+telepathy-salut (0.8.1-6) unstable; urgency=medium
[ Jonny Lamb ]
* Remove myself from Uploaders.
@@ -18,7 +18,10 @@ telepathy-salut (0.8.1-6) UNRELEASED; urgency=medium
* Drop -dbg package and rely on the -dbgsym one
* debian/rules: Enable all hardening options
- -- Laurent Bigonville Sun, 10 Nov 2019 14:04:56 +0100
+ [ Sandro Tosi ]
+ * Drop twisted, avahi from b-d, part of py2removal effort
+
+ -- Sandro Tosi Wed, 01 Apr 2020 19:49:05 -0400
telepathy-salut (0.8.1-5) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 4758307..c884f5e 100644
--- a/debian/control
+++ b/debian/control
@@ -16,9 +16,7 @@ Build-Depends: debhelper (>= 12),
libsqlite3-dev,
libtelepathy-glib-dev (>= 0.17.1),
libxml2-dev,
- python (>= 2.5),
- python-avahi,
- python-twisted (>= 15.4),
+ python,
uuid-dev,
xsltproc
Homepage: https://telepathy.freedesktop.org/wiki/
diff --git a/debian/rules b/debian/rules
index 8b074e2..d988810 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,6 +23,7 @@ override_dh_auto_configure:
--libexecdir="\$${prefix}/lib/telepathy" \
--enable-olpc \
--disable-static \
+ --disable-avahi-tests \
$(NULL)
# the regression tests are too race-prone to run on Debian buildds
Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1
On Thu, 26 Mar 2020 21:02:59 +0100 Matthias Klose wrote:
> yes, but we cannot rebuild the package, because it build-depends on gnat-8.
> Filed a removal bug for gcc-8 instead.
An easy fix would probably be to temporarily add a versioned
Provides: libgcc-s1 (= 1:${binary:Version})
to libgcc-s1 in src:gcc-10 which should make libgcc-8-dev installable
again, s.t. gcc-8 can be rebuilt fixed.
Andreas
Bug#955525: Multiple Syntax warnings while upgrading python3-astroquery
Package: python3-astroquery Version: 0.4+dfsg-2 Severity: normal Dear Maintainer, Came across several syntaxwarnings, please fix them so it works well with python3. Setting up python3-astroquery (0.4+dfsg-2) ... /usr/lib/python3/dist-packages/astroquery/jplhorizons/core.py:1087: SyntaxWarning: "is" with a literal. Did you mean "=="? if (self.query_type is 'ephemerides' and /usr/lib/python3/dist-packages/astroquery/jplhorizons/core.py:1094: SyntaxWarning: "is" with a literal. Did you mean "=="? elif (self.query_type is 'elements' and /usr/lib/python3/dist-packages/astroquery/jplhorizons/core.py:1099: SyntaxWarning: "is" with a literal. Did you mean "=="? elif (self.query_type is 'vectors' and /usr/lib/python3/dist-packages/astroquery/jplhorizons/core.py:1231: SyntaxWarning: "is" with a literal. Did you mean "=="? if self.query_type is 'ephemerides' and 'a-mass' in data.colnames: /usr/lib/python3/dist-packages/astroquery/jplhorizons/core.py:1235: SyntaxWarning: "is" with a literal. Did you mean "=="? if self.query_type is 'ephemerides': /usr/lib/python3/dist-packages/astroquery/jplhorizons/core.py:1237: SyntaxWarning: "is" with a literal. Did you mean "=="? elif self.query_type is 'elements': /usr/lib/python3/dist-packages/astroquery/jplhorizons/core.py:1239: SyntaxWarning: "is" with a literal. Did you mean "=="? elif self.query_type is 'vectors': /usr/lib/python3/dist-packages/astroquery/jplhorizons/tests/test_jplhorizons.py:201: SyntaxWarning: 'tuple' object is not callable; perhaps you missed a comma? Hopefully this can be fixed or perhaps already fixed upstream. -- 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.4.0-4-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-astroquery depends on: ii python3 3.8.2-2 ii python3-astropy 4.0-4 ii python3-bs4 4.8.2-1 ii python3-html5lib 1.0.1-2 ii python3-keyring 18.0.1-2 ii python3-requests 2.22.0-2 ii python3-six 1.14.0-2 ii python3-tk3.8.2-2 python3-astroquery recommends no packages. Versions of packages python3-astroquery suggests: pn python-astroquery-doc -- no debconf information -- 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#955501: yaz: please make the build reproducible
Hi Adam, > We are using yaz-config for side-by-side builds which means we can't > apply that patch as is. What do you mean by side-by-side build? I have not come across this term before. (Do you mean you are Build-Depending on yaz from another package?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#955524: nvidia-cuda-toolkit: needs gcc-8
Package: nvidia-cuda-toolkit Version: 10.1.168-7 Severity: important Control: block 954831 with -1 We need to prevent removal of gcc-8 since it is needed for building packages with cuda support. I recently noticed a FTBFS of eztrace-contrib in sid. nvidia-cuda-toolkit does not expose a hard dependency on gcc-8 since we have that or-ed dependency list of all supported ancient gcc and clang versions. This will change with the nvidia-cuda-toolkit-gcc package currently sitting in NEW. That should make it easier to have a contrib package building with nvidia-cuda-toolkit and a non-default gcc. Unfortunately the situation does not seen to improve with 10.2 which still only supports gcc <= 8 according to https://gist.github.com/ax3l/9489132 Andreas
Bug#954460: remove mentions of "volatile" repo from sources.list
Hello Cyril, > Would the following look like some reasonable middle ground? > > 1. Link to the wiki for the time being, getting rid of volatile, and > pointing users without any IP restrictions to some documentation. > 2. Get the ball rolling to update the devref. > 3. Switch the link from the wiki to the devref once the latter is > updated. Yes, this seems like a good way to go, I will be able to work on this during the weekend, to update the patch and submit the devref MR, if you'd like to do it yourself before that, feel free to go ahead. Thanks, -- Samuel Henrique
Bug#938278: python-xmltodict: Python2 removal in sid/bullseye
On Fri, 30 Aug 2019 07:48:50 + Matthias Klose wrote: > Package: src:python-xmltodict > Version: 0.11.0-2 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal Consider maintain this package under the Debian python modules team umbrella
Bug#937638: python-certifi: Python2 removal in sid/bullseye
On Fri, 30 Aug 2019 07:37:18 + Matthias Klose wrote: > Package: src:python-certifi > Version: 2018.8.24-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal Consider maintain this package under the Debian python modules team umbrella
Bug#955522: RM: python-backports-shutil-get-terminal-size -- RoQA; python2-only; backport of a python3 module; no rdeps
Package: ftp.debian.org Severity: normal
Bug#955523: polari: Join button is grayed out. No rooms shown.
Package: polari Version: 3.36.1-1 Severity: important Dear Maintainer, After upgrade to polari 3.36 I cannot join any room. Also all old subscribtion to rooms are gone. Starting polari from the command line gives the next error after selecting a server from the server list. (polari:6460): Gjs-WARNING **: 23:39:49.532: JS ERROR: TelepathyGLib.Error: _onRowActivated/<@resource:///org/gnome/Polari/js/connections.js:216:27 main@resource:///org/gnome/Polari/js/main.js:63:12 run@resource:///org/gnome/gjs/modules/package.js:222:12 start@resource:///org/gnome/gjs/modules/package.js:206:5 @:1:1 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (800, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/12 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:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages polari depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-3 ii gir1.2-glib-2.0 1.62.0-5+b1 ii gir1.2-gspell-1 1.8.3-1 ii gir1.2-gtk-3.0 3.24.14-1 ii gir1.2-pango-1.0 1.42.4-8 ii gir1.2-secret-1 0.20.2-1 ii gir1.2-soup-2.4 2.70.0-1 ii gir1.2-telepathyglib-0.120.24.1-2+b1 ii gir1.2-telepathylogger-0.2 0.8.2-4 ii gjs 1.58.1-2 ii libc62.30-2 ii libgirepository-1.0-11.62.0-5+b1 ii libgjs0g 1.58.1-2 ii libglib2.0-0 2.64.1-1 ii libglib2.0-bin 2.64.1-1 ii libgtk-3-0 3.24.14-1 ii libtelepathy-glib0 0.24.1-2+b1 ii telepathy-idle 0.2.0-2+b1 ii telepathy-logger 0.8.2-4 ii telepathy-mission-control-5 1:5.16.5-1 polari recommends no packages. polari suggests no packages. -- no debconf information
Bug#945710: neopi: Python2 removal in sid/bullseye
> On 4/1/20 5:31 PM, Sandro Tosi wrote: > >> I'm no longer interested in this package. I guess Miguel Angel Martin > >> Serrano is > >> also not interested. > >> > >> Feel free to adopt it, otherwise I will probably drop it from Debian at > >> some point. > > > > I'm not interested in the package either, if you dont mind, i'd like > > to file a removal bugs in the next few days - this will help with the > > py2removal effort. > > > > That would be appreciated. filed as #955518 -- thanks! Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#955519: sass-spec: patch to make it cross-installable
Source: sass-spec
Version: 3.5.4-2
Tags: patch
Severity: important
Hello, please apply the following patch from Steve Langasek to make it
cross-installable with Multiarch and mark as multi-arch foreign!
--- sass-spec-3.5.4/debian/changelog2019-07-08 04:17:36.0 +0200
+++ sass-spec-3.5.4/debian/changelog2020-04-01 13:58:53.0 +0200
@@ -1,3 +1,11 @@
+sass-spec (3.5.4-2.1) unstable; urgency=medium
+
+ [ Steve Langesek ]
+ * Use ruby:any to make it cross-installable (Closes: #-1)
+ * Mark it as multi-arch foreign
+
+ -- Gianfranco Costamagna Wed, 01 Apr 2020
13:58:53 +0200
+
sass-spec (3.5.4-2) unstable; urgency=medium
* Fix Vcs-* URLs.
diff -Nru sass-spec-3.5.4/debian/control sass-spec-3.5.4/debian/control
--- sass-spec-3.5.4/debian/control 2019-07-08 04:17:36.0 +0200
+++ sass-spec-3.5.4/debian/control 2020-04-01 13:58:53.0 +0200
@@ -19,9 +19,10 @@
Package: sass-spec
Section: devel
Architecture: all
+Multi-Arch: foreign
XB-Ruby-Versions: ${ruby:Versions}
Depends:
- ruby | ruby-interpreter,
+ ruby:any | ruby-interpreter,
ruby-sass | sass,
${misc:Depends},
Recommends:
@@ -41,6 +42,7 @@
Package: sass-spec-data
Section: devel
Architecture: all
+Multi-Arch: foreign
Depends:
${misc:Depends},
Enhances:
thanks
Gianfranco
Bug#955520: ruby-sass: patch to make it cross-installable
Source: ruby-sass
Version: 3.7.4-1
Tags: patch
Severity: important
Hello, please apply the following patch from Steve Langasek to make it
installable on i386 when multiarch is enabled.
--- ruby-sass-3.7.4/debian/changelog2019-07-08 05:29:27.0 +0200
+++ ruby-sass-3.7.4/debian/changelog2020-04-01 16:52:06.0 +0200
@@ -1,3 +1,10 @@
+ruby-sass (3.7.4-1.1) unstable; urgency=medium
+
+ [ Steve Langasek ]
+ * Depend on ruby:any to make it cross-installable (Closes: #-1)
+
+ -- Gianfranco Costamagna Wed, 01 Apr 2020
16:52:06 +0200
+
ruby-sass (3.7.4-1) unstable; urgency=medium
[ upstream ]
diff -Nru ruby-sass-3.7.4/debian/control ruby-sass-3.7.4/debian/control
--- ruby-sass-3.7.4/debian/control 2019-07-08 05:23:05.0 +0200
+++ ruby-sass-3.7.4/debian/control 2020-04-01 16:52:04.0 +0200
@@ -18,7 +18,7 @@
Architecture: all
XB-Ruby-Versions: ${ruby:Versions}
Depends:
- ruby | ruby-interpreter,
+ ruby:any | ruby-interpreter,
${misc:Depends},
# FIXME: recommend when in Debian
Suggests:
Bug#955521: libsass: patch for using autopkgtests in cross-environments
Source: libsass Version: 3.6.3-1 Tags: patch Severity: important Hello, please apply the following patch from Steve Langasek to make it work with ruby on i386 when cross-tested diff -Nru libsass-3.6.3/debian/changelog libsass-3.6.3/debian/changelog --- libsass-3.6.3/debian/changelog 2020-02-28 12:04:53.0 +0100 +++ libsass-3.6.3/debian/changelog 2020-04-01 13:55:07.0 +0200 @@ -1,3 +1,10 @@ +libsass (3.6.3-1.1) unstable; urgency=medium + + [ Steve Langasek ] + * Use ruby:native to fix autopkgtests on cross-environments (Closes: #-1) + + -- Gianfranco Costamagna Wed, 01 Apr 2020 13:55:07 +0200 + libsass (3.6.3-1) unstable; urgency=medium [ upstream ] diff -Nru libsass-3.6.3/debian/tests/control libsass-3.6.3/debian/tests/control --- libsass-3.6.3/debian/tests/control 2018-11-19 12:00:46.0 +0100 +++ libsass-3.6.3/debian/tests/control 2020-04-01 13:55:05.0 +0200 @@ -1,2 +1,2 @@ Tests: spec -Depends: ruby, sassc, sass-spec, sass-spec-data +Depends: ruby:native, sassc, sass-spec, sass-spec-data thanks Gianfranco
Bug#955518: RM: neopi -- RoQA; python2-only; current maintainers no longer interested; leaf pkg; low popcon
Package: ftp.debian.org Severity: normal
Bug#955517: RM: python-dingus -- RoQA; Depends on Python 2, dead upstream, unmaintained, no reverse deps
Package: ftp.debian.org Severity: normal Please remove python-dingus. It depends on Python 2, there are no reverse deps, the last upstream release was in 2012 and so was the last upload. Cheers, Moritz
Bug#938637: Status of telepathy-gabble and telepathy-salut IRT py2removal
Hello, telepathy-gabble and telepathy-salut are the last 2 reverse dependencies for python-twisted in Debian unstable, and i'd very much like to remove that package soon. It looks like twisted is only used for tests in both those packages and it looks like they are not being run in d/rules anyway. I'll try update the package to remove the dependency on python-twisted (and all other python2 modules i can). I've just requested access to the telepathy team in salsa, so that i can push my changes there. Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#955516: RM: ndpmon -- RoQA; Depends on Python 2, dead upstream, unmaintained, license issue
Package: ftp.debian.org Severity: normal Please remove ndpmon. It depends on Python 2, is dead upstream (last release from 2012), hasn't seen a maintainer upload since 2012 and there's also an open license issue (951861) Cheers, Moritz
Bug#885506: bumping severity of pygtk bugs
On Mon, Oct 07, 2019 at 04:53:03PM +0200, Thibaut Paumard wrote: > Dear Jeremy, > > Thanks, I have warned upstream that YAO will be removed if not updated > to Python 3 and Gtk 3. It's now the last package blocking the removal of pygtk, let's remove it. Cheers, Moritz
Bug#955515: RM: pwrkap -- RoQA; Dead upstream, unmaintained, depends on pygtk/Py2
Package: ftp.debian.org Severity: normal Please remove pwrkap. It depends on Python and pygtk, is dead upstream and the last maintainer upload was in 2010. Cheers, Moritz
Bug#955514: RM: nicotine -- RoQA; Depends on pygtk2, unmaintained
Package: ftp.debian.org Severity: normal Please remove nicotine. It's one of the two last remaining blockers of the pygtk removal and hasn't seen a maintainer upload since 2011. It can be reintroduced when ported to gi/gtk3. Cheers, Moritz
Bug#930137: ITA: nicotine -- graphical client for the SoulSeek peer-to-peer system
On Sat, Mar 21, 2020 at 09:53:10PM +0100, Moritz Mühlenhoff wrote: > On Thu, Jun 20, 2019 at 07:30:12PM -0600, Josue Ortega wrote: > > rename 930137 ITA: nicotine -- graphical client for the SoulSeek > > peer-to-peer > > Hi Josue, > what's the status here? Are you still interested in adopting it and working on > it? Otherwise I'll file an RM bug soon, as nicotine isn't ported to Python 3 > and one of the last dependencies on pygtk2 (which is also going away like Py2) I did that now. nicotine can still be introduced when ported to gtk3/Py3. Cheers, Moritz
Bug#890168: python-gasp: Please switch to python-gobject-2/python-gi
On Tue, Mar 24, 2020 at 10:13:33PM +0100, Moritz Mühlenhoff wrote: > On Sun, Oct 06, 2019 at 06:00:02PM -0400, Jeremy Bicha wrote: > > Control: severity -1 serious > > Tags: fixed-upstream > > > > It looks to me like upstream has ported gasp to Python3 and GObject > > Introspection. > > > > https://launchpad.net/gasp-core > > Hi Luke, > are you still interested in maintaining python-gasp/updating it to > the current upstream? Otherwise I'll file a removal bug, it's among > the last handful of packages blocking the pygtk removal at this point. I've filed an RM bug now to unclock the pygtk removal. gasp can still be reintroduced before the bullseye release. Cheers, Moritz
Bug#955513: RM: python-gasp -- RoQA; Depends on pygtk/py2, unmaintained
Package: ftp.debian.org Severity: normal Please remove python-gasp. It's one of the two last remaining blockers of the pygtk removal and hasn't seen an upload since 2015. Cheers, Moritz
Bug#955512: RFS: sane-backends/1.0.29-1~experimental2 -- API library for scanners -- utilities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sane-backends" Package name: sane-backends Version : 1.0.29-1~experimental2 Upstream Author : [fill in name and email of upstream] URL : http://www.sane-project.org License : GPL-2+ with sane exception Vcs : https://jff.email/cgit/sane-backends.git Section : graphics It builds those binary packages: sane-utils - API library for scanners -- utilities libsane-common - API library for scanners -- documentation and support files libsane1 - API library for scanners libsane-dev - API development library for scanners [development files] To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sane-backends Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.29-1~experimental2.dsc or from git https://jff.email/cgit/sane-backends.git?h=release%2Fexperimental%2F1.0.29-1_experimental2 Changes since the last upload: * New debian/patches/0150-i386-test.patch: - Remove 4 tests failed tests on i386. * New patches/0155-hurd_PATH_MAX.patch: - Fix missing PATH_MAX on hurd-i386. * New patches/0160-big_endian.patch: - Fix FTBFS on big endian systems. * Remove now useless lintian overrides. CU Jörg Frings-Fürst -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#938425: 938425
On Wed, Apr 01, 2020 at 07:32:26AM +0200, JCF Ploemen wrote: > Removing pygtk won't make sabnzbdplus uninstallable; python-gtk2 is a > suggested dependency used only for an optional tray icon. Oh, indeed. Totally missed that, no problem at all with waiting for the new upstream release, then! Cheers, Moritz
Bug#955511: xbmc-pvr-addons: Should be removed from testing
Source: xbmc-pvr-addons Severity: serious Hi, The source builds only transitional packages and they are not needed anymore. After removing them from testing they can be removed from unstable as well. Cheers, Balint -- Balint Reczey Ubuntu & Debian Developer
Bug#909963: xterm-256color: Corrupts first line in hexedit window
- Original Message - | From: "Thomas Dickey" | To: 909...@bugs.debian.org | Cc: 909963-submit...@bugs.debian.org | Sent: Wednesday, April 1, 2020 4:18:52 PM ... | | But what is the actual terminfo used? terminal (not "terminfo") | | a) a terminal emulator such as KDE konsole (and version) | b) Linux console -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net
Bug#955510: buster-pu: package jsp-api/2.3.4-2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hello,
I would like to fix Debian bug #947844 in Buster which was introduced
by upgrading tomcat8 to version 8.5.50-0+deb9u1 in Stretch. When upgrading
libservlet3.1-java from Stretch to Buster, the upgrade will fail due
to an insufficient Breaks and Replaces relation in src:jsp-api. The
solution is to use << 9 for libservlet3.1-java. It will always be
correct for the remaining release cycle in Stretch because we will
never introduce tomcat9. I have tested the change and can confirm that
the upgrade works flawlessly now.
Please find attached the debdiff.
Regards,
Markus
diff -Nru jsp-api-2.3.4/debian/changelog jsp-api-2.3.4/debian/changelog
--- jsp-api-2.3.4/debian/changelog 2019-01-18 02:31:35.0 +0100
+++ jsp-api-2.3.4/debian/changelog 2020-04-01 21:06:44.0 +0200
@@ -1,3 +1,11 @@
+jsp-api (2.3.4-2+deb10u1) buster; urgency=medium
+
+ * Team upload.
+ * Change Breaks and Replaces for libservlet3.1-java to << 9 and fix dpkg
+error when upgrading tomcat 8 from Stretch to Buster.
+
+ -- Markus Koschany Wed, 01 Apr 2020 21:06:44 +0200
+
jsp-api (2.3.4-2) unstable; urgency=medium
* Install Maven artifacts mimicking the version 2.3 to preserve the backward
diff -Nru jsp-api-2.3.4/debian/control jsp-api-2.3.4/debian/control
--- jsp-api-2.3.4/debian/control2019-01-18 02:31:30.0 +0100
+++ jsp-api-2.3.4/debian/control2020-04-01 21:06:44.0 +0200
@@ -20,8 +20,8 @@
Architecture: all
Depends: ${maven:Depends}, ${misc:Depends}
Suggests: ${maven:OptionalDepends}
-Breaks: libservlet3.1-java (<< 8.5.35-3~), libservlet2.5-java
-Replaces: libservlet3.1-java (<< 8.5.35-3~), libservlet2.5-java
+Breaks: libservlet3.1-java (<< 9), libservlet2.5-java
+Replaces: libservlet3.1-java (<< 9), libservlet2.5-java
Description: JavaServer Pages API
JavaServer Pages (JSP) is a technology that helps software developers
create dynamically generated web pages based on HTML, XML, or other
Bug#955509: buster-pu: package websocket-api/1.1-1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hello,
I would like to fix Debian bug #947844 in Buster which was introduced
by upgrading tomcat8 to version 8.5.50-0+deb9u1 in Stretch. When upgrading
libservlet3.1-java from Stretch to Buster, the upgrade will fail due
to an insufficient Breaks and Replaces relation in src:websocket-api. The
solution is to use << 9 for libservlet3.1-java. It will always be
correct for the remaining release cycle in Stretch because we will
never introduce tomcat9. I have tested the change and can confirm that
the upgrade works flawlessly now.
Please find attached the debdiff.
Regards,
Markus
diff -Nru websocket-api-1.1/debian/changelog websocket-api-1.1/debian/changelog
--- websocket-api-1.1/debian/changelog 2018-12-14 10:26:56.0 +0100
+++ websocket-api-1.1/debian/changelog 2020-04-01 21:11:54.0 +0200
@@ -1,3 +1,11 @@
+websocket-api (1.1-1+deb10u1) buster; urgency=medium
+
+ * Team upload.
+ * Change Breaks and Replaces for libservlet3.1-java to << 9 and fix dpkg
+error when upgrading tomcat 8 from Stretch to Buster.
+
+ -- Markus Koschany Wed, 01 Apr 2020 21:11:54 +0200
+
websocket-api (1.1-1) unstable; urgency=medium
* Initial release (Closes: #916245)
diff -Nru websocket-api-1.1/debian/control websocket-api-1.1/debian/control
--- websocket-api-1.1/debian/control2018-12-14 10:26:56.0 +0100
+++ websocket-api-1.1/debian/control2020-04-01 21:11:54.0 +0200
@@ -17,8 +17,8 @@
Architecture: all
Depends: ${maven:Depends}, ${misc:Depends}
Suggests: ${maven:OptionalDepends}
-Breaks: libservlet3.1-java (<< 8.5.35-3~)
-Replaces: libservlet3.1-java (<< 8.5.35-3~)
+Breaks: libservlet3.1-java (<< 9)
+Replaces: libservlet3.1-java (<< 9)
Description: Java WebSocket API
Java API for WebSocket (JSR-356) defines a standard API for the development
of websocket applications, both on the server side as well as on the Java
Bug#955508: buster-pu: package el-api/3.0.0-2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hello,
I would like to fix Debian bug #947844 in Buster which was introduced
by upgrading tomcat8 to version 8.5.50-0+deb9u1 in Stretch. When upgrading
libservlet3.1-java from Stretch to Buster, the upgrade will fail due
to an insufficient Breaks and Replaces relation in src:el-api. The
solution is to use << 9 for libservlet3.1-java. It will always be
correct for the remaining release cycle in Stretch because we will
never introduce tomcat9. I have tested the change and can confirm that
the upgrade works flawlessly now.
Please find attached the debdiff.
Regards,
Markus
diff -Nru el-api-3.0.0/debian/changelog el-api-3.0.0/debian/changelog
--- el-api-3.0.0/debian/changelog 2018-12-27 23:17:57.0 +0100
+++ el-api-3.0.0/debian/changelog 2020-04-01 20:59:11.0 +0200
@@ -1,3 +1,11 @@
+el-api (3.0.0-2+deb10u1) buster; urgency=medium
+
+ * Team upload.
+ * Change Breaks and Replaces for libservlet3.1-java to << 9 and fix dpkg
+error when upgrading tomcat 8 from Stretch to Buster.
+
+ -- Markus Koschany Wed, 01 Apr 2020 20:59:11 +0200
+
el-api (3.0.0-2) unstable; urgency=medium
* Use a real pom for the 3.0 artifacts to improve the compatibility
diff -Nru el-api-3.0.0/debian/control el-api-3.0.0/debian/control
--- el-api-3.0.0/debian/control 2018-12-27 23:07:39.0 +0100
+++ el-api-3.0.0/debian/control 2020-04-01 20:59:11.0 +0200
@@ -17,8 +17,8 @@
Architecture: all
Depends: ${maven:Depends}, ${misc:Depends}
Suggests: ${maven:OptionalDepends}
-Breaks: libservlet3.1-java (<< 8.5.35-3~), libservlet2.5-java
-Replaces: libservlet3.1-java (<< 8.5.35-3~), libservlet2.5-java
+Breaks: libservlet3.1-java (<< 9), libservlet2.5-java
+Replaces: libservlet3.1-java (<< 9), libservlet2.5-java
Description: Expression Language API
EL is a simple language designed to meet the needs of the presentation
layer in Java web applications.
Bug#955495: ITP: orthanc-python -- Develop plugins for Orthanc using the Python programming language
On 4/1/20 5:38 PM, Sebastien Jodogne wrote: > Package: wnpp > Severity: wishlist > Owner: Sebastien Jodogne > > * Package name: orthanc-python > Version : 1.0 > Upstream Author : Sebastien Jodogne > * URL : https://www.orthanc-server.com/ > * License : AGPL > Programming Lang: C++, Python > Description : Develop plugins for Orthanc using the Python programming > language > > This plugin can be used to write Orthanc plugins using the Python programming > language instead of the more complex C/C++ programming languages. It can be > used to gain access to Python modules directly in Orthanc. > > This plugin can be of great help to anyone wishing to automate her imaging > workflow, to design/train new machine learning algorithms, or to deploy AI > systems directly in clinical setups. > > Full documentation is available in the Orthanc Book: > https://book.orthanc-server.com/plugins/python.html > Hi Sebastien, if this is a python module then it should follow python guidelines. The name in this case should be python3-orthanc, see LibraryStyleGuide: https://wiki.debian.org/Python/LibraryStyleGuide After building and installing orthanc-python I can't import orthanc from python3 most likely because python doesn't know where to find it. By following the python packaging guidelines this problem will be solved. I'd remove Resources/Builders/ via files-excluded in d/copyright since these files are not relevant for Debian as far as I see. There is no need in empty d/patches/ d/watch, is there need for +dfsg suffix ? If I run uscan --force-download it downloads and repacks tarball without dfsg suffix. Some files have trailing white space, which is a bit annoying, but this is already nitpicking :) - d/control - d/copyright Best regards, Alex
Bug#955005: Relax requirements to copy copyright notices into d/copyright
No, I missed this. We're on the same page.
Bug#954402: OpenSSL EOF handling, severity import
Control: severity -1 important OpenSSL 1.1.1f is in unstable now which reverts the unexpected EOF reporting via SSL_ERROR_SSL. In the OpenSSL 3.0 release it will be reported again as SSL_ERROR_SSL with reason code SSL_R_UNEXPECTED_EOF_WHILE_READING. Therefore the severity is downgraded to `important' because it no longer leads to an error during build but will later. Sebastian
Bug#909963: xterm-256color: Corrupts first line in hexedit window
On Wed, Apr 01, 2020 at 11:02:13AM +0200, Mathieu Malaterre wrote: > Hi Thomas, > > Thanks for your time reading my bug report. > > On Wed, Apr 1, 2020 at 10:09 AM Thomas Dickey wrote: > > > > On Wed, Apr 01, 2020 at 08:48:20AM +0200, Mathieu Malaterre wrote: > > > Control: affects -1 src:hexedit > > > > > > Here is the output of: > > > > neither the original report nor any followup identifies the actual > > terminal which is being used. In addition to that, there is only But what is the actual terminfo used? a) a terminal emulator such as KDE konsole (and version) b) Linux console > > a copy/paste from the screen (a "typescript" using "script" would > > show what ncurses actually does). > > I have attached the two generated "typescript" files. One is what I > called the good session (setting XTERM to linux) while the other > called the bad one is with the default settings. ... > +|0| > +: Esc [ 7 b > +& REP: REPEAT This is the feature mentioned in the FAQ. It is in xterm for more than 20 years. Some xterm look-alikes came much later. Programs that don't _try_ to act like xterm probably don't support it. > > Given the scanty information, this looks like an old report > > which was addressed in the FAQ, using a system which hasn't been updated. > > > > https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic > > I'll do my best at trying to read and understand this FAQ. :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#924362: Failure upgrading chkrootkit
Hello If no more information is provided, i will close this bug in a few days. Greetings, Marcos. El mar, 24-03-2020 a las 23:21 +0100, Marcos Fouces escribió: > Hello Adam > > I am trying to reproduce the bug with current version of chkrootkit > but > i obtain a different result: > > # sudo /usr/share/debconf/frontend > /var/lib/dpkg/info/chkrootkit.postinst configure 0.53-1; echo $? > > # 0 > > I used a (still unreleased) 0.53-2 version and it seems to be > correctly > upgraded. > > Could you confirm this? > > Greetings, > Marcos. >
Bug#348991: Confirm for iotop behavior
Hello If no more informartion is provided, i will close this bug in a few days. Greetings, Marcos
Bug#955501: yaz: please make the build reproducible
Thanks for the patch. We are using yaz-config for side-by-side builds which means we can't apply that patch as is.. the echo_source definition.. We will have to make two yaz-config's .. One for the side-by-side build which obviously will have those build directories and another one to be installed in /usr/bin without those. / Adam On Wed, Apr 1, 2020 at 7:33 PM Chris Lamb wrote: > Source: yaz > Version: 5.29.0-2 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: buildpath > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Hi, > > Whilst working on the Reproducible Builds effort [0] we noticed that > yaz could not be built reproducibly. > > This is because it embeds the absolute build path into the /usr/bin/ > yaz-config file. > > A patch is attached. As this path will not exist at runtime, assuming > that yaz works today (!), then the application of this patch could be > reasoned to therefore be harmless. > > [0] https://reproducible-builds.org/ > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- >
Bug#954371: [Pkg-openssl-devel] Bug#954371: Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Control: reassign -1 libio-socket-ssl-perl 2.067-1 Control: severity -1 important Hi, On Wed, Apr 01, 2020 at 08:40:05PM +0200, Sebastian Andrzej Siewior wrote: > On 2020-03-31 21:49:51 [+0200], Salvatore Bonaccorso wrote: > > Hi Kurt, > Hi Salvatore, > > > I see, but then I prefer to loop in Steffen Ullrich into the loop > > (upstream of IO::Socket::SSL). Steffen, see the above comment from > > Kurt in the Debian bug, so it looks we cannot close > > https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e > > as broken only. What do you think? > > we have openssl f in unstable so the visibile problem is gone for now. > Can this bug be assigned back to libio-socket-ssl-perl? Okay let's do that. Steffen Any comment on Kurt's hints in https://bugs.debian.org/954371#42? Regards, Salvatore
Bug#955005: Relax requirements to copy copyright notices into d/copyright
Hello Sam, On Wed 01 Apr 2020 at 05:11AM -04, Sam Hartman wrote: > I think there is another use of debian/copyright beyond just documenting > what ends up in the binaries. > I think that if I read debian/copyright in a source package, I should > expect to understand the licenses I need to comply with when dealing > with the source package. > > So for example if the package requires GPL-3 code during its build, and > by policy I don't want to deal with GPL-3 I should know I have a problem > only from reading debian/copyright. > > > So I think you need to talk about more than just binaries. As I mentioned in my e-mail opening the bug, I do not believe that my proposal changes anything at all about the requirements to document licenses in d/copyright, only copyright notices. Please take another look and let me know if my patch somehow changes the requirements to document licenses in a way I did not intend. -- Sean Whitton signature.asc Description: PGP signature
Bug#955507: RM: lilo-installer -- ROM; No longer needed for d-i
Package: ftp.debian.org Severity: normal Hi folks, It's time to remove lilo-installer altogether. We agreed to stop using it some time ago in d-i; now it's time to remove it from the archive too. Cheers, Steve
Bug#955475: mawk: umount tab gives awk error on Bullesye
On Wed, Apr 01, 2020 at 04:31:05AM -0500, Goran Muminovic wrote: > Package: mawk > Version: 1.3.4.20200120-2 > Severity: normal perhaps wishlist. not a bug in mawk. > Typing umount followed by space then tab or tab at half-typed "mount point" > trying to use bash-completion gives following error on Bullseye: > > awk: line 18: function gensub never defined man gawk: GNU EXTENSIONS Gawk has a too-large number of extensions to POSIX awk. They are described in this section. All the extensions described here can be disabled by invoking gawk with the --traditional or --posix options. ... · The and(), asort(), asorti(), bindtextdomain(), compl(), dcgettext(), dcngettext(), gensub(), lshift(), mktime(), or(), patsplit(), rshift(), strftime(), strtonum(), systime() and xor() functions. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#955502: metview: Error creating missing file
Control: reassign -1 metview 5.8.1-2 Control: severity -1 important On Mi, 01 apr 20, 18:39:24, David Goodenough wrote: > Package: metview Version: 5.8.1-2 Severity: important > > Dear Maintainer, > > If I try to start metview froma command line I get:- > > >metview creating Metview user directories in /home/david/metview... UNABLE > >TO > CREATE: missing file metview: EXIT on ERROR (line 1), exit status 1, starting > 'cleanup' /usr/ > bin/metview: line 153: 5: Bad file descriptor > > This is after updating to 5.8.1-2 > > > Trying to pre-create /home/david/metview does not help, and the directory > is always remove on exit. > > > -- System Information: Debian Release: bullseye/sid APT prefers unstable > APT policy: (500, > 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 > > Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, > LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: / > bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: > AppArmor: > enabled > > Versions of packages metview depends on: ii libatlas-ecmwf-0 0.19.0-8+b2 > ii libc6 >2.30-4 ii libeccodes0 2.17.0-1 ii libeckit0d >1.4.7-7 ii libemos0d >2:4.5.9-3 ii libgcc-s110-20200324-1 ii libgdbm6 >1.18.1-5 ii libgeotiff5 > 1.5.1-2+b1 ii libgfortran5 10-20200324-1 ii libmagplus3v5 > 4.3.0-1+b1 ii > libmetview0d 5.8.1-2 ii libnetcdf15 1:4.7.3-1 ii > libodb-api-0d0.18.1-10+b1 ii > libqt5core5a 5.12.5+dfsg-9 ii libqt5gui5 5.12.5+dfsg-9 ii > libqt5network5 > 5.12.5+dfsg-9 ii libqt5printsupport5 5.12.5+dfsg-9 ii libqt5svg5 > 5.12.5-2 ii > libqt5widgets5 5.12.5+dfsg-9 ii libqt5xml5 5.12.5+dfsg-9 ii > libqt5xmlpatterns5 > 5.12.5-1 ii libstdc++6 10-20200324-1 ii libterralib3 > 4.3.0+dfsg.2-12.1 ii metview- > data 5.8.1-2 ii python3 3.8.2-2 ii x11-utils > 7.7+5 > > Versions of packages metview recommends: ii flexpart 9.02-22 ii flextra > 5.0-13 ii > magics++ 4.3.0-1+b1 > > metview suggests no packages. > > -- debconf-show failed > > > -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#954371: [Pkg-openssl-devel] Bug#954371: Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
On 2020-03-31 21:49:51 [+0200], Salvatore Bonaccorso wrote: > Hi Kurt, Hi Salvatore, > I see, but then I prefer to loop in Steffen Ullrich into the loop > (upstream of IO::Socket::SSL). Steffen, see the above comment from > Kurt in the Debian bug, so it looks we cannot close > https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e > as broken only. What do you think? we have openssl f in unstable so the visibile problem is gone for now. Can this bug be assigned back to libio-socket-ssl-perl? > Regards, > Salvatore Sebastian
Bug#955506: aptitude: [INTL:nl] Dutch po file for the aptitude package
Package: aptitude Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch po file for the aptitude package. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as "po/nl.po" in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#955505: apt: [INTL:nl] Dutch po file for the apt package
Package: apt Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch po file for the apt package. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as "po/nl.po" in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#955504: bilibop: [INTL:nl] Dutch translation of debconf messages
Package: bilibop Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of bilibop debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#947716: RFH: terminator -- multiple GNOME terminals in one window
Am Montag, den 30.12.2019, 13:38 +0100 schrieb Markus Frosch: > I tried contacting the admins of the project on launchpad. Now I decided to start this as a project. There is a new GitHub organization: https://github.com/gnome-terminator?type=source You can find all information here: https://github.com/gnome-terminator/terminator/issues/1 Anyone that would like to help is welcome! Regards Markus -- lazyfro...@debian.org https://lazyfrosch.de
Bug#949062: ifupdown: Bonding interface gets the wrong MAC address when configured for the first time
Package: ifupdown Version: 0.8.35+b1 Followup-For: Bug #949062 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It looks like systemd is the one to blame. I've managed to solve the issue by creating the following file: # cat /etc/systemd/network/99-default.link [Match] OriginalName=bond* [Link] MACAddressPolicy=none See this link[1] for more info. [1]: https://bugzilla.suse.com/show_bug.cgi?id=1136600 - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-amd64+ (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: TAINT_RANDSTRUCT 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 ifupdown depends on: ii adduser 3.118 ii iproute2 5.5.0-1 ii libc6 2.30-4 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2.1+b2 Versions of packages ifupdown suggests: ii ppp 2.4.7-2+4.1+b1 pn rdnssd - -- Configuration Files: /etc/default/networking changed [not included] - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXoTVOwAKCRAy2ctjR5bM oe2+AP9aVF/Tz4uQ1HuugWjxXhmMWMUnG4UfPJb3C46i45BCWAEAo7Df5SbUfOKz DyrsIPTZceTmzXnwlzLDse4QUSLTSAw= =9XVO -END PGP SIGNATURE-
Bug#955503: RM: python-elements -- RoQA; Depends on Python 2, dead upstream, unmaintained
Package: ftp.debian.org Severity: normal Please remove python-elements. It's dead upstream (no commit since seven years, depends on Python 2, there are no reverse deps and there hasn't been a maintainer upload since 2010 (and the package is RC-buggy since 2018 due to the invalid maintainer address) Cheers, Moritz
Bug#955502: metview: Error creating missing file
Package: metview Version: 5.8.1-2 Severity: important Dear Maintainer, If I try to start metview froma command line I get:- >metview creating Metview user directories in /home/david/metview... UNABLE TO CREATE: missing file metview: EXIT on ERROR (line 1), exit status 1, starting 'cleanup' /usr/ bin/metview: line 153: 5: Bad file descriptor This is after updating to 5.8.1-2 Trying to pre-create /home/david/metview does not help, and the directory is always remove on exit. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: / bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages metview depends on: ii libatlas-ecmwf-0 0.19.0-8+b2 ii libc6 2.30-4 ii libeccodes0 2.17.0-1 ii libeckit0d 1.4.7-7 ii libemos0d 2:4.5.9-3 ii libgcc-s110-20200324-1 ii libgdbm6 1.18.1-5 ii libgeotiff5 1.5.1-2+b1 ii libgfortran5 10-20200324-1 ii libmagplus3v5 4.3.0-1+b1 ii libmetview0d 5.8.1-2 ii libnetcdf15 1:4.7.3-1 ii libodb-api-0d0.18.1-10+b1 ii libqt5core5a 5.12.5+dfsg-9 ii libqt5gui5 5.12.5+dfsg-9 ii libqt5network5 5.12.5+dfsg-9 ii libqt5printsupport5 5.12.5+dfsg-9 ii libqt5svg5 5.12.5-2 ii libqt5widgets5 5.12.5+dfsg-9 ii libqt5xml5 5.12.5+dfsg-9 ii libqt5xmlpatterns5 5.12.5-1 ii libstdc++6 10-20200324-1 ii libterralib3 4.3.0+dfsg.2-12.1 ii metview- data 5.8.1-2 ii python3 3.8.2-2 ii x11-utils 7.7+5 Versions of packages metview recommends: ii flexpart 9.02-22 ii flextra 5.0-13 ii magics++ 4.3.0-1+b1 metview suggests no packages. -- debconf-show failed
Bug#955501: yaz: please make the build reproducible
Source: yaz Version: 5.29.0-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that yaz could not be built reproducibly. This is because it embeds the absolute build path into the /usr/bin/ yaz-config file. A patch is attached. As this path will not exist at runtime, assuming that yaz works today (!), then the application of this patch could be reasoned to therefore be harmless. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/reproducible-build.patch 2020-04-01 18:15:31.120487468 +0100 @@ -0,0 +1,17 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2020-04-01 + +--- yaz-5.29.0.orig/yaz-config.in yaz-5.29.0/yaz-config.in +@@ -14,8 +14,8 @@ echo_include=no + echo_source=yes + echo_lalibs=no + echo_comp=no +-src_root="@abs_top_srcdir@" +-build_root="@abs_top_builddir@" ++src_root="/nonexistent" ++build_root="/nonexistent" + ICU_LIBS="@ICU_LIBS@" + ICU_CPPFLAGS="@ICU_CPPFLAGS@" + SSL_LIBS="@SSL_LIBS@" --- a/debian/patches/series 2020-04-01 18:10:23.033987972 +0100 --- b/debian/patches/series 2020-04-01 18:15:30.084479062 +0100 @@ -1 +1,2 @@ yaz_diag_to_str.patch +reproducible-build.patch
Bug#955500: faudio: Please update to latest upstream version
Source: faudio Severity: wishlist Dear Maintainer, faudio in Debian unstable / testing got pretty outdated. In general, upstream releases new versions every month with various bug fixes and features. See: https://github.com/FNA-XNA/FAudio/releases Currently the latest version is 20.04. Please update it in Debian repos. Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0 (SMP w/24 CPU cores) Kernel taint flags: TAINT_WARN, 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#955499: lxcfs: LXC container reports spike in swap occasionally
Package: lxcfs Version: 3.0.4-2 Severity: normal Dear Maintainer, * lxcfs provides a container-specific view of /proc/meminfo. * Occasionally, with near zero or zero swap usage *and* swap * accounting turned on (kernel parameter swapaccount=1), the * container will report 100% swap utilization. * There is a fix upstream: https://github.com/lxc/lxcfs/pull/316 * It has been applied to the upstream stable-3.0 branch: * https://github.com/lxc/lxcfs/commit/f18d29d86acca2b0218c296f7451f9a1d9fe8c55 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-18-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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) Versions of packages lxcfs depends on: ii init-system-helpers 1.57 ii libc62.30-4 pn libfuse2 ii lsb-base 11.1.0 lxcfs recommends no packages. lxcfs suggests no packages.
Bug#886254: ITP: cuba -- library for multidimensional numerical integration
The package is available on salsa science-team group. However, it was rejected due to license issues discussed in [1]. I didn't receive feedback from upstream yet, and a similar package, cubature, was recently added to Debian. Hence, at the moment I am no longer very motivated to maintain the package. I am going to retitle the ITP to RFP, in case in future the copyright and proprietary license issues will be solved. [1] https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2019-December/076976.html Best, Francesco
Bug#955498: RFP: libtap-harness-junit-perl -- Generate JUnit compatible output from TAP results
Package: wnpp Severity: see below https://github.com/jlavallee/tap-harness-junit https://metacpan.org/pod/TAP::Harness::JUnit License: > This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. Debian already packages the TAP formatter https://packages.debian.org/buster/libtap-formatter-junit-perl but you can't actually use that easily without this corresponding TAP::Harness::Junit module. I'd like to request that Debian include this package in future releases. Thank you, Brendan J. McCollam
Bug#954654: transition: hdf5
Some intervention for gdal on s390x may be needed, it's stuck in Maybe-Successful state blocking the rebuild of its rdeps. The log seems to indicate that the build was indeed successful. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#955497: ITP: ruby-ffi-compiler -- Automating compilation of native libraries
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-ffi-compiler Version : 1.0.1 Upstream Author : Wayne Meissner * URL : https://github.com/ffi/ffi-compiler * License : Apache-2.0 Programming Lang : Ruby Description : Automating compilation of native libraries ffi-compiler is a ruby library for automating compilation of native libraries for use with ffi. . To use, define your own ruby->native API using ffi, implement it in C, then use ffi-compiler to compile it. Best, Utkarsh
Bug#955496: RFS: libsys-hostaddr-perl/0.993-1 [ITP] -- Get IP address information about this host
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libsys-hostaddr-perl" * Package name: libsys-hostaddr-perl Version : 0.993-1 Upstream Author : Jeremy Kister|http://jeremy.kister.net/ * URL : https://metacpan.org/release/Sys-HostAddr * License : Artistic * Vcs : https://salsa.debian.org/hilmar-guest/libsys-hostaddr-perl Section : perl It builds those binary packages: libsys-hostaddr-perl - Get IP address information about this host To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libsys-hostaddr-perl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libs/libsys-hostaddr-perl/libsys-hostaddr-perl_0.993-1.dsc Changes since the last upload: * Initial release. (Closes: #955449). Regards, Hilmar Preusse -- Hilmar Preusse -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#951142: mwic: Please package new upstream version (0.7.8)
Hi, the solution is to add the package 'hunspell-en-gb' to build and test-run dependencies, so the en-GB locale related tests can succeed. See https://salsa.debian.org/python-team/modules/mwic/-/merge_requests/1
Bug#955495: ITP: orthanc-python -- Develop plugins for Orthanc using the Python programming language
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-python Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://www.orthanc-server.com/ * License : AGPL Programming Lang: C++, Python Description : Develop plugins for Orthanc using the Python programming language This plugin can be used to write Orthanc plugins using the Python programming language instead of the more complex C/C++ programming languages. It can be used to gain access to Python modules directly in Orthanc. This plugin can be of great help to anyone wishing to automate her imaging workflow, to design/train new machine learning algorithms, or to deploy AI systems directly in clinical setups. Full documentation is available in the Orthanc Book: https://book.orthanc-server.com/plugins/python.html
Bug#955490: [Pkg-libvirt-maintainers] Bug#955490: libvirt-daemon: ERROR internal error: child reported (status=125): Kernel does not provide mount namespace: Permission denied
Sorry, my mistake. On Wed, 1 Apr 2020 at 17:02, Guido Günther wrote: > control: severity -1 normal > > Hi, > On Wed, Apr 01, 2020 at 04:39:34PM +0200, usuario wrote: > > Package: libvirt-daemon > > Version: 6.0.0-4 > > Severity: grave > > Tags: a11y > > Justification: renders package unusable > > certainly not unusable since others ore running just fine. > -- Guido > > > > > Dear Maintainer, > > > > *** Reporter, please consider answering these questions, where > appropriate *** > > > >* What led up to the situation? > > > > sudo virt-install \ > > -n vm1 \ > > -r 512 \ > > --vcpus=2 \ > > --os-variant=debiantesting \ > > --disk /var/lib/libvirt/images/vm1.img,size=2 \ > > --nographics \ > > -l http://ftp.debian.org/debian/dists/testing/main/installer-amd64/ \ > > -x console=ttyS0,115200 > > > >* What exactly did you do (or not do) that was effective (or > > ineffective)? > > > > Launch above command > > > >* What was the outcome of this action? > > > > Below error: > > > > ERRORinternal error: child reported (status=125): Kernel does not > provide mount namespace: Permission denied > > > >* What outcome did you expect instead? > > > > A success message confirming I'm able to install the Virtual Machine > > > > *** End of the template - remove these template lines *** > > > > > > -- System Information: > > Debian Release: bullseye/sid > > APT prefers testing > > APT policy: (500, 'testing') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages libvirt-daemon depends on: > > ii libblkid1 2.34-0.1 > > ii libc6 2.30-2 > > ii libcap-ng0 0.7.9-2.1+b2 > > ii libdbus-1-3 1.12.16-2 > > ii libdevmapper1.02.1 2:1.02.167-1+b1 > > ii libfuse22.9.9-3 > > ii libgcc-s1 10-20200324-1 > > ii libglib2.0-02.64.1-1 > > ii libnetcf1 1:0.2.8-1+b3 > > ii libparted2 3.3-4 > > ii libpcap0.8 1.9.1-2 > > ii libpciaccess0 0.14-1 > > ii libselinux1 3.0-1+b1 > > ii libudev1244.3-1 > > ii libvirt-daemon-driver-qemu 6.0.0-4 > > ii libvirt06.0.0-4 > > ii libxml2 2.9.10+dfsg-4 > > > > Versions of packages libvirt-daemon recommends: > > ii libvirt-daemon-driver-lxc 6.0.0-4 > > ii libvirt-daemon-driver-vbox 6.0.0-4 > > ii libvirt-daemon-driver-xen 6.0.0-4 > > ii libxml2-utils 2.9.10+dfsg-4 > > ii netcat-openbsd 1.206-1 > > ii qemu-kvm1:4.2-3 > > > > Versions of packages libvirt-daemon suggests: > > pn libvirt-daemon-driver-storage-gluster > > pn libvirt-daemon-driver-storage-rbd > > pn libvirt-daemon-driver-storage-zfs > > ii libvirt-daemon-system 6.0.0-4 > > pn numad > > > > -- debconf-show failed > > > > ___ > > Pkg-libvirt-maintainers mailing list > > pkg-libvirt-maintain...@alioth-lists.debian.net > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers >
Bug#945710: neopi: Python2 removal in sid/bullseye
On 4/1/20 5:31 PM, Sandro Tosi wrote: >> I'm no longer interested in this package. I guess Miguel Angel Martin >> Serrano is >> also not interested. >> >> Feel free to adopt it, otherwise I will probably drop it from Debian at some >> point. > > I'm not interested in the package either, if you dont mind, i'd like > to file a removal bugs in the next few days - this will help with the > py2removal effort. > That would be appreciated. Thanks!
Bug#945710: neopi: Python2 removal in sid/bullseye
> I'm no longer interested in this package. I guess Miguel Angel Martin Serrano > is > also not interested. > > Feel free to adopt it, otherwise I will probably drop it from Debian at some > point. I'm not interested in the package either, if you dont mind, i'd like to file a removal bugs in the next few days - this will help with the py2removal effort. Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#955494: `menhir --suggest-menhirLib` suggests wrong directory
Package: menhir Version: 20200123-2 Severity: important Dear Maintainer, `menhir --suggest-menhirLib` returns `/usr/lib/menhirLib` which does not exist. It think it should return `/usr/lib/ocaml/menhirLib`. Cheers, -- Stéphane -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages menhir depends on: ii libc6 2.29-10 menhir recommends no packages. Versions of packages menhir suggests: pn menhir-doc -- no debconf information
Bug#951771: linux-source-5.4: linux 5.4.0-4 does not boot on this pc
Control: found -1 src:linux 5.5.13-2 thanks Hi, linux 5.5.13-2 still does not boot on this computer. Adding 'nomodeset i915.modeset=0' to boot options solves that. This time full Hardware overview attached. Thanks. kind regards, Thilo Package: src:linux Version: 5.5.13-2 Severity: normal -- Package-specific info: ** Version: Linux version 5.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.5.0-1-amd64 root=UUID=492e9a7d-9e6d-4702-81a2-ed1816a5a973 ro nomodeset i915.modeset=0 consoleblank=0 systemd.show_status=1 ** Tainted: E (8192) * unsigned module was loaded ** Kernel log: [5.883468] usb usb7: Manufacturer: Linux 5.5.0-1-amd64 ehci_hcd [5.883469] usb usb7: SerialNumber: :00:1a.7 [5.885335] hub 7-0:1.0: USB hub found [5.885343] hub 7-0:1.0: 6 ports detected [5.911441] hub 1-0:1.0: USB hub found [5.911449] hub 1-0:1.0: 2 ports detected [5.918863] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k [5.918864] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [5.919067] e1000e :00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [5.919814] sr 1:0:0:0: [sr0] scsi3-mmc drive: 48x/32x writer dvd-ram cd/rw xa/form2 cdda tray [5.919817] cdrom: Uniform CD-ROM driver Revision: 3.20 [5.931655] sr 1:0:0:0: Attached scsi CD-ROM sr0 [5.939437] hub 2-0:1.0: USB hub found [5.939445] hub 2-0:1.0: 2 ports detected [5.967426] hub 3-0:1.0: USB hub found [5.967434] hub 3-0:1.0: 2 ports detected [6.003797] ppdev: user-space parallel port driver [6.006809] fschmd 0-0073: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). [6.007619] fschmd 0-0073: Registered watchdog chardev major 10, minor: 130 [6.007620] fschmd 0-0073: Detected FSC Hades chip, revision: 112 [6.051530] ehci-pci :00:1d.7: EHCI Host Controller [6.051537] ehci-pci :00:1d.7: new USB bus registered, assigned bus number 8 [6.051548] ehci-pci :00:1d.7: debug port 1 [6.055469] ehci-pci :00:1d.7: cache line size of 32 is not supported [6.057689] watchdog: iamt_wdt: cannot register miscdev on minor=130 (err=-16). [6.057752] watchdog: iamt_wdt: a legacy watchdog module is probably present. [6.060814] ehci-pci :00:1d.7: irq 20, io mem 0xf03a7400 [6.075364] ehci-pci :00:1d.7: USB 2.0 started, EHCI 1.00 [6.075406] usb usb8: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05 [6.075408] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [6.075409] usb usb8: Product: EHCI Host Controller [6.075410] usb usb8: Manufacturer: Linux 5.5.0-1-amd64 ehci_hcd [6.075411] usb usb8: SerialNumber: :00:1d.7 [6.075624] hub 8-0:1.0: USB hub found [6.075725] hub 8-0:1.0: 6 ports detected [6.103454] hub 4-0:1.0: USB hub found [6.103615] hub 4-0:1.0: 2 ports detected [6.108917] iTCO_vendor_support: vendor-support=0 [6.125838] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [6.125870] iTCO_wdt: Found a ICH9DO TCO device (Version=2, TCOBASE=0x1060) [6.125892] watchdog: iTCO_wdt: cannot register miscdev on minor=130 (err=-16). [6.125957] watchdog: iTCO_wdt: a legacy watchdog module is probably present. [6.126048] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [6.131447] hub 5-0:1.0: USB hub found [6.131463] hub 5-0:1.0: 2 ports detected [6.159410] hub 6-0:1.0: USB hub found [6.159417] hub 6-0:1.0: 2 ports detected [6.171777] intel_powerclamp: No package C-state available [6.199698] intel_powerclamp: No package C-state available [6.201472] e1000e :00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:19:99:32:80:b1 [6.201474] e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection [6.201500] e1000e :00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FF-0FF [6.320222] snd_hda_codec_realtek hdaudioC0D2: autoconfig for ALC262: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [6.320225] snd_hda_codec_realtek hdaudioC0D2:speaker_outs=1 (0x16/0x0/0x0/0x0/0x0) [6.320226] snd_hda_codec_realtek hdaudioC0D2:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [6.320227] snd_hda_codec_realtek hdaudioC0D2:mono: mono_out=0x0 [6.320228] snd_hda_codec_realtek hdaudioC0D2:inputs: [6.320230] snd_hda_codec_realtek hdaudioC0D2: Front Mic=0x19 [6.320231] snd_hda_codec_realtek hdaudioC0D2: Rear Mic=0x18 [6.320233] snd_hda_codec_realtek hdaudioC0D2: Line=0x1a [6.335947] input: HDA Intel Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input10 [6.336009] input: HDA Intel Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input11 [6.336064] input: HDA Intel Line as /devices/pci:00/:00:1b.0/sound/card0/input12 [6.336112] input: HDA Intel L
Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
(Switched back to my main address, accidentally switched to GMail) On 4/1/20 5:05 PM, Sébastien Villemot wrote: >> So, the currently only candidate for this scenario is mipsel and I think this >> is a risk that is bearable, in particular since upstream considers 32-bit >> mips >> one of the supported architectures unlike alpha and hppa. > > There is also armel that you added recently (I don’t know how supported > it is by upstream). ARMv5 is actually the default baseline that upstream supports. A patch by me to raise the baseline for ARM was rejected by Stas. >> In the worst case, you will have to file a removal bugs for sbcl on mipsel >> if upstream is really unwilling to fix the build issue on mipsel which I >> don't >> think is the case. I have had a lot of interaction with Doug Kratzman from >> sbcl upstream and he is usually very responsive. >> >> I will help with the package in any case. > > Note that several reverse build-dependencies of sbcl (e.g. pgloader) > would have to be removed as well. Good point, but I think the list isn't too long: Checking reverse dependencies... # Broken Depends: buildapp: buildapp [amd64 arm64 armel armhf i386 ppc64el] # Broken Build-Depends: apt-dpkg-ref: sbcl buildapp: sbcl cafeobj: sbcl cffi: sbcl cl-alexandria: sbcl cl-asdf: sbcl cl-unicode: sbcl pgcharts/non-free: sbcl (>= 1.2.0) pgloader: sbcl (>= 1.1.13) stumpwm: sbcl > In any case, thanks for your commitment to helping with portability. > I’m going to apply the patch attached to the present bug in the next > upload. Thanks and you're welcome. I enjoy fixing these portability issues. 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#955493: network-manager-fortisslvpn: new upstream available
Source: network-manager-fortisslvpn Version: 1.2.8-2 Severity: wishlist Dear maintainer, There is a new upstream release that implements a few new things, amongst which it exposes the "realm" settings, which is required for some networks. -- 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#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen
Dear Maintainer, I observed such logging, too. My system is similar to the submitters one. Found two occourences in still available kern.log* files. (See attached file.) One was most probably related to a "GPU fault" 25 seconds before, running 4.19.0-8-amd64/4.19.98-1. The other was while not being at the idling system, running 5.4.0-0.bpo.3-amd64/5.4.13-1~bpo10+1. No negative consequence found at that time. Kind regards, Bernhard # LANG=C lscpu ... CPU family: 23 Model: 1 Model name: AMD Ryzen 7 1700 Eight-Core Processor Stepping:1 ... # (zcat kern.log.4.gz kern.log.3.gz kern.log.2.gz; cat kern.log.1 kern.log) | grep -E "NMI received|Linux version" -A3 Mar 7 00:10:29 rechner kernel: [0.00] Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26) ... Mar 7 00:10:29 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019 ... Mar 7 00:13:49 rechner kernel: [ 205.788363] amdgpu :08:00.0: GPU fault detected: 147 0x0c304401 for process SOTTR.exe pid 3426 thread SOTTR.exe:cs0 pid 3448 Mar 7 00:13:49 rechner kernel: [ 205.788370] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0FF22786 Mar 7 00:13:49 rechner kernel: [ 205.788373] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E044001 Mar 7 00:13:49 rechner kernel: [ 205.788378] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 267528070, read from 'TC1' (0x54433100) (68) ... Mar 7 00:13:49 rechner kernel: [ 205.788463] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 142747517, read from 'TC1' (0x54433100) (68) Mar 7 00:13:59 rechner kernel: [ 215.998608] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=25858, emitted seq=25860 Mar 7 00:13:59 rechner kernel: [ 215.998615] [drm] GPU recovery disabled. Mar 7 00:14:14 rechner kernel: [ 230.580910] Uhhuh. NMI received for unknown reason 2d on CPU 7. Mar 7 00:14:14 rechner kernel: [ 230.580911] Do you have a strange power saving mode enabled? Mar 7 00:14:14 rechner kernel: [ 230.580914] Dazed and confused, but trying to continue Mar 7 00:15:17 rechner kernel: [ 294.139939] sysrq: SysRq : Keyboard mode set to system default Mar 7 00:15:20 rechner kernel: [ 296.891922] sysrq: SysRq : Terminate All Tasks (attempt to test Shadow of the Tomb Raider Trial via Steam, kernel crash dump available, at least the "GPU fault" was reproducible.) -- Mar 26 10:00:52 rechner kernel: [0.00] Linux version 5.4.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07) ... Mar 26 10:00:52 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019 ... Mar 29 07:27:08 rechner kernel: [246383.312487] Uhhuh. NMI received for unknown reason 3c on CPU 6. Mar 29 07:27:08 rechner kernel: [246383.312488] Do you have a strange power saving mode enabled? Mar 29 07:27:08 rechner kernel: [246383.312489] Dazed and confused, but trying to continue Mar 29 07:35:37 rechner kernel: [246892.656398] Process accounting resumed (system was at this time idle, no negative consequences recognized, system could be shutdown later without problems.)
Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Le mercredi 01 avril 2020 à 16:56 +0200, John Paul Adrian Glaubitz a écrit : > On 4/1/20 4:51 PM, Sébastien Villemot wrote: > > > FWIW, sbcl builds fine for me on mipsel if clang is used as the C > > > compiler, > > > I'll file a separate bug report for that. > > > > I have mixed feelings about this. I am worried by the fact that those > > architectures are not really supported upstream. Hence, if by chance we > > manage to compile SBCL on one of those mostly-unsupported archs, I > > don’t know how we would be able to deal with regressions that could > > appear in the future, and that would block testing migration for > > supported archs. > > First of all, testing migration is only affected if: > > a) a package previously built fine on a certain architecture > b) the architecture in question is one of the release architectures > (this does not apply for alpha, hppa, ppc64, riscv64) > > So, the currently only candidate for this scenario is mipsel and I think this > is a risk that is bearable, in particular since upstream considers 32-bit mips > one of the supported architectures unlike alpha and hppa. There is also armel that you added recently (I don’t know how supported it is by upstream). > In the worst case, you will have to file a removal bugs for sbcl on mipsel > if upstream is really unwilling to fix the build issue on mipsel which I don't > think is the case. I have had a lot of interaction with Doug Kratzman from > sbcl upstream and he is usually very responsive. > > I will help with the package in any case. Note that several reverse build-dependencies of sbcl (e.g. pgloader) would have to be removed as well. In any case, thanks for your commitment to helping with portability. I’m going to apply the patch attached to the present bug in the next upload. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#955492: ITP: thumbor -- thumbor is a photo thumbnail service
Package: wnpp Severity: wishlist * Package name: thumbor Version : 7.0.0a5 Upstream Author : Globo.com * URL : https://github.com/thumbor/thumbor * License : MIT License Programming Lang: Python Description : thumbor is a photo thumbnail service Thumbor is a smart imaging service. It enables on-demand crop, resizing and flipping of images. It also features a VERY smart detection of important points in the image for better cropping and resizing, using state-of-the-art face and feature detection algorithms (more on that in Detection Algorithms). Using thumbor is very easy (after it is running). All you have to do is access it using an url for an image, like this: http:///300x200/smart/s.glbimg.com/et/bb/f/original/2011/03/24/VN0JiwzmOw0b0lg.jpg -- Marcelo Jorge Vieira xmpp:me...@jabber-br.org http://metaldot.alucinados.com https://movimente.me signature.asc Description: This is a digitally signed message part
Bug#955490: [Pkg-libvirt-maintainers] Bug#955490: libvirt-daemon: ERROR internal error: child reported (status=125): Kernel does not provide mount namespace: Permission denied
control: severity -1 normal Hi, On Wed, Apr 01, 2020 at 04:39:34PM +0200, usuario wrote: > Package: libvirt-daemon > Version: 6.0.0-4 > Severity: grave > Tags: a11y > Justification: renders package unusable certainly not unusable since others ore running just fine. -- Guido > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > sudo virt-install \ > -n vm1 \ > -r 512 \ > --vcpus=2 \ > --os-variant=debiantesting \ > --disk /var/lib/libvirt/images/vm1.img,size=2 \ > --nographics \ > -l http://ftp.debian.org/debian/dists/testing/main/installer-amd64/ \ > -x console=ttyS0,115200 > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Launch above command > >* What was the outcome of this action? > > Below error: > > ERRORinternal error: child reported (status=125): Kernel does not provide > mount namespace: Permission denied > >* What outcome did you expect instead? > > A success message confirming I'm able to install the Virtual Machine > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libvirt-daemon depends on: > ii libblkid1 2.34-0.1 > ii libc6 2.30-2 > ii libcap-ng0 0.7.9-2.1+b2 > ii libdbus-1-3 1.12.16-2 > ii libdevmapper1.02.1 2:1.02.167-1+b1 > ii libfuse22.9.9-3 > ii libgcc-s1 10-20200324-1 > ii libglib2.0-02.64.1-1 > ii libnetcf1 1:0.2.8-1+b3 > ii libparted2 3.3-4 > ii libpcap0.8 1.9.1-2 > ii libpciaccess0 0.14-1 > ii libselinux1 3.0-1+b1 > ii libudev1244.3-1 > ii libvirt-daemon-driver-qemu 6.0.0-4 > ii libvirt06.0.0-4 > ii libxml2 2.9.10+dfsg-4 > > Versions of packages libvirt-daemon recommends: > ii libvirt-daemon-driver-lxc 6.0.0-4 > ii libvirt-daemon-driver-vbox 6.0.0-4 > ii libvirt-daemon-driver-xen 6.0.0-4 > ii libxml2-utils 2.9.10+dfsg-4 > ii netcat-openbsd 1.206-1 > ii qemu-kvm1:4.2-3 > > Versions of packages libvirt-daemon suggests: > pn libvirt-daemon-driver-storage-gluster > pn libvirt-daemon-driver-storage-rbd > pn libvirt-daemon-driver-storage-zfs > ii libvirt-daemon-system 6.0.0-4 > pn numad > > -- debconf-show failed > > ___ > Pkg-libvirt-maintainers mailing list > pkg-libvirt-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Hi! On 4/1/20 4:51 PM, Sébastien Villemot wrote: >> FWIW, sbcl builds fine for me on mipsel if clang is used as the C compiler, >> I'll file a separate bug report for that. > > I have mixed feelings about this. I am worried by the fact that those > architectures are not really supported upstream. Hence, if by chance we > manage to compile SBCL on one of those mostly-unsupported archs, I > don’t know how we would be able to deal with regressions that could > appear in the future, and that would block testing migration for > supported archs. First of all, testing migration is only affected if: a) a package previously built fine on a certain architecture b) the architecture in question is one of the release architectures (this does not apply for alpha, hppa, ppc64, riscv64) So, the currently only candidate for this scenario is mipsel and I think this is a risk that is bearable, in particular since upstream considers 32-bit mips one of the supported architectures unlike alpha and hppa. In the worst case, you will have to file a removal bugs for sbcl on mipsel if upstream is really unwilling to fix the build issue on mipsel which I don't think is the case. I have had a lot of interaction with Doug Kratzman from sbcl upstream and he is usually very responsive. I will help with the package in any case. 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#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Hi, Le mercredi 01 avril 2020 à 16:43 +0200, John Paul Adrian Glaubitz a écrit : > On 3/16/20 1:16 AM, John Paul Adrian Glaubitz wrote: > > sbcl has partial support for alpha, hppa, mips*, ppc64 and riscv64 > > and if we try to build sbcl on any architecture using clisp, we will > > be able to provide upstream with a build log of sbcl on any architecture > > that might be supported in the future (like ppc64 and riscv64) or > > was previously supported and is currently broken (like alpha and hppa). > > > > The attached patch enables building with clisp on all unsupported > > architectures. > > Any chance we can get this implemented for the next upload? > > FWIW, sbcl builds fine for me on mipsel if clang is used as the C compiler, > I'll file a separate bug report for that. I have mixed feelings about this. I am worried by the fact that those architectures are not really supported upstream. Hence, if by chance we manage to compile SBCL on one of those mostly-unsupported archs, I don’t know how we would be able to deal with regressions that could appear in the future, and that would block testing migration for supported archs. What’s your view on this? Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#955486: Acknowledgement (ITP: python3-box -- Python dictionaries with advanced dot notation access)
Hi, Sorry for typo , fixed below : Package: python-box Thanks, Michal Arbet ( kevko ) st 1. 4. 2020 v 15:03 odesílatel Debian Bug Tracking System < ow...@bugs.debian.org> napsal: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 955486: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955486. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > w...@debian.org > > If you wish to submit further information on this problem, please > send it to 955...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 955486: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955486 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#955484: ITP: python3-dynaconf --Easy and Powerful Settings Configuration for Python
Hi Sandro, Sorry for typo, of course i've set name to python-dynaconf and will maintain inside DPMT team. Feel free to check salsa git : https://salsa.debian.org/python-team/modules/python-dynaconf/-/blob/master/debian/changelog Thanks, Michal Arbet (kevko) st 1. 4. 2020 v 16:12 odesílatel Sandro Tosi napsal: > On Wed, 1 Apr 2020 14:33:34 +0200 Michal Arbet > wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Michal Arbet > > > > * Package name: python3-dynaconf > > Version : 2.2.3 > > Upstream Author : Bruno Rocha > > * URL : https://github.com/rochacbruno/dynaconf > > * License : MIT > > Programming Lang: Python > > Description : Easy and Powerful Settings Configuration for Python > > the source package name should be python-dynaconf. > > please also consider maintaining this package with the Debian Python > Modules team >
Bug#944592: FTBFS with OCaml 4.08.1 (safe strings)
control: tags -1 patch pending diff uploaded G. On Tue, 12 Nov 2019 10:22:55 +0100 =?utf-8?q?St=C3=A9phane_Glondu?= wrote: > Package: src:ocaml-deriving-ocsigen > Version: 0.7.1-1 > Severity: serious > Tags: ftbfs > User: debian-ocaml-ma...@lists.debian.org > Usertags: ocaml-4.08-transition > > Dear Maintainer, > > ocaml-deriving-ocsigen FTBFS with OCaml 4.08.1 because -safe-string is > the default now: > > https://buildd.debian.org/status/package.php?p=ocaml-deriving-ocsigen > > > Cheers, > > -- > Stéphane > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.2.0-3-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 /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled diff -Nru ocaml-deriving-ocsigen-0.7.1/debian/changelog ocaml-deriving-ocsigen-0.7.1/debian/changelog --- ocaml-deriving-ocsigen-0.7.1/debian/changelog 2016-08-03 16:27:18.0 +0200 +++ ocaml-deriving-ocsigen-0.7.1/debian/changelog 2020-04-01 16:30:46.0 +0200 @@ -1,3 +1,13 @@ +ocaml-deriving-ocsigen (0.7.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + + [ Dimitri John Ledkov ] + * Cherrypick upstream patch to fix ftbfs with new ocaml (Closes: #944592). + * Add libnum-ocaml-dev dependency + + -- Gianfranco Costamagna Wed, 01 Apr 2020 16:30:46 +0200 + ocaml-deriving-ocsigen (0.7.1-1) unstable; urgency=medium * New upstream release diff -Nru ocaml-deriving-ocsigen-0.7.1/debian/control ocaml-deriving-ocsigen-0.7.1/debian/control --- ocaml-deriving-ocsigen-0.7.1/debian/control 2016-08-03 16:26:27.0 +0200 +++ ocaml-deriving-ocsigen-0.7.1/debian/control 2020-04-01 16:30:43.0 +0200 @@ -11,6 +11,7 @@ debhelper (>= 9), libtype-conv-camlp4-dev (>= 108), liboptcomp-camlp4-dev, + libnum-ocaml-dev, oasis (>= 0.4.5), camlp4-extra Standards-Version: 3.9.8 diff -Nru ocaml-deriving-ocsigen-0.7.1/debian/patches/df07e7150f4d196720fa6b44a289783ae9168810.patch ocaml-deriving-ocsigen-0.7.1/debian/patches/df07e7150f4d196720fa6b44a289783ae9168810.patch --- ocaml-deriving-ocsigen-0.7.1/debian/patches/df07e7150f4d196720fa6b44a289783ae9168810.patch 1970-01-01 01:00:00.0 +0100 +++ ocaml-deriving-ocsigen-0.7.1/debian/patches/df07e7150f4d196720fa6b44a289783ae9168810.patch 2020-04-01 16:30:43.0 +0200 @@ -0,0 +1,82 @@ +From df07e7150f4d196720fa6b44a289783ae9168810 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Daniel=20Hillerstr=C3=B6m?= +Date: Tue, 14 Nov 2017 19:56:45 + +Subject: [PATCH] Since OCaml 4.06.0 (-safe-string option) bytes and strings + cannot be used interchangeably. This patch fixes the code base such that the + modules Bytes and String (and hence types bytes and string) are no longer + used interchangeably. + +--- + lib/deriving_Dump.ml | 7 --- + lib/deriving_interned.ml | 9 + + syntax/common/utils.ml | 2 +- + 3 files changed, 10 insertions(+), 8 deletions(-) + +diff --git a/lib/deriving_Dump.ml b/lib/deriving_Dump.ml +index 13e356f..9bafe3d 100644 +--- a/lib/deriving_Dump.ml b/lib/deriving_Dump.ml +@@ -142,7 +142,7 @@ module Dump_string = Defaults ( + for i = 0 to len - 1 do + Bytes.unsafe_set s i (Stream.next stream) + done; +-s ++Bytes.to_string s + end + ) + +@@ -241,7 +241,8 @@ module Dump_via_marshal (P : sig type a end) = Defaults ( + struct + include P + let to_buffer buffer obj = Buffer.add_string buffer (Marshal.to_string obj [Marshal.Closures]) +-let from_stream stream = ++let from_stream stream = ++ let to_string bs = Bytes.to_string bs in + let readn n = + let s = Bytes.create n in + for i = 0 to n - 1 do +@@ -252,5 +253,5 @@ module Dump_via_marshal (P : sig type a end) = Defaults ( + let header = readn Marshal.header_size in + let datasize = Marshal.data_size header 0 in + let datapart = readn datasize in +-Marshal.from_string (header ^ datapart) 0 ++Marshal.from_string ((to_string header) ^ (to_string datapart)) 0 + end) +diff --git a/lib/deriving_interned.ml b/lib/deriving_interned.ml +index d53bcc7..88aad8f 100644 +--- a/lib/deriving_interned.ml b/lib/deriving_interned.ml +@@ -14,15 +14,16 @@ type t = int * string + deriving (Show) + + let intern s = +- try BytesMap.find s !map ++ let bs = Bytes.of_string s in ++ try BytesMap.find bs !map + with Not_found -> +-let fresh = (!counter, Bytes.of_string s) in begin +- map := BytesMap.add s fresh !map; ++let fresh = (!counter, s) in begin ++ map := BytesMap.add bs fresh !map; + incr counter; + fresh + end + +-let to_string (_,s) = Bytes.to_string s ++let to_string (_,s) = s + let name
Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Hi! On 3/16/20 1:16 AM, John Paul Adrian Glaubitz wrote: > sbcl has partial support for alpha, hppa, mips*, ppc64 and riscv64 > and if we try to build sbcl on any architecture using clisp, we will > be able to provide upstream with a build log of sbcl on any architecture > that might be supported in the future (like ppc64 and riscv64) or > was previously supported and is currently broken (like alpha and hppa). > > The attached patch enables building with clisp on all unsupported > architectures. Any chance we can get this implemented for the next upload? FWIW, sbcl builds fine for me on mipsel if clang is used as the C compiler, I'll file a separate bug report for that. 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#955491: puppet-agent: incorrect mkdir path in rbconfig.rb
Package: puppet-agent Version: 6.12.0-1buster Severity: normal Dear Maintainer, puppet-agent's bundled rbconfig.rb contains the following line: CONFIG["MAKEDIRS"] = "/usr/bin/mkdir -p" however there is no /usr/bin/mkdir on a clean Debian system; mkdir resides in /bin only. This configuration results in failed build of native Ruby gems, which use mkmf: mkmf generates the following line into the native Ruby gem Makefile: MAKEDIRS = /usr/bin/mkdir -p Following use of such $MAKEDIRS value results in failed installation, e.g. for the msgpack gem: make "DESTDIR=" install make: /usr/bin/mkdir: Command not found make: *** [Makefile:200: .sitearchdir.-.msgpack.time] Error 12 make install failed, exit code 2 The behavior can be verified on your system by running /opt/puppetlabs/puppet/bin/gem install --no-document msgpack My ruby experience level is low, however based on the above I recommend to fix the value of CONFIG["MAKEDIRS"] in rbconfig.rb. This would avoid the failed builds of native gems/extensions. Thank you for handling this issue. Best regards Radek Zajic -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/28 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages puppet-agent depends on: ii findutils 4.6.0+git+20190209-2 ii tar1.30+dfsg-6 puppet-agent recommends no packages. puppet-agent suggests no packages. -- Configuration Files: /etc/puppetlabs/puppet/puppet.conf changed [not included] -- no debconf information
Bug#955490: libvirt-daemon: ERROR internal error: child reported (status=125): Kernel does not provide mount namespace: Permission denied
Package: libvirt-daemon Version: 6.0.0-4 Severity: grave Tags: a11y Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? sudo virt-install \ -n vm1 \ -r 512 \ --vcpus=2 \ --os-variant=debiantesting \ --disk /var/lib/libvirt/images/vm1.img,size=2 \ --nographics \ -l http://ftp.debian.org/debian/dists/testing/main/installer-amd64/ \ -x console=ttyS0,115200 * What exactly did you do (or not do) that was effective (or ineffective)? Launch above command * What was the outcome of this action? Below error: ERRORinternal error: child reported (status=125): Kernel does not provide mount namespace: Permission denied * What outcome did you expect instead? A success message confirming I'm able to install the Virtual Machine *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-daemon depends on: ii libblkid1 2.34-0.1 ii libc6 2.30-2 ii libcap-ng0 0.7.9-2.1+b2 ii libdbus-1-3 1.12.16-2 ii libdevmapper1.02.1 2:1.02.167-1+b1 ii libfuse22.9.9-3 ii libgcc-s1 10-20200324-1 ii libglib2.0-02.64.1-1 ii libnetcf1 1:0.2.8-1+b3 ii libparted2 3.3-4 ii libpcap0.8 1.9.1-2 ii libpciaccess0 0.14-1 ii libselinux1 3.0-1+b1 ii libudev1244.3-1 ii libvirt-daemon-driver-qemu 6.0.0-4 ii libvirt06.0.0-4 ii libxml2 2.9.10+dfsg-4 Versions of packages libvirt-daemon recommends: ii libvirt-daemon-driver-lxc 6.0.0-4 ii libvirt-daemon-driver-vbox 6.0.0-4 ii libvirt-daemon-driver-xen 6.0.0-4 ii libxml2-utils 2.9.10+dfsg-4 ii netcat-openbsd 1.206-1 ii qemu-kvm1:4.2-3 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 6.0.0-4 pn numad -- debconf-show failed
Bug#952026: More information
I debugged this case and looked into the FTBFS of ruby-handlebas-assets. I checked out the upstream git repository and it tests just fine even when I raise the haml and rake gem versions to match the ones in Debian. But it fails with exactly the same error if I replace the javascript files in vendor/assets/javascript by the javascript files provided by libjs-handlebars. So there seems to be some incompatbility or difference with these files actually causing the build issue (and I don't believe it's the version difference of 4.7.2 vs 4.7.3). Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#955058: speedcrunch: FTBFS with Sphinx 2.4: Could not import extension qtkeyword (exception: No module named 'sphinxcontrib')
Hi Felix! On Sat, Mar 28, 2020 at 01:18:37PM -0400, Sandro Tosi wrote: > > On Sat, Mar 28, 2020 at 05:40:05PM +0100, Felix Krull wrote: > > > I do have a question: this is caused by the qthelp builder being > > > deprecated and moved to sphinxcontrib (but with a shim in the main > > > package). Are there existing plans to package > > > https://github.com/sphinx-doc/sphinxcontrib-qthelp or do I need to > > > take care of it myself? > > > > Either I or Sandro (CCed) will take care of it soon. > > yep i'll take care of it It is now available in experimental: https://tracker.debian.org/pkg/sphinxcontrib-qthelp -- Dmitry Shachnev signature.asc Description: PGP signature
