Bug#1071586: kicad: bookworm-backports requires update to 8.x
Package: kicad Version: 7.0.11+dfsg-1~bpo12+1 Severity: wishlist Backports is expected to track the version in testing. But at the moment, it is unfortunately from an older version. It would be nice to have an upload to bookworm-backports which updates it to the "same" version. If there are any blockers then it would also be nice to just hear about them. (btw. thanks for all the work. I just got curious and took this as an opportunity to create this ticket to track the state).
Bug#1069191: glibc: GLIBC-SA-2024-0004/CVE-2024-2961: ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence
Hi, Can this be backported to older Debian versions via the security repo? This bug can be used to execute code when using the PHP engine: * https://www.offensivecon.org/speakers/2024/charles-fol.html * https://www.openwall.com/lists/oss-security/2024/04/18/4
Bug#1064476: dpkg-buildflags: add support for building with frame pointers enabled
Control: merge 1064476 1058665 1058664 I would even love to have finally a debian again which can be used to debug and profile production ready binaries (at least on amd64). See also * https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html * https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default * https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
Bug#1037363: libkf5mimetreeparser5abi1: does not find the key used to sign a message if a signing subkey was used
Package: libkf5mimetreeparser5abi1 Version: 4:22.12.3-1 Tags: bookworm sid patch upstream Forwarded: https://bugs.kde.org/show_bug.cgi?id=469304 Control: affects -1 kmail SUMMARY KMail claims that messages signed with a subkey of my own key are signed with an unknown key. STEPS TO REPRODUCE 1. You need an OpenPGP certficate with a signing subkey. 2. Sign a message with this key and send it to yourself (or use Send Later to put it in your outbox). 3. View the message. OBSERVED RESULT I have an OpenPGP certficate with a signing subkey that is used to sign my messages. KMail has no problem signing my messages, but when viewing my messages KMail says: > Message was signed on 25.04.23 18:24 with unknown key > 0xDB8E020E328C30942060BF21B16F599516474ABA. > The validity of the signature cannot be verified. > Status: Good signature Obviously, this doesn't make any sense because how can the signature be good if it was signed with an unknown key. It turns out that gpg which is used to verify the signature very well knows the key, but KMail is not able to find it. EXPECTED RESULT KMail should say something like: > Message was signed by *@ingo-kloecker.de (Key ID: 0xE375339BF4C51840). > The signature is valid and the key is ultimately trusted. The fix can be found at https://invent.kde.org/pim/messagelib/commit/70f39256784280d2034aa7bf1c4765f606c22d56
Bug#1031616: kmail: E-Mail signed with gnupg subkey not properly shown as valid
Package: kmail Version: 22.12.2-1 Severity: normal Tags: bookworm sid upstream Forwarded: https://bugs.kde.org/show_bug.cgi?id=465551 SUMMARY I'm using gnupg with an subkey to sign my e-mails. KMail shows following message when a e-mail was signed with the gnugp subkey: "Not enough information to check signature validity." Details message: "Message was signed on with unknown key . The validity of the signature cannot be verified. Status: Good signature" Expected STEPS TO REPRODUCE 1. Create e-mail in composer, with signing active (using an gnupg key with an signing only subkey) 2. save e-mail as draft (just for simplicity - sending the mail to yourself would also work) 3. Open draft email (preview - not the editing) OBSERVED RESULT KMail shows an orange border with following message when a e-mail was signed with the gnugp subkey: "Not enough information to check signature validity." Details message: "Message was signed on with unknown key . The validity of the signature cannot be verified. Status: Good signature" EXPECTED RESULT Showing an green border. This is also the result I see in Debian bullseye with gpg 2.2.27-2, kmail 20.08.3 and 5.20.5 ADDITIONAL INFORMATION The log output when "Write server mode logs to FILE" is configured shows following Information when the signed e-mail is opened: 2023-02-10 17:06:11 gpg[1848451] armor: BEGIN PGP SIGNATURE 2023-02-10 17:06:11 gpg[1848451] Signature made Do 22 Dez 2022 11:53:36 CET 2023-02-10 17:06:11 gpg[1848451]using RSA key 2023-02-10 17:06:11 gpg[1848451] using subkey instead of primary key 2023-02-10 17:06:11 gpg[1848451] using subkey instead of primary key 2023-02-10 17:06:11 gpg[1848451] using classic trust model 2023-02-10 17:06:11 gpg[1848451] key : accepted as trusted key 2023-02-10 17:06:11 gpg[1848451] Good signature from "" [ultimate] 2023-02-10 17:06:11 gpg[1848451] using subkey instead of primary key 2023-02-10 17:06:11 gpg[1848451] binary signature, digest algorithm SHA256, key algorithm rsa4096 2023-02-10 17:06:11 gpg[1848454] using character set 'utf-8' 2023-02-10 17:06:11 gpg[1848454] using classic trust model 2023-02-10 17:06:11 gpg[1848454] key : accepted as trusted key So gnupg itself uses the subkey to verify the signature Additional information. When I click on the link inside the details message "Message was signed on with unknown key " an kleopatra window opens and shows the correct gnupg key/certificate. It seems that only kmail cannot find the correct gnugpg key/certificate via an gnupg subkey fingerprint
Bug#1003242: python3-mailman-hyperkitty: Need a newer version to match mailman core
Control: tags -1 + fixed-upstream patch security Justification: CVE-2021-35058 https://gitlab.com/mailman/mailman-hyperkitty/-/commit/18816fbd4130a9f08b0885e0421c963879808921 https://gitlab.com/mailman/mailman-hyperkitty/-/commit/df9cdc44dc59c7ed78097ef8f5ba3db46e7a92e9 But it might be better to package 1.2.x instead of cherry-picking this patch
Bug#1025019: python-aiosmtpd: (autopkgtest) needs update for python3.11: Can't decode base64
Control: tags -1 + fixed-upstream patch Patch can be found at https://github.com/aio-libs/aiosmtpd/commit/827f2321b7a926f3e8ba2aad6387b36c7c2e0b9a.patch
Bug#1013480: hyperkitty: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args'
Am Mo., 14. Nov. 2022 um 10:53 Uhr schrieb Pierre-Elliott Bécue : > I really don't need reminders about the bugs on my packages. This is not a reminder. I was just going through the mailman3 packages to understand what is currently blocking the migration of packages. And when I found out what is blocking it, I've only checked if this problem is solved upstream or not. And if it was solved upstream, I added information about the situation in the already existing bug. > Please refrain from putting pressure on people with the expectation that > they'll do what you want at the tine you want. > > This is the last time I reply to such sollicitations. I don't understand why you are so unfriendly.
Bug#1013480: hyperkitty: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args'
Control: tags -1 + fixed-upstream patch This problem currently blocks various mailman3 related packages from migrating to Debian bookwoom. But it seems like this is fixed by 1.3.6: https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-6
Bug#1013500: django-mailman3: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args'
Control: tags -1 + fixed-upstream patch This problem currently blocks various mailman3 related packages from migrating to Debian bookwoom. But it seems like this is fixed by 1.3.8: https://pypi.org/project/django-mailman3/ (btw. thanks for the mailman 3.3.7 upload)
Bug#998223: Contributors for Mailman 3 in Debian / your RFH
> Mailman3 has been part of buster and bullseye, but the release of sqlalchemy > 1.4 is not compatible with it and therefore there is a chance that it will > not make it in bookworm. There is nothing that any contributor can do except > taking the time to help mailman upstream to be fixed and work with sqlalchemy > 1.4. Upstream released a version which is compatible with sqlalchemy 1.4 and which should also fix all other blocking problems in the mailman3 problems. See bug #1023976 for things I am assuming are fixed by it.
Bug#1023976: mailman3: Package version 3.3.7
Package: mailman3 Version: 3.3.3-1 Severity: wishlist Control: block 996806 by -1 Control: tags 996806 + patch fixed-upstream Control: block 995779 by -1 Control: tags 995779 + patch fixed-upstream Control: block 1004934 by -1 Control: tags 1004934 + patch fixed-upstream Control: block 1015989 by -1 Control: tags 1015989 + patch fixed-upstream Control: block 997877 by -1 Control: tags 997877 + patch fixed-upstream The version 3.3.7 was released upstream and should fix all the bugs which are currently breaking mailman 3 on Debian unstable (and preventing it to enter Debian bookworm). https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.html
Bug#995779: autopkgtest fails with sqlalchemy 1.4.23+ds1
Control: tags 995779 + patch This is the upstream merged fix for sqlalchemy 1.4: https://gitlab.com/mailman/mailman/-/commit/c926e3d54680d4fac0648cde036368c699976038
Bug#998223: Contributors for Mailman 3 in Debian / your RFH
Am Sa., 15. Okt. 2022 um 09:39 Uhr schrieb Pierre-Elliott Bécue : > Mailman3 has been part of buster and bullseye, but the release of sqlalchemy > 1.4 is not compatible with it and therefore there is a chance that it will > not make it in bookworm. There is nothing that any contributor can do except > taking the time to help mailman upstream to be fixed and work with sqlalchemy > 1.4. Thanks for the info. This is the upstream merged fix for sqlalchemy 1.4: https://gitlab.com/mailman/mailman/-/commit/c926e3d54680d4fac0648cde036368c699976038
Bug#998223: Contributors for Mailman 3 in Debian / your RFH
Hi, Where can we find results from the new contributors? Because it looks at the moment like Debian bookworm might become the third Debian release (after buster + bullseye) which is unsuitable as a base system for software project servers (redmine + mailman3 + gitolite). At least, for the last two releases, redmine was to blame here but now it looks like mailman3 might be the blocker. See also https://lists.debian.org/debian-devel-announce/2022/10/msg4.html for the Debian bookworm timeline
Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM
Completely disabling the autoupdater was an extremely bad idea. Now even various autoupdater scripts to update the global version in /usr/lib/chromium/WidevineCdm don't work anymore - so leaving users in a broken state. See also #981069
Bug#981069: chromium: Doesn't load widevine from /usr/lib/chromium/WidevineCdm/
Package: chromium Version: 88.0.4324.96-0.1 X-Debbugs-CC: Olivier Tilloy X-Debbugs-CC: mimi8 The changes for ticket #960454 removed the autoupdater for widevine. And then mentions in the README.debian that /usr/lib/chromium/WidevineCdm/ is the place to put the widevine binaries. But this is not working anymore with this chromium version (but worked with older versions from May 2020). Also the patch to load it from $HOME/.local/lib/libwidevinecdm.so doesn't have any effect at all anymore. The only file queried for widevine is now $HOME/.config/chromium/WidevineCdm/latest-component-updated-widevine-cdm And this definitely makes sense because Debian builds it without BUNDLE_WIDEVINE_CDM and so the code (AddContentDecryptionModules's bundled_widevine, ...) is completely disabled - thus disabling $HOME/.local/lib/libwidevinecdm.so and /usr/lib/chromium/WidevineCdm/
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
Package: libselinux1 Version: 2.8-1+b1 Severity: grave Right now, an update from buster to bullseye on amd64 completely bricks the system because libselinux1 is requiring a libc6 which is not yet installed on the system: Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ... De-configuring libselinux1:i386 (2.8-1+b1) ... Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ... tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found (required by /lib/x86_64-linux-gnu/libselinux.so.1) dpkg-deb: error: tar subprocess returned error exit status 1 It is then not possible anymore to recover the system because dpkg (mv, ...) is no longer working. There is most likely some kind dependency missing to let aptitude known that it must first update libc6 before it can update libselinux1. At least on this system, the installed version of libc6 for amd64 and i386 was still 2.28-10 when this happened
Bug#977510: [gajim] File/Link actions cause g-io-error-quark exception
Package: gajim
Version: 1.2.2-1
Severity: important
Tags: patch
X-Debbugs-Cc: pkg-gnome-maintain...@lists.alioth.debian.org
X-Debbugs-Cc: pkg-xmpp-de...@lists.alioth.debian.org
X-Debbugs-Cc: pkg-freedesktop-maintain...@lists.alioth.debian.org
It was noticed that there is a regression when switching from gajim on
Debian buster to gajim on Debian bullseye.
When clicking on a file (aesgcm://) in the chat, the data is
downloaded but the buttons "Open Folder" or "Open" aren't doing
anything. Also clicking on a link will not open a browser window. Only
following is shown in the log for all the described scenarios:
15.12.2020 09:23:17 (E) gajim.c.helpersg-io-error-quark:
No application is registered as handling this file (15)
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gajim/common/helpers.py", line
1044, in func_wrapper
result = func(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/gajim/common/helpers.py", line
1160, in open_file
Gio.AppInfo.launch_default_for_uri(path)
gi.repository.GLib.GError: g-io-error-quark: No application is
registered as handling this file (15)
This can easily be fixed with the attached patch for the dependencies
in debian/control to make sure that desktop-file-utils are installed.
diff --git a/debian/control b/debian/control
index 697079d..11e7a3d 100644
--- a/debian/control
+++ b/debian/control
@@ -31,6 +31,7 @@ Architecture: all
Depends:
${misc:Depends},
${python3:Depends},
+desktop-file-utils,
gir1.2-gtk-3.0 (>= 3.22.27~),
python3 (>= 3.5),
python3-cssutils (>= 1.0.2),
Bug#950500: aqbanking-tools: aqpaypal-tool unable to call any control function
Package: aqbanking-tools Version: 6.0.1-2 Tags: patch The libaqbanking44 or the aqbanking-tools are currently incompatible with each other when calling the aqpaypal backend aqpaypal-tool fff 3:2020/02/02 17-39-18:aqpaypal-tool(16869):aqpaypal-tool.c: 246: Error calling control function (-51) It can be solved by changing --with-backends="aqnone aqhbci aqofxconnect aqebics" in debian/rules to --with-backends="aqnone aqhbci aqofxconnect aqebics aqpaypal"
Bug#947080: [getmail] Crashes when not being able to decode encoding of Cc line
Package: getmail
Version: 5.13-1
Severity: normal
Tags: buster
X-Debbugs-CC: getm...@lists.pyropus.ca
X-Debbugs-CC: charlesc-getmail-supp...@pyropus.ca
I now have to soothe a lot of angry people because I didn't receive
some important mails from one of my accounts (and thus didn't act
correctly). The problem was that I received a mail with following
(raw) Cc line on the same account:
Cc: =?utf-8?b?UmFmYcWCIE1pxYJl?==?utf-8?b?Y2tp?=
It seems like python2 can decode this:
>>> email.header.decode_header('=?utf-8?b?UmFmYcWCIE1pxYJl?= =?utf-8?b?Y2tp?=')
but not
>>> email.header.decode_header('=?utf-8?b?UmFmYcWCIE1pxYJl?==?utf-8?b?Y2tp?=')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/email/header.py", line 108, in decode_header
raise HeaderParseError
email.errors.HeaderParseError
getmail just crashed all the time (and systemd restarted it
automatically) but never downloaded any mail for this specific account
again.
getmail[15939]: Traceback (most recent call last):
getmail[15939]: File "/usr/bin/getmail", line 934, in
getmail[15939]: main()
getmail[15939]: File "/usr/bin/getmail", line 898, in main
getmail[15939]: success = go(configs, options.idle)
getmail[15939]: File "/usr/bin/getmail", line 200, in go
getmail[15939]: msg = retriever.getmsg(msgid)
getmail[15939]: File
"/usr/lib/python2.7/dist-packages/getmailcore/_retrieverbases.py",
line 1008, in getmsg
getmail[15939]: return self._getmsgbyid(msgid)
getmail[15939]: File
"/usr/lib/python2.7/dist-packages/getmailcore/_retrieverbases.py",
line 1934, in _getmsgbyid
getmail[15939]: for (val, encoding) in decode_header(encoded_value):
getmail[15939]: File "/usr/lib/python2.7/email/header.py", line 108,
in decode_header
getmail[15939]: raise HeaderParseError
getmail[15939]: email.errors.HeaderParseError
systemd[261]: getmail.service: Main process exited, code=exited,
status=1/FAILURE
systemd[261]: getmail.service: Failed with result 'exit-code'.
This will no longer affect getmail in Debian sid in the near future
because sid is dropping Python2 (and Python3 doesn't have this
decoding problem).
Bug#945406: chromium: Widevine content decrytion module no longer working
Package: chromium Version: 78.0.3904.97-1~deb10u1 Tags: buster The update in Debian Buster amd64 broke the support for the Widevine content decryption module. It was working fine before with 76.0.3809.100-1~deb10u1. The component is also no longer shown under chrome://components/ and this problem is also visible when going to https://bitmovin.com/demos/drm (see list of supported DRMs in the list) The 4.10.1440.19 version of widevine was installed under /usr/lib/chromium/libwidevinecdm.so . It was downloaded from https://dl.google.com/widevine-cdm/4.10.1440.19-linux-x64.zip. And it is the same version which is also used by Firefox This currently breaks chromium for me with Netflix and Amazon Prime (Music).
Bug#931496: redmine: Missing in Debian Buster
Source: redmine Severity: normal Tags: buster I've just updated my server to Debian buster and then noticed that my redmine was gone. Problem is that it was removed from Debian testing https://tracker.debian.org/news/1027921/redmine-removed-from-testing/ (when Buster was still equal to testing) Please provide an buster-backports upload to allow other admins to upgrade their servers without ending up without redmine or with a broken redmine installation.
Bug#929492: iwyu: Requests to add forward declaration which is in file
Package: iwyu
Version: 7.0-3
Forwarded:
https://github.com/include-what-you-use/include-what-you-use/issues/682
Tags: buster sid
X-Debbugs-CC: Kim Grasman
Problem can reproduced via (please check the first line):
struct foobar;
struct foobar *test(struct foobar *asd)
{
return asd;
}
And then iwyu tells me:
$ iwyu test.c
test.c should add these lines:
struct foobar;
test.c should remove these lines:
The full include-list for test.c:
struct foobar;
---
Something which is already there. Now adding the line again:
struct foobar;
struct foobar;
struct foobar *test(struct foobar *asd)
{
return asd;
}
But it tells me now again that I should add this line again:
$ iwyu test.c
test.c should add these lines:
struct foobar;
test.c should remove these lines:
The full include-list for test.c:
struct foobar;
---
This currently breaks iwyu for me in Debian Buster
Bug#925528: kwin-x11: High CPU load and extreme screen tearing with nvidia driver
Here is a patch which can be applied on top of the kwin package to
include the two patches which modify GlxBackend::GlxBackend.
From ad5f05d207edd32fc8571c9ae6bb916e61b291d4 Mon Sep 17 00:00:00 2001
From: Charlemagne Lasse
Date: Tue, 26 Mar 2019 15:30:19 +0100
Subject: [PATCH] Fix missing vsync and high CPU load with Nvidia's proprietary
driver
---
debian/changelog | 8 ++
.../patches/Fix-flickering-with-Qt-5.12.patch | 47 ++
...pBuffers-to-block-with-NVIDIA-driver.patch | 94 +++
debian/patches/series | 2 +
4 files changed, 151 insertions(+)
create mode 100644 debian/patches/Fix-flickering-with-Qt-5.12.patch
create mode 100644 debian/patches/Force-glXSwapBuffers-to-block-with-NVIDIA-driver.patch
diff --git a/debian/changelog b/debian/changelog
index 0f0e4d3..4f4ce7b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+kwin (4:5.14.5-2) UNRELEASED; urgency=medium
+
+ [ Charlemagne Lasse ]
+ * Backport upstream patches to fix missing vsync and high CPU load with
+Nvidia's proprietary driver (Closes: #925528)
+
+ -- Charlemagne Lasse Tue, 26 Mar 2019 15:26:54 +0100
+
kwin (4:5.14.5-1) unstable; urgency=medium
* New upstream release (5.14.5).
diff --git a/debian/patches/Fix-flickering-with-Qt-5.12.patch b/debian/patches/Fix-flickering-with-Qt-5.12.patch
new file mode 100644
index 000..647fc69
--- /dev/null
+++ b/debian/patches/Fix-flickering-with-Qt-5.12.patch
@@ -0,0 +1,47 @@
+From: Alexander Volkov
+Date: Tue, 22 Jan 2019 22:36:15 +0300
+Subject: Fix flickering with Qt 5.12
+
+Summary:
+Mesa requires XESetWireToEvent xlib callbacks to be called
+when DRI2 is used. This is done by the GLX integration in
+the Qt's xcb plugin, but Qt 5.12 initializes the GLX integration
+only when required, e.g. when a window with OpenGL support is
+created or when availability of OpenGL is checked.
+
+So force initialization of the GLX integration by calling
+QOpenGLContext::supportsThreadedOpenGL().
+
+https://codereview.qt-project.org/#/c/6557/
+https://bugzilla.opensuse.org/show_bug.cgi?id=1120090
+
+Reviewers: #kwin, graesslin
+
+Reviewed By: #kwin, graesslin
+
+Subscribers: davidedmundson, graesslin, fvogt, filipf, kwin
+
+Tags: #kwin
+
+Differential Revision: https://phabricator.kde.org/D18366
+
+Origin: upstream, https://cgit.kde.org/kwin.git/patch/?id=5d63b9c05bbe0c6545b3eeea98d95b40f800fb55
+---
+ plugins/platforms/x11/standalone/glxbackend.cpp | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/plugins/platforms/x11/standalone/glxbackend.cpp b/plugins/platforms/x11/standalone/glxbackend.cpp
+index a2c570e..eb2d464 100644
+--- a/plugins/platforms/x11/standalone/glxbackend.cpp
b/plugins/platforms/x11/standalone/glxbackend.cpp
+@@ -115,6 +115,10 @@ GlxBackend::GlxBackend(Display *display)
+ , haveSwapInterval(false)
+ , m_x11Display(display)
+ {
++ // Force initialization of GLX integration in the Qt's xcb backend
++ // to make it call XESetWireToEvent callbacks, which is required
++ // by Mesa when using DRI2.
++ QOpenGLContext::supportsThreadedOpenGL();
+ }
+
+ static bool gs_tripleBufferUndetected = true;
diff --git a/debian/patches/Force-glXSwapBuffers-to-block-with-NVIDIA-driver.patch b/debian/patches/Force-glXSwapBuffers-to-block-with-NVIDIA-driver.patch
new file mode 100644
index 000..97b5932
--- /dev/null
+++ b/debian/patches/Force-glXSwapBuffers-to-block-with-NVIDIA-driver.patch
@@ -0,0 +1,94 @@
+From: Erik Kurzinger
+Date: Wed, 20 Mar 2019 09:50:13 -0700
+Subject: Force glXSwapBuffers to block with NVIDIA driver
+
+Summary:
+The NVIDIA implementation of glXSwapBuffers will, by default, queue up
+to two frames for presentation before blocking. KWin's compositor,
+however, assumes that calls to glXSwapBuffers will always block until
+the next vblank when rendering double buffered. This assumption isn't
+valid, as glXSwapBuffers is specified as being an implicit glFlush,
+not an implicit glFinish, and so it isn't required to block. When this
+assumption is violated, KWin's frame timing logic will
+break. Specifically, there will be extraneous calls to
+setCompositeTimer with a waitTime of 0 after the non-blocking buffer
+swaps, dramatically reducing desktop responsiveness. To remedy this,
+a call to glXWaitGL was added by Thomas Luebking after glXSwapBuffers
+in 2015 (see bug 346275, commit
+8bea96d7018d02dff9462326ca9456f48e9fe9fb). That glXWaitGL call is
+equivalent to a glFinish call in direct rendering, so it was a good
+way to make glXSwapBuffers behave as though it implied a glFinish
+call.
+
+However, the NVIDIA driver will by default do a busy wait in glFinish,
+for reduced latency. Therefore that change dramatically increased CPU
+usage. GL_YIELD can be set to USLEEP (case insensitive) to change
+the behavior and use usleep instead. When using the NVIDIA driver,
+KWin will disable vsync entirely if GL_YIELD isn't set to USLEEP
+(case
Bug#925528: kwin-x11: High CPU load and extreme screen tearing with nvidia driver
Package: kwin-x11 Version: 4:5.14.5-1 Severity: important Tags: buster sid patch upstream fixed-upstream Forwarded: https://bugs.kde.org/show_bug.cgi?id=322060 kwin-x11 with the current nvidia driver causes extreme high CPU load and tearing. The graphics performance is also reduced to an unacceptable level when compositing is enabled. This is caused by the way how kwin-x11 tries to flush frames - which doesn't work with advanced drivers (like the ones from nvidia). This was better described by Erik Kurzinger in his patch https://phabricator.kde.org/D19867 The NVIDIA implementation of glXSwapBuffers will, by default, queue up to two frames for presentation before blocking. KWin's compositor, however, assumes that calls to glXSwapBuffers will always block until the next vblank when rendering double buffered. This assumption isn't valid, as glXSwapBuffers is specified as being an implicit glFlush, not an implicit glFinish, and so it isn't required to block. When this assumption is violated, KWin's frame timing logic will break. Specifically, there will be extraneous calls to setCompositeTimer with a waitTime of 0 after the non-blocking buffer swaps, dramatically reducing desktop responsiveness. To remedy this, a call to glXWaitGL was added by Thomas Luebking after glXSwapBuffers in 2015 (see bug 346275, commit 8bea96d7018d02dff9462326ca9456f48e9fe9fb). That glXWaitGL call is equivalent to a glFinish call in direct rendering, so it was a good way to make glXSwapBuffers behave as though it implied a glFinish call. However, the NVIDIA driver will by default do a busy wait in glFinish, for reduced latency. Therefore that change dramatically increased CPU usage. GL_YIELD can be set to USLEEP (case insensitive) to change the behavior and use usleep instead. When using the NVIDIA driver, KWin will disable vsync entirely if GL_YIELD isn't set to USLEEP (case sensitive, a bug in KWin). However, the NVIDIA driver supports another environment variable, __GL_MaxFramesAllowed, which can be used to control how many frames may be queued by glXSwapBuffers. If this is set to 1 the function will always block until retrace, in line with KWin's expectations. This allows the now-unnecessary call to glXWaitGL to be removed along with the logic to conditionally disable vsync, providing a better experience on NVIDIA hardware. The patch can be found under https://phabricator.kde.org/D19867 and upstream (Martin Flöser) recommends to backport it to all older versions. This also includes Debian Buster (and maybe also Stretch - not sure about this part)
Bug#922502: plasma-desktop: regional settings allow do select system incompatible locales
> Control: reassign -1 libqt5core5a/5.11.3+dfsg-2 > Control: affects -1 plasma-desktop > > Control: severity -1 important > > Please, don't abuse the bugs severity just to get more attention. I didn't abuse the severity. The https://www.debian.org/Bugs/Developer#severities has an entry "makes unrelated software on the system (or the whole system) break". And this is the case here. There is no obvious relation between plasma-desktop/libqt5core5a and the tex-common installation scripts. The same happened in the tex-common bug (actually worse - they just closed it). I am under the impression that everyone just wants to ignore this problem.
Bug#922213: Bug#922500: tex-common: Fails to install with LC_TIME=en_DE.UTF-8
> On Sun, 17 Feb 2019, Charlemagne Lasse wrote: > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LANGUAGE = "en_US:en", > > LC_ALL = (unset), > > LC_TIME = "en_DE.UTF-8", > > LANG = "C" > > are supported and installed on your system. > > > locale: Cannot set LC_ALL to default locale: No such file or directory > > You have a broken locale setup, there is nothing we can do. luatex needs > correctly setup locales, but they are not. But the installation of tex-common should not fail because of this. It works fine when LC_TIME is not set to C or en_US.UTF-8 and so on (everything which locales-all provides). If the installation of a package fails because a user set locale is wrong then something is terrible broken with your installation process. I understand that it may fail when the user calls luatex manually with some incorrect env but not when the installation process is run. Setup/Installation happens in the system context. But now you are telling me that something in the user context is allowed to break the installation. Nothing in the users env should change the way how the package installation process behaves. We have /etc for that - not the user specific env. What would you say when you swedish system administrator installs package xyz and suddenly all english-only speaking users of the system have to deal with a swedish-only installation of xyz - even when the swedish system admin never explicitly said that a swedish-only version should be installed? Sounds wrong, correct? It is a little bit like farting in the face of the reproducible build folks. Cool, we removed all the non-reproducible behavior in the build process - lets move all the reproducibility problems in the installation process. Maybe the package is assigned incorrectly in this ticket and dpkg/aptitude/... should sanitize the env. But the ticket should not be closed so easily. It is not like I sat down and broke the package on purpose. I just selected some good looking regional settings in KDE plasma. And suddenly my texlive installation doesn't work anymore. Not something which you would expect.
Bug#922502: plasma-desktop: regional settings allow do select system incompatible locales
See also https://bugs.debian.org/922500
Bug#922502: plasma-desktop: regional settings allow do select system incompatible locales
Package: plasma-desktop
Version: 4:5.14.5-1
Severity: critical
Justification: makes unrelated software break on the system
The "regional settings" allow to select various regions which are not
available on the system (even with locales-all). An example here is
en_DE (Germany) for "Time". This is then exported at the next login in
the env variable LC_TIME as "en_DE.UTF-8". This is not supported on
any Debian buster installation and is causing other software to break.
Here an example of me trying to install tex-common under the
environment created by the plasma desktop:
sudo aptitude reinstall tex-common
Warning: Invalid locale (please review locale settings, this might
lead to problems later):
locale::facet::_S_create_c_locale name not valid
The following packages will be REINSTALLED:
tex-common
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and
33 not upgraded.
Need to get 53.0 kB of archives. After unpacking 0 B will be used.
Get: 1 http://ftp.de.debian.org/debian buster/main amd64 tex-common
all 6.10 [53.0 kB]
Fetched 53.0 kB in 1s (105 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 21 files and directories currently installed.)
Preparing to unpack .../tex-common_6.10_all.deb ...
Unpacking tex-common (6.10) over (6.10) ...
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.kwturaob
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess
returned error exit status 1
Processing triggers for man-db (2.8.5-1) ...
Errors were encountered while processing:
tex-common
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.oXxMEBqv
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
tex-common
sudo cat /tmp/fmtutil.oXxMEBqv
fmtutil: fmtutil is using the
Bug#922500: tex-common: Fails to install with LC_TIME=en_DE.UTF-8
Package: tex-common
Version: 6.10
Severity: serious
Justification: Fails to install on a normal KDE installation with
"Germany" setting as Time localization
The installation works fine with LC_TIME=C but not with the setting
generated by KDE LC_TIME=en_DE.UTF-8. The aptitude output follows and
at the end the log file content mentioned in the aptitude output
sudo LC_TIME=en_DE.UTF-8 aptitude reinstall tex-common
Warning: Invalid locale (please review locale settings, this might
lead to problems later):
locale::facet::_S_create_c_locale name not valid
The following packages will be REINSTALLED:
tex-common
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and
33 not upgraded.
Need to get 53.0 kB of archives. After unpacking 0 B will be used.
Get: 1 http://ftp.de.debian.org/debian buster/main amd64 tex-common
all 6.10 [53.0 kB]
Fetched 53.0 kB in 1s (105 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 21 files and directories currently installed.)
Preparing to unpack .../tex-common_6.10_all.deb ...
Unpacking tex-common (6.10) over (6.10) ...
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.kwturaob
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess
returned error exit status 1
Processing triggers for man-db (2.8.5-1) ...
Errors were encountered while processing:
tex-common
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.oXxMEBqv
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
tex-common
sudo cat /tmp/fmtutil.oXxMEBqv
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil: /usr/share/texmf/web2c/fmtutil.cnf
fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the
Bug#922213: locales-all: Doesn't provide en_DE.UTF-8
Package: locales-all
Version: 2.28-6
Severity: normal
X-Debbugs-CC: debian-qt-...@lists.debian.org, debian-tex-ma...@lists.debian.org
It is possible under KDE to change the locale to en_DE.UTF-8/German
for some specific parts (e.g. time) but it seems to be missing on the
system even when locales-all is installed.
This breaks various things - here for example when I install
tex-common (via texlive package) and have LC_TIME set to en_DE.UTF-8:
LANG=C sudo aptitude
Warning: Invalid locale (please review locale settings, this might
lead to problems later):
locale::facet::_S_create_c_locale name not valid
Performing actions...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.JfWPLgok
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
tex-common
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up tex-common (6.10) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.uxDJVCLH
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
tex-common
Press Return to continue, 'q' followed by Return to quit.
q
LC_TIME=C LANG=C sudo aptitude
Performing actions...
Setting up tex-common (6.10) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... done.
Press Return to continue, 'q' followed by Return to quit.
sudo tail -n 50 /tmp/fmtutil.uxDJVCLH
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/ibyhyph.tex
Greek hyphenation patterns for Ibycus encoding, v3.0))
) )
Beginning to dump on file mllatex.fmt
(preloaded format=mllatex 2019.2.13)
5212 strings of total length 71738
47758 memory locations dumped; current usage is 144&46999
3492 multiletter control sequences
\font\nullfont=nullfont
Bug#921381: [firefox-esr] Fails to use the correct esr update channel + gmp-components
> The attached patch can be used to switch firefox-esr to the correct > MOZ_UPDATE_CHANNEL "esr" instead of "default" (which provided the > incompatible Gecko Media Plugins widevine and openh264) The same problem was observed on Gentoo. The gentoo reporter basically ported the bugfix from this ticket to fix their ebuild: https://bugs.gentoo.org/677722
Bug#921832: [firefox-esr] FTBFS of security/certverifier/Buffer.cpp
Source: firefox-esr Version: 60.5.0esr-1 Severity: grave Tags: patch Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1526648 Noticed while trying to prepare the mini fix for https://bugs.debian.org/921381 /usr/bin/g++ -o Unified_cpp_certverifier0.o -c -Ibuster/stl_wrappers -Ibuster/system_wrappers -include /build/firefox-esr-60.5.0esr/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 '-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/build/firefox-esr-60.5.0esr/security/certverifier -I/build/firefox-esr-60.5.0esr/build-browser/security/certverifier -I/build/firefox-esr-60.5.0esr/security/manager/ssl -I/build/firefox-esr-60.5.0esr/security/pkix/include -I/build/firefox-esr-60.5.0esr/security/pkix/lib -I/build/firefox-esr-60.5.0esr/build-browser/dist/include -I/usr/include/nspr -I/usr/include/nss -fPIC -DMOZILLA_CLIENT -include /build/firefox-esr-60.5.0esr/build-browser/mozilla-config.h -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -fno-sized-deallocation -fstack-protector-strong -Wformat -Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse -fno-delete-null-pointer-checks -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O2 -fomit-frame-pointer -Wall -Wextra -Wunreachable-code -Wno-unused-parameter -MD -MP -MF .deps/Unified_cpp_certverifier0.o.pp /build/firefox-esr-60.5.0esr/build-browser/security/certverifier/Unified_cpp_certverifier0.cpp In file included from /build/firefox-esr-60.5.0esr/build-browser/security/certverifier/Unified_cpp_certverifier0.cpp:20: /build/firefox-esr-60.5.0esr/security/certverifier/Buffer.cpp: In function 'bool mozilla::operator==(const Buffer&, const Buffer&)': /build/firefox-esr-60.5.0esr/security/certverifier/Buffer.cpp:14:11: error: 'memcmp' was not declared in this scope memcmp(a.begin(), b.begin(), a.length()) == 0); ^~ /build/firefox-esr-60.5.0esr/security/certverifier/Buffer.cpp:14:11: note: 'memcmp' is defined in header ''; did you forget to '#include '? /build/firefox-esr-60.5.0esr/security/certverifier/Buffer.cpp:1:1: +#include /* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /build/firefox-esr-60.5.0esr/security/certverifier/Buffer.cpp:14:11: memcmp(a.begin(), b.begin(), a.length()) == 0); ^~ make[6]: *** [/build/firefox-esr-60.5.0esr/config/rules.mk:1056: Unified_cpp_certverifier0.o] Error 1 make[6]: Leaving directory '/build/firefox-esr-60.5.0esr/build-browser/security/certverifier' make[5]: *** [/build/firefox-esr-60.5.0esr/config/recurse.mk:73: security/certverifier/target] Error 2 make[5]: Leaving directory '/build/firefox-esr-60.5.0esr/build-browser' make[4]: *** [/build/firefox-esr-60.5.0esr/config/recurse.mk:33: compile] Error 2 make[4]: Leaving directory '/build/firefox-esr-60.5.0esr/build-browser' make[3]: *** [/build/firefox-esr-60.5.0esr/config/rules.mk:442: default] Error 2 make[3]: Leaving directory '/build/firefox-esr-60.5.0esr/build-browser' dh_auto_build: cd build-browser && make -j1 LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code 2 make[2]: *** [debian/rules:227: stamps/build-browser] Error 2 make[2]: Leaving directory '/build/firefox-esr-60.5.0esr' make[1]: *** [debian/rules:336: build-arch] Error 2 make[1]: Leaving directory '/build/firefox-esr-60.5.0esr' make: *** [debian/rules:336: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 From: Charlemange Lasse Date: Sat, 9 Feb 2019 10:08:10 +0100 Subject: [PATCH] Fix FTBFS of security/certverifier/Buffer.cpp --- debian/changelog | 1 + .../Bug-1526648-Include-cstring-for-memcmp.patch | 12 debian/patches/series| 1 + 3 files changed, 14 insertions(+) create mode 100644 debian/patches/fixes/Bug-1526648-Include-cstring-for-memcmp.patch --- a/debian/changelog +++ b/debian/changelog @@ -4,6 +4,7 @@ firefox-esr (60.5.0esr-2) UNRELEASED; urgency=medium * Fix download of esr compatible Gecko Media Plugins (widevine, openh264) by switching to "esr" update channel (Closes: #921381, #921121, #921654) + * Fix FTBFS of security/certverifier/Buffer.cpp (Closes: #-TODO) -- Charlemange Lasse Sat, 09 Feb 2019 08:47:47 +0100 --- /dev/null +++ b/debian/patches/fixes/Bug-1526648-Include-cstring-for-memcmp.patch @@ -0,0 +1,12 @@ +diff --git
Bug#921381: [firefox-esr] Fails to use the correct esr update channel + gmp-components
forcemerge 921381 921654 921121 tags 921381 + patch sid buster stretch found 921381 60.5.0esr-1 thanks The attached patch can be used to switch firefox-esr to the correct MOZ_UPDATE_CHANNEL "esr" instead of "default" (which provided the incompatible Gecko Media Plugins widevine and openh264) From: Charlemange Lasse Date: Sat, 9 Feb 2019 08:53:20 +0100 Subject: [PATCH] Switch to ESR update channel for GMP downloads It was noticed that the Debian stretch version (and most likely also the Debian buster) of firefox-esr uses the wrong channel to search for components. As result, the downloaded components don't work with the esr browser and break major parts of the multimedia features of the browser. This was also confirmed by a Mozilla developer https://bugzilla.mozilla.org/show_bug.cgi?id=1524830#c4 The fix is to use MOZ_UPDATE_CHANNEL "esr" and not "default". --- debian/browser.mozconfig.in | 1 + debian/changelog| 9 + 2 files changed, 10 insertions(+) --- a/debian/browser.mozconfig.in +++ b/debian/browser.mozconfig.in @@ -43,3 +43,4 @@ ac_add_options --disable-updater ac_add_options --enable-pie ac_add_options --with-unsigned-addon-scopes=app,system ac_add_options --enable-alsa +ac_add_options --enable-update-channel=esr --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +firefox-esr (60.5.0esr-2) UNRELEASED; urgency=medium + + [ Charlemagne Lasse ] + + * Fix download of esr compatible Gecko Media Plugins (widevine, openh264) by +switching to "esr" update channel (Closes: #921381, #921121, #921654) + + -- Charlemange Lasse Sat, 09 Feb 2019 08:47:47 +0100 + firefox-esr (60.5.0esr-1) unstable; urgency=medium * New upstream release.
Bug#921823: chromium: FTBFS of vaapi_wrapper.cc in i386/armhf (pointer casting)
Source: chromium
Version: 72.0.3626.81-1
Severity: grave
X-Debbugs-CC: 856...@bugs.debian.org
FAILED: obj/media/gpu/vaapi/vaapi/vaapi_wrapper.o
g++ -MMD -MF obj/media/gpu/vaapi/vaapi/vaapi_wrapper.o.d
-DMEDIA_GPU_IMPLEMENTATION -DV8_DEPRECATION_WARNINGS -DUSE_UDEV
-DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC
-DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL
-DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DVK_NO_PROTOTYPES
-DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DSK_HAS_PNG_LIBRARY
-DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY
-DSK_VULKAN_HEADER=\"../../skia/config/SkVulkanConfig.h\"
-DSK_VULKAN=1 -DSK_SUPPORT_GPU=1
-DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\"
-DVK_NO_PROTOTYPES -DUSING_SYSTEM_ICU=1
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=uint16_t
-DU_IMPORT=U_EXPORT -DGOOGLE_PROTOBUF_NO_RTTI
-DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD
-DLEVELDB_PLATFORM_CHROMIUM=1 -DLEVELDB_PLATFORM_CHROMIUM=1 -I../..
-Igen -I../../third_party/libyuv/include
-Igen/shim_headers/libevent_shim -Igen/shim_headers/libpng_shim
-Igen/shim_headers/libwebp_shim -Igen/shim_headers/icuuc_shim
-Igen/shim_headers/zlib_shim -I../../third_party/khronos -I../../gpu
-Igen/shim_headers/libdrm_shim -I../../third_party/vulkan/include
-Igen/shim_headers/icui18n_shim -Igen/shim_headers/re2_shim
-Igen/shim_headers/ffmpeg_shim -Igen/shim_headers/libvpx_shim
-Igen/shim_headers/snappy_shim -Igen/shim_headers/opus_shim
-I../../skia/config -I../../skia/ext
-I../../third_party/skia/include/c
-I../../third_party/skia/include/config
-I../../third_party/skia/include/core
-I../../third_party/skia/include/docs
-I../../third_party/skia/include/effects
-I../../third_party/skia/include/encode
-I../../third_party/skia/include/gpu
-I../../third_party/skia/include/pathops
-I../../third_party/skia/include/ports
-I../../third_party/skia/include/utils
-I../../third_party/vulkan/include
-I../../third_party/skia/third_party/vulkanmemoryallocator
-I../../third_party/skia/include/codec
-I../../third_party/skia/src/gpu -I../../third_party/skia/src/sksl
-I../../third_party/skia/modules/skottie/include
-I../../third_party/vulkan/include -I../../third_party/ced/src
-I../../third_party/protobuf/src -I../../third_party/mesa_headers
-I../../third_party/libwebm/source -I../../third_party/protobuf/src
-Igen/protoc_out -I../../third_party/leveldatabase
-I../../third_party/leveldatabase/src
-I../../third_party/leveldatabase/src/include -fno-strict-aliasing
--param=ssp-buffer-size=4 -fstack-protector
-Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__=
-funwind-tables -fPIC -pipe -pthread -march=armv7-a -mfloat-abi=hard
-mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb -Wall -Wno-psabi
-Wno-unused-local-typedefs -Wno-maybe-uninitialized
-Wno-deprecated-declarations -Wno-comments
-Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident
-fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0
-fvisibility=hidden -I/usr/include/glib-2.0
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -std=gnu++14
-Wno-narrowing -fno-exceptions -fno-rtti -fvisibility-inlines-hidden
-Wdate-time -D_FORTIFY_SOURCE=2 -Wno-pedantic -Wno-unused-function
-Wno-unused-variable -Wno-unused-but-set-variable
-Wno-deprecated-declarations -Wno-return-type
-Wno-misleading-indentation -Wno-attributes -Wno-subobject-linkage
-Wno-ignored-attributes -Wno-address -Wno-dangling-else
-Wno-class-memaccess -Wno-invalid-offsetof -Wno-packed-not-aligned
-Wno-pedantic -Wno-unused-function -Wno-unused-variable
-Wno-unused-but-set-variable -Wno-deprecated-declarations
-Wno-return-type -Wno-misleading-indentation -Wno-attributes
-Wno-subobject-linkage -Wno-ignored-attributes -Wno-address
-Wno-dangling-else -Wno-class-memaccess -Wno-invalid-offsetof
-Wno-packed-not-aligned -c ../../media/gpu/vaapi/vaapi_wrapper.cc -o
obj/media/gpu/vaapi/vaapi/vaapi_wrapper.o
../../media/gpu/vaapi/vaapi_wrapper.cc: In member function
'scoped_refptr
media::VaapiWrapper::CreateVASurfaceForPixmap(const
scoped_refptr&)':
../../media/gpu/vaapi/vaapi_wrapper.cc:1012:38: error: invalid
conversion from 'long unsigned int*' to 'uintptr_t*' {aka 'unsigned
int*'} [-fpermissive]
va_attrib_extbuf.buffers = fds.data();
^~
https://buildd.debian.org/status/fetch.php?pkg=chromium=armhf=72.0.3626.81-1=1549182249=0
https://buildd.debian.org/status/fetch.php?pkg=chromium=i386=72.0.3626.81-1=1549136121=0
Bug#921738: chromium-widevine: Widevine does not work with Netflix
tags 921738 + wontfix
bye
This package is *not* widevine. It is the *support* for the legacy
widevine cdm. You still have to download the widevine cdm from
widevine.com/google. Google prohibits its distribution without a
license:
> "Google Inc. and its affiliates ("Google") own all legal right, title and
> interest in and to the content decryption module software ("Software") and
> related documentation, including any intellectual property rights in the
> Software. You may not use, modify, sell, or otherwise distribute the Software
> without a separate license agreement with Google. The Software is not open
> source software.
>
> If you are interested in licensing the Software, please contact
> widev...@google.com.
This package was removed from newer releases of the chromium package.
The new widevine cdm module (4.10.1196.0) will be loaded directly by
the browser from /usr/lib/chromium/libwidevinecdm.so when you have a
version installed which isn't affected by
https://bugs.debian.org/916058 - you still have to get
libwidevinecdm.so
If you are interested in automatically installing this plugin then
please use the approach by
https://tracker.debian.org/pkg/pepperflashplugin-nonfree and upload
the download helper to contrib/web.
As far as I know, Mozilla has a license to use widevine but not a
license to distribute it. Steam/Valve maybe has a license to
redistribute it (I could be wrong but I thought that it was in their
steam runtime) and the chrome team definitely has a license to
distribute it.
You have to contact netflix directly about their wrong help message
Bug#921646: kdepim-runtime: akonadi_imap_resource fails to download gmail content
Package: kdepim-runtime Version: 4:18.08.3-1 Severity: important I've spend now a week trying to get may my gmail imap downloaded. I am using the standard settings from imap with imap server set to imap.gmail.com. It downloads the mails of a single year (2015) and then shows it stops suddenly After a couple of minutes it then starts the download again (starting a 0%) but cancels itself again after a couple of seconds (when it reaches 4%). AgentBase(akonadi_imap_resource_14): killed AgentBase(akonadi_imap_resource_14): Unable to connect to the IMAP server. and sometimes it also only shows: AgentBase(akonadi_imap_resource_14): Connection lost I've tried to restart akonoadi, reboot the pc, remove and readd the imap account and to completely remove the akonadi files and restart the PC. Nothing worked and it is always it this state. It is basically impossible to use kmail at the moment for me with gmail. It was working fine with Debian stretch. I am only minutes away from throwing my PC against a wall.
Bug#921521: chromium-browser: CVE/Security fixes missing in stable-sec
Package: chromium Version: 71.0.3578.80-1~deb9u1 Severity: serious The stable-sec package is stuck with version 71.0.3578.80 and is missing security updates for several CVEs. Take for example the list from 72.0.3626.81 - Stack buffer overflow in Skia. Reported by Ivan Fratric - Use after free in Mojo, FileAPI, and Payments. Reported by Mark Brand - CVE-2018-17481: Use after free in PDFium. Reported by Anonymous - CVE-2019-5754: Inappropriate implementation in QUIC Networking. Reported by Klzgrad - CVE-2019-5755: Inappropriate implementation in V8. Reported by Jay Bosamiya - CVE-2019-5756: Use after free in PDFium. Reported by Anonymous - CVE-2019-5757: Type Confusion in SVG. Reported by Alexandru Pitis - CVE-2019-5758: Use after free in Blink. Reported by Zhe Jin - CVE-2019-5759: Use after free in HTML select elements. Reported by Almog Benin - CVE-2019-5760: Use after free in WebRTC. Reported by Zhe Jin - CVE-2019-5762: Use after free in PDFium. Reported by Anonymous - CVE-2019-5763: Insufficient validation of untrusted input in V8. Reported by Guang Gong - CVE-2019-5764: Use after free in WebRTC. Reported by Eyal Itkin - CVE-2019-5765: Insufficient policy enforcement in the browser. Reported by Sergey Toshin - CVE-2019-5766: Insufficient policy enforcement in Canvas. Reported by David Erceg - CVE-2019-5767: Incorrect security UI in WebAPKs. Reported by Haoran Lu, Yifan Zhang, Luyi Xing, and Xiaojing Liao - CVE-2019-5768: Insufficient policy enforcement in DevTools. Reported by Rob Wu - CVE-2019-5769: Insufficient validation of untrusted input in Blink. Reported by Guy Eshel - CVE-2019-5770: Heap buffer overflow in WebGL. Reported by hemidallt - CVE-2019-5772: Use after free in PDFium. Reported by Zhen Zhou - CVE-2019-5773: Insufficient data validation in IndexedDB. Reported by Yongke Wang - CVE-2019-5774: Insufficient validation of untrusted input in SafeBrowsing. Reported by Junghwan Kang and Juno Im - CVE-2019-5775: Insufficient policy enforcement in Omnibox. Reported by evi1m0 - CVE-2019-5776: Insufficient policy enforcement in Omnibox. Reported by Lnyas Zhang - CVE-2019-5777: Insufficient policy enforcement in Omnibox. Reported by Khalil Zhani - CVE-2019-5778: Insufficient policy enforcement in Extensions. Reported by David Erceg - CVE-2019-5779: Insufficient policy enforcement in ServiceWorker. Reported by David Erceg - CVE-2019-5780: Insufficient policy enforcement. Reported by Andreas Hegenberg - CVE-2019-5781: Insufficient policy enforcement in Omnibox. Reported by evi1m0 - CVE-2019-5782: Inappropriate implementation in V8 reported by Qixun Zhao - CVE-2019-5783: Insufficient validation of untrusted input in DevTools. Reported by Shintaro Kobori
Bug#921381: [firefox-esr] Fails to use the correct esr update channel + gmp-components
Package: firefox-esr
Version: 60.5.0esr-1~deb9u1
Severity: important
X-Debbugs-CC: bvan...@mozilla.com
It was noticed that the Debian stretch version (and most likely also the
Debian buster) of firefox-esr uses the wrong channel to search for
components. As result, the downloaded components don't work with the esr
browser and break major parts of the multimedia features of the browser.
This was also confirmed by a Mozilla developer
https://bugzilla.mozilla.org/show_bug.cgi?id=1524830#c4
The fix is to use MOZ_UPDATE_CHANNEL "esr" and not "default". One place
which is affected by it is
$ grep app.update.channel /usr/lib/firefox-esr/defaults/pref/channel-prefs.js
pref("app.update.channel", "default");
This should be "esr" and not "default".
Bug#911433: [nvidia-driver] Update to 410.66
Source: nvidia-driver Severity: wishlist The new driver version is required to support the current generation of nvidia GPUs: Added support for the following GPUs: GeForce RTX 2070 GeForce RTX 2080 Ti GeForce RTX 2080 Quadro P5200 with Max-Q Design Quadro P4200 with Max-Q Design Quadro P2000 with Max-Q Design https://www.nvidia.com/Download/driverResults.aspx/138959/en-us I am currently unable to work under Debian because of the missing driver package --- System information. --- Architecture: Kernel: Linux 4.18.0-2-amd64 Debian Release: buster/sid 500 testing-debug debug.mirrors.debian.org 500 testing deb.debian.org 1 testing www.deb-multimedia.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible
found 904652 11.1-5 thanks > i didn't do anything. > Upgrading the system like always. > Suddenly there was no sound available. Change /etc/pulse/default.pa to automatically load module-alsa-sink on boot (module-udev-detect is broken and will not load the alsa-sink anymore) This is also a problem in buster (which is still using 11.1-5)
Bug#898643: [python-keyring] update to keyring 12.x
Source: python-keyring Version: 10.1-1 Severity: normal The gajim developers asked me to test 12.x of python keyring. These seems to fix a problem with their login system. See https://dev.gajim.org/gajim/gajim/issues/9126#note_186025
Bug#888605: [gajim] Regression: kwallet integration missing
Source: gajim Source-Version: 1.0.0~beta1-1 Seems to work here. Thanks
Bug#889809: [linux] Fails to compile external modules
Source: linux Version: 4.14.13-1~bpo9+1 Severity: normal X-Debbugs-CC: backpo...@vger.kernel.org It seems like the current kernel in stretch backporst and in buster has problems when compiling external modules against it. This worked fine in the past. Also works fine when compiling against a manually compiled 4.14 Linux kernel. So it seems to be a Debian specific regression. Here are some examples $ curl https://mirror2.openwrt.org/sources/backports-2017-11-01.tar.xz|tar xvJ $ make -C backports-2017-11-01 defconfig-ath9k $ make -C backports-2017-11-01 make: Entering directory '/usr/src/backports-2017-11-01' make[5]: 'conf' is up to date. # # configuration written to .config # Building backport-include/backport/autoconf.h ... done. In file included from :0:0: /usr/src/backports-2017-11-01/backport-include/backport/backport.h:3:32: fatal error: generated/autoconf.h: No such file or directory #include ^ compilation terminated. In file included from :0:0: /usr/src/backports-2017-11-01/backport-include/backport/backport.h:3:32: fatal error: generated/autoconf.h: No such file or directory #include $ curl https://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-2017.4.tar.gz|tar xvz $ make -C batman-adv-2017.4 make: Entering directory '/usr/src/batman-adv-2017.4' /usr/src/batman-adv-2017.4/gen-compat-autoconf.sh /usr/src/batman-adv-2017.4/compat-autoconf.h mkdir -p /usr/src/batman-adv-2017.4/build/net/batman-adv/ compat-patches/replacements.sh touch /usr/src/batman-adv-2017.4/build/net/batman-adv/.compat-prepared make -C /lib/modules/4.14.0-0.bpo.3-amd64/build M=/usr/src/batman-adv-2017.4/build PWD=/usr/src/batman-adv-2017.4/build REVISION= CONFIG_BATMAN_ADV=m CONFIG_BATMAN_ADV_DEBUG=n CONFIG_BATMAN_ADV_DEBUGFS=y CONFIG_BATMAN_ADV_BLA=y CONFIG_BATMAN_ADV_DAT=y CONFIG_BATMAN_ADV_NC=n CONFIG_BATMAN_ADV_MCAST=y CONFIG_BATMAN_ADV_BATMAN_V=n INSTALL_MOD_DIR=updates/ modules make[1]: Entering directory '/usr/src/linux-headers-4.14.0-0.bpo.3-amd64' In file included from :31:0: /usr/src/batman-adv-2017.4/build/../compat.h:24:52: fatal error: linux/version.h: No such file or directory #include /* LINUX_VERSION_CODE */ ^ compilation terminated. In file included from :31:0: /usr/src/batman-adv-2017.4/build/../compat.h:24:52: fatal error: linux/version.h: No such file or directory #include /* LINUX_VERSION_CODE */ ^ compilation terminated. --- System information. --- Architecture: Kernel: Linux 4.14.0-0.bpo.3-amd64 Debian Release: 9.3 500 stable security.debian.org 500 stable httpredir.debian.org 100 stretch-backports httpredir.debian.org
Bug#888605: [gajim] Regression: kwallet integration missing
forwarded 888605 https://dev.gajim.org/gajim/gajim/issues/8875 tags 888605 + patch thanks The problem is fixed in https://dev.gajim.org/gajim/gajim/merge_requests/206. The kwalletcli dependency has to be dropped in debian (it is wrong at the moment anyway) and instead it now has to depend on python3-keyring and python3-dbus
Bug#888611: [gajim] Fails to keep connection against prosody 0.9.12-2 (Debian Stretch)
Package: gajim Version: 1.0.0~alpha2-1 Severity: normal The gajim version from Debian Stretch worked fine but now with gajim 1.0.0~alpha2-1 (0.98.2 according to the about page), the connection drops all the time against a prosody 0.9.12-2 server (Debian Stretch). I see following in the XML log: This makes it impossible to use gajim for me. --- System information. --- Architecture: Kernel: Linux 4.14.0-3-amd64 Debian Release: buster/sid 500 testing-debug debug.mirrors.debian.org 500 testing httpredir.debian.org 1 testing www.deb-multimedia.org --- Package information. --- Depends (Version) | Installed ==-+-== python3-nbxmpp (>= 0.6.0) | 0.6.2-1 python3-openssl (>= 0.12) | 17.5.0-1 python3-pyasn1 | 0.4.2-3 python3:any (>= 3.3.2-2~) | gir1.2-gtk-3.0 | 3.22.26-2 python3| 3.6.4-1 python3-gi | 3.26.1-2 python3-gi-cairo | 3.26.1-2 python3-idna | 2.6-1 Recommends (Version) | Installed ==-+-=== aspell-en | 2017.08.24-0-0.1 OR aspell-dictionary | ca-certificates| 20170717 dbus | 1.12.2-1 fonts-noto-color-emoji | 0~20180102-1 gajim-omemo (>= 2.5.1) | 2.5.4-1 gajim-pgp | 1.2.1-2 gir1.2-farstream-0.2 | 0.2.8-2 gir1.2-geoclue-2.0 | 2.4.7-1 gir1.2-gspell-1| 1.6.1-1 gir1.2-gst-plugins-base-1.0| 1.12.4-1 gir1.2-gstreamer-1.0 | 1.12.4-1 gir1.2-gupnpigd-1.0| 0.2.4-2 gir1.2-networkmanager-1.0 | 1.10.2-1 gir1.2-secret-1| 0.18.5-5 gstreamer0.10-plugins-ugly | notification-daemon| 3.20.0-2 pulseaudio-utils | 11.1-4 OR alsa-utils | 1.1.3-1 OR sox| 14.4.2-3 OR oss4-base | python3-crypto | 2.6.1-8 python3-dbus (>= 0.81) | 1.2.4-1+b4 python3-gnupg (>= 0.4.1) | 0.4.1-1 python3-pil| 4.3.0-2 python3-precis-i18n| Suggests (Version) | Installed ===-+-=== avahi-daemon| 0.7-3 libxss1 | nautilus-sendto | python3-avahi | python3-gconf | python3-gnome2 | python3-kerberos (>= 1.1) | python3-pycurl |
Bug#888609: [smb4k] Retrieving the list of available domains failed
Package: smb4k Version: 2.0.2-1 Severity: normal smb4k shows me following when it gets started under Debian buster: Retrieving the list of available domains failed: Usage: [-?fMRSTrAV] [-?|--help] [--usage] [-B|--broadcast=BROADCAST-ADDRESS] [-f|--flags] [-U|--unicast=STRING] [-M|--master-browser] [-R|--recursion] [-S|--status] [-T|--translate] [-r|--root-port] [-A|--lookup-by-ip] [-d|--debuglevel=DEBUGLEVEL] [-s|--configfile=CONFIGFILE] [-l|--log-basename=LOGFILEBASE] [-V|--version] [--option=name=value] [-O|--socket-options=SOCKETOPTIONS] [-n|--netbiosname=NETBIOSNAME] [-W|--workgroup=WORKGROUP] [-i|--scope=SCOPE] ... --- System information. --- Architecture: Kernel: Linux 4.14.0-3-amd64 Debian Release: buster/sid 500 testing-debug debug.mirrors.debian.org 500 testing httpredir.debian.org 1 testing www.deb-multimedia.org --- Package information. --- Depends (Version) | Installed ==-+-== cifs-utils (>= 2:4.1) | 2:6.7-1 samba-common-bin (>= 2:3.4.7~dfsg) | 2:4.7.4+dfsg-1 smbclient(>= 2:3.4.7~dfsg) | 2:4.7.4+dfsg-1 kio| 5.37.0-2 libc6(>= 2.14) | libkf5auth5(>= 4.96.0) | libkf5completion5 (>= 4.97.0) | libkf5configcore5 (>= 4.98.0) | libkf5configgui5 (>= 4.97.0) | libkf5configwidgets5 (>= 4.96.0) | libkf5coreaddons5 (>= 5.2.0) | libkf5dbusaddons5 (>= 4.97.0) | libkf5i18n5(>= 4.97.0) | libkf5iconthemes5 (>= 5.11.0) | libkf5jobwidgets5 (>= 4.96.0) | libkf5kiocore5 (>= 4.96.0) | libkf5kiowidgets5(>= 5.5.0+git20141226.0011+15.04) | libkf5notifications5 (>= 4.96.0) | libkf5parts5 (>= 4.96.0) | libkf5solid5 (>= 4.97.0) | libkf5wallet-bin | libkf5wallet5 (>= 4.96.0) | libkf5widgetsaddons5 (>= 4.96.0) | libkf5windowsystem5(>= 4.96.0) | libkf5xmlgui5 (>= 4.98.0) | libqt5core5a (>= 5.9.0~beta) | libqt5gui5 (>= 5.7.0) | libqt5network5 (>= 5.0.2) | libqt5printsupport5 (>= 5.0.2) | libqt5test5 (>= 5.0.2) | libqt5widgets5 (>= 5.7.0) | libstdc++6 (>= 4.1.1) | Recommends (Version) | Installed =-+-=== sudo | 1.8.21p2-3 Suggests(Version) | Installed =-+-=== kwalletmanager| 4:17.08.3-1
Bug#888605: [gajim] Regression: kwallet integration missing
Package: gajim
Version: 1.0.0~alpha2-1
Severity: important
The kwallet integration was done in the gajim stretch version using
kwalletcli. But upstream removed it in 13a61d76187c ("Remove support for GNOME
Keyring and KWalletCLI, instead always use libsecret.") without a replacement
for KDE. The kwallet can currently no longer be used with this gajim version.
This is a regression compared to the older version.
Either kwalletcli is added again to gajim or org.freedesktop.secrets dbus
support must be added to kwalletd5
--- System information. ---
Architecture:
Kernel: Linux 4.14.0-3-amd64
Debian Release: buster/sid
500 testing-debug debug.mirrors.debian.org
500 testing httpredir.debian.org
1 testing www.deb-multimedia.org
--- Package information. ---
Depends (Version) | Installed
==-+-==
python3-nbxmpp (>= 0.6.0) | 0.6.2-1
python3-openssl (>= 0.12) | 17.5.0-1
python3-pyasn1 | 0.4.2-3
python3:any (>= 3.3.2-2~) |
gir1.2-gtk-3.0 | 3.22.26-2
python3| 3.6.4-1
python3-gi | 3.26.1-2
python3-gi-cairo | 3.26.1-2
python3-idna | 2.6-1
Recommends (Version) | Installed
==-+-===
aspell-en | 2017.08.24-0-0.1
OR aspell-dictionary |
ca-certificates| 20170717
dbus | 1.12.2-1
fonts-noto-color-emoji | 0~20180102-1
gajim-omemo (>= 2.5.1) | 2.5.4-1
gajim-pgp | 1.2.1-2
gir1.2-farstream-0.2 | 0.2.8-2
gir1.2-geoclue-2.0 | 2.4.7-1
gir1.2-gspell-1| 1.6.1-1
gir1.2-gst-plugins-base-1.0| 1.12.4-1
gir1.2-gstreamer-1.0 | 1.12.4-1
gir1.2-gupnpigd-1.0| 0.2.4-2
gir1.2-networkmanager-1.0 | 1.10.2-1
gir1.2-secret-1| 0.18.5-5
gstreamer0.10-plugins-ugly |
notification-daemon| 3.20.0-2
pulseaudio-utils | 11.1-4
OR alsa-utils | 1.1.3-1
OR sox| 14.4.2-3
OR oss4-base |
python3-crypto | 2.6.1-8
python3-dbus (>= 0.81) | 1.2.4-1+b4
python3-gnupg (>= 0.4.1) | 0.4.1-1
python3-pil| 4.3.0-2
python3-precis-i18n|
Suggests (Version) | Installed
===-+-===
avahi-daemon| 0.7-3
libxss1 |
nautilus-sendto |
python3-avahi |
python3-gconf |
python3-gnome2 |
python3-kerberos (>= 1.1) |
python3-pycurl |
Bug#888442: [nftables] Crash when list(ing) ip6tables-compat CT rules
Package: nftables
Version: 0.7-1
Severity: important
The nft list crashes when an ip6tables-compat CT rule is found also in
iptables-compat. This is either an assert with 0.7-1 or a segfault
with 0.8-2~bpo9+1.
# nft flush ruleset
# nft list ruleset
# iptables-compat -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
ct state related,established counter packets 0 bytes 0 accept
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
}
}
# ip6tables-compat -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# nft list ruleset
BUG: XT match conntrack not found
nft: xt.c:208: netlink_parse_match: Assertion `0' failed.
Aborted
--- System information. ---
Architecture:
Kernel: Linux 4.9.65-3+deb9u2
Debian Release: 9.3
500 stable security.debian.org
500 stable httpredir.debian.org
100 stretch-backports httpredir.debian.org
1 stable www.deb-multimedia.org
--- Package information. ---
Depends (Version) | Installed
===-+-
init-system-helpers (>= 1.18~) | 1.48
libc6 (>= 2.15) |
libgmp10|
libmnl0 (>= 1.0.3-4~) |
libnftnl4 (>= 1.0.5+snapshot20160416) |
libreadline7 (>= 6.0) |
libxtables12|
Package's Recommends field is empty.
Package's Suggests field is empty.
Bug#863475: [prosody] Fails to initiate s2s when lua-event 0.4.3 is installed
Package: prosody Version: 0.9.12-1 Severity: serious Tags: patch stretch Prosody fails to intiate S2S connections when lua-event 0.4.3 is installed. This bug was already fixed in the 0.10 branch of prosody but is still present on Debian stretch (which is shipped with lua-event 0.4.3) The fix can be found at https://prosody.im/issues/issue/555 Errors in the log are: May 27 13:47:24 adnswarnDNS socket for 8.8.8.8 disconnected: connection timeout May 27 13:47:39 adnswarnDNS socket for 8.8.4.4 disconnected: connection timeout May 27 13:47:59 adnswarnDNS socket for 8.8.8.8 disconnected: connection timeout May 27 13:47:59 adnserror Exhausted all 2 configured DNS servers, next lookup will try 8.8.4.4 again May 27 13:48:04 s2sout55ea3204b2d0 infoOut of connection options, can't connect to jabber.linux.it May 27 13:48:04 s2sout55ea3204b2d0 infoSending error replies for 2 queued stanzas because of failed outgoing connection to jabber.linux.it The problem can either be resolved by backporting the fix or marking lua-event 0.4.3 as conflict (and remove it from the Recommended field). Marking this as serious bug because federation is an extreme important part of XMPP/Jabber --- System information. --- Architecture: Kernel: Linux 4.9.0-3-amd64 Debian Release: 9.0 500 testing-debug debug.mirrors.debian.org 500 testing httpredir.debian.org
Bug#842710: [gcc-6] Fails to compile OpenWrt/LEDE prereq-build
Package: gcc-6
Version: 6.2.0-10
Severity: serious
X-Debbugs-CC: lede-...@lists.infradead.org
There is a regression after gcc-6 6.2.0-6. I get following output when
trying to compile LEDE/OpenWrt "Please install a static zlib"
This is wrong
$ ls -ltr /usr/lib/x86_64-linux-gnu/libz.a
-rw-r--r-- 1 root root 149834 Nov 27 2014 /usr/lib/x86_64-linux-gnu/libz.a
Following can be found in their include/prereq-build.mk
ifeq ($(HOST_OS),Linux)
zlib_link_flags := -Wl,-Bstatic -lz -Wl,-Bdynamic
else
zlib_link_flags := -lz
endif
$(eval $(call TestHostCommand,zlib, \
Please install a static zlib. (Missing libz.a or zlib.h), \
echo 'int main(int argc, char **argv) { gzdopen(0, "rb"); return 0; }' | \
gcc -include zlib.h -x c -o $(TMP_DIR)/a.out - $(zlib_link_flags)))
Testing it with gcc-6 6.2.0-6 works:
$ echo 'int main(int argc, char **argv) { gzdopen(0, "rb"); return 0;
}' | gcc -include zlib.h -x c -o a.out - -Wl,-Bstatic -lz
-Wl,-Bdynamic
$ echo $?
0
with gcc-6 6.2.0-10 fails:
$ echo 'int main(int argc, char **argv) { gzdopen(0, "rb"); return 0;
}' | gcc -include zlib.h -x c -o a.out - -Wl,-Bstatic -lz
-Wl,-Bdynamic
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libz.a(gzlib.o):
relocation R_X86_64_32S against `.rodata' can not be used when making
a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
$ echo $?
1
Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*
severity 831525 serious bye Then please integrate your changes in upstream mupen64plus. Many "forks" are now removed from debian (I think mutt-patched is one of the recent ones) and now you start to introduce new ones - against the Debian policy
Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*
Source: libretro-mupen64plus Version: 2.0+git20160207+dfsg2-1 Severity: serious Marked as serious because it is a violation of paragraph 4.13 from the Debian Policy. Debian should not ship the same things twice. So the Debian Games Team should decide whether it wants to ship mupen64plus-* or libretro-mupen64plus Maybe it is also possible not to use the included copies and instead load the plugins from mupen64plus-*
