Bug#909345: roaraudio FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: roaraudio
Version: 1.0~beta11-10
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

roaraudio fails to cross build from source, because it configures for
the build architecture. Normally, the simple cure is using
dh_auto_configure, but roaraudio's ./configure does not follow the
typical autotools convenctions. For some reason, the --cc option seems
to be ignored by ./configure, but passing the cross compiler via the
environment works. The attached patch fixes the ./configure invocation,
but it does not make it cross buildable: The pkg-config file is
generated using roar-config and the build system decides to skip that
for cross compilation. Consequently the .pc file is missing and
dh_install complains. I don't see a simple fix for this issue. Most
likely, the .pc file should be generated without roar-config. Please
consider applying the attached patch anyway and close this bug when
doing so.

Helmut
diff --minimal -Nru roaraudio-1.0~beta11/debian/changelog 
roaraudio-1.0~beta11/debian/changelog
--- roaraudio-1.0~beta11/debian/changelog   2017-07-03 13:17:48.0 
+0200
+++ roaraudio-1.0~beta11/debian/changelog   2018-09-21 19:45:12.0 
+0200
@@ -1,3 +1,10 @@
+roaraudio (1.0~beta11-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Tell ./configure about cross building. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 21 Sep 2018 19:45:12 +0200
+
 roaraudio (1.0~beta11-10) unstable; urgency=low
 
   * Remove esound support.
diff --minimal -Nru roaraudio-1.0~beta11/debian/rules 
roaraudio-1.0~beta11/debian/rules
--- roaraudio-1.0~beta11/debian/rules   2017-07-03 13:17:48.0 +0200
+++ roaraudio-1.0~beta11/debian/rules   2018-09-21 19:45:12.0 +0200
@@ -3,7 +3,9 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 DEB_VERSION := $(shell dpkg-parsechangelog|egrep '^Version:'|cut -f 2 -d ' ')
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+export CC
 
 DEB_CONFIGURE_EXTRA_FLAGS := \
--cflags "$(CFLAGS)" \
@@ -25,6 +27,10 @@
--no-slp \
--distribution-version-string "Debian-$(DEB_VERSION)"
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+DEB_CONFIGURE_EXTRA_FLAGS += --cross-compile
+endif
+
 %:
dh $@
 

Bug#909346: glib2.0 FTBFS with profile noudeb

[Helmut Grohne]

Source: glib2.0
Version: 2.58.0-4
Tags: patch ftbfs

glib2.0 fails to build from source on amd64 in unstable when using the
noudeb profile. The dh_missing call for the udeb is not conditionalized
and consequently fails. The attached patch makes the build work. Please
consider applying it.

Helmut
diff --minimal -Nru glib2.0-2.58.0/debian/changelog 
glib2.0-2.58.0/debian/changelog
--- glib2.0-2.58.0/debian/changelog 2018-09-17 23:47:57.0 +0200
+++ glib2.0-2.58.0/debian/changelog 2018-09-22 07:03:31.0 +0200
@@ -1,3 +1,10 @@
+glib2.0 (2.58.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with noudeb profile. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 22 Sep 2018 07:03:31 +0200
+
 glib2.0 (2.58.0-4) unstable; urgency=medium
 
   [ Simon McVittie ]
diff --minimal -Nru glib2.0-2.58.0/debian/rules glib2.0-2.58.0/debian/rules
--- glib2.0-2.58.0/debian/rules 2018-09-17 23:47:57.0 +0200
+++ glib2.0-2.58.0/debian/rules 2018-09-22 07:03:29.0 +0200
@@ -182,5 +182,7 @@
dh_install --remaining-packages --sourcedir=debian/install/deb
 
 override_dh_missing:
+ifneq ($(filter %-udeb,$(binaries)),)
dh_missing --sourcedir=debian/install/udeb --fail-missing
+endif
dh_missing --sourcedir=debian/install/deb --fail-missing

Bug#909344: node-form-data: adequate informs of broken index.js in node-form-data

[shirish शिरीष]

Package: node-form-data
Version: 2.3.2-2
Severity: normal

Usertags: broken-symlink adequate
User: debian...@lists.debian.org

Dear Maintainer,

Thank you for maintaining node-form-data package.

I was updating my system when I saw the following -

$ adequate node-form-data
node-form-data: broken-symlink /usr/lib/nodejs/form-data/index.js ->
form_data.js

On further investigation found that -

/usr/lib/nodejs/form-data$ ls -l index.js
lrwxrwxrwx 1 root root 12 Sep 19 22:32 index.js -> form_data.js

/usr/lib/nodejs/form-data$ cd lib

/usr/lib/nodejs/form-data/lib$ ls
browser.js  form_data.js  populate.js

/usr/lib/nodejs/form-data/lib$ ls -l form_data.js
-rw-r--r-- 1 root root 12249 Feb 14  2018 form_data.js

So the path information needs to be modified. Please do the needful.

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

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

Versions of packages node-form-data depends on:
ii  node-asynckit 0.4.0-2
ii  node-combined-stream  1.0.6-1
ii  node-mime-types   2.1.20-1
ii  nodejs8.11.2~dfsg-1

node-form-data recommends no packages.

node-form-data suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Mike Hommey]

On Sat, Sep 22, 2018 at 08:08:01AM +0900, Mike Hommey wrote:
> On Sat, Sep 08, 2018 at 09:11:46PM +0200, Stephan Goll wrote:
> > Package: firefox-esr
> > Version: 60.2.0esr-1~deb9u2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> > 
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
> > 
> > *** End of the template - remove these template lines ***
> > 
> 
> > After upgrading from 52.9 to 60.2 I got no sound in youtube. I do not
> > user pulseaudio, but in about:buildconfig I cannot see
> > "--enable-alsa". 
> 
> I'm sorry, but something doesn't add up here: 52.9 wasn't built with
> --enable-alsa either, and it wasn't the build system default either, so
> alsa wasn't enabled in 52. In fact, if you look in the firefox-esr bug
> list, you'll find reports about alsa stopping working when people
> upgraded from 45 to 52.
> 
> From that perspective, your report doesn't make sense.

Ah, I wasn't looking at the right branch, and the branch for esr52 *did*
have --enable-alsa as of 52.0.1esr-1.

Mike

Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Koo Zhong Zheng]

Dear Mike,

Good day to you.

By the way, I met this issue as well. However, from what I found on the
related issue, is the
"Pulseaudio" has not been included in package dependency.

Since, the Mozilla had decided to take Pulseaudio support from Firefox 52,
as following official
link:
https://support.mozilla.org/en-US/kb/fix-common-audio-and-video-issues#w_you-may-need-to-
install-the-required-pulseaudio-software

I'm running Debian stable (Stretch), where no issue for firefox-esr
(52.9.0esr-1~deb9u1) to run
without "Pulseaudio", but no sound issue happens for firefox-esr
(60.2.0esr-1~deb9u2). The
warning messages are appended, in this email message, as reference.

Hence, is that possible to add the "Pulseaudio" as required dependency, in
future?

sla@hostname:~$ /usr/bin/firefox-esr --version
Mozilla Firefox 60.2.0
sla@hostname:~$ /usr/bin/firefox-esr  # then "youtube.com" is
loaded.

[Child 51, MediaPlayback #1] WARNING: 7fe8157e7580 OpenCubeb() failed to
init cubeb: file
/build/firefox-esr-QYWh35/firefox-esr-60.2.0esr/dom/media/AudioStream.cpp,
line 388
[Child 51, MediaPlayback #1] WARNING: Decoder=7fe817fe5e20
[OnMediaSinkAudioError]: file
/build/firefox-esr-QYWh35/firefox-esr-60.2.0esr/dom/media/MediaDecoderStateMachine.cpp,
line 3750
[Child 51, MediaPlayback #2] WARNING: Decoder=7fe817fe5e20 Decode error:
NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) -
RefPtr,
mozilla::MediaResult, true> >
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is
detached.: file
/build/firefox-esr-QYWh35/firefox-esr-60.2.0esr/dom/media/MediaDecoderStateMachine.cpp,
line 3445



On Sat, Sep 22, 2018 at 7:39 AM Mike Hommey  wrote:

> On Sat, Sep 08, 2018 at 09:11:46PM +0200, Stephan Goll wrote:
> > Package: firefox-esr
> > Version: 60.2.0esr-1~deb9u2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
> >
> > *** End of the template - remove these template lines ***
> >
>
> > After upgrading from 52.9 to 60.2 I got no sound in youtube. I do not
> > user pulseaudio, but in about:buildconfig I cannot see
> > "--enable-alsa".
>
> I'm sorry, but something doesn't add up here: 52.9 wasn't built with
> --enable-alsa either, and it wasn't the build system default either, so
> alsa wasn't enabled in 52. In fact, if you look in the firefox-esr bug
> list, you'll find reports about alsa stopping working when people
> upgraded from 45 to 52.
>
> From that perspective, your report doesn't make sense.
>
> Mike
>
>

Bug#909343: libcatalyst-perl: fails to build with libmoosex-getopt-perl 0.73-1

[gregor herrmann]

Source: libcatalyst-perl
Version: 5.90118-1
Severity: serious
Tags: upstream sid buster
Justification: fails to build from source
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=127050

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As first noticed by ci.debian.net, one test in libcatalyst-perl fails
with the new libmoosex-getopt-perl 0.73-1.

t/aggregate/unit_core_script_help.t ...
No subtests run
…
Test Summary Report
- ---
t/aggregate/unit_core_script_help.t (Wstat: 0 
Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output


The upstream report at https://rt.cpan.org/Public/Bug/Display.html?id=127050
is undecided if the problem is in Catalyst-Runtime or in
MooseX-Getopt, there's also https://rt.cpan.org/Ticket/Display.html?id=127096


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlulr4FfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbYCA//c9H7i6yDCv1RCgKhxvO4uLY1BJEdYAw+uidNV2aLXXyUfCueJorewdHN
ccZirNKbRwxkkIQtSZYCB0qvlhM0RRdk8//aXR+FM+hSiVeEXp/HRXNrAKji19jT
6JJJkRSoTNEkvc0OIgdi/ljRgKS27r+DLBfFjKV18IiTAdfO45Dbz1zso/7QGkUa
tRGTaP9B3jOVTYT9sCB0UFfvtpDuQ9Svl+aWFY4VIGPDbF/1j4Y5QWf/BdXqsyuN
9Gukw2Zy2RxGYTZ4diHR8Dwh9WGzvX9FBZUkkT39EbtqYPazSF0X4QryTXt4KKQ/
0QDTLQV4EAaXp3GP472LCPNvmZxBUg75QEeczC++gAQCFnnTYjW90PvntNEIy3uV
BaIXbkXEdai8A1vDn3ay8gqOPukcASIDwnqYp7GCmpheru4RofBWzxPnxPfB0k+T
2yo4fkPIjXbttrCUmQ2Wlki8ZMuyfhfJN9SFuGxsoOEg+xRSDgum34Hd7Isr99Gi
0hWTpxZYepyUGDx+mJm3m7SpzWZeeH1xj6cJUgzS23UzEkaHyB4ZmVaLFOFvkMhB
YDFDrJjZkBV+53oNNiahJ434GMZWdrqcvko+FxFtYvGpusEaF6YVwQpJe+oeSx3P
913F96sBqq/cfNEcEjQJF4shi6yrWInGGzZxTefVJsG2EdQsboM=
=632F
-END PGP SIGNATURE-

Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload

[Simon Richter]

Hi,

pulling gnupg or enigmail from backports would only solve the problem
for new installations, but doesn't help users who have both thunderbird
and enigmail installed, only have stretch and stretch-security in the
sources.list (what I'd expect to be the majority) and are now trying to
run "apt upgrade":

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  icedove lightning thunderbird
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

So this is blocking security upgrades.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#909342: adequate: warn about broken alternatives

[Paul Wise]

Package: adequate
Version: 0.15.1
Severity: wishlist

I discovered some broken alternatives and reported them in #909340,
it would be nice if adequate could also report when the alternatives
registry items[1] contain filenames that do not exist on the system
and when the alternatives configuration[2] contains broken symlinks.

   1. /var/lib/dpkg/alternatives/*
   2. /etc/alternatives/*

-- 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.18.0-1-amd64 (SMP w/4 CPU cores)
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 adequate depends on:
ii  debconf  1.5.69
ii  perl 5.26.2-7

Versions of packages adequate recommends:
ii  pkg-config  0.29-4+b1

adequate suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#909341: easy-rsa: use OpenSSL 1.1.1 .include directive in easyrsa-openssl.cnf

[Paul Wise]

Package: easy-rsa
Version: 3.0.4-2
Severity: wishlist

The easyrsa-openssl.cnf file created by make-cadir is a copy of the
default easy-rsa openssl-easyrsa.cnf file. I think it would be better
to generate an openssl-easyrsa.cnf that uses the OpenSSL 1.1.1 .include
directive to include the default file and then allow admins to add
lines overriding the defaults. This way if the defaults change, they
also get automatically updated for existing easy-rsa managed dirs.

-- 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.18.0-1-amd64 (SMP w/4 CPU cores)
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 easy-rsa depends on:
ii  openssl  1.1.1-1

Versions of packages easy-rsa recommends:
pn  opensc  

easy-rsa suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#909340: acpica-tools: update-alternatives: warning: skip creation of ... because associated file ... (of link group ...) doesn't exist

[Paul Wise]

Package: acpica-tools
Version: 20180810-1
Severity: normal

During the recent upgrade I got two warnings from update-alternatives.
This is because two of the manual pages are compressed but the
alternatives are setup pointing to the uncompressed filenames.

$ sudo apt upgrade
...
Preparing to unpack .../acpica-tools_20180810-1_amd64.deb ...
Unpacking acpica-tools (20180810-1) over (20180629-1) ...
Setting up acpica-tools (20180810-1) ...
update-alternatives: using /usr/bin/acpixtract-acpica to provide 
/usr/bin/acpixtract (acpixtract) in auto mode
update-alternatives: warning: skip creation of 
/usr/share/man/man1/acpixtract.1.gz because associated file 
/usr/share/man/man1/acpixtract-acpica.1 (of link group acpixtract) doesn't exist
update-alternatives: using /usr/bin/acpidump-acpica to provide 
/usr/bin/acpidump (acpidump) in auto mode
update-alternatives: warning: skip creation of 
/usr/share/man/man1/acpidump.1.gz because associated file 
/usr/share/man/man1/acpidump-acpica.1 (of link group acpidump) doesn't exist
Processing triggers for man-db (2.8.4-2) ...

$ ls -l /usr/share/man/man1/acpixtract-acpica.1* 
/usr/share/man/man1/acpidump-acpica.1*
-rw-r--r-- 1 root root 1.1K Sep 16 07:23 
/usr/share/man/man1/acpidump-acpica.1.gz
-rw-r--r-- 1 root root  899 Sep 16 07:23 
/usr/share/man/man1/acpixtract-acpica.1.gz

$ grep -A3 update /var/lib/dpkg/info/acpica-tools.postinst 
configure) update-alternatives --install $BINDIR/acpixtract acpixtract \
 $BINDIR/acpixtract-acpica 100 \
--slave $MANDIR/man1/acpixtract.1.gz acpixtract.1.gz \
$MANDIR/man1/acpixtract-acpica.1
   update-alternatives --install $BINDIR/acpidump acpidump \
 $BINDIR/acpidump-acpica 100 \
--slave $MANDIR/man1/acpidump.1.gz acpidump.1.gz \
$MANDIR/man1/acpidump-acpica.1

-- 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.18.0-1-amd64 (SMP w/4 CPU cores)
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 acpica-tools depends on:
ii  libc6  2.27-6

acpica-tools recommends no packages.

acpica-tools suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Yangfl]

Guillem Jover  于2018年9月22日周六 上午8:30写道：
>
> The attached is what I'd include.
>
> Thanks,
> Guillem

$ ./a.out --test
md5 self-test completed successfully.
$ ldd ./a.out
linux-vdso.so.1 (0x7ffc941d6000)
libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x7f0388a58000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f03888c4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0388707000)
/lib64/ld-linux-x86-64.so.2 (0x7f0388c8b000)

Looks great. Thanks!

Bug#845126: firewalld: Please merge configuration during upgrade

[James Valleroy]

Hello,

Just wanted to check, could you consider this patch? Or is there another
approach we could try?

Regards,
James



signature.asc
Description: OpenPGP digital signature

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

On Fri, 2018-09-21 at 19:35:53 +0200, Guillem Jover wrote:
> On Sat, 2018-09-22 at 00:13:47 +0800, Yangfl wrote:
> > Guillem Jover  于2018年9月21日周五 上午7:42写道：
> > > Something like the attached patch would do I guess? I'm not sure if
> > > I'd want to expose those unconditionally, as that might pollute the
> > > namespace.
> > 
> > Please find the attached md5main-md.c, taken from libmd5-rfc but
> > modified to be compiled with -lmd. Notice the segfault here. Clearly
> > MD5End supplies the hash in ASCII hex string, but md5_finish in raw
> > char array. That's not the same.
> 
> Ah indeed sorry, I used initially MD5Final() which is the correct one
> here, but switched to MD5End() because it was failing the libmd test
> suite.
> 
> Patch updated, I'll fix the test suite later today.

The attached is what I'd include.

Thanks,
Guillem
diff --git i/include/md5.h w/include/md5.h
index dee2bf4..2f8b167 100644
--- i/include/md5.h
+++ w/include/md5.h
@@ -47,4 +47,17 @@ char	*MD5Data(const uint8_t *, size_t, char *);
 }
 #endif
 
+/*
+ * Interface compatibility with Aladdin Enterprises independent
+ * implemntation from RFC 1321.
+ */
+
+typedef uint8_t md5_byte_t;
+typedef uint32_t md5_word_t;
+typedef MD5_CTX md5_state_t;
+
+#define md5_init(pms) MD5Init(pms)
+#define md5_append(pms, data, nbytes) MD5Update(pms, data, nbytes)
+#define md5_finish(pms, digest) MD5Final(digest, pms)
+
 #endif /* _MD5_H_ */
diff --git i/test/md5.c w/test/md5.c
index 5dac6e1..f18f398 100644
--- i/test/md5.c
+++ w/test/md5.c
@@ -30,12 +30,55 @@
 #include 
 #include 
 
+static int
+hexchar2bin(int c)
+{
+	if (c >= '0' && c <= '9')
+		return c - '0';
+	else if (c >= 'a' && c <= 'f')
+		return c - 'a' + 10;
+	else if (c >= 'A' && c <= 'F')
+		return c - 'A' + 10;
+	assert(!"invalid hexadecimal input");
+}
+
+static void
+hex2bin(uint8_t *bin, const char *str, size_t bin_len)
+{
+	int i;
+
+	for (i = 0; i < bin_len; i++)
+		bin[i] = hexchar2bin(str[i * 2]) << 4 |
+		 hexchar2bin(str[i * 2 + 1]);
+}
+
 void
-test_md5(const char *digest, const char *string)
+test_md5(const char *digest_str, const char *string)
 {
-	char result[MD5_DIGEST_STRING_LENGTH];
+	uint8_t digest[MD5_DIGEST_LENGTH];
+	uint8_t result[MD5_DIGEST_LENGTH];
+	char result_str[MD5_DIGEST_STRING_LENGTH];
+	MD5_CTX ctx;
+	md5_state_t pms;
+
+	hex2bin(digest, digest_str, MD5_DIGEST_LENGTH);
+
+	assert(strcmp(digest_str, MD5Data(string, strlen(string), result_str)) == 0);
+
+	MD5Init();
+	MD5Update(, string, strlen(string));
+	MD5End(, result_str);
+	assert(strcmp(digest_str, result_str) == 0);
+
+	MD5Init();
+	MD5Update(, string, strlen(string));
+	MD5Final(result, );
+	assert(memcmp(digest, result, MD5_DIGEST_LENGTH) == 0);
 
-	assert(strcmp(digest, MD5Data(string, strlen(string), result)) == 0);
+	md5_init();
+	md5_append(, string, strlen(string));
+	md5_finish(, result);
+	assert(memcmp(digest, result, MD5_DIGEST_LENGTH) == 0);
 }
 
 int

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

[Bernhard Übelacker]

Hello Emmanuel,
I made a mistake and did my first investigations on testing instead of unstable.
So my findings of my first mail are unrelated (but hope they still help).

So I did another try and got all tests fail like in the reproducible build log.


Something bad happens in these lines:
(gdb) list RendererWidget.cpp:589
588 
orientationDecorationsTextMapper[i]->SetInput(orientationDecorationLetters[i].toStdString().c_str());
589 
orientationDecorationsTextMapper[i]->GetTextProperty()->ShallowCopy(orientationDecorationsProp);


Valgrind also points to that location.

For some reason I could not step into the SetInput method and tried
therefore to get further on instruction level and found my self to
my surprise in libvtkRenderingOpenGL2-7.1.so.7.1.

Therefore I assume Andreas is right that libvtkgdcm2.8 started this issue,
as that pulls in libvtk7.1, so we have some vtk6 and some vtk7 libraries in
the same process.

I tried changing debian/control to build agains libvtk7-dev and libvtk7-qt-dev.
With that even more tests crash in the same QGLContext::makeCurrent call,
but thats maybe a different issue.

Kind regards,
Bernhard



With all required dbgsym packages installed the stack looks like this:
(gdb) bt
#0  vtkTextProperty::ShallowCopy (this=0xbae9c9b0, tprop=0x55cdbae92d70) at 
./Rendering/Core/vtkTextProperty.cxx:70
#1  0x7fdb0af837d7 in camitk::RendererWidget::RendererWidget(QWidget*, 
camitk::RendererWidget::ControlMode) () at 
/usr/include/vtk-6.3/vtkSmartPointer.h:77
#2  0x7fdb0af6fd42 in 
camitk::InteractiveViewer::InteractiveViewer(QString&, 
camitk::InteractiveViewer::ViewerType) () at 
./sdk/libraries/core/viewer/InteractiveViewer.cpp:192
#3  0x7fdb0af71533 in camitk::InteractiveViewer::getNewViewer(QString, 
camitk::InteractiveViewer::ViewerType) () at 
./sdk/libraries/core/viewer/InteractiveViewer.cpp:90
#4  0x7fdb0af717c5 in camitk::InteractiveViewer::getViewer(QString) () at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:953
#5  0x7fdb0af71b25 in camitk::InteractiveViewer::getAxialViewer() () at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:953
#6  0x7fdb0af3ca2f in camitk::SingleImageComponent::initRepresentation() () 
at ./sdk/libraries/core/component/image/SingleImageComponent.cpp:94
#7  0x7fdb0af3cb67 in 
camitk::SingleImageComponent::SingleImageComponent(camitk::Component*, 
camitk::Slice::SliceOrientation, QString const&, 
vtkSmartPointer) () at 
./sdk/libraries/core/component/image/SingleImageComponent.cpp:58
#8  0x7fdb0af33fbf in camitk::ImageComponent::buildImageComponents() () at 
/usr/include/vtk-6.3/vtkSmartPointer.h:26
#9  0x7fdb0af36b4d in 
camitk::ImageComponent::setImageData(vtkSmartPointer, bool, 
camitk::ImageOrientationHelper::PossibleImageOrientations, 
vtkSmartPointer) () at 
./sdk/libraries/core/component/image/ImageComponent.cpp:313
#10 0x7fdaf567adf9 in VtkImageComponent::createComponent(QString const&) () 
at /usr/include/vtk-6.3/vtkSmartPointer.h:26
#11 0x7fdaf567b905 in VtkImageComponent::VtkImageComponent(QString const&) 
() at ./sdk/components/vtkimage/VtkImageComponent.cpp:53
#12 0x7fdaf567bf3a in VtkImageComponentExtension::open(QString const&) () 
at ./sdk/components/vtkimage/VtkImageComponentExtension.cpp:76
#13 0x7fdb0af04c24 in camitk::Application::open(QString const&) () at 
./sdk/libraries/core/application/Application.cpp:470
#14 0x55cdb93043df in main () at /usr/include/c++/8/bits/basic_string.h:2293
#15 0x7fdb09eccb17 in __libc_start_main (main=0x55cdb9303e80 , 
argc=5, argv=0x7ffd21845c18, init=, fini=, 
rtld_fini=, stack_end=0x7ffd21845c08) at ../csu/libc-start.c:310
#16 0x55cdb93051aa in _start () at 
./sdk/applications/testactions/main.cpp:189


LANG=C dpkg --purge libvtk7.1
dpkg: dependency problems prevent removal of libvtk7.1:
 libvtkgdcm2.8:amd64 depends on libvtk7.1.


(gdb) info share
>FromTo  Syms Read   Shared Object Library
...
0x77265580  0x77458d2d  Yes 
/usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.3.so.6.3
...
0x7fffe934cee0  0x7fffe9515aed  Yes (*) 
/usr/lib/x86_64-linux-gnu/libvtkCommonCore-7.1.so.7.1


# Unstable:


- change sources.list from buster to unstable
apt update
apt dist-upgrade
reboot
apt autoremove
apt install apt-show-versions
apt-show-versions | grep No
dpkg --purge libdns-export1100

apt build-dep camitk
apt install mc htop systemd-coredump fakeroot gdb valgrind git libvtk6.3-dbgsym 
libqt5core5a-dbgsym


mkdir vtk6/orig -p
cdvtk6/orig
apt source vtk6
cd ../..


mkdir qtbase-opensource-src/orig -p
cdqtbase-opensource-src/orig
apt source qtbase-opensource-src
cd ../..


mkdir camitk/orig -p
cdcamitk/orig
apt source camitk
cd ../..


cd camitk
cp -a orig try1
cd try1/camitk-4.1.2
dpkg-buildpackage



[Sa Sep 22 00:00:04 2018] camitk-testacti[24045]: segfault at bae9c9b0 ip 
7fdb08754f15 sp 7ffd21844f50 error 4 in 

Bug#909339: git-deborig: should ensure .git/info exists before writing attributes

[James Cowgill]

Package: devscripts
Version: 2.18.4
Severity: normal

Hi,

If git-deborig is run in a repository without a .git/info directory, it
fails with:
> could not open .git/info/attributes for writing at /usr/bin/git-deborig line 
> 230.

git-deborig should probably create this directory before hand.

Thanks,
James

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=AEED6158020EAFFF
DEBSIGN_PROGRAM=gpg

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0~rc2
pn  at  
ii  curl7.61.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.07.24
ii  dput-ng [dput]  1.21
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-1
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
ii  licensecheck3.0.31-2
ii  lintian 2.5.104
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.7.0~rc1
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-2
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  5.5
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.5
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
ii  diffoscope   101
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  faketime 0.9.7-2
pn  gnuplot  
ii  gpgv 2.2.10-1
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:7.8p1-1
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-2
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Mike Hommey]

On Sat, Sep 08, 2018 at 09:11:46PM +0200, Stephan Goll wrote:
> Package: firefox-esr
> Version: 60.2.0esr-1~deb9u2
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 

> After upgrading from 52.9 to 60.2 I got no sound in youtube. I do not
> user pulseaudio, but in about:buildconfig I cannot see
> "--enable-alsa". 

I'm sorry, but something doesn't add up here: 52.9 wasn't built with
--enable-alsa either, and it wasn't the build system default either, so
alsa wasn't enabled in 52. In fact, if you look in the firefox-esr bug
list, you'll find reports about alsa stopping working when people
upgraded from 45 to 52.

>From that perspective, your report doesn't make sense.

Mike

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Ben Hutchings]

On Fri, 2018-09-21 at 08:32 -0700, Geoff Levand wrote:
> On 09/20/2018 12:49 PM, Geoff Levand wrote:
> > Attached are the two kernel config patches rebased to the latest
> > v4.18.6-1
> > Buster kernel. 
> 
> Forgot to include the rebased m400 fixup patch.
> 
>   0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
>   0002-arm64-Updates-for-ACPI-servers.patch
>   0003-arm64-Add-fixup-for-HPE-m400-APEI-firmware-problems.patch

I've applied these, with some changes:

0001: Rather than changing the setting of CONFIG_ACPI_NFIT for arm64, I
removed it entirely as it would be redundant with the top-level config.

0002: I dropped several of the config symbols which are automatic.  Any
config symbol that doesn't have a description can only be enabled via
other symbols that select it.  These shouldn't be mentioned in
debian/config files.

I also removed CONFIG_ACPI_CONFIGFS as I have a concern that this
feature allows subverting Secure Boot.  If this feature is important to
you, I can investigate further and maybe add a patch to conditionally
disable it at run-time instead.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.




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

Bug#908156: xpra cannot create directories in /run

[Alex]

Hi.
It seems to work, but still logs an error about the directory to stdout:

Warning: cannot use the system proxy for 'start' subcommand,
 failed to connect to '/run/xpra/system':
 [Errno 2] No such file or directory
 more information may be available in your system log
2018-09-22 00:08:12,217 Warning: failed to write script file in
'/run/user/1000/xpra':
2018-09-22 00:08:12,217  [Errno 2] No such file or directory:
'/run/user/1000/xpra'
2018-09-22 00:08:12,217  ($XDG_RUNTIME_DIR has not been created?)
Entering daemon mode; any further errors will be reported to:
  /home/allo/.xpra/:10.log

Alex

Bug#909319: Show unnecessary overrides

[Mattia Rizzolo]

On Fri, Sep 21, 2018 at 12:14:41PM -0700, Josh Triplett wrote:
> > > ...argh. unused-override is *info*-level?
> > > 
> > > That explains why I didn't see it by default, but is there any
> > > particular reason for that?
> > 
> > It's been that way since at least lintian 1.23 (April 2004) according
> > to git, so I imagine no-one remembers specifically why.
> 
> Would there be any objection to upgrading it to a warning (not an error,
> just a warning)?


Yes, please read /usr/share/doc/lintian/lintian.txt.gz, §2.3:

   Errors (E)
  The displayed message indicates a policy violation or a
  packaging error. For policy violations, Lintian will
  cite the appropriate policy section when it is invoked
  with the -i option.

   Warnings (W)
  The displayed message might be a policy violation or
  packaging error. A warning is usually an indication that
  the test is known to sometimes produce false positive
  alarms, because either the corresponding rule in policy
  has many exceptions or the test uses some sort of
  heuristic to find errors.

   Info (I)
  The displayed message is meant to inform the maintainer
  about a certain packaging aspect. Such messages do not
  usually indicate errors, but might still be of interest
  to the curious. They are not displayed unless the -I
  option is set.

   Pedantic (P)
  The displayed message indicates a message of Lintian at
  its most pickiest and include checks for particular
  Debian packaging styles, checks that are very frequently
  wrong, and checks that many people disagree with. They
  are not displayed unless the --pedantic option is set.


Clearly I is the perfect level for that tag.


I like the proposal to have the number of unused-overrides reported in
the final summary though.

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

Bug#909338: clang-format: lacks symlink to git-clang-format

[brian m. carlson]

Package: clang-format
Version: 1:6.0-43
Severity: normal

The clang-format package depends on clang-format-6.0, which provides a
git-clang-format-6.0.  However, the clang-format package doesn't provide
an unversioned symlink.  This makes using the git clang-format tool from
various scripts (such as Git's makefile) much more difficult.

Could you please include a git-clang-format symlink as part of the
clang-format package?

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

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

Versions of packages clang-format depends on:
ii  clang-format-6.0  1:6.0.1-9

clang-format recommends no packages.

clang-format suggests no packages.

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#909319: Show unnecessary overrides

[Josh Triplett]

Control: retitle -1 Please count "unnecessary overrides" in summary line

On Fri, Sep 21, 2018 at 02:12:58PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> 
> > While I do think unused-override makes sense as a warning, here's an
> > alternative that would have worked for the issue I ran into:
> 
> > Could Lintian's summary line mention unused overrides?
> 
> > The line that says:
> 
> > N: 1 tag overridden (1 error)
> 
> > could say:
> 
> > N: 1 tag overridden (1 error); 1 unnecessary override
> 
> > That would have called attention to the issue, without necessarily
> > emitting an actual warning.
> 
> > Does that seem reasonable?
> 
> That seems reasonable to me, although I'm also curious why you don't want
> to run Lintian with info enabled if you care about this sort of thing.

I probably should. But at the same time, *any* time I have to configure
a tool to use something other than the defaults, I try to figure out if
there's a better default first. :)

Bug#909318: fai-setup-storage failes with INTERNAL ERROR in setup-storage: convert_unit <476.22GiB

[Thomas Lange]

In fai-diskimage we use this line to set the variable

export SS_IGNORE_VG=$(vgs --unbuffered --noheadings -o name --rows)

-- 
regards Thomas

Bug#906183: libopenhpi-dev: broken symlink: /usr/lib/libopenhpi_snmp.so -> libopenhpi_snmp.so.3.8.0

[Devarajulu, Mohanasundaram]

Hello Andreas,


I have modified the dependencies. Because of that additional packages need to 
be loaded during upgrade to get the missing file. If all the packages are 
already installed upgrade goes well. If only few packages (libopenhpi-dev) is 
loaded then they are held back during upgrade. I understand this is expected 
behavior from apt when new packages are brought in during upgrade. However the 
following work well

a. apt-get --with-new-packages upgrade

b. apt-get dist-upgrade

c. apt-get install libopenhpi-dev

I think the above behavior is ok. Is it ok to upload the new release?


Regards

Mohan



From: Andreas Beckmann 
Sent: Wednesday, August 15, 2018 4:12:20 AM
To: Debian Bug Tracking System
Subject: Bug#906183: libopenhpi-dev: broken symlink: 
/usr/lib/libopenhpi_snmp.so -> libopenhpi_snmp.so.3.8.0

Package: libopenhpi-dev
Version: 3.8.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m34.1s ERROR: FAIL: Broken symlinks:
  /usr/lib/libopenhpi_snmp.so -> libopenhpi_snmp.so.3.8.0


You are probably missing a dependency on the corresponding
library package.


cheers,

Andreas

Bug#909318: fai-setup-storage failes with INTERNAL ERROR in setup-storage: convert_unit <476.22GiB

[Thomas Lange]

It's possible to ignore the volume groups of the host system by
setting the variable SS_IGNORE_VG. See man setup-storage for details.

This may help, but I'm not sure if it fixes this completly.

-- 
regards Thomas

Bug#898216: unattended-upgrades: flaky autopkgtest

[Réczey Bálint]

On Fri, Sep 21, 2018, 21:00 Paul Gevers  wrote:

> Hi Balint,
>
> On 05-09-18 22:13, Paul Gevers wrote:
> > On Fri, 6 Jul 2018 14:06:32 +0200 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
> >  wrote:
> >> I monitored the runs for some time and the test does not seem to be
> >> flaky in unstable. Since I added a new test with debootstrap I keep
> >> monitoring it and it shows to be flaky I may add retries somewhere.
> >
> > September 2, 2018:
> >
> https://ci.debian.net/data/autopkgtest/testing/amd64/u/unattended-upgrades/926140/log.gz
> >
> > In unstable August 23, 2018:
> >
> https://ci.debian.net/data/autopkgtest/unstable/amd64/u/unattended-upgrades/871383/log.gz
>
> unattended-upgrades is failing now in testing with python-apt/1.7.0~rc1
> twice in a row. Can you check that this is a real regression or again
> just unattended-upgrades being flaky?
>

It is, I have the fix waiting for review on GitHub.

Cheers,
Balint


> Paul
>
>

Bug#909331: proftpd-basic: The '%u' variable is not fully interpreted for SFTPAuthorizedUserKeys parameter

[Nicolas Couturier]

I'm on unstable on my laptop.

Let me try.


Le 21/09/2018 à 21:02, Hilmar Preuße a écrit :

On 21.09.2018 20:20, Nicolas Couturier wrote:


Package: proftpd-basic
Version: 1.3.5b-4
Severity: normal



Do you have the chance to retest on Debian unstable or should I do for you?

Hilmar

Bug#909319: Show unnecessary overrides

[Russ Allbery]

Josh Triplett  writes:

> While I do think unused-override makes sense as a warning, here's an
> alternative that would have worked for the issue I ran into:

> Could Lintian's summary line mention unused overrides?

> The line that says:

> N: 1 tag overridden (1 error)

> could say:

> N: 1 tag overridden (1 error); 1 unnecessary override

> That would have called attention to the issue, without necessarily
> emitting an actual warning.

> Does that seem reasonable?

That seems reasonable to me, although I'm also curious why you don't want
to run Lintian with info enabled if you care about this sort of thing.  Or
is this about the default view in the package tracker?

-- 
Russ Allbery (r...@debian.org)   

Bug#909319: Show unnecessary overrides

[Josh Triplett]

On Fri, Sep 21, 2018 at 01:18:08PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> 
> > Would there be any objection to upgrading it to a warning (not an error,
> > just a warning)?
> 
> I vaguely recall us considering doing that, but the concern was that
> overrides are a mechanism to keep people using Lintian who are pretty
> sensitive to unnecessary tags.  So giving people a way to just make the
> tag go away and not bother them about it felt a touch inconsistent with
> making the unused-override tag a warning, particularly since there were
> (are?) a few Lintian tags that can come and go with different versions of
> the package or builds on different architectures.
> 
> Lintian in general uses warning as the level of "we really think every
> packager should know about this stuff even if you don't really like
> linters or Lintian in particular," and info as the level of "okay, you
> actually care about Lintian, so we're going to show you all the things we
> think are reasonably fixable."

While I do think unused-override makes sense as a warning, here's an
alternative that would have worked for the issue I ran into:

Could Lintian's summary line mention unused overrides?

The line that says:

N: 1 tag overridden (1 error)

could say:

N: 1 tag overridden (1 error); 1 unnecessary override

That would have called attention to the issue, without necessarily
emitting an actual warning.

Does that seem reasonable?

Bug#902256: [freshplayerplugin] Broken with the latest Firefox versions

[Gunnar Hjalmarsson]

Thanks for working on this! There are two things you need to deal with to be 
able to build:

* The libpdf and NaCl wrappers have been dropped upstream, so you need
  to drop the -libpdf and -nacl binaries.

* You need to patch an upstream commit to make it build with latest
  ffmpeg. It's this commit:

  https://github.com/i-rinat/freshplayerplugin/commit/934aa9c2

We have built it successfully on Ubuntu, so you may want to check what the 
debian/ folder looks like there.

https://launchpad.net/ubuntu/+source/freshplayerplugin/0.3.9-0ubuntu3

Please note, though, that we have a couple of Ubuntu specific changes which are 
not suitable for Debian.

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#909305: RFS: android-platform-system-core/1:8.1.0+r23-1~stage1.1

[殷啟聰 | Kai-Chung Yan]

Hello Roger! 
> I just quickly checked the version on salsa, and find d/changelog is
> not uploaded yet.

I was planning to push the changes to Salsa after it gets uploaded. I just did 
it a while ago.

> So could you change the version to 1:8.1.0+r23-1~stage2 ?

No, we will stick with this version. This release isn't a stage2 one but a fix 
for the previous release, which FTBFS on armel and MIPS family.



signature.asc
Description: OpenPGP digital signature

Bug#909337: RFP: crux-el -- A Collection of Ridiculously Useful eXtensions for Emacs

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
User: debian-emac...@lists.debian.org
Usertags: elpafy

* Package name: crux-el
  Version : 0.3.0 (or git snapshot)
  Upstream Author : Bozhidar Batsov 
* URL : https://github.com/bbatsov/crux/
* License : GPL-3+
  Programming Lang: elisp
  Description : A Collection of Ridiculously Useful eXtensions for Emacs

A Collection of Ridiculously Useful eXtensions for Emacs. crux bundles
a few useful interactive commands to enhance your overall Emacs
experience.



CRUX bundles a bunch of functions I happened to have written versions
of myself as keyboard macros or .emacs functions, which is silly.

My favorites are:

 * crux-transpose-windows
 * crux-rename-file-and-buffer

But there are way more in there I would like to get familiar with.

This should probably be under the Emacs team umbrella and I don't have
time to personally package it right now. I would be happy to review
and sponsor a package however.

Bug#909336: RFP: atomic-chrome-el -- Edit text area on Chrome with Emacs using Atomic Chrome

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
User: debian-emac...@lists.debian.org
Usertags: elpafy

* Package name: atomic-chrome-el
  Version : v2.0.0 (or git snapshot?)
  Upstream Author : "alpha22jp"
* URL : https://github.com/alpha22jp/atomic-chrome
* License : GPL-2+
  Programming Lang: elisp
  Description : Edit text area on Chrome with Emacs using Atomic Chrome

This is the Emacs version of Atomic Chrome which is an extension for
Google Chrome browser that allows you to edit text areas of the
browser in Emacs. It's similar to Edit with Emacs, but has some
advantages as below with the help of websocket.

 * The input on Emacs is reflected to the browser instantly and
   continuously.
 * You can use both the browser and Emacs at the same time. They are
   updated to the same content bi-directionally.

Since v2.0.0, Atomic Chrome for Emacs supports Ghost Text as browser
extension, bringing compatibility with Firefox, too.



I use this to edit text areas in a web browser with my favorite
editor. It works with the Atomic Chrome or Ghost Text extensions in
Google Chrome / Chromium or Firefox.

This should probably be under the Emacs team umbrella and I don't have
time to personally package it right now. I would be happy to review
and sponsor a package however.

Bug#908889: src:firefox-esr: Fix broken ppc64 build

[Team Power Progress Community]

Hi Mike,
i've compiled ff as suggested on ppc64be.

more info :
a) running firefox-esr on powermac G5 (ppc64) crashes without even opening
a window;
b) passing --safe-mode does not make any difference;
c) i attach some debug info from gdb, how can i help further ?

Regards,
Roberto

 DEBUG INFO ---

debian@rt1kg5e:~$ gdb firefox-esr
GNU gdb (Debian 8.1-4) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from firefox-esr...Reading symbols from
/usr/lib/debug/.build-id/16/d27c27ff704d507a098c1b28d7aa53a5ce5b1c.debug...done.
done.
(gdb) r
Starting program: /usr/bin/firefox-esr
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00019ae8 in RedBlackTree::TreeNode::SetColor
(this=, aColor=)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/build-browser/dist/include/mozilla/Assertions.h:40
40gMozCrashReason = reason;
(gdb) bt full
#0  0x00019ae8 in RedBlackTree::TreeNode::SetColor(NodeColor) (this=,
aColor=)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/build-browser/dist/include/mozilla/Assertions.h:40
#1  0x0001000116d4 in RedBlackTree::TreeNode::SetColor(NodeColor) (this=, aColor=Red)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/rb.h:201
node = 
rbp_mrr_t = 
#2  0x0001000116d4 in RedBlackTree::MoveRedRight(RedBlackTree::TreeNode) (this=, aNode=...)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/rb.h:668
node = 
rbp_mrr_t = 
#3  0x0001000118d0 in RedBlackTree::Remove(RedBlackTree::TreeNode) (this=0x77800080, aNode=...)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/rb.h:104
rbp_r_s =
{u = {mBytes =
"\000\000\177\377\364\240\001\270\000\000\000\000\000\000\000\000\000\000\177\377\377\377\322",
, mDummy = 140737297514936}}
rbp_r_p = {mNode = 0x74a001b8}
rbp_r_c = 
rbp_r_xp = 
rbp_r_t = 
rbp_r_u = 
rbp_r_cmp = 
#4  0x000100012d30 in RedBlackTree::
Remove(arena_chunk_map_t*) (aNode=0x74b00038, this=0x77800080)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/rb.h:159
chunk = 0x74b0
old_ndirty = 1
run_ind = 1
total_pages = 2147480753
need_pages = 8
rem_pages = 2147480745
i = 
#5  0x000100012d30 in arena_t::SplitRun(arena_run_t*, unsigned long,
bool, bool) (this=this@entry=0x7780,
aRun=aRun@entry=0x74b1, aSize=aSize@entry=524288,
aLarge=,
aLarge@entry=false, aZero=)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/mozjemalloc.cpp:2384
chunk = 0x74b0
old_ndirty = 1
run_ind = 1
total_pages = 2147480753
need_pages = 8
rem_pages = 2147480745
i = 
#6  0x000100012fe8 in arena_t::AllocRun(unsigned long, bool, bool)
(this=0x7780, aSize=524288, aLarge=aLarge@entry=false,
aZero=aZero@entry=false)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/mozjemalloc.cpp:2562
run = 0x74b1
mapelm = 
key =
  {link = {mLeft = , mRightAndColor = }, bits = 524304}
#7  0x0001000150d0 in arena_t::GetNonFullBinRun(arena_bin_t*)
(this=, aBin=0x77800868)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/mozjemalloc.cpp:2812
run = 
i = 
remainder = 
aBin = 0x77800868
mapelm = 0x0
run = 
#8  0x000100016d1c in arena_t::MallocSmall(unsigned long, bool)
(aZero=true, aSize=8192, this=0x7780)
at
/home/debian/rt1k/debian/pck/rebuild/firefox-esr/firefox-esr-60.2.0esr/memory/build/mozjemalloc.cpp:2958
ret = 
bin = 0x77800868
run = 
sizeClass = {mType = SizeClass::SubPage, mSize = 8192}
arena = 0x7780
checkedSize = {mValue = , mIsValid = true}
ret = 
#9  

Bug#909275: [Pkg-privacy-maintainers] Bug#909275: xorg-server breaks onioncircuits autopkgtest: expected string, NoneType found

[Paul Gevers]

Hi Sascha,

On 21-09-18 09:29, Sascha Steinbiss wrote:
> I would be tempted to close the bug and maybe adapt the error message given 
> in the test. Any arguments against that?

Julien already assigned the bug to onioncircuits, and looking at the
test history, I think he has a point with his re-titling of the bug. It
seems that onioncircuits is failing once in a while without clear reasons.

Recent discussion of gating migration by autopkgtests on debian-devel
[1] noted that if this is going to work, and in particular if we are
going to *block* migration when it causes autopkgtest regressions rather
than merely delaying it, intermittent autopkgtest failures are likely to
have to be considered RC due to their impact on the tested package's
dependencies.

Paul

[1] https://lists.debian.org/debian-devel/2018/05/msg00061.html



signature.asc
Description: OpenPGP digital signature

Bug#909319: Show unnecessary overrides

[Russ Allbery]

Josh Triplett  writes:

> Would there be any objection to upgrading it to a warning (not an error,
> just a warning)?

I vaguely recall us considering doing that, but the concern was that
overrides are a mechanism to keep people using Lintian who are pretty
sensitive to unnecessary tags.  So giving people a way to just make the
tag go away and not bother them about it felt a touch inconsistent with
making the unused-override tag a warning, particularly since there were
(are?) a few Lintian tags that can come and go with different versions of
the package or builds on different architectures.

Lintian in general uses warning as the level of "we really think every
packager should know about this stuff even if you don't really like
linters or Lintian in particular," and info as the level of "okay, you
actually care about Lintian, so we're going to show you all the things we
think are reasonably fixable."

-- 
Russ Allbery (r...@debian.org)   

Bug#861128: RFP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs

[Antoine Beaupré]

On 2018-09-17 22:40:10, Nicholas D Steeves wrote:
> Re: a couple of markdown-toc bugs:
>
> https://github.com/ardumont/markdown-toc/issues/29
>   * Solve in Debian with a hard depends on >= markdown-mode 2.2?
>   * You mentioned markdown-mode 2.1 is bad, 20161222.1416 is good,
> and 2.2 is from 20170526, thus 2.2 should be good.
>   * possibly fixed in markdown-toc?

I can't reproduce this with the markdown-mode version in Debian. It
might still occur with the version in stable, but then the bugfix is
just an upgrade away.

> https://github.com/ardumont/markdown-toc/issues/15
>   * "Don't assume that a document has an h1"
>   * How serious is this one?  Seems like it could be annoying.

I just tested this and can confirm the bug happens with your version of
the package as well.

It's not a big deal: the generated TOC can be modified by hand so extra
content or errors can be easily fixed. In fact, I very often tweak the
TOC by hand myself because it's easier than changing the settings
(e.g. to remove a subsection and so on).

> https://github.com/ardumont/markdown-toc/issues/35
>   * "Lines starting with # in code sections are treated as headings"
>   * I imagine this one will frustrate many users.

I can't reproduce this one, but this may be because of the version of
markdown.el in Debian (2.3snapshot154).

So, conclusion: I'd be happy to sponsor the package as is any time. Just
let me know when you're ready and let's get this one out the door!

A.
-- 
People in glass houses shouldn't throw stones.
People in glass cities shouldn't fire missiles.
- Banksy

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

[Andreas Tille]

On Fri, Sep 21, 2018 at 07:05:40PM +0200, Emmanuel Promayon wrote:
> Andreas, do you have any smart way to check the list of packages that have
> changed/been uploaded in sid in the dependencies of a package during a
> period of time (here from 9 Sep to 15 Sep)? This might help me finding how
> to solve this.

Since you mentioned vtk in your long text I simply checked

https://tracker.debian.org/libvtkgdcm2-dev

I think we have found a probably candidate (see "news" section).
(gdcm Uploaders in CC - please check the full bug log of this bug)

Hope this helps

Andreas.

-- 
http://fam-tille.de

Bug#904558: What should happen when maintscripts fail to restart a service

[Tollef Fog Heen]

]] Ian Jackson 

> Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts 
> fail to restart  a service"):

[...]

> > This means that failure to start a daemon should generally not cause the
> > postinst to fail.
> 
> ... I disagree with that.  I think that in the usual case, if the
> daemon is broken, and the package's purpose is to provide that daemon
> service, then the package probably isn't providing its API.

I don't think dpkg relationships are a good fit for expressing those
kinds of statements.  They are not about in-memory and process state
management, they're about what's on disk.

[...]

> Also:
> 
> > The API provided by a package being in the configured state is not
> > whether the relevant daemon is running or not; that is runtime and can
> > and will change many times while the package is in the configured state,
> > so dpkg dependencies are not useful for expressing "this service must be
> > running".
> 
> I disagree with this.
> 
> dpkg dependencies are not just about what sets of packages can be
> coinstalled.  They also imply sequencing of package setup.  And since
> starting daemons is part of package setup, dpkg dependencies imply a
> sequencing of daemon startup.

If you include the word «attempted» there, I might agree.  policy-rc.d
for instance enters the picture here.  Blacklisting in the init system
does as well, probably others too.  The landscape is pretty crowded with
actors.

> That is actually necessary in the case where the startup of daemon B
> can only successfully completed if daemon A is up,

That's the job of the init system's dependency resolution mechanisms,
not dpkg's.  dpkg does not have information about what is running and so
can't do this.  Ordering is also separate from dependencies, at least
for some init systems.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#861128: RFP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs

[Antoine Beaupré]

On 2018-09-18 18:14:04, Nicholas D Steeves wrote:
> Hey Antoine,
>
> Package ready for testing from:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/m/markdown-toc-el/markdown-toc-el_0.1.2-1.dsc
>
> Upstream included an autoload cookie so 'markdown-toc-generate-toc'
> works out of the box.  I can provide a deb and signed changes if that
> would be more convenient.  In particular someone needs to test
> 'markdown-toc-user-toc-structure-manipulation-fn' before I can
> responsibly file an RFS bug.

I actually got time to look into the packaging more.

It seems to me the release-notes.md could be shipped with
dh_installchangelogs instead of as is, because it is effectively a
changelog.

I'm testing the package now but the source looks good otherwise.

A.
-- 
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain

Bug#904558: What should happen when maintscripts fail to restart a service

[Tollef Fog Heen]

]] Wouter Verhelst 

> On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:

[...]

> > The API provided by a package being in the configured state is not
> > whether the relevant daemon is running or not; that is runtime and can
> > and will change many times while the package is in the configured state,
> > so dpkg dependencies are not useful for expressing «this service must be
> > running».
> 
> No. But it *is* a useful way to express "this service must be able to
> run".

That's not what «configured» means, though.  «apt install foo ; rm
/etc/foo.conf» and the package will be in a «running, but can't restart»
state, but also configured in dpkg terms.

> Additionally, if something fails to restart, then that is a serious
> problem that I, as a system administrator, would like to know about.
> Failure to configure a package signals that there is a serious problem
> that I need to fix, so that informs me.

I think monitoring should be implemented using monitoring tools, so if
you actually care if a service is up, you should monitor it rather than
relying on postinsts failing or succeeding.

Alternatively, you could just add «systemctl is-system-running» to a
post-dpkg-invoke hook, it'll tell you if there are daemons that have
failed.

[...]

> There are really only two[1] reasons why a daemon could fail to restart:
> 
> - The maintainer made a mistake in the default configuration, and the
>   user didn't make any changes so the old conffiles are being replaced
>   by the new ones, or the package is being newly installed; now the
>   daemon encounters a syntax error. This is a bug, plain and simple, and
>   catching bugs earlier rather than later is a good idea, which will
>   happen if the daemon restart failure causes a postinst failure.
> - The maintainer made no mistake, but the upgrading user made some local
>   changes, so the conffile system ensures that the syntactic differences
>   in the configuration are not incorporated and the daemon fails to
>   restart. As a system administrator, I would want to know when
>   something like that happens sooner rather than later, so that I can
>   fix it (also sooner rather than later). Failing to finish postinst
>   correctly ensures that that does happen.

In addition to this: Any number of runtime problems.  The disk might be
full.  The service might try to look up a user whose name is in LDAP and
the network is down and thus the user lookup fails.  Some hardware the
service needs is not plugged in or doesn't work correctly.  Data files
are corrupted.  Out of memory.  I'm sure you can come up with more. :-)

This then also ties into what the semantics of «daemon is started»
should be: is it that the service has started, or that it is working?
What should happen if you, on a host with no network connectivity (or
just heavily firewalled), do «apt install ntp»?  Should it wait until
the clock is synced (effectively forever in this case?  Should the
postinst fail until you've fixed the firewall?)?

> [1] There is also the possibility of "the package ships with incomplete
> configuration on purpose, because there are no sane defaults to use
> and installing the package requires manual steps from the maintainer
> before it can be made to work", but (a) our best practices recommend
> against doing that if at all possible, and (b) in that case starting
> the daemon shouldn't even be attempted from postinst, and so failure
> to start can't be a consideration in the exit state of postinst.

You might still want to restart it on upgrade to ensure you don't run
outdated binaries.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#909335: ITP: python-glad -- GL/GLES/EGL/GLX/WGL Loader-Generator

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-glad
* URL : https://github.com/Dav1dde/glad
* License : MIT
  Description : GL/GLES/EGL/GLX/WGL Loader-Generator

The package is team-maintained on
https://salsa.debian.org/python-team/modules/glad

 This package provides the implementation of what is also available as
 a webservice on
  http://glad.dav1d.de/
 to transform OpenGL specs into an API that one can program against.
 It uses the official Khronos-XML specs to generate a GL/GLES/EGL/GLX/WGL
 Loader made for your needs. Glad currently supports the languages C,
 D and Volt.
 .
 The package is not meant for end users and will not be installed
 by the users of the package that it helped building.  It is a build
 dependency that is prepared to be integrated with CMake or Conan into
 the build process.

Bug#909334: ITP: openrazer -- OpenRazer peripheral drivers

[Dylan Aïssi]

Package: wnpp
Severity: wishlist
Owner: Dylan Aïssi 

Package name: openrazer
URL: https://openrazer.github.io/
License: GPL-2+
Description: OpenRazer peripheral drivers
 OpenRazer is a collection of GNU/Linux drivers for the Razer devices.
 Supported devices include keyboards, mice, mouse-mats, headsets and
 various other devices.

Current packaging take place at:
https://salsa.debian.org/daissi-guest/openrazer

Bug#909333: [python3-sympy] Please update to 1.3

[Alexander Kernozhitsky]

Package: python3-sympy
Version: 1.2-1
Severity: wishlist

SymPy 1.3 is available now, please update the version in Debian.

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-1-amd64

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-==
python3:any(>= 3.3.2-2~) | 
python3-mpmath   | 1.0.0-1


Recommends (Version) | Installed
-+-===
python3-pil  | 5.2.0-2
ipython3 | 5.5.0-1
python3-numpy| 1:1.14.5-1+b1


Suggests (Version) | Installed
==-+-===
texlive-fonts-extra| 2018.20180824-1
dvipng | 1.15-1
python-sympy-doc   | 
-- 
Alexander Kernozhitsky

Bug#909319: Show unnecessary overrides

[Josh Triplett]

On Fri, Sep 21, 2018 at 08:04:37PM +0100, Adam D. Barratt wrote:
> On Fri, 2018-09-21 at 11:58 -0700, Josh Triplett wrote:
> > On Fri, Sep 21, 2018 at 07:44:05PM +0100, Adam D. Barratt wrote:
> > > On Fri, 2018-09-21 at 11:40 -0700, Josh Triplett wrote:
> > > > It no longer triggers that tag as of lintian 2.5.104, which
> > > > allows
> > > > metapackages to depend on toolchain packages.
> > > 
> > > Right, sorry, I missed that the stretch-backports package is
> > > lagging a
> > > little.
> > > 
> > > However, running from a current lintian git checkout gives:
> > > 
> > > adam@jacala:~/code/debian/lintian$ ./frontend/lintian -I -E --
> > > pedantic --show-overrides ../../josh-meta/target/josh-
> > > dev_77_all.deb 
> > > P: josh-dev: copyright-refers-to-symlink-license usr/share/common-
> > > licenses/GPL
> > > I: josh-dev: unused-override binary-package-depends-on-toolchain-
> > > package
> > > 
> > > which looks like exactly what was expected?
> > 
> > ...argh. unused-override is *info*-level?
> > 
> > That explains why I didn't see it by default, but is there any
> > particular reason for that?
> 
> It's been that way since at least lintian 1.23 (April 2004) according
> to git, so I imagine no-one remembers specifically why.

Would there be any objection to upgrading it to a warning (not an error,
just a warning)?

Bug#909331: proftpd-basic: The '%u' variable is not fully interpreted for SFTPAuthorizedUserKeys parameter

[Hilmar Preuße]

On 21.09.2018 20:20, Nicolas Couturier wrote:

> Package: proftpd-basic
> Version: 1.3.5b-4
> Severity: normal
> 
> 
Do you have the chance to retest on Debian unstable or should I do for you?

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

Bug#909319: Show unnecessary overrides

[Adam D. Barratt]

On Fri, 2018-09-21 at 11:58 -0700, Josh Triplett wrote:
> On Fri, Sep 21, 2018 at 07:44:05PM +0100, Adam D. Barratt wrote:
> > On Fri, 2018-09-21 at 11:40 -0700, Josh Triplett wrote:
> > > It no longer triggers that tag as of lintian 2.5.104, which
> > > allows
> > > metapackages to depend on toolchain packages.
> > 
> > Right, sorry, I missed that the stretch-backports package is
> > lagging a
> > little.
> > 
> > However, running from a current lintian git checkout gives:
> > 
> > adam@jacala:~/code/debian/lintian$ ./frontend/lintian -I -E --
> > pedantic --show-overrides ../../josh-meta/target/josh-
> > dev_77_all.deb 
> > P: josh-dev: copyright-refers-to-symlink-license usr/share/common-
> > licenses/GPL
> > I: josh-dev: unused-override binary-package-depends-on-toolchain-
> > package
> > 
> > which looks like exactly what was expected?
> 
> ...argh. unused-override is *info*-level?
> 
> That explains why I didn't see it by default, but is there any
> particular reason for that?

It's been that way since at least lintian 1.23 (April 2004) according
to git, so I imagine no-one remembers specifically why.

Regards,

Adam

Bug#909319: Show unnecessary overrides

[Josh Triplett]

On Fri, Sep 21, 2018 at 07:44:05PM +0100, Adam D. Barratt wrote:
> On Fri, 2018-09-21 at 11:40 -0700, Josh Triplett wrote:
> > It no longer triggers that tag as of lintian 2.5.104, which allows
> > metapackages to depend on toolchain packages.
> 
> Right, sorry, I missed that the stretch-backports package is lagging a
> little.
> 
> However, running from a current lintian git checkout gives:
> 
> adam@jacala:~/code/debian/lintian$ ./frontend/lintian -I -E --pedantic 
> --show-overrides ../../josh-meta/target/josh-dev_77_all.deb 
> P: josh-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
> I: josh-dev: unused-override binary-package-depends-on-toolchain-package
> 
> which looks like exactly what was expected?

...argh. unused-override is *info*-level?

That explains why I didn't see it by default, but is there any
particular reason for that?

Bug#909332: gnome-shell: grp:shifts_toggle keyboard layout switch depends on the sequence in which Shift keys are pressed

[Alexander Kuznetsov]

Package: gnome-shell
Version: 3.30.0-1
Severity: normal
Tags: upstream

I have two keyboard layouts and switch them with both Shift keys together.

If I hold LShift and press RShift, the layout switches.
If I hold RShift and press LShift, it does not.

All is normal if I use xset to configure such behavior at X11 level, but have
the glitch if I do it at Gnome.


$ gsettings list-recursively org.gnome.desktop.input-sources
org.gnome.desktop.input-sources show-all-sources false
org.gnome.desktop.input-sources xkb-options ['terminate:ctrl_alt_bksp',
'grp:shifts_toggle']
org.gnome.desktop.input-sources per-window false
org.gnome.desktop.input-sources current uint32 0
org.gnome.desktop.input-sources mru-sources @a(ss) []
org.gnome.desktop.input-sources sources [('xkb', 'us'), ('xkb', 'ru')]



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  evolution-data-server3.28.5-3
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.30.0-2
ii  gir1.2-freedesktop   1.58.0-1
ii  gir1.2-gcr-3 3.28.0-1
ii  gir1.2-gdesktopenums-3.0 3.28.0-1
ii  gir1.2-gdm-1.0   3.28.2-4
ii  gir1.2-geoclue-2.0   2.4.12-2
ii  gir1.2-glib-2.0  1.58.0-1
ii  gir1.2-gnomebluetooth-1.03.28.2-2
ii  gir1.2-gnomedesktop-3.0  3.30.0-1
ii  gir1.2-gtk-3.0   3.22.30-2
ii  gir1.2-gweather-3.0  3.28.2-1
ii  gir1.2-ibus-1.0  1.5.19-1
ii  gir1.2-mutter-3  3.30.0-1
ii  gir1.2-nm-1.01.12.2-3
ii  gir1.2-nma-1.0   1.8.18-1
ii  gir1.2-pango-1.0 1.42.4-3
ii  gir1.2-polkit-1.00.105-21
ii  gir1.2-rsvg-2.0  2.40.20-3
ii  gir1.2-soup-2.4  2.64.0-2
ii  gir1.2-upowerglib-1.00.99.8-2
ii  gjs  1.52.3-2
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.0-1
ii  gnome-shell-common   3.30.0-1
ii  gsettings-desktop-schemas3.28.0-1
ii  libatk-bridge2.0-0   2.30.0-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libcroco30.6.12-2
ii  libecal-1.2-19   3.28.5-3
ii  libedataserver-1.2-233.28.5-3
ii  libgcr-base-3-1  3.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libgirepository-1.0-11.58.0-1
ii  libgjs0g [libgjs0-libmozjs-52-0] 1.52.3-2
ii  libglib2.0-0 2.58.0-4
ii  libglib2.0-bin   2.58.0-4
ii  libgstreamer1.0-01.14.2-2
ii  libgtk-3-0   3.22.30-2
ii  libical3 3.0.3-1
ii  libjson-glib-1.0-0   1.4.2-4
ii  libmutter-3-03.30.0-1
ii  libnm0   1.12.2-3
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpolkit-agent-1-0  0.105-21
ii  libpolkit-gobject-1-00.105-21
ii  libpulse-mainloop-glib0  12.2-2
ii  libpulse012.2-2
ii  libsecret-1-00.18.6-2
ii  libstartup-notification0 0.12-5
ii  libsystemd0  239-9
ii  libx11-6 2:1.6.6-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.0-1
ii  python3  3.6.5-3

Versions of packages gnome-shell recommends:
ii  bolt  0.3-2
ii  chrome-gnome-shell9-1
ii  gdm3  3.28.2-4
ii  gkbd-capplet  3.26.0-3
ii  

Bug#907887: dnsmasq: Update root DNSSEC trust anchor in stretch and jessie

[Santiago Ruano Rincón]

On Mon, 3 Sep 2018 17:18:41 +0200 "Santiago R.R."  wrote:
> Source: dnsmasq
> Version: 2.72-3+deb8u2
> Severity: important
> Tags: patch
> 
> Hi Simon,
> 
> The DNS Root Key Signing Key (KSK) Rollover is scheduled for 11 October
> 2018 [1]. After this date, DNS resolvers will need to have the new key
> (KSK-2017) to perform DNSSEC validation.
> 
> [1] https://www.icann.org/news/announcement-2018-08-22-en

Hi Simon,

Please find attached a NMU debdiff that would include the KSK in
stretch. May I proceed and ask release team approval, or do you want to
handle the change by yourself?

Cheers,

 -- Santiago
diff -u dnsmasq-2.76/debian/changelog dnsmasq-2.76/debian/changelog
--- dnsmasq-2.76/debian/changelog
+++ dnsmasq-2.76/debian/changelog
@@ -1,3 +1,11 @@
+dnsmasq (2.76-5+deb9u1.1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * trust-anchors.conf: include latest DNS trust anchor KSK-2017.
+(Closes: #907887)
+
+ -- Santiago Ruano Rincón   Fri, 21 Sep 2018 17:06:18 
+0200
+
 dnsmasq (2.76-5+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
only in patch2:
unchanged:
--- dnsmasq-2.76.orig/trust-anchors.conf
+++ dnsmasq-2.76/trust-anchors.conf
@@ -1,9 +1,10 @@
-# The root DNSSEC trust anchor, valid as at 30/01/2014
+# The root DNSSEC trust anchor, valid as at 10/02/2017
 
 # Note that this is a DS record (ie a hash of the root Zone Signing Key) 
 # If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml
 
 
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
+trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
 
 
 


signature.asc
Description: PGP signature

Bug#898216: unattended-upgrades: flaky autopkgtest

[Paul Gevers]

Hi Balint,

On 05-09-18 22:13, Paul Gevers wrote:
> On Fri, 6 Jul 2018 14:06:32 +0200 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
>  wrote:
>> I monitored the runs for some time and the test does not seem to be
>> flaky in unstable. Since I added a new test with debootstrap I keep
>> monitoring it and it shows to be flaky I may add retries somewhere.
> 
> September 2, 2018:
> https://ci.debian.net/data/autopkgtest/testing/amd64/u/unattended-upgrades/926140/log.gz
> 
> In unstable August 23, 2018:
> https://ci.debian.net/data/autopkgtest/unstable/amd64/u/unattended-upgrades/871383/log.gz

unattended-upgrades is failing now in testing with python-apt/1.7.0~rc1
twice in a row. Can you check that this is a real regression or again
just unattended-upgrades being flaky?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)

[Sergio Mendoza]

Hi Ilias,

  Unfortunately, no matter how hard I look for to spot the problem, I have
not find the culprit package.  I tried and tried, but couldn't.  This is
the reason I reported the bug to goobook.  Sorry for not being more
helpful.

Regards,

Sergio.

-- 
Sergio Mendoza  
Instituto de Astronomia, UNAM
http://www.mendozza.org/sergio

On Fri, Sep 21, 2018 at 07:39:29PM +0300, Ilias Tsitsimpis wrote:
> Hi Sergio,
> 
> On Sat, Sep 15, 2018 at 11:28AM, Sergio Mendoza wrote:
> > Hi again,
> > 
> >   Today after an upgrade once again the problem appears:
> 
> Do you know which package you updated that broke goobook?
> 
> > sergio@izta:~$ goobook query sergio
> > Traceback (most recent call last):
> >   File "/usr/bin/goobook", line 11, in 
> > load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
> >   File "/usr/share/goobook/goobook/application.py", line 94, in main
> > args.func(config, args)
> >   File "/usr/share/goobook/goobook/application.py", line 125, in do_query
> > goobk = GooBook(config)
> >   File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> > self.cache.load()
> >   File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> > self.update()
> >   File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> > self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
> >   File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contacts
> > res = self._get(query)
> >   File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
> > connection_type=httplib2.HTTPSConnectionWithTimeout)
> >   File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", 
> > line 562, in new_request
> > redirections, connection_type)
> >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> > 1608, in request
> > (response, content) = self._request(conn, authority, uri, request_uri, 
> > method, body, headers, redirections, cachekey)
> >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> > 1350, in _request
> > (response, content) = self._conn_request(conn, request_uri, method, 
> > body, headers)
> >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> > 1272, in _conn_request
> > conn.connect()
> >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> > 1059, in connect
> > raise SSLHandshakeError(e)
> > httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
> > verify failed (_ssl.c:726)
> 
> The above traceback mentions 
> "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py".
> This is not the canonical location where Debian Python packages get
> installed. I believe you have installed a different version of the
> httplib2 module using pip. Could you please test using the Python module
> provided by the python-httplib2 package?
> 
> Cheers,
> 
> -- 
> Ilias

Bug#909319: Show unnecessary overrides

[Adam D. Barratt]

On Fri, 2018-09-21 at 11:40 -0700, Josh Triplett wrote:
> It no longer triggers that tag as of lintian 2.5.104, which allows
> metapackages to depend on toolchain packages.

Right, sorry, I missed that the stretch-backports package is lagging a
little.

However, running from a current lintian git checkout gives:

adam@jacala:~/code/debian/lintian$ ./frontend/lintian -I -E --pedantic 
--show-overrides ../../josh-meta/target/josh-dev_77_all.deb 
P: josh-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
I: josh-dev: unused-override binary-package-depends-on-toolchain-package

which looks like exactly what was expected?

Regards,

Adam

Bug#909328: gnome-terminal: Crashes when using 'set lines=999' in Vim editor

[Jeremy Bicha]

On Fri, Sep 21, 2018 at 2:18 PM Leon van Velzen
 wrote:
> Used common option 'set lines=999' and 'set columns=999' in the Vim editor as 
> a
> trick to make the terminal full screen. This worked in other terminals but I
> noticed it made all instances of gnome terminal crash.

In GNOME Terminal > Preferences, you can set the initial terminal size.

Thanks,
Jeremy Bicha

Bug#909319: Show unnecessary overrides

[Josh Triplett]

On Fri, Sep 21, 2018 at 07:38:32PM +0100, Adam D. Barratt wrote:
> On Fri, 2018-09-21 at 10:34 -0700, Josh Triplett wrote:
> > Control: retitle -1 Doesn't show unused override
> > 
> > On Fri, Sep 21, 2018 at 06:41:14PM +0200, Mattia Rizzolo wrote:
> [...]
> > > Check out https://lintian.debian.org/tags/unused-override.html
> > 
> > Interesting. I filed this because I observed lintian not raising this
> > when I expected it to.
> > 
> > For a test case, git clone https://joshtriplett.org/git/josh-meta and
> > run ./build in that directory. Note that the josh-dev package has a
> > now-unnecessary lintian override, which should trigger unused-
> > override.
> 
> How is it unused / unnecessary?
> 
> 
> Package: josh-dev
> Architecture: all
> Depends:
>  autoconf,
>  automake,
>  build-essential,
>  ccache,
>  colordiff,
>  debhelper,
> 
> 
> and the use of debhelper triggers binary-package-depends-on-toolchain-
> package, which is the only tag that josh-dev overrides.

It no longer triggers that tag as of lintian 2.5.104, which allows
metapackages to depend on toolchain packages.

Bug#909319: Show unnecessary overrides

[Adam D. Barratt]

On Fri, 2018-09-21 at 10:34 -0700, Josh Triplett wrote:
> Control: retitle -1 Doesn't show unused override
> 
> On Fri, Sep 21, 2018 at 06:41:14PM +0200, Mattia Rizzolo wrote:
[...]
> > Check out https://lintian.debian.org/tags/unused-override.html
> 
> Interesting. I filed this because I observed lintian not raising this
> when I expected it to.
> 
> For a test case, git clone https://joshtriplett.org/git/josh-meta and
> run ./build in that directory. Note that the josh-dev package has a
> now-unnecessary lintian override, which should trigger unused-
> override.

How is it unused / unnecessary?


Package: josh-dev
Architecture: all
Depends:
 autoconf,
 automake,
 build-essential,
 ccache,
 colordiff,
 debhelper,


and the use of debhelper triggers binary-package-depends-on-toolchain-
package, which is the only tag that josh-dev overrides.

adam@jacala:~/code/debian/lintian$ cat data/fields/toolchain 
cdbs
debhelper

Regards,

Adam

Bug#908925: s-nail: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Hello Paride,
On Tue, Sep 18, 2018 at 12:07:11AM +0200, Paride Legovini wrote:
> On Sun, 16 Sep 2018 Helge Kreutzmann  wrote:
> > Please find the initial German debconf translation for s-nail
> > attached.
> > 
> > Please place this file in debian/po/ as de.po for your next upload.
> > 
> > If you update your template, please use 
> > 'msgfmt --statistics '
> > to check the po-files for fuzzy or untranslated strings.
> > 
> > If there are such strings, please contact me so I can update the 
> > German translation.
> 
> Dear Helge,
> 
> There is a newer version of the debconf strings:
> 
> https://salsa.debian.org/debian/s-nail/tree/master/debian/po
> 
> The change reflects the deprecation of a s-nail option. This version
> simpler and more general, thus less likely to vary in the future. Could
> you please update your translation?

Please finde the update translation attached. You might consier using
podebconf-report-po(1) to collect and upate your debconf template,
especially if you have this not yet published version.

Greetings

  Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
# Translation of s-nail debconf templates to German
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the s-nail package.
#
# Helge Kreutzmann , 2018.
msgid ""
msgstr ""
"Project-Id-Version: s-nail\n"
"Report-Msgid-Bugs-To: s-n...@packages.debian.org\n"
"POT-Creation-Date: 2018-09-17 19:46+0200\n"
"PO-Revision-Date: 2018-09-21 20:29+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: german \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../s-nail.templates:1001
msgid "Should the dotlock helper be installed ‘setgid mail’?"
msgstr "Soll das Dotlock-Hilfsprogramm »setgid mail« installliert werden?"

#. Type: boolean
#. Description
#: ../s-nail.templates:1001
msgid ""
"S-nail protects mbox files via fcntl(2) file-region locks during file "
"operations in order to avoid inconsistencies due to concurrent "
"modifications. By default system mbox files are also locked using "
"traditional dotlock files."
msgstr ""
"S-nail schützt Mbox-Dateien während Dateiaktionen mittels fcntl(2)-"
"Dateibereichssperren, um Inkonsistenzen aufgrund von parallelen Änderungen "
"zu vermeiden. Standardmäßig werden Mbox-Dateien auch mittels traditionellen "
"Sperrdateien gesperrt."

#. Type: boolean
#. Description
#: ../s-nail.templates:1001
msgid ""
"On Debian system users normally lack the permissions to create files in the "
"directory containing the system mailboxes (/var/mail/). In this case a "
"dedicated privileged (setgid mail) dotlock helper is needed, however this "
"may be a security concern."
msgstr ""
"Auf Debian-Systemen fehlen den Benutzern die Rechte, Dateien in dem "
"Verzeichnis, das die System-Mailboxen enthält ((/var/mail/), zu erstellen. "
"In diesem Fall wird ein dedizierte, privilegierte (Setgid Mail) Dotlock-"
"Hilfsprogramm benötigt, was allerdings Sicherheitsbedenken hervorrufen "
"könnte."


signature.asc
Description: Digital signature

Bug#909330: newmat packages are completely broken

[Adrian Bunk]

Source: newmat
Version: 1.10.4-7
Severity: serious
Control: affects -1 libnewmat10ldbl libnewmat10-dev src:sofa-framework

Please do a debdiff of all binaries when doing non-trivial
changes to debian/rules or bumping the debhelper compat.

Contents lost in libnewmat10ldbl:
-rw-r--r--  root/root   /usr/lib/libnewmat.so.10.0.0
-rw-r--r--  root/root   /usr/share/doc/libnewmat10ldbl/changelog.gz
-rw-r--r--  root/root   DEBIAN/shlibs
-rw-r--r--  root/root   DEBIAN/triggers
lrwxrwxrwx  root/root   /usr/lib/libnewmat.so.10 -> libnewmat.so.10.0.0

Contents lost in libnewmat10-dev:
-rw-r--r--  root/root   /usr/include/newmat/boolean.h
-rw-r--r--  root/root   /usr/include/newmat/config.h
-rw-r--r--  root/root   /usr/include/newmat/controlw.h
-rw-r--r--  root/root   /usr/include/newmat/include.h
-rw-r--r--  root/root   /usr/include/newmat/myexcept.h
-rw-r--r--  root/root   /usr/include/newmat/newmat.h
-rw-r--r--  root/root   /usr/include/newmat/newmatap.h
-rw-r--r--  root/root   /usr/include/newmat/newmatio.h
-rw-r--r--  root/root   /usr/include/newmat/newmatnl.h
-rw-r--r--  root/root   /usr/include/newmat/newmatrc.h
-rw-r--r--  root/root   /usr/include/newmat/newmatrm.h
-rw-r--r--  root/root   /usr/include/newmat/precisio.h
-rw-r--r--  root/root   /usr/include/newmat/solution.h
-rw-r--r--  root/root   /usr/lib/libnewmat.a
-rw-r--r--  root/root   /usr/lib/libnewmat.la
-rw-r--r--  root/root   /usr/share/doc/libnewmat10-dev/changelog.gz

Bug#909331: proftpd-basic: The '%u' variable is not fully interpreted for SFTPAuthorizedUserKeys parameter

[Nicolas Couturier]

Package: proftpd-basic
Version: 1.3.5b-4
Severity: normal



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

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

Versions of packages proftpd-basic depends on:
ii  adduser3.115
ii  debianutils4.8.1.1
ii  libacl12.2.52-3+b1
ii  libc6  2.24-11+deb9u3
ii  libcap21:2.25-1
ii  libmemcached11 1.0.18-4.1
ii  libmemcachedutil2  1.0.18-4.1
ii  libncurses56.0+20161126-1+deb9u2
ii  libpam-runtime 1.1.8-3.6
ii  libpam0g   1.1.8-3.6
ii  libpcre3   2:8.39-3
ii  libssl1.0.21.0.2l-2+deb9u3
ii  libtinfo5  6.0+20161126-1+deb9u2
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125
ii  netbase5.4
ii  sed4.4-1
ii  ucf3.0036
ii  zlib1g 1:1.2.8.dfsg-5

proftpd-basic recommends no packages.

Versions of packages proftpd-basic suggests:
pn  openbsd-inetd | inet-superserver  
ii  openssl   1.1.0f-3+deb9u2
ii  proftpd-doc   1.3.5b-4
pn  proftpd-mod-geoip 
pn  proftpd-mod-ldap  
ii  proftpd-mod-mysql 1.3.5b-4
pn  proftpd-mod-odbc  
pn  proftpd-mod-pgsql 
pn  proftpd-mod-sqlite

-- Configuration Files:
/etc/logrotate.d/proftpd-basic changed [not included]

-- debconf information:
* shared/proftpd/inetd_or_standalone: standalone

I tried to set up publickey authentification with proftpd.
I added the public key location in my Virtualhost :
SFTPAuthorizedUserKeys file:/etc/proftpd/authorized_keys/%u

When I tried to connect I had this error :
Permission denied (publickey).
Couldn't read packet: Connection reset by peer

I had this error in SFTP log :
2018-09-21 17:44:14,273 mod_sftp/0.9.9[19024]: sending userauth failure;
remaining userauth methods: publickey,password

I activated Trace logs
Here is the error :
2018-09-21 17:44:11,980 [19024] : using SFTPAuthorizedUserKeys
'/etc/proftpd/authorized_keys/imps' for public key authentication for
user 'imps'
2018-09-21 17:44:11,980 [19024] : error opening
SFTPAuthorizedUserKeys 'file:/etc/proftpd/authorized_keys/%u': No such
file or directory

The %u variable is interpreted for finding the name of the key file but not for
opening it.

I changed the location of the public key file for that :
SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys

After moving the user public key in his folder .sftp, authentification
worked.

Could please have a look on this issue ?
I prefered to put user key outside home directory.

Regards.

Bug#898945: Can Ubuntu 16.04 be patched to fix this?

[Ben Hutchings]

On Fri, 2018-09-21 at 12:03 -0500, Ryan Arp wrote:
> Is it possible to get this patched for Ubuntu 16.04? 

You need to ask Ubuntu about that.  Fixes in Debian will generally find
their way into future Ubuntu releases, but updates to existing releases
are entirely a matter for them.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.




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

Bug#909329: libnitrokey: Please backport version 3.3 for Stretch

[Jan Luca Naumann]

Source: libnitrokey
Severity: wishlist

Please backport libnitrokey version 3.3 for Stretch. This allows to backport
nitrokey-app 1.3.1 for Stretch as well.

Thank you in advance

Bug#907988: rubber must specify the encoding when opening files

[Hilmar Preuße]

On 09.09.2018 15:33, Adrian Bunk wrote:

Hi Adrian,

Did you find the time to answer my question and re-test? Thanks!

> I can confirm that it fixes the why3 build.
> 
> Your solution is a bit ouch, but I understand why it is not easy to 
> fix in a better way.
> 
Upstream decided to solve the problem a different way and has released
version 1.5.1. New package is on [1], could you retest?

Thanks!

Hilmar

[1] https://freeshell.de/~hille42/rubber/
-- 
sigfault
#206401 http://counter.li.org

Bug#909328: gnome-terminal: Crashes when using 'set lines=999' in Vim editor

[Leon van Velzen]

Package: gnome-terminal
Version: 3.30.0-1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

Used common option 'set lines=999' and 'set columns=999' in the Vim editor as a
trick to make the terminal full screen. This worked in other terminals but I
noticed it made all instances of gnome terminal crash.

   * What was the outcome of this action?

A crash of all terminal instances, not just the one running Vim.

   * What outcome did you expect instead?

That the terminals stayed alive, Vim kept running and the terminal would resize
to the full size of the screen.



Thanks for all the software, it's a joy to use Gnome.



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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.0-1
ii  gnome-terminal-data   3.30.0-1
ii  gsettings-desktop-schemas 3.28.0-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libdconf1 0.30.0-1
ii  libglib2.0-0  2.58.0-4
ii  libgtk-3-03.24.0-3
ii  libpango-1.0-01.42.4-3
ii  libuuid1  2.32.1-0.1
ii  libvte-2.91-0 0.54.0-1
ii  libx11-6  2:1.6.6-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.38.0-2
ii  nautilus-extension-gnome-terminal  3.30.0-1
ii  yelp   3.30.0-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#909327: unattended-upgrades FTBFS: test failures

[Adrian Bunk]

Source: unattended-upgrades
Version: 1.5
Severity: serious
Tags: ftbfs

Some recent change in unstable makes unattended-upgrades FTBFS:

https://tests.reproducible-builds.org/debian/history/unattended-upgrades.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/unattended-upgrades.html

...
==
FAIL: test_remove_unused_dependencies (__main__.TestRemoveUnused)
--
Traceback (most recent call last):
  File "./test_remove_unused.py", line 111, in test_remove_unused_dependencies
"Can not find '%s' in '%s'" % (needle, haystack))
AssertionError: False is not true : Can not find 'Packages that were 
successfully auto-removed: old-unused-dependency test-package-dependency' in 
'2018-09-20 20:38:43,234 INFO Initial blacklisted packages: 
2018-09-20 20:38:43,235 INFO Initial whitelisted packages: 
2018-09-20 20:38:43,235 INFO Starting unattended upgrades script
2018-09-20 20:38:43,236 INFO Allowed origins are: o=Ubuntu,a=lucid-security
2018-09-20 20:38:43,464 DEBUG APT::VersionedKernelPackages is not set
2018-09-20 20:38:43,466 DEBUG Checking: test-package ([])
2018-09-20 20:38:43,470 DEBUG pkgs that look like they should be upgraded: 
test-package
2018-09-20 20:38:43,478 DEBUG fetch.run() result: 0
2018-09-20 20:38:43,479 DEBUG http://archive.ubuntu.com/ubuntu/test-package_2.0_all.deb' ID:0 
ErrorText: ''>
2018-09-20 20:38:43,480 DEBUG 
check_conffile_prompt(/build/1st/unattended-upgrades-1.5/test/root.unused-deps/var/cache/apt/archives/test-package_2.0_all.deb)
2018-09-20 20:38:43,481 DEBUG found pkg: test-package
2018-09-20 20:38:43,481 DEBUG blacklist: []
2018-09-20 20:38:43,481 DEBUG whitelist: []
2018-09-20 20:38:43,481 INFO Packages that will be upgraded: test-package
2018-09-20 20:38:43,482 INFO Writing dpkg log to 
./root.unused-deps/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2018-09-20 20:38:43,490 DEBUG applying set ['test-package']
2018-09-20 20:38:43,951 DEBUG left to upgrade set()
2018-09-20 20:38:43,951 INFO All upgrades installed
2018-09-20 20:38:43,960 DEBUG InstCount=1 DelCount=0 BrokenCount=0
2018-09-20 20:38:43,968 DEBUG Extracting content from 
./root.unused-deps/var/log/unattended-upgrades/unattended-upgrades-dpkg.log 
since 2018-09-20 20:38:43
'

==
FAIL: test_remove_unused_dependencies_new_unused_only 
(__main__.TestRemoveUnused)
--
Traceback (most recent call last):
  File "./test_remove_unused.py", line 138, in 
test_remove_unused_dependencies_new_unused_only
"Can not find '%s' in '%s'" % (needle, haystack))
AssertionError: False is not true : Can not find 'Packages that were 
successfully auto-removed: test-package-dependency' in '2018-09-20 20:38:43,984 
INFO Initial blacklisted packages: 
2018-09-20 20:38:43,985 INFO Initial whitelisted packages: 
2018-09-20 20:38:43,985 INFO Starting unattended upgrades script
2018-09-20 20:38:43,985 INFO Allowed origins are: o=Ubuntu,a=lucid-security
2018-09-20 20:38:44,278 DEBUG Using (^linux-image|^.*-modules|^linux-headers) 
regexp to find kernel packages
2018-09-20 20:38:44,284 DEBUG Using 
(^linux-image.*4.9.0-8-amd64|4.9.0-8-amd64.*-modules|^linux-headers.*4.9.0-8-amd64)
 regexp to find running kernel packages
2018-09-20 20:38:44,286 DEBUG Checking: test-package ([])
2018-09-20 20:38:44,288 DEBUG pkgs that look like they should be upgraded: 
test-package
2018-09-20 20:38:44,298 DEBUG fetch.run() result: 0
2018-09-20 20:38:44,299 DEBUG http://archive.ubuntu.com/ubuntu/test-package_2.0_all.deb' ID:0 
ErrorText: ''>
2018-09-20 20:38:44,299 DEBUG 
check_conffile_prompt(/build/1st/unattended-upgrades-1.5/test/root.unused-deps/var/cache/apt/archives/test-package_2.0_all.deb)
2018-09-20 20:38:44,299 DEBUG found pkg: test-package
2018-09-20 20:38:44,300 DEBUG blacklist: []
2018-09-20 20:38:44,300 DEBUG whitelist: []
2018-09-20 20:38:44,301 INFO Packages that will be upgraded: test-package
2018-09-20 20:38:44,301 INFO Writing dpkg log to 
./root.unused-deps/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2018-09-20 20:38:44,312 DEBUG applying set ['test-package']
2018-09-20 20:38:44,318 DEBUG InstCount=1 DelCount=0 BrokenCount=0
2018-09-20 20:38:44,318 DEBUG InstCount=1 DelCount=0 BrokenCount=0
2018-09-20 20:38:44,322 DEBUG Extracting content from 
./root.unused-deps/var/log/unattended-upgrades/unattended-upgrades-dpkg.log 
since 2018-09-20 20:38:43
2018-09-20 20:38:44,322 DEBUG Extracting content from 
./root.unused-deps/var/log/unattended-upgrades/unattended-upgrades-dpkg.log 
since 2018-09-20 20:38:43
'

--
Ran 2 tests in 1.110s

FAILED (failures=2)
/build/1st/unattended-upgrades-1.5/test/unattended_upgrade.py:1158: 
ResourceWarning: unclosed file <_io.TextIOWrapper 

Bug#909326: RFS: easyspice/0.6.8-3

[Gudjon I. Gudjonsson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "easyspice"

 * Package name: easyspice
Version : 0.6.8-3
Upstream Author : Werner Hoch  
 * URL   : http://easy-spice.sourceforge.net
 * License : GPLv2
   Section  : electronics

It builds those binary packages:
easyspice  - Graphical frontend to the Spice simulator

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/easyspice

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/contrib/e/easyspice/easyspice_0.6.8-3.dsc

Changes since the last upload:

  * Bump standards version to 4.2.1.
  * Bump compat to 11
  * Remove dependency on autotools-dev
  * Add dependency on sensible-utils
  * Add patch 02_spelling
  * Add header to patch 01_docurl
  * Fix description
  * Add required targets to rules
  * Fix build flags
  * Change watch file from http to https


Regards,
Gudjon I. Gudjonsson

Bug#898945: Can Ubuntu 16.04 be patched to fix this?

[Ryan Arp]

Is it possible to get this patched for Ubuntu 16.04? 

Bug#909325: ROM; thunderbird [mips mipsel] -- NBS; requires rustc and cargo

[Carsten Schoenert]

Package: ftp.debian.org
Severity: normal

Hi FTP team,

starting with version 60.0 in unstable the source package of thunderbird
can't be built on the architectures mips and mipsel due the build
requirement of rustc and cargo. Please remove the old binaries of
thunderbird for mips and mispel. Also the thunderbird-dev package is now
gone. It's quite the same situation like for firefox-esr in #908579 [1].

Please remove all remaining cruft so thunderbird can go into testing.

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

Regards and thanks!
Carsten

Bug#909319: Show unnecessary overrides

[Josh Triplett]

Control: retitle -1 Doesn't show unused override

On Fri, Sep 21, 2018 at 06:41:14PM +0200, Mattia Rizzolo wrote:
> On Fri, Sep 21, 2018 at 09:12:40AM -0700, Josh Triplett wrote:
> > Sometimes an override becomes unnecessary, either because the package
> > changed to not need it or lintian changed to become more discerning and
> > no longer flags the package. Either way, at that point the override
> > becomes unnecessary. Lintian should show the unnecessary override to
> > call attention to it, so that the maintainer can remove it.
> 
> It already does it?
> 
> Check out https://lintian.debian.org/tags/unused-override.html

Interesting. I filed this because I observed lintian not raising this
when I expected it to.

For a test case, git clone https://joshtriplett.org/git/josh-meta and
run ./build in that directory. Note that the josh-dev package has a
now-unnecessary lintian override, which should trigger unused-override.

Bug#860064: 860064 fixed in 2.72-3+deb8u3

[Santiago Ruano Rincón]

Control: fixed -1 2.72-3+deb8u3

The bug doesn't occur in stretch. I think it can be tagged as notfound.


signature.asc
Description: PGP signature

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

On Sat, 2018-09-22 at 00:13:47 +0800, Yangfl wrote:
> Guillem Jover  于2018年9月21日周五 上午7:42写道：
> > Something like the attached patch would do I guess? I'm not sure if
> > I'd want to expose those unconditionally, as that might pollute the
> > namespace.
> 
> Please find the attached md5main-md.c, taken from libmd5-rfc but
> modified to be compiled with -lmd. Notice the segfault here. Clearly
> MD5End supplies the hash in ASCII hex string, but md5_finish in raw
> char array. That's not the same.

Ah indeed sorry, I used initially MD5Final() which is the correct one
here, but switched to MD5End() because it was failing the libmd test
suite.

Patch updated, I'll fix the test suite later today.

Thanks,
Guillem
diff --git i/include/md5.h w/include/md5.h
index dee2bf4..2f8b167 100644
--- i/include/md5.h
+++ w/include/md5.h
@@ -47,4 +47,17 @@ char	*MD5Data(const uint8_t *, size_t, char *);
 }
 #endif
 
+/*
+ * Interface compatibility with Aladdin Enterprises independent
+ * implemntation from RFC 1321.
+ */
+
+typedef uint8_t md5_byte_t;
+typedef uint32_t md5_word_t;
+typedef MD5_CTX md5_state_t;
+
+#define md5_init(pms) MD5Init(pms)
+#define md5_append(pms, data, nbytes) MD5Update(pms, data, nbytes)
+#define md5_finish(pms, digest) MD5Final(digest, pms)
+
 #endif /* _MD5_H_ */

Bug#909324: geeqie: please document locations of config and state files in the man page

[Marvin Renich]

Package: geeqie
Version: 1:1.4+git20180820-1
Severity: minor

Please document in the man page the locations of the config files (e.g.
/etc/geeqie/geeqierc.xml and ~/.config/geeqie/geeqierc.xml) and state
files (e.g. ~/.local/share/geeqie/*) in a FILES section (man ssh is a
good example).

This is an offshoot of old bug 762231 where a deprecation warning did
not give any indication of how to resolve the warning.  But knowing
where state files are stored and how they are used will help users to be
able to clean up cruft on their system.

Thanks...Marvin

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

Kernel: Linux 4.18.0-1-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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4+git20180820-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libexiv2-14  0.25-4
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-6
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.58.0-4
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblirc-client0  0.10.0-2+b1
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpangoft2-1.0-01.42.4-3
ii  libstdc++6   8.2.0-6
ii  libtiff5 4.0.9-6
ii  sensible-utils   0.0.12

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.8-5
ii  exiftran 2.10-2+b3
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.8+dfsg-1
ii  librsvg2-common  2.40.20-3
ii  ufraw-batch  0.22-3
ii  zenity   3.28.1-1

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.10.6-3
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#909323: zathura: Blocks in full width mode.

[Jacek Sobczak]

Package: zathura
Version: 0.4.1-1
Severity: normal

Dear Maintainer,

Zathura blocks in full width mode (s key) in various situations. To
reproduce switch between full width and full height mode several times
(s-a-s-a...). Occurs also whew switched to full width then page is
changed and you try to switch back to full height. When blocked zooming
(+/-) doesn't work either.

Jacek

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pl_PL.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 zathura depends on:
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libgirara-gtk3-3 0.3.1-1
ii  libglib2.0-0 2.58.0-4
ii  libgtk-3-0   3.24.0-3
ii  libmagic11:5.34-2
ii  libpango-1.0-0   1.42.4-3
ii  libsqlite3-0 3.25.0-1
ii  libsynctex2  2018.20180907.48586-2
ii  zathura-pdf-poppler  0.2.9-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  chromium [www-browser]  69.0.3497.92-1
ii  w3m [www-browser]   0.5.3-36+b1
pn  zathura-cb  
pn  zathura-djvu
pn  zathura-ps  

-- no debconf information

Bug#762231: warning on startup: Option image.dither_quality ignored

[Marvin Renich]

* Andreas Ronnquist  [180916 10:41]:
> Hi - replying to a really old bug here -
> 
> Do you have a /etc/geeqie folder and a /etc/geeqie/geeqierc.xml file?
> 
> If not, check in $HOME/.config/geeqie/geeqierc.xml - 
> 
> If you have a line containing your mentioned option
> (image.dither_quality) in either of these files, simply remove it from either
> file.
> 
> (If I add it on an up to date geeqie 1.4+git20180820, I do get the
> warning you are mentioning, but it then removes the option, and I don't
> get the warning on subsequent startups of geeqie).
> 
> So, it should be safe to simply remove the option. - I intend to close
> this bug.

SGTM.  I don't know how long it has been since I last saw the warning,
but it has been quite a while (and I do not now have that option in
either config file).

I'm going to open a new bug asking for the locations of the config files
to be documented in the man page.  If it had been documented when I
first encountered this, I would not have considered the warning a bug
(or if the warning msg pointed to the offending config file).

...Marvin

Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[felipe]

Tested again with experimental kernel 4.19-rc4 and the result is the same (not 
able to find firmware) as with 4.19-rc3
and 4.19-rc2.

Tried reinstalling the firmware-amd-graphics and firmware-linux packages.

Booting with kernel parameters 'radeon.si_support=0 amdgpu.si_support=1' and 
kernel 4.19.rc-4 the system bails and
cannot find the required firmware which is located at '/lib/firmware/radeon'.

If I copy the contents of '/lib/firmware/radeon' to '/lib/firmware/amdgpu' and 
restart, the system boots, loads the
firmware and works.

Since previous kernels (4.17, 4.18) the system had no problem finding the 
correct firmware inside '/lib/firmware/radeon'
when using amdgpu driver.




On 9/13/18 1:44 PM, felipe wrote:
> Today I had some spare time and I did some tests.
> 
> On kernel 4.17 and 4.18 I can switch from radeonsi to amdgpu using/removing 
> 'radeon.si_support=0 amdgpu.si_support=1'
> and the system finds and loads the relevant firmware in /lib/firmware/radeon, 
> giving this system a boost in performance,
> correct HDMI output and no crashes.
> 
> Booting kernel 4.19, the system could not load the relevant firmware when I 
> tried to use amdgpu, but booted using radeonsi.
> 
> Today I did copy all the firmware in '/lib/firmware/radeon' to 
> '/lib/firmware/amdgpu' and the system booted in a working
> state and has been stable for the last hour.
> 
> Since it is possible to use amdgpu with older GCN cards, the kernel should 
> also look for the firmware inside
> '/lib/firmware/radeon' when using 'amdgpu' driver.
> 
> 
> '$ cat /var/log/syslog' of this working session with kernel 4.19-rc3 and 'cp 
> /lib/firmware/radeon/* /lib/firmware/amdgpu'

Bug#893647: time to go

[Adam Borowski]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: severity -2 normal
Control: retitle -2 RM: kterm -- RoQA, obsolete, alternatives exist, dead 
upstream

> I believe that kterm is no longer suitable for inclusion in Debian, and thus
> propose its removal.  It lacks features considered basic for a terminal
> emulator, such as UTF-8 support; its compatibility with terminal abilities
> taken for granted these days is poor, and it has been dead upstream since
> times immemorial (predating the first Debian version in 1996).

Reassigning for RM -- goodbye kterm!

-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

[Emmanuel Promayon]

Dear Bernhard,

Thank you for your investigation and your time. You are right about 
these double delete and this will have to be fixed.


But I am still puzzled:
1) your patch is absolutely required for handling delete properly (btw 
thanks for the corresponding references!) but unfortunately it can fix 
only some of the tests
2) this bug only appeared recently, no segfault were detected before on 
sid (first trace I found of a failure is in our weekly packaging test 
last Sunday 15 September, everything was fine on Sunday 9 September)

3) the segfaults are generated during testing

This probably means that the problem comes from a deeper (darker, harder 
to find) side of the build.


So I started with the first test on the list that generates a segfaults 
(test #27 named action-editframes-level1-1) and run it through the 
debugger (I run it through the same xvfb-run command line as in the 
debian/control file).


Here is the first outcome:

xvfb-run --auto-servernum --server-args="-screen 0 1024x768x24" 
/usr/bin/gdb 
/root/packaging/camitk-debian-ci/camitk-build/bin/camitk-testactions

GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/root/packaging/camitk-debian-ci/camitk-build/bin/camitk-testactions...done.
(gdb) r "-i" 
"/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha" 
"-a" 
"/root/packaging/camitk-debian-ci/camitk-build/lib/camitk-4.2/actions/libeditframes.so"
Starting program: 
/root/packaging/camitk-debian-ci/camitk-build/bin/camitk-testactions 
"-i" 
"/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha" 
"-a" 
"/root/packaging/camitk-debian-ci/camitk-build/lib/camitk-4.2/actions/libeditframes.so"

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
camitk-testactions run with arguments:
- action library file: 
"/root/packaging/camitk-debian-ci/camitk-build/lib/camitk-4.2/actions/libeditframes.so"
- input test file: 
"/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha"

Working directory: /root/packaging/camitk-debian-ci/camitk-build
Starting the camitk default application...
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[New Thread 0x7fffec879700 (LWP 8505)]
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[New Thread 0x7fffe7f46700 (LWP 8507)]
[OK]
Opening component: 
/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha...

[New Thread 0x7fffda562700 (LWP 8514)]
[New Thread 0x7fffd9d61700 (LWP 8515)]
[New Thread 0x7fffd9560700 (LWP 8516)]
[Thread 0x7fffda562700 (LWP 8514) exited]
[New Thread 0x7fffd8d5f700 (LWP 8517)]
[Thread 0x7fffd9d61700 (LWP 8515) exited]
[New Thread 0x7fffd3fff700 (LWP 8518)]
[New Thread 0x7fffd37fe700 (LWP 8519)]
[New Thread 0x7fffd2ffd700 (LWP 8520)]
[Thread 0x7fffd9560700 (LWP 8516) exited]
[Thread 0x7fffd8d5f700 (LWP 8517) exited]
[Thread 0x7fffd3fff700 (LWP 8518) exited]
[Thread 0x7fffd2ffd700 (LWP 8520) exited]
[Thread 0x7fffd37fe700 (LWP 8519) exited]
[New Thread 0x7fffd2ffd700 (LWP 8521)]
[New Thread 0x7fffd37fe700 (LWP 8522)]
[New Thread 0x7fffd3fff700 (LWP 8523)]
[New Thread 0x7fffd8d5f700 (LWP 8524)]
[New Thread 0x7fffd25c4700 (LWP 8525)]
[New Thread 0x7fffd1dc3700 (LWP 8526)]
[New Thread 0x7fffd15c2700 (LWP 8527)]
[New Thread 0x7fffd0dc1700 (LWP 8528)]

Thread 1 "camitk-testacti" received signal SIGSEGV, Segmentation fault.
0x75718f15 in vtkTextProperty::ShallowCopy(vtkTextProperty*) () 
from /lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3

(gdb) where
#0  0x75718f15 in vtkTextProperty::ShallowCopy(vtkTextProperty*) 
() from /lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3
#1  0x77f457d7 in 
camitk::RendererWidget::RendererWidget(QWidget*, 
camitk::RendererWidget::ControlMode) () at 
/usr/include/vtk-6.3/vtkSmartPointer.h:77
#2  0x77f31d42 in 
camitk::InteractiveViewer::InteractiveViewer(QString&, 
camitk::InteractiveViewer::ViewerType) ()

    at ./sdk/libraries/core/viewer/InteractiveViewer.cpp:192
#3  0x77f33533 in 
camitk::InteractiveViewer::getNewViewer(QString, 
camitk::InteractiveViewer::ViewerType) ()

    at ./sdk/libraries/core/viewer/InteractiveViewer.cpp:90
#4  

Bug#909305: RFS: android-platform-system-core/1:8.1.0+r23-1~stage1.1

[Roger Shimizu]

On Fri, Sep 21, 2018 at 7:58 PM, 殷啟聰 | Kai-Chung Yan
 wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "android-platform-system-core"
>
> * Package name: android-platform-system-core
>   Version : 1:8.1.0+r23-1~stage1.1

Good to see this package!

I just quickly checked the version on salsa, and find d/changelog is
not uploaded yet.

$ git diff --name-status 8b1e66f8 42202fb6 debian/
Mdebian/append2simg.mk
Mdebian/control
Mdebian/libadb.mk
Mdebian/libcrypto_utils.mk
Mdebian/rules
Mdebian/simg2img.mk
Mdebian/simg2simg.mk

So could you change the version to 1:8.1.0+r23-1~stage2 ?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#909319: Show unnecessary overrides

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Fri, Sep 21, 2018 at 09:12:40AM -0700, Josh Triplett wrote:
> Sometimes an override becomes unnecessary, either because the package
> changed to not need it or lintian changed to become more discerning and
> no longer flags the package. Either way, at that point the override
> becomes unnecessary. Lintian should show the unnecessary override to
> call attention to it, so that the maintainer can remove it.

It already does it?

Check out https://lintian.debian.org/tags/unused-override.html

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

Bug#905783: dunno if I should add this to the current bug or make a new bug -

[shirish शिरीष]

Reply in-line :-

On 21/09/2018, James Lu  wrote:
> Hi Shirish,
>
> Re title: Filing new bugs for each distinct problem / error is easiest
> to manage on any BTS :)
>
> Also, was the original autostart issue fixed? Everything else previously
> mentioned here should be fixed as of 0.7.0.

yup, after for some reason the mate autostart application had mangled
the variety binary name and path which I fixed, think had shared above.

> On 2018-09-21 01:55 AM, shirish शिरीष wrote:
>> Dear James,
>>
>> After today's update, I took the plunge and removed -
>>
>> ~/.config$ rm -rf variety
>>
>> $ variety
>> ERROR: 2018-09-21 14:10:30,552: _generate_pencil_tile() 'Could not
>> generate pencil_tile.png'
>> Traceback (most recent call last):
>>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
>> 302, in _generate_pencil_tile
>> "-motion-blur 0x20+135 -charcoal 2 -resize 50%% %s" %
>> pipes.quote(pencil_tile_filename.encode('utf8')))
>>   File "/usr/lib/python3.6/shlex.py", line 314, in quote
>> if _find_unsafe(s) is None:
>> TypeError: cannot use a string pattern on a bytes-like object
>
> Fixed in
> https://github.com/varietywalls/variety/commit/a6eaec2e5f5ef3836919d4ce70303cf94899f83c
> for next release
>

nice.

>> WARNING: 2018-09-21 14:10:30,653: load_history() 'Could not load
>> history file, continuing without it, no worries'
>> WARNING: 2018-09-21 14:10:30,846: create_menu() 'Variety Slideshow is
>> not installed. This is an optional extension adding pan-and-zoom
>> slideshows to Variety: see
>> https://github.com/peterlevi/variety-slideshow for details'
>>
>> (variety:1800): Gdk-CRITICAL **: 14:10:30.994:
>> gdk_window_thaw_toplevel_updates: assertion
>> 'window->update_and_descendants_freeze_count > 0' failed
>> ERROR: 2018-09-21 14:10:31,145: image_ok() 'Error in image_ok for file
>> /usr/share/backgrounds/bluebird.svg'
>> Traceback (most recent call last):
>>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
>> 1478, in image_ok
>> i = PILImage.open(img)
>>   File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2622, in open
>> % (filename if filename else fp))
>> OSError: cannot identify image file '/usr/share/backgrounds/bluebird.svg'
>> ERROR: 2018-09-21 14:10:31,319: image_ok() 'Error in image_ok for file
>> /usr/share/backgrounds/greybird.svg'
>> Traceback (most recent call last):
>>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
>> 1478, in image_ok
>> i = PILImage.open(img)
>>   File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2622, in open
>> % (filename if filename else fp))
>> OSError: cannot identify image file '/usr/share/backgrounds/greybird.svg'
>> ERROR: 2018-09-21 14:10:31,605: image_ok() 'Error in image_ok for file
>> /usr/share/backgrounds/albatross-wall-source.svg'
>> Traceback (most recent call last):
>>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
>> 1478, in image_ok
>> i = PILImage.open(img)
>>   File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2622, in open
>> % (filename if filename else fp))
>> OSError: cannot identify image file
>> '/areusr/sh/backgrounds/albatross-wall-source.svg'
>>
>> Looks like variety doesn't understand svg files :(
>
> This might be a worthwhile feature request, though I have no idea how
> common desktop environment support for SVG backgrounds is.
>

same here, although it would depend upon how fattening  the support would be.

The three files it shares are from greybird-gtk-theme ,
albatross-gtk-theme and bluebird-gtk-theme.


I did see that there are quite a few gtk-theme in the debian archive
(on testing) but not too many -

$ aptitude search gtk-theme
i A albatross-gtk-theme  - dark and
light GTK+ theme from the Shimmer Project
i A blackbird-gtk-theme  - dark GTK+
theme from the Shimmer Project
i A bluebird-gtk-theme   - blue GTK+
theme from the Shimmer Project
p   breeze-gtk-theme - GTK theme
built to match KDE's Breeze
p   breeze-gtk-theme-dbgsym  - debug
symbols for breeze-gtk-theme
p   darkcold-gtk-theme   - dark
GTK2/GTK3/Metacity theme
p   darkmint-gtk-theme   - dark
GTK2/GTK3/Metacity theme
i A greybird-gtk-theme   - grey GTK+
theme from the Shimmer Project
p   gtk-theme-switch - GTK+ theme
switching utility
p   gtk-theme-switch-dbgsym  - Debug
symbols for gtk-theme-switch
p   materia-gtk-theme- Material
Design theme for GNOME/GTK+ based desktop environments
p   numix-gtk-theme  - modern flat
theme from the Numix project

5 of the packages shared above have .svg files.  So it's really upto you.

>> Seems the scripts are 

Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)

[Ilias Tsitsimpis]

Hi Sergio,

On Sat, Sep 15, 2018 at 11:28AM, Sergio Mendoza wrote:
> Hi again,
> 
>   Today after an upgrade once again the problem appears:

Do you know which package you updated that broke goobook?

> sergio@izta:~$ goobook query sergio
> Traceback (most recent call last):
>   File "/usr/bin/goobook", line 11, in 
> load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
>   File "/usr/share/goobook/goobook/application.py", line 94, in main
> args.func(config, args)
>   File "/usr/share/goobook/goobook/application.py", line 125, in do_query
> goobk = GooBook(config)
>   File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> self.cache.load()
>   File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> self.update()
>   File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
>   File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contacts
> res = self._get(query)
>   File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
> connection_type=httplib2.HTTPSConnectionWithTimeout)
>   File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
> 562, in new_request
> redirections, connection_type)
>   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> 1608, in request
> (response, content) = self._request(conn, authority, uri, request_uri, 
> method, body, headers, redirections, cachekey)
>   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> 1350, in _request
> (response, content) = self._conn_request(conn, request_uri, method, body, 
> headers)
>   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> 1272, in _conn_request
> conn.connect()
>   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
> 1059, in connect
> raise SSLHandshakeError(e)
> httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
> verify failed (_ssl.c:726)

The above traceback mentions 
"/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py".
This is not the canonical location where Debian Python packages get
installed. I believe you have installed a different version of the
httplib2 module using pip. Could you please test using the Python module
provided by the python-httplib2 package?

Cheers,

-- 
Ilias

Bug#908494: lightning: no icon to access calendar after upgrade to TB 60

[Tim Riemenschneider]

Am 21.09.18 um 17:28 schrieb Carsten Schoenert:
>
>> So IMHO the thunderbird-l10n-$(lang) packages should recommend the
>> corresponding lightning-l10n-$(lang) package,
>> since thunderbird recommends lightning.
> Only a small amount of users is able to really understand what
> Recommends and Suggests means. And the real problem is more the really
> depending package here. But we have no way to detect the correct
> circumstances and needs by dpkg here. So we need to solve this problem
> in a different way than using Recommends.
My idea was that when lightning was installed alongside thunderbird
because of the recommend (i.e. the user did not call apt with
"--without-recommends"), the lightning-l10n package should be
installed, too.
(at least it would have saved me some time finding this. I first tried
to debug this locally before I went to the bugtracker ;-) )
This would mean, that in a default debian-setup in most cases
one of two cases would happen:
- don't install recommends: only installing thunderbird-l10n-XX would
not install lighting, so no problem (thunderbird is installed via depends)
- install recommends: lightning is installed via recommends, as well
as the language-pack, so also no problem

The current state (lighting-l10n missing) would require some manual
intervention.

>> (I used to only "apt install thunderbird-l10n-de", which pulled in
>> thunderbird and lightning by depends/recommends, and
>> just now wondered where my calendar is ;-) )
>>
>> Even better would be to detect the missing lightning-l10n-pack and
>> either let lightning fallback to english or, if that is somehow
>> not possible, notify the user.
> Unfortunately all this is impossible. We have no way to interact here
> with Thunderbird and control the behavior of the Thunderbird binary then.
I suspected something like that...
However I still find it somewhat strange, that there is no indication inside
thunderbird that something is not alright, I would either expect it to
simply
fallback to english, or to show an error somewhere.
(In my case, coming from software-development myself, even a rather cryptic
"l10n-error: could not open calendar-de/something" would have helped ;-)
But if I understand you right, thats because the debian-packaging deviates
from the way mozilla is distibuting this?
(Would this problem also arise with thirdparty extensions, i.e.
extensions not
normally bundled with thunderbird?)
> We could have detect this all earlier if user would test also packages
> from experimental. :)
>
;-)

Bug#909321: JBL Xtreme not visible on pairing

[Thom Thom]

Package: bluetooth
Version:  5.50-1I have a JBL Xtreme Bluetooth speaker and it's not working with 
my Debian Testing installation. I can't find it when I do the pairing.

It does works with Windows 10 (same laptop) and my Android phone.

$ uname -a
Linux anoob 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux



$ aptitude search ~i | grep -i bluetooth
iB blueman - Graphical bluetooth manager
i  bluetooth - Bluetooth support (metapackage)
iBA bluez - Bluetooth tools and daemons
i  bluez-firmware - Firmware for Bluetooth devices
id libbluetooth3 - Library to use the BlueZ Linux Bluetooth stack
iB pulseaudio-module-bluetooth - Bluetooth module for PulseAudio sound server



$ blueman-applet 
blueman-applet version 2.0.6 starting
_
Load (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:60)
['StatusIcon', 'DBusService', 'ExitItem', 'SerialManager', 'AppIndicator', 
'RecentConns', 'StandardItems', 'PowerManager', 'NetUsage', 'ShowConnected', 
'Menu', 'DhcpClient', 'PPPSupport', 'GameControllerWakelock', 'NMPANSupport', 
'KillSwitch', 'AuthAgent', 'TransferService', 'NMDUNSupport', 'DiscvManager', 
'Networking', 'Headset'] 
_
get_interface_version 
(/usr/lib/python3/dist-packages/blueman/bluez/BlueZInterface.py:13)
Detected BlueZ 5 
/usr/lib/python3/dist-packages/blueman/plugins/applet/AppIndicator.py:8: 
PyGIWarning: AppIndicator3 was imported without specifying a version first. Use 
gi.require_version('AppIndicator3', '0.1') before import to ensure that the 
right version gets loaded.
  from gi.repository import AppIndicator3 as girAppIndicator
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
Not loading DhcpClient because it's conflict has higher priority 
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
Not loading PPPSupport because it's conflict has higher priority 
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
get_interface_version 
(/usr/lib/python3/dist-packages/blueman/bluez/obex/Base.py:20)
Detected BlueZ integrated obexd 
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
update_menuitems 
(/usr/lib/python3/dist-packages/blueman/plugins/applet/DiscvManager.py:123)
warning: Adapter is None 
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
load_nap_settings 
(/usr/lib/python3/dist-packages/blueman/plugins/applet/Networking.py:36)
Loading NAP settings 
_
__load_plugin (/usr/lib/python3/dist-packages/blueman/main/PluginManager.py:133)
loading  
_
io_event 
(/usr/lib/python3/dist-packages/blueman/plugins/applet/KillSwitch.py:71)
killswitch registered 2 
_
io_event 
(/usr/lib/python3/dist-packages/blueman/plugins/applet/KillSwitch.py:71)
State: True 
_
UpdatePowerState 
(/usr/lib/python3/dist-packages/blueman/plugins/applet/PowerManager.py:159)
off False 
foff False 
on True 
current state True 
new state True 
_
_on_obex_owner_changed 
(/usr/lib/python3/dist-packages/blueman/plugins/applet/TransferService.py:172)
obex owner changed: :1.37 
_
on_dbus_name_owner_change (/usr/bin/blueman-applet:95)
org.bluez owner changed to :1.4 
_
initialize 
(/usr/lib/python3/dist-packages/blueman/plugins/applet/RecentConns.py:144)
rebuilding menu 
_

Bug#908206: thunderbird: Can not open links due to AppArmour profile

[Vincas Dargis]

I believe the "perfect" solution would be to implement a child profile, that would allow only to 
launch browsers, as as far as I can see, only links (not attachments) are opened with this new gio 
helper.


Consider:

```
  ...

  /usr/lib/@{multiarch}/glib-[0-9].[0-9]/gio-launch-desktop Cx -> 
gio_launch_desktop,

  ...


  profile gio_launch_desktop {
#include 
#include 

/usr/lib/@{multiarch}/glib-[0-9].[0-9]/gio-launch-desktop mr,

  }


```

Though sadly, AppArmor does not support transition from child profile ("profile transition not 
found") to child profile (nested child), as these `ubuntu-x` helpers implemented by transitioning 
into `sanitized_helper` child profile.


I guess I'll try to propose a child profile with "backported" ubuntu-browsers 
abstraction:

```
  profile gio_launch_desktop {
#include 

/usr/lib/@{multiarch}/glib-[0-9].[0-9]/gio-launch-desktop mr,

#Backported form abstractions/ubuntu-browsers
#TODO: fix when nested child profiles are possible and use that abstraction 
directly
...
/usr/bin/chromium{,-browser} PUx,
/usr/lib{,64}/chromium{,-browser}/chromium{,-browser} Pux,
/usr/bin/firefox PUx,
/usr/lib{,64}/firefox*/firefox* PUx,
...

  }
```

Or alternatively we could use:

```
/usr/lib/@{multiarch}/glib-[0-9].[0-9]/gio-launch-desktop Cx -> 
sanitized_helper,
```

Even if we could use `ubuntu-browsers` as a child-child profile, there's another issue that there's 
no way to specify `Px|Cx->sanitized_helper` - i.e. to either use "proper" profile, OR use 
sanitized_helper (or other mechanism for environment scrubbing) as fallback.


These two features - nested child profiles (or similar alternaive), and fallback profile transitions 
(or similar alternative), would really help to confine these kind of complex GUI applications...

Bug#810865: infinoted NMU to add init script and systemd service file

[Philipp Kern]

On 2018-09-21 14:58, Jonas Meurer wrote:

thanks for maintaining infinoted.

Would you mind if I uploaded an NMU of infinoted just with the patch
from this bugreport applied? I verified that the patch works. It's
somewhat annoying to not have init system integration of infinoted.

I'll go on with an NMU (to delayed-7) if I don't hear back from you.


I'm pretty reluctant to maintain an init script at all and that's the 
primary reason why I haven't merged one - as soon as it's legit to just 
have a systemd service, I'm very happy to add one to the packaging. I 
also think service files should've been submitted upstream and work 
consistently across platforms, which this one won't (due to the 
Debian-specific /etc/default setup, also infinoted.service references an 
${OPTIONS} that isn't actually set?). It also uses /etc/infinoted for 
variable data (directory owned by the service user to store the key 
material there) but doesn't even put the config file into that directory 
- instead it lives in the non-discoverable /etc/xdg directory. I suppose 
given that it's managed by ucf it's not even a conffile (which is good, 
but again not discoverable).


I feel you could feel free to take over the package and if there's 
ongoing maintenance/migration work commit to that? Rather than doing an 
NMU for a wishlist bug? That'd be fine with me.


Kind regards and thanks
Philipp Kern

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Yangfl]

Guillem Jover  于2018年9月21日周五 上午7:42写道：
> Something like the attached patch would do I guess? I'm not sure if
> I'd want to expose those unconditionally, as that might pollute the
> namespace.

Please find the attached md5main-md.c, taken from libmd5-rfc but
modified to be compiled with -lmd. Notice the segfault here. Clearly
MD5End supplies the hash in ASCII hex string, but md5_finish in raw
char array. That's not the same.
/*
  Copyright (C) 2002 Aladdin Enterprises.  All rights reserved.

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
 claim that you wrote the original software. If you use this software
 in a product, an acknowledgment in the product documentation would be
 appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
 misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

  L. Peter Deutsch
  gh...@aladdin.com

 */
/* $Id: md5main.c,v 1.1 2002/04/13 19:20:28 lpd Exp $ */
/*
  Independent implementation of MD5 (RFC 1321).

  This code implements the MD5 Algorithm defined in RFC 1321, whose
  text is available at
	http://www.ietf.org/rfc/rfc1321.txt
  The code is derived from the text of the RFC, including the test suite
  (section A.5) but excluding the rest of Appendix A.  It does not include
  any code or documentation that is identified in the RFC as being
  copyrighted.

  The original and principal author of md5.c is L. Peter Deutsch
  .  Other authors are noted in the change history
  that follows (in reverse chronological order):

  2002-04-13 lpd Splits off main program into a separate file, md5main.c.
 */

#include 
#include 
#include 

#include 

typedef uint8_t md5_byte_t;
typedef uint32_t md5_word_t;
typedef MD5_CTX md5_state_t;

#define md5_init(pms) MD5Init(pms)
#define md5_append(pms, data, nbytes) MD5Update(pms, data, nbytes)
#define md5_finish(pms, digest) MD5End(pms, digest)

/*
 * This file builds an executable that performs various functions related
 * to the MD5 library.  Typical compilation:
 *	gcc -o md5main -lm md5main.c md5.c
 */
static const char *const usage = "\
Usage:\n\
md5main --test		# run the self-test (A.5 of RFC 1321)\n\
md5main --t-values		# print the T values for the library\n\
md5main --version		# print the version of the package\n\
";
static const char *const version = "2002-04-13";

/* Run the self-test. */
static int
do_test(void)
{
static const char *const test[7*2] = {
	"", "d41d8cd98f00b204e9800998ecf8427e",
	"a", "0cc175b9c0f1b6a831c399e269772661",
	"abc", "900150983cd24fb0d6963f7d28e17f72",
	"message digest", "f96b697d7cb7938d525a2f31aaf161d0",
	"abcdefghijklmnopqrstuvwxyz", "c3fcd3d76192e4007dfb496cca67e13b",
	"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789",
"d174ab98d277d9f5a5611c2c9f419d9f",
	"12345678901234567890123456789012345678901234567890123456789012345678901234567890", "57edf4a22be3c955ac49da2e2107b67a"
};
int i;
int status = 0;

for (i = 0; i < 7*2; i += 2) {
	md5_state_t state;
	md5_byte_t digest[16];
	char hex_output[16*2 + 1];
	int di;

	md5_init();
	md5_append(, (const md5_byte_t *)test[i], strlen(test[i]));
	md5_finish(, digest);
	for (di = 0; di < 16; ++di)
	sprintf(hex_output + di * 2, "%02x", digest[di]);
	if (strcmp(hex_output, test[i + 1])) {
	printf("MD5 (\"%s\") = ", test[i]);
	puts(hex_output);
	printf(" ERROR, should be: %s\n", test[i + 1]);
	status = 1;
	}
}
if (status == 0)
	puts("md5 self-test completed successfully.");
return status;
}

/* Print the T values. */
static int
do_t_values(void)
{
int i;
for (i = 1; i <= 64; ++i) {
	unsigned long v = (unsigned long)(4294967296.0 * fabs(sin((double)i)));

	/*
	 * The following nonsense is only to avoid compiler warnings about
	 * "integer constant is unsigned in ANSI C, signed with -traditional".
	 */
	if (v >> 31) {
	printf("#define T%d /* 0x%08lx */ (T_MASK ^ 0x%08lx)\n", i,
		   v, (unsigned long)(unsigned int)(~v));
	} else {
	printf("#define T%d0x%08lx\n", i, v);
	}
}
return 0;
}

/* Main program */
int
main(int argc, char *argv[])
{
if (argc == 2) {
	if (!strcmp(argv[1], "--test"))
	return do_test();
	if (!strcmp(argv[1], "--t-values"))
	return do_t_values();
	if (!strcmp(argv[1], "--version")) {
	puts(version);
	return 0;
	}
}
puts(usage);
return 0;
}

Bug#909319: Show unnecessary overrides

[Josh Triplett]

Package: lintian
Version: 2.5.104
Severity: normal

Sometimes an override becomes unnecessary, either because the package
changed to not need it or lintian changed to become more discerning and
no longer flags the package. Either way, at that point the override
becomes unnecessary. Lintian should show the unnecessary override to
call attention to it, so that the maintainer can remove it.

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-6
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.34-2
ii  gettext0.19.8.1-7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.74+repack-1
ii  man-db 2.8.4-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-7
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#909313: [xul-ext-sogo-connector] Not compatible with thunderbird 60 (New version exists)

[Carsten Schoenert]

Please use Reply-All to update the BTS as well.

Am 21.09.18 um 17:34 schrieb Michael Meier:
...
> I've just tested out the nightly build, and it seems to be working. I've 
> created some events, tried to sync them in both ways, delete them.
> 
> So at least basic functionality seems to be working. The rest time will 
> show...
> 
> The new version is not compatibly to thunderbird version <60.

Thanks, unfortunately this package has some low priority at the moment
on my side.

-- 
Regards
Carsten Schoenert

Bug#909313: [xul-ext-sogo-connector] Not compatible with thunderbird 60 (New version exists)

[Michael Meier]

ups, I didn't reply to the list...

On 9/21/18 9:21 AM, Carsten Schoenert


Hello Michael,

Am 21.09.18 um 15:29 schrieb Michael Meier:

The version 31.0.5-2 is not compatible with thunderbird 60.
But it seems there exists already a new sogo-connector version which is
compatible. Please update.

have you tested this?

Updating to 31.0.6 is not that easy as simply importing the updated 
version.

First we need to be able to build every thing from source due the DFSG
and secondly the packaging need to be moved over to the packaging format
of webextension packages.

Before doing all this we need to be sure that the new version of
sogo-connector is really working with TB >= 60.x.

I've just tested out the nightly build, and it seems to be working. I've 
created some events, tried to sync them in both ways, delete them.


So at least basic functionality seems to be working. The rest time will 
show...


The new version is not compatibly to thunderbird version <60.

Bug#909281: Apparmor: allow access to ~/.mailcap

[Vincas Dargis]

On Thu, 20 Sep 2018 16:53:44 -0400 Anthony DeRobertis  wrote> would make sense 
to allow a mail program to read ~/.mailcap (and execute

the programs found there, no idea how that's done in apparmor)


Allowing to read that file will be trivial, but AppArmor will not be able to parse it and 
dynamically allow execute programs based on that file. You'll have to add rules to 
`/etc/apparmor.d/local/usr.bin.thunderbird`, like:


```
/usr/bin/foo PUx, # your application mentioned in .mailcap
```

Bug#896109: ppc64el test failure

[Frédéric Bonnard]

As this is not a gcc bug, I'm wondering if that's just not something to
handle on flif side also.. see that other related bug :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906708

F.


pgpsVyvqYVpAX.pgp
Description: PGP signature

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Geoff Levand]

On 09/20/2018 12:49 PM, Geoff Levand wrote:
> Attached are the two kernel config patches rebased to the latest v4.18.6-1
> Buster kernel. 

Forgot to include the rebased m400 fixup patch.

  0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
  0002-arm64-Updates-for-ACPI-servers.patch
  0003-arm64-Add-fixup-for-HPE-m400-APEI-firmware-problems.patch

-Geoff

>From 63d1232a77b667090e2dd3fff0ac7868784850e9 Mon Sep 17 00:00:00 2001
From: Geoff Levand 
Date: Thu, 20 Sep 2018 12:23:55 -0700
Subject: [PATCH 1/8] [arm64] Use default of CONFIG_ACPI_NFIT=m

Commit ed497f3cb706d0e0f63844b064d9ebbf6f33b052 (Add server and 96boards options)
added an arm64 specific CONFIG_ACPI_NFIT=y, overriding the default of =m, but the
commit message mentions nothing about why this was done.

Remove the arm64 specific setting and use the default of module build.

Cc: Riku Voipio 
Signed-off-by: Geoff Levand 
---
 debian/config/arm64/config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index d14f3ff13174..0e0bf1b05db7 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -71,7 +71,7 @@ CONFIG_ACPI_NUMA=y
 ##
 ## file: drivers/acpi/nfit/Kconfig
 ##
-CONFIG_ACPI_NFIT=y
+CONFIG_ACPI_NFIT=m
 
 ##
 ## file: drivers/android/Kconfig
-- 
2.14.1

>From b1e30cf4155b5496234da7b1072f4c246cdfc9a1 Mon Sep 17 00:00:00 2001
From: Geoff Levand 
Date: Thu, 20 Sep 2018 12:23:55 -0700
Subject: [PATCH 2/8] [arm64] Updates for ACPI servers

o Enable CONFIG_SCHED_SMT for hyperthreading processors.
o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
o Enable a number of ACPI options likely to be available on servers.
o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.

Signed-off-by: Geoff Levand 
---
 debian/config/arm64/config | 29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index 0e0bf1b05db7..1a6c6a41d6e4 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -9,6 +9,7 @@ CONFIG_ARM64_ERRATUM_834220=y
 CONFIG_ARM64_VA_BITS_48=y
 ## end choice
 CONFIG_SCHED_MC=y
+CONFIG_SCHED_SMT=y
 CONFIG_NR_CPUS=256
 CONFIG_NUMA=y
 CONFIG_SECCOMP=y
@@ -24,6 +25,7 @@ CONFIG_RANDOMIZE_BASE=y
 CONFIG_RANDOMIZE_MODULE_REGION_FULL=y
 CONFIG_ARM64_ACPI_PARKING_PROTOCOL=y
 CONFIG_COMPAT=y
+CONFIG_ARM64_LSE_ATOMICS=y
 
 ##
 ## file: arch/arm64/crypto/Kconfig
@@ -67,6 +69,21 @@ CONFIG_ARCH_XGENE=y
 ##
 CONFIG_ACPI=y
 CONFIG_ACPI_NUMA=y
+CONFIG_ACPI_PCI_SLOT=y
+CONFIG_ACPI_HED=y
+CONFIG_ACPI_BGRT=y
+CONFIG_ACPI_WATCHDOG=y
+CONFIG_ACPI_CONFIGFS=m
+
+##
+## file: drivers/acpi/apei/Kconfig
+##
+CONFIG_ACPI_APEI=y
+CONFIG_ACPI_APEI_GHES=y
+CONFIG_ACPI_APEI_PCIEAER=y
+CONFIG_ACPI_APEI_SEA=y
+CONFIG_ACPI_APEI_MEMORY_FAILURE=y
+CONFIG_ACPI_APEI_EINJ=m
 
 ##
 ## file: drivers/acpi/nfit/Kconfig
@@ -222,6 +239,12 @@ CONFIG_EXTCON_USB_GPIO=m
 ##
 CONFIG_RASPBERRYPI_FIRMWARE=y
 
+##
+## file: drivers/firmware/efi/Kconfig
+##
+CONFIG_UEFI_CPER=y
+CONFIG_UEFI_CPER_ARM=y
+
 ##
 ## file: drivers/gpio/Kconfig
 ##
@@ -1097,6 +1120,7 @@ CONFIG_VIRTIO_MMIO=m
 ## file: drivers/watchdog/Kconfig
 ##
 CONFIG_GPIO_WATCHDOG=m
+CONFIG_WDAT_WDT=m
 CONFIG_ARM_SP805_WATCHDOG=m
 CONFIG_ARM_SBSA_WATCHDOG=m
 CONFIG_DW_WATCHDOG=m
@@ -1107,11 +1131,6 @@ CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
 CONFIG_BCM2835_WDT=m
 
-##
-## file: fs/pstore/Kconfig
-##
-CONFIG_PSTORE=y
-
 ##
 ## file: mm/Kconfig
 ##
-- 
2.14.1

>From 0fc33a4cfa3bb1ad35f18d161c9b78298dd08770 Mon Sep 17 00:00:00 2001
From: Geoff Levand 
Date: Thu, 20 Sep 2018 12:23:55 -0700
Subject: [PATCH 3/8] [arm64] Add fixup for HPE m400 APEI firmware problems

Signed-off-by: Geoff Levand 
---
 .../arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch | 94 ++
 debian/patches/series  |  1 +
 2 files changed, 95 insertions(+)
 create mode 100644 debian/patches/bugfix/arm64/arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch

diff --git a/debian/patches/bugfix/arm64/arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch b/debian/patches/bugfix/arm64/arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch
new file mode 100644
index ..efd13e36faa0
--- /dev/null
+++ b/debian/patches/bugfix/arm64/arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch
@@ -0,0 +1,94 @@
+From e0dc30ae9056c3c01423c75ea28c20fb135f72ad Mon Sep 17 00:00:00 2001
+From: Geoff Levand 
+Date: Wed, 13 Jun 2018 10:56:08 -0700
+Subject: [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
+
+Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
+a work-around for HPE ProLiant m400 APEI firmware problems.
+
+The work-around disables APEI when CONFIG_ACPI_APEI is set and
+m400 firmware is detected.  Without this fixup m400 systems
+experience errors like these on startup:
+
+  [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
+  [Hardware Error]: event severity: fatal
+  [Hardware Error]: 

Bug#908494: lightning: no icon to access calendar after upgrade to TB 60

[Carsten Schoenert]

Hello Tim,

Am 21.09.18 um 16:50 schrieb Tim Riemenschneider:
> Thank you, this was exactly my problem, too.

good to hear you were able to solve this issue locally. So thank you for
some positive feedback!

> So IMHO the thunderbird-l10n-$(lang) packages should recommend the
> corresponding lightning-l10n-$(lang) package,
> since thunderbird recommends lightning.

Only a small amount of users is able to really understand what
Recommends and Suggests means. And the real problem is more the really
depending package here. But we have no way to detect the correct
circumstances and needs by dpkg here. So we need to solve this problem
in a different way than using Recommends.

Unfortunately Mozilla isn't going a strict way as before of TB 60. They
have mixed up Lightning as a pre-integrated AddOn in their builds for
some time and also need then the correct l10n files within. Mozilla is
now providing pre-compiled binaries with fitting l10n files for Lighting
too, they also providing different l10n packages for Thunderbird itself
but not for Lightning. This means users are impossible to switch the
Lightning UI to their preferred language if this is different than the
installed language of the Thunderbird archive. We don't want this within
Debian, so we provide different language packs as before.

For all Linux distributions means this they need to rethink their
packaging method, so also we in Debian. And it has costs a lot of time
to figure all this out.

> (I used to only "apt install thunderbird-l10n-de", which pulled in
> thunderbird and lightning by depends/recommends, and
> just now wondered where my calendar is ;-) )
> 
> Even better would be to detect the missing lightning-l10n-pack and
> either let lightning fallback to english or, if that is somehow
> not possible, notify the user.

Unfortunately all this is impossible. We have no way to interact here
with Thunderbird and control the behavior of the Thunderbird binary then.

> In the current state, there is no indication what is wrong:
> - lightning is shown in the addon-manager
> - no error is shown
> - but all artifacts of lightning are completely missing:
>     - no icons in the toolbar
>     - no menu-entry for the whole calendar-menu
>     - no "calendar"-tab in settings
>     - no calendar-related items in File -> new (no "new calendar", "new
> event", "new task" etc.)

We have done some thinking about how to improve the situation.
Currently we will probably drop all the lightning-l10n packages and
package the belonging data within the respective thunderbird-l10n
packages. We need to add the lightning l10n data files here and some
users may don't want to use Lightning, but currently this is the only
way to ensure users get all the needed l10n files as a dependency installed.

We could have detect this all earlier if user would test also packages
from experimental. :)

-- 
Regards
Carsten Schoenert

Bug#896109: ppc64el test failure

[Frédéric Bonnard]

Hi,
this bug happens on ppc64el and several other with the same error.

I compared the .pam files generated on ppc64el and amd64 (whose test
passed) and they have the same md5sum.
The png being from the source, it actually looks like "compare" is
giving a different output on ppc64el .

Digging deeper, it seems imagemagick is victim of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 , because I
recompiled it with -ffp-contract=off and "compare" outputs a "0 (0, 0)".

Not sure if imagemagick should use that flag, but for the time being
wouldn't it possible to use a different metric for compare ?

F.


pgpvQJieyPTnX.pgp
Description: PGP signature

Bug#909275: xorg-server breaks onioncircuits autopkgtest: expected string, NoneType found

[Julien Cristau]

Control: reassign -1 onioncircuits 0.5-2
Control: retitle -1 onioncircuits: flaky autopkgtest?

This doesn't seem related to xorg-server.

Cheers,
Julien

On 09/20/2018 09:36 PM, Paul Gevers wrote:
> Source: xorg-server, onioncircuits
> Control: found -1 xorg-server/2:1.20.1-3
> Control: found -1 onioncircuits/0.5-2
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainers,
> 
> With a recent upload of xorg-server the autopkgtest of onioncircuits
> fails in testing when that autopkgtest is run with the binary packages
> of xorg-server from unstable. Interesting data point, with 2:1.20.1-2
> from two days ago it passed. It passes when run with only packages from
> testing. In tabular form:
>passpass  fail
> xorg-serverfrom testing2:1.20.1-22:1.20.1-3
> onioncircuits  from testing0.5-2 0.5.2
> all others from testingfrom testing  from testing
> 
> I copied some of the output at the bottom of this report. Based on
> reading the xorg-server changelog, I suspect these tests are trying to
> activate something on screen and now they are missing the active area:
>   * xvfb-run*: Update default resolution and bitdepth to match upstream
> defaults.
> 
> Currently this regression is contributing to the delay of the migration
> of xorg-server to testing [1]. Due to the nature of this issue, I filed
> this bug report against both packages. Can you please investigate the
> situation and reassign the bug to the right package? If needed, please
> change the bug's severity.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=xorg-server
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/onioncircuits/1022616/log.gz
> 
> autopkgtest [16:47:15]: test gui-test: [---
> waiting for Tor to settle...
> E
> ==
> ERROR: test_has_correct_circuits (__main__.TestOnionCircuitsGUI)
> --
> Traceback (most recent call last):
>   File "debian/tests/check-circuits", line 70, in test_has_correct_circuits
> self.assertEqual(self._get_circuits(), mycircs)
>   File "debian/tests/check-circuits", line 54, in _get_circuits
> circs.add(", ".join(nicks))
> TypeError: sequence item 0: expected string, NoneType found
> 
> --
> Ran 1 test in 1.046s
> 
> FAILED (errors=1)
> autopkgtest [16:47:37]: test gui-test: ---]
> 

Bug#909318: fai-setup-storage failes with INTERNAL ERROR in setup-storage: convert_unit <476.22GiB

[Michael Schaller]

Package: fai-setup-storage
Version: 5.7.2
Severity: normal

Dear Maintainer,

I'm trying to setup a raw disk image with the size of 1280 bytes (128 
GB) that has been loop mounted with the following disk config:

# Use GPT (with BIOS compatibility), boot from the ESP and create a fstab that
# uses UUIDs.
disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid

# disk1.1: /boot/efi EFI System Partition (ESP).
primary /boot/efi 2048MB vfat defaults

# disk1.2: /boot partition.
primary /boot 2048MB ext2 defaults

# disk1.3: Rest of the disk is an encrypted LUKS container.
primary - 0- - -
disk_config cryptsetup
luks - disk1.3 - -

# disk1.3/LUKS: All the space in the LUKS container will be used by a single LVM
# system VG.
disk_config lvm fstabkey:uuid
#vg system disk1.3


The setup storage command line I'm using is:

/usr/sbin/setup-storage -X -f disk_config -d -D loop0


The config works without 'disk_config lvm fstabkey:uuid'.
As soon as 'disk_config lvm' is added it fails with this error:

INTERNAL ERROR in setup-storage:
convert_unit <476.22GiB
Please report this error to the Debian Bug Tracking System.
 at /usr/share/fai/setup-storage/Parser.pm line 379.
FAI::convert_unit("<476.22GiB") called at 
/usr/share/fai/setup-storage/Volumes.pm line 430
FAI::get_current_lvm called at /usr/sbin/setup-storage line 168


setup-storage is running on a host system that also uses LVM inside a LUKS 
container for the running Linux system.

How could I gather more information what is actually going wrong here?

Best,

Michael Schaller

Bug#905820: android-platform-external-boringssl: Incomplete debian/copyright?

[Chris Lamb]

tags 905820 + pending
thanks

Hi Kai,

> https://mentors.debian.net/debian/pool/main/a/android-platform-external-boringssl/android-platform-external-boringssl_8.1.0+r23-2.dsc

Uploaded; thanks! Please address the Lintian errors on the next upload,
mind you...


Regards,

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

Bug#908494: lightning: no icon to access calendar after upgrade to TB 60

[Tim Riemenschneider]

Thank you, this was exactly my problem, too.

So IMHO the thunderbird-l10n-$(lang) packages should recommend the
corresponding lightning-l10n-$(lang) package,
since thunderbird recommends lightning.

(I used to only "apt install thunderbird-l10n-de", which pulled in
thunderbird and lightning by depends/recommends, and
just now wondered where my calendar is ;-) )

Even better would be to detect the missing lightning-l10n-pack and
either let lightning fallback to english or, if that is somehow
not possible, notify the user.
In the current state, there is no indication what is wrong:
- lightning is shown in the addon-manager
- no error is shown
- but all artifacts of lightning are completely missing:
    - no icons in the toolbar
    - no menu-entry for the whole calendar-menu
    - no "calendar"-tab in settings
    - no calendar-related items in File -> new (no "new calendar", "new
event", "new task" etc.)

Bug#909317: texlive-bin: buffer overflow (DSA-4299-1)

[Salvatore Bonaccorso]

Source: texlive-bin
Version: 2016.20160513.41080.dfsg-2
Severity: grave
Tags: patch security upstream fixed-upstream
Control: fixed -1 2016.20160513.41080.dfsg-2+deb9u1
Control: fixed -1 2018.20180907.48586-2

Filling for tracking of the issue fixed in DSA-4299-1, CVE assignment
is pending.

Nick Roessler from the University of Pennsylvania has found a buffer overflow
in texlive-bin, the executables for TexLive, the popular distribution of TeX
document production system.

This buffer overflow can be used for arbitrary code execution by crafting a
special type1 font (.pfb) and provide it to users running pdf(la)tex, dvips or
luatex in a way that the font is loaded.

https://lists.debian.org/debian-security-announce/2018/msg00230.html

Regards,
Salvatore

Bug#906472: How should sparse depend on gcc?

[Uwe Kleine-König]

Hello,

sparse is a C code checker that reuses include files from gcc. Currently
there are missing the needed dependencies
(https://bugs.debian.org/906472).

Now I wonder, what is the right way to depend on gcc. For sparse it
would be enough to depend on libgcc-8-dev (I think), but as cgcc (which
is included in the sparse package) calls gcc, too, I need a dependency
on the gcc package directly (which via gcc-8 depends on libgcc-8-dev).

As gcc-7 doesn't provide the needed paths, gcc 4:7.whatever isn't enough
though.

I can imagine the following options to depend on:

a) gcc, libgcc-8-dev
b) gcc (>= 4:8~), gcc (<< 4:9)

. Both have the disadvantage that they need manual adaption when gcc
bumps it's major version.

a) also has the disadvantage that gcc might provide gcc-9 and so sparse
uses different includes than the default compiler (not sure this is bad
enough to care).

b) is bad, because gcc_4:9~prerelease12 would be good enough to make
dpkg happy, but sparse would fail anyhow.

Alternatively sparse could stop hardcoding the include path and ask gcc
on each invokation. But I don't like that much as the path hardly ever
changes and it adds some overhead to sparse.

Do you have any thoughts/recommendations?

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#909313: [xul-ext-sogo-connector] Not compatible with thunderbird 60 (New version exists)

[Carsten Schoenert]

Hello Michael,

Am 21.09.18 um 15:29 schrieb Michael Meier:
> The version 31.0.5-2 is not compatible with thunderbird 60.
> But it seems there exists already a new sogo-connector version which is 
> compatible. Please update.

have you tested this?

Updating to 31.0.6 is not that easy as simply importing the updated version.
First we need to be able to build every thing from source due the DFSG
and secondly the packaging need to be moved over to the packaging format
of webextension packages.

Before doing all this we need to be sure that the new version of
sogo-connector is really working with TB >= 60.x.

-- 
Regards
Carsten Schoenert

Bug#905783: dunno if I should add this to the current bug or make a new bug -

[James Lu]

Hi Shirish,

Re title: Filing new bugs for each distinct problem / error is easiest
to manage on any BTS :)

Also, was the original autostart issue fixed? Everything else previously
mentioned here should be fixed as of 0.7.0.

On 2018-09-21 01:55 AM, shirish शिरीष wrote:
> Dear James,
> 
> After today's update, I took the plunge and removed -
> 
> ~/.config$ rm -rf variety
> 
> $ variety
> ERROR: 2018-09-21 14:10:30,552: _generate_pencil_tile() 'Could not
> generate pencil_tile.png'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
> 302, in _generate_pencil_tile
> "-motion-blur 0x20+135 -charcoal 2 -resize 50%% %s" %
> pipes.quote(pencil_tile_filename.encode('utf8')))
>   File "/usr/lib/python3.6/shlex.py", line 314, in quote
> if _find_unsafe(s) is None:
> TypeError: cannot use a string pattern on a bytes-like object

Fixed in
https://github.com/varietywalls/variety/commit/a6eaec2e5f5ef3836919d4ce70303cf94899f83c
for next release

> WARNING: 2018-09-21 14:10:30,653: load_history() 'Could not load
> history file, continuing without it, no worries'
> WARNING: 2018-09-21 14:10:30,846: create_menu() 'Variety Slideshow is
> not installed. This is an optional extension adding pan-and-zoom
> slideshows to Variety: see
> https://github.com/peterlevi/variety-slideshow for details'
> 
> (variety:1800): Gdk-CRITICAL **: 14:10:30.994:
> gdk_window_thaw_toplevel_updates: assertion
> 'window->update_and_descendants_freeze_count > 0' failed
> ERROR: 2018-09-21 14:10:31,145: image_ok() 'Error in image_ok for file
> /usr/share/backgrounds/bluebird.svg'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
> 1478, in image_ok
> i = PILImage.open(img)
>   File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2622, in open
> % (filename if filename else fp))
> OSError: cannot identify image file '/usr/share/backgrounds/bluebird.svg'
> ERROR: 2018-09-21 14:10:31,319: image_ok() 'Error in image_ok for file
> /usr/share/backgrounds/greybird.svg'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
> 1478, in image_ok
> i = PILImage.open(img)
>   File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2622, in open
> % (filename if filename else fp))
> OSError: cannot identify image file '/usr/share/backgrounds/greybird.svg'
> ERROR: 2018-09-21 14:10:31,605: image_ok() 'Error in image_ok for file
> /usr/share/backgrounds/albatross-wall-source.svg'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/variety/VarietyWindow.py", line
> 1478, in image_ok
> i = PILImage.open(img)
>   File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2622, in open
> % (filename if filename else fp))
> OSError: cannot identify image file
> '/usr/share/backgrounds/albatross-wall-source.svg'
> 
> Looks like variety doesn't understand svg files :(

This might be a worthwhile feature request, though I have no idea how
common desktop environment support for SVG backgrounds is.

> Seems the scripts are not regenerated and guess variety has to be
> purged and installed as new .
> 
> Did that and still came with the error above.

They should be copied even if the pencil_tile generation breaks?
Double check whether ~/.config/variety/scripts/ looks correct.

> Also nice to see variety using libayatana-appindicator instead of the
> way out appindicator.

:)

Best,
James



signature.asc
Description: OpenPGP digital signature