Bug#955277: buster-pu: package mini-buildd/1.0.36
Hi Adam, On Sun, 2020-11-22 at 18:30 +, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > Hi, > > Apologies for having somehow missed your earlier reply. > > On Tue, 2020-04-28 at 08:51 +0200, Stephan Sürken wrote: (...) > Please go ahead. thx, uploaded now. I guess my new year's resolution now is to skip all mail filters, as I also failed to see your reply for ~2 month ;). Hth, S signature.asc Description: This is a digitally signed message part
Bug#979866: knxd FTBFS everywhere: autoconf issues
Source: knxd
Version: 0.14.41-1
Severity: serious
Tags: ftbfs
knxd fails to build from source for all attempted architectures on the
buildds. A build log usually ends with:
|dh_autoreconf -a
| find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} + -o -type l -printf "symlink %p
| " > debian/autoreconf.before
| grep -q ^XDT_ configure.ac
| autoreconf -f -i
| configure.ac:30: error: AC_INIT should be called with package and version
arguments
| /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
| configure.ac:30: the top level
| autom4te: /usr/bin/m4 failed with exit status: 1
| aclocal: error: /usr/bin/autom4te failed with exit status: 1
| autoreconf: aclocal failed with exit status: 1
| find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} + -o -type l -printf "symlink %p
| " > debian/autoreconf.after
| dh_autoreconf: error: autoreconf -f -i returned exit code 1
| make: *** [debian/rules:14: build-arch] Error 25
Could this be related to autoconf 2.70?
Helmut
Bug#979867: vilistextum FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck
Source: vilistextum Version: 2.6.9-1.4 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs vilistextum fails to cross build from source, because it fails running tests despite DEB_BUILD_OPTIONS=nocheck. They're actually run twice - once via dh_auto_build and once via dh_auto_test. The default target happens to depend on the check target. While dh_auto_test honours DEB_BUILD_OPTIONS=nocheck, dh_auto_build doesn't expect to run a test suite. I suggest updating the upstream Makefiles to decouple these. Doing so makes vilistextum cross buildable. Please consider applying the attached patch. Helmut --- vilistextum-2.6.9.orig/tests/Makefile.am +++ vilistextum-2.6.9/tests/Makefile.am @@ -16,5 +16,3 @@ test: check -all: check -
Bug#979548: u-boot: Package Xen build
On Thu, Jan 07, 2021 at 11:34:44PM -0800, Vagrant Cascadian wrote: > This doesn't describe how to use it or, importantly, what files we would > need to ship in the package. If you could help clarify that (possibly > provide a patch), and ideally get it clarified in the upstream > documentation, then I would think we would be able to ship such a > package. I think 2 or 3 files would be useful to ship in such a package. First would be "u-boot.bin" or whatever the output filename is. Second might be a README mentioning the 3 values needing to be set in a domu.cfg file. Third might be a /etc/xen/xlexample.u-boot file. The 3 values which need to be set in the domain configuration file are: kernel = "/usr/lib/u-boot/xen/u-boot.bin" # ramdisk = # extra = Mainly the "ramdisk" and "extra" settings should be left unset, while "kernel" points at the U-Boot image. A /etc/xen/xlexample.u-boot would be a copy of Xen's /etc/xen/xlexample.pvlinux with the 3 values set appropriately. Then https://wiki.debian.org/Xen should be adjusted to mention U-Boot being available to boot user domains for Xen. In fact I'm trying to find out whether Xen/U-Boot can load OSes besides Linux. Note, this is presently theory as src:u-boot has a problematic set of package requirements. Presently libfdt-dev doesn't allow installation of multiple architecture versions. My build VM is setup to target Xen which needs the host package, while the u-boot build needs the build package. Grr! -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#979865: m2crypto FTBFS on IPV6-only buildds
Source: m2crypto
Version: 0.37.1-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/fetch.php?pkg=m2crypto=amd64=0.37.1-1=1610432018=0
...
I: pybuild base:232: cd /<>/.pybuild/cpython3_3.9_m2crypto/build;
python3.9 -m pytest tests
= test session starts ==
platform linux -- Python 3.9.1+, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
rootdir: /<>
collected 374 items
tests/test_aes.py [ 1%]
tests/test_asn1.py [ 3%]
tests/test_authcookie.py ... [ 8%]
tests/test_bio.py ...[ 17%]
tests/test_bio_file.py ... [ 19%]
tests/test_bio_iobuf.py [ 21%]
tests/test_bio_membuf.py .. [ 24%]
tests/test_bio_ssl.py ...[ 26%]
tests/test_bn.py ... [ 27%]
tests/test_dh.py .. [ 28%]
tests/test_dsa.py ...[ 31%]
tests/test_ec_curves.py .. [ 32%]
tests/test_ecdh.py ... [ 32%]
tests/test_ecdsa.py ... [ 34%]
tests/test_engine.py .. [ 36%]
tests/test_err.py . [ 36%]
tests/test_evp.py .. [ 51%]
[ 53%]
tests/test_obj.py .. [ 54%]
tests/test_rand.py ..[ 56%]
tests/test_rc4.py .. [ 56%]
tests/test_rsa.py .. [ 63%]
tests/test_smime.py .[ 69%]
tests/test_ssl.py ...s..F..F...FFF.F.FFs.F.. [ 83%]
... [ 84%]
tests/test_ssl_offline.py . [ 86%]
tests/test_threading.py .. [ 86%]
tests/test_timeout.py ...[ 90%]
tests/test_util.py [ 92%]
tests/test_x509.py ... [100%]
=== FAILURES ===
__ HttpslibSSLSNIClientTestCase.test_IP_call ___
self =
def test_IP_call(self):
no_exception = True
runs_counter = 0
pid = self.start_server(self.args)
for entry in socket.getaddrinfo(self.srv_host, self.srv_port,
socket.AF_INET,
socket.SOCK_STREAM,
socket.IPPROTO_TCP):
ipfamily, socktype, _, _, sockaddr = entry
ip = sockaddr[0]
sock = socket.socket(ipfamily, socktype)
conn = SSL.Connection(self.ctx, sock=sock)
conn.set_tlsext_host_name(self.srv_host)
conn.set1_host(self.srv_host)
runs_counter += 1
try:
conn.connect((ip, self.srv_port))
except (SSL.SSLError, socket.error):
log.exception("Failed to connect to %s:%s", ip, self.srv_port)
no_exception = False
finally:
conn.close()
out, _ = self.stop_server(pid)
> self.assertEqual(
out.count('Hostname in TLS extension: "%s"' % self.srv_host),
runs_counter)
E AssertionError: 0 != 2
tests/test_ssl.py:306: AssertionError
...
=== 29 failed, 343 passed, 2 skipped, 5 warnings in 77.18s (0:01:17) ===
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.9_m2crypto/build; python3.9 -m pytest tests
rm -fr -- /tmp/dh-xdg-rundir-3bUiHX0w
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9
returned exit code 13
make: *** [debian/rules:17: build-arch] Error 25
Bug#978066: pmix: breaks openmpi autopkgtest
Control: reopen -1 pmix/4.0.0-2 from unstable still causes the autopkgtests of openmpi 4.0.5-7 in testing to fail If it is not intended that this combination should work together, please add Breaks: libopenmpi3 (<< 4.1.0-3) or similar to libpmix2.
Bug#974779: [Pkg-julia-devel] Bug#974779: Bug#974779: closed by Debian FTP Masters (reply to Gianfranco Costamagna ) (Bug#974779: fixed in l
On Tue, 12 Jan 2021, Graham Inggs wrote: > Well Julia still needs to upgrade to llvm-toolchain-11 for bookworm, > so I suggest to leave this bug open until then. Ok, taht is fine - I am currently working on 1.6.0-beta1 and hope that it builds fine with llvm11. That would be after release, though. Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#979864: stepic: Stepic incorrectly handles non-latin texts and binary data
Package: stepic Version: 0.5.0-1 Severity: normal Tags: l10n upstream Dear Maintainer, I've tried to use stepic command line script to hide some Cyrillic text in UTF-8 inside a PNG image, and found out that if stepic correctly encodes it (and this text is decoded by older Python2 based version of Stepic from ubuntu xenial), it fails to decode non-ascii text. It seems that stepic interprets bytes extracted from image as ISO8859-1 text and converts them to utf-8 before outputing to stdout or writing to output file. Moreover, it does so regardless of current locale settings. i have to "convert" stepic output "from utf-8" "to iso8859-1" with iconv to get correct UTF-8 text. I think that at least when writing output to file stepic should write bytes extactly as they were extracted from image for they might be some binary data such as encrypted text. It is better to not do any encoding conversion event when writing to stdout. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.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 stepic depends on: ii python3 3.7.3-1 ii python3-pil 5.4.1-2+deb10u2 stepic recommends no packages. stepic suggests no packages. -- no debconf information
Bug#974779: [Pkg-julia-devel] Bug#974779: Bug#974779: closed by Debian FTP Masters (reply to Gianfranco Costamagna ) (Bug#974779: fixed in l
On Tue, 12 Jan 2021 at 01:15, Norbert Preining wrote: > So I would like to know what remains to be done form my side? Well Julia still needs to upgrade to llvm-toolchain-11 for bookworm, so I suggest to leave this bug open until then.
Bug#979863: copyright need to update to 2021 year
Source: debian-reference Version: 2.77 Severity: wishlist Tags: patch suggest copyright info update to 2021 year in 2.77 copyright.txt update to 2021 year diff --git a/asciidoc/copyright.txt b/asciidoc/copyright.txt index 1178397..df54d2e 100644 --- a/asciidoc/copyright.txt +++ b/asciidoc/copyright.txt @@ -3,7 +3,7 @@ - 2013-2018 + 2013-2021 Osamu Aoki -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.5-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN:zh (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled commit e9279ff234e4e0c2f667b87767f959a500698d86 Author: xiao sheng wen Date: Tue Jan 12 11:49:39 2021 +0800 copyright.txt update to 2021 year diff --git a/asciidoc/copyright.txt b/asciidoc/copyright.txt index 1178397..df54d2e 100644 --- a/asciidoc/copyright.txt +++ b/asciidoc/copyright.txt @@ -3,7 +3,7 @@ - 2013-2018 + 2013-2021 Osamu Aoki
Bug#979135: chromium: GPU hw-accel: ANGLE libs cause a lot of errors and warnings
With chromium version 87.0.4280.141-0.1 installed I have commented now in /etc/chromium.d/default-flags... ##export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --use-gl=desktop" ...and desktop GL implementation is used as foreseen. How can I switch back to ANGLE libs? Just curious. export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --use-gl= ??? " Thanks. - Sedat - On Sat, Jan 9, 2021 at 10:15 AM Jan Luca Naumann wrote: > > The reason I prefer at the moment the way to change the order in the > code is that there it is checked if the desktop implementation is an > allowed choice. I do not know what the behavior would be if this is not > a valid choice for some case but we use the command line flag. > > The patch still allows to use "--use-gl=" in > /etc/chromium.d/default-flags if people want to use something else for > their installation. > > Best, > Jan > > Am 09.01.21 um 08:03 schrieb Sedat Dilek: > > Hi, > > > > Jan Luca is working on a patch "Use desktop gl implementation as default"... > > > > What about placing "--use-gl=desktop" in /etc/chromium.d/default-flags > > as an alternative? > > > > # Default for GPU hardware-acceleration (Debian bug #979135) > > export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --use-gl=desktop" > > > > Cannot say if this is wanted behaviour - to enable GPU hw-accel by default? > > Looks like a safer methon when GPU hw-accel is wanted. > > > > In my logs I found references to Skia renderer... > > > > [ chrome://flags ] > > > > Skia API for compositing > > If enabled, the display compositor will use Skia as the graphics API > > instead of OpenGL ES. – Mac, Windows, Linux, Android > > Here set to "Default" > > > > [ chrome://gpu ] > > Graphics Feature Status > Skia Renderer: Enabled > > > > Cannot judge when not using ANGLE libs if there is a fallback to OpenGL ES. > > Might be OpenGL ES renderer is the better choice? > > > > I have not looked for the parameters and cannot say I will play with them. > > > > ( BTW, I played with Vulkan support enabled - slow performance here > > with Intel Sandy Bridge GPU. ) > > > > Regards, > > - Sedat - > > > > [1] https://salsa.debian.org/janluca-guest/chromium/-/commits/angle_fix > > [2] https://wiki.archlinux.org/index.php/chromium#Force_GPU_acceleration > > [3] > > https://wiki.archlinux.org/index.php/chromium#Hardware_video_acceleration > > >
Bug#941801: cups update in asciidoc branch is not sync to master
Control: reopen -1 Hi, https://www.debian.org/doc/manuals/debian-reference/ch06.en.html#_the_print_server_and_utilities is still old, it's not update to the asciidoc branch. I'd see this commit in asciidoc branch, but it's update is not sync to rawxml in the master branch. commit 88d4fc28fa47cf178607da98865afaa150e9f3ef Author: Osamu Aoki Date: Sat Jan 9 16:14:41 2021 +0900 Update printing for post-CUPS 1.6 Closes: #941801 Can run the following step to sync them? git checkout asciidoc make debian-reference.rawxml git checkout master cp debian-reference.rawxml rawxml/ make test -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》https://www.atzlinux.com 基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB OpenPGP_0x00186602339240CB.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co
> Can simply replacing the dependency in all of them with bbolt work? I don't know myself, but some upstream think it's not a trivial change. For example, see: https://github.com/hashicorp/raft-boltdb/pull/19#issuecomment-703732437 In short: hashicorp-raft-boltdb wants to make sure there's no issue before making the change. This change would impact reverse build deps of hashicorp-raft-boltdb, like nomad or consul. I think it's better to downgrade the severity here (as was done in coreos-bbolt, see https://bugs.debian.org/976926).
Bug#748631: apt-listchanges: add a sanitise mode
Control: retitle -1 apt-listchanges: add a sanitise mode
Control: severity -1 normal
Control: tags -1 - moreinfo
Hey.
I've finally been so annoyed by this, that I've manually fixed it. ;-D
Anyone who suffers from a similar problem can solve it with something
like:
$ python3
Python 3.9.1+ (default, Jan 10 2021, 15:42:50)
[GCC 10.2.1 20201224] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from dbm import ndbm
>>> db=ndbm.open("/pathToList/listchanges", 'w')
>>> print(db["lvm2"])
b'2:1.02.48-2'
>>> db["lvm2"] = b'2.03.10-1'
>>> print(db["util-linux"])
b'1:2.17.2-3.1'
>>> db["util-linux"] = b'2.36.1-4'
>>> db.close()
>>>
That is, resetting the seen versions to what's actually installed on
the system.
/pathToList/listchanges (sic! - no .db, apparently) is typically
"/var/lib/apt/listchanges".
Make a backup in advance!
1) As for that,... there really should be a --sanitise option or so,
which takes the db and for every entry in it sets the seen version to
the one currently installed.
2) Maybe there should be even something like --garbage-collect, which
removes any seen entries for which the package no longer .
Well, what should be?
a) Just taking packages no longer installed (locally) would be one way,
but maybe people would re-install them later and still skip the already
seen changes.
b) Perhaps any package which can no longer be found in the currently
configured repos?
Ideally, the user could choose, and would be presented with a list of
all entries to be removed, which he can then either take all, or
selectively walk through.
Cheers,
Chris.
Bug#974207: psi-plus: FTBFS with Qt 5.15
Package: psi-plus
Version: 1.4.554-4
Followup-For: Bug #974207
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch
Hi,
In Ubuntu, the attached patch was applied to achieve the following:
* d/p/qt-5.15.patch: Explicitly include QPainterPath to fix FTBFS with Qt
5.15.
Thanks for considering the patch.
Logan
diff -Nru psi-plus-1.4.554/debian/patches/qt-5.15.patch
psi-plus-1.4.554/debian/patches/qt-5.15.patch
--- psi-plus-1.4.554/debian/patches/qt-5.15.patch 1969-12-31
19:00:00.0 -0500
+++ psi-plus-1.4.554/debian/patches/qt-5.15.patch 2021-01-11
22:20:22.0 -0500
@@ -0,0 +1,51 @@
+--- a/src/plugins/generic/screenshotplugin/screenshot.cpp
b/src/plugins/generic/screenshotplugin/screenshot.cpp
+@@ -32,6 +32,7 @@
+ #include
+ #include
+ #include
++#include
+
+
+ #include "screenshot.h"
+--- a/src/avatars.cpp
b/src/avatars.cpp
+@@ -35,6 +35,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #include "xmpp_xmlcommon.h"
+ #include "xmpp_vcard.h"
+--- a/src/contactlistdragview.cpp
b/src/contactlistdragview.cpp
+@@ -45,6 +45,7 @@
+ #include
+ #include
+ #include
++#include
+
+ ContactListDragView::ContactListDragView(QWidget* parent)
+ : ContactListView(parent)
+--- a/src/rosteravatarframe.cpp
b/src/rosteravatarframe.cpp
+@@ -23,6 +23,8 @@
+ #include "iconset.h"
+ #include "qpainter.h"
+
++#include
++
+
+ RosterAvatarFrame::RosterAvatarFrame(QWidget *parent)
+ : QFrame(parent)
+--- a/src/whiteboarding/wbnewpath.cpp
b/src/whiteboarding/wbnewpath.cpp
+@@ -23,6 +23,7 @@
+ #include "../sxe/sxesession.h"
+
+ #include
++#include
+
+ WbNewPath::WbNewPath(QGraphicsScene* s, QPointF startPos, int strokeWidth,
const QColor , const QColor ) : WbNewItem(s) {
+ controlPoint_ = 0;
diff -Nru psi-plus-1.4.554/debian/patches/series
psi-plus-1.4.554/debian/patches/series
--- psi-plus-1.4.554/debian/patches/series 2020-02-25 19:49:20.0
-0500
+++ psi-plus-1.4.554/debian/patches/series 2021-01-11 22:19:52.0
-0500
@@ -2,3 +2,4 @@
fix-autoscroll-in-chats.patch
send-unavailable-presence-on-program-exit.patch
change-omemo-initialization-vector-length.patch
+qt-5.15.patch
Bug#978070: src:roundcube: LESS-generated code installed only compressed, unlike other CSS code
Control: reopen -1 Control: tag -1 pending On Fri, 25 Dec 2020 at 15:51:01 +0100, Guilhem Moulin wrote: > This is deliberate: we ship the source (LESS or un-minified CSS) and the > generated minified CSS. Also IIRC Roundcube won't prefer the .min.css > over the .css in this case, and only load the .css. On closer look these days this is only true for embed.css; embed.min.css is never requested, but for other files the client does request the .min.css. So I changed my mind and will apply your suggestion with the next upload :-) Thanks for the poke! -- Guilhem. signature.asc Description: PGP signature
Bug#979856: linux-image-5.10.0-1-amd64: 5.10.0-1 kernel does not have the AMDGPU 'DCN 3.0 family' option turned on for Navi 21 support
Package: src:linux Version: 5.10.4-1 Severity: critical Tags: patch Justification: breaks the whole system X-Debbugs-Cc: ago_debian...@protonmail.com It would seem that this kernel build was compiled without DCN 3.0 Support enabled in the config, which means that upon boot my system with an AMD Radeon 6900XT has no video output - not even trying to open a new TTY works. I can SSH into the machine, but it auto-reboots after a short while, rendering the system unusable. Compiling the package with this option enabled in menuconfig fixes the issue: Device Drivers>Graphics Support>AMD GPU/Display Engine Configuration>DCN 3.0 family -- Package-specific info: ** Kernel log: Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (++) using VT number 1 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) systemd-logind: took control of session /org/freedesktop/login1/session/c2 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) xfree86: Adding drm device (/dev/dri/card0) Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 14 paused 0 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (--) PCI:*(47@0:0:0) 1002:73bf:1002:0e3a rev 192, Mem @ 0x78/17179869184, 0x7c/2684> Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) LoadModule: "glx" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Loading /usr/lib/xorg/modules/extensions/libglx.so Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Module glx: vendor="X.Org Foundation" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: compiled for 1.20.10, module version = 1.0.0 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: ABI class: X.Org Server Extension, version 10.0 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) LoadModule: "amdgpu" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Module amdgpu: vendor="X.Org Foundation" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: compiled for 1.20.9, module version = 19.1.0 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: Module class: X.Org Video Driver Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: ABI class: X.Org Video Driver, version 24.1 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) AMDGPU: Driver for AMD Radeon: Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: All GPUs supported by the amdgpu kernel driver Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) AMDGPU(0): Creating default Display subsection in Screen section Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: "Default Screen Section" for depth/fbbpp 24/32 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (==) AMDGPU(0): Default visual is TrueColor Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (**) AMDGPU(0): Option "VariableRefresh" "true" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (==) AMDGPU(0): RGB weight 888 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) AMDGPU(0): Using 8 bits per RGB (8 bit DAC) Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID = 0x73bf) Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Loading sub module "fb" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) LoadModule: "fb" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Loading /usr/lib/xorg/modules/libfb.so Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Module fb: vendor="X.Org Foundation" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: compiled for 1.20.10, module version = 1.0.0 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: ABI class: X.Org ANSI C Emulation, version 0.4 Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Loading sub module "dri2" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) LoadModule: "dri2" Jan 11 22:19:45 snorlax /usr/libexec/gdm-x-session[1149]: (II) Module "dri2" already built-in Jan 11 22:19:45 snorlax pipewire[1025]: [E][6.810992][core.c:71 core_event_error()] core 0x55880d9c1930: proxy 0x55880da103d0 id:4: bound:-1 seq:4 re> Jan 11 22:19:45 snorlax pipewire[1025]: [E][6.810999][media-session.c:1971 core_error()] error id:4 seq:4 res:-2 (No such file or directory): can't c>
Bug#979862: fp-compiler-3.2.0+dfsg-9 error when installing
Package: fp-compiler-3.2.0
Version: 3.2.0+dfsg-9
Severity: important
Tags: patch
X-Debbugs-Cc: serfyo...@yandex.ru
Dear Maintainer,
Packet:
fp-compiler-3.2.0_3.2.0+dfsg-9_amd64.deb
control.tar.xz
postinst
line
--slave ${MAN_DIR}/fpcres.1.gz fpcres.1.gz ${MAN_DIR}/fpcres-3.2.0.1.gz
must be
--slave ${MAN_DIR}/fpcres.1.gz fpcres.1.gz ${MAN_DIR}/fpcres-3.2.0.1.gz
\
otherwise the next line
--slave ${MAN_DIR}/fpcmkcfg.1.gz fpcmkcfg.1.gz
${MAN_DIR}/fpcmkcfg-3.2.0.1.gz
is not executed and the installation of the package gives an error.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fp-compiler-3.2.0 depends on:
ii binutils 2.35.1-7
ii debconf [debconf-2.0] 1.5.74
ii fp-units-rtl-3.2.0 3.2.0+dfsg-9
ii libc6 2.31-9
Versions of packages fp-compiler-3.2.0 recommends:
ii fp-utils-3.2.0 3.2.0+dfsg-9
Versions of packages fp-compiler-3.2.0 suggests:
ii fp-docs-3.2.0 3.2.0+dfsg-9
-- debconf information:
fp-compiler/rename_cfg: true
fp-compiler/windres-select: Select manually
fp-compiler/windres: Select manually
Bug#979156: [pkg-php-pear] Bug#979156: Useless in Debian
Thanks. Sure, let me look it and get back. Thanks Rajasekhar On 11/01/21 6:54 am, Sunil Mohan Adapa wrote: > Added CC: Rajasekhar Ponakala > > On 10/01/21 3:58 pm, Guilhem Moulin wrote: >> Hi all, >> >> On Sun, 03 Jan 2021 at 16:54:41 -0800, Sunil Mohan Adapa wrote: >>> I will be filing an RM: bug on the package on Jan 10, 2021. I will >>> wait to see if the other uploaders think it is still needed. >> Roundcube's test suite which I'm working on now has some tests making >> use of Net_IDNA2 so I'd like to keep the package around if possible :-) >> I can give a hand and help bringing it up to shape for Bullseye. >> > I found a migrated repository that seem have to done some work to import > the latest upstream version[1]. Recent most commits incorrectly > overwrote the upstream source with another package's source. Some > reverting and testing should get the package in shape. I can help if needed. > > Links: > 1) https://salsa.debian.org/php-team/pear/php-net-idna2/ > > Thanks, >
Bug#979861: ITP: uwebsockets-dev -- simple, secure & standards compliant web server
Package: wnpp Severity: wishlist Owner: Aisha Tammy X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: uwebsockets-dev Version : 18.19.0 Upstream Author : Alex Hultman * URL : https://github.com/uNetworking/uWebSockets * License : Apache-2.0 Programming Lang: C++ Description : simple, secure & standards compliant web server uWebSocket (it's "micro") is simple, secure & standards compliant web server for the most demanding of applications.
Bug#979860: ITP: purritobin -- ultra fast, minimalistic, encrypted command line paste-bin
Package: wnpp Severity: wishlist Owner: Aisha Tammy X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: purritobin Version : 0.3.3 Upstream Author : Aisha Tammy * URL : https://bsd.ac/ * License : ISC Programming Lang: C++ Description : ultra fast, minimalistic, encrypted command line paste-bin Purrito Bin is an ultra fast, minimalistic, encrypted command line paste-bin server written in C++ for handling large number of requests. It is very easy to integrate with any standard http server such as httpd(8), apache or nginx and follows the KISS principle towards handling pastes.
Bug#979750: transition: skalibs execline s6
Hi, On Mon, Jan 11, 2021 at 11:33 AM Shengjing Zhu wrote: > > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: z...@debian.org > > Hi, > > Skarnet.org softwares just released a new version today... > > http://skarnet.org/cgi-bin/archive.cgi?1:mss:1515:202101:mhcdpginfgieagphalne > > I have packaged three of them, which are skalibs, execline and s6. > > They both have SO bump this time. There's no reverse depend except for > themselves. > > I have uploaded them to experimental, and still wait for the NEW queue. > Can this be warranted for the "Soft Freeze" deadline as no other > packages are involved. > They have been cleared from the NEW queue. Do you consider it a transition or not? -- Shengjing Zhu
Bug#979859: libvirt0: Starting virtual pc with virtManager cause raise libvirtError setCpusetMemoryMigrate' not supported
Package: libvirt0
Version: 5.0.0-4+deb10u1
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Starting any virtual pc with virtManager
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
Error report VirtManager:
Fehler beim Starten der Domain: Operation not supported: operation
'setCpusetMemoryMigrate' not supported
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66,
in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in
startup
self._backend.create()
File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: Operation not supported: operation
'setCpusetMemoryMigrate' not supported
* What outcome did you expect instead?
Just starting the VM like day before.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 10.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.6 (SMP w/12 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libvirt0 depends on:
ii libacl1 2.2.53-4
ii libapparmor12.13.2-10
ii libaudit1 1:2.8.4-3
ii libavahi-client30.7-4+b1
ii libavahi-common30.7-4+b1
ii libc6 2.28-10
ii libcap-ng0 0.7.9-2
ii libcurl3-gnutls 7.64.0-4+deb10u1
ii libdbus-1-3 1.12.20-0+deb10u1
ii libdevmapper1.02.1 2:1.02.155-3
ii libgcc1 1:8.3.0-6
ii libgnutls30 3.6.7-4+deb10u5
ii libnl-3-200 3.4.0-1
ii libnl-route-3-200 3.4.0-1
ii libnuma12.0.12-1
ii libsasl2-2 2.1.27+dfsg-1+deb10u1
ii libselinux1 2.8-1+b1
ii libssh2-1 1.8.0-2.1
ii libxml2 2.9.4+dfsg1-7+deb10u1
ii libyajl22.1.0-3
Versions of packages libvirt0 recommends:
ii lvm2 2.03.02-3
libvirt0 suggests no packages.
-- no debconf information
Bug#932054: bug reply
rspamd default configuration file contains a set of RBL servers, links to different phishing/spamming feeds, public ASN lookup server, fuzzy hashes server, etc. All the data is refreshed with regular intervals. https://github.com/rspamd/rspamd/blob/master/conf/modules.d/rbl.conf https://github.com/rspamd/rspamd/blob/master/conf/modules.d/phishing.conf https://github.com/rspamd/rspamd/blob/master/conf/modules.d/asn.conf https://github.com/rspamd/rspamd/blob/52a281c58f31ba48e1d365c1646321747be501ff/conf/modules.d/fuzzy_check.conf#L21 OpenPGP_signature Description: OpenPGP digital signature
Bug#943462: [polkit-kde-agent-1] Fails to start with elogind
severity 943462 normal tags 943462 + moreinfo unreproducible thanks Hi Alex, On Wed, 23 Dec 2020, Norbert Preining wrote: > This is for a very old version of Plasma. Could you please try the > current 5.20.4 from unstable. Since we didn't get any feedback from your side about whether this is reproducible with current Plasma, I am adjusting severity and tagging the bug accordingly. Thanks for your understanding Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#942078: [high quality bug] baloo crash, can't recover; forced reindex does not fix; unusable via dolphin C-f
severity 942078 normal tags 942078 + moreinfo unreproducible thanks Hi Nicholas, I cannot reproduce this, nor anyone else in the team, and you haven't given an update to whether this is reproducible or not on your side. I thus downgrade this bug and tag it appropriately. Thanks for your understanding Norbert On Wed, 23 Dec 2020, Norbert Preining wrote: > Can you reproduce this with current frameworks 5.77 in unstable? > > Does it always crash at the same file (jack_capture_90.mp3) or always in > different files? -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#979612: 78.6.1esr-1~deb10u1 issues / wonky behavior and security concern.
Strange and unexpected behavior of the gnome ui continued since firefox-exr ver: 78.6.1esr-1~deb10u1 got pulled in and installed from debian repositories via apt. Most obvious issue was the random glitch with sudden inability to move applications around the screen by grabbing top bar with the mouse. Random loss of ability to close / quit applications using normal exit dialog, for example if chromuim or gedit confirming exit when more than one tab is opened or if a user wants to save changes if such where made before exit. Dialog is prompted but clicking produces no action and dialog window just stays on the screen. Using a 'TAB' button on the keyboard followed by the 'enter' button on the keyboard closes an application as expected. So this bug seems to have something to do with the mouse clicks interpretations in the gonme UI. Multiple applications are affected ranging from wonky behavior of gnome terminal, to chromium and tor browser. All related to managing application in UI with the mouse. To stop all of this from happening I had to do the following: downgrade firefox-esr. And here comes next unexpected and strange issue. Last know version that worked with out messing up gnome ui on my host was a firefox-esr ver: 76.6.0esr-1~deb10u1 However (howeva!), when checking against debian repository servers, turns out this version is no longer available. ;( bummer. Instead, an older version available - 78.5.0esr-1~deb10u1 It is what is is, so here we go, that's what i had to do: 1. Elevate your user privileges or use sudo. 2. Check (ask) via apt what options do I have by quavering the following: # apt policy firefox-esr Examine the answer and look for the proper naming schema for firefox-esr versions. firefox-esr: Installed: 78.6.1esr-1~deb10u1 Candidate: 78.5.0esr-1~deb10u1 Version table: 78.6.1esr-1~deb10u1 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages *** 78.5.0esr-1~deb10u1 500 500 http://deb.debian.org/debian buster/main amd64 Packages 100 /var/lib/dpkg/status In this output its clear I need version '78.5.0esr-1~deb10u1' 3. Okie-dokie, let's do it... instruct apt do pull down the older version, override the currently installed version - effectively downgrading the firefox-esr by issuing the following instruction to apt: # apt install firefox-esr=78.5.0esr-1~deb10u1 Confirm to apt that yes, that's what has to happened. Once this done, I logged out my user session in gnome, logged back in... and for the past 12 hours everything is running as expected with no issues. QUESTION (!) If some one from Debian security team can chime in and comment on the following: When I submitted this ticket for a potential bug with the firefox-esr: 78.6.1esr-1~deb10u1 I used 'reportbug' package. Ok, details provided and right before I submitted it, 'reportbug' package collected basic info about my host and this has cut my attention. In the report there is a section labeled '-- Extensions information' With in that section it appears a reference to a file in my system: Location: /usr/lib/firefox-esr/browser/omni.ja I have checked and yes, this file is present in my Debian instance and yes, with in this file there is amazon. bing, google all mentioned. Question, what is that, why is it in there, and why hasn't anyone disclosed it to a user before integrating it to a code? I do not want anything in my Debian instance having anything to do with dose platforms. It would be very reassuring if some one independent of Mozilla, like Debian security team to comment and perhaps clarify the purpose of those 'extensions' I have never installed and yet according to this info, they are present AND enabled in my system somehow. I have checked and Firefox normal GUI settings do not show anything remotely like that. Aiy Dios Mio! Karramba!!! Please, someone... what is this??? Damien
Bug#979823: catch2: diff for NMU version 2.13.4-1.1
On Mon, Jan 11, 2021 at 07:27:24PM +0100, Tobias Frost wrote: Dear maintainer, Hi Tobias, I've prepared an NMU for catch2 (versioned as 2.13.4-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks for fixing this! However I noticed a bug in version 2.13.4-1 and I am preparing a new upload. We can keep the NMU, but the new upload will render it moot. Cheers, -- Mathieu Mirmont signature.asc Description: PGP signature
Bug#979858: ITP: golang-github-henvic-httpretty -- Prints HTTP requests made with Go pretty on your terminal
Package: wnpp Severity: wishlist Owner: Joao Paulo Lima de Oliveira X-Debbugs-Cc: debian-de...@lists.debian.org, jlima.oliveir...@gmail.com * Package name: golang-github-henvic-httpretty Version : 0.0.6-1 Upstream Author : Henrique Vicente * URL : https://github.com/henvic/httpretty * License : MIT Programming Lang: Go, Shell Description : Prints HTTP requests made with Go pretty on your terminal Prints the HTTP requests of your Go programs pretty on your terminal screen. It is mostly inspired in curl's --verbose mode, and also on the httputil.DumpRequest and similar functions.
Bug#979613: i386 UEFI disk/CDROM image cannot be started on x86_64 host
Control: tags -1 + wontfix I was told that the upstream recognize this as "feature", see https://github.com/virt-manager/virt-manager/issues/209#issuecomment-758128491 Best regards, Ryutaroh
Bug#975861: mercurial: after switching to pytohn3.9 it is 3 times as slow
Hi Julien, Sorry for not replying earlier. On Fri, Jan 8, 2021 at 1:24 PM Julien Cristau wrote: > > Hi Daniel, > [...] > > Can you provide the output of running hg status with the --profile > option, in both the faster and slower cases? There is an error in the command above, the fast case was using "python3.8", the slow case was using "python3.9". I reinstalled python3.8 to test again, but mercurial did not run with python3.8 anymore: $ python3.8 /usr/bin/hg status Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mercurial/policy.py", line 69, in _importfrom fakelocals[modname] = mod = getattr(pkg, modname) File "/usr/lib/python3/dist-packages/mercurial/pycompat.py", line 303, in w return f(object, sysstr(name), *args) AttributeError: module 'mercurial.cext' has no attribute 'parsers' But, I can't reproduce the slowdown anymore using current mercurial and python3.9 versions in unstable, now it is fast again: In an empty repository: $ time /usr/bin/hg status real 0m0.126s user 0m0.113s sys 0m0.013s And with "--profile": $ time /usr/bin/hg status --profile | 100.0% 0.03s dispatch.py:run line 43: dispatch.run() | 100.0% 0.03s dispatch.py:dispatch line 113: status = dispatch(req) | 100.0% 0.03s dispatch.py:_runcatch line 303: ret = _runcatch(req) or 0 | 100.0% 0.03s dispatch.py:_callcatchline 479: return _callcatch(ui, _runc... | 100.0% 0.03s scmutil.py: callcatch line 488: return scmutil.callcatch(ui... | 100.0% 0.03s dispatch.py:_runcatchfunc line 153: return func() | 100.0% 0.03s dispatch.py:_dispatch line 469: return _dispatch(req) \ 33.3% 0.01s hg.py: repositoryline 1183: repo = hg.repository( | 33.3% 0.01s hg.py: _peerorrepo line 221: peer = _peerorrepo( | 33.3% 0.01s util.py:__getattribute__line 188: obj = _peerlookup(path).ins... | 33.3% 0.01s : exec_moduleline245: self.__spec__.loader.exec_m... | 33.3% 0.01s : get_codeline 786: | 33.3% 0.01s : get_dataline 881: \ 33.3% 0.01s extensions.py: loadall line 1043: extensions.loadall(lui) | 33.3% 0.01s extensions.py: loadline 301: load(ui, name, path, loadin... | 33.3% 0.01s pycompat.py:w line 224: minver = getattr(mod, 'mini... | 33.3% 0.01s util.py:__getattribute__line 303: return f(object, sysstr(nam... | 33.3% 0.01s : exec_moduleline245: self.__spec__.loader.exec_m... | 33.3% 0.01s : _call_with_frames_removedline 790: | 33.3% 0.01s __init__.py:line 228: | 33.3% 0.01s : _handle_fromlistline 15: from . import ( | 33.3% 0.01s : _call_with_frames_removedline 1058: | 33.3% 0.01s : _find_and_loadline 228: | 33.3% 0.01s : _find_and_load_unlockedline 1007: | 33.3% 0.01s : _find_specline 982: | 33.3% 0.01s demandimportpy3.py: find_spec line 925: | 33.3% 0.01s : find_specline 111: spec = find_spec(fullname, ... | 33.3% 0.01s : _get_specline 1349: | 33.3% 0.01s : find_specline 1321: | 33.3% 0.01s : _fill_cacheline1450: \ 33.3% 0.01s dispatch.py:runcommandline 1232: return runcommand( | 33.3% 0.01s pager.py: pagecmd line 917: ret = _runcommand(ui, optio... | 33.3% 0.01s dispatch.py:_runcommand line 76: return orig(ui, options, cm... | 33.3% 0.01s dispatch.py:line 1244: return cmdfunc() | 33.3% 0.01s util.py:check line 1230: d = lambda: util.checksigna... | 33.3% 0.01s util.py:check line 1867: return func(*args, **kwargs) | 33.3% 0.01s mq.py: mqcommand line 1867: return func(*args, **kwargs) | 33.3% 0.01s util.py:check line 4222: return orig(ui, repo, *args... | 33.3% 0.01s commands.py:status line 1867: return func(*args, **kwargs) | 33.3% 0.01s scmutil.py: match line 6657: m = scmutil.match(ctx2, pat... | 33.3% 0.01s scmutil.py: matchandpatsline 940: return matchandpats(ctx, pa... | 33.3% 0.01s context.py: match line 922: m = ctx.match( | 33.3% 0.01s util.py:__getattribute__line 1752: return matchmod.match( | 33.3% 0.01s : exec_moduleline245: self.__spec__.loader.exec_m... | 33.3% 0.01s : get_codeline 786: | 33.3% 0.01s : get_dataline 881: --- Sample count: 11 Total time: 0.03 seconds (0.03 wall) real 0m0.133s user 0m0.126s sys 0m0.009s So, you can close the bug. Thanks. Daniel.
Bug#979844: ITP: usockets-dev -- miniscule async eventing, networking & crypto library
Package: wnpp Severity: wishlist Owner: Aisha Tammy X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : usockets-dev Version : 0.6.0 Upstream Author : Alex Hultman * URL : https://github.com/uNetworking/uSockets * License : ( Apache-2.0 ) Programming Lang: (C, C++) Description : miniscule async eventing, networking & crypto library useful library for doing fast socket io it is similar to other socket io libraries but focuses on speed with a high level API
Bug#978994: O: php-dompdf -- HTML to PDF converter
Dear Markus, On Saturday, 2 January 2021 6:50:14 AM AEDT Markus Frosch wrote: > I intend to orphan the php-dompdf package, because I only did partial > uploads for dependencies I maintained, but the only reverse dependency > is now: > > civicrm-common Thanks for your work on "php-dompdf". I'm near my capacity limit but CiviCRM is important so I might have to adopt "php-dompdf" if no one else cares for it. -- Regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- Hay smells different to lovers and horses. -- Stanisław Jerzy Lec --- Bill Gates is a least qualified most influential self-appointed "doctor" in the world. -- Vernon Coleman signature.asc Description: This is a digitally signed message part.
Bug#979063: php-font-lib: Useless in Debian
On Saturday, 2 January 2021 11:39:12 PM AEDT Markus Frosch wrote: > Similar to php-dompdf [1], this package is pretty useless for bullseye, > since it is only needed by php-dompdf, which is not depent on by any > package in testing. > > Only possible candidate would be civicrm [2], which seems not be able to > make it to bullseye. I took care of CiviCRM and I might adopt php-dompdf (and reluctantly php- font-lib) as I intend to continue to look after CiviCRM... -- Regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- Censorship is always cause for celebration. It is always an opportunity because it reveals fear of reform. It means that the power position is so weak that you have got to care what people think. -- Julian Assange --- Covid: The Big Picture in 7 Charts https://swprs.org/covid-the-big-picture-in-7-charts/ signature.asc Description: This is a digitally signed message part.
Bug#979857: Memory corruption and hang in unzip
Hello. I received this today from the Debian bug system. I'm forwarding it to the current maintainer, and also Mark Adler who maintains a fork in github. [ Please keep the 979...@bugs.debian.org address when replying ] Thanks. - Forwarded message from Sirus Sh - Date: Mon, 11 Jan 2021 16:46:43 -0700 From: Sirus Sh To: sub...@bugs.debian.org Subject: Bug#979857: Memory corruption and hang in unzip Package: unzip Version: 6.0-25 During the development and evaluation of our fuzzer, we found multiple bugs in the last version of unzip. I have attached three inputs (in a tar file) that can crash unzip because of these issues: 1- Out of bound read in crc32.c 2- Integer overflow in fileio.c 3- Invalid pointer dereference in process.c 4- Program hangs in extract.c (BZ2_bzDecompress in bzlib.c doesn't return properly). The first crashing input (crash000_opt_a_SIGSEGV) needs "-a" argument to crash the program. If you can get any CVE number to assign to these bugs, please let me know so that we mention the numbers in our paper. Also if you have any question or need to discuss these further, feel free to send me a message. -- Best Regards Sirus Shahini - End forwarded message - zharf_crashes.tgz Description: application/gtar-compressed
Bug#611647: bombardier: diff for NMU version 0.8.3+nmu3
Control: tags 611647 + pending Dear maintainer, I've prepared an NMU for bombardier (versioned as 0.8.3+nmu3) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards. diff -Nru bombardier-0.8.3+nmu2/debian/bombardier.dirs bombardier- 0.8.3+nmu3/debian/bombardier.dirs --- bombardier-0.8.3+nmu2/debian/bombardier.dirs1969-12-31 19:00:00.0 -0500 +++ bombardier-0.8.3+nmu3/debian/bombardier.dirs2021-01-11 18:26:39.0 -0500 @@ -0,0 +1 @@ +var/games/ diff -Nru bombardier-0.8.3+nmu2/debian/bombardier.install bombardier- 0.8.3+nmu3/debian/bombardier.install --- bombardier-0.8.3+nmu2/debian/bombardier.install 2009-10-11 09:03:07.0 -0400 +++ bombardier-0.8.3+nmu3/debian/bombardier.install 1969-12-31 19:00:00.0 -0500 @@ -1,2 +0,0 @@ -usr/share/man/man6/bombardier.6 -usr/games/bombardier diff -Nru bombardier-0.8.3+nmu2/debian/changelog bombardier- 0.8.3+nmu3/debian/changelog --- bombardier-0.8.3+nmu2/debian/changelog 2020-02-20 15:13:46.0 -0500 +++ bombardier-0.8.3+nmu3/debian/changelog 2021-01-11 18:40:39.0 -0500 @@ -1,3 +1,12 @@ +bombardier (0.8.3+nmu3) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: Migrate to dh syntax. + * Makefile: Fix FTBFS with ld.gold. (Closes: #611647) + * Makefile: Also accept external build environment variables. + + -- Boyuan Yang Mon, 11 Jan 2021 18:40:39 -0500 + bombardier (0.8.3+nmu2) unstable; urgency=medium * Non-maintainer upload. diff -Nru bombardier-0.8.3+nmu2/debian/compat bombardier- 0.8.3+nmu3/debian/compat --- bombardier-0.8.3+nmu2/debian/compat 2009-10-10 13:48:52.0 -0400 +++ bombardier-0.8.3+nmu3/debian/compat 1969-12-31 19:00:00.0 -0500 @@ -1 +0,0 @@ -7 diff -Nru bombardier-0.8.3+nmu2/debian/control bombardier- 0.8.3+nmu3/debian/control --- bombardier-0.8.3+nmu2/debian/control2020-02-20 15:13:46.0 -0500 +++ bombardier-0.8.3+nmu3/debian/control2021-01-11 18:36:25.0 -0500 @@ -2,8 +2,10 @@ Section: games Priority: optional Maintainer: RISKO Gergely -Build-Depends: libncurses5-dev, debhelper (>>7) -Standards-Version: 3.8.3.0 +Build-Depends: + debhelper-compat (= 13), + libncurses-dev, +Standards-Version: 4.5.1 Vcs-Browser: https://salsa.debian.org/debian/bombardier Vcs-Git: https://salsa.debian.org/debian/bombardier.git diff -Nru bombardier-0.8.3+nmu2/debian/rules bombardier- 0.8.3+nmu3/debian/rules --- bombardier-0.8.3+nmu2/debian/rules 2020-02-20 09:18:50.0 -0500 +++ bombardier-0.8.3+nmu3/debian/rules 2021-01-11 18:40:39.0 -0500 @@ -1,43 +1,19 @@ #!/usr/bin/make -f -build: build-stamp -build-stamp: - dh_testdir - dh_auto_build - touch build-stamp +export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic -Wno-error=format- security -clean: - dh_testdir - dh_testroot - rm -f build-stamp - $(MAKE) clean - dh_clean +DPKG_EXPORT_BUILDFLAGS = 1 +DPKG_EXPORT_BUILDTOOLS = 1 +include /usr/share/dpkg/default.mk +include /usr/share/dpkg/buildflags.mk +include /usr/share/dpkg/buildtools.mk -install: build - dh_testdir - dh_testroot - dh_prep - dh_installdirs var/games - $(MAKE) install DESTDIR=`pwd`/debian/tmp +%: + dh $@ -binary-indep: build install - -binary-arch: build install - dh_testdir - dh_testroot - dh_install - dh_installdocs - dh_installmenu - dh_installman - dh_installchangelogs - dh_strip - dh_compress +override_dh_fixperms: dh_fixperms -Xgames/bombardier - dh_installdeb - dh_shlibdeps - dh_gencontrol - dh_md5sums - dh_builddeb -binary: binary-indep binary-arch -.PHONY: build clean binary-indep binary-arch binary install +execute_after_dh_auto_install: + # Let postinst handle content + $(RM) -r $(CURDIR)/debian/bombardier/var/games/bombardier diff -Nru bombardier-0.8.3+nmu2/Makefile bombardier-0.8.3+nmu3/Makefile --- bombardier-0.8.3+nmu2/Makefile 2020-02-20 09:13:39.0 -0500 +++ bombardier-0.8.3+nmu3/Makefile 2021-01-11 18:40:33.0 -0500 @@ -3,17 +3,17 @@ # Copyright (C) 2001, 2009 Gergely Risko # Can be licensed under the terms of GPL v3 or above -CC=gcc -CFLAGS=-Wall -g -O2 -pedantic -LDFLAGS=-g +CC ?= gcc +CFLAGS ?= -Wall -g -O2 -pedantic +LDFLAGS ?= -g LIBS=-lncurses OBJS=bombardier.o display.o date.o randomhouse.o step.o hof.o signal.o gcurses.o -DESTDIR=/ +DESTDIR ?= / all: bombardier bombardier: $(OBJS) - $(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) + $(CC) -o $@ $(OBJS) $(LDFLAGS) $(LIBS) clean: rm -f $(OBJS) bombardier signature.asc Description: This is a digitally signed message part
Bug#979857: Memory corruption and hang in unzip
Package: unzip Version: 6.0-25 During the development and evaluation of our fuzzer, we found multiple bugs in the last version of unzip. I have attached three inputs (in a tar file) that can crash unzip because of these issues: 1- Out of bound read in crc32.c 2- Integer overflow in fileio.c 3- Invalid pointer dereference in process.c 4- Program hangs in extract.c (BZ2_bzDecompress in bzlib.c doesn't return properly). The first crashing input (crash000_opt_a_SIGSEGV) needs "-a" argument to crash the program. If you can get any CVE number to assign to these bugs, please let me know so that we mention the numbers in our paper. Also if you have any question or need to discuss these further, feel free to send me a message. -- Best Regards Sirus Shahini zharf_crashes.tgz Description: application/gtar-compressed signature.asc Description: PGP signature
Bug#979734: closed by Debian FTP Masters (reply to YOKOTA Hiroshi ) (Bug#979734: fixed in calibre 5.9.0+dfsg-2)
> Thank you for the very fast fix. python3-crypto is still listed in > Depends, though. Bummer ... thanks! Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#979734: closed by Debian FTP Masters (reply to YOKOTA Hiroshi ) (Bug#979734: fixed in calibre 5.9.0+dfsg-2)
Control: reopen -1 Thank you for the very fast fix. python3-crypto is still listed in Depends, though. Cheers On 2021-01-11 15:51:03 +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:calibre package: > > #979734: calibre: remove python3-crypto from (Build-)Depends > > It has been closed by Debian FTP Masters > (reply to YOKOTA Hiroshi ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to YOKOTA Hiroshi > ) by > replying to this email. > > > -- > 979734: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979734 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Date: Mon, 11 Jan 2021 15:48:30 + > From: Debian FTP Masters > To: 979734-cl...@bugs.debian.org > Subject: Bug#979734: fixed in calibre 5.9.0+dfsg-2 > Reply-To: YOKOTA Hiroshi > Message-Id: > > Date: Sun, 10 Jan 2021 23:34:05 +0100 > From: Sebastian Ramacher > To: Debian Bug Tracking System > Subject: calibre: remove python3-crypto from (Build-)Depends > Message-ID: > > Source: calibre > Version: 5.8.1+dfsg+fontFix-1 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > Control: block 972184 by -1 > Control: block 979318 by -1 > > We will remove python3-crypto from bullseye. It is unmaintained and a > replacement is available via python3-pycryptodome. calibre only uses any > module from python3-crypto in src/calibre/test_build.py to check if is > installed. No other code in calibre uses python3-crypto. So I recommend > to simply remove this check and drop the dependencies. > > Cheers > -- > Sebastian Ramacher -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#974779: [Pkg-julia-devel] Bug#974779: closed by Debian FTP Masters (reply to Gianfranco Costamagna ) (Bug#974779: fixed in llvm-toolchai
Hi everyone, thanks for all your work, when I came back I saw that Julia has transitioned into testing without any further ado. So I would like to know what remains to be done form my side? Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#979855: RFS: budgie-desktop-view/1.1.1-1 -- Desktop Icons for the Budgie-Desktop
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "budgie-desktop-view": * Package name: budgie-desktop-view Version : 1.1.1-1 Upstream Author : Josh Strobl * URL : https://github.com/getsolus/budgie-desktop-view * License : Apache-2.0 * Vcs : https://github.com/UbuntuBudgie/budgie-desktop-view/tree/debian Section : misc It builds those binary packages: budgie-desktop-view - Desktop Icons for the Budgie-Desktop To access further information about this package, please visit the following URL: https://mentors.debian.net/package/budgie-desktop-view/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/budgie-desktop-view/budgie-desktop-view_1.1.1-1.dsc Notes: I am the Debian Maintainer of budgie-desktop & budgie-extras (plus several other packages). This package Is currently in Testing. I have spot checked the diff between the previous version 1.1 and this (v1.1.1) to to ensure they contain no changes to the copyright header. Note - upstream have changed the copyright header to 2021 post this microrelease. I don't consider this necessary to capture the source copyright year change as a patch and can be dealt with in a subsequent microrelease if made before final freeze. I have sbuild this package against unstable and all information & warning lintian issues have been resolved. The build has been tested and confirmed working as per the upstream release statement for this microrelease In addition to sponsoring this package update - if appropriate I would like to continue maintainership of this package (assuming that it is acceptable to Debian) in a similar manner as my current maintainership packages (dak fossfree...@ubuntu.com) Changes since the last upload: budgie-desktop-view (1.1.1-1) unstable; urgency=medium . * New upstream release - Check if a desktop item is a special item before attempting to trash it Regards, -- David Mohammed
Bug#979686: mediawiki: Cannot skip installing mariadb & postgresql
Hi Joseph, On 1/9/21 7:07 PM, Joseph Nuthalapati wrote: However, the Debian package for MediaWiki installs mariadb server, client and libraries for PHP and Perl. The MariaDB daemon consumes 80-90 MB of memory which is a lot to spare on Single Board Computers. Similarly, it also installs PostgreSQL server, client and libraries. MediaWiki currently "Recommends" MariaDB/postgres, it's not a hard dependency. I do believe that for most users MariaDB is the best option and should be installed by default, but understand and agree that for FreedomBox SQLite is a better choice. It is possible to install mediawiki without mariadb and postgreql using the following command, but one has to guess the version numbers correctly. The easiest and most foolproof way would be: # apt install mediawiki --no-install-recommends # apt install mediawiki mariadb-server-10.5- postgresql-13- On Buster (didn't try unstable yet), the following seems to work as well: # apt install mediawiki default-mysql-server- You probably also want to install php-sqlite3 explicitly so php-mysql isn't pulled in. Maybe a package like mediawiki-sqlite which doesn't install the other databases would help. I would be open to such a solution if we can't figure it out another way. -- Kunal
Bug#979573: Acknowledgement (nvidia-driver: Screen freezes since upgrade to 455.45)
Addendum: The fix is to install nvidia-driver 460.27.04-1 No freezes happened since then: system boot 5.10.x Fri Jan 8 15:20 still running Cheers Seegras -- "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin "It's also true that those who would give up privacy for security are likely to end up with neither." -- Bruce Schneier
Bug#979854: nextpnr-ice40-qt: Segfault when opening layed out design from GUI
Package: nextpnr-ice40-qt Version: 0.0~git20200831.4512a9d-1+b1 Severity: important Dear Maintainer, When opening a .json file in the nextpnr-ice40 QT GUI, I get a segmentation fault. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU threads) 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 Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages nextpnr-ice40-qt depends on: ii libboost-filesystem1.74.0 1.74.0-5 ii libboost-program-options1.74.0 1.74.0-5 ii libboost-thread1.74.0 1.74.0-5 ii libc6 2.31-6 ii libgcc-s1 10.2.1-1 ii libpython3.93.9.1-1 ii libqt5core5a5.15.2+dfsg-2 ii libqt5gui5 5.15.2+dfsg-2 ii libqt5widgets5 5.15.2+dfsg-2 ii libstdc++6 10.2.1-1 nextpnr-ice40-qt recommends no packages. Versions of packages nextpnr-ice40-qt suggests: ii fpga-icestorm 0~20190913git0ec00d8-2 ii yosys 0.9-1+b1 -- no debconf information
Bug#979827: php7.4: please package new point release
Package: php7.4 Version: 7.4.11-1 Dear Maintainer, unstable/testing is missing a recent php 7.4 version. Three new point releases were published including a fix for CVE-2020-7071. Please consider updating php7.4. Best regards, Christian Göttsche
Bug#887231: dnssec-trigger should depend on e2fsprogs explicitly
On Mon, 2021-01-11 at 00:00 +0200, Faidon Liambotis wrote: > On Mon, Jan 22, 2018 at 11:22:51PM +0100, Andreas Henriksson wrote: > > These occurances can be found in the source at: > > > > https://sources.debian.org/src/dnssec-trigger/0.13-6/riggerd/reshook.c/#L114 > > https://sources.debian.org/src/dnssec-trigger/0.13-6/dnssec-trigger-script.in/#L528 Huh. Thank you for pointing that out. I'll try to make a fix tonight when I'm bit less busy. As you point out it should be pretty easy to fix. Diane
Bug#935654: matrix-synapse: /etc/init.d/matrix-synapse stop doesn't work
Hello, On Sun, 10 Jan 2021 17:34:57 +0100 wrote: > * Forcing start-stop-daemon to create the PID file. > Synapse seems to fail to do this, see > https://github.com/matrix-org/synapse/issues/9066 indeed matrix-synapse does it properly - it just needs the "--daemonize" option. See my updated patch: it uses "--daemonize" (for matrix-synapse) instead of "--background" (for start-stop-daemon). (the removal of "--exec" in "stop" is unrelated and still necessary) This fixes the start/stop issue. Cheers, Lars --- matrix-synapse.orig 2021-01-10 17:19:42.921852639 +0100 +++ matrix-synapse 2021-01-11 23:15:49.078774154 +0100 @@ -102,10 +89,12 @@ touch $PIDFILE chown $USER:nogroup $PIDFILE chown $USER:nogroup $SHAREDIR/media/ + + mkdir -p "$SHAREDIR/uploads" chown $USER:nogroup $SHAREDIR/uploads/ - start-stop-daemon --start --background --pidfile $PIDFILE --chuid $USER \ - --exec $PYTHON -- -m "synapse.app.homeserver" $CONFIGS || return 2 + start-stop-daemon --start --pidfile $PIDFILE --chuid $USER \ + --exec $PYTHON -- -m "synapse.app.homeserver" --daemonize $CONFIGS || return 2 return 0 } @@ -126,7 +115,7 @@ return $RETVAL fi - start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --user $USER --exec $PYTHON + start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --user $USER RETVAL="$?" [ "$RETVAL" = 2 ] && return 2
Bug#979853: fp-compiler-3.2.0: does not install: postinst: line 68: --slave: command not found
Package: fp-compiler-3.2.0 Version: 3.2.0+dfsg-9 Severity: grave Justification: renders package unusable Hi! During postinst the following happens: Setting up fp-compiler-3.2.0:amd64 (3.2.0+dfsg-9) ... Saved old "fpc-3.2.0.cfg" to "fpc-3.2.0.bak" /var/lib/dpkg/info/fp-compiler-3.2.0:amd64.postinst: line 68: --slave: command not found Reason: Line 67 misses the \ at the end for the continuation line to work. Grüße Sven. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (400, 'testing'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.10.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages fp-compiler-3.2.0 depends on: ii binutils 2.35.1-7 ii debconf [debconf-2.0] 1.5.74 ii fp-units-rtl-3.2.0 3.2.0+dfsg-9 ii libc6 2.31-9 Versions of packages fp-compiler-3.2.0 recommends: ii fp-utils-3.2.0 3.2.0+dfsg-9 Versions of packages fp-compiler-3.2.0 suggests: pn fp-docs-3.2.0 -- debconf information excluded
Bug#979852: ITP: usockets-dev -- miniscule async eventing, networking & crypto library
Package: wnpp Severity: wishlist Owner: Aisha Tammy X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: usockets-dev Version : 0.6.0 Upstream Author : Alex Hultman * URL : https://github.com/uNetworking/uSockets * License : ( Apache-2.0 ) Programming Lang: (C, C++) Description : miniscule async eventing, networking & crypto library useful library for doing fast socket io it is similar to other socket io libraries but focuses on speed with a high level API
Bug#979851: fp-compiler-3.2.0: missing backslash in postinst, line 68
Package: fp-compiler-3.2.0 Version: 3.2.0+dfsg-9 Severity: normal Dear Maintainer, Installation of the package fails, line 68 of the postinst script misses a backslash at the end of the line Best wishes, Jan -- System Information: Debian Release: bullseye/sid APT prefers experimental APT policy: (800, 'experimental'), (500, 'master'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.5-xanmod1 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_CRAP, 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 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fp-compiler-3.2.0 depends on: hi binutils 2.35.1-7 ii debconf [debconf-2.0] 1.5.74 ii fp-units-rtl-3.2.0 3.2.0+dfsg-9 ii libc6 2.31-9 Versions of packages fp-compiler-3.2.0 recommends: ii fp-utils-3.2.0 3.2.0+dfsg-9 Versions of packages fp-compiler-3.2.0 suggests: ii fp-docs-3.2.0 3.2.0+dfsg-9 -- debconf information excluded
Bug#979850: fp-compiler-3.2.0: missing '\' at end of line 67 in postinst script
Package: fp-compiler-3.2.0 Version: 3.2.0+dfsg-9 Severity: grave Justification: renders package unusable Dear maintainer, At upgrade time: Setting up fp-compiler-5.2.0:amd64 (3.2.0+dfsg-9) ... Saved old "fpc-3.2.0.cfg" to "fpc-3.2.0.bak" /var/lib/dpkg/info/fp-compiler-3.2.0:amd64.postinst: 68: --slave: not found dpkg: error processing package fp-compiler-3.2.0:amd64 (--configure): This is because there is a missing '\' ant the end of line 67. Thanks, -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fp-compiler-3.2.0 depends on: ii binutils 2.35.1-7 ii debconf [debconf-2.0] 1.5.74 ii fp-units-rtl-3.2.0 3.2.0+dfsg-9 ii libc6 2.31-9 Versions of packages fp-compiler-3.2.0 recommends: pn fp-utils-3.2.0 Versions of packages fp-compiler-3.2.0 suggests: pn fp-docs-3.2.0 -- debconf information excluded
Bug#979847: RFS: mypager/0.6.3-1 -- pager for MySQL/PostgreSQL command line clients
> On 11 Jan 2021, at 21:37, Romuald Brunet wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "mypager": > > * Package name: mypager > Version : 0.6.3-1 > Upstream Author : [fill in name and email of upstream] > * URL : http://romuald.github.io/mypager/ > * License : Apache-2.0 > * Vcs : https://github.com/romuald/mypager > Section : misc > > It builds those binary packages: > > mypager - pager for MySQL/PostgreSQL command line clients > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/mypager/ > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/m/mypager/mypager_0.6.3-1.dsc > > Changes since the last upload: > > mypager (0.6.3-1) unstable; urgency=medium As usual I guess, my mail client did truncate the content of the mail, here is the changelog as shown in debian/changelog Changes since the last upload: mypager (0.6.3-1) unstable; urgency=medium * New upstream release -- Romuald Brunet Mon, 11 Jan 2021 20:55:02 +0100 mypager (0.6.2-1) unstable; urgency=low * New upstream release -- Romuald Brunet Fri, 08 Jan 2021 10:39:06 +0100 -- Romuald Brunet
Bug#931003: [Pkg-rust-maintainers] Bug#931003: Removed package(s) from unstable
These packages are not installed by users, so leaving them as FTBFS is not a big deal. If you want to clean it up, please feel free. I can certainly understand if people (e.g. me) want to spend their time doing other things. X Santiago Vila: > On Sun, 8 Sep 2019, Ximin Luo wrote: > >> Santiago Vila: >>> reopen 931003 >>> found 931003 0.2.4-1 >>> fixed 931003 0.2.4-1+rm >>> thanks >>> >>> Hi. >>> >>> This was automatically closed by ftpmaster because the package was >>> removed from unstable, but this still does not fix the FTBFS problem >>> in stable. >>> >>> Thanks. >>> >> >> Please be aware that the Debian Rust team today *does not make any >> effort* towards bugs affecting Debian Stable. [...] > > Not even FTBFS bugs, as it is the case here? > > There are already 74 packages which FTBFS in stable (by my count), it > would be much better if every mantainer cared about their own packages. > I'm curious: does this really sound unreasonable for you? > > Thanks. > > ___ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers > -- GPG: ed25519/56034877E1F87C35 https://github.com/infinity0/pubkeys.git
Bug#979562: lightdm session termination does not stop xscreensaver
Am 11.01.21 um 22:04 schrieb Eduard Bloch: Not sure which kind of backup you expect. Well, you filed a serious bug report against systemd, so I expect at least some kind of justification for that. OpenPGP_signature Description: OpenPGP digital signature
Bug#979849: ITP: golang-github-cli-browser -- helpers to open URLs, files, or readers in a web browser
Package: wnpp Severity: wishlist Owner: Joao Paulo Lima de Oliveira X-Debbugs-Cc: debian-de...@lists.debian.org, jlima.oliveir...@gmail.com * Package name: golang-github-cli-browser Version : 1.0.0-1 Upstream Author : Dave Cheney * URL : https://github.com/cli/browser * License : BSD-2-clause Programming Lang: Go Description : helpers to open URLs, files, or readers in a web browser golang-github-cli-browser is dependent on Github-Cli. Provides an auxiliary way to open URL in system browsers. This package adds: -safety when running inside of an untrusted directory on Windows; -WSL compatibility; -OpenReader error wrapping; -ErrNotFound error wrapping on BSD; -Go 1.13 support
Bug#979562: lightdm session termination does not stop xscreensaver
> my .icewm/startup file at the moment contains: > > xscreensaver -nosplash -log wtf-xscreensaver.txt & > > When icewm starts, I see the splash screen for a brief moment (not joking, > looks -nosplash has no effect there), but it does not happen every time. This kinda sounds like *something else* is launching xscreensaver at the same time, and whatever that is is doing it without -nosplash. The two of them racing would explain the "already running" error. > Or, if run ps quick enough before it's killed, I see: > > user 3904 0.0 0.0 5712 1128 ?SN 21:13 0:00 > xscreensaver-systemd -verbose > lightdm11997 0.1 0.0 18948 5952 ?Ss 21:55 0:00 > xscreensaver > lightdm12068 0.0 0.0 5712 1128 ?SN 21:55 0:00 > xscreensaver-systemd > user 12416 0.0 0.0 3748 664 pts/0S+ 21:56 0:00 grep saver Note that pid 11997 does not have -nosplash on its command line. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#979562: lightdm session termination does not stop xscreensaver
Hallo, * Michael Biebl [Sun, Jan 10 2021, 08:24:12PM]: > Am 10.01.21 um 20:02 schrieb Jamie Zawinski: > > > Why would a xscreensaver instance running for user A have any influence > > > on a xscreensaver instance running for user B? That seems absolutely > > > weird to me and something I don't understand. > > > > Yeah, that sounds impossible, assuming that the X server has restarted > > between user A and user B. > > > > If things have gone wrong in a weird way, the "xscreensaver-systemd" > > process of user A might linger, but it won't be able to communicate with > > user B's xscreensaver. > > Since Eduard has been claiming this originally: > > > - having this xscreensaver hanging around disturbs the startup of > >another xscreensaver process in the new user session > > I guess he needs to back this up somehow. > Unfortunately I haven't seen any log files or anything, which would give us > the opportunity to retrace what's happening. Not sure which kind of backup you expect. How can I generate more useful logfiles? IMHO I asked before for some kind of tracing functionality to become able to get that information, i.e. to see how systemd is ticking, to see what is happening or how the the delayed SIGTERM is triggered. Those are basically the symptoms I see: my .icewm/startup file at the moment contains: xscreensaver -nosplash -log wtf-xscreensaver.txt & When icewm starts, I see the splash screen for a brief moment (not joking, looks -nosplash has no effect there), but it does not happen every time. And in wtf-xscreensaver.txt I find: xscreensaver: 21:50:06: already running on display :0 (window 0x45) from process 9797 (lightdm@whitestar). Second attempt (and a different PID): When I run "xscreensaver-command -lock" (through ctrl-alt-del dialog of icewm) then the screen gets locked, and pushing a key shows me the credentials prompt for the user called "lightdm". Or, if run ps quick enough before it's killed, I see: user 3904 0.0 0.0 5712 1128 ?SN 21:13 0:00 xscreensaver-systemd -verbose lightdm11997 0.1 0.0 18948 5952 ?Ss 21:55 0:00 xscreensaver lightdm12068 0.0 0.0 5712 1128 ?SN 21:55 0:00 xscreensaver-systemd user 12416 0.0 0.0 3748 664 pts/0S+ 21:56 0:00 grep saver (one of those "xscreensaver-systemd" belongs to an earlier session, this is another complaint of mine in #978589 but it's claimed not to cause the main issue). Best regards, Eduard.
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
Hi, On 10/01/2021 20:03, Simon McVittie wrote: If you intend the scope of this bug to involve overruling maintainers' decisions in packages other than NM, what other packages/bugs did you have in mind? Is it just udisks2/#923387, or are there more? I understand (but I don't think it has been explicitly stated) that the TC is going to decline to overrule on the question of init scripts?[0] I'm going to beg that question for the rest of this mail, but obviously if I'm wrong that will increase the scope somewhat. Please overrule the maintainer in #923387 so that it is can be used on systems with elogind; it has been tested and shown to work thus as well as being supported by upstream[1]. Mark tells us that there are not currently any other packages which could be used with elogind were it not for an incorrect dependency on libpam-systemd, so I hope we don't need to worry about the broader question any further. Regards, Matthew [0] to that end, orphan-sysvinit-scripts is in NEW, and while I hope your ruling will not result in a bonfire of perfectly good init scripts, I hope that maintainers who decide to ditch them will let us know so we can add them there [1] I've not restated my rationale about how technologies like elogind are important to the project per GR etc etc. I can if you like, but I don't think that's necessary here
Bug#903125: exec-maven-plugin: FTBFS in stretch (expected:<[mvn] --version> but was:<['mvn'] --version>)
On Tue, 19 Feb 2019, Markus Koschany wrote: > Since there is also a simple workaround for > stable and oldstable (disabling the tests), I am going to lower the > severity to important. Please don't do that sort of thing. A package is considered to have a FTBFS bug, serious and RC, if the exit status of dpkg-buildpackage is > 0, indicating error, for whatever reason which is not the fault of the person building the package (including of course failing the tests). If you believe severities of FTBFS bugs should be lower than serious in case it's the tests the ones to fail, then please make a proposal to make all FTBFS bugs of "grave" severity as a general rule, then and only then it would make sense to downgrade from grave to serious. Thanks.
Bug#979718: Acknowledgement (request for new package rduty)
RFP: rduty easily run commands on remote or local hosts and devices COPYRIGHT is GPL2: https://github.com/gabgio/rduty/blob/main/LICENSE Release: https://github.com/gabgio/rduty/releases/download/v0.3.2/rduty-0.3.2.tar.gz URL: https://github.com/gabgio/rduty make deb from the source tarball create a .deb package. I'm looking to join as a maintainer myself, but I read that first a sponsor is needed But that's another story. Thanks Il giorno dom 10 gen 2021 alle ore 18:51 Debian Bug Tracking System < ow...@bugs.debian.org> ha scritto: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 979718: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979718. > > 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): > unknown-pack...@qa.debian.org > > If you wish to submit further information on this problem, please > send it to 979...@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. > > -- > 979718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979718 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#931003: [Pkg-rust-maintainers] Bug#931003: Removed package(s) from unstable
On Sun, 8 Sep 2019, Ximin Luo wrote: > Santiago Vila: > > reopen 931003 > > found 931003 0.2.4-1 > > fixed 931003 0.2.4-1+rm > > thanks > > > > Hi. > > > > This was automatically closed by ftpmaster because the package was > > removed from unstable, but this still does not fix the FTBFS problem > > in stable. > > > > Thanks. > > > > Please be aware that the Debian Rust team today *does not make any > effort* towards bugs affecting Debian Stable. [...] Not even FTBFS bugs, as it is the case here? There are already 74 packages which FTBFS in stable (by my count), it would be much better if every mantainer cared about their own packages. I'm curious: does this really sound unreasonable for you? Thanks.
Bug#979848: apt: [INTL:de] updated German po file translation
Package: apt Version: 2.1.16 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for apt attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Greetings Helge # German messages for the apt suite. # Copyright (C) 1997, 1998, 1999 Jason Gunthorpe and others. # Helge Kreutzmann , 2020, 2021. # Holger Wansing , 2008, 2009, 2010, 2012, 2014, 2017, 2018. # Jens Seidel , 2008. # Michael Piefel , 2001, 2002, 2003, 2004, 2006. # Rüdiger Kuhlmann , 2002. # # msgid "" msgstr "" "Project-Id-Version: apt 2.1.16\n" "Report-Msgid-Bugs-To: APT Development Team \n" "POT-Creation-Date: 2021-01-08 21:58+0100\n" "PO-Revision-Date: 2021-01-11 21:40+0100\n" "Last-Translator: Helge Kreutzmann \n" "Language-Team: German \n" "Language: de\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n != 1;\n" #: apt-pkg/acquire-item.cc msgid "" "Updating from such a repository can't be done securely, and is therefore " "disabled by default." msgstr "" "Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art " "durchgeführt werden, daher ist es standardmäßig deaktiviert." #: apt-pkg/acquire-item.cc msgid "" "Data from such a repository can't be authenticated and is therefore " "potentially dangerous to use." msgstr "" "Daten von solch einem Depot können nicht authentifiziert werden und deren " "Nutzung ist daher potentiell gefährlich." #: apt-pkg/acquire-item.cc msgid "" "See apt-secure(8) manpage for repository creation and user configuration " "details." msgstr "" "Weitere Details zur Erzeugung von Paketdepots sowie zu deren " "Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8)." #: apt-pkg/acquire-item.cc #, c-format msgid "The repository '%s' is no longer signed." msgstr "Das Depot »%s« ist nicht mehr signiert." #: apt-pkg/acquire-item.cc #, c-format msgid "The repository '%s' no longer has a Release file." msgstr "Das Depot »%s« enthält keine Release-Datei mehr." #: apt-pkg/acquire-item.cc msgid "" "This is normally not allowed, but the option Acquire::" "AllowDowngradeToInsecureRepositories was given to override it." msgstr "" "Dies ist normalerweise nicht erlaubt, was aber wegen der angegebenen Option " "»Acquire::AllowDowngradeToInsecureRepositories« unbeachtet blieb." #: apt-pkg/acquire-item.cc #, c-format msgid "The repository '%s' is not signed." msgstr "Das Depot »%s« ist nicht signiert." #: apt-pkg/acquire-item.cc #, c-format msgid "The repository '%s' does not have a Release file." msgstr "Das Depot »%s« enthält keine Release-Datei." #: apt-pkg/acquire-item.cc #, c-format msgid "The repository '%s' provides only weak security information." msgstr "" "Das Depot »%s« stellt nur schwache Sicherheitsinformationen zur Verfügung." #: apt-pkg/acquire-item.cc ftparchive/writer.cc #, c-format msgid "Failed to readlink %s" msgstr "readlink von %s fehlgeschlagen" #: apt-pkg/acquire-item.cc ftparchive/cachedb.cc methods/rred.cc #, c-format msgid "Failed to stat %s" msgstr "%s mit »stat« abfragen fehlgeschlagen" #: apt-pkg/acquire-item.cc msgid "Hash Sum mismatch" msgstr "Hash-Summe stimmt nicht überein" #: apt-pkg/acquire-item.cc msgid "Insufficient information available to perform this download securely" msgstr "" "Es sind nur unzureichende Informationen verfügbar, um diesen Download auf " "sichere Art durchzuführen." #: apt-pkg/acquire-item.cc apt-pkg/contrib/fileutl.cc #, c-format msgid "rename failed, %s (%s -> %s)." msgstr "Umbenennen fehlgeschlagen, %s (%s -> %s)." #: apt-pkg/acquire-item.cc msgid "Size mismatch" msgstr "Größe stimmt nicht überein" #: apt-pkg/acquire-item.cc msgid "Invalid file format" msgstr "Ungültiges Dateiformat" #: apt-pkg/acquire-item.cc msgid "Signature error" msgstr "Signaturfehler" #. TRANSLATORS: %s is a single techy word like 'NODATA' #: apt-pkg/acquire-item.cc methods/gpgv.cc #, c-format msgid "" "Clearsigned file isn't valid, got '%s' (does the network require " "authentication?)" msgstr "" "Durch Clearsign signierte Datei ist nicht gültig, »%s« erhalten (erfordert " "das Netzwerk eine Authentifizierung?)" #: apt-pkg/acquire-item.cc #, c-format msgid "" "An error occurred during the signature verification. The repository is not " "updated and the previous index files will be used. GPG error: %s: %s" msgstr "" "Während der Überprüfung der Signatur trat ein Fehler auf. Das Depot wurde " "nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-" "Fehler: %s: %s" #. Invalid signature file, reject (LP: #346386) (Closes: #627642) #: apt-pkg/acquire-item.cc #, c-format msgid "GPG error: %s: %s" msgstr "GPG-Fehler: %s: %s" #: apt-pkg/acquire-item.cc #, c-format msgid "" "Skipping acquire of configured file '%s' as repository '%s' doesn't have
Bug#979847: RFS: mypager/0.6.3-1 -- pager for MySQL/PostgreSQL command line clients
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mypager": * Package name: mypager Version : 0.6.3-1 Upstream Author : [fill in name and email of upstream] * URL : http://romuald.github.io/mypager/ * License : Apache-2.0 * Vcs : https://github.com/romuald/mypager Section : misc It builds those binary packages: mypager - pager for MySQL/PostgreSQL command line clients To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mypager/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mypager/mypager_0.6.3-1.dsc Changes since the last upload: mypager (0.6.3-1) unstable; urgency=medium . * New upstream release Regards, -- Romuald Brunet
Bug#979846: ITP: bazel -- Tool to automate software builds and tests
Package: wnpp Severity: wishlist Owner: Olek Wojnar * Package name: bazel Version : 3.5.1 Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/bazel * License : Apache-2 Programming Lang: Java and C++ Description : Tool to automate software builds and tests Supported build tasks include running compilers and linkers to produce executable programs and libraries, and assembling deployable packages for Android, iOS and other target environments. Bazel is similar to other tools like Make, Ant, Gradle, Buck, Pants and Maven. This package will effectively replace the bazel-bootstrap package which was created to avoid circular build dependencies with Bazel. The bazel-bootstrap package will likely remain in the archives as a means of adding Bazel support to additional architectures in the future.
Bug#979845: mustache-java: Please drop the Build-Depends on jruby
Package: src:mustache-java Version: 0.8.18-1.1 Severity: important X-Debbugs-CC: elb...@debian.org Owner: po...@debian.org Dear maintainers, At the moment, jruby in Debian is pretty broken [1] and probably should not be in the next Debian Stable release. Since this package build-depends on it, jruby is in the "key packages" list and is thus not subject to autoremoval from testing, although it has multiple RC bugs. I see the latest upstream version for this package has removed support for jruby. As such, I'll try to update it to version 0.9.7 and see what happens. If I'm not able to, I'll ask for help on the Java Team ML. Cheers, [1]: https://lists.debian.org/debian-java/2020/12/msg00073.html -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#979563: gitlab: my instance work great after upgrade to 13.5.6.1!
Just to know, in previous version I have some trouble with licensee, and I do the following to solve the problem: gitaly(13.4.6+dfsg1-2) and gitlab(13.4.7-2) have in Gemfile: gem 'rugged', '~> 0.28' ... gem 'licensee', '~> 8.9' But rugged is 1.1.0+ds-1 in testing and unstable and licensee need rugged~>0.24. Solved putting in Gemfile: gem 'rugged', '>= 0.28' gem 'licensee', '~> 9.14', '>= 9.14.1' and manually install licensee 9.14.1 with: cd /usr/share/gitlab gem install licensee It could help. Cu respect, Dragos Jarca General manager Dynamic Puzzle S.R.L. www.dynamicpuzzle.ro On 11.01.2021 17:52, Pirate Praveen wrote: On 2021, ജനുവരി 11 7:00:11 PM IST, Dragos Jarca wrote: Package: gitlab Followup-For: Bug #979563 Dear Maintainer, My instance work great after upgrade to 13.5.6.1! I can see the content of folder and files on UI. I can fetch, push, etc. I added versions off packages if I use, maby will help you. If you want to give you more info, tell me. Thanks for the feedback. I can see gitaly is still 13.4.6 so the bug is in gitaly. - Versions of packages gitlab recommends: ii certbot 1.10.1-1 ii gitaly 13.4.6+dfsg1-2 So I suggest you hold gitaly on this version.
Bug#979843: python-django: autopkgtest regression in testing: 'image/vnd.mozilla.apng' != 'image/png'
Source: python-django Version: 2:2.2.17-2 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent in testing the autopkgtest of your package started to fail. I copied some of the output at the bottom of this report. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django/9501583/log.gz == FAIL: test_attach_file (mail.tests.MailTests) Test attaching a file against different mimetypes and make sure that -- Traceback (most recent call last): File "/usr/lib/python3.9/unittest/case.py", line 59, in testPartExecutor yield File "/usr/lib/python3.9/unittest/case.py", line 593, in run self._callTestMethod(testMethod) File "/usr/lib/python3.9/unittest/case.py", line 550, in _callTestMethod method() File "/tmp/autopkgtest-lxc.pw5bm44p/downtmp/autopkgtest_tmp/tests/mail/tests.py", line 472, in test_attach_file self.assertEqual(mimetypes.guess_type(basename)[0], real_mimetype) File "/usr/lib/python3.9/unittest/case.py", line 831, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib/python3.9/unittest/case.py", line 1211, in assertMultiLineEqual self.fail(self._formatMessage(msg, standardMsg)) File "/usr/lib/python3.9/unittest/case.py", line 670, in fail raise self.failureException(msg) AssertionError: 'image/vnd.mozilla.apng' != 'image/png' - image/vnd.mozilla.apng + image/png OpenPGP_signature Description: OpenPGP digital signature
Bug#979842: ITP: todo.txt-gtd -- add GTD project features to todo.txt
Package: wnpp Severity: wishlist Owner: 'David Steele' thanks * Package name: todo.txt-gtd Version : 0.4 Upstream Author : 'David Steele' * URL : https://github.com/davesteele/todo.txt-gtd * License : GPL-2+ Description : GTD project features for todo.txt This package extends packages providing the virtual package [todo.txt] - adding features to enhance project-level documentation within the todo.txt tasking file. Utilities include: tdtcleanup - re-sort all tasks by project within a todo.txt file project - edit just one or several projects in a todo.txt file The utilities integrate with the current todo.txt provider, running cleanup automatically and discovering the correct todo.txt path. The project features are inspired by the Getting Things Done ([GTD]) methodology. [todo.txt]: http://todotxt.org/ [GTD]: https://gettingthingsdone.com/ OpenPGP_signature Description: OpenPGP digital signature
Bug#979841: rdflib: autopkgtest failure: cannot create directory ‘build/py3_testing’
Source: rdflib Version: 4.2.1-2 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You package has an autopkgtest, graet. However, it always fails on the ci.debian.net infrastructure [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/testing/amd64/r/rdflib/9601096/log.gz autopkgtest [14:14:57]: test python3: [--- Traceback (most recent call last): File "/tmp/autopkgtest-lxc.y62s4fn_/downtmp/build.9Un/src/setup.py", line 39, in from setuptools import setup, find_packages ModuleNotFoundError: No module named 'setuptools' mkdir: cannot create directory ‘build/py3_testing’: No such file or directory cp: cannot create directory 'build/py3_testing/': No such file or directory cp: target 'build/py3_testing/' is not a directory cp: cannot stat 'build/lib/rdflib': No such file or directory ./run_tests_py3.sh: 14: cd: can't cd to build/py3_testing ./run_tests_py3.sh: 16: 2to3: not found ./run_tests_py3.sh: 17: 2to3: not found File "/tmp/autopkgtest-lxc.y62s4fn_/downtmp/build.9Un/src/run_tests.py", line 92 print "Running nose with:", " ".join(finalArgs[1:]) ^ SyntaxError: invalid syntax OpenPGP_signature Description: OpenPGP digital signature
Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53
Source: dns-root-data Version: 2019052802 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a not so recent change (beginning 2020) somewhere outside your package the autopkgtest of your package started to fail. I copied some of the output at the bottom of this report. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/testing/amd64/d/dns-root-data/9516338/log.gz autopkgtest [17:42:10]: test baseline: [--- ;; WARNING: response timeout for 127.0.0.1@53(UDP) ;; WARNING: response timeout for 127.0.0.1@53(UDP) ;; WARNING: response timeout for 127.0.0.1@53(UDP) ;; ERROR: failed to query server 127.0.0.1@53(UDP) autopkgtest [17:42:25]: test baseline: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#979839: Please package LilyPond 2.22.0
Package: lilypond Severity: wishlist Thank you for packaging LilyPond for Debian! As you no doubt are aware, LilyPond 2.22.0 has been released: https://lists.gnu.org/archive/html/lilypond-devel/2021-01/msg00069.html This version no longer depends on Python 2. For that reason alone, would it be possible to package it for Bullseye? Besides, having the latest version in Stable is always nice. Thanks! Yours truly, John Zaitseff -- John Zaitseff ╭───╮ Email: j.zaits...@zap.org.au The ZAP Group │ Z │ GnuPG: 0x0D254111C4EE569B Sydney, Australia ╰───╯ https://www.zap.org.au/~john/
Bug#979838: twisted: autopkgtest regression in testing: No such file or directory: 'ckeygen'
Source: twisted
Version: 18.9.0-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a not so recent change (March 2019) in testing the autopkgtest of
your package started to fail. I copied some of the output at the bottom
of this report. Can you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
https://ci.debian.net/data/autopkgtest/testing/amd64/t/twisted/9444048/log.gz
autopkgtest [09:30:22]: test unit-tests-3: [---
Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
line 86, in test_keygeneration
self._testrun('ecdsa', '384')
File
"/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
line 75, in _testrun
subprocess.call(args)
File "/usr/lib/python3.9/subprocess.py", line 349, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.9/subprocess.py", line 947, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.9/subprocess.py", line 1819, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
builtins.FileNotFoundError: [Errno 2] No such file or directory: 'ckeygen'
Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
line 105, in test_runBadKeytype
subprocess.check_call(
File "/usr/lib/python3/dist-packages/twisted/trial/_synctest.py", line
352, in __exit__
self._testCase.fail(
twisted.trial.unittest.FailTest: builtins.FileNotFoundError raised
instead of CalledProcessError:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/twisted/trial/_asynctest.py",
line 111, in _run
d = defer.maybeDeferred(
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line
151, in maybeDeferred
result = f(*args, **kw)
File "/usr/lib/python3/dist-packages/twisted/internet/utils.py", line
217, in runWithWarningsSuppressed
result = f(*a, **kw)
File
"/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
line 105, in test_runBadKeytype
subprocess.check_call(
--- ---
File
"/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
line 105, in test_runBadKeytype
subprocess.check_call(
File "/usr/lib/python3.9/subprocess.py", line 368, in check_call
retcode = call(*popenargs, **kwargs)
File "/usr/lib/python3.9/subprocess.py", line 349, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.9/subprocess.py", line 947, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.9/subprocess.py", line 1819, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
builtins.FileNotFoundError: [Errno 2] No such file or directory: 'ckeygen'
OpenPGP_signature
Description: OpenPGP digital signature
Bug#933059: Debian Buster with encrypted root on degraded raid1 (md-raid)
Thank you Guilhem, much appreciated!
Bug#979837: xserver-xorg-video-intel: Depth dropped to 16
Package: xserver-xorg-video-intel Severity: normal Dear Maintainer, Some applications don't work with Depth 16 and require 24. The last version where the support of Depth 24 was seen was 2:2.99.917+git20171229-1. All higher up to latest restricted to 16 only. So I compelled to downgrade and pin that working version. Please, return back the Depth 24 -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xserver-xorg-video-intel depends on: ii libc6 2.31-9 ii libdrm-intel1 2.4.103-2 ii libdrm22.4.103-2 ii libpciaccess0 0.16-1 ii libpixman-1-0 0.40.0-1 ii libudev1 247.2-4 ii libx11-6 2:1.7.0-1 ii libx11-xcb12:1.7.0-1 ii libxcb-dri2-0 1.14-2.1 ii libxcb-util1 0.4.0-1+b1 ii libxcb11.14-2.1 ii libxcursor11:1.2.0-2 ii libxdamage11:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxinerama1 2:1.1.4-2 ii libxrandr2 2:1.5.1-1 ii libxrender11:0.9.10-1 ii libxss11:1.2.3-1 ii libxtst6 2:1.2.3-1 ii libxvmc1 2:1.0.12-2 ii xserver-xorg-core [xorg-video-abi-24] 2:1.20.10-2 xserver-xorg-video-intel recommends no packages. xserver-xorg-video-intel suggests no packages.
Bug#979836: icu: autopkgtest failure (fixed in experimental)
Source: icu Version: 57.1-9 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: fails-always Control: close -1 68.2-1 Dear maintainer(s), You package has an autopkgtest, graet. However, it always fails on the ci.debian.net infrastructure [1]. Can you please investigate the situation and fix it? I see you fixed it in experimental, could you carry the autopkgtest change to the version in unstable? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#979835: RFP: rolisteam -- tabletop role playing game over the network
Package: wnpp Severity: wishlist Control: tags -1 newcomer * Package name: rolisteam Version : 1.9.3 Upstream Author : Renaud Guezennec http://www.rolisteam.org/contact * URL : https://rolisteam.org/ * License : GPL-2+, GPL-3+, LGPL-2.1+, LGPL-2.1 with Digia-Qt-1.1 exception Programming Lang: C++ Description : tabletop role playing game over the network Rolisteam helps you to manage a tabletop role playing game with remote friends/players. It provides many features to share maps, pictures and it also includes tool to communicate with your friends/players. This package installs both the rolisteam client for normal players and roliserver for the game host. There seems to be no competitor in Debian. This package is an opportunity for a new contributor. The source builds one binary package, the build system is quite standard, I may provide help and/or sponsor uploads. The attached packaging seems ready for upload, but could be improved afterwards. * debian/rules works around the non-standard usage of PREFIX by the upstream build system. The proper solution would be to fix the build system and forward a patch. * An embedded copy of libjs-pdf is replaced with a Debian dependency. The result should ideally be tested, fixed if necessary, then submitted upstream as a build-time option. rolisteam-packaging.tar.gz Description: application/gzip
Bug#979834: chromiums shows … nothing but errors on the console
Package: chromium Version: 87.0.4280.141-0.1 Severity: serious Justification: unusable as shipped -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Starting today's chromium leads to - - nothing within the window (actually an image from the previous desktop) - - tons of errors like Xlib: sequence lost (0x1012c > 0x12e) in reply type 0x0! in the terminal. After looking through https://peter.sh/experiments/chromium-command-line-switches/ and trying some switches I found that --gpu-sandbox-start-early helps to get it back to working. Some observations: % chromium --use-gl=desktop Xlib: sequence lost (0x1010d > 0x10f) in reply type 0x0! Xlib: sequence lost (0x10114 > 0x116) in reply type 0x0! Xlib: sequence lost (0x1011b > 0x11d) in reply type 0x0! [11129:11129:0111/200209.168377:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. Xlib: sequence lost (0x1012c > 0x12e) in reply type 0x0! Xlib: sequence lost (0x10133 > 0x135) in reply type 0x0! Xlib: sequence lost (0x1013a > 0x13c) in reply type 0x0! Xlib: sequence lost (0x10145 > 0x147) in reply type 0x0! Xlib: sequence lost (0x1014c > 0x14e) in reply type 0x0! Xlib: sequence lost (0x10153 > 0x155) in reply type 0x0! % chromium --use-gl=desktop --gpu-sandbox-start-early [12840:12840:0111/200259.913622:ERROR:gl_implementation.cc(282)] Failed to load libGL.so.1: libGL.so.1: cannot open shared object file: Operation not permitted [12840:12840:0111/200259.923311:ERROR:viz_main_impl.cc(150)] Exiting GPU process due to errors during initialization % chromium --use-gl=egl --gpu-sandbox-start-early [25274:25274:0111/200829.114696:ERROR:gl_implementation.cc(282)] Failed to load libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: Operation not permitted [25274:25274:0111/200829.136862:ERROR:viz_main_impl.cc(150)] Exiting GPU process due to errors during initialization locate finds both /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 and /usr/lib/x86_64-linux-gnu/libGL.so.1 This Xlib error reminds me of #979561 (without the segfault). Unlike in geeqie, downgrading libx11-6 from 2:1.7.0-1 to 2:1.6.12-1 doesn't help (chromium first starts (without any switches) but crashes soon). Cheers, gregor - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 87.0.4280.141-0.1 ii libasound2 1.2.4-1.1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libatomic1 10.2.1-6 ii libatspi2.0-02.38.0-2 ii libavcodec58 7:4.3.1-5 ii libavformat587:4.3.1-5 ii libavutil56 7:4.3.1-5 ii libc62.31-9 ii libcairo21.16.0-5 ii libcups2 2.3.3op1-3 ii libdbus-1-3 1.12.20-1 ii libdrm2 2.4.103-2 ii libevent-2.1-7 2.1.12-stable-1 ii libexpat12.2.10-1 ii libflac8 1.3.3-2 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgbm1 20.3.2-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 ii libgtk-3-0 3.24.24-1 ii libharfbuzz0b2.6.7-1 ii libicu67 67.1-5 ii libjpeg62-turbo 1:2.0.5-2 ii libjsoncpp24 1.9.4-4 ii liblcms2-2 2.9-4+b1 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.29-1 ii libnss3 2:3.60-1 ii libopenjp2-7 2.3.1-1 ii libopus0 1.3.1-0.1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpng16-16 1.6.37-3 ii libpulse014.0-2 ii libre2-9 20201101+dfsg-2 ii libsnappy1v5 1.1.8-1 ii libstdc++6 10.2.1-6 ii libwebp6 0.6.1-2+b1 ii libwebpdemux20.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libx11-6 2:1.7.0-1 ii libx11-xcb1 2:1.7.0-1 ii libxcb1 1.14-2.1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxml2 2.9.10+dfsg-6.3+b1 ii libxrandr2 2:1.5.1-1 ii libxslt1.1 1.1.34-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages chromium recommends: ii chromium-sandbox 87.0.4280.141-0.1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of
Bug#975115: Info received (Wrong API version string in Debian packaged tbsync extension)
Ok - so - the API string in buster is actually:
$ rgrep "2\.4"
dav/content/provider.js:static getApiVersion() { return "2.4"; }
eas/content/provider.js:static getApiVersion() { return "Beta 2.4"; }
dpkg/content/tbsync.jsm: apiVersion: "Beta 2.4",
So now EAS complains for me :-) But since I don't need that, I removed
it. But IMHO neither webext-eas4tbsync nor webext-tbsync should be
"Beta". I guess it's fixed for sid, where webext-tbsync is newer and
webext-eas4tbsync got a "version bump to 2.4" in 1.20-2.
HTH
Jan-Marek
Bug#979833: libtiff4: Document that Debian build is GPL due to dependency on libjbig0 (?)
Package: libtiff5 Version: 4.2.0-1 Severity: wishlist I'm wondering whether it would make sense to document in /usr/share/doc/libtiff5/copyright that even though the tiff source package in general is under a BSD/MIT style license, the Debian build is necessarily GPL due to linking against the GPL library libjbig0. On the other hand, similar reasoning would suggest going through all the reverse dependencies of libtiff4 to see what other packages would need to put in similar disclaimers - I would suppose probably at least all Gtk and Qt based packages would be affected. But that would be a huge and invasive task; so I'm not sure whether this request makes sense or not. -- Daniel Schepler
Bug#979381: Useless in Debian
Hello, I have filed an RM bug (#979832) against the package and CCed David and all the uploaders. Thanks, -- Sunil
Bug#979832: RM: php-db-dataobject -- ROM; unused, no reverse depends
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This package was uploaded as part of effort to get GNU Social into Debian. There is currently no active interest in uploading GNU social. No other packages are currently using this library. Discussion on whether to keep the package as done at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979381 Please remove the package from unstable. Thanks, - -- Sunil -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl/8n3gRHHN1bmlsQG1l ZGhhcy5vcmcACgkQQ+oc/wqnxfJmFQ/8C9mFuGlfediVXfMWxOTVgUlJMAQr5Evx iftYUPv/LVQxyjri102sKEVh/RKd+TJL2p8MjzrOy1MnJ+aHbEJeUwvnMXryMnsK CpKul2Uhs7/JF+06jpYncQfcs4w/VygRIw8G+kySwQF96/T1XkGnnI6qNFWogqFa Zc8H0Ptq+uRbJ2tQIf3owKno9vi3VcBu85sAs+xywTE1B45G4hS0mUA9K6toBidK sy32/27rCH1qVO4uQURwpFA11QLim7xfa7LlVbWvOoxXHWf0KbDnmm+Na8gZinrq tW6KYnRlpC8ZUakczLDQIZDF+BCcqdpdzQqoBIiYvi92YljPqpBq8QKo5sJjDTZL WTcYVjTgv2qAAgLAxChAfgR2PtAAfB6qrE23wRyIOgzGsSGPUv/imb079lHdUNeK gF1r++7FsabW27D+JdKPVu2zyEPjV7Ri145hJFxbcXCFnOSAh2sg7AMnZgaSljVW 3XRU8mPWBh1M9LneWAYNr66kj+xpwvIfLUw3Xc0BEyBmuQTpJAjI/1XjeVldqaFH 6iQHXR/orQAY1XESpJQsx3CRSSyJxT/dwn6z5vta9xf9AuwGvUbu89eQgf6qAOUC czait9AooEJpVk8ROWikufzPLG8cgchLOlJ/7cdW26rHYS5j51njyJdQP8u7OeSO luY5gewudQs= =MMk6 -END PGP SIGNATURE-
Bug#979831: src:colord: fails to migrate to testing for too long: unresolved RC bug
Source: colord Version: 1.4.4-2 Severity: serious Control: close -1 1.4.5-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 978167 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:colord in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=colord OpenPGP_signature Description: OpenPGP digital signature
Bug#979830: gitlab: Issue view shows error message: "Failed to load sidebar lock status"
Package: gitlab Version: 13.5.6-1~fto10+1 Severity: normal Dear Maintainer, after upgrading from 13.4.7-2~fto10+1 to 13.5.6-1~fto10+1, every issue view shows the following error message at the top: Failed to load sidebar lock status No negative impact is visible besides this error message. The related upstream code is here: https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/sidebar/mount_sidebar.js#L187 j4v4m4n commented via IRC (#debian-gitlab at oftc.net): > 19:36 Probably related to font-awesome not found > 19:42 > https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/patches/0740-use-packaged-modules.patch#L275 > 19:42 This could be the issue I think > 19:43 We don't need that change now as yarn will create a symlink > there (I hope, I did put the comments into proper order and not out of context) Thanks for your work! Cheers, Lars
Bug#979707: anki fails to start: python3: Fatal IO error 2 (No such file or directory) on X server :0.0.
On Mon, 11 Jan 2021 at 18:20, Dmitry Shachnev wrote: > Control: tags -1 + moreinfo > > Hi Alberto! > > On Sun, Jan 10, 2021 at 10:17:16PM +0100, alberto fuentes wrote: > > Kontact is failing with the same error too > > > > It seems to be related with pyqt5, which i checked and was among the > > packages updated today. Can you help me reassign and reopen bug? > > I do not understand how this is related to pyqt5. Can you please clarify? > The description mentions file not found error, but which file is not found? > Sorry, i changed the description as the mantainer of anki suggested I think is qt related because every program that uses it, exits with the same error > > Also can you please try to obtain a proper stacktrace? That would be more > useful than strace output. > Problem is that the programs dont crash, but exit with failure Short instruction: > > - sudo apt install gdb python3-pyqt5-dbg > - gdb anki > - (in gdb) run > - (in gdb, after anki crashes) bt > - attach the output here > $ gdb /usr/bin/anki For help, type "help". Type "apropos word" to search for commands related to "word"... "0x7ffc5965ab10s": not in executable format: file format not recognized quit) $ gdb kontact Reading symbols from kontact... (No debugging symbols found in kontact) (gdb) Quit (gdb) run Starting program: /usr/bin/kontact [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe1ba9700 (LWP 6362)] Gdk-Message: 19:38:25.175: kontact: Fatal IO error 2 (No such file or directory) on X server :0.0. [Thread 0x7fffe22bc440 (LWP 6293) exited] [Inferior 1 (process 6293) exited with code 01] (gdb) bt No stack. (gdb) > Also it may be useful to run "python3 -X faulthandler /usr/bin/anki", > wait until anki crashes, and paste the output of that command (it will > print the Python stacktrace). > $ python3 -X faulthandler /usr/bin/anki Gdk-Message: 19:44:02.305: python3: Fatal IO error 2 (No such file or directory) on X server :0.0. $ Is there any other way? Thanks for the help!
Bug#979156: [pkg-php-pear] Bug#979156: Useless in Debian
On 11/01/21 4:37 am, Guilhem Moulin wrote:
> Control: severity -1 serious
>
> On Mon, 11 Jan 2021 at 00:58:01 +0100, Guilhem Moulin wrote:
>> On Sun, 03 Jan 2021 at 16:54:41 -0800, Sunil Mohan Adapa wrote:
>>> I will be filing an RM: bug on the package on Jan 10, 2021. I will
>>> wait to see if the other uploaders think it is still needed.
>>
>> Roundcube's test suite which I'm working on now has some tests making
>> use of Net_IDNA2
>
> On closer look Net_IDNA2 is only used as a fallback when idn_to_{ascii,utf8}()
> do not exist. Roundcube has a hard dependency on php-intl already, so
> as far as Debian is concerned the part using Net_IDNA2 is dead code. I
> therefore drop my interest in having php-net-idna2 in Bullseye and
> restore the RC severity :-)
>
> Appologies for the noise
>
I filed an RM bug (#979829) and CCed all uploaders and participants of
this bug.
--
Sunil
OpenPGP_signature
Description: OpenPGP digital signature
Bug#979825: chromium: Chromium freezes on startup
Package: chromium
Version: 87.0.4280.141-0.1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
Chromium freezes on start up, requiring it to be killed, and making it
completely unusable.
Exactly the same with clean temporary profile.
Console output:
$ chromium --temp-profile
Using temporary profile: /tmp/tmp.7HqrY9kdHm
[4080619:4080655:0111/130724.593825:ERROR:nss_util.cc(283)] After loading Root
Certs, loaded==false: NSS error code: -8018
libva error: vaGetDriverNameByIndex() failed with unknown libva error,
driver_name = (null)
[4080617:4080617:0111/130724.619909:ERROR:vaapi_wrapper.cc(541)] vaInitialize
failed: unknown libva error
[4080617:4080617:0111/130724.640757:ERROR:sandbox_linux.cc(374)]
InitializeSandbox() called with multiple threads in process gpu-process.
[4080588:4080588:0111/130725.142104:ERROR:CONSOLE(1)] "Refused to execute
inline event handler because it violates the following Content Security Policy
directive: "script-src 'strict-dynamic'
'sha256-1+GSDjMMklBjZY0QiWq+tGupCvajw4Xbn46ect2mZgM='
'sha256-2mX1M62Fd0u8q0dQY2mRsK5S1NS9jJuQAvyE8tD0dkQ='
'sha256-EtIKSV82ixJHE3AzqhoiVbUGKG+Kd8XS0fFToow29o0='
'sha256-QSyFltV9X3gkyBrg+SMfKvZNXmqPQc6K4B6OYhTuXmw='
'sha256-ANdtIo91Yk/zh1YKZ+IXKP1pb00awOjEFMAUld02F6A='
'sha256-CbH+xPsBKQxVw5d9blISLDeuMSe1M+dJ4xfArFynIfw='
'sha256-lA+EURA/fC0TZq1ATYZvxIQHBc9iTAaBcI+dFMmTn9I='
'sha256-ezOZE3GsFiiFM39LE8bQs5vdJyeJAqh3r+5jHc7863I='". Either the
'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is
required to enable inline execution.
", source: chrome-search://local-ntp/local-ntp.html (1)
[4080617:4080617:0111/130728.834685:ERROR:gl_surface_presentation_helper.cc(259)]
GetVSyncParametersIfAvailable() failed for 1 times!
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (800, 'testing'), (750, 'unstable'), (500, 'unstable-debug'),
(500, 'testing-debug'), (500, 'oldstable-updates'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chromium depends on:
ii chromium-common87.0.4280.141-0.1
ii libasound2 1.2.4-1.1
ii libatk-bridge2.0-0 2.38.0-1
ii libatk1.0-02.36.0-2
ii libatomic1 10.2.1-3
ii libatspi2.0-0 2.38.0-2
ii libavcodec-extra58 [libavcodec58] 7:4.3.1-5
ii libavformat58 7:4.3.1-5
ii libavutil567:4.3.1-5
ii libc6 2.31-9
ii libcairo2 1.16.0-5
ii libcups2 2.3.3op1-5
ii libdbus-1-31.12.20-1
ii libdrm22.4.103-2
ii libevent-2.1-7 2.1.12-stable-1
ii libexpat1 2.2.10-1
ii libflac8 1.3.3-2
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgbm120.3.2-1
ii libgcc-s1 10.2.1-3
ii libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii libglib2.0-0 2.66.4-1
ii libgtk-3-0 3.24.24-1
ii libharfbuzz0b 2.6.7-1
ii libicu67 67.1-5
ii libjpeg62-turbo1:2.0.5-2
ii libjsoncpp24 1.9.4-4
ii liblcms2-2 2.9-4+b1
ii libminizip11.1-8+b1
ii libnspr4 2:4.29-1
ii libnss32:3.60-1
ii libopenjp2-7 2.3.1-1
ii libopus0 1.3.1-0.1
ii libpango-1.0-0 1.46.2-3
ii libpangocairo-1.0-01.46.2-3
ii libpng16-161.6.37-3
ii libpulse0 14.0-2
ii libre2-9 20201101+dfsg-2
ii libsnappy1v5 1.1.8-1
ii libstdc++6 10.2.1-3
ii libwebp6 0.6.1-2+b1
ii libwebpdemux2 0.6.1-2+b1
ii libwebpmux30.6.1-2+b1
ii libx11-6 2:1.6.12-1
ii libx11-xcb12:1.7.0-1
ii libxcb11.14-2.1
ii libxcomposite1 1:0.4.5-1
ii libxdamage11:1.1.5-2
ii libxext6 2:1.3.3-1.1
ii libxfixes3 1:5.0.3-2
ii libxml22.9.10+dfsg-6.3+b1
Bug#979829: RM: php-net-idna2 -- ROM; unused, no reverse depends
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This package was uploaded as part of effort to get GNU Social into Debian. There is currently no active interest in uploading GNU social. No other packages are currently using this library. Discussion on whether to keep the package as done at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979156 Please remove the package from unstable. Thanks, - -- Sunil -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl/8nDoRHHN1bmlsQG1l ZGhhcy5vcmcACgkQQ+oc/wqnxfL0GA/6Atcwno5WTLVNfSaPSD+WWYjgfpCjrHOq ZAPMHkoBi2c17ZCW94Xi8v8vCzQ9ZE1rSM6ak3nv8mOm4jbzao0S9maD29fc4cAi djllnKOt44l/PymB0NZ8RllXL0hKHwfQeYXMUhSe3lC+q01DB93db9PtbSFy72QA Nk1ExLIByy5Qhi5EaSiqvFAzbfk/gZAVJUSnw4MinahhOy6I53Z3vK6P4ce30GKE 4vlbXBRSOieE41Qb0hjToibwqvROXE4iQYPoTR0ctUe+qBwLlheSG1f8QuFtAoc3 HxaIm1wYR1ZVc1Jvx2TJvIKBeCpaLYHT+N5mXSLLUI3kNBn+1j/5aYjTpvsDiLmw wUQeFsRNT7spu0vFntA4DD7FqBR+5SZodjOpNyixrkVqiwtXG9mbZQXtfI7zZeAm wdzDsZkNf4zjb14UY51TSEq5+yhbAYyoNI+bdZbd/RKqzhvLaHLnUOrcmzeD8yz2 OfWdgRh917++Dxtn1EYKqYPY5Ej3SPq0558D+U58hPFQpqqibxstBW4Fz42Kmc9A yfTd0UkRwApO9dgoYMEyK0GAa4rLgqSpqbDoNtoJhTBPiAnaZUNudpzCJyrHOWlO GIOoMVwx2Y1QQcDyjX4dArTcvJH4+4dyTw8bf6p16+eRsOsf47sntR9RnxxIruAj J43kqAA7rOs= =qsVb -END PGP SIGNATURE-
Bug#979824: Burp utest Timeout
Package: Burp Version 2.2.18-8 Some autopkgtests for burp are failing due to a timeout in the test_attribs utest. This has already been addressed upstream at https://github.com/grke/burp/commit/e57878cfad335ffe6b439338ea546060aca71712 by increasing the timeout in utest/test_attribs.c from 5 seconds to 10. I suggest increasing this timeout value to reflect the upstream change.
Bug#979826: slic3r-prusa: Embeddeding a code copy of catch2
Package: prusa-slicer
Version: 2.2.0+dfsg1-3
Severity: normal
Tags: patch
Justification: Policy 4.13
Dear Maintainer,
slic3r-prusa embeds catch2, and a quite old one, too.*
Policy §4.13 asks to not use convienience copies, especially when
it has been packaged already.
The attached patch uses the packaged one (and make that a sure thing by
removing the embedded code copy.
(As you are already dfsg-repacking, you probably want to add it to
Files-Excluded with the next new upstream version;
this is _not_ in my patch)
--
Cheers
tobi
* convenience copy: 2.9.2 g2c869e1; Debian archive: 2.13.4
PS: Thanks for maintaining prusa-slicer; I use it regularily :)
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages prusa-slicer depends on:
ii fonts-noto-hinted 20201109-1
ii libboost-chrono1.71.0 1.71.0-7+b1
ii libboost-filesystem1.71.0 1.71.0-7+b1
ii libboost-locale1.71.0 1.71.0-7+b1
ii libboost-log1.71.0 1.71.0-7+b1
ii libboost-regex1.71.0 [libboost-regex1.71.0-icu67] 1.71.0-7+b1
ii libboost-thread1.71.0 1.71.0-7+b1
ii libc6 2.31-4
ii libcurl3-gnutls7.72.0-1
ii libexpat1 2.2.10-1
ii libgcc-s1 10.2.0-19
ii libgl1 1.3.2-1
ii libglew2.1 2.1.0-4+b1
ii libglu1-mesa [libglu1] 9.0.1-1
ii libgmp10 2:6.2.1+dfsg-1
ii libilmbase25 2.5.3-2
ii libmpfr6 4.1.0-3
ii libnlopt0 2.7.0-4+b2
ii libopenvdb7.1 7.1.0-2+b3
ii libstdc++6 10.2.0-19
ii libtbb22020.3-1
ii libwxbase3.0-0v5 3.0.5.1+dfsg-2
ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-2
prusa-slicer recommends no packages.
prusa-slicer suggests no packages.
-- no debconf information
diff -Naur archive/slic3r-prusa-2.2.0+dfsg1/debian/clean
slic3r-prusa-2.2.0+dfsg1/debian/clean
--- archive/slic3r-prusa-2.2.0+dfsg1/debian/clean 1970-01-01
01:00:00.0 +0100
+++ slic3r-prusa-2.2.0+dfsg1/debian/clean 2021-01-11 19:05:11.022641604
+0100
@@ -0,0 +1,2 @@
+cmake/modules/Catch2/Catch.cmake
+tests/catch2/*
diff -Naur archive/slic3r-prusa-2.2.0+dfsg1/debian/control
slic3r-prusa-2.2.0+dfsg1/debian/control
--- archive/slic3r-prusa-2.2.0+dfsg1/debian/control 2020-09-27
19:13:24.0 +0200
+++ slic3r-prusa-2.2.0+dfsg1/debian/control 2021-01-11 19:05:45.907515936
+0100
@@ -4,6 +4,7 @@
Maintainer: Debian 3-D Printing Packages
<3dprinter-gene...@lists.alioth.debian.org>
Uploaders: Chow Loong Jin
Build-Depends: debhelper (>= 9.20120312),
+ catch2,
cmake,
help2man,
libboost-all-dev,
diff -Naur archive/slic3r-prusa-2.2.0+dfsg1/debian/patches/series
slic3r-prusa-2.2.0+dfsg1/debian/patches/series
--- archive/slic3r-prusa-2.2.0+dfsg1/debian/patches/series 2020-09-27
19:13:24.0 +0200
+++ slic3r-prusa-2.2.0+dfsg1/debian/patches/series 2021-01-11
19:17:25.653044397 +0100
@@ -1,2 +1,3 @@
Move-Slic3r-data-to-usr-share-slic3r-prusa.patch
Install-XS-files-into-usr-lib-slic3r-prusa3d.patch
+use-packaged-catch2.patch
diff -Naur
archive/slic3r-prusa-2.2.0+dfsg1/debian/patches/use-packaged-catch2.patch
slic3r-prusa-2.2.0+dfsg1/debian/patches/use-packaged-catch2.patch
--- archive/slic3r-prusa-2.2.0+dfsg1/debian/patches/use-packaged-catch2.patch
1970-01-01 01:00:00.0 +0100
+++ slic3r-prusa-2.2.0+dfsg1/debian/patches/use-packaged-catch2.patch
2021-01-11 19:06:42.160925422 +0100
@@ -0,0 +1,29 @@
+--- a/tests/CMakeLists.txt
b/tests/CMakeLists.txt
+@@ -4,15 +4,8 @@
+ set(TEST_DATA_DIR ${CMAKE_CURRENT_SOURCE_DIR}/data)
+ file(TO_NATIVE_PATH "${TEST_DATA_DIR}" TEST_DATA_DIR)
+
+-add_library(Catch2 INTERFACE)
+-list (APPEND CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/modules/Catch2)
+-target_include_directories(Catch2 INTERFACE ${CMAKE_CURRENT_LIST_DIR})
+-add_library(Catch2::Catch2 ALIAS
Bug#979828: minidlna: Daemon fails after logrotate (SIGHUP)
Package: minidlna Version: 1.3.0+dfsg-1 Severity: important 1.3.0 uses new log reopen logic (from upstream). Bug when we send SIGHUP to main process daemon stops responding. Need to debug the problem. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (670, 'stable-updates'), (670, 'stable'), (630, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.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 minidlna depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii libavformat587:4.1.6-1~deb10u1 ii libavutil56 7:4.1.6-1~deb10u1 ii libc62.28-10 ii libexif120.6.21-5.1+deb10u5 ii libflac8 1.3.2-3 ii libid3tag0 0.15.1b-14 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii libogg0 1.3.2-1+b1 ii libsqlite3-0 3.27.2-3+deb10u1 ii libvorbis0a 1.3.6-2 ii lsb-base 10.2019051400 minidlna recommends no packages. minidlna suggests no packages.
Bug#979575: ispell 3.4.01 breaks affix files of igerman98 and hkgerman
reassign 979694 ispell 3.4.01-1 reassign 979746 ispell 3.4.01-1 forcemerge 979575 979694 979746 affects 979575 ispanish thanks El dom, 10 ene 2021 a las 23:02, Agustin Martin () escribió: > > El dom, 10 ene 2021 a las 22:39, Robert Luberda () > escribió: > > > > reassign 979549 ispell 3.4.01-1 > > reassign 979565 ispell 3.4.01-1 > > forcemerge 979575 979549 979565 > > affects 979575 ingerman iogerman ifrench iesperanto iswiss > > tags 979575 pending fixed-upstream > > thanks > > > > > > Roland Rosenfeld pisze: > > > > > > In the meantime upstream maintainer released a version 3.4.02 on > > > > Yes, I've noticed it this morning, and it looks like upgrading to that > > version fixes the issue. > > This may also be causing #979694. Confirmed, ispell 3.4.02 fixes this problem. Reassigning and forcemerging #979575 and #979746 with this bug report, so everything is marked as fixed. Regards, -- Agustin
Bug#979823: catch2: diff for NMU version 2.13.4-1.1
Control: tags 979823 + patch Control: tags 979823 + pending Dear maintainer, I've prepared an NMU for catch2 (versioned as 2.13.4-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. (It is a no-change source only upload) Regards. diff -Nru catch2-2.13.4/debian/changelog catch2-2.13.4/debian/changelog --- catch2-2.13.4/debian/changelog 2020-12-29 21:12:46.0 +0100 +++ catch2-2.13.4/debian/changelog 2021-01-11 19:24:37.0 +0100 @@ -1,3 +1,11 @@ +catch2 (2.13.4-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * No-Change-Source-Only upload to allow testing migration testing. +(Closes: #979823) + + -- Tobias Frost Mon, 11 Jan 2021 19:24:37 +0100 + catch2 (2.13.4-1) unstable; urgency=medium * New upstream release
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
Simon, On Sun, Jan 10, 2021 at 08:03:18PM +, Simon McVittie wrote: > I wouldn't want to give a ruling that would be interpreted as precedent to > (effectively) overrule multiple maintainer decisions (whether they're > decisions by a single maintainer in multiple packages, or multiple > maintainers' decisions in multiple packages) without at least being aware > of how many packages and decisions we are affecting - similar to the > principle that when the Policy editors add a new normative requirement, > they usually want to know how many packages were compliant with the old > Policy but are considered non-compliant under the new Policy. [...] > However, I think we would be reluctant to give a general ruling like that, > because it would not always be correct. systemd is quite featureful and > its interface is quite large (if I understand correctly, this is one of > the major things that people who would prefer a different init system > dislike about it). Different packages use different subsets of that > interface, sometimes larger[1] than the subset that can be provided by > elogind (because elogind closely resembles systemd-logind, and by design > the other parts of systemd's interface are outside its scope). The extent > to which the various parts of the interface are required by the dependent > package (whether they would be Depends, Recommends, Suggests or nothing, > if they were represented by separate dependencies) also varies. > > dbus-user-session is one concrete example of a package that needs a > working `systemd --user` instance per uid (a per-uid user-service > manager), and so will not do what its (informal) specification > says if it is forced to be installed on non-systemd systems - > so replacing its libpam-systemd dependency with > "default-logind | logind" would be incorrect. If that dependency > was replaced, the replacement would have to include something like > "libpam-systemd | libpam-start-dbus-daemon-per-uid", where the latter > doesn't currently exist. Of course you are quite correct that libpam-systemd provides access to 'systemd --user' which libpam-elogind does not and can not. In unstable the list of packages with a hard libpam-systemd dependency is now quite small. Both dbus-user-session (as you say) and gdm3 require 'systemd --user' and support for elogind has quite rightly been refused by the maintainers on that basis. nix-setup-systemd is clearly systemd dependent. 2 packages are empty metapackages[1] with specific purpose that I would not expect to support elogind. That leaves udisks2 and network-manager as the only outstanding packages in which elogind support is possible but unavailable. As in the case of network-manager, I can confirm that my testing of udisks2 shows it works with libpam-elogind without issue. Obviously Michael is maintainer of both pacakges. In the absence of public comment or engagement from him I do not want to infer his motives. However, the end of his submission to the tech-ctte relayed by Elana states > On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote: [...] > elogind is very difficult to support in its current state (see the > following bugs: [2] [3] [4] [5]), which is why Michael does not want to > maintain support for it. I have already made the point that[2] the bugs he referenced have been addressed and do not represent a technical reason why elogind should not be supported. I completely understand that the tech-ctte would not want to make a ruling that could be over generalised. But I don't think that is what is being asked for (although Matthew may want to clarify this). This is about securing implementation of the GR result. If there is a technical reason which prevents a package working with elogind I completely agree that it would be wrong for it to make use of the logind virtual packages. Mark [1] progress-linux-base-system and debian-cloud-images-packages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075#224
Bug#969264: (no subject)
Hi, I think those two bugs are not related. I also get that "iwl-debug-yoyo" error, but without the firmware load error and have no problem at all using the WiFi. For reference, the exact messages are: [ 3.459322] iwlwifi :04:00.0: firmware: direct-loading firmware iwlwifi-7260-17.ucode [ 3.459554] iwlwifi :04:00.0: loaded firmware version 17.3216344376.0 7260-17.ucode op_mode iwlmvm [ 3.459568] iwlwifi :04:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2) [ 3.638557] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 [ 3.666215] iwlwifi :04:00.0: base HW address: d8:fc:93:b8:ff:06 [ 3.908366] iwlwifi :04:00.0 wlp4s0: renamed from wlan0 Best regards, Hadrien
Bug#979823: catch2: Needs source-only upload
Package: src:catch2 Version: 2.13.4-1 Severity: source Dear Maintainer, as the tracker says, catch2 needs a source-only upload to migrate to testing. (I maybe do an NMU targeting DELAYED/2 later) -- tobi
Bug#979822: postgresql-13: Claims to connect to port 5434 but does not
Package: postgresql-13 Version: 13.1-1+b1 Severity: normal Short bug report: = from the postregsql log: 2021-01-11 18:20:07.039 CET [969840] LOG: PostgreSQL 13.1 (Debian 13.1-1+b1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.0-18) 10.2.0, 64-bit startet 2021-01-11 18:20:07.039 CET [969840] LOG: erwarte Verbindungen auf IPv4-Adresse »127.0.0.1«, Port 5434 (in english: expecting connection on IPv4 address "127.0.0.1", port 5434). 2021-01-11 18:20:07.078 CET [969840] LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen (in english: Database system is ready to accept connections) However: netstat -nlp | grep 5432 And clients complain that connection is not possible on that port. Long version: (aka: What lead up to this) = I'm running postgresql for ages. Until a few days ago I had version 11, 12 and 13 installed. The client was from 13, the server was running version 11. I intended to upgrade the server but made a mistake: I dropped the cluster on version 11, not 13 to prepare the upgrade. As I'm regularly backing up (including database dumps) I decided to simply (probably bad idea?) import the dump into version 13. However, I could not connect to the database afterwards. I removed postgresql 11 and 12, but no change. After (finally) reading the man page of pg_wrapper, I could connect. However, I needed to explicitly pass "--cluster 13/main" to psql. I did this, but found out that I could work around this explicit flag by adding helge * 13 main* to /etc/postgresql-common/user_clusters (This file was untouched before). However, this does not help if I try to acces via other methods, like in perl scripts (same user) or in PHP scripts (different user, added that in user_clusters as well). So I'm now trying to track this down, but to no avail so far. What really makes me think in circles is that the server happily tells me he is listening on port 5434 but actually does not, so I'm a bit lost how to proceed debugging this. If you have an idea, besides the bug reported above, how to revert to the 11 behaviour (simply connecting to the db server running on port 5434 without needing to edit user_clusters and other files) I would be more than happy :-)) [I have modified pg_hba.conf, but I tried both with the stock install and the version of "pg_hba.conf" I used with postgresql-11, no change detected both in behaviour and (non) error output] -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.3 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgresql-13 depends on: ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-9 ii libgcc-s1 10.2.1-3 ii libgssapi-krb5-2 1.18.3-4 ii libicu67 67.1-5 ii libldap-2.4-2 2.4.56+dfsg-1 ii libllvm11 1:11.0.0-5+b1 ii libpam0g 1.3.1-5 ii libpq5 13.1-1+b1 ii libselinux13.1-2+b2 ii libssl1.1 1.1.1i-1 ii libstdc++6 10.2.1-3 ii libsystemd0247.2-4 ii libuuid1 2.36.1-4 ii libxml22.9.10+dfsg-6.3+b1 ii libxslt1.1 1.1.34-4 ii locales2.31-9 ii postgresql-client-13 13.1-1+b1 ii postgresql-common 223 ii ssl-cert 1.1.0 ii tzdata 2020f-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages postgresql-13 recommends: pn sysstat postgresql-13 suggests no packages. -- debconf information: postgresql-13/postrm_purge_data: true -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#956423: Bullseye freeze is coming soon
Hi all, Bullseye freeze is coming and we still have problems with node-request removal. In particular, node-jsdom is not easy to patch. I tried a patch (not approved by upstream) but it needs a lot of unavailable Node.js modules. Looking at the following list, it seems that only node-jsdom is important to update, others have no important reverse dependencies AFAIK, haven't they? List of problems (from dak): # Broken Depends: node-jsdom: node-jsdom node-jsonld: node-jsonld node-matrix-js-sdk: node-matrix-js-sdk node-millstone: node-millstone node-yarnpkg: yarnpkg # Broken Build-Depends: node-client-sessions: node-request node-jsdom: node-request node-matrix-js-sdk: node-request node-opencv: node-request node-request-promise-core: node-request node-yarnpkg: node-request (>= 2.88.1-5~)
Bug#979821: firefox-esr: Try to read policies.json from wrong directory
Package: firefox-esr
Version: 78.6.1esr-1~deb10u1
Severity: normal
Dear maintainer.
My firefox-esr is a little bit confused the correct location of "policies.json".
Mozilla's page
https://support.mozilla.org/en-US/kb/managing-policies-linux-desktops
says:
1. Create a file called policies.json with your policies.
2. Place this file in firefox/distribution where "firefox"
is the installation directory for Firefox. (This will
vary per distribution).
In the Debian, place is definetely under /etc. Firefox-esr's debian package
creates /etc/firefox-esr :
pi@raspberrypi:~ $ dpkg -L firefox-esr |grep etc
/etc
/etc/firefox-esr
/etc/firefox-esr/firefox-esr.js
but try to read policies.json from /etc/firefox:
pi@raspberrypi:~ $ grep "/etc/fi" firefox.strace
faccessat(AT_FDCWD, "/etc/firefox/policies/policies.json", F_OK) = -1 ENOENT
(No such file or directory)
and this is the problem, because it is not documented or it is not the
directory created by
debian installer. And anyway, strace should not be a end user tool to find out
location of
fundamendal configuration files.
My suggestion is:
1. Place this file to /etc/firefox-esr/polcies
2. Document it
3. (Optionally) Put into this policies.json
{"policies":{"DisableAppUpdate":true}}
because an end-user-program should not to try
update itself. It is matter of a package manager.
Thanks in advance
-- Package-specific info:
-- Addons package information
-- System Information:
Debian Release: 10.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 5.10.5-v8+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_DK, LC_CTYPE=en_DK (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages firefox-esr depends on:
ii debianutils 4.8.6.1
ii fontconfig 2.13.1-2
ii libatk1.0-0 2.30.0-2
ii libc6 2.28-10
ii libcairo-gobject2 1.16.0-4+rpt1
ii libcairo2 1.16.0-4+rpt1
ii libdbus-1-3 1.12.20-0+deb10u1
ii libdbus-glib-1-20.110-4
ii libevent-2.1-6 2.1.8-stable-4
ii libffi6 3.2.1-9
ii libfontconfig1 2.13.1-2
ii libfreetype62.9.1-3+deb10u2
ii libgcc1 1:8.3.0-6
ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii libglib2.0-02.58.3-2+deb10u2
ii libgtk-3-0 3.24.5-1+rpt2
ii libpango-1.0-0 1.42.4-8~deb10u1
ii libstdc++6 8.3.0-6
ii libx11-62:1.6.7-1+deb10u1
ii libx11-xcb1 2:1.6.7-1+deb10u1
ii libxcb-shm0 1.13.1-2
ii libxcb1 1.13.1-2
ii libxcomposite1 1:0.4.4-2
ii libxdamage1 1:1.1.4-3+b3
ii libxext62:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxrender1 1:0.9.10-1
ii procps 2:3.3.15-2
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages firefox-esr recommends:
ii libavcodec58 7:4.1.6-1~deb10u1+rpt1
Versions of packages firefox-esr suggests:
pn fonts-lmodern
pn fonts-stix | otf-stix
ii libcanberra0 0.30-7
ii libgssapi-krb5-2 1.17-3+deb10u1
ii libgtk2.0-02.24.32-3+rpt1
ii pulseaudio 12.2-4+deb10u1+rpi3
-- no debconf information
Bug#979563: gitlab: my instance work great after upgrade to 13.5.6.1!
Package: gitlab Followup-For: Bug #979563 Dear Maintainer, My instance work great after upgrade to 13.5.6.1! I can see the content of folder and files on UI. I can fetch, push, etc. I added versions off packages if I use, maby will help you. If you want to give you more info, tell me. Dragos -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gitlab depends on: ii asciidoctor 2.0.10-2 ii bc 1.07.1-2+b2 ii bundler 2.2.0~rc.2-6 ii bzip21.0.8-4 ii dbconfig-pgsql 2.0.17 ii debconf [debconf-2.0]1.5.74 ii fonts-font-awesome [node-font-awesome] 5.0.10+really4.7.0~dfsg-4 ii gitlab-common13.4.6+dfsg1-2 ii gitlab-workhorse 8.46.0+debian-1 ii libjs-bootstrap4 [node-bootstrap]4.5.2+dfsg1-4 ii libjs-codemirror [node-codemirror] 5.59.0+~cs0.23.105-1 ii libjs-pdf [node-pdfjs-dist] 2.6.347+dfsg-3 ii libjs-popper.js [node-popper.js] 1.16.1+ds-2 ii libruby2.7 [ruby-json] 2.7.2-3 ii lsb-base 11.1.0 ii nginx1.18.0-6 ii nginx-extras [nginx] 1.18.0-6+b1 ii node-autosize4.0.2~dfsg1-5 ii node-axios 0.21.1+dfsg-1 ii node-babel-loader8.2.2-3 ii node-babel7 7.12.11+~cs150.141.84-3 ii node-brace-expansion 2.0.0-1 ii node-cache-loader4.1.0+~cs2.0.0-1 ii node-chart.js2.9.4+dfsg+~cs2.10.1-3 pn node-clipboard ii node-compression-webpack-plugin 6.1.1-1 ii node-copy-webpack-plugin 5.1.2+~cs9.0.2-4 ii node-core-js 3.8.2-1 ii node-css-loader 5.0.1+~cs14.0.5-1 ii node-d3 5.16.0-4 ii node-d3-scale2.2.2-3 ii node-d3-selection1.4.0-6 pn node-dateformat pn node-deckar01-task-list ii node-exports-loader 1.1.1-2 ii node-file-loader 6.2.0-2 pn node-fuzzaldrin-plus ii node-glob7.1.6+~7.1.3-1 pn node-imports-loader ii node-jed 1.1.1-2 ii node-jquery 3.5.1+dfsg+~3.5.5-5 pn node-jquery-ujs pn node-js-cookie ii node-js-yaml 3.14.0+dfsg-3 ii node-jszip 3.5.0+dfsg-1 ii node-jszip-utils 0.0.2+dfsg-2 ii node-katex 0.8.3+dfsg-2 ii node-lodash 4.17.20+dfsg+~cs8.31.172-1 ii node-marked 0.8.0+ds+repack-2 ii node-mermaid 8.7.0+ds+~cs27.17.17-2 ii node-minimatch 3.0.4+~3.0.3-1 ii node-miragejs0.1.41+~cs5.6.6-4 ii node-mousetrap 1.6.5~ds-1 ii node-prismjs 1.11.0+dfsg-4 ii node-prosemirror-markdown1.4.4-2 pn node-prosemirror-model pn node-raven-js ii node-raw-loader 4.0.2-2 ii node-style-loader2.0.0-2 ii node-three-orbit-controls82.1.0-3 ii node-three-stl-loader1.0.6-3 ii node-timeago.js 4.0.2-3 pn node-underscore ii node-url-loader 4.1.1-3 ii node-uuid8.3.2+~8.3.0-3 ii node-vue
Bug#975665: Raising the bug's severity
Control: tags -1 patch There is a patch available; with it applied it builds here locally (until it hits #975198) https://build.opensuse.org/package/view_file/science/PrusaSlicer/PrusaSlicer-pr4340-boost-1-73.patch?expand=0 -- tobi
