Bug#955032: RM: orthanc-dicomweb [s390x] -- RoM; ANAIS
Package: ftp.debian.org Severity: normal The "orthanc" package for s390x was removed, because of issue #954317: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954317 As this package depends on "orthanc", it must also be removed.
Bug#955034: RM: orthanc-postgresql [s390x] -- RoM; ANAIS
Package: ftp.debian.org Severity: normal The "orthanc" package for s390x was removed, because of issue #954317: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954317 As this package depends on "orthanc", it must also be removed.
Bug#955033: RM: orthanc-mysql [s390x] -- RoM; ANAIS
Package: ftp.debian.org Severity: normal The "orthanc" package for s390x was removed, because of issue #954317: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954317 As this package depends on "orthanc", it must also be removed.
Bug#955035: RM: orthanc-webviewer [s390x] -- RoM; ANAIS
Package: ftp.debian.org Severity: normal The "orthanc" package for s390x was removed, because of issue #954317: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954317 As this package depends on "orthanc", it must also be removed.
Bug#944913: [Python-modules-team] Bug#944913: Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1
Hi, So I did the rebuild. I did not rebuild packages that are not in testing (I usually don't rebuild them because there's so much brokenness among them). The logs for builds that succeeded with an unstable chroot, but failed with unstable + sphinx from experimental, are available at http://qa-logs.debian.net/2020/03/26/ I've also added http://qa-logs.debian.net/2020/03/26/00summary.txt that summarizes the failures. I can do the bug filing, but would need a template similar to https://salsa.debian.org/lucas/collab-qa-tools/-/blob/master/lib/collab-qa/log-parser.rb#L644 with probably a paragraph of explanation about the custom sphinx version, when you plan to upload to unstable, etc. Lucas On 25/03/20 at 23:31 -0400, Sandro Tosi wrote: > > I might be able to help, yes. You would need to: > > thanks! > > > 1/ provide me with a script that customizes a chroot to install the > > version you need (from experimental or from an unofficial repository). > > You can inspire from > > https://salsa.debian.org/lucas/collab-qa-tools/-/blob/master/modes/gcc10 > > so i'm not sure if your setup already contains `experimental` if it > does, `sphinx243` attached should do what you ask > > if experimental needs to be added to the APT sources, i'd need to know > what mirror to point it to (and then i'll follow what gcc10 does to > add it to the sources list) > > > 2/ provide me with the list of packages to build > > sphinx243.pkglist is my attempt at it, i got it from `dak` and then > parsing its output > > let me know if they are good or need tweaking, and definitely Dmitry > should have a look at them. > > Lucas, will you do the bug reporting or will you send back a list of > build logs for us to parse? > > Thanks! > > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#949389: nmh: after version upgrade, mh_build not run on outgoing messages
norman, sorry for the late response; i didn't find any time for nmh until now... On Mon, 20 Jan 2020 10:43:19 -0500, Norman Ramsey writes: >I tried forwarding message using `forw -mi`, then telling whatnow to send. >I expected mh_build to be run, as it would have been had I typed >`mime` to whatnow. (This is an improvement that was made a few >versions back.) > The feature worked as expected under Debian 9.11, but stopped >working after a fresh install of Debian 10.2. (A fresh install >was necessary, not an upgrade, because I was migrating from x86 to amd64.) 9 had nmh 1.6.something, 10 has 1.7.something. the NEWS file states that for 1.7 various bugs were fixed, e.g. "mhbuild no longer parses lines that start with # as directives with -nodirectives." in addition to that, automimeproc was removed in 1.6. the man page for forw (and others) was changed to say 'Note that nmh will not invoke mhbuild automatically; you must specifically give the command What now? mime prior to sending the draft.' before it mentioned automimeproc as alternative setup. your profile still sets automimeproc. i do concur that forw -mime, with a plain 'send' at the whatnowproc prompt does not translate #forw... directives; i just tried it with a trivial .mh_profile. however: as far as i can tell that is working as designed! man mh-mime says "All messages sent by send(1) will automatically be processed by mhbuild(1) before being passed to post(1) for message submission." followed by this crucial bit "It is important to note that when using mhbuild directives the user must run mhbuild outside of send to have it process directives; when being run by send, mhbuild is configured to not process directives so normal user text is not mistaken for a directive. When using directives a user typically uses the mime command at the “What now?” prompt to process them." this is related to the removal of automimeproc, which your mh_profile still refers to; and forw -mime, which does indeed generate mhbuild directives; the send manpage mentions that mhbuild is run with -auto, and the mhbuild manpage says that -auto implies -nodirectives. so, in 1.6 this worked because -nodirectives in mhbuild wasn't honored. in 1.7 -nodirectives wins. as far as i can tell from digging through the source, forw -mime will not work unless an explicit 'mime' step is given at the whatnowproc prompt. i cannot see a way anymore to convince whatnow to automate that step - the relevant source commit comment from before the 1.6 release states 'Remove automimeproc functionality; it's redundant now.' but it seems that's not quite the case in the forw -mime scenario. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol. -- Larry Wall signature.asc Description: Digital Signature
Bug#955031: Generated code is not compatible with golang-google-grpc-dev
Source: golang-goprotobuf Version: 1.3.4-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! After the upgrade to 1.3.4, the generated code is not usable with golang-google-grpc-dev currently in unstable. Both packages share a tight relationship. src/github.com/osrg/gobgp/api/gobgp.pb.go:9587:7: undefined: grpc.ClientConnInterface src/github.com/osrg/gobgp/api/gobgp.pb.go:9591:11: undefined: grpc.SupportPackageIsVersion6 src/github.com/osrg/gobgp/api/gobgp.pb.go:9651:5: undefined: grpc.ClientConnInterface src/github.com/osrg/gobgp/api/gobgp.pb.go:9654:27: undefined: grpc.ClientConnInterface - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.10 (SMP w/8 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl59mdYSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5O2EP/0pwGFl4HAKHMIKVi/2OHRtgtQ2GD2du ZY5h56Yi5yMNpUJzZ/cLE3Wydl7KyQhFkBtmUqVoUqPqwRhnxpHRJhEUfQEhoaj7 koKRojwaQwBGaQrfYiYB7SztsrpJsro7wZu2rYS/iBPp3f2LZXGOo2LtsXf9Rbk/ dhTuU5SIqTntxcYM8fSgqPpHgTYowpWfVH52vG4JQrx8a93vTjdY58W5VfGXeZ8r jaTebGmBF0b9ItvzVyilI+aOsFBwOwEgNRRYtWBBw8MzJQ1ja1UZdpVWuBz5lczi L9OQIfJhU4tAw0wNk9j2W1ARHijBQ4V/2UbcMBBFWWD2b56Z/o3tw37LBnuAoxP8 42zcg55mVTy5BlXs63CV5WuIpdhdkjNGQ0stkbiFccJifHdawJHIWnlb4kRsXQKv 6+zBHNbm6x0NHrsrPz3z/DP0uzdJnKHuTDtoBYEmSxx5tMPbX+M++CJlzqJkxUYB k6xrrBRyFh8lbSHgabbJeU0bBQa97HY/S3ij9xRWBlxCvb0BZTX0ykvS3qj1vmae KJrI5+EskcSJAmj0mF/iGC2p0aSHz4CGBpmCzxgkZXubqLXZpK3rg4LMi3vDw3/6 1bSpeUc1F+4T8N7E2dtO3h5GXV80lv5ccAKa2qgDa26am6R6iddHEJDLKy1KSMQu mcgd+ETX67Ui =1WW4 -END PGP SIGNATURE-
Bug#932456: libvirt-daemon-system: blockcommit => permission denied
Hello
Before blockcommit I do
aa-disable /etc/apparmor.d/libvirt/libvirt-`sudo virsh domuuid $activevm`
then
virsh blockcommit $activevm $disk --active --verbose --pivot
From: Kaulkwappe
Sent: Monday, March 23, 2020 9:55 PM
To: 932...@bugs.debian.org
Cc: pkg-libvirt-maintain...@lists.alioth.debian.org
Subject: Bug#932456: libvirt-daemon-system: blockcommit => permission denied
Dear Maintainer!
I can confirm that this bug (#932456) unfortunately still exists in Debian 10.3
(Buster) while using only default configurations, no custom paths (so all
images are placed in /var/lib/libvirt/images):
> root@root:~# virsh blockcommit {vm-name} vda --active --wait --pivot
> error: internal error: unable to execute QEMU command 'block-commit': Could
> not reopen file: Permission denied
> qemu-img version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u4)
> libvirtd (libvirt) 5.0.0
After some research I suspected the AppArmor configs to be the reason for the
permission error which corresponds to the research Robert Niederreiter has
already done on 13th October 2019 (Message #25):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932456#25
However, the behaviour does *not* disappear when AppArmor is disabled using
complain mode:
> apt install apparmor-utils
> aa-complain /usr/sbin/libvirtd
> aa-complain /etc/apparmor.d/libvirt/libvirt-{id}
But what I noticed is that the owner and rights of the guest XML files
(/run/libvirt/qemu/{vm-name}.xml) always change back to root:root and 0600 even
if "dynamic_ownership" is set to 0 in /etc/libvirt/qemu.conf. Since the other
file permissions look good I suspect this to have something to do with that
issue.
Setting "security_driver" in /etc/libvirt/qemu.conf to "none" or changing
"user" and "group" to root:root or to unprivileged:unprivileged did not solve
the issue.
This bug is critical because one is not able to create backups of the guests
without shutting them down.
Is there any workaround available?
Kind Regards,
Kaulkwappe
Bug#954256: [Python-modules-team] Bug
On Thu, 19 Mar 2020 12:20:05 + Scott Kitterman
wrote:
> Thanks. The virtualenv package needs updating following the recent pip
update. I'm working on it.
I can still replicate this with the new virtualenv. Here's the verbose
version for posterity:
Installing collected packages: setuptools, wheel
Created temporary directory: /tmp/pip-unpacked-wheel-w3e1u2qx
Creating /tmp/pip-build-env-htd82usc/overlay/bin
changing mode of /tmp/pip-build-env-htd82usc/overlay/bin/easy_install to
755
changing mode of /tmp/pip-build-env-htd82usc/overlay/bin/easy_install-3.8
to 755
Created temporary directory: /tmp/pip-unpacked-wheel-_pm79f2o
changing mode of /tmp/pip-build-env-htd82usc/overlay/bin/wheel to 755
Successfully installed setuptools-46.1.3 wheel-0.34.2
Cleaning up...
Removed build tracker: '/tmp/pip-req-tracker-e53aaqlu'
Installing build dependencies ... done
Running command /tmp/venv/bin/python3 /tmp/venv/share/python-wheels/
pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py
get_requires_for_build_wheel /tmp/tmpqmbnti16
/tmp/venv/bin/python3: can't find '__main__' module in '/tmp/venv/share/
python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py'
Getting requirements to build wheel ... error
Cleaning up...
Removed file:///home/pypa from build tracker '/tmp/pip-req-tracker-e53aaqlu'
Removed build tracker: '/tmp/pip-req-tracker-e53aaqlu'
ERROR: Command errored out with exit status 1: /tmp/venv/bin/python3 /tmp/
venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/
_in_process.py get_requires_for_build_wheel /tmp/tmpqmbnti16 Check the logs
for full command output.
Exception information:
Traceback (most recent call last):
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/cli/
base_command.py", line 186, in _main
status = self.run(options, args)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/commands/
install.py", line 357, in run
resolver.resolve(requirement_set)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/
legacy_resolve.py", line 177, in resolve
discovered_reqs.extend(self._resolve_one(requirement_set, req))
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/
legacy_resolve.py", line 333, in _resolve_one
abstract_dist = self._get_abstract_dist_for(req_to_install)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/
legacy_resolve.py", line 265, in _get_abstract_dist_for
return self.preparer.prepare_editable_requirement(req)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/operations/
prepare.py", line 554, in prepare_editable_requirement
abstract_dist = _get_prepared_distribution(
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/operations/
prepare.py", line 95, in _get_prepared_distribution
abstract_dist.prepare_distribution_metadata(finder, build_isolation)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/distributions/
sdist.py", line 38, in prepare_distribution_metadata
self._setup_isolation(finder)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/distributions/
sdist.py", line 96, in _setup_isolation
reqs = backend.get_requires_for_build_wheel()
File "/tmp/venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/
pep517/wrappers.py", line 151, in get_requires_for_build_wheel
return self._call_hook('get_requires_for_build_wheel', {
File "/tmp/venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/
pep517/wrappers.py", line 245, in _call_hook
self._subprocess_runner(
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/utils/
subprocess.py", line 271, in runner
call_subprocess(
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/utils/
subprocess.py", line 242, in call_subprocess
raise InstallationError(exc_msg)
pip._internal.exceptions.InstallationError: Command errored out with exit
status 1: /tmp/venv/bin/python3 /tmp/venv/share/python-wheels/pep517-0.7.0-
py2.py3-none-any.whl/pep517/_in_process.py get_requires_for_build_wheel /tmp/
tmpqmbnti16 Check the logs for full command output.
signature.asc
Description: This is a digitally signed message part.
Bug#954402: m2crypto: FTBFS since openssl 1.1.1e
> So the test expects no error. Since the commit mention there is an > error where earlier there was none. From the Changes file: > > | *) Properly detect EOF while reading in libssl. Previously if we hit an EOF > |while reading in libssl then we would report an error back to the > |application (SSL_ERROR_SYSCALL) but errno would be 0. We now add > |an error to the stack (which means we instead return SSL_ERROR_SSL) and > |therefore give a hint as to what went wrong. > > OpenSSL 1.1.1d with the commit question leads to this behaviour. isnt this a regression in openssl then? why there's no RC bug filed against openssl and you filed this bug against a downstream package? i'm still not clear what you expect us to do with regards to m2crypto: should we skip the failing test? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#937521: pyrit: Python2 removal in sid/bullseye
Hey Marcos, On Thu, Mar 19, 2020 at 7:33 AM Marcos Fouces wrote: > > Hello Sandro > > Upstream seems a bit stalled but there is a patch (by Kimocoder from > aircrack project) to migrate it. You can see it here: > > https://github.com/JPaulMora/Pyrit/pull/593 > > As i have some time these days,i will try to test it a see if it is a > valid approach. i wanted to check in to see how your tests are going: do you have already a python3 pyrit? if not, how mich longer do you think it would take you? Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#950729: notmuch: Fails to build against ruby2.7
Package: src:notmuch Followup-For: Bug #950729 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I ran two builds and both succeeded. I wonder if this FTBFS is still valid. Regards, Daniel - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl59Z/0ACgkQS80FZ8KW 0F11vQ/6A2PluEdJThrmzqg1LTpZ2CIjMPyGvVxT3SKGPiB+79WLQdXiKgRrlfXG pDGDGB9EAVhJ8o+9KOVlzL+isdfZ0KJghOuSdTftmoyRYZsUyasZMG4H9mshocwG EB7RcLkshIS8TngTb3Wm2RHnFxmHXUqxfmd9arkzUfvu/ObtvhKocdivERmQxbYl CLxJlz/khwv1xY2JcboxyhY7WjbpcWST4W+9KkQlLR+FDzfMhMAa9PAciqJPJugD JHMvM+YYuex/EIwXqkciWcxK3mzZMmkh6oHzrCYO3QB/H9XJ3Lnm+LkoqNx+Ob7x XPW/75whPHDoGG/rdgaHWvAwMPwVAoOJ1dipJKMQdRDSuQhsUXwYQSfjjMwYHpMS BpBMc5ROFayU7df4MpbtEsbt0h5XvA1w182oeLkgOxhBHUI/o2fl/iA7osHwSfdP RCoa0RGBqWnwkhbaJO2zyp8+QeB4zt9cogTI8oMTcxsow1wi4Dox23ldA1AR26H4 dMAkCoHoub/6wyZzBOIDnuYb1aqEncJt++t4ERM4znXWof4gJenrhp20/Z/CkZHV SdF7iBCx+p4ardSE70oA3AE+vkL+mh3/mCSBIRyy/nUF/X/FoLbLjdv31aIUo7fz JV87bDMV4mbYJWqe57SbRgZ79H3BJUCgDR4nLLVtT2eP0/8GHyA= =OUVM -END PGP SIGNATURE-
Bug#955030: dpkg/man/*: Remove trailing whitespace in manuals
Package: dpkg-dev Version: 1.19.7 Severity: minor Tags: patch Dear Maintainer, Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z [ "test-groff" is a developmental version of "groff" ] Input file is ./man/deb-buildinfo.man troff: :41: warning: trailing space Input file is ./man/deb-changelog.man troff: :122: warning: trailing space Input file is ./man/dpkg-buildflags.man troff: :568: warning: trailing space Input file is ./man/dselect.man troff: :138: warning: trailing space ### The diff is from the current git repository at "git.dpkg.org". The patch is in the attachment. Signed-off-by: Bjarni Ingi Gislason --- man/deb-buildinfo.man | 2 +- man/deb-changelog.man | 2 +- man/dpkg-buildflags.man | 2 +- man/dselect.man | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) -- System Information: Debian Release: bullseye/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.19-1 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages dpkg-dev depends on: ii binutils 2.34-5 ii bzip2 1.0.8-2 ii libdpkg-perl 1.19.7 ii make 4.2.1-1.2 ii patch 2.7.6-6 ii perl 5.30.0-9 ii tar 1.30+dfsg-7 ii xz-utils 5.2.4-1+b1 Versions of packages dpkg-dev recommends: pn build-essential ii clang-8 [c-compiler] 1:8.0.1-9 ii clang-9 [c-compiler] 1:9.0.1-10 ii fakeroot 1.24-1 ii gcc [c-compiler] 4:9.2.1-3.1 ii gcc-10 [c-compiler] 10-20200312-2 ii gcc-7 [c-compiler] 7.5.0-5 ii gcc-8 [c-compiler] 8.4.0-1 ii gcc-9 [c-compiler] 9.3.0-3 ii gnupg2.2.19-3 ii gpgv 2.2.19-3 pn libalgorithm-merge-perl Versions of packages dpkg-dev suggests: pn debian-keyring -- no debconf information -- Bjarni I. Gislason >From e815c0d16fcca2f3f9d1e6c3abbf45625e22b72c Mon Sep 17 00:00:00 2001 From: Bjarni Ingi Gislason Date: Fri, 27 Mar 2020 00:51:05 + Subject: [PATCH] dpkg/man/*: Trim trailing whitespace in manuals Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z [ "test-groff" is a developmental version of "groff" ] Input file is ./man/deb-buildinfo.man .../git/groff/build/s-tmac/an-old.tmac:478: backtrace: macro 'BR' troff: :41: warning: trailing space Input file is ./man/deb-changelog.man .../git/groff/build/s-tmac/an-old.tmac:478: backtrace: macro 'BR' troff: :122: warning: trailing space Input file is ./man/dpkg-buildflags.man .../git/groff/build/s-tmac/an-old.tmac:478: backtrace: macro 'BR' troff: :568: warning: trailing space Input file is ./man/dselect.man .../git/groff/build/s-tmac/an-old.tmac:478: backtrace: macro 'BR' troff: :138: warning: trailing space Signed-off-by: Bjarni Ingi Gislason --- man/deb-buildinfo.man | 2 +- man/deb-changelog.man | 2 +- man/dpkg-buildflags.man | 2 +- man/dselect.man | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/man/deb-buildinfo.man b/man/deb-buildinfo.man index 4e72a5169..72ae484aa 100644 --- a/man/deb-buildinfo.man +++ b/man/deb-buildinfo.man @@ -38,7 +38,7 @@ Fields are delimited only by field tags. In other words, field text may be multiple lines in length, but the installation tools will generally join lines when processing the body of the field (except in case of the multiline fields -.BR Binary\-Only\-Changes ", " Installed\-Build\-Depends ", " Environment ", " +.BR Binary\-Only\-Changes ", " Installed\-Build\-Depends ", " Environment , .BR Checksums\-Md5 ", " Checksums\-Sha1 and .BR Checksums\-Sha256 , diff --git a/man/deb-changelog.man b/man/deb-changelog.man index 6b2ee7849..2e0f5b205 100644 --- a/man/deb-changelog.man +++ b/man/deb-changelog.man @@ -119,7 +119,7 @@ Is a one- or two-digit day of the month (\fB01\fP-\fB31\fP). .TP .I month Is one of: -.BR Jan ", " Feb ", " Mar ", " Apr ", " May ", " Jun ", " Jul ", " Aug ", " +.BR Jan ", " Feb ", " Mar ", " Apr ", " May ", " Jun ", " Jul ", " Aug , .BR Sep ", " Oct ", " Nov ", " Dec . .TP .I diff --git a/man/dpkg-buildflags.man b/man/dpkg-buildflags.man index 5d41bd57e..525ac067d 100644 --- a/man/dpkg-buildflags.man +++ b/man/dpkg-buildflags.man @@ -565,7 +565,7 @@ The accepted values are: \fB0\fP and \fB1\fP (default). .B %PKGCONFDIR%/buildflags.conf System wide configuration file. .TP -.BR $XDG_CONFIG_HOME/dpkg/buildflags.conf " or " +.BR $XDG_CONFIG_HOME/dpkg/buildflags.conf " or" .TQ .B $HOME/.config/dpkg/buildflags.conf User configuration file. diff --git a/man/dselect.man b/man/dselect.man index 0c963e23e..0d87f34dc 100644 --- a/man/dselect.man +++ b/man/dselect.man @@ -135,7 +135,7 @@ Optionally, aft
Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release
On Thu, 2020-03-26 at 21:32 +0100, Paul Gevers wrote: > maybe all the tracker needs is the freeze date and the release date. I guess that would probably do it yeah. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#955029: assimp: CMake Warning CMP0012 'if given arguments: "ON"' during 'find_package(assimp)'
Package: libassimp-dev Version: 5.0.1~ds0-1 Severity: normal File: assimp Tags: upstream Dear Maintainer, This package emits a CMake warning during `find_package(assimp)`. The bug is known upstream, and it has been fixed in this commit. https://github.com/assimp/assimp/commit/6ac8279977c3a54118551e549d77329497116f66 Would you be willing to apply that commit here? Instructions to reproduce: mkdir -p /tmp/assimp_bug/build cd /tmp/assimp_bug printf "cmake_minimum_required(VERSION 3.0)\nproject(assimp_bug)\nfind_package(assimp)" > CMakeLists.txt cd build cmake .. Output from the above: -- The C compiler identification is GNU 9.3.0 -- The CXX compiler identification is GNU 9.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Warning (dev) at /usr/lib/x86_64-linux-gnu/cmake/assimp-5.0/assimpTargets.cmake:54 (if): if given arguments: "ON" An argument named "ON" appears in a conditional statement. Policy CMP0012 is not set: if() recognizes numbers and boolean constants. Run "cmake --help-policy CMP0012" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/assimp-5.0/assimp-config.cmake:1 (include) CMakeLists.txt:3 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done -- Generating done -- Build files have been written to: /tmp/assimp_bug/build Cheers, Shane -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-91-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libassimp-dev:amd64 depends on: ii libassimp5 5.0.1~ds0-1 libassimp-dev:amd64 recommends no packages. libassimp-dev:amd64 suggests no packages. -- no debconf information
Bug#955028: dpkg/man/*: Fix misused two-fonts macros in manuals
Package: dpkg-dev Version: 1.19.7 Severity: minor Tags: patch Dear Maintainer, Correct the misuse of a two-fonts macro, which function is to 1) use the first font for each odd numbered argument and the second font for all others. 2) join the arguments without an intervening space. The output of nroff and troff is unchanged. The patch is based on the current git repository in "git.dpkg.org". ### THE PATCH IS IN THE ATTACHMENT. Signed-off-by: Bjarni Ingi Gislason --- man/deb-buildinfo.man | 2 +- man/deb-substvars.man | 4 ++-- man/deb-symbols.man | 2 +- man/deb.man | 2 +- man/dpkg-buildflags.man | 10 +- man/dpkg-buildpackage.man | 28 ++-- man/dpkg-checkbuilddeps.man | 2 +- man/dpkg-deb.man| 2 +- man/dpkg-distaddfile.man| 2 +- man/dpkg-genbuildinfo.man | 6 +++--- man/dpkg-genchanges.man | 2 +- man/dpkg-gencontrol.man | 2 +- man/dpkg-gensymbols.man | 16 man/dpkg-parsechangelog.man | 2 +- man/dpkg-scanpackages.man | 2 +- man/dpkg-shlibdeps.man | 6 +++--- man/dpkg-source.man | 12 ++-- man/dsc.man | 2 +- man/start-stop-daemon.man | 14 +++--- man/update-alternatives.man | 4 ++-- 20 files changed, 61 insertions(+), 61 deletions(-) -- System Information: Debian Release: bullseye/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.19-1 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages dpkg-dev depends on: ii binutils 2.34-5 ii bzip2 1.0.8-2 ii libdpkg-perl 1.19.7 ii make 4.2.1-1.2 ii patch 2.7.6-6 ii perl 5.30.0-9 ii tar 1.30+dfsg-7 ii xz-utils 5.2.4-1+b1 Versions of packages dpkg-dev recommends: pn build-essential ii clang-8 [c-compiler] 1:8.0.1-9 ii clang-9 [c-compiler] 1:9.0.1-10 ii fakeroot 1.24-1 ii gcc [c-compiler] 4:9.2.1-3.1 ii gcc-10 [c-compiler] 10-20200312-2 ii gcc-7 [c-compiler] 7.5.0-5 ii gcc-8 [c-compiler] 8.4.0-1 ii gcc-9 [c-compiler] 9.3.0-3 ii gnupg2.2.19-3 ii gpgv 2.2.19-3 pn libalgorithm-merge-perl Versions of packages dpkg-dev suggests: pn debian-keyring -- no debconf information -- Bjarni I. Gislason Correct the misuse of a two-fonts macro, which function is to 1) use the first font for each odd numbered argument and the second font for all others. 2) join the arguments without an intervening space. The output of nroff and troff is unchanged. The patch is in the attachment. Signed-off-by: Bjarni Ingi Gislason --- man/deb-buildinfo.man | 2 +- man/deb-substvars.man | 4 ++-- man/deb-symbols.man | 2 +- man/deb.man | 2 +- man/dpkg-buildflags.man | 10 +- man/dpkg-buildpackage.man | 28 ++-- man/dpkg-checkbuilddeps.man | 2 +- man/dpkg-deb.man| 2 +- man/dpkg-distaddfile.man| 2 +- man/dpkg-genbuildinfo.man | 6 +++--- man/dpkg-genchanges.man | 2 +- man/dpkg-gencontrol.man | 2 +- man/dpkg-gensymbols.man | 16 man/dpkg-parsechangelog.man | 2 +- man/dpkg-scanpackages.man | 2 +- man/dpkg-shlibdeps.man | 6 +++--- man/dpkg-source.man | 12 ++-- man/dsc.man | 2 +- man/start-stop-daemon.man | 14 +++--- man/update-alternatives.man | 4 ++-- 20 files changed, 61 insertions(+), 61 deletions(-) diff --git a/man/deb-buildinfo.man b/man/deb-buildinfo.man index 0a77c1bf6..4e72a5169 100644 --- a/man/deb-buildinfo.man +++ b/man/deb-buildinfo.man @@ -204,7 +204,7 @@ For dependencies coming from the source control fields, all dependency alternatives and all providers of virtual packages depended on will be included. .TP -.BR Environment: +.B Environment: .TQ .I " variable-list" The list of environment variables that are known to affect the package build diff --git a/man/deb-substvars.man b/man/deb-substvars.man index 5f9ef67d2..aca9e06f1 100644 --- a/man/deb-substvars.man +++ b/man/deb-substvars.man @@ -94,7 +94,7 @@ symbol (comments) are ignored. Additionally, the following standard variables are available: .TP -.BI Arch +.B Arch The current host architecture (i.e. the architecture the package is being built for, the equivalent of \fBDEB_HOST_ARCH\fP). .TP @@ -166,7 +166,7 @@ These variables are only available when generating binary control files. .TP .BI F: fieldname The value of the output field -.IR fieldname +.I fieldname (which must be given in the canonical capitalisation). Setting th
Bug#955027: php-recode: uninstallable due to php7.4-recode dependency
Package: php-recode Version: 2:7.4+74 Severity: grave Justification: renders package unusable Dear Maintainer, The php-recode package is currently not installable because it depends on php7.4-recode, which doesn't exist. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages php-recode depends on: ii php-common 2:74 ii php7.3-recode 7.3.15-3 php-recode recommends no packages. php-recode suggests no packages. -- no debconf information
Bug#953903: smbnetfs: Switch from deprecated to
fixed in smbnetfs-0.6.2 On Sat, 14 Mar 2020 18:41:45 +0100 Guillem Jover wrote: > Package: smbnetfs > Version: 0.6.1-1 > Severity: important > User: a...@packages.debian.org > Usertags: libattr-drop-attr-xattr-header > > Hi! > > This package uses the deprecated header (from libattr) > instead of the one provided now by glibc . > > The former header has been removed in upstream libattr, but got > reintroduced in Debian to avoid breakage just before the Debian buster > freeze. But I'd like to be able to remove it in Debian too, so that > the interface can be synced with upstream. > > It looks like this the only header used by this package from libattr, > so you should be able to drop the dependency on libattr entirely, as > glibc should be providing all that is needed now. > > Thanks, > Guillem
Bug#954901: ghostscript: runtime error: malloc(): invalid size (unsorted)
Dear Maintainer, I tried to collect some more information and might have found something. The allocator aborts at the backtrace below. A valgrind run points to the same function txt_add_fragment. There is seems that in line 2121 the allocation takes place with 12 bytes total, then a memset is done with 12 bytes. But in line 2126 the memcpy is done with 24 bytes. This is because allocation is done with penum->TextBufferIndex == 3, but the memcpy uses penum->text.size == 6. (For the given input file.) The same pattern in lines 2134 to 2139. But I have no clue if the variables are the right ones, or contain wrong values. It might be related to this upstream bug, which touches the same lines: https://bugs.ghostscript.com/show_bug.cgi?id=701877 Kind regards, Bernhard https://sources.debian.org/src/ghostscript/9.52%7Edfsg-1/devices/vector/gdevtxtw.c/#L2121 https://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=devices/vector/gdevtxtw.c;h=87f9355d8771e1fa546b4eb687ae4078ef2abdff;hb=HEAD#l2121 2121 penum->text_state->Widths = (float *)gs_malloc(tdev->memory->stable_memory, 2122 penum->TextBufferIndex, sizeof(float), "txtwrite alloc widths array"); 2123 if (!penum->text_state->Widths) 2124 return gs_note_error(gs_error_VMerror); 2125 memset(penum->text_state->Widths, 0x00, penum->TextBufferIndex * sizeof(float)); 2126 memcpy(penum->text_state->Widths, penum->Widths, penum->text.size * sizeof(float)); (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7fb706bae55b in __GI_abort () at abort.c:79 #2 0x7fb706c06ff8 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fb706d13f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x7fb706c0e39a in malloc_printerr (str=str@entry=0x7fb706d16010 "malloc(): invalid size (unsorted)") at malloc.c:5339 #4 0x7fb706c11304 in _int_malloc (av=av@entry=0x7fb706d45b80 , bytes=bytes@entry=62) at malloc.c:3736 #5 0x7fb706c12a74 in __GI___libc_malloc (bytes=bytes@entry=62) at malloc.c:3058 #6 0x7fb7070a3445 in gs_heap_alloc_bytes (mem=0x5600c40c5c40, size=14, cname=0x7fb7072389c8 "txtwrite alloc sorted text buffer") at ./base/gsmalloc.c:191 #7 0x7fb706fe88e1 in txt_add_fragment (penum=0x5600c45abea8, tdev=) at ./devices/vector/gdevtxtw.c:2141 #8 textw_text_process (pte=0x5600c45abea8) at ./devices/vector/gdevtxtw.c:2241 #9 0x7fb70717b8a0 in op_show_continue (i_ctx_p=0x5600c40f9778) at ./psi/zchar.c:690 #10 op_show_continue (i_ctx_p=0x5600c40f9778) at ./psi/zchar.c:685 #11 0x7fb70715d739 in interp (perror_object=, pref=, pi_ctx_p=) at ./psi/interp.c:1300 #12 gs_call_interp (pi_ctx_p=pi_ctx_p@entry=0x5600c40c6590, pref=pref@entry=0x775a4350, user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x775a43cc, perror_object=) at ./psi/interp.c:520 #13 0x7fb70715ec7a in gs_interpret (pi_ctx_p=pi_ctx_p@entry=0x5600c40c6590, pref=pref@entry=0x775a4350, user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x775a43cc, perror_object=, perror_object@entry=0x775a43d0) at ./psi/interp.c:477 #14 0x7fb70715153e in gs_main_interpret (perror_object=0x775a43d0, pexit_code=0x775a43cc, user_errors=1, pref=0x775a4350, minst=) at ./psi/imain.c:791 #15 gs_main_run_string_end (minst=minst@entry=0x5600c40c64f0, user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x775a43cc, perror_object=perror_object@entry=0x775a43d0) at ./psi/imain.c:791 #16 0x7fb7071515d1 in gs_main_run_string_with_length (str=, length=, perror_object=0x775a43d0, pexit_code=0x775a43cc, user_errors=1, minst=0x5600c40c64f0) at ./psi/imain.c:735 #17 gs_main_run_string_with_length (minst=0x5600c40c64f0, str=0x5600c41c2720 "<6f75742e706466>.runfile", length=24, user_errors=1, pexit_code=0x775a43cc, perror_object=0x775a43d0) at ./psi/imain.c:721 #18 0x7fb7071534ef in run_string (minst=minst@entry=0x5600c40c64f0, str=str@entry=0x5600c41c2720 "<6f75742e706466>.runfile", options=options@entry=3, user_errors=user_errors@entry=1, pexit_code=0x775a43cc, pexit_code@entry=0x0, perror_object=0x775a43d0, perror_object@entry=0x0) at ./psi/imainarg.c:1119 #19 0x7fb7071537e6 in runarg (minst=minst@entry=0x5600c40c64f0, arg=arg@entry=0x775a4508 "out.pdf", post=post@entry=0x7fb70725cc5c ".runfile", options=options@entry=3, user_errors=1, pexit_code=pexit_code@entry=0x0, perror_object=0x0, pre=0x7fb70723aced "") at ./psi/imainarg.c:1088 #20 0x7fb707153904 in argproc (arg=0x775a4508 "out.pdf", minst=0x5600c40c64f0) at ./psi/imainarg.c:1010 #21 argproc (minst=0x5600c40c64f0, arg=0x775a4508 "out.pdf") at ./psi/imainarg.c:995 #22 0x7fb707155010 in gs_main_init_with_args01 (minst=minst@entry=0x5600c40c64f0, argc=7, argv=0x775a5038) at ./psi/imainarg.c:241 #23 0x7fb7071552b9 in gs_main_init_with_args (minst=0x5600c40c64f0, argc=, argv=) at ./psi/imainarg.c:
Bug#954658: Info received (Bug#954658 closed by Dennis Braun (Re: qjackctl: Frames/Period setting not always saved when it's the only setting changed.))
To make it even clearer for the upstream developer, it's a data synchronisation issue between the instances of qjackctlSetupForm and qjackctlMainForm. When the Frames/Period setting is changed, yes jackd is notified. But the new setting isn't stored in the qjackctlSetup object that both forms share a reference to. As well as the change not being written to disk, the main form is unaware of the fact that a change has even happened. So press stop and play on the main form and the new instance of jackd uses the old, incorrect values. The patch I've written corrects that issue. It doesn't force an additional, unnecessary restart on the jack server. Likewise, when cancel is hit on the form, the old (and correct) values stored in m_pSetup aren't written back to the user interface. (Because the existing instance of the form is used, and it's not reinitialised.) Cheers, Aaron On 27/3/20 08:57, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. 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): Debian Multimedia Maintainers If you wish to submit further information on this problem, please send it to 954...@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.
Bug#954960: steam: new steam update crashes with fatal error: could not load steamui.so
On Thu, 26 Mar 2020 at 22:32:25 +, Ximin Luo wrote: > Thanks for the hints. I was able to figure out that somehow I had an > extra copy of an old glib from May 2018 in /lib, similar to the problem > described in #896019. Ugh, it's looking like this is more common than we might have anticipated... > sudo rm -f /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4 That's GLib 2.32.4, from Debian 7 'wheezy' (or Ubuntu 12.04 'precise', or some contemporary version), 2012 or early 2013. Do you have any idea why it might still be there, even after you (presumably) upgraded libglib2.0-0:i386 to a much newer version? Or, do you have any ideas of something significant that might have happened to this system in May 2018, like disk corruption, encountering dpkg bugs, applying local workarounds for wrong library dependencies, that sort of thing? Do you have any other non-dpkg-owned libraries in /lib/MULTIARCH or in /usr/lib/MULTIARCH? I wonder whether it's significant, or just coincidence, that this is the same GLib version that's in the Steam Runtime? smcv
Bug#954960: steam: new steam update crashes with fatal error: could not load steamui.so
Control: notfound -1 1.0.0.61-2 Control: done -1 Hi, Thanks for the hints. I was able to figure out that somehow I had an extra copy of an old glib from May 2018 in /lib, similar to the problem described in #896019. After removing it: sudo rm -f /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4 steam is now back to normal and I don't need that workaround any more. Ximin Simon McVittie: > On Wed, 25 Mar 2020 at 20:48:37 +, Ximin Luo wrote: >> In $STEAMDIR/error.log we see: >> >> Failed to load steamui.so - dlerror(): >> /usr/lib/i386-linux-gnu/libpango-1.0.so.0: undefined symbol: >> g_log_structured_standard > > It looks as though the Steam Runtime infrastructure is selecting libpango > from your host OS (Debian), but GLib from the Steam Runtime. That shouldn't > be happening: it is meant to use the host OS (i.e. Debian) version of GLib > if it's newer, which, in practice, it has been for a long time. > > Recent versions of Steam have a debugging tool that can be used to > diagnose issues like this. It's intended for upstream to use, but should > be equally handy for downstreams like us. (You'll find my name in its > changelog - I have both of those hats right now.) > > Please try running: > > ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh \ > > ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info > > It will output quite a lot of JSON. Please send it to this bug report > (you can censor it if you want, as long as it's clear which bits you have > edited). > > It might also help to re-run the same tool with the --verbose option, > which will list the paths to all the libraries that are part of the > Steam Runtime. > > You could also try running > > ~/.steam/steam/ubuntu12_32/steam-runtime/setup.sh --force > > but if you do, please capture a steam-runtime-system-info report before > and after you do that, so we can compare. > >> Launching /usr/games/steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 >> works around this problem for now. > > That option usually breaks the open-source (Mesa) driver stack by using > the Steam Runtime's ancient libraries in preference to the ones Mesa > needs, so it is generally a bad idea, and it will disappear entirely in > the next release of the Steam Runtime. I'm surprised it's having a > positive effect for you. > > smcv > -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#955026: Right touchpad button not enabled on lenovo z580 with synaptics touchpad
Package: linux-image-4.19.0-8-amd64 Version: 4.19.98-1 My lenovo Z580 laptop has a left and a right touchpad button. In Debian 10 they both behave like a left touchpad button, i.e. my right "mouse" button is missing. I suppose that the right button is not enabled by psmouse. X uses the evdev driver that states "evdev: SynPS/2 Synaptics TouchPad: Found 1 mouse buttons". Other selected information see below. Thanks in advance for your help, Ralf - Selected output from /proc/bus/input/devices: I: Bus=0011 Vendor=0002 Product=0007 Version=01b1 N: Name="SynPS/2 Synaptics TouchPad" P: Phys=isa0060/serio4/input0 S: Sysfs=/devices/platform/i8042/serio4/input/input145 U: Uniq= H: Handlers=mouse0 event7 B: PROP=5 B: EV=b B: KEY=e520 1 0 0 0 0 B: ABS=66080001103 - Selected output from journalctl -xb: Mar 24 21:46:07 z580 kernel: psmouse serio4: synaptics: Touchpad model: 1, fw: 8.0, id: 0x1e2b1, caps: 0xd00123/0x840300/0x123c00/0x0, board id: 1800, fw id: 876955 - Selected output from evtest: Input driver version is 1.0.1 Input device ID: bus 0x11 vendor 0x2 product 0x7 version 0x1b1 Input device name: "SynPS/2 Synaptics TouchPad" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 272 (BTN_LEFT) Event code 325 (BTN_TOOL_FINGER) Event code 328 (BTN_TOOL_QUINTTAP) Event code 330 (BTN_TOUCH) Event code 333 (BTN_TOOL_DOUBLETAP) Event code 334 (BTN_TOOL_TRIPLETAP) Event code 335 (BTN_TOOL_QUADTAP) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 2058 Min 1472 Max 5664 Resolution 42 Event code 1 (ABS_Y) Value 1590 Min 1408 Max 4682 Resolution 52 Event code 24 (ABS_PRESSURE) Value 0 Min0 Max 255 Event code 28 (ABS_TOOL_WIDTH) Value 0 Min0 Max 15 Event code 47 (ABS_MT_SLOT) Value 0 Min0 Max1 Event code 53 (ABS_MT_POSITION_X) Value 0 Min 1472 Max 5664 Resolution 42 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min 1408 Max 4682 Resolution 52 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min0 Max65535 Event code 58 (ABS_MT_PRESSURE) Value 0 Min0 Max 255 Properties: Property type 0 (INPUT_PROP_POINTER) Property type 2 (INPUT_PROP_BUTTONPAD)
Bug#954935: dbgsym packages for 2:4.9.5+dfsg-5+deb10u1? (winbind crashes when queried for user)
Dear Maintainer, I tried to start looking at the given backtrace, but could not find the winbind-dbgsym packages for 2:4.9.5+dfsg-5+deb10u1 like they are availabe for 2:4.9.5+dfsg-5. At least apt did not find it in buster-proposed-updates-debug and at snapshot.debian.org they are also not listed. Is there a source known for the dbgsym packages? Kind regards, Bernhard
Bug#953985: python3-msgpack: 0.6.2-1 results in 'unsupported' msgpack[-python] version message
Package: python3-msgpack Followup-For: Bug #953985 Dear Maintainer, Just for the records: updating borgbackup to 1.1.11-5 solves the problem. Regards, xiscu -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (10, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-msgpack depends on: ii libc62.30-2 ii python3 3.8.2-2 python3-msgpack recommends no packages. python3-msgpack suggests no packages. -- no debconf information
Bug#936188: bbqsql: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:11:19AM +, Matthias Klose wrote: > Package: src:bbqsql > Version: 1.1-4 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. Hi Marcos, bbqsql seems dead upstream, development mostly stopped in 2013 and the author mentions in https://github.com/Neohapsis/bbqsql/pull/61 "he no longer works for the company". Are you planning to port it to Python 3 yourself or should it be removed? Cheers, Moritz
Bug#954971: should not try to send a traceback in production
On 2020-03-26 20:36:15, Carsten Leonhardt wrote: > Hi Antoine, > >> Bacula seems to be configured to unconditionnally send a backtrace >> when it crashes. The TRACEBACK define seems to be unconditionnally set >> in `version.h`, regardless of any configuration flag. (Same with >> DEBUG, by the way.) >> >> Production software should require us to ship with debugging >> symbols. If it fails and crashes and burn, it should send a proper, >> actionable, error message instead of going crazy. > > the crash you see happens after clear error messages are given, see the > transcript at the end. Even if not run in the foreground, clear error > messages are sent to syslog. The error gets sent to syslog, sure, but not by email. > It's neither required to have debugging symbols installed nor to have > gdb installed. The report will just be less useful for debugging > purposes. Usually an email is generated when a crash happens, whatever > the exact content is, it does alert the admin to the fact that there is > a problem. True. > Could you explain how you would want this improved? I would prefer that no email is sent at all, or have that configurable. I would prefer, in fact, that TRACEBACK is disabled at compile time, unless the debugging symbols are shipped. A. -- Evil exists to glorify the good. Evil is negative good. It is a relative term. Evil can be transmuted into good. What is evil to one at one time, becomes good at another time to somebody else. - Sivananda
Bug#953633: pari: backport patch for #2164, #2208
On Wed, Mar 25, 2020 at 08:32:59PM +0100, Tobias Hansen wrote: > > If I release 2.11.4-pre1 on April 3, would that be OK ? > > > > Cheers, > > Sure, but that means that the fix would only be in Debian with the > release of 2.11.4 in about three weeks right? Then I should still > disable the test in order not to have a broken sagemath all this time. Well I suppose I can upload 2.11.4-pre1 to Debian on the same day. Cheers, -- Bill. Imagine a large red swirl here.
Bug#954658: closed by Dennis Braun (Re: qjackctl: Frames/Period setting not always saved when it's the only setting changed.)
Sure, the settings are changed immediately, but the change is not written to disk. So say I change the Frames/Period setting to 512 from 1024. That works for the current running instance of jackd. But the next time I launch the daemon after stopping it? Back to 1024. And worse still, the settings dialogue still shows 512, so it's incredibly frustrating and confusing to the user when they're trying to match settings across two computers for something like jacktrip and it looks like they match in the UI, but they don't in reality. (And on next load, because it wasn't saved to disk, the 1024 reappears and the user is left scratching their head as to why their settings aren't preserved.) Also, pressing cancel and not having the UI reflect the previous changes instead of the original settings? Definitely not a feature. Additionally, the fix I've provided doesn't prevent the Frames/Period change from happening immediately - that part of the code is unaltered. If the jack daemon can change its settings immediately, it still does without reset. Feature preserved. What it does do is to actually write the change to disk for future instances of the jack daemon, so that the user doesn't wonder why their old settings keep popping back up. Aaron On 27/3/20 06:57, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the qjackctl package: #954658: qjackctl: Frames/Period setting not always saved when it's the only setting changed. It has been closed by Dennis Braun . 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 Dennis Braun by replying to this email.
Bug#955025: imagemagick: CVE-2019-14981
Source: imagemagick Version: 8:6.9.10.23+dfsg-2.1 Severity: important Tags: security upstream Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1552 Control: found -1 8:6.9.7.4+dfsg-11+deb9u7 Control: found -1 8:6.9.7.4+dfsg-11 Hi, The following vulnerability was published for imagemagick. CVE-2019-14981[0]: | In ImageMagick 7.x before 7.0.8-41 and 6.x before 6.9.10-41, there is | a divide-by-zero vulnerability in the MeanShiftImage function. It | allows an attacker to cause a denial of service by sending a crafted | file. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-14981 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14981 [1] https://github.com/ImageMagick/ImageMagick/issues/1552 Regards, Salvatore
Bug#938612: sx: Python2 removal in sid/bullseye
On Tue, Jan 21, 2020 at 12:02:45AM +1100, Stuart Prescott wrote: > It seems that the upstream for src:sx has disappeared and so I guess the > porting work to change this package to be Python 3 compatible has not been > done. > > At a quick glance, the porting doesn't look that hard to do, but is it > worthwhile for what appears to be a low popcon, dead upstream package? Is > removal a better option at this stage? Hi Laszlo, what do think, should we remove sx? Cheers, Moritz
Bug#944181: ghdl: non-standard gcc/g++ used for build (gcc-8)
Control: block 954831 with -1 Control: severity -1 serious On Tue, 05 Nov 2019 13:23:02 + Matthias Klose wrote: > Package: ghdl > Severity: important > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy > > This package builds with a non standard compiler version; please check > if this package can be built with the default version of gcc/g++, or > with gcc-9/g++-9. > > Please keep this report open until the package uses the default > compiler version (or gcc-9) for the package build. > > If the package cannot be built anymore, please file a bug report for > ftp.debian.org, asking for the removal of the package. > > The severity of this report is likely to be raised before the release, > so that the gcc-8 package can be removed for the release. GCC 8 is being removed, so this is now serious. Cheers, Emilio
Bug#955024: RM: funkload -- RoQA; Depends on Python 2, dead upstream
Package: ftp.debian.org Severity: normal Please remove funkload, it depends on Python 2 and is dead upstream (last release from 2015, homepage vanished). Cheers, Moritz
Bug#944167: gcc-mingw-w64: non-standard gcc/g++ used for build (gcc-8)
Control: block 954831 with -1 Control: severity -1 serious On Tue, 05 Nov 2019 13:22:42 + Matthias Klose wrote: > Package: gcc-mingw-w64 > Severity: important > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy > > This package builds with a non standard compiler version; please check > if this package can be built with the default version of gcc/g++, or > with gcc-9/g++-9. > > Please keep this report open until the package uses the default > compiler version (or gcc-9) for the package build. > > If the package cannot be built anymore, please file a bug report for > ftp.debian.org, asking for the removal of the package. > > The severity of this report is likely to be raised before the release, > so that the gcc-8 package can be removed for the release. GCC 8 is being removed, so this is now serious. Cheers, Emilio
Bug#944169: open-ath9k-htc-firmware: non-standard gcc/g++ used for build (gcc-8)
Control: block 954831 with -1 Control: severity -1 serious On Tue, 05 Nov 2019 13:22:48 + Matthias Klose wrote: > Package: open-ath9k-htc-firmware > Severity: important > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy > > This package builds with a non standard compiler version; please check > if this package can be built with the default version of gcc/g++, or > with gcc-9/g++-9. > > Please keep this report open until the package uses the default > compiler version (or gcc-9) for the package build. > > If the package cannot be built anymore, please file a bug report for > ftp.debian.org, asking for the removal of the package. > > The severity of this report is likely to be raised before the release, > so that the gcc-8 package can be removed for the release. GCC 8 is being removed, so this is now serious. Cheers, Emilio
Bug#944172: openzwave: non-standard gcc/g++ used for build (gcc-8)
Control: block 954831 with -1 Control: severity -1 serious On Tue, 05 Nov 2019 13:22:49 + Matthias Klose wrote: > Package: openzwave > Severity: important > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy > > This package builds with a non standard compiler version; please check > if this package can be built with the default version of gcc/g++, or > with gcc-9/g++-9. > > Please keep this report open until the package uses the default > compiler version (or gcc-9) for the package build. > > If the package cannot be built anymore, please file a bug report for > ftp.debian.org, asking for the removal of the package. > > The severity of this report is likely to be raised before the release, > so that the gcc-8 package can be removed for the release. GCC 8 is being removed, so this is now serious. Cheers, Emilio
Bug#944177: mysql-workbench: non-standard gcc/g++ used for build (gcc-8)
Control: block 954831 with -1 Control: severity -1 serious On Tue, 05 Nov 2019 13:22:57 + Matthias Klose wrote: > Package: mysql-workbench > Severity: important > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy > > This package builds with a non standard compiler version; please check > if this package can be built with the default version of gcc/g++, or > with gcc-9/g++-9. > > Please keep this report open until the package uses the default > compiler version (or gcc-9) for the package build. > > If the package cannot be built anymore, please file a bug report for > ftp.debian.org, asking for the removal of the package. > > The severity of this report is likely to be raised before the release, > so that the gcc-8 package can be removed for the release. GCC 8 is being removed, so this is now serious. Cheers, Emilio
Bug#944170: kfreebsd-10: non-standard gcc/g++ used for build (gcc-8)
Control: block 954831 with -1 Control: severity -1 serious On Tue, 05 Nov 2019 13:22:46 + Matthias Klose wrote: > Package: kfreebsd-10 > Severity: important > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy > > This package builds with a non standard compiler version; please check > if this package can be built with the default version of gcc/g++, or > with gcc-9/g++-9. > > Please keep this report open until the package uses the default > compiler version (or gcc-9) for the package build. > > If the package cannot be built anymore, please file a bug report for > ftp.debian.org, asking for the removal of the package. > > The severity of this report is likely to be raised before the release, > so that the gcc-8 package can be removed for the release. GCC 8 is being removed, so this is now serious. Cheers, Emilio
Bug#953098: xscreensaver: Crashes with XIO: fatal IO error
Jens, the log indicates the machine has an Intel(R) HD Graphics 530 (Skylake GT2) GPU. Is this the same for the other machines? I have been trying to reproduce for several days, also running on Intel drivers, but with a 5500 series GPU and also I am on "testing" so I have newer Xorg and kernel. Tormod
Bug#955022: i915: Frequent graphics lockups; GPU HANG: ecode 9:1:0x00000000, hang on rcs0
Package: src:linux
Version: 5.4.19-1
Severity: important
Multiple times a day, my graphical session will freeze. If I'm in a video call,
sometimes the audio continues, other times it breaks into a loop. Sometimes
recoverable with SAK, so I can continue without rebooting after waiting a bit.
I don't have a definite reproduction case; sometimes it will be fine for a day
or so, or today, where it happened twice, most recently <45m after boot.
Appears to be more likely when switching virtual workspaces in SwayWM
(Wayland), and always appears to be mid-render of a graphics effect from a
video or an image transition.
I believe this started with 5.4.0-4-amd64[1], I don't recall it happening
before I updated from 5.4.0-3-amd64 earlier this month.
I suspect this is the same issue as this upstream bug[3], which indicates it's
fixed in 5.5, and it looks like Ubuntu backported this to 5.4[4].
Attached are ``/sys/class/drm/card0/error`` for the last two crashes.
[1]: 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200203
(Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)
[2]: 5.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200117
(Debian 9.2.1-24)) #1 SMP Debian 5.4.13-1 (2020-01-19)
[3]: https://gitlab.freedesktop.org/drm/intel/issues/673
[4]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861395
Please let me know if there's any additional information I can provide.
Cheers,
Luke Faraone
-- Package-specific info:
** Version:
Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1
20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)
** Command line:
BOOT_IMAGE=/vmlinuz-5.4.0-4-amd64 root=/dev/mapper/debvg-root ro quiet
cgroup_enable=memory
** Not tainted
** Kernel log:
[ 1647.162227] hid-generic 0003:1050:0116.0013: input,hidraw4: USB HID v1.10
Keyboard [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input0
[ 1647.163235] hid-generic 0003:1050:0116.0014: hiddev1,hidraw5: USB HID v1.10
Device [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input1
[ 1652.879527] usb 1-8.1: USB disconnect, device number 13
[ 2548.286765] usb 1-8.1: new full-speed USB device number 14 using xhci_hcd
[ 2548.397134] usb 1-8.1: New USB device found, idVendor=1050, idProduct=0116,
bcdDevice= 3.42
[ 2548.397136] usb 1-8.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 2548.397137] usb 1-8.1: Product: Yubikey NEO OTP+U2F+CCID
[ 2548.397138] usb 1-8.1: Manufacturer: Yubico
[ 2548.414445] input: Yubico Yubikey NEO OTP+U2F+CCID as
/devices/pci:00/:00:14.0/usb1/1-8/1-8.1/1-8.1:1.0/0003:1050:0116.0015/input/input31
[ 2548.471349] hid-generic 0003:1050:0116.0015: input,hidraw4: USB HID v1.10
Keyboard [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input0
[ 2548.472439] hid-generic 0003:1050:0116.0016: hiddev1,hidraw5: USB HID v1.10
Device [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input1
[ 2558.098065] usb 1-8.1: USB disconnect, device number 14
[ 2564.230766] usb 1-2: new full-speed USB device number 15 using xhci_hcd
[ 2564.380688] usb 1-2: New USB device found, idVendor=1050, idProduct=0407,
bcdDevice= 4.37
[ 2564.380694] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2564.380697] usb 1-2: Product: Yubikey 4 OTP+U2F+CCID
[ 2564.380700] usb 1-2: Manufacturer: Yubico
[ 2564.386624] input: Yubico Yubikey 4 OTP+U2F+CCID as
/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:1050:0407.0017/input/input32
[ 2564.443522] hid-generic 0003:1050:0407.0017: input,hidraw4: USB HID v1.10
Keyboard [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-2/input0
[ 2564.444788] hid-generic 0003:1050:0407.0018: hiddev1,hidraw5: USB HID v1.10
Device [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-2/input1
[ 2576.846425] usb 1-2: USB disconnect, device number 15
[ 2782.143185] i915 :00:02.0: GPU HANG: ecode 9:1:0x, hang on rcs0
[ 2782.144195] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2782.144965] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset request timed
out: {request: 0001, RESET_CTL: 0001}
[ 2782.145079] i915 :00:02.0: Resetting chip for hang on rcs0
[ 2782.146848] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset request timed
out: {request: 0001, RESET_CTL: 0001}
[ 2782.147606] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset request timed
out: {request: 0001, RESET_CTL: 0001}
[ 2790.143136] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2798.147163] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2800.127153] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2802.143165] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2804.127179] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2806.143162] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2808.127173] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2810.143192] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2812
Bug#953985: python3-msgpack: 0.6.2-1 results in 'unsupported' msgpack[-python] version message
Package: python3-msgpack Version: 0.6.2-1 Followup-For: Bug #953985 Dear Maintainer, I'm also getting the messages. The installed borgbackup version on (26.03.2030) is 1.1.20-2, as dependencies seems to be configured python3-msgpack (>= 0.5.1) In the upstream link https://github.com/borgbackup/borg/issues/3753 it's stated """(on 14.01.2019) borg 1.1.x does not work with msgpack >= 0.6.0, there are multiple issues (search this issue tracker, if interested). """ Doesn't that means that the debian borgbackup package should be configured to just accept upto 0.6.0 (for that borgbackup version 1.1.10-2) ? Thanks in advance! xiscu -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (10, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-msgpack depends on: ii libc62.30-2 ii python3 3.7.5-3 python3-msgpack recommends no packages. python3-msgpack suggests no packages. -- no debconf information
Bug#955021: gnome-calendar: Google Calendar daily limit exceeded
Package: gnome-calendar Version: 3.36.0-1 Severity: normal Since 2020-03-24, I've started getting a bunch of lines such as these in my log file at 23:17 and 23:47 (where contains the names of my various Google calendars). Mar 25 23:17:29 olgas gnome-calendar[67978]: source_credentials_required_cb: Failed to authenticate ': Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API Console: https://console.developers.google.com/apis/api/caldav.googleapis.com/quotas?project=44438659992 I can't say what triggered these, as I don't explicitly use Evolution or other clients that may take advantage of my Google account. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-calendar depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gsettings-desktop-schemas3.36.0-1 ii libc62.30-2 ii libcairo21.16.0-4 ii libdazzle-1.0-0 3.36.0-1 ii libecal-2.0-13.36.0-1 ii libedataserver-1.2-243.36.0-1 ii libedataserverui-1.2-2 3.36.0-1 ii libgeoclue-2-0 2.5.6-1 ii libglib2.0-0 2.64.1-1 ii libgoa-1.0-0b3.36.0-1 ii libgtk-3-0 3.24.14-1 ii libgweather-3-16 3.36.0-1 ii libhandy-0.0-0 0.0.13-1 ii libical3 3.0.8-1 ii libpango-1.0-0 1.42.4-8 ii libpangocairo-1.0-0 1.42.4-8 ii libsoup2.4-1 2.70.0-1 Versions of packages gnome-calendar recommends: ii evolution-data-server 3.36.0-1 gnome-calendar suggests no packages. -- no debconf information -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Bug#955020: php-horde-form: CVE-2020-8866
Source: php-horde-form Version: 2.0.19-1 Severity: important Tags: security upstream Control: found -1 2.0.18-3.1 Control: found -1 2.0.15-1+deb9u1 Control: found -1 2.0.15-1 Hi, The following vulnerability was published for php-horde-form. CVE-2020-8866[0]: | This vulnerability allows remote attackers to create arbitrary files | on affected installations of Horde Groupware Webmail Edition 5.2.22. | Authentication is required to exploit this vulnerability. The specific | flaw exists within add.php. The issue results from the lack of proper | validation of user-supplied data, which can allow the upload of | arbitrary files. An attacker can leverage this in conjunction with | other vulnerabilities to execute code in the context of the www-data | user. Was ZDI-CAN-10125. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-8866 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8866 Regards, Salvatore
Bug#954857: RFS: siconos/4.2.0+git20181026.0ee5349+dfsg.2-3 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)
Hello Adam, Thank you for looking at the package. I believe I have fixed the problem now and updated master on salsa. I am trying to re-upload to mentors but no acknowledgement yet after waiting the whole day, I will try again tomorrow. I have now to taught my system to run autopkgtest automatically after sbuild, so hopefully won't make the same mistake again. Incidentally, in the interim I have been informed by upstream that a new version is coming soon so I will be updating the package probably again next week, but it would be good to get this fix in anyways since I don't know exactly how long that will be. regards, Steve On Thu, Mar 26, 2020 at 3:03 AM Adam Borowski wrote: > > On Tue, Mar 24, 2020 at 03:17:31PM +0100, Stephen Sinclair wrote: > > * Package name: siconos > >Version : 4.2.0+git20181026.0ee5349+dfsg.2-3 > > > Changes since the last upload: > > > >* Patch to remove bad cc options. > >* Patch to find python3.8 config. > >* Depend on swig instead of swig3.0. > >* Backport support for swig4.0. (Closes: #952601) > >* Removed a failing numerics test. > >* debian/rules: Remove use of ccache. (Closes: #945613 #954497) > >* Require Python 3.8. > > Hi! > I'm afraid that while the package builds, it fails tests: > > autopkgtest [02:57:15]: summary > kernel-dev PASS > numerics-tests FAIL non-zero exit status 2 > kernel-tests FAIL non-zero exit status 2 > control-testsFAIL non-zero exit status 2 > kernel-tests-python PASS > control-tests-python PASS > mechanics-tests FAIL non-zero exit status 2 > mechanics-tests-python PASS > mechanics-tools PASS > > Full log attached. > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. > ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi > ⠈⠳⣄
Bug#955019: php-horde-trean: CVE-2020-8865
Source: php-horde-trean Version: 1.1.9-4 Severity: important Tags: security upstream Control: found -1 1.1.9-3 Hi, The following vulnerability was published for php-horde-trean. CVE-2020-8865[0]: | This vulnerability allows remote attackers to execute local PHP files | on affected installations of Horde Groupware Webmail Edition 5.2.22. | Authentication is required to exploit this vulnerability. The specific | flaw exists within edit.php. When parsing the params[template] | parameter, the process does not properly validate a user-supplied path | prior to using it in file operations. An attacker can leverage this in | conjunction with other vulnerabilities to execute code in the context | of the www-data user. Was ZDI-CAN-10469. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-8865 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8865 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#955018: shiro: CVE-2020-1957
Source: shiro Version: 1.3.2-4 Severity: important Tags: security upstream Control: found -1 1.3.2-1 Hi, The following vulnerability was published for shiro. CVE-2020-1957[0]: | Apache Shiro before 1.5.2, when using Apache Shiro with Spring dynamic | controllers, a specially crafted request may cause an authentication | bypass. There is no reference to upstream issues or fixes, can you check? If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-1957 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1957 [1] https://www.openwall.com/lists/oss-security/2020/03/23/2 Regards, Salvatore
Bug#944365: FTBFS with OCaml 4.08.1 (implementation/interface mismatch)
control: tags -1 pending in deferred/5 G. On Fri, 08 Nov 2019 16:54:04 +0100 =?utf-8?q?St=C3=A9phane_Glondu?= wrote: > Package: src:frama-c > Version: 20171101+sulfur+dfsg-2 > Severity: serious > Tags: ftbfs > User: debian-ocaml-ma...@lists.debian.org > Usertags: ocaml-4.08-transition > > Dear Maintainer, > > frama-c FTBFS with OCaml 4.08.1: > > https://buildd.debian.org/status/package.php?p=frama-c > > > Cheers, > > -- > Stéphane > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled
Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release
Hi Pabs, On 14-03-2020 00:33, Paul Wise wrote: > Since the release team are going to be able to tell which packages are > at which stage of the freeze, you could export the information > (migrations: manual or x days) alongside the excuses for each package > and the tracker could list that information in human readable form. Although that is true, we don't export that info as part of the excuses, except for package that are out-of-sync between unstable and testing. I hope you don't propose to make something new for all packages as I'm not too interested to start generating such output. Maybe it's just simpler if from the start of the freeze the tracker stops hinting packages along until the release. As although technically allowed, new upstream releases most often aren't appropriate anymore once the (soft) freeze starts and maybe shouldn't be hinted anymore even during the transition freeze. So, maybe all the tracker needs is the freeze date and the release date. Paul signature.asc Description: OpenPGP digital signature
Bug#955017: evince: Apparmor profile breaks print preview
Package: evince Version: 3.36.0-1 Severity: normal The apparmor profile installed by evince breaks the print preview functionality (in all gtk3 applications): Mar 26 21:09:23 x kernel: [ 2754.171426] audit: type=1400 audit(1585253363.723:33): apparmor="DENIED" operation="exec" profile="/usr/bin/evince" name="/usr/bin/dash" pid=9096 comm="evince" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evince depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii evince-common3.36.0-1 ii gsettings-desktop-schemas3.36.0-1 ii libatk1.0-0 2.34.1-1 ii libc62.30-2 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libevdocument3-4 3.36.0-1 ii libevview3-3 3.36.0-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-3 ii libglib2.0-0 2.64.1-1 ii libgnome-desktop-3-183.34.2-2 ii libgtk-3-0 3.24.14-1 ii libnautilus-extension1a 3.34.1-1 ii libpango-1.0-0 1.42.4-8 ii libpangocairo-1.0-0 1.42.4-8 ii libsecret-1-00.20.2-1 ii shared-mime-info 1.10-1 Versions of packages evince recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 Versions of packages evince suggests: ii gvfs 1.44.0-1 pn nautilus-sendto ii poppler-data 0.4.9-2 pn unrar -- no debconf information
Bug#955016: vpnc-scripts: Fix incompatibility with iproute2 >= 5.1 syncing with upstream
Package: vpnc-scripts Version: 0.1~git20190117-1 Severity: minor vpnc-scripts has become incompatible with iproute2 >= 5.1 (applies to bullseye and sid as of now) and is therefore reporting issues with calls to "ip route get", but it's still working. This issue has been reported upstream [1] and a fix has been already merged [2]. Simply updating the package to the upstream repository would eliminate the ugly error messages. [1] https://gitlab.com/openconnect/openconnect/-/issues/106 [2] https://gitlab.com/openconnect/vpnc-scripts/-/merge_requests/5 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) 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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vpnc-scripts depends on: ii iproute2 5.5.0-1 ii net-tools 1.60+git20180626.aebd88e-1 vpnc-scripts recommends no packages. Versions of packages vpnc-scripts suggests: pn dnsmasq ii openssh-server 1:8.2p1-4 pn resolvconf -- no debconf information
Bug#955015: python3-xarray: Backend api engine grib broken
Package: python3-xarray
Version: 0.15.0-3
Severity: important
Dear Maintainer,
I was trying to use to_netcdf() located in
/usr/lib/python3/dist-packages/xarray/backends/api.py on a grib file without
specifying the engine and it appears that the default engine selection end up
on grib engine.
So _get_default_engine calls _get_default_engine_grib as we have a grib file
but this function always raise a ValueError even if cfgrib import succeed but
anyway, there is a real issue with this function as it is returning nothing
while _get_default_engine is expecting an engine.
If we try to, somehow, makes _get_default_engine_grib return cfdisk as engine,
it will still fail as cfgrib is absent of the WRITEABLE_STORES bellow but even
if it would have been present, cfgrib does not implement a writeable store.
WRITEABLE_STORES: Dict[str, Callable] = {
"netcdf4": backends.NetCDF4DataStore.open,
"scipy": backends.ScipyDataStore,
"h5netcdf": backends.H5NetCDFStore.open,
}
I'm quite new dealing with xarray but I think grib engine seems to be on work
in progress or something and doesn't look ready yet.
In order to get the job done, I tryed to make _get_default_engine_grib
returning "netcdf4" based on observation on an older implementation of xarray
(0.10.2-1). This "hack" worked but it is really dirty.
Could you please dig a bit more and fix this issue?
Best regards, and thank you for all job done maintaining theses packages.
-- System Information:
Debian Release: bullseye/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-xarray depends on:
ii python3 3.8.2-2
ii python3-numpy 1:1.17.4-5
ii python3-pandas 0.25.3+dfsg-7
Versions of packages python3-xarray recommends:
ii python3-bottleneck 1.2.1+ds1-2+b1
ii python3-dask2.11.0+dfsg-1
ii python3-h5netcdf0.7.1-1
ii python3-netcdf4 1.5.3-1+b2
ii python3-zarr2.4.0+ds-1
Versions of packages python3-xarray suggests:
pn python-xarray-doc
pn python3-cartopy
ii python3-matplotlib 3.2.1-1
pn python3-pydap
pn python3-rasterio
ii python3-scipy 1.3.3-3
pn python3-seaborn
ii python3-toolz 0.9.0-1
-- no debconf information
Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1
On 3/26/20 8:51 PM, Colomban Wendling wrote: > Hi, > > Sorry if I'm too far off the tree, but isn't this just an overlook of > the dependency switch from libgcc1 (which has an "1" epoch) to the > libgcc-s1 (which doesn't have an epoch)? > > ATM at least clang-9 (which is still the default in unstable) depends on > libgcc-8-dev, and while I probably miss some important details, I fail > to see why we have to drop gcc-8 because of this? yes, but we cannot rebuild the package, because it build-depends on gnat-8. Filed a removal bug for gcc-8 instead.
Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1
Hi, Sorry if I'm too far off the tree, but isn't this just an overlook of the dependency switch from libgcc1 (which has an "1" epoch) to the libgcc-s1 (which doesn't have an epoch)? ATM at least clang-9 (which is still the default in unstable) depends on libgcc-8-dev, and while I probably miss some important details, I fail to see why we have to drop gcc-8 because of this? Regards, Colomban
Bug#954971: should not try to send a traceback in production
Hi Antoine, > Bacula seems to be configured to unconditionnally send a backtrace > when it crashes. The TRACEBACK define seems to be unconditionnally set > in `version.h`, regardless of any configuration flag. (Same with > DEBUG, by the way.) > > Production software should require us to ship with debugging > symbols. If it fails and crashes and burn, it should send a proper, > actionable, error message instead of going crazy. the crash you see happens after clear error messages are given, see the transcript at the end. Even if not run in the foreground, clear error messages are sent to syslog. It's neither required to have debugging symbols installed nor to have gdb installed. The report will just be less useful for debugging purposes. Usually an email is generated when a crash happens, whatever the exact content is, it does alert the admin to the fact that there is a problem. Could you explain how you would want this improved? Regards, Carsten # /usr/sbin/bacula-fd -f -c /etc/bacula/bacula-fd.conf cixi: Warning: Cannot bind port 22: ERR=Address already in use: Retrying ... cixi: ABORTING due to ERROR in bnet_server.c:132 Cannot bind port 22: ERR=Address already in use. 26-Mar 19:59 cixi: ABORTING due to ERROR in bnet_server.c:132 Cannot bind port 22: ERR=Address already in use. Bacula interrupted by signal 11: Segmentation violation Kaboom! bacula-fd, cixi got signal 11 - Segmentation violation at 26-Mar-2020 19:59:48. Attempting traceback. Kaboom! exepath=/usr/sbin/ Calling: /usr/sbin/btraceback /usr/sbin/bacula-fd 4576 /var/lib/bacula It looks like the traceback worked... LockDump: /var/lib/bacula/bacula.4576.traceback cixi: lockmgr.c:1221-0 lockmgr disabled free(): invalid next size (fast)
Bug#954635: golang-github-thecreeper-go-notify: FTBFS: Errors while processing: libdbus2.0-cil libglib2.0-cil libgtk2.0-cil libdbus-glib2.0-cil libnotify0.4-cil libnotify-cil-dev sbuild-build-depends-
Control: reassign -1 src:mono 6.8.0.105+dfsg-2 Control: retitle -1 CLI binding packages fail to install: Unhandled Exception: System.TypeInitializationException: The type initializer for 'Sys' threw an exception Control: affects -1 src:golang-github-thecreeper-go-notify libglib2.0-cil libgdcm-cil Control: severity -1 grave On Sun, 22 Mar 2020 08:45:16 +0100 Lucas Nussbaum wrote: > Source: golang-github-thecreeper-go-notify > Version: 0.0~git20160203.0.b5cd147-4 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200321 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): [snip] > Setting up librest-0.7-0:amd64 (0.8.1-1+b1) ... > Setting up libgtk-3-0:amd64 (3.24.14-1) ... > Setting up libgtk2.0-0:amd64 (2.24.32-4) ... > Setting up libgtk-3-bin (3.24.14-1) ... > Setting up notification-daemon (3.20.0-4) ... > Setting up libmono-system-numerics4.0-cil (6.8.0.105+dfsg-2) ... > Setting up libmono-system-core4.0-cil (6.8.0.105+dfsg-2) ... > Setting up dh-autoreconf (19) ... > Setting up libmono-system-security4.0-cil (6.8.0.105+dfsg-2) ... > Setting up mono-runtime-sgen (6.8.0.105+dfsg-2) ... > Setting up mono-runtime (6.8.0.105+dfsg-2) ... > update-alternatives: using /usr/bin/mono to provide /usr/bin/cli (cli) in > auto mode > Setting up libmono-system-configuration4.0-cil (6.8.0.105+dfsg-2) ... > Setting up debhelper (12.9) ... > Setting up libmono-corlib4.5-cil (6.8.0.105+dfsg-2) ... > Setting up libmono-cairo4.0-cil (6.8.0.105+dfsg-2) ... > Setting up libmono-system-xml4.0-cil (6.8.0.105+dfsg-2) ... > Setting up dh-golang (1.48) ... > Setting up libmono-system4.0-cil (6.8.0.105+dfsg-2) ... > Setting up libmono-posix4.0-cil (6.8.0.105+dfsg-2) ... > Setting up libmono-system-drawing4.0-cil (6.8.0.105+dfsg-2) ... > Setting up libdbus2.0-cil (0.8.1-2) ... > * Installing 1 assembly from libdbus2.0-cil into Mono > > Unhandled Exception: > System.TypeInitializationException: The type initializer for 'Sys' threw an > exception. ---> System.DllNotFoundException: System.Native assembly: assembly> type: member:(null) > at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag() > at Interop+Sys..cctor () [0x0] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 >--- End of inner exception stack trace --- > at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, > System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0xf] in > <12b418a7818c4ca0893feeaaf67f1e7f>:0 > at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath) > [0x6] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 > at System.IO.File.Exists (System.String path) [0x00058] in > <12b418a7818c4ca0893feeaaf67f1e7f>:0 > at Mono.Tools.Driver.LoadConfig (System.Boolean quiet) [0x00031] in > <3a4d36ecef0a47439a72108fe400486f>:0 > at Mono.Tools.Driver.Main (System.String[] args) [0x00347] in > <3a4d36ecef0a47439a72108fe400486f>:0 > [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The > type initializer for 'Sys' threw an exception. ---> > System.DllNotFoundException: System.Native assembly: > type: member:(null) > at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag() > at Interop+Sys..cctor () [0x0] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 >--- End of inner exception stack trace --- > at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, > System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0xf] in > <12b418a7818c4ca0893feeaaf67f1e7f>:0 > at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath) > [0x6] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 > at System.IO.File.Exists (System.String path) [0x00058] in > <12b418a7818c4ca0893feeaaf67f1e7f>:0 > at Mono.Tools.Driver.LoadConfig (System.Boolean quiet) [0x00031] in > <3a4d36ecef0a47439a72108fe400486f>:0 > at Mono.Tools.Driver.Main (System.String[] args) [0x00347] in > <3a4d36ecef0a47439a72108fe400486f>:0 > E: installing Assembly /usr/lib/cli/dbus-sharp-2.0/dbus-sharp.dll failed > E: Installation of libdbus2.0-cil with /usr/share/cli-common/runtimes.d/mono > failed > dpkg: error processing package libdbus2.0-cil (--configure): > installed libdbus2.0-cil package post-installation script subprocess > returned error exit status 29 > Setting up mono-4.0-gac (6.8.0.105+dfsg-2) ... > Setting up libglib2.0-cil (2.12.40-3) ... I am seeing this in more places, see e.g. https://piuparts.debian.org/sid/fail/libgdcm-cil_3.0.5-1.log I can easily reproduce those in both testing and sid chroots by installing libglib2.0-cil or libgdcm-cil (probably others are affected as well but I just tried those). A subsequent `apt install -f' manages to configure the affected package, so I wonder if this is related to mono not working properly until mono-runtime-common is configured due to the absence of /etc/mono/config, which doe
Bug#955013: src:boxer-data: fails to migrate to testing for too long
Source: boxer-data Version: 10.8.11 Severity: serious Control: fixed -1 10.8.12 Tags: sid bullseye pending User: release.debian@packages.debian.org Usertags: out-of-sync 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:boxer-data 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 marked the version in unstable as fixing this bug, 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. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=boxer-data signature.asc Description: OpenPGP digital signature
Bug#955012: src:librouteros: fails to migrate to testing for too long
Source: librouteros Version: 2.2.0-1 Severity: serious Control: fixed -1 3.0.0-1 Tags: sid bullseye pending User: release.debian@packages.debian.org Usertags: out-of-sync 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:librouteros 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 marked the version in unstable as fixing this bug, 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. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=librouteros signature.asc Description: OpenPGP digital signature
Bug#955011: imap-dl: depends explicitly on python3-gssapi
Package: mailscripts Version: 0.19-1 X-Debbugs-Cc: rharw...@club.cc.cmu.edu the typesafety checks in imap-dl turn out to make imap-dl fail when python3-gssapi is installed. In particular: try: import gssapi # type: ignore except ModuleNotFoundError: gssapi = None […] class GSSAPI_handler(): gss_vc:gssapi.SecurityContext this fails when the gssapi module isn't installed. I should have caught it earlier, sorry! not sure the right way to handle this while retaining the type-safety though. --dkg signature.asc Description: PGP signature
Bug#949366: bacula-fd: bacula-rd crashes if can't bind to port
Control: forwarded -1 https://bugs.bacula.org/view.php?id=2528 Hi Lukas, > bacula-fd crashes with SIGSEGV if it can't bind to the configure port on the > configured network interface. thanks for your report, I've forwarded it upstream. Out of curiosity: the standard port 9102 is registered with IANA for use with bacula-fd. What is conflicting with it? Regards, Carsten
Bug#954998: update
On Thu, 26 Mar 2020 19:26:56 +0100, Dominique Dumont wrote: > > > And maybe we should create a backport for libconfig-model-dpkg-perl … > > > > Or maybe not: > > > > pbuilder-satisfydepends-dummy : Depends: licensecheck (>= 3.0.45) but it is > > not going to be installed > > Fixing the issue with Lintian would require a small modification of libconfig- > model-dpkg-perl . This would create a branch of libconfig-model-dpkg-perl > dedicated to stable. I don't know if this is possible for a backport. Or maybe we should try to fix this in stable proper? If the change also works with the "old" lintian (I haven't tested this combination). Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital Signature
Bug#954836: flowblade: does not start
Installation of python3-distutils solves the problem. On Wed, 25 Mar 2020 11:33:53 +0100 Gürkan Myczko wrote: > Hi Marek > > And it starts after you install python3-distutils? > > Best,
Bug#955005: Relax requirements to copy copyright notices into d/copyright
On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote: > 4. License requires copyright notice but doesn't specify anything about > source or binary (didn't look for an example, but I can totally see this > happening): I think this case is unclear with your revised wording. With > the current policy wording copyright notices would be required in > debian/copyright and I think that's correct. The current wording does seem > harsh, so it could probably be better while not leaving an ambiguity. Here's a specific example I am looking at in New: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Scott K signature.asc Description: This is a digitally signed message part.
Bug#952016: ruby-graffiti: FTBFS: ERROR: Test "ruby2.7" failed.
Package: src:ruby-graffiti
Followup-For: Bug #952016
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
After some digging one issue is in
/tmp/build-area/ruby-graffiti-2.3.1/debian/ruby-graffiti/usr/lib/ruby/vendor_ruby/graffiti/squish.rb:106:in
`upcase!'
Error: [..]: FrozenError: can't modify frozen String: ""
The offending line is
> @order_dir.upcase!
Fixing this leaves just one other failure which is in
/tmp/build-area/ruby-graffiti-2.3.1/debian/ruby-graffiti/usr/lib/ruby/vendor_ruby/graffiti/sql_mapper.rb:832:in
`gsub!'
Error: [..]: FrozenError: can't modify frozen String: ""
> @global_filter.gsub!(/#{Regexp.escape(node)}\b/) do
HTH, Daniel
- -- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl58+AQACgkQS80FZ8KW
0F1ROBAAlL5YtYi+CVAUblsNBCEsrwtopp1s7/iN7mSzKxdVBxuAXQyKxixDKpZd
CyCp14BzLfwDTvbzlBscq8a6jAj3rtIDBNTZHbvMII5PS5Aeuy3vmUTIS90z87/z
uJBfsQ5OrsRsaUFOOY4QFjWXQu7BCLymsVZnUhBlwGP4F3afuxiojgtOPyeDYYtP
23xD8J+vy6Yuz/vFfIs3ygnXG4hdtiB4k9jLf8xRbXiqD3GVclNbhQA4CXo5V2ok
6O30g26F8kyWfRHsh3ktNYDI5ELeN1lPBXIuiFdI16BmEl+WHoHCapooY1an5gN3
XRUXr7/bUiRoKnnU1Btlx3oOAcAlUx2d19mh7kHdEPKzXH6SyvfnOb32BdnM111r
hrsi6Zq80u2jcqHMP4/6CqwCHi5h7QvIf2bYM89VWwKBv3n9ARRPAQKh6k7l1wgo
ou4OQ90I15CO5yfEWmGMD1dNhnmTbIiEOUV0Dpj5UzqHRkggRw0iju4uw2LQ4XCK
/JiYGVIrp08OnSrIvZYhjE1EX1UWJDadO+ItLx7xQf0zXS96SuqTCigPaWEDySrV
G+lhICaQj8Yj9doKFZUTBo4XfQfbDtHkduHBxSJ7fUBtAJdUqSPOwG3QAtMnYV6k
iwmdp4PJhrNFHw7Ou96laIW2EVG7Zvddn9ORQVcNUPIR/Sbh79M=
=w+14
-END PGP SIGNATURE-
Bug#955010: python3-cfgrib: cfgrib, import fail "No module named 'cffi"
Package: python3-cfgrib Version: 0.9.5.1-1 Severity: important Tags: d-i Dear Maintainer, I was installing cfgrib on a fresh debian install and it appears that cfgrib have missing dependency : cffi Just installing python3-cffi fix the problem. However, I think this issue should be reported even if it is fixed on unstable (cffi appear on librairie and import doesn't failed). It would be great if you could add/backport this dependency to have this package well packed :) Thank you for adding this package to debian ! -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-cfgrib depends on: ii libeccodes-data 2.12.0-1 ii libeccodes0 2.12.0-1 ii python3 3.7.3-1 ii python3-attr 18.2.0-1 ii python3-cffi-backend [python3-cffi-backend-api-min] 1.12.2-1 pn python3-cffi-backend-api-max ii python3-click7.0-1 ii python3-future 0.16.0-1 ii python3-numpy1:1.16.2-1 ii python3-xarray 0.11.3-2 python3-cfgrib recommends no packages. python3-cfgrib suggests no packages. -- no debconf information
Bug#954998: update
On jeudi 26 mars 2020 18:08:17 CET you wrote: > > And maybe we should create a backport for libconfig-model-dpkg-perl … > > Or maybe not: > > pbuilder-satisfydepends-dummy : Depends: licensecheck (>= 3.0.45) but it is > not going to be installed Fixing the issue with Lintian would require a small modification of libconfig- model-dpkg-perl . This would create a branch of libconfig-model-dpkg-perl dedicated to stable. I don't know if this is possible for a backport. All the best Dod
Bug#954981: libnet-z3950-simpleserver-perl: FTBFS without yaz-config
On Thu, 26 Mar 2020 21:05:23 +1100, Hugh McMaster wrote: > I have removed yaz-config from libyaz-dev 5.29.0-1, which is currently in > experimental. > > Your package fails to build from source without yaz-config. > > YAZ 5.29.0 includes new pkg-config files, replacing the functionality provided > by yaz-config. > > Please switch to pkg-config. Fixed in git, waits for YAZ 5.29.0 to enter unstable (for the yaz-server.pc file). Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: The Dubliners: Johnny McGory signature.asc Description: Digital Signature
Bug#884095: revisiting this
Hi Hans,
> I really don't think it will be possible to fix this issue something like
> file magin auto-detection. An APK can be a working APK, JAR, DEX, and
> ZIP all at the same time. Using file extensions could work.
I am still not 100% convinced that autodetection is the issue here,
which partly contributed to my retitling, but also because issues
should IMHO describe the goal or problem, not the steps towards that
goal.
To elaborate, the example that you link, ie:
https://verification.f-droid.org/eu.faircode.email_914.apk.diffoscope.html
… very much appears to have detected this file *correctly* as an apk
file, although that is because it has added the following error:
Command `apktool d -k -m -o {} {}` exited with 1.
^^^
It would not have run apktool if it thought it was a simple .zip file.
Sure, there should not be an error and the output is useless, but that
is likely to have a different cause.
Regardless of the potential solution, what I would need in any case is
access to the two files that diffoscope is failing to analyse for you.
Please could you provide them so I do not need to guess further at
things? Uploading to salsa would be best, but you could also provide
possibly temporary HTTP links in reply to this bug and I would be
happy to upload them myself.
The other relevant issue is that you appear to be using an old version
of diffoscope, namely version 113, whilst the last release was 137. I
mention this in particular because there have been *lots* of changes
to apk/dex etc. file handling since then. But still, getting the files
from you would be the next step towards solving this for you.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-
Bug#946561: Does not work with python 3.8
Hello. Yesterday I tried to install an HP Laserjet P1102, and when the program tries to download the plugging, it failed: Checking for network connection... Downloading plug-in from: Traceback (most recent call last): File "/usr/share/hplip/base/password.py", line 84, in get_distro_name os_name = platform.dist()[0] AttributeError: module 'platform' has no attribute 'dist' I'm not a python expert but it seems platform.dist() is not longer available in python 3.8. A quick and dirty fix is to edit the file /usr/share/hplip/base/password.py and around line 84 edit this: try: os_name = 'debian' except AttributeError: import distro os_name = distro.linux_distribution()[0] into this try: #os_name = platform.dist()[0] os_name = 'debian' except AttributeError: import distro os_name = distro.linux_distribution()[0] In this way the plugin downloads and install just fine. I hope this helps someone.
Bug#948573: Say how to turn message off without installing a certificate.
Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=2545 On 2020-03-26 Andreas Metzler wrote: > On 2020-03-25 積丹尼 Dan Jacobson wrote: > > /usr/share/doc/exim4/README.Debian.gz > > Says > >This informative message can be ignored. > > But doesn't say how to turn it off without installing a certificate. > That is how things are. Either you install a cert or you get a message. Now reported upstream as wishlist request. cu Andreas
Bug#955009: font-manager: please make the build reproducible
Source: font-manager
Version: 0.7.3-1.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] we noticed that
font-manager could not be built reproducibly.
This is because it embeds @abs_top_srcdir@ [1] into the final executable
when attempting (presumably at runtime?) to load GConf settings:
│ │ │ │ │0x00549710 4e6f2073 6368656d 61207769 74682069 No schema with i
│ │ │ │ │0x00549720 64202573 20696e20 64656661 756c7420 d %s in default
│ │ │ │ │ - 0x00549730 736f7572 6365 2f627569 6c642f31 source../build/1
│ │ │ │ │ - 0x00549740 73742f66 6f6e742d 6d616e61 6765722d st/font-manager-
│ │ │ │ │ - 0x00549750 302e372e 372f6f62 6a2d7838 365f3634 0.7.7/obj-x86_64
│ │ │ │ │ - 0x00549760 2d6c696e 75782d67 6e752f64 61746100 -linux-gnu/data.
│ │ │ │ │ + 0x00549730 736f7572 6365 2f627569 6c642f32 source../build/2
│ │ │ │ │ + 0x00549740 2f666f6e 742d6d61 6e616765 722d302e /font-manager-0.
│ │ │ │ │ + 0x00549750 372e372f 326e642f 6f626a2d 7838365f 7.7/2nd/obj-x86_
│ │ │ │ │ + 0x00549760 36342d6c 696e7578 2d676e75 2f646174 64-linux-gnu/dat
│ │ │ │ │ + 0x00549770 6100 536b6970 70696e67 a...Skipping
As this is not going to work at runtime, I have attached a patch that
removes the reference to @abs_top_srcdir@. I am assuming this will
have no effect on build-time tests so you may wish to check this.
[0] https://reproducible-builds.org/
[1]
https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Preset-Output-Variables.html
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Description: Make the build reproducible
Author: Chris Lamb
Last-Update: 2020-03-26
--- font-manager-0.7.3.orig/lib/Common/Settings.vala.in
+++ font-manager-0.7.3/lib/Common/Settings.vala.in
@@ -22,8 +22,7 @@
*/
const string [] POSSIBLE_SCHEMA_DIRS = {
-"@prefix@/share/glib-2.0/schemas",
-"@abs_top_srcdir@/data"
+"@prefix@/share/glib-2.0/schemas"
};
public Settings? get_gsettings (string schema_id) {
Bug#955005: Relax requirements to copy copyright notices into d/copyright
On March 26, 2020 4:57:12 PM UTC, Sean Whitton wrote: >Package: debian-policy >Version: 4.5.0.0 >User: debian-pol...@packages.debian.org >Usertags: normative discussion >X-debbugs-cc: debian-de...@lists.debian.org, ftpmas...@debian.org > >Scott has provided a useful summary of what the FTP Team require when >it >comes to copyright information, and as another FTP Team member, I >concur >with his assessment of the consensus within the team: > >On Thu 26 Mar 2020 at 10:32AM -04, Scott Kitterman wrote: > >> I think you assume we're looking for more than we are. We aren't >asking >> anyone to research and document undocumented but technically legally >> assertable copyright claims. From an FTP perspective we're after >license >> compliance. >> >> If debian/copyright includes all the copyright notices that upstream >does (or >> an equivalent), then that's all that's needed (there are exceptions, >I have >> reviewed packages where upstream literally wrote that they had copied >a bunch >> of code from some other location, changed the copyright owner to >themselves, >> and changed the license - that we had a problem with, but it wasn't >like we >> went looking for it). >> >> To pick one example, the Expat (MIT) license includes: >> >> The above copyright notice and this permission notice shall be >> included in all copies or substantial portions of the Software. >> >> When we ask for listing copyright holders in debian/copyright, that's >what >> we're after. I don't think complying with license requirements is an >> unreasonable thing to ask. >> >> That said, if we can make it easier for everyone, then we should >investigate >> that. As mentioned, policy does have a higher bar. It says they all >have to >> be listed regardless of license requirements. >> >> To pick another example, Apache-2.0 includes: >> >> (c) You must retain, in the Source form of any Derivative Works >> that You distribute, all copyright, patent, trademark, and >> attribution notices from the Source form of the Work, >> excluding those notices that do not pertain to any part of >> the Derivative Works; and >> >> For something that we distribute based on our rights in the >Apache-2.0 license >> and requirement to document all the copyright holders is strictly >Debian >> specific based on policy. Personally, I think the policy should be >changed so >> we don't require everyone to go beyond the license requirements. >Currently I >> think there is consensus within the FTP Team not to reject packages >for this. > >Policy currently says: > >Every package must be accompanied by a verbatim copy of its >copyright information, unless its distribution license explicitly >permits this information to be excluded from distributions of >binaries built from the source. In such cases, a verbatim copy of >its copyright information should normally still be included, but >need not be if creating and maintaining a copy of that information >involves significant time and effort. > >We wrote this based on [1], but I now believe it is too conservative, >and does not reflect what the FTP Team require, nor the project's >consensus on what should be in d/copyright. I think we want something >like this: > >The copyright information for files in a package must be copied >verbatim into d/copyright when (i) the distribution license for >those files requires that copyright information be included in all >binary distributions; (ii) the files are shipped in the binary >package, either in source or compiled form; and (iii) the form in > which the files are present in the binary package does not include a >plain text version of their copyright notices. > >Thus, the copyright information for files in the source package >which are only part of its build process, such as autotools files, >need not be included in d/copyright, because those files do not get >installed into the binary package. Similarly, plain text files > which include their own copyright information and are installed into >the binary package unmodified need not have that copyright >information copied into d/copyright. > > However, the copyright notices for any files which are complied into >the object code shipped in the binary package must all be included >in d/copyright when the license requires that copyright information >be included in all binary distributions, as most do. > >The point of separating (ii) and (iii) is because the source form of a >file need not be plain text, such as image files, and because even for >plain text files the copyright information may not be included in the >files themselves, but perhaps only in LICENSE.txt or similar. > >This is, I believe, the minimum required for license compliance when it >comes to copyright notices. It is significantly weaker than what >Policy >currently requires, but I think we have a project consensus
Bug#955008: black: black --version reports incorrect version
Package: black Version: 19.10b0-2 Severity: normal ~$ dpkg-query --show black black 19.10b0-2 ~$ black --version black, version 18.9b0 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages black depends on: ii python33.8.2-2 ii python3-appdirs1.4.3-2.1 ii python3-attr 19.3.0-2 ii python3-click 7.0-3 ii python3-pathspec 0.7.0-2 ii python3-pkg-resources 44.0.0-1 ii python3-regex 0.1.20190819-2 ii python3-toml 0.10.0-3 ii python3-typed-ast 1.4.1-1 black recommends no packages. Versions of packages black suggests: pn python-black-doc -- no debconf information signature.asc Description: PGP signature
Bug#955007: kile: Kile can't replace the circumflex accent by it's Latex equivalent
Package: kile Version: 4:2.9.93-1 Severity: normal Tags: upstream Dear Maintainer, When using the genral option in Kile "Automatically insert the LaTex equivalent of the special caracters when typing " It fails for the circumflex accent : When typing on my machine ê it just the ê is seen for a fraction of second and is "erased" and disapeared. (no pb with French locales, everywhere else including here the display is correct : ê ) Cheers, Laurent -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kile depends on: ii kinit 5.62.0-1+b1 ii kio5.62.1-2+b1 ii konsole-kpart 4:19.08.1-2+b1 ii libc6 2.30-2 ii libgcc-s1 [libgcc1]10-20200312-2 ii libgcc11:10-20200312-2 ii libkf5codecs5 5.62.0-1 ii libkf5completion5 5.62.0-1+b1 ii libkf5configcore5 5.62.0-1+b1 ii libkf5configgui5 5.62.0-1+b1 ii libkf5configwidgets5 5.62.0-1+b1 ii libkf5coreaddons5 5.62.0-1 ii libkf5crash5 5.62.0-1+b1 ii libkf5dbusaddons5 5.62.0-1 ii libkf5guiaddons5 5.62.0-2 ii libkf5i18n55.62.0-1 ii libkf5iconthemes5 5.62.0-1+b1 ii libkf5jobwidgets5 5.62.0-1+b1 ii libkf5khtml5 5.62.0-1+b1 ii libkf5kiocore5 5.62.1-2+b1 ii libkf5kiofilewidgets5 5.62.1-2+b1 ii libkf5kiowidgets5 5.62.1-2+b1 ii libkf5parts5 5.62.0-1+b1 ii libkf5service-bin 5.62.0-1 ii libkf5service5 5.62.0-1 ii libkf5texteditor5 5.62.0-1+b1 ii libkf5textwidgets5 5.62.0-1+b1 ii libkf5widgetsaddons5 5.62.0-1+b1 ii libkf5windowsystem55.62.0-2+b1 ii libkf5xmlgui5 5.62.0-1+b1 ii libpoppler-qt5-1 0.71.0-6 ii libqt5core5a 5.12.5+dfsg-9 ii libqt5dbus55.12.5+dfsg-9 ii libqt5gui5 5.12.5+dfsg-9 ii libqt5script5 5.12.5+dfsg-2 ii libqt5widgets5 5.12.5+dfsg-9 ii libqt5xml5 5.12.5+dfsg-9 ii libstdc++6 10-20200312-2 ii okular 4:19.12.3-1 ii perl 5.30.0-9 ii texlive-latex-base 2019.20200302-1 Versions of packages kile recommends: ii dvipng 1.15-1.1+b1 ii ghostscript 9.52~dfsg-1 ii imagemagick 8:6.9.10.23+dfsg-2.1+b2 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2 ii psutils 1.17.dfsg-4 ii texlive 2019.20200302-1 Versions of packages kile suggests: ii aspell 0.60.8-1 pn asymptote pn context pn dblatex ii ispell 3.4.00-8 pn kbibtex pn kile-doc pn kile-l10n pn latex2html pn lilypond ii texlive-plain-generic [tex4ht] 2019.202000302-1 pn texlive-xetex ii zip 3.0-11+b1 -- no debconf information
Bug#955006: src:gubbins: fails to migrate to testing for too long: ftbfs on i386
Source: gubbins Version: 2.3.5-1 Severity: serious Control: fixed -1 2.4.1-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync 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:gubbins in its current version in unstable has been trying to migrate for 64 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 marked the version in unstable as fixing this bug, 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=gubbins signature.asc Description: OpenPGP digital signature
Bug#954998: update
On Thu, 26 Mar 2020 17:58:27 +0100, gregor herrmann wrote: > And maybe we should create a backport for libconfig-model-dpkg-perl … Or maybe not: pbuilder-satisfydepends-dummy : Depends: licensecheck (>= 3.0.45) but it is not going to be installed Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Bruce Springsteen: The River signature.asc Description: Digital Signature
Bug#951979: Anything related to recent patch from Ubuntu?
Well I did some more digging.
I believe it's the Python variables which are wrong. Specifically the
${Python_INCLUDE_DIR}
I believe the correct variable is ${Python_INCLUDE_DIRS}
I made a patch, which patches the old patch.
I created a merge request in salsa with the change.
Håvard
Bug#954998: update
On Thu, 26 Mar 2020 11:23:23 -0500, Ryan Pavlik wrote: > OK, I found lintian 2.55.0~bpo10+1 on snapshot.d.o, and cme edit dpkg > works fine there. So, some change between lintian 2.55.0~bpo10+1 and > 2.57.0~bpo10+1 broke cme edit dpkg. Right, that was lintian 2.57.0 breaking libconfig-model-dpkg-perl; the latter is fixed in version 2.132. For some background cf. https://lists.debian.org/debian-perl/2020/03/msg00027.html Maybe lintian should add a "Breaks: libconfig-model-dpkg-perl (<< 2.132)" … And maybe we should create a backport for libconfig-model-dpkg-perl … Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Bruce Springsteen: The River signature.asc Description: Digital Signature
Bug#955005: Relax requirements to copy copyright notices into d/copyright
Package: debian-policy Version: 4.5.0.0 User: debian-pol...@packages.debian.org Usertags: normative discussion X-debbugs-cc: debian-de...@lists.debian.org, ftpmas...@debian.org Scott has provided a useful summary of what the FTP Team require when it comes to copyright information, and as another FTP Team member, I concur with his assessment of the consensus within the team: On Thu 26 Mar 2020 at 10:32AM -04, Scott Kitterman wrote: > I think you assume we're looking for more than we are. We aren't asking > anyone to research and document undocumented but technically legally > assertable copyright claims. From an FTP perspective we're after license > compliance. > > If debian/copyright includes all the copyright notices that upstream does (or > an equivalent), then that's all that's needed (there are exceptions, I have > reviewed packages where upstream literally wrote that they had copied a bunch > of code from some other location, changed the copyright owner to themselves, > and changed the license - that we had a problem with, but it wasn't like we > went looking for it). > > To pick one example, the Expat (MIT) license includes: > > The above copyright notice and this permission notice shall be > included in all copies or substantial portions of the Software. > > When we ask for listing copyright holders in debian/copyright, that's what > we're after. I don't think complying with license requirements is an > unreasonable thing to ask. > > That said, if we can make it easier for everyone, then we should investigate > that. As mentioned, policy does have a higher bar. It says they all have to > be listed regardless of license requirements. > > To pick another example, Apache-2.0 includes: > > (c) You must retain, in the Source form of any Derivative Works > that You distribute, all copyright, patent, trademark, and > attribution notices from the Source form of the Work, > excluding those notices that do not pertain to any part of > the Derivative Works; and > > For something that we distribute based on our rights in the Apache-2.0 license > and requirement to document all the copyright holders is strictly Debian > specific based on policy. Personally, I think the policy should be changed so > we don't require everyone to go beyond the license requirements. Currently I > think there is consensus within the FTP Team not to reject packages for this. Policy currently says: Every package must be accompanied by a verbatim copy of its copyright information, unless its distribution license explicitly permits this information to be excluded from distributions of binaries built from the source. In such cases, a verbatim copy of its copyright information should normally still be included, but need not be if creating and maintaining a copy of that information involves significant time and effort. We wrote this based on [1], but I now believe it is too conservative, and does not reflect what the FTP Team require, nor the project's consensus on what should be in d/copyright. I think we want something like this: The copyright information for files in a package must be copied verbatim into d/copyright when (i) the distribution license for those files requires that copyright information be included in all binary distributions; (ii) the files are shipped in the binary package, either in source or compiled form; and (iii) the form in which the files are present in the binary package does not include a plain text version of their copyright notices. Thus, the copyright information for files in the source package which are only part of its build process, such as autotools files, need not be included in d/copyright, because those files do not get installed into the binary package. Similarly, plain text files which include their own copyright information and are installed into the binary package unmodified need not have that copyright information copied into d/copyright. However, the copyright notices for any files which are complied into the object code shipped in the binary package must all be included in d/copyright when the license requires that copyright information be included in all binary distributions, as most do. The point of separating (ii) and (iii) is because the source form of a file need not be plain text, such as image files, and because even for plain text files the copyright information may not be included in the files themselves, but perhaps only in LICENSE.txt or similar. This is, I believe, the minimum required for license compliance when it comes to copyright notices. It is significantly weaker than what Policy currently requires, but I think we have a project consensus that we should not be requiring more than what is required for license compliance. Of course, it is still open to maintainers to include more information in d/copyrigh
Bug#944553: midori deletes my files
Control: severity -1 important On Tue, 18 Feb 2020, Sergio Durigan Junior wrote: > Thanks for the report. > > It's not clear from your description whether tmpa_crtoef.htm is the > only file that triggers this behaviour, or if this happens with any file > when you try opening it with Midori. > > I gave it a quick try with a simple file here and could not reproduce > the issue: Given this and the lack of upstream answer I'm downgrading this bug to important because midori has been removed from testing due to this unreproducible issue! Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Bug#911378: cutecom: Send file always fails
Hello Roman, On Sat, 20 Oct 2018 21:32:59 +0300 Roman Khimov wrote: > В письме от пятница, 19 октября 2018 г. 13:20:08 MSK Вы написали: > > Please incorporate the fix from above issue into the Debian package or > > update Debian's version to 0.45.0 which includes the fix. > > Thanks for the bug, I think it's time to update it, I have a half-baked > update > to version 0.40.0, now need to bring it into the 2018. I would be happy to use the "sz send" feature. Maybe I can help you somehow with updating the package? Thanks for maintaining cutecom! Cheers, Lars
Bug#948573: Say how to turn message off without installing a certificate.
On 2020-03-25 積丹尼 Dan Jacobson wrote: > /usr/share/doc/exim4/README.Debian.gz > Says >This informative message can be ignored. > But doesn't say how to turn it off without installing a certificate. That is how things are. Either you install a cert or you get a message.
Bug#955004: linux-image-5.4.0-4-amd64: Missing module CONFIG_I2C_AMD_MP2 for some touchpads/touchscreens
Package: src:linux Version: 5.4.19-1 Severity: normal Dear Maintainer, Problem : The problem was that my Lenovo Ideapad 530s touchpad's wasn't recognized (not listed in /proc/bus/input/devices and not recognized by gnome). Resolution : I compiled a 5.4.19 kernel with the same configuration as the debian one's but i just added CONFIG_I2C_AMD_MP2=y and it worked. So the fix will be to include CONFIG_I2C_AMD_MP2 in the kernel build. Thanks :) -- Package-specific info: ** Version: Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-4-amd64 root=UUID=cf4ba8a3-69e8-4a39-9bd3-78ba7c156f9d ro quiet ** Not tainted ** Kernel log: [3.530939] systemd[1]: plymouth-read-write.service: Succeeded. [3.531302] systemd[1]: Finished Tell Plymouth To Write Out Runtime Data. [3.531757] systemd[1]: Started Journal Service. [3.539193] usbcore: registered new interface driver btusb [3.544808] systemd-journald[278]: Received client request to flush runtime journal. [3.571188] audit: type=1400 audit(1585240888.557:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=561 comm="apparmor_parser" [3.571384] audit: type=1400 audit(1585240888.557:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=562 comm="apparmor_parser" [3.571389] audit: type=1400 audit(1585240888.557:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=562 comm="apparmor_parser" [3.571929] audit: type=1400 audit(1585240888.557:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=565 comm="apparmor_parser" [3.571933] audit: type=1400 audit(1585240888.557:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=565 comm="apparmor_parser" [3.571936] audit: type=1400 audit(1585240888.557:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=565 comm="apparmor_parser" [3.571994] audit: type=1400 audit(1585240888.557:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=564 comm="apparmor_parser" [3.573028] audit: type=1400 audit(1585240888.561:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" pid=560 comm="apparmor_parser" [3.573299] audit: type=1400 audit(1585240888.561:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=567 comm="apparmor_parser" [3.681587] kvm: Nested Virtualization enabled [3.681593] kvm: Nested Paging enabled [3.681593] SVM: Virtual VMLOAD VMSAVE supported [3.681593] SVM: Virtual GIF supported [3.684526] MCE: In-kernel MCE decoding enabled. [3.686753] EDAC amd64: Node 0: DRAM ECC disabled. [3.686754] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) [3.700902] ath10k_pci :01:00.0: firmware: failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2) [3.700940] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [3.700987] ath10k_pci :01:00.0: firmware: failed to load ath10k/cal-pci-:01:00.0.bin (-2) [3.702185] ath10k_pci :01:00.0: firmware: direct-loading firmware ath10k/QCA9377/hw1.0/firmware-6.bin [3.702191] ath10k_pci :01:00.0: qca9377 hw1.1 target 0x05020001 chip_id 0x003821ff sub 17aa:0901 [3.702192] ath10k_pci :01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 [3.702617] ath10k_pci :01:00.0: firmware ver WLAN.TF.2.1-00021-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32 42e41877 [3.745752] EDAC amd64: Node 0: DRAM ECC disabled. [3.745754] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) [3.767454] ath10k_pci :01:00.0: firmware: direct-loading firmware ath10k/QCA9377/hw1.0/board-2.bin [3.767639] ath10k_pci :01:00.0: board_file api 2 bmi_id N/A crc32 8aedfa4a [3.786119] EDAC amd64: Node 0: DRAM ECC disabled. [3.786120] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) [3.843427] ath10k_pci :01:00.0: unsupported HTC service id: 1536 [
Bug#955003: command-not-found: Does not work on raspbian due to rpi package source
Package: command-not-found
Version: 18.04.5-1
Severity: important
Dear Maintainer,
Sorry for using debian bug system to report the issue, this is the only
bug tracking mentioned in software --helps and it is a hard-to-google
sython package info)e.
Software simply breaks on any invocation on standard raspbian system,
due to unability to handle rpi in /etc/apt/sources.list. The software
can be fixed by simply adding rpi to the file
/usr/share/command-not-found/CommandNotFound/db/creator.py:
component_priorities = {
'main': 120,
'rpi': 110,
'universe': 100,
'contrib': 80,
'restricted': 60,
'non-free': 40,
'multiverse': 20,
}
(it would also be a good thing to have a pointer to software's own issue
tracker or homepage in --help or similar as well as in the python
package info)
-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux bullseye/sid
Release:testing
Codename: bullseye
Architecture: armv7l
Kernel: Linux 4.19.97-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to fi_FI.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to fi_FI.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages command-not-found depends on:
ii apt-file 3.2.2
ii lsb-release 11.1.0+rpi1
ii python3 3.7.5-3
ii python3-apt 1.9.10
command-not-found recommends no packages.
Versions of packages command-not-found suggests:
pn snapd
-- no debconf information
Bug#955002: mm-common-get is missed from the *.deb package
Package: mm-common Version: 0.9.12-1 Severity: normal mm-common-get script is missed. https://packages.debian.org/sid/all/mm-common/filelist Is there any reason for that? -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mm-common depends on: ii automake [automaken] 1:1.16.1-4 ii libtool 2.4.6-14 ii pkgconf [pkg-config] 1.6.3-5+b1 Versions of packages mm-common recommends: ii clang-8 [c++-compiler] 1:8.0.1-9 ii clang-9 [c++-compiler] 1:9.0.1-10 ii doxygen 1.8.16-2 ii g++ [c++-compiler] 4:9.2.1-3.1 ii g++-9 [c++-compiler]9.3.0-3 ii graphviz2.42.2-3+b1 ii xsltproc1.1.34-4 Versions of packages mm-common suggests: pn libglibmm-2.4-dev pn libglibmm-2.4-doc ii libsigc++-2.0-doc 2.10.2-1
Bug#949641: This has been fixed upstream by commit ba38b44
Hi there, Upstream fixed the specific issue sometime back, see https://github.com/translate/translate/commit/ba38b4465f555863df7640c156abb23cc219222c -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#955001: ITP: spdx-license-text -- Collection of license data provided by SPDX
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: spdx-licenses Version : 3.8 Upstream Author : SPDX Workgroup * URL : https://github.com/spdx/license-list-data * License : public-domain Programming Lang: text Description : Collection of license data provided by SPDX Workgroup SPDX License Text provides a collection of license data (text, meta, etc.) assembled by SPDX Workgroup, a Linux Foundaition Project. This includes all of the most common licenses as well as many not-so-common and deprecated licenses. -- Michael Lustfield
Bug#954998: update
control: affects -1 lintian OK, I found lintian 2.55.0~bpo10+1 on snapshot.d.o, and cme edit dpkg works fine there. So, some change between lintian 2.55.0~bpo10+1 and 2.57.0~bpo10+1 broke cme edit dpkg. Ryan
Bug#954965: /etc/ssh/ssh_config: ssh_config: Include custom config files at the end, so they can overwrite the default settings
Mar 25, 2020, 23:07 by cjwat...@debian.org: > On Wed, Mar 25, 2020 at 10:33:20PM +0100, Jan wrote: > >> /etc/ssh/ssh_config now includes /etc/ssh/ssh_config.d/*.conf but does so >> at the beginning. Thus custom config files cannot overwrite the default >> options, all of which are set afterwards. >> > But, as ssh_config(5) says, "the first obtained value for each parameter > is used". > I have to admit that I missed that. Even more embarrassing as it's also state in the beginning of /etc/ssh/ssh_config. It does not apply in my case though, see below. > I tested this and confirmed that it was possible to use files > in /etc/ssh/ssh_config.d/*.conf to override default options in > /etc/ssh/ssh_config. > > What tests did you perform? > I want to avoid sending any environment, but /etc/ssh/ssh_config has | SendEnv LANG LC_* So I originally put | Host * | SendEnv -LANG -LC_* into /etc/ssh/ssh_config.d/no_env.conf. It works when I included that file at the very end of /etc/ssh/ssh_config. Just setting SendEnv at the beginning (via included files) does not help because this option has append semantics and the prepended dash only remove entries that already exist. Regards, Jan
Bug#954959: libunivalue: CVE-2019-18936
Quoting Salvatore Bonaccorso (2020-03-26 16:09:56) > Hi Jonas, > > On Thu, Mar 26, 2020 at 03:19:45PM +0100, Jonas Smedegaard wrote: > > Quoting Salvatore Bonaccorso (2020-03-26 14:56:39) > > > Hey Jonas! > > > > > > [Cc'ing security team address] > > > > > > On Thu, Mar 26, 2020 at 12:13:34PM +0100, Jonas Smedegaard wrote: > > > > Quoting Salvatore Bonaccorso (2020-03-25 21:07:13) > > > > > The following vulnerability was published for libunivalue. > > > > > > > > > > CVE-2019-18936[0]: > > > > > | UniValue::read() in UniValue before 1.0.5 allow attackers to > > > > > | cause a denial of service (the class internal data reaches an > > > > > | inconsistent state) via input data that triggers an error. > > > > > > > > > > > > > > > If you fix the vulnerability please also make sure to include the > > > > > CVE (Common Vulnerabilities & Exposures) id in your changelog > > > > > entry. > > > > > > > > > > For further information see: > > > > > > > > > > [0] https://security-tracker.debian.org/tracker/CVE-2019-18936 > > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18936 > > > > > [1] https://github.com/jgarzik/univalue/pull/58 > > > > > > > > I have prepared fixed packages for stretch and buster for this > > > > issue. > > > > > > > > In case you want to examine my work (I how highly appreciate that!) > > > > they are available on newly created branches debian/buster and > > > > debian/stretch in git > > > > g...@salsa.debian.org:cryptocoin-team/libunivalue.git a.k.a. > > > > https://salsa.debian.org/cryptocoin-team/libunivalue.git > > > > > > > > How do I proceed? > > > > > > Many thanks for working on fixes in all affected branches. I quickly > > > skimmed over the cherry-picked patch and it looks good to me. That > > > said though the issue looks to me more a no-DSA candidate, and could > > > be fixed in a regular point release. > > > > > > Unless you feel I'm overlooking something important, can I route you > > > there? > > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions > > > > > > contains some information. > > > > I think you know better than me which types of CVEs are DSA candidates. > > > > If you consider this a non-DSA bug then it seems (from above referenced > > URL) that the release managers prefer that you apply a "non-DSA" tag in > > the CVE tracker. > > Yes which I did actually already earlier[1] while replying to you > here :) > > [1] > https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/29eb855aeb7733cbe600080b2277fee115c6cff0 Ah, then it simply takes time to appear at https://security-tracker.debian.org/tracker/source-package/libunivalue (where I checked before posting my request/suggestion). Thanks, I will follow the *-proposed-updates approach. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#955000: azure-cli: Autopkgtest failure in unstable
Package: azure-cli
Version: 2.0.81+ds-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it is the closest one we have.
Now that humanfriendly is fixed to provide the missing files, azure-cli
has what looks like a real test failure [1]. Here's the relevant log
extract:
=== FAILURES ===
__ TestProgress.test_progress_indicator_indet_stdview __
self =
def test_progress_indicator_indet_stdview(self):
# tests the indeterminate progress standardout view
outstream = MockOutstream()
view = progress.IndeterminateStandardOut(out=outstream)
view.write({})
self.assertEqual(view.spinner.label, 'In Progress')
before = view.spinner.total
view.write({})
after = view.spinner.total
> self.assertTrue(after >= before)
E TypeError: '>=' not supported between instances of 'NoneType' and
'NoneType'
../autopkgtest-lxc.r8vnoncs/downtmp/autopkgtest_tmp/tests_core/test_progress.py:63:
TypeError
Scott K
[1]
https://ci.debian.net/data/autopkgtest/testing/amd64/a/azure-cli/4686987/log.gz
Bug#954999: eclipse-titan still encodes an upper dependency on gcc
Package: eclipse-titan Version: 6.6.1-1 Severity: serious Tags sid bullseye eclipse-titan still encodes an upper dependency on gcc. The changelog says this is fixed upstream, nevertheless the package still has this dependency. Plus this dependency is bogus. The gcc-9 package changed to 9.3, and eclipse-titan still seems to work. So an upper dependency on the gcc dependency package doesn't make sene.
Bug#954391: transition: protobuf
Control: tags -1 pending On 25/03/2020 07:06, László Böszörményi (GCS) wrote: > On Mon, Mar 23, 2020 at 10:16 AM Emilio Pozuelo Monfort > wrote: >> On 22/03/2020 12:34, Emilio Pozuelo Monfort wrote: >>> On 22/03/2020 08:33, László Böszörményi (GCS) wrote: Thanks, uploaded. Built on all primary architectures and on secondary ones that have ruby2.7 - only sparc64 regressed if that's the correct phrase as it fails with "fatal error: error writing to /tmp/ccC8qVCe.s: No space left on device". Package grpc also built on all primary architectures. > Built on an other sparc64 buildd with more disk space successfully. > Hurd is a question. I've seen it stuck on 'Maybe-Successful' and > checking the buildd log it was compiled correctly. Now someone > initiated a binNMU and the buildd is stuck with it for five hours now > (normal build time is around thirty minutes on Hurd). > >> Things seem to be in a good shape, except for astroidmail which needs an >> upload >> from experimental as you said, and protobuf itself which is failing its >> autopkgtests: >> >> https://ci.debian.net/data/autopkgtest/testing/amd64/p/protobuf/4635215/log.gz > Meanwhile astroidmail went 'sid only' as its RC bug made it removed > from testing. Fixed autopkgtests in my latest upload looking for its > results on the buildd network. > An other question is opencv as in the transition tracker its marked > unknown status (?) as '?!'. Manually checking its binNMU logs reveals > it built correctly on all supported architectures. > Previously mentioned under-maintained packages ignition-msgs and > ignition-transport: these build correctly but their autopkgtests are > failing. What should be done with packages that have 1.0.0 vs 5.0.0 > and 4.0.0 vs 8.0.0 versions in the Debian archives vs upstream latest > stable release. May these be removed from testing until their DM > update the packages? No point on keeping these for the next Debian > release as is. I removed those due to the failing tests to help protobuf migrate to testing, as it was one of the few remaining blockers on the python3.8 transition. protobuf is in testing now, but there a few rdeps that haven't migrated yet (such as opencv and caffe). Once that transition finishes most of the remaining rdeps will be able to migrate. Cheers, Emilio
Bug#954998: libconfig-model-dpkg-perl: cme edit dpkg does not start
Package: libconfig-model-dpkg-perl Version: 2.122 Severity: important Dear Maintainer, Recently, I have had cme edit dpkg stop working on my Buster system, which is mostly clean, with some use of buster-backports. This seemed to occur in conjunction with an update in which lintian was upgraded - lintian (2.59.0~bpo10+1) over (2.55.0~bpo10+1). However, downgrading (to 2.57~bpo10+1 at least) did not resolve it, so perhaps it was something unrelated. (the only other possibly-related update in that batch was libicu63/libicu-dev.) The error message I get, no matter the package I run it on, is: Reading package lists... Done Building dependency tree Reading state information... Done Single parameters to new() must be a HASH ref data => debian at /usr/share/perl5/Config/Model/Dpkg/Control/Source/StandardVersion.pm line 15. Compilation failed in require at /usr/share/perl5/Config/Model/Node.pm line 247, line 84. I have in the past attempted to backport newer versions of this package and its deps, but as it introduced a number of dependencies I was unfamiliar with, I did give up rather quickly, and I don't believe I have any of them installed. Thanks for any help. Ryan -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.3-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libconfig-model-dpkg-perl depends on: ii libapt-pkg-perl0.1.34+b1 ii libarray-intspan-perl 2.003-1 ii libconfig-model-backend-yaml-perl 2.133-2 ii libconfig-model-perl 2.133-1 ii libexporter-lite-perl 0.08-1 ii liblog-log4perl-perl 1.49-1 ii libmouse-perl 2.5.6-1+b1 ii libparse-recdescent-perl 1.967015+dfsg-2 ii libsoftware-licensemoreutils-perl 1.004-1 ii libtext-autoformat-perl1.74-2 ii libtext-levenshtein-damerau-perl 0.41-1 ii liburi-perl1.76-1 ii libwww-perl6.36-2 ii libyaml-perl 1.27-1 ii licensecheck 3.0.31-3 ii lintian2.57.0~bpo10+1 ii perl [libmodule-corelist-perl] 5.28.1-6 Versions of packages libconfig-model-dpkg-perl recommends: ii libconfig-model-tkui-perl 1.369-2 libconfig-model-dpkg-perl suggests no packages. -- no debconf information
Bug#954865: ruby: Ruby update to 2.7 broke all native extensions, including ones needed for gem pristine
* Calum McConnell [200324 16:30]: > [..] > > /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in > > `require': libruby-2.5.so.2.5: cannot open shared object file: No > > such file or directory - > > /home/calum/gems/gems/psych-3.1.0/lib/psych.so (LoadError) > > > [..] > > Further, I shouldnt need to reinstall ruby: rebuilding native > > extensions should > > be done by the upgrade script. > > Rebuilding gems/extensions that are located in your home directory > or other random places is not something that is allowed to be be done > by the upgrade process. It also wouldn't work in multi-machine setups > and many other cases. Okay, fair enough. > Please rebuild the gems in your home directory yourself, possibly by > deleting them first. I would also recommend using versioned > directories in your gem path to avoid breaking gem itself on such > occasions. Thanks for the solution! My gem directories were auto-generated by Bundler, and given how rarely I use ruby, I don't think its worth the time to try and mess with the defaults. I'm perfectly willing to rm -rf ~/gems once yearly instead. You may want to mention the gem- breaking in the news file, though: many people (okay, at least this person) don't remember that native-extensions are version dependent and require rebuilds. Thanks for the quick assistance, Calum (you can close this bug, if you havent already) signature.asc Description: This is a digitally signed message part
Bug#952043: ruby-ole: FTBFS: ERROR: Test "ruby2.7" failed: /<>/lib/ole/storage/base.rb:352:in `': superclass mismatch for class Header (TypeError)
Package: src:ruby-ole Followup-For: Bug #952043 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The issue seems to be that every test file prepends lib/ to the LOAD_PATH leading to conflicting/duplicate definitions. Changing from d/ruby-test-files.yaml to d/ruby-tests.rake fixes the issue. Otherwise removing the lines, where lib/ is prepended, works too. Regards, Daniel - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl58yRIACgkQS80FZ8KW 0F0ZUQ/9GBHmh9JR0DsVSALUdAvfubfFvXpv1iooy1yVJqH+JDWRr2bxCqXKTWak vnE/eoOzkg1MOMxbelD+8yTb5yA+HxGVasVuGz0xU9eCzpEXcaPelFO8o7ha3wZH /VzWDUEaL0nbouTFzdFskbwxNwWgcNsLtXJIWuFiqOc705JEuPKXXZfeWa7mS4tZ DK7ys4wqGqTwn5QvZE1b106YudJYGwu+BoH/wu1qDle/IYeHh++yS3VS37QClStm IrBpBYGD7mF8jYxMwa995JR14Uf1A0Gb7GZ96xX2NWQP+8uaP2wnAtOZNHSJFJQL 7/zulVEpmZ3+jzu7f1/W3+huZQvpTNjUKaUvyCaw549DuKm7o5O56zUx4AGfBu4a MQU8ONGzBz9UJ6H6v4fF6rA1AZLbJ+r4nTJCE2Eyj2aGUcT533F8WfFf4CXCeWQs jKTfHe5RCr3+hZqpwQIpj5aqouTc0lgGKV9jNZNrKLYECgY9mMP3teUILnJs/l0I bYC7q72f2F3UbZ8YmCouFZGSh+9BmlW5V3gwxMSaaP2BSkrbGP1QgCQ4wQdkSf9n rp3RdXjC+9sk+W0+qNrYzvC8qvpvye9NY0nezl4Ogy5nLA41Lpp986a4NcDyBtTp quCCAodg6nLDVNy9s96aj1oAxuoyK3uURSjNiiqWc6ZOld/cJhI= =4GZO -END PGP SIGNATURE-
Bug#954997: mpirun: reading from stdin more than 64k cause crashes
Package: openmpi-bin
Version: 3.1.3-11
Severity: normal
Dear Alastair,
Reading from stdin more than 64k of data cause mpirun to crash randomly.
Not every time but often enogh to be unreliable.
I did not see this issue with 2.0.2-2.
Apparently timing is important.
I join a minimal test program mpicat.c and a test file.
You can try something like
mpicc -Wall mpicat.c -o mpicat
for i in `seq 1 100`;do mpirun -np 12 ./mpicat < file >/dev/null; done
[pari:15569] *** Process received signal ***
[pari:15569] Signal: Segmentation fault (11)
[pari:15569] Signal code: Address not mapped (1)
[pari:15569] Failing at address: 0x88
[pari:15569] [ 0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f3519a06730]
[pari:15569] [ 1]
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_iof_hnp.so(orte_iof_hnp_read_local_handler+0x2ee)[0x7f3514b493ae]
[pari:15569] [ 2]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22c05)[0x7f3519c3ac05]
[pari:15569] [ 3]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f3519c3b537]
[pari:15569] [ 4] mpirun(+0x1522)[0x5629426ba522]
[pari:15569] [ 5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f351985709b]
[pari:15569] [ 6] mpirun(+0x115a)[0x5629426ba15a]
[pari:15569] *** End of error message ***
I worked aroud this bug by issuing
setvbuf(stdin,pari_malloc(SIZE),_IOFBF,SIZE);
with SIZE large enough to hold the file.
Cheers,
Bill.
-- System Information:
Debian Release: 10.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500,
'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-8-amd64 (SMP w/32 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages openmpi-bin depends on:
ii libc62.28-10
ii libevent-2.1-6 2.1.8-stable-4
ii libevent-pthreads-2.1-6 2.1.8-stable-4
ii libhwloc51.11.12-3
ii libopenmpi3 3.1.3-11
ii openmpi-common 3.1.3-11
ii openssh-client [ssh-client] 1:7.9p1-10+deb10u2
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages openmpi-bin recommends:
ii libopenmpi-dev 3.1.3-11
Versions of packages openmpi-bin suggests:
pn gfortran | fortran-compiler
-- no debconf information
#include
#include
#include
int child(void)
{
long a;
MPI_Recv(&a, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();
return 0;
}
int main(void)
{
char buf[1024];
int rank,size;
long i;
if (MPI_Init(0, NULL))
{
fprintf(stderr,"error starting MPI\n");
return 1;
}
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);
if (rank)
return child();
for(i = 0; !feof(stdin); i++)
{
if (fgets(buf,128,stdin)) printf("%s",buf);
if (i%100==1) usleep(1000*100);
if (i>350) break;
}
for(i = 1; i < size; i++)
MPI_Send(&i, 1, MPI_LONG, i, 0, MPI_COMM_WORLD);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();
return 0;
}
.
Bug#954959: libunivalue: CVE-2019-18936
Hi Jonas, On Thu, Mar 26, 2020 at 03:19:45PM +0100, Jonas Smedegaard wrote: > Quoting Salvatore Bonaccorso (2020-03-26 14:56:39) > > Hey Jonas! > > > > [Cc'ing security team address] > > > > On Thu, Mar 26, 2020 at 12:13:34PM +0100, Jonas Smedegaard wrote: > > > Quoting Salvatore Bonaccorso (2020-03-25 21:07:13) > > > > The following vulnerability was published for libunivalue. > > > > > > > > CVE-2019-18936[0]: > > > > | UniValue::read() in UniValue before 1.0.5 allow attackers to > > > > | cause a denial of service (the class internal data reaches an > > > > | inconsistent state) via input data that triggers an error. > > > > > > > > > > > > If you fix the vulnerability please also make sure to include the > > > > CVE (Common Vulnerabilities & Exposures) id in your changelog > > > > entry. > > > > > > > > For further information see: > > > > > > > > [0] https://security-tracker.debian.org/tracker/CVE-2019-18936 > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18936 > > > > [1] https://github.com/jgarzik/univalue/pull/58 > > > > > > I have prepared fixed packages for stretch and buster for this > > > issue. > > > > > > In case you want to examine my work (I how highly appreciate that!) > > > they are available on newly created branches debian/buster and > > > debian/stretch in git > > > g...@salsa.debian.org:cryptocoin-team/libunivalue.git a.k.a. > > > https://salsa.debian.org/cryptocoin-team/libunivalue.git > > > > > > How do I proceed? > > > > Many thanks for working on fixes in all affected branches. I quickly > > skimmed over the cherry-picked patch and it looks good to me. That > > said though the issue looks to me more a no-DSA candidate, and could > > be fixed in a regular point release. > > > > Unless you feel I'm overlooking something important, can I route you > > there? > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions > > > > contains some information. > > I think you know better than me which types of CVEs are DSA candidates. > > If you consider this a non-DSA bug then it seems (from above referenced > URL) that the release managers prefer that you apply a "non-DSA" tag in > the CVE tracker. Yes which I did actually already earlier[1] while replying to you here :) [1] https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/29eb855aeb7733cbe600080b2277fee115c6cff0 Regards, Salvatore
Bug#940264: vpnc-scripts: vpnc-script ignores netmask in VPN-provided routes
Hi, On Sat, 14 Sep 2019 23:00:42 +0300 Dmitry Semyonov wrote: > Package: vpnc-scripts > Version: 0.1~git20190117-1 > Severity: normal > > Dear Maintainer, > > When VPN server (Cisco in my case) provides a list of sub-nets that should not > be routed through VPN, the script creates a bunch of corresponding routes but > omits the provided netmasks, thus effectively ignoring the feature. Moreover, > on termination of VPN connection the script is not able to properly remove > created routes because they use invalid netmask (/32 by default). > > I traced the problem down to the 'route add' command executed inside > set_exclude_route(). The following hack fixes the issue for me: > > cmd="$IPROUTE route add `$IPROUTE route get "$NETWORK/$NETMASKLEN" > | fix_ip_get_output`" > cmd=`echo $cmd | sed -e 's@ via @'"/$NETMASKLEN via @"` # add proper > netmask > $cmd > > (A similar change is needed for set_ipv6_exclude_route() if you use IPv6.) This has been fixed upstream: - http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/fe5cb8a6d9791aa5217db31825b66eb185066a8d - cleanup: http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/0851a20770d875d5b6cb76ec49b3137f56410f9a Any chance this could end up in a stable update? cheers, Stefan
Bug#954960: steam: new steam update crashes with fatal error: could not load steamui.so
On Wed, 25 Mar 2020 at 20:48:37 +, Ximin Luo wrote: > In $STEAMDIR/error.log we see: > > Failed to load steamui.so - dlerror(): > /usr/lib/i386-linux-gnu/libpango-1.0.so.0: undefined symbol: > g_log_structured_standard It looks as though the Steam Runtime infrastructure is selecting libpango from your host OS (Debian), but GLib from the Steam Runtime. That shouldn't be happening: it is meant to use the host OS (i.e. Debian) version of GLib if it's newer, which, in practice, it has been for a long time. Recent versions of Steam have a debugging tool that can be used to diagnose issues like this. It's intended for upstream to use, but should be equally handy for downstreams like us. (You'll find my name in its changelog - I have both of those hats right now.) Please try running: ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh \ ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info It will output quite a lot of JSON. Please send it to this bug report (you can censor it if you want, as long as it's clear which bits you have edited). It might also help to re-run the same tool with the --verbose option, which will list the paths to all the libraries that are part of the Steam Runtime. You could also try running ~/.steam/steam/ubuntu12_32/steam-runtime/setup.sh --force but if you do, please capture a steam-runtime-system-info report before and after you do that, so we can compare. > Launching /usr/games/steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 > works around this problem for now. That option usually breaks the open-source (Mesa) driver stack by using the Steam Runtime's ancient libraries in preference to the ones Mesa needs, so it is generally a bad idea, and it will disappear entirely in the next release of the Steam Runtime. I'm surprised it's having a positive effect for you. smcv
Bug#954718: grub-installer: update templates for UEFI and other media than hard disks
Hi, Steve McIntyre wrote: > > > >I have attached an updated patch, which might be considered. > > I think this is better, yes. :-) Taking into account Adrian's > feedback, maybe s/primary drive/hard disk/ in most places? No, with Justin as native speaker, we came to "primary drive", so I will stick with that. > Thanks for this effort - it's definitely good to move away from the > misleading "MBR" text. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
