Bug#926060: lintian: portable-executable-missing-security-features false positives

[Scott Kitterman]

Package: lintian
Version: 2.11.0
Severity: normal

I'm reasonably confident that clamav testfiles don't need hardening features,
so [1] seems pretty pointless.

Scott K

[1] 
https://lintian.debian.org/maintainer/pkg-clamav-de...@lists.alioth.debian.org.html#clamav

clamav-testfiles

E portable-executable-missing-security-features
usr/share/clamav-testfiles/clam-aspack.exe ASLR DEP/NX SafeSEH
usr/share/clamav-testfiles/clam-fsg.exe ASLR DEP/NX SafeSEH
usr/share/clamav-testfiles/clam-nsis.exe ASLR DEP/NX
usr/share/clamav-testfiles/clam-pespin.exe ASLR DEP/NX SafeSEH
usr/share/clamav-testfiles/clam-petite.exe ASLR DEP/NX SafeSEH
usr/share/clamav-testfiles/clam-upx.exe ASLR DEP/NX SafeSEH
usr/share/clamav-testfiles/clam-wwpack.exe ASLR DEP/NX SafeSEH
usr/share/clamav-testfiles/clam-yc.exe ASLR DEP/NX SafeSEH
usr/share/clamav-testfiles/clam.ea05.exe ASLR DEP/NX
usr/share/clamav-testfiles/clam.ea06.exe ASLR DEP/NX
usr/share/clamav-testfiles/clam.exe ASLR DEP/NX
usr/share/clamav-testfiles/clam_IScab_ext.exe ASLR DEP/NX
usr/share/clamav-testfiles/clam_IScab_int.exe ASLR DEP/NX
usr/share/clamav-testfiles/clam_ISmsi_ext.exe ASLR DEP/NX
usr/share/clamav-testfiles/clam_ISmsi_int.exe ASLR DEP/NX

Bug#920139: sddm: GTK and GNOME: Applications won't launch due error of glib2

[Adrian Immanuel Kiess]

Hello Bernhard,

yes, I still encounter this bug in Debian/testing (Buster).

I still can't login to a GNOME session using sddm.

Using startx and running gnome-session from ~/.xinitrc everything works
fine.

I suspect running the X session from a display manager some environment
variables do not get set correctly also. Because when I login to
Enlightenment DR17 through sddm I also have an error configuring
desktop-file-utils though apt.

Here is the error shown:

Processing triggers for desktop-file-utils (0.23-4) ...
dpkg: error processing package desktop-file-utils (--configure):
 installed desktop-file-utils package post-installation script
subprocess returned error exit status 1

Running apt via an login shell on the console everything works fine and the 
post-installation script succeeds.

I don't have any of those old GNOME applications installed, you mentioned.

I still wonder what could be the issue. 

Thanks for your help.

Yours sincerely,

Adrian

-- 
With many greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Gothaer Straße 34
D-04155 Leipzig

Administrator & programmer
Unix ∧ Perl ∧ Java ∧ LaTeX

 — < adr...@kiess.onl >
 — https://www.kiess.onl # Dem Ingenieur ist nichts zu schwör
☕ — https://arosusi.kiess.onl # Nickpage of Adrian Immanuel Kieß
 — https://outanekka.kiess.onl # Outanekka online imagery

--SYSTEM--
echo "Your fortune cookie: " && /usr/games/fortune -c -s
> (people) % Others can stop you temporarily, only you can do it permanently.

echo "KIESS.ONL uptime: " && /usr/bin/uptime
> 06:07:59 up 3 days, 23:43, 6 users, load average: 1.59, 1.60, 1.63


On Sat, 2019-03-16 at 16:47 +0100, Bernhard Übelacker wrote:
> 
> 
> Hello Adrian Immanuel,
> I am sorry for the late reply.
> 
> First a question: Do you still observe this fault?
> 
> 
> I took a look today inside the md5sums you supplied
> and tried to reproduce this setup inside a VM.
> 
> Unfortunately I found following old packages that are not
> packaged in Debian anymore or maybe not installed in the
> latest version:
> 
>   nautilus-pastebin: last built 2012, found just at
> snapshot.debian.org
>   geoclue: last in jessie
>   easytag: not in the lastest version?
>   command-runner-applet: last in jessie
>   gnome-search-tool: last in stretch
>   sflphone-gnome: last in stretch
> 
> Can you please have a look at these packages, if you
> really use them?
> If not you might uninstall them and test if you still
> can observe the not launching applications?
> 
> If you use synaptic, there should be a folder with outdated packages.
> 
> 
> However, I tried to put your gsettings.compiled into that VM
> and could login into GNOME and GNOME Classic sessions without
> hitting that fault (traps: gnome-session-b...).
> 
> Kind regards,
> Bernhard
> 


signature.asc
Description: This is a digitally signed message part

Bug#925353: [Pkg-linaro-lava-devel] Bug#925353: lava-server: logrotate complains about "parent directory has insecure permissions"

[Steve McIntyre]

On Thu, Mar 28, 2019 at 06:01:38PM +0100, Andreas Beckmann wrote:
>On 2019-03-28 17:31, Steve McIntyre wrote:
>> I'm a little bit at a loss to see what's causing it... :-/
>
>I tried to normalize the logs (remove timestamps, tmpdir and everything
>before the dist-upgrade to buster) and then diff them to find this:
>
>@@ -6631,10 +6227,9 @@
>  INFO: Package lava-server contains logrotate file: 
> /etc/logrotate.d/lava-master-log
>  INFO: Package lava-server contains logrotate file: 
> /etc/logrotate.d/lava-publisher-log
>  INFO: Package lava-server contains logrotate file: 
> /etc/logrotate.d/lava-server-gunicorn-log
>- INFO: Package lava-server contains logrotate file: 
>/etc/logrotate.d/lava-server-uwsgi-log
>  DEBUG: Starting command: ['chroot', '<>', 'dpkg-query', '-W', '-f', 
> '${Status}\\t${binary:Package}\\t${Package}\\t${Version}\\n']
>
>and further up:
>
>@@ -5953,11 +5600,6 @@
>  DEBUG: Command ok: ['adequate', '--root', '<>', 'lava-server']
>  ERROR: WARN: Inadequate results from running adequate!
>   lava-server: broken-symlink /usr/share/lava-server/static/docs -> 
> ../../doc/lava-server-doc/html
>-  lava-server: obsolete-conffile /etc/logrotate.d/lava-server-uwsgi-log
>-  lava-server: obsolete-conffile /etc/lava-server/lava-server.wsgi
>-  lava-server: obsolete-conffile /etc/lava-server/debug.wsgi
>-  lava-server: obsolete-conffile /etc/lava-server/uwsgi.ini
>-  lava-server: obsolete-conffile /etc/lava-server/uwsgi.reload
>   lava-server: obsolete-conffile /etc/logrotate.d/lava-scheduler-log
>   lava-server: obsolete-conffile /etc/lava-server/lava-server-gunicorn.service
>   lava-server: obsolete-conffile 
> /etc/lava-server/dispatcher-config/device-types/nxp-k64f.jinja2
>@@ -5975,11 +5617,6 @@
>  DEBUG: Command ok: ['chroot', '<>', 
> 'tmp/scripts/pre_remove_40_find_missing_md5sums']
>  DEBUG: Starting command: ['chroot', '<>', 
> 'tmp/scripts/pre_remove_40_find_obsolete_conffiles']
>  DUMP:
>-  OBSOLETE CONFFILE /etc/logrotate.d/lava-server-uwsgi-log REGISTERED BY 
>lava-server
>-  OBSOLETE CONFFILE /etc/lava-server/lava-server.wsgi REGISTERED BY 
>lava-server
>-  OBSOLETE CONFFILE /etc/lava-server/debug.wsgi REGISTERED BY lava-server
>-  OBSOLETE CONFFILE /etc/lava-server/uwsgi.ini REGISTERED BY lava-server
>-  OBSOLETE CONFFILE /etc/lava-server/uwsgi.reload REGISTERED BY lava-server
>   OBSOLETE CONFFILE /etc/logrotate.d/lava-scheduler-log REGISTERED BY 
> lava-server (MISSING)
>   OBSOLETE CONFFILE /etc/lava-server/lava-server-gunicorn.service REGISTERED 
> BY lava-server
>   OBSOLETE CONFFILE 
> /etc/lava-server/dispatcher-config/device-types/nxp-k64f.jinja2 REGISTERED BY 
> lava-server
>
>So you have a lot of conffile cruft stemming from both jessie and stretch ...
>debian/lava-server.maintscript will be your friend :-)

ACK!

>We have the data already:
>https://piuparts.debian.org/stretch2buster/obsolete_conffiles_issue.html
>Someone needs to start filing bugs ... obsolete conffiles will bite you in the 
>future :-)

Nod, time to start cleaning up some of the old conffiles.

Thanks for the help with tracking this down - it's really appreciated!

-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Bug#925160: request for performance test in your environment

[Osamu Aoki]

Aaron

Thanks for reminder

The latest code candidate doesn’t use glob any more to reduce diff following 
Yoshino-san’s suggestion 

Now question are possible other regressions to fcitx and scim 

Sent from iPhone 

2019/03/31 11:19、Aaron M. Ucko のメール:

> I meant i386-gnu for the Hurd; sorry for the thinko.
> 
> -- 
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#925160: request for performance test in your environment

[Aaron M. Ucko]

I meant i386-gnu for the Hurd; sorry for the thinko.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#925160: request for performance test in your environment

[Aaron M. Ucko]

Please note that the Hurd (admittedly not a release architecture) uses a
multiarch tag of hurd-i386, with only two components, which is why I'd
suggested *-* rather than *-*-*.  Sorry for not stating that explicitly
earlier.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#926059: libgudev: please include a udeb, needed for libinput support in d-i

[Cyril Brulebois]

Control: block 823994 by -1

Cyril Brulebois  (2019-03-31):
> While this is very late in the release cycle to request a new binary,
> the installer team (and you!) might get a free pass on this one. A while
> ago, I've tested this successfully on stretch, and I've just refreshed
> this on top of sid; tested on some Dell Latitude laptop.
> 
> The attached patch (against current git) adds the needed udeb so that
> libwacom2 can be rebuilt against the patched libgudev, fixing the buggy
> dependencies in the libwacom2-udeb package (see #815717).

Woops, wrong lookup: I meant #823994, which I'm blocking by this bug report.

  → libwacom2-udeb: uninstallable, depends on non-udeb libgudev-1.0-0


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#926059: libgudev: please include a udeb, needed for libinput support in d-i

[Cyril Brulebois]

Source: libgudev
Version: 232-2
Severity: important
Tags: d-i

Hi,

While this is very late in the release cycle to request a new binary,
the installer team (and you!) might get a free pass on this one. A while
ago, I've tested this successfully on stretch, and I've just refreshed
this on top of sid; tested on some Dell Latitude laptop.

The attached patch (against current git) adds the needed udeb so that
libwacom2 can be rebuilt against the patched libgudev, fixing the buggy
dependencies in the libwacom2-udeb package (see #815717).

Thanks for considering!


And thanks to Mozilla for hosting this BSP.


>From Paris with bugs,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
>From b37f75201fc578feb6e3ce674c01560b28cac21a Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Thu, 10 Aug 2017 21:21:28 +
Subject: [PATCH] Add libgudev-1.0-0-udeb udeb.

It is needed by libwacom2-udeb in a Debian Installer context, for the
libinput X driver.
---
 debian/changelog   |  7 +++
 debian/control | 10 ++
 debian/control.in  | 10 ++
 debian/libgudev-1.0-0-udeb.install |  1 +
 debian/rules   |  2 +-
 5 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 debian/libgudev-1.0-0-udeb.install

diff --git a/debian/changelog b/debian/changelog
index 89b151a..a4f524b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libgudev (232-3) UNRELEASED; urgency=medium
+
+  * Add libgudev-1.0-0-udeb, needed by libwacom2-udeb in a Debian
+Installer context, for the libinput X driver.
+
+ -- Cyril Brulebois   Thu, 10 Aug 2017 21:13:43 +
+
 libgudev (232-2) unstable; urgency=medium
 
   * Update Vcs fields and debian/gbp.conf for Debian GNOME conventions
diff --git a/debian/control b/debian/control
index 80faef8..390b61c 100644
--- a/debian/control
+++ b/debian/control
@@ -35,6 +35,16 @@ Description: GObject-based wrapper library for libudev
  programming languages, such as Javascript, because of GObject introspection
  support.
 
+Package: libgudev-1.0-0-udeb
+Section: debian-installer
+Priority: optional
+Architecture: linux-any
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
+Package-Type: udeb
+Description: GObject-based wrapper library for libudev -- udeb
+ This is a udeb version of libgudev-1.0-0
+
 Package: gir1.2-gudev-1.0
 Section: introspection
 Priority: optional
diff --git a/debian/control.in b/debian/control.in
index 3d2dc02..7aa0f73 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -30,6 +30,16 @@ Description: GObject-based wrapper library for libudev
  programming languages, such as Javascript, because of GObject introspection
  support.
 
+Package: libgudev-1.0-0-udeb
+Section: debian-installer
+Priority: optional
+Architecture: linux-any
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
+Package-Type: udeb
+Description: GObject-based wrapper library for libudev -- udeb
+ This is a udeb version of libgudev-1.0-0
+
 Package: gir1.2-gudev-1.0
 Section: introspection
 Architecture: linux-any
diff --git a/debian/libgudev-1.0-0-udeb.install 
b/debian/libgudev-1.0-0-udeb.install
new file mode 100644
index 000..9ba9c91
--- /dev/null
+++ b/debian/libgudev-1.0-0-udeb.install
@@ -0,0 +1 @@
+usr/lib/*/libgudev*.so.* usr/lib
diff --git a/debian/rules b/debian/rules
index ae2265f..aef3e8d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,7 +34,7 @@ override_dh_missing:
dh_missing --fail-missing
 
 override_dh_makeshlibs:
-   dh_makeshlibs -- -c4
+   dh_makeshlibs -V --add-udeb=libgudev-1.0-0-udeb -- -c4
 
 override_dh_gencontrol:
# Ubuntu has an epoch on gudev
-- 
2.11.0

Bug#924888: remove /misc/laptops/

[Thomas Lange]

We can remove /misc/laptops/, because its content can be removed.

The link to the mailing lists is already reachable via support -> mailing lists

https://wiki.debian.org/InstallingDebianOn/ is not that important,
since it's in our wiki. It may fit onto the support or documentation page.

The other links are not Debian specific and can be removed.

-- 
regards Thomas

Bug#901952: fixing pristine-tar w.r.t. changed tar escaping

[Bernhard R. Link]

* Bernhard R. Link  [190330 07:58]:
> I'm looking into #901952 (pristine-tar failing to checkout out old files
> with non-printable unicode characters) and think that might be solved
> with the attached patches, by calling tar with --null and giving it
> a copy of the manifest file that is unescaped and NUL-terminated.
> 
> What I haven't looked into yet is whether it will break files
> generated with 1.46, as that the format incompatibly without
> changing the version of the delta (though perhaps that can be
> mitigated by an additional variant at checkout time).
> 
> What are your opinions on that? Is this worth trying to get into buster?

Attached version with some small fixes, more tests convering those
changes (and compatibility with previous versions), and an additional
variant run on checkout time to also handle files commited with 1.46.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC
>From c26122199aca7c2e08a8597d700d66b8734a3ad6 Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link" 
Date: Fri, 29 Mar 2019 22:32:13 +0100
Subject: [PATCH 1/6] revert writing unquoted filenames to manifest

this caused the filename to be unquoted two times,
break with filenames containing newlines
and changed the semantics of manifest files without changing the format version
---
 pristine-tar | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pristine-tar b/pristine-tar
index 0fe132e..fe10340 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -664,7 +664,7 @@ sub genmanifest {
 chomp;
 # ./ or / in the manifest just confuses tar
 s/^\.?\/+//;
-print OUT unquote_filename($_) . "\n" if length $_;
+print OUT $_ . "\n" if length $_;
   }
   close IN;
   close OUT;
-- 
2.20.1

>From bf607f0cd6de861a461eec9f60998950267001ab Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link" 
Date: Fri, 29 Mar 2019 22:44:25 +0100
Subject: [PATCH 2/6] change unquoting to match how tar quotes the filenames

Tar also generates octal escape sequences (\123) for some unicode
characters, especially when run in a non-unicode locale like with
LC_ALL=C. Those were not yet unquoted.

Vertical tab was unquoted improperly \x11 instead of \x0b.

If there was a literal backslash in a filename followed by
a character like a, b, n, r, t, v, then tar escapes that to
e.g. \\b. The old unquote the \b it saw in that, which this
fixes.

With those changes the unquote matches what tar uses, which
is a prerequisite for giving tar the unquoted filenames
to work around the behaviour change in tar 1.30.

Compared to versions <= 1.45 this does not change the result
of recreating a tar (so ensures every delta produced by those
is still useable) and only make pristine-tar able to handle
more tarballs. (As unquote in those were only used to create
dummy files for missing files in git, while tar was given
the original manifest file ignoring wrongly unquoted files).

As 1.46 wrote unquoted files to the manifest, this commit
breaks using some delta files created with 1.46. A later
commit will add a compatibility step for those.
---
 pristine-tar | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/pristine-tar b/pristine-tar
index fe10340..f6754c8 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -362,15 +362,27 @@ Options:
 sub unquote_filename {
   my $filename = shift;
 
-  $filename =~ s/\\a/\a/g;
-  $filename =~ s/\\b/\b/g;
-  $filename =~ s/\\f/\f/g;
-  $filename =~ s/\\n/\n/g;
-  $filename =~ s/\\r/\r/g;
-  $filename =~ s/\\t/\t/g;
-  $filename =~ s/\\v/\x11/g;
-  $filename =~ s//\\/g;
+  my $unquote_character = sub {
+if (defined $2 and $2 eq "000") {
+  die "filenames with NUL bytes are not supported";
+}
+return pack("C", oct($2)) if defined $2;
+my %map_named_escapes = (
+a => "\a",
+b => "\b",
+f => "\f",
+n => "\n",
+r => "\r",
+t => "\t",
+v => "\x0b",
+"\\" => "\\",
+);
+return $map_named_escapes{$1};
+  };
 
+  # unquote by calling $unquote_character for each matched group:
+  # (do all in a single run, as the octal sequences might output anything)
+  $filename =~ s/\\([abfnrtv\\])|\\([0-7]{3})/$unquote_character->()/ge;
   return $filename;
 }
 
-- 
2.20.1

>From c4d5609decd4b81285e92950a343b822e21608dc Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link" 
Date: Fri, 29 Mar 2019 22:56:52 +0100
Subject: [PATCH 3/6] send manifests file to tar NUL-terminated and unquoted
 (Closes: #901952)

tar changed behavior in no longer unescaping filenames with --verbatim-files-from
breaking reading all delta files and handling files with such filenames.

(This also fixes #902115 properly this time).
---
 pristine-tar | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/pristine-tar b/pristine-tar
index f6754c8..1c6e02e 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -396,12 +396,14 @@ sub recreatetarball {
 
   my @manifest;
   open(IN, "<", 

Bug#926058: /intro/organization does not list cloud teams

[Thomas Lange]

Package: www.debian.org


The Debian cloud team is not listed even if it has some official
delegates.


-- 
regards Thomas

Bug#926057: linux: please include intel-lpss-pci.ko in some udeb

[Cyril Brulebois]

Source: linux
Version: 4.19.28-2
Severity: normal
Tags: d-i

(debian-boot@ and olasd@ in copy.)

Hi,

Nicolas Dandrimont was brave enough to try and help out with d-i by
testing the latest development version on his laptop. We discovered some
shim bug (for this specific laptop), but also noticed missing support
for his touchpad & trackpad (IDs will be provided in a follow-up mail).

Comparing with the list of modules obtained on an installed system, we
first tried to ship d-i with these:

  /lib/modules/4.19.0-4-amd64/kernel/drivers/platform/x86/intel-hid.ko
  /lib/modules/4.19.0-4-amd64/kernel/drivers/input/sparse-keymap.ko (dependency 
of the former)

but there were no changes (looking at /proc/bus/input/devices). Adding
those made both touchpad & trackpad pop up (and be usable):

  /lib/modules/4.19.0-4-amd64/kernel/drivers/mfd/intel-lpss.ko (dependency of 
the latter)
  /lib/modules/4.19.0-4-amd64/kernel/drivers/mfd/intel-lpss-pci.ko

Since I suppose there might be other peripheral types using this (like
wireless?), I'm not sure this should belong to input-modules, even if
that's the udeb we double-checked first.


Thanks to Mozilla for hosting the BSP!


>From Paris with bugs,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#926056: poppler-utils: pdftohtml with -xml options generate corrupted xml file

[Robert Paciorek]

Package: poppler-utils
Version: 0.71.0-3
Severity: important

Hi,

pdftohtml with -xml options puts incorrect characters (binary data?) in "id" 
and "size" attributes of  tag.

Bug appeared in 0.71 version - 0.69.0 don't have this issue (but have other 
problem with missing whitespaces, not present in 0.71).

Looks like bug is fixed in 0.74 (0.74 from Ubuntu works OK).

Best Regards,
Robert Paciorek


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages poppler-utils depends on:
ii  libc6 2.28-8
ii  libcairo2 1.16.0-4
ii  libfreetype6  2.9.1-3
ii  liblcms2-22.9-3
ii  libpoppler82  0.71.0-3
ii  libstdc++68.3.0-2

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- no debconf information

Bug#926055: ITP: python-django-debreach -- some protection against the BREACH attack in Django

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-django-debreach
  Version : 1.5.2
  Upstream Author : Luke Pomfrey 
* URL : https://github.com/lpomfrey/django-debreach
* License : BSD-2-Clause
  Programming Lang: Python
  Description : some protection against the BREACH attack in Django

 This Python Django module provides basic/extra mitigation against the BREACH
 attack for Django projects. When combined with rate limiting in your
 web-server, or by using something like django-ratelimit, the techniques here
 should provide at least some protection against the BREACH attack.

Note: This is a new dependency of OpenStack Dashboard (aka: Horizon).

Bug#923930: FTBFS: FAIL test_chain (exit status: 1)

[deb251]

It looks like this is fixed upstream (at least for 64-bit machines): 
https://github.com/heimdal/heimdal/issues/533



On Sun, 10 Mar 2019 06:17:32 -0500 "A. Wilcox"  
wrote:

> Source: heimdal
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> heimdal fails to build from source, both in Buster and Sid. It is

> failing in one of the tests. Relevant snippet below and full build log
> is accessible at:
> 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/heimdal_7.5.0+dfsg-2.1.rbuild.log.gz
> 
> =

>Heimdal 7.5.0: lib/hx509/test-suite.log
> =
> 
> # TOTAL: 16

> # PASS:  15
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> FAIL: test_chain

> 
> 
> cert -> root

> cert -> root
> cert -> root
> sub-cert -> root
> sub-cert -> sub-ca -> root
> sub-cert -> sub-ca
> sub-cert -> sub-ca -> root
> sub-cert -> sub-ca -> root
> sub-cert -> sub-ca -> root
> max depth 2 (ok)
> max depth 1 (fail)
> ocsp non-ca responder
> ocsp ca responder
> ocsp no-ca responder, missing cert
> ocsp no-ca responder, missing cert, in pool
> ocsp no-ca responder, keyHash
> ocsp revoked cert
> ocsp print reply resp1-ocsp-no-cert
> ocsp print reply resp1-ca
> ocsp print reply resp1-keyhash
> ocsp print reply resp2
> ocsp verify exists
> ocsp verify not exists
> ocsp verify revoked
> crl non-revoked cert
> FAIL test_chain (exit status: 1)
> 
> -- System Information:

> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Bug#926054: ITP: golang-github-kodeworks-golang-image-ico -- Golang support for windows .ico file format.

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-kodeworks-golang-image-ico
  Version : 0.0~git20141118.73f0f4c-1
  Upstream Author : Kodeworks
* URL : https://github.com/Kodeworks/golang-image-ico
* License : BSD-3-clause
  Programming Lang: Go
  Description : Golang support for windows .ico file format.

 The ICO file format is an image file format for computer icons
 in Microsoft Windows. ICO files contain one or more small images
 at multiple sizes and color depths, such that they may be scaled
 appropriately. In Windows, all executables that display an icon
 to the user, on the desktop, in the Start Menu, or in Windows Explorer,
 must carry the icon in ICO format.

This package is a dependency of another package "golang-fyne-fyne" (#925466).

Bug#926051:

[Dawid Dziurla]

Forgot to add that:

This package is a dependency of another package "golang-fyne-fyne" (#925466).

Bug#842893: libxml-twig-perl: expand_external_ents fails to work as documented

[gregor herrmann]

Control: tag -1 + patch

On Sun, 17 Mar 2019 23:27:59 +0100, Moritz Mühlenhoff wrote:

> severity 842893 grave
> thanks
> 
> On Wed, Nov 02, 2016 at 07:07:13AM +0100, Salvatore Bonaccorso wrote:
> > Source: libxml-twig-perl
> > Version: 1:3.39-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=118097
> > 
> > Hi
> > 
> > XML::Twig's expand_external_ents fails to work as documented, see the
> > upstream bug report for details and as well reported to Red Hat at
> > https://bugzilla.redhat.com/show_bug.cgi?id=1379553 .
> > 
> > There is though still no upstream fix for it.
> 
> This is unfixed for long time and I don't think this should slip
> unfixed into another stable release. Especially given that the fix is
> simple; 3.50 introduced the no_xxe option, so all that needs to be
> done is to fix the misleading docs for expand_external_ents (and
> refer to use no_xxe instead there).

I had a look at this bug yesterday evening, and I'm attaching a
potential patch.

Moritz, I'm not completely sure I understand which changes to the
docs you imagined, but I've added the following now:

+B: setting expand_external_ents to 0 or -1 currently doesn't work
+as expected; cf. L.
+To completelty turn off expanding external entities use C.
+
+=item no_xxe
+
+If this argument is set to a true value, expanding of external entities is
+turned off.
+

Additionally (actually before changing the docs, in the hope to fix
the actual bug which I didn't manage to do), I added a test for both
expand_external_ents and no_xxe, based on the reproducer in the CPAN
RT ticket. Doesn't help alot now but might be beneficial for the
future. Not sure what the release team thinks about it but it doesn't
affect the binary package.

In general, if we go ahead with something like this, I'm not sure if
we should really close this bug; the issue is mitigated by using and
documenting no_xxe but the expand_external_ents option is still buggy.
[0]. 


Cheers,
gregor

[0] This is also the last comment at
https://bugzilla.redhat.com/show_bug.cgi?id=1379553

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Tracy Chapman: Why
diff -Nru libxml-twig-perl-3.50/debian/changelog libxml-twig-perl-3.50/debian/changelog
--- libxml-twig-perl-3.50/debian/changelog	2016-08-04 18:52:02.0 +0200
+++ libxml-twig-perl-3.50/debian/changelog	2019-03-30 17:36:55.0 +0100
@@ -1,3 +1,15 @@
+libxml-twig-perl (1:3.50-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "CVE-2016-9180: expand_external_ents fails to work as
+documented": add patch CVE-2016-9180.patch:
+- update documentation about expand_external_ents and no_xxe
+- add test for expand_external_ents and no_xxe
+Additionally add build dependency on libtest-exception-perl.
+(Closes: #842893)
+
+ -- gregor herrmann   Sat, 30 Mar 2019 17:36:55 +0100
+
 libxml-twig-perl (1:3.50-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libxml-twig-perl-3.50/debian/control libxml-twig-perl-3.50/debian/control
--- libxml-twig-perl-3.50/debian/control	2016-08-04 18:52:02.0 +0200
+++ libxml-twig-perl-3.50/debian/control	2019-03-30 17:36:55.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Bart Martens 
 Standards-Version: 3.9.8
-Build-Depends-Indep: perl (>= 5.6.0-16), libxml-parser-perl, libunicode-map8-perl, libunicode-string-perl, libtie-ixhash-perl, libxml-xpathengine-perl | libxml-xpath-perl, libtest-pod-perl, libtest-pod-coverage-perl (>= 1.00), libxml-handler-yawriter-perl, libxml-sax-machines-perl, libxml-simple-perl, libyaml-perl
+Build-Depends-Indep: perl (>= 5.6.0-16), libxml-parser-perl, libunicode-map8-perl, libunicode-string-perl, libtie-ixhash-perl, libxml-xpathengine-perl | libxml-xpath-perl, libtest-pod-perl, libtest-pod-coverage-perl (>= 1.00), libxml-handler-yawriter-perl, libxml-sax-machines-perl, libxml-simple-perl, libyaml-perl, libtest-exception-perl
 Build-Depends: debhelper (>= 8.0.0), expat
 Homepage: http://www.xmltwig.org/
 
diff -Nru libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch
--- libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch	1970-01-01 01:00:00.0 +0100
+++ libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch	2019-03-30 17:36:55.0 +0100
@@ -0,0 +1,85 @@
+Description: Update documentation for XML::Twig.
+ Mention problems with expand_external_ents and add
+ information about new no_xxe argument.
+ .
+ Additionally add tests for both expand_external_ents and no_xxe.
+Origin: vendor
+Bug: https://rt.cpan.org/Public/Bug/Display.html?id=118097
+Bug-Debian: https://bugs.debian.org/842893
+Author: 

Bug#903499: Merge request

[Moritz Muehlenhoff]

Hi,
I created https://salsa.debian.org/multimedia-team/audiofile/merge_requests/1 
to address this.

Cheers,
Moritz

Bug#926053: unblock: firefox-esr/60.6.1esr-1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package firefox-esr. It upgrades to the latest 60 ESR release,
including a few security fixes.

unblock firefox-esr/60.6.1esr-1

Cheers,
Moritz

Bug#926043: CVE-2019-0816

[Thomas Goirand]

On 3/30/19 8:10 PM, Moritz Muehlenhoff wrote:
> Package: cloud-init
> Severity: grave
> Tags: security
> 
> This was assigned CVE-2019-0816:
> https://code.launchpad.net/~jasonzio/cloud-init/+git/cloud-init/+merge/363445
> https://support.microsoft.com/en-us/help/4491476/extraneous-ssh-public-keys-added-to-authorized-keys-file-on-linux-vm
> 
> Is this something that affects cloud-init as shipped in Debian or in the way 
> we generate Debian
> images for Azure?
> 
> Cheers,
> Moritz

Hi Moritz,

If I understand well the problem, the issue is simply that some extra
Microsoft keys may end up being setup into an Azure Debian instance. I
don't see this as a very "grave" security issue because:

1/ Azure users must trust Azure anyways, otherwise, they should just
stop doing hosting there.
2/ It only affects Azure users.

I'm not even sure that our image is really using cloud-init to do the
ssh key provisioning, if I'm not mistaking, it's using the Azure agent
to do that (can Bastian confirm this?).

In any case, can we downgrade this bug to "important"? Or am I missing
something here?

Cheers,

Thomas Goirand (zigo)

Bug#926052: unblock: python-pip/18.1-5

[Thomas Goirand]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-pip

The version 18.1-5 includes a fix so that using the --extra-index-url option
of pip doesn't result in a "HTTPError: 404 Client Error: NOT FOUND".

Note that the bug is Debian specific, and is due to the way upstream calls
the requests module, which fails if the requests module is de-vendored /
de-embedded from pip, which is what has been done in Debian.

Bellow, inline in the body of this mail (sorry, I should have made it an
attachment, maybe?) is the debdiff for the package. Note that the changes to
the "hands-off-system-packages.patch" may be ignore, it's just produced by a
"quilt refresh" of the patch. Reading it, you'll notice that the only thing
that changes is the way "except HTTPError as exc:" is done, using the
imported "HTTPError" from pip._vendor.requests.exceptions rather than from
requests.HTTPError which fails.

Note that this bug deeply impacts the OpenStack CI/CD system which deeply
relies on pip and the --extra-index-url, which is why I care a lot for this
patch to go through.

Please unblock python-pip/18.1-5.

Cheers,

Thomas Goirand (zigo)

diff -Nru python-pip-18.1/debian/changelog python-pip-18.1/debian/changelog
--- python-pip-18.1/debian/changelog2019-01-03 17:38:22.0 +0100
+++ python-pip-18.1/debian/changelog2019-03-30 21:10:13.0 +0100
@@ -1,3 +1,15 @@
+python-pip (18.1-5) unstable; urgency=medium
+
+  * Team upload.
+  * Refresh hands-off-system-packages.patch.
+  * Add Properly_catch_requests_HTTPError_in_index.py.patch: this fixes 404
+when using --extra-index-url due to the way we de-bundle python-requests
+from pip. Thanks to Fabio Natali  for the bug report,
+Clark Boylan for the patch, and all of the OpenStack infra team for their
+help and involving me for this fix (Closes: #837764).
+
+ -- Thomas Goirand   Sat, 30 Mar 2019 21:10:13 +0100
+
 python-pip (18.1-4) unstable; urgency=medium
 
   * Generate Built-Using at the build time (Closes: #831271).
diff -Nru python-pip-18.1/debian/patches/hands-off-system-packages.patch 
python-pip-18.1/debian/patches/hands-off-system-packages.patch
--- python-pip-18.1/debian/patches/hands-off-system-packages.patch  
2019-01-03 17:38:22.0 +0100
+++ python-pip-18.1/debian/patches/hands-off-system-packages.patch  
2019-03-30 21:10:13.0 +0100
@@ -17,17 +17,18 @@
 Patch-Name: hands-off-system-packages.patch
 ---
 
 a/src/pip/_internal/utils/misc.py
-+++ b/src/pip/_internal/utils/misc.py
-@@ -285,22 +285,40 @@
+Index: python-pip/src/pip/_internal/utils/misc.py
+===
+--- python-pip.orig/src/pip/_internal/utils/misc.py
 python-pip/src/pip/_internal/utils/misc.py
+@@ -289,22 +289,40 @@ def renames(old, new):
  
  def is_local(path):
  """
 -Return True if path is within sys.prefix, if we're running in a 
virtualenv.
--
--If we're not in a virtualenv, all paths are considered "local."
 +Return True if this is a path pip is allowed to modify.
-+
+ 
+-If we're not in a virtualenv, all paths are considered "local."
 +If we're in a virtualenv, sys.prefix points to the virtualenv's
 +prefix; only sys.prefix is considered local.
 +
diff -Nru 
python-pip-18.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
 
python-pip-18.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
--- 
python-pip-18.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
  1970-01-01 01:00:00.0 +0100
+++ 
python-pip-18.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
  2019-03-30 21:10:13.0 +0100
@@ -0,0 +1,47 @@
+Description: Properly catch requests' HTTPError in index.py
+ This resolves issue #4195.
+ .
+ In index.py's index retrieval routine we were catching
+ requests.HTTPError to log and ignore 404s and other similar HTTP server
+ errors when pulling from (extra-)index-urls. Unfortunately, the actual
+ path to that exception is requests.exceptions.HTTPError and the alias we
+ were using does not work when pip is installed with unvendored libs as
+ with the debian packaged pip.
+ .
+ Thankfully the fix is simple. Import and use
+ requests.exceptions.HTTPError. This comes with the added bonus of
+ fitting in with the existing handling for RetryError and SSLError. With
+ this change in place upstream pip and downstream packaged pip should
+ both catch this exception properly.
+ .
+ Note: I've not added any tests cases as I'm unsure how to test the
+ distro packaging case within pip's testsuite. However, the existing test
+ suite should hopefully cover that this isn't a regression and I've
+ manually confirmed that this works with a hacked up debian package
+ install. Also this is how we handle RetryError and SSLError.
+Author: Clark Boylan 
+Date: Fri, 29 Mar 2019 10:17:31 -0700
+Origin: 

Bug#926051: ITP: golang-github-jackmordaunt-icns -- Easily create .icns files (Mac Icons) with this Go library or the included CLI app.

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-jackmordaunt-icns
  Version : 2.0.3-1
  Upstream Author : Jack Mordaunt
* URL : https://github.com/jackmordaunt/icns
* License : Expat
  Programming Lang: Go
  Description : Easily create .icns files (Mac Icons) with this Go library 
or the included CLI app.

 icns files allow for high resolution icons to make your apps look
 sexy. The most common ways to generate icns files are: • iconutil, which
 is a Mac native cli utility.• ImageMagick which adds a large dependency
 to your project for such a simple use case.  With this library you can
 use pure Go to create icns files from any source image, given that you
 can decode it into an image.Image, without any heavyweight dependencies
 or subprocessing required. You can also use it to create icns files on
 windows and linux (thanks Go).
 .
 A small CLI app icnsify is provided allowing you to create icns files
 using this library from the command line. It supports piping, which is
 something iconutil does not do, making it substantially easier to wrap
 or chuck into a shell pipeline.

Bug#926050: stretch-pu: package python-pip/9.0.1-2+deb9u1

[Thomas Goirand]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

I would like to upload a fix to python-pip to Stretch, fixing pip download
when using --extra-index-url. Pip is indeed broken because of the way pip
handles exceptions from the vendored requests module, and the way Debian
de-embbed requests. The patch is pretty short (2 lines are changed).

Debdiff is attached.

Please allow me to upload python-pip/9.0.1-2+deb9u1 to stretch PU.

Cheers,

Thomas Goirand (zigo)
diff -Nru python-pip-9.0.1/debian/changelog python-pip-9.0.1/debian/changelog
--- python-pip-9.0.1/debian/changelog   2017-01-11 21:48:53.0 +0100
+++ python-pip-9.0.1/debian/changelog   2019-03-31 00:02:11.0 +0100
@@ -1,3 +1,12 @@
+python-pip (9.0.1-2+deb9u1) stretch; urgency=medium
+
+  * Team upload.
+  * Add Properly_catch_requests_HTTPError_in_index.py.patch, which fixes
+--extra-index-url results in "HTTPError: 404 Client Error: NOT FOUND".
+The patch makes works even with the unbundled requests. (Closes: #837764).
+
+ -- Thomas Goirand   Sun, 31 Mar 2019 00:02:11 +0100
+
 python-pip (9.0.1-2) unstable; urgency=medium
 
   * d/control: Update python-setuptools Built-Using version.
diff -Nru 
python-pip-9.0.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
 
python-pip-9.0.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
--- 
python-pip-9.0.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
 1970-01-01 01:00:00.0 +0100
+++ 
python-pip-9.0.1/debian/patches/Properly_catch_requests_HTTPError_in_index.py.patch
 2019-03-31 00:01:10.0 +0100
@@ -0,0 +1,47 @@
+Description: Properly catch requests' HTTPError in index.py
+ This resolves issue #4195.
+ .
+ In index.py's index retrieval routine we were catching
+ requests.HTTPError to log and ignore 404s and other similar HTTP server
+ errors when pulling from (extra-)index-urls. Unfortunately, the actual
+ path to that exception is requests.exceptions.HTTPError and the alias we
+ were using does not work when pip is installed with unvendored libs as
+ with the debian packaged pip.
+ .
+ Thankfully the fix is simple. Import and use
+ requests.exceptions.HTTPError. This comes with the added bonus of
+ fitting in with the existing handling for RetryError and SSLError. With
+ this change in place upstream pip and downstream packaged pip should
+ both catch this exception properly.
+ .
+ Note: I've not added any tests cases as I'm unsure how to test the
+ distro packaging case within pip's testsuite. However, the existing test
+ suite should hopefully cover that this isn't a regression and I've
+ manually confirmed that this works with a hacked up debian package
+ install. Also this is how we handle RetryError and SSLError.
+Author: Clark Boylan 
+Date: Fri, 29 Mar 2019 10:17:31 -0700
+Origin: upstream, 
https://github.com/pypa/pip/pull/6367/commits/f8292a304deebcf0e4cda2e40caa226c70030f11
+Bug-Debian: https://bugs.debian.org/837764
+Last-Update: 2019-03-30
+
+--- python-pip-9.0.1.orig/pip/index.py
 python-pip-9.0.1/pip/index.py
+@@ -34,7 +34,7 @@ from pip._vendor import html5lib, reques
+ from pip._vendor.packaging.version import parse as parse_version
+ from pip._vendor.packaging.utils import canonicalize_name
+ from pip._vendor.packaging import specifiers
+-from pip._vendor.requests.exceptions import SSLError
++from pip._vendor.requests.exceptions import HTTPError, SSLError
+ from pip._vendor.distlib.compat import unescape
+ 
+ 
+@@ -809,7 +809,7 @@ class HTMLPage(object):
+ return
+ 
+ inst = cls(resp.content, resp.url, resp.headers)
+-except requests.HTTPError as exc:
++except HTTPError as exc:
+ cls._handle_fail(link, exc, url)
+ except SSLError as exc:
+ reason = ("There was a problem confirming the ssl certificate: "
diff -Nru python-pip-9.0.1/debian/patches/series 
python-pip-9.0.1/debian/patches/series
--- python-pip-9.0.1/debian/patches/series  2017-01-11 21:48:53.0 
+0100
+++ python-pip-9.0.1/debian/patches/series  2019-03-31 00:02:05.0 
+0100
@@ -4,3 +4,4 @@
 set_user_default.patch
 disable-pip-version-check.patch
 html5lib-alternative-beta-name.patch
+Properly_catch_requests_HTTPError_in_index.py.patch

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Sven Hartge]

On 25.03.19 20:25, Sven Hartge wrote:
> On 24.03.19 02:02, Sven Hartge wrote:
> 
>> So far, so good. I have your packages running on the main webmail server
>> and the main web server for my university and so far everything is fine,
>> while default packages and the test1 packages with mpm_event would
>> normally start showing the symptoms after ~12 hours.
> 
> Still no problems here and both systems have seen some serious traffic
> the last days, with the new semester starting next week and all.

One week later: still no problems here.

I also did a cross-check with 2.4.25-3+deb9u6 and it died after ~12 hours.

So from my perspective 2.4.25-3+deb9u7~test2 fixes the problems with
mpm_event for me.

S!



signature.asc
Description: OpenPGP digital signature

Bug#925911: RFS: lopsub-1.0.2 [ITP]

[Adam Borowski]

On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
>  * Package name: lopsub
>Version : 1.0.2

Such a version means a native package; only software written specifically
for Debian which makes no sense outside it should use the native format.
Even if you're both upstream and the packager, a non-native format is
helpful in case someone other than you would upload a fix.

This library is certainly not something for Debian only, thus please append
"-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
despite the name, doesn't require actually using quilt).

>Upstream Author : Andre Noll 
>  * URL : http://people.tuebingen.mpg.de/maan/lopsub/
>  * License : (L)GPLv3

It would be nice to mention more prominently what parts are GPLv3-ed and
which are LGPLv3-ed.

>Section : libdevel
> 
> lopsup - The Long Option Parser for Subcommands

> However, there are still some warnings from lintian
> I don't know how to deal with.

I'd recommend running "lintian -i" which gives a long descriptive message
for every warning, including hints how to fix.

I see a static library installed by the package.  Those shouldn't generally
be used unless you're doing something special -- static linking makes
security and bugfix updates extremely tedious.  Libraries should also be
split into separate binary packages, with lib${name}dev providing
development files while lib${name}${so} the runtime lib.

I'll stop this round of review here; I haven't took a look at the actual
functionality yet.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Bug#924951: buildable debian directory

[Jeffrey Cliff]

on the upside...the above link has a branch that successfully builds an
installable package...

on the down side this package turns out to be one of those 'one-function'
ones, so it probably just makes more sense to fold it into mist.

Hopefully this helps,

Jeff Cliff

Bug#725761: RFP: libervia -- web frontend for Salut à Toi

[W. Martin Borgert]

See https://salsa.debian.org/goffi-guest/sat-xmpp-libervia

Bug#926049: shntool: should be section "sound"

[Christoph Anton Mitterer]

Package: shntool
Version: 3.0.10-1
Severity: wishlist


Hi.

The package would IMO fit much better into the section "sound".

Cheers,
Chris.

Bug#897232: RFP: cagou -- Desktop frontend for Salut à Toi XMPP client

[W. Martin Borgert]

See https://salsa.debian.org/goffi-guest/sat-xmpp-cagou

Bug#925919: linux-image-amd64: linux-image-3.16.0-8-amd64 - unpredictable reboots / kernel panics?

[ingo7993]

About 8 to 10 of our servers suffered from these issues in the last days. All 
servers are virtualized on
a vSphere cluster. It happens with amd64 and i386 machines. Our sole 
non-virtualized server with Debian
8 and linux-image-3.16.0-8-amd64 (Nagios under heavy load) runs stable until 
now.

One of the affected servers crashes reproducible only a few seconds after the 
boot process. I thought,
this would be a good candidate for trying the fixed kernel from

> https://people.debian.org/~benh/packages/jessie-security/

Unfortunately this server (Subversion/Apache) runs a i386 system and the one 
provided kernel is an amd64
package.

Ingo

Bug#924762: a bug in xfce4?

[ziegler]

"xterm -T ä" crashes the X-server too.

So it seems rather to be a bug in xfce4.

Martin

Bug#926048: RM: tbdialout/1.7.2-1+deb9u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

This extension is broken with Thunderbird 60 and was already removed from sid.

Cheers,
Moritz

Bug#926040: u-boot: Please support Olimux Teres-I DIY laptop

[Vagrant Cascadian]

On 2019-03-30, Jonas Smedegaard  wrote:
> Quoting Vagrant Cascadian (2019-03-30 19:32:10)
>> On 2019-03-30, Jonas Smedegaard wrote:
>> > As subject says, please have u-boot support Olimux Teres-I DIY laptop.
...
>> I've glanced at the changes, and overall they look ok. A little more
>> invasive than one might want this late in the freeeze, though...
>
> As you maybe noticed from the history of the git, I first tried older 
> more minimal patches, before I stumbled upon this current one which 
> actually works for me: Today was first time ever that I booted my 
> Teres-I off of an up-to-date (and then patched) u-boot.

Congrats! I know from experience how much of an adventure that can be...


>> Have the patches been submitted upstream? Is the added .dts based on 
>> the one included in the linux kernel?
>
> Short version: No.

That makes it harder to consider, to be honest. I've made the mistake of
maintaining invasive third-party patches before... would prefer to not
make that mistake again. Especially where we're at in the freeze.

I would consider including them in an upload to experimental, with the
understanding that they might be removed again later.

I was planning on uploading a v2019.04-rc* to experimental soon, and
maybe it would make sense to target that.


> I am not in contact with the author of the patch, just lifted it our of 
> their rpm source package and applied ot to our u-boot package.
>
> This is as far as I know the newest conversation related to this (and 
> the post that clued me in on searching for work done by Torsten Duwe): 
> https://lkml.org/lkml/2019/2/4/1012
>
> My understanding is that it is is being pushed to Linux kernel actively 
> by Icenowy Zheng, and for u-boot seemingly only exists as the work by 
> Torsten Duwe which seemingly is not pushing it upstream actively.
>
> My (wild) guess is that Icenowy will push it to u-boot when in Linux.

Thanks for a little deeper background. It still sounds unclear when the
changes might plausibly land upstream, though.

Maybe nudging some people to get the patches upstream would be feasible;
a u-boot merge window opens in a couple weeks.


>> It would be helpful to either include the patches in the bug report, 
>> or submit a merge request on salsa.debian.org. Mixing the two methods 
>> feels a bit suboptimal to me.
>
> I was awaiting your response to know what you preferred.
>
> I am not familiar with Gitlab merge requests, but am willing to try if 
> guided.  But easiest for me is to simply push directly to the u-boot git 
> if that's ok with you (I got write access already since you put it in 
> the debian area on salsa).  If you want me to add it in a separate 
> branch, then what branch name do you prefer?

At the moment, I'd prefer to hold off on these patches until upstream
status is a little more solid, or keep the patches only in experimental
till then.

Do feel free to push to a "wip/teres-i" branch in the u-boot salsa; I
think that would make it easier for me to review.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#925084: di-netboot-assistant: debian-installer-xxx-netboot-yyy are wrongly configured

[Jérémy Viès]

Hi Andreas,

sorry for the delay, your emails went to my spam folder.

I thought I was more smart than the doc... I didn't mount/bind the
installer folder, instead I linked it to the correct place.
I've just tried mounting the folder, and all is OK !

so sorry again for the disturbing !

by curiosity, why does it work using mount/bind and not with a simple
symbolic link ?

regards,


Le ven. 22 mars 2019 à 18:48, Andreas B. Mundt  a écrit :

> Control: tags + unreproducible moreinfo
>
>
> Hi Jérémy,
>
> On Tue, Mar 19, 2019 at 07:43:47PM +0100, Jérémy Viès wrote:
> […]
> > I get a "No DEFAULT or UI configuration directive found!" when the PXE
> client
> > boots on one of these installer.
>
> I cannot reproduce the problem you reported.  It works fine here, also
> with the packaged installer.  Can you check if the installer is
> available in '/var/lib/tftpboot/d-i/n-pkg/' (or your corresponding
> TFTP-root)?
>
> Thanks and best regards,
>
>   Andi
>

Bug#926047: missing licenses

[Thorsten Alteholz]

Package: octave
Version: 5.1.0-1
Severity: serious
User: alteh...@debian.org
Usertags: ftp
thanks

Please add the missing licenses of:
 etc/fonts/*.otf
to your debian/copyright.

While you are at it, our hardworking trainees found:
  ./display-available.h:Copyright (C) 2012-2019 John W. Eaton
  ./main.in.cc:Copyright (C) 2012-2019 John W. Eaton
  ./main-gui.cc:Copyright (C) 2012-2019 John W. Eaton
  ./main-cli.cc:Copyright (C) 2012-2019 John W. Eaton
  ./display-available.c:Copyright (C) 2012-2019 John W. Eaton

Thanks!
  Thorsten

Bug#926040: u-boot: Please support Olimux Teres-I DIY laptop

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-03-30 20:46:14)
> Quoting Vagrant Cascadian (2019-03-30 19:32:10)
> > Have the patches been submitted upstream? Is the added .dts based on 
> > the one included in the linux kernel?
> 
> Short version: No.

Sorry, I answered only the first of above questions.

Yes, the DTS is clearly based on the one included in the linux kernel.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#926046: Negotiated or default wsize causes misbehavior

[Elliott Mitchell]

Package: nfs-common
Version: 1:1.3.4-2.1

I'm using NFSv4 over TCP at the moment.  If I don't specify rsize and
wsize on the client, either the client negotiates a wsize of 256KB or
defaults to a wsize of 256KB ("wsize=262144").

When dumping large amounts of data (moving 2TB of data around, figure
many 200MB files) onto the server, after a while the mount hangs and then
messages start appearing in the server kernel log:
"[sss.mmm] NFSD: client x testing state ID with incorrect client ID"
After several minutes the mount was recovering, but having an entire
machine locked up for a while is a problem.

During an attempt to revert to using UDP, I discovered that explicitly
setting wsize=8192 fixed the problem (this size is reasonable with UDP if
you've got jumbo-frame support).  I'm guessing either the default is bad
or negotiation is failing to generate a working value.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#801067: Concurring with #801067

[Elliott Mitchell]

I have little option, but to agree with Reuben Thomas.  The bottom of
README.Debian.nfsv4 has a date of "Wed, 11 Oct 2006 15:18:03 +0200", more
than 10 years old.

Even for Debian being in the distribution for 10 years no longer
qualifies as "rather new".  A 2.6 kernel is no longer "recent" in light
of Debian being on 4.9 now.  The lines suggested to be added to
/etc/services on the client are now present in Debian's default
/etc/services file.

Yeah, that file needs a bit of an update or removal...


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#926045: unblock: software-properties/0.96.20.2-2

[Julian Andres Klode]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package software-properties

This fixes a release critical bug that made software-properties
generate a trusted.gpg file in the wrong format, causing apt to
fail to read.

I essentially replaced the AptAuth.py with the one in Ubuntu 18.04,
which makes it use apt-key instead of gpg directly, so while this
is not as minimal a change as it maybe? could be, it's battle-tested :)

(include/attach the debdiff against the package in testing)

unblock software-properties/0.96.20.2-2

-- System Information:
Debian Release: buster/sid
  APT prefers disco
  APT policy: (991, 'disco'), (500, 'disco'), (500, 'cosmic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-7-generic (SMP w/8 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

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
diff -Nru software-properties-0.96.20.2/debian/changelog software-properties-0.96.20.2/debian/changelog
--- software-properties-0.96.20.2/debian/changelog	2016-06-30 12:13:48.0 +0200
+++ software-properties-0.96.20.2/debian/changelog	2019-03-30 20:45:34.0 +0100
@@ -1,3 +1,10 @@
+software-properties (0.96.20.2-2) unstable; urgency=medium
+
+  * softwareproperties/AptAuth.py: Use apt-key (Closes: #867681)
+  * debian/gbp.conf: Point to debian/buster
+
+ -- Julian Andres Klode   Sat, 30 Mar 2019 20:45:34 +0100
+
 software-properties (0.96.20.2-1) unstable; urgency=medium
 
   * Imported Upstream version 0.96.20.2
diff -Nru software-properties-0.96.20.2/debian/gbp.conf software-properties-0.96.20.2/debian/gbp.conf
--- software-properties-0.96.20.2/debian/gbp.conf	2016-06-30 12:13:48.0 +0200
+++ software-properties-0.96.20.2/debian/gbp.conf	2019-03-30 20:45:34.0 +0100
@@ -1,2 +1,3 @@
-[buildpackage]
+[DEFAULT]
 sign-tags = True
+debian-branch = debian/buster
diff -Nru software-properties-0.96.20.2/debian/patches/0001-Imported-Debian-version-0.96.9debian1.patch software-properties-0.96.20.2/debian/patches/0001-Imported-Debian-version-0.96.9debian1.patch
--- software-properties-0.96.20.2/debian/patches/0001-Imported-Debian-version-0.96.9debian1.patch	2016-06-30 12:13:48.0 +0200
+++ software-properties-0.96.20.2/debian/patches/0001-Imported-Debian-version-0.96.9debian1.patch	2019-03-30 20:45:34.0 +0100
@@ -46,7 +46,7 @@

  True
 diff --git a/softwareproperties/gtk/SoftwarePropertiesGtk.py b/softwareproperties/gtk/SoftwarePropertiesGtk.py
-index fbe5b0a..33eaaca 100644
+index 11e65c4..cf375c1 100644
 --- a/softwareproperties/gtk/SoftwarePropertiesGtk.py
 +++ b/softwareproperties/gtk/SoftwarePropertiesGtk.py
 @@ -51,7 +51,11 @@ import softwareproperties.distro
diff -Nru software-properties-0.96.20.2/debian/patches/0004-Implement-PackageKit-support.patch software-properties-0.96.20.2/debian/patches/0004-Implement-PackageKit-support.patch
--- software-properties-0.96.20.2/debian/patches/0004-Implement-PackageKit-support.patch	2016-06-30 12:13:48.0 +0200
+++ software-properties-0.96.20.2/debian/patches/0004-Implement-PackageKit-support.patch	2019-03-30 20:45:34.0 +0100
@@ -146,7 +146,7 @@
  
  return res
 diff --git a/softwareproperties/gtk/SoftwarePropertiesGtk.py b/softwareproperties/gtk/SoftwarePropertiesGtk.py
-index 33eaaca..df8ad45 100644
+index cf375c1..92037a9 100644
 --- a/softwareproperties/gtk/SoftwarePropertiesGtk.py
 +++ b/softwareproperties/gtk/SoftwarePropertiesGtk.py
 @@ -27,16 +27,21 @@ from __future__ import absolute_import, print_function
@@ -191,7 +191,7 @@
  
  # Put some life into the user interface:
  self.init_auto_update()
-@@ -1031,7 +1038,7 @@ class SoftwarePropertiesGtk(SoftwareProperties, SimpleGtkbuilderApp):
+@@ -1033,7 +1040,7 @@ class SoftwarePropertiesGtk(SoftwareProperties, SimpleGtkbuilderApp):
  if e._dbus_error_name == 'com.ubuntu.SoftwareProperties.PermissionDeniedByPolicy':
  logging.error("Authentication canceled, changes have not been saved")
  
@@ -200,7 +200,7 @@
  #print(progress)
  self.button_driver_revert.set_visible(False)
  self.button_driver_apply.set_visible(False)
-@@ -1041,30 +1048,30 @@ class SoftwarePropertiesGtk(SoftwareProperties, SimpleGtkbuilderApp):
+@@ -1043,30 +1050,30 @@ class SoftwarePropertiesGtk(SoftwareProperties, SimpleGtkbuilderApp):
  self.progress_bar.set_visible(True)
  
  self.label_driver_action.set_label(_("Applying changes..."))
@@ -254,7 +254,7 @@
  
  def on_driver_changes_apply(self, button):
  
-@@ -1077,18 +1084,36 @@ class 

Bug#925179: perl: autopkgtest failures on arm64, ppc64el and s390x: NDBM backwards binary compatibility

[Niko Tyni]

On Sun, Mar 24, 2019 at 12:19:20PM +0200, Niko Tyni wrote:

> While the current test data files from stretch indeed cannot be read
> on sid, I cannot make new test data files on stretch that reproduce the
> behaviour. I've created 100 such databases on each affected architecture
> and all of those are readable on sid.
> 
> I note that the test data files we're shipping for stretch versions of
> ppc64el and arm64 are identical, which seems improbable. My best guess
> is that I've mixed up the test data files from different architectures
> when copying them around and committing them to git. How embarrassing.

Trying to fix things for a new upload I finally understood what went
wrong here.

The stretch version of the GDBM "compat library" created a hard
link between the .dir and .pag files. The buster version checks
for this and handles it as a special case.

  https://sources.debian.org/src/gdbm/1.8.3-14/dbminit.c/#L99

  https://sources.debian.org/src/gdbm/1.18.1-4/compat/dbmopen.c/#L78

As git doesn't store hard links, this broke when I copied
the files around and committed them to git.

What a mess. At least I now know I wasn't *that* careless :)

Possibly I need to tar the files, or just recreate the hard links in
the autopkgtest check. Will try to come up with something tomorrow.
-- 
Niko

Bug#524458: Still a problem? NFS version?

[Elliott Mitchell]

It has been quite some time since there was last any activity on #524458.
Is this problem still occuring for the submitter?  Might it have been
fixed in one of the update rounds?

If this is still a problem, what version of the NFS protocol is in use?
In theory NFSv2 should be able to handle files under 2GB, but perhaps a
limitation of Linux's NFS client or NFS server made a 176MB file be a
problem.  Version 3 of the protocol is widely supportted, I'd suggest
moving to version 3 or version 4 if this mount is still on version 2.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#926040: u-boot: Please support Olimux Teres-I DIY laptop

[Jonas Smedegaard]

Quoting Vagrant Cascadian (2019-03-30 19:32:10)
> On 2019-03-30, Jonas Smedegaard wrote:
> > As subject says, please have u-boot support Olimux Teres-I DIY laptop.
> 
> Great!
> 
> 
> > The 2 patches I have put together at
> > https://salsa.debian.org/js/u-boot/tree/master/debian/patches/sunxi
> > works succesfully on my laptop, when used together with
> > https://salsa.debian.org/js/u-boot/commit/532adee and
> > https://salsa.debian.org/js/u-boot/commit/85402df
> 
> I've glanced at the changes, and overall they look ok. A little more
> invasive than one might want this late in the freeeze, though...

As you maybe noticed from the history of the git, I first tried older 
more minimal patches, before I stumbled upon this current one which 
actually works for me: Today was first time ever that I booted my 
Teres-I off of an up-to-date (and then patched) u-boot.

As I noted a moment ago at 
https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I#A2019.01_fork 
I suspect the patch include some legacy parts no longer needed with 
arm-trusted-firmware 2.0.  But I am hesitant messing with it myself due 
to my quite limited skills here.


> Have the patches been submitted upstream? Is the added .dts based on 
> the one included in the linux kernel?

Short version: No.

I am not in contact with the author of the patch, just lifted it our of 
their rpm source package and applied ot to our u-boot package.

This is as far as I know the newest conversation related to this (and 
the post that clued me in on searching for work done by Torsten Duwe): 
https://lkml.org/lkml/2019/2/4/1012

My understanding is that it is is being pushed to Linux kernel actively 
by Icenowy Zheng, and for u-boot seemingly only exists as the work by 
Torsten Duwe which seemingly is not pushing it upstream actively.

My (wild) guess is that Icenowy will push it to u-boot when in Linux.


> It would be helpful to either include the patches in the bug report, 
> or submit a merge request on salsa.debian.org. Mixing the two methods 
> feels a bit suboptimal to me.

I was awaiting your response to know what you preferred.

I am not familiar with Gitlab merge requests, but am willing to try if 
guided.  But easiest for me is to simply push directly to the u-boot git 
if that's ok with you (I got write access already since you put it in 
the debian area on salsa).  If you want me to add it in a separate 
branch, then what branch name do you prefer?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#900573: qreator: Proposed patch to fix the crash

[Andreas Boll]

On Thu, Mar 28, 2019 at 10:22:31PM +0800, Chow Loong Jin wrote:
> On Wed, Mar 27, 2019 at 10:31:35PM +0100, Andreas Boll wrote:
> > Control: severity -1 serious
> > Control: tags -1 + patch
> > 
> > Dear maintainer,
> > 
> > I've prepared a patch to fix this issue.
> > Also currently the package qreator isn't useful at all with this issue
> > because it crashes on startup. Thus bumping severity to serious
> > because this package shouldn't end up in Debian Buster without a fix
> > for this issue.
> > 
> > Please let me know if I should upload this fix as NMU or if you like
> > to upload it yourself.
> 
> Please go ahead and upload this fix. Thanks.
> 
> -- 
> Kind regards,
> Loong Jin

Cool, I've uploaded it to sid now.
Attached is the nmudiff.

Thanks,
Andreas
diff -Nru qreator-16.06.1/debian/changelog qreator-16.06.1/debian/changelog
--- qreator-16.06.1/debian/changelog	2018-04-14 14:48:31.0 +0200
+++ qreator-16.06.1/debian/changelog	2019-03-30 20:35:12.0 +0100
@@ -1,3 +1,11 @@
+qreator (16.06.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Fix-python-pil-imports.patch, fixes a program crash due to
+incorrect PIL imports (Closes: #900573).
+
+ -- Andreas Boll   Sat, 30 Mar 2019 20:35:12 +0100
+
 qreator (16.06.1-3) unstable; urgency=medium
 
   * [207e2e1] Port qreator to libnm (Closes: #857227)
diff -Nru qreator-16.06.1/debian/patches/Fix-python-pil-imports.patch qreator-16.06.1/debian/patches/Fix-python-pil-imports.patch
--- qreator-16.06.1/debian/patches/Fix-python-pil-imports.patch	1970-01-01 01:00:00.0 +0100
+++ qreator-16.06.1/debian/patches/Fix-python-pil-imports.patch	2019-03-27 21:45:38.0 +0100
@@ -0,0 +1,22 @@
+Author: Andreas Boll 
+Date:   Wed Mar 27 21:09:41 2019 +0100
+
+Fix python-pil imports
+
+Fixes bug #900573
+
+diff --git a/qreator/QRCode.py b/qreator/QRCode.py
+index d3a0130..930a538 100644
+--- a/qreator/QRCode.py
 b/qreator/QRCode.py
+@@ -20,8 +20,8 @@ try:
+ except ImportError:
+ print "You need to install the python-qrencode package"
+ sys.exit(1)
+-import Image
+-import ImageOps
++from PIL import Image
++from PIL import ImageOps
+ import cairo
+ import array
+
diff -Nru qreator-16.06.1/debian/patches/series qreator-16.06.1/debian/patches/series
--- qreator-16.06.1/debian/patches/series	2018-04-14 14:48:31.0 +0200
+++ qreator-16.06.1/debian/patches/series	2019-03-27 21:45:54.0 +0100
@@ -3,3 +3,4 @@
 Port-to-geoclue-2.0.patch
 Port-to-libnm.patch
 Fix-IndexError-when-a-wifi-network-has-100-strength.patch
+Fix-python-pil-imports.patch


signature.asc
Description: PGP signature

Bug#917793: [debian-mysql] Bug#917793: Bug#917793: Automatically update MariaDB plugin paths libmariadb18 -> libmariadb19 on upgrade from MariaDB 10.1 to MariaDB 10.3

[Otto Kekäläinen]

Looking at current table contents looks like there are no paths or
soname versions stored at all:

MariaDB [mysql]> select * from plugin;
+--++
| name | dl |
+--++
| auth_socket  | auth_socket.so |
| mroonga  | ha_mroonga.so  |
| spider   | ha_spider.so   |
| spider_alloc_mem | ha_spider.so   |
+--++

Bug#926044: linux-image-4.19.0-4-amd64: amd_iommu and pcie 2.0 1x USB3 controller card

[Michael Rasmussen]

Package: src:linux
Version: 4.19.28-2
Severity: normal

Dear Maintainer,

I don't know whether this is related to the kernel or the motherboard but if 
amd_iommu=on is given as kernel boot parameter my external pcie 2.0 1x USB3 
controller card stops working. I have tried with kernels 4.18.x, 4.19.x, and 
5.0.x with same result.

Hardware:
Motherboard: Asrock B450 pro4
CPU: AMD Ryzen 7 1700

>From syslog:
Mar 30 10:17:33 sleipner kernel: [   46.126124] xhci_hcd :19:00.0: WARNING: 
Host System Error
Mar 30 10:17:33 sleipner kernel: [   46.126197] xhci_hcd :19:00.0: AMD-Vi: 
Event logged [IO_PAGE_FAULT domain=0x address=0xffe6f000 
flags=0x]
Mar 30 10:17:33 sleipner kernel: [   46.173112] xhci_hcd :19:00.0: Host 
halt failed, -110
Mar 30 10:18:09 sleipner kernel: [   82.157657] xhci_hcd :19:00.0: xHCI 
host not responding to stop endpoint command.
Mar 30 10:18:09 sleipner kernel: [   82.204584] xhci_hcd :19:00.0: Host 
halt failed, -110
Mar 30 10:18:09 sleipner kernel: [   82.204587] xhci_hcd :19:00.0: xHCI 
host controller not responding, assume dead
Mar 30 10:18:09 sleipner kernel: [   82.204606] xhci_hcd :19:00.0: HC died; 
cleaning up


-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-4-amd64 
root=UUID=aee6bc10-58e7-4966-a6c1-f1822dcee938 ro cgroup_enable=memory 
pnpacpi=off iommu=1 amd_iommu=off slab_common.usercopy_fallback=Y 
elevator=deadline

** Tainted: PWOE (12801)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[7.084304] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.1/:1f:00.1/sound/card1/input17
[7.289961] bridge: filtering via arp/ip/ip6tables is no longer available by 
default. Update your scripts to load br_netfilter if you need this.
[7.294233] br0: port 1(enp28s0) entered blocking state
[7.295841] br0: port 1(enp28s0) entered disabled state
[7.297562] device enp28s0 entered promiscuous mode
[7.387133] 8021q: adding VLAN 0 to HW filter on device enp28s0
[7.393327] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready
[9.937130] e1000e: enp28s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None
[9.938196] br0: port 1(enp28s0) entered blocking state
[9.938910] br0: port 1(enp28s0) entered forwarding state
[9.939735] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
[   10.945461] vmbr9: port 1(enp28s0.9) entered blocking state
[   10.947190] vmbr9: port 1(enp28s0.9) entered disabled state
[   10.949035] device enp28s0.9 entered promiscuous mode
[   10.955487] vmbr9: port 1(enp28s0.9) entered blocking state
[   10.957222] vmbr9: port 1(enp28s0.9) entered forwarding state
[   11.139733] vmbr20: port 1(enp28s0.20) entered blocking state
[   11.141486] vmbr20: port 1(enp28s0.20) entered disabled state
[   11.143304] device enp28s0.20 entered promiscuous mode
[   11.150842] vmbr20: port 1(enp28s0.20) entered blocking state
[   11.152582] vmbr20: port 1(enp28s0.20) entered forwarding state
[   11.344742] vmbr30: port 1(enp28s0.30) entered blocking state
[   11.346471] vmbr30: port 1(enp28s0.30) entered disabled state
[   11.348319] device enp28s0.30 entered promiscuous mode
[   11.355114] vmbr30: port 1(enp28s0.30) entered blocking state
[   11.355875] vmbr30: port 1(enp28s0.30) entered forwarding state
[   11.538429] vmbr300: port 1(enp28s0.300) entered blocking state
[   11.540147] vmbr300: port 1(enp28s0.300) entered disabled state
[   11.541881] device enp28s0.300 entered promiscuous mode
[   11.550249] vmbr300: port 1(enp28s0.300) entered blocking state
[   11.551770] vmbr300: port 1(enp28s0.300) entered forwarding state
[   11.736278] vmbr900: port 1(enp28s0.900) entered blocking state
[   11.737894] vmbr900: port 1(enp28s0.900) entered disabled state
[   11.739580] device enp28s0.900 entered promiscuous mode
[   11.745832] vmbr900: port 1(enp28s0.900) entered blocking state
[   11.747774] vmbr900: port 1(enp28s0.900) entered forwarding state
[   11.937058] vmbr1000: port 1(enp28s0.1000) entered blocking state
[   11.938670] vmbr1000: port 1(enp28s0.1000) entered disabled state
[   11.940361] device enp28s0.1000 entered promiscuous mode
[   11.946489] vmbr1000: port 1(enp28s0.1000) entered blocking state
[   11.947150] vmbr1000: port 1(enp28s0.1000) entered forwarding state
[   12.115035] usblp2: removed
[   12.132204] vmbr1100: port 1(enp28s0.1100) entered blocking state
[   12.133968] vmbr1100: port 1(enp28s0.1100) entered disabled state
[   12.134018] usblp 1-10:1.0: usblp2: USB Bidirectional printer dev 3 if 0 alt 
0 proto 2 vid 0x0922 pid 0x1002
[   12.135636] device enp28s0.1100 entered promiscuous mode
[   12.143253] vmbr1100: port 1(enp28s0.1100) entered blocking state
[   12.143930] vmbr1100: 

Bug#925202: Keep calypso out of testing/buster

[Keith Packard]

Ivo De Decker  writes:

> I added a removal hint to get it out of testing.

I saw that after I uploaded 2.0-1... I'd been meaning to get back to
calypso for quite a while but got stuck because the various Python2
dependencies were no longer supported and yet some were not yet
available for Python3. With everything now available in Python3, it was
a fairly simple matter to transition the rest of the code over to the
newer version, which should make it far more maintainable going forward.

In addition, Python 3.7 has ThreadingHTTPServer, which means a
long-standing issue of supporting only one connection at a time has been
resolved. With that, Calypso can start to become a more complete caldav
solution, although there are still many little things to work on.

I'd be fine with having 1.5-5 not shipped in testing; it's certainly not
going to be supportable for the length of the next stable release.

> However, please note that there was a new upload in unstable. The history for
> that version doesn't include the history for 1.5-1 to 1.5-5. I don't know if
> that was intentional. I updated the metadata for this bug to make sure it
> affects both. I might be good to consolidate the history of the
> package.

Agreed; there are several useful patches on the agx debian branch but
I'd lost track of that as the package hadn't been transitioned over to
salsa. I've created a salsa project now and anyone should be able to
make changes there.

Please feel free to hack on the code if you like. For instance, getting
Guido's autopkgtest bits re-integrated would be awesome. There are also
a couple of bug reports against 1.5 and it would be good to check and
see if they're still valid against 2.0.

-- 
-keith


signature.asc
Description: PGP signature

Bug#924018: RM: python3.6 -- superseded by python3.7

[Scott Kitterman]

This removal is done now.

Documenting the cruft left behind for the future:

# Broken Depends:
ecflow: python3-ecflow [kfreebsd-amd64 kfreebsd-i386]
gdb: gdb [hurd-i386]
 gdb-multiarch [hurd-i386]
glom: glom [kfreebsd-amd64 kfreebsd-i386]
  libglom-1.30-0 [kfreebsd-amd64 kfreebsd-i386]
libixion: python3-ixion [hurd-i386]
libkolabxml: python3-kolabformat [kfreebsd-amd64 kfreebsd-i386]
libpeas: libpeas-1.0-0 [kfreebsd-amd64 kfreebsd-i386]
libxml2: python3-libxml2 [kfreebsd-amd64 kfreebsd-i386]
 python3-libxml2-dbg [kfreebsd-amd64 kfreebsd-i386]
ovito: ovito [amd64 arm64 i386 mips mips64el mipsel ppc64el s390x]
plplot: python3-plplot [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-plplot-qt [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
poezio: poezio
pyotherside: pyotherside-tests [kfreebsd-i386]
pyqt5: python3-pyqt5 [kfreebsd-amd64 kfreebsd-i386]
   python3-pyqt5.qtquick [kfreebsd-amd64 kfreebsd-i386]
pyside: libpyside-py3-1.2 [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.phonon [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtcore [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtdeclarative [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtgui [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qthelp [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtnetwork [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtopengl [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtscript [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtsql [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtsvg [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qttest [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtuitools [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtwebkit [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtxml [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python-escript: python3-escript [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python-numpy: python3-numpy [kfreebsd-amd64 kfreebsd-i386]
pythonqt: libpythonqt-qt5-python3-3 [kfreebsd-amd64 kfreebsd-i386]
  libpythonqt-qtall-qt5-python3-3 [kfreebsd-amd64 kfreebsd-i386]
ros-image-common: python3-camera-calibration-parsers [kfreebsd-amd64]
ros-ros-comm: python3-roslz4 [kfreebsd-amd64 kfreebsd-i386]
uwsgi: uwsgi-plugin-python3 [kfreebsd-amd64 kfreebsd-i386]
vim: vim-athena [kfreebsd-amd64 kfreebsd-i386]
 vim-gtk [kfreebsd-amd64 kfreebsd-i386]
 vim-gtk3 [kfreebsd-amd64 kfreebsd-i386]
 vim-nox [kfreebsd-amd64 kfreebsd-i386]
wxpython4.0: python3-wxgtk-media4.0 [kfreebsd-amd64 kfreebsd-i386]
 python3-wxgtk-webview4.0 [kfreebsd-amd64 kfreebsd-i386]
 python3-wxgtk4.0 [kfreebsd-amd64 kfreebsd-i386]
zeroc-ice: python3-zeroc-ice [kfreebsd-amd64 kfreebsd-i386]

Scott K

Bug#876893: Patch for multiple security issues

[Moritz Mühlenhoff]

Attached patch fixes most open security issues in testing/sid
(as applied by Leonidas S. Barbosa in Ubuntu), but needs
additional work to deal with the versioned symbols fallout
caused by GCC changes which happened after the last exiv upload
to sid.
diff -Nru exiv2-0.25/debian/patches/CVE-2017-11591.patch exiv2-0.25/debian/patches/CVE-2017-11591.patch
--- exiv2-0.25/debian/patches/CVE-2017-11591.patch	1970-01-01 01:00:00.0 +0100
+++ exiv2-0.25/debian/patches/CVE-2017-11591.patch	2019-02-26 00:40:56.0 +0100
@@ -0,0 +1,27 @@
+Index: exiv2-0.25/include/exiv2/value.hpp
+===
+--- exiv2-0.25.orig/include/exiv2/value.hpp
 exiv2-0.25/include/exiv2/value.hpp
+@@ -1657,11 +1657,12 @@ namespace Exiv2 {
+ ok_ = true;
+ return static_cast(value_[n]);
+ }
++#define LARGE_INT 100
+ // Specialization for rational
+ template<>
+ inline long ValueType::toLong(long n) const
+ {
+-ok_ = (value_[n].second != 0);
++ok_ = (value_[n].second != 0 && -LARGE_INT < value_[n].first && value_[n].first < LARGE_INT);
+ if (!ok_) return 0;
+ return value_[n].first / value_[n].second;
+ }
+@@ -1669,7 +1670,7 @@ namespace Exiv2 {
+ template<>
+ inline long ValueType::toLong(long n) const
+ {
+-ok_ = (value_[n].second != 0);
++ok_ = (value_[n].second != 0 && value_[n].first < LARGE_INT);
+ if (!ok_) return 0;
+ return value_[n].first / value_[n].second;
+ }
diff -Nru exiv2-0.25/debian/patches/CVE-2017-11683.patch exiv2-0.25/debian/patches/CVE-2017-11683.patch
--- exiv2-0.25/debian/patches/CVE-2017-11683.patch	1970-01-01 01:00:00.0 +0100
+++ exiv2-0.25/debian/patches/CVE-2017-11683.patch	2019-02-26 00:40:56.0 +0100
@@ -0,0 +1,42 @@
+From 1f1715c086d8dcdf5165b19164af9aee7aa12e98 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Dan=20=C4=8Cerm=C3=A1k?= 
+Date: Fri, 6 Oct 2017 00:37:43 +0200
+Subject: [PATCH] =?UTF-8?q?Use=20nullptr=20check=20instead=20of=20assertio?=
+ =?UTF-8?q?n,=20by=20Rapha=C3=ABl=20Hertzog?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Source:
+https://github.com/Exiv2/exiv2/issues/57#issuecomment-333086302
+
+tc can be a null pointer when the TIFF tag is unknown (the factory
+then returns an auto_ptr(0)) => as this can happen for corrupted
+files, an explicit check should be used because an assertion can be
+turned of in release mode (with NDEBUG defined)
+
+This also fixes #57
+---
+ src/tiffvisitor.cpp | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/src/tiffvisitor.cpp
 b/src/tiffvisitor.cpp
+@@ -1290,11 +1290,12 @@ namespace Exiv2 {
+ }
+ uint16_t tag = getUShort(p, byteOrder());
+ TiffComponent::AutoPtr tc = TiffCreator::create(tag, object->group());
+-// The assertion typically fails if a component is not configured in
+-// the TIFF structure table
+-assert(tc.get());
+-tc->setStart(p);
+-object->addChild(tc);
++if (tc.get()) {
++tc->setStart(p);
++object->addChild(tc);
++} else {
++   EXV_WARNING << "Unable to handle tag " << tag << ".\n";
++}
+ p += 12;
+ }
+ 
diff -Nru exiv2-0.25/debian/patches/CVE-2017-14859_14862_14864.patch exiv2-0.25/debian/patches/CVE-2017-14859_14862_14864.patch
--- exiv2-0.25/debian/patches/CVE-2017-14859_14862_14864.patch	1970-01-01 01:00:00.0 +0100
+++ exiv2-0.25/debian/patches/CVE-2017-14859_14862_14864.patch	2019-02-26 00:40:56.0 +0100
@@ -0,0 +1,74 @@
+Backported of:
+
+Description: Fix CVE-2017-14864, CVE-2017-14862 and CVE-2017-14859
+Origin: backport, https://github.com/Exiv2/exiv2/pull/110
+Last-Update: 2017-10-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: exiv2-0.25/src/error.cpp
+===
+--- exiv2-0.25.orig/src/error.cpp
 exiv2-0.25/src/error.cpp
+@@ -106,7 +106,9 @@ namespace {
+ { 50, N_("Multiple TIFF array element tags %1 in one directory") }, // %1=tag number
+ { 51, N_("TIFF array element tag %1 has wrong type") }, // %1=tag number
+ { 52, N_("%1 has invalid XMP value type `%2'") }, // %1=key, %2=value type
+-{ 58, N_("corrupted image metadata") }
++{ 57, N_("invalid memory allocation request") },
++{ 58, N_("corrupted image metadata") },
++{ 59, N_("Arithmetic operation overflow") },
+ };
+ 
+ }
+Index: exiv2-0.25/src/tiffvisitor.cpp
+===
+--- exiv2-0.25.orig/src/tiffvisitor.cpp
 exiv2-0.25/src/tiffvisitor.cpp
+@@ -47,6 +47,7 @@ EXIV2_RCSID("@(#) $Id: tiffvisitor.cpp 3
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ // 

Bug#926043: CVE-2019-0816

[Moritz Muehlenhoff]

Package: cloud-init
Severity: grave
Tags: security

This was assigned CVE-2019-0816:
https://code.launchpad.net/~jasonzio/cloud-init/+git/cloud-init/+merge/363445
https://support.microsoft.com/en-us/help/4491476/extraneous-ssh-public-keys-added-to-authorized-keys-file-on-linux-vm

Is this something that affects cloud-init as shipped in Debian or in the way we 
generate Debian
images for Azure?

Cheers,
Moritz

Bug#924965: libssh2: CVE-2019-3855 CVE-2019-3856 CVE-2019-3857 CVE-2019-3858 CVE-2019-3859 CVE-2019-3860 CVE-2019-3861 CVE-2019-3862 CVE-2019-3863

[Salvatore Bonaccorso]

Hi,

On Tue, Mar 19, 2019 at 10:23:22AM +0100, Salvatore Bonaccorso wrote:
> Source: libssh2
> Version: 1.8.0-2
> Severity: grave
> Tags: security upstream
> Control: found -1 1.7.0-1
> 
> Hi,
> 
> The following vulnerabilities were published for libssh2.
[...]

Trying to work on a NMU and should be ready soon for debdiff proposal
and upload to delayed queue.

Regards,
Salvatore

Bug#918320: (no subject)

[Jonathan Dupart]

user debian-rele...@lists.debian.org
usertags 918320 + bsp-2019-03-fr-paris
hank you

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[GCS]

Hi Steven,

On Sat, Feb 2, 2019 at 10:03 AM Steven Shiau  wrote:
> The mksquashfs from squashfs-tools 1:4.3-11 somehow can not make use all
> CPU cores. I found this when making a Debian live Sid system on my
> Stretch amd64 machine. Hence I have tried different versions of
> squashfs-tools. For mksquashfs from squashfs-tools 1:4.3-11 , I ran it by:
> time sudo mksquashfs squashfs-root filesystem.squashfs.new -b 1024k
> -comp xz -Xbcj x86 -e boot -no-progress
 Is there any way I can generate that set of files / directory you are
using for mksquashfs?
Anyway, please try the upcoming squashfs-tools package release[1] and
report back to me. Indeed it is slower than -9 on my data, but only
around 20%.

Thanks in advance,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/squashfs-tools_4.3-12.dsc

Bug#917501: Attempt to work on the bug

[Giovanni Mascellani]

user debian-rele...@lists.debian.org

usertags 917501 + bsp-2019-03-fr-paris
thank you

Hi,

I tried to work on this bug for a few hours, but I am quite puzzled:
first of all, the issue I am experiencing right now is different from
what is already described in the bug log. If I build meson with sbuild
it fails because the test "test_generate_gir_with_address_sanitizer" in
run_unittests.py fails (if I comment out that test, the package builds
correctly).

Such test consists in configuring and compiling the directory "test
cases/frameworks/7 gnome" using meson, passing the options
"-Db_sanitize=address -Db_lundef=false" to meson itself. Well, if I do
that myself "by hand" meson and the compilation work without problems.

I have tried in many ways to replicate the failure, for example by
checking thoroughly passed options and environment variables, but I
could not find the core point. So I am leaving this issue for the moment.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#924562: (no subject)

[Jonathan Dupart]

user debian-rele...@lists.debian.org
usertags 924562 + bsp-2019-03-fr-paris
thank you

Bug#926040: u-boot: Please support Olimux Teres-I DIY laptop

[Vagrant Cascadian]

On 2019-03-30, Jonas Smedegaard wrote:
> As subject says, please have u-boot support Olimux Teres-I DIY laptop.

Great!


> The 2 patches I have put together at
> https://salsa.debian.org/js/u-boot/tree/master/debian/patches/sunxi
> works succesfully on my laptop, when used together with
> https://salsa.debian.org/js/u-boot/commit/532adee and
> https://salsa.debian.org/js/u-boot/commit/85402df

I've glanced at the changes, and overall they look ok. A little more
invasive than one might want this late in the freeeze, though...

Have the patches been submitted upstream? Is the added .dts based on the
one included in the linux kernel?

It would be helpful to either include the patches in the bug report, or
submit a merge request on salsa.debian.org. Mixing the two methods feels
a bit suboptimal to me.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#925899: lxc: Unprivileged containers fail to start after recent updates

[Regis Smith]

Hi!  Thanks for replying.

On Sat, 30 Mar 2019 14:51:47 +0100 Pierre-Elliott =?utf-8?B?QsOpY3Vl?=
 wrote:
> Le mercredi 27 mars 2019 à 22:08:49-0700, Regis Smith a écrit :
> > Package: lxc
> > Version: 1:3.1.0+really3.0.3-6
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > 
> > apt update; apt upgrade
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> > As a normal user:
> > $ lxc-start -n test
> > 
> >* What was the outcome of this action?
> > 
> > lxc-start: test: lxccontainer.c: wait_on_daemonized_start: 833 No
such file or directory - Failed to receive the container state
> > lxc-start: test: tools/lxc_start.c: main: 330 The container failed
to start
> > lxc-start: test: tools/lxc_start.c: main: 333 To get more details,
run the container in foreground mode
> > lxc-start: test: tools/lxc_start.c: main: 336 Additional
information can be obtained by setting the --logfile and --logpriority
options
> > 
> > If I run it in the foreground instead I get
> > 
> > $ lxc-start -n test -F
> > lxc-start: test: lsm/apparmor.c: apparmor_prepare: 974 Cannot use
generated profile: apparmor_parser not available
> > lxc-start: test: start.c: lxc_init: 899 Failed to initialize LSM
> > lxc-start: test: start.c: __lxc_start: 1917 Failed to initialize
container "test"
> > lxc-start: test: tools/lxc_start.c: main: 330 The container failed
to start
> > lxc-start: test: tools/lxc_start.c: main: 336 Additional
information can be obtained by setting the --logfile and --logpriority
options
> > 
> >* What outcome did you expect instead?
> > 
> > A running container.  These used to work up until recently.  Now I
can't stop
> > already running containers because I won't be able to restart them.
> 
> Hi,
> 
> Thanks for submitting this bug.
> 
> As you can see, it is possible to get more debug via the --logfile
and
> the --logpriority options.
> 
> That said, the first line with the -F option says it all:
> 
> > lxc-start: test: lsm/apparmor.c: apparmor_prepare: 974 Cannot use
> > generated profile: apparmor_parser not available
> 
> It means that you're lacking the apparmor_parser command, which is
> shipped by apparmor. It probably means that you refused to install
> apparmor on your host.

Actually, I do have apparmor installed, and I can run apparmor_parser
as root.  aa-status shows all the related "lxc-container-*" in enforce
mode. Priveleged containers work fine, but I can not start unprivileged
containers.  Both privileged and unpriveleged worked fine before the
updates over the past several weeks.

> 
> You have multiple choices. The first one being installing apparmor,
and
> the second one being to edit your container's configuration (or the
> /etc/lxc/default.conf file) to change the lxc.apparmor.profile
> parameter.
> 
> This bugreport raises an interesting question regarding the tradeoff

I attached the log from running

$ lxc-start -n test --logpriority DEBUG --logfile lxc.log

I commented out "apparmor.profile = generated" and it still doesn't
work.  I'd like to get this working with apparmor, since it's the
default.  However, I'd love to hear from anyone who has unprivileged
containers working on an up-to-date Buster.  The fickleness of LXC in
Stretch wore me out, so I was quite pleased when it worked reliably in
Buster, up until now.

Regis

lxc-start test 20190330180301.167 INFO confile - confile.c:set_config_idmaps:1605 - Read uid map: type u nsid 0 hostid 10 range 65536
lxc-start test 20190330180301.167 INFO confile - confile.c:set_config_idmaps:1605 - Read uid map: type g nsid 0 hostid 10 range 65536
lxc-start test 20190330180301.168 INFO lxccontainer - lxccontainer.c:do_lxcapi_start:961 - Set process title to [lxc monitor] /home/rsmith/.local/share/lxc test
lxc-start test 20190330180301.168 INFO lsm - lsm/lsm.c:lsm_init:50 - LSM security driver AppArmor
lxc-start test 20190330180301.169 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "reject_force_umount  # comment this to allow umount -f;  not recommended"
lxc-start test 20190330180301.169 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start test 20190330180301.169 INFO seccomp - seccomp.c:parse_config_v2:937 - Added native rule for arch 0 for reject_force_umount action 0(kill)
lxc-start test 20190330180301.169 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start test 20190330180301.169 INFO seccomp - seccomp.c:parse_config_v2:946 - Added compat rule for arch 1073741827 for reject_force_umount action 0(kill)
lxc-start test 20190330180301.169 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start test 20190330180301.169 INFO seccomp - seccomp.c:parse_config_v2:956 - Added compat rule for arch 1073741886 for reject_force_umount action 0(kill)
lxc-start 

Bug#915319: Further triaging

[Giovanni Mascellani]

Il 30/03/19 19:14, Scott Kitterman ha scritto:
> Is there anything left in the archive that uses this functionality?

I am not sure this question is for me, but just in case: I have no idea.
I just met this bug during the Paris BSP, but I do not specific
knowledge of neither KDE nor CMake.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#915319: Further triaging

[Scott Kitterman]

On March 30, 2019 6:10:40 PM UTC, Giovanni Mascellani  wrote:
>user debian-rele...@lists.debian.org
>
>usertags 915319 + bsp-2019-03-fr-paris
>tags 915319 + patch
>thank you
>
>Hi,
>
>I did some further diagnosis on this bug: the reason why CMake fails to
>discover libsmbclient is because CMake tries to compile a little
>program
>including libsmbclient.h using -std=c90, which is insufficient for
>libsmbclient.h. However libsmbclient.h works with more recent C
>standards, like the GCC default -std=gnu11.
>
>The attached patch should fix the problem. I can NMU if this is ok for
>you. Probably it is not the cleanest solution ever (if would be better
>to fix CMake files from kdelibs5-dev), but it seems to work.
>
>Thanks, Giovanni.


Is there anything left in the archive that uses this functionality?

Scott K

Bug#915319: Further triaging

[Giovanni Mascellani]

user debian-rele...@lists.debian.org

usertags 915319 + bsp-2019-03-fr-paris
tags 915319 + patch
thank you

Hi,

I did some further diagnosis on this bug: the reason why CMake fails to
discover libsmbclient is because CMake tries to compile a little program
including libsmbclient.h using -std=c90, which is insufficient for
libsmbclient.h. However libsmbclient.h works with more recent C
standards, like the GCC default -std=gnu11.

The attached patch should fix the problem. I can NMU if this is ok for
you. Probably it is not the cleanest solution ever (if would be better
to fix CMake files from kdelibs5-dev), but it seems to work.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
From 5acb1dc95b67b14d9939ec54135c06b132996776 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani 
Date: Sat, 30 Mar 2019 18:59:00 +0100
Subject: [PATCH] Fix libsmbclient.h discovery.

---
 debian/changelog | 9 +
 debian/rules | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 60e7c0d..29b52fc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+kde-runtime (4:17.08.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Force usage of -std=gnu11 for CMake compilation, because CMake's default
+seems to be -std=c90 which makes libsmbclient.h discovery fail
+(closes: #915319).
+
+ -- Giovanni Mascellani   Sat, 30 Mar 2019 19:03:11 +0100
+
 kde-runtime (4:17.08.3-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/rules b/debian/rules
index a581bcd..25cc39a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@ include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk
 include /usr/share/dpkg/architecture.mk
 
 override_dh_auto_configure:
-	$(overridden_command) -- -DBUILD_khelpcenter=FALSE -DBUILD_drkonqi=FALSE
+	$(overridden_command) -- -DBUILD_khelpcenter=FALSE -DBUILD_drkonqi=FALSE -DCMAKE_REQUIRED_FLAGS="-std=gnu11"
 
 override_dh_auto_test:
 	# Disable dh_auto_test at build time
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#926042: torbrowser-launcher should not be included in Buster

[intrigeri]

Source: torbrowser-launcher
Version: 0.3.1-2
Severity: serious

Hi,

for basically the same reasons that made us not include
torbrowser-launcher in Stretch, IMO it should not be part of Buster
either:

1. This downloader package requires updates, from time to time, to
   cope with changes in how Tor Browser is distributed upstream
   (OpenPGP keys, URLs, SSL certificates, you name it).

2. One of the key bonuses brought by torbrowser-launcher, compared to
   installing Tor Browser as recommended by the Tor project, is that
   it ships AppArmor profiles. Debian Buster will ship with AppArmor
   enabled by default, so keeping these profiles in a shape that does
   not break Tor Browser will soon become a critical requirement.

   These profiles are currently in a poor shape. For example, Tor
   Browser runs under the wrong profile when it restarts after
   applying an upgrade, which breaks all kinds of functionality.

   These profiles need regular updates; whenever a new Tor Browser
   that requires such updates is needed, Debian stable users would
   have a broken Tor Browser until someone (generally me so far) have
   time to prepare such updates and submit them upstream, then someone
   on the pkg-privacy team includes them in an upload to sid, and
   finally backport them into some kind of stable update (presumably
   buster-updates, as waiting for the next Buster point-release can
   take up to 4 more months of breakage). I personally cannot commit
   to do my part of the work in a timely manner for the entire Buster
   lifetime; and I have doubt pkg-privacy can reasonably commit to do
   the rest of the work in a timely manner either.

3. torbrowser-launcher upstream maintains no LTS branch so fixing any
   problem of one of the aforementioned kinds in Debian stable would
   require us to backport the fix, somehow (and occasionally to
   prepare the fix ourselves, in case upstream is not reactive
   enough). I'm sure that this should be straightforward in many
   cases, but:

- It seems to me that during the Buster development cycle, we
  lacked the time+energy to backport such fixes to sid
  consistently. Adding another target for backports seems
  unreasonable to me.

- Major technology changes upstream can make such backports much
  harder. For example, torbrowser-launcher 0.3.0 switched from
  python2 to python3, from gtk2 to Qt5, and from twisted to
  requests/socks.

If my team-mates disagree and want to give it a try anyway, fine.
Then, I would strongly recommend disabling the AppArmor profiles in
Buster by default.

Cheers!
-- 
intrigeri

Bug#922339: unblock: python-cassandra-driver/3.16.0-1

[Paul Gevers]

tags 922339 wontfix
thanks

On Sun, 17 Mar 2019 17:38:21 + Jonathan Wiltshire 
wrote:
> On Thu, Feb 14, 2019 at 08:11:55PM +0100, Héctor Orón Martínez wrote:
> > Please unblock package python-cassandra-driver
> > 
> > I have been working with Emmanuel Arias on getting his package sponsored
> > into Debian, however it did not make it into Buster on time. It is a
> > `salt` build dependency (however `salt` package maintainer has disabled
> > it until it makes it in Buster).
> 
> Is the intention that salt will enable support once this package migrates?
> Will that require an unblock too?
> 
> #921658 seems to suggest that salt is only a test-time build dependency.
> Does this mean that not all of salt's tests are being run at the moment?
> What is the impact of this?
> 
> 2018-12-05 when the upload was prepared to 2019-02-08 when it was uploaded
> is quite a long delay. Is long-term maintenance assured? Are sufficient 
> sponsors available for the next 5-6 years?

I am closing this bug as wontfix as it is getting too late in the cycle
for new packages and the above questions were not answered.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#926041: unblock: bwa/0.7.17-3

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package bwa.

   [ Dylan Aïssi ]
   * Add patch from upstream to fix CVE-2019-10269.
   (Closes: #926014)

   [ Jelmer Vernooij ]
   * Trim trailing whitespace.


Thanks.
Dylan

Bug#922809: unblock: aac-tactics/8.8.0+1.gbp069dc3b-1

[Paul Gevers]

tags 922809 wontfix
thanks

Hi Benjamin,

On Tue, 12 Mar 2019 20:55:31 -0400 Benjamin Barenblat
 wrote:
> > Couldn't you just fix the FTBFS by patching the original version in
> > Debian? That would make reviewing a lot easier.
> 
> Perhaps, but unfortunately, I don’t have the time to write those patches
> right now. If the new version is too much to accept into buster at this
> point, please feel free to close this as a wontfix – I think the world
> can live without aac-tactics for one release cycle.

So, that is what I end up doing. It's getting to late into the cycle to
let new packages in.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#925919: RFT: linux with fix for VMware regression

[Werner Detter]

Hi Ben,

thanks for the updated version. I've installed the new version on one
affected machine which crashed after some hours with the old kernel.
It's currently running with the updated version since 9 hours without
problems. I'll get back to you.

Cheers,
Werner


Am 30.03.19 um 05:15 schrieb Ben Hutchings:
> I've uploaded a new version of linux to:
> https://people.debian.org/~benh/packages/jessie-security/
> which I believe will fix this regression (bug #925919).  Please let me
> know whether it works for you.
> 
> I only included the amd64 linux-image package and sources there, but
> can add i386 linux-image packages if needed.
> 
> Ben.
> 




signature.asc
Description: OpenPGP digital signature

Bug#926040: u-boot: Please support Olimux Teres-I DIY laptop

[Jonas Smedegaard]

Source: u-boot
Version: 2019.01+dfsg-3
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As subject says, please have u-boot support Olimux Teres-I DIY laptop.

The 2 patches I have put together at
https://salsa.debian.org/js/u-boot/tree/master/debian/patches/sunxi
works succesfully on my laptop, when used together with
https://salsa.debian.org/js/u-boot/commit/532adee and
https://salsa.debian.org/js/u-boot/commit/85402df


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlyfqskACgkQLHwxRsGg
ASGQ1RAAlvD59IcsGWNedQsAaicbmSatLKlT4BtHdIaREMcIMs1yAo/E4/lz9e82
pFzB//Vfdi048Vj0uGM7f1AD6etpw8Q8jIshnIUsR1imxdsZBwoZYtfICYCVmmU9
Cnjkfn7d/5CyOdTOwoG/vzZZEI/XY+HgEmN4HD1LQ9BeO+KSKmAqQnCYjjjFtbvW
KUZt5/C0TaZY7Bh4PVwbAWXUws0nol13JinmZCDyfFKn7+iTsVqSIF0az4TAPkjB
wlu4q7h1ZLbalIOMUwqfYrLzqC53xrgzssK+ZQghCwqvKs0O8KvUfpypApi9z62o
Voprd1jMxXU3dEUlh3WMZ0WaKOO6x+TjOL/C/a4XFgIPevDJyMwpIpkzA4/z1lI4
Ra+PgP6cXrw/R570Dx5iUgU85Z+cgXPOUJ+mbtYc3qP3EO6ASB3rKfdXx5v/g5rh
kToXQMM1PZb9b9H5QLU6SIgT4NpxV6/kSRk468RtJ0hebLQikADzl8fngJKIexqk
sRey3anRnPHN40o8RDp1TrfxkQMkgvJhN/RH31TZMyVKpjVxrvgEcnhit7ma/Sk9
u0bcNATdKOPJ21lvKteMfwMY8/4vTbTjiIrCaA/OjorBwCufx1+sIFNN5H4vdp1v
O+lPydd4H8j7zp8AXl29U7j5MleLUSuogtMSxm1/yjILhN2Eya8=
=heer
-END PGP SIGNATURE-

Bug#926039: "fixme" package: missing layout files

[Ryan Kavanagh]

Package: texlive-latex-extra
Version: 2018.20190227-1
Severity: normal

This package does not install all layout files for the fixme package.

For example, latex complains as follows on MWE below:

! LaTeX Error: File `fxlayoutmarginclue.sty' not found.

This is not the expected behaviour, based on my understanding of §3.5.2
of the FiXme manual (see: texdoc fixme).

##
minimal input file

\documentclass{minimal}
\usepackage{fixme}
\fxloadlayouts{marginclue}
\begin{document}
\end{document}

##
other files

##
 List of ls-R files

-rw-r--r-- 1 rak rak 118874 May 15  2016 /home/rak/.texmf/ls-R
-rw-rw-r-- 1 root staff 80 May 15  2016 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 1311 Mar 13 23:03 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28 09:28 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Mar  1 21:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Mar  1 21:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Mar  4 15:36 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Mar  1 21:27 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
-rw-r--r-- 1 rak rak 32 Jul 25  2017 /home/rak/.texmf/web2c/updmap.cfg
-rw-r--r-- 1 root root 3215 Mar  4 15:45 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep  2  2015 mktex.cnf
-rw-r--r-- 1 root root 475 Mar  4 15:36 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-2
ii  python 2.7.16-1
ii  tex-common 6.11
ii  texlive-base   2018.20190227-2
ii  texlive-binaries   2018.20181218.49446-2
ii  texlive-latex-recommended  2018.20190227-2
ii  texlive-pictures   2018.20190227-2

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2018.20190227-2
ii  texlive-plain-generic  2018.20190227-1

Versions of packages texlive-latex-extra suggests:
ii  icc-profiles2.1-2
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.3.1+dfsg-1
ii  texlive-latex-extra-doc 2018.20190227-1

Versions of packages tex-common depends on:
ii  dpkg  1.19.6
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.1.1

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.11
ii  texlive-binaries  2018.20181218.49446-2

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#926038: RM: libjogl2-jni [armel mips mipsel] -- RoQA ANAIS

[Ivo De Decker]

package: ftp.debian.org

Hi,

The latest upload of src:libjogl2-java removes armel, mips and mipsel from the
supported architectures. The only arch specific binary is libjogl2-jni, which
needs to be removed on these architectures.

This breaks libjogl2-java (arch: all) on these architectures, but that's
expected.

Thanks!

Ivo

Bug#902171: libvirt-clients: unsafe blockresize behaviour inconsistent with vol-resize

[intrigeri]

Control: severity -1 important

Hi,

thank you for reporting this bug to Debian. I concur with your
analysis; in particular, I appreciate that you're taking into account
how the behavior of other virsh commands sets users' expectations
which are not matched by blockresize. I encourage you to share your
analysis upstream:

  https://libvirt.org/
  https://www.redhat.com/mailman/listinfo/libvir-list

This being said, I disagree this bug should block the Buster release
and I'm thus challenging its RC severity for 2 reasons:

1. It seems that "virsh blockresize" was introduced, with this
behavior, about 7 years ago. I'm not aware of actual data loss
reported by Debian users during that time.

2. Considering the target audience of libvirt, which is mostly system
administrators rather than non-technical users, it seems reasonable to
have slightly higher expectations than usual wrt. reading the
blockresize's documentation before using it and wrt. having proper
backups, which makes the "causes serious data loss" justification
disputable IMHO.

Cheers,
-- 
intrigeri

Bug#926036: net-retriever: missing support for Acquire-By-Hash

[Julien Cristau]

Package: net-retriever
Version: 1.51
Severity: minor
Tags: patch

olasd tried to install his new laptop.  He got hashsum mismatches.  That
made him sad.  We don't want a sad olasd.

Patch up at
https://salsa.debian.org/jcristau/net-retriever/commit/2653045287c502399c31495e1dfd502e03efbc08

Cheers,
Julien

Bug#926035: net-retriever: missing support for InRelease

[Julien Cristau]

Package: net-retriever
Version: 1.51
Severity: minor
Tags: patch

Hi,

net-retriever downloads Release and Release.gpg instead of trying InRelease 
first.

Patch up at 
https://salsa.debian.org/jcristau/net-retriever/commit/1237e465cc83a0832c365f8b9f67f98943229dd6

Cheers,
Julien

Bug#890084: libvirt: error : unable to set AppArmor profile

[intrigeri]

Control: tag -1 + unreproducible

Hi Craig,

did this problem happen again? If it ever does, please share the
output of "sudo journalctl -u libvirtd.service" and the relevant
file timestamps.

I'm using libvirt + AppArmor heavily and have never seen it myself :/

Cheers,
-- 
intrigeri

Bug#900611: Re[2]: [Pkg-libvirt-maintainers] Bug#900611: libvirt-daemon-system: deamon not start, problem in apparmor config

[intrigeri]

Control: fixed -1 3.10.0-1

Hi,

rem_lex:
> fixed by add in to file /etc/apparmor.d/usr.sbin.libvirtd at line 39
> ///
> diff -au ./usr.sbin.libvirtd.old ./usr.sbin.libvirtd.new
> --- ./usr.sbin.libvirtd.old 2018-03-12 20:11:00.0 +0200
> +++ ./usr.sbin.libvirtd.new 2018-06-02 01:28:10.0 +0300
> @@ -36,6 +36,7 @@
>    network inet6 dgram,
>    network packet dgram,
>    network packet raw,
> +  network netlink raw,

I've fixed this upstream with commit 3b1d19e6c9500d392b6635de92877b725d214f7f,
that was first released in libvirt v3.10.0.

Cheers,
-- 
intrigeri

Bug#878121: Updates about BLAS64, co-installable variants

[Sébastien Villemot]

Le mardi 05 février 2019 à 03:34 +, Mo Zhou a écrit :

> I'd like to update the proposal again. Alerted by the threading issue
> about Octave+MKL, I changed my mind to make all variants co-installable
> so any user would have a chance to switch them without installation/removal.
> This proposal has been applied to BLIS (>= 0.5.1-8) already.
> 
> I believe this version of layout looks far much better.

Thanks. Indeed I also prefer the flat layout.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://seb
astien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: This is a digitally signed message part

Bug#926034: RFP: python-txjsonrpc -- code for creating Twisted JSON-RPC servers and clients

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: python-txjsonrpc
  Version : 0.5
  Upstream Author : Paul Hummer 
* URL : https://pypi.org/project/txJSON-RPC/
* License : MIT/X
  Programming Lang: Python
  Description : code for creating Twisted JSON-RPC servers and clients

txJSON-RPC allows you to create async Python JSON-RPC servers and
clients either over HTTP or directly on TCP with the Netstring protocol.
txJSON-RPC is written in Twisted.

This is a dependency for libervia (#725761).

Bug#864827: zotero-standalone: ask for removal?

[Sébastien Villemot]

Le mercredi 13 mars 2019 à 14:08 +0100, Félix Sipma a écrit :
> It may be time to ask for removal... What do you think?

Indeed. I have filed the removal request (see #926033).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://seb
astien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: This is a digitally signed message part

Bug#926033: RM: zotero-standalone-build -- ROM; outdated; RC buggy; orphaned

[Sébastien Villemot]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

Please remove zotero-standalone-build.

The package is now in bad shape, won’t be part of buster, and significant work
is needed to revive it.

I orphaned the package 6 months ago and nobody has showed up.

It’s better to remove it now instead of letting it bitrot.

Cheers,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#924418: libvirt-daemon-system: apparmor prevents libvirtd from spawning VMs

[intrigeri]

Control: tag -1 + moreinfo

Hi Robbie,

Robbie Harwood:
> When I attempt to spawn a QEMU/kvm VM (sudo virsh start vmname), it fails 
> with:

> error: Failed to start domain 7-1
> error: internal error: Process exited prior to exec: libvirt:  error : 
> unable to set AppArmor profile 'libvirt-16efecbc-66ca-4559-8558-7084588065d4' 
> for '/usr/bin/kvm': No existe el fichero o el directorio

> (That approximately translates to "The file or directory doesn't exist".  I
> set LC_ALL=en_US.utf8, but it didn't seem to be respected.)

> […]

> I don't know how to debug this further, but please let me know if there's more
> information I can provide.

Can you please share:

 - the libvirtd.service logs:

 sudo journalctl -u libvirtd.service

 - the logs for the affected guest, that you can find in
   /var/log/libvirt/qemu/

 - the output of the aa-status command

Also, does this affect all your VMs or only one?

Cheers,
-- 
intrigeri

Bug#846050: libvirt-daemon-system: Cannot create VM - cannot load AppArmor profile

[intrigeri]

Control: tag -1 + moreinfo

Hi,

> On Mon, Nov 28, 2016 at 02:16:38AM -0500, Derth Lambert wrote:
>> Trying to create a virtual machine using Virt-Manager interface OR import any
>> existing using "virsh define *.xml" result in:
>> 
>> Unable to complete install: 'internal error: cannot load AppArmor profile
>> 'libvirt-xxx--'

Can you still reproduce this problem on current Buster?
Worst case, on current Stretch?

Cheers,
-- 
intrigeri

Bug#926032: [chromium] Buggy / Solarized videos

[victor.boyau]

Package: chromium
Version: 73.0.3683.75-1
Severity: important

--- Please enter the report below this line. ---

A lot of streaming videos are rendered incorrectly and truly
unwatchable. Sound is not affected, however. Youtube videos look good
but not those streamed from other popular web sites like these ones :

https://www.imdb.com (try any movie trailer, e.g.)
https://www.francetvinfo.fr/en-direct/tv.html (any embedded video)

Downgrading to a previous version like 72.x either from stable
ou from testing immedialely solves the problem.

VB

--- System information. ---
Architecture: 
Kernel:   Linux 4.19.32-tz1903270806

Debian Release: 9.8
  990 stable-updates  deb.debian.org 
  990 stable  wire-app.wire.com 
  990 stable  download.webmin.com 
  990 stable  deb.debian.org 
  990 proposed-updates deb.debian.org 
  777 stretch-backports deb.debian.org 
  666 testing deb.debian.org 
  500 unstabledeb.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-=
libasound2   (>= 1.0.16) | 1.1.8-1
libatk-bridge2.0-0(>= 2.5.3) | 2.30.0-2~bpo9+1
libatk1.0-0   (>= 2.2.0) | 2.30.0-1~bpo9+1
libatomic1  (>= 4.8) | 8.3.0-4
libatspi2.0-0(>= 2.9.90) | 2.30.0-2~bpo9+1
libavcodec58  (>= 7:4.0) | 7:4.1.1-1
libavformat58 (>= 7:4.1) | 7:4.1.1-1
libavutil56   (>= 7:4.0) | 7:4.1.1-1
libc6  (>= 2.28) | 2.28-8
libcairo-gobject2(>= 1.10.0) | 1.16.0-4
libcairo2 (>= 1.6.0) | 1.16.0-4
libcups2  (>= 1.4.0) | 2.2.1-8+deb9u3
libdbus-1-3  (>= 1.9.14) | 1.12.12-1
libdrm2   (>= 2.3.1) | 2.4.97-1
libevent-2.1-6 (>= 2.1.8-stable) | 2.1.8-stable-4
libexpat1 (>= 2.0.1) | 2.2.0-2+deb9u1
libflac8  (>= 1.3.0) | 1.3.2-3
libfontconfig1   (>= 2.12.6) | 2.13.1-2
libfreetype6  (>= 2.3.9) | 2.9.1-3
libgcc1   (>= 1:4.0) | 1:8.3.0-4
libgdk-pixbuf2.0-0   (>= 2.22.0) | 2.38.1+dfsg-1
libglib2.0-0 (>= 2.31.8) | 2.58.3-1
libgtk-3-0   (>= 3.9.10) | 3.24.5-1
libharfbuzz0b (>= 2.2.0) | 2.3.1-1
libicu63(>= 63.1-1~) | 63.1-6
libjpeg62-turbo   (>= 1.5.0) | 1:1.5.2-2+b1
libjsoncpp1   (>= 1.7.4) | 1.7.4-3
liblcms2-2  (>= 2.2+git20110628) | 2.9-3
libminizip1 (>= 1.1) | 1.1-8+b1
libnspr4   (>= 2:4.9-2~) | 2:4.20-1
libnss3  (>= 2:3.22) | 2:3.42.1-1
libopenjp2-7  (>= 2.2.0) | 2.3.0-2
libopus0(>= 1.1) | 1.3-1
libpango-1.0-0   (>= 1.14.0) | 1.42.4-6
libpangocairo-1.0-0  (>= 1.14.0) | 1.42.4-6
libpci3   (>= 1:3.5.2-1) | 1:3.5.2-1
libpng16-16 (>= 1.6.2-1) | 1.6.36-5
libpulse0(>= 0.99.1) | 12.2-4
libre2-5   (>= 20160901) | 20190101+dfsg-2
libsnappy1v5 | 1.1.7-1
libstdc++6(>= 6) | 8.3.0-4
libva2(>= 1.0.3) | 2.4.0-1
libvpx5   (>= 1.6.0) | 1.7.0-3
libwebp6  (>= 0.5.1) | 0.6.1-2
libwebpdemux2 (>= 0.5.1) | 0.6.1-2
libwebpmux3 (>= 0.6.1-2) | 0.6.1-2
libx11-6 (>= 2:1.4.99.1) | 2:1.6.7-1
libx11-xcb1  | 2:1.6.7-1
libxcb1 (>= 1.6) | 1.13.1-2
libxcomposite1  (>= 1:0.3-1) | 1:0.4.4-2
libxcursor1   (>> 1.1.2) | 1:1.1.15-2
libxdamage1   (>= 1:1.1) | 1:1.1.4-3+b3
libxext6 | 2:1.3.3-1+b2
libxfixes3(>= 1:5.0) | 1:5.0.3-1

Bug#916587: AppArmor breaks virtio-gpu + virgl

[intrigeri]

Control: severity -1 important
Control: tag -1 + fixed-upstream

Hi,

bumping severity as this totally breaks an option offered to users via
virt-manager.

Now, I've verified that virt-manager in current sid still creates new
VMs with QXL graphics by default, so this bug only affects users who
opt in for virtio + 3D acceleration. As such, I'm unsure how much of
a stretch it would be to request a freeze exception — Guido, what do
you think?

If it helps, I'd be happy to test the corresponding upstream patches:

   commit f2cbb94eabdd5e3422c45b1afa48eb4c951c09e0
   Author: Christian Ehrhardt 
   Date:   Tue Mar 5 13:38:38 2019 +0100
   
   security: aa-helper: gl devices in sysfs at arbitrary depth
   
   commit 00fbb9e51678f76effa2d20e78a9be861ad5f484
   Author: Christian Ehrhardt 
   Date:   Fri Mar 1 07:25:59 2019 +0100
   
   security: aa-helper: nvidia rules for gl devices
   
   commit 27a9ebf28183cb3c3c784fcab622e67e978eb3dc
   Author: Christian Ehrhardt 
   Date:   Tue Feb 12 11:12:52 2019 +0100
   
   security: aa-helper: generate more rules for gl devices
   
   commit d85e8e400b48f1b4c1dfbf438dda83cd959eacf7
   Author: Christian Ehrhardt 
   Date:   Tue Feb 12 10:33:23 2019 +0100
   
   security: aa-helper: allow virt-aa-helper to read /dev/dri
   
   commit fb01e1a44daea773cd53f275cad6f031506c20db
   Author: Christian Ehrhardt 
   Date:   Mon Jan 14 15:15:06 2019 +0200
   
   virt-aa-helper: generate rules for gl enabled graphics devices

Cheers!

Bug#925604: unblock: ruby-doorkeeper-openid-connect/1.5.5-1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Wed, Mar 27, 2019 at 07:11:57PM +0530, Utkarsh Gupta wrote:
> Please unblock package ruby-doorkeeper-openid-connect.
> 
> There was a CVE bug (#924747) reported against the package with severity:
> grave.
> It was reported on 16th March and was resolved in the latest upload, which was
> on 24th March.
> Thus, requesting you to please unblock the same and let it be a part of 
> Buster,
> as was going to :)

This upload seems to include a number of changes other than the fix for the
security issue. This doesn't seem to comply with the freeze policy. Perhaps
you can clarify the changes. Otherwise, please revert the upload and upload a
targeted fix for this issue.

Thanks,

Ivo

Bug#925202: Keep calypso out of testing/buster

[Ivo De Decker]

Control: found -1 1.5

Hi,

On Thu, Mar 21, 2019 at 09:02:13AM +0100, Guido Günther wrote:
> Package: calypso
> Version: 1.5-5
> Severity: grave
> 
> Calypso has not seen much attention recently so it's likely better to
> not ship it in a stable release. It wasn't in stretch either so this
> will not affect current users.
> Cheers,
>  -- Guido

I added a removal hint to get it out of testing.

However, please note that there was a new upload in unstable. The history for
that version doesn't include the history for 1.5-1 to 1.5-5. I don't know if
that was intentional. I updated the metadata for this bug to make sure it
affects both. I might be good to consolidate the history of the package.

Cheers,

Ivo

Bug#923810: ITP: ruby-sassc -- Use libsass with Ruby

[Manas Kashyap]

As i talked with ruby-team , so they advised me on learning the new
techniques more and also as adding gbp.conf is a nice thing to do and
practice , so , i will keep it maintained in sass-team


On Thu, Mar 28, 2019 at 12:38 AM Jonas Smedegaard  wrote:

> Quoting Manas Kashyap (2019-03-27 17:37:49)
> > So, As Jonas said , that the way we do in ruby-team , keeping sbuild
> > happy and checking it from meta build command , is not similar to the
> > way it is maintained by sass team , so i would like to maintain this
> > ruby-sassc package in ruby-team , therefore i request , to please
> > delete the repo from sass team and i will ask in ruby-team to create a
> > desired repo and will add it there.
>
> Too bad this is the outcome, but that is your choice to make.
>
> You have the power in the Sass team to delete the repository yourself,
> but if you don't do that - e.g. if you unsubscribe from the team while
> leaving behind the repository - then I will clean up after you.
>
> Thanks for your interest in maintaining ruby-sassc, regardless how.
> Hope to hear more from you in the future.  Did you perhaps consider
> attending the next Debconf?  You are quite welcome!
>
>   https://debconf19.debconf.org/
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>

Bug#925934: RM: golang-gopkg-data-dog-go-sqlmock.v1/1.3.0-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi rajudev,

On 28-03-2019 21:36, rajudev wrote:
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> This was a dependency of golang-github-lucasb-eyer-go-colorful as estimated by
> dh-make-golang.
> https://salsa.debian.org/libregeekingkid-guest/micro/wikis/Dependency-Tree-of-Micro
> 
> Shengjing pointed it out that golang-github-data-dog-go-sqlmock-dev can be
> used for package which imports gopkg.in/DATA-DOG/go-sqlmock.v1
> 
> Hence I want this package to be removed.

Do you want it removed from Debian, or *only* from testing? In the
former case, please clone this bug to the ftp.debian.org pseudo package.

However, it can't be removed yet, as there are multiple packages (build)
depending on it, which need to be fixed first (see below). Did you
coordinate this removal request with the maintainers of those packages?

Paul

elbrus@respighi:~$ dak rm --no-action -R
golang-github-lucasb-eyer-go-colorful
Will remove the following packages from unstable:

golang-github-lucasb-eyer-go-colorful |  1.0-2 | source
golang-github-lucasb-eyer-go-colorful-dev |  1.0-2 | all

Maintainer: Debian Go Packaging Team 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
golang-github-gdamore-tcell: golang-github-gdamore-tcell-dev
golang-github-rivo-tview: golang-github-rivo-tview-dev
golang-github-zyedidia-tcell: golang-github-zyedidia-tcell-dev

# Broken Build-Depends:
golang-github-gdamore-tcell: golang-github-lucasb-eyer-go-colorful-dev
golang-github-rivo-tview: golang-github-lucasb-eyer-go-colorful-dev
golang-github-zyedidia-tcell: golang-github-lucasb-eyer-go-colorful-dev

Dependency problem found.

Bug#924232: python{,3}-notebook: unhandled symlink to directory conversion: /usr/lib/python{2.7,3}/dist-packages/notebook/static/components/bootstrap

[Sébastien Villemot]

user debian-rele...@lists.debian.org
usertags 924232 + bsp-2019-03-fr-paris
tags 924232 + patch pending
thank you

Dear Maintainer,

I am about to NMU a fix this bug. I submitted a merge request
corresponding to the contents of the upload:

https://salsa.debian.org/python-team/modules/jupyter-notebook/merge_requests/1/

Cheers,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://seb
astien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: This is a digitally signed message part

Bug#925327: gpsd: CVE-2018-17937

[Bernd Zeimetz]

Hi, 

totally agree,  although I'll also see what upgrading json.c  to the latest 
version gives for results.  That should not depend on the rest of the gpsd 
code. 

Am 30. März 2019 13:25:45 MEZ schrieb Markus Koschany :
>Hi,
>
>On Sat, 30 Mar 2019 08:32:34 +0100 Salvatore Bonaccorso
> wrote:
>> Hi Bernd,
>> 
>> On Fri, Mar 29, 2019 at 10:54:50PM +0100, Bernd Zeimetz wrote:
>> > Hi Salvatore,
>> > 
>> > > The following vulnerability was published for gpsd, not competely
>sure
>> > > on severity and on if the referenced upstream commit is enough.
>> > > Ideally though the fix seems ideal to go to buster.
>> > 
>> > I've tried to get more information out of Upstream, but did not get
>a
>> > reply yet. So I'll prepare an upload with the mentioned commit.
>Looking
>> > trough the commit logs from gpsd it seems to be the only relevant
>one.
>> 
>> Ack thank you for investigating, I was neither more successfull to
>> determine if that's enough.
>> 
>> Cc;ing the security team alias, if anyone has more ideas.
>
>I think I would also backport
>
>http://git.savannah.nongnu.org/cgit/gpsd.git/commit/json.c?id=9b3724cb7bca7a0776bcb9b054cd1d8d736278a4
>
>and
>
>http://git.savannah.nongnu.org/cgit/gpsd.git/commit/json.c?id=317375877576b10fd5312a7b0dec4a192881eead
>
>for good measure.
>
>But I agree that the essential fix seems to be
>
>http://git.savannah.nongnu.org/cgit/gpsd.git/commit/?id=7646cbd04055a50b157312ba6b376e88bd398c19
>
>Regards,
>
>Markus

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#926031: unblock: chromium/73.0.3683.75-1

[Michael Gilbert]

package: release.debian.org
user: release.debian@packages.debian.org
usertags: unblock

Please consider unblocking chromium.  This is a large upstream release
with a bunch of security fixes.  As has been done for the past few
stable releases, the plan is to push ongoing upstream security updates
to buster(-security).

Best wishes,
Mike

unblock chromium/73.0.3683.75-1

Bug#926030: RFP: python-plyer -- platform-independent wrapper for platform-dependent APIs

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: python-plyer
  Version : 1.4.0
  Upstream Author : Kivy team 
* URL : https://pypi.org/project/plyer/
* License : MIT/X
  Programming Lang: Python
  Description : platform-independent wrapper for platform-dependent APIs

 Plyer is a platform-independent api to use features commonly found on various
 platforms, notably mobile ones, in Python.

This is a dependency for Cagou (#897232).

Bug#926029: RM: python-pydap -- ROM; FTBFS; orphaned

[ghisvail]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-scie...@lists.debian.org
Control: affects -1 python-pydap

Please remove source package python-pydap from unstable.

This package fails to build with recent releases of Python and NumPy
(two RC bugs) and is no longer actively maintained by myself.

Best regards,
Ghislain

Bug#925899: lxc: Unprivileged containers fail to start after recent updates

[Pierre-Elliott Bécue]

Le 30 mars 2019 15:29:52 GMT+01:00, intrigeri  a écrit :
>Hi,
>
>Pierre-Elliott Bécue:
>> This bugreport raises an interesting question regarding the tradeoff
>> between the solution we implemented to fix bug #916639.
>
>> Cc-ing intrigeri: I'm reconsidering the /etc/lxc/default.conf setting
>> regarding apparmor.profile. Putting generated breaks many unpriv
>> containers as they have no apparmor.profile set in their
>configuration.
>
>I'd love to help but I'll need more info to understand why the current
>setup breaks "many unpriv containers", e.g.:
>
> - Is this specific to unprivileged containers?
>
> - Is it because "apparmor.profile = generated" is not suitable
>   for unprivileged containers?
>
>Finally, I wonder if "Suggests: apparmor" expresses strongly enough
>the current status of the LXC + AppArmor integration in Debian.
>Thankfully the Linux images will pull apparmor via Recommends…
>except on systems where the administrator has disabled installation
>of Recommends.
>
>Cheers,

It is specific to unpriviledged containers and due to the fact that non root 
users don't seem to have the ability to use the generated profile. 
PEB (from my phone)

Bug#926028: RM: xtensor-python -- ROM; NPOASR; orphaned

[ghisvail]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-scie...@lists.debian.org
Control: affects -1 xtensor-python

Please remove source package xtensor-python from unstable.

This package is severely outdated and is no longer actively maintained
by myself (same situation as xtensor).

Best regards,
Ghislain

Bug#926027: RM: xtensor -- ROM; NPOASR; FTBFS; orphaned

[ghisvail]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-scie...@lists.debian.org
Control: affects -1 xtensor

Please remove source package xtensor from unstable.

This package currently FTBFS, is severely outdated and is no longer
actively maintained by myself.

Best regards,
Ghislain

Bug#926026: RM: shark -- ROM; FTBFS; orphaned

[ghisvail]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-scie...@lists.debian.org
Control: affects -1 shark

Please remove source package shark from unstable.

This package fails to build on major release architectures and is no
longer actively maintained by myself. It has got no rdpends and should
therefore be safe to remove.

Best regards,
Ghislain

Bug#926024: RM: linop -- ROM; abandonned upstream

[ghisvail]

Package: ftp.debian.org
Severity: normal

Please remove source package linop from unstable.

This library is no longer actively maintained upstream and better
alternatives exist within the Python scientific stack.

This package has got no rdepends and should therefore be safe to
remove.

Best regards,
Ghislain

Bug#926023: ITP: golang-github-jsimonetti-pwscheme -- Golang packages defining different password schemes

[Balasankar C]

Package: wnpp
Severity: wishlist
Owner: Balasankar C 

* Package name: golang-github-jsimonetti-pwscheme
  Version : 0.0~git20160922.7680470-1
  Upstream Author : Jeroen Simonetti
* URL : https://github.com/jsimonetti/pwscheme
* License : MIT (Expat)
  Programming Lang: Go
  Description : Golang packages defining different password schemes


This Golang package provides different password schemes, like Salted
SHA1, Salted SHA256, Crypt with MD5, etc.

Packaging as a dependency of gopasspw[0][1]


[0] https://github.com/gopasspw/gopass/
[1] https://bugs.debian.org/901133

Regards
Balasankar "Balu" C

Bug#925600: [pkg-apparmor] Bug#925600: apparmor-profiles-extra: adjust autopkgtests to also work on Ubuntu

[intrigeri]

Jamie Strandboge:
> Thanks for considering the patch.

LGTM!

I'll apply this once Buster is released.

Bug#925899: lxc: Unprivileged containers fail to start after recent updates

[intrigeri]

Hi,

Pierre-Elliott Bécue:
> This bugreport raises an interesting question regarding the tradeoff
> between the solution we implemented to fix bug #916639.

> Cc-ing intrigeri: I'm reconsidering the /etc/lxc/default.conf setting
> regarding apparmor.profile. Putting generated breaks many unpriv
> containers as they have no apparmor.profile set in their configuration.

I'd love to help but I'll need more info to understand why the current
setup breaks "many unpriv containers", e.g.:

 - Is this specific to unprivileged containers?

 - Is it because "apparmor.profile = generated" is not suitable
   for unprivileged containers?

Finally, I wonder if "Suggests: apparmor" expresses strongly enough
the current status of the LXC + AppArmor integration in Debian.
Thankfully the Linux images will pull apparmor via Recommends…
except on systems where the administrator has disabled installation
of Recommends.

Cheers,
-- 
intrigeri

Bug#911890: Pending removal

[ghisvail]

control: tags -1 + pending

Removal bug filed, see #926022.

Bug#925919: RFT: linux with fix for VMware regression

[Emanuel Kocher]

On 30/03/2019 05:15, Ben Hutchings wrote:
> I've uploaded a new version of linux to:
> https://people.debian.org/~benh/packages/jessie-security/
> which I believe will fix this regression (bug #925919).  Please let me
> know whether it works for you.
I just installed it on two machines which hung quite often but 
everything looks stable for now - would prefer to give them until monday 
though when the normal workload is back to see how they behave.
> I only included the amd64 linux-image package and sources there, but
> can add i386 linux-image packages if needed.
>
> Ben.
>
Cheers
Emanuel