Bug#929268: [Pkg-samba-maint] Bug#929268: Acknowledgement (samba: Samba segfault)

[Mathieu Parent]

Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=13315
Control: tag -1 + upstream fixed-upstream patch
It looks to be:
https://bugzilla.samba.org/show_bug.cgi?id=13315

Regards
-- 
Mathieu Parent

Bug#928944: CVE-2019-12046: lemonldap-ng tokens allows anonymous session when stored in session DB

[Xavier]

Le 21 mai 2019 21:40:35 GMT+02:00, Guilhem Moulin  a écrit :
>Hi Xavier,
>
> # Load session data into object
> if ($data) {
>+if ( $self->kind ) {
>+unless ( $data->{_session_kind} eq $self->kind ) {
>+$self->error("Session kind mistmatch");
>+return undef;
>+}
>+}
>
>Doesn't that break CDA in 1.9.7-3+deb9u1?  At least I'm no longer able
>to access a protected application under domains other than the portal.
>
>Error output shows occurrences of “Session kind mistmatch” instead, and
>further debugging suggests that $data->{_session_kind} is "CDA" while
>$self->kind is "SSO" in the execution flow that yields access denial.

Hello,

It seems that Clément has fixed something related to that feature. Could you 
try 
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/commit/deff50f072c64898d1204daa28c01fdcc7275ea4
 ?

If it's OK, I'll propose a stretch update

-- 
Send with my EELO / K-9 Mail

Bug#929344: libnss-pgsql FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: libnss-pgsql
Version: 1.4.0debian-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libnss-pgsql fails to cross build from source, because it does not pass
--host ./configure. The easiest way of fixing that - using
dh_auto_configure - makes libnss-pgsql cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru libnss-pgsql-1.4.0debian/debian/changelog 
libnss-pgsql-1.4.0debian/debian/changelog
--- libnss-pgsql-1.4.0debian/debian/changelog   2014-10-10 17:54:53.0 
+0200
+++ libnss-pgsql-1.4.0debian/debian/changelog   2019-05-22 05:59:42.0 
+0200
@@ -1,3 +1,10 @@
+libnss-pgsql (1.4.0debian-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 22 May 2019 05:59:42 +0200
+
 libnss-pgsql (1.4.0debian-8) unstable; urgency=medium
 
   * debian/control: set myself as Maintainer because the team list does
diff --minimal -Nru libnss-pgsql-1.4.0debian/debian/rules 
libnss-pgsql-1.4.0debian/debian/rules
--- libnss-pgsql-1.4.0debian/debian/rules   2014-10-10 17:54:53.0 
+0200
+++ libnss-pgsql-1.4.0debian/debian/rules   2019-05-22 05:59:38.0 
+0200
@@ -2,13 +2,9 @@
 
 override_dh_auto_configure:
autoreconf -if
-   ./configure \
-   --prefix=/usr \
+   dh_auto_configure -- \
--libdir=/lib \
-   --mandir=\$${prefix}/share/man \
-   --infodir=\$${prefix}/share/info \
-   --with-docdir=\$${prefix}/share/doc/libnss-pgsql2 \
-   --sysconfdir=/etc
+   --with-docdir=\$${prefix}/share/doc/libnss-pgsql2
 
 override_dh_auto_clean:
 ifeq (Makefile, $(wildcard Makefile))

Bug#929345: getstream FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: getstream
Version: 20100616-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

getstream fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - does not entirely fix the issue, because the upstream
Makefile hard codes plain gcc and Makefile.defs.sh hard codes
pkg-config. Substituting the latter is a little difficult, because
dh_auto_build does not pass environment variables, but make variables.
So we need to supply PKG_CONFIG ourselves. The attached patch makes
getstream cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru getstream-20100616/debian/changelog 
getstream-20100616/debian/changelog
--- getstream-20100616/debian/changelog 2017-01-21 20:32:23.0 +0100
+++ getstream-20100616/debian/changelog 2019-05-22 06:00:26.0 +0200
@@ -1,3 +1,12 @@
+getstream (20100616-2) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build supply cross tools to make.
++ cross.patch: Make build tools substitutable.
++ Additionally pass PKG_CONFIG as environment variable.
+
+ -- Helmut Grohne   Wed, 22 May 2019 06:00:26 +0200
+
 getstream (20100616-1) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru getstream-20100616/debian/patches/cross.patch 
getstream-20100616/debian/patches/cross.patch
--- getstream-20100616/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ getstream-20100616/debian/patches/cross.patch   2019-05-22 
06:00:26.0 +0200
@@ -0,0 +1,31 @@
+--- getstream-20100616.orig/Makefile.defs.sh
 getstream-20100616/Makefile.defs.sh
+@@ -1,8 +1,9 @@
+-echo CFLAGS+=`pkg-config --cflags glib-2.0`
+-echo LDFLAGS+=`pkg-config --libs glib-2.0`
++: "${PKG_CONFIG:=pkg-config}"
++echo CFLAGS+=`${PKG_CONFIG} --cflags glib-2.0`
++echo LDFLAGS+=`${PKG_CONFIG} --libs glib-2.0`
+ 
+-libeventlibs=`pkg-config --libs libevent 2>/dev/null`
+-libeventcflags=`pkg-config --cflags libevent 2>/dev/null`
++libeventlibs=`${PKG_CONFIG} --libs libevent 2>/dev/null`
++libeventcflags=`${PKG_CONFIG} --cflags libevent 2>/dev/null`
+ 
+ if [ -z "${libeventcflags}" ]; then
+   libeventcflags=
+--- getstream-20100616.orig/Makefile
 getstream-20100616/Makefile
+@@ -26,10 +26,10 @@
+ all: getstream tsdecode
+ 
+ tsdecode: $(OBJ-tsdecode)
+-  gcc -o $@ $+ $(LDFLAGS)
++  $(CC) -o $@ $+ $(LDFLAGS)
+ 
+ getstream: $(OBJ-getstream)
+-  gcc -o $@ $+ $(LDFLAGS) 
++  $(CC) -o $@ $+ $(LDFLAGS) 
+ 
+ clean:
+   -rm -f $(OBJ-getstream) $(OBJ-tsdecode)
diff --minimal -Nru getstream-20100616/debian/patches/series 
getstream-20100616/debian/patches/series
--- getstream-20100616/debian/patches/series2017-01-21 20:32:23.0 
+0100
+++ getstream-20100616/debian/patches/series2019-05-22 06:00:26.0 
+0200
@@ -2,3 +2,4 @@
 glib-single-include.patch
 0001-Makefile-fix-for-link-as-needed.patch
 0001-Make-building-easier-by-using-pkg-config.patch
+cross.patch
diff --minimal -Nru getstream-20100616/debian/rules 
getstream-20100616/debian/rules
--- getstream-20100616/debian/rules 2017-01-21 20:32:23.0 +0100
+++ getstream-20100616/debian/rules 2019-05-22 06:00:26.0 +0200
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE=1
 
+-include /usr/share/dpkg/buildtools.mk
+export PKG_CONFIG ?= pkg-config
 
 CFLAGS = -Wall -g
 
@@ -9,7 +11,7 @@
 build-stamp: $(DPATCH_STAMPFN)
dh_testdir
 
-   $(MAKE)
+   dh_auto_build
 
touch $@
 

Bug#929343: choosewm FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: choosewm
Version: 0.1.6-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

choosewm fails to cross build from source, because debian/rules hard
codes the build architecture pkg-config. The attached patch uses dpkg's
buildtools.mk to supply the right pkg-config and makes choosewm cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru choosewm-0.1.6/debian/changelog 
choosewm-0.1.6/debian/changelog
--- choosewm-0.1.6/debian/changelog 2011-08-24 10:52:20.0 +0200
+++ choosewm-0.1.6/debian/changelog 2019-05-22 06:15:48.0 +0200
@@ -1,3 +1,10 @@
+choosewm (0.1.6-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 22 May 2019 06:15:48 +0200
+
 choosewm (0.1.6-3) unstable; urgency=low
 
   * quick fix to make it build again until I have time for
diff --minimal -Nru choosewm-0.1.6/debian/rules choosewm-0.1.6/debian/rules
--- choosewm-0.1.6/debian/rules 2011-08-24 10:47:57.0 +0200
+++ choosewm-0.1.6/debian/rules 2019-05-22 06:15:44.0 +0200
@@ -3,8 +3,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+PKG_CONFIG ?= pkg-config
 
 CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
 CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
@@ -12,7 +13,7 @@
 
 CFLAGS += -Wall -g -Wextra -Wmissing-prototypes -Wstrict-prototypes 
-Wpointer-arith
 LDFLAGS := -Wl,-z,defs $(LDFLAGS)
-CPPFLAGS := $(CPPFLAGS) $(shell pkg-config --cflags gtk+-x11-2.0)
+CPPFLAGS := $(CPPFLAGS) $(shell $(PKG_CONFIG) --cflags gtk+-x11-2.0)
 
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
 MAKEFLAGS += -j$(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))

Bug#929342: unblock: aqemu/0.9.2-2.2

[Abhijith PA]

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

Dear release team,

Please unblock package aqemu.

I reported a RC bug (#927126) against aqemu. Though its actual
maintainer is not active for years, a debian contributor (Alexis
Murzeau) fixed and filed a RFS(#929180) for a NMU. I've tested the
package and uploaded to the unstable.

diff:
https://salsa.debian.org/amurzeau-guest/aqemu/commit/5ce9cf29186a1f5d6ddcd8994351161de5ec76a7.diff


unblock aqemu/0.9.2-2.2

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#926118: unblock: libmspack/0.10.1-1

[David Palacio]

Hi

I want to add that according to freeze policy, exceptions may be made for
`optional` packages such as `libmspack` to solve `important` severity bugs.
Bug #912687 is marked `important` and is still present in Buster, the next
stable release. As of the current situation winetricks is unusable for the
very important role of installing native Windows dlls on Wine prefixes.
Please make the exception.

Cheers

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T7978

Bug#929341: cinnamon-settings-daemon mis-built without wacom support

[David Lamparter]

Package: cinnamon-settings-daemon
Version: 3.8.4-2
Severity: important

Dear Maximiliano, dear Debian maintainers,


it seems that the cinnamon-settings-daemon package available in buster
for amd64 was mis-built without wacom support.  I have fetched the
source package and compiled it on my local system, and there is a
difference in the files:

--- upstream-contents.txt   2019-05-22 02:58:17.414589122 +0200
+++ ../local-contents.txt   2019-05-22 02:58:21.754581540 +0200
@@ -24,0 +25 @@
+-rw-r--r-- root/root   269 
/etc/xdg/autostart/cinnamon-settings-daemon-wacom.desktop
@@ -42 +43 @@
--rwxr-xr-x root/root 22520 
/usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-input-helper
+-rwxr-xr-x root/root 18424 
/usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-input-helper
@@ -43,0 +45 @@
+-rwxr-xr-x root/root 63560 
/usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-list-wacom
@@ -53,0 +56,3 @@
+-rwxr-xr-x root/root117400 
/usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-wacom
+-rwxr-xr-x root/root 14416 
/usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-wacom-led-helper
+-rwxr-xr-x root/root 92376 
/usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-wacom-osd
@@ -216,0 +222 @@
+-rw-r--r-- root/root   935 
/usr/share/polkit-1/actions/org.cinnamon.settings-daemon.plugins.wacom.policy

(this is cinnamon-settings-daemon_3.8.4-2_amd64.deb specifically)

As a result of this, since csd-wacom is not in the package, the Wacom
tablet settings simply have no effect.

I have made no modifications at all to the source package, I simply
fetched it (apt source cinnamon-settings-daemon), installed the build
deps (mk-build-deps -i) and built it (dpkg-buildpackage -j6 -b -uc -us)
and the wacom bits were built correctly.  Something must've gone wrong
on the build servers.  Not sure how to get a rebuild?  +b1 I guess?

Would be nice to get this fixed :)

Thanks,

-David

P.S.: I have checked arm64 and i386 packages, they are missing the wacom
bits too.  Would guess all architectures were mis-built somehow.

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

Control: tags -1 - unreproducible
Control: tags -1 forwarded https://phab.enlightenment.org/T7978

On Tue, May 21, 2019 at 09:11:01PM +0300, sergio wrote:
> Yes. In fact I have the following scheme:

I've configured a user similar to your scheme, and I can confirm that the
Adwaita icon is not loaded when I log in.  In ~etmp/.xsession:

  #!/bin/bash
  rm -rf ~/.cache /tmp/etmp_cache
  ln -s /tmp/etmp_cache ~/.cache
  mkdir $(readlink ~/.cache)
  enlightenment_start

> But really all this doesn't matter as I've just reproduced this issue on
> the new user profile, with empty e setting and no cache logic.
> 
> 1. Just after the first logging in and answering configuration questions
>I see Pavucontrol icon in the application menu.
> 2. I press logout, switch to console (Alt-Ctrl-F1) and wait for the die
>of efreed.
> 3. In the .cache I see only efreed folder. I drop the whole folder or
>only icons_Adwaita_$HOST.eet, it doesn't matter.
> 4. Logging in again into e. The .cache/efreed folder is recreated,
>icons_Adwaita_$HOST.eet is present, but there are no icon for
>Pavucontrol in the application menu

Interesting- I'm not able to reproduce a missing pavucontrol icon.  It gets the
wrong icon, but it does get an icon.

> > Is your /tmp on a different filesystem (i.e., tmpfs)?
> 
> Yes, my /tmp in on a tmpfs.

My /tmp is not, so I think this is ruled out as irrelevant.

Thanks,
Ross

Bug#929340: partman-efi: erasing data necessitates to re-choose usage

[sergio]

Package: partman-efi
Version: 80
Severity: normal
Tags: d-i

Dear Maintainer,

steps to reproduce:

1. Create partition
2. Use as: EFI System Partition
3. Press Erase data on this partition

4. Done setting up the partition
5. Finish partitioning and write changes to disk

The attempt to mount a file system with type vfat ... at /boot/efi
failed.

Bug#929063: init: delegate selinux operation to separate binary

[Dmitry Bogatov]

[2019-05-18 15:00] Laurent Bigonville 
> I've seen that in your commit, I just don't understand why this is even 
> a goal.

Because I do not want to pay for what I do not use. It is matter of good
design and Unix way.

> libselinux is really small and only pulls libpcre3 which is pulled by
> grep (which is Essential). It's not possible today to install debian
> without libselinux installed anyway.

Path of a thousand miles starts with a single step.

> Also, what's your plan regarding packaging? Would that executable be
> put in a separate package?

Yes, that the plan.

> TBRH I spent a lot of time working opening bugs/submitting patches in
> debian so the user who wants to use SELinux can get (an almost) out of
> the box experience in debian and I would not really be happy to see
> that attempt to revert that in a core component.

And I spend a lot of time of not having useless things installed on my
box.

What is wrong with having selinux support in separate package? Just
enable "Apt::InstallSuggests" and you are golden.

> If you really (really) want to go that way, maybe you should use a
> private path for the helper (as it shouldn't be called my regular users 
> after the initial load) and/or use a less common name than "selinux-check".

No problem. I do not insist on any particular naming of helper and I
installed it into sbin just to reduce Makefile part of patch.

It was my plan to install it into /lib/init/ anyway, and you are welcome
to propose any name. What do you suggest?

> >> Was that discussed with anybody involved in SELinux in debian and/or
> >> upstream?
> > That is exactly place to start discussion. Luckily, Jesse is following
> > BTS, and I do not have to go through Savannah issue tracker.
>
> I was more thinking about upstream SELinux people

Okay. I see you added "selinux-devel" into thread. Thank you.

Dear selinux-devel maintainers, we are considering moving following
check from /sbin/init into subprocess:

   if (getenv("SELINUX_INIT") == NULL) {
 if (is_selinux_enabled() != 1) {
   if (selinux_init_load_policy() == 0) {
 putenv("SELINUX_INIT=YES");
 execv(myname, argv);
   } else {
 if (enforce > 0) {
   /* SELinux in enforcing mode but load_policy failed */
   /* At this point, we probably can't open /dev/console, so log() 
won't work */
   fprintf(stderr,"Unable to load SELinux Policy. Machine is in 
enforcing mode. Halting now.\n");
   exit(1);
 }
   }
 }
   }

Are there any possible unwanted side-effects? Any suggestions about it?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#929063: Moving SELinux check

[Dmitry Bogatov]

[2019-05-18 16:14] Jesse Smith 
> From a practical perspective, I'm curious if there is any benefit or
> drawback. Is this patch fixing a known bug,
> does it significantly reduce the size of PID 1 in memory?

Not that I really care about 1Mb of RAM, but:

152K/lib/x86_64-linux-gnu/libselinux.so.1
692K/lib/x86_64-linux-gnu/libsepol.so.1
460K/lib/x86_64-linux-gnu/libpcre.so.3.13.3
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#929339: RFP: qsmtp - drop-in replacement for qmail STMP programs

[Dmitry Bogatov]

Package: wnpp
Severity: wishlist

Qsmtp is a drop in replacement for the qmail SMTP programs qmail-smtpd
and qmail-remote. That means you just change your startup scripts to use
Qsmtpd instead of qmail-smtpd and most things will work as before.

The initial point was a heavily patched qmail-smtpd to get some decent
antispam features. This was then rewritten from scratch into a new
binary that was designed to allow easy extension to new mail filters.
Another design goal was to be 100% IPv6 clean.

  • Fast and small: written in plain C
  • IPv6 clean
  • Many antispam modules included, e.g. SPF, IP blacklists, domain
blacklists, badmailfrom, helo filtering
  • Easy API to add your own spamfilters
  • For vpopmail hosts: does not create bounces for non-existing users
  • Tested: includes unit tests, nightly checks available
at http://my.cdash.org/index.php?project=Qsmtp


pgpy6HbvQIaEQ.pgp
Description: PGP signature

Bug#928919: patch: Do not hide errors from initscripts

[Dmitry Bogatov]

[2019-05-18 23:26] Thorsten Glaser 
> > If initscript is called during postinst and fail -- yes, it interrupts
> > installation. And it is bug in package.
>
> No, I can install a package and not have it start perfectly fine.

You have exit status 6 for case of package not being configured.
Otherwise, I strongly disagree with "failure to start service fine".

> Worse is breakage on package *removal*, especially in situations
> where the system is wrecked (e.g. package install was aborted)
> anyway.
>
> Breaking apt is more evil than some dæmon not starting during
> the system run (on large upgrades, a reboot will be done anyway,
> so the problem is very transient).

Yeah, having non-unstallable package is evil. But I think hiding
the fact, that initscript is broken is even more evil.

But with these matters of good and evil we got off the main discussion:
what is wrong with having initscripts from bin:initscripts more sensible
exit values, given they are not invoked in maintainer scripts?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#929337: rust-string-cache-shared debian/copyright is malformed

[Daniel Kahn Gillmor]

On Tue 2019-05-21 17:29:23 -0400, Daniel Kahn Gillmor wrote:
> I think this particular patch to debcargo-conf is what you want:
>
> --- a/src/string-cache-shared/debian/copyright
> +++ b/src/string-cache-shared/debian/copyright
> @@ -1,3 +1,8 @@
> +Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> +Upstream-Name: string_cache_shared
> +Upstream-Contact: The Servo Project Developers
> +Source: https://github.com/servo/string-cache
> +
>  Files: ./lib.rs
>  Copyright: 2015 The Servo Project Developers
>  License: MIT or Apache-2.0

I've just uploaded an NMU to fix this, with the attached debdiff.  It's
also in salsa as:

 https://salsa.debian.org/rust-team/debcargo-conf/merge_requests/38


> However, when i try to rebuild string-cache-shared from debcargo-conf
> with this patch, i get a failure:
>
> Something failed: ErrorMessage { msg: "Couldn\'t find any crate matching 
> string-cache-shared *\n Try `debcargo update` to update the crates.io index." 
> }
> ./build.sh: abort: couldn't find crate string-cache-shared
>
> I don't know what this error message means exactly, but it seems like
> maybe string-cache-shared went away upstream.  If that means we can't
> build it in the expected way any more, even to fix problems like this,
> that's pretty frustrating.

Looking at this a bit deeper than just this superficial fix, it seems to
me that this is actually shipped from the same source git repository as
string-cache, but that package is at 0.7.3 in debian, not 0.3.0.
Shouldn't these two source packages be collapsed somehow?

anyway, i don't understand the debian rust packaging approach well
enough to know how to stitch together the two string-cache packages
safely, so i guess that's a different issue, but if anyone has pointers
i'd be happy to learn.

Regards,

--dkg

diff -Nru rust-string-cache-shared-0.3.0/debian/changelog rust-string-cache-shared-0.3.0/debian/changelog
--- rust-string-cache-shared-0.3.0/debian/changelog	2018-07-05 18:16:14.0 -0400
+++ rust-string-cache-shared-0.3.0/debian/changelog	2019-05-21 18:30:35.0 -0400
@@ -1,3 +1,10 @@
+rust-string-cache-shared (0.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * fix debian/copyright (Closes: #929337)
+
+ -- Daniel Kahn Gillmor   Tue, 21 May 2019 18:30:35 -0400
+
 rust-string-cache-shared (0.3.0-1) unstable; urgency=medium
 
   * Package string_cache_shared 0.3.0 from crates.io using debcargo 2.1.2
diff -Nru rust-string-cache-shared-0.3.0/debian/copyright rust-string-cache-shared-0.3.0/debian/copyright
--- rust-string-cache-shared-0.3.0/debian/copyright	2018-07-05 18:16:14.0 -0400
+++ rust-string-cache-shared-0.3.0/debian/copyright	2019-05-21 18:30:10.0 -0400
@@ -1,3 +1,8 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: string_cache_shared
+Upstream-Contact: The Servo Project Developers
+Source: https://github.com/servo/string-cache
+
 Files: ./lib.rs
 Copyright: 2015 The Servo Project Developers
 License: MIT or Apache-2.0


signature.asc
Description: PGP signature

Bug#925555: linux-image-4.19.0-4-amd64: [regression] No graphics on some IvyBridge / Haswell systems

[Alexis Murzeau]

Hi,

On Mon, 6 May 2019 12:08:03 +0100 "Rebecca N. Palmer"
 wrote:
> Control: forcemerge -1 926193
> Control: tags -1 upstream patch
> Control: retitle -1 linux-image-4.19.0-4-amd64: [regression] No graphics on 
> some IvyBridge / Haswell systems
> Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=109806
> 
> (Summary of the merged bugs - I haven't tried any of this myself)
> 
> Workaround for individuals (from leandroembu) - install 
> xserver-xorg-video-intel and copy 
> /usr/share/doc/xserver-xorg-video-intel/xorg.conf to /etc/X11.  This is 
> probably not suitable as an official fix as it may cause problems on 
> newer hardware (e.g. #860133).
> 
> Possible patch: revert drm/i915/fbdev: Actually configure untiled 
> displays (d179b88deb3bf6fed4991a31fd6f0f2cad21fab5).  Has been applied 
> upstream, but the real bug is thought to be in xorg not linux.
> 
> 
> 

As a side note, I'm affected by this bug and your suggested workaround
of copying a xorg.conf in /etc/Xorg worked for me, thanks :)

The linux commit got reverted since v5.1-rc7.

I don't know how Xorg and modeset work and what is exactly the atomic mode.
Also, I wasn't able to find what was fixed with the commit
d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 in linux, if it was possible
bugs discovered by reading the code or actual bugs users already
encountered.

But as I understand, there are several solutions to this bug:

- Revert the drm/i915/fbdev: Actually configure untiled displays
(d179b88deb3bf6fed4991a31fd6f0f2cad21fab5) commit in Linux. This revert
is in mainline since v5.1-rc7 [0]

- Rework the atomic support in Xorg, that require extensive
modifications but is in state to be tested, updated and validated [1]

- Disable atomic mode and fallback to legacy mode but that seem
suboptimal as atomic mode might be required by some drivers [2]



I guess backporting PR !36 [1] is too much changes in Xorg now that we
are in hard freeze and probably too risky given it is still
work-in-progress.

But I can't see how broken is to revert d179b88 commit in linux as I
don't what that commit fixed.
It seems to be not that critical as upstream linux has done the revert.

So I guess one solution is to just do the revert in linux and let the
next stable after Buster have the proper fix in Xorg with the time
needed to ensure it is working fine without breaking in various ways.

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9fa246256e09dc30820524401cdbeeaadee94025
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36
[2] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F













signature.asc
Description: OpenPGP digital signature

Bug#754513: Paper Submission - Thailand IRED International Conference - August 2019

[Stefania Wilson]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint 
International Conference organised by Institute of Research Engineers and 
Doctors at Bangkok, Thailand. The theme for the 2019 Thailand conference is to 
bring together innovative academics and industrial experts to a common forum. 
We would be delighted to have you present at this conference to hear what the 
technology experts and researchers have to share about the technology 
advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:




Track 1: 9th International Conference on Advances in Computing, Electronics and 
Communication - ACEC


Official Website: www.acec.theired.org




Track 2: 9th International Conference On Advances in Civil, Structural and 
Environmental Engineering - ACSEE


Official Website: www.acsee.theired.org




Track 3: 9th International Conference On Advances in Mechanical and Robotics 
Engineering - AMRE


Official Website: www.amre.theired.org




Track 4: 9th International Conference On Advances in Social Science, Management 
and Human Behaviour - SMHB


Official Website: www.smhb.theired.org


Conference Venue: Hotel Lebua at State Tower, Bangkok, Thailand


Conference Date: 03 - 04 August 2019


Abstract/ Full Paper Submission For Review: 10 June 2019




About Publication:

All the registered papers will proudly be published by IRED-CPS and stored in 
the SEEK digital Library 

(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) 
from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and 
Indexing. Proc. will also be published in International Journals with ISSN 
Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held 
International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.




https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in 
order to promote the conference.


The aim of the conference is to provide a platform to the researchers and 
practitioners from both academia as well as industry to meet and share 
cutting-edge development in the field.
Please take the time to explore the website for more details, check on 
important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published 
in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; 
which are NOT submitted or published or under consideration anywhere in other 
conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 

unsubscribe
IRED 

Bug#929260: apt-listbugs: not saving pinnings to disk

[Boruch Baum]

On 2019-05-22 00:04, Francesco Poli wrote:
> On Tue, 21 May 2019 06:02:56 -0400 Boruch Baum wrote:
> > On 2019-05-20 23:38, Francesco Poli wrote:
> > > First of all, apt-listbugs is not supposed to update
> > > file /etc/apt/apt.conf.d/10apt-listbugs
> >
> > Oops. That file exists, size zero, so the substance of the bug report 
> > stands.
>
> Which file?
> I guess  /etc/apt/preferences.d/apt-listbugs
> Is this the case?
Yes.

> By looking at the transcript, I suppose you are using Devuan, is that
> correct?
Yes.

> I am suspecting that you upgrade by explicitly selecting the unstable
> suite (codename "ceres"), but configured the general package pinnings
> so that you track another (older) suite by default.
Yes.

> If this is the case, then the daily cron job probably removes the
> pin on package rng-tools once a day, since its candidate version
> (2-unofficial-mt.14-1+b2) is not buggy.
Understood. Sorry for the confusion. You can close this report.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#929338: wordplay: Non-dfsg license

[Moshe Piekarski]

Package: wordplay
Version: 7.22-19
Severity: serious
Justification: Policy 2.2.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

the license is nondfsg compatible

- -- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wordplay depends on:
ii  libc6  2.28-10

wordplay recommends no packages.

wordplay suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAlzkeGwZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igV3lD/98Hgf5dJxM2MatL728jeF9
juKhuomVIBuvjDByi6jKJEHEJiZAzpfqRbH6ZG7QYTNK9yVRpBpIzXoqEvg33jsj
HTrYLQfB9ya7f5wvgJ8UfKHW4cHvLaJIXbVcS71QOUZJF3hcWOKPXsS911qbzC+f
uMYQopK4HuRps+eTHrDG7nxspFmPvD7KKEBQKV72CIG5p6rS+VibV1CI+WrYfCv5
vNsiGO4vGy0rj/5rh/u4oy5IypsphVM2k7I2v/20fF6cyDRF0VyoAELMOx41/hBi
+uzBXj1A2ICR8uEGTSiYy2mPgPImgZSjCbIAk40akfJc4Suwoy7ZauEweYShzaH0
0kmJ4IhMgopGMhKkQsqoFR5KG1vG8nu1gllaZ0P2Qo34Pi9B1LgjI4OUSvHPNyR+
DN1Hil/xjMT8EzFXlkOMGhRKLFYqiz1Wu0dz699ZrUWlp4dSNEr70mlGEzyQsabz
Dlo0p7uv6hCL4JodGlM96DQu8xvMp38kE44OM/g77c9cWmbOMhjAB62xJcc7VlvX
Cxz62rL37PBTYSTzOd+Y5t55oLeXt+waTc+Bqty7aE6nqBXDYLRmKjiBDuJKG1R8
OfUvUwoUysW5hWDkbP+zlxTJZ/GmBUCPlLj9f1HToSkrRwYjckrn6Jl4UDnMjw1L
Pe/SW3D+9gVmz2mWd5KjOg==
=sdqo
-END PGP SIGNATURE-

Bug#929260: apt-listbugs: not saving pinnings to disk

[Francesco Poli]

On Tue, 21 May 2019 06:02:56 -0400 Boruch Baum wrote:

> On 2019-05-20 23:38, Francesco Poli wrote:
> > Control: tags -1 + moreinfo
> >
> >
> > On Mon, 20 May 2019 03:23:24 -0400 Boruch Baum wrote:
> >
> > [...]
> > > For several upgrade procedures in the course of the recent few weeks,
> > > apt-listbugs has repeatedly been prompting me for the same bug (#915689
> > > rng-tools), and doesn't ever seem to update file
> > > /etc/apt/apt.conf.d/10apt-listbugs
> >
> > Hello again Boruch,
> > thanks for this second bug report.
> >
> > First of all, apt-listbugs is not supposed to update
> > file /etc/apt/apt.conf.d/10apt-listbugs
> 
> Oops. That file exists, size zero, so the substance of the bug report stands.

Which file?
I guess  /etc/apt/preferences.d/apt-listbugs
Is this the case?

> 
> > Secondly, it's not clear to me exactly what you did, when prompted by
> > apt-listbugs.
> > Could you please send (to the bug e-mail address) a transcript of your
> > interaction with apt-listbugs during one of the package upgrades?
> 
> serious bugs of rng-tools (2-unofficial-mt.14-1+b2 → 5-1) 
>  b1 - #915689 - prevent from migrating to testing
> Summary:
>  rng-tools(1 bug)
> Are you sure you want to install/upgrade the above packages? [Y/n/?/...] ?
> 
> ... (snip)
> 
> Are you sure you want to install/upgrade the above packages? [Y/n/?/...] p
> The following 1 package will be pinned or on hold:
>  rng-tools
> Are you sure? [Y/n]
> rng-tools pinned by adding Pin preferences in 
> /etc/apt/preferences.d/apt-listbugs. Restart APT session to enable
> Are you sure you want to install/upgrade the above packages? [N/?/...]
> **
> ** Exiting with an error in order to stop the installation. **
> **
> E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (10)
> E: Failure running script /usr/sbin/apt-listbugs apt
> # apt-get -t ceres upgrade
> 
> ... (snip)
> 
> After this operation, 31.7 kB disk space will be freed.
> Do you want to continue? [Y/n]
> Retrieving bug reports... Done
> Parsing Found/Fixed information... Done

OK, I am beginning to guess what's going on.

By looking at the transcript, I suppose you are using Devuan, is that
correct?

According to the [Devuan release page], ceres is the unstable suite,
but I see that you explicitly selected it in the upgrade command
("apt-get -t ceres upgrade").

[Devuan release page]: 

I am suspecting that you upgrade by explicitly selecting the unstable
suite (codename "ceres"), but configured the general package pinnings
so that you track another (older) suite by default.

If this is the case, then the daily cron job probably removes the
pin on package rng-tools once a day, since its candidate version
(2-unofficial-mt.14-1+b2) is not buggy.

Please send me the output of the following commands, after pinning
package rng-tools:

$ apt-cache policy
$ cat /etc/apt/preferences.d/apt-listbugs
$ apt-cache policy rng-tools
$ apt-cache -o Dir::Etc::PreferencesParts=/dev/null  policy rng-tools

Let's see whether my guess is correct...



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2iT3P2zlr7.pgp
Description: PGP signature

Bug#923930: testsuite comes with built-in time-bomb

[Brian May]

On Mon, May 20, 2019 at 09:53:27PM +0200, Giovanni Mascellani wrote:
> Upstream confirms that an update that handles 32 bit archs is not on the
> radar soon. I don't know what it is the best way forward now, but if it
> is decided that it is ok the ignore the error for 32 bit archs, then I
> can try to cook up the required patch.

I would appreciate any fix that will fix this for both 32bit and 64bit
- preferably as simple as possible, so I can get the recent security
  fixes into buster.

(also please do CC me in BTS emails)

Thanks!
-- 
Brian May 

Bug#916375: AW: Bug#916375: AW: [debian-mysql] Bug#916375: Update libaprutil1-dbd-mysql

[Daniel Högele - adelphi]

>How about removing all php5-packages or at least the php5-mysql package from 
>your system? 

We had to migrate a none php7 compatible 3rd party application first, therefore 
the test took a little bit longer.
I can finally confirm that removing all php5 packages did solve the problem.

Thanks!

Bug#928966: heimdal: CVE-2018-16860

[Brian May]

Salvatore Bonaccorso  writes:

> Ah right, this is #923930?

Yes, looks like it. I didn't get the recent emails, thanks for the
reference. I have now followed up there.
-- 
Brian May 

Bug#929221: Keytags missing from ods-enforcer key export

[Mathieu Mirmont]

control: -1 +wontfix

On Tue, May 21, 2019 at 07:19:47PM +, Jaap Winius wrote:
> 
> Quoting Mathieu Mirmont :
> 
> > If you need an immediate solution:
> > - "ods-enforcer key list -v" does list the IDs of all keys.
> > - "ods-enforcer key export --ds" does list the key ID of the DS record.
> > - grep your key from your signed zone, the comment field is there.
> 
> This does indeed work, so thank you very much for mentioning this
> workaround. It fixes my problem for now and I'm sure many others will be
> interested to read this as well. But, I hope the developers hear about this
> and at least add an option to include the keytag in the output of the
> "ods-enforcer key export" command.
> 
> Thanks again!

No worries. I did write a patch to re-introduce this comment field
(trivial one-liner), but then looking at the git history I noticed
that this comment field was in fact explicitly removed:

https://issues.opendnssec.org/browse/SUPPORT-208

Since it wasn't an accident but done on purpose, I don't feel that I
should revert it in the Debian package. If you really would like to
have the comment field back, please try your luck upstream :)

Cheers,

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#929337: rust-string-cache-shared debian/copyright is malformed

[Daniel Kahn Gillmor]

Package: src:rust-string-cache-shared
Version: 0.3.0-1
Control: tags -1 + patch

https://tracker.debian.org/media/packages/r/rust-string-cache-shared/copyright-0.3.0-1

shows that it does not have the appropriate header stanza.

I think this particular patch to debcargo-conf is what you want:

--- a/src/string-cache-shared/debian/copyright
+++ b/src/string-cache-shared/debian/copyright
@@ -1,3 +1,8 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: string_cache_shared
+Upstream-Contact: The Servo Project Developers
+Source: https://github.com/servo/string-cache
+
 Files: ./lib.rs
 Copyright: 2015 The Servo Project Developers
 License: MIT or Apache-2.0


However, when i try to rebuild string-cache-shared from debcargo-conf
with this patch, i get a failure:

Something failed: ErrorMessage { msg: "Couldn\'t find any crate matching 
string-cache-shared *\n Try `debcargo update` to update the crates.io index." }
./build.sh: abort: couldn't find crate string-cache-shared

I don't know what this error message means exactly, but it seems like
maybe string-cache-shared went away upstream.  If that means we can't
build it in the expected way any more, even to fix problems like this,
that's pretty frustrating.

Note that with this malformed file, anything that depends directly on it
will also fail with:

/usr/share/cargo/bin/dh-cargo-built-using: abort: Not in machine-readable 
format: /usr/share/doc/librust-string-cache-shared-dev/copyright

   --dkg


signature.asc
Description: PGP signature

Bug#928053: Severity of bug #928053 is too high

[Christian Folini]

On Tue, May 21, 2019 at 10:39:03PM +0200, Moritz Mühlenhoff wrote:
> > Yes. Our plan is to bring out a fix and then get in touch and have 4 of the 
> > 5
> > CVEs rejected. Unfortunately, the fix is far more complicated than we had
> > hoped for. But we have a pull request now, so this is getting closer.
> 
> Ack, sounds good. If those get rejected, the Security Tracker will pick
> it up from the MITRE feed.

Good to know. Thank you. I'll keep posting here as well.

Christian


> 
> Cheers,
> Moritz

Bug#929336: unblock: evolvotron/0.7.1-3

[Axel Beckert]

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

Please unblock evolvotron/0.7.1-3. It fixes frequent segfaults at
startup, namely #929034.

Full source debdiff:

diff -Nru evolvotron-0.7.1/debian/changelog evolvotron-0.7.1/debian/changelog
--- evolvotron-0.7.1/debian/changelog   2018-01-02 08:32:53.0 +0100
+++ evolvotron-0.7.1/debian/changelog   2019-05-21 01:40:39.0 +0200
@@ -1,3 +1,15 @@
+evolvotron (0.7.1-3) unstable; urgency=high
+
+  [ Ondřej Nový ]
+  * debian/watch: Use HTTPS.
+
+  [ Axel Beckert ]
+  * Apply patch to fix erasing while iterating. Fixes frequent segfaults
+on startup. (Closes: #929034) Thanks to Saverio Brancaccio for
+reporting the issue and thanks to Jan Nordholz for the patch!
+
+ -- Axel Beckert   Tue, 21 May 2019 01:40:39 +0200
+
 evolvotron (0.7.1-2) unstable; urgency=medium
 
   * Add lintian override for bogus tech-ctte decision imposed onto policy,
diff -Nru evolvotron-0.7.1/debian/patches/fix_erasing_while_iterating.patch 
evolvotron-0.7.1/debian/patches/fix_erasing_while_iterating.patch
--- evolvotron-0.7.1/debian/patches/fix_erasing_while_iterating.patch   
1970-01-01 01:00:00.0 +0100
+++ evolvotron-0.7.1/debian/patches/fix_erasing_while_iterating.patch   
2019-05-21 01:39:42.0 +0200
@@ -0,0 +1,66 @@
+Description: Fix erasing while iterating
+Author: Jan Nordholz 
+Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929034#41
+Bug-Debian: https://bugs.debian.org/929034
+Forwarded: yes
+
+Index: evolvotron-0.7.1/libevolvotron/mutatable_image_computer_farm.cpp
+===
+--- evolvotron-0.7.1.orig/libevolvotron/mutatable_image_computer_farm.cpp
 evolvotron-0.7.1/libevolvotron/mutatable_image_computer_farm.cpp
+@@ -72,19 +72,20 @@ void MutatableImageComputerFarm::fasttra
+ {
+   QMutexLocker lock(&_mutex);
+   
+-  // \todo: Inefficient starting search again each time.  Some problem with 
erase otherwise though, but might have been task abort mem leak.
+-  TodoQueue::iterator it;
+-  while (
+-   (
+-it=std::find_if(_todo.begin(),_todo.end(),predicate_aborted)
+-)
+-   !=
+-   _todo.end()
+-   )
+-{
+-  _done[(*it)->display()].insert(*it);
+-  _todo.erase(it);
+-}  
++  TodoQueue::iterator it = _todo.begin();
++
++  while (it != _todo.end())
++{
++  if ((*it)->aborted())
++  {
++_done[(*it)->display()].insert(*it);
++it = _todo.erase(it);
++  }
++  else
++  {
++it++;
++  }
++}
+ }
+ 
+ void MutatableImageComputerFarm::push_todo(const 
boost::shared_ptr& task)
+@@ -214,7 +215,9 @@ void MutatableImageComputerFarm::abort_f
+   if ((*it)->display()==disp)
+   {
+ (*it)->abort();
+-_todo.erase(it);
++it = _todo.erase(it);
++if (it == _todo.end())
++  break;
+   }
+ }
+   
+@@ -234,7 +237,9 @@ void MutatableImageComputerFarm::abort_f
+ if ((*it1)->display()==disp)
+   {
+ (*it1)->abort();
+-q.erase(it1);
++it1 = q.erase(it1);
++if (it1 == q.end())
++  break;
+   }
+   }
+ }
diff -Nru evolvotron-0.7.1/debian/patches/series 
evolvotron-0.7.1/debian/patches/series
--- evolvotron-0.7.1/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ evolvotron-0.7.1/debian/patches/series  2019-05-21 01:20:58.0 
+0200
@@ -0,0 +1 @@
+fix_erasing_while_iterating.patch
diff -Nru evolvotron-0.7.1/debian/watch evolvotron-0.7.1/debian/watch
--- evolvotron-0.7.1/debian/watch   2016-05-18 23:16:11.0 +0200
+++ evolvotron-0.7.1/debian/watch   2019-05-17 00:24:11.0 +0200
@@ -1,2 +1,2 @@
 version=3
-http://sf.net/evolvotron/evolvotron-(.*)\.tar\.gz
+https://sf.net/evolvotron/evolvotron-(.*)\.tar\.gz

It has been built successfully on all release architectures as well on
all other architectures except kfreebsd-* where the build is still
pending: https://buildd.debian.org/status/package.php?p=evolvotron

So please:

unblock evolvotron/0.7.1-3

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#928966: heimdal: CVE-2018-16860

[Salvatore Bonaccorso]

Hi Brian,

On Tue, May 21, 2019 at 07:00:52PM +1000, Brian May wrote:
> Salvatore Bonaccorso  writes:
> 
> > Alright, I will mark it no-dsa for stretch then at least. For buster,
> > might be still good to have the fix go in?
> 
> First attempt, looks like version in buster/sid doesn't build :-(

Ah right, this is #923930?

Regards,
Salvatore

Bug#928053: Severity of bug #928053 is too high

[Moritz Mühlenhoff]

On Tue, May 21, 2019 at 10:23:22AM +0200, Christian Folini wrote:
> > And the CVE description
> > explicitly refers to ModSecurity, so if those reports are not correct, the
> > CVE IDs should be rejected as MITRE.
> 
> Yes. Our plan is to bring out a fix and then get in touch and have 4 of the 5
> CVEs rejected. Unfortunately, the fix is far more complicated than we had
> hoped for. But we have a pull request now, so this is getting closer.

Ack, sounds good. If those get rejected, the Security Tracker will pick
it up from the MITRE feed.

Cheers,
Moritz

Bug#929302: libgc: Update to 8.0.4 (fixed symbols)

[Ivan Maidanski]

Here's an update of the proposed patch (with the correct 
debian/libgc1c2.symbols).

Tested on Debian 9.9 amd64

The proposed patch closes: #493784 and #911729


-- 
Ivan Maidanski

libgc-update-8.0.4-v2.diff
Description: Binary data

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

[Diederik de Haas]

On dinsdag 21 mei 2019 21:20:18 CEST Diederik de Haas wrote:
> What was the reason for the test?

FTR: before I did the test I had already downgraded firmware-amd-graphics and 
consequently also firmware-linux-nonfree and firmware-misc-nonfree back to 
version 20190114-1

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

Bug#929271: it makes sense

[ospos web]

I have followed this discussion, since we provide an image based debian con
nuestro producto, and we have realized that in part is right... the program
gives options to alter all sources of packages except the "backports"...
because you can alter all and not that?

I don't think that the excuse of "all are always in the same source" is
valid, because according to the installation images as well as the
backports images are not always coordinated between all the mirrors origins
according to the debian notes.

In addition, not all the countries have excelent internet providers and the
net service are expensive in some cases.. so please.. seems all of you must
take care of the common environment not just only the Debian excelent
resources environment with great bandwith

-- 
www.osposweb.com

Bug#929335: nagios-plugins-contrib FTCBFS: multiple reasons

[Helmut Grohne]

Source: nagios-plugins-contrib
Version: 24.20190301
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nagios-plugins-contrib fails to build from source. The first failure is
installing Build-Depends as python and python-debian are not cross
satisfiable. Since these are only used for scripts, we can annotate them
with :native. Then, check_varnish is configured without --host. The
attached patch uses dh_auto_configure to fix that. Finally,
check_memcached hard codes the build architecture pkg-config. The
attached patch makes nagios-plugins-contrib cross buildable. Please
consider applying it.

Helmut
diff --minimal -Nru nagios-plugins-contrib-24.20190301/debian/changelog 
nagios-plugins-contrib-24.20190301+nmu1/debian/changelog
--- nagios-plugins-contrib-24.20190301/debian/changelog 2019-03-01 
14:22:08.0 +0100
+++ nagios-plugins-contrib-24.20190301+nmu1/debian/changelog2019-05-21 
21:15:19.0 +0200
@@ -1,3 +1,13 @@
+nagios-plugins-contrib (24.20190301+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate python* build-depends with :native.
++ Perform the check_varnish build using dh_auto_*
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Tue, 21 May 2019 21:15:19 +0200
+
 nagios-plugins-contrib (24.20190301) unstable; urgency=medium
 
   * [94e6962] check_rbl: Update to 1.4.4
diff --minimal -Nru nagios-plugins-contrib-24.20190301/debian/control 
nagios-plugins-contrib-24.20190301+nmu1/debian/control
--- nagios-plugins-contrib-24.20190301/debian/control   2019-03-01 
14:22:08.0 +0100
+++ nagios-plugins-contrib-24.20190301+nmu1/debian/control  2019-05-21 
21:15:19.0 +0200
@@ -3,10 +3,10 @@
 Priority: optional
 Maintainer: Debian Nagios Maintainer Group 

 Uploaders: Bernd Zeimetz , Jan Wagner , 
Stefan Schoerghofer , Petter Reinholdtsen , 
Leo Antunes 
-Build-Depends: debhelper (>= 8.0.0),
+Build-Depends: debhelper (>= 9.20160114),
dh-autoreconf,
-   python,
-   python-debian,
+   python:any,
+   python-debian:native,
quilt (>= 0.46-7),
autotools-dev, flex, libmemcached-dev [!hurd-i386], 
libvarnishapi-dev [!hurd-i386 !m68k], pkg-config, automake-1.15
 Standards-Version: 4.3.0
diff --minimal -Nru 
nagios-plugins-contrib-24.20190301/debian/patches/cross.patch 
nagios-plugins-contrib-24.20190301+nmu1/debian/patches/cross.patch
--- nagios-plugins-contrib-24.20190301/debian/patches/cross.patch   
1970-01-01 01:00:00.0 +0100
+++ nagios-plugins-contrib-24.20190301+nmu1/debian/patches/cross.patch  
2019-05-21 21:15:19.0 +0200
@@ -0,0 +1,11 @@
+--- nagios-plugins-contrib-24.20190301+nmu1.orig/check_memcached/Makefile
 nagios-plugins-contrib-24.20190301+nmu1/check_memcached/Makefile
+@@ -1,6 +1,7 @@
+ #/usr/bin/make -f
+ CLEANFILES = check_memcached check_memcached.c
+-LIBS += $(shell pkg-config --libs libmemcached) -lpthread
++PKG_CONFIG ?= pkg-config
++LIBS += $(shell $(PKG_CONFIG) --libs libmemcached) -lpthread
+ 
+ include ../common.mk
+ 
diff --minimal -Nru nagios-plugins-contrib-24.20190301/debian/patches/series 
nagios-plugins-contrib-24.20190301+nmu1/debian/patches/series
--- nagios-plugins-contrib-24.20190301/debian/patches/series2019-03-01 
14:22:08.0 +0100
+++ nagios-plugins-contrib-24.20190301+nmu1/debian/patches/series   
2019-05-21 21:15:19.0 +0200
@@ -52,3 +52,4 @@
 check_varnish/fix_for_v56
 check_raid/no_epn
 percona-nagios-plugins/fix_bashism
+cross.patch
diff --minimal -Nru nagios-plugins-contrib-24.20190301/debian/rules 
nagios-plugins-contrib-24.20190301+nmu1/debian/rules
--- nagios-plugins-contrib-24.20190301/debian/rules 2019-03-01 
14:22:08.0 +0100
+++ nagios-plugins-contrib-24.20190301+nmu1/debian/rules2019-05-21 
21:15:19.0 +0200
@@ -11,6 +11,12 @@
dh $@ --with quilt,python2
 
 override_dh_auto_build:
+   dh_update_autotools_config
+   # Perform check_varnish/ build separately to use dh_auto_*
+   dh_auto_configure --sourcedirectory=check_varnish/src
+   dh_auto_build --sourcedirectory=check_varnish/src
+   cp check_varnish/src/check_varnish check_varnish/check_varnish
+
dh_auto_build
$(PACKAGING_HELPER) --generate-readme
 

Bug#929271: backports customizations are not enabled for live-build

[PICCORO McKAY Lenz]

obviously you Maichael do not paid attention, i repeat:

1. the bug was reported agains strecht.. i cannot build strecht image using
different mirrors for each case!
2. -for low performance networks it's a good practice have differents
mirrors so download task will be separatelly,
3. docummentation are obviuslly out of date, script obvouslly are out of
date, all are obviouslly out of sync

in any case, that are ilogic, iu can provide different mirror for chroot
installer and for booststrap but not for backports? PUFFF

i mean event have normal and backports in same domain.. i setup different
origin domains sources for normal repository and backports repository...
that's a good practice

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


El mar., 21 de may. de 2019 a la(s) 15:16, Michael . (keltoi...@gmail.com)
escribió:

> Jessie security support ended June 17 2018. Asking the live project to
> support a dist that is no longer security supported adds work to an
> already huge workload.
>
> On 22/05/2019, PICCORO McKAY Lenz  wrote:
> > Roland, i track back all the history and get not lost.. BUT IN ANY CASE
> > THAT BEHAVIOUR ARE NOT VIABLE, lest see:
> >
> > about the commits history: seems the migration was not as espected
> > (migrations was done good but the results are not same as xpected)
> >
> > the commits are :
> >
> https://salsa.debian.org/live-team/live-build/commit/dd15ade8bbdc6360816ed858253e7aaa68e4c9c2
> >
> > and also
> >
> https://salsa.debian.org/live-team/live-build/commit/68700f466c142082e7423282ca4caaf7552bf8e9
> >
> > I EXPLAIN WHY THAT COMMITS MUST BE REVERTED
> >
> > 1. - the mirror are track from default mirror.. so oldstable moving of
> > backports (as seems always) are not in same repository, that made this
> > behaviour ilogic and ridiculus, due for olstable the repository will be
> > archived .. same for updates repository!
> >
> > 2. -for low performance networks it's a good practice have differents
> > mirrors so download task will be separatelly, i mean event have normal
> and
> > backports in same domain.. i setup different origin domains sources for
> > normal repository and backports repository... that's a good practice
> >
> > there's more reason but in my case those are enouoght
> >
> > Please therat that issue quick due i cannot build any jessie image
> property
> > or i cannot use any strecth image in good shape!
> >
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> >
> > El mar., 21 de may. de 2019 a la(s) 02:38, Roland Clobus
> > (rclo...@rclobus.nl)
> > escribió:
> >
> >> Hello PICCORO,
> >>
> >> On 20/05/2019 15:42, PICCORO McKAY Lenz wrote:
> >> > when try to build live jessie image using strecht i got those errors
> >> >
> >> > lb config: unrecognized option '--mirror-chroot-updates'
> >> > lb config: unrecognized option '--parent-mirror-binary-updates'
> >> > lb config: unrecognized option '--parent-mirror-chroot-updates'
> >>
> >> When working on the documentation, I've noticed these command line
> >> options as well. They are not present in the scripts, they are only in
> >> the documentation.
> >> Unfortunately due to the migration from alioth to salsa the git history
> >> got lost, so I cannot trace it back. I would assume that the
> >> functionality was remove from the scripts at some time, and that someone
> >> forgot to update the documentation accordingly. I've downloaded the
> >> package 1:20151215 [1], and the command line is mentioned there also
> >> only in the documentation, which confirms my assumption.
> >>
> >> Instead of (re-)implementing these options, I would update the
> >> documentation instead.
> >>
> >> With kind regards,
> >> Roland Clobus
> >>
> >> [1] https://snapshot.debian.org/package/live-build/1%3A20151215/
> >>
> >>
> >>
> >>
> >
>

Bug#929221: Keytags missing from ods-enforcer key export

[Jaap Winius]

Quoting Mathieu Mirmont :


If you need an immediate solution:
- "ods-enforcer key list -v" does list the IDs of all keys.
- "ods-enforcer key export --ds" does list the key ID of the DS record.
- grep your key from your signed zone, the comment field is there.


This does indeed work, so thank you very much for mentioning this  
workaround. It fixes my problem for now and I'm sure many others will  
be interested to read this as well. But, I hope the developers hear  
about this and at least add an option to include the keytag in the  
output of the "ods-enforcer key export" command.


Thanks again!

Jaap Winius

Bug#928053: Severity of bug #928053 is too high

[Moritz Mühlenhoff]

Hi Alberto,

On Tue, May 21, 2019 at 10:15:20AM +0200, Alberto Gonzalez Iniesta wrote:
> Hi all,
> 
> I'll try to clarify a bit on ModSecurity vs CRS, since I think it may be
> a bit confusing.

Indeed, it's much clearer now with your explanation.

I'll update the CVE entries in the Debian security to reflect the
negligible security impact, feel free to also lower the BTS severity.

Cheers,
Moritz

Bug#929334: libvirt: CVE-2019-10132: Insecure permissions for systemd socket for virtlockd/virtlogd

[Salvatore Bonaccorso]

Source: libvirt
Version: 5.0.0-2
Severity: grave
Tags: security upstream
Control: found -1 5.0.0-2.1
Control: found -1 5.2.0-2

Hi,

The following vulnerability was published for libvirt.

CVE-2019-10132[0]:
Insecure permissions for systemd socket for virtlockd/virtlogd

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10132
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10132
[1] https://security.libvirt.org/2019/0003.html

Please adjust the affected versions in the BTS as needed, looks like
the issue is introduced upstream in v4.1.0-rc1 though.

Regards,
Salvatore

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

[Diederik de Haas]

On dinsdag 21 mei 2019 21:20:18 CEST Diederik de Haas wrote:
> Checking 'git log' for that specific file before I did the test made me
> conclude it wouldn't make a difference with packaged version 20190114-1
> (but did the test anyway as requested).

To verify whether that single file wasn't an anomaly, I compared the vega10* 
files from the 20190114-1 package with the files from the requested commit 
using 
SHA256 and they were all exactly the same.


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

Bug#929333: RM: colorediffs-extension -- RoQA; Broken with Thunderbird 60

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove colorediffs-extension. It's broken with Thunderbird
and the last upload was in 2014.

Cheers,
Moritz

Bug#918171: Broken with Thunderbird 60

[Moritz Mühlenhoff]

On Mon, May 20, 2019 at 07:03:04PM +0200, Daniel Baumann wrote:
> Hi Moritz,
> 
> sorry for the late response, your mail slipped through the cracks on my
> end.. :(
> 
> re adoption: removal request sounds fine, I currently have not enough
> time to take on more packages in Debian.

Ack, I just filed a removal bug.

Cheers,
Moritz

Bug#928944: CVE-2019-12046: lemonldap-ng tokens allows anonymous session when stored in session DB

[Guilhem Moulin]

Hi Xavier,

 # Load session data into object
 if ($data) {
+if ( $self->kind ) {
+unless ( $data->{_session_kind} eq $self->kind ) {
+$self->error("Session kind mistmatch");
+return undef;
+}
+}

Doesn't that break CDA in 1.9.7-3+deb9u1?  At least I'm no longer able
to access a protected application under domains other than the portal.

Error output shows occurrences of “Session kind mistmatch” instead, and
further debugging suggests that $data->{_session_kind} is "CDA" while
$self->kind is "SSO" in the execution flow that yields access denial.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#929332: ironic-inspector: CVE-2019-10141: SQL Injection vulnerability when receiving introspection data

[Salvatore Bonaccorso]

Source: ironic-inspector
Version: 8.0.0-2
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for ironic-inspector.

CVE-2019-10141[0]:
SQL Injection vulnerability when receiving introspection data

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10141
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10141
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1711722
[2] https://review.opendev.org/#/c/660234/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#929331: unblock: ruby-devise/4.5.0-3

[Utkarsh Gupta]

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

Hey,

Please unblock package ruby-devise.

The latest upload contains a CVE-2019-5421 (and #926348) fix.
Thus requesting you to:
unblock ruby-devise/4.5.0-3


Best,
Utkarsh
---

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

[Diederik de Haas]

On dinsdag 21 mei 2019 19:24:07 CEST Romain Perier wrote:
> Hi,

Hi,

> firmware-amd-graphics 20190502-1 is based onto upstream commit
> 92e17d0dd2437140fab044ae62baf69b35d7d1fa, that is commit "amdgpu: update
> vega20 to the latest 19.10 firmware" . Two commits behind there is commit
> "amdgpu: update vega10 to the latest 19.10 firmware", that is already
> included in firmware-amd-graphics 20190502-1.
> 
> Could you try to revert "amdgpu: update vega10 to the latest 19.10
> firmware" ? So try to use the firmware for vega10 that is before this
> commit. Does it work for you ?
> 
> 1. Use linux-firmware.git with last HEAD in the master branch
> 2. git checkout 4ea5c73b96ed4a508f90047e22ccbaa477481310 (commit "amdgpu:
> update polaris11 to the latest 19.10 firmware", that is the commit before
> bumping vega10 to 19.10) 3. Copy vega10 binary blobs to
> /lib/firmware/amdgpu
> 
> Does it work ?

Yes, that does work.
What did surprise me is that I saw a blinking cursor, which I don't see with 
firmware-amd-graphics version 20190114-1.
$ git log --oneline -- amdgpu/vega10_ce.bin
0f22c85 Revert "amdgpu: update vega10 fw for 18.50 release"
ec4b0cd amdgpu: update vega10 fw for 18.50 release
ac5f8bd amdgpu: update vega10 firmware to 18.40
10e2971 amdgpu: sync up vega10 firmware with 18.20 release
0d672f7 amdgpu: sync up vega10 firmware with 18.10 release
f0698be amdgpu: add initial vega10 firmware

This tells me I'm running actually running "ac5f8bd amdgpu: update vega10 
firmware to 18.40"
https://tracker.debian.org/news/1021249/accepted-firmware-nonfree-20190114-1-source-into-unstable/
 contains:
- amd-graphics:
   + "Polaris10", "Polaris11", "Raven" firmware updates to sync with
 18.50 release
   + "Fiji", "Tonga", "Vega10", "Carrizo" firmware updates to sync with
 18.40 release

So in both cases I'm supposed to run the exact same firmware version, so even 
the minor change in behavior (blinking cursor) surprises me.

What was the reason for the test?
Checking 'git log' for that specific file before I did the test made me 
conclude 
it wouldn't make a difference with packaged version 20190114-1 (but did the 
test anyway as requested).

Cheers,
  Diederik

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

Bug#929271: backports customizations are not enabled for live-build

[Michael .]

Jessie security support ended June 17 2018. Asking the live project to
support a dist that is no longer security supported adds work to an
already huge workload.

On 22/05/2019, PICCORO McKAY Lenz  wrote:
> Roland, i track back all the history and get not lost.. BUT IN ANY CASE
> THAT BEHAVIOUR ARE NOT VIABLE, lest see:
>
> about the commits history: seems the migration was not as espected
> (migrations was done good but the results are not same as xpected)
>
> the commits are :
> https://salsa.debian.org/live-team/live-build/commit/dd15ade8bbdc6360816ed858253e7aaa68e4c9c2
>
> and also
> https://salsa.debian.org/live-team/live-build/commit/68700f466c142082e7423282ca4caaf7552bf8e9
>
> I EXPLAIN WHY THAT COMMITS MUST BE REVERTED
>
> 1. - the mirror are track from default mirror.. so oldstable moving of
> backports (as seems always) are not in same repository, that made this
> behaviour ilogic and ridiculus, due for olstable the repository will be
> archived .. same for updates repository!
>
> 2. -for low performance networks it's a good practice have differents
> mirrors so download task will be separatelly, i mean event have normal and
> backports in same domain.. i setup different origin domains sources for
> normal repository and backports repository... that's a good practice
>
> there's more reason but in my case those are enouoght
>
> Please therat that issue quick due i cannot build any jessie image property
> or i cannot use any strecth image in good shape!
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
>
> El mar., 21 de may. de 2019 a la(s) 02:38, Roland Clobus
> (rclo...@rclobus.nl)
> escribió:
>
>> Hello PICCORO,
>>
>> On 20/05/2019 15:42, PICCORO McKAY Lenz wrote:
>> > when try to build live jessie image using strecht i got those errors
>> >
>> > lb config: unrecognized option '--mirror-chroot-updates'
>> > lb config: unrecognized option '--parent-mirror-binary-updates'
>> > lb config: unrecognized option '--parent-mirror-chroot-updates'
>>
>> When working on the documentation, I've noticed these command line
>> options as well. They are not present in the scripts, they are only in
>> the documentation.
>> Unfortunately due to the migration from alioth to salsa the git history
>> got lost, so I cannot trace it back. I would assume that the
>> functionality was remove from the scripts at some time, and that someone
>> forgot to update the documentation accordingly. I've downloaded the
>> package 1:20151215 [1], and the command line is mentioned there also
>> only in the documentation, which confirms my assumption.
>>
>> Instead of (re-)implementing these options, I would update the
>> documentation instead.
>>
>> With kind regards,
>> Roland Clobus
>>
>> [1] https://snapshot.debian.org/package/live-build/1%3A20151215/
>>
>>
>>
>>
>

Bug#929330: uc-echo FTCBFS: unsatisfiable Build-Depends

[Helmut Grohne]

Source: uc-echo
Version: 1.12-10
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

uc-echo fails to cross build from source, because its Build-Depends are
not satisfiable. python-all-dev should be replaced with
python-all-dev:any, libpython-all-dev. The python modules can be
annotated with :native. After doing so, uc-echo cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru uc-echo-1.12/debian/changelog uc-echo-1.12/debian/changelog
--- uc-echo-1.12/debian/changelog   2018-07-03 15:30:44.0 +0200
+++ uc-echo-1.12/debian/changelog   2019-05-21 21:01:35.0 +0200
@@ -1,3 +1,10 @@
+uc-echo (1.12-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 21 May 2019 21:01:35 +0200
+
 uc-echo (1.12-10) unstable; urgency=medium
 
   [ Steffen Moeller and Jon Ison ]
diff --minimal -Nru uc-echo-1.12/debian/control uc-echo-1.12/debian/control
--- uc-echo-1.12/debian/control 2018-07-03 15:30:44.0 +0200
+++ uc-echo-1.12/debian/control 2019-05-21 21:01:35.0 +0200
@@ -6,9 +6,10 @@
 Section: science
 Priority: optional
 Build-Depends: debhelper (>= 11~),
-   python-all-dev,
-   python-scipy,
-   python-numpy,
+   python-all-dev:any,
+   libpython-all-dev,
+   python-scipy:native,
+   python-numpy:native,
g++-multilib [i386 powerpc sparc x32]
 Standards-Version: 4.1.4
 Vcs-Browser: https://salsa.debian.org/med-team/uc-echo

Bug#924554: Bug#928108: unblock: unattended-upgrades/1.12 ?

[Paul Gevers]

Control: tags -1 confirmed moreinfo

Hi Bálint,

On 21-05-2019 09:58, Bálint Réczey wrote:
> OK, I understand. I hoped Release Team could take a look at the
> referenced bugs and list the ones they would see important enough to
> include in Buster. IMO letting 1.12 in would come with the least
> amount of risk and would fix many issues already fixed in Ubuntu, but
> I see that there is other important work to be done for the release,
> too.

Thanks for understanding.

> Please find the the patch attached for cherry-picking only the fix for
> #924554. If you prefer adding only this fix to Buster I will upload
> this change to unstable then it can be let to testing.

You can go ahead with that, except I prefer not to have the +deb10u1
version as that looks weird for an unstable upload. Seem like you could
use 1.11.1 or something along those lines.

Please remove the moreinfo tag when the package built successfully.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929327: keylaunch FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: keylaunch
Version: 1.3.9
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

keylaunch fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes keylaunch cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru keylaunch-1.3.9/debian/changelog 
keylaunch-1.3.9+nmu1/debian/changelog
--- keylaunch-1.3.9/debian/changelog2010-02-16 07:46:38.0 +0100
+++ keylaunch-1.3.9+nmu1/debian/changelog   2019-05-21 20:47:29.0 
+0200
@@ -1,3 +1,11 @@
+keylaunch (1.3.9+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes:
+#-1)
+
+ -- Helmut Grohne   Tue, 21 May 2019 20:47:29 +0200
+
 keylaunch (1.3.9) unstable; urgency=low
 
   * Distclean should clean too. (Closes: #570044)
diff --minimal -Nru keylaunch-1.3.9/debian/rules 
keylaunch-1.3.9+nmu1/debian/rules
--- keylaunch-1.3.9/debian/rules2010-02-14 17:20:35.0 +0100
+++ keylaunch-1.3.9+nmu1/debian/rules   2019-05-21 20:47:25.0 +0200
@@ -5,7 +5,7 @@
 configure-stamp:
dh_testdir
# Add here commands to configure the package.
-   ./configure --prefix=/usr
+   dh_auto_configure
touch configure-stamp
 
 build: configure-stamp build-stamp

Bug#929328: netmate FTCBFS: upstream Makefile hard codes build tools

[Helmut Grohne]

Source: netmate
Version: 0.2.0-10
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

netmate fails to cross build from source, because the upstream Makefile
hard codes build tools such as gcc or pkg-config. The attached patch
makes them substitutable and netmate cross buildable. Please consider
applying it.

Helmut
--- netmate-0.2.0.orig/Makefile
+++ netmate-0.2.0/Makefile
@@ -10,12 +10,13 @@
 DEBUGFLAGS = -g
 CFLAGS += $(OPTFLAGS) $(WARNFLAGS) $(DEBUGFLAGS)
 LDFLAGS += -Wl,-z,relro
-GTK_CFLAGS = $(shell pkg-config --cflags gtk+-3.0)
-GTK_LIBS = $(shell pkg-config --libs gtk+-3.0)
+PKG_CONFIG ?= pkg-config
+GTK_CFLAGS = $(shell $(PKG_CONFIG) --cflags gtk+-3.0)
+GTK_LIBS = $(shell $(PKG_CONFIG) --libs gtk+-3.0)
 
 all: netmate.c layer2.h layer3.h layer4.h
-	gcc $(CPPFLAGS) $(GTK_CFLAGS) $(CFLAGS) -c netmate.c -o netmate.o
-	gcc $(LDFLAGS) netmate.o $(GTK_LIBS)  -lpcap -o netmate
+	$(CC) $(CPPFLAGS) $(GTK_CFLAGS) $(CFLAGS) -c netmate.c -o netmate.o
+	$(CC) $(LDFLAGS) netmate.o $(GTK_LIBS)  -lpcap -o netmate
 
 install:
 	install -D -m 755 netmate $(DESTDIR)/$(BINDIR)/netmate

Bug#929329: plume-creator FTCBFS: wrong qmake

[Helmut Grohne]

Source: plume-creator
Version: 0.66+dfsg1-3.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

plume-creator fails to cross build from source, because it runs the
build architecture qmake. Using dh_auto_configure is the easiest way to
fix that. After fixing that, the cross build fails due to #887534.
Please consider applyig the attached patch.

Helmut
diff --minimal -Nru plume-creator-0.66+dfsg1/debian/changelog 
plume-creator-0.66+dfsg1/debian/changelog
--- plume-creator-0.66+dfsg1/debian/changelog   2016-01-13 21:53:03.0 
+0100
+++ plume-creator-0.66+dfsg1/debian/changelog   2019-05-21 20:37:06.0 
+0200
@@ -1,3 +1,10 @@
+plume-creator (0.66+dfsg1-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure use a cross qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 21 May 2019 20:37:06 +0200
+
 plume-creator (0.66+dfsg1-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru plume-creator-0.66+dfsg1/debian/rules 
plume-creator-0.66+dfsg1/debian/rules
--- plume-creator-0.66+dfsg1/debian/rules   2016-01-13 21:53:03.0 
+0100
+++ plume-creator-0.66+dfsg1/debian/rules   2019-05-21 20:37:06.0 
+0200
@@ -16,7 +16,7 @@
CFLAGS="$(CFLAGS) $(CPPFLAGS)" \
CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS)" \
LFLAGS="$(LDFLAGS) $(LDFLAGS2)" \
-   qmake -makefile plume-creator.pro
+   dh_auto_configure -- plume-creator.pro
touch $@
 
 build-stamp: config

Bug#929326: subversion: please add pkg.subversion.nokde build profile

[Jason Duerstock]

Source: subversion
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Dear Maintainer,

Subversion currently depends on KDE in order to build, which creates an
excessive build dependency chain.  Please accept the following patch
which adds a pkg.subversion.nokde build profile that removes the KDE
dependency requirement.

-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.19.0-5-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/control  2019-05-21 14:32:14.938904862 -0400
+++ debian/control  2019-05-21 14:32:25.070975575 -0400
@@ -17,9 +17,9 @@
libdb5.3-dev,
libdbus-1-dev,
liblz4-dev (>= 0.0~r129),
-   libkf5coreaddons-dev,
-   libkf5i18n-dev,
-   libkf5wallet-dev,
+   libkf5coreaddons-dev ,
+   libkf5i18n-dev ,
+   libkf5wallet-dev ,
libperl-dev,
libsasl2-dev,
libsecret-1-dev,
--- debian/rules2019-05-21 14:32:09.770868795 -0400
+++ debian/rules2019-05-21 14:32:20.826945955 -0400
@@ -89,7 +89,6 @@
--with-editor=/usr/bin/editor \
--with-ruby-sitedir=/usr/lib/ruby \
--with-swig=/usr/bin/swig \
-   --with-kwallet=/usr/include:$(libdir) \
--with-lz4 \
--with-utf8proc \
CFLAGS="$(CFLAGS)" \
@@ -102,6 +101,10 @@
   confflags+= --enable-debug
 endif
 
+ifeq ($(filter pkg.subversion.nokde,$(DEB_BUILD_PROFILES)),)
+  confflags+= --with-kwallet=/usr/include:$(libdir)
+endif
+
 export DH_OPTIONS
 ifdef DEB_OPT_WITH_JAVAHL
   # jikes 1.22 cannot compile javahl.

Bug#928227: unblock: golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3

[Paul Gevers]

Hi Shengjing,

I have decided that I'll let golang-golang-x-net-dev migrate to testing
do the binNMUs in buster. I'll leave the bug open until the rebuilds
have succeeded to keep track of the issue.

Let's hope for the best.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[sergio]

On 21/05/2019 18:06, Ross Vandegrift wrote:


> Where do you see the icon missing?

In the menu. Favorite and Applications.


> Does this only occur if ~/.cache is on /tmp?

Yes. In fact I have the following scheme:

~/.cache is a symlink to /tmp/sergio_cache/
~/.cache_persistent contains cache that should survive reboot (minidlna
and liferea for example as they are huge)

and

mkdir $(readlink ~/.cache)
ln -sf ~/.cache_persistent/* ~/.cache

in ~/.xsession


So, If I move correct efreet cache (after I press Application Theme ->
Icons, choose Adwaita icon theme) to ~/.cache_persistent all works fine.


But really all this doesn't matter as I've just reproduced this issue on
the new user profile, with empty e setting and no cache logic.

1. Just after the first logging in and answering configuration questions
   I see Pavucontrol icon in the application menu.
2. I press logout, switch to console (Alt-Ctrl-F1) and wait for the die
   of efreed.
3. In the .cache I see only efreed folder. I drop the whole folder or
   only icons_Adwaita_$HOST.eet, it doesn't matter.
4. Logging in again into e. The .cache/efreed folder is recreated,
   icons_Adwaita_$HOST.eet is present, but there are no icon for
   Pavucontrol in the application menu


> Is your /tmp on a different filesystem (i.e., tmpfs)?

Yes, my /tmp in on a tmpfs.


-- 
sergio.

Bug#927991: Fix for FTBFS

[Gregor Riepl]

Dear maintainer,

With the latest upload of MariaDB 10.3, --libmysqld-libs is now supported by
mysql_config/mariadb_config:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928230#46

Can you please trigger a rebuild of amarok once mariadb-10.3_1:10.3.15-1 has
hit unstable?

Please also consider unblocking the package so it can still go back into
buster, if possible.

Thanks!

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

[Romain Perier]

On Tue, May 21, 2019 at 09:59:21AM +0200, Diederik de Haas wrote:
> Got a new MB BIOS and after installing that, I made a new attempt with 
> firmware-amd-graphics version 20190502-1.
> It failed again, but it got slightly further this time.
> I saw a remount message, then a blinking cursor and then blank 
> screen+freeze+monitor in standby modus.
> I figured that would've produced a kern.log and it did; see attachment.
> 
> I have the upstream git repo on my machine and when I did
> "git log -- amdgpu/vega10_ce.bin" I noticed commit 
> 0f22c8527439eaaf5c3fcf87b31c89445b6fa84d with the following message:
> Revert "amdgpu: update vega10 fw for 18.50 release"
> 
> This reverts commit ec4b0cd394472ee1491df6ef5f215d1f0953f836.
> 
> This causes GPU hangs for some users.  Let's revert for now
> while we try and root cause the issue.
> 
> Sounds familiar.
> 
> What I could do is getting the various versions of amdgpu/vega10* from the 
> upstream git repo and place them in /lib/firmware/amdgpu/ to see which 
> versions 
> work and which don't.
> Would that be useful? Any specific tests I should do or data to gather 
> (please 
> indicate how I should do that)
> 
> Cheers,
>   Diederik

Hi,

firmware-amd-graphics 20190502-1 is based onto upstream commit
92e17d0dd2437140fab044ae62baf69b35d7d1fa, that is commit "amdgpu: update vega20 
to the latest 19.10 firmware"
. Two commits behind there is commit "amdgpu: update vega10 to the latest 19.10 
firmware", that is
already included in firmware-amd-graphics 20190502-1.

Could you try to revert "amdgpu: update vega10 to the latest 19.10
firmware" ? So try to use the firmware for vega10 that is before this commit. 
Does it work for you ?

1. Use linux-firmware.git with last HEAD in the master branch
2. git checkout 4ea5c73b96ed4a508f90047e22ccbaa477481310 (commit "amdgpu: 
update polaris11 to the latest 19.10 firmware", that is the commit before 
bumping vega10 to 19.10)
3. Copy vega10 binary blobs to /lib/firmware/amdgpu

Does it work ?


Thanks,
Regards,
Romain


> May 21 08:48:40 bagend kernel: [0.00] Linux version 4.19.0-5-amd64 
> (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP 
> Debian 4.19.37-3 (2019-05-15)
> May 21 08:48:40 bagend kernel: [0.00] Command line: 
> BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
> root=UUID=a2a5e481-0ac6-4e68-818f-38255bf7dd57 ro quiet
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Supporting XSAVE 
> feature 0x001: 'x87 floating point registers'
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Supporting XSAVE 
> feature 0x002: 'SSE registers'
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Supporting XSAVE 
> feature 0x004: 'AVX registers'
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: xstate_offset[2]:  
> 576, xstate_sizes[2]:  256
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Enabled xstate 
> features 0x7, context size is 832 bytes, using 'compacted' format.
> May 21 08:48:40 bagend kernel: [0.00] BIOS-provided physical RAM map:
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x-0x0009d3ff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0009d400-0x0009] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x000e-0x000f] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0010-0x09cf] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x09d0-0x09ff] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0a00-0x0a1f] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0a20-0x0a20afff] ACPI NVS
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0a20b000-0x0aff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0b00-0x0b01] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0b02-0xd873efff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xd873f000-0xdb030fff] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb031000-0xdb137fff] ACPI data
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb138000-0xdb244fff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb245000-0xdb60afff] ACPI NVS
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb60b000-0xdc68bfff] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdc68c000-0xdeff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 

Bug#929325: libmseed2: New upstream version (requires a transition)

[Paride Legovini]

Package: libmseed2
Version: 2.19.6-1
Severity: normal

Upstream is going to release a new major version of the library: libmseed3.
For the moment the 3.x tags are marked as pre-releases on GitHub.
Once released as stable and once Debian is out of the freeze I'll package the
new version and request the transition. Progress will be tracker here.

Paride

Bug#922246: #821096 is very much related

[Holger Levsen]

hi,

Debian#821096: filenames of generated by parse-advisory.pl and
parse-dls.pl files should include the revision number -
https://bugs.debian.org/821096


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#929324: Fwd: php-curl inability to send blank accept headers

[oneeyedspacefish]

Package: php-curl
Version: 1:7.0+49


Hello there!

I noticed using guzzle that we are unable to send a blank accept header, so
I had tested the same thing using the PHP-Curl extension.

The behavior seems to be the same; a '*/*, '  value is being sent using the
underlying 'Accept;' CURLOPT header.

The test code:

 \str_replace(' ', '%20',
'https://postman-echo.com/get?foo1=bar1=bar2'),
CURLOPT_RETURNTRANSFER => true,CURLOPT_HEADER => false,
CURLOPT_FOLLOWLOCATION => true,CURLOPT_AUTOREFERER => true,
CURLOPT_CONNECTTIMEOUT => 120,CURLOPT_TIMEOUT => 120,
CURLOPT_MAXREDIRS => 10,CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_HTTPHEADER => $curlHeaders,];$options[CURLOPT_CUSTOMREQUEST] =
'GET';\curl_setopt_array($curl, $options);echo
\curl_exec($curl);\curl_close($curl);

With Dockerfile (I'm using docker to be able to quickly test this behavior
under different platforms)

FROM php:7.3-cli
COPY test.php /usr/src/myapp/test.php
WORKDIR /usr/src/myapp
CMD [ "php", "./test.php" ]

I have back-tested this, and the behavior is the same for php:7.3-cli,
php:7.2-cli, php:7.1-cli, php:7.0-cli and php:5.6-cli.

And then I tested this using the alpine based images, of which seems to
behave correctly, and the blank header is being sent accordingly.

This is a guess on my part, but at this stage I suspect that the Debian
curl extension causing this difference of behavior.

Bug#929271: backports customizations are not enabled for live-build

[PICCORO McKAY Lenz]

Roland, i track back all the history and get not lost.. BUT IN ANY CASE
THAT BEHAVIOUR ARE NOT VIABLE, lest see:

about the commits history: seems the migration was not as espected
(migrations was done good but the results are not same as xpected)

the commits are :
https://salsa.debian.org/live-team/live-build/commit/dd15ade8bbdc6360816ed858253e7aaa68e4c9c2

and also
https://salsa.debian.org/live-team/live-build/commit/68700f466c142082e7423282ca4caaf7552bf8e9

I EXPLAIN WHY THAT COMMITS MUST BE REVERTED

1. - the mirror are track from default mirror.. so oldstable moving of
backports (as seems always) are not in same repository, that made this
behaviour ilogic and ridiculus, due for olstable the repository will be
archived .. same for updates repository!

2. -for low performance networks it's a good practice have differents
mirrors so download task will be separatelly, i mean event have normal and
backports in same domain.. i setup different origin domains sources for
normal repository and backports repository... that's a good practice

there's more reason but in my case those are enouoght

Please therat that issue quick due i cannot build any jessie image property
or i cannot use any strecth image in good shape!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


El mar., 21 de may. de 2019 a la(s) 02:38, Roland Clobus (rclo...@rclobus.nl)
escribió:

> Hello PICCORO,
>
> On 20/05/2019 15:42, PICCORO McKAY Lenz wrote:
> > when try to build live jessie image using strecht i got those errors
> >
> > lb config: unrecognized option '--mirror-chroot-updates'
> > lb config: unrecognized option '--parent-mirror-binary-updates'
> > lb config: unrecognized option '--parent-mirror-chroot-updates'
>
> When working on the documentation, I've noticed these command line
> options as well. They are not present in the scripts, they are only in
> the documentation.
> Unfortunately due to the migration from alioth to salsa the git history
> got lost, so I cannot trace it back. I would assume that the
> functionality was remove from the scripts at some time, and that someone
> forgot to update the documentation accordingly. I've downloaded the
> package 1:20151215 [1], and the command line is mentioned there also
> only in the documentation, which confirms my assumption.
>
> Instead of (re-)implementing these options, I would update the
> documentation instead.
>
> With kind regards,
> Roland Clobus
>
> [1] https://snapshot.debian.org/package/live-build/1%3A20151215/
>
>
>
>

Bug#929323: cacti-spine: results_buffer size limits reporting capabilities

[Anthony Bible]

Package: cacti-spine
Version: 1.1.37-2~bpo9+1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
We have several services being checked that return more than 1024 bytes 
(with_resluts_buffer limit of cacti-spine). This makes it so information 
doesn't get catalouged by cacti.  
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
We use several different scripts, two of which  is a vanrish check: 
https://github.com/glensc/cacti-template-varnish and percona 
https://www.percona.com/doc/percona-monitoring-plugins/LATEST/cacti/creating-graphs.html.
 I assume there are many more packages that require a results_buffer more than 
1024 bytes
   * What was the outcome of this action?
   * What outcome did you expect instead?
The poller should reliably store information more than 1024 bytes. I 
believe the solution is to increase the default compile option of the 
with_results_buffer to at least 2048 bytes as services grow to return more data.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cacti-spine depends on:
ii  cacti  1.1.38+ds1-1~bpo9+1
ii  dbconfig-no-thanks 2.0.11~bpo9+1
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u4
ii  libcap21:2.25-1
ii  libmariadbclient18 10.1.38-0+deb9u1
ii  libsnmp30  5.7.3+dfsg-1.7+deb9u1
ii  ucf3.0036

Versions of packages cacti-spine recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages cacti-spine suggests:
ii  snmp-mibs-downloader  1.1+nmu1

-- no debconf information

Bug#929322: partman-auto: Should increase size of / in multi and home recipes

[Raphael Hertzog]

Package: partman-auto
Version: 148
Severity: wishlist
Tags: patch
User: de...@kali.org
Usertags: origin-kali

The size of the root partition has not been reevaluated since 2014 but the
size of typical installations has grown in the mean time. When you install
a Debian system with many packages (such as in many live images) and when
you select a recipe with multiple partitions, you might find that / is too
small to contain all the applications/data.

We have this problem in Kali where our standard installation is about
8Gb. And nowadays a typical desktop dist-upgrade will require 2 Gb in
/var too.

Thus I'm suggesting to increase the size both of the root partition and of
the /var partition.

Please find attached a suggested patch which increases / to 12Gb in all
recipes and /var to 2.5Gb in the multi recipe.

The net result is that the multi and home recipes will not be proposed
when you have disks smaller than 18Gb roughly which sounds about right.
Anyone who wants multiple partitions on disks smaller than that should do
it manually based on their own analysis.

Let me know if you are happy with this change and I can commit it (after
the buster release I assume). This patch is in use in Kali.

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
--- a/recipes-amd64-efi/home
+++ b/recipes-amd64-efi/home
@@ -14,7 +14,7 @@ partman-auto/text/home_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-1500 6000 3 $default_filesystem
+12000 6000 3 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes-amd64-efi/multi b/recipes-amd64-efi/multi
index 78639ed..3b74b0a 100644
--- a/recipes-amd64-efi/multi
+++ b/recipes-amd64-efi/multi
@@ -14,7 +14,7 @@ partman-auto/text/multi_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-2000 3500 25000 $default_filesystem
+12000 3500 25000 $default_filesystem
$lvmok{ }
method{ format }
format{ }
@@ -22,7 +22,7 @@ partman-auto/text/multi_scheme ::
$default_filesystem{ }
mountpoint{ / } .
 
-1000 1500 1 $default_filesystem
+2500 1500 1 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes-armhf/home b/recipes-armhf/home
index 9362612..9a69ff2 100644
--- a/recipes-armhf/home
+++ b/recipes-armhf/home
@@ -9,7 +9,7 @@ partman-auto/text/home_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-1500 6000 2 $default_filesystem
+12000 6000 2 $default_filesystem
$lvmok{ }
$primary{ }
method{ format }
diff --git a/recipes-armhf/multi b/recipes-armhf/multi
index 690676a..9f58371 100644
--- a/recipes-armhf/multi
+++ b/recipes-armhf/multi
@@ -9,7 +9,7 @@ partman-auto/text/multi_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-2000 3500 25000 $default_filesystem
+12000 3500 25000 $default_filesystem
$lvmok{ }
$primary{ }
method{ format }
@@ -18,7 +18,7 @@ partman-auto/text/multi_scheme ::
$default_filesystem{ }
mountpoint{ / } .
 
-1000 1500 1 $default_filesystem
+2500 1500 1 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes/home b/recipes/home
index 6abd95f..2603759 100644
--- a/recipes/home
+++ b/recipes/home
@@ -13,7 +13,7 @@ partman-auto/text/home_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-1500 6000 3 $default_filesystem
+12000 6000 3 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes/multi b/recipes/multi
index b7b7f55..5e2ea3c 100644
--- a/recipes/multi
+++ b/recipes/multi
@@ -13,7 +13,7 @@ partman-auto/text/multi_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-2000 3500 25000 $default_filesystem
+12000 3500 25000 $default_filesystem
$lvmok{ }
method{ format }
format{ }
@@ -21,7 +21,7 @@ partman-auto/text/multi_scheme ::
$default_filesystem{ }
mountpoint{ / } .
 
-1000 1500 1 $default_filesystem
+2500 1500 1 $default_filesystem
$lvmok{ }
method{ format }
format{ }

Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)

[Thomas Goirand]

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

Please unblock package sqlalchemy,

My last (team-)upload for version 1.2.18+ds1-2 adds a patch from upstream
for CVE-2019-7164 CVE-2019-7548, which is an SQL vulnerability problem.

Note that it may (or not) break some reverse dependencies, though according
to upstream, OpenStack (the biggest SQLAlchemy consumer in Debian) behaves
correctly with it. If this happens, then these reverse dependencies will
have to be fixed.

Debdiff attached.

unblock sqlalchemy/1.2.18+ds1-2

Cheers,

Thomas Goirand (zigo)
diff -Nru sqlalchemy-1.2.18+ds1/debian/changelog 
sqlalchemy-1.2.18+ds1/debian/changelog
--- sqlalchemy-1.2.18+ds1/debian/changelog  2019-02-25 00:01:50.0 
+0100
+++ sqlalchemy-1.2.18+ds1/debian/changelog  2019-05-21 16:23:35.0 
+0200
@@ -1,3 +1,11 @@
+sqlalchemy (1.2.18+ds1-2) unstable; urgency=high
+
+  * Team upload.
+  * CVE-2019-7164 CVE-2019-7548: SQL injection. Apply upstream backported patch
+for this. Note: This potentially impacts applications (Closes: #922669).
+
+ -- Thomas Goirand   Tue, 21 May 2019 16:23:35 +0200
+
 sqlalchemy (1.2.18+ds1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
--- 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
   1970-01-01 01:00:00.0 +0100
+++ 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
   2019-05-21 16:23:35.0 +0200
@@ -0,0 +1,331 @@
+Description: CVE-2019-7164 / CVE-2019-7548: Illustrate fix for #4481 in terms 
of a 1.2 patch
+ Release 1.2 has decided (so far) not to backport 1.3's fix for #4481 as it is
+ backwards-incompatible with code that relied upon the feature of automatic 
text
+ coercion in SQL statements.  However, for the specific case of order_by() and
+ group_by(), we present a patch that backports the specific change in compiler
+ to have 1.3's behavior for order_by/group_by specifically.   This is much more
+ targeted than the 0.9 version of the patch as it takes advantage 1.0's
+ architecture which runs all order_by() / group_by() through a label lookup 
that
+ only warns if the label can't be matched.
+ .
+ For an example of an application that was actually impacted by 1.3's change
+ and how they had to change it, see:
+ .
+ https://github.com/ctxis/CAPE/commit/be0482294f5eb30026fe97a967ee5a768d032278
+ .
+ Basically, in the uncommon case an application is actually using the text
+ coercion feature which was generally little-known, within the order_by()
+ and group_by() an error is now raised instead of a warning; the application
+ must instead ensure the SQL fragment is passed within a text() construct.
+ The above application has also been seeing a warning about this since 1.0
+ which apparently remained unattended.
+ .
+ The patch includes adjustments to the tests that were testing for the
+ warning to now test that an exception is raised. Any distro that wants
+ to patch the specific CVE issue resolved in #4481 to SQLAlchemy 1.0, 1.1
+ or 1.2 can use this patch.
+Author: Mike Bayer 
+Date: Mon, 08 Apr 2019 22:07:35 -0400
+Change-Id: I3363b21428f1ad8797394b63197375a2e56a0bd7
+References: #4481
+Bug-Debian: https://bugs.debian.org/922669
+Origin: upstream, 
https://gerrit.sqlalchemy.org/#/c/sqlalchemy/sqlalchemy/+/1184/
+Last-Update: 2019-05-21
+
+diff --git a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py
+index 5a11ed1..4780bab 100644
+--- a/lib/sqlalchemy/sql/compiler.py
 b/lib/sqlalchemy/sql/compiler.py
+@@ -757,12 +757,11 @@
+ else:
+ col = with_cols[element.element]
+ except KeyError:
+-# treat it like text()
+-util.warn_limited(
+-"Can't resolve label reference %r; converting to text()",
+-util.ellipses_string(element.element),
++elements._no_text_coercion(
++element.element,
++exc.CompileError,
++"Can't resolve label reference for ORDER BY / GROUP BY.",
+ )
+-return self.process(element._text_clause)
+ else:
+ kwargs["render_label_as_label"] = col
+ return self.process(
+diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py
+index 299fcad..ff86deb 100644
+--- a/lib/sqlalchemy/sql/elements.py
 b/lib/sqlalchemy/sql/elements.py
+@@ -4432,6 +4432,17 @@
+ )
+ 
+ 
++def _no_text_coercion(element, exc_cls=exc.ArgumentError, extra=None):
++raise exc_cls(
++"%(extra)sTextual SQL expression %(expr)r should be "
++"explicitly declared as 

Bug#929320: unblock: libpfm4/4.10.1+git10-gd2a5b56-1

[Andreas Beckmann]

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

Please unblock package libpfm4

This is a new upstream snapshot updating the event definitions for some
CPU models.

unblock libpfm4/4.10.1+git10-gd2a5b56-1

Andreas
diff --git a/Makefile b/Makefile
index 440249f..c928088 100644
--- a/Makefile
+++ b/Makefile
@@ -65,11 +65,14 @@ tar: clean
ln -s $$PWD ../$(PKG) && cd .. &&  $(TAR) -zcf $(TARBALL) $(PKG)/. && 
rm $(PKG)
@echo generated ../$(TARBALL)
 
-install: 
-   @echo installing in $(DESTDIR)
-   @set -e ; for d in $(DIRS) ; do $(MAKE) -C $$d $@ ; done
-
-install_examples:
+install-lib:
+   @echo installing in $(DESTDIR)$(PREFIX)
+   @$(MAKE) -C lib install
+install install-all:
+   @echo installing in $(DESTDIR)$(PREFIX)
+   @set -e ; for d in $(DIRS) ; do $(MAKE) -C $$d install ; done
+install-examples install_examples:
+   @echo installing in $(DESTDIR)$(PREFIX)
@set -e ; for d in $(EXAMPLE_DIRS) ; do $(MAKE) -C $$d $@ ; done
 
 tags:
@@ -79,6 +82,6 @@ tags:
 static:
make all CONFIG_PFMLIB_SHARED=n
 
-.PHONY: all clean distclean depend tar install install_examples lib static
+.PHONY: all clean distclean depend tar install install-all install-lib 
install-examples lib static install_examples
 
 # DO NOT DELETE
diff --git a/config.mk b/config.mk
index cc9a6d9..daa982e 100644
--- a/config.mk
+++ b/config.mk
@@ -116,7 +116,7 @@ AGE=1
 #
 # Where should things (lib, headers, man) go in the end.
 #
-PREFIX=/usr/local
+PREFIX?=/usr/local
 LIBDIR=$(PREFIX)/lib
 INCDIR=$(PREFIX)/include
 MANDIR=$(PREFIX)/share/man
diff --git a/debian/changelog b/debian/changelog
index fed9f51..bae0b83 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+libpfm4 (4.10.1+git10-gd2a5b56-1) unstable; urgency=medium
+
+  * New upstream GIT snapshot.
+- Update SKX and CLX event tables.
+
+ -- Andreas Beckmann   Sat, 18 May 2019 15:13:01 +0200
+
+libpfm4 (4.10.1+git9-gac95d19-1) unstable; urgency=medium
+
+  * New upstream GIT snapshot.
+- Remove MERGE event from AMD Fam17h table.
+
+ -- Andreas Beckmann   Tue, 30 Apr 2019 01:46:05 +0200
+
 libpfm4 (4.10.1+git6-g8f2208a-1) unstable; urgency=medium
 
   * New upstream GIT snapshot.
diff --git a/debian/snapshot.sh b/debian/snapshot.sh
index 4c68d61..4d15f21 100755
--- a/debian/snapshot.sh
+++ b/debian/snapshot.sh
@@ -5,7 +5,8 @@ set -e
 
 commit=${1:-libpfm4/master}
 
-gitver=$(git describe --tags ${commit})
+upsver=$(git describe --tags ${commit})
+gitver=$(git describe --match ${upsver%+git*} --tags ${commit})
 gitver=${gitver#v}
 tagver=${gitver%%-*}
 gitver=${gitver#${tagver}-}
diff --git a/debian/source/lintian-overrides b/debian/source/lintian-overrides
new file mode 100644
index 000..53fb7f6
--- /dev/null
+++ b/debian/source/lintian-overrides
@@ -0,0 +1,2 @@
+# this is a git snapshot
+hyphen-in-upstream-part-of-debian-changelog-version
diff --git a/docs/man3/pfm_get_os_event_encoding.3 
b/docs/man3/pfm_get_os_event_encoding.3
index 6ec57be..c9cab18 100644
--- a/docs/man3/pfm_get_os_event_encoding.3
+++ b/docs/man3/pfm_get_os_event_encoding.3
@@ -64,7 +64,7 @@ in this field. The typical calling sequence looks as follows:
PFM_OS_NONE,
);
if (ret == PFM_SUCCESS) {
-  printf("fstr=%s\n", fstr);
+  printf("fstr=%s\\n", fstr);
   free(fstr);
}
 .fi
diff --git a/examples/Makefile b/examples/Makefile
index 68d1081..fc5677a 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -51,7 +51,7 @@ clean:
 
 distclean: clean
 
-install_examples: $(TARGETS)
+install-examples install_examples: $(TARGETS)
@echo installing: $(TARGETS)
-mkdir -p $(EXAMPLESDIR)
$(INSTALL) -m 755 $(TARGETS) $(EXAMPLESDIR)
@@ -59,4 +59,4 @@ install_examples: $(TARGETS)
 #
 # examples are installed as part of the RPM install, typically in 
/usr/share/doc/libpfm-X.Y/
 #
-.PHONY: install depend install_examples
+.PHONY: install depend install-example install_examples
diff --git a/lib/events/amd64_events_fam17h.h b/lib/events/amd64_events_fam17h.h
index b0db898..deadbed 100644
--- a/lib/events/amd64_events_fam17h.h
+++ b/lib/events/amd64_events_fam17h.h
@@ -953,13 +953,6 @@ static const amd64_entry_t amd64_fam17h_pe[]={
 .numasks = LIBPFM_ARRAY_SIZE(amd64_fam17h_tablewalker_allocation),
 .umasks = amd64_fam17h_tablewalker_allocation,
   },
-  { .name   = "MERGE",
-.desc   = "Merge two counters together. This event must be programmed on 
the odd performance counter",
-.modmsk  = AMD64_FAM17H_ATTRS,
-.code= 0xfff,
-.flags   = 0,
-.ngrp= 0,
-  },
   { .name   = "L1_BTB_CORRECTION",
 .desc   = "TBD",
 .modmsk  = AMD64_FAM17H_ATTRS,
diff --git a/lib/events/intel_skl_events.h b/lib/events/intel_skl_events.h
index 4e1b355..20c8b7a 100644
--- a/lib/events/intel_skl_events.h
+++ b/lib/events/intel_skl_events.h
@@ -309,6 

Bug#929319: Move mkvtoolnix-gui.1 from package mkvtoolnix to mkvtoolnix-gui

[Dylan Aïssi]

Package: src:mkvtoolnix
Severity: minor
Tags: patch

Hi,

The manpage of mkvtoolnix-gui is not provided by the package which
provides the binary of mkvtoolnix-gui. Currently, manpage of
mkvtoolnix-gui is provided by mkvtoolnix. I guess is should be better
to move the manpage to the package which provides the binary. Please
find attached a patch to do this (you will have to adapt Breaks and
Replaces according to the new version).

Best,
Dylan
From 500f99b99dac97932d24c42164ad63c3a2a8a468 Mon Sep 17 00:00:00 2001
From: Dylan Aïssi 
Date: Sat, 4 May 2019 09:34:07 +0200
Subject: [PATCH] Move mkvtoolnix-gui.1 from package mkvtoolnix to mkvtoolnix-gui

---
 debian/control| 4 +++-
 debian/mkvtoolnix-gui.install | 2 ++
 debian/mkvtoolnix.install | 9 -
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index b5d3d766..172b40e8 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends: debhelper-compat (= 12), libboost-math-dev, libboost-regex-dev,
 Package: mkvtoolnix
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: mkvtoolnix-gui (<< 31.0.0-2)
 Suggests: mkvtoolnix-gui
 Description: Set of command-line tools to work with Matroska files
  Matroska is a new multimedia container format, based on EBML (Extensible
@@ -30,7 +31,8 @@ Description: Set of command-line tools to work with Matroska files
 Package: mkvtoolnix-gui
 Architecture: any
 Depends: mkvtoolnix (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
-Replaces: mkvtoolnix (<= 4.6.0-1)
+Breaks: mkvtoolnix (<< 31.0.0-2)
+Replaces: mkvtoolnix (<< 31.0.0-2)
 Description: Set of tools to work with Matroska files - GUI frontend
  Matroska is a new multimedia container format, based on EBML (Extensible 
  Binary Meta Language), which is a kind of binary XML.
diff --git a/debian/mkvtoolnix-gui.install b/debian/mkvtoolnix-gui.install
index e9716086..179a142e 100644
--- a/debian/mkvtoolnix-gui.install
+++ b/debian/mkvtoolnix-gui.install
@@ -6,3 +6,5 @@ usr/share/mkvtoolnix/sounds/finished-2.ogg
 usr/share/mkvtoolnix/sounds/finished-3.ogg
 usr/share/mime/packages/org.bunkus.mkvtoolnix-gui.xml
 usr/share/metainfo/org.bunkus.mkvtoolnix-gui.appdata.xml
+usr/share/man/man1/mkvtoolnix-gui.1
+usr/share/man/*/man1/mkvtoolnix-gui.1
diff --git a/debian/mkvtoolnix.install b/debian/mkvtoolnix.install
index 65a94d5f..5c174d53 100644
--- a/debian/mkvtoolnix.install
+++ b/debian/mkvtoolnix.install
@@ -2,7 +2,14 @@ usr/bin/mkvmerge
 usr/bin/mkvinfo
 usr/bin/mkvextract
 usr/bin/mkvpropedit
-usr/share/man
+usr/share/man/man1/mkvextract.1
+usr/share/man/man1/mkvinfo.1
+usr/share/man/man1/mkvmerge.1
+usr/share/man/man1/mkvpropedit.1
+usr/share/man/*/man1/mkvextract.1
+usr/share/man/*/man1/mkvinfo.1
+usr/share/man/*/man1/mkvmerge.1
+usr/share/man/*/man1/mkvpropedit.1
 usr/share/locale
 usr/share/icons/hicolor/*/apps/mkvpropedit.png
 usr/share/icons/hicolor/*/apps/mkvextract.png
-- 
2.11.0

Bug#929318: unblock: papi/5.7.0+dfsg-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: block -1 with 928368

Please unblock package papi

Hi,

there are two things that need to be fixed in PAPI for buster.
* transition libpapi5 -> libpapi5.7, (one package needs a binNMU),
  see #928368 for details (upstream has now accepted and applied my
  patch)
* removal of non-dfsg-free iozone code (only used for tests for a
  component not included in our builds, so no negative effect)

The package is not uploaded to unstable yet, waiting for 5.7.0-2 to pass
experimental/NEW for libpapi5.7.

 debian/changelog   |16 
+
 debian/control |12 
+-
 debian/copyright   | 6 
+-
 debian/gbp.conf| 2 
+-
 debian/libpapi5.install| 2 
-
 debian/{libpapi5.README.Debian => libpapiSOVERSION.README.Debian}  | 0
 debian/{libpapi5.docs => libpapiSOVERSION.docs}| 0
 debian/libpapiSOVERSION.install| 2 
+
 debian/{libpapi5.symbols => libpapiSOVERSION.symbols}  |20 
+-
 debian/patches/0001-set-SONAME-to-libpapi.so.-PAPIVER-.-PAPIREV.patch  |   163 
+
 debian/patches/0002-Clean-up-of-carriage-return-character-M-from.patch |   119 
+
 debian/patches/do-not-ignore-failures.patch| 8 
+-
 debian/patches/for-debian-no-rpath.patch   | 4 
+-
 debian/patches/series  | 2 
+
 debian/rules   |20 
+
 debian/watch   | 3 
+-
 src/components/appio/tests/iozone/Changes.txt  |  2409 

 src/components/appio/tests/iozone/Generate_Graphs  |32 
-
 src/components/appio/tests/iozone/Gnuplot.txt  |23 
-
 src/components/appio/tests/iozone/client_list  |36 
-
 src/components/appio/tests/iozone/fileop.c |  1389 
---
 src/components/appio/tests/iozone/gengnuplot.sh|57 
-
 src/components/appio/tests/iozone/gnu3d.dem|   146 
-
 src/components/appio/tests/iozone/gnuplot.dem  |60 
-
 src/components/appio/tests/iozone/gnuplotps.dem|63 
-
 src/components/appio/tests/iozone/iozone.c | 25297 
---
 src/components/appio/tests/iozone/iozone_visualizer.pl |   262 
-
 src/components/appio/tests/iozone/libasync.c   |  1604 
---
 src/components/appio/tests/iozone/libbif.c |   452 
-
 src/components/appio/tests/iozone/makefile |  1461 
---
 src/components/appio/tests/iozone/pit_server.c |   831 
--
 src/components/appio/tests/iozone/read_telemetry   |29 
-
 src/components/appio/tests/iozone/report.pl|   150 
-
 src/components/appio/tests/iozone/spec.in  |   107 
-
 src/components/appio/tests/iozone/write_telemetry  |29 
-
 35 files changed, 350 insertions(+), 34466 deletions(-)

A git diff (since it better copes with the renames) from 5.7.0-1 in buster
with the deletions excluded is attached. Obviously still needs a dch -r :-)

unblock papi/5.7.0+dfsg-1

Thanks for considering,


Andreas
diff --git a/debian/changelog b/debian/changelog
index d019e5d..2c87196 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+papi (5.7.0+dfsg-1) UNRELEASED; urgency=medium
+
+  * Repack upstream tarball to remove src/components/appio/tests/iozone/*
+which does not permit distribution of derivative works.  (Closes: #928959)
+
+ -- Andreas Beckmann   Mon, 20 May 2019 14:35:18 +0200
+
+papi (5.7.0-2) experimental; urgency=medium
+
+  * Restore support for changing the SOVERSION frequently.
+  * Change SONAME to libpapi.so.5.7.  (Closes: #928367)
+  * Bump libpfm4-dev B-D to >= 4.10.1+git7.
+  * Upload to experimental.
+
+ -- Andreas Beckmann   Mon, 06 May 2019 02:14:13 +0200
+
 papi (5.7.0-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index 9cb1a61..8da8e4c 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Uploaders:
  Andreas Beckmann 
 Build-Depends:
  debhelper-compat (= 12),
- libpfm4-dev (>= 4.10.1+git6),
+ libpfm4-dev (>= 4.10.1+git7),
  gfortran,
 Rules-Requires-Root: no
 Standards-Version: 4.3.0
@@ -15,15 +15,17 @@ Homepage: 

Bug#924132: runit: Add support for runit in init-system-helpers

[Lorenzo Puliti]

Control: reassign 924132 init-system-helpers

Dear init-system-helpers Maintainers,
 
 here are a series of 5 commits that add support for runit-init into
 'update-rc.d', 'invoke-rc.d' and 'service' scripts.
 
 https://salsa.debian.org/Lorenzo.ru.g-guest/init-system-helpers/commits/runit
 
 This has been already reviewed by Dmitry Bogatov.
 If you don't have further question or requirements, can you upload to 
experimental 
 and then, after Buster release, to unstable?
 
 Thanks,
 Lorenzo



-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.28-10
ii  runit-helper2.8.10
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-30

runit suggests no packages.

-- Configuration Files:
/etc/runit/2 changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

Bug#929317: unblock: dmarc-cat/0.9.2-2

[Antoine Beaupre]

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

Please unblock package dmarc-cat

Test suite communicates with network, RC bug #928990

Fixed package uploaded to unstable, debdiff:

diff -Nru dmarc-cat-0.9.2/debian/changelog dmarc-cat-0.9.2/debian/changelog
--- dmarc-cat-0.9.2/debian/changelog2019-02-06 10:21:31.0 -0500
+++ dmarc-cat-0.9.2/debian/changelog2019-05-21 10:13:55.0 -0400
@@ -1,3 +1,10 @@
+dmarc-cat (0.9.2-2) unstable; urgency=medium
+
+  * move test suite to autopkgtest because of network access (Closes:
+#928990)
+
+ -- Antoine Beaupré   Tue, 21 May 2019 10:13:55 -0400
+
 dmarc-cat (0.9.2-1) unstable; urgency=medium
 
   * new upstream release
diff -Nru dmarc-cat-0.9.2/debian/rules dmarc-cat-0.9.2/debian/rules
--- dmarc-cat-0.9.2/debian/rules2019-02-06 10:21:31.0 -0500
+++ dmarc-cat-0.9.2/debian/rules2019-05-21 10:13:55.0 -0400
@@ -6,6 +6,8 @@
 %:
dh $@ --buildsystem=golang --with=golang
 
+override_dh_auto_test:
+   echo "W: skipping test suite that attempts network connexions during 
build, see #928990"
 
 override_dh_dwz:
echo "W: dwz(1) fails on this package, cause unknown"
diff -Nru dmarc-cat-0.9.2/debian/tests/control 
dmarc-cat-0.9.2/debian/tests/control
--- dmarc-cat-0.9.2/debian/tests/control1969-12-31 19:00:00.0 
-0500
+++ dmarc-cat-0.9.2/debian/tests/control2019-05-21 10:13:55.0 
-0400
@@ -0,0 +1,3 @@
+Test-command: dh_auto_test
+Depends: @, @builddeps@
+Restrictions: build-needed, rw-build-tree

unblock dmarc-cat/0.9.2-2

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

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

Bug#929316: dkms driver acpi-call can leak memory

[Colin Ian King]

Package: acpi-call
Version: 1.1.0-4

Static analysis with Coverity has picked up a memory leak in the
acpi-call dkms driver.

In function acpi_proc_write() the call to parse_acpi_args() can return
allocated buffers as pointed to by args even when the function returns
null.  Hence the kfree of args buffers needs to be done if args is not
null no matter if method is null or not-null.

Attached is a proposed fixed to go into debian/patches.

Regards,

Colin
Description: Fix memory leak on args
 parse_acpi_args can may have allocated args even when method is null
Author: Colin Ian King 
Origin: vendor, https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1829883
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1829883
Last-Update: 2019-05-21
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: acpi-call-1.1.0/acpi_call.c
===
--- acpi-call-1.1.0.orig/acpi_call.c
+++ acpi-call-1.1.0/acpi_call.c
@@ -282,14 +282,15 @@ static int acpi_proc_write( struct file
 input[len-1] = '\0';
 
 method = parse_acpi_args(input, , );
-if (method) {
+if (method)
 do_acpi_call(method, nargs, args);
-if (args) {
-for (i=0; i

Bug#929315: docker.io: Please configure docker0 ip address and netmask at install time

[Salvo Tomaselli]

Package: docker.io
Version: 18.09.1+dfsg1-7~deb10u1
Severity: important

Dear Maintainer,

as it is, docker.io will automatically start and create a docker0 network
interface with some hard-coded IP address, and there is no file in /etc that
can be edited to change said IP address.

One must look into the documentation, find out that a file called
 /etc/docker.daemon.json
needs to be created, with a field called "bip", and have as value an
ip/netmask.

It is important because for some people (for example me) having an interface
pop up with an hard coded address can cause collisions with existing routes and
local network configuration.

So ideally, this shouldbe configured at install time, like postfix-style, but
at the very least, a configuration file that one can just edit should be in
place.

Of course the .json files do not allow for commments, so one should understand
that "bip" stands for "bridge ip", but better than the current situation.

Best

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to 
it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages docker.io depends on:
ii  adduser 3.118
ii  iptables1.8.2-4
ii  libc6   2.28-10
ii  libdevmapper1.02.1  2:1.02.155-2
ii  libltdl72.4.6-9
ii  libnspr42:4.20-1
ii  libnss3 2:3.42.1-1
ii  libseccomp2 2.3.3-4
ii  libsystemd0 241-3
ii  lsb-base10.2019031300
ii  runc1.0.0~rc6+dfsg1-3
ii  tini0.18.0-1

Versions of packages docker.io recommends:
ii  ca-certificates  20190110
ii  cgroupfs-mount   1.4
ii  git  1:2.20.1-2
ii  needrestart  3.4-3
ii  xz-utils 5.2.4-1

Versions of packages docker.io suggests:
pn  aufs-tools   
pn  btrfs-progs  
ii  debootstrap  1.0.114
pn  docker-doc   
ii  e2fsprogs1.44.5-1
pn  rinse
pn  xfsprogs 
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

On Tue, May 21, 2019 at 07:25:38AM +0300, sergio wrote:
> On 26/04/2019 22:19, Ross Vandegrift wrote:
> 
> > 1) Application Theme -> Icons, choose Adwaita icon theme.
> > 2) rm ~/.cache/efreet/icons_Adwaita_*
> > 3) log out and back in
> > 4) check pavucontrol icon in everything & menus
> 
> I can reproduce this with libefreet1a=1.21.1-5 from sid.
> 
> 
> > With a fresh efreetd, I cannot reproduce this issue.
> 
> What is "a fresh efreetd"? 

I meant ensuring that efreetd exits before login in step #3.  If you
always reboot after log out, then your efreetd should always be fresh.

Where do you see the icon missing?  Does this only occur if ~/.cache is
on /tmp?  Is your /tmp on a different filesystem (i.e., tmpfs)?

> Do you have deb that I can check?

Nope, I'm using 1.21.1-5 from buster.

Ross

Bug#868898: MR for 868898

[Rohan Garg]

Hi
I've uploaded a MR for bug 868898 here [1].

It'd be great if someone could have a look at it.

Cheers
Rohan Garg

[1] https://salsa.debian.org/xorg-team/lib/libdrm/merge_requests/3

Bug#915444: ITP: aspell-el -- Greek dictionary for GNU Aspell

[Vangelis Mouhtsis]

Package: wnnp

Severity: wishlist

Owner: Vangelis Mouhtsis 

* Package name    : aspell-el

  Version     : 0.50-3-6.2

   Upstream Author : Evripidis Papakostas 

* URL : http://ispell.source.gr

* Licence : GPL3

  Description : Greek dictionary for GNU Aspell

   This package contains all the required files to add support for the

   Greek language to the GNU Aspell spell checker.


-- 
GPG Fingerprint: 868D EF24 37CC E9F5 C5DC  63B7 5E57 25A1 FB41 2219



signature.asc
Description: OpenPGP digital signature

Bug#922669: Debdiff to fix this

[Thomas Goirand]

Hi,

Here's, attached to this message, the debdiff to fix this CVE. Note that
the patch was backported to 1.2 by upstream himself, so it's kind of
safe to apply, however, it may potentially impact SQLAlchemy reverse
dependencies. It should be safe for OpenStack applications though.

Please, either allow me to upload as-is, or build and upload yourself
ASAP (preferably, in time for Buster).

Cheers,

Thomas Goirand (zigo)
diff -Nru sqlalchemy-1.2.18+ds1/debian/changelog 
sqlalchemy-1.2.18+ds1/debian/changelog
--- sqlalchemy-1.2.18+ds1/debian/changelog  2019-02-25 00:01:50.0 
+0100
+++ sqlalchemy-1.2.18+ds1/debian/changelog  2019-05-21 16:23:35.0 
+0200
@@ -1,3 +1,11 @@
+sqlalchemy (1.2.18+ds1-2) unstable; urgency=high
+
+  * Team upload.
+  * CVE-2019-7164 CVE-2019-7548: SQL injection. Apply upstream backported patch
+for this. Note: This potentially impacts applications (Closes: #922669).
+
+ -- Thomas Goirand   Tue, 21 May 2019 16:23:35 +0200
+
 sqlalchemy (1.2.18+ds1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
--- 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
   1970-01-01 01:00:00.0 +0100
+++ 
sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch
   2019-05-21 16:23:35.0 +0200
@@ -0,0 +1,331 @@
+Description: CVE-2019-7164 / CVE-2019-7548: Illustrate fix for #4481 in terms 
of a 1.2 patch
+ Release 1.2 has decided (so far) not to backport 1.3's fix for #4481 as it is
+ backwards-incompatible with code that relied upon the feature of automatic 
text
+ coercion in SQL statements.  However, for the specific case of order_by() and
+ group_by(), we present a patch that backports the specific change in compiler
+ to have 1.3's behavior for order_by/group_by specifically.   This is much more
+ targeted than the 0.9 version of the patch as it takes advantage 1.0's
+ architecture which runs all order_by() / group_by() through a label lookup 
that
+ only warns if the label can't be matched.
+ .
+ For an example of an application that was actually impacted by 1.3's change
+ and how they had to change it, see:
+ .
+ https://github.com/ctxis/CAPE/commit/be0482294f5eb30026fe97a967ee5a768d032278
+ .
+ Basically, in the uncommon case an application is actually using the text
+ coercion feature which was generally little-known, within the order_by()
+ and group_by() an error is now raised instead of a warning; the application
+ must instead ensure the SQL fragment is passed within a text() construct.
+ The above application has also been seeing a warning about this since 1.0
+ which apparently remained unattended.
+ .
+ The patch includes adjustments to the tests that were testing for the
+ warning to now test that an exception is raised. Any distro that wants
+ to patch the specific CVE issue resolved in #4481 to SQLAlchemy 1.0, 1.1
+ or 1.2 can use this patch.
+Author: Mike Bayer 
+Date: Mon, 08 Apr 2019 22:07:35 -0400
+Change-Id: I3363b21428f1ad8797394b63197375a2e56a0bd7
+References: #4481
+Bug-Debian: https://bugs.debian.org/922669
+Origin: upstream, 
https://gerrit.sqlalchemy.org/#/c/sqlalchemy/sqlalchemy/+/1184/
+Last-Update: 2019-05-21
+
+diff --git a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py
+index 5a11ed1..4780bab 100644
+--- a/lib/sqlalchemy/sql/compiler.py
 b/lib/sqlalchemy/sql/compiler.py
+@@ -757,12 +757,11 @@
+ else:
+ col = with_cols[element.element]
+ except KeyError:
+-# treat it like text()
+-util.warn_limited(
+-"Can't resolve label reference %r; converting to text()",
+-util.ellipses_string(element.element),
++elements._no_text_coercion(
++element.element,
++exc.CompileError,
++"Can't resolve label reference for ORDER BY / GROUP BY.",
+ )
+-return self.process(element._text_clause)
+ else:
+ kwargs["render_label_as_label"] = col
+ return self.process(
+diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py
+index 299fcad..ff86deb 100644
+--- a/lib/sqlalchemy/sql/elements.py
 b/lib/sqlalchemy/sql/elements.py
+@@ -4432,6 +4432,17 @@
+ )
+ 
+ 
++def _no_text_coercion(element, exc_cls=exc.ArgumentError, extra=None):
++raise exc_cls(
++"%(extra)sTextual SQL expression %(expr)r should be "
++"explicitly declared as text(%(expr)r)"
++% {
++"expr": util.ellipses_string(element),
++"extra": "%s " % extra if extra else "",
++}
++)
++
++
+ def _no_literals(element):
+ 

Bug#929314: lxqt-openssh-askpass: Typo in package description

[Ralf Jung]

Package: lxqt-openssh-askpass
Version: 0.14.1-1
Severity: minor

Dear Maintainer,

the package description says "will perform security tast over scale access 
privilegies".
I don't know what that is supposed to mean, but it seems fairly far from an 
English sentence.

Kind regards,
Ralf

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lxqt-openssh-askpass depends on:
ii  libc6   2.28-10
ii  liblxqt00.14.1-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-6

Versions of packages lxqt-openssh-askpass recommends:
ii  lxqt-openssh-askpass-l10n  0.14.1-1
pn  lxqt-qtplugin  
pn  lxqt-session   

Versions of packages lxqt-openssh-askpass suggests:
pn  lxqt | lxqt-core  

-- no debconf information

Bug#929313: ITP: ocaml-cairo2 -- OCaml libraries interfacing to Cairo

[Ralf Treinen]

Package: wnpp
Severity: wishlist
Owner: Ralf Treinen 

* Package name: ocaml-cairo2
  Version : 0.6.1
  Upstream Author : Christophe Troestler 
* URL : https://github.com/Chris00/ocaml-cairo
* License : LGPL3
  Programming Lang: OCaml
  Description : OCaml libraries interfacing to Cairo
  This is an OCaml binding for the Cairo library, a 2D graphics library
  with support for multiple output devices.

***

This is a build-dependency for the most recent versions of lablgtk3.
The package will be maintained under the umbrella of the ocaml-team.

Bug#905022: gcc-8 documentation packages

[Dmitry Eremin-Solenikov]

Hello,

I've updated gcc-doc/gcc-doc-defaults packages to support new gcc-8
documentation generation. NMU Packages are uploaded to
mentors.debian.net
for review, git trees are put on salsa.debian.org/gcc-doc (-defaults).

-- 
With best wishes
Dmitry

Bug#929312: wxpython4.0: Build-Depends too loose: needs sip-dev >= 4.19.1

[Simon Richter]

Source: wxpython4.0
Version: 4.0.4+dfsg-2
Severity: normal

Hi,

while backporting to Devuan ascii, which has sip-dev 4.18.1+dfsg-2, I got a
build error:

Running command: sip
/usr/bin/sip -w -o -g -I /tmp/wxpython4.0-4.0.4+dfsg/src -I 
/tmp/wxpython4.0-4.0.4+dfsg/sip/gen -c /tmp/tmpxXqdbK -b sip/cpp/_core.sbf -X 
pycode_core:wx/core.py sip/gen/_core.sip
sip: sip/gen/display.sip:34: syntax error
Command '/usr/bin/sip -w -o -g -I /tmp/wxpython4.0-4.0.4+dfsg/src -I 
/tmp/wxpython4.0-4.0.4+dfsg/sip/gen -c /tmp/tmpxXqdbK -b sip/cpp/_core.sbf -X 
pycode_core:wx/core.py sip/gen/_core.sip' failed with exit code 1.
Finished command: sip (0.45s)

The line in question is "%PreMethodCode", which was introduced in sip
4.19.1, so the Build-Depends need to be tightened here.

   Simon

-- System Information:
Debian Release: 9.9
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#929311: gcc-9: please include fix for pr87338

[James Clarke]

Control: tags -1 pending
(sort of; changelog won't close this bug)

On 21 May 2019, at 14:24, Jason Duerstock  wrote:
> 
> Package: gcc-9
> Version: 9-20190428-1
> Severity: normal
> User: debian-i...@lists.debian.org
> Usertags: ia64
> 
> Dear Maintainer,
> 
> Please include the fix for pr87338 that was previously included in
> gcc-8.  This patch is required for gcc-9 to build under ia64.
> 
> Thank you.

Already done in git[1] less than an hour ago :)

James

[1] 
https://salsa.debian.org/toolchain-team/gcc/commit/8477738a263fd225e71b3d629c29c1bc38faca35

Bug#929311: gcc-9: please include fix for pr87338

[Jason Duerstock]

Package: gcc-9
Version: 9-20190428-1
Severity: normal
User: debian-i...@lists.debian.org
Usertags: ia64

Dear Maintainer,

Please include the fix for pr87338 that was previously included in
gcc-8.  This patch is required for gcc-9 to build under ia64.

Thank you.

-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.19.0-5-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-9 depends on:
ii  binutils  2.31.1-16
ii  cpp-9 9-20190428-1
ii  gcc-9-base9-20190428-1
ii  libc6.1   2.28-2
ii  libcc1-0  9-20190428-1
ii  libgcc-9-dev  9-20190428-1
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++69-20190428-1
ii  libunwind81.2.1-9
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages gcc-9 recommends:
ii  libc6.1-dev  2.28-2

Versions of packages gcc-9 suggests:
pn  gcc-9-doc 
pn  gcc-9-locales 
pn  libasan5-dbg  
pn  libatomic1-dbg
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan1-dbg 

-- no debconf information

Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH

[Jorge Barata González]

Got it. Thanks a million! I learned a lot from your responses :)

Jorge


On Tue, 21 May 2019 at 05:46, Theodore Ts'o  wrote:

> On Mon, May 20, 2019 at 08:17:09PM -0700, Noah Meyerhans wrote:
> > At this point, I think it'd be worth revisiting, at the project level,
> > the historical tradition of leaving the sbin directories out of non-root
> > paths. Setting aside all the single user desktop and laptop systems,
> > there are enough alternative ways to grant restricted root (file ACLs,
> > etc), and to run in alternate filesystem namespaces (e.g.  containers),
> > that the functional distinctions that lead to the original directory
> > split are probably applicable in a minority of situations these days.
>
> Sure, and I often use /sbin/mke2fs on create file system images on
> plain files and then corrupt them using /sbin/debugfs to create
> regression tests for e2fsck, and I do all of this w/o being root.  So
> I have /sbin and /usr/sbin and /usr/local/sbin in my path.  Along with
> a whole bunch of other customizations in my dot files, of course.
>
> But my usage is an edge case, and asking Debian to make changes to
> global changes to the defaults for people like me was never something
> I thought was justifiable.  Ultimately, if we believe that someday
> we'll have the year of the Linux Desktop, where the primary
> applications used by users are things like Firefox, Open Office,
> Tuxracer, etc., adding /sbin and /usr/sbin might not be doing those
> users a favor --- and those of us who are more technical are perfectly
> capable of customizing our dot files.  (Heck, I just pull a git repo
> into ~/dotfiles, and then run "make install" and I get a custom set of
> my dotfiles for that installation.  :-)
>
> > This isn't something that I feel strongly about, though. Anybody who
> > does should retitle this bug appropriately and reassign it to the
> > 'general' pseudopackage, whereupon it can be discussed on debian-devel.
> > Otherwise it should get tagged wontfix, unless someone thinks this is an
> > appropriate change to introduce at the cloud image level (I would not
> > agree with this).
>
> I agree this should be a project-level decision, and not cloud-image
> specific.  I personally am against changing the default.  That's
> because if someone is installing Debian on student laptops / desktops
> at an educational institution like MIT, most of those users really
> don't need /sbin and /usr/sbin; Debian users include far more than
> just system administrators, kernel developers, and devops types.
>
> I don't feel very strongly about it, though, so if the project as a
> whole thinks Debian should be optimized for technical users, it's not
> something I'll lose any sleep over.  I replace all of the default
> dotfiles for myself, anyway.  :-)
>
> - Ted
>

Bug#897109: fastqc: htsjdk.samtools.util.RuntimeIOException: java.io.IOException: Stream closed

[Andreas Tille]

Hi Dylan,

On Tue, May 21, 2019 at 02:32:48PM +0200, Dylan Aïssi wrote:
> Control: severity -1 serious
> 
> Hi,
> I have tested the testsuite with the upstream binary (FastQC 0.11.8)
> and there is no error, so the testsuite is fine. This bug was probably
> hidden before we added the test of bam and sam files. Currently,
> fastqc from our package is unable to process bam and sam files which
> is very annoying for Buster. I guess we have to modify
> htsjdk-api.patch, but I admit I have no clue how to fix it. The
> easiest way should be to add SAMFileReader like suggested in [1]. Any
> suggestion?

Thanks for pointing out this issue.
No better suggestion than the naive one that I gave in issue #767.
May be FastQC contacting upstream is a good idea.

Kind regards

Andreas.

> [1] https://github.com/samtools/htsjdk/issues/767#issuecomment-264843094

-- 
http://fam-tille.de

Bug#929310: monitoring-plugins-basic: check_ntp_peer does not allow unix socket for "-H"

[Ronny Lindner]

Package: monitoring-plugins-basic
Version: 2.2-3
Severity: normal

Dear Maintainer,

the help text for the "-H" option states:
 -H, --hostname=ADDRESS
 Host name, IP Address, or unix socket (must be an absolute path)

but it uses "is_host()" to test for a valid ip address or dns-hostname.
This behavior has not changed between 2.2-3 (stretch) and 2.2-6 (sid).

It should either not say "unix socket" in the help text or allow the
usage of unix sockets.

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages monitoring-plugins-basic depends on:
ii  iputils-ping   3:20161105-1
ii  libc6  2.24-11+deb9u4
ii  libssl1.1
1.1.1b-1+0~20190228092419.10+stretch~1.gbp729d89
ii  monitoring-plugins-common  2.2-3
ii  procps 2:3.3.12-3+deb9u1
ii  ucf3.0036

Versions of packages monitoring-plugins-basic recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages monitoring-plugins-basic suggests:
pn  icinga | icinga2  

-- no debconf information

Bug#915270: libgovirt: diff for NMU version 0.3.4-3.1

[Giovanni Mascellani]

Control: tags 915270 + patch
Control: tags 915270 + pending

Dear maintainer,

I've prepared an NMU for libgovirt (versioned as 0.3.4-3.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.

Regards, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
diff -Nru libgovirt-0.3.4/debian/changelog libgovirt-0.3.4/debian/changelog
--- libgovirt-0.3.4/debian/changelog	2018-12-28 03:33:34.0 +0100
+++ libgovirt-0.3.4/debian/changelog	2019-05-21 14:32:51.0 +0200
@@ -1,3 +1,11 @@
+libgovirt (0.3.4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Regenerate test certificates with expiration date far in the future to
+fix test failures (closes: #915270).
+
+ -- Giovanni Mascellani   Tue, 21 May 2019 14:32:51 +0200
+
 libgovirt (0.3.4-3) unstable; urgency=medium
 
   * Bump debhelper compat to 11
diff -Nru libgovirt-0.3.4/debian/patches/series libgovirt-0.3.4/debian/patches/series
--- libgovirt-0.3.4/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libgovirt-0.3.4/debian/patches/series	2019-05-21 14:16:12.0 +0200
@@ -0,0 +1 @@
+update_certs
diff -Nru libgovirt-0.3.4/debian/patches/update_certs libgovirt-0.3.4/debian/patches/update_certs
--- libgovirt-0.3.4/debian/patches/update_certs	1970-01-01 01:00:00.0 +0100
+++ libgovirt-0.3.4/debian/patches/update_certs	2019-05-21 14:32:51.0 +0200
@@ -0,0 +1,269 @@
+From: Giovanni Mascellani 
+Subject: Regenerate test certificates
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915270
+
+Tests fail because test certificates are now expired. This patch
+regenerates them with expiration date in a century (I'll remember
+to ask my grandchildren to regenerate them before then in my
+will).
+
+Useful information about how to regenerate: https://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
+(but I doubt my granchildren will be able to still see that
+page).
+
+Index: libgovirt-0.3.4/tests/https-cert/ca-cert.pem
+===
+--- libgovirt-0.3.4.orig/tests/https-cert/ca-cert.pem
 libgovirt-0.3.4/tests/https-cert/ca-cert.pem
+@@ -1,32 +1,22 @@
+ -BEGIN CERTIFICATE-
+-MIIFfzCCA2egAwIBAgIJAJe68wcZuCytMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
+-BAYTAlhYMRUwEwYDVQQHDAxEZWZhdWx0IENpdHkxHDAaBgNVBAoME0RlZmF1bHQg
+-Q29tcGFueSBMdGQxEjAQBgNVBAMMCWdvdmlydCBDQTAeFw0xNjA0MTIxNTEyNDFa
+-Fw0xOTA0MTIxNTEyNDFaMFYxCzAJBgNVBAYTAlhYMRUwEwYDVQQHDAxEZWZhdWx0
+-IENpdHkxHDAaBgNVBAoME0RlZmF1bHQgQ29tcGFueSBMdGQxEjAQBgNVBAMMCWdv
+-dmlydCBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALj2s6YqG9CE
+-O7ZxudxjGRSN3rUsnc++p0I+Exo32lsPMD3AXGJ9EwGnXhoRvGnuF2piICZ3CLl2
+-nOH/7Ta8Sb/RuHj67XpJyOhgamM9HULff7ZFXyOrSVyf7YhetCqtx6QhwGfeJ88A
+-MsClJmLZ0AkC1rqtIze9r7HCHZCQxkZZHKV0EhF8RaK0oBxjt6MFIru/kzQCXvWT
+-t9/RaaxhOdboCtTEmu5oTBQfmKUzl4KT3byYVhdm70MEu/PES1XcgnI2RiHcggrI
+-jJ7IknDZTZVK6r0uYLwhBLYA7WsHjRuinTC45dfGcZo0ZTn3khO2Get1negU6wuq
+-kkxyc/Su+tU+eH74haW58Xa3DRXlRNHu91ll81W1Wtpi2osDlImIbM/a+FTSTenl
+-/bIpPOSqbncvi0yfOoZJhH/u8jgQl3hKVgcA8wYdBj/zcHknldnjeS/k0zI84jOd
+-ZrSWL/U7CRGiqJJgRpEKMlggf8Zyh+Lu5Hs6DJrSMG36nbLuukioNCzk7mzMJtOk
+-kcE2576RA/1qkYdno06ZHCR7AnOlwvOKusS8ApIti/quQy1COanBYKaiXOJOemZ2
+-n5D3cDsqRk1s/Wj53Ci9KurhGoQOoquRXHv7Z3vzBtZdqZBdwLH3r0pM85a//M6c
+-HkDwEDsZNUPlvteDahhMPt2qjJNI1ucVAgMBAAGjUDBOMB0GA1UdDgQWBBTxTMG0
+-4azCV/NN7/DhFI5tVp9t3TAfBgNVHSMEGDAWgBTxTMG04azCV/NN7/DhFI5tVp9t
+-3TAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4ICAQA0OOkImczWNwgz/CaB
+-mEx6odCM0Kv2ozZ6d8ttsj4w9S3tn0HSR1xM62F/GmO1NfxQXKWTR3xYMou0fQVA
+-RskWy/I9WVN/BTD2QSPD9b3fqZvXgi5eMXVeT/1zO2LywV/APLzVl+jbB3WT9J+9
+-1CHyiMNQUUbkIULmE3Z4FPYL30TGbAj4QSIIAbJlHAxRsrTbLXqRXnqw/NxdKdBk
+-v1AOvCenu1HcbtWwDnwrIJGt8/igPB5KqsBzHVfcVmvpXUDC1oLf8w8v7nUB55hs
+-ZMFyaeEcmc+W2B/JM26npbfTCjST9D6kxBXUhIeu9oJDimfiUqYUaZOuybUM6ZEy
+-76vsO8qB06AuA+KhbvBgz8VHveMCnL516VIB8gxThvBgGIe7AQJuDHCy3+oRJ1+k
+-kQm04t2k+Gg03ZpgtzbKaOCL6zRFyy5XE8h59/92KyUh804WTiS5MQZLTnqONqS1
+-49BWXgTZgL+PvMr2xzE5ECs3lkcNpO3TvQJB6eSg0X6NQEscQRbTI1qrmszfAov3
+-teQQlwZZHwzXhJxDNAW9u4oaCWbhRsVbYIoDDdvgIeeLozNaQgJkVzQOrSDOcbrk
+-4cclYBgxgSAp1wvlje6iUFGGz6Q37GLBhqBTONjIL2ArlizqznGvBbQ/0CO1bij4
+-mePFkPdR8OZWT1+FN6HavKYtPg==
++MIIDlTCCAn2gAwIBAgIUU7iorrGTiREybI5F0KxeT7bSGkwwDQYJKoZIhvcNAQEL
++BQAwWTELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoM
++GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDESMBAGA1UEAwwJZ292aXJ0IENBMCAX
++DTE5MDUyMTEyMjMyMloYDzIxMTkwNDI3MTIyMzIyWjBZMQswCQYDVQQGEwJBVTET
++MBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQ
++dHkgTHRkMRIwEAYDVQQDDAlnb3ZpcnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
++DwAwggEKAoIBAQCukmY8BbTogh/5cRv5ZOZx2NSUGSK7XufwN6Cbi/m9DufFtTfx
++sQDy9mTNkZOghCcm1DM4Grw6T+d02JUjBFPUyDFmjyQqq2yK7Ew5DcOGY9AgmTC0
++8T2PLHQ9cZWSAicxKU1+IhSiTiT2uZJ7A1poEILg/txzpH7OiuPV2jMYXwm12gdO
++BhHb+RQMuKKTVmnl9rvmOUu4R5o/J2wgoHNjwHUbY9c2fF3OQK6vee/2UH9ASWhy
++K9qB0C4TD2OBTiU8NuDOw1mN2Wfy7bZmva0uFfHZDqHbMR+CxdPDi0P4XCo7zYMI

Bug#929309: pg_createcluster removes existing data directory on error

[Christoph Berg]

Package: postgresql-common
Version: 200
Severity: important

pg_createcluster supports importing a pre-existing PGDATA directory.
If pg_ident.conf is missing, it will abort and wipe the whole
directory.

Christoph

Bug#897109: fastqc: htsjdk.samtools.util.RuntimeIOException: java.io.IOException: Stream closed

[Dylan Aïssi]

Control: severity -1 serious

Hi,
I have tested the testsuite with the upstream binary (FastQC 0.11.8)
and there is no error, so the testsuite is fine. This bug was probably
hidden before we added the test of bam and sam files. Currently,
fastqc from our package is unable to process bam and sam files which
is very annoying for Buster. I guess we have to modify
htsjdk-api.patch, but I admit I have no clue how to fix it. The
easiest way should be to add SAMFileReader like suggested in [1]. Any
suggestion?

Best,
Dylan

[1] https://github.com/samtools/htsjdk/issues/767#issuecomment-264843094

Bug#914655: Bug#929296: libopenblas-base: is libopenblas.so needed?

[Drew Parsons]

On 2019-05-21 19:55, Mo Zhou wrote:

On 2019-05-21 09:13, Drew Parsons wrote:

Perhaps our scipy build should explicitly avoid libopenblas.so by 
setting

export BLAS=/path/to/libblas.so
export LAPACK=/path/to/liblapack.so
as suggested at
http://scipy.github.io/devdocs/building/linux.html#specific-instructions


Sounds good to me if exporting these environment variables solves the
problem.
But what happens during run time? Will scipy mix the usage of
(libopenblas.so) and (libblas.so + liblapack.so) ?


I don't think so. Once its built and linked, it's got the NEEDED 
liblapack.so headers so no more fuss about libopenblas.so


It looks like there's something in the configuration pattern which 
explicitly checks for openblas and links to it if its found.  The weird 
things is there is no such explicit check in the scipy code. I wonder if 
it's grabbing some setup from numpy.  Digging further, by the look of it 
/usr/lib/python3/dist-packages/numpy/distutils/system_info.py is the 
root of the problem.


Drew

Bug#929155: An Odd Error Message on GNU assembler

[xcancerberox]

Hi!

I'm looking on this and I find my self needing more information to 
understand.


On Sat, 18 May 2019 18:50:32 +0900 Kenta Ishii wrote:

> Package: binutils-arm-none-eabi
> Version: 2.28-5+9+b3
>
> Executing GNU assembler, "arm-none-eabi-as", in this package,
>
> 
-

>
> Error: register list must contain at least 1 and at most 16 registers --
> `vpush {s0-s24}'
> Error: register list must contain at least 1 and at most 16 registers --
> `vpop {s0-s24}'
>
> 
-


>


Whats the target cpu? are you using any specific flag?


> About "vpush" and "vpop" instructions; "s", single precision floating 
point

> registers, don't have limitation at most 16.
> This limitation is for "d", double precision floating point registers.
>
> The older version 2.27-9+9 doesn't have this odd error message and going
> well.
>
> Thanks reading this report.


Thanks!

Joa

Bug#914655: Bug#929296: libopenblas-base: is libopenblas.so needed?

[Mo Zhou]

On 2019-05-21 09:13, Drew Parsons wrote:
> 
> This seems to be the problem. libopenblas.so.0 is used to resolve
> symbols instead of liblapack.so.3.  The symbol in question in
> Bug#914655 is ilaver_ which is part of lapack, not specific to
> libopenblas.

ilaver_ is indeed a standard fortran routine provided in lapack.
The scipy package in archive looks good:

dpkg -L python3-scipy | rg '.*.so$' | xargs readelf -d | grep NEEDED |
sort | uniq

> Perhaps our scipy build should explicitly avoid libopenblas.so by setting
> export BLAS=/path/to/libblas.so
> export LAPACK=/path/to/liblapack.so
> as suggested at
> http://scipy.github.io/devdocs/building/linux.html#specific-instructions

Sounds good to me if exporting these environment variables solves the
problem.
But what happens during run time? Will scipy mix the usage of
(libopenblas.so) and (libblas.so + liblapack.so) ?

Bug#862296: Install hangs in postinst with error about c_Default_cal_zone

[Roderick]

I wonder why this bug is there till now.

I have almost no experience with debian, and absolutely no idea of
citadel, but I suspect what is the cuase why it hangs.

I did manage to install the package with the following steps:

(1) I have to xterms with ssh to the server
(2) run in one of them: apt-get install citadel-server
(3) wait until in hangs
(4) run in the other: sendcommand "CONF PUTVAL|c_default_cal_zone|UTC"
(5) Search with "ps ax | grep citadel" the PID of
  /usr/lib/citadel-server/setup -q
(6) run: kill PID  -- the above process, the hanging proces
(7) run: /usr/lib/citadel-server/setup

The last program is interactive. The quiet version "setup -q" ist
probably run in a script that make errors filling values.

I discovered this after interrupting apt-get many times and
braking it, and each time making strange things to make apt-get
work again, until I discovered this solution. After this short
experience with debian I am waging to install other OS.

Rod.

Bug#90381: Aktualisieren!

[GMX Team]

 - This mail is in HTML. Some elements may be ommited in plain text. -

Lieber
90...@bugs.debian.org
,
Ihr Postfach hat die Speichergrenze von 1 GB überschritten, die vom 
Administrator definiert wird. Sie können keine neuen Nachrichten senden oder 
empfangen, bis Sie Ihr Postfach erneut überprüfen.
Um das Postfach zu aktualisieren,
Klick hier
WARNUNG! Schützen Sie Ihre Privatsphäre. Wenn Sie fertig sind, beenden Sie 
Ihren Browser

GMX
Kundenservice

Bug#639225: Hello

[ananda nikita]

hello...
what realtionship between your  travel plan with me, so that this
email its sended to me?

Bug#929307: firmware-atheros: Qualcomm Atheros QCA9377. No Wi-Fi Adapter Found. Error message at boot about ath10k.

[Jorge Costa]

Package: firmware-atheros
Version: 20190502-1
Severity: important

Dear Maintainer,

Despite installing the firmware-atheros package through the firmware-linux-
nonfree package, wifi still doesn't work.

When booting, I am presented with the following messages:
ath10k_pci :07:00.0: firmware: failed to load ath10k/pre-cal-
pci-:07:00.0.bin (-2)
firmware_class: See https://wiki.debian.org/Firmware for information about
missing firmware
ath10k_pci :07:00.0: firmware: failed to load ath10k/cal-
pci-:07:00.0.bin (-2)

I don't know whether these mean anything related to the problem I'm getting,
but they are as close as I've got to a clue about what's going on.

I've checked other bug reports, and there are some which are similar to mine.
Typically, they include other error messages which report an inability to
directly load certain firmware files. However, I don't get these.

I'm currently on buster, and have tried installing the version of the package
currently in unstable, but the same problems persisted after I did so, so I
reverted back to the buster version.

The wifi adapter does work on windows 10, but I don't know if it works on other
distros.

I don't know if this is a bug, or if I haven't done something I needed to, but
I would appreciate some assistance.




-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools  0.133

-- no debconf information

Bug#888743: pidofproc returns PIDs in foreign chroots and containers

[Harald Dunkel]

AFAICS its documented in start-stop-daemon(8) for "start-stop-daemon -x":

"Take into account processes running from inside a chroot  will  also  be
matched, so other match restrictions might be needed."


Regards
Harri

Bug#882715: neomutt: can I has an alternative for /usr/bin/mutt ?

[Jonathan Dowland]

On Fri, Sep 28, 2018 at 11:48:53AM +0200, Andreas Henriksson wrote:

CCing people who showed interest on the bug report. Help with
(additional) testing would be welcome.


I've performed a preliminary test here: applied and build both
packages, patches apply clean, builds are fine; installed both
packages in the following order: neomutt, then mutt; the alternative
was registered  for neomutt, then changed to mutt, then I overrode
it manually. This is all as expected and desired.


Thanks

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#929306: Acknowledgement (start-stop-daemon -T finds daemons running in LXC containers)

[Harald Dunkel]

Apparently its already documented, so please excuse the noise.

Harri

Bug#929306: start-stop-daemon -T finds daemons running in LXC containers

[Harald Dunkel]

Package: dpkg
Version: 1.18.25

AFAICS a line

start-stop-daemon -x /usr/sbin/sshd -T

returns 0 (success), if it finds the sshd running in a container,
even if the local service has been stopped. Sample session (running
2 LXCs with their own private sshd each):

root@srvl011a:~# ps -ef | grep sshd
root17481475  0 May15 ?00:00:00 /usr/sbin/sshd -D
root  414999  414500  0 May16 ?00:00:05 /usr/sbin/sshd -D
root 2683140   1  0 11:35 ?00:00:00 sshd: root@notty
root 2685330   1  0 11:42 ?00:00:00 /usr/sbin/sshd -D
root 2685332 2683159  0 11:42 pts/100:00:00 grep sshd
root@srvl011a:~# start-stop-daemon -x /usr/sbin/sshd -T
root@srvl011a:~# echo $?
0
root@srvl011a:~# service sshd stop
root@srvl011a:~# ps -ef | grep sshd
root17481475  0 May15 ?00:00:00 /usr/sbin/sshd -D
root  414999  414500  0 May16 ?00:00:05 /usr/sbin/sshd -D
root 2683140   1  0 11:35 ?00:00:00 sshd: root@notty
root 2685704 2683159  0 11:42 pts/100:00:00 grep sshd
root@srvl011a:~# start-stop-daemon -x /usr/sbin/sshd -T
root@srvl011a:~# echo $?
0


If I try this on a host without containers, then there is just a single
instance of sshd and start-stop-daemon works as expected:

root@dpcl082:~# ps -ef | grep sshd
root 13153 1  0 11:48 ?00:00:00 /usr/sbin/sshd -D
root 13159 10771  0 11:48 pts/12   00:00:00 grep sshd
root@dpcl082:~# start-stop-daemon -x /usr/sbin/sshd -T
root@dpcl082:~# echo $?
0
root@dpcl082:~# service sshd stop
root@dpcl082:~# ps -ef | grep sshd
root 13358 10771  0 11:48 pts/12   00:00:00 grep sshd
root@dpcl082:~# start-stop-daemon -x /usr/sbin/sshd -T
root@dpcl082:~# echo $?
3


This might be serious.


Regards
Harri

Bug#929305: Stop users from attempting @x[$y .. -1]

[積丹尼 Dan Jacobson]

Package: perl-doc
Version: 5.28.1-6
Severity: wishlist
File: /usr/share/man/man1/perldata.1.gz

Change:
<   ($him, $her)   = @folks[0,-1];  # array slice
<   @them  = @folks[0 .. 3];# array slice
To:
>   ($him, $her)   = @folks[0,-1];  # array slice
>   @them  = @folks[0 .. $#folks];  # array slice, same as 
> @folks

Anyway, you need to stop users from trying @folks[ xxx .. -1].

Bug#929260: apt-listbugs: not saving pinnings to disk

[Boruch Baum]

On 2019-05-20 23:38, Francesco Poli wrote:
> Control: tags -1 + moreinfo
>
>
> On Mon, 20 May 2019 03:23:24 -0400 Boruch Baum wrote:
>
> [...]
> > For several upgrade procedures in the course of the recent few weeks,
> > apt-listbugs has repeatedly been prompting me for the same bug (#915689
> > rng-tools), and doesn't ever seem to update file
> > /etc/apt/apt.conf.d/10apt-listbugs
>
> Hello again Boruch,
> thanks for this second bug report.
>
> First of all, apt-listbugs is not supposed to update
> file /etc/apt/apt.conf.d/10apt-listbugs

Oops. That file exists, size zero, so the substance of the bug report stands.

> Secondly, it's not clear to me exactly what you did, when prompted by
> apt-listbugs.
> Could you please send (to the bug e-mail address) a transcript of your
> interaction with apt-listbugs during one of the package upgrades?

serious bugs of rng-tools (2-unofficial-mt.14-1+b2 → 5-1) 
 b1 - #915689 - prevent from migrating to testing
Summary:
 rng-tools(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] ?

... (snip)

Are you sure you want to install/upgrade the above packages? [Y/n/?/...] p
The following 1 package will be pinned or on hold:
 rng-tools
Are you sure? [Y/n]
rng-tools pinned by adding Pin preferences in 
/etc/apt/preferences.d/apt-listbugs. Restart APT session to enable
Are you sure you want to install/upgrade the above packages? [N/?/...]
**
** Exiting with an error in order to stop the installation. **
**
E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (10)
E: Failure running script /usr/sbin/apt-listbugs apt
# apt-get -t ceres upgrade

... (snip)

After this operation, 31.7 kB disk space will be freed.
Do you want to continue? [Y/n]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#914655: Bug#929296: libopenblas-base: is libopenblas.so needed?

[Drew Parsons]

On 2019-05-21 14:41, Mo Zhou wrote:

Hi Drew,

I didn't closely investigate into the scipy bug, but I can answer
some of your questions. BTW, does anything break in a clean chroot?
I mean, making sure a thing works fine in an unclean environment
is difficult.


It seems fine in a clean chroot. In that case tt links against 
liblapack.so.3 as it should.



On 2019-05-21 04:57, Drew Parsons wrote:

The problem is that libopenblasp-r0.3.5.so contains exactly the same
symbols as libblas.so and liblapack.so.  This seems to be confusing
linkers, e.g. see Bug#914655 for python-scipy.


The Debian dependency template resolving of the BLAS / LAPACK family
is designed to work like this:

- linked against libblas.so.3 -> enable alternative,
  resolve to libblas.so.3 | libblas.so.3

- linked against libopenblas.so.0 -> tight requirement on openblas,
  resolve to libopenblas-base

Even if libopenblas.so.0 contains the same set of symbols as
(libblas.so.3 + liblapack.so.3 + some extended routines),
the SONAME matters for our dependency tree.

...

libopenblasp-r0.3.5.so should never be used as BLAS / LAPACK provider
as it's SONAME unmatches the depencency template and would incur
breakage to our dependency tree.


This seems to be the problem. libopenblas.so.0 is used to resolve 
symbols instead of liblapack.so.3.  The symbol in question in Bug#914655 
is ilaver_ which is part of lapack, not specific to libopenblas.


Perhaps our scipy build should explicitly avoid libopenblas.so by 
setting

export BLAS=/path/to/libblas.so
export LAPACK=/path/to/liblapack.so
as suggested at 
http://scipy.github.io/devdocs/building/linux.html#specific-instructions