Bug#926692: ITP: fluentd -- Fluentd event collector
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: fluentd Version : 1.4.2 Upstream Author : Sadayuki Furuhashi * URL : https://www.fluentd.org/ * License : Apache-2.0 Programming Lang: Ruby Description : Fluentd event collector Fluentd is an open source data collector designed to scale and simplify log management. It can collect, process and ship many kinds of data in near real-time.
Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused
> You're welcome :-) Does clearing the SSL_MODE_AUTO_RETRY context flag > (i.e., reverting the default from OpenSSL <1.1.1) solves this for you > too? If so, what do you think about my proposed paths forwards from Simply clearing SSL_MODE_AUTO_RETRY will cause problems with blocking connections in TLS 1.3. I've tried to work around the behavior change by clearing SSL_MODE_AUTO_RETRY for non-blocking and setting it again when doing blocking connections. Please check if https://github.com/noxxi/p5-io-socket-ssl/commit/09bc6a3203bc7bc89078317da42a3e96cdbf94fc fixes the problems you see. Regards, Steffen Ullrich, Maintainer IO::Socket::SSL.
Bug#926691: python-rsa: Missing manpages for binaries
Source: python-rsa Version: 4.0-2 Severity: minor Tags: patch Hi, attached manpages for the binaries in this package. (python2 versions are just generated from the corresponding python3 versions) python-rsa-manpages.tar.gz Description: application/tgz
Bug#915333: git-annex: Illegal Instruction on armel (Fujitsu Q700 like QNAP TS-21x/TS-22x)
On Sun, Apr 07, 2019 at 02:01:33PM +0200, Darshaka Pathirana wrote: > Hey, > > On Mon, 11 Mar 2019 12:05:55 +0200 Adrian Bunk wrote: > > On Thu, Jan 31, 2019 at 08:12:17PM +0100, Bernhard Übelacker wrote: > > > Hello Everyone, > > > I own a qnap ts-119pII with a similar cpu. > > > > > > See attached file with several debugging attempts. > > I took some time and wanted to reproduce and test this issue. >... What are you planning to do after reproducing it? Bernhard did debug it back in January, and I described what line the problem is. > Regards from the Debian BSP201904, Salzburg, > - Darsha cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#926602: CVE-2019-10906 - jinja sandbox escape poc
Hi Hugo, On Mon, Apr 08, 2019 at 10:20:29PM +0200, Hugo Lefeuvre wrote: > Hi Salvatore, > > > CVE-2016-10745 was assigned for this issue. > > Thanks for the information. > > I just noticed you added CVE-2016-10745 to the tracker. I am fairly > confused, do you know why this CVE was not referenced in the tracker? > Or did you just request it? It was not referenced, because there was not CVE yet. I was irritated that for the later issue apparently a CVE Was assigned, but not for the original first issue, so I requested a CVE for it. It would have showed up on next CVE list update, bug given I got the confirmation from MITRE on the assignment I then already added it to the tracker. So in short, yes I did rquest the CVE and was assigned yesterday. Regards, Salvatore
Bug#926690: unblock: pillow/5.4.1-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pillow
Matthias fixed the important bug #926552 (fails loading some PNG files)
in pillow/5.4.1-2. While the bug is not release critical, it breaks
operation of dedup.debian.net. The bug is well understood upstream and
Matthias essentially cherry-picked the relevant upstream patch. Would
you consider including this change in buster?
unblock pillow/5.4.1-2
Thank you for considering
Helmut
diff --minimal -Nru pillow-5.4.1/debian/changelog pillow-5.4.1/debian/changelog
--- pillow-5.4.1/debian/changelog 2019-01-18 11:05:56.0 +0100
+++ pillow-5.4.1/debian/changelog 2019-04-07 02:53:28.0 +0200
@@ -1,3 +1,9 @@
+pillow (5.4.1-2) unstable; urgency=medium
+
+ * Allow for unknown PNG chunks after image data. Closes: #926552.
+
+ -- Matthias Klose Sun, 07 Apr 2019 02:53:28 +0200
+
pillow (5.4.1-1) unstable; urgency=medium
* New upstream version.
diff --minimal -Nru
pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
--- pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
1970-01-01 01:00:00.0 +0100
+++ pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
2019-04-07 02:53:18.0 +0200
@@ -0,0 +1,43 @@
+Allow for unknown PNG chunks after image data
+
+diff --git a/Tests/test_file_png.py b/Tests/test_file_png.py
+index c94f8eaad..84017 100644
+--- a/Tests/test_file_png.py
b/Tests/test_file_png.py
+@@ -596,6 +596,7 @@ def test_apng(self):
+ im = Image.open("Tests/images/iss634.apng")
+ self.assertEqual(im.get_format_mimetype(), 'image/apng')
+
++# This also tests reading unknown PNG chunks (fcTL and fdAT) in
load_end
+ expected = Image.open("Tests/images/iss634.webp")
+ self.assert_image_similar(im, expected, 0.23)
+
+diff --git a/src/PIL/PngImagePlugin.py b/src/PIL/PngImagePlugin.py
+index f3a2eaf21..0669ab216 100644
+--- a/src/PIL/PngImagePlugin.py
b/src/PIL/PngImagePlugin.py
+@@ -533,14 +533,6 @@ def chunk_acTL(self, pos, length):
+ self.im_custom_mimetype = 'image/apng'
+ return s
+
+-def chunk_fcTL(self, pos, length):
+-s = ImageFile._safe_read(self.fp, length)
+-return s
+-
+-def chunk_fdAT(self, pos, length):
+-s = ImageFile._safe_read(self.fp, length)
+-return s
+-
+
+ #
+ # PNG reader
+@@ -682,6 +674,9 @@ def load_end(self):
+ break
+ except EOFError:
+ ImageFile._safe_read(self.fp, length)
++except AttributeError:
++logger.debug("%r %s %s (unknown)", cid, pos, length)
++ImageFile._safe_read(self.fp, length)
+ self._text = self.png.im_text
+ self.png.close()
+ self.png = None
diff --minimal -Nru pillow-5.4.1/debian/patches/series
pillow-5.4.1/debian/patches/series
--- pillow-5.4.1/debian/patches/series 2019-01-18 11:05:56.0 +0100
+++ pillow-5.4.1/debian/patches/series 2019-04-07 02:53:28.0 +0200
@@ -1,3 +1,4 @@
toplevel-setup.py
generate-webp-file
js-script-file.diff
+4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
Bug#62763: Progress
The fix has been merged upstream. https://gitlab.freedesktop.org/xorg/app/xbiff/merge_requests/1
Bug#926656: git-debrebase docs are intimidating
I don't know. As I said in my mail I'm not even sure there's a problem here. Let me give a bit of background here. Ian and I had what I thought was a really exciting call about git and source packages and stuff. It sounded like Ian hopes we'll some day get rid of patches-unapplied data models from our processes. To do that, there needs to be something to replace gbp pq in terms of simplicity and something that the average developer can understand. I said that I really didn't think git-dpm counted; I liked git-dpm but found gbp pq lots simpler. Ian nominated git-debrebase as a gbp pq replacement. I said I'd look. My conclusion is that it's certainly a git-dpm replacement, and I'll look at whether it is as easy to use in practice as gbp pq, but then I wrote that note saying that I think its docs are harder to approach. I think the one explicit concrete suggestion I'd make is to make it so a casual user can read git-debrebase (1) without git-debrebase(5) Or something so there's one man page that a user can start with that tells them enough to get going, and that they can approach git-debrebase without dgit. Rationale: 1) dgit is more complex and has more failure modes because as we all know, turning a git tree into a quilt dsc is really hard. 2) I think we're hoping eventually that pushing to salsa does the dgit-like-thing (possibly by calling dgit) and users don't need to do that themselves.
Bug#853923: ITP: pytorch/0.1.7 -- Tensors and Dynamic neural networks in Python
control: close -1 I give up.
Bug#926656: git-debrebase docs are intimidating
Hello, On Mon 08 Apr 2019 at 03:43PM +0100, Ian Jackson wrote: > From: Sam Hartman Thank you for your continued interest in dgit and gdr, Sam! > To: Ian Jackson Subject: Re: git > debrebase is cool Date: Sat, 06 Apr 2019 13:01:57 -0400 > >> "Ian" == Ian Jackson writes: > Ian> Did you see dgit-maint-debrebase(7) ? > > No. > I'll read it, but before doing so I'll respond with my user hat on: > > 1) I want to learn about git-debrebase, not about dgit. Dgit is really > scary and I'm told this thing is better than gbp pq. I don't think it would be crazy to write a manpage which is dgit-maint-debrebase(7) with the dgit stuff stripped out. The duplication would not introduce a new maintainance burden because there is already duplication between the tutorial manpages; we have to review them all when significant changes happen. If you both think this would help, I would produce the new manpage. > 5) Eventually come back to the git-debrebase man page. Wait this really > isn't so bad. I think I might kind of understand things. Except I > totally don't know how to manage my orig tarballs, or my upstream tags > or anything. I guess I can use gbp for that, but then why don't I use > gbp for everything. ... however, management of upstream tags etc. might not be easy to filter out of dgit-maint-debrebase(7) without introducing dgit thoughts. Not sure yet. -- Sean Whitton signature.asc Description: PGP signature
Bug#926689: [pkg-cryptsetup-devel] Bug#926689: cryptsetup-initramfs: config lines in grub.cfg for cryptodisk/luks and other modules missing
Control: reassign -1 grub2-common Control: merge-1 924151 Hi, On Mon, 08 Apr 2019 at 20:19:47 -0400, Gabriel Filion wrote: > Package: cryptsetup > Version: 2:2.1.0-2 > […] > I found out that some configuration lines are missing in all options that get > generated inside grub.cfg. > > Here's a diff between the grub configuration that was generated while in > rescue > mode (in a chroot inside the device that gets used for / ) vs. generated while > the system is running: > > -8<8<8<--- > $ diff -burN ~/grub.cfg /boot/grub/grub.cfg > --- /home/gabster/grub.cfg2019-04-08 19:20:24.000726392 -0400 > +++ /boot/grub/grub.cfg 2019-04-08 19:37:00.360714287 -0400 /boot/grub/grub.cfg is not generated by src:cryptsetup. Reassigning accordingly, and merging with #924151. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#926689: cryptsetup-initramfs: config lines in grub.cfg for cryptodisk/luks and other modules missing
Package: cryptsetup Version: 2:2.1.0-2 Severity: grave Justification: renders package unusable Hello, I've rebooted my computer this morning and the password prompt to unlock the crypto device would not appear before grub would search for the lvm device inside. This means that the system was not booting and I was getting dropped in the grub rescue prompt. The only way that I could bring the system back was by using the "Rescue mode" with the debian stretch installer. I have all files, including /boot, in one partition, and I use grub to unlock the crypto in order for it to find kernel and boot options. If this seems like a case that wouldn't affect most users, please don't hesitate to demote the severity. I found out that some configuration lines are missing in all options that get generated inside grub.cfg. Here's a diff between the grub configuration that was generated while in rescue mode (in a chroot inside the device that gets used for / ) vs. generated while the system is running: -8<8<8<--- $ diff -burN ~/grub.cfg /boot/grub/grub.cfg --- /home/gabster/grub.cfg 2019-04-08 19:20:24.000726392 -0400 +++ /boot/grub/grub.cfg 2019-04-08 19:37:00.360714287 -0400 @@ -58,15 +58,8 @@ if [ x$feature_default_font_path = xy ] ; then font=unicode else -insmod part_msdos -insmod cryptodisk -insmod luks -insmod gcry_rijndael -insmod gcry_rijndael -insmod gcry_sha256 insmod lvm insmod ext2 -cryptomount -u f100e85eb832489a9e97f1a9661a0c45 set root='lvmid/RfBQnU-gtRN-m55o-zwRA-L433-esRb-UpOa0w/lEtX5E-aBNo-0ngD-TwvX-3qrY-OxNF-DaG8T4' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='lvmid/RfBQnU-gtRN-m55o-zwRA-L433-esRb-UpOa0w/lEtX5E-aBNo-0ngD-TwvX-3qrY-OxNF-DaG8T4' f8c6cb03-667e-46fc-b531-eb30a2558d74 @@ -81,7 +74,7 @@ load_video insmod gfxterm set locale_dir=$prefix/locale - set lang=C + set lang=en_CA insmod gettext fi terminal_output gfxterm ->8>8>8--- (I've abbreviated the diff since all the rest is just repetition of missing "insmod" and "cryptomount" lines for all options. for some reason those lines are not added when running the system after decrypting the disk properly, but they are present when the grub.conf file is generated in the chroot in rescue mode. since the same versions of software are used in both cases, I can only presume that something is different in the mounts currently available, or some other kernel setting that might differ.. Heres a listing of mounts (which are mostly things that come from the kernel -- you can also see the debian stretch usb key that saved me :P ) -8<8<8<--- $ mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=8053524k,nr_inodes=2013381,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1614472k,mode=755) /dev/mapper/host-root on / type ext4 (rw,relatime,errors=remount-ro,stripe=8191) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12208) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
Bug#926688: unblock: robocode/1.9.3.3-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package robocode
Robocode in Buster is affected by CVE-2019-10648. The fix applied
cleanly and all tests pass. This is Debian bug 926088.
Thank you.
unblock robocode/1.9.3.3-2
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 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 /bin/dash
Init: unable to detect
diff -Nru robocode-1.9.3.3/debian/changelog robocode-1.9.3.3/debian/changelog
--- robocode-1.9.3.3/debian/changelog 2018-09-13 13:52:33.0 +0200
+++ robocode-1.9.3.3/debian/changelog 2019-04-08 00:13:19.0 +0200
@@ -1,3 +1,13 @@
+robocode (1.9.3.3-2) unstable; urgency=medium
+
+ * Fix CVE-2019-10648:
+Robocode allows remote attackers to cause external service interaction
+(DNS), as demonstrated by a query for a unique subdomain name within an
+attacker-controlled DNS zone, because of a .openStream call within
+java.net.URL. (Closes: #926088)
+
+ -- Markus Koschany Mon, 08 Apr 2019 00:13:19 +0200
+
robocode (1.9.3.3-1) unstable; urgency=medium
* New upstream version 1.9.3.3.
diff -Nru robocode-1.9.3.3/debian/patches/CVE-2019-10648.patch
robocode-1.9.3.3/debian/patches/CVE-2019-10648.patch
--- robocode-1.9.3.3/debian/patches/CVE-2019-10648.patch1970-01-01
01:00:00.0 +0100
+++ robocode-1.9.3.3/debian/patches/CVE-2019-10648.patch2019-04-08
00:13:19.0 +0200
@@ -0,0 +1,235 @@
+From: Markus Koschany
+Date: Mon, 8 Apr 2019 00:11:33 +0200
+Subject: CVE-2019-10648
+
+Bug-Debian: https://bugs.debian.org/926088
+Origin:
https://github.com/robo-code/robocode/commit/836c84635e982e74f2f2771b2c8640c3a34221bd
+---
+ .../host/security/RobocodeSecurityManager.java | 26 ++--
+ .../src/main/java/tested/robots/DnsAttack.java | 18 +
+ .../test/robots/TestConstructorHttpAttack.java | 11 +++---
+ .../sf/robocode/test/robots/TestHttpAttack.java| 11 +++---
+ .../robots/TestStaticConstructorDnsAttack.java | 46 ++
+ 5 files changed, 96 insertions(+), 16 deletions(-)
+ create mode 100644
robocode.tests.robots/src/main/java/tested/robots/DnsAttack.java
+ create mode 100644
robocode.tests/src/test/java/net/sf/robocode/test/robots/TestStaticConstructorDnsAttack.java
+
+diff --git
a/robocode.host/src/main/java/net/sf/robocode/host/security/RobocodeSecurityManager.java
b/robocode.host/src/main/java/net/sf/robocode/host/security/RobocodeSecurityManager.java
+index bc4c85a..ebd23e9 100644
+---
a/robocode.host/src/main/java/net/sf/robocode/host/security/RobocodeSecurityManager.java
b/robocode.host/src/main/java/net/sf/robocode/host/security/RobocodeSecurityManager.java
+@@ -12,7 +12,9 @@ import net.sf.robocode.host.IHostedThread;
+ import net.sf.robocode.host.IThreadManager;
+ import net.sf.robocode.io.RobocodeProperties;
+
++import java.net.SocketPermission;
+ import java.security.AccessControlException;
++import java.security.Permission;
+
+
+ /**
+@@ -49,7 +51,6 @@ public class RobocodeSecurityManager extends SecurityManager
{
+ }
+
+ Thread c = Thread.currentThread();
+-
+ if (isSafeThread(c)) {
+ return;
+ }
+@@ -84,7 +85,7 @@ public class RobocodeSecurityManager extends SecurityManager
{
+ if (robotProxy != null) {
+ robotProxy.punishSecurityViolation(message);
+ }
+- throw new AccessControlException(message);
++ throw new SecurityException(message);
+ }
+ }
+
+@@ -94,7 +95,6 @@ public class RobocodeSecurityManager extends SecurityManager
{
+ return;
+ }
+ Thread c = Thread.currentThread();
+-
+ if (isSafeThread(c)) {
+ return;
+ }
+@@ -123,9 +123,27 @@ public class RobocodeSecurityManager extends
SecurityManager {
+ String message = "Robots are only allowed to create up
to 5 threads!";
+
+ robotProxy.punishSecurityViolation(message);
+- throw new AccessControlException(message);
++ throw new SecurityException(message);
+ }
+ }
++
++public void checkPermission(Permission perm) {
++ if (RobocodeProperties.isSecurityOff()) {
++ return;
++ }
++ Thread c = Thread.currentThread();
++ if (isSafeThread(c)) {
++ return;
++ }
++super.checkPermission(perm);
++
++if (perm instanceof SocketPermission) {
++
Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?
control: tags -1 + patch
On Fri, Feb 22, 2019 at 05:45:29PM -0700, Sean Whitton wrote:
> On Mon 18 Feb 2019 at 11:54PM +00, Linda Lapinlampi wrote:
> > FHS 3.0's section 4.5 is about a completely irrelevant /usr/include
> > directory, not about /usr/local. I think this should point to section
> > 4.9 in the FHS?
>
> Thanks. A patch would be welcome.
Hi, apologies for the delay especially now that Buster is already in
full-freeze. :(
I'm attaching a patch, seems trivial. Here's the word-diff=plain to
resolve typos. Hoping this is okay to merge as is, but more feedback is
welcome.
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 59c92ec..6e0c020 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -127,8 +127,8 @@ empty.
Note that this applies only to directories *below* ``/usr/local``, not
*in* ``/usr/local``. Packages must not create sub-directories in the
directory ``/usr/local`` itself, except those listed in FHS, section
[-4.5.-]{+4.9.+} However, you may create directories below them as you wish. You
must not remove any of the directories listed in [-4.5,-]{+4.9,+} even if you
created them.
If ``/etc/staff-group-for-usr-local`` does not exist, ``/usr/local``
>From 88353bf9931337efae5c06cad23306ff276d521e Mon Sep 17 00:00:00 2001
From: "Juuso \"Linda\" Lapinlampi"
Date: Mon, 8 Apr 2019 22:53:48 +
Subject: [PATCH] ch-opersys: Update referenced sections to FHS 3.0
The policy says in section 9.1.1 all files and directories must comply
with Filesystem Hierarchy Standard (FHS) 3.0. Later in section 9.1.2,
the references to FHS' section numbers were pointing to sections
apparently only sensible for an older FHS 2.3 document.
This fixes those references to the new numbers found in the FHS 3.0
document, and thus fixes the typos.
See: https://bugs.debian.org/922654
---
policy/ch-opersys.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 59c92ec..6e0c020 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -127,8 +127,8 @@ empty.
Note that this applies only to directories *below* ``/usr/local``, not
*in* ``/usr/local``. Packages must not create sub-directories in the
directory ``/usr/local`` itself, except those listed in FHS, section
-4.5. However, you may create directories below them as you wish. You
-must not remove any of the directories listed in 4.5, even if you
+4.9. However, you may create directories below them as you wish. You
+must not remove any of the directories listed in 4.9, even if you
created them.
If ``/etc/staff-group-for-usr-local`` does not exist, ``/usr/local``
--
2.20.1
Bug#920321: lua5.3: CVE-2019-6706
Hi, Yep, my bad not had added any info on the patch...said that The patch can be find here [1] It was tested against the POC and it fixed the issue. Any other question, please let me know :) [1] http://lua.2524044.n2.nabble.com/CVE-2019-6706-use-after-free-in-lu a-upvaluejoin-function-tc7685575.html Cheers! On Seg, 2019-04-08 at 20:29 +0200, Moritz Mühlenhoff wrote: > On Thu, Jan 24, 2019 at 07:02:59AM +0100, Salvatore Bonaccorso wrote: > > > > Source: lua5.3 > > Version: 5.3.3-1.1 > > Severity: important > > Tags: security upstream > > Control: found -1 5.3.3-1 > > > > Hi, > > > > The following vulnerability was published for lua5.3. > > > > CVE-2019-6706[0]: > > > > > > Lua 5.3.5 has a use-after-free in lua_upvaluejoin in lapi.c. For > > > example, a crash outcome might be achieved by an attacker who is > > > able > > > to trigger a debug.upvaluejoin call in which the arguments have > > > certain > > > relationships. > Ubuntu fixed this via https://launchpad.net/ubuntu/+source/lua5.3/5.3 > .3-1ubuntu0.18.10.1 : > http://launchpadlibrarian.net/417853567/lua5.3_5.3.3-1_5.3.3-1ubuntu0 > .18.10.1.diff.gz > > Leonidas, what's the provenance of that patch (given that upstream > doesn't > have a public code repo), has it been reviewed/blessed by the Lua > upstream > developers? > > Cheers, > Moritz signature.asc Description: This is a digitally signed message part
Bug#923423: dpkg: Hangs for 19 mins installing texlive-fonts-extra
Hi! On Tue, 2019-03-05 at 15:43:05 +0100, Vincent Lefevre wrote: > I've done a test with "iozone -a -e", and with this -e option > (to include fsync), the operations are much slower than on the > other machine. > > zira:~> iozone -a -e > [...] > random > random bkwdrecordstride > kB reclenwrite rewritereadrereadread > write read rewrite read fwrite frewritefread freread > 64 4 1821 1987 1922 3703 3657 > 1770 1621 1628 1697 1707 1773 1879725 2892445 > 64 8 1606 1684 1713 3493 3476 > 1700 1765 1730 1812 2135 1852 2278628 3406295 > 64 16 1807 1823 1986 3898 3798 > 1977 1813 1988 1871 2049 3320 2561267 4018152 > 64 32 1702 1714 1755 3494 3683 > 1741 1841 1796 1737 1633 1674 1879725 4018152 > 64 64 1808 1790 1632 3314 3387 > 2254 1995 1843 1984 1789 1820 2801873 3203069 > [...] Ok, can we conclude this is not a problem in dpkg then? :) It seems to me either hardware, filesystem or kernel related as mentioned before. Could you reassign where you think it would be more appropriate? Thanks, Guillem
Bug#926387: oxygen-icons5: FTBFS randomly (Directory renamed before its status could be extracted)
Control: tag -1 moreinfo Hi! On Thu, 2019-04-04 at 10:27:29 +, Santiago Vila wrote: > Package: src:oxygen-icons5,dpkg-dev,tar > Tags: ftbfs > I tried to build "oxygen-icons5" in buster but it failed: > This happens randomly. Sometimes it fails, sometimes it does not. It > happens in other packages as well, but it happens particularly often > with oxygen-icons5, as shown in my build history: > I'm using sbuild + schroot + eatmydata + overlayfs on 1-XS instances > from Scaleway. Hmm, can you reproduce those results on a system not using overlayfs? That's my immediate suspect here, as that has already produced in the past misbehavior in combination with dpkg when it comes to POSIX compliance and expected sane filesystem behavior. Thanks, Guillem
Bug#926686: RFP: node-evacuated-deep-extend -- Recursive object extending
Package: wnpp Severity: wishlist * Package name: node-evacuated-deep-extend Version : 0.6.0 Upstream Author : Viacheslav Lotsmanov * URL : https://salsa.debian.org/themusicgod1-guest/node-evacuated-deep-extend/ * License : Expat Programming Lang: javascript Description : Recursive object extending (This is a fork of node-deep-extend with a non-NSA/Microsoft upstream.) This module does a recursive object extending. Node.js is an event-based server-side JavaScript engine.
Bug#920489: opensmtpd: new upstream version available
On Mon, Apr 08, 2019 at 10:10:10PM +, Linda Lapinlampi wrote: > Ping. Would you upload OpenSMTPD 6.4.1p2 to experimental with the > patches re-enabling OpenSSL support provided in this Bug#, please? I reminded myself how my patches don't change anything required to build/install the new smtp(1) client, man pages, etc. Some additional plumbing in debian/* may be required to make that client available.
Bug#926472: dpkg(1) man page: should document that putting a package on hold will require to process triggers manually
Control: retitle -1 dpkg: --pending should enqueue packages in hold state Control: severity -1 normal Hi! On Fri, 2019-04-05 at 19:29:28 +0200, Vincent Lefevre wrote: > Package: dpkg > Version: 1.19.6 > Severity: wishlist > When a package is on hold, its triggers are not processed > automatically, and this is regarded as a feature[*]. It > should be documented that triggers need to be processed > manually. > > [*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901040 Actually, this looks like a bug to me. A package being held does not prevent trigger processing or much at all from the dpkg side (mostly automatic removal or automatic configuration of unrelated packages via --force-configure-any), this is mostly a state relevant for front-ends. The problem is that the --pending option does not enqueue held packages, while a manual --configure would work. I'm going to fix this in 1.20.x. Thanks, Guillem
Bug#926685: unblock: python3-lexicon/3.0.8-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello release team,
I was recently made aware of a bug in python3-lexicon that causes the
certbot dnsimple plugin to be completely broken. I've spoken to the
upstreams of both certbot and lexicon, and we've worked out a plan
forward.
A single backported patch for python3-lexicon will fix the issue for
certbot and anything else that's using the DNSimple API. The
functional change is a single line, though the patch is slightly
bigger to correct the tests as well.
Could I get it unblocked for migration into buster? A debdiff is
attached.
Thanks!
unblock python3-lexicon/3.0.8-2
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.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
diff -Nru lexicon-3.0.8/debian/changelog lexicon-3.0.8/debian/changelog
--- lexicon-3.0.8/debian/changelog 2019-01-06 09:24:20.0 -0500
+++ lexicon-3.0.8/debian/changelog 2019-04-08 18:07:45.0 -0400
@@ -1,3 +1,10 @@
+lexicon (3.0.8-2) unstable; urgency=high
+
+ * Team upload.
+ * Import dnsimple create fix from upstream (Closes: #926682)
+
+ -- Harlan Lieberman-Berg Mon, 08 Apr 2019 18:07:45
-0400
+
lexicon (3.0.8-1) unstable; urgency=medium
[ Ana Custura ]
diff -Nru lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch
lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch
--- lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch
1969-12-31 19:00:00.0 -0500
+++ lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch
2019-04-08 18:02:42.0 -0400
@@ -0,0 +1,143 @@
+From d0bf4939d49c63026411a306615b6fb13ed0cc22 Mon Sep 17 00:00:00 2001
+From: Adrien Ferrand
+Date: Wed, 3 Apr 2019 23:43:24 +0200
+Subject: [PATCH] Fix create record on dnsimple (#389)
+
+---
+ lexicon/providers/dnsimple.py | 2 +-
+ ..._calling_delete_record_by_filter_should_remove_record.yaml | 2 +-
+ ..._record_by_filter_with_fqdn_name_should_remove_record.yaml | 2 +-
+ ..._record_by_filter_with_full_name_should_remove_record.yaml | 2 +-
+ ...ling_delete_record_by_identifier_should_remove_record.yaml | 2 +-
+ ...h_record_set_by_content_should_leave_others_untouched.yaml | 2 +-
+ ...calling_delete_record_with_record_set_name_remove_all.yaml | 4 ++--
+ ...ing_update_record_with_fqdn_name_should_modify_record.yaml | 2 +-
+ ...ing_update_record_with_full_name_should_modify_record.yaml | 2 +-
+ 9 files changed, 10 insertions(+), 10 deletions(-)
+
+Index: python-lexicon/lexicon/providers/dnsimple.py
+===
+--- python-lexicon.orig/lexicon/providers/dnsimple.py
python-lexicon/lexicon/providers/dnsimple.py
+@@ -69,7 +69,7 @@ class Provider(BaseProvider):
+ record['regions'] = self._get_provider_option('regions')
+
+ payload = self._post(
+-'{0}/zones/{1}/records'.format(self.account_id, self.domain),
record)
++'/{0}/zones/{1}/records'.format(self.account_id, self.domain),
record)
+
+ LOGGER.debug('create_record: %s', 'id' in payload)
+ return 'id' in payload
+Index:
python-lexicon/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_record_by_filter_should_remove_record.yaml
+===
+---
python-lexicon.orig/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_record_by_filter_should_remove_record.yaml
python-lexicon/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_record_by_filter_should_remove_record.yaml
+@@ -112,7 +112,7 @@ interactions:
+ Content-Type: [application/json]
+ User-Agent: [python-requests/2.19.1]
+ method: POST
+-uri: https://api.sandbox.dnsimple.com/v2731/zones/lexicontest.us/records
++uri: https://api.sandbox.dnsimple.com/v2/731/zones/lexicontest.us/records
+ response:
+ body: {string:
'{"data":{"id":502887,"zone_id":"lexicontest.us","parent_id":null,"name":"delete.testfilt","content":"challengetoken","ttl":3600,"priority":null,"type":"TXT","regions":["global"],"system_record":false,"created_at":"2018-07-09T05:38:19Z","updated_at":"2018-07-09T05:38:19Z"}}'}
+ headers:
+Index:
python-lexicon/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_record_by_filter_with_fqdn_name_should_remove_record.yaml
+===
+---
Bug#920489: opensmtpd: new upstream version available
Control: retitle 920489 opensmtpd: new upstream version available On Sat, Feb 09, 2019 at 10:29:03AM -0500, Ryan Kavanagh wrote: > Thanks for the bug report. I think it would be best to keep 6.0.3p1 for > Buster given that it has been well tested. I am also reluctant to make > the jump to 6.4.x right before freeze given the dependency on libressl > and the changes to config file syntax. > > That said, I am willing to upload 6.4.x to experimental if there is > interest. Thank you, Linda, for the patches. Ping. Would you upload OpenSMTPD 6.4.1p2 to experimental with the patches re-enabling OpenSSL support provided in this Bug#, please? I'm aware Buster is in full freeze right now, so an upload to unstable would not be feasible anyway. I also agree #754513 (LibreSSL) dependency is/would be a good reason to block an upload to unstable, if the freeze wasn't happening.
Bug#926684: tracker.debian.org: Outdated team information (here debian-tryton)
Package: tracker.debian.org Severity: normal Dear Maintainers, the information on https://tracker.debian.org/teams/debian-tryton/ is severely outdated and misleading: URL: http://tryton.alioth.debian.org/ Maintainer email: maintain...@debian.tryton.org I couldn't find a way to update that information via 'Manage team'. Could you please fix that or point me to where to fix it to URL: https://tryton-team.pages.debian.net/ Maintainer email: team+tryton-t...@tracker.debian.org Thanks Mathias -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#926103: Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2
Hi Release Team,
Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve
the attached debdiff, so that I can upload the fixed package to unstable.
Thank you for your consideration.
Best,
Reinhard
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+ * Acknoledge NMU.
+ * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler Mon, 08 Apr 2019 17:58:31 -0400
+
pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 2017-05-29
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 2019-04-08
17:58:31.0 -0400
@@ -1 +1,2 @@
enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
---
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
1969-12-31 19:00:00.0 -0500
+++
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber
+Date: Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+ uint32_t Len;
+- uint16_t wLenRsp=0;
+- uint16_t wLenErr=0;
++ uint32_t wLenRsp=0;
++ uint32_t wLenErr=0;
+ if(ResponseLen!=0)
+- wLenRsp=(uint16_t)*ResponseLen;
++ wLenRsp=*ResponseLen;
+ if(ApplicationErrorLength!=NULL)
+- wLenErr=(uint16_t)*ApplicationErrorLength;
+- if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++ wLenErr=*ApplicationErrorLength;
++ Len=4+wLenRsp+wLenErr;
++ if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++ return CJ_ERR_WRONG_PARAMETER;
+
+
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+ {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ *ApplicationErrorLength=0;
+ return Res;
+ }
+- memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+- wLenRsp=ReaderToHostShort(wLenRsp);
+- memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+- wLenErr=ReaderToHostShort(wLenErr);
++
++ uint16_t wLenRsp16 = 0;
++ uint16_t wLenErr16 = 0;
++ memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++ wLenRsp=ReaderToHostShort(wLenRsp16);
++ memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++ wLenErr=ReaderToHostShort(wLenErr16);
++
+ if(ApplicationErrorLength)
+ {
+ if(wLenErr>*ApplicationErrorLength)
Bug#823237: proposal cont.
I will remove the section "Manuals for GNU/Linux in general" if there are no opbjections. It only contains links to tldp.org that are all outdated and really do not give any useful information for the user. IMO we should also focus on Debian related documentation. -- regards Thomas
Bug#926683: unblock: libfm-qt/0.14.1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libfm-qt
New version fixes grave bug #926626 libfm-qt6: Cannot copy dirs over smb
Solution: Added upstream patch
>From 6cb5f38d2c1261b782b16da45bb323b069db94fe Mon Sep 17 00:00:00 2001
From: Tsu Jan
Date: Mon, 8 Apr 2019 07:13:09 +0430
Subject: [PATCH] Fixed SMB recursive copy
Fixes https://github.com/lxqt/libfm-qt/issues/385 by trying to set dir
permissions only once and ignoring possible errors (that happen with SMB and,
maybe, other protocols).
---
src/core/filetransferjob.cpp | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/core/filetransferjob.cpp b/src/core/filetransferjob.cpp
index 4039c58..6b44576 100644
--- a/src/core/filetransferjob.cpp
+++ b/src/core/filetransferjob.cpp
@@ -279,16 +279,17 @@ bool FileTransferJob::makeDir(const FilePath& srcPath,
GFileInfoPtr srcInfo, Fil
mode,
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS,
cancellable().get(),
);
if(!chmod_done) {
-ErrorAction act = emitError(err, ErrorSeverity::MODERATE);
+/* NOTE: Some filesystems may not support this. So, ignore
errors for now. */
+break;
+/*ErrorAction act = emitError(err,
ErrorSeverity::MODERATE);
if(act != ErrorAction::RETRY) {
break;
-}
-/* FIXME: some filesystems may not support this. */
+}*/
}
} while(!chmod_done && !isCancelled());
}
}
-return mkdir_done && chmod_done;
+return mkdir_done/* && chmod_done*/;
}
bool FileTransferJob::handleError(GErrorPtr , const FilePath ,
const GFileInfoPtr , FilePath , int& flags) {
Thanks Alf
unblock libfm-qt/0.14.1-4
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.7-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Bug#823237: proposal
I will replace the Howto section in /doc by this if there are no objections. HOWTOs The https://www.tldp.org/HOWTO/HOWTO-INDEX/categories.html;>HOWTO documents, like their name says, describe how to do something, and they usually cover a more specific subject. P.S.: There's no need in listing "the most important Linux HOWTOs", which are just old and outdated. -- regards Thomas
Bug#926682: lexicon cannot create records through DNSimple
Package: python3-lexicon Version: 3.0.8-1 Severity: important Tags: upstream An update to the DNSimple API caused a bug in lexicon to go from technically-wrong-but-working to straight-up-broke. A minor patch ported from upstream will fix this problem, and unbreak the certbot plugin that depends on lexicon for its dnsimple support. I've verified with the upstream developers that there's no problem in cherry-picking just the patch back onto the version we have in buster. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.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 python3-lexicon depends on: ii python3 3.7.2-1 ii python3-cryptography 2.6.1-3 ii python3-future0.16.0-1 ii python3-requests 2.21.0-1 pn python3-tldextract ii python3-yaml 3.13-2 Versions of packages python3-lexicon recommends: pn python3-boto3 pn python3-softlayer python3-lexicon suggests no packages.
Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed
On Mon, 8 Apr 2019 16:50:31 +0100 ana wrote: > Thanks for the update on this. It would be a shame to drop the package > entirely from Debian. Have had a look at the packaging on salsa and I'm > happy to take over. I would need DM permissions on it to make uploads. Hi Ana! Happy to sponsor you for uploading on it if you'll take it over. Ping me on the original removal bug when you have the upload prepared that names you as a maintainer and closes the O. -Harlan
Bug#926671: nheko: Unrecognized event id formats cause nheko to crash
Control: tags 926671 + patch Control: severity 926671 important I'm attaching a DEP-3 formatted Debian patch, backported from upstream mtxclient to nheko 0.6.3-1 in Debian. I'm also increasing the severity of this bug to "important". I think it'd be best to try to get the release managers' manual approval for unblock this change into Buster via unstable upload, since nheko in buster/stable may not be very useful in few years without this patch or a backport: https://github.com/matrix-org/matrix-doc/pull/1943 (uhoreg@ mentined libqmatrixclient may need this same patch too, but I didn't look into that.)
Bug#926671: nheko: Unrecognized event id formats cause nheko to crash
On Mon, Apr 08, 2019 at 09:22:43PM +, Linda Lapinlampi wrote:
> I'm attaching a DEP-3 formatted Debian patch, backported from upstream
> mtxclient to nheko 0.6.3-1 in Debian.
...and here's the patch I forgot to attach earlier.
Author: redsky17
Bug: https://github.com/Nheko-Reborn/mtxclient/issues/3
Bug-Debian: https://bugs.debian.org/926671
Description: Fix Room v3 Issue
This at least partially addresses #3. I have a feeling that
additional updates will be needed at some point, but this
fixes the issue where mtxclient would throw an exception for
unrecognized event id formats, which caused nheko to crash.
Origin: backport, https://github.com/Nheko-Reborn/mtxclient/commit/67d39691666bcdf3cc660db19ccc0d9941df13fd
Last-Update: 2019-04-08
diff --git a/mtxclient/include/mtx/identifiers.hpp b/mtxclient/include/mtx/identifiers.hpp
index 87acc43..7885885 100644
--- a/mtxclient/include/mtx/identifiers.hpp
+++ b/mtxclient/include/mtx/identifiers.hpp
@@ -90,7 +90,10 @@ parse(const std::string )
identifier.hostname_ = id.substr(parts + 1);
identifier.id_= id;
} else {
-throw std::invalid_argument(id + ": invalid format\n");
+// V3 event ids don't use ':' at all, don't parse them the same way.
+identifier.localpart_ = id;
+identifier.hostname_ = id;
+identifier.id_ = id;
}
return identifier;
Bug#926681: unblock: acme-tiny/1:4.0.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, I'm asking for the unblock of acme-tiny because a critical bug was solved upstream. I needed to package the last upstream release to address the following bug: acme-tiny: Please update to ACMEv2 API #924393 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924393 I didn't upload to unstable yet as I'm still waiting for the ack from the other members of the LetsEncrypt team and I also understand that the debdiff is big so it's better to wait for the release team's ack as well. Here is why I believe this last release is at least as stable as the previous one: It is dated 17/05/2018, this is almost one year since it was released, considering the package is also available on pip, I assume a good amount of people are already running the latest release for some time now. Also, a good amount of open issues and PRs on Github are dated from before the latest release, there are no indicators in there this release may introduce new problems. Thanks, -- Samuel Henrique acme-tiny.debdiff Description: Binary data
Bug#926602: CVE-2019-10906 - jinja sandbox escape poc
Hi Salvatore, > CVE-2016-10745 was assigned for this issue. Thanks for the information. I just noticed you added CVE-2016-10745 to the tracker. I am fairly confused, do you know why this CVE was not referenced in the tracker? Or did you just request it? cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Bug#899128: kdepim: Limit CVE-2017-17689 (EFAIL) even more for kmail
Control: reassign -1 src:kdepim Hi Ivo, On Mon, Apr 08, 2019 at 11:36:10AM +0200, Ivo De Decker wrote: > Hi, > > On Sat, May 19, 2018 at 07:18:06PM +0200, Sandro Knauß wrote: > > I now created a debdiff for kdepim. The patch depdends on the new symbol > > that > > was added in new messageviewer (see #899127). > > Does this bug still affect buster/sid? From the bug log and the tracker for > CVE-2017-17689, it look like kmail in buster/sid is not affected, but it would > be good if someone could confirm that. I think the tracking problem was hiere that #899128 is associated with src:meta-kde, but it should be src:kdepim (#899128) and respectively kf5-messagelib was #899127. The issue was fixed in the kf5-messagelib in version 4:18.08.1-1. In stretch src:kdepim was a source package, whilst in buster kdepim is a binary package produced by kde-meta, but the issue lies there in src:kf5-messagelib. Regards, Salvatore
Bug#926680: nheko: fakehome is not automatically cleaned up
Source: nheko Version: 0.6.3-1 Severity: normal Dear Maintainer, if building from source fails during the CMake build process, fakehome won't be automatically cleaned up and dpkg-source will complain about local changes. This happened to me when I ran out of storage space on /tmp where it was building. Specifically, CMake's .deps directory in fakehome can cause trouble too. It'd be the best if fakehome could be avoided altogether. dh_auto_build removes the fakehome directory, but it should probably be done in dh_auto_clean instead. > dpkg-source: info: local changes detected, the modified files are: > > nheko-0.6.3/fakehome/.cmake/packages/MatrixClient/4f5a4442c20c172452cff095aaf9ebc8 > dpkg-source: error: aborting due to unexpected upstream changes, see > /tmp/nheko_0.6.3-1.1.diff.J43BJC -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#926679: RFP: node-evacuated-elsint-config-prettier -- Turns off all rules that are unnecessary or might conflict with Prettier
Package: wnpp Severity: wishlist * Package name: node-evacuated-elsint-config-prettier Version : 2.9.0 Upstream Author : Simon Lydell * URL : https://salsa.debian.org/themusicgod1-guest/node-evacuated-elsint-config-prettier/ * License : MIT Programming Lang: javascript Description : Turns off all rules that are unnecessary or might conflict with Prettier (This project has been forked/evacuated from NSA/Microsoft Github) lets you use you favorite shareable config without letting its stylistic choices get in the way when using Prettier. Supports eslint-plugin-flowtype, eslint-plugin-react and eslint-plugin-standard. Also ships with a little CLI tool to help you check if your configuration contains any rules that are unnecessary or conflict with Prettier.
Bug#924848: telegram-cli: FTBFS: build-dependency not installable: libwolfssl-dev
Hi Tobias, Thanks for tackling this. I'm a bit busy last week due to Linaro connect. And yes as you described, telegram-cli seems still needs the header of SSL to be compiled. I use wolfssl completely due to the license issue. I've also tried to backport the patch for wolfssl but it seems to me that it is not a trivial one. We might need to bump the version of wolfssl. But since we are in freeze, so bumping the version seems not good. So maybe we need to remove telegram-cli from testing. I mean exclude telegram-cli in buster release. And include it back in buster+1. Yours, Paul On Sat, Apr 6, 2019 at 3:42 AM Tobias Frost wrote: > On Wed, 3 Apr 2019 22:16:23 +0500 Andrey Rahmatullin > wrote: > > libwolfssl was removed from testing due to #918952. > > The shared lib was removed but this package was not, because it > doesn't > > depend on the lib. Maybe the B-D can be safely removed. > > Checked, will FTBFS when done… > It will likely build with openssl (not tried), but the source code is > GPL2.0 without an OpenSSL license exception... > I asked upstream to add such an exception in > https://github.com/vysheng/tg/issues/1591 > > > > -- > > WBR, wRAR >
Bug#926677: RFP: node-evacuated-electron-download -- downloads an electron release zip
Package: wnpp Severity: wishlist * Package name: node-evacuated-electron-download Version : 4.1.0 Upstream Author : max ogden * URL : https://salsa.debian.org/themusicgod1-guest/evacuated-electron-download * License : BSD-3-Clause Programming Lang: javascript Description : downloads an electron release zip This is listed as a prerequisite of electron ( #842420 ) by the electron task list https://wiki.debian.org/Javascript/Nodejs/Tasks/electron It downloads electron itself, currently from NSA/Microsoft (changing it to grab from a non-NSA/Microsoft source is an open issue - https://salsa.debian.org/themusicgod1-guest/evacuated-electron-download/issues/1 ) If it's at all possible to use electron *without* this particular package, to pull the sources out by using it once and packaging *them*, we should do so. This rfp is just following the dependencies outlined by the electron task and will be removed if it's at all possible to package electron without it.
Bug#926676: guile-2.2-dev: Missing binary symlink Usage: guild COMMAND [ARGS] Run command-line scripts provided by GNU Guile and related programs. Commands: compile Compile a file. d
Package: guile-2.2-dev Version: 2.2.4+1-1 Severity: normal The `guile-2.2` package installs the `guile-2.2` binary. This in turn will cause the `GUILE_PROGS` autoconf macro (as shipped in `guile-2.2-dev`) to look for `guild-2.2`, not considering the installed `guild` binary, thus causing `configure` scripts that use `GUILE_PROGS` to fail like this: configure: checking for guile 2.2 configure: found guile 2.2 checking for guile-2.2... /usr/bin/guile-2.2 checking for Guile version >= 2.2... 2.2.4 checking for guild-2.2... no checking for guile-config-2.2... no checking for guile-tools-2.2... no configure: error: 'guild' binary not found; please check your guile-2.x installation. The above output was from an attempt at compiling `guix` [0]. It seems that if a versioned `guile` binary (such as `guile-2.2`) is present, so should versioned variants of `guild`, `guile-config`, and `guile-tools`. The documentation of the `GUILE_PROGS` macro supports this: This macro looks for programs ‘guile’ and ‘guild’, setting variables GUILE and GUILD to their paths, respectively. The macro will attempt to find ‘guile’ with the suffix of ‘-X.Y’, followed by looking for it with the suffix ‘X.Y’, and then fall back to looking for ‘guile’ with no suffix. If ‘guile’ is still not found, signal an error. The suffix, if any, that was required to find ‘guile’ will be used for ‘guild’ as well. Installing the versioned variants might even be a step on the way to allow co-installability of `guile-2.2-dev` and future versions of the Guile development binary package. [0] https://www.gnu.org/software/guix/manual/en/guix.html#Introduction Kind Regards, Rotty -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (850, 'testing'), (800, 'unstable'), (500, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages guile-2.2-dev depends on: ii guile-2.2 2.2.4+1-1 ii guile-2.2-libs 2.2.4+1-1 ii libc6-dev 2.28-8 ii libgc-dev 1:7.6.4-0.4 ii libgmp-dev 2:6.1.2+dfsg-4 ii libltdl-dev 2.4.6-9 ii libncurses-dev [libncurses5-dev]6.1+20181013-2 ii libncurses5-dev 6.1+20181013-2 ii libreadline-dev [libreadline6-dev] 7.0-5 ii pkg-config 0.29-6 guile-2.2-dev recommends no packages. guile-2.2-dev suggests no packages. -- no debconf information
Bug#926646: libdmtx: Incomplete debian/copyright?
Control: found 926646 0.7.5-2 On Mon, 08 Apr 2019 at 08:43:57 -0400, Chris Lamb wrote: > I just ACCEPTed libdmtx from NEW but the FTP team had noticed that the > copyright stanza for debian/ is labelled GPL-2+ but its content is > GPL-2. This is not a regression in my NMU (which didn't touch d/copyright) so I'm marking it as a bug that already existed in the version in testing. I am not a (significant) copyright holder on the packaging, so I can't fix this by NMUing. Roberto: if my changes to the libdmtx packaging are significant enough to be protected by copyright, you are welcome to treat them as GPL-2+, GPL-2, BSD-3-clause and/or BSD-2-clause, whichever is most convenient for you. smcv
Bug#926389: (no subject)
Any progress on fixing this in Jessie?
Bug#842420: non nsa/microsoft upstream link
there is a non-NSA/Microsoft upstream repo available for this project at https://notabug.org/themusicgod1/electron
Bug#926328: [Pkg-utopia-maintainers] Bug#926328: network-manager-gnome: nm-applet crashes with a coredump when try to create a new WiFi network
This sounds like the upstream bug... https://gitlab.gnome.org/GNOME/network-manager-applet/issues/43 ...according to the backtrace with the call of nma_wifi_dialog_get_connection() followed by free(). I'm affected by this issue too (in testing), but with the connection to a hidden SSID. The issue is already solved, so there is hope for patch by the maintainer. Because this will officially arrive earliest with v1.8.22.
Bug#921266: The segfault Is defintely not caused by t-online, but linpone
I have done further tests and finally given up to get linphone working as a SIP client here - the segfault on password enty is absolutely reproducible. To solve this issue I have tried "twinkle" (another SIP client from Buster-repo and that was set up within a few minutes. Just entered the SIP and STUN servers and my credentials for my t-online account - and all works as expected. This definitely confirms that it is not related to t-online, nor to some missconfiguration of my system. Moreover such a segfault is caused by severe bugs in the application itself. Again the syslog message: tux kernel: [ 4866.131680] linphone[6107]: segfault at 0 ip 003153a8f37a sp 7ffe572604c8 error 4 in libc-2.24.so[3153a0+194000] Mar 3 18:17:33 tux kernel: [ 4866.131690] Code: 89 e6 5b 4c 89 ef 5d 41 5c 41 5d e9 e0 49 ff ff 89 f8 31 d2 66 0f ef ff 09 f0 25 ff 0f 00 00 3d c0 0f 00 00 0f 8f 78 02 00 00 0f 6f 0f f3 0f 6f 06 66 0f 74 c1 66 0f da c1 66 0f ef c9 66 0f of which the tail is always the same: - ... 89 f8 31 d2 66 0f ef ff 09 f0 25 ff 0f 00 00 3d c0 0f 00 00 0f 8f 78 02 00 00 0f 6f 0f f3 0f 6f 06 66 0f 74 c1 66 0f da c1 66 0f ef c9 66 0f There is also no means to gather more info about the crash in libc6 besides the syslog entry. Linphone's debug output. Even at highest level does not disclose anything valuable for me. So linphone 3.12 from Buster is buggy and absolutely unusable for me, severity should be set back to 'serious' to reflect that.
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Luca & others, I've been working on syslinux-efi support in the past weeks and just submitted a MR with a working implementation, along with some small bootloader-related cleanups and refactors: https://salsa.debian.org/live-team/live-build/merge_requests/19 In the end, I opted to implement syslinux-efi rather than make grub-efi work on hdd images, since that seemed easier and allows preserving the existing bootloader config files in our project. Getting grub-efi to work on hdd images might still be an interesting project that could be implemented alongside syslinux-efi support, though I do not have any specific purpose for it as of yet. As predicted by others in this bug report, my work does not enable secure boot (which syslinux simply does not support), nor enable syslinux-efi support in iso/isohybrid images (since syslinux-efi does not support this, or at least it apparently does not work). Gr. Matthijs signature.asc Description: PGP signature
Bug#926654: tinc: Fails to parse '::' in IPv6-address
On Mon, Apr 08, 2019 at 04:02:20PM +0200, Casper Gielen (Unix Administrator University Tilburg) wrote: > if the Subnet in /etc/tinc//hosts/ contains '::' then > TINC does not parse it correctly. > > bad: > /etc/tinc/cluster/hosts/nyorobo > Subnet = fd00:610:1410:ae2e:23f0:c936::50 > > # service restart tinc && pkill -USR2 tincd > > /var/log/syslog: > Apr 8 15:57:08 nyorobo tincd[1427]: Subnet list: > Apr 8 15:57:08 nyorobo tincd[1427]: 0:10:10:2e:f0:36#10 owner nyorobo Ah, it actually depends on the place of the '::'; if it's after the sixth element it will incorrectly parse it as a MAC address. In tinc 1.1 it's already fixed, I'll backport the fix. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#926674: links2: Crash on invalid IDN URL
Package: links2
Version: 2.18
Severity: important
Tags: fixed-upstream upstream patch
Control: submitter -1 Mikulas Patocka
I just received the attached mail from upstream with a patch that
fixes a crash on an invalid IDN URL.
I intent to fix this in Debian Sid/Buster with applying the functional
part of the patch (but probably not the changelog part) against 2.18-1
and uploading 2.19 to Debian Experimental until Buster is released.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
--- Begin Message ---
Hi
I submit this patch for links-2.18 in Debian Buster. It fixes a crash on
invalid IDN URL.
For Debian Sid, you can upgrade to links-2.19.
Mikulas
commit 9dc711da9b61431f83f863920583d4c9d3bea26d
Author: Mikulas Patocka
Date: Sat Mar 30 22:36:43 2019 +0100
fix a crash on invalid idn url
diff --git a/ChangeLog b/ChangeLog
index 92736b50..4ea09306 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+Sat Mar 30 21:56:02 CET 2019 mikulas:
+
+ Fixed a crash on invalid IDN URL, such as http://test,ï.com/
+ (found by lsxv...@gmail.com)
+
Tue Mar 12 23:02:33 CET 2019 mikulas:
Make it possible to select other fonts, using fontconfig and freetype
diff --git a/url.c b/url.c
index e6252d70..8dc34d47 100644
--- a/url.c
+++ b/url.c
@@ -1153,6 +1153,8 @@ static unsigned char *display_url_or_host(struct terminal
*term, unsigned char *
url_enc = idn_encode_url(url_conv2, 0);
else
url_enc = idn_encode_host(url_conv2,
(int)strlen(cast_const_char url_conv2), separator, 0);
+ if (!url_enc)
+ url_enc = stracpy(url_conv2), is_idn = 1;
mem_free(url_conv2);
if (!strcmp(cast_const_char url_enc, cast_const_char url)) {
if (is_idn && warn_idn) {--- End Message ---
signature.asc
Description: Digital signature
Bug#926675: proj FTCBFS: fails running javadoc
Source: proj Version: 5.2.0-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap proj fails to cross build from source, because it fails running javadoc with an Exec format error. javadoc is needed for the build architecture, but requested for the host architecture. Annotating the default-jdk-headless dependency with :native fixes the cross build. Please consider applying the attached patch. Helmut diff --minimal -Nru proj-5.2.0/debian/changelog proj-5.2.0/debian/changelog --- proj-5.2.0/debian/changelog 2018-09-15 18:15:48.0 +0200 +++ proj-5.2.0/debian/changelog 2019-04-08 21:07:50.0 +0200 @@ -1,3 +1,11 @@ +proj (5.2.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Annotate Build-Depends default-jdk-headless with +:native. (Closes: #-1) + + -- Helmut Grohne Mon, 08 Apr 2019 21:07:50 +0200 + proj (5.2.0-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru proj-5.2.0/debian/control proj-5.2.0/debian/control --- proj-5.2.0/debian/control 2018-09-15 18:14:39.0 +0200 +++ proj-5.2.0/debian/control 2019-04-08 21:07:49.0 +0200 @@ -7,7 +7,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf, sharutils, - default-jdk-headless, + default-jdk-headless:native, ant, doxygen, graphviz,
Bug#925525: unblock: glusterfs/5.5-1
Control: tags -1 confirmed moreinfo Hi, On Mon, Apr 08, 2019 at 11:50:50AM +0200, Patrick Matthäi wrote: > Am 06.04.2019 um 13:42 schrieb Ivo De Decker: > > Control: tags -1 moreinfo > > > > Hi, > > > > On Tue, Mar 26, 2019 at 11:33:20AM +0100, Patrick Matthäi wrote: > >> I would like to upload glusterfs 5.5-1 (currently in experimental) to sid > >> and > >> target this release for buster. It is a bugfix only release, also for a > >> regression, and has got small changes: > > You didn't explain what changes are important enough to ask for an unblock. > > Please elaborate. > > > > The diff is small, so it might be suitable. > > > > Cheers, > > > > Ivo > > Hi, > > there are several fixes: > https://docs.gluster.org/en/latest/release-notes/5.5/ > > They also state, that 5.4 was never offical announced, because of the > regressions in it, which prevents rolling upgrades: > https://bugzilla.redhat.com/show_bug.cgi?id=1679968 > https://bugzilla.redhat.com/show_bug.cgi?id=1684569 > https://bugzilla.redhat.com/show_bug.cgi?id=1684385 OK, having some of the info included in those links in the changelog or in the unblock request would have made things a bit easier. That said, it looks like 5.5-1 is acceptable for buster. So please go ahead and do an upload to unstable, and remove the moreinfo tag from this bug once the package is in unstable and built on all relevant architectures. Thanks, Ivo
Bug#926660: Acknowledgement (webfs: "systemctl stop webfs" not working)
the package version is not indicating this: This problem pops up on Debian buster, it was no issue on stretch.
Bug#926673: poppler: CVE-2019-9631: heap overflow in downsample_row_box_filter
Source: poppler Version: 0.71.0-3 Severity: important Tags: patch security upstream Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/736 Hi, The following vulnerability was published for poppler. CVE-2019-9631[0]: | Poppler 0.74.0 has a heap-based buffer over-read in the | CairoRescaleBox.cc downsample_row_box_filter function. 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-9631 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9631 [1] https://gitlab.freedesktop.org/poppler/poppler/issues/736 [2] https://gitlab.freedesktop.org/poppler/poppler/commit/8122f6d6d409b53151a20c5578fc525ee97315e8 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#926672: debbugs: 'bug' parameter is undefined for canonical URIs
Package: debbugs Severity: normal Dear Maintainer, I noticed the HTML source of Bug# pages has the following backtrace on bugs.debian.org:
Bug#926670: CVE-2019-0542
Source: node-xterm Severity: grave Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0542 Cheers, Moritz
Bug#926671: nheko: Unrecognized event id formats cause nheko to crash
Package: nheko
Version: 0.6.3-1
Severity: normal
Control: tags -1 + fixed-upstream
Control: tags -1 + forwarded https://github.com/Nheko-Reborn/mtxclient/issues/3
Dear Maintainer,
because mtxclient has no package in Debian and nheko static-links with
it (Bug#926668), I'm filing this against the nheko package.
The above mentioned version of the package includes an older version of
mtxclient, which does not yet include an upstream patch for preventing a
crash in nheko Reborn in Debian.
The patch to mtxclient is attached. The crash is reproduced in Matrix
room version 3, which as of today is not yet the default room version
and thus doesn't impact the usability of this package too much yet.
Please consider fixing this issue in the package available from Debian,
due to the way mtxclient is currently packaged with nheko.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nheko depends on:
ii libboost-atomic1.67.0 1.67.0-13
ii libboost-chrono1.67.0 1.67.0-13
ii libboost-date-time1.67.0 1.67.0-13
ii libboost-iostreams1.67.0 1.67.0-13
ii libboost-random1.67.0 1.67.0-13
ii libboost-regex1.67.0 1.67.0-13
ii libboost-system1.67.0 1.67.0-13
ii libboost-thread1.67.0 1.67.0-13
ii libc6 2.28-8
ii libcmark0 0.28.3-1
ii libgcc1 1:8.3.0-5
ii liblmdb0 0.9.22-1
ii libolm2 2.2.2+git20170526.0fd768e+dfsg-1+b11
ii libqt5concurrent5 5.11.3+dfsg1-1
ii libqt5core5a 5.11.3+dfsg1-1
ii libqt5dbus5 5.11.3+dfsg1-1
ii libqt5gui55.11.3+dfsg1-1
ii libqt5multimedia5 5.11.3-2
ii libqt5network55.11.3+dfsg1-1
ii libqt5svg55.11.3-2
ii libqt5widgets55.11.3+dfsg1-1
ii libsodium23 1.0.17-1
ii libssl1.1 1.1.1b-1
ii libstdc++68.3.0-5
ii zlib1g1:1.2.11.dfsg-1
Versions of packages nheko recommends:
ii ca-certificates 20190110
nheko suggests no packages.
-- no debconf information
From 67d39691666bcdf3cc660db19ccc0d9941df13fd Mon Sep 17 00:00:00 2001
From: redsky17
Date: Fri, 22 Feb 2019 03:24:14 +
Subject: [PATCH] Fix Room v3 Issue
This at least partially addresses #3. I have a feeling that
additional updates will be needed at some point, but this
fixes the issue where mtxclient would throw an exception for
unrecognized event id formats, which caused nheko to crash.
---
include/mtx/identifiers.hpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/mtx/identifiers.hpp b/include/mtx/identifiers.hpp
index 87acc43..7885885 100644
--- a/include/mtx/identifiers.hpp
+++ b/include/mtx/identifiers.hpp
@@ -90,7 +90,10 @@ parse(const std::string )
identifier.hostname_ = id.substr(parts + 1);
identifier.id_= id;
} else {
-throw std::invalid_argument(id + ": invalid format\n");
+// V3 event ids don't use ':' at all, don't parse them the same way.
+identifier.localpart_ = id;
+identifier.hostname_ = id;
+identifier.id_ = id;
}
return identifier;
Bug#925411: kernel-package: Not suitable for release
Hi, I'm another happy user of make-kpkg. ;-) I've just tested the "make bindeb- pkg" method. I see two drawback: - (minor) I didn't find the way to do the same thing as the "--revision" option. - I see a big advantage of using make-kpkg with dkms. I can keep the kernel sources in a directory (that I update with the incremental patches) and I don't have to install the generated header for dkms to find them as it can use the source directory. My 2 cents, Yannick -- Formatted to fit your screen.
Bug#926669: [RFC] Feature suggestion: extend dpkg-shlibdeps Build-Depends-Package to support multiple package candidates
Package: dpkg
Version: 1.19.4
When parsing "* Build-Depends-Package: " in a symbols file,
dpkg-shlibdeps currently does not appear to support multiple dev
packages listed in this field. This could be useful in cases such the
following:
* Source package "foo" provides "libfoo-c-dev" and
"libfoo-fortran-dev" binary packages with no overlap, along with a
"libfoo-dev" metapackage that depends on both. (This might happen if
a source package transitions from building a single "libfoo-dev"
binary package to building a split set of -dev binary packages, or it
might be done at first release for simple convenience).
* Source package "bar" may have a build-dep that could be satisfied by
only the "libfoo-c-dev" package, while source package "baz" may have a
build-dep that really does need the full "libfoo-dev" package set (or
perhaps "baz" only happens to know about the original, combined
"libfoo-dev" package).
In the current dpkg code, both "bar" and "baz" source packages could
only get accurate dpkg-shlibdeps info if they both specified
"Build-Depends: libfoo-dev (>=[ver])", and source package "foo"
included "* Build-Depends-Package: libfoo-dev" in all package symbols
files. I see no mechanism to allow either "libfoo-c-dev" or
"libfoo-dev" to trigger shlibdeps dependency versioning in this
scenario.
It would be fairly simple to support such a mechanism using one of two
approaches:
1) Extend "* Build-Depends-Package:" to understand multiple (space or
comma-delimited) package names in this field (see attached diff for
PoC code).
2) Add a new meta-info token (such as plural "*
Build-Depends-Packages:") to support the above syntax, without
modifying the existing understanding of singular
"Build-Depends-Package" (this would be trivially different from PoC
code).
Even though my initial PoC took the first approach, I'm favoring the
second approach, because it avoids breaking backwards compatibility.
With the first approach, any package using the new syntax in its
symbols files would completely lose this functionality on dpkg
releases that don't understand the new syntax (unmodded dpkg doesn't
completely fail, but it appears to simply not match anything in
"Build-Depends-Package" if it lists multiple packages). The second
approach allows packagers to take advantage of the new meta-info
without giving up the original meta-info functionality on older dpkg.
--
Frank Schaefer
"If a server crashes in a server farm and no one pings it, does it
still cost four figures to fix?"
--- dpkg-shlibdeps.orig 2019-04-08 12:55:28.649166818 -0500
+++ dpkg-shlibdeps 2019-04-08 12:54:27.777685461 -0500
@@ -435,18 +435,22 @@
foreach my $soname (@sonames) {
# Adjust minimal version of dependencies with information
# extracted from build-dependencies
- my $dev_pkg = $symfile->get_field($soname, 'Build-Depends-Package');
- if (defined $dev_pkg) {
-debug(1, "Updating dependencies of $soname with build-dependencies");
- my $minver = get_min_version_from_deps($build_deps, $dev_pkg);
- if (defined $minver) {
- foreach my $dep ($symfile->get_dependencies($soname)) {
- update_dependency_version($dep, $minver, 1);
-debug(1, " Minimal version of $dep updated with $minver");
+ my $dev_pkg_list = $symfile->get_field($soname, 'Build-Depends-Package');
+ if (defined $dev_pkg_list) {
+ foreach my $dev_pkg (split(/[,\s]+/, $dev_pkg_list)) {
+ if (defined $dev_pkg) {
+ debug(1, "Updating dependencies of $soname with build-dependencies");
+ my $minver = get_min_version_from_deps($build_deps, $dev_pkg);
+ if (defined $minver) {
+ foreach my $dep ($symfile->get_dependencies($soname)) {
+ update_dependency_version($dep, $minver, 1);
+ debug(1, " Minimal version of $dep updated with $minver");
+ }
+ } else {
+ debug(1, " No minimal version found in $dev_pkg build-dependency");
+ }
}
- } else {
-debug(1, " No minimal version found in $dev_pkg build-dependency");
-}
+ }
}
# Warn about un-NEEDED libraries
Bug#914796: sleuthkit: CVE-2018-19497 out of bounds read in Sleuthkit
On Tue, Feb 19, 2019 at 05:39:10PM +0100, Moritz Mühlenhoff wrote: > On Tue, Nov 27, 2018 at 01:38:43PM +0100, Jordy Zomer wrote: > > Package: sleuthkit > > Version: 4.2.0-3 > > Severity: normal > > > > Dear Maintainer, > > > > An issue was discovered in The Sleuth Kit (TSK) through 4.6.4. > > The "tsk_getu16(hfs->fs_info.endian, _buf[rec_off2])" call in > > hfs_dir_open_meta_cb in > > tsk/fs/hfs_dent.c does not properly check boundaries. This results in > > a crash (SEGV on unknown address > > READ memory access) > > when reading too much in the destination buffer. > > > > this is because the boundary check in hfs_traverse_cat wasn't done properly. > > > > The following CVE was assigned (It's still reserved): > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19497 > > Fixed in > https://github.com/sleuthkit/sleuthkit/commit/bc04aa017c0bd297de8a3b7fc40ffc6bb95d *ping*, could we get that into buster still? Cheers, Moritz
Bug#926668: nheko: mtxclient is missing from debian/control output
Source: nheko Severity: important Dear Maintainer, according to the `debian/README.sources` file (see Bug#926659), the sources of mtxclient are included with nheko's source in Debian. The source package doesn't declare to build a mtxclient package in debian/control. What I wanted to do was make an UNRELEASED package for nheko 0.6.3, with a more up-to-date mtxclient dependency (to resolve a bug causing nheko 0.6.3 to crash with Matrix v3 rooms). This dependency does not exist in the Debian tree by itself, but is static-linked with nheko Reborn. What I found was this convoluted and antiqued Standards-Version packaging, which requires running debian/rules make-orig-source and fetching sources from out of the tree. The CMake rules for this project would seem to otherwise download source tarballs from the Internet during the build process. I would also believe mtxclient would be more useful as a standalone package, and the nheko package in Debian should be patched to dynamically link to it, but that's maybe off-topic for this issue. Despite Debian Policy 4.3.0.3 § 4.13 on convenience copies saying it's a "should" and not a "must" to not use the convenience copies, but please consider if this makes the package unsuitable for release in buster (severity serious). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#926667: CVE-2019-10723
Source: libpodofo Severity: important Tags: security This was assigned CVE-2019-10723: https://sourceforge.net/p/podofo/tickets/46/ Cheers, Moritz
Bug#926666: CVE-2019-9718 CVE-2019-9721
Package: ffmpeg Version: 7:4.1.1-1 Severity: important Tags: security https://security-tracker.debian.org/tracker/CVE-2019-9718 https://security-tracker.debian.org/tracker/CVE-2019-9721 Both a fixed in the 4.1.3 release, which also fixes a number of additional issues without a CVE ID. Cheers, Moritz
Bug#920321: lua5.3: CVE-2019-6706
On Thu, Jan 24, 2019 at 07:02:59AM +0100, Salvatore Bonaccorso wrote: > Source: lua5.3 > Version: 5.3.3-1.1 > Severity: important > Tags: security upstream > Control: found -1 5.3.3-1 > > Hi, > > The following vulnerability was published for lua5.3. > > CVE-2019-6706[0]: > | Lua 5.3.5 has a use-after-free in lua_upvaluejoin in lapi.c. For > | example, a crash outcome might be achieved by an attacker who is able > | to trigger a debug.upvaluejoin call in which the arguments have certain > | relationships. Ubuntu fixed this via https://launchpad.net/ubuntu/+source/lua5.3/5.3.3-1ubuntu0.18.10.1 : http://launchpadlibrarian.net/417853567/lua5.3_5.3.3-1_5.3.3-1ubuntu0.18.10.1.diff.gz Leonidas, what's the provenance of that patch (given that upstream doesn't have a public code repo), has it been reviewed/blessed by the Lua upstream developers? Cheers, Moritz
Bug#926664: shim-signed: [INTL:nl] Dutch translation of debconf messages
Package: shim-signed Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of shim-signed debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#926479: [Fwd: [Pkg-swan-devel] Bug#926479: Interesting ..]
Hi, On 08-04-2019 12:03, Yves-Alexis Perez wrote: > Christian replied to me and the bug but not you so in case you're not actively > monitoring the bug I'm forwarding it as well. Thanks, I am not watching the bug indeed. > What is your opinion on the proposal at the end? Perfect solution if the test indeed needs that. If it does, I don't understand why it passes sometimes, as all the workers on ci.d.n should be the same. Maybe the lxc leaks a bit? But this change would be even acceptable for an unblock if it can happen soon (without any other changes). I am seriously wondering if the last test doesn't *also* need a isolation-machine restriction. It seems to me that modprobe isn't available in a linux container. Paul signature.asc Description: OpenPGP digital signature
Bug#926662: neutron-dynamic-routing: [INTL:nl] Dutch translation of debconf messages
Package: neutron-dynamic-routing Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the Dutch translation of neutron-dynamic- routing debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#926663: gnome-control-center: Mouse keys in Universal Access menu stopped working
Package: gnome-control-center Version: 1:3.30.3-1 Severity: normal Tags: a11y Dear Maintainer, in previous versions of Gnome, the Mouse Keys option in the Universal Access menu had the same effect as the old XWindow PointerKeys configuration flag. That is: 1. the arrow labelled keys on the numeric keypad move the pointer 2. the / * - keys select left, middle and right button, respectively 3. the 9, +, 0, and . keys click, doubleclick, press, and release the selected button, respectively. But in this version, *only* 1 above seems to work; the other keys have no effect. This is a big deal a11y - wise; it makes the system nearly unusable for me, because I avoid almost all use of the physical mouse (it gives me RSI). Side notes: a. This is also bug 1689356 in Red Hat bugzilla b. I am aware that this is likely the wrong package for this issue, but I don't know enough about Gnome internals to file against one of the Gnome libraries. Please forward as appropriate. Thanks. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.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 gnome-control-center depends on: ii accountsservice0.6.45-2 ii apg2.2.3.dfsg.1-5 ii colord 1.4.3-4 ii desktop-base 10.0.0 ii desktop-file-utils 0.23-4 ii gnome-control-center-data 1:3.30.3-1 ii gnome-desktop3-data3.30.2.1-1 ii gnome-settings-daemon 3.30.2-3 ii gsettings-desktop-schemas 3.28.1-1 ii libaccountsservice00.6.45-2 ii libatk1.0-02.30.0-2 ii libc6 2.28-8 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libcheese-gtk253.31.90-1 ii libcheese8 3.31.90-1 ii libclutter-1.0-0 1.26.2+dfsg-10 ii libclutter-gtk-1.0-0 1.8.4-4 ii libcolord-gtk1 0.1.26-2 ii libcolord2 1.4.3-4 ii libcups2 2.2.10-5 ii libfontconfig1 2.13.1-2 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgnome-bluetooth13 3.28.2-3 ii libgnome-desktop-3-17 3.30.2.1-1 ii libgoa-1.0-0b 3.30.1-2 ii libgoa-backend-1.0-1 3.30.1-2 ii libgrilo-0.3-0 0.3.7-1 ii libgtk-3-0 3.24.5-1 ii libgtop-2.0-11 2.38.0-4 ii libgudev-1.0-0 232-2 ii libibus-1.0-5 1.5.19-4 ii libkrb5-3 1.17-2 ii libmm-glib01.10.0-1 ii libnm0 1.14.6-2 ii libnma01.8.20-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-01.42.4-6 ii libpolkit-gobject-1-0 0.105-25 ii libpulse-mainloop-glib012.2-4 ii libpulse0 12.2-4 ii libpwquality1 1.4.0-3 ii libsecret-1-0 0.18.7-1 ii libsmbclient 2:4.9.5+dfsg-2 ii libsoup2.4-1 2.64.2-2 ii libupower-glib30.99.10-1 ii libwacom2 0.32-1 ii libwayland-server0 1.16.0-1 ii libx11-6 2:1.6.7-1 ii libxi6 2:1.7.9-1 ii libxml22.9.4+dfsg1-7+b3 Versions of packages gnome-control-center recommends: pn cracklib-runtime ii cups-pk-helper0.2.6-1+b1 ii gkbd-capplet 3.26.1-1 ii gnome-online-accounts 3.30.1-2 ii gnome-user-docs 3.30.2-1 ii gnome-user-share 3.28.0-2 ii iso-codes 4.2-1 ii libcanberra-pulse 0.30-7 pn libnss-myhostname pn mousetweaks ii network-manager-gnome 1.8.20-1 ii policykit-1 0.105-25 ii pulseaudio-module-bluetooth 12.2-4 pn realmd ii rygel 0.36.2-4 ii rygel-tracker 0.36.2-4 ii system-config-printer-common 1.5.11-4 Versions of packages gnome-control-center suggests: ii gnome-software 3.30.6-5 ii gstreamer1.0-pulseaudio 1.14.4-1 pn libcanberra-gtk-module pn libcanberra-gtk3-module ii x11-xserver-utils7.7+8 -- no debconf information
Bug#926661: ucf: [INTL:nl] Dutch translation of debconf messages
Package: ucf Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of ucf debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#923478: initscripts use unsafe `: >` shell command to create files
On Mon, 8 Apr 2019, Dmitry Bogatov wrote: > [2019-04-07 10:52] Cristian Ionescu-Idbohrn > > > On Sat, 6 Apr 2019, Dmitry Bogatov wrote: > > > > The redirection in /etc/init.d/bootmisc.sh on line 29 is _not_ error > > handled. Writing to a file can fail (for various reasons). > > > > OTOH, the redirection in /lib/init/bootclean.sh on line 22 _is_ error > > handled. > > Good catch. Mind to send a patch into a separate bug? Sure. So, what do you want it to do when truncating /var/run/utmp fails? 29 : > /var/run/utmp 30 if grep -q ^utmp: /etc/group 31 then 32 chmod 664 /var/run/utmp 33 chgrp utmp /var/run/utmp 34 fi Cheers, -- Cristian
Bug#926657: [Pkg-openldap-devel] Bug#926657: openldap: slapd process failure is not detected by systemd
Hi Heitor, Thanks for reporting this, and also for posting your detailed notes on the LP ticket. (For posterity: https://bugs.launchpad.net/bugs/1821343) I was about to merge this with #877512, but if you are going with the override drop-in solution, I would be happy to adopt that in Debian as well to mitigate this specific issue until I get a full native service file developed. Thanks for helping out with openldap! :)
Bug#926660: webfs: "systemctl stop webfs" not working
Package: webfs Version: 1.21+ds1-12 Severity: important Dear Maintainer, webfs keeps running, even though it should be stopped. After a systemctl stop webfs syslog shows: Apr 8 17:27:38 hostname webfs[13111]: Stopping httpd daemon: webfsdstart-stop-daemon: matching only on non-root pidfile /var/run/webfs/webfsd.pid is insecure Apr 8 17:27:38 hostname webfs[13111]: failed! Apr 8 17:27:38 hostname systemd[1]: webfs.service: Succeeded. Apr 8 17:27:38 hostname systemd[1]: Stopped LSB: Webfs simple HTTP server. systemd refuses to kill the webfsd pid because the PID file is owned by non-root user. After those syslog messages, webfsd keeps running. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.114-vs2.3.9.7 (SMP w/2 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 /bin/dash Init: sysvinit (via /sbin/init) Versions of packages webfs depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-8 ii libgnutls303.6.6-2 ii lsb-base 10.2019031300 ii ucf3.0038+nmu1 webfs recommends no packages. webfs suggests no packages.
Bug#926475: Review + debdiff
Am Sonntag, den 07.04.2019, 15:26 +0200 schrieb Stefan Potyra:
> Hi Bruno,
>
> On Sat, Apr 06, 2019 at 04:56:29AM +0200, Bruno Kleinert wrote:
> > Hi Stefan,
> >
> > that's great! I offer reviews and will sponsor uploads :)
>
> cool, thanks for the offer :).
>
> Preliminary package available:
> dget http://potyra.de/dlt-viewer/dlt-viewer_2.18.0+dfsg-1.dsc
>
> Please give it a thourough review. It's been some time since I last created a
> package...
>
> Cheers,
> Stefan.
Hi Stefan,
I only had minor improvements, see attached debdiff. Those include:
* Set debhelper compatibility level by build dependency magic.
* Update the .desktop file patch to remove a broken line and add
another category for the tool.
* Override lintian warning for source tarball repack and provide a
rationale.
I *think* the "Copyright (c)" part is redundant in debian/copyright and
could possibly be removed from lines 27-32.
Cheers - Bruno
diff -Nru dlt-viewer-2.18.0+dfsg/debian/compat dlt-viewer-2.18.0+dfsg/debian/compat
--- dlt-viewer-2.18.0+dfsg/debian/compat 2019-04-06 14:15:24.0 +0200
+++ dlt-viewer-2.18.0+dfsg/debian/compat 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-12
diff -Nru dlt-viewer-2.18.0+dfsg/debian/control dlt-viewer-2.18.0+dfsg/debian/control
--- dlt-viewer-2.18.0+dfsg/debian/control 2019-04-07 14:38:26.0 +0200
+++ dlt-viewer-2.18.0+dfsg/debian/control 2019-04-07 14:38:26.0 +0200
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Stefan Potyra
Uploaders: Bruno "Fuddl" Kleinert
-Build-Depends: debhelper (>= 12),
+Build-Depends: debhelper-compat (= 12),
qtbase5-dev,
qtdeclarative5-dev,
libqt5serialport5-dev,
@@ -18,7 +18,7 @@
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Viewer for GENIVI DLT traces
The Diagnostic Log and Trace Viewer is an application that can send and
- receive control messages to the DLT daemon, e.g. to set individual log
+ receive control messages to the DLT daemon, e.g., to set individual log
levels of applications and contexts or get the list of applications
and contexts registered in the DLT daemon.
@@ -27,7 +27,7 @@
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Viewer for GENIVI DLT traces - development files
The Diagnostic Log and Trace Viewer is an application that can send and
- receive control messages to the DLT daemon, e.g. to set individual log
+ receive control messages to the DLT daemon, e.g., to set individual log
levels of applications and contexts or get the list of applications
and contexts registered in the DLT daemon.
.
diff -Nru dlt-viewer-2.18.0+dfsg/debian/patches/02_fix_desktop_file.patch dlt-viewer-2.18.0+dfsg/debian/patches/02_fix_desktop_file.patch
--- dlt-viewer-2.18.0+dfsg/debian/patches/02_fix_desktop_file.patch 2019-04-07 14:38:26.0 +0200
+++ dlt-viewer-2.18.0+dfsg/debian/patches/02_fix_desktop_file.patch 2019-04-07 14:38:26.0 +0200
@@ -3,14 +3,20 @@
Author: Stefan Potyra
Forwarded: no
dlt-viewer-2.18.0+dfsg.orig/src/dlt_viewer.desktop
-+++ dlt-viewer-2.18.0+dfsg/src/dlt_viewer.desktop
-@@ -3,7 +3,7 @@ Type=Application
+Index: dlt-viewer-2.18.0+dfsg/src/dlt_viewer.desktop
+===
+--- dlt-viewer-2.18.0+dfsg.orig/src/dlt_viewer.desktop 2019-04-08 19:10:07.038029821 +0200
dlt-viewer-2.18.0+dfsg/src/dlt_viewer.desktop 2019-04-08 19:17:21.299174475 +0200
+@@ -1,9 +1,8 @@
+ [Desktop Entry]
+ Type=Application
Name=DLT Viewer
- Name[xx]=Diagnostic Log and Trace Viewer
- GenericName=DLT Viewer - Diagnostic Log and Trace Viewer needed for devices running DLT daemon
+-Name[xx]=Diagnostic Log and Trace Viewer
+-GenericName=DLT Viewer - Diagnostic Log and Trace Viewer needed for devices running DLT daemon
-Exec=dlt_viewer %u
++GenericName=Diagnostic Log and Trace Viewer needed for devices running DLT daemon
+Exec=dlt-viewer %u
Icon=face-glasses
Terminal=false
- Categories=Qt;KDE;Development;
+-Categories=Qt;KDE;Development;
++Categories=Qt;KDE;Development;System;
diff -Nru dlt-viewer-2.18.0+dfsg/debian/source/lintian-overrides dlt-viewer-2.18.0+dfsg/debian/source/lintian-overrides
--- dlt-viewer-2.18.0+dfsg/debian/source/lintian-overrides 1970-01-01 01:00:00.0 +0100
+++ dlt-viewer-2.18.0+dfsg/debian/source/lintian-overrides 2019-04-07 14:38:26.0 +0200
@@ -0,0 +1,2 @@
+# Rationale is documented in debian/README.source
+dlt-viewer source: missing-explanation-for-repacked-upstream-tarball
signature.asc
Description: This is a digitally signed message part
Bug#926659: nheko: Wrong debian/README.source filename
Source: nheko Severity: minor Dear Maintainer, I believe the file `debian/README.sources` should be renamed to `debian/README.source` accordingly with Debian policy v4.3.0.3 § 4.14. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#925399: zim: Window dialog become oversized for long paths
On 25/03/2019 11:23, Raphael Hertzog wrote: Hello, On Sun, 24 Mar 2019, Emmanuel Chantréau wrote: ... Can you share with us the current name of the page being renamed so that we get an idea of how long it was? The complet path (which zim try to print in one line) is : Recherche:5 Vérif types:4 Définir extensions:1 Par mot clé et déduction d'ajout et d'application:3 Traduction sans hypothèse:Règle du tiers exclu:Toute vérité se calcule en une égalité:Théorème =c est une relation d'équivalence:Théorème de jonction des sous-calculs:Théorème de la ligne de destins en univocal Also can you try with zim 0.70~rc3-1 from experimental? It's rewritten using python3 and Gtk3, and given the big change in the graphical toolkit, it's worth ensuring that the problem also exists in that version before reporting the bug to upstream. Done, I installed a virtual box with zim Version : 0.70~rc3-1. The bug is unchanged. You can get the zim document : git clone https://framagit.org/emmchan/lazi.git He is in the "wiki" directory. Cheers, Thank you for your work! -- Emmanuel Chantréau
Bug#926658: gnuplot: free(): double free detected in tcache 2
Source: gnuplot Version: 5.2.6+dfsg1-1 Severity: important Hi, After upgrading lindsay.d.o to buster, we see errors when trying to generate graphs of the tags. While trying to create a minimal reproducer I tripped a double free bug in gnuplot. The following steps were done to reproduce the issue: """ $ unzip test-files.zip $ cd test-files test-files$ gdb -args gnuplot call.gp [...] (gdb) run Starting program: /usr/bin/gnuplot call.gpi [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Plotting $tag statistics... "./tags.gpi" line 27: undefined variable: date_min free(): double free detected in tcache 2 Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x778c6535 in __GI_abort () at abort.c:79 #2 0x7791d778 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x77a2828d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x77923e6a in malloc_printerr (str=str@entry=0x77a29f58 "free(): double free detected in tcache 2") at malloc.c:5341 #4 0x7792594d in _int_free (av=0x77a5fc40 , p=0x556eb250, have_lock=) at malloc.c:4193 #5 0x5558d71d in gpfree_string (a=0x556e9828) at .././../../src/eval.c:423 #6 0x5558dbcb in gpfree_string (a=) at .././../../src/eval.c:422 #7 gpfree_array (a=a@entry=0x556e9860) at .././../../src/eval.c:446 #8 0x555be5a7 in lf_pop () at .././../../src/misc.c:515 #9 0x555bebad in load_file_error () at .././../../src/misc.c:626 #10 0x5556e8e5 in main (argc=2, argv=0x7fffe178) at .././../../src/plot.c:555 (gdb) quit """ Note: The test files *are* invalid - the common.gpi file should define some variables but it does not (e.g. date_min). Nonetheless, gnuplot should not trip a double-free regardless of whether the input is valid or not. Relevant versions of gnuplot used for reproducing this: """ $ dpkg -l | grep gnuplot ii gnuplot-data 5.2.6+dfsg1-1 all Command-line driven interactive plotting program. Data-files ii gnuplot-nox 5.2.6+dfsg1-1 amd64Command-line driven interactive plotting program. No-X package ii gnuplot-nox-dbgsym 5.2.6+dfsg1-1 amd64debug symbols for gnuplot-nox """ Thanks, ~Niels
Bug#926657: openldap: slapd process failure is not detected by systemd
Package: openldap Severity: normal Dear Maintainer, The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal.
Bug#926543: lintian: Deadlock in source-copyright check on source:khronos-opencl-man/1.0~svn33624-4
Niels Thykier:
> Niels Thykier:
>> Niels Thykier:
>>> Package: lintian
>>> Version: 2.9.1
>>> Severity: important
>>>
>>> Hi,
>>>
>>> Discovered in the archive-wide run on lindsay.d.o; lintian does not
>>> terminate when run on khronos-opencl-man/1.0~svn33624-4 (source).
>>>
>>> Thanks,
>>> ~Niels
>>>
>>
>> For reference, I used the following command line to confirm it on lindsay:
>>
>> lintian -EvIL +pedantic -j2 -ddd \
>> /srv/mirrors/debian/pool/main/k/khronos-opencl-man/*33624*.{deb,dsc}
>>
>> I.e. I ran it with source and binaries available (didn't check of the
>> source alone was enough to trigger the issue..
>>
>> Thanks,
>> ~Niels
>>
>
> The source package is enough to reproduce it but I cannot reproduce it
> on buster. It has to be stretch or older; this implies that the
> underlying issue might have been fixed in a dependency (presumably
> IPC::Run).
>
> Thanks,
> ~Niels
>
lindsay.debian.org has been upgraded to buster but the problem still
persist. I reproduced it today with 2.12.0 (git checkout).
Thanks,
~Niels
Bug#923476: webkit2gtk: FTBFS for unknown reasons (maybe Makefile bug)
On Mon, Apr 08, 2019 at 06:02:41PM +0200, Santiago Vila wrote: > On Fri, Mar 08, 2019 at 05:40:01AM -0500, Jeremy Bicha wrote: > > On Fri, Mar 8, 2019 at 4:03 AM Alberto Garcia wrote: > > > For Debian the change is very simple (apply the patch to use > > > cmake+ninja to the unstable branch), are we still on time to upload > > > this? In any case I'd wait until 2.22.7-1 reaches buster first, it has > > > important fixes. > > > > Since 2.22 is unsupportable for Buster (upstream will stop supporting > > it this month), we'll be filing an unblock request for 2.24 after it's > > released next week. > > So: Can we expect to see 2.24 in buster, given the unsupportable > status of 2.22? (If you need to talk with RM, please do so). I plan to upload it to unstable this week (2.24.1 is about to be released). Berto
Bug#923476: webkit2gtk: FTBFS for unknown reasons (maybe Makefile bug)
On Fri, Mar 08, 2019 at 05:40:01AM -0500, Jeremy Bicha wrote: > On Fri, Mar 8, 2019 at 4:03 AM Alberto Garcia wrote: > > For Debian the change is very simple (apply the patch to use > > cmake+ninja to the unstable branch), are we still on time to upload > > this? In any case I'd wait until 2.22.7-1 reaches buster first, it has > > important fixes. > > Since 2.22 is unsupportable for Buster (upstream will stop supporting > it this month), we'll be filing an unblock request for 2.24 after it's > released next week. So: Can we expect to see 2.24 in buster, given the unsupportable status of 2.22? (If you need to talk with RM, please do so). Thanks.
Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed
Thanks for the update on this. It would be a shame to drop the package entirely from Debian. Have had a look at the packaging on salsa and I'm happy to take over. I would need DM permissions on it to make uploads. Cheers, Ana
Bug#374039: #374039 shutdown -h -H: warn that then cannot poweroff perhaps
On 4/8/19 12:38 PM, Dmitry Bogatov wrote: > control: tags -1 +upstream > > [ Please keep attribution ] > > [2019-04-07 11:12] Jesse Smith >> >> That is what halt means - to stop running the system without powering >> off. > Maybe, but many of us are accustomed that /sbin/halt turns off the computer, > so here comes confusion. That is certainly true, but I'd like to point out that /sbin/halt only turns off the computer because Debian modifies halt's behaviour. If you run /sbin/halt without Debian's modifications, the traditional action (stop without powering off) occurs. I'd almost consider this a bug since /sbin/halt should be used to stop the system while /sbin/poweroff should be used to, well, turn off the power to the system. >> Halting is often used to run through the shutdown process and leave >> output on the screen for debugging purposes. Or when you want the OS to >> stop, but leave the power on. There is no negative side-effect to using >> the -H option, no loss of data. There isn't any reason to print an extra >> warning. > Okay, what about including this explanation into manpage? I know, Unix > is about sharp tools, but before I started working on sysvinit, I > believed, that "halt == turn-off", so extra explanation, that it is > different things would be nice to user. I'm in favour of this change and can expand on the explanation in the manual page for the next release.
Bug#926474: [Pkg-samba-maint] Bug#926474: smbclient: Can browse samba shares as root but not as user
Installed winbind (and then also iibpam-winbind, iibnss-winbind) : no change on smbtree output command. The warning about "messaging context" is always there in the first line, followed either by nothing, or by only the remote (win xp) shares, or by the complete list of shares. The behaviour is quite random and could not grasp under which conditions I get one or the other situation. Once the complete list has appeared after a long time (some 5 -10 min.). When the local (buster) shares are not shown, I cannot browse them from win xp, otherwise I can do that flawlessly. However, now I realized an unexpected outcome 1) running Dolphin as user, opening /Network/Shared Folders (SMB) I get an empty window 2) addressing Dolphin to open smb://casa(=workgroup) I get the error warning "Internal Error Please send a full bug report at http://bugs.kde.org Unknown error condition in stat: File exists" or instead, going to smb://(user)@(workgroup), i get "Internal Error Please send a full bug report at http://bugs.kde.org libsmbclient reported an error, but did not specify what the problem is. This might indicate a severe problem with your network - but also might indicate a problem with libsmbclient. If you want to help us, please provide a tcpdump of the network interface while you try to browse (be aware that it might contain private data, so do not post it if you are unsure about that - you can send it privately to the developers if they ask for it)" 3) but if I address Dolphin to directly go to smb://(remote host) or smb://(user)@(remote host) then - after being requested and giving the password - I CAN ACCESS the remote shares, and, as far as I could see, I can fully operate r/w as allowed in smb.conf. Same for the local shares. Even more surprisingly (it seems that) I can access local and remote shares INDEPENDENTLY from whether smbtree lists them or not. Given the invitation above to submit a tcpdump report, I installed wireshark and took a dump for each of the cases above, together with a snapshot of Dolphin in/out put, and I am available to submit them privately if of interest. Finally, allow me to ask what "messaging context" is? which process is supposed to activate that? Thanks for attention and kind regards
Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-07 10:52] Cristian Ionescu-Idbohrn > On Sat, 6 Apr 2019, Dmitry Bogatov wrote: > > [2019-04-05 11:11] Cristian Ionescu-Idbohrn > > > > > Thing is neither the `:' nor the `true' commands are needed. To > > > truncate a file it's sufficient to redirect _nothing_ to that file. > > > > > >$ dash -c '>/tmp/dir/; echo $?; echo hello world;' > > > dash: 1: cannot create /tmp/dir/: Is a directory > > > 2 > > > hello world > > > > Nice to know. Is this behaviour mandated by posix? > > Not in so many words, but it doesn't say there _must_ be input to > redirect to stdout or stderr. > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07 > > "The overall format used for redirection is: > > [n]redir-op word" > > (nothing about input). dash, bash, busybox ash work fine, but not zsh > (it's waiting for input). > > I've been using these redirections for many, many years without any > ill effects: > > >file # truncate or create > >>file # `touch' or create > > > > The real problem is that a failing redirection is _not_ error handled > > > (in the /etc/init.d/bootmisc.sh case). > > > > Sorry, failed to parse. You seems to tell, that there is another problem > > in 'bootmisc.sh', but I do not understand, which one. > > The redirection in /etc/init.d/bootmisc.sh on line 29 is _not_ error > handled. Writing to a file can fail (for various reasons). > > OTOH, the redirection in /lib/init/bootclean.sh on line 22 _is_ error > handled. Good catch. Mind to send a patch into a separate bug? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#374039: #374039 shutdown -h -H: warn that then cannot poweroff perhaps
control: tags -1 +upstream [ Please keep attribution ] [2019-04-07 11:12] Jesse Smith > > Halt action is to halt or drop into boot monitor on systems that > > support it." is not enough to convey, that in many cases it brings > > machine into state, when it is still on, display still showing > > letters, but no interation (except physical poweroff) is possible. > > That is what halt means - to stop running the system without powering > off. Maybe, but many of us are accustomed that /sbin/halt turns off the computer, so here comes confusion. > > "Maybe -H is actually produces useful behaviour in some cases (no > > idea), but please add into manpage warning like "Do not use -H option, > > unless you really know what are you doing." > > Halting is often used to run through the shutdown process and leave > output on the screen for debugging purposes. Or when you want the OS to > stop, but leave the power on. There is no negative side-effect to using > the -H option, no loss of data. There isn't any reason to print an extra > warning. Okay, what about including this explanation into manpage? I know, Unix is about sharp tools, but before I started working on sysvinit, I believed, that "halt == turn-off", so extra explanation, that it is different things would be nice to user. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926545: startpar: option -v is not present in manual
control: tags -1 +fixed-upstream [2019-04-06 17:23] Jesse Smith > > Manual page startpar(8) does not mention `-v' (version) option, while > > it is present > > Agreed. I have added the -v flag to the startpar manual page. Good. Thank you. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#925314: unblock: wordpress/5.0.3+dfsg1-1
Control: tags -1 confirmed
Hi,
On Sun, Mar 24, 2019 at 09:31:11AM +1100, Craig Small wrote:
> Hi,
> Attached is a debdiff between 5.0.3 to 5.04 which is essentially the
> changesets I previously reference from the upstream SVN repository.
>
> Option 1 is my preference, the main difference between #1 and #2 was the
> changelog version.
Please go ahead with the upload of 5.0.4+dfsg1-1 ("option 1"), but set the
distribution to "buster" instead of "testing-proposed-updates".
Remove the moreinfo tag from this bug once the upload is in t-p-u.
Thanks,
Ivo
P.S. In the future, please try to avoid uploading new upstream versions to
unstable that might not be suitable for testing.
Bug#920139: sddm: GTK and GNOME: Applications won't launch due error of glib2
Hello Adrian, > I don't have any of those old GNOME applications installed, you mentioned. Then these files should not be there I guess like e.g.: /usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml On a system where e.g. easytag is installed a 'dpkg -S' returns this: $ dpkg -S /usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml easytag: /usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml However, if you suspect something of the environment may be wrong, you could try this: - login through sddm env | sort > /home/user/env-enlightment.txt - login through another login manager env | sort > /home/user/env-other.txt - compare: diff -Nurp /home/user/env-other.txt /home/user/env-enlightment.txt - then you may search if GSETTINGS_SCHEMA_DIR in the differences shown. - or set the different variables one by one in a terminal by export VAR=value (call from there one of the crashing programs) and check if that changes behaviour. Kind regards, Bernhard
Bug#926616: Fwd: Bug#926650 closed by Ivo De Decker (unblock node-deep-extend)
node-deep-extend 0.4.1-2 is unblocked
Message transféré
Sujet : Bug#926650 closed by Ivo De Decker
(unblock node-deep-extend)
Date : Mon, 08 Apr 2019 14:36:04 +
De : Debian Bug Tracking System
Répondre à : 926...@bugs.debian.org
Pour : Xavier Guimard
This is an automatic notification regarding your Bug report
which was filed against the release.debian.org package:
#926650: unblock: node-deep-extend/0.4.1-2
It has been closed by Ivo De Decker .
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 Ivo De Decker
by
replying to this email.
--
926650: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926650
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Unblocked node-deep-extend.
--- End Message ---
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package node-deep-extend
Hi all,
node-deep-extend is vulnerable to CVE-2018-3750 [1]. This vulnerability
has been tagged as unimportant, however patch is simple and package is
outdated (VCS fields, bad section, bad copyright years) and upstream tests
were not enabled. I fixed this in version 0.4.1-2. Here is the full changes:
* Add patch to prevent Object prototype pollution
(Closes: #926616, CVE-2018-3750)
* Enable upstream tests using pkg-js-tools
* Fix VCS fields
* Fix debian/copyright years
* Add upstream/metadata
* Change section to javascript
node-deep-extend has no build reverse dependencies.
Reverse dependencies:
node-rc
node-registry-url & node-registry-auth-token
node-package-json
node-latest-version
npm
npm2deb
node-pre-gyp
node-sqlite3
node-mbtiles
node-tilejson
node-millstone
node-zipfile
node-millstone
node-mapnik
node-tilelive-bridge
node-tilelive-vector
node-tilelive-mapnik
node-opencv
Since patch seems to have no consequences on normal node-deep-extend
usage, I think it is low risky to unblock node-deep-extend.
Patch comes from
https://github.com/unclechu/node-deep-extend/commit/9423fae877e2ab6b4aecc4db79a0ed63039d4703
(I just taked the useful part of it).
Cheers,
Xavier
[1]: https://security-tracker.debian.org/tracker/CVE-2018-3750
unblock node-deep-extend/0.4.1-2
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 5b0e688..e4e0c2e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,18 @@
+node-deep-extend (0.4.1-2) unstable; urgency=medium
+
+ * Team upload
+ * Add patch to prevent Object prototype pollution
+(Closes: #926616, CVE-2018-3750)
+ * Enable upstream tests using pkg-js-tools
+ * Fix VCS fields
+ * Fix debian/copyright years
+ * Add upstream/metadata
+ * Change section to javascript
+
+ -- Xavier Guimard Mon, 08 Apr 2019 14:52:06 +0200
+
node-deep-extend (0.4.1-1) unstable; urgency=medium
- * Initial release
+ * Initial release
-- Thorsten Alteholz Mon, 22 Feb 2016 18:16:21 +0100
-
diff --git a/debian/control b/debian/control
index 72892ea..4db1cb8 100644
--- a/debian/control
+++ b/debian/control
@@ -1,22 +1,24 @@
Source: node-deep-extend
-Section: web
-Priority: optional
Maintainer: Debian Javascript Maintainers
Uploaders: Thorsten Alteholz
-Build-Depends:
- debhelper (>= 9)
- , dh-buildinfo
- , nodejs
-Standards-Version: 3.9.7
+Section: javascript
+Testsuite: autopkgtest-pkg-nodejs
+Priority: optional
+Build-Depends: debhelper (>= 9),
+ dh-buildinfo,
+ mocha,
+ nodejs,
+ node-should,
+ pkg-js-tools
+Standards-Version: 4.3.0
+Vcs-Browser: https://salsa.debian.org/js-team/node-deep-extend
+Vcs-Git: https://salsa.debian.org/js-team/node-deep-extend.git
Homepage: https://github.com/unclechu/node-deep-extend
-Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-deep-extend.git
-Vcs-Browser:
https://anonscm.debian.org/gitweb/?p=pkg-javascript/node-deep-extend.git
Package: node-deep-extend
Architecture: all
-Depends:
- ${misc:Depends}
- , nodejs
+Depends: ${misc:Depends},
+ nodejs
Description: Recursive object extending
This module does a recursive object extending.
.
diff --git a/debian/copyright b/debian/copyright
index 28c1d90..a1f8541 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,14 +1,14 @@
Bug#925265: unblock: ntp/1:4.2.8p12+dfsg-4 or ntp/1:4.2.8p13+dfsg-2 (pre-approval)
Control: tags -1 confirmed moreinfo Hi, On Fri, Mar 22, 2019 at 12:11:29AM +0100, Bernhard Schmidt wrote: > The other option would be to only backport the fix for CVE-2019-8936 and > upload > -4. > > While processing this I discovered three small commits sitting in the master > branch that had not been uploaded yet. They could be backed out if you want > to. > They fix important Bug#772790, normal Bug#764546 and remove a leftover from > the > locking that used to be in place to prevent a race between ntpd and the > ntpdate > ifupdown hooks. The ifupdown hooks have been removed since September, so the > locking is not necessary anymore. > > Please tell me what you want me to upload > > a) 1:4.2.8p13+dfsg-1 currently in experimental (as -2) > b) 1:4.2.8p13+dfsg-1 currently in experimental (as -2), but with some/all not >previously uploaded changes to debian/ dropped > c) 1:4.2.8p12+dfsg-4 containing only the CVE fix > d) 1:4.2.8p12+dfsg-4 containing the CVE fix and some/all not previously > uploaded >changes to debian/ Both option c or d sound ok. Options a and b really don't sound like something we should do at this point. So please go ahead with the 1:4.2.8p12+dfsg-4 upload and remove the moreinfo tag from this bug once the package is in unstable. Thanks, Ivo
Bug#926656: git-debrebase docs are intimidating
Package: git-debrebase Version: 8.4 Sam Hartman wrote the following me in private email. It is a apposite (and sadly hilarious) critique of the documentation. I am filing it here as a bug, with permission. Ian. -8<- From: Sam Hartman To: Ian Jackson Subject: Re: git debrebase is cool Date: Sat, 06 Apr 2019 13:01:57 -0400 > "Ian" == Ian Jackson writes: Ian> Did you see dgit-maint-debrebase(7) ? No. I'll read it, but before doing so I'll respond with my user hat on: 1) I want to learn about git-debrebase, not about dgit. Dgit is really scary and I'm told this thing is better than gbp pq. 2) I started with git-debrebase (1) It told me I needed to read git-debrebase(5) before I had any hope of understanding it. So I went and looked up how to look at a man 5 page when there is also a man 1 page (OK, I as Sam actually already knew this), and with great trepidation stopped reading git-debrebase to read this other thing. 3) I started to see a reference to one of those terms from git-debrebase (1) (anchor), but it tricked me and was just a cross reference to a detailed branch specification. I don't want to learn a detailed specification of anything just to go update my patch. Is this going to be like that time when my friend told me git grafts could solve that mismerge problem I had and I ended up trying to understand the gitrepository man page? 4) Then there are diagrams of merge histories. Wait, this is starting to remind me of the git-rebase man page that I never understood. O, wait, rebase is in the name. This is not good! And then there is all this illegal operations stuff!!! Help! 5) Eventually come back to the git-debrebase man page. Wait this really isn't so bad. I think I might kind of understand things. Except I totally don't know how to manage my orig tarballs, or my upstream tags or anything. I guess I can use gbp for that, but then why don't I use gbp for everything. To be clear, I appreciate the detailed documentation, data model and description of invarients. I did find it took me a lot longer to go through than the gbp documentation, but I'm the kind of person who found this detail helpful. But in contranst gbp-pq mentions rebase once. It allows the user to think they are not going to need to understand any of the more complex git stuff, where as git-debrebase tells you right there that rebase -i might be something you want to do often. And yeah, you and I probably do want to rebase -i quite often. But there are a lot of people who never understand git that well. I don't have a handle on the skill of the average DD nor what the tail looks like. When I joined Debian, the developers I interacted with were all fairly skilled. And yet watching discussion of git, git-dpm and dgit in #debian-devel, I think a lot of people find them beyond their comfort level. I don't know what the answer is. I don't even know for sure this is a problem. I know I want to be in a world where I get to be using tools like git-debrebase or git-dpm. I would rather live in a world where we all use gbp pq than where we never get to anything uniform, but that would not be my first choice. -8<- -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#926653: openssh-server: Locked out of server after upgrading to buster.
Control: reassign -1 release-notes Control: merge 926613 -1 On Mon, Apr 08, 2019 at 02:31:36PM +0100, Sam Bull wrote: > Due to a change in how some options are handled in sshd_config, upgrading to > buster can result in the user getting locked out of their system if the config > is not updated. You already filed this bug and I already responded to it, so I'm merging the duplicate. -- Colin Watson [cjwat...@debian.org]
Bug#779893: ipfs in Debian
Help is welcomed ! Some of those packages are already in pkg-go salsa repo, but I haven't gotten a chance to work on it since a few months so feel free to pick it back up ! On 8 April 2019 8:39:54 AM GMT-03:00, mer...@debian.org wrote: >Hello, > >bringing ipfs in Debian requires packaging lots of dependencies: > >$ dh-make-golang estimate github.com/ipfs/go-ipfs >2019/04/08 07:31:22 Bringing github.com/ipfs/go-ipfs to Debian requires >packaging the following Go packages: >github.com/ipfs/go-ipfs-addr > github.com/ipfs/go-log > github.com/whyrusleeping/go-logging > github.com/libp2p/go-libp2p-peer > github.com/libp2p/go-libp2p-crypto > github.com/btcsuite/btcd > github.com/multiformats/go-multihash > github.com/gxed/hashland > github.com/mr-tron/base58 > github.com/multiformats/go-multiaddr >github.com/ipfs/go-ipfs-blockstore > github.com/ipfs/bbloom > github.com/ipfs/go-cid > github.com/multiformats/go-multibase > github.com/multiformats/go-base32 > github.com/ipfs/go-ipfs-ds-help > github.com/ipfs/go-datastore > github.com/jbenet/goprocess > github.com/ipfs/go-metrics-interface > github.com/ipfs/go-block-format > github.com/ipfs/go-ipfs-util >github.com/ipfs/go-ipfs-blocksutil >github.com/ipfs/go-ipfs-chunker > github.com/libp2p/go-buffer-pool > github.com/whyrusleeping/chunker >github.com/ipfs/go-ipfs-cmdkit >github.com/ipfs/go-ipfs-cmds > github.com/ipfs/go-ipfs-files > github.com/texttheater/golang-levenshtein > github.com/Kubuxu/go-os-helper > github.com/rs/cors >github.com/ipfs/go-ipfs-config > github.com/multiformats/go-multiaddr-dns >github.com/ipfs/go-ipfs-delay >github.com/ipfs/go-ipfs-exchange-interface >github.com/ipfs/go-ipfs-exchange-offline >github.com/ipfs/go-ipfs-flags >github.com/ipfs/go-ipfs-posinfo > github.com/ipfs/go-ipld-format > >(2/3 of the output stripped for brevity). > >Nevertheless, I am willing to help, starting from the bottom :) [1] > >Best, >Andrius > >[1] >https://ftp-master.debian.org/new/golang-github-minio-blake2b-simd_0.0~git20160723.3f5f724-1.html > >-- >Andrius Merkys >Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room >V325 >LT-10257 Vilnius, Lithuania -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#926654: tinc: Fails to parse '::' in IPv6-address
Package: tinc Version: 1.0.35-2 Severity: normal Dear Maintainer, if the Subnet in /etc/tinc//hosts/ contains '::' then TINC does not parse it correctly. bad: /etc/tinc/cluster/hosts/nyorobo Subnet = fd00:610:1410:ae2e:23f0:c936::50 # service restart tinc && pkill -USR2 tincd /var/log/syslog: Apr 8 15:57:08 nyorobo tincd[1427]: Subnet list: Apr 8 15:57:08 nyorobo tincd[1427]: 0:10:10:2e:f0:36#10 owner nyorobo good: /etc/tinc/cluster/hosts/nyorobo Subnet = fd00:610:1410:ae2e:23f0:c936:0:50 # service restart tinc && pkill -USR2 tincd /var/log/syslog: Apr 8 15:58:08 nyorobo tincd[1747]: Subnet list: Apr 8 15:58:08 nyorobo tincd[1747]: fd00:610:1410:ae2e:23f0:c936:0:50/128#10 owner nyorobo Both ways of writing this Subnet-address should give the same result. -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages tinc depends on: ii init-system-helpers 1.56+nmu1 ii libc62.28-8 ii liblzo2-22.10-0.1 ii libssl1.11.1.1b-1 ii lsb-base 10.2019031300 ii zlib1g 1:1.2.11.dfsg-1 tinc recommends no packages. tinc suggests no packages. -- no debconf information
Bug#147164: ping and new proposal
> On Mon, 8 Apr 2019 16:54:21 +0300, Andrei POPESCU > said: > I would suggest this should read "Every document must have at least one > active maintainer" (regardless of what the Maintainer: field contains). So you mean the usual Debian package maintainer? Then we do not need to mention this explicitly, but better say that every manual should be also a Debian package. Are there manuals which are not in Debian package? -- regards Thomas
Bug#147164: ping and new proposal
On Du, 07 apr 19, 21:17:13, Thomas Lange wrote: > > "Every document has one maintainer." seems to be not true since I > found this in debian/control: > Maintainer: Debian Documentation Project > > So just remove this item. I would suggest this should read "Every document must have at least one active maintainer" (regardless of what the Maintainer: field contains). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#926652: python-trustme: FTBFS on all
On Mon, Apr 08, 2019 at 01:38:04PM +, Ivo De Decker wrote: > The latest version of python-trustme in unstable fails on all: See also bug 925576. I haven't got round to looking at it yet. I hope to investigate and fix it soon; patches also welcome. signature.asc Description: PGP signature
Bug#926653: openssh-server: Locked out of server after upgrading to buster.
Package: openssh-server Severity: serious Justification: Policy 8.2 Dear Maintainer, Due to a change in how some options are handled in sshd_config, upgrading to buster can result in the user getting locked out of their system if the config is not updated. Probably the most likely cause (and what occurred to me) is if the PubkeyAcceptedKeyTypes includes ssh-rsa and the admin logs in with an RSA key. After upgrading, the user will no longer be able to connect to the server. The solution for this case is to replace ssh-rsa with rsa-sha2-256,rsa-sha2-512. At the very least this needs to be mentioned in the upgrade instructions in the release notes for buster. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-47-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE=en_GB:en (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.6 ii libaudit1 1:2.8.4-2 ii libc6 2.28-8 ii libcom-err21.44.5-1 ii libgssapi-krb5-2 1.17-2 ii libkrb5-3 1.17-2 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libssl1.1 1.1.1b-1 ii libsystemd0241-1 pn libwrap0 ii lsb-base 10.2019031300 ii openssh-client 1:7.9p1-9 pn openssh-sftp-server pn procps pn ucf ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd 241-1 pn ncurses-term ii xauth 1:1.0.10-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw signature.asc Description: This is a digitally signed message part
Bug#926647: leveldb-sharp: ABI change in libleveldb 1.20
On 2019-04-08 14:50, Julien Cristau wrote: > as documented in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=83 libleveldb's > ABI changed incompatibly in 1.20. The 1.20-2.1 NMU changed SONAME to > reflect that, and leveldb-sharp 1.9.1-1.2 was patched to use the new > SONAME. However, with no corresponding source change, I'm not convinced > this is actually compatible; I'd have expected something in the C# > binding to need an update for the new leveldb Options structure layout. I primarily did the same as in the NMU after the library rename three years ago. And I only touched it because I NMUed it in the past. I have no idea what the package is good for :-) > I know nothing of C# / Mono though, so I might well be wrong. I probably have as much clue about these as you :-) There is this comment from Robert Bruce Park in the 1.9.1-1.1 changelog entry: "this package only uses the C ABI" Not sure if the ABI breakage is limited to the C++ part (leveldb::Options is at least a C++ thing) Andreas
Bug#926652: python-trustme: FTBFS on all
package: src:python-trustme version: 0.4.0-2 severity: serious tags: ftbfs Hi, The latest version of python-trustme in unstable fails on all: https://buildd.debian.org/status/package.php?p=python-trustme Cheers, Ivo
Bug#925455: alsa volume never saved/restored
Looking a bit further it seems that /var/lib/alsa/asound.state doesn't exist. That means that we are facing a chicken-egg problem here, the file will never be created as the service is never started (and then never stopped). I don't know, if it helps, but I could manually create a working settings file with: alsactl -f /var/lib/alsa/asound.state init alsactl -f /var/lib/alsa/asound.state store In the shell: root@debian:/var/lib/alsa# alsactl -f /var/lib/alsa/asound.state init Found hardware: "ICH" "Analog Devices AD1881A" "AC97a:41445348" "0x1043" "0x11d4" Hardware is initialized using a generic method root@debian:/var/lib/alsa# ls -l insgesamt 0 root@debian:/var/lib/alsa# alsactl -f /var/lib/alsa/asound.state store root@debian:/var/lib/alsa# ls -l insgesamt 8 -rw-r--r-- 1 root root 5680 Apr 7 18:55 asound.state root@debian:/var/lib/alsa# Since then, the sound level was properly saved and restored on restart. /var/log/syslog on start: Apr 7 19:41:46 debian systemd[1]: Starting Save/Restore Sound Card State... Apr 7 19:41:46 debian systemd[1]: Started Save/Restore Sound Card State. Apr 7 19:41:46 debian systemd[1]: Reached target Sound Card. /var/log/syslog on shutdown: Apr 7 19:45:17 debian systemd[1]: Stopped target Sound Card. Apr 7 19:45:17 debian systemd[1]: Stopping Save/Restore Sound Card State... I doesn't say "Stopped Save/Restore Sound Card State.", though. So the last confirmation seems to be missing. But it still works, as far as I can tell... I think, I always needed to run "alsactl init" at least once since Debian 8 Jessie, and this is still mentioned in the Debian Wiki: Configure alsa by running the command 'alsactl init' as root. Then reboot and try to test your sound. -- https://wiki.debian.org/ALSA Regards, Hartmut Buhrmester
Bug#926602: CVE-2019-10906 - jinja sandbox escape poc
Hi Hugo, On Mon, Apr 08, 2019 at 10:04:35AM +0200, Hugo Lefeuvre wrote: > > This should help confirming vulnerability in other suites. > > 2.7.3-1 and all later releases affected. In addition, both 2.7.3-1 and > 2.8-1 are affected by the previous str.format issue[0]. > > [0] https://palletsprojects.com/blog/jinja-281-released/ CVE-2016-10745 was assigned for this issue. Regards, Salvtore
Bug#926649: ITP: r-cran-psychometric -- GNU R applied psychometric theory
Package: wnpp Severity: wishlist Subject: ITP: r-cran-psychometric -- GNU R applied psychometric theory Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-psychometric Version : 2.2 Upstream Author : Thomas D. Fletcher * URL : https://cran.r-project.org/package=psychometric * License : GPL-2+ Programming Lang: GNU R Description : GNU R applied psychometric theory Contains GNU R functions useful for correlation theory, meta-analysis (validity-generalization), reliability, item analysis, inter-rater reliability, and classical utility. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-psychometric
