Bug#928921: reprotest: kernel too old SIGSEGV

[Vagrant Cascadian]

On 2019-05-13, Dmitry Bogatov wrote:
> Hello. I am working on setting up CI for my packages, and one of them
> fail "reprotest" phase with error: "FATAL: kernel too old"[1][2].

This is probably due to the kernel variation using "setarch", which will
cause uname to report a 2.6 kernel, which is too old for some things...

You should be able to disable it with --variations=+all,-kernel


live well,
  vagrant


signature.asc
Description: PGP signature

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

[Paul Wise]

Package: user-mode-linux
Version: 4.19-1um-1
Severity: important
File: /usr/bin/linux.uml

linux.uml in a GNOME terminal gives these errors in new tabs:

There was an error creating the child process for this terminal
Failed to execute child process “port-helper” (No such file or directory)

The linux.uml binary references the wrong path for port-helper:

$ strings /usr/bin/linux.uml | grep port-helper
/usr/lib//uml/port-helper

$ dpkg -L uml-utilities | grep port-helper
/usr/lib64/uml/port-helper

Please fix this issue in Debian buster, it is an annoying bug.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages user-mode-linux depends on:
ii  libc6  2.28-10

Versions of packages user-mode-linux recommends:
ii  uml-utilities  20070815.2-1

Versions of packages user-mode-linux suggests:
ii  gnome-terminal [x-terminal-emulator]  3.30.2-2
pn  rootstrap 
pn  slirp 
ii  user-mode-linux-doc   20060501-3
pn  vde2  
ii  xterm [x-terminal-emulator]   344-1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#928923: linux-image-4.19.0-4-cloud-amd64: reports different NIC name than linux-image-amd64 on virtio-net

[Xinyue Lu]

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


Environment:

Proxmox VE host, 5.4-1
KVM guest, Debian 10 testing
virtio_net NIC

With linux-image-4.19.0-4-cloud-amd64:

# udevadm test-builtin net_id /sys/class/net/en*
Load module index
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
Using default interface naming scheme 'v240'.
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxbe57fa7f6fb0
ID_NET_NAME_PATH=enp6s18
Unload module index
Unloaded link configuration context.

enp6s18 is used for NIC.

With linux-image-4.19.0-4-amd64:

+ID_NET_NAME_SLOT=ens18

ens18 is used for NIC.

Changing NIC name on switching between kernel varient, IMHO, is not
expected.


-- Package-specific info:
** Version:
Linux version 4.19.0-4-cloud-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-cloud-amd64 
root=UUID=8782a6fc-9622-4d76-8ba0-a7c51dfc9b19 ro quiet

** Not tainted

** Kernel log:

** Model information
[0.620425] pcieport :00:1c.0: Signaling PME with IRQ 24
[0.620484] pcieport :00:1c.1: Signaling PME with IRQ 25
[0.620542] pcieport :00:1c.2: Signaling PME with IRQ 26
[0.620599] pcieport :00:1c.3: Signaling PME with IRQ 27
[0.620659] pciehp :00:1c.0:pcie004: Slot #0 AttnBtn+ PwrCtrl+ MRL- 
AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep- (with Cmd 
Compl erratum)
[0.620816] pciehp :00:1c.1:pcie004: Slot #0 AttnBtn+ PwrCtrl+ MRL- 
AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep- (with Cmd 
Compl erratum)
[0.620949] pciehp :00:1c.2:pcie004: Slot #0 AttnBtn+ PwrCtrl+ MRL- 
AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep- (with Cmd 
Compl erratum)
[0.621082] pciehp :00:1c.3:pcie004: Slot #0 AttnBtn+ PwrCtrl+ MRL- 
AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep- (with Cmd 
Compl erratum)
[0.621261] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[0.621694] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 
0x60,0x64 irq 1,12
[0.622440] serio: i8042 KBD port at 0x60,0x64 irq 1
[0.622447] serio: i8042 AUX port at 0x60,0x64 irq 12
[0.622514] mousedev: PS/2 mouse device common for all mice
[0.622763] input: AT Translated Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input0
[0.623105] NET: Registered protocol family 10
[0.627774] Segment Routing with IPv6
[0.627790] mip6: Mobile IPv6
[0.627794] NET: Registered protocol family 17
[0.627820] mpls_gso: MPLS GSO support
[0.627848] sched_clock: Marking stable (609989229, 14091148)->(634303071, 
-10222694)
[0.627952] registered taskstats version 1
[0.627952] Loading compiled-in X.509 certificates
[0.659562] Loaded X.509 cert 'Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[0.659575] Loaded X.509 cert 'Debian Secure Boot Signer: 00a7468def'
[0.659584] AppArmor: AppArmor sha1 policy hashing enabled
[0.661077] Freeing unused kernel image memory: 1456K
[0.672181] Write protecting the kernel read-only data: 16384k
[0.673093] Freeing unused kernel image memory: 2028K
[0.673655] Freeing unused kernel image memory: 1420K
[0.673763] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[0.673764] x86/mm: Checking user space page tables
[0.673781] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[0.673784] Run /init as init process
[0.734305] PCI Interrupt Link [GSIF] enabled at IRQ 21
[0.734939] PCI Interrupt Link [GSIG] enabled at IRQ 22
[0.739958] cryptd: max_cpu_qlen set to 1000
[0.746752] AVX version of gcm_enc/dec engaged.
[0.746752] AES CTR mode by8 optimization enabled
[0.751777] PCI Interrupt Link [GSIH] enabled at IRQ 23
[0.772002] virtio_net virtio1 enp6s18: renamed from eth0
[0.772457] SCSI subsystem initialized
[0.775114] scsi host0: Virtio SCSI HBA
[0.776243] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK2.5+ 
PQ: 0 ANSI: 5
[0.776500] scsi 0:0:0:1: Direct-Access QEMU QEMU HARDDISK2.5+ 
PQ: 0 ANSI: 5
[0.787717] random: fast init done
[0.792775] sd 0:0:0:0: Power-on or device reset occurred
[0.793199] sd 0:0:0:0: [sda] 1073741824 512-byte logical blocks: (550 
GB/512 GiB)
[0.793223] sd 0:0:0:0: [sda] Write Protect is off
[0.793228] sd 0:0:0:0: [sda] Mode Sense: 63 00 00 08
[0.793271] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[0.794211] sd 0:0:0:0: [sda] Attached SCSI disk
[0.794229] sd 0:0:0:1: Power-on or device reset occurred
[0.794433] sd 0:0:0:1: [sdb] 31457280 512-byte logical blocks: (16.1 
GB/15.0 GiB)
[0.794462] sd 0:0:0:1: [sdb] Write Protect is off
[0.794464] sd 0:0:0:1: [sdb] Mode Sense: 63 00 00 08
[0.794515] sd 0:0:0:1: [sdb] Write cache: enabled, 

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

[Steffen Ullrich]

On Mon, May 13, 2019 at 01:02:45AM +0200, Guilhem Moulin  
wrote:
> Thanks for your analysis, Steffen.  Dropping the Debian-specific patch
> is definitely the way to go for libwww/LWP.  However I still believe
> IO::Socket::SSL should provide a way to clear SSL_MODE_AUTO_RETRY in
> order to fix applications relying on the former OpenSSL defaults, as
> suggested in the OpenSSL changelog:
>
> “SSL_MODE_AUTO_RETRY is enabled by default. Applications that use
> blocking I/O in combination with something like select() or poll()
> will hang. This can be turned off again using SSL_CTX_clear_mode().”
>
> Otherwise the “usual” way to write event loops in blocking I/O won't be
> possible with IO::Socket::SSL.

Applications which relied on blocking I/O in connection with select could
also hang before, only this problem is worse now. Before TLS 1.3 these
applications could hang if the peer initiated a renegotiation since this
were TCP level data without any SSL application payload, i.e. select was
triggered but sysread would not return with data. It could also lead to
delays when SSL frames larger than the TCP window size where used or due to
interactions with NAGLE algorithms or delayed ACK. In this case too TCP
level data were received but the SSL level data where only received later
once the SSL frame was completed, which means it had to wait until
completation of the SSL frame in sysread.

With TLS 1.3 this problem is now worse since it happens more often. And
frankly, I'd rather see the applications fix their wrong approach than to
give them an opportunity to work around the most common cause and leave
them wondering about strange problems which happen from time to time and
which nobody can really reproduce.

Additionally switching off SSL_MODE_AUTO_RETRY would actually just add a
different unexpected behavior: that sysread might return with EAGAIN on a
blocking socket. This is not the behavior one expects from a blocking
socket, i.e. it should block until it returns data, should return no data
only on connection shutdown or should fail permanently.
It was just a coincidence that LWP::protocol::http could deal with this
situation. And this coincidence came from the fact, that this code was
actually designed for non-blocking sockets and only the Debian patch caused
it to use a blocking socket instead.

I've added more information regarding this to the IO::Socket::SSL
documentation:
https://github.com/noxxi/p5-io-socket-ssl/commit/ee176e489f02bfaaa479fc8d9312c8458bf55565

Regards,
Steffen

Bug#928810: patch: Make debian-watch-uses-insecure-uri more generic

[Dmitry Bogatov]

[2019-05-11 16:08] Jelmer Vernooij 
> On Sat, May 11, 2019 at 02:49:11PM +, Dmitry Bogatov wrote:
> > From 2789fed85a6088c85f8f37ba96984eb7f3d8e8ef Mon Sep 17 00:00:00 2001
> > From: Dmitry Bogatov 
> > Date: Fri, 10 May 2019 23:32:01 +
> > Subject: [PATCH] Make debian-watch-uses-insecure-uri more generic
> > 
> > Instead of using hard-coded list of hosts, that are known to support
> > https new implementation just replace "http://; with "https://; and
> > makes sure, that uscan report is same.
> Does lintian-brush still build successfully under e.g. sbuild with this patch?
> I suspect that this makes the test for debian-watch-uses-insecure-uri fail
> because it now needs internet access.

Good catch. What do you want me to do about it?

By the way, how does it come that "homepage-uses-insecure-uri" does not
fail in sbuild?

> This also seems to unconditionally run uscan, regardless of whether
> there are any http: URLs in debian/watch, slowing down lintian-brush
> in situations when there's nothing to fix. Could you perhaps grep for
> http: first?

Good idea.

From f1a994eae7b81f208a6973af4249918b87bd26ea Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Fri, 10 May 2019 23:32:01 +
Subject: [PATCH] Make debian-watch-uses-insecure-uri more generic

Instead of using hard-coded list of hosts, that are known to support
https new implementation just replace "http://; with "https://; and
makes sure, that uscan report is same.
---
 fixers/debian-watch-uses-insecure-uri.sh | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/fixers/debian-watch-uses-insecure-uri.sh 
b/fixers/debian-watch-uses-insecure-uri.sh
index 85136b8..66c9dad 100755
--- a/fixers/debian-watch-uses-insecure-uri.sh
+++ b/fixers/debian-watch-uses-insecure-uri.sh
@@ -1,6 +1,20 @@
 #!/bin/sh
-perl -p -i -e 
's/http:\/\/code.launchpad.net\//https:\/\/code.launchpad.net\//' debian/watch
-perl -p -i -e 's/http:\/\/launchpad.net\//https:\/\/launchpad.net\//' 
debian/watch
-perl -p -i -e 's/http:\/\/ftp.gnu.org\//https:\/\/ftp.gnu.org\//' debian/watch
+test -r debian/watch|| exit 0
+grep 'http://' debian/watch || exit 0
+
+before=$(mktemp)
+after=$(mktemp)
+uscan --dehs > "${before}" 2>&1
+sed -i.bak s,http://,https://,g debian/watch
+uscan --dehs > "${after}" 2>&1
+
+# Make sure that reports are same up to http/https substitution in URL.
+sed -i s,http://,https://,g "${before}" "${after}"
+if cmp -s "${before}" "${after}" ; then
+   rm -f debian/watch.bak
+else
+   mv debian/watch.bak debian/watch
+fi
+rm -f "${before}" "${after}"
 echo "Use secure URI in debian/watch."
 echo "Fixed-Lintian-Tags: debian-watch-uses-insecure-uri"
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#928811: patch: New fixer: patch-file-present-but-not-mentioned-in-series.sh

[Dmitry Bogatov]

[2019-05-11 15:56] Jelmer Vernooij 
> Thanks! Makes sense.
>
> Any chance you could add a test case for this under
> tests/patch-file-present-but-not-mentioned-in-series/?

Sure.

From 6e795731f4ae266954acf9de70ace6f0ea4e944c Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sat, 11 May 2019 14:46:44 +
Subject: [PATCH] New fixer: patch-file-present-but-not-mentioned-in-series.sh

Make sure that debian/patches contain only patches, mentioned in series
file.
---
 fixers/index.desc  |  3 +++
 .../patch-file-present-but-not-mentioned-in-series.sh  | 10 ++
 .../have-patches/in/debian/patches/one |  0
 .../have-patches/in/debian/patches/series  |  2 ++
 .../have-patches/in/debian/patches/three   |  0
 .../have-patches/in/debian/patches/two |  0
 .../have-patches/message   |  2 ++
 .../have-patches/out/debian/patches/one|  0
 .../have-patches/out/debian/patches/series |  2 ++
 .../have-patches/out/debian/patches/two|  0
 .../no-patches/in/debian/control   |  0
 .../no-patches/out |  1 +
 12 files changed, 20 insertions(+)
 create mode 100755 fixers/patch-file-present-but-not-mentioned-in-series.sh
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/one
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/three
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/two
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/message
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/out/debian/patches/one
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/out/debian/patches/series
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/have-patches/out/debian/patches/two
 create mode 100644 
tests/patch-file-present-but-not-mentioned-in-series/no-patches/in/debian/control
 create mode 12 
tests/patch-file-present-but-not-mentioned-in-series/no-patches/out

diff --git a/fixers/index.desc b/fixers/index.desc
index 735179f..058889c 100644
--- a/fixers/index.desc
+++ b/fixers/index.desc
@@ -120,6 +120,9 @@ Lintian-Tags:
   package-uses-deprecated-debhelper-compat-version,
   package-uses-old-debhelper-compat-version
 
+Fix-Script: patch-file-present-but-not-mentioned-in-series.sh
+Lintian-Tags: patch-file-present-but-not-mentioned-in-series
+
 Fix-Script: possible-missing-colon-in-closes.sh
 Lintian-Tags: possible-missing-colon-in-closes
 
diff --git a/fixers/patch-file-present-but-not-mentioned-in-series.sh 
b/fixers/patch-file-present-but-not-mentioned-in-series.sh
new file mode 100755
index 000..66ff555
--- /dev/null
+++ b/fixers/patch-file-present-but-not-mentioned-in-series.sh
@@ -0,0 +1,10 @@
+#!/bin/sh -eu
+test -r debian/patches/series || exit 0
+cd debian/patches
+
+for f in * ; do
+   test "${f}" != series || continue
+   grep -q -- "${f}" series || rm "${f}"
+done
+echo "Remove patches missing from debian/patches/series."
+echo "Fixed-Lintian-Tags: patch-file-present-but-not-mentioned-in-series"
diff --git 
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/one
 
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/one
new file mode 100644
index 000..e69de29
diff --git 
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
 
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
new file mode 100644
index 000..814f4a4
--- /dev/null
+++ 
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
@@ -0,0 +1,2 @@
+one
+two
diff --git 
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/three
 
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/three
new file mode 100644
index 000..e69de29
diff --git 
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/two
 
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/two
new file mode 100644
index 000..e69de29
diff --git 
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/message 
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/message
new file mode 100644
index 000..2281c60
--- /dev/null
+++ b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/message
@@ -0,0 +1,2 @@
+Remove patches missing from debian/patches/series.
+Fixed-Lintian-Tags: 

Bug#928918: hurd: taking over /etc/hurd/runsystem.sysv

[Dmitry Bogatov]

Package: hurd
Severity: normal
Affects: initscripts
Blocks: 922962

Dear Maintainer,

bin:initscripts ships /etc/hurd/runsystem.sysv file on hurd architecture,
thus making bin:initscript arch:any, which is quite unfortunate, given
that both "/etc/hurd/runsystem.sysv" and rest of bin:initscript are
shell scripts.

Please copy this file into bin:hurd and provide apporiate Replaces.


pgpicL_W7Y9MQ.pgp
Description: PGP signature

Bug#928394: RFS: freetype-py/2.1.0.post1-1 [ITP]

[Dmitry Bogatov]

[2019-05-09 22:35] Bastian Germann 
> I have changed that and also made the smoke test run.

Fine. Uploaded. I also suggest you to use Gitlab CI. See here:

https://salsa.debian.org/salsa-ci-team/pipeline/
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#928920: patch: Introduce logging functions that check ${VERBOSE}

[Dmitry Bogatov]

Package: lsb-base
Severity: wishlist
Tags: patch

From 58dd6e6add24a4e5531a84ff2404f2f5ed71e114 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sat, 11 May 2019 21:20:48 +
Subject: [PATCH] Introduce logging functions that check ${VERBOSE}

Use of logging functions in initscripts are often conditioned on value
of $VERBOSE variable, causing same code to be repeated over and over
again.

This change introduce number of logging functions (with prefix "v") that
are functionally equivalent to their counterparts without prefix when
value of $VERBOSE is not "no", and do nothing if value of $VERBOSE is "no".
---
 conf/conf.yaml| 7 +++
 debian/control| 1 +
 debian/lsb-base.install   | 1 +
 debian/rules  | 4 
 init-functions.d/.gitignore   | 1 +
 init-functions.d/00-verbose.jinja | 9 +
 6 files changed, 23 insertions(+)
 create mode 100644 conf/conf.yaml
 create mode 100644 init-functions.d/.gitignore
 create mode 100644 init-functions.d/00-verbose.jinja

diff --git a/conf/conf.yaml b/conf/conf.yaml
new file mode 100644
index 000..d1ac18b
--- /dev/null
+++ b/conf/conf.yaml
@@ -0,0 +1,7 @@
+log_functions:
+  - log_daemon_msg
+  - log_begin_msg
+  - log_end_msg
+  - log_action_msg
+  - log_action_begin_msg
+  - log_action_end_msg
diff --git a/debian/control b/debian/control
index b39cdc6..e4746d2 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends: debhelper (>> 11~),
  python3-all:any,
  dh-python,
  distro-info-data,
+ ionit
 Standards-Version: 4.2.1
 Homepage: https://wiki.linuxfoundation.org/lsb/start
 Vcs-Browser: https://salsa.debian.org/debian/lsb
diff --git a/debian/lsb-base.install b/debian/lsb-base.install
index 66dc0df..d2d9588 100644
--- a/debian/lsb-base.install
+++ b/debian/lsb-base.install
@@ -1,2 +1,3 @@
 init-functions /lib/lsb
+init-functions.d/00-verbose  /lib/lsb/init-functions.d
 init-functions.d/20-left-info-blocks /lib/lsb/init-functions.d
diff --git a/debian/rules b/debian/rules
index 33c4aff..32789c5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,10 @@ PY3VERSIONS=$(shell [ -x /usr/bin/py3versions ] && py3versions 
-vr)
 %:
dh $@ --with python3
 
+override_dh_auto_build:
+   dh_auto_build
+   ionit -c conf -t init-functions.d
+
 # These are used for cross-compiling and for saving the configure script
 # from having to guess our platform (since we know it already)
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
diff --git a/init-functions.d/.gitignore b/init-functions.d/.gitignore
new file mode 100644
index 000..876584d
--- /dev/null
+++ b/init-functions.d/.gitignore
@@ -0,0 +1 @@
+00-verbose
diff --git a/init-functions.d/00-verbose.jinja 
b/init-functions.d/00-verbose.jinja
new file mode 100644
index 000..15916aa
--- /dev/null
+++ b/init-functions.d/00-verbose.jinja
@@ -0,0 +1,9 @@
+## Generated automatically. Do not edit! -*- shell-script -*-
+{% for fn in log_functions %}
+v{{ fn }} () {
+   if test "${VERBOSE:-yes}" != no ; then
+   {{ fn }} "$@"
+   fi
+}
+{% endfor %}
+# vim: ft=sh
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgp2KJ8ql_M2p.pgp
Description: PGP signature

Bug#928921: reprotest: kernel too old SIGSEGV

[Dmitry Bogatov]

Package: reprotest
Version: 0.7.8
Severity: normal

Hello. I am working on setting up CI for my packages, and one of them
fail "reprotest" phase with error: "FATAL: kernel too old"[1][2].

I grepped upstream sources for "kernel too old" message and found
nothing. Regular build is successful. Any suggestions, what may be wrong
and how to fix it?

On another package I get "bad system call" error[2].

 [^1] https://salsa.debian.org/debian/bglibs/-/jobs/170367
 [^2] https://salsa.debian.org/debian/bcron/-/jobs/170195
 [^3] https://salsa.debian.org/debian/gdbm/-/jobs/170585
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpY_nC7exCk5.pgp
Description: PGP signature

Bug#928922: devscripts: make debrepro use debuild

[Dmitry Bogatov]

Package: devscripts
Version: 2.19.4
Severity: wishlist

Dear Maintainer,

please consider using "debuild" instead of "dpkg-buildpackage" in
"debrepro" script to avoid spurious failures in unsual environments
(effectful environment variables, unexpected binaries in PATH, ...)

Alternatively (not that it is best route), document that "debrepro" uses
"dpkg-buildpackage" and user is responsible for environment
sanititization.


pgpd2Y9xV4OUz.pgp
Description: PGP signature

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

[Dmitry Bogatov]

Package: initscripts
Severity: wishlist
Tags: patch

From 987ac0ec780a063052346ff8adb33a072694ae11 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sat, 11 May 2019 20:19:11 +
Subject: [PATCH] Do not hide errors from initscripts

---
 debian/src/initscripts/etc/init.d/bootlogs   | 2 --
 debian/src/initscripts/etc/init.d/bootmisc.sh| 2 --
 debian/src/initscripts/etc/init.d/checkfs.sh | 2 --
 debian/src/initscripts/etc/init.d/checkroot-bootclean.sh | 2 --
 debian/src/initscripts/etc/init.d/checkroot.sh   | 2 --
 debian/src/initscripts/etc/init.d/halt   | 2 --
 debian/src/initscripts/etc/init.d/hostname.sh| 2 --
 debian/src/initscripts/etc/init.d/mountall-bootclean.sh  | 2 --
 debian/src/initscripts/etc/init.d/mountall.sh| 2 --
 debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh  | 2 --
 debian/src/initscripts/etc/init.d/mountnfs.sh| 2 --
 debian/src/initscripts/etc/init.d/rmnologin  | 2 --
 debian/src/initscripts/etc/init.d/sendsigs   | 2 --
 debian/src/initscripts/etc/init.d/umountfs   | 2 --
 debian/src/initscripts/etc/init.d/umountnfs.sh   | 2 --
 debian/src/initscripts/etc/init.d/umountroot | 2 --
 debian/src/initscripts/etc/init.d/urandom| 2 --
 17 files changed, 34 deletions(-)

diff --git a/debian/src/initscripts/etc/init.d/bootlogs 
b/debian/src/initscripts/etc/init.d/bootlogs
index 686a2afb..3916e4ef 100644
--- a/debian/src/initscripts/etc/init.d/bootlogs
+++ b/debian/src/initscripts/etc/init.d/bootlogs
@@ -65,5 +65,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/bootmisc.sh 
b/debian/src/initscripts/etc/init.d/bootmisc.sh
index 461b7472..f56b4078 100755
--- a/debian/src/initscripts/etc/init.d/bootmisc.sh
+++ b/debian/src/initscripts/etc/init.d/bootmisc.sh
@@ -58,5 +58,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/checkfs.sh 
b/debian/src/initscripts/etc/init.d/checkfs.sh
index 67929dec..ab5a4bac 100755
--- a/debian/src/initscripts/etc/init.d/checkfs.sh
+++ b/debian/src/initscripts/etc/init.d/checkfs.sh
@@ -145,5 +145,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh 
b/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh
index effe252b..1cf811cd 100755
--- a/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh
+++ b/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh
@@ -39,5 +39,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/checkroot.sh 
b/debian/src/initscripts/etc/init.d/checkroot.sh
index 873e6748..cb7e1537 100755
--- a/debian/src/initscripts/etc/init.d/checkroot.sh
+++ b/debian/src/initscripts/etc/init.d/checkroot.sh
@@ -375,5 +375,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/halt 
b/debian/src/initscripts/etc/init.d/halt
index c179a25a..f4f5ffaf 100755
--- a/debian/src/initscripts/etc/init.d/halt
+++ b/debian/src/initscripts/etc/init.d/halt
@@ -79,5 +79,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/hostname.sh 
b/debian/src/initscripts/etc/init.d/hostname.sh
index 71635d37..95880cc1 100755
--- a/debian/src/initscripts/etc/init.d/hostname.sh
+++ b/debian/src/initscripts/etc/init.d/hostname.sh
@@ -46,5 +46,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/mountall-bootclean.sh 
b/debian/src/initscripts/etc/init.d/mountall-bootclean.sh
index 546c5322..d4d1dad8 100755
--- a/debian/src/initscripts/etc/init.d/mountall-bootclean.sh
+++ b/debian/src/initscripts/etc/init.d/mountall-bootclean.sh
@@ -31,5 +31,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/mountall.sh 
b/debian/src/initscripts/etc/init.d/mountall.sh
index 129a4325..50d192cb 100755
--- a/debian/src/initscripts/etc/init.d/mountall.sh
+++ b/debian/src/initscripts/etc/init.d/mountall.sh
@@ -112,5 +112,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh 
b/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh
index d1a6d8bc..d6ffae12 100755
--- a/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh
+++ b/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh
@@ -31,5 +31,3 @@ case "$1" in
exit 3
;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/mountnfs.sh 
b/debian/src/initscripts/etc/init.d/mountnfs.sh
index 00ac7572..a33e9ef7 100755
--- a/debian/src/initscripts/etc/init.d/mountnfs.sh
+++ b/debian/src/initscripts/etc/init.d/mountnfs.sh
@@ -102,5 +102,3 @@ case "$1" in
 exit 3
 ;;
 esac
-
-:
diff --git a/debian/src/initscripts/etc/init.d/rmnologin 

Bug#921600: closed by "Arnaud Rebillout" ()

[Arnaud Rebillout]

On Fri, 10 May 2019 22:12:46 + "brian m. carlson"
 wrote:
> On Fri, May 10, 2019 at 02:12:04AM +, Debian Bug Tracking System
wrote:
> >
> > This bug was fixed upstream already, see:
> > - https://github.com/docker/libnetwork/pull/2343
> > - https://github.com/docker/libnetwork/pull/2339#issuecomment-487207550
>
> Unfortunately, this requires Docker 18.09.4 or newer, and even
> experimental has only 18.09.3. Without an update or a patch, Docker
> continues to use iptables-legacy, and as a consequence things still fail
> to work.

Hey, you're right, sorry for the mistake and thanks for notifying!

>
> Could you please update to a newer version or apply a patch? It's
> probably better to apply a patch for buster, while uploading a newer
> version may be appropriate for unstable or experimental.

So I indeed applied the patch, and pushed the changes on the master
branch at Salsa. Now waiting for review and upload from Dmitry (he's the
package maintainer).

Regarding experimental, Salsa is already at 18.09.5, also just waiting
for an upload.

Thanks again,

  Arnaud

Bug#928500: mentors.debian.net

[Joël Krähemann]

Hi,

FYI:

https://mentors.debian.net/package/gsequencer

cheers,
Joël

Bug#928917: contents

[susu]

--
Deleting module version: 4.19+20190211
completely from the DKMS tree.
--
Done.
Loading new aufs-4.19+20190211 DKMS files...
Building for 4.19.0-4-amd64
Building initial module for 4.19.0-4-amd64
Done.

aufs.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.19.0-4-amd64/updates/dkms/

depmod...
--
After exporting the content, he stopped working.

Bug#928917: aufs-dkms: debian 10 don't install aufs-dkms

[susu]

Package: aufs-dkms
Version: 4.19+20190211-1
Severity: important

Dear Maintainer,

Subject: aufs-dkms: debian 10 don't install aufs-dkms package
Package: aufs-dkms
Version: 4.19+20190211-1
Severity: important

Dear Maintainer,

I want to install docker-ce in debian10. docker-ce relies on aufs-tools, but 
aufs-dkms can't be installed correctly. He always gets stuck after the output 
of the following content. I don't know how to review this problem.

-- 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/16 CPU cores)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN:zh (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aufs-dkms depends on:
ii  dkms  2.6.1-4

Versions of packages aufs-dkms recommends:
ii  aufs-tools  1:4.14+20190211-1

Versions of packages aufs-dkms suggests:
pn  aufs-dev  

-- no debconf information

Bug#928879: sample log

[hoxp18]

To: Mike Hommey
Cc: related maintainers

On 5/13/19 8:38 AM, Mike Hommey wrote:

On Sun, May 12, 2019 at 08:52:20PM +0900, hoxp18 wrote:

Dear maintainers,

I forgot to add the sample log. Apology.

kernel: [ sec] audit: type=1400 audit(X.YYY:ZZZ):
   apparmor="DENIED" operation="mknod"
   profile="/usr/share/firefox-esr/firefox-esr"
   name="/usr/share/firefox-esr/fonts/.uuid.TMP-RANDOM"
   pid=PID comm=("firefox-esr"|[:digits:])
   requested_mask="c" denied_mask="c" fsuid=UID ouid=UID

This is after I mkdir /usr/share/firefox-esr/fonts.

kernel: [ sec] audit: type=1400 audit(X.YYY:ZZZ):
   apparmor="DENIED" operation="mknod"
   profile="/usr/lib/firefox-esr/firefox-esr"
   name="/usr/lib/firefox-esr/fonts/.uuid.TMP-RANDOM"
   pid=PID comm=("firefox-esr"|[:digits:])
   requested_mask="c" denied_mask="c" fsuid=UID ouid=UID


It would be useful to have stack traces for these operations to see
where they come from.

Mike


I'd like to, but Firefox itself does not crash because of this.

There are no "Crash Reports" nor stack trace log in syslog.

Since I'm not a developer, my best guess is (by simple grep the source)
somewhere around,

1. gfx/2d/ScaledFontDWrite.cpp
   aFace->QueryInterface(__uuidof(IDWriteFontFace5),

2. gfx/thebes/gfxDWriteFontList.cpp
   mFontFace->QueryInterface(__uuidof(IDWriteFontFace5),

3. gfxPlatformGtk::GetCommonFallbackFonts
   in gfx/thebes/gfxPlatformGtk.cpp;

If you provide me some specific instructions,
I may be able to do some more.

Regards.

Bug#928916: "System error during SSL_connect(): Success"

[Paul Kimoto]

Package: fetchmail
Version: 6.3.26-3
Severity: wishlist

>From time to time I invoke fetchmail, and it fails with

 fetchmail: System error during SSL_connect(): Success
 fetchmail: SSL connection failed.

which is a rather confusing error message.

My libssl is 1.1.0j-1~deb9u1.

Bug#928915: Full log unavailable with -e or -x

[ಚಿರಾಗ್ ನಟರಾಜ್]

Hmm, it seems there's been a change in behavior? Before I upgraded, I could 
access the full log with -xe, but it seems that now -e implies -n1000?

So I guess this isn't explicitly an issue, but it was a surprise after I 
upgraded.

Sincerely,

Chiraag
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Graduate Student at Brown University
Email: chiraag.nata...@gmail.com
Phone: 610-350-6329
Website: http://chiraag.nataraj.us



signature.asc
Description: PGP signature

Bug#928915: systemd: Full log unavailable with -e or -x

[ಚಿರಾಗ್ ನಟರಾಜ್]

Package: systemd
Version: 242-1
Severity: normal

Dear Maintainer,

Different invocations of journalctl seem to display different amounts of the 
log.

$ sudo journalctl -xe
-- Logs begin at Sun 2019-05-12 20:37:51 EDT, end at Sun 2019-05-12 21:16:32 
EDT. --
ಮೇ 12 20:44:29 chiraag env[8395]: 
{"name":"log","hostname":"chiraag","pid":203,"level":30,"msg":"GET 
https://textsecure-service.whispersystems.org/

$ sudo journalctl -x
-- Logs begin at Sun 2019-05-12 20:37:51 EDT, end at Sun 2019-05-12 21:16:32 
EDT. --
ಮೇ 12 20:44:29 chiraag env[8395]: 
{"name":"log","hostname":"chiraag","pid":203,"level":30,"msg":"GET 
https://textsecure-service.whispersystems.org/

$ sudo journalctl -e
-- Logs begin at Sun 2019-05-12 20:37:51 EDT, end at Sun 2019-05-12 21:16:32 
EDT. --
ಮೇ 12 20:44:29 chiraag env[8395]: 
{"name":"log","hostname":"chiraag","pid":203,"level":30,"msg":"GET 
https://textsecure-service.whispersystems.org/

$ sudo journalctl
-- Logs begin at Sun 2019-05-12 20:37:51 EDT, end at Sun 2019-05-12 21:17:17 
EDT. --
ಮೇ 12 20:37:51 chiraag kernel: microcode: microcode updated early to revision 
0x9a, date = 2018-07-16

I included the first line only, but it should get the point across. I scrolled 
back up to the top with the invocations which include -e, so that's not the 
issue. Additionally, this seems to not be an issue if I use --unit to filter by 
regexp.

Sincerely,

Chiraag

-- Package-specific info:

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

Kernel: Linux 5.0.2-chiraag (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=kn_IN.UTF-8, LC_CTYPE=kn_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=kn_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.2.0~rc0-1
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-2
ii  libgpg-error01.36-1
ii  libidn2-02.0.5-1
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.32-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.9-1
ii  libsystemd0  242-1
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.13.8-1
ii  libpam-systemd  242-1

Versions of packages systemd suggests:
ii  policykit-10.116-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 242-1

-- Configuration Files:
/etc/systemd/resolved.conf changed [not included]

-- no debconf information

Bug#928914: Fix for #898892 breaks normal usage

[ಚಿರಾಗ್ ನಟರಾಜ್]

Never mind, I'm an idiot. The name of the unit was boinc-client.service.

Sincerely,

Chiraag


signature.asc
Description: PGP signature

Bug#928914: systemd: Fix for #898892 breaks normal usage

[ಚಿರಾಗ್ ನಟರಾಜ್]

Package: systemd
Version: 242-1
Severity: normal

Dear Maintainer,

It seems the fix for #898892 renders bare unit names unusable.

Example:

$ sudo journalctl --unit boinc
-- No entries --

$ sudo journalctl --unit boinc*
ಮೇ 12 20:39:36 chiraag systemd[1]: Started Berkeley Open Infrastructure Network 
Computing Client.
ಮೇ 12 20:39:38 chiraag boinc[1405]: 12-May-2019 20:39:38 [---] Starting BOINC 
client version 7.14.2 for x86_64-pc-linux-gnu
ಮೇ 12 20:39:38 chiraag boinc[1405]: 12-May-2019 20:39:38 [---] log flags: 
file_xfer
ಮೇ 12 20:39:38 chiraag boinc[1405]: 12-May-2019 20:39:38 [---] Libraries: 
libcurl/7.64.0 OpenSSL/1.1.1b zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+l
ಮೇ 12 20:39:38 chiraag boinc[1405]: 12-May-2019 20:39:38 [---] Data directory: 
/var/lib/boinc-client


That is, in order for me to view the logs of boinc.service, I need to pass 
boinc* as the argument to --unit (--unit boinc.service gives me the same result 
as --unit boinc).

Sincerely,

Chiraag

-- Package-specific info:

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

Kernel: Linux 5.0.2-chiraag (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=kn_IN.UTF-8, LC_CTYPE=kn_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=kn_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.2.0~rc0-1
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-2
ii  libgpg-error01.36-1
ii  libidn2-02.0.5-1
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.32-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.9-1
ii  libsystemd0  242-1
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.13.8-1
ii  libpam-systemd  242-1

Versions of packages systemd suggests:
ii  policykit-10.116-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 242-1

-- Configuration Files:
/etc/systemd/resolved.conf changed [not included]

-- no debconf information

Bug#928894: [pkg-gnupg-maint] Bug#928894: custom keyring is not honoured

[Toni Mueller]

Hi Daniel,

On Sun, May 12, 2019 at 06:52:17PM -0400, Daniel Kahn Gillmor wrote:
> I'm not sure that this demonstrates what you're describing.
> 
> Here is a run with gpg 2.2.15-1 that demonstrates the key being fetched
> into the extra keyring:
> 
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ export GNUPGHOME=$(pwd)

I did not do this. This variable is unset in my environment.

> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ touch $(pwd)/extra.gpg
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ gpg --no-default-keyring --keyring 
> $(pwd)/extra.gpg --recv-keys CC64B1DB67ABBEECAB24B6455FC346329753F4B0
> gpg: key 2D9AE806EC1592E2: 6 signatures not checked due to missing keys
> gpg: /tmp/cdtemp.AhkyjS/trustdb.gpg: trustdb created
> gpg: key 2D9AE806EC1592E2: public key "Teabot " imported
> gpg: no ultimately trusted keys found
> gpg: Total number processed: 1
> gpg:   imported: 1
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ gpg --list-options show-keyring -k 
> tea...@gitea.io
> gpg: keybox '/tmp/cdtemp.AhkyjS/pubring.kbx' created
> gpg: error reading key: No public key
> 2 dkg@alice:/tmp/cdtemp.AhkyjS$ ls -la
> total 24
> drwx--  4 dkg  dkg   160 May 12 18:48 .
> drwxrwxrwt 28 root root 1420 May 12 18:47 ..
> drwx--  2 dkg  dkg60 May 12 18:48 crls.d
> -rw-r--r--  1 dkg  dkg  6467 May 12 18:48 extra.gpg
> -rw-r--r--  1 dkg  dkg  6467 May 12 18:48 extra.gpg~
> drwx--  2 dkg  dkg40 May 12 18:48 private-keys-v1.d
> -rw---  1 dkg  dkg32 May 12 18:48 pubring.kbx
> -rw---  1 dkg  dkg  1200 May 12 18:48 trustdb.gpg
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ 

Your experiment only shows that the key did *not* end
up in /tmp/cdtemp.AhkyjS/pubring.kbx. Otherwise, the "gpg -k" above
should have listed it, instead of saying "No public key".

> perhaps the teabot key was already in your default keyring before you
> run the --recv-keys operation?  that would certainly explain the
> behavior that you're seeing.

No, it does not. If a key is already there, it would not say
"imported: 1". And since it said "imported: 1" for you, I challenge you
to find the location of that key, because it is obviously not in your
temporary keyring.

For what it's worth, here's another run, setting GNUPGHOME:


$ touch ~/mnt/tools/gitea-keys.gpg
$ GNUPGHOME=`/bin/pwd`
$ echo ${GNUPGHOME}
/home/toni/mnt/tools
$ gpg --list-options show-keyring -k tea...@gitea.io
gpg: please do a --check-trustdb
gpg: error reading key: No public key
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg   --list-options show-keyring -k 
tea...@gitea.io
gpg: please do a --check-trustdb
gpg: error reading key: No public key
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg --no-default-keyring --recv-keys 
CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 0x2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: key 0x2D9AE806EC1592E2: public key "Teabot " imported
gpg: Total number processed: 1
gpg:   imported: 1
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg --no-default-keyring --recv-keys 
CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 0x2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: key 0x2D9AE806EC1592E2: "Teabot " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg   --list-options show-keyring -k 
tea...@gitea.io
gpg: please do a --check-trustdb
Keyring: /home/toni/.gnupg/pubring.gpg
--
pub   rsa4096/0x2D9AE806EC1592E2 2018-06-24 [SC] [expires: 2020-06-23]
  7C9E68152594688862D62AF62D9AE806EC1592E2
uid   [ unknown] Teabot 
sub   rsa4096/0x1FBE01D7CBADB9A0 2018-06-24 [E] [expires: 2020-06-23]
sub   rsa4096/0x5FC346329753F4B0 2018-06-24 [S] [expires: 2019-06-24]

$ l `/bin/pwd`/gitea-keys.gpg
-rw-r- 1 toni toni 0 May 13 00:55 /home/toni/mnt/tools/gitea-keys.gpg
$ 


Enjoy,
Toni

Bug#928879: sample log

[Mike Hommey]

On Sun, May 12, 2019 at 08:52:20PM +0900, hoxp18 wrote:
> Dear maintainers,
> 
> I forgot to add the sample log. Apology.
> 
> kernel: [ sec] audit: type=1400 audit(X.YYY:ZZZ):
>   apparmor="DENIED" operation="mknod"
>   profile="/usr/share/firefox-esr/firefox-esr"
>   name="/usr/share/firefox-esr/fonts/.uuid.TMP-RANDOM"
>   pid=PID comm=("firefox-esr"|[:digits:])
>   requested_mask="c" denied_mask="c" fsuid=UID ouid=UID
> 
> This is after I mkdir /usr/share/firefox-esr/fonts.
> 
> kernel: [ sec] audit: type=1400 audit(X.YYY:ZZZ):
>   apparmor="DENIED" operation="mknod"
>   profile="/usr/lib/firefox-esr/firefox-esr"
>   name="/usr/lib/firefox-esr/fonts/.uuid.TMP-RANDOM"
>   pid=PID comm=("firefox-esr"|[:digits:])
>   requested_mask="c" denied_mask="c" fsuid=UID ouid=UID

It would be useful to have stack traces for these operations to see
where they come from.

Mike

Bug#927462: Bug #927462: megadown: Does not download anything

[Alexis Murzeau]

Hi,

Did you see this bug on the megadown package ?
I saw that your maintainer email (vivia.nikolai...@puri.sm) is not the one you 
used when creating bugs before (n.vi...@gmail.com), so I am mailing both just 
in case.

On Sat, 20 Apr 2019 09:12:53 +0300 jim_p  wrote:
> Package: megadown
> Version: 0~20180705+git83c53dd-1
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> When trying to download a file from mega, which is the sole reason this script
> exists, megadown fails like so
> 
> $ megadown
> 'https://mega.nz/#!3QsG0IDJ!wnEhMRAj1UsXvH3BmWKfr5Z4wqMD2c5ru4iWgFzJmO0'
>    Reading link metadata...
> MEGA bad link
> 
> I reported the issue to the project's github page, because it happened with
> other mega links as well, and its dev issued a patch that restores the 
> intended
> functionality, here
> 
> https://github.com/tonikelope/megadown/commit/734e46fec67a2798bfbb5e21a75f04b90afafd65
> 
> So please update the package on the repo, which by the way is numerous minor
> versions behind.
> 

Are you already in the process of backporting this patch, or do you need any 
help ?

-- 
Alexis Murzeau

Bug#928913: unblock: elpy/1.28.0-2

[Nicholas D Steeves]

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

Please unblock package elpy

I'm filing this unblock request before uploading to unstable.  This
proposed upload closes several documentation-related bugs, and
disables DH_VERBOSE.  In particular, I believe these fixes are
valuable for developers with a Python background who are new to Emacs.
Closed bugs are:

#927084 elpa-elpy: README.Debian misleads users into enabling nonexistent 
Python 2 support
#927085 elpa-elpy: Please provide a QuickStart page
#928633 elpa-elpy: please provide docs in html format

I'm also considering adding a couple of lines to README.Debian apropos
how to configure a persistent Python shell pane, which is the familiar
and expected interface for devs coming from Eclipse+PyDev, Spyder,
PyCharm, Thonny, et al.

debdiff elpa-elpy_1.28.0-1_all.deb TO elpa-elpy_1.28.0-2_all.deb:
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/concepts.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/editing.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/extending.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/ide.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/index.rst.txt
-rw-r--r--  root/root   
/usr/share/doc/elpa-elpy/html/_sources/introduction.rst.txt
-rw-r--r--  root/root   
/usr/share/doc/elpa-elpy/html/_sources/quickstart.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/ajax-loader.gif
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/basic.css
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/classic.css
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/comment-bright.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/comment-close.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/comment.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/default.css
-rw-r--r--  root/root   
/usr/share/doc/elpa-elpy/html/_static/documentation_options.js
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/down-pressed.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/down.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/file.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/language_data.js
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/minus.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/plus.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/pygments.css
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/up-pressed.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/up.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/concepts.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/editing.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/extending.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/genindex.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/ide.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/index.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/introduction.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/objects.inv
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/quickstart.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/search.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/searchindex.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/doctools.js -> 
../../../../javascript/sphinxdoc/1.0/doctools.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/jquery.js -> 
../../../../javascript/sphinxdoc/1.0/jquery.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/searchtools.js -> 
../../../../javascript/sphinxdoc/1.0/searchtools.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/sidebar.js -> 
../../../../javascript/sphinxdoc/1.0/sidebar.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/underscore.js -> 
../../../../javascript/sphinxdoc/1.0/underscore.js

Control files: lines which differ (wdiff format)

Installed-Size: [-567-] {+815+}
Version: [-1.28.0-1-] {+1.28.0-2+}
--

debdiff elpy_1.28.0-1.dsc TO elpy_1.28.0-2.dsc:
diff -Nru elpy-1.28.0/debian/changelog elpy-1.28.0/debian/changelog
--- elpy-1.28.0/debian/changelog2019-01-05 17:13:12.0 -0500
+++ elpy-1.28.0/debian/changelog2019-04-17 19:13:51.0 -0400
@@ -1,3 +1,16 @@
+elpy (1.28.0-2) UNRELEASED; urgency=medium
+
+  * debian/rules: Disable DH_VERBOSE.
+  * Use sphinx to build and generate documentation in html format.
+(Closes: #928633)
+  * debian/README.Debian: Make 

Bug#928901: shutdown-qapps FTCBFS: missing Build-Depens: qt5-qmake:native

[Christian Metscher]

Thank you Helmut!

I will take a look this evening (Tokyo time). 
There were some updates to the source that I wanted to do anyway.


Best regards,
Christian



On 2019年5月13日 3:47:53 JST, Helmut Grohne  wrote:
>Source: shutdown-qapps
>Version: 1.7.3-1
>Tags: patch
>User: helm...@debian.org
>Usertags: rebootstrap
>
>shutdown-qapps fails to cross build from source, because it fails
>running lrelease. For using lrelease you must add qt5-qmake:native to
>Build-Depends. Please consider applying the attached patch.
>
>Helmut

-- 
K-9 Mail で Android デバイスから送信しました。簡単で申し訳ありません。

Bug#925546: How to reproduce?

[Alexis Murzeau]

Hi,

On Wed, 17 Apr 2019 15:27:19 +0300 Joonas Kylmälä wrote:
> Hi,
> > Hilko Bengen:
> > I can get rid of the issues by backporting a number of commits from
> > github.com/nsf/gocode and will submnit an updated package for
> > stretch-proposed-updates.
> > Thanks for investigating.
> > > Are you able to build .deb packages from source or should I provide a
> > binary package for you to test?
> > I can build from source.

Autoremoval is going to beat this package, so checking any news.
I saw on internet that this package still has advantages over alternatives.

Did you got something working or need any help ?
-- 
Alexis Murzeau

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

[Guilhem Moulin]

Thanks for your analysis, Steffen.  Dropping the Debian-specific patch
is definitely the way to go for libwww/LWP.  However I still believe
IO::Socket::SSL should provide a way to clear SSL_MODE_AUTO_RETRY in
order to fix applications relying on the former OpenSSL defaults, as
suggested in the OpenSSL changelog:

“SSL_MODE_AUTO_RETRY is enabled by default. Applications that use
blocking I/O in combination with something like select() or poll()
will hang. This can be turned off again using SSL_CTX_clear_mode().”

Otherwise the “usual” way to write event loops in blocking I/O won't be
possible with IO::Socket::SSL.

On Sat, 11 May 2019 at 21:56:01 +0200, Steffen Ullrich wrote:
> As far as I can see it has nothing to do with SSL_MODE_AUTO_RETRY but
> instead is caused by expectations on the behavior of select which are
> wrong with TLS 1.3.

Please consider the enclosed netcat-like program.  I don't think I'm
relying on any particular behavior of a specific TLS version, and
follow the practices for polling blocking sockets, as documented in
libssl, Net::SSLeay, and IO::Socket::SSL, namely:

  - If SSL_pending() > 0, skip the (blocking) select() call and instead
call SSL_read() to process remaining bytes in the current SSL frame.
  - If SSL_read() fails and sets SSL_ERROR_WANT_READ, don't treat it as
a read error.

The last point however relies on SSL_MODE_AUTO_RETRY being *unset*, like
it used to be with OpenSSL <1.1.1a.  With SSL_MODE_AUTO_RETRY being set,
the program doesn't work properly.  (*Not only for TLSv1.3, but also for
TLSv1.2*).  This is expected with the new default:

“If the underlying BIO is blocking, a read function will only return
once the read operation has been finished or an error occurred,
except when a non-application data record has been processed and
SSL_MODE_AUTO_RETRY is not set. Note that if SSL_MODE_AUTO_RETRY is
set and only non-application data is available the call will hang.”
— https://www.openssl.org/docs/manmaster/man3/SSL_read.html

As seen below, this also breaks with ≤TLSv1.2; but only when the TLS
session is renegotiated, not during the initial handshake.

Generate a self-signed certificate:

$ openssl req -x509 -keyout /tmp/key.pem -out /tmp/cert.pem -subj 
/CN=127.0.0.1 -nodes

Start a TLSv1.2 server on [127.0.0.1]:4433:

$ openssl s_server -accept 127.0.0.1:4433 -key /tmp/key.pem -cert 
/tmp/cert.pem -tls1_2

Now start the enclosed program in another terminal.  What's being
written in the s_server(1ssl) TTY is echoed on the netcat.pl side, and
vice versa.  All good.  Now trigger renegotiate the TLS session by
pressing ‘r\n’.  The server prints

SSL_do_handshake -> 1
Read BLOCK

and netcat ends up being stuck in a blocking read().  So what's being
written client-side won't show up anymore in the server window, until
data is being sent from the server to the client and makes read()
return.

openssl s_server … -tls1_2  netcat.pl
--- -
S: Using default temp DH parameters  
S: ACCEPT 
S: -BEGIN SSL SESSION PARAMETERS-
S: […]
S: ---
S: No server certificate CA names sent
S: CIPHER is ECDHE-RSA-AES128-GCM-SHA256
S: Secure Renegotiation IS supported
S: Entering loop...
C: can you hear me now?
S: can you hear me now?
C: yes
S: yes 
C: good
S: good
C: starving you now
S: starving you now
C: r
S: SSL_do_handshake -> 1
S: Read BLOCK
C: meh, I'm muted
C: unstarving
S: meh, I'm muted
S: unstarving

(The ‘C: ’ prefix indicates a line written to the standard input, and
the ‘S: ’ prefix a line written to the standard output or error output.)

After renegotiation, the client is stuck in a blocking read() until the
server sends some data.  Same thing with TLSv1.3, but of course without
the renegotiation part: this happens right at the begining.

openssl s_server … -tls1_3  netcat.pl
--- -
S: Using default temp DH parameters  
S: ACCEPT 
S: -BEGIN SSL SESSION PARAMETERS-
S: […]
S: ---
S: No server certificate CA names sent
S: CIPHER is TLS_AES_256_GCM_SHA384
S: Secure Renegotiation IS supported
S: Entering loop...
C: can you hear me now?
C: I guess no...
C: unstarving
S: can you hear me now?
S: I guess no...
 

Bug#928912: shorewall: Shorewall does not automatically start after (re-)boot

[Richard Harb]

Package: shorewall
Version: 5.0.15.6-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

  Clean install of the package, copied known good relevant interfaces, 
rules, zones, etc files
  Edited /etc/default/shorewall and set startup=1


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

  # shorewall restart
  worked perfectly


   * What was the outcome of this action?

  System reboot: not running


   * What outcome did you expect instead?

  Status running.

   * Remedy found in a web search:

  manually run:
  # systemctl enable shorewall.service

  next reboot, shorewall was running as it should.


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


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

Kernel: Linux 4.9.0-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)

Versions of packages shorewall depends on:
ii  bc 1.06.95-9+b3
ii  debconf [debconf-2.0]  1.5.61
ii  iproute2   4.9.0-1+deb9u1
ii  iptables   1.6.0+snapshot20161117-6
ii  lsb-base   9.20161125
ii  perl   5.24.1-3+deb9u5
ii  shorewall-core 5.0.15.6-1

Versions of packages shorewall recommends:
ii  libnetfilter-cthelper0  1.0.0-1

Versions of packages shorewall suggests:
ii  make   4.1-9.1
pn  shorewall-doc  

-- Configuration Files:
/etc/shorewall/conntrack [Errno 13] Permission denied: 
'/etc/shorewall/conntrack'
/etc/shorewall/params [Errno 13] Permission denied: '/etc/shorewall/params'
/etc/shorewall/shorewall.conf

-- debconf information:
  shorewall/major_release:
  shorewall/invalid_config:
  shorewall/dont_restart:

Bug#928894: [pkg-gnupg-maint] Bug#928894: custom keyring is not honoured

[Daniel Kahn Gillmor]

Control: tags 928894 + moreinfo

Hi Toni--

On Sun 2019-05-12 19:46:45 +0100, Toni wrote:
> --recv-keys does not seem to honour the keyring options, so the received
> key ends up in the wrong keyring:
>
> $ touch ~/mnt/tools/gitea-keys.gpg
> $ gpg  --no-default-keyring  --keyring ~/mnt/tools/gitea-keys.gpg --recv-keys 
> CC64B1DB67ABBEECAB24B6455FC346329753F4B0
> gpg: key 0x2D9AE806EC1592E2: 6 signatures not checked due to missing keys
> gpg: key 0x2D9AE806EC1592E2: public key "Teabot " imported
> gpg: Total number processed: 1
> gpg:   imported: 1
> $ gpg --list-options show-keyring -k tea...@gitea.io
> gpg: please do a --check-trustdb
> Keyring: /home/toni/.gnupg/pubring.gpg
> --
> pub   rsa4096/0x2D9AE806EC1592E2 2018-06-24 [SC] [expires: 2020-06-23]
>   7C9E68152594688862D62AF62D9AE806EC1592E2
> uid   [ unknown] Teabot 
> sub   rsa4096/0x1FBE01D7CBADB9A0 2018-06-24 [E] [expires: 2020-06-23]
> sub   rsa4096/0x5FC346329753F4B0 2018-06-24 [S] [expires: 2019-06-24]

I'm not sure that this demonstrates what you're describing.

Here is a run with gpg 2.2.15-1 that demonstrates the key being fetched
into the extra keyring:

0 dkg@alice:/tmp/cdtemp.AhkyjS$ export GNUPGHOME=$(pwd)
0 dkg@alice:/tmp/cdtemp.AhkyjS$ touch $(pwd)/extra.gpg
0 dkg@alice:/tmp/cdtemp.AhkyjS$ gpg --no-default-keyring --keyring 
$(pwd)/extra.gpg --recv-keys CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: /tmp/cdtemp.AhkyjS/trustdb.gpg: trustdb created
gpg: key 2D9AE806EC1592E2: public key "Teabot " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:   imported: 1
0 dkg@alice:/tmp/cdtemp.AhkyjS$ gpg --list-options show-keyring -k 
tea...@gitea.io
gpg: keybox '/tmp/cdtemp.AhkyjS/pubring.kbx' created
gpg: error reading key: No public key
2 dkg@alice:/tmp/cdtemp.AhkyjS$ ls -la
total 24
drwx--  4 dkg  dkg   160 May 12 18:48 .
drwxrwxrwt 28 root root 1420 May 12 18:47 ..
drwx--  2 dkg  dkg60 May 12 18:48 crls.d
-rw-r--r--  1 dkg  dkg  6467 May 12 18:48 extra.gpg
-rw-r--r--  1 dkg  dkg  6467 May 12 18:48 extra.gpg~
drwx--  2 dkg  dkg40 May 12 18:48 private-keys-v1.d
-rw---  1 dkg  dkg32 May 12 18:48 pubring.kbx
-rw---  1 dkg  dkg  1200 May 12 18:48 trustdb.gpg
0 dkg@alice:/tmp/cdtemp.AhkyjS$ 

perhaps the teabot key was already in your default keyring before you
run the --recv-keys operation?  that would certainly explain the
behavior that you're seeing.

 --dkg


signature.asc
Description: PGP signature

Bug#928892: RFS: heimdall-flash/1.4.2-1

[etchevef]

Ah, I see. That must have been when I pasted the example text, I noticed some 
weard  formating in my mail client, I should have been more careful. Anyway, 
thank you for the help.

Regards.


May 13, 2019, 12:11 AM by bernha...@mailbox.org:

> Hello Francois,
> it looks like your email did not contain any newlines.
> Therefore it seems like the whole email was interpreted as the "package".
>
> You can see what I mean in this page [1] near
> "Bug reassigned from package".
>
> Kind regards,
> Bernhard
>
> [1] > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928892 
> 
>

Bug#928868: unblock: ruby-globalid/0.4.2+REALLY.0.3.6-1

[Utkarsh Gupta]

Hey,

On Mon 13 May, 2019, 12:42 AM Paul Gevers,  wrote:

> Hi Utkarsh,
>
> On 12-05-2019 11:44, Utkarsh Gupta wrote:
> > Hence, requesting you to:
> > unblock ruby-globalid/0.4.2+REALLY.0.3.6-1
>
> It would have been easier if you would have left the old patches in
> place, but anyways. Thanks for following up and reverting the new
> upstream version in unstable.
>

Ah.

unblocked.
>

Thank you :)


Best,
Utkarsh

Bug#928892: RFS: heimdall-flash/1.4.2-1

[Bernhard Übelacker]

Hello Francois,
it looks like your email did not contain any newlines.
Therefore it seems like the whole email was interpreted as the "package".

You can see what I mean in this page [1] near
"Bug reassigned from package".

Kind regards,
Bernhard

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928892

Bug#928892: RFS: heimdall-flash/1.4.2-1

[etchevef]

I'm not sure I understand what the problem is, but please do what you think 
necessary.
 Did I make a mistake ? It is my first RFS so that is very probable, but I 
don't see it.

Thanks for your help.
Regards, 
François Etcheverry

May 12, 2019, 11:48 PM by bernha...@mailbox.org:

> Control: reassign 928892 sponsorship-requests
>
>
> Hello Francois,
> it looks like somthing ate all newlines in your email.
> I hope it is ok if I reassign to sponsorship-requests.
>
> Kind regards,
> Bernhard
>

Bug#928911: grub-efi-amd64: destroys EFI partition despite being told not to

[Adam Borowski]

Package: grub-efi-amd64
Version: 2.02+dfsg1-18
Severity: important

Hi!
Just did a d-i bare-metal test run; installing to another disk, with the
obvious requirement of not damaging the primary system.  Thus, I explicitly
marked all relevant partitions (EFI, sys, and swap) as "do not use".

Yet the newly installed system overwrote the ESP anyway.  It also did so in
a way that neither the old nor new system could be booted (no entries for
any of the existing two systems were created, and I did not succeed booting
manually).

Disks present in the system:
* NVME-SSD:
  [all "do not use"] ESP (fat), sys (btrfs), swap
* 4x NVME-Optane:
  MD RAID0 <- new system (d-i test) was installed here
* HDD:
  * another old system (ext4) -- x32, BIOS-boot
  * boot partition for the d-i test run
  * data partition (btrfs)

It can be argued that the setup above may be a bit overcomplicated (thus
the installer being confused might be understandable).
But I insist that disregarding the explicit "do not use" and scribbling
over anyway is a severe bug.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p2 / btrfs rw,noatime,ssd,space_cache,subvolid=259,subvol=/sys 0 0
/dev/nvme0n1p2 /var/cache btrfs 
rw,noatime,ssd,space_cache,subvolid=393,subvol=/sys-cache 0 0
/dev/nvme0n1p2 /mnt/btr1 btrfs rw,noatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p2 /home btrfs rw,noatime,ssd,space_cache,subvolid=261,subvol=/home 
0 0
/dev/nvme0n1p2 /home/kilobyte/@ btrfs 
rw,noatime,ssd,space_cache,subvolid=365,subvol=/kb-@ 0 0
/dev/nvme0n1p2 /home/kilobyte/tmp btrfs 
rw,noatime,ssd,space_cache,subvolid=364,subvol=/kb-tmp 0 0
/dev/nvme0n1p2 /home/kilobyte/.cache btrfs 
rw,noatime,ssd,space_cache,subvolid=394,subvol=/kb-cache 0 0
/dev/nvme0n1p2 /home/kilobyte/mp3 btrfs 
rw,noatime,ssd,space_cache,subvolid=329,subvol=/mp3 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/pmem0 /mnt/pmem ext4 
rw,relatime,block_validity,delalloc,nojournal_checksum,barrier,dax,user_xattr,acl
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod btrfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  4cf50beb-18f7-4bdf-9f33-362ba9c30c15
else
  search --no-floppy --fs-uuid --set=root 4cf50beb-18f7-4bdf-9f33-362ba9c30c15
fi
font="/sys/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=C
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod btrfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  4cf50beb-18f7-4bdf-9f33-362ba9c30c15
else
  search --no-floppy --fs-uuid --set=root 4cf50beb-18f7-4bdf-9f33-362ba9c30c15
fi
insmod png
if background_image 
/sys/usr/share/desktop-base/futureprototype-theme/grub/grub-16x9.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-4cf50beb-18f7-4bdf-9f33-362ba9c30c15' {
load_video
   

Bug#926180: scilab: FTBFS on all - New trouble - upstream bugfix release while in freeze

[Alexis Murzeau]

Hi,

Le 12/05/2019 à 22:10, Julien Puydt a écrit :
> Hi,
> 
> On 12/05/2019 11:46, Alexis Murzeau wrote:
> 
>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
> 
> I had started to package 6.0.2 on salsa already in february.

I was wondering, will such bug-fix upstream release be accepted in
buster, now that we are in full freeze ?
That bug-fix release seems a welcomed version given the many bugs fixed
since 6.0.1, but it is not a small targeted fix release.

I'm adding debian-mentors for advice about this.

[0]
https://help.scilab.org/docs/6.0.2/en_US/CHANGES.html#Bugs_fixed_in_6.0.2

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

Bug#928892: RFS: heimdall-flash/1.4.2-1

[Bernhard Übelacker]

Control: reassign 928892 sponsorship-requests


Hello Francois,
it looks like somthing ate all newlines in your email.
I hope it is ok if I reassign to sponsorship-requests.

Kind regards,
Bernhard

Bug#928805: texlive-lang-czechslovak: fails to install: fmtutil failed

[Norbert Preining]

> Committed to git, tag pending.

Thanks!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#928666: Want dgit FAQ

[Ian Jackson]

Sean Whitton writes ("Re: Bug#928666: Want dgit FAQ"):
> I would like to just get this published on the Debian wiki as soon as
> possible; let me know if you really want to avoid that, Ian.

Great!  Please go ahead.  That's great.  (I haven't reviewed these,
but it's a wiki...)

Ian.

Bug#928910: feature request: support odroid-hc1

[Andreas Jellinghaus]

Package: flash-kernel
Version: 3.98

Would it be possible to support odroid-hc1 single board computers with
flash-kernel?

Here is how I configure the board manually:
https://wiki.debian.org/InstallingDebianOn/OdroidHC1

flash-kernel wouldn't need to deal with samsung firmware blobs, as those
get installed once and are never touched again.
To update u-boot on an sd-card it only needs to: dd iflag=dsync oflag=dsync
if=$uboot of=$device seek=63

Is any other info required for this?

Thanks, Andreas

Bug#928805: texlive-lang-czechslovak: fails to install: fmtutil failed

[Hilmar Preuße]

tags 928805 + pending
stop

On 11.05.19 15:55, Andreas Beckmann wrote:

Hi,

> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
Committed to git, tag pending.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#928909: bleachbit: new upstream 2.2

[Jonatan Nyberg]

Package: bleachbit
Version: 2.2
Severity: normal

Please consider to upgrade to the current upstream version (2.2).

Regards
Jonatan

Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))

[-]

Am Freitag, den 10.05.2019, 12:13 +0200 schrieb Michel Dänzer:
> On 2019-05-07 7:13 a.m., - wrote:
> > This morning GNOME Shell crashed again, see attached logs.
> > Connecting/disconecting the Thunderbolt Gen2 Dock was working fine
> > for
> > 1-2 weeks, now it crashed again.
> > 
> > Hope the logs help to narrow down the issue finally.
> 
> It looks like it could be (related to)
> https://gitlab.freedesktop.org/xorg/xserver/issues/11 , which is said
> to
> be fixed with Xwayland 1.20.4. Have you tried that?
> 

This evening I have installed Xwayland 1.20.4 and xserver-common 1.20.4
from unstable. I will report back if the issue is solved and how the
system behaves.

Thanks for the hint.

Christian Höffer

Bug#928908: unblock: libdebian-installer/0.119

[Asbjørn Sloth Tønnesen]

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

Please unblock libdebian-installer/0.119 fixing RC bug #55
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=55

Changes:
  libdebian-installer (0.119) unstable; urgency=medium

  [ Cyril Brulebois ]
   * Drop support for arm*/ixp4xx and arm*/iop32x; support for those
 platforms was removed from the Linux kernel and therefore d-i.
   * Remove Christian Perrier from Uploaders, with many thanks for all
 his contributions over the years! (Closes: #927544)
 .
   [ Bastian Blank ]
   * Enlarge maximum line length in Packages and Sources files.
 (closes: #55)

Diff stat:
 debian/changelog   | 14 ++
 debian/control |  2 +-
 src/parser_rfc822.c|  2 +-
 src/system/subarch-arm-linux.c | 17 -
 4 files changed, 16 insertions(+), 19 deletions(-)


Bastian Blank (2):
  Enlarge maximum line length in Packages and Sources files
  releasing version 0.119

Cyril Brulebois (2):
  Drop support for arm*/ixp4xx and arm*/iop32x.
  Remove Christian Perrier from Uploaders.

Holger Wansing (1):
  Add reference to bugreport

--
Best regards
Asbjørn Sloth Tønnesen

Bug#928905: kguiaddons FTCBFS: missing Build-Depends: qttools5-dev

[Helmut Grohne]

Source: kguiaddons
Version: 5.54.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

kguiaddons fails to cross build from source, because it misses a
dependency on qttools5-dev. See #915122 for details. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru kguiaddons-5.54.0/debian/changelog 
kguiaddons-5.54.0/debian/changelog
--- kguiaddons-5.54.0/debian/changelog  2019-01-17 23:26:51.0 +0100
+++ kguiaddons-5.54.0/debian/changelog  2019-05-12 21:58:26.0 +0200
@@ -1,3 +1,11 @@
+kguiaddons (5.54.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add missing build dependency qttools5-dev. See #915122.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 21:58:26 +0200
+
 kguiaddons (5.54.0-1) unstable; urgency=medium
 
   * New upstream release (5.52.0).
diff --minimal -Nru kguiaddons-5.54.0/debian/control 
kguiaddons-5.54.0/debian/control
--- kguiaddons-5.54.0/debian/control2019-01-17 23:26:51.0 +0100
+++ kguiaddons-5.54.0/debian/control2019-05-12 21:58:25.0 +0200
@@ -16,6 +16,7 @@
pkg-kde-tools (>= 0.15.15ubuntu1~),
qtbase5-dev (>= 5.9.0~),
qtbase5-private-dev,
+   qttools5-dev,
qttools5-dev-tools (>= 5.4),
 Standards-Version: 4.1.4
 Homepage: http://projects.kde.org/kguiaddons

Bug#901592: Bug#928428: unblock: [pre-approval] wicd/1.7.4+tb2-7

[Axel Beckert]

Hi Niels,

Niels Thykier wrote:
> Axel Beckert:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > In the light of dhcpcd5 automremoval (#928056, #928104, #928105), I'd
> > like to upload a wicd package which relies less on dhcpcd5.  [...]
[...]
> AFAICT, the dhcpcd5 issues have been fixed and wicd is at the moment not
> at risk of being removed from testing on that account.

Ack. Actually I didn't expected those CVEs to be fixed that quickly
given how RC bugs in that package were handled in the past. I guess
these memories are from the times where the Debian packages of dhcpcd*
was (not really) maintained by the upstream maintainer.

> If so, then I would prefer deferring these changes to bullseye in
> general to reduce the risks of regressions in testing at the moment.

I actually thought that way, too, and nearly would have closed the
request myself.

But then again it seems that if only the default DHCP client
dependency is installed, it won't find the according binary. (See
https://bugs.debian.org/852343 — probably has the wrong severity,
should be at least important from my point of view.)

Then again, in most cases, when wicd is being installed, that
alternative dependency where dhcpcd5 comes first (#901592) is usually
already fulfilled by isc-dhcp-client which is installed by default and
hence present on most installations.

So while the impact of #852343 (at least together with #901592) is
probably RC on the paper, there are actually only very few people who
actually will run into it (and nobody who complained by having run
into it so far), e.g. those who have no DHCP client installed at all
when wicd is being installed or which uninstall all other DHCP clients
afterwards.

The only real impact I can imagine is on derivatives which install
wicd by default and follow Debian release cycles — of which I can't
remember any at the moment — at least Raspbian uses pure dhcpcd5 +
dhcpcd-gtk (and not Debian's packages of dhcpcd* as I just noticed).

So I'm generally fine with postponing this until bullseye. If you
agree with my reasoning above, please close this unblock request.

Will drop the created git branch "buster" only after the release of
buster, though, just to be on the safe side.

Salvo Tomaselli wrote:
> Well I use isc-dhcp-client and it works fine

I'm sorry, but IMHO this fact is not really relevant for this
discussion.

> so I guess it is an ok change.

... and since it ignores the core issues of th proposed change, this
reasoning is IMHO bogus.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#928907: karchive FTCBFS: missing Build-Depends: qttools5-dev

[Helmut Grohne]

Source: karchive
Version: 5.54.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

karchive fails to cross build from source, because it misses a build
dependency on qttools5-dev. See #915122 for context. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru karchive-5.54.0/debian/changelog 
karchive-5.54.0/debian/changelog
--- karchive-5.54.0/debian/changelog2019-01-17 23:26:23.0 +0100
+++ karchive-5.54.0/debian/changelog2019-05-12 21:51:41.0 +0200
@@ -1,3 +1,10 @@
+karchive (5.54.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add missin Build-Depends: qttools5-dev. See #915122. (Closes: 
#-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 21:51:41 +0200
+
 karchive (5.54.0-1) unstable; urgency=medium
 
   * New upstream release (5.52.0).
diff --minimal -Nru karchive-5.54.0/debian/control 
karchive-5.54.0/debian/control
--- karchive-5.54.0/debian/control  2019-01-17 23:26:23.0 +0100
+++ karchive-5.54.0/debian/control  2019-05-12 21:51:39.0 +0200
@@ -13,6 +13,7 @@
libqt5sql5-sqlite:native,
pkg-kde-tools (>= 0.15.16~),
qtbase5-dev (>= 5.9.0~),
+   qttools5-dev,
qttools5-dev-tools (>= 5.4),
zlib1g-dev,
 Standards-Version: 4.1.4

Bug#928906: pd-chaos FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: pd-chaos
Version: 0.2-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pd-chaos fails to cross build from source, because it uses the wrong
strip during make install. Beyond breaking cross compilation, this also
breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym
packages. The attached patch defers all stripping to dh_strip and fixes
all of the above. Please consider applying it.

Helmut
diff --minimal -Nru pd-chaos-0.2/debian/changelog pd-chaos-0.2/debian/changelog
--- pd-chaos-0.2/debian/changelog   2018-01-29 21:44:08.0 +0100
+++ pd-chaos-0.2/debian/changelog   2019-05-12 21:57:40.0 +0200
@@ -1,3 +1,10 @@
+pd-chaos (0.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't strip during make install. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 21:57:40 +0200
+
 pd-chaos (0.2-3) unstable; urgency=medium
 
   * Demote pd-libdir to Recommends
diff --minimal -Nru pd-chaos-0.2/debian/rules pd-chaos-0.2/debian/rules
--- pd-chaos-0.2/debian/rules   2018-01-29 21:44:08.0 +0100
+++ pd-chaos-0.2/debian/rules   2019-05-12 21:57:39.0 +0200
@@ -13,7 +13,7 @@
$(empty)
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=:
 # replace license file with link to the Debian license file
rm -f -- $(CURDIR)/debian/*/$(pkglibdir)/*/LICENSE.txt
 

Bug#926180: scilab: FTBFS on all - New trouble

[Julien Puydt]

Hi,

On 12/05/2019 11:46, Alexis Murzeau wrote:

> I saw that there is a bugfix release 6.0.2 with many fixes [0].

I had started to package 6.0.2 on salsa already in february. I removed
the patch about Linenum as that was supposed to have been reworked and
fixed, and it now fails with :

ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I
./src/xml2modelica  nums.cmxa ./src/xml2modelica/xMLTree.ml
./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml
./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml
./src/xml2modelica/xMLLexer.ml
./src/xml2modelica/modelicaCodeGenerator.ml
./src/xml2modelica/xML2Modelica.ml
File "./src/xml2modelica/xML2Modelica.ml", line 1:
Error: Files ./src/xml2modelica/xMLParser.cmx
   and ./src/xml2modelica/linenum.cmx
   make inconsistent assumptions over implementation Linenum

ie : it looks like upstream's fix isn't correct.

I don't know when I'll find the time to dig it.

Cheers,

JP

Bug#907733: curlpp package still orphaned?

[Ximin Luo]

JB:
> Hi,
> 
> I would be interested in taking over this package but I'm confused ; it 
> seemed to have attracted other interested people as well, but the package is 
> still being listed as looking for a maintainer.
> 
> So, I just wanted to know if someone (Jaime?) had taken over or if this 
> package was still waiting for a maintainer.
> 

Jaime started an update but there are remaining issues to be resolved with the 
merge PR:

https://salsa.debian.org/infinity0/curlpp/merge_requests/1

Feel free to take it over if he doesn't have time to finish it.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#858245: gmusicbrowser: Search-as-you-type causes crash

[Vladimir K]

The fix works,
Thank you!

Bug#928904: onionshare: new upstream 2.1

[Jonatan Nyberg]

Package: onionshare
Version: 2.1
Severity: High

Please consider to upgrade to the current upstream version (2.1).

Regards
Jonatan

Bug#928903: ITP: piperka-client -- Mobile oriented web comics reader client

[Kari Pahula]

Package: wnpp
Severity: wishlist
Owner: Kari Pahula 

* Package name: piperka-client
  Version : 0.2.1
  Upstream Author : Kari Pahula 
* URL : https://gitlab.com/piperka/client
* License : GPLv2 or later
  Programming Lang: C++
  Description : Mobile oriented web comics reader client

 Piperka is a web comic tracking and bookmarking service with over
 6000 comics listed on it.  It doesn't host any web comics by itself
 but maintains a list of them and an index of their archive pages.
 .
 Piperka Client uses Piperka's database to provide browsing and
 navigation for web comics' archives in a unified manner with an
 embedded browser. It stores user's bookmarks and periodically contacs
 the server to check for any updates to the comics that a user reads.
 .
 This program is geared towards mobile use.


I originally wrote this app for Sailfish and then implemented a
generic Qt mobile oriented version of it, mainly to get it to Android.
Packaging it for Debian is a low hanging fruit so why not.

I haven't actually tagged a 0.2.1 yet but will do so soon.

Bug#740504: Please Confirm This Information if you are Dead or Alive.

[Cordiez Tagba]

*Confirm This Information.*

*It is totally against the ethics and civil service code of conduct in
accordance with oath of secrecy for me to do this but I wish to do this on
personal capacity believing you will not betray me but will surely come
back to reward me for my sincerity, honesty and for my great effort made to
secure a successful conclusion of this transaction in your favor. Please
confirm if truly the bank has communicated you regarding payment of your
overdue fund.*
*However, I wish to inform you that your Attorney. Has presented a woman
submitting her name claiming that you were death and to be your next of
kin, her details and banking particular was among the list certified for
payments,see below and confirm for the account she submitted for transfer
of your fund Valued at US$9.600 Million United States Dollars.*

*Beneficiary: Ms.Ronnette James*
*Bank Name: The Commerce Bank*
*Bank Address: 1072, Richmond av.*
*Staten Island, New York*
*Account Number: 4121097896,*
*Routing No:003-051-200,*
*Swift Code: CBNAUS33*

*I have inquired deeper to come to the conclusion that she and few powerful
individuals are behind this dastardly act without due notices to you, As it
stands now,you will certainly encounter enormous problems to convince the
International Remittance Department that you have not been served with
required number of direct notices. You are therefore advised to submit your
approval, as the bank will certainly not be held responsible for paying
into a wrong account, It will serve you well if you would quickly get back
to me.so that I can issue instruction for re-verification on your payment
file towards Online Transfer of your fund (US$9.600 Million United States
Dollars) to you.*
*Please we need to hear from you before the transfer take place to
confirmed if you are death for real or they are trying to remove you from
the inheritance approved funds.*

*Thanks for your co-operations.*

*Sincerely,*
*MR.Cordiez Tagba*
*SECRETARIAT GENERAL*
*FOREIGN REMITTANCE DEPT.*
*BANQUE ATLANTIQUE TOGO*
*Security and Finance Company,*
*Email;hon.cordiezta...@aol.com *
*Direct line:+228 98596621.*

*NOTE: IF YOU RECEIVED THIS MESSAGE IN YOUR SPAM/BULK FOLDER, THAT IS
BECAUSE OF THE RESTRICTIONS IMPLEMENTED BY YOUR INTERNET SERVICE PROVIDER*

Bug#928717: in normal builds local urresponsive flas are parsed to build process

[Juhani Numminen]

Control: tags -1 moreinfo

Hello,

I don't know asterisk at all but maybe I can help with triaging this bug.

On Thu, 9 May 2019 12:10:08 -0400 PICCORO McKAY Lenz  
wrote:
> Cited from upstream For a native x86_64 build, you need to REMOVE {{-fPIE}}
> from the CFLAGS and {{-fPIE -pie}} from LDFLAGS.
> 
> Seems dpkg-buildflags are passed that arguments to build processs in 64bits
> amd64,
> 
> due in i386 builds compiles fine!

With pbuilder, amd64 compiles fine for me. It seems that those PIE flags are
neither added by asterisk's debian/rules nor dpkg-buildflags.

I think your system may have custom CFLAGS and LDFLAGS environment variables,
can you confirm?  Please see if removing the PIE flags from your environment
causes the error to go away.


Regards,
Juhani

Bug#928808: tracker.debian.org: automatic filing bugs

[Raphael Hertzog]

Hi,

On Sat, 11 May 2019, Dmitry Bogatov wrote:
> would it be possible to automatically file bugs with issues, already
> detected by tracker?

Right now, there's no email notification and I certainly agree
that there should be some email notification about new upstream releases.
Wouldn't that be sufficient? Do you really want a bug filed?

> Question is access-control. Probably, only maintainer/uploader of
> package can make decision, whether bugs should be auto-reported.
> I see it as something like this:

While we have a mailbot, I see it mainly as legacy, the control interface
for such a feature would likely be on the web interface.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#928367: libpapi5: SOVERSION is too wide for the runtime check in PAPI_library_init()

[Andreas Beckmann]

Control: tag -1 pending patch fixed-upstream

On 2019-05-12 20:15, Andreas Tille wrote:
> in the thread on the upstream mailing list[1] you proposed a patch that
> was confirmed working by upstream.  Do you think this patch should be
> submitted to Debian BTS and the bug tagged patch?

It's already sitting in experimental/NEW .

Andreas

Bug#928046: ~ Re: Bug#928046: dosbox: input issues under Wayland (some keys not behaving)

[Jonathan Dowland]

Hi all

On Sat, May 11, 2019 at 11:36:00AM +, Niels Thykier wrote:

Have you tried Stephen's suggestion of setting "usescancodes" and see if
that fixes the issue?


I hadn't, until now, but I can now confirm that this does resolve the issue.


Thanks,

--

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

Bug#928868: unblock: ruby-globalid/0.4.2+REALLY.0.3.6-1

[Paul Gevers]

Hi Utkarsh,

On 12-05-2019 11:44, Utkarsh Gupta wrote:
> Hence, requesting you to:
> unblock ruby-globalid/0.4.2+REALLY.0.3.6-1

It would have been easier if you would have left the old patches in
place, but anyways. Thanks for following up and reverting the new
upstream version in unstable.

unblocked.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#928897: pipemeter FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: pipemeter
Version: 1.1.3-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

pipemeter fails to cross build from source, because it strips with the
build architecture strip. Beyond breaking cross compilation, stripping
at make install time also breaks DEB_BUILD_OPTIONS=nostrip and
generating a useful -dbgsym package. The attached patch drops the -s
flag from the install invocation. Please consider applying it.

Helmut
--- pipemeter-1.1.3.orig/Makefile.in
+++ pipemeter-1.1.3/Makefile.in
@@ -24,7 +24,7 @@
 	
 
 install: pipemeter pipemeter.1
-	install -D -p -s pipemeter $(DESTDIR)${PREFIX}/bin/pipemeter
+	install -D -p pipemeter $(DESTDIR)${PREFIX}/bin/pipemeter
 	install -D -p pipemeter.1 $(DESTDIR)${PREFIX}/share/man/man1/pipemeter.1
 
 dist: pipemeter

Bug#928902: spectrwm FTCBFS: uses build architecture build tools

[Helmut Grohne]

Source: spectrwm
Version: 3.2.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

spectrwm fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - is insufficient here. The relevant Makefile also hard
codes pkg-config. The attached patch fixes both and makes spectrwm cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru spectrwm-3.2.0/debian/changelog 
spectrwm-3.2.0/debian/changelog
--- spectrwm-3.2.0/debian/changelog 2018-09-29 15:32:14.0 +0200
+++ spectrwm-3.2.0/debian/changelog 2019-05-12 19:59:22.0 +0200
@@ -1,3 +1,12 @@
+spectrwm (3.2.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Sun, 12 May 2019 19:59:22 +0200
+
 spectrwm (3.2.0-1) unstable; urgency=low
 
   * New upstream release
diff --minimal -Nru spectrwm-3.2.0/debian/patches/cross.patch 
spectrwm-3.2.0/debian/patches/cross.patch
--- spectrwm-3.2.0/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ spectrwm-3.2.0/debian/patches/cross.patch   2019-05-12 19:59:22.0 
+0200
@@ -0,0 +1,27 @@
+--- spectrwm-3.2.0.orig/linux/Makefile
 spectrwm-3.2.0/linux/Makefile
+@@ -6,6 +6,7 @@
+ MANDIR   ?= $(DATAROOTDIR)/man
+ DOCDIR   ?= $(DATAROOTDIR)/doc/spectrwm
+ XSESSIONSDIR ?= $(DATAROOTDIR)/xsessions
++PKG_CONFIG   ?= pkg-config
+ 
+ BUILDVERSION= $(shell sh $(CURDIR)/../buildver.sh)
+ LIBVERSION  = $(shell .  $(CURDIR)/../lib/shlib_version; echo 
$$major.$$minor)
+@@ -21,12 +22,12 @@
+ 
+ BIN_CFLAGS   = -fPIE
+ BIN_LDFLAGS  = -fPIE -pie
+-BIN_CPPFLAGS = $(shell pkg-config --cflags x11 x11-xcb xcb-icccm xcb-keysyms 
xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
+-BIN_LDLIBS   = $(shell pkg-config --libs   x11 x11-xcb xcb-icccm xcb-keysyms 
xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
++BIN_CPPFLAGS = $(shell $(PKG_CONFIG) --cflags x11 x11-xcb xcb-icccm 
xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
++BIN_LDLIBS   = $(shell $(PKG_CONFIG) --libs   x11 x11-xcb xcb-icccm 
xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
+ LIB_CFLAGS   = -fPIC
+ LIB_LDFLAGS  = -fPIC -shared
+-LIB_CPPFLAGS = $(shell pkg-config --cflags x11)
+-LIB_LDLIBS   = $(shell pkg-config --libs   x11) -ldl
++LIB_CPPFLAGS = $(shell $(PKG_CONFIG) --cflags x11)
++LIB_LDLIBS   = $(shell $(PKG_CONFIG) --libs   x11) -ldl
+ 
+ all: spectrwm libswmhack.so.$(LIBVERSION)
+ 
diff --minimal -Nru spectrwm-3.2.0/debian/patches/series 
spectrwm-3.2.0/debian/patches/series
--- spectrwm-3.2.0/debian/patches/series2018-09-29 15:32:14.0 
+0200
+++ spectrwm-3.2.0/debian/patches/series2019-05-12 19:59:22.0 
+0200
@@ -2,3 +2,4 @@
 U01-install-more-files.diff
 D01-adapt-libswmhack.diff
 D02-change-default-programs.diff
+cross.patch
diff --minimal -Nru spectrwm-3.2.0/debian/rules spectrwm-3.2.0/debian/rules
--- spectrwm-3.2.0/debian/rules 2018-09-29 15:32:14.0 +0200
+++ spectrwm-3.2.0/debian/rules 2019-05-12 19:59:20.0 +0200
@@ -19,7 +19,7 @@
 # the top-level Makefile, which only works on OpenBSD. We also pass a
 # few extra variables to customize the installation paths.
 override_dh_auto_build:
-   $(MAKE) -C linux/
+   dh_auto_build --sourcedirectory=linux
 
 override_dh_auto_install:
$(MAKE) -C linux/ install

Bug#928900: efte FTCBFS: runs cmake for the build architecture

[Helmut Grohne]

Source: efte
Version: 1.1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

efte fails to cross build from source, because the cmake invocation
lacks cross flags. The easiest way of fixing that is using
dh_auto_configure. The attached patch implements that, but doesn't make
efte cross buildable, because it fails running bin2c. Fixing that part
is harder with cmake unfortunately and I don't have a solution at this
time. Please consider applying the patch and close this bug when doing
so.

Helmut
diff -u efte-1.1/debian/changelog efte-1.1/debian/changelog
--- efte-1.1/debian/changelog
+++ efte-1.1/debian/changelog
@@ -1,3 +1,9 @@
+efte (1.1-3) UNRELEASED; urgency=medium
+
+  * Address FTCBFS: Let dh_autoconfigure call a cross cmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 20:09:21 +0200
+
 efte (1.1-2) unstable; urgency=low
 
   * QA upload.
diff -u efte-1.1/debian/rules efte-1.1/debian/rules
--- efte-1.1/debian/rules
+++ efte-1.1/debian/rules
@@ -10,8 +10,7 @@
 
 builddir/Makefile:
dh_testdir
-   mkdir -p builddir
-   cd builddir && cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_C_FLAGS="$(CFLAGS)" -DCMAKE_LD_FLAGS="$(LDFLAGS),defs" 
-DCMAKE_CXX_FLAGS="$(CXXFLAGS)" -DCMAKE_SKIP_RPATH=ON 
-DCMAKE_VERBOSE_MAKEFILE=ON
+   dh_auto_configure --builddirectory=builddir -- 
-DCMAKE_C_FLAGS="$(CFLAGS)" -DCMAKE_LD_FLAGS="$(LDFLAGS),defs" 
-DCMAKE_CXX_FLAGS="$(CXXFLAGS)" -DCMAKE_SKIP_RPATH=ON
 
 build: build-arch build-indep
 

Bug#928898: t2n FTCBFS: multiple reasons

[Helmut Grohne]

Source: t2n
Version: 0.6-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

t2n fails to cross build from source, because it does not pass cross
tools to make. The easiest way to fix that - using dh_auto_build - is
not sufficient here, because the Makefile hard codes gcc in one place
and uses a non-standard compiler variable name "LK". The attached patch
fixes all of that. Please consider applying it.

Helmut
diff --minimal -Nru t2n-0.6/debian/changelog t2n-0.6/debian/changelog
--- t2n-0.6/debian/changelog2017-08-01 10:15:56.0 +0200
+++ t2n-0.6/debian/changelog2019-05-12 20:22:00.0 +0200
@@ -1,3 +1,13 @@
+t2n (0.6-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Also pass the C++ compiler as LK.
++ cross.patch: Don't hardcode gcc.
+
+ -- Helmut Grohne   Sun, 12 May 2019 20:22:00 +0200
+
 t2n (0.6-6) unstable; urgency=medium
 
   * Corrected section in d/gbp.conf.
diff --minimal -Nru t2n-0.6/debian/patches/cross.patch 
t2n-0.6/debian/patches/cross.patch
--- t2n-0.6/debian/patches/cross.patch  1970-01-01 01:00:00.0 +0100
+++ t2n-0.6/debian/patches/cross.patch  2019-05-12 20:22:00.0 +0200
@@ -0,0 +1,11 @@
+--- t2n-0.6.orig/Makefile
 t2n-0.6/Makefile
+@@ -41,7 +41,7 @@
+  $(OBJDIR)/ezargs.o 
+ 
+ $(OBJDIR)/usbscan: $(SRCDIR)/usbscan.c
+-  gcc $(CFLAGS) $(LDFLAGS) $(SRCDIR)/usbscan.c $(LIBS) -o 
$(OBJDIR)/usbscan
++  $(CC) $(CFLAGS) $(LDFLAGS) $(SRCDIR)/usbscan.c $(LIBS) -o 
$(OBJDIR)/usbscan
+ 
+ $(OBJDIR)/$(MAIN) : $(OBJS)
+   $(LK) $(LDFLAGS) $(OBJS) $(LIBS) -o $(OBJDIR)/$(MAIN)
diff --minimal -Nru t2n-0.6/debian/patches/series t2n-0.6/debian/patches/series
--- t2n-0.6/debian/patches/series   2016-09-12 09:18:29.0 +0200
+++ t2n-0.6/debian/patches/series   2019-05-12 20:22:00.0 +0200
@@ -1 +1,2 @@
 01-readme-typo.patch
+cross.patch
diff --minimal -Nru t2n-0.6/debian/rules t2n-0.6/debian/rules
--- t2n-0.6/debian/rules2016-07-09 09:17:40.0 +0200
+++ t2n-0.6/debian/rules2019-05-12 20:22:00.0 +0200
@@ -9,4 +9,4 @@
 
 override_dh_auto_build:
 #  post hardenning options to Makefile
-   make LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" CFLAGS="$(shell 
dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags --get CPPFLAGS)"
+   dh_auto_build -- LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" 
CFLAGS="$(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags --get 
CPPFLAGS)" LK='$$(CXX)'

Bug#928901: shutdown-qapps FTCBFS: missing Build-Depens: qt5-qmake:native

[Helmut Grohne]

Source: shutdown-qapps
Version: 1.7.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

shutdown-qapps fails to cross build from source, because it fails
running lrelease. For using lrelease you must add qt5-qmake:native to
Build-Depends. Please consider applying the attached patch.

Helmut
diff --minimal -Nru shutdown-qapps-1.7.3/debian/changelog 
shutdown-qapps-1.7.3/debian/changelog
--- shutdown-qapps-1.7.3/debian/changelog   2017-01-14 05:08:42.0 
+0100
+++ shutdown-qapps-1.7.3/debian/changelog   2019-05-12 20:42:53.0 
+0200
@@ -1,3 +1,11 @@
+shutdown-qapps (1.7.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: qt5-qmake:native for running lrelease.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 20:42:53 +0200
+
 shutdown-qapps (1.7.3-1) unstable; urgency=low
   * qshutdown
 - fixed bug for shutdown/reboot/suspend/hibernate settings caused by
diff --minimal -Nru shutdown-qapps-1.7.3/debian/control 
shutdown-qapps-1.7.3/debian/control
--- shutdown-qapps-1.7.3/debian/control 2017-01-14 05:08:42.0 +0100
+++ shutdown-qapps-1.7.3/debian/control 2019-05-12 20:42:52.0 +0200
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Christian Metscher 
-Build-Depends: debhelper (>= 9), qtbase5-dev, qttools5-dev-tools
+Build-Depends: debhelper (>= 9), qtbase5-dev, qttools5-dev-tools, 
qt5-qmake:native
 Standards-Version: 3.9.8
 Vcs-Git: https://github.com/hakaishi/shutdown-qapps.git
 Vcs-browser: https://github.com/hakaishi/shutdown-qapps

Bug#928899: giftrans FTCBFS: uses the wrong compiler

[Helmut Grohne]

Source: giftrans
Version: 1.12.2-19
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

giftrans fails to cross build from source, because debian/rules uses the
build architecture compiler as a make default. The easiest way of fixing
that - seeding $(CC) from dpkg's buildtools.mk - makes giftrans cross
buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru giftrans-1.12.2/debian/changelog 
giftrans-1.12.2/debian/changelog
--- giftrans-1.12.2/debian/changelog2015-08-05 19:18:47.0 +0200
+++ giftrans-1.12.2/debian/changelog2019-05-12 20:12:47.0 +0200
@@ -1,3 +1,9 @@
+giftrans (1.12.2-20) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply $(CC). (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 20:12:47 +0200
+
 giftrans (1.12.2-19) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru giftrans-1.12.2/debian/rules giftrans-1.12.2/debian/rules
--- giftrans-1.12.2/debian/rules2015-08-04 23:06:04.0 +0200
+++ giftrans-1.12.2/debian/rules2019-05-12 20:12:46.0 +0200
@@ -2,6 +2,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 

Bug#928895: kmerresistance FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: kmerresistance
Version: 2.0+git20180205.26467e9-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

kmerresistance fails to cross build from source, because debian/rules
hard codes plain "gcc". The easiest way of discovering the correct
compiler is using dpkg's buildtools.mk. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru kmerresistance-2.0+git20180205.26467e9/debian/changelog 
kmerresistance-2.0+git20180205.26467e9/debian/changelog
--- kmerresistance-2.0+git20180205.26467e9/debian/changelog 2019-02-20 
12:58:24.0 +0100
+++ kmerresistance-2.0+git20180205.26467e9/debian/changelog 2019-05-12 
20:39:44.0 +0200
@@ -1,3 +1,10 @@
+kmerresistance (2.0+git20180205.26467e9-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use a CC from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 20:39:44 +0200
+
 kmerresistance (2.0+git20180205.26467e9-1) unstable; urgency=medium
 
   * Initial release (Closes: #922759)
diff --minimal -Nru kmerresistance-2.0+git20180205.26467e9/debian/rules 
kmerresistance-2.0+git20180205.26467e9/debian/rules
--- kmerresistance-2.0+git20180205.26467e9/debian/rules 2019-02-20 
12:58:24.0 +0100
+++ kmerresistance-2.0+git20180205.26467e9/debian/rules 2019-05-12 
20:39:42.0 +0200
@@ -4,8 +4,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 
 override_dh_auto_build:
-   gcc $(CFLAGS) -o kmerresistance KmerResistance.c -lm $(LDFLAGS)
+   $(CC) $(CFLAGS) -o kmerresistance KmerResistance.c -lm $(LDFLAGS)

Bug#928896: yabar FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: yabar
Version: 0.4.0-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

yabar fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. Making it substitutable is
sufficient to fix this, but the cross build fails due to #853713 then.
Please consider applying the attached patch.

Helmut
--- yabar-0.4.0.orig/Makefile
+++ yabar-0.4.0/Makefile
@@ -1,8 +1,9 @@
 VERSION ?= $(shell git describe)
 CPPFLAGS += -DVERSION=\"$(VERSION)\" -D_POSIX_C_SOURCE=199309L -DYA_INTERNAL -DYA_DYN_COL \
 			-DYA_ENV_VARS -DYA_INTERNAL_EWMH
-CFLAGS += -std=c99 -Iinclude -pedantic -Wall -Os `pkg-config --cflags pango pangocairo libconfig`
-LDLIBS += -lxcb -lpthread -lxcb-randr -lxcb-ewmh `pkg-config --libs pango pangocairo libconfig`
+PKG_CONFIG ?= pkg-config
+CFLAGS += -std=c99 -Iinclude -pedantic -Wall -Os `$(PKG_CONFIG) --cflags pango pangocairo libconfig`
+LDLIBS += -lxcb -lpthread -lxcb-randr -lxcb-ewmh `$(PKG_CONFIG) --libs pango pangocairo libconfig`
 PROGRAM := yabar
 PREFIX ?= /usr
 BINPREFIX ?= $(PREFIX)/bin

Bug#928894: custom keyring is not honoured

[Toni]

Package: gpg
Version: 2.2.12-1
Severity: normal

Hi,

--recv-keys does not seem to honour the keyring options, so the received
key ends up in the wrong keyring:


$ touch ~/mnt/tools/gitea-keys.gpg
$ gpg  --no-default-keyring  --keyring ~/mnt/tools/gitea-keys.gpg --recv-keys 
CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 0x2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: key 0x2D9AE806EC1592E2: public key "Teabot " imported
gpg: Total number processed: 1
gpg:   imported: 1
$ gpg --list-options show-keyring -k tea...@gitea.io
gpg: please do a --check-trustdb
Keyring: /home/toni/.gnupg/pubring.gpg
--
pub   rsa4096/0x2D9AE806EC1592E2 2018-06-24 [SC] [expires: 2020-06-23]
  7C9E68152594688862D62AF62D9AE806EC1592E2
uid   [ unknown] Teabot 
sub   rsa4096/0x1FBE01D7CBADB9A0 2018-06-24 [E] [expires: 2020-06-23]
sub   rsa4096/0x5FC346329753F4B0 2018-06-24 [S] [expires: 2019-06-24]

$



Cheers,
Toni



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'stable'), (70, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, 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 gpg depends on:
ii  gpgconf2.2.12-1
ii  libassuan0 2.5.2-1
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libgpg-error0  1.35-1
ii  libreadline7   7.0-5
ii  libsqlite3-0   3.27.2-2
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages gpg recommends:
ii  gnupg  2.2.12-1

gpg suggests no packages.

-- no debconf information

Bug#928809: lintian: suggest adding gitlab-ci file

[Chris Lamb]

Mattia Rizzolo wrote:

> > please add suggestion that if Vcs-Git points to salsa.debian.org,
> > CI should be used.
> 
> Please, don't.

I'm somewhat inclined to agree with Mattia here but perhaps not as
strongly - I'm a huge fan of CI systems to catch things. I'm not very
happy with testsuite-autopkgtest-missing myself too, however.

Mattia, just to gauge your opinion, what would you hypothethically say
to a "P:" check for this and, separately, the current "I:" autopkgtest
check?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#928805: texlive-lang-czechslovak: fails to install: fmtutil failed

[Hilmar Preuße]

On 11.05.19 18:41, Norbert Preining wrote:

Hi Norbert,

> That needs some serious rework ... I tend to depend on texlive-lang-all
> ..
> 
Here is the list of not found files and the packages I had to install:

hyph-en-gb texlive-lang-english
hyph-it texlive-lang-italian
hyph-de-1996 texlive-lang-german
hyph-fr texlive-lang-french
hyph-pl texlive-lang-polish
hyph-es texlive-lang-spanish
hyph-sl texlive-lang-european
... I guess this is far from -all

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#928367: libpapi5: SOVERSION is too wide for the runtime check in PAPI_library_init()

[Andreas Tille]

Hi Andreas,

in the thread on the upstream mailing list[1] you proposed a patch that
was confirmed working by upstream.  Do you think this patch should be
submitted to Debian BTS and the bug tagged patch?

Kind regards

   Andreas.

[1] 
https://groups.google.com/a/icl.utk.edu/forum/#!topic/perfapi-devel/Qgv4BpZl64U

-- 
http://fam-tille.de

Bug#928891: linux-image-amd64: Kernel crash when using any disk that uses reiserfs

[Ben Hutchings]

On Sun, 2019-05-12 at 18:34 +0200, Thanatermesis wrote:
> Package: linux-image-amd64
> Version: 4.19+104
> Severity: important
> 
> Dear Maintainer,
> 
> When using any partition which uses reiserfs, the kernel crashes
> 
> This happens very easily by just using the reiser (v3) filesystem, some
> of my external hard disks uses it (so I cannot make use of them), or
> partition mountpoints with reiserfs becomes totally unusable and
> dangerous
> 
> This bug is easily reproducible by creating a new reiserfs partition
> (image file probably too) and start using it, so it looks like it
> specially affects in RW operations
> 
> I suggest to mark this bug as a serious one since there's so many people
> using this filesystem, in desktops or servers.
> 
> The package is the last one available on the buster branch

reiserfs v3 is *not* widely used, and is barely maintained upstream. 
Debian hasn't supported installing to reiserfs for a while.

It is quite possible that we will "fix" this by disabling reiserfs
altogether.  In any case, I strongly recommend that you switch to a
better supported filesystem like ext4 or xfs.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education.
  - Albert Einstein




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

Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

[Svjatoslav Agejenko]

Package: gnome-disk-utility
Version: 3.30.2-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

Install system using normal full disk encryption LUKS+Ext4.
After install open gnome-disk-utility and change
encryption password. It gives some error dialog and
now you are royally screwed. It deleted the only
LUKS keyslot. Cannot add new keyslots because of that.
All data will be lost after reboot.

Here is output of luksdump:

udo cryptsetup luksDump /dev/sda5
LUKS header information
Version:2
Epoch:  4
Metadata area:  16384 [bytes]
Keyslots area:  1678 [bytes]
UUID:   3c16ad4c-294c-4547-bf3e-bb8864ba5ea3
Label:  (no label)
Subsystem:  (no subsystem)
Flags:  (no flags)

Data segments:
  0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]

Keyslots:
Tokens:
Digests:
  0: pbkdf2
Hash:   sha256
Iterations: 59904
Salt:   XX XX XX XX XX 
Digest: XX XX XX XX XX ...



I changed salt and digest. No Keyslots are present!!!

I tried this 2 times in a row with new install,
exactly same result.



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

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

Versions of packages gnome-disk-utility depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libdvdread4  6.0.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  liblzma5 5.2.4-1
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpwquality11.4.0-3
ii  libsecret-1-00.18.7-1
ii  libsystemd0  241-3
ii  libudisks2-0 2.8.1-4
ii  udisks2  2.8.1-4

gnome-disk-utility recommends no packages.

gnome-disk-utility suggests no packages.

-- no debconf information

Bug#928892: RFS: heimdall-flash/1.4.2-1

[etchevef]

Package: sponsorship-requests  Severity: normal   Dear mentors,  I am looking 
for a sponsor for my package "heimdall-flash" * Package name: 
heimdall-flash   Version : 1.4.2-1   Upstream Author : Benjamin Dobell 
(@glassechidna ) * URL : 
https://www.glassechidna.com.au/heimdall/ 
 * License : MIT License 
(Expat)   Section : devel  It builds those binary packages:
heimdall-flash - tool for flashing firmware on Samsung Galaxy S 
devicesheimdall-flash-frontend - tool for flashing firmware on Samsung Galaxy S 
devices - Qt GUI  To access further information about this package, please 
visit the following URL:  https://mentors.debian.net/package/heimdall-flash 
  Alternatively, one can 
download the package with dget using this command:dget -x 
https://mentors.debian.net/debian/pool/main/h/heimdall-flash/heimdall-flash_1.4.2-1.dsc
 

  More information about heimdall-flash can be obtained from 
https://www.example.com .  Changes since the last 
upload:  * New upstream release.  Regards,   Francois ETCHEVERRY

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

[Vagrant Cascadian]

On 2019-05-12, Karsten Merker wrote:
> On Sun, May 12, 2019 at 10:40:39AM +0200, Domenico Andreoli wrote:
>> +Machine: FriendlyARM NanoPi NEO 2
>> +Kernel-Flavors: arm64
>> +Boot-Script-Path: /boot/boot.scr
>> +DTB-Id: allwinner/sun50i-h5-nanopi-neo2.dtb
>> +U-Boot-Script-Name: bootscr.uboot-generic
>> +Required-Packages: u-boot-tools
>> +
>> 
>> I was not able to cross-build the arm64 installer from amd64 so the
>> patch is not tested.
>>
>> 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?

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 ...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#928887: hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 (buster)

[Santiago Vila]

On Sun, May 12, 2019 at 04:30:01PM +0200, Andreas Beckmann wrote:
> Please do a dummy 2.10-2 upload to fix this ...

I am in fact considering a not-so-dummy upload with minor changes,
because after all this is a package to be copied and pasted, but I'll
have to ask for permission to release.debian.org, not every update is
100% safe. See Bug #928889 for an example :-)

Thanks.

Bug#928889: debhelper: dh_autoreconf says "sh: 1: build-aux/git-version-gen: not found"

[Niels Thykier]

Control: tags -1 moreinfo

Santiago Vila:
> Package: debhelper
> Version: 12.1.1
> 
> Hello Niels.
> 

Hi,

> I tried using compat version 12 in package "hello" and this is what happened:
> 

For reference/FYI, I suspect this will happen already at compat 10 or
later (I noted that hello in sid uses compat 9 and compat 10 is the
first to use dh_autoreconf by default).

> sh: 1: build-aux/git-version-gen: not found
> sh: 1: build-aux/git-version-gen: not found
> sh: 1: build-aux/git-version-gen: not found
> sh: 1: build-aux/git-version-gen: not found
> sh: 1: build-aux/git-version-gen: not found
> 
> Is this normal/expected/safe?
> 
> I'd like to see it documented somewhere.
> 
> Thanks.
> 

I think this is because of two things:

 1) The source does not include build-aux/git-version-gen
 2) The configure.ac references build-aux/git-version-gen and appears
to use it unconditionally[1]

So when dh_autoreconf does its job of regenerating the build scripts
from configure.ac, then it will trigger those warnings because of the
above.  I.e. this is a "hello"-specific issue.

Not sure what the proper fix is here.  Options include:

 * Have upstream include build-aux/git-version-gen in the source
   - Though it may need git and a git repo to work properly, so this
 might only make sense from the PoV of ensuring that we have the
 complete source of the build scripts.

 * Patch configure.ac to *not* rely on the build-aux/git-version-gen
   script

 * Skip reconfiguration by overriding dh_autoreconf (see [2] as an
   example).

I hope the above answers your question.

Thanks,
~Niels

[1]: https://sources.debian.org/src/hello/2.10-1/configure.ac/#L12

[2]:
"""
# Skip dh_autoreconf because .
override_dh_autoreconf:
"""

Bug#928891: linux-image-amd64: Kernel crash when using any disk that uses reiserfs

[Thanatermesis]

Package: linux-image-amd64
Version: 4.19+104
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

When using any partition which uses reiserfs, the kernel crashes

This happens very easily by just using the reiser (v3) filesystem, some
of my external hard disks uses it (so I cannot make use of them), or
partition mountpoints with reiserfs becomes totally unusable and
dangerous

This bug is easily reproducible by creating a new reiserfs partition
(image file probably too) and start using it, so it looks like it
specially affects in RW operations

I suggest to mark this bug as a serious one since there's so many people
using this filesystem, in desktops or servers.

The package is the last one available on the buster branch


Thank you


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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.19.0-4-amd64  4.19.28-2

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfeKOpqCfdgmEOvbZoseZv9/418IFAlzYSmYACgkQoseZv9/4
18LahhAAteYzza00P/QifDn3CbF5z3CHj3WDHJ9wj/CdIgUDEU7nvZpwTiF6WvwF
4Rjx2ZWXuaRDaBO2FnZQI/aANGm3wNNo7Y4Q3IzVC4OCO8uRbenHLzkViQbhBdLb
aqsSyDrT4ryHgxWM6pF+Fg6shIhiOObEqUfmD0ZNoCGuk6iReYPSOYT2MebIEdKH
QxBVwdCFfUuaZfp873joDblPTVly9ynvFyvhQ9xZG0yu7wrSFWSWt5fEMWatDhbW
vVS5iFICh4HzYeYFkeMgBWc+SLPcnefwXEcZgBKtpNHCpfiq3Xow85QIK6/ec72A
ay8fRWqiOMNU3GgyHfI/4olNm/K6vJ2ZL9m6N4lD5YN3WrRK9Qg0GWu7tfr35J6S
VLRr+1a89vzqzS3piOUd5bVyakJueVCtLiwcDLfi36c1iEjr+GJwvvy8M5/QO2xS
Q1khrBQui3lKNPxgxF3KGNX3qtvdIthrsGdO7Aoyzb3Fh3Xt6Tyl6shWWqK9mm9H
7fhmuORhnZQKSO35epRgNYhv35c1I9w5e4iHxNfbhTH4dlMZkCEJYLXnD+vtsWzz
Op4nsYFuqDfB1XgrsvNfbeIy8szHKzHKDF4TAdtjsHd+AXJYnaQCR/Wq4y+RwaO8
Ff6gTBha4OKups3X0OL6e5/xUO+RREUYBtYEenXIYURvX4Kidh4=
=kmLp
-END PGP SIGNATURE-

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

[Pirate Praveen]

On Mon, 06 May 2019 11:48:47 + HIGUCHI Daisuke (VDR dai)
 wrote:
> Source: ruby-pygments.rb
> Source-Version: 1.2.0-4
> 
> We believe that the bug you reported is fixed in the latest version of
> ruby-pygments.rb, which is due to be installed in the Debian FTP archive.
> 

Hi dai,

We will have to file an unblock request for this to migrate to testing.
Can you file it?

Thanks
Praveen



signature.asc
Description: OpenPGP digital signature

Bug#915333: git-annex: Illegal Instruction on armel (Fujitsu Q700 like QNAP TS-21x/TS-22x)

[Adrian Bunk]

On Sun, May 12, 2019 at 03:16:10PM +0300, Ilias Tsitsimpis wrote:
> On Mon, Mar 11, 2019 at 12:05PM, Adrian Bunk wrote:
> > On Thu, Jan 31, 2019 at 08:12:17PM +0100, Bernhard Übelacker wrote:
> > > See attached file with several debugging attempts.
> > 
> > Looking at the code, the bug seems to be in
> > https://sources.debian.org/src/ghc/8.4.4+dfsg1-2/debian/patches/llvm-arm-unknown-linux-gnueabi.patch/
> 
> Hey all,
> 
> Thank you Bernhard and Adrian for debugging this. I have opened an unblock
> request for ghc to see if RT will allow us to fix this for buster.
> 
> [#928882] https://bugs.debian.org/928882

Thanks a lot for this.

> Running the `utils/llvm-targets/gen-data-layout.sh` script[1], outputs
> the following triplet for arm-unknown-linux-gnueabi:
> 
>   ("arm-unknown-linux-gnueabi", 
> ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm7tdmi", "+soft-float 
> -fp-only-sp -d16 -vfp2 -vfp3 -fp16 -vfp4 -fp-armv8 -neon -crypto 
> +strict-align"))
> 
> The ARM7TDMI processor core implements the ARM architecture v4T, so it
> looks like the correct value for armel, but it would be great if someone
> from the debian-arm team could verify that the rest of the flags are OK.
>...

For buster the baseline of the Debian armel port was raised
from v4T to v5TE.

v4T is still fine on the armel port (only slightly slower).

For an upstreamable change arm7tdmi might be better since v4T
is the lowest with Thumb (and Thumb interworking) support.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#928666: Want dgit FAQ

[Sean Whitton]

Hello,

I felt a desire to write some entries.

I would like to just get this published on the Debian wiki as soon as
possible; let me know if you really want to avoid that, Ian.

~ ~ ~ ~ ~

Q: Why should I bother to learn how to use dgit?

A: If you incorporate `dgit push-source` into your workflow, then you
will be providing your git history to Debian's users and downstreams in
a way that is more useful to them than adding a `Vcs-Git` header.

If you think that a package maintainer's git history should be provided
to users because it is part of the preferred format for modification,
then dgit is the easiest way to provide it.

Specifically, if you incorporate `dgit push-source` into your workflow,
you provide your git history to your users in a form known as the *dgit
view*.  The dgit view of a package is designed to be what someone who
knows git, but does not know Debian-specific practices, would expect.

You don't have to think about difference between the maintainer view and
the dgit view (if any), because dgit will perform that conversion for
you when you upload.  It does this in a way which does not hide the
maintainer's git history.  I.e. the dgit view is constructed from the
maintainer's git history, not from the `.dsc`.  has some additional
commits appended to convert your maintainer history into the dgit view.

There are also minor conveniences for maintainers in using dgit, which
together mean that you have to think less about the idiosyncracies of
uploading to the Debian archive and more about the contents of your
package.

~ ~ ~ ~ ~

Q: Do I need to change my git workflow in order to use dgit?

A: In principle, no.  It is a design goal of dgit that you don't have to
do that.

However, dgit does have to be taught about each Debian git workflow in
order that users of that workflow can start using dgit, and there are
some git workflows out there for which support has not yet been added.

git-buildpackage and git-dpm users are fully supported and that support
is stable and well-tested.  See dgit-maint-gbp(7) and dgit-maint-dpm(7).

~ ~ ~ ~ ~

Q: Why is dgit so fussy / Why are dgit's error messages so difficult?

A: dgit tries very hard to avoid a number of different possible mistakes
in your uploads.  The result of this is that you have to think less hard
about the idiosyncracies of uploading to the Debian archive, and focus
more on the contents of your package.

However, while dgit is good at emitting error messages at the right
times, the error messages that it emits are definitely not as helpful
and easy to understand as we want them to be.  Bug reports are welcome.
The dgit developers already know what's going on, so it is difficult for
us to univocally improve the error output.

~ ~ ~ ~ ~

Q: Does everyone on my team have to be using dgit in order for me to use
it to upload team-maintained packages.

A: No.  dgit copes just fine with interspersed dgit and non-dgit
uploads.  Your use of dgit will not disrupt the work of other people on
your team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928889: debhelper: dh_autoreconf says "sh: 1: build-aux/git-version-gen: not found"

[Santiago Vila]

Package: debhelper
Version: 12.1.1

Hello Niels.

I tried using compat version 12 in package "hello" and this is what happened:

sh: 1: build-aux/git-version-gen: not found
sh: 1: build-aux/git-version-gen: not found
sh: 1: build-aux/git-version-gen: not found
sh: 1: build-aux/git-version-gen: not found
sh: 1: build-aux/git-version-gen: not found

Is this normal/expected/safe?

I'd like to see it documented somewhere.

Thanks.

Bug#927942: gucharmap: FTBFS with unicode-data >= 12

[peter green]

(note: I'm just someone taking a look to see what is blocking the unicode-data 
"transition", i'm not a maintainer of this package or a member of the release 
team).


unicode-data 12.0.0 is now in unstable/testing (Buster).
gucharmap FTBFS with this;


It seems upstream have updated gucharmap for unicode 12.0. It appears that 
upstream releases of gucharmap are versioned based on the version of unicode 
they support, with an extra element added to the end for updates to gucharmap 
only. So the large increase in gucharmap upsteam version number does not 
indicate massive changes to the software.

The total changes between the versions are quite voluminous, but they appear to be mostly 
translation and documentation updates. Filtering those out ( I used git clone "git clone 
https://gitlab.gnome.org/GNOME/gucharmap/; followed by "git diff 11.0.3..12.0.1 | 
filterdiff -p1 -x'po/*' -x'help/*' --clean" ) seems to leave a quite reasonable remaining diff.

However debian sid has now moved on from unicode 12.0 to unicode 12.1, there is 
an upstream bug report for 12.1 support, but so far there doesn't seem to be 
any publically visible activity on it. 
https://gitlab.gnome.org/GNOME/gucharmap/issues/17

Bug#928888: On debian 9, /etc/init.d/hostapd shows [ ok ], when actually hostapd failed to start

[Alan Jenkins]

Package: hostapd
Version: 2.4-1+deb9u3

https://salsa.debian.org/debian/wpa/blob/debian/2%252.4-1+deb9u2/debian/hostapd.init

log_daemon_msg "Starting $DESC" "$NAME"
start-stop-daemon --start --oknodo --quiet --exec "$DAEMON_SBIN" \
--pidfile "$PIDFILE" -- $DAEMON_OPTS >/dev/null
log_end_msg "$?"

I.e. it fails to pass on the exit status from start-stop-daemon.  As a
result, *** when this specific version of hostapd is used with systemd
*** , "[ ok ]" is shown even if hostapd failed :

> # /etc/init.d/hostapd start
> [ ok ] Starting hostapd (via systemctl): hostapd.service.
> ...
> The error in journalctl -b -u hostapd is:
> Starting advanced IEEE 802.11 management: hostapd failed!

The above is taken from the user report / support request at
https://unix.stackexchange.com/questions/518466/hostapd-hotspot-not-running

In Debian buster, this problem with systemd will be entirely solved,
because we now have hostapd.service, a native systemd service.  Yay!

However there is still this bug in the init script.  Other init
systems are available. These may rely on the old-style init.d scripts,
and may or may not give similarly confusing results.  So it would
still be nice to fix this bug.

I searched for a standard template for a Debian init script.  It turns
out /etc/init.d/skeleton went away, because simple scripts should now
be written using `init-d-script` .  There is a man page for it.  The
current man page is missing a lot of critical information, e.g.
forgets to mention how to pass arguments to the daemon :-( .  The
answers are in the source code, e.g. you can set DAEMON_ARGS.

The hack with "sleep 8" should be easy to re-create if necessary by
defining do_restart_override() and do_force_reload_override() .  I
guess that you are still finding it necessary, seeing as you have
defined RestartSec=2 in the systemd service.

source code link:
https://salsa.debian.org/debian/sysvinit/commit/fbf700964e86953d2c573229c39482db0b9e1eb7

---

There's a similar example showing how this init script incorrectly
shows "active" instead of "failed" in "systemctl status" :
https://github.com/raspberrypi/firmware/issues/1117 :

# service hostapd status
hostapd.service - LSB: Advanced IEEE 802.11 management daemon
   Loaded: loaded (/etc/init.d/hostapd; generated; vendor preset: enabled)
   Active: active (exited) since Wed 2019-02-27 21:05:29 UTC; 3s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2177 ExecStop=/etc/init.d/hostapd stop (code=exited,
status=0/SUCCESS)
  Process: 2212 ExecStart=/etc/init.d/hostapd start (code=exited,
status=0/SUCCESS)

Feb 27 21:05:29  systemd[1]: Starting LSB: Advanced IEEE
802.11 management daemon...
Feb 27 21:05:29  hostapd[2212]: Starting advanced IEEE
802.11 management: hostapd failed!
Feb 27 21:05:29  systemd[1]: Started LSB: Advanced IEEE
802.11 management daemon.

Bug#927471: curl: Regression that fails to exhaust socket data

[Guillem Jover]

Hi!

On Tue, 2019-05-07 at 14:57:53 +0200, Guillem Jover wrote:
> Thanks! I tried yesterday and today to get a deterministic reproducer
> with the version from unstable, but I'm not sure what's the trigger,
> perhaps the torrent peers or the chunk arrival order or something. In
> any case I was able to get the problem while redownloading some torrents
> I had around. Installed the new package, and redownloaded several old
> torrents and several new ones, and none have shown the problem since.
> 
> But even though I was getting that pretty often before, that does not
> mean I might have been lucky until now! So, while it does look like the
> issue is gone, I cannot say that with 100% assurance. :)
> 
> Will keep checking and report again in a day or two.

Ok, been using it for a while, and I've not seen the busy-looping
since, so it LGTM!

Thanks,
Guillem

Bug#928887: hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 (buster)

[Santiago Vila]

On Sun, May 12, 2019 at 04:30:01PM +0200, Andreas Beckmann wrote:
> Package: hello
> Version: 2.10-1
> Severity: serious
> Tags: sid buster
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package violates version
> ordering:
> 
>  hello | 2.10-1| stretch  | source
>  hello | 2.10-1| buster   | source
>  hello | 2.10-1| sid  | source
>  hello | 2.10-1+b1 | stretch  | amd64, ...
>  hello | 2.10-1+b1 | buster   | amd64, ...
>  hello | 2.10-1+b1 | sid  | amd64, ...
>  hello | 2.10-1+deb9u1 | stretch-security | source, amd64, ...
> 
> Please do a dummy 2.10-2 upload to fix this ...

Considering that version in stretch-security was a test by security
team and was never meant to reach stretch itself, is this really a
problem?

Thanks.

Bug#928657: ITP: golang-github-naegelejd-go-acl -- Golang POSIX 1e ACL bindings

[Felixoid]

Hey, I've done everything with dh-make-golang already. Only the latest `gbp
push` returns error by insufficient permissions.

пт, 10 мая 2019 г. в 14:19, Shengjing Zhu :

> Hi
>
> On Fri, May 10, 2019 at 4:06 PM Felixoid  wrote:
> >
> > + submit, debian-devel, debian-go
>
> sub...@bugs.debian.org is meant for creating a new bug..
>
> >
> > пт, 10 мая 2019 г. в 09:31, Felixoid :
> >>
> >> Hello. Did I miss something here? What would be the next step to submit
> the repo https://github.com/Felixoid/golang-github-naegelejd-go-acl to
> the created salsa
> https://salsa.debian.org/go-team/packages/golang-github-naegelejd-go-acl
> as well?
> >>
> >> I've created a guest user felixoid-guest and couldn't push into repo
> because of lack of permissions:
> >> > GitLab: You are not allowed to push code to this project.
>
> You could do it with dh-make-golang, you can get more info at
> https://go-team.pages.debian.net/packaging.html#_using_dh_make_golang
>
> --
> Shengjing Zhu
>

Bug#928887: hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 (buster)

[Andreas Beckmann]

Package: hello
Version: 2.10-1
Severity: serious
Tags: sid buster
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package violates version
ordering:

 hello | 2.10-1| stretch  | source
 hello | 2.10-1| buster   | source
 hello | 2.10-1| sid  | source
 hello | 2.10-1+b1 | stretch  | amd64, ...
 hello | 2.10-1+b1 | buster   | amd64, ...
 hello | 2.10-1+b1 | sid  | amd64, ...
 hello | 2.10-1+deb9u1 | stretch-security | source, amd64, ...

Please do a dummy 2.10-2 upload to fix this ...


Andreas

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

[Samuel Henrique]

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#928886: iwgetid: document exit codes in man page

[Darshaka Pathirana]

Package: wireless-tools
Version: 30~pre9-12+b1
Severity: minor

Dear Maintainer,

please document the Exit Codes of iwgetid. For example, if the
wireless network is not connected then iwgetid returns the exit code
255:

# sudo iwgetid -r
# echo $?
255

Are there more?

Thank you for maintainting wireless-tools!

Regards,
 - Darsha

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

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

Versions of packages wireless-tools depends on:
ii  libc62.24-11+deb9u4
ii  libiw30  30~pre9-12+b1

wireless-tools recommends no packages.

wireless-tools suggests no packages.

-- no debconf information

Bug#921694: mdk4 (0~git20181205-2) is not suitable for Buster

[Samuel Henrique]

Control: severity -1 serious

Thank you for your work Santiago, I appreciate all of the bug reports I've
received from you so far.

I'm taking the opportunity of this bugreport to bump the severity and block
mdk4 from entering Buster, as the current version in Testing is a git
snapshot not officially released.

Considering we don't know for sure what is causing this FTBFS and that is
very likely that there are other bugs in this version, I find it better not
to ship it on Buster.

Also, for those who need it, there is already mdk3, the previous generation
of it, the main difference is that mdk3 doesn't support 5.8Ghz AFAIK.

Regards,

-- 
Samuel Henrique 

Bug#928885: FTBFS with librsync 2

[Andrey Rahmatullin]

Package: src:rdiff-backup
Version: 1.2.8-7
Severity: normal
Tags: upstream

We plan upgrading librsync to 2.0.2 after the buster release, see #776246. This
version is not API-compatible with 0.9.7 but it seems the only package that
breaks is rdiff-backup:

x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-
map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong
-Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c
_librsyncmodule.c -o build/temp.linux-x86_64-2.7/_librsyncmodule.o
_librsyncmodule.c: In function ‘_librsync_new_sigmaker’:
_librsyncmodule.c:63:17: error: ‘RS_DEFAULT_STRONG_LEN’ undeclared (first use
in this function); did you mean ‘RS_DEFAULT_BLOCK_LEN’?
 (size_t)RS_DEFAULT_STRONG_LEN);
 ^
 RS_DEFAULT_BLOCK_LEN
_librsyncmodule.c:63:17: note: each undeclared identifier is reported only once
for each function it appears in
_librsyncmodule.c:62:17: error: too few arguments to function ‘rs_sig_begin’
   sm->sig_job = rs_sig_begin((size_t)blocklen,
 ^~~~
In file included from _librsyncmodule.c:25:
/usr/include/librsync.h:397:11: note: declared here
 rs_job_t *rs_sig_begin(size_t new_block_len, size_t strong_sum_len,
   ^~~~

Please do something with this. New librsync is available in experimental. This
bug report will be upgraded to RC once the freeze ends.



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

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

Bug#928884: avr-evtd FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: avr-evtd
Version: 1.7.7-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

avr-evtd fails to cross build from source, because debian/rules uses the
build architecture compiler as a make default. Letting dpkg's
buildtools.mk initialize $(CC) fixes that. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru avr-evtd-1.7.7/debian/changelog 
avr-evtd-1.7.7/debian/changelog
--- avr-evtd-1.7.7/debian/changelog 2010-05-21 07:10:41.0 +0200
+++ avr-evtd-1.7.7/debian/changelog 2019-05-12 14:36:49.0 +0200
@@ -1,3 +1,10 @@
+avr-evtd (1.7.7-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply $(CC). (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2019 14:36:49 +0200
+
 avr-evtd (1.7.7-2) unstable; urgency=low
 
   * Restrict build architectures to linux-any
diff --minimal -Nru avr-evtd-1.7.7/debian/rules avr-evtd-1.7.7/debian/rules
--- avr-evtd-1.7.7/debian/rules 2010-05-21 05:24:29.0 +0200
+++ avr-evtd-1.7.7/debian/rules 2019-05-12 14:36:47.0 +0200
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+-include /usr/share/dpkg/buildtools.mk
 TARGETDIR=$(CURDIR)/debian/avr-evtd
 
 CFLAGS = -Wall -Wextra -g

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

[Jens Reyer]

control: retitle -1 binNMU: please rebuild wine-development against 
unicode-data 12.1.0~pre1-2
control: reassign -1 release.debian.org

Hi,

On 11.05.19 20:25, Paul Gevers wrote:
> Hi Jens,
> 
> On 09-05-2019 22:54, Jens Reyer wrote:
> 
> [...]
> 
>> The files built with unicode-data are in arch-specific packages, so a
>> binnmu should work.

FTR fonts-wine (arch all) contains affected build results, but is only
built by src:wine, not src:wine-development.  All other arch all
packages in src:wine-development are definitely not affected.

> [...]
> 
>> So what do you think, binnmu or new source upload?
> 
> Than I have a preference for binNMU (this could be my first binNMU as well).

Thanks Paul.
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"

Greets
jre

Bug#928386: syslinux: possible regression bug 'Undef symbol FAIL: memset'

[Holger Levsen]

On Sun, May 12, 2019 at 01:10:47PM +0200, Lukas Schwaighofer wrote:
> I've confirmed the issue is fixed in backports version
> 3:6.04~git20190206.bf6db5b4+dfsg1-1~bpo9+2. Looks like the "Closes:"
> mechanism is not available for backports, so closing manually

thank you for both, Lukas!

> (also not
> sure if setting the Version pseudo-header makes sense here since the BTS
> does not know about backports versions anyways…).

it surely doesnt hurt. :)


-- 
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#928822: raqm: clean after build deletes docs/html/* which is not regenerated

[Andreas Beckmann]

On 2019-05-12 04:38, أحمد المحمودي wrote:
> I checked the diff between upstream sources 0.5.0 (the one in testing) & 
> 0.6.0, and I don't see any significant difference in Makefiles or docs/ 
> to cause this. It might something in experimental's toolchain ?

This is probably reproducible in sid as well, I just run this test on
experimental only.


Andreas

Bug#915333: git-annex: Illegal Instruction on armel (Fujitsu Q700 like QNAP TS-21x/TS-22x)

[Ilias Tsitsimpis]

On Mon, Mar 11, 2019 at 12:05PM, Adrian Bunk wrote:
> On Thu, Jan 31, 2019 at 08:12:17PM +0100, Bernhard Übelacker wrote:
> > See attached file with several debugging attempts.
> 
> Looking at the code, the bug seems to be in
> https://sources.debian.org/src/ghc/8.4.4+dfsg1-2/debian/patches/llvm-arm-unknown-linux-gnueabi.patch/

Hey all,

Thank you Bernhard and Adrian for debugging this. I have opened an unblock
request for ghc to see if RT will allow us to fix this for buster.

[#928882] https://bugs.debian.org/928882

Running the `utils/llvm-targets/gen-data-layout.sh` script[1], outputs
the following triplet for arm-unknown-linux-gnueabi:

  ("arm-unknown-linux-gnueabi", 
("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm7tdmi", "+soft-float 
-fp-only-sp -d16 -vfp2 -vfp3 -fp16 -vfp4 -fp-armv8 -neon -crypto 
+strict-align"))

The ARM7TDMI processor core implements the ARM architecture v4T, so it
looks like the correct value for armel, but it would be great if someone
from the debian-arm team could verify that the rest of the flags are OK.

Hopefully, we can fix this for buster.

[1] 
https://sources.debian.org/src/ghc/8.4.4+dfsg1-2/utils/llvm-targets/gen-data-layout.sh

-- 
Ilias

Bug#928883: libzorpll-dev: add Breaks

[Andreas Beckmann]

Package: libzorpll-dev
Version: 7.0.1.0~alpha1-1
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch' in some scenarios, and the old version from stretch is kept
installed. This is related to the switch from libssl1.0-dev to
libssl-dev.

Adding
  Breaks: libzorpll-6.0-10-dev, libssl1.0-dev
to libzorpll-7.0-1-dev pushes the scores in the right direction and apt
will remove libssl1.0-dev to perform this upgrade step.

Note that the synopsis of libzorpll-7.0-1-dev still mentions
"development files for version 6.0-10", you should fix that as well.

I've tested that the package built with the attached patch passes the
piuparts stretch->buster upgrade test without holding back any upgradable
package.


cheers,

Andreas
diff -Nru libzorpll-7.0.1.0~alpha1/debian/changelog 
libzorpll-7.0.1.0~alpha1/debian/changelog
--- libzorpll-7.0.1.0~alpha1/debian/changelog   2018-10-10 22:21:22.0 
+0200
+++ libzorpll-7.0.1.0~alpha1/debian/changelog   2019-05-12 12:20:04.0 
+0200
@@ -1,3 +1,10 @@
+libzorpll (7.0.1.0~alpha1-1.1) UNRELEASED; urgency=medium
+
+  * libzorpll-7.0-1-dev: Add Breaks: libzorpll-6.0-10-dev, libssl1.0-dev for
+smoother upgrades from stretch.  (Closes: #xx)
+
+ -- Andreas Beckmann   Sun, 12 May 2019 12:20:04 +0200
+
 libzorpll (7.0.1.0~alpha1-1) unstable; urgency=medium
 
   * New upstream version (Closes: #859055)
diff -Nru libzorpll-7.0.1.0~alpha1/debian/control 
libzorpll-7.0.1.0~alpha1/debian/control
--- libzorpll-7.0.1.0~alpha1/debian/control 2018-10-10 22:21:22.0 
+0200
+++ libzorpll-7.0.1.0~alpha1/debian/control 2019-05-12 12:20:04.0 
+0200
@@ -34,7 +34,7 @@
 Package: libzorpll-7.0-1-dev
 Section: libdevel
 Replaces: libzorpll-dev ( << 6.0.8.0-1)
-Breaks: libzorpll-dev ( << 6.0.8.0-1)
+Breaks: libzorpll-dev ( << 6.0.8.0-1), libzorpll-6.0-10-dev, libssl1.0-dev
 Conflicts: libzorpll-6.0-8-dev
 Architecture: any
 Depends: libzorpll-7.0-1 (= ${binary:Version}), ${misc:Depends}, 
libglib2.0-dev, libcap-dev [linux-any], libssl-dev


libzorpll-dev_7.0.1.0~alpha1-1.log.gz
Description: application/gzip

Bug#928809: lintian: suggest adding gitlab-ci file

[Mattia Rizzolo]

Hi,

On Sat, May 11, 2019 at 02:49:02PM +, Dmitry Bogatov wrote:
> please add suggestion that if Vcs-Git points to salsa.debian.org,
> CI should be used.

Please, don't.

For most of my packages, I don't want to bother with setting up a CI,
neither I see any use for it, and I don't think lintian should bother me
more with that (there already is the tag about autopkgtest that way too
often is just causing noise for me).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature