Bug#918988: [debian-mysql] Bug#918988: Maybe I can help with this issue

[debian-mailinglist]

Hey Otto,

ok thats an interesting question.

Querying the installed packages tells me the following:

root@system: #  apt list --installed
[...]
php-auth-sasl/stable,stable,now 1.0.6-3 all [installed,automatic]
php-cli/stable,stable,now 1:7.0+49 all [installed,automatic]
php-common/stable,stable,now 1:49 all [installed,automatic]
php-mail/stable,stable,now 1.3.0-1 all [installed]
php-mail-mime/stable,stable,now 1.10.0-2 all [installed]
php-mbstring/stable,stable,now 1:7.0+49 all [installed]
php-mysql/stable,stable,now 1:7.0+49 all [installed]
php-net-dime/stable,stable,now 1.0.2-3 all [installed]
php-net-smtp/stable,stable,now 1.7.1-2 all [installed]
php-net-socket/stable,stable,now 1.0.14-2 all [installed]
php-net-url/stable,stable,now 1.0.15-4 all [installed]
php-net-url2/stable,stable,now 2.2.1-0.1 all [installed]
php-pclzip/stable,stable,now 2.8.2-4 all [installed]
php-pear/stable,stable,stable,now 1:1.10.1+submodules+notgz-9+deb9u1
all [installed] php-soap/stable,stable,now 1:7.0+49 all [installed]
php-xml/stable,stable,now 1:7.0+49 all [installed]
php5/now 5.6.39+dfsg-0+deb8u1 all [installed,local]
php5-apcu/now 4.0.7-1 amd64 [installed,local]
php5-cgi/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-cli/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-common/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-curl/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-dev/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-fpm/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-gd/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-imap/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-json/now 1.3.6-1 amd64 [installed,local]
php5-ldap/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-mcrypt/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-mysql/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-pgsql/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-readline/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php5-sqlite/now 5.6.39+dfsg-0+deb8u1 amd64 [installed,local]
php7.0/stable,stable,stable,now 7.0.33-0+deb9u3 all [installed]
php7.0-cli/stable,stable,stable,now 7.0.33-0+deb9u3 amd64
[installed,automatic] php7.0-common/stable,stable,stable,now
7.0.33-0+deb9u3 amd64 [installed,automatic]
php7.0-curl/stable,stable,stable,now 7.0.33-0+deb9u3 amd64 [installed]
php7.0-gd/stable,stable,stable,now 7.0.33-0+deb9u3 amd64 [installed]
php7.0-json/stable,stable,stable,now 7.0.33-0+deb9u3 amd64
[installed,automatic] php7.0-mbstring/stable,stable,stable,now
7.0.33-0+deb9u3 amd64 [installed] php7.0-mysql/stable,stable,stable,now
7.0.33-0+deb9u3 amd64 [installed]
php7.0-opcache/stable,stable,stable,now 7.0.33-0+deb9u3 amd64
[installed,automatic] php7.0-readline/stable,stable,stable,now
7.0.33-0+deb9u3 amd64 [installed,automatic]
php7.0-soap/stable,stable,stable,now 7.0.33-0+deb9u3 amd64 [installed]
php7.0-xml/stable,stable,stable,now 7.0.33-0+deb9u3 amd64 [installed]
php7.0-zip/stable,stable,stable,now 7.0.33-0+deb9u3 amd64 [installed]
[...]

It seems like these php5-* packages are from the old Debian 8
installation as this system was migrated from 8 to 9.

I will try to switch to php7.0 for my web applications and after that
I'll try to remove all php5 packages.

I will get back to you.

Regards
codiflow

Otto Kekäläinen  schrieb am Wed, 15 May 2019 08:35:04
+0300:

> Hello!
> 
> > Downgrading the package is not working anymore - it was a dirty
> > workaround for about two months:
> > apt-get install libmariadbclient18=10.1.26-0+deb9u1
> > apt-mark hold libmariadbclient18  
> 
> Maybe because the problem is not in that package, but some other
> binary in the chain of what Apache/Nginx/PHP uses or has been built
> with?
> 
> > Removing of libmysqlclient18 would also remove php5-mysql* which is
> > not what I want.  
> 
> Do you have some custom PHP installation?
> 
> I don't see any such package in Stretch:
> 
> root@d6b6aa0e9494:/build# cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> 
> root@d6b6aa0e9494:/build# apt-get install php5-mysql
> Package php5-mysql is not available, but is referred to by another
> package. This may mean that the package is missing, has been
> obsoleted, or is only available from another source
> E: Package 'php5-mysql' has no installation candidate
> 
> 
> 
> Please provide me with some steps on how to reproduce the bug.
> The steps can for example start with:
>   docker run -it debian:stretch bash
>   apt-get update
>   apt-get instal 

Bug#927851: testing-updates...

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> andrew@a68n:~$ ssh root@detst
> Linux detst 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64
> 
> The programs included with the Debian GNU/Linux system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
> 
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> Last login: Thu May  9 15:44:26 2019 from 192.168.0.58
> root@detst:~# aptitude update && aptitude upgrade
> Get: 1 http://security.debian.org/debian-security buster/updates InRelease
> [39.1 kB] Hit http://packages.x2go.org/debian buster
> InRelease Get: 2 http://ftp2.de.debian.org/debian buster InRelease [163 kB]
> Get: 3 http://ftp2.de.debian.org/debian buster/main amd64
> Packages.diff/Index [27.9 kB] Get: 4 http://ftp2.de.debian.org/debian
> buster/main Translation-en.diff/Index [27.9 kB] Get: 5
> http://ftp2.de.debian.org/debian buster/non-free amd64 Packages.diff/Index
> [27.8 kB] Get: 6 http://ftp2.de.debian.org/debian buster/contrib amd64
> Packages.diff/Index [27.8 kB] Get: 7 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-09-1407.29.pdiff [58 B] Get: 8
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-10-0209.45.pdiff [1,741 B] Get: 9 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-10-2009.52.pdiff [8,587 B] Get: 10
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-11-0209.49.pdiff [7,815 B] Get: 11 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-11-1411.27.pdiff [220 B] Get: 12
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-11-2011.01.pdiff [1,409 B] Get: 13 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-12-0210.41.pdiff [5,366 B] Get: 14
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-12-1411.29.pdiff [1,734 B] Get: 15 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-12-2011.15.pdiff [1,236 B] Get: 16
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-13-0210.50.pdiff [2,685 B] Get: 17 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-13-1411.18.pdiff [387 B] Get: 18
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-14-0211.12.pdiff [1,517 B] Get: 19 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-15-0308.52.pdiff [1,368 B] Get: 20
> http://ftp2.de.debian.org/debian buster/main Translation-en
> 2019-05-09-1407.29.pdiff [57 B] Get: 21 http://ftp2.de.debian.org/debian
> buster/main Translation-en 2019-05-11-0209.49.pdiff [191 B] Get: 22
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-15-0308.52.pdiff [1,368 B] Get: 23 http://ftp2.de.debian.org/debian
> buster/main Translation-en 2019-05-12-0210.41.pdiff [399 B] Get: 24
> http://ftp2.de.debian.org/debian buster/non-free amd64 Packages
> 2019-05-12-0210.41.pdiff [295 B] Get: 25 http://ftp2.de.debian.org/debian
> buster/main Translation-en 2019-05-12-0210.41.pdiff [399 B] Get: 26
> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages
> 2019-05-11-2011.01.pdiff [515 B] Get: 27 http://ftp2.de.debian.org/debian
> buster/non-free amd64 Packages 2019-05-12-0210.41.pdiff [295 B] Get: 28
> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages
> 2019-05-11-2011.01.pdiff [515 B] Fetched 349 kB in 8s (44.6 kB/s) Current
> status: 13 (+13) upgradable, 1414 (+2) new. The following packages will be
> upgraded: firefox-esr gir1.2-javascriptcoregtk-4.0 gir1.2-webkit2-4.0
> grub-common grub-pc grub-pc-bin grub2-common libjavascriptcoregtk-4.0-18
> libpq5 libwebkit2gtk-4.0-37 manpages xserver-xorg-video-ati
> xserver-xorg-video-radeon 13 packages upgraded, 0 newly installed, 0 to
> remove and 0 not upgraded. Need to get 64.9 MB of archives. After unpacking
> 3,072 B will be used. Do you want to continue? [Y/n/?] Get: 1
> http://ftp2.de.debian.org/debian buster/main amd64 manpages all 4.16-2
> [1,295 kB] Get: 2 http://ftp2.de.debian.org/debian buster/main amd64
> firefox-esr amd64 60.6.3esr-1 [41.7 MB] Get: 3
> http://ftp2.de.debian.org/debian buster/main amd64 libwebkit2gtk-4.0-37
> amd64 2.24.1-2 [11.7 MB] Get: 4 http://ftp2.de.debian.org/debian
> buster/main amd64 libjavascriptcoregtk-4.0-18 amd64 2.24.1-2 [4,870 kB]
> Get: 5 http://ftp2.de.debian.org/debian buster/main amd64
> gir1.2-webkit2-4.0 amd64 2.24.1-2 [127 kB] Get: 6
> http://ftp2.de.debian.org/debian buster/main amd64
> gir1.2-javascriptcoregtk-4.0 amd64 2.24.1-2 [80.6 kB] Get: 7
> http://ftp2.de.debian.org/debian buster/main amd64 grub-pc amd64
> 2.02+dfsg1-18 [131 kB] Get: 8 http://ftp2.de.debian.org/debian buster/main
> amd64 grub2-common amd64 2.02+dfsg1-18 [537 kB] Get: 9
> http://ftp2.de.debian.org/debian buster/main amd64 grub-pc-bin amd64
> 2.02+dfsg1-18 [901 kB] Get: 10 http://ftp2.de.debian.org/debian buster/main
> amd64 

Bug#918988: [debian-mysql] Bug#918988: Maybe I can help with this issue

[Otto Kekäläinen]

Hello!

> Downgrading the package is not working anymore - it was a dirty
> workaround for about two months:
> apt-get install libmariadbclient18=10.1.26-0+deb9u1
> apt-mark hold libmariadbclient18

Maybe because the problem is not in that package, but some other
binary in the chain of what Apache/Nginx/PHP uses or has been built
with?

> Removing of libmysqlclient18 would also remove php5-mysql* which is not
> what I want.

Do you have some custom PHP installation?

I don't see any such package in Stretch:

root@d6b6aa0e9494:/build# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

root@d6b6aa0e9494:/build# apt-get install php5-mysql
Package php5-mysql is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'php5-mysql' has no installation candidate



Please provide me with some steps on how to reproduce the bug.
The steps can for example start with:
  docker run -it debian:stretch bash
  apt-get update
  apt-get instal 

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

[Otto Kekäläinen]

ti 23. huhtik. 2019 klo 10.21 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> It was reported in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920619#20:
> > Updating libaprutil1-dbd-mysql to 1.6.1-4 (from unstable as of now)
> > fixed the problem
>
> Does this fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918988
> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916375 as well?

If I don't get any more info on these bugs or precise steps on how to
reproduce, I will just close this bug report. No point in keeping it
hanging if nobody of the affected users supply more input.

Bug#929006: intel-microcode: Atom fails to boot when loading microcode

[Richard Hector]

Package: intel-microcode
Version: 3.20180807a.2~deb9u1
Severity: normal

Dear Maintainer,

I don't know whether this is a problem with the intel-microcode package,
the kernel, or the microcode itself.

I installed intel-microcode and rebooted.

The machine failed to boot - when using recovery mode, it stopped after
"Freeing SMP alternatives memory: 24K"

If I booted with "dis_ucode_ldr" on the kernel command line, it
booted successfully.

System is an HP T5740 Thin Client.

/proc/cpuinfo:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 28
model name  : Intel(R) Atom(TM) CPU N280   @ 1.66GHz
stepping: 2
microcode   : 0x20a
cpu MHz : 1000.000
cache size  : 512 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3
xtpr pdcm movbe lahf_lm dtherm
bugs:
bogomips: 3325.21
clflush size: 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 28
model name  : Intel(R) Atom(TM) CPU N280   @ 1.66GHz
stepping: 2
microcode   : 0x20a
cpu MHz : 1000.000
cache size  : 512 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 1
apicid  : 1
initial apicid  : 1
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3
xtpr pdcm movbe lahf_lm dtherm
bugs:
bogomips: 3325.21
clflush size: 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:


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

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

Versions of packages intel-microcode depends on:
ii  iucode-tool  2.1.1-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.130

intel-microcode suggests no packages.

-- no debconf information

Thanks,
Richard



signature.asc
Description: OpenPGP digital signature

Bug#929004: yank FTCBFS: multiple reasons

[Helmut Grohne]

Source: yank
Version: 1.1.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

yank fails to cross build from source. During dh_auto_build, it
correctly cross builds the "yank" executable. Then during make install,
PROG is changed to yank-cli, so it needs to be rebuilt, but no cross
tools are passed. Passing PROG to the build step as well fixes this
part. Then it passes -s to install, which uses the wrong strip. This
also breaks DEB_BUILD_OPTIONS=nostrip and generation of a -dbgsym
package. Dropping the -s flag and deferring all stripping to dh_strip is
the usual solution here. Please consider applying the attached patch.

Helmut
diff --minimal -Nru yank-1.1.0/debian/changelog yank-1.1.0/debian/changelog
--- yank-1.1.0/debian/changelog 2018-11-07 16:29:11.0 +0100
+++ yank-1.1.0/debian/changelog 2019-05-15 06:16:19.0 +0200
@@ -1,3 +1,12 @@
+yank (1.1.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Also pass PROG= to dh_auto_build.
++ Pass INSTALL_PROGRAM without -s.
+
+ -- Helmut Grohne   Wed, 15 May 2019 06:16:19 +0200
+
 yank (1.1.0-1) unstable; urgency=medium
 
   * New upstream version 1.1.0
diff --minimal -Nru yank-1.1.0/debian/rules yank-1.1.0/debian/rules
--- yank-1.1.0/debian/rules 2018-11-07 16:29:11.0 +0100
+++ yank-1.1.0/debian/rules 2019-05-15 06:16:19.0 +0200
@@ -7,5 +7,8 @@
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- PROG=yank-cli
+
 override_dh_auto_install:
-   $(MAKE) PREFIX=$(CURDIR)/debian/yank/usr PROG=yank-cli install
+   $(MAKE) PREFIX=$(CURDIR)/debian/yank/usr PROG=yank-cli 
INSTALL_PROGRAM="install -m 0755" install

Bug#929005: superkb FTCBFS: upstream build system hard codes build architecture tools

[Helmut Grohne]

Source: superkb
Version: 0.23-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

superkb fails to cross build from source, because the upstream build
system hard codes build architecture build tools (gcc and pkg-config).
The attached patch makes these tools substitutable, but it doesn't make
superkb cross buildable due to its use of help2man. This is harder to
solve and not fixed here. Please consider applying the attached patch
anyway and close this bug when doing so even though superkb will
continue to fail cross building.

Helmut
--- superkb-0.23.orig/Makefile
+++ superkb-0.23/Makefile
@@ -1,3 +1,4 @@
+PKG_CONFIG ?= pkg-config
 
 #Build configuration file.
 CONFIGURATION=configuration
@@ -7,50 +8,50 @@
 #puticon/puticon-gdkpixbuf
 obj-$(PUTICON_GDKPIXBUF) += puticon/puticon-gdkpixbuf.o
 syms-$(PUTICON_GDKPIXBUF) += -DWITH_GDKPIXBUF
-ldlibs-$(PUTICON_GDKPIXBUF) += $(shell pkg-config gdk-pixbuf-xlib-2.0 --libs)
-cflags-$(PUTICON_GDKPIXBUF) += $(shell pkg-config gdk-pixbuf-xlib-2.0 --cflags)
+ldlibs-$(PUTICON_GDKPIXBUF) += $(shell $(PKG_CONFIG) gdk-pixbuf-xlib-2.0 --libs)
+cflags-$(PUTICON_GDKPIXBUF) += $(shell $(PKG_CONFIG) gdk-pixbuf-xlib-2.0 --cflags)
 
 #puticon/puticon-imlib2 (which I prefer)
 obj-$(PUTICON_IMLIB2) += puticon/puticon-imlib2.o
 syms-$(PUTICON_IMLIB2) += -DWITH_IMLIB2
-ldlibs-$(PUTICON_IMLIB2) += $(shell pkg-config imlib2 --libs)
-cflags-$(PUTICON_IMLIB2) += $(shell pkg-config imlib2 --cflags)
+ldlibs-$(PUTICON_IMLIB2) += $(shell $(PKG_CONFIG) imlib2 --libs)
+cflags-$(PUTICON_IMLIB2) += $(shell $(PKG_CONFIG) imlib2 --cflags)
 
 #drawkblibs/drawkblibs-xlib
 obj-$(DRAWKBLIBS_XLIB) += drawkblibs/drawkblibs-xlib.o
 syms-$(DRAWKBLIBS_XLIB) += -DWITH_DRAWKBLIBS_XLIB
-ldlibs-$(DRAWKBLIBS_XLIB) += $(shell pkg-config x11 --libs)
-cflags-$(DRAWKBLIBS_XLIB) += $(shell pkg-config x11 --cflags)
+ldlibs-$(DRAWKBLIBS_XLIB) += $(shell $(PKG_CONFIG) x11 --libs)
+cflags-$(DRAWKBLIBS_XLIB) += $(shell $(PKG_CONFIG) x11 --cflags)
 
 #drawkblibs/drawkblibs-cairo
 obj-$(DRAWKBLIBS_CAIRO) += drawkblibs/drawkblibs-cairo.o
 syms-$(DRAWKBLIBS_CAIRO) += -DWITH_DRAWKBLIBS_CAIRO
-ldlibs-$(DRAWKBLIBS_CAIRO) += $(shell pkg-config x11 renderproto xrender cairo cairo-xlib pangocairo --libs)
-cflags-$(DRAWKBLIBS_CAIRO) += $(shell pkg-config x11 renderproto xrender cairo cairo-xlib pangocairo --cflags) -DPANGO_ENABLE_BACKEND
+ldlibs-$(DRAWKBLIBS_CAIRO) += $(shell $(PKG_CONFIG) x11 renderproto xrender cairo cairo-xlib pangocairo --libs)
+cflags-$(DRAWKBLIBS_CAIRO) += $(shell $(PKG_CONFIG) x11 renderproto xrender cairo cairo-xlib pangocairo --cflags) -DPANGO_ENABLE_BACKEND
 
-cflags-y += $(shell pkg-config xft --cflags)
-ldlibs-y += $(shell pkg-config xft --libs)
+cflags-y += $(shell $(PKG_CONFIG) xft --cflags)
+ldlibs-y += $(shell $(PKG_CONFIG) xft --libs)
 
 #Choose whether Xinerama will be emulated or real.
 ifeq ($(XINERAMA_SUPPORT),n)
 	obj-y += screeninfo-xlib.o
 else
 	obj-y += screeninfo-xinerama.o
-	ldlibs-y += $(shell pkg-config xinerama --libs)
-	cflags-y += $(shell pkg-config xinerama --cflags)
+	ldlibs-y += $(shell $(PKG_CONFIG) xinerama --libs)
+	cflags-y += $(shell $(PKG_CONFIG) xinerama --cflags)
 endif
 
 version_extrainfo = $(shell ./extendedversioninfo.bash)
 
 #Conditional -pedantic-errors because of pango 1.32.3, 1.32.4 and 1.32.5.
 PEDANTIC_ERRORS := -pedantic-errors
-ifeq ($(shell pkg-config --modversion pango),1.32.3)
+ifeq ($(shell $(PKG_CONFIG) --modversion pango),1.32.3)
PEDANTIC_ERRORS :=
 endif
-ifeq ($(shell pkg-config --modversion pango),1.32.4)
+ifeq ($(shell $(PKG_CONFIG) --modversion pango),1.32.4)
PEDANTIC_ERRORS :=
 endif
-ifeq ($(shell pkg-config --modversion pango),1.32.5)
+ifeq ($(shell $(PKG_CONFIG) --modversion pango),1.32.5)
PEDANTIC_ERRORS :=
 endif
 
@@ -111,22 +112,22 @@
 	}
 
 configuration:
-	-pkg-config xinerama --exists > /dev/null \
+	-$(PKG_CONFIG) xinerama --exists > /dev/null \
 		&& (echo "XINERAMA_SUPPORT=y" >> configuration) \
 		|| (echo "XINERAMA_SUPPORT=n" >> configuration)
-	-pkg-config gdk-pixbuf-xlib-2.0 --exists > /dev/null \
+	-$(PKG_CONFIG) gdk-pixbuf-xlib-2.0 --exists > /dev/null \
 		&& (echo "PUTICON_GDKPIXBUF=$(MODTYPE)" >> configuration) \
 		|| (echo "PUTICON_GDKPIXBUF=n" >> configuration)
-	-pkg-config imlib2 --exists > /dev/null \
+	-$(PKG_CONFIG) imlib2 --exists > /dev/null \
 		&& (echo "PUTICON_IMLIB2=$(MODTYPE)" >> configuration) \
 		|| (echo "PUTICON_IMLIB2=n" >> configuration)
 	-echo "DRAWKBLIBS_XLIB=$(MODTYPE)" >> configuration
-	-pkg-config x11 renderproto xrender cairo cairo-xlib pangocairo --exists > /dev/null \
+	-$(PKG_CONFIG) x11 renderproto xrender cairo cairo-xlib pangocairo --exists > /dev/null \
 		&& (echo "DRAWKBLIBS_CAIRO=$(MODTYPE)" >> configuration) \
 		|| (echo "DRAWKBLIBS_CAIRO=n" >> configuration)
 
 checkdep:
-	@./approve-config
+	@PKG_CONFIG=$(PKG_CONFIG) ./approve-config
 
 superkb.o: superkb.h
 superkbrc.o: superkbrc.h globals.h
@@ -140,7 +141,7 @@
 
 
 $(SHARED): %.so: %.o
-	

Bug#864654: synaptic: Duplicate package entries in Origin

[Avinash Sonawane]

Hi!

I can reproduce this bug on latest Debian stable.

Please check the screenshots:
1. https://i.imgur.com/fPCScbm.png
2. https://i.imgur.com/9w0hsyY.png

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 9.9 (stretch)
Release:9.9
Codename:   stretch
$ apt-cache policy yarn
yarn:
  Installed: 1.16.0-1
  Candidate: 1.16.0-1
  Version table:
 *** 1.16.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
100 /var/lib/dpkg/status
 1.15.2-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.13.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.12.3-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.12.1-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.10.1-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.10.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.9.4-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.9.2-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.7.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.6.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.5.1-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.3.2-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.2.1-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.2.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.1.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.0.2-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 1.0.1-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.27.5-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.27.4-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.27.3-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.27.2-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.24.6-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.24.5-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.24.4-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.24.3-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.23.4-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.23.3-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.23.2-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 https://dl.yarnpkg.com/debian stable/main all Packages
 0.22.0-1 500
500 https://dl.yarnpkg.com/debian stable/main amd64 Packages
500 

Bug#928975: (no subject)

[Michael Lustfield]

After looking at the provided samples, I would agree that the similarity
between the two is too close to be a coincidence, especially considering the
timeline described/observed.

Without evidence to the contrary, I agree that this should be removed from
Debian. You should probably also file similar bugs with any other distro
(epel?) that may have a copy of software built from this source, as well as
with the upstream project itself. Depending on the result you get, you may
(hopefully not) find these resources helpful.

- http://gpl-violations.org/
- https://sfconservancy.org/about/
- http://www.softwarefreedom.org/about/contact/

-- 
Michael Lustfield

Bug#929003: release-notes: Provide specific instructions to remove obsolete packages

[Karl O. Pinc]

Package: release-notes
Severity: normal
Tags: patch

The buster release notes should provide more specifics when it comes
to removing obsolete packages.

The following patch makes 2 changes.

It recommends removing packages that are obsolete in stretch before
beginning the upgrade to buster.

It provides commands, instead of vague TUI recommendations, describing
how to remove obsolete packages.

Regards,
Karl

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 30e138ab..90e4d189 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -309,6 +309,11 @@ $ apt-forktracer | sort
 .
   
 
+  
+It is a good idea to remove obsolete
+packages from your system before upgrading.
+  
+
   
 The proposed-updates section
 
@@ -1296,10 +1301,14 @@ $ aptitude purge '~c'
   
   
 Detecting which packages in an updated system are obsolete 
is easy since the
-package management front-ends will mark them as such.  If you are using
-aptitude, you will see a listing of these packages in 
the
-Obsolete and Locally Created Packages entry.
+package management front-ends will mark them as such.
+The  aptitude commands to list and
+purge obsolete commands are:
   
+  
+# aptitude search '~o'
+# aptitude purge '~o'
+  
   
 The Debian Bug Tracking System
 often provides additional information on why the package was removed.  You

Bug#929002: release-notes: Current buster release notes do not validate

[Karl O. Pinc]

Package: release-notes
Severity: normal

Hi,

The buster release notes as of commit 29a765c0991f, Tue May 14 23:53:09 2019 
+0200 do not validate.

'make validate' produces the following errors:

nl/about.dbk:131: parser error : Entity 'url-svn-release-notes' not defined
url="">web-interface gebruiken om via het web
^
nl/about.dbk:134: parser error : Entity 'url-ddp-svn-info' not defined
url="">VCS-informatiepagina's van het Debian
   ^
nl/whats-new.dbk:11: parser error : Entity 'url-wiki-newininrelease' not defined
  De Wiki-pagina bevat meer

ro/moreinfo.dbk:116: parser error : Entity 'url-ddp-svn-info' not defined
url="">documentației sau 

Bug#928942: Bug #928942: udd: cannot import database dump into PostgreSQL ("function release_name(text) does not exist")

[Leandro Doctors]

On Tue, 14 May 2019 at 19:01, Mattia Rizzolo  wrote:
> TTBOMK, the schema Is just handled pseudo-manually, so any change would need 
> to be applied directly.
>
> I'm not even sure if the schema dump in git is current anymore (being 7 
> months old).

Then, probably the best course of action would be to delete it from
the repo and make it so it gets generated automatically along every
dump?


> Also, thank you for the analysis, and the upcoming patch! :)

Don't thank me so much yet: I only came up with an idea. I still have
to make it work :-)

I think that, for now, I will simply try to make the dump
forward-compatible with newer versions of PostgreSQL, and the schema
to be generated automatically along every dump.

(After having quickly read the PostgreSQL 10 release notes, it seems
that the solution involves using 'pg_dumpall' instead of 'pg_dump' - I
will have to explore this...)

I will let you know once I progress on this.

Best,
Leandro

Bug#928942: Bug #928942: udd: cannot import database dump into PostgreSQL ("function release_name(text) does not exist")

[Mattia Rizzolo]

On Tue, 14 May 2019, 11:42 pm Leandro Doctors,  wrote:

> I'll give it a try and open a MR on salsa.d.o to solve this. (I guess
> that changing the schema itself should be trivial. I will only have to
> think a little bit about the migration process of the current DB.)
>

TTBOMK, the schema Is just handled pseudo-manually, so any change would
need to be applied directly.

I'm not even sure if the schema dump in git is current anymore (being 7
months old).

Also, thank you for the analysis, and the upcoming patch! :)

Bug#929000: sloccount: --autogen flag seems not to work

[Reuben Thomas]

Package: sloccount
Version: 2.26-5.2
Severity: normal

If I have files foo.py and foo.py.in, and run sloccount foo.py, I get no
lines counted. The same happens for foo.py.in (perhaps because sloccount
does not recognise “.in” as a language?).

So I try sloccount --autogen foo.py, but that still gives 0 lines.

I confirm that it seems to be the autogen detection that is in play by
removing foo.py.in, and rerunning sloccount foo.py: this now gives me a
non-zero count.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-48-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sloccount depends on:
ii  libc6  2.27-3ubuntu1
ii  perl   5.26.1-6ubuntu0.3

sloccount recommends no packages.

Versions of packages sloccount suggests:
ii  doc-base  0.10.8

-- no debconf information

Bug#928942: Bug #928942: udd: cannot import database dump into PostgreSQL ("function release_name(text) does not exist")

[Leandro Doctors]

On Tue, 14 May 2019 at 06:20, Michael Banck  wrote:
> Am Montag, den 13.05.2019, 15:44 -0300 schrieb Leandro Doctors:

Hi, Michael!

Thanks for your detailed answer.

> > Package: qa.debian.org
> > Severity: grave
> > Justification: causes non-serious data loss>
> not sure whether that is warranted; a materialized view is by definition
> no new data that could be lost.

As I'm no DD, I wasn't sure about the severity level... That being
said, the fact is that this error renders impossible the full restore
of the dump...
If you can think of a more appropriate one, please feel free to change it :-)

[...]
> The problem is that the UDD schema does not schema-qualify functions
> when using them.
[...]
> The actual problem appears to be in the bugs_rt_affect_dist
> function that calls release_name($1) without schema-qualifiying it:
>
> https://salsa.debian.org/qa/udd/blob/master/sql/udd-schema.sql#L553

I'll give it a try and open a MR on salsa.d.o to solve this. (I guess
that changing the schema itself should be trivial. I will only have to
think a little bit about the migration process of the current DB.)

Thanks again, Michael!

Best,
Leandro

Bug#928999: ITP: puppet-module-magnum -- Puppet module for OpenStack Magnum

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-magnum
  Version : 14.4.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/puppet-magnum
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for OpenStack Magnum

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenStack
 Magnum.
 .
 Magnum is an OpenStack project which offers container orchestration engines
 for deploying and managing containers as first class resources in OpenStack.
 It features:
  * Abstractions for bays, containers, nodes, pods, replication controllers,
and services
  * Integration with Kubernetes and Docker for backend container technology
  * Integration with Keystone for multi-tenant security
  * Integration with Neutron for Kubernetes multi-tenancy network security

Bug#928998: mirror submission for debian.blue3.com.br

[Samir Hanna Verza]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.blue3.com.br
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Samir Hanna Verza 
Country: BR Brazil
Location: Porto Alegre / RS
Sponsor: BLUE3 http://blue3.com.br
Comment: [2019] 20Gbps with PTTRS RPN, 1Gbps with ISP




Trace Url: http://debian.blue3.com.br/debian/project/trace/
Trace Url: http://debian.blue3.com.br/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.blue3.com.br/debian/project/trace/debian.blue3.com.br

Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist

[Martin Olsson]

Hi!

I don't know why you need it, since the bug is in systemctl, but here it is:

#cat /etc/systemd/system/myfoobar.target
[Unit]
Description=MyFooBar (with 2 workers)
Wants=foo1of2.service foo2of2.service

[Install]
WantedBy=multi-user.target


Since Puppet use the exit-status from 'systemctl is-enabled', it is
important that this query can be trusted.
If you have a unit that is currently NOT enabled, the 'systemctl
is-enabled' query should not say "enabled" just because an alias
symlink exist.

If I delete the alias symlink, the 'systemctl is-enabled' query says
"disabled". Correct.
If I create the alias symlink, the 'systemctl is-enabled' query says
"enabled". Wrong!

If I remove the alias symlink and manually run 'systemctl enable
myfoobar.target', then the query says "enabled". Correct (since a
wants-symlink now exist).




Den tis 14 maj 2019 kl 17:19 skrev Michael Biebl :
>
> Am 14.05.19 um 16:58 schrieb Martin Olsson:
> > Package: systemd
> > Version: 232-25+deb9u11
> >
> > Problem:
> > The command 'systemctl is-enabled myfoobar.target' return "enabled"
> > (exit code 0) when it should return "disabled" (code >0).
>
>
> Please share the full myfoobar.target
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Bug#928997: RM: gpsshogi -- RoQA; RoQA, unmaintained, dead-upsteam. low popcon

[Tobias Frost]

Package: ftp.debian.org
Severity: normal

Dear ftp-masters,

Daigo Moriwaki (the maintainer of this package) has asked me to help him
with removal of this package:

"The upstream, gpsshogi, has no update. It would surely be obsolete.
I am ok to orphan or remove it from the Debian."

tobi (for the MIA team)


signature.asc
Description: PGP signature

Bug#928991:

[Samuel Henrique]

Control: fixed -1 t50/5.8.3-2
thanks

Yeah our tooling is not that great :/


--
Samuel Henrique 

Bug#928996: hddemux FTCBFS: upstream Makefile hard codes build architecture build tools

[Helmut Grohne]

Source: hddemux
Version: 0.4-7
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

hddemux fails to cross build from source, because it hard codes build
architecture build tools. The attached patch makes the relevant tools
substitutable and hddemux cross buildable. Please consider applying it.

Helmut
--- hddemux-0.4.orig/Makefile
+++ hddemux-0.4/Makefile
@@ -2,10 +2,11 @@
 
 CFLAGS += -D_GNU_SOURCE -g -O3
 
-CFLAGS += $(shell pkg-config --cflags libuv)
-CFLAGS += $(shell pkg-config --cflags libsystemd)
-LDFLAGS += $(shell pkg-config --libs libuv)
-LDFLAGS += $(shell pkg-config --libs libsystemd)
+PKG_CONFIG ?= pkg-config
+CFLAGS += $(shell $(PKG_CONFIG) --cflags libuv)
+CFLAGS += $(shell $(PKG_CONFIG) --cflags libsystemd)
+LDFLAGS += $(shell $(PKG_CONFIG) --libs libuv)
+LDFLAGS += $(shell $(PKG_CONFIG) --libs libsystemd)
 
 all: hddemux hddemux.1
 
@@ -13,7 +14,7 @@
 	PATH=.:$$PATH ./testsuite
 
 hddemux: hddemux.c
-	gcc $(CPPFLAGS) $(CFLAGS) $< $(LDFLAGS) -std=c11 -pedantic -Wall -Werror -o $@
+	$(CC) $(CPPFLAGS) $(CFLAGS) $< $(LDFLAGS) -std=c11 -pedantic -Wall -Werror -o $@
 
 hddemux.1: hddemux.1.md
 	pandoc -s -f markdown -t man -o $@ $<

Bug#928991:

[Samuel Henrique]

fixed -1 t50/5.8.3-2
thanks


--
Samuel Henrique 

Bug#928995: debian-installer: gen-hd-image: Start default partition size at 4MB.

[Vagrant Cascadian]

Package: debian-installer
Severity: normal
Tags: patch
X-Debbugs-Cc: debian-...@lists.debian.org

Some boot firmware, such as u-boot am335x_evm, have grown large enough
that it may overwrite the start of the first partition when configured
to start at 1MB.

We do not yet support targets affected by this, (e.g. am335x_evm), but
with this patch it would be trivial to add, or at least allow people to
use the firmware.none.img.gz + partition.img.gz and install u-boot
themselves.

Starting at an offset of 4MB will give plenty of room for feature
bloat... er... growth, and also better aligns with default size for page
erases on some media as a minor side benefit.

Currently, only images generated on armhf and arm64 would be affected.


A way to also set the default partition start in "partman" may be needed
as well at some point, in case someone installing with debian-installer
wants to use the boot media for the OS installation.

For now, at least making the boot media start at the 4MB offset will be
a start.


One-line patch attached! :)


live well,
  vagrant

From a05f428d987fadad1c2a1602d75245b42d6df89f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 14 May 2019 12:25:54 -0700
Subject: [PATCH] build/util/gen-hd-image: Start partition offset at 4MB to
 allow more room for boot firmware.

Boot firmware such as u-boot am335x_evm are installed at an offset
before the first partition, but has grown large enough to overlap and
thus overwrite the default 1MB partition offset.
---
 build/util/gen-hd-image | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build/util/gen-hd-image b/build/util/gen-hd-image
index 52697bec7..4a70ee2bd 100755
--- a/build/util/gen-hd-image
+++ b/build/util/gen-hd-image
@@ -63,7 +63,7 @@ PARTID="0x0c"
 FATSIZE="32"
 BUILDTYPE="complete"
 SOURCEDIR="."
-PARTOFFSET="2048"
+PARTOFFSET="8192"
 DEFAULT_IMAGESIZE="976560" # default d-i FLOPPY_SIZE for hd-media images
 IMAGESIZE="${DEFAULT_IMAGESIZE}"
 COMPRESS="none"
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#928014: binNMU: rebuild wine-development against unicode-data 12.1.0~pre1-2

[Paul Gevers]

Hi Jens,

On 12-05-2019 14:50, Jens Reyer wrote:
> Reassigning to the release team then, please binNMU and unblock:
> 
> nmu wine-development_4.2-4 . ANY . unstable . -m "rebuild against 
> unicode-data 12.1.0~pre1-2"

Scheduled. I'll unblock it when all builds are fine.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#928994: unblock: t50/5.8.3-2

[Samuel Henrique]

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

Hello,

I'm asking for the unblock of t50
because a critical bug was solved in the last upload.

The change consists of an update to an already existing quilt patch, and it
is removing architecture specific code from the Makefile.

Bug report: #928991
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928991

Thanks,


-- 
Samuel Henrique 


t50.debdiff
Description: Binary data

Bug#928993: sdaps: Please package the latest upstream version

[Boyuan Yang]

Package: sdaps
Severity: important

Dear sdaps maintainers,

I noticed that Debian is providing sdaps 1.2.1-2 while upstream has released
v1.9.6. The old version depends on python-zbar, which is a python2 binding of
libzbar. We are working on zbar to provide python3 binding instead and
eventually drop the python2 binding, which requires an upgrade for its reverse
dependencies including sdaps. Since sdaps upstream has migrated onto Python3,
packaging the new version seems could solve this issue.

--
Thanks,
Boyuan Yang


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

Bug#928992: priority-extra-is-replaced-by-priority-optional doesn't catch some packages

[s3v]

Package: lintian
Severity: minor


Dear maintainer,

 after downloading Packages.xz file [1] and searching
priority-extra files for amd64 architecture in sid:

 $ sed -n "/Priority: extra/p" Packages | wc -l
 272

I saw a little divergence.
I compared the result with this page [2] that reports 3578 matches
(archs different than amd64? experimental packages?) but some packages
seem to be missing.

E.g.

Package: allure
Version: 0.8.3.0-3
Installed-Size: 36600
Maintainer: Debian Haskell Group 

[...]
Section: games
Priority: extra
^^^

Package: binutils-i686-gnu
Source: binutils
Version: 2.31.1-16
Installed-Size: 15253
Maintainer: Matthias Klose 
[...]
Section: devel
Priority: extra
^^^

maybe others... I have to admit that I have not checked all occurrences.

Thanks for considering.

Kind regards.


[1] http://ftp.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz
[2]
https://lintian.debian.org/tags/priority-extra-is-replaced-by-priority-optional.html

Bug#928991: t50 Makefile is failing to detect right architecture and using cpu specific flags

[Samuel Henrique]

Package: t50
Severity: serious
Version:  5.8.3-1
Fixed: 5.8.3-2

We found out that version 5.8.3-1 of t50 is trying to detect the
architecture its being build to on Makefile but it fails to do that on some
cases, this was detected thanks to the reproducible builds project.

It is known that t50's upstream adds lots of cpu specific code to it, and
the main indicator for that has always been the failure to build in a
reproducible way.

A few days ago I raised a discussion about this problem on the security
tools team's list, and we found out that t50 was using the "-ftree-vectorize"
flag, while at the same time failing to check the correct architecture it
was being build upon.

The fix consisted of removing any CPU specific code from the Makefile, thus
making the build reproducible and fixing the problems with the build.

This is the discussion on the team's mailing list[0]

[0]https://lists.debian.org/debian-security-tools/2019/05/msg1.html

-- 
Samuel Henrique 

Bug#928989: linux-image-4.19.0-4-amd64: CVE-2019-11815

[Ben Hutchings]

Control: fixed -1 4.19.37-1
Control: found -1 4.9.168-2
Control: found -1 3.16.64-2
Control: severity -1 important

On Tue, 2019-05-14 at 14:37 -0400, Jeff Cliff wrote:
> Package: src:linux
> Version: 4.19.28-2
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Dear Maintainer,
> 
> An issue was discovered in rds_tcp_kill_sock in net/rds/tcp.c in the
> Linux kernel before 5.0.8. 
> There is a race condition leading to a use-after-free, related to net
> namespace cleanup.
> 
> the security-tracker is tracking this issue but there does not seem
> to be a bug report for it
> 
> https://security-tracker.debian.org/tracker/CVE-2019-11815
> 
> Fixed by: 
> https://git.kernel.org/linus/cb66ddd156203daefb8d71158036b27b0e2caf63
> 
> currently affects: buster/testing, stable
> currently does not affect: sid
[...]

This was already mitigated in older suites, in that we disable auto-
loading of the rds module.  This is therefore only exploitable on
systems that actually use rds.  For that reason, I'm downgrading this
to "important".

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.




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

Bug#928990: dmarc-cat: attempts internet communication during build

[Gianfranco Costamagna]

Package: dmarc-cat
Version: 0.9.2-1
Severity: serious


Hello, as said, the package attempts to do internet communication during 
build... this is forbidden by policy.

this is an example of what happens in Ubuntu, where internet is more strictly 
disabled:

+--+
| Build|
+--+


Unpack source
-

gpgv: Signature made Tue Feb 12 16:54:32 2019 UTC
gpgv:using RSA key 7B164204D096723B019635AB3EA1B261D97B
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./dmarc-cat_0.9.2-1.dsc
dpkg-source: info: extracting dmarc-cat in dmarc-cat-0.9.2
dpkg-source: info: unpacking dmarc-cat_0.9.2.orig.tar.gz
dpkg-source: info: unpacking dmarc-cat_0.9.2-1.debian.tar.xz

Check disc space


Sufficient free space for build

User Environment


APT_CONFIG=/var/lib/sbuild/apt.conf
DEB_BUILD_OPTIONS=parallel=4
HOME=/sbuild-nonexistent
LANG=C.UTF-8
LC_ALL=C.UTF-8
LOGNAME=buildd
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
SCHROOT_ALIAS_NAME=build-PACKAGEBUILD-16663957
SCHROOT_CHROOT_NAME=build-PACKAGEBUILD-16663957
SCHROOT_COMMAND=env
SCHROOT_GID=2501
SCHROOT_GROUP=buildd
SCHROOT_SESSION_ID=build-PACKAGEBUILD-16663957
SCHROOT_UID=2001
SCHROOT_USER=buildd
SHELL=/bin/sh
TERM=unknown
USER=buildd
V=1

dpkg-buildpackage
-

dpkg-buildpackage: info: source package dmarc-cat
dpkg-buildpackage: info: source version 0.9.2-1
dpkg-buildpackage: info: source distribution unstable
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --buildsystem=golang --with=golang
   dh_auto_clean -O--buildsystem=golang
   dh_autoreconf_clean -O--buildsystem=golang
   dh_clean -O--buildsystem=golang
 debian/rules build
dh build --buildsystem=golang --with=golang
   dh_update_autotools_config -O--buildsystem=golang
   dh_autoreconf -O--buildsystem=golang
   dh_auto_configure -O--buildsystem=golang
   dh_auto_build -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" 
-asmflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" -v -p 4 
github.com/keltia/dmarc-cat
internal/race
runtime/internal/atomic
errors
internal/cpu
runtime/internal/sys
sync/atomic
unicode
unicode/utf8
encoding
internal/bytealg
math
internal/testlog
runtime
math/bits
unicode/utf16
runtime/cgo
vendor/golang_org/x/net/dns/dnsmessage
strconv
internal/nettrace
sync
io
reflect
syscall
github.com/ivpusic/grpool
internal/singleflight
math/rand
bytes
strings
bufio
text/tabwriter
hash
path
hash/crc32
internal/syscall/unix
time
internal/poll
sort
encoding/binary
os
regexp/syntax
encoding/base64
path/filepath
fmt
regexp
io/ioutil
flag
encoding/csv
encoding/xml
encoding/json
go/token
net/url
go/scanner
text/template/parse
go/ast
compress/flate
github.com/pkg/errors
github.com/proglottis/gpgme
text/template
archive/zip
go/parser
go/printer
compress/gzip
log
context
net
go/format
github.com/intel/tfortools
github.com/keltia/archive
github.com/keltia/dmarc-cat
   dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
github.com/keltia/dmarc-cat
=== RUN   TestAnalyze
--- PASS: TestAnalyze (0.00s)
=== RUN   TestGatherRows_Empty
--- PASS: TestGatherRows_Empty (0.00s)
=== RUN   TestGatherRows_Good
--- PASS: TestGatherRows_Good (0.00s)
=== RUN   TestResolveIP_Error
--- PASS: TestResolveIP_Error (0.00s)
=== RUN   TestResolveIP_Good
--- PASS: TestResolveIP_Good (0.00s)
=== RUN   TestCheckFilename
--- PASS: TestCheckFilename (0.00s)
=== RUN   TestHandleSingleFile
--- PASS: TestHandleSingleFile (0.00s)
=== RUN   TestHandleSingleFile2
--- PASS: TestHandleSingleFile2 (0.00s)
=== RUN   TestHandleSingleFile3
--- PASS: TestHandleSingleFile3 (0.00s)
=== RUN   TestHandleSingleFile4
--- PASS: TestHandleSingleFile4 (0.00s)
=== RUN   TestHandleSingleFile_Verbose
--- PASS: TestHandleSingleFile_Verbose (0.00s)
=== RUN   TestHandleSingleFile_Debug
2019/05/03 10:40:43 file=empty.txt
--- PASS: TestHandleSingleFile_Debug (0.00s)
=== RUN   TestSetup
2019/05/03 10:40:43 You must specify at least one file.
--- PASS: TestSetup (0.00s)
=== RUN   TestSetup2
--- PASS: TestSetup2 (0.00s)
=== RUN   TestSetup3
--- PASS: TestSetup3 (0.00s)
=== RUN   TestSetup4
dmarc-cat.test version 0.9.2/j4 archive/0.3.3
--- PASS: TestSetup4 (0.00s)
=== RUN   TestVersion
dmarc-cat.test version 0.9.2/j4 archive/0.3.3
--- PASS: TestVersion (0.00s)
=== RUN   TestMain_Noargs
2019/05/03 10:40:43 You must specify at least one file.
--- PASS: TestMain_Noargs (0.00s)
=== RUN   TestMain_Noargs_Verbose
2019/05/03 10:40:43 You must specify at least one file.
--- PASS: TestMain_Noargs_Verbose (0.00s)
=== RUN   

Bug#928465: stretch-pu: package linux/4.9.168-1

[Salvatore Bonaccorso]

Hi Adam,

On Thu, May 09, 2019 at 10:04:10PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> Hi,
> 
> Sorry for not picking this up sooner.
> 
> On Sun, 2019-05-05 at 11:28 +0200, Salvatore Bonaccorso wrote:
> > The last linux upload via the stretch point release unfortunately
> > uncovered #928125, easily triggerble when forcing the kernel to scan
> > the partition table on a newly created loop device.
> > 
> > In the upstream development of the 4.9 series between the 4.9.140
> > upload in the previous stretch point release, some backports to
> > changes related to the loopback were  again later reverted due to
> > regressions.
> > 
> > One commit though was keept up to 4.9.168, which relates to the
> > thread
> > in 
> > https://lore.kernel.org/stable/20190320125806.gd9...@quack2.suse.cz/
> > .
> > 
> > I seek input/advice/opinion from you stable release managers: Do you
> > want to issue a SUA and fast-track a fix for this issue via
> > stretch-updates?
> > 
> > For completeness, the isolated revert is at
> > https://salsa.debian.org/kernel-team/linux/commit/5f66def673547b7d1e7
> > a841937fbd0ab10a925a0
> 
> Let's go with the quicker fix - hopefully the SUA can get released over
> the weekend.

We will "shortly" release a DSA for linux which will include this
regression fix as well, so no furhter action via a SUA would be
needed.

Regards,
Salvatore

Bug#928989: linux-image-4.19.0-4-amd64: CVE-2019-11815

[Jeff Cliff]

Package: src:linux
Version: 4.19.28-2
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

An issue was discovered in rds_tcp_kill_sock in net/rds/tcp.c in the Linux 
kernel before 5.0.8. 
There is a race condition leading to a use-after-free, related to net namespace 
cleanup.

the security-tracker is tracking this issue but there does not seem to be a bug 
report for it

https://security-tracker.debian.org/tracker/CVE-2019-11815

Fixed by: https://git.kernel.org/linus/cb66ddd156203daefb8d71158036b27b0e2caf63

currently affects: buster/testing, stable
currently does not affect: sid


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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 
root=UUID=6fa86bad-c261-44db-8fc0-f7bd76dc2be3 ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

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

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

Versions of packages linux-image-4.19.0-4-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod26-1
ii  linux-base  4.5

Versions of packages linux-image-4.19.0-4-amd64 recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4
ii  irqbalance   1.5.0-3

Versions of packages linux-image-4.19.0-4-amd64 suggests:
ii  debian-kernel-handbook  1.0.19
ii  grub-pc 2.02+dfsg1-16
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-4-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- debconf-show failed

Bug#905720: Bug#926681: unblock: acme-tiny/1:4.0.4-1

[Samuel Henrique]

Hi all,

Uploaded to the DELAYED queue with 7 days delay.

On Sun, 12 May 2019 at 14:58, Samuel Henrique  wrote:

> Hello Niels,
>
> Sorry for the delay on this.
>>
>
> No worries, I know you've been doing lots of work during the freeze, and I
> noticed that you also proactively unblocked some of my packages, thanks for
> that.
>
>
>> Please go ahead with the upload and remove the moreinfo tag once it is
>> in unstable and ready to be unblocked.
>>
>
> Unfortunately the package was removed from testing 5 days ago [2019-05-08],
> the freeze policy says that "packages not in testing can not migrate to
> testing¨.
>
> Is this case different because the fix was ready before the package was
> removed?
>
> Harlan and Sebastien:
> I think I'm not in the salsa team yet, can you please take a look at this
> as well, so I would rather have the team's acknowledgment, this seems like
> an important package for you.
>

Thanks,

-- 
Samuel Henrique 

Bug#928988: RM: openjdk-7/experimental -- ROM; obsolete, no longer builds

[Emilio Pozuelo Monfort]

Package: ftp.debian.org
Severity: normal

Hi,

openjdk-7 was kept in experimental in order to prepare updates and see
them build, and later backport them to the security suites that still
had openjdk-7. However for a while now openjdk-7 hasn't built on
experimental anymore, and it's only supported on jessie now, so it
makes sense to remove it from experimental and upload the new updates
directly to jessie.

I talked to Matthias and he acked this plan.

Cheers,
Emilio

Bug#927348: unblock: salt/2018.3.4+dfsg1-2

[Paul Gevers]

Hi Benjamin,

On 14-05-2019 13:13, Benjamin Drung wrote:
> Hi Paul,
> 
> Am Freitag, den 10.05.2019, 20:40 +0200 schrieb Paul Gevers:
>> Control: tags -1 moreinfo
>>
>> So, all in all, I don't want to unblock the new upstream with your
>> packaging, we're too late in the cycle and the version really doesn't
>> match the freeze policy. However, I am offering you an upload based
>> on the version currently in buster via t-p-u. If you go that route,
>> please only fix bugs 919849, 928337, 922352, 924763, the
>> LC_ALL=C.UTF-8 item and the systemd issue. Please fix 919849 without
>> switching your build to sphinxdoc, that isn't appropriate at this
>> moment.
> 
> Okay. So you prefer an upload to t-p-u or can I just revert those
> rejected changes (typos fixes and using dh_sphinxdoc) and do another
> upload to unstable?

I would prefer an upload to unstable if you also revert to the previous
upstream tar ball (e.g. using the +really version syntax).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#846645: Proposal

[Lehmann Schulz]

Please did you receive the project email I sent you?

Bug#928505: fixed in ruby-pygments.rb 1.2.0-4

[Pirate Praveen]

On Tue, May 14, 2019 at 8:51 AM, d...@debian.org wrote:

Hi,

On Sun, May 12, 2019 at 09:55:33PM +0530, Pirate Praveen wrote:
 We will have to file an unblock request for this to migrate to 
testing.

 Can you file it?


sorry for my afk, but thanks to release team (maybe), it migrated to 
testing.




Great! I was just checking in case you forgot.

Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2

[Vagrant Cascadian]

On 2019-05-14, Domenico Andreoli wrote:
> On Sun, May 12, 2019 at 10:13:50AM -0700, Vagrant Cascadian wrote:
>> On 2019-05-12, Karsten Merker wrote:
>> > On Sun, May 12, 2019 at 10:40:39AM +0200, Domenico Andreoli wrote:
>> > > Please mind that the NanoPi NEO 2 target for u-boot has just been merged
>> > > in sid so it's not yet in Buster.
...
>> Would it be ok to test it in-place on an installed system by adding the
>> entry to /etc/flash-kernel/db? That's how I usually test boards I've
>> added. Or do you not have an installed system?
>
> Yes, I've a running system and the locally built flash-kernel now
> creates a nice boot.scr in /boot.
>
> Now the problem is that my first partition is for EFI (I installed with
> regular Buster RC1 installer) and so u-boot does not find the newly
> created boot.scr and just goes with grub.
>
> If I put the boot.scr in the EFI partition, grub is still used. I'm a bit
> struggling to understand why. I'll try to manually boot with boot.scr,
> just to validate it.

u-boot will look for a partition marked bootable, which is different for
GPT partition tables, and falls back to the first partition if neither
an msdos bootable partition nor a gpt bootable partition is found.

You can interrupt the boot process at the u-boot prompt and change...:

  editenv scan_dev_for_boot_part

change:

  ... env exists devplist || setenv devplist 1 ...

to:

  ... env exists devplist ; setenv devplist 3 ...

Assuming partition 3 is where /boot/boot.scr resides.


>> It's a bit difficult to fully test within debian-installer, as the
>> installer typically pulls in .udebs from the archive, and you have a bit
>> of chicken-and-egg problem to require testing from d-i, or a lot of
>> manual fiddling within the installer. You could also patch
>> /target/etc/flash-kernel/db or /target/usr/share/flash-kernel/db from
>> within the install at just the right moment ...
>
> Thanks for the trick but you don't say when it's the right moment :)

Before it runs flash-kernel, but after it's installed... or
something. I haven't ever done that part.


> Aside from that, a few other things are not clear to me:
>
> * is it true that Debian arm64 implies UEFI+grub?

I think the goal was to stick to EFI on arm64 on Debian, but I think
some hardware vendors have implemented some things in a way that makes
that more difficult (e.g. allwinner 64-bit device offsets conflicting
with standard GPT partitioning).


>   if not, how does e.g. Pine64 handle bare u-boot vs u-boot + grub?

Manual configuration of the partition table. I *think* if you set the
debconf priority to low it gives you the option to create an MSDOS/MBR
style partition table.

On my pinebook's initial installation, I managed to install with GPT
partition tables and u-boot+EFI+GRUB and that sort of worked, except it
wiped out the bootloader. Then I managed to convert the GPT partition
table to MSDOS/MBR and re-installed u-boot and I've been using that ever
since.


> * is the partition table label (msdos vs. gpt) dependent on the board?
>   if not, how does e.g. Pine64 handle GPT + spl?

Apparently it may be possible to install any of the 64-bit allwinner
boards with a specially crafted GPT partition table with few enough
partitions:

  https://salsa.debian.org/debian/u-boot/merge_requests/6

I haven't verified that it works yet. Or if simply creating four or
fewer partitions will work correctly from the installer.


> Is an updated flash-kernel-installer udeb going to automagically solve
> all the above issues or am I missing some other moving part here?

Definitely not, unfortunately.


> I'm definitively impressed by the evolution reached to handle all the
> specially crafted variants supported out of the box.
>
> Thanks for the support.

Working on it ... still a long ways to go! Thanks for your help adding
one more board!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#928967: unblock: needrestart/3.4-4

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Tue, May 14, 2019 at 11:25:57AM +0200, Patrick Matthäi wrote:
> +needrestart (3.4-3~bpo9+1) stretch-backports; urgency=medium
> +
> +  * Rebuild for stretch-backports.
> +
> + -- Patrick Matthäi   Wed, 24 Apr 2019 10:04:02 +0200
> +

This changelog entry should not be present; 3.4-3~bpo9+1 is not an
ancestor of 3.4-4.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#928965: unblock: lsb/10.2019051400

[Jonathan Wiltshire]

Control: tag -1 confirmed moreinfo

On Tue, May 14, 2019 at 08:57:18AM +0200, Didier 'OdyX' Raboud wrote:
> I hereby request an upload authorization towards an unblock for package lsb
> 10.2019051400, which was not uploaded yet.
> 
> lsb (10.2019051400) unstable; urgency=medium
> 
>   [ Harald Dunkel ]
>   * pidofproc: use "pidof -c" to avoid pidofproc results from containers or 
> chroots
> (Closes: #888743)

Please go ahead and remove the moreinfo tag from this bug when it is ready
to be unblocked.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#928987: compiz: make a compiz-boxmenu package

[boffi]

Source: compiz
Severity: wishlist

Dear Maintainer,

I'd like to see compiz-boxmenu

in Debian.

Thank you for compiz, ciao · g
-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#928986: CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:

[Johannes 'josch' Schauer]

Package: cloudcompare
Version: 2.10.1-1
Severity: grave
Justification: renders package unusable

Hi,

after installing the package, when attempting to start CloudCompare I
get the following error message:

CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:
cannot open shared object file: No such file or directory

Indeed that file seems to be contain in no binary package in the
archive?

Thanks!

cheers, josch


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

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

Versions of packages cloudcompare depends on:
ii  libboost-atomic1.67.0 1.67.0-11
ii  libboost-chrono1.67.0 1.67.0-11
ii  libboost-date-time1.67.0  1.67.0-11
ii  libboost-system1.67.0 1.67.0-10
ii  libboost-thread1.67.0 1.67.0-11
ii  libc6 2.28-2
ii  libcgal13 4.12-1
ii  libgcc1   1:8.2.0-9
ii  libgl11.1.0-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgmpxx4ldbl 2:6.1.2+dfsg-4
ii  libgomp1  8.2.0-9
ii  libmpfr6  4.0.1-1
ii  libpdal-base7 1.8.0+ds-1+b2
ii  libpdal-util7 1.8.0+ds-1+b2
ii  libqt5concurrent5 5.11.3+dfsg-2
ii  libqt5core5a  5.11.3+dfsg-2
ii  libqt5gui55.11.3+dfsg-2
ii  libqt5opengl5 5.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg-2
ii  libqt5widgets55.11.3+dfsg-2
ii  libstdc++68.2.0-9

cloudcompare recommends no packages.

cloudcompare suggests no packages.

-- debconf-show failed

Bug#928863: debian-installer: Add support for NanoPi NEO2

[Cyril Brulebois]

Hi,

Domenico Andreoli  (2019-05-14):
> > I suppose we could merge this and let you test and report what
> > happens with daily builds. Would that be fine with you?
> 
> Of course it's fine with me.

Great! Just pushed an updated master; you should find updated images in
a couple of hours here:
  https://d-i.debian.org/daily-images/daily-build-overview.html
  https://d-i.debian.org/daily-images/arm64/daily/

> > I see that Vagrant already spotted the needed bump to Build-Depends.
> > :)
> 
> I already fixed it, the MR is updated.

Yeah, sure! I just mentioned it because that's one of our usual gotchas
when adding support to new hardware, and I was happy to see it was
already taken care of. :)


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


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[gregor herrmann]

On Mon, 13 May 2019 01:02:45 +0200, Guilhem Moulin wrote:

> Thanks for your analysis, Steffen.  Dropping the Debian-specific patch
> is definitely the way to go for libwww/LWP.

Thanks for the confirmation, Guilhem, and all your work on this
issue, and thanks alot to Steffen for tracking down the real cuplrit
of the troubles!

I've now uploaded libwww-perl without the problematic patch (and this
upload will close the bug).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Tori Amos: Yes, Anastasia


signature.asc
Description: Digital Signature

Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2

[Domenico Andreoli]

On Sun, May 12, 2019 at 10:13:50AM -0700, Vagrant Cascadian wrote:
> On 2019-05-12, Karsten Merker wrote:
> > On Sun, May 12, 2019 at 10:40:39AM +0200, Domenico Andreoli wrote:
> > > ...
> > >
> > > Please mind that the NanoPi NEO 2 target for u-boot has just been merged
> > > in sid so it's not yet in Buster.
> ...
> > while the change looks ok to me, I'd very much prefer if it was
> > actually tested before committing it (the same is true for
> > bug#928863).
> 
> Would it be ok to test it in-place on an installed system by adding the
> entry to /etc/flash-kernel/db? That's how I usually test boards I've
> added. Or do you not have an installed system?

Yes, I've a running system and the locally built flash-kernel now
creates a nice boot.scr in /boot.

Now the problem is that my first partition is for EFI (I installed with
regular Buster RC1 installer) and so u-boot does not find the newly
created boot.scr and just goes with grub.

If I put the boot.scr in the EFI partition, grub is still used. I'm a bit
struggling to understand why. I'll try to manually boot with boot.scr,
just to validate it.

> 
> It's a bit difficult to fully test within debian-installer, as the
> installer typically pulls in .udebs from the archive, and you have a bit
> of chicken-and-egg problem to require testing from d-i, or a lot of
> manual fiddling within the installer. You could also patch
> /target/etc/flash-kernel/db or /target/usr/share/flash-kernel/db from
> within the install at just the right moment ...

Thanks for the trick but you don't say when it's the right moment :)

Aside from that, a few other things are not clear to me:

* is it true that Debian arm64 implies UEFI+grub?
  if not, how does e.g. Pine64 handle bare u-boot vs u-boot + grub?
* is the partition table label (msdos vs. gpt) dependent on the board?
  if not, how does e.g. Pine64 handle GPT + spl?

Is an updated flash-kernel-installer udeb going to automagically solve
all the above issues or am I missing some other moving part here?

I'm definitively impressed by the evolution reached to handle all the
specially crafted variants supported out of the box.

Thanks for the support.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#928985: bluez: Device1 UUIDs property D-Bus reading issue

[Artem Kabakov]

Package: bluez
Version: 5.50
Severity: normal

Dear Maintainer,

My application uses bluez for BLE data exchange and connection management. It 
has recconection logic implemented: after the app start, it reads "UUID" 
property of paired
BLE devices from cache using bluez API 
(bluez_device_get_property(g_dbus_proxy_get_object_path(proxy), "UUIDs").
The devices that have this property are added to reconnection list.

The bug description:

1. Six BLE devices were paired to raspberry PI 3b via bluez API.

2. After some time of normal operation (about 2 weeks with daily reboot), the 
attempt of reading out "UUIDs" property for one of the paired devices returned 
0: bluez API 
returned zero-length UUIDs list ("Found 0 UUIDs on the device 
/org/bluez/hci0/dev_94_54_93_XX_XX_XX"). System reboot didn't resolve the issue 
- it was still not possible to read out UUID prorerty via bluez API. 
However, this property was avaliable in the file here 
/var/lib/bluetooth/B8:27:EB:10:DE:3D/94:54:93:XX:XX:XX/info. 
The device's other properties, like "Paired", "Address", "RSSI" were also 
avaliable for reading out using bluez API, so the device reconnection could be 
completed forcibly.
After the reconnection, "UUID" property became avaliable for reading out via 
bluez API again.
What could be the issue with data lost in the cache?

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.1 (stretch)
Release:9.1
Codename:   stretch
Architecture: armv7l

Kernel: Linux 4.14.94-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bluez depends on:
ii  dbus 1.10.26-0+deb9u1
ii  init-system-helpers  1.48
ii  kmod 23-2
ii  libc62.24-11+deb9u1
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libreadline7 7.0-3
ii  libudev1 232-25+deb9u2
ii  lsb-base 9.20161125+rpi1
ii  udev 232-25+deb9u2

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- Configuration Files:
/etc/dbus-1/system.d/bluetooth.conf changed:

http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;>

  
  











  
  

  
  
  

  
  

  



-- no debconf information

Bug#901389: [firmware-iwlwifi] Crash when using as a hotspot with intense usage

[nozzy123nozzy]

Package: src:linux
Version: 4.19.37-1
Severity: important

Dear Maintainer,

 I use another version of linux in my debian box,but I also have
totally the same problem when I use my laptop as a hotspot.

 I attached crash log filename="crash.log" in this report.

 This problem is randomly and often happened. I think this problem is
more often happend when windows10 pc access to this hotspot via wifi.

 I hope someone will fix this problem.

Thank you in advance,
 --
Takahide Nojima

-- Package-specific info:
** Version:
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-1 (2019-05-05)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=f8dd9a0a-8954-4faa-
afe8-ecda81deca67 ro quiet

** Not tainted

** Kernel log:
[5.342873] Bluetooth: hci0: API lock is enabled
[5.342873] Bluetooth: hci0: Debug lock is disabled
[5.342875] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[5.355324] bluetooth hci0: firmware: direct-loading firmware
intel/ibt-11-5.sfi
[5.355328] Bluetooth: hci0: Found device firmware: intel/ibt-11-
5.sfi
[5.355879] idma64 idma64.1: Found Intel integrated DMA 64-bit
[5.368464] sr 0:0:0:0: Attached scsi generic sg0 type 5
[5.387753] Adding 1952764k swap on /dev/nvme0n1p5.  Priority:-2
extents:1 across:1952764k SSFS
[5.396268] intel_rapl: Found RAPL domain package
[5.396270] intel_rapl: Found RAPL domain core
[5.396270] intel_rapl: Found RAPL domain uncore
[5.396271] intel_rapl: Found RAPL domain dram
[5.410355] usbcore: registered new interface driver uvcvideo
[5.410356] USB Video Class driver (1.1.1)
[5.410916] input: HDA Intel PCH Mic as
/devices/pci:00/:00:1f.3/sound/card0/input19
[5.410968] input: HDA Intel PCH Headphone as
/devices/pci:00/:00:1f.3/sound/card0/input20
[5.411321] input: HDA Intel PCH HDMI/DP,pcm=3 as
/devices/pci:00/:00:1f.3/sound/card0/input21
[5.411593] input: HDA Intel PCH HDMI/DP,pcm=7 as
/devices/pci:00/:00:1f.3/sound/card0/input22
[5.411639] input: HDA Intel PCH HDMI/DP,pcm=8 as
/devices/pci:00/:00:1f.3/sound/card0/input23
[5.411680] input: HDA Intel PCH HDMI/DP,pcm=9 as
/devices/pci:00/:00:1f.3/sound/card0/input24
[5.411722] input: HDA Intel PCH HDMI/DP,pcm=10 as
/devices/pci:00/:00:1f.3/sound/card0/input25
[5.448734] iwlwifi :05:00.0: base HW address: 28:16:ad:e9:10:c9
[5.498155] pktcdvd: pktcdvd0: writer mapped to sr0
[5.506507] pktcdvd: pktcdvd0: pkt_get_last_written failed
[5.528738] input: VAIO0002:00 04F3:3014 Touchpad as
/devices/pci:00/:00:15.0/i2c_designware.0/i2c-1/i2c-
VAIO0002:00/0018:04F3:3014.0001/input/input27
[5.528875] hid-multitouch 0018:04F3:3014.0001: input,hidraw0: I2C
HID v1.00 Mouse [VAIO0002:00 04F3:3014] on i2c-VAIO0002:00
[5.550162] ieee80211 phy0: Selected rate control algorithm 'iwl-
mvm-rs'
[5.550408] thermal thermal_zone4: failed to read out thermal zone
(-61)
[5.552550] iwlwifi :05:00.0 wlp5s0: renamed from wlan0
[5.556225] audit: type=1400 audit(1557846641.909:2):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/lib/unreal-*/System/*.bin" pid=568 comm="apparmor_parser"
[5.559893] audit: type=1400 audit(1557846641.913:3):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/lib/telepathy/mission-control-5" pid=567
comm="apparmor_parser"
[5.559897] audit: type=1400 audit(1557846641.913:4):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/lib/telepathy/telepathy-*" pid=567 comm="apparmor_parser"
[5.559899] audit: type=1400 audit(1557846641.913:5):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/lib/telepathy/telepathy-*//pxgsettings" pid=567
comm="apparmor_parser"
[5.559900] audit: type=1400 audit(1557846641.913:6):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/lib/telepathy/telepathy-*//sanitized_helper" pid=567
comm="apparmor_parser"
[5.559902] audit: type=1400 audit(1557846641.913:7):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/lib/telepathy/telepathy-ofono" pid=567
comm="apparmor_parser"
[5.560973] audit: type=1400 audit(1557846641.913:8):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="nvidia_modprobe" pid=574 comm="apparmor_parser"
[5.560976] audit: type=1400 audit(1557846641.913:9):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="nvidia_modprobe//kmod" pid=574 comm="apparmor_parser"
[5.563849] audit: type=1400 audit(1557846641.917:10):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/bin/man" pid=575 comm="apparmor_parser"
[5.563851] audit: type=1400 audit(1557846641.917:11):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="man_filter" pid=575 comm="apparmor_parser"
[

Bug#927913: As we see upstream has no such problem

[積丹尼 Dan Jacobson]

As we see in the comments above upstream has no such problem.
So I cannot file the bug upstream.

Bug#928863: debian-installer: Add support for NanoPi NEO2

[Domenico Andreoli]

On Tue, May 14, 2019 at 02:42:01PM +0200, Cyril Brulebois wrote:
> Hi Domenico,

Hi Cyril,

> Domenico Andreoli  (2019-05-12):
> >   please consider adding the generation of the installer image file
> > for FriendlyArm NanoPi NEO 2. MR is available on Salsa:
> > 
> > https://salsa.debian.org/installer-team/debian-installer/merge_requests/9
> 
> At first glance, that looks good to me.
> 
> > I was not able to cross-build the arm64 installer from amd64 so the
> > patch is not tested.
> 
> I suppose we could merge this and let you test and report what happens
> with daily builds. Would that be fine with you?

Of course it's fine with me.

> 
> > Please mind that the NanoPi NEO 2 target for u-boot has just been
> > merged in sid so it's not yet in Buster.
> 
> I see that Vagrant already spotted the needed bump to Build-Depends. :)

I already fixed it, the MR is updated.

> 
> That shouldn't stop us from merging your work right now, I can always
> hint u-boot into buster, should we need it; but thanks for mentioning it
> anyway!

Thanks a lot :)

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#928984: ifupdown: networking lost when installing ifupdown2

[George Diamantopoulos]

Package: ifupdown
Version: 0.8.35
Severity: important

Dear Maintainer,

I'm not sure if this bug should be filed against ifupdown or ifupdown2.
This issue only seems to affect current versions of these packages
in buster, I haven't encountered this in stretch.

When installing ifupdown2, apt will remove ifupdown before proceeding with
installation of ifupdown2 as the two cannot co-exist on the same system.

The problem seems to be that, following removal of ifupdown, the networking
service is stopped, and the host loses all connectivity. This behaviour is
potentially debilitating, especially when the task is performed via SSH
or via configuration management software which depends on the host
being reachable over the network to operate.

When issuing the command to install ifupdown2 over SSH the issue can be
quite easily worked around by restarting the networking service immediately
after ifupdown2 is installed:
  apt-get install ifupdown2 && systemctl restart networking

However, there seems to be no simple solution when using configuration
management (like ansible) to install ifupdown2. The relevant tasks will
hang forever upon ifupdown2 installation.

Is this deliberate? Any chance you can reconsider the actions taken
upon uninstallation of ifupdown? Thank you.

Best regards,
George Diamantopoulos

-- 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_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  lsb-base  10.2019031300

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- Configuration Files:
/etc/default/networking changed [not included]
/etc/init.d/networking changed [not included]

Bug#928983: ITP: gversion-plugin -- Gradle plugin for auto generating a version class in multiple JVM Languages

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : gversion-plugin
  Version : 1.5.0
  Upstream Author : Peter Abeles 
* URL : https://github.com/lessthanoptimal/gversion-plugin
* License : MIT or Unlicense
  Programming Lang: Java
  Description : Gradle plugin for auto generating a version class in
multiple JVM Languages
gversion-plugin is a Gradle plugin for auto generating a version class in
multiple JVM Languages. Currently it support Java and Kotlin. The class will
include information which can only be obtained at compile time, such as
build
time, git SHA, and Gradle version. Command line applications are used to
gather
most of this information. If a command line operation fails a default value
will be used instead.

gversion-plugin is required to build boofcv, which in turn is required
by cephis, publication-mining library, which I intend to package.

This package is to be maintained in Java Team at
https://salsa.debian.org/java-team/gversion-plugin

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist

[Michael Biebl]

Am 14.05.19 um 16:58 schrieb Martin Olsson:
> Package: systemd
> Version: 232-25+deb9u11
> 
> Problem:
> The command 'systemctl is-enabled myfoobar.target' return "enabled"
> (exit code 0) when it should return "disabled" (code >0).


Please share the full myfoobar.target


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist

[Martin Olsson]

Package: systemd
Version: 232-25+deb9u11

Problem:
The command 'systemctl is-enabled myfoobar.target' return "enabled"
(exit code 0) when it should return "disabled" (code >0).

How to reproduce:
Create a symlink /etc/systemd/system/foo.target -->
/etc/systemd/system/myfoobar.target
either manually with 'ln -s' or via an "Alias=" in your unit file.

Without the alias symlink, 'systemctl is-enabled myfoobar.target'
return "disabled" just as it should.
When adding the symlink, 'systemctl is-enabled myfoobar.target'
suddenly return "enabled".
I think this is wrong.

The manual states:
--
is-enabled NAME...
Checks whether any of the specified unit files are enabled (as with
enable). Returns an exit code of 0 if at least one is enabled,
non-zero otherwise.
Prints the current enable status (see table). To suppress this output,
use --quiet. To show installation targets, use --full.
Result "enabled" (exit code 0) = Enabled via .wants/, .requires/ or
alias symlinks (permanently in /etc/systemd/system/, or transiently in
/run/systemd/system/).
--

Why should is-enabled report "enabled" on alias symlinks in
/etc/systemd/system/?
Aliases are just aliases, they don't automatically enable the
service/target/unit on boot.



How I found this issue:
I use Puppet to handle the state of my custom service (which is
actually a .target, with multiple services as Wants).
When Puppet check to see if the service 'myfoobar.target' is enabled,
it runs the command 'systemctl is-enabled myfoobar.target'. This
returns true (since I have an alias symlink
/etc/systemd/system/foo.target), so Puppet never force the service to
become enabled. :-(

Bug#928963: giveback for monkeysphere 0.43-3 on ppc64, s390x, and sparc64

[Daniel Kahn Gillmor]

Hi Debian buildd maintainers for our 64-bit big-endian platforms!

monkeysphere 0.43-3 FTBFS on ppc64, s390x, and sparc64.  I traced the
problem down to https://bugs.debian.org/928963 in GnuPG, which is now
fixed upstream (https://dev.gnupg.org/T4501) and patched in debian
unstable.

This was a subtle bug in GnuPG's use of the GCrypt S-Expression
string-assembling printf-style interface.  On platforms where int and
size_t are the same size, or on little-endian platforms where size_t is
bigger than int, there was no problem.

However, ppc64, s390x, and sparc64 all are "weird" enough that this
subtle bug in GnuPG manifested itself there.

With that issue fixed, monkeysphere builds and tests fine on s390x (i've
tested directly on the porterbox zelenka.debian.org) and it should be
fine on the other platforms as well.  if you could poke your
architecture's build daemon to give back monkeysphere 0.43-3, that would
be great!

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#928981: fai-client: regression introduced with bugfix for #925247: leaving /run/udev behind itself

[Michael Prokop]

Package: fai-client
Version: 5.8.4
Severity: important

Hi,

with the following change I noticed a regression in FAI's behavior
of task_updatebase(), which leaves /run/udev behind itself:

| commit a03e71b12a544460ba78c97f67623a461b3ecc54
| Author: Thomas Lange 
| Date:   Mon Mar 25 21:22:25 2019 +0100
| 
| mount /run/udev into /target, closes: #925247
| 
| diff --git a/lib/updatebase b/lib/updatebase
| index 5ed845d1..fc1d1e4d 100755
| --- a/lib/updatebase
| +++ b/lib/updatebase
| @@ -13,6 +13,8 @@ if [ "$FAI_ACTION" = "install" -o "$FAI_ACTION" = 
"dirinstall" ]; then
|  if [ -f /etc/init.d/udev ]; then
|mount --bind /dev $FAI_ROOT/dev
|mount --make-private $FAI_ROOT/dev
| +  mkdir -p $target/run/udev
| +  mount --bind /run/udev $target/run/udev
|  fi
|  mount -t devpts devpts $FAI_ROOT/dev/pts
|  mount --make-private $FAI_ROOT/dev/pts

I noticed the bug in grml-live's fai dirinstall usage, leaving
/run/udev inside the chroot behind:

| rm: cannot remove 
'/srv/jenkins/jobs/grml64-small_sid/workspace/grml_chroot/run/udev': Device or 
resource busy

regards
-mika-

Bug#922935: Run without cron or is cron job still needed?

[Bálint Réczey]

Hi Bryan,

Bryan Quigley  ezt írta (időpont: 2019.
febr. 22., P, 2:03):
>
> Package: passwd
> Version: 1:4.5-1.1
>
> This is regards to passwd.cron.daily which backups 
> passwd/group/shadow/gshadow daily, which AFAICT is not upstream, but may have 
> been in the past.
>
> I'm looking at what it takes to run systems without cron and following the 
> example of other packages like logrotate:
>
> They add this bit to the cron script:
> # skip in favour of systemd timer
> if [ -d /run/systemd/system ]; then
> exit 0
> fi
>
> and then create a systemd service/timer.  Happy to do the work to make a 
> patch if the above is the preferred solution.

Thank you for the offer. It is indeed a good solution and a patch is welcome.

Cheers,
Balint

>
> ___
>
> Alternatively, I have also wondered if the cron job functionality is still 
> needed or if the built-in generated backups are enough - /etc/group- etc.
>
> On my machine the /etc/group- backup would have been much more useful then 
> the one replaced daily by the cron job in /var/backups.
>
> Thanks!

Bug#928170: chrony: Apparmor profile contains wrong path for samba sntp

[Vincent Blut]

Hi Louis,

So According to the information gleaned in #928168¹, adding a rule to 
allow read access to winbindd pipe doesn’t seem necessary‽
As far as I can see from my local tests, only read/write access to 
/var/lib/samba/ntp_signd/socket is needed. Could you please confirm?


If so, chronyd’s Apparmor profile should just include (for samba ofc):
/var/lib/samba/ntp_signd/socket rw,

Cheers,
Vincent


¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928168


signature.asc
Description: PGP signature

Bug#928068: ruby2.5: FTBFS on ia64 due to segfault

[John Paul Adrian Glaubitz]

On 5/14/19 2:39 PM, Antonio Terceiro wrote:
> It would be nice if you could build from git master and confirm that all
> goes well; I would have done it myself but there is no ia64 porterbox
> listed in the Debian LDAP.

I just verified that the patch fixes the build on ia64 for me.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Tobias Eliasson]

Den tis 14 maj 2019 kl 15:05 skrev Vincent Lefevre :

>
> This patch alone (slightly modified to avoid a conflict) does not
> solve the issue. I even suspect that the "double free" error and
> that the patch issue had different causes. The "double free" error
> might be this one:
>
>
> https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/14c23a5715c529be175d8d6152cabd4ddad4e981
>
> ("Fix double-free").
>
> Perhaps we're seeing two issues then, both the appended (double) sysroot
and double free.

Are you able to reproduce this error with the latest fontconfig 2.13.1 in
buster?
Seeing as the defect was written with the old 2.12.6 release in mind and if
we can't reproduce this in the latest release this defect should be
rejected.

Bug#904998: closing GCC issue

[Matthias Klose]

Version: 8.3.0-1

> Confirming that this bug is fixed in 8.3.0

closing.

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Vincent Lefevre]

On 2019-05-14 12:37:57 +0200, Tobias Eliasson wrote:
> Den tis 14 maj 2019 kl 11:14 skrev Vincent Lefevre :
> > (BTW, the bug did not appear to be fixed according to the fontconfig
> > changelog, but the changelog does not actually seem to be up-to-date!)
> >
> > I narrowed it down to commit 34b5c949d51fcc8eafe2301ca8f539f735e31522
> upstream at fontconfig which solves this issue.
> See
> https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/34b5c949d51fcc8eafe2301ca8f539f735e31522
> for more information.

This patch alone (slightly modified to avoid a conflict) does not
solve the issue. I even suspect that the "double free" error and
that the patch issue had different causes. The "double free" error
might be this one:

https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/14c23a5715c529be175d8d6152cabd4ddad4e981

("Fix double-free").

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Paul Wise]

On Tue, 2019-05-14 at 13:57 +0100, Ben Hutchings wrote:

> Does user-mode-linux need to be a separate source package at all?

I guess it is separate to not require building yet another variant.

Looks like merging it was discussed in 2016:

https://bugs.debian.org/837920

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#928980: icecc: Icecream writing logs to location with no permission

[Matthew Exon]

Source: icecc
Version: 1.2-1
Severity: normal
Tags: patch

Icecream is writing its log files directly to /var/log, even though it
is running as the icecc user which has no permission to write to
/var/log.  This problem has already been reported in Ubuntu here:

https://bugs.launchpad.net/ubuntu/+source/icecc/+bug/1671926

I've attached a patch to fix it.  As suggested in the Ubuntu bug, I have
added a HUP signal when the logs are rotated.  I have also added
/etc/default files to allow easily turning up the log level.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-48-generic (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru icecc-1.2/debian/changelog icecc-1.2/debian/changelog
--- icecc-1.2/debian/changelog  2018-12-21 08:29:36.0 +
+++ icecc-1.2/debian/changelog  2019-05-14 12:12:44.0 +
@@ -1,3 +1,10 @@
+icecc (1.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Write log files to a location with appropriate permissions 
+
+ -- Matthew Exon   Tue, 14 May 2019 12:12:44 +
+
 icecc (1.2-1) unstable; urgency=medium
 
   [ Pino Toscano ]
diff -Nru icecc-1.2/debian/icecc.conf icecc-1.2/debian/icecc.conf
--- icecc-1.2/debian/icecc.conf 2018-12-21 07:52:33.0 +
+++ icecc-1.2/debian/icecc.conf 2019-05-14 12:12:44.0 +
@@ -8,7 +8,7 @@
 # icecc daemon log file
 #
 # ICECC_LOG_FILE="/var/log/iceccd.log"
-ICECC_LOG_FILE="/var/log/iceccd.log"
+ICECC_LOG_FILE="/var/log/icecc/iceccd.log"
 
 #
 # Identification for the network the scheduler and daemon run on.
@@ -47,7 +47,7 @@
 # icecc scheduler log file
 #
 # ICECC_SCHEDULER_LOG_FILE="/var/log/icecc_scheduler.log"
-ICECC_SCHEDULER_LOG_FILE="/var/log/icecc_scheduler.log"
+ICECC_SCHEDULER_LOG_FILE="/var/log/icecc/icecc_scheduler.log"
 
 #
 # If the daemon can't find the scheduler by broadcast (e.g. because
diff -Nru icecc-1.2/debian/icecc.iceccd.default 
icecc-1.2/debian/icecc.iceccd.default
--- icecc-1.2/debian/icecc.iceccd.default   1970-01-01 00:00:00.0 
+
+++ icecc-1.2/debian/icecc.iceccd.default   2019-05-14 12:12:44.0 
+
@@ -0,0 +1,7 @@
+# /etc/default/icecc
+
+# Defaults for icecc initscript.  This file is sourced by
+# /bin/sh from /etc/init.d/iceccd
+
+# Options to pass to iceccd
+#ICECCD_OPTS=
diff -Nru icecc-1.2/debian/icecc.iceccd.init icecc-1.2/debian/icecc.iceccd.init
--- icecc-1.2/debian/icecc.iceccd.init  2018-12-21 07:52:33.0 +
+++ icecc-1.2/debian/icecc.iceccd.init  2019-05-14 12:12:44.0 +
@@ -12,7 +12,7 @@
 
 DAEMON=/usr/sbin/iceccd
 CONFIGFILE=/etc/icecc/icecc.conf
-DEFAULTFILE=/etc/default/icecc
+DEFAULTFILE=/etc/default/iceccd
 
 # Read configuration files
 [ -r $CONFIGFILE ] && . $CONFIGFILE
@@ -59,7 +59,7 @@
fi
 
start-stop-daemon --start --quiet --exec $DAEMON -- \
-   -d $logfile $nice $scheduler $netname -u icecc $basedir $maxjobs 
$noremote
+   -d $logfile $nice $scheduler $netname -u icecc $ICECCD_OPTS $basedir 
$maxjobs $noremote
 }
 
 stop_icecc_daemon() {
diff -Nru icecc-1.2/debian/icecc.icecc-scheduler.default 
icecc-1.2/debian/icecc.icecc-scheduler.default
--- icecc-1.2/debian/icecc.icecc-scheduler.default  1970-01-01 
00:00:00.0 +
+++ icecc-1.2/debian/icecc.icecc-scheduler.default  2019-05-14 
12:12:44.0 +
@@ -0,0 +1,7 @@
+# /etc/default/icecc
+
+# Defaults for icecc initscript.  This file is sourced by
+# /bin/sh from /etc/init.d/icecc-scheduler
+
+# Options to pass to icecc-scheduler
+#ICECC_SCHEDULER_OPTS=
diff -Nru icecc-1.2/debian/icecc.icecc-scheduler.init 
icecc-1.2/debian/icecc.icecc-scheduler.init
--- icecc-1.2/debian/icecc.icecc-scheduler.init 2018-12-21 07:52:33.0 
+
+++ icecc-1.2/debian/icecc.icecc-scheduler.init 2019-05-14 12:12:44.0 
+
@@ -12,7 +12,7 @@
 
 SCHEDULER=/usr/sbin/icecc-scheduler
 CONFIGFILE=/etc/icecc/icecc.conf
-DEFAULTFILE=/etc/default/icecc
+DEFAULTFILE=/etc/default/icecc-scheduler
 
 # Read configuration files
 [ -r $CONFIGFILE ] && . $CONFIGFILE
@@ -36,7 +36,7 @@
: > $ICECC_SCHEDULER_LOG_FILE
chown icecc $ICECC_SCHEDULER_LOG_FILE
start-stop-daemon --start --quiet --chuid icecc \
-   --exec $SCHEDULER -- -d $logfile $netname
+   --exec $SCHEDULER -- $ICECC_SCHEDULER_OPTS -d $logfile $netname
 }
 
 stop_icecc_scheduler() {
diff -Nru icecc-1.2/debian/icecc.logrotate icecc-1.2/debian/icecc.logrotate
--- icecc-1.2/debian/icecc.logrotate2018-12-21 07:52:33.0 +
+++ icecc-1.2/debian/icecc.logrotate2019-05-14 12:12:44.0 +
@@ -7,7 +7,9 @@
 
 /var/log/iceccd.log {
missingok
-   

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Paul Wise]

Control: notforwarded -1
 
On Tue, 2019-05-14 at 14:36 +0530, Ritesh Raj Sarraf wrote:

> I submitted this fix upstream to the kernel some time ago. I don't
> recollect if the 4.19 kernel is what had it included.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9ca19a3a3e2482916c475b90f3d7fa2a03d8e5ed

That patch is already applied in the Debian user-mode-linux package:

debian/patches/fix-port-helper-path.patch

I noticed that the path embedded in the binary has an extra slash in it
compared to what the patch changes it to so I think the problem is that
the OS_LIB_PATH variable isn't defined correctly on amd64.

There seems to be some sort of confusion about the CONFIG_64BIT var but
it seems like the paths and variables in the sources are correct so I'm
not sure what is going on.

BTW, is it possible to do source-only uploads so that the build logs
are available on amd64, or do the versioned binaries mean no logs? If
so I think it would be good to only upload i386 binary packages so that
we get the build logs for the most used architecture.

~/linux-4.19.37 $ grep -rC1 OS_LIB_PATH 
arch/um/drivers/xterm.c-char *argv[] = { terminal_emulator, 
title_switch, title, exec_switch,
arch/um/drivers/xterm.c: OS_LIB_PATH 
"/uml/port-helper", "-uml-socket",
arch/um/drivers/xterm.c- file, NULL };
--
arch/um/include/shared/os.h-#ifdef CONFIG_64BIT
arch/um/include/shared/os.h:#define OS_LIB_PATH "/usr/lib64/"
arch/um/include/shared/os.h-#else
arch/um/include/shared/os.h:#define OS_LIB_PATH "/usr/lib/"
arch/um/include/shared/os.h-#endif
--
arch/um/os-Linux/main.c-
arch/um/os-Linux/main.c:#define UML_LIB_PATH":" OS_LIB_PATH "/uml"
arch/um/os-Linux/main.c-

~/user-mode-linux-4.19-1um $ grep -r CONFIG_64BIT
config.i386:# CONFIG_64BIT is not set
config.amd64:CONFIG_64BIT=y

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ben Hutchings]

On Tue, 2019-05-14 at 18:13 +0530, Ritesh Raj Sarraf wrote:
> On Tue, 2019-05-14 at 10:45 +0100, Ben Hutchings wrote:
> > > Irrespective, I think it is a fair candidate to be backported if
> > 4.19
> > > missed that window. For User-Mode-Linux, The sources are the same
> > that
> > > the Debian Linux kernel team maintains. So either they could pick
> > this
> > > commit as a patch  or else I'll try to look into it soon.
> > [...]
> > 
> > Can you please send this request to sta...@vger.kernel.org as well?
> 
> Thanks for the suggestion Ben.
> 
> The fix for this bug is now queued for the 4.19 stable tree. So soon,
> this fix will show up in the Debian Linux kernel package too. That is
> when we can trigger a rebuild of user-mode-linux package and then mark
> this bug fixed.
> 
> Debian Buster already has the dependency set correct to the 4.19
> kernel. Wishfully it would be much nicer if this whole process of the
> build could be automated to trigger periodically, or trigger on every
> upload of the linux-source package.

Does user-mode-linux need to be a separate source package at all?

It might be difficult to integrate it with the linux source package, as
we currently assume a strict separation between kernel and userland
binary packages, but it is probably possible to do.  Something to
consider for the bullseye release cycle.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.




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

Bug#923053: python3-stem: Version in stretch-backport isn't installable

[user]

Package: python3-stem
Followup-For: Bug #923053

python3-distutils is not needed since version 1.7.0

Bug#928979: nvidia-legacy-390xx-driver: fails to launch GDM

[Arnaud Mounier]

Package: nvidia-legacy-390xx-driver
Version: 390.116-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I install the nvidia legacy package (nvidia-legacy-390xx-driver) instead of
nouveau driver

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I just install the legacy package

   * What was the outcome of this action?
the installing package process goes normally, build the
initrd.img-4.19.0-5-amd64 image and install it in the /boot repo.

But when I restart the computer and for every starting process, the systemd
starting process hangs on with the message :
[OK] starting Gnome Display Manager
resuming from hibernation

I have to use Alt-Ctrl F2 and Alt-Ctrl F1 to launch GDM

   * What outcome did you expect instead?

I expected that systemd launch GDM automatically



-- Package-specific info:
uname -a:
Linux anesidora 4.19.0-5-amd64 #1 SMP Debian 4.19.37-1 (2019-05-05) x86_64 
GNU/Linux

/proc/version:
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-1 (2019-05-05)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  390.116  Sun Jan 27 07:21:36 
PST 2019
GCC version:  gcc version 8.3.0 (Debian 8.3.0-7) 

lspci 'display controller [030?]':
0f:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF100GL [Quadro 
4000] [10de:06dd] (rev a3) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company GF100GL [Quadro 4000] [103c:0780]
Physical Slot: 2
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 May 14 11:40 /dev/dri/card0
crw-rw+ 1 root render 226, 128 May 14 11:40 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 May 14 11:40 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 May 14 11:40 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 May 14 11:40 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 May 14 11:40 pci-:0f:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 May 14 11:40 pci-:0f:00.0-render -> ../renderD128
video:x:44:arnome

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 May 14 11:31 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   51 May 14 11:31 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   50 May 14 11:31 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 May 14 11:31 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   57 May 14 11:31 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 May 14 11:31 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   54 May 14 11:31 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 May 14 11:31 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   44 May 14 11:31 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root   44 May 14 11:31 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root   51 May 14 11:31 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 May 14 11:31 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 May 14 11:31 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 May 14 11:31 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 May 14 11:31 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 May 14 11:31 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 May 14 11:31 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 May 14 11:31 

Bug#928931: debian-installer: apt-setup/local0/key fails on buster because gnupg is not installed

[Cyril Brulebois]

Hi,

Mikko Tuumanen  (2019-05-13):
> Package: debian-installer
> Severity: normal
> 
> Dear Maintainer,
> 
> I tried to preseed Debian buster with
> 
> d-i apt-setup/local0/repository string http://foo/ buster bar
> d-i apt-setup/local0/key string http://foo/key
> d-i pkgsel/include string baz
> 
> and used netboot "linux" and "initrd.gz" dated 2019-04-10.
> 
> This caused
> 
> May 13 06:34:21 main-menu[300]: (process:30688): 2019-05-13 06:34:18
> URL:http://foo/key [2448/2448] -> "/target/tmp/_fetch-url_key0.pub.31236" [1]
> May 13 06:34:21 main-menu[300]: (process:30688): E: gnupg, gnupg2 and gnupg1 
> do
> not seem to be installed, but one of them is required for this operation
> 
> and later package baz was not found which stopped the installation.

Right, I had been meaning to take care of it, but this special use case
had way lower priority than other issues…

> Work-around:
> 
> d-i preseed/late_command string in-target /bin/bash -c "\
> wget -O /etc/foo.asc http://foo/key ;\
> echo 'deb [signed-by=/etc/foo.asc] http://foo/ buster bar'
> /etc/apt/sources.list ;\
> apt update ;\
> apt -y install baz"

I seem to remember having seen some discussion regarding how to detect
binary or armoured keys; maybe a cheap(er) fix would be to make sure we
install the needed gnupg bits into /target when such a setting 
(apt-setup/local*/key) is detected?

See generators/60local in apt-setup.


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


signature.asc
Description: PGP signature

Bug#928973: Processed: Re: snapshot.debian.org: internal server error (Error 500)

[Peter Palfrader]

severity 928973 normal
close 928973
thanks

On Tue, 14 May 2019, Debian Bug Tracking System wrote:

> > severity -1 grave

> Bug #928973 [snapshot.debian.org] snapshot.debian.org: internal server error 
> (Error 500)
> Severity set to 'grave' from 'important'

This is snapshot being overloaded by people pointing their CI at it, by
jigdo using it as it primary backends, and other abuses.

We are, in our limited time, trying to keep it working, but we don't
always succeed.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

On Tue, 2019-05-14 at 10:45 +0100, Ben Hutchings wrote:
> > Irrespective, I think it is a fair candidate to be backported if
> 4.19
> > missed that window. For User-Mode-Linux, The sources are the same
> that
> > the Debian Linux kernel team maintains. So either they could pick
> this
> > commit as a patch  or else I'll try to look into it soon.
> [...]
> 
> Can you please send this request to sta...@vger.kernel.org as well?

Thanks for the suggestion Ben.

The fix for this bug is now queued for the 4.19 stable tree. So soon,
this fix will show up in the Debian Linux kernel package too. That is
when we can trigger a rebuild of user-mode-linux package and then mark
this bug fixed.

Debian Buster already has the dependency set correct to the 4.19
kernel. Wishfully it would be much nicer if this whole process of the
build could be automated to trigger periodically, or trigger on every
upload of the linux-source package.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#928978: d-s-s: avoid code duplication in postinst and hook

[Holger Levsen]

package: debian-security-support
severity: wishlist
x-debbugs-cc: gitlab+5e74195596a3e5490bb9e119f75e9...@salsa.debian.org, 
guil...@debian.org

On Tue, May 14, 2019 at 12:44:09PM +, Guillem Jover wrote:
> > +##
> > +##
> > +# WARNING: if you modify code here, you probably also need to modify #
> > +#  ../check-support-status.hook  #
> > +##
> > +##
> Perhaps a better way would be to give the hook a nice name and then call that 
> from both the dpkg hook and the postinst, to avoid duplication. At the time 
> it gets called in both cases, whatever file it is in, will have been unpacked 
> already.

indeed. I'm just over my quota for work on d-s-s for this month already
;)


-- 
tschau,
Holger

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

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature

Bug#928863: debian-installer: Add support for NanoPi NEO2

[Cyril Brulebois]

Hi Domenico,

Domenico Andreoli  (2019-05-12):
>   please consider adding the generation of the installer image file
> for FriendlyArm NanoPi NEO 2. MR is available on Salsa:
> 
> https://salsa.debian.org/installer-team/debian-installer/merge_requests/9

At first glance, that looks good to me.

> I was not able to cross-build the arm64 installer from amd64 so the
> patch is not tested.

I suppose we could merge this and let you test and report what happens
with daily builds. Would that be fine with you?

> Please mind that the NanoPi NEO 2 target for u-boot has just been
> merged in sid so it's not yet in Buster.

I see that Vagrant already spotted the needed bump to Build-Depends. :)

That shouldn't stop us from merging your work right now, I can always
hint u-boot into buster, should we need it; but thanks for mentioning it
anyway!


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


signature.asc
Description: PGP signature

Bug#928068: ruby2.5: FTBFS on ia64 due to segfault

[Antonio Terceiro]

On Tue, May 14, 2019 at 09:06:15AM +0200, John Paul Adrian Glaubitz wrote:
> Hello Antonio!
> 
> On 4/27/19 2:00 PM, James Clarke wrote:
> > Currently, ruby2.5 FTBFS, segfaulting when building documentation.
> > Please include the above patch applied[1] upstream (currently only to
> > trunk) to fix this.
> 
> Would you mind including this patch in the next upload?
> 
> It's just a one-liner which removes one line of code which is also
> ia64-specific.

Yes. I included it in the git repository, and will upload again after
the upload from yesterday reaches testing.

It would be nice if you could build from git master and confirm that all
goes well; I would have done it myself but there is no ia64 porterbox
listed in the Debian LDAP.


signature.asc
Description: PGP signature

Bug#928977: e2fsprogs: e2scrub_all cron job complains about lack of lvm2

[Jon]

Package: e2fsprogs
Version: 1.45.1-1
Severity: normal

After the latest upgrade of e2fsprogs I started getting email from cron
about lvm2 not being installed:

Subject: Cron  test -e /run/systemd/system || /sbin/e2scrub_all
-A -r

e2scrub_all: can't find lvcreate --- is lvm2 installed?


Since lvm2 is not a dependency of e2fsprogs this cron job should not
trigger an email if it is not installed.

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

Kernel: Linux 4.19.0-5-amd64 (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 /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcom-err2  1.45.1-1
ii  libext2fs2   1.45.1-1
ii  libss2   1.45.1-1
ii  libuuid1 2.33.1-0.1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-25

-- no debconf information

Bug#928972: unblock: debian-security-support/2019.05.14

[Holger Levsen]

On Tue, May 14, 2019 at 12:11:41PM +0200, Holger Levsen wrote:
> +  * postinst and check-support-status.hook: add code to create the d-s-s
> +user's home directory if it doesn't exist, as schroot copies /etc/passwd
> +from the host without creating the user home directories. Closes: 
> #928204.
> +Thanks to Santiago Vila.
> 
> Here I decided to also add this code to check-support-status.hook to be on
> the safe side. I believe this is not needed but let's be safe now.
> (Cleaning this up for bullseye is tracked via #928968.)

as you can read in #928968 it was good to stay on the safe side and to
add the relevant code to check-support-status.hook, so that I have
improved the code comments in git further (see
https://salsa.debian.org/debian/debian-security-support/commit/db4096368c49002cfb413d8a9dabb2afffb39f39
if you care about the details) and closed #928968.

tl;dr: debian-security-support 2019.05.14 is still good for buster as it
is.


-- 
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#748207: It's not going to be fixed

[Changwoo Ryu]

Control: tags -1 + wontfix

"Fixing" this bug in Debian doesn't really make any sense. This
function just exists in the source code and is not even called.

Bug#928976: ca-certificates-java - Stretch backport for JDK11

[Schmidt, Christian]

Package: ca-certificates-java
Version: 20190405

Hello,

I’m using OpenJDK 11 form Stretch backports and have problems updating the ca 
certificates.

The Update routine in /etc/ca-certificates/update.d/jks-keystore only considers 
JDK 7/8/9 as valid options.

for jvm in java-7-openjdk-$arch java-7-openjdk \
   oracle-java7-jre-$arch oracle-java7-server-jre-$arch 
oracle-java7-jdk-$arch \
   java-8-openjdk-$arch java-8-openjdk \
   oracle-java8-jre-$arch oracle-java8-server-jre-$arch 
oracle-java8-jdk-$arch \
   java-9-openjdk-$arch java-9-openjdk \
   oracle-java9-jre-$arch oracle-java9-server-jre-$arch 
oracle-java9-jdk-$arch; do

best regards,
Christian
[cid:NC_LOGO_SIGNATUR.png@0BEF9728.0001]
Christian Schmidt
Content Delivery Server & Dienste

NetCologne Gesellschaft für Telekommunikation mbH
Am Coloneum 9 - 50829 Köln
tel: 0221 -5257  - fax: 0221 -75257


www.netcologne.koeln 

Geschäftsführung: Timo von Lepel
Vorsitzender des Aufsichtsrates: Dr. Andreas Cerbe
HRB 25580, AG Köln





Diese Nachricht (inklusive aller Anhänge) ist vertraulich. Sollten Sie diese 
Nachricht versehentlich erhalten haben, bitten wir, den Absender (durch 
Antwort-E-Mail) hiervon unverzüglich zu informieren und die Nachricht zu 
löschen. Die E-Mail darf in diesem Fall weder vervielfältigt noch in anderer 
Weise verwendet werden.

Bug#928975: seafile: copyright concerns

[Jan-Henrik Haukeland]

Source: seafile
Version: 6.2.11-1

We ask Debian to consider removing and stop distributing Seafile packages [1]  
due to copyright concerns. 

Background: 
-

Seafile is an open-source dropbox clone created by a team from China. Around 
2013 they needed MySQL and PostgreSQL support and started using our open-source 
database connection pool library, libzdb [2].  

In 2014 a push was made to include Seafile in Debian and a discussion about 
copyright concerns in Seafile started on GitHub [3]. Libzdb played a role in 
this discussion and one of the results were that Seafile in 2016 removed the 
dependency on libzdb and stated that “we completely replaced libzdb with our 
own code.” [4] Seafile has since been included in Debian [1].

Concern:


We later discovered that the code that replaced libzdb is mostly a copy of 
libzdb's code and structures. This stand in contrast to the statement “we 
completely replaced libzdb with our own code.”  [4]

Libzdb is licensed under GPLv3. Copying and modifying GPL code is perfectly 
fine as long as the original copyright notice and license are kept. 
Unfortunately, this is not what the Seafile team did. Instead they copied code 
from libzdb, removed the copyright notice, claimed the code as their own and 
re-license it under another license. 

Evidence: 
-

To do a side by side comparison I’m going to use Seafile’s version of libzdb 
which they forked on GitHub [6] at version 2.11.1 and based their new code on 
and claimed as their own [5]. The comparison is going to be against our same 
version on Bitbucket. 

Libzdb is a database connection pool library which consists of 4 major 
components: ConnectionPool, Connection, ResultSet and PreparedStatement. 
Forward declared data structures are used to abstract the concrete database 
implementation. These components together with their method association are 
quite unique for a _C_ database connection pool library as far as I know. The 
Seafile "rewrite" uses the exact same components and method association between 
components with modest renaming. Mostly by going from camel-case to snake-case.

I’m going to limit the comparison somewhat for brevity, but it should be enough 
to demonstrate copyright concern. The full comparison can be done by comparing 
[5] and [7]. 


1. The Connection Pool has two significant methods:

- Get a connection from the pool

a:libzdb: 
https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/ConnectionPool.c#lines-314

a:seafile: 
https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/db-wrapper.c#L180

- And return a connection to the pool

b:libzdb: 
https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/ConnectionPool.c#lines-345

b:seafile: 
https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/db-wrapper.c#L220

Apart from Seafile using glib array and libzdb using its own vector module the 
above demonstrate copy of code with the same logic, method and variable names. 
Libzdb’s Connection_setAvailable is equal to their conn->is_available = FALSE; 
And our LOCK macro is just pthread_mutex_lock. I.e. the same code and logic, 
just expanded and inlined. 


2. Connection

In libzdb a Connection has three significant  methods, Connection_execute, 
Connection_executeQuery and Connection_prepareStatement. Seafile has the same 
methods implemented in the same way

a:libzdb: 
https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/Connection.c#lines-308

a:seafile: 
https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/db-wrapper.c#L258

b:libzdb: 
https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/Connection.c#lines-323

b:seafile: 
https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/db-wrapper.c#L350

Seafile has not copied all methods from libzdb’s Connection, but 
Connection_ping is is there as well as Connection_beginTransaction, 
Connection_rollback and Connection_commit

c:libzdb: 
https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/Connection.c#lines-228

c:seafile: 
https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/db-wrapper.c#L241

What is special about our transaction code in libzdb is that we keep a counter 
called “isInTransaction” which Seafile has as “in_transaction”. 

d:libzdb: 
https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/Connection.c#lines-252

d:seafile: 
https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/db-wrapper.c#L424


3. ResultSet and PreparedStatment are also clearly copied from libzdb. We 

Bug#928968: debian-security-support: cleanup cruft in check-support-status.hook after the buster release

[Guillem Jover]

Hi!

On Tue, 2019-05-14 at 11:29:04 +0200, Holger Levsen wrote:
> Package: debian-security-support
> Version: 2019.02.02
> Severity: minor

> check-support-status.hook contains code (copied from postinst) to create
> the d-s-s user, which (I believe) is useless as the user is created in 
> postinst
> anyway and this hook will only be run after postinst.

The hook is called always after a dpkg run, but those runs can be for
any dpkg command. In addition the hook cannot control how dpkg was
called. So the following could easily happen for example:

  run 0
  unpack \
debian-security-support \
libfoo \
libbar \
# EOL
  post-invoke hook

  run 1
  configure \
libfoo \
libbar \
# EOL
  post-invoke hook

  run 2
  configure \
debian-security-support
# EOL
  post-invoke hook


And only on the last one the user would have already been created.
Restricting the action via DPKG_HOOK_ACTION == configure, would not
help much either as it would strip over the above scenario.

> we should clean this up after the release of buster.

I'm not sure this is feasible, given the way this package currently
works?

Thanks,
Guillem

Bug#924787: I would really like to see yubikey-personalization in buster

[Petter Reinholdtsen]

Note, the clock is ticking now, as yubikey-personalization is scheduled for 
removal
2019-06-12 because of this RC bug.

-- 
Happy hacking
Petter Reinholdtsen

Bug#927348: unblock: salt/2018.3.4+dfsg1-2

[Benjamin Drung]

Hi Paul,

Am Freitag, den 10.05.2019, 20:40 +0200 schrieb Paul Gevers:
> Control: tags -1 moreinfo
> 
> So, all in all, I don't want to unblock the new upstream with your
> packaging, we're too late in the cycle and the version really doesn't
> match the freeze policy. However, I am offering you an upload based
> on the version currently in buster via t-p-u. If you go that route,
> please only fix bugs 919849, 928337, 922352, 924763, the
> LC_ALL=C.UTF-8 item and the systemd issue. Please fix 919849 without
> switching your build to sphinxdoc, that isn't appropriate at this
> moment.

Okay. So you prefer an upload to t-p-u or can I just revert those
rejected changes (typos fixes and using dh_sphinxdoc) and do another
upload to unstable?

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Tue, 14 May 2019 at 03:57:46 +0200, Steffen Ullrich wrote:
>> Ah I see, thanks for the clarification.  I thought you meant it could
>> yield a deadlock.  Aren't temporary failures also possible on plain
>> sockets (though of course the extra SSL layer make it strictly more
>> likely to happen)?  IIRC if the checksum of the incoming packet
>> mismatches, which causes the read() call to block until the packet is
>> retransmitted.
> 
> select only shows an fd ready  if data are available for read in the socket
> buffer. Data with wrong checksum are discarded by the kernel before they are
> put into the socket buffer and thus don't cause select to show it ready for
> read.
> 
> select(2) explicitly says:
> 
> A file descriptor is considered ready if it is possible to perform a
> corresponding I/O operation (e.g., read(2)  without blocking ...

Hmm, however in the “Bugs” sections, it says it's in fact not the case, and
that non-blocking I/O should be used to avoid temporary failures:

Under Linux, select() may report a socket file descriptor as "ready for
reading", while nevertheless a subsequent read blocks.  This could for
example happen when data has arrived but upon examination has wrong
checksum and is discarded.  There may be other circumstances in which a
file descriptor is spuriously reported as ready.  Thus it may be safer to
use O_NONBLOCK on sockets that should not block.
 
>>> And while using blocking I/O with polling sockets might be fine with plain
>>> sockets where each byte is part of application data it is not fine with SSL
>>> since the unit in SSL is not a byte but a record and some records might
>>> contain application data and some not.
>>
>> Why is that not fine, if the SSL_read() caller is ready for that (documented)
>> outcome, and doesn't assume that the call will always block until some
>> application data is received?
> 
> IO::Socket::SSL is intended as abstraction which behaves as much as possible
> as other IO::Socket classes. It is not intended that the developer has to be
> familiar with the exact semantics of SSL_read (which also changed over
> time, especially with OpenSSL 1.1.0 and again with OpenSSL 1.1.1). While it
> is impossible to behave in exactly all cases sysread is usually not expect
> to return a temporary error on a blocking socket.
> […]
> Yes, the intention was to reflect as much as possible what is expected from
> IO::Socket::sysread and not what the SSL_read documentation says.

Fair enough.  Then it sounds like you'd want to set SSL_MODE_AUTO_RETRY
explicitly and not rely on the OpenSSL old or new defaults :-)  (Or loop in
Perl if support for OpenSSL that are two decades old is desired.)

For what it's worth, I interpreted

Also, calls to sysread might fail, because it must first finish an SSL
handshake.
To understand these behaviors is essential, if you write applications
which use event loops and/or non-blocking sockets.

from the sysread() documentation as an invitation to read the low-level
documentation and see what SSL_read() may return, also with blocking I/O :-)
(After all since sysread() will never block if there is some unprocessed data
left in the current SSL frame, that's already a hint that this sysread() has
some peculiarities that are not found in the version with plain sockets.)  The
new documentation clarifies a bit the expectation, thanks!  But I guess it
would be clearer if the paragraphs I quoted above were explicitly said
to only apply to non-blocking I/O.

Also isn't the workaround you implemented earlier

“deal with OpenSSL 1.1.1 switching on SSL_AUTO_RETRY by default by 
disabling it when non-blocking”

https://github.com/noxxi/p5-io-socket-ssl/commit/09bc6a3203bc7bc89078317da42a3e96cdbf94fc

a no-op?  AFAICT setting SSL_MODE_AUTO_RETRY avoids SSL_read() returning
SSL_ERROR_WANT_READ when a non-application data record is received, and
instead makes it block until application data is received.  For non-blocking
I/O however, SSL_read() will of course never block and may — regardless of
whether SSL_MODE_AUTO_RETRY is set — return SSL_ERROR_WANT_{READ,WRITE}.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928973: snapshot.debian.org: internal server error (Error 500)

[Vincent Lefevre]

Control: severity -1 grave

Raising the severity since the packages are themselves affected by
the internal errors, making the service impossible to use.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#928974: Vinagre crash with white screen after canceling the RDP session before signing in

[Sauer Jochen]

Package: Vinagre

Version: 3.22.0
 
Debian Buster Testing (2019-05-06)
 

When Vinagre starts an RDP connection and you quit before entering the user
and password, the screen turns completely white.

Now no keyboard shortcut works anymore. Neither Alt + F4 to exit, nor F11 to
exit the Vinagre full screen.

 

 

Viele Grüße

Jochen Sauer 

 

Bug#928973: snapshot.debian.org: internal server error (Error 500)

[Vincent Lefevre]

Package: snapshot.debian.org
Severity: important

I sometimes get internal server errors (Error 500) on various
snapshot.debian.org URLs, e.g.

  https://snapshot.debian.org/package/fontconfig/

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

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

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Tobias Eliasson]

Den tis 14 maj 2019 kl 11:14 skrev Vincent Lefevre :

>
> (BTW, the bug did not appear to be fixed according to the fontconfig
> changelog, but the changelog does not actually seem to be up-to-date!)
>
> I narrowed it down to commit 34b5c949d51fcc8eafe2301ca8f539f735e31522
upstream at fontconfig which solves this issue.
See
https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/34b5c949d51fcc8eafe2301ca8f539f735e31522
for more information.

Bug#927726: wlroots: Please upload new upstream version

[iskrenx2]

Hello, how can I help this gets into the experimental repo and unblock Sway
1.0 final? 


What needs to be done ? 


Thank you.


-

П.П. Разбра ли, че Яна щала да си прави сайт? Яна, от онази реклама. Виж сайт 
билдъра на СуперХостинг.БГ, за да си направиш сайт и ти.
 
https://www.superhosting.bg/site-builder.php?utm_source=mbg_medium=cpm_content=mail_footer_campaign=newuser_campaign2019

Bug#928972: unblock: debian-security-support/2019.05.14

[Holger Levsen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
x-debbugs-cc: sanv...@unex.es

Please unblock package debian-security-support, it fixes two RC bugs.

Attached is the debdiff against 2019.04.25 which is not in testing but
has been unblocked by Niels via #926397.

unblock debian-security-support/2019.05.14

The changelog explained:

+  * check-support-status.in: don't fail if security-support-ended.debX does
+not exist for the release d-s-s is running on. Closes: #927450.

For this I just replaced 'exit 1' with 'exit 0'...

+  * postinst and check-support-status.hook: add code to create the d-s-s
+user's home directory if it doesn't exist, as schroot copies /etc/passwd
+from the host without creating the user home directories. Closes: #928204.
+Thanks to Santiago Vila.

Here I decided to also add this code to check-support-status.hook to be on
the safe side. I believe this is not needed but let's be safe now.
(Cleaning this up for bullseye is tracked via #928968.)

+  * d/control: set myself as maintainer to formally adopt the package and drop
+Christoph Biedl on his request. Many thanks for creating this package and
+maintaining it, Christoph!


-- 
tschau,
Holger

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

Some people say that the climate crisis  is something that we all have created,
but  that is not true,  because if everyone is guilty  then no one is to blame.
And someone is to blame.  Some people, some companies,  some decision-makers in
particular, have known exactly what priceless values they have been sacrificing
to continue making unimaginable amounts of money.
diff -Nru debian-security-support-2019.04.25/check-support-status.hook debian-security-support-2019.05.14/check-support-status.hook
--- debian-security-support-2019.04.25/check-support-status.hook	2019-04-25 11:24:00.0 +0200
+++ debian-security-support-2019.05.14/check-support-status.hook	2019-05-14 11:36:45.0 +0200
@@ -4,6 +4,8 @@
 #%# License: GPL-2.0-only
 
 # This codes duplicates "postinst configure"
+# 20190514: but why? and why all of it, eg the user creation?
+# FIXME: we should drop this after the Buster release, this is tracked as #928968.
 
 set -e
 
@@ -23,6 +25,12 @@
 "$USERNAME"
 fi
 
+# needed for schroots which copy /etc/passwd from the host
+if [ ! -d "$LIB_DIR" ]; then
+mkdir "$LIB_DIR"
+chown $USERNAME:$USERNAME "$LIB_DIR"
+fi
+
 if [ "$TMPDIR" ] && [ "$(stat --format=%a "$TMPDIR")" != '1777' ] ; then
 export TMPDIR='/tmp'
 fi
diff -Nru debian-security-support-2019.04.25/check-support-status.in debian-security-support-2019.05.14/check-support-status.in
--- debian-security-support-2019.04.25/check-support-status.in	2019-04-25 11:20:34.0 +0200
+++ debian-security-support-2019.05.14/check-support-status.in	2019-05-13 21:14:22.0 +0200
@@ -22,7 +22,7 @@
 
 if [ "$DEBIAN_VERSION" -lt "$DEB_LOWEST_VER_ID" ] || [ "$DEBIAN_VERSION" -gt "$DEB_NEXT_VER_ID" ] ; then
 eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values from \$DEB_LOWEST_VER_ID and \$DEB_NEXT_VER_ID"; echo
-exit 1
+exit 0
 fi
 
 LIST=
diff -Nru debian-security-support-2019.04.25/debian/changelog debian-security-support-2019.05.14/debian/changelog
--- debian-security-support-2019.04.25/debian/changelog	2019-04-25 11:36:54.0 +0200
+++ debian-security-support-2019.05.14/debian/changelog	2019-05-14 11:48:37.0 +0200
@@ -1,3 +1,17 @@
+debian-security-support (2019.05.14) unstable; urgency=medium
+
+  * check-support-status.in: don't fail if security-support-ended.debX does
+not exist for the release d-s-s is running on. Closes: #927450.
+  * postinst and check-support-status.hook: add code to create the d-s-s
+user's home directory if it doesn't exist, as schroot copies /etc/passwd
+from the host without creating the user home directories. Closes: #928204.
+Thanks to Santiago Vila.
+  * d/control: set myself as maintainer to formally adopt the package and drop
+Christoph Biedl on his request. Many thanks for creating this package and
+maintaining it, Christoph!
+
+ -- Holger Levsen   Tue, 14 May 2019 11:48:37 +0200
+
 debian-security-support (2019.04.25) unstable; urgency=medium
 
   * Team upload.
diff -Nru debian-security-support-2019.04.25/debian/control debian-security-support-2019.05.14/debian/control
--- debian-security-support-2019.04.25/debian/control	2019-04-20 16:17:12.0 +0200
+++ debian-security-support-2019.05.14/debian/control	2019-05-14 11:42:09.0 +0200
@@ -1,7 +1,7 @@
 Source: debian-

Bug#403369: initscripts: boot messages not displayed on serial console with bootlogd enabled

[Paul Slootman]

On Tue 14 May 2019, Dmitry Bogatov wrote:
> 
> Seems things changed for 13 years. I just set up virtual machine with
> following kernel options:
> 
>   console=tty0 console=ttyS0,9600n
> 
> and runit with "kvm -serial file:serial". When it booted content of
> /var/log/boot in VM and "serial" on host was same -- both listed events
> up to openssh service.
> 
> So, seems I need more information and guidance to debug this issue.

You do have bootlogd installed?
I would suggest removing the "console=tty0" as this happened on a system
with only serial, no display.

However, as that system has since been recycled, I can't reproduce it
either anymore, so I suggest that the bug may be closed as far as I am
concerned.


Thanks,
Paul

Bug#928971: ITS: libgit2

[Jongmin Kim]

Source: libgit2
Version: 0.27.7+dfsg.1-0.1
Severity: important

Dear Russell (and relevant maintainer of libgit2 package in Debian),

The package 'libgit2' appears to be unmaintained by listed Maintainer.
The last upload by the listed Maintainer seems July 29, 2017 (2 years
ago). After that it was for a long time maintained with NMUs.

After checking the qualification criteria, I am filing this Intent To
Salvage (ITS) bug, following the process outlined in:

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging

For reference:

> After the 21 days delay, if no answer has been sent to the bug [..]

... I'll make this on 4 June, 2019.

Thank you!


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#928966: heimdal: CVE-2018-16860

[Salvatore Bonaccorso]

Hi Brian,

On Tue, May 14, 2019 at 06:11:05PM +1000, Brian May wrote:
> Salvatore Bonaccorso  writes:
> 
> > Source: heimdal
> > Version: 7.5.0+dfsg-2.1
> > Severity: important
> > Tags: security upstream
> > Control: found -1 7.1.0+dfsg-13+deb9u2
> > Control: found -1 7.1.0+dfsg-13
> >
> > Hi,
> >
> > The following vulnerability was published for heimdal, actually just
> > what is affecting samba embedded copy of heimdal.
> >
> > CVE-2018-16860[0]:
> > Samba AD DC S4U2Self/S4U2Proxy unkeyed checksum
> >
> > 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-2018-16860
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16860
> >
> > Please adjust the affected versions in the BTS as needed, all versions
> > starting from 0.8 upwards including 7.5.0 are affected.
> >
> > What is your take on this? Does this need a DSA or is an update via an
> > upcoming point release enough?
> 
> I am hardly authoritative on this, however my rough take right now is:
> 
> * There is a vulerability.
> * The fix is simple. Looking at the Samba patches, I suspect we only
>   need the bit that alters krb5tgs.c - below.
> * Not convinced this can actually be exploited without AD. It is
>   unlikely you would be using the stock Heimdal with AD. So possible
>   we don't need to worry.

Alright, I will mark it no-dsa for stretch then at least. For buster,
might be still good to have the fix go in?

Regards,
Salvatore

Bug#928827: libjs-jquery: Minified version of jquery.js (jquery.min.js) throws syntax error

[Christoph Weber]

Source: jquery
Version: 1.7.2+dfsg-3.2+deb8u6
Followup-For: Bug #928827

Hello,

I investigated this issue and believe the recent change
"Fix problem calling uglify during build." (related patch is
"fix_uglify_invocation.patch") leads to this issue. I guess
it was introduced in the security fix #927385. (The previous
version 1.7.2+dfsg-3.2 works fine after downgrade.)

The key to this issue is the following target in the Makefile:

${JQ_MIN}: ${JQ}
@@if test ! -z ${JS_ENGINE}; then \
echo "Minifying jQuery" ${JQ_MIN}; \
${COMPILER} < ${JQ} > ${JQ_MIN}.tmp; \
${POST_COMPILER} ${JQ_MIN}.tmp; \
rm -f ${JQ_MIN}.tmp; \
else \
echo "You must have NodeJS installed in order to minify 
jQuery."; \
fi

POST_COMPILER, namely post-compile.js, is a script which tries to
replace the first comment in ${JQ_MIN}.tmp with a version number.
The COMPILER, namely uglifyjs, removes all comments by default.
Therefore, the regex in post-compile.js matches some quoted
strings containing "/*" and "*/" and replaces a large section of
code with a version number.

The browser reacts with "nothing to repeat", as the breakage is
within a regex and the asterisk follows nothing appropriate.

There are multiple ways to fix it: Disable post-compile.js, fix
the regex to match only valid comments, or keep the first comment.
I'll add a patch to achieve the latter, because I like the initial
comment containing the version number.

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

Kernel: Linux 3.16.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
keep the first comment (post-compile.js needs and replaces it)
Index: jquery-1.7.2+dfsg/Makefile
===
--- jquery-1.7.2+dfsg.orig/Makefile
+++ jquery-1.7.2+dfsg/Makefile
@@ -6,7 +6,7 @@ PREFIX = .
 DIST_DIR = ${PREFIX}/dist
 
 JS_ENGINE ?= `which node 2>/dev/null || which nodejs 2>/dev/null`
-COMPILER = `which uglifyjs 2>/dev/null` --unsafe
+COMPILER = `which uglifyjs 2>/dev/null` --unsafe --comments /license/
 POST_COMPILER = ${JS_ENGINE} ${BUILD_DIR}/post-compile.js
 
 BASE_FILES = ${SRC_DIR}/core.js\

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ben Hutchings]

On Tue, 2019-05-14 at 14:36 +0530, Ritesh Raj Sarraf wrote:
> Control: tag -1 +fixed-upstream
> 
> CC: Adding Debian Kernel Maintainers
> 
> 
> Hello Paul,
> 
> I submitted this fix upstream to the kernel some time ago. I don't
> recollect if the 4.19 kernel is what had it included.

It went into 4.20 and hasn't been applied to 4.19-stable.

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9ca19a3a3e2482916c475b90f3d7fa2a03d8e5ed
> 
> Irrespective, I think it is a fair candidate to be backported if 4.19
> missed that window. For User-Mode-Linux, The sources are the same that
> the Debian Linux kernel team maintains. So either they could pick this
> commit as a patch  or else I'll try to look into it soon.
[...]

Can you please send this request to sta...@vger.kernel.org as well?

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.




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

Bug#928969: stterm: incorrect rendering of cyrillic letters with Terminus

[Dmitry Bogatov]

Package: stterm
Version: 0.8.2-1
Severity: normal

Dear Maintainer,

cyrillic letters in stterm with Terminus font are rendered as more wide
and overlapping than latin letters. On both "xterm" and under tty
cyrillic letters are rendered properly.

This issue is only with Terminus font: no other monospace font I checked
have such problems.

Please, try to reproduce it yourself. You will need:

 * xfonts-terminus
 * stterm
 * cyrillic text "Привет"

Start stterm:

$ stterm -f Terminus

and view cyrillic text in that terminal. If you want, I can make
screenshots.


pgpNnbmKG2voB.pgp
Description: PGP signature

Bug#624289: sysvinit-utils: bootlogd fails to start: ioctl TIOCGDEV: invalid argument

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2011-04-27 09:24] arno renevier 
> Package: sysvinit-utils
> Version: 2.88dsf-13.2
> Severity: normal
>
> Hi,
> bootlogd fails to start. I investigated with printf-debug, and found that
> ioctl(0, TIOCGDEV, ) fails and strerror(errno) is: "Invalid argument".
> Also, when removing the ioctl stuff, consolename is correctly found. Why not
> continue into the function even if ioctl fails ?
>
> Bootlogd worked fine until 13rd or 14th or 15th of april. And sysvinit-utils
> was not upgraded at that time. So, the bug may come from another package.

Sorry for late response. Can you reproduce issue on modern
installations?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#440709: patch: mount securityfs when it is available (Closes: #440709)

[Dmitry Bogatov]

control: tags 440709 +patch +pending

Here I refreshed patch:

From efedf38621a2a63fd193f1fa740c3a97ae8bee26 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Mon, 13 May 2019 15:18:41 +
Subject: [PATCH] Mount securityfs when it is available (Closes: #440709)

Thanks: Ritesh Raj Sarraf 
---
 debian/src/initscripts/etc/init.d/mountkernfs.sh | 4 
 debian/src/initscripts/etc/init.d/umountfs   | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/src/initscripts/etc/init.d/mountkernfs.sh 
b/debian/src/initscripts/etc/init.d/mountkernfs.sh
index e95cac3a..8f2b20a8 100755
--- a/debian/src/initscripts/etc/init.d/mountkernfs.sh
+++ b/debian/src/initscripts/etc/init.d/mountkernfs.sh
@@ -34,6 +34,10 @@ mount_filesystems () {
#
domount "$MNTMODE" proc "" /proc proc "-onodev,noexec,nosuid"
 
+   if grep -E -qs "securityfs\$" /proc/filesystems ; then
+   domount securityfs "" /sys/kernel/security securityfs
+   fi
+
#
# Mount sysfs on /sys
#
diff --git a/debian/src/initscripts/etc/init.d/umountfs 
b/debian/src/initscripts/etc/init.d/umountfs
index 633a3f6d..126e7aab 100755
--- a/debian/src/initscripts/etc/init.d/umountfs
+++ b/debian/src/initscripts/etc/init.d/umountfs
@@ -30,7 +30,7 @@ do_stop () {
;;
esac
case "$FSTYPE" in
- proc|procfs|linprocfs|sysfs|usbfs|usbdevfs|devpts)
+ proc|procfs|linprocfs|sysfs|securityfs|usbfs|usbdevfs|devpts)
continue
;;
  tmpfs)
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpANv2I0iCik.pgp
Description: PGP signature

Bug#403369: initscripts: boot messages not displayed on serial console with bootlogd enabled

[Dmitry Bogatov]

control: tags -1 +unreproducible +moreinfo

[2006-12-16 18:01] Paul Slootman 
> part   text/plain1776
> Package: initscripts
> Version: 2.86.ds1-14.1
> Severity: normal
>
> While configuring a Sun Netra T1 (which only has a serial console, no
> graphics at all), I noticed that the boot messages from init scripts
> stopped displaying when I enabled bootlogd. I get this (serial consoles
> _are_ handy :-) :
>
> 
> [   23.190733] EXT3-fs: mounted filesystem with ordered data mode.
> [   23.268793] VFS: Mounted root (ext3 filesystem) readonly.
> INIT: version 2.86 booting
> Starting boot logger: bootlogd[   24.866020] Adding 2931760k swap on 
> /dev/md4.  Priority:-1 extentsk
> [...]

Seems things changed for 13 years. I just set up virtual machine with
following kernel options:

console=tty0 console=ttyS0,9600n

and runit with "kvm -serial file:serial". When it booted content of
/var/log/boot in VM and "serial" on host was same -- both listed events
up to openssh service.

So, seems I need more information and guidance to debug this issue.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#927254: [Pkg-javascript-devel] Bug#927254: libjs-vue-router: ships node module instead of browser one

[Dmitry Bogatov]

[2019-04-22 09:56] Dmitry Bogatov 
> > Provided files are not node-* ones but recompiled using rollup. Could
> > you check if Laminar works well with
> > https://unpkg.com/vue-router@3.0.2/dist/vue-router.js file ? (same
> > version than in Buster)
>
> Yes, file from this URL is OK. Is it present in some Debian package?

Any suggestions, what to do next?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#669406: patch: remove overly aggressive optimization from /etc/init.d/rc

[Dmitry Bogatov]

control: tags 669406 +patch +pending

From 59a9444af50c2b922db6b28cf7bb4476acaba19d Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Tue, 14 May 2019 08:07:02 +
Subject: [PATCH] Remove overly aggressive optimization from /etc/init.d/rc

The optimization:

A start script is not run when the service was already
configured to run in the previous runlevel.  A stop script is
not run when the the service was already configured not to run
in the previous runlevel.

assumes, that services are never started or stopped manually. It means,
that if service was started manually, but disabled in general, on
shutdown it will not be duly stoppend. This change remove such
optimization. (Closes: #669406)
---
 debian/src/sysv-rc/rc | 48 ---
 1 file changed, 48 deletions(-)

diff --git a/debian/src/sysv-rc/rc b/debian/src/sysv-rc/rc
index 025a1c54..3cf51dbb 100755
--- a/debian/src/sysv-rc/rc
+++ b/debian/src/sysv-rc/rc
@@ -4,11 +4,6 @@
 #
 # Starts/stops services on runlevel changes.
 #
-# Optimization: A start script is not run when the service was already
-# configured to run in the previous runlevel.  A stop script is not run
-# when the the service was already configured not to run in the previous
-# runlevel.
-#
 # Authors:
 #  Miquel van Smoorenburg 
 #  Bruce Perens 
@@ -167,20 +162,6 @@ then
# Check if the script is there.
[ ! -f "$i" ] && continue
 
-   #
-   # Find stop script in previous runlevel but
-   # no start script there.
-   #
-   suffix=${i#/etc/rc$runlevel.d/K[0-9][0-9]}
-   
previous_stop=/etc/rc$previous.d/K[0-9][0-9]$suffix
-   
previous_start=/etc/rc$previous.d/S[0-9][0-9]$suffix
-   #
-   # If there is a stop script in the previous 
level
-   # and _no_ start script there, we don't
-   # have to re-stop the service.
-   #
-   [ -f $previous_stop ] && [ ! -f $previous_start 
] && continue
-
# Stop the service.
SCRIPTS="$SCRIPTS $i"
done
@@ -214,35 +195,6 @@ then
do
[ ! -f "$i" ] && continue
 
-   suffix=${i#/etc/rc$runlevel.d/S[0-9][0-9]}
-   if [ "$previous" != N ]
-   then
-   #
-   # Find start script in previous 
runlevel and
-   # stop script in this runlevel.
-   #
-   
stop=/etc/rc$runlevel.d/K[0-9][0-9]$suffix
-   
previous_start=/etc/rc$previous.d/S[0-9][0-9]$suffix
-   #
-   # If there is a start script in the 
previous level
-   # and _no_ stop script in this level, 
we don't
-   # have to re-start the service.
-   #
-   if [ start = "$ACTION" ] ; then
-   [ -f $previous_start ] && [ ! 
-f $stop ] && continue
-   else
-   # Workaround for the special
-   # handling of runlevels 0 and 6.
-   
previous_stop=/etc/rc$previous.d/K[0-9][0-9]$suffix
-   #
-   # If there is a stop script in 
the previous level
-   # and _no_ start script there, 
we don't
-   # have to re-stop the service.
-   #
-   [ -f $previous_stop ] && [ ! -f 
$previous_start ] && continue
-   fi
-
-   fi
SCRIPTS="$SCRIPTS $i"
done
startup $ACTION $SCRIPTS
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpzNaaAWALrs.pgp
Description: PGP signature

Bug#627797: patch: ensure mdadm starts before checkfs (Closes: #627797)

[Dmitry Bogatov]

control: tags 627797 +patch +pending

From 5de0dc682fc11e9bd10691638610955eec979571 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Mon, 13 May 2019 17:53:47 +
Subject: [PATCH] Ensure mdadm starts before checkfs (Closes: #627797)

---
 debian/src/initscripts/etc/init.d/checkfs.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/src/initscripts/etc/init.d/checkfs.sh 
b/debian/src/initscripts/etc/init.d/checkfs.sh
index 67929dec..738a7415 100755
--- a/debian/src/initscripts/etc/init.d/checkfs.sh
+++ b/debian/src/initscripts/etc/init.d/checkfs.sh
@@ -3,7 +3,7 @@
 # Provides:  checkfs
 # Required-Start:checkroot
 # Required-Stop:
-# Should-Start:
+# Should-Start:  mdadm-raid
 # Default-Start: S
 # Default-Stop:
 # X-Interactive: true
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgp37ScxLyQuZ.pgp
Description: PGP signature