Bug#926720: [Pkg-javascript-devel] Bug#926720: node-miller-rabin: FTBFS randomly (uses a non-prime to test the test)

[Santiago Vila]

On Tue, Apr 09, 2019 at 09:31:07PM +0200, Xavier wrote:

> > NB, it's been already reported upstream that the number of iterations
> > this implementation chooses in not adequate:
> > https://github.com/indutny/miller-rabin/issues/9
> 
> I think we could keep this patch for now to avoid FTBFS and reopened
> this bug with a lower severity (normal) to wait for upstream patch, do
> you agree ?

I would keep the current bug unchanged (at least until the current
package propagates to testing) and file another (different) bug saying
"please fix the code and enable the test suite" (i.e. what Jakub asked).

Thanks.

Bug#926743: fetchmail: update-libc.d script can't find invoke-rc.d

[nick black]

Package: fetchmail
Version: 6.4.0~beta4-3
Severity: normal
Tags: patch

Dear Maintainer,

fetchmail 6.4.0~beta4-3 doesn't play nicely with
init-system-helpers 1.56+nmu1 in Unstable. We get the following error on
device ifdown:

[schwarzgerat](0) $ sudo ifdown iw7260
...blahblah
DHCPRELEASE of **
/etc/resolvconf/update-libc.d/fetchmail: 4: 
/etc/resolvconf/update-libc.d/fetchmail: invoke-rc.d: not found
run-parts: /etc/resolvconf/update-libc.d/fetchmail exited with return code 127
run-parts: /etc/resolvconf/update.d/libc exited with return code 1
[schwarzgerat](0) $

The problem is resolved by supplying the full path (among other possible
solutions). I've included a patch to do this. Thanks!

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

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

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.8.6.1
ii  libc6 2.28-8
ii  libcom-err2   1.45.0-1
ii  libgssapi-krb5-2  1.17-2
ii  libk5crypto3  1.17-2
ii  libkrb5-3 1.17-2
ii  libssl1.1 1.1.1b-1
ii  lsb-base  10.2019031300

Versions of packages fetchmail recommends:
ii  ca-certificates  20190110

Versions of packages fetchmail suggests:
pn  fetchmailconf   
ii  postfix [mail-transport-agent]  3.4.5-1
ii  resolvconf  1.79

-- no debconf information
diff -ur fetchmail-6.4.0~beta4/debian/resolvconf 
fetchmail-6.4.0~beta4-new/debian/resolvconf
--- fetchmail-6.4.0~beta4/debian/resolvconf 2018-06-23 11:52:22.0 
-0400
+++ fetchmail-6.4.0~beta4-new/debian/resolvconf 2019-04-09 18:53:43.756857127 
-0400
@@ -1,5 +1,5 @@
 #!/bin/sh
 
 if [ -x /etc/init.d/fetchmail ] && [ -n "$(pidof fetchmail)" ]; then
-invoke-rc.d --quiet fetchmail awaken
+/usr/sbin/invoke-rc.d --quiet fetchmail awaken
 fi

Bug#882324: fixed in amavisd-new 1:2.11.0-6.1

[MK]

Any chance of having this pushed into debian-release for buster via an unblock 
request?This seems important to anyone running a mail server with amavis in 
buster.
Thanks-M
 

Bug#926744: gimp: Error message when backporting Gimp 2.10.8-2 Debian package from unstable to stable

[Faheem Mitha]

Package: gimp
Version: 2.10.8-2
Severity: normal

Dear Maintainer,

Reported at https://gitlab.gnome.org/GNOME/gimp/issues/3216 but I got
answer which suggests the Gimp devs consider this a Debian issue. So
reporting it here.

Summary, I tried to backport the Debian Gimp 2.10.8 packaging to
stable, the build errors out with failed tests.

I've done this with lots of packages. It normally works, but I realise
Gimp is a complex piece of software with many dependencies.

I'm attaching app/tests/test-suite.log.

I haven't actually installed the 2.10.8 package, though I'm upgraded a
bunch of dependencies. So the versions reported are a bit off.

I'd appreciate any ideas about what these failed tests might mean.

Regards, Faheem Mitha

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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)

Versions of packages gimp depends on:
ii  gimp-data2.8.18-1+deb9u1
ii  libaa1   1.4p5-44+b1
ii  libatk1.0-0  2.22.0-1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdbus-glib-1-2 0.108-2
ii  libexif120.6.21-2+b2
ii  libexpat12.2.0-2+deb9u1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libgegl-0.3-00.3.8-4
ii  libgimp2.0   2.8.18-1+deb9u1
ii  libglib2.0-0 2.60.0-1
ii  libgs9   9.26a~dfsg-0+deb9u1
ii  libgtk2.0-0  2.24.31-2
ii  libgudev-1.0-0   230-3
ii  libice6  2:1.0.9-2
ii  libjpeg62-turbo  1:1.5.1-2
ii  libjson-glib-1.0-0   1.2.6-1
ii  liblcms2-2   2.9-3
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libpng16-16  1.6.28-1
ii  libpoppler-glib8 0.48.0-2+deb9u2
ii  librsvg2-2   2.40.16-1+b1
ii  libsm6   2:1.2.2-1+b3
ii  libtiff5 4.0.8-2+deb9u4
ii  libwmf0.2-7  0.2.8.4-10.6
ii  libx11-6 2:1.6.4-3+deb9u1
ii  libxcursor1  1:1.1.14-1+deb9u2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  libxt6   1:1.1.5-1
ii  python   2.7.13-2
ii  python-gtk2  2.24.0-5.1
ii  python2.72.7.13-2+deb9u3
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages gimp recommends:
ii  ghostscript  9.26a~dfsg-0+deb9u1

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-en [gimp-help]  2.8.2-0.1
ii  gvfs-backends 1.30.4-1
ii  libasound21.1.3-5

-- no debconf information
===
   GIMP 2.10.8: app/tests/test-suite.log
===

# TOTAL: 9
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  6
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-save-and-export
==

gimp_icons_sanity_check: Icon theme path has no 'hicolor' subdirectory: 
/usr/share/gimp/2.0/icons
/gimp-save-and-export/new_file_has_no_files: Error creating proxy: Error 
sending credentials: Error sending message: Operation not permitted 
(g-io-error-quark, 14)
Error creating proxy: Error sending credentials: Error sending message: 
Operation not permitted (g-io-error-quark, 14)
Error creating proxy: Error sending credentials: Error sending message: 
Operation not permitted (g-io-error-quark, 14)
Error creating proxy: Error sending credentials: Error sending message: 
Operation not permitted (g-io-error-quark, 14)
Error creating proxy: Error sending credentials: Error sending message: 
Operation not permitted (g-io-error-quark, 14)
OK
/gimp-save-and-export/opened_xcf_file_files: OK
/gimp-save-and-export/imported_file_files: OK
/gimp-save-and-export/saved_imported_file_files: OK
/gimp-save-and-export/exported_file_files: Error creating proxy: Error sending 
credentials: Error sending message: Operation not permitted (g-io-error-quark, 
14)
Error creating proxy: Error sending credentials: Error sending message: 
Operation not permitted (g-io-error-quark, 14)
Error creating proxy: Error sending credentials: Error sending message: 
Operation not permitted (g-io-error-quark, 14)
Error creating proxy: Error sending credentials: Error sending message: 
Operation not permitted (g-io-error-quark, 14)
OK
/gimp-save-and-export/clear_import_file_after_export: OK

Bug#926733: gimp-gmic does not load

[jEsuSdA]

Package: gimp-gmic
Version: 2.4.5-1
Severity: important

Dear Maintainer,

The gimp-gmic Debian package does not run at all in my machine.

I tested the gimp-gmic binary from gmic.eu download page and it works fine.

Here some error messages I obtain trying runing gimp-gmic from debian package:



[Detaching after vfork from child process 3401]

(gmic_gimp:3401): Gtk-WARNING **: 20:07:50.099: Theme parsing error: gtk-
contained.css:5000:8: 'height' is not a valid property name

(gmic_gimp:3401): Gtk-WARNING **: 20:07:50.099: Theme parsing error: gtk-
contained.css:5001:7: 'width' is not a valid property name

(gmic_gimp:3401): Gtk-WARNING **: 20:07:50.099: Theme parsing error: gtk-
contained.css:5090:26: The :insensitive pseudo-class is deprecated. Use
:disabled instead.

(gmic_gimp:3401): Gtk-WARNING **: 20:07:50.100: Theme parsing error: gtk-
contained.css:5091:19: The :insensitive pseudo-class is deprecated. Use
:disabled instead.

(gmic_gimp:3401): GLib-GObject-WARNING **: 20:07:50.142: cannot register
existing type 'GtkWidget'

(gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142:
g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE
(instance_type)' failed

(gmic_gimp:3401): GLib-GObject-WARNING **: 20:07:50.142: cannot register
existing type 'GtkBuildable'

(gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142:
g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE
(interface_type)' failed

(gmic_gimp:3401): GLib-CRITICAL **: 20:07:50.142: g_once_init_leave: assertion
'result != 0' failed

(gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142:
g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE
(instance_type)' failed

(gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142:
g_type_register_static: assertion 'parent_type > 0' failed
[Thread 0x7fffcd9c2700 (LWP 3393) exited]





Thanks a lot.



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

Kernel: Linux 4.18.0-20.2-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gimp-gmic depends on:
ii  gimp 2.10.8-2+aptbuild3
ii  libatk1.0-0  2.30.0-2
ii  libbabl-0.1-01:0.1.62-dmo1
ii  libc62.28-7
ii  libcairo21.16.0-2+aptbuild1
pn  libcurl3 
ii  libfftw3-double3 3.3.8-2
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-2
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libgegl-0.4-01:0.4.12-dmo1+aptbuild2
ii  libgimp2.0   2.10.8-2+aptbuild3
ii  libglib2.0-0 2.58.3-1
ii  libgmic1 2.4.5-1
ii  libgomp1 8.3.0-2
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libpng16-16  1.6.34-2
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-2
ii  libx11-6 2:1.6.7-1
ii  zlib1g   1:1.2.11.dfsg-1

gimp-gmic recommends no packages.

Versions of packages gimp-gmic suggests:
pn  gmic  

Bug#926700: cacti: CVE-2019-11025

[Paul Gevers]

Control: found -1 0.8.8h+ds1-10 0.8.8b+dfsg-8+deb8u6

Hi Salvatore,

On 09-04-2019 12:28, Salvatore Bonaccorso wrote:
> Please adjust the affected versions in the BTS as needed.

Doing so now. Thanks for the report.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#926720: node-miller-rabin: FTBFS randomly (uses a non-prime to test the test)

[Jakub Wilk]

* Santiago Vila , 2019-04-09, 15:32:
AFAIK, this being a primality test, I assume the outcome is either "not 
prime" or "maybe prime", so the only way to test the test is by giving 
a known prime and expect "maybe prime" as output.


So: Why is the test calling mr.test with 221, which is not prime? (221 
= 13 x 17)


Correctly implemented Miller-Rabin test should have false positives only 
with negligible probability.


And why this fails randomly? Does the test perform random calculations 
internally and it's therefore not deterministic?


Yes.

Even in such case I don't see how a non-prime like 221 may help to 
catch obvious errors in a test suite for a primality test.


It's just proven to be useful.

Please restore the test and fix the code instead.

NB, it's been already reported upstream that the number of iterations 
this implementation chooses in not adequate:

https://github.com/indutny/miller-rabin/issues/9

--
Jakub Wilk

Bug#899128: kdepim: Limit CVE-2017-17689 (EFAIL) even more for kmail

[Moritz Muehlenhoff]

On Tue, Apr 09, 2019 at 06:49:16PM +0200, Ivo De Decker wrote:
> Hi Salvatore,
> 
> On 4/8/19 10:59 PM, Salvatore Bonaccorso wrote:
> > Control: reassign -1 src:kdepim
> > On Mon, Apr 08, 2019 at 11:36:10AM +0200, Ivo De Decker wrote:
> > > Hi,
> > > 
> > > On Sat, May 19, 2018 at 07:18:06PM +0200, Sandro Knauß wrote:
> > > > I now created a debdiff for kdepim. The patch depdends on the new 
> > > > symbol that
> > > > was added in new messageviewer (see #899127).
> > > 
> > > Does this bug still affect buster/sid? From the bug log and the tracker 
> > > for
> > > CVE-2017-17689, it look like kmail in buster/sid is not affected, but it 
> > > would
> > > be good if someone could confirm that.
> > 
> > I think the tracking problem was hiere that #899128 is associated with
> > src:meta-kde, but it should be src:kdepim (#899128) and respectively
> > kf5-messagelib was #899127. The issue was fixed in the kf5-messagelib
> > in version 4:18.08.1-1. In stretch src:kdepim was a source package,
> > whilst in buster kdepim is a binary package produced by kde-meta, but
> > the issue lies there in src:kf5-messagelib.
> 
> The tracker for CVE-2017-17689 doesn't list anything related to kdepim or
> src:meta-kde for buster. Is the issue fixed in the binary kdepim (produced
> by src:meta-kde) in buster? If so, that should probably be stated explicitly
> in the tracker.

For buster the affected code is in src:kf5-messagelib and fixed in 4:18.08.1-1

In stretch the affected code is in src:kdepim

In Buster the binary package kdepim is now built out of src:meta-kde, but that
was never affected. That's we don't track src:meta-kde at all in
https://security-tracker.debian.org/tracker/CVE-2017-17689

Does that clarify?

Cheers,
Moritz

Bug#926737: Possible memory leak after upgrading from 16.1.1 to 16.2.1

[Bernhard Schmidt]

Source: asterisk
Version: 1:16.2.1~dfsg-1
Severity: serious

Hi,

I intend to look at this myself, but I'm short on time right now. Filing this
bug so I don't forget (and maybe someone else can look at it).

After having upgraded one of my test systems from 16.1.1 to 16.2.1 shows the
Asterisk process being constantly growing until the machine finally runs out of
memory.

2019-04-04 16:55:33 upgrade asterisk:amd64 1:16.1.1~dfsg-1 1:16.2.1~dfsg-1

This was a dist-upgrade in a sid container, so it might be something else
triggering it, but it is definitely the Asterisk process leaking memory.

asterisk 10485  0.3 26.8 964940 271656 ?   Ssl  Apr08   5:23 
/usr/sbin/asterisk -g -f -p -U asterisk

Directly after a fresh restart

asterisk 11171 15.8  8.0 759704 80928 ?Ssl  19:45   0:03 
/usr/sbin/asterisk -g -f -p -U asterisk

I'll do some more tests and will followup on this bug.

Bernhard

Bug#922754: closing 922754

[Sven Hartge]

On Thu, 04 Apr 2019 14:24:40 +0100 Sam Morris  wrote:

> # turns out this was a local problem

For the archives: Could you please describe the local problem and the
solution? Because I am having exactly the same problem with plymouth here.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#926738: git-send-email: transferencoding config ignored

[Heinrich Schuchardt]

Package: git-email
Version: 1:2.20.1-2
Severity: normal

The value of the sendmail.transferencoding configuration item is ignored.

A patch has been submitted as
https://marc.info/?l=git=155483810827726=2

The patch is also appended.

Best regards

Heinrich Schuchardt
From f3afc36a7c624f300739ab43fd56b9e4850db6a5 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Tue, 9 Apr 2019 21:03:43 +0200
Subject: [PATCH 1/1] send-email: fix transferencoding config option

Since e67a228cd8a ("send-email: automatically determine transfer-encoding")
the value of sendmail.transferencoding is ignored because when parsing
the configuration $target_xfer_encoding is not initial anymore.

Instead of initializing variable $target_xfer_encoding on definition we
have to set it to the default value of 'auto' if is initial after parsing
the configuration files.

The documentation erroneously mentions the option as
sendmail.transferEncoding. Fix that typo.

Fixes: e67a228cd8a ("send-email: automatically determine transfer-encoding")
Signed-off-by: Heinrich Schuchardt 
---
 Documentation/git-send-email.txt | 2 +-
 git-send-email.perl  | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 1afe9fc858..884e776add 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -146,7 +146,7 @@ Note that no attempts whatsoever are made to validate the encoding.
 	even more opaque.  auto will use 8bit when possible, and quoted-printable
 	otherwise.
 +
-Default is the value of the `sendemail.transferEncoding` configuration
+Default is the value of the `sendemail.transferencoding` configuration
 value; if that is unspecified, default to `auto`.

 --xmailer::
diff --git a/git-send-email.perl b/git-send-email.perl
index 8200d58cdc..0e23193939 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -239,7 +239,7 @@ sub do_edit {
 my (@suppress_cc);
 my ($auto_8bit_encoding);
 my ($compose_encoding);
-my $target_xfer_encoding = 'auto';
+my ($target_xfer_encoding);

 my ($debug_net_smtp) = 0;		# Net::SMTP, see send_message()

@@ -446,6 +446,8 @@ sub read_config {
 			$smtp_encryption = 'ssl';
 		}
 	}
+
+	$target_xfer_encoding = 'auto' unless (defined $target_xfer_encoding);
 }

 # read configuration from [sendemail "$identity"], fall back on [sendemail]
--
2.20.1

Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry

[Alf]

Am 09.04.19 um 21:51 schrieb Bernhard Übelacker:
> Hello Alf,
> maybe we can get more context of this crash
> by doing one of the following:
>
> - Install gdb and run linphone like this:
>
> script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' 
> -ex 'bt' -ex 'bt full' -ex 'detach' -ex 'quit' --args linphonec -d 5 -l 
> linphone-debug" -a gdb_linphone_$(date +%Y-%m-%d_%H-%M-%S).log
>
>   The created file might contain a backtrace, that
>   could help here.
>
> - Install a core dump collector like
>
>   - systemd-coredump: should output a backtrace
> without debug symbol information right into
> the journal.
>
> Alternatively one could list the crashes happend
> since this boot by:
>
>coredumpctl list
>
> And attach get a backtrace from gdb from this by:
>
>coredumpctl gdb 
>  bt
>  bt full
>  quit
>
>   - corekeeper: should also collect core dumps which
> could be inspected by:
>
>  gdb -q $(which linphonec) --core /var/crash/user/coredump
>bt
>bt full
>quit
>
> All the ways might be improved by installing
> the debug information packages described in [1],
> e.g. linphone-nogtk-dbgsym.
> Adding these packages for the shared libraries,
> shown in the backtrace, helps further.
>
> Kind regards,
> Bernhard
>
> [1] 
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
>


Hi Bernhard,

I performed the first proposal and got some 4kb of output.
I did not find any debug symbols for linphone yet in the standard
repositories, so there ar some complaints.

I did alter the phone number (2 places) and of course substituted my
paaswrd.

I do attach the output here, please advise whether I should try your
other proposals and/or install required debug symbols.

Kind regards,
Alf
Script started on 2019-04-09 22:35:58+02:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="184" LINES="20"]
Reading symbols from linphonec...(no debugging symbols found)...done.
Starting program: /usr/bin/linphonec -d 5 -l linphone-debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe81ea700 (LWP 2000)]
Ready
Warning: video is disabled in linphonec, use -V or -C or -D to enable.
[New Thread 0x7fffe79e9700 (LWP 2001)]
linphonec> Refreshing on sip:061234567...@tel.t-online.de...
linphonec> Registration on sip:tel.t-online.de failed: Unauthorized 11030230348
linphonec>
Password for 061234567818 on tel.t-online.de: [top secret]
Refreshing on sip:061234567...@tel.t-online.de...
linphonec>
Thread 1 "linphonec" received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31	../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: Datei oder Verzeichnis nicht gefunden.
#0  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#2  0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#3  0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#4  0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#5  0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#6  0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#7  0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#8  0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#9  0x555b1cc2 in sal_iterate ()
#10 0x555eabc6 in linphone_core_iterate ()
#11 0x555a83db in ?? ()
#12 0x555a858d in linphonec_readline ()
#13 0x555a6dd8 in main ()
#0  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
No locals.
#1  0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#2  0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#3  0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#4  0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#5  0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#6  0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#7  0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#8  0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No 

Bug#925359: dietlibc: built program on x32 terminates with 'smashed stack detected, program terminated.'

[Bernhard Übelacker]

Hello Thorsten Glaser,

Am 24.03.19 um 14:25 schrieb Thorsten Glaser:
> Bernhard Übelacker dixit:
> 
>> I see that the syscall number gets modified to become 0x4062.
>>
>> But the syscall modifies 144 bytes, more than just the size of
>> variable ru1 of 88 bytes.
>>
>> This 144 bytes is the size I could observe within amd64 userland.
> 
> The x32 syscalls often have struct mapping, so amd64 userland
> sizes have no bearing on it.

That was just to demonstrate what the size would be if
the interface uses 64bit int.
Could there still be struct mapping behind the syscall instruction?
Wouldn't that then already be on kernel side?


>> Found also this bug at bugzilla.kernel.org [1].
> 
> That’s from 2013. But given that it works with the other C libraries
> I’ll see whether I can fix it myself, unless Christian beats me to it.

As this was opened by "H.J. Lu", who was implementing
linux x32 [1][2], I think this sentence from the bug
report could still be relevant:

...
X32 uses the same system call interface as x86-64
for them. Some of those field should be long long
since they must be 64-bit integer in x32.  But long
is 32-bit in x32.


Attached is also a file that wants to demonstrate a
getrusage call with a x32 glibc linked program.
There 144 bytes get modified by the syscall instruction.

Kind regards,
Bernhard

[1] https://lkml.org/lkml/2011/8/26/415
[2] https://sites.google.com/site/x32abi/documents/abi.pdf?attredirects=0=1

# Unstable amd64-kernel with x32-userland qemu VM 2019-04-09

apt update
apt dist-upgrade


apt install dpkg-dev devscripts build-essential gdb mc



mkdir /home/benutzer/source/libc6/orig -p
cd/home/benutzer/source/libc6/orig
apt source libc6
cd







cat < test.c
/*
gcc -g -O0 test.c -o test
*/

#include 
#include 
#include 
#include 

int main()
{
struct rusage usage;
int r;
memset(, 0xab, sizeof(usage));
r = getrusage(RUSAGE_SELF, );
printf("r=%d sizeof(usage)=%d\n", r, sizeof(usage));
}
EOF

gcc -g -O0 test.c -o test
file test
ldd test
./test








benutzer@debian:~$ cat < test.c
> /*
> gcc -g -O0 test.c -o test
> */
> 
> #include 
> #include 
> #include 
> #include 
> 
> int main()
> {
> struct rusage usage;
> int r;
> memset(, 0xab, sizeof(usage));
> r = getrusage(RUSAGE_SELF, );
> printf("r=%d sizeof(usage)=%d\n", r, sizeof(usage));
> }
> EOF
benutzer@debian:~$ 
benutzer@debian:~$ gcc -g -O0 test.c -o test
benutzer@debian:~$ file test
test: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0, 
BuildID[sha1]=fc9badaccaf302b5c1707a8a3c02d4949a4934dd, with debug_info, not 
stripped
benutzer@debian:~$ ldd test
linux-vdso.so.1 (0xff9b)
libc.so.6 => /lib/x86_64-linux-gnux32/libc.so.6 (0xf7d7)
/libx32/ld-linux-x32.so.2 (0xf7f29000)
benutzer@debian:~$ ./test
r=0 sizeof(usage)=144







gdb -q --args ./test

set width 0
set pagination off
directory /home/benutzer/source/libc6/orig/glibc-2.28/sysdeps
b getrusage
run
bt
display/i $pc
stepi
up
print sizeof(usage)
print 
x/160xb (char*)$2 - 8
stepi
x/160xb (char*)$2 - 8
detach
q



##


benutzer@debian:~$ gdb -q --args ./test
Reading symbols from ./test...done.
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/libc6/orig/glibc-2.28/sysdeps
Source directories searched: 
/home/benutzer/source/libc6/orig/glibc-2.28/sysdeps:$cdir:$cwd
(gdb) b getrusage
Breakpoint 1 at 0x401030
(gdb) run
Starting program: /home/benutzer/test 

Breakpoint 1, getrusage () at ../sysdeps/unix/syscall-template.S:78
78  T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) bt
#0  getrusage () at ../sysdeps/unix/syscall-template.S:78
#1  0x0040117a in main () at test.c:15
(gdb) display/i $pc
1: x/i $pc
=> 0xf7efc190 :  mov$0x4062,%eax
(gdb) stepi
0xf7efc195  78  T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
1: x/i $pc
=> 0xf7efc195 :syscall 
(gdb) up
#1  0x0040117a in main () at test.c:15
15  r = getrusage(RUSAGE_SELF, );
(gdb) print sizeof(usage)
$1 = 144
(gdb) print 
$2 = (struct rusage *) 0xd5a0
(gdb) x/160xb (char*)$2 - 8
0xd598: 0x7a0x110x400x000x000x000x000x00
0xd5a0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5a8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5b0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5b8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5c0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5c8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5d0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5d8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5e0: 0xab0xab0xab0xab0xab0xab

Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry

[Alf]

Am 09.04.19 um 21:51 schrieb Bernhard Übelacker:
...


And here with the 3 debug packages for linphone installed,

Alf
Script started on 2019-04-09 23:13:10+02:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="119" LINES="28"]
Reading symbols from linphonec...Reading symbols from /usr/lib/debug/.build-id/a6/e413996c0caf2689202302196ba19a26ce481f.debug...done.
done.
Starting program: /usr/bin/linphonec -d 5 -l linphone-debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe81ea700 (LWP 3303)]
Ready
Warning: video is disabled in linphonec, use -V or -C or -D to enable.
[New Thread 0x7fffe79e9700 (LWP 3305)]
linphonec> Refreshing on sip:061234567...@tel.t-online.de...
linphonec> Registration on sip:tel.t-online.de failed: Unauthorized 11030230348
linphonec>
Password for 061234567818 on tel.t-online.de: [top secret]
Refreshing on sip:061234567...@tel.t-online.de...
linphonec>
Thread 1 "linphonec" received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31	../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: Datei oder Verzeichnis nicht gefunden.
#0  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#2  0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#3  0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#4  0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#5  0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#6  0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#7  0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#8  0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
#9  0x555b1cc2 in sal_iterate (sal=) at ./coreapi/bellesip_sal/sal_impl.c:838
#10 0x555eabc6 in linphone_core_iterate (lc=0x55693480) at ./coreapi/linphonecore.c:3194
#11 0x555a83db in linphonec_idle_call () at ./console/linphonec.c:1023
#12 0x555a858d in linphonec_readline (prompt=) at ./console/linphonec.c:543
#13 0x555a6dd8 in linphonec_main_loop (opm=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:64
#14 main (argc=, argv=) at ./console/linphonec.c:652
#0  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
No locals.
#1  0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#2  0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#3  0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#4  0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#5  0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#6  0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#7  0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#8  0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0
No symbol table info available.
#9  0x555b1cc2 in sal_iterate (sal=) at ./coreapi/bellesip_sal/sal_impl.c:838
No locals.
#10 0x555eabc6 in linphone_core_iterate (lc=0x55693480) at ./coreapi/linphonecore.c:3194
calls = 
call = 
curtime_ms = 
elapsed = 
current_real_time = 1554844401
diff_time = 
one_second_elapsed = 0 '\000'
remote_provisioning_uri = 
#11 0x555a83db in linphonec_idle_call () at ./console/linphonec.c:1023
opm = 0x55693480
#12 0x555a858d in linphonec_readline (prompt=) at ./console/linphonec.c:543
prompt_reader_started = 1 '\001'
pipe_reader_started = 0 '\000'
#13 0x555a6dd8 in linphonec_main_loop (opm=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:64
input = 
input = 
iptr = 
input_len = 
#14 main (argc=, argv=) at ./console/linphonec.c:652
No locals.
Detaching from program: /usr/bin/linphonec, process 3299
[Inferior 1 (process 3299) detached]

Script done on 2019-04-09 23:13:21+02:00 [COMMAND_EXIT_CODE="0"]

Bug#926742: netdata: /etc/netdata/edit-config looks for config files in the wrong place

[Nye Liu]

That should have read:

sudo /etc/netdata/edit-config health.d/tcp_listen.conf

edit-config should be something like:

[ -z "${NETDATA_USER_CONFIG_DIR}"  ] && 
NETDATA_USER_CONFIG_DIR="/etc/netdata"
[ -z "${NETDATA_STOCK_CONFIG_DIR}" ] && 
NETDATA_STOCK_CONFIG_DIR="/usr/lib/netdata/conf.d"

Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry

[Bernhard Übelacker]

Hello Alf,
maybe we can get more context of this crash
by doing one of the following:

- Install gdb and run linphone like this:

script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex 
'bt' -ex 'bt full' -ex 'detach' -ex 'quit' --args linphonec -d 5 -l 
linphone-debug" -a gdb_linphone_$(date +%Y-%m-%d_%H-%M-%S).log

  The created file might contain a backtrace, that
  could help here.

- Install a core dump collector like

  - systemd-coredump: should output a backtrace
without debug symbol information right into
the journal.

Alternatively one could list the crashes happend
since this boot by:

   coredumpctl list

And attach get a backtrace from gdb from this by:

   coredumpctl gdb 
 bt
 bt full
 quit

  - corekeeper: should also collect core dumps which
could be inspected by:

 gdb -q $(which linphonec) --core /var/crash/user/coredump
   bt
   bt full
   quit

All the ways might be improved by installing
the debug information packages described in [1],
e.g. linphone-nogtk-dbgsym.
Adding these packages for the shared libraries,
shown in the backtrace, helps further.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Bug#926658: gnuplot: free(): double free detected in tcache 2

[Anton Gladky]

Hello,

thank you all for participating. I will upload a package
with the fix into experimental soon.

Regards

Anton


Am Di., 9. Apr. 2019 um 20:27 Uhr schrieb Bernhard Übelacker <
bernha...@mailbox.org>:

> Control: tags 926658 + patch upstream fixed-upstream
>
>
> Dear Maintainer,
> I just tried to help triage this issue.
>
> I think this is related to upstream bug [1] and
> was already fixed in the 5.2 branch by commit [2].
>
> A package built with this patch does just show the
> 'undefined variable' error, but not the double free fault.
>
> Kind regards,
> Bernhard
>
> [1] https://sourceforge.net/p/gnuplot/bugs/2115/
> [2]
> https://sourceforge.net/p/gnuplot/gnuplot-main/ci/732014eefd41235a143626d2bc02d3d34934e1b3/
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#926720: [Pkg-javascript-devel] Bug#926720: node-miller-rabin: FTBFS randomly (uses a non-prime to test the test)

[Xavier]

Le 09/04/2019 à 21:16, Jakub Wilk a écrit :
> * Santiago Vila , 2019-04-09, 15:32:
>> AFAIK, this being a primality test, I assume the outcome is either
>> "not prime" or "maybe prime", so the only way to test the test is by
>> giving a known prime and expect "maybe prime" as output.
>>
>> So: Why is the test calling mr.test with 221, which is not prime? (221
>> = 13 x 17)
> 
> Correctly implemented Miller-Rabin test should have false positives only
> with negligible probability.
> 
>> And why this fails randomly? Does the test perform random calculations
>> internally and it's therefore not deterministic?
> 
> Yes.
> 
>> Even in such case I don't see how a non-prime like 221 may help to
>> catch obvious errors in a test suite for a primality test.
> 
> It's just proven to be useful.
> 
> Please restore the test and fix the code instead.
> 
> NB, it's been already reported upstream that the number of iterations
> this implementation chooses in not adequate:
> https://github.com/indutny/miller-rabin/issues/9

I think we could keep this patch for now to avoid FTBFS and reopened
this bug with a lower severity (normal) to wait for upstream patch, do
you agree ?

Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable

[Aljoscha Lautenbach]

Hi,

during the BSP in Gothenburg last weekend I discussed with Jonas how
I could help to put libsass back on track regarding its security
status. We agreed that the best move is to start with triaging the
existing Debian bugs and by identifying the CVE status in upstream's
issue tracker. [0]

Unfortunately upstream does not actively track CVE numbers. After
Anthony Fok asked them about it in mid 2018 [1], they replied that
CVE numbers are only tracked if bug reporters add the CVE numbers
themselves, which several bug reporters have started to do since
then. As a result, CVE tracking on upstream's issue tracker seems to
have improved since mid 2018, but there is no guarantee that this
will persist, so manual vigilance is still required. ;)

Also, for older CVEs this info does not seem to be available in
upstream's issue tracker, and occasionally bug status information can
fall through the cracks during merges, see e.g., #2814
(CVE-2019-6283), #2815 (CVE-2019-6286) and #2816 (CVE-2019-6284): the
git log in the master branch only specifies that #2814 was fixed, but
pull request #2857 specifies that the same commit also fixed #2815
and #2816. [2]

I started by cross-referencing the CVEs (which are explicitly
mentioned in upstream's issue tracker) with upstream fixes:

|++-|
| CVE| Upstream bug # | Fixed in upsteam commit |
|++-|
| CVE-2019-6284  | #2816  | 8e681e2 |
| CVE-2019-6286  | #2815  | 8e681e2 |
| CVE-2019-6283  | #2814  | 8e681e2 |
| CVE-2018-19827 | #2782  | b21fb9f |
| CVE-2018-19797 | #2779  | e94b5f9 |
| CVE-2018-11499 | #2643  | 930857c |

As mentioned, this only covers recent CVEs, and there is still a lot
of manual triaging needed. Several of the older CVEs seem to have
been fixed "silently" (without explicitly referring to the CVEs), but
that remains to be confirmed. I will try to cross-reference all known
CVEs with upstream issues on github, so we can track if upstream
fixed them already and when.

This is obviously only the first step, but with that information we
can try to identify which CVEs are still relevant for Debian, and
which fixes need to be backported. Over time, we should be able to
get this package back in shape. :)

Kind regards,
Aljoscha

[0] https://github.com/sass/libsass/issues?q=is%3Aissue+cve+is%3Aclosed
[1] https://github.com/sass/libsass/issues/2682
[2] https://github.com/sass/libsass/pull/2857

Bug#926741: RFP: node-evacuated-mocha -- simple, flexible, fun test framework - Node.js module

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-evacuated-mocha
  Version : 5.2.0
  Upstream Author : TJ Holowaychuk 
* URL : https://salsa.debian.org/themusicgod1-guest/evacuated-mocha
* License : MIT
  Programming Lang: javascript
  Description : simple, flexible, fun test framework - Node.js module

This is an alternative upstream repo/fork to the existing node-mocha.

Mocha is a feature-rich JavaScript test framework running on Node.js and 
browser, making 
asynchronous testing simple and fun. Mocha tests run serially, allowing for 
flexible and 
accurate reporting, while mapping uncaught exceptions to the correct test 
cases. Node.js 
is an event-based server-side JavaScript engine. 

node-evacuated-mocha is a prerequisite to node-gulp-spawn-mocha ( #922716 ).

Bug#926734: unblock: libcaca/0.99.beta19-2.1

[Tobias Frost]

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

Please unblock package libcaca

The new packages fixes 6 CVE's. (Bug #917807)

Thanks!

unblock libcaca/0.99.beta19-2.1

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libcaca-0.99.beta19/debian/changelog 
libcaca-0.99.beta19/debian/changelog
--- libcaca-0.99.beta19/debian/changelog2014-06-02 22:39:11.0 
+0200
+++ libcaca-0.99.beta19/debian/changelog2019-04-06 22:18:41.0 
+0200
@@ -1,3 +1,12 @@
+libcaca (0.99.beta19-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-Pick fixes from upstream git repository:
+- CVE-2018-20545, CVE-2018-20546, CVE-2018-20547,CVE-2018-20548 and
+  CVE-2018-20549 (Closes: #917807)
+
+ -- Tobias Frost   Sat, 06 Apr 2019 22:18:41 +0200
+
 libcaca (0.99.beta19-2) unstable; urgency=medium
 
   * debian/patches/100_doxygen.diff: remove deprecated Doxygen variables.
diff -Nru libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch 
libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch
--- libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch 1970-01-01 
01:00:00.0 +0100
+++ libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch 2019-04-06 
21:36:52.0 +0200
@@ -0,0 +1,45 @@
+From 84bd155087b93ab2d8d7cb5b1ac94ecd4cf4f93c Mon Sep 17 00:00:00 2001
+From: Sam Hocevar 
+Date: Sat, 29 Dec 2018 22:13:56 +0100
+Subject: [PATCH] dither: fix integer overflows that were causing a division by
+ zero.
+
+Fixes: #36 (CVE-2018-20544)
+---
+ caca/dither.c | 16 
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/caca/dither.c b/caca/dither.c
+index 04b678e0..c6ebab1b 100644
+--- a/caca/dither.c
 b/caca/dither.c
+@@ -991,10 +991,10 @@ int caca_dither_bitmap(caca_canvas_t *cv, int x, int y, 
int w, int h,
+ /* First get RGB */
+ if(d->antialias)
+ {
+-fromx = (x - x1) * w / deltax;
+-fromy = (y - y1) * h / deltay;
+-tox = (x - x1 + 1) * w / deltax;
+-toy = (y - y1 + 1) * h / deltay;
++fromx = (uint64_t)(x - x1) * w / deltax;
++fromy = (uint64_t)(y - y1) * h / deltay;
++tox = (uint64_t)(x - x1 + 1) * w / deltax;
++toy = (uint64_t)(y - y1 + 1) * h / deltay;
+ 
+ /* We want at least one pixel */
+ if(tox == fromx) tox++;
+@@ -1017,10 +1017,10 @@ int caca_dither_bitmap(caca_canvas_t *cv, int x, int 
y, int w, int h,
+ }
+ else
+ {
+-fromx = (x - x1) * w / deltax;
+-fromy = (y - y1) * h / deltay;
+-tox = (x - x1 + 1) * w / deltax;
+-toy = (y - y1 + 1) * h / deltay;
++fromx = (uint64_t)(x - x1) * w / deltax;
++fromy = (uint64_t)(y - y1) * h / deltay;
++tox = (uint64_t)(x - x1 + 1) * w / deltax;
++toy = (uint64_t)(y - y1 + 1) * h / deltay;
+ 
+ /* tox and toy can overflow the canvas, but they cannot overflow
+  * when averaged with fromx and fromy because these are guaranteed
diff -Nru libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch 
libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch
--- libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch 
1970-01-01 01:00:00.0 +0100
+++ libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch 
2019-04-06 22:08:34.0 +0200
@@ -0,0 +1,34 @@
+Description: img2txt: fix an integer overflow in the BMP loader.
+Origin: 
https://github.com/cacalabs/libcaca/commit/3e52dabe3e64dc50f4422effe364a1457a8a8592
+Forwarded: not-needed
+Applied-Upstream: 
https://github.com/cacalabs/libcaca/commit/3e52dabe3e64dc50f4422effe364a1457a8a8592
+Last-Update: 2019-04-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/common-image.h
 b/src/common-image.h
+@@ -1,19 +1,19 @@
+ /*
+  *  Imaging tools for cacaview and img2irc
+- *  Copyright (c) 2003-2012 Sam Hocevar 
+- *All Rights Reserved
++ *  Copyright (c) 2003-2018 Sam Hocevar 
++ *  All Rights Reserved
+  *
+  *  This program is free software. It comes without any warranty, to
+  *  the extent permitted by applicable law. You can redistribute it
+  *  and/or modify it under the terms of the Do What the Fuck You Want
+- *  to Public License, Version 2, as published by Sam Hocevar. See
+- *  http://www.wtfpl.net/ for more details.
++ *  to Public License, Version 2, as 

Bug#926740: bugs.debian.org: Subscription confirmation reply-to address length exceeds RFC-5321 limit

[Nazar Zhuk]

Package: bugs.debian.org
Severity: important

Dear Maintainer,

I subscribed to a bug (924787) and received a confirmation email asking
me to confirm the subscription by emailing to
924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org

My smpt server (mailfence) rejects an email to this address with a
message:

---
The recipient address
<924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org>
is not a valid RFC-5321 address..
---

As a result I am unable to confirm subscription.


RFC-5321 states:

---
4.5.3.1.1.  Local-part

The maximum total length of a user name or other local-part is 64
octets.
---

924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f36964b1 
is 79 characters.

-- 
Nazar

Bug#922368: bleachbit: New upstream release (2.2)

[Rogério Brito]

Package: bleachbit
Version: 2.0-3
Followup-For: Bug #922368

There is a new upstream version released. Even if due to the freeze, if it
could be uploaded to experimental, that would be awesome.


Thanks,

Rogério Brito.


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

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

Versions of packages bleachbit depends on:
ii  policykit-10.105-25
ii  python 2.7.16-1
ii  python-gtk22.24.0-5.1+b1
ii  python-simplejson  3.16.0-1

Versions of packages bleachbit recommends:
ii  python-notify  0.1.1-4

bleachbit suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#926628: tdbcmysql: hard-coded (build-)dependency on libmariadbclient18

[Andreas Beckmann]

On Mon, 8 Apr 2019 09:53:16 +0200 Ivo De Decker  wrote:
> tdbcmysql has a hard-coded (build-)dependency on "libmariadbclient18 |
> libmysqlclient18 | libmysqlclient20". This is clearly wrong.
> 
> This now blocks the migration of mariadb-10.3 to testing, because
> libmariadbclient18 is no longer built.

This will require more than just updating the dependencies, since it now
has to dlopen libmariadb.so.3


Andreas

Bug#891294: plasma-discover: Discover->settings->software sources does nothing (seems a bug in kdesu, #913741)

[Laura Arjona Reina]

Hello
I've reproduced the same issue with KDE partition manager and it seems
that the problem is in kdesu (a bug was reported already):

#913741 libkdesu5: when kdesu is invoked by kde partition manager, after
entering the password the window freezes

I've added a block.

Kind regards,

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#926738: git-send-email: transferencoding config ignored

[Jonathan Nieder]

tags 926738 + upstream patch
forwarded 926738 
https://public-inbox.org/git/20190409192733.10173-1-xypron.g...@gmx.de/
quit

Hi,

Heinrich Schuchardt wrote:

> The value of the sendmail.transferencoding configuration item is ignored.
>
> A patch has been submitted as
> https://marc.info/?l=git=155483810827726=2

Thanks for reporting.  Let's discuss this upstream.

Sincerely,
Jonathan

Bug#926658: gnuplot: free(): double free detected in tcache 2

[Bernhard Übelacker]

Control: tags 926658 + patch upstream fixed-upstream


Dear Maintainer,
I just tried to help triage this issue.

I think this is related to upstream bug [1] and
was already fixed in the 5.2 branch by commit [2].

A package built with this patch does just show the
'undefined variable' error, but not the double free fault.

Kind regards,
Bernhard

[1] https://sourceforge.net/p/gnuplot/bugs/2115/
[2] 
https://sourceforge.net/p/gnuplot/gnuplot-main/ci/732014eefd41235a143626d2bc02d3d34934e1b3/

# Buster amd64 real hardware 2019-04-09


apt update
apt dist-upgrade


#


mkdir /home/benutzer/926658_gnuplot-crash -p
cd/home/benutzer/926658_gnuplot-crash

debootstrap --arch=amd64 buster chroot 
http://192.168.178.25:/debian-10-buster-deb.debian.org/
mount --rbind /proc chroot/proc

cp -a ../rr*.deb chroot/
# workaround https://github.com/mozilla/rr/issues/2342

env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -l root
apt install locales
dpkg-reconfigure locales
nano /etc/inputrc
adduser benutzer
mv /etc/apt/sources.list /etc/apt/sources.list.d/buster-approx.list
echo "deb-src http://192.168.178.25:/debian-10-buster-deb.debian.org 
buster main" >> /etc/apt/sources.list.d/buster-approx.list
echo "deb 
http://192.168.178.25:/debian-10-buster-debug.mirrors.debian.org 
buster-debug main" >> /etc/apt/sources.list.d/buster-approx.list


apt update
apt install dpkg-dev devscripts mc wget unzip rr gdb gnuplot 
gnuplot-qt-dbgsym

dpkg -i /*.deb
# workaround https://github.com/mozilla/rr/issues/2342

echo 1 > /proc/sys/kernel/perf_event_paranoid


env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -l benutzer

mkdir /home/benutzer/source/gnuplot/orig -p
cd/home/benutzer/source/gnuplot/orig
apt source gnuplot
cd

mkdir /home/benutzer/source/libc6/orig -p
cd/home/benutzer/source/libc6/orig
apt source libc6
cd

wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=926658;filename=test-files.zip;msg=10;
 -O test-files.zip
unzip test-files.zip
cd test-files
rr record gnuplot call.gpi
rr replay



set width 0
set pagination off
directory 
/home/benutzer/source/gnuplot/orig/gnuplot-5.2.6+dfsg1/src/wxterminal/bitmaps
directory /home/benutzer/source/libc6/orig/glibc-2.28/malloc
cont
bt
reverse-finish
reverse-finish
reverse-finish
reverse-finish
reverse-finish
reverse-finish
reverse-finish
print a->v.string_val
print &(a->v.string_val)
b __GI___libc_free if mem==0x564e97351a60
watch *0x564e9734ed90
reverse-cont
bt
reverse-finish
print a->v.string_val
print &(a->v.string_val)
reverse-cont
bt


#


benutzer@willi-laptop:~$ gnuplot --version
gnuplot 5.2 patchlevel 6


benutzer@willi-laptop:~/test-files$ rr record gnuplot call.gpi
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/gnuplot-0'.
Plotting $tag statistics...
"./tags.gpi" line 27: undefined variable: date_min

free(): double free detected in tcache 2
Abgebrochen




benutzer@willi-laptop:~/test-files$ rr replay
...
Reading symbols from /usr/bin/gnuplot-qt...(no debugging symbols found)...done.
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Remote debugging using 127.0.0.1:16489
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/75/5312dcb2382eb2fde78494879bb2104028ae80.debug...done.
done.
0x7f088a6fd090 in _start () from /lib64/ld-linux-x86-64.so.2
(rr) set width 0
(rr) set pagination off
(rr) cont
Continuing.
Plotting $tag statistics...
"./tags.gpi" line 27: undefined variable: date_min

free(): double free detected in tcache 2

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f0d2535 in __GI_abort () at abort.c:79
#2  0x7f0888929778 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f0888a3428d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f088892fe6a in malloc_printerr (str=str@entry=0x7f0888a35f58 
"free(): double free detected in tcache 2") at malloc.c:5341
#4  0x7f088893194d in _int_free (av=0x7f0888a6bc40 , 
p=0x564e97351a50, have_lock=) at malloc.c:4193
#5  0x564e95fbb8bd in ?? ()
#6  0x564e95fbbd6b in ?? ()
#7  0x564e95fec887 in ?? ()
#8  0x564e95fece8d in ?? ()
#9  0x564e95f9b3bd in ?? ()
#10 0x7f0d409b in __libc_start_main (main=0x564e95f9b000, argc=2, 
argv=0x7ffe67c3fb68, init=, fini=, 
rtld_fini=, stack_end=0x7ffe67c3fb58) at ../csu/libc-start.c:308
#11 0x564e95f9c76a in ?? ()







# With debug symbols

benutzer@willi-laptop:~$ rr replay
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU 

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

[Guilhem Moulin]

On Tue, 09 Apr 2019 at 17:26:22 +0200, gregor herrmann wrote:
> On Tue, 09 Apr 2019 17:14:32 +0200, Guilhem Moulin wrote:
>> With TLS 1.3?  (You can pass ‘SSL_version => "TLSv1_3"’ to ssl_opts to
>> force this.)  Doesn't work here, still hangs on read():
> 
> Yes, also with using TLSv1_3 explicitly:
> […]
> (trace attached in case it helps)

AFAICT this worked this time because the socket was *only* marked as
ready for writing after the first select() call.  Only during the second
call was there some data to be read:

> select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 1 (out [3], left 
> {tv_sec=179, tv_usec=96})
> select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left 
> {tv_sec=179, tv_usec=977469})

I'm unable to reproduce this with v1.3, probably due to race conditions.
Anyway I fail to see how the patch can help, because as I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034#101 the socket
is in blocking mode (hence SSL_MODE_AUTO_RETRY is set) by the time LWP
starts its select loop, and SSL_MODE_AUTO_RETRY is set.  This is visible
by adding fcntl(2) to the traced set of system calls:

$ strace -etrace=fcntl,select,read perl -MLWP::UserAgent -MIO::Socket::SSL 
-e \
'$IO::Socket::SSL::DEBUG = 3;
 LWP::UserAgent->new(ssl_opts => {SSL_version => 
"TLSv1_3"})->post("https://facebook.com;, { data => "" })'
[…]
fcntl(3, F_GETFL)   = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0
DEBUG: .../IO/Socket/SSL.pm:831: set socket to non-blocking to enforce 
timeout=180
DEBUG: .../IO/Socket/SSL.pm:844: call Net::SSLeay::connect
read(3, 0x5628bec16923, 5)  = -1 EAGAIN (Resource temporarily 
unavailable)
DEBUG: .../IO/Socket/SSL.pm:847: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:857: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:867: waiting for fd to become ready: SSL wants 
a read first
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left 
{tv_sec=179, tv_usec=988296})
DEBUG: .../IO/Socket/SSL.pm:887: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:844: call Net::SSLeay::connect
[…]
DEBUG: .../IO/Socket/SSL.pm:847: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:902: ssl handshake done
fcntl(3, F_GETFL)   = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR)   = 0
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], 
left {tv_sec=179, tv_usec=98})
read(3, "…", 5)   = 5
read(3, "…", 156) = 156
read(3,

When the non-application record comes in, the socket is marked as ready
for reading, but SSL_read() transparently processes the non-application
data record, and blocks on trying to read an application data record.

If one is lucky and the socket is *only* marked as ready for writing (ie
not for reading as well, like in your trace) when select() returns then
the problem doesn't trigger (at least not right after the handshake —
OTOH it might occur later on renegotiation), but AFAICT it's orthogonal
to whether the patch is applied or not: we use blocking I/O, so
SSL_MODE_AUTO_RETRY is set just like before (`Net::SSLeay::set_mode($ssl,
$mode_auto_retry)` is called just before clearing O_NONBLOCK).

If the (blocking) socket is marked for reading when select() returns,
then the application assumes that SSL_read() won't block, and setting
SSL_MODE_AUTO_RETRY breaks that assumption, as written in the OpenSSL
changelog.  Instead of a blocking SSL_read() the application expects it
to return SSL_ERROR_WANT_READ.  And proceeds with SSL_write() if the
socket is also ready for writing, like in the trace above.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#926151: chromium: Youtube not working in latest testing version on recent intel hw

[Javier]

Package: chromium
Version: 73.0.3683.75-1
Followup-For: Bug #926151

I can confirm the bug. Meanwhile you can install h264ify extension from
chromium store to make youtube videos to work, but other sites may still not
work.



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

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

Versions of packages chromium depends on:
ii  chromium-common  73.0.3683.75-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.3.0-5
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.1-1
ii  libavformat587:4.1.1-1
ii  libavutil56  7:4.1.1-1
ii  libc62.28-8
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-5
ii  libdbus-1-3  1.12.12-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-5
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1
ii  libopenjp2-7 2.3.0-2
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.36-5
ii  libpulse012.2-4
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-5
ii  libva2   2.4.0-1
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  73.0.3683.75-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox 73.0.3683.75-1
ii  dunst [notification-daemon]  1.3.2-1
ii  fonts-liberation 1:1.07.4-9
ii  gnome-shell [notification-daemon]3.30.2-3
ii  libgl1-mesa-dri  18.3.4-2
ii  libu2f-udev  1.1.9-1
ii  notification-daemon  3.20.0-4
ii  upower   0.99.10-1
ii  xfce4-notifyd [notification-daemon]  0.4.3-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  8.3.0-5
ii  libc6   2.28-8
ii  libgcc1 1:8.3.0-5
ii  libstdc++6  8.3.0-5

-- no debconf information

Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed

[Ivo De Decker]

Control: severity -1 important

Hi Ana,

On Mon, Apr 08, 2019 at 04:50:31PM +0100, ana wrote:
> Thanks for the update on this. It would be a shame to drop the package
> entirely from Debian. Have had a look at the packaging on salsa and I'm
> happy to take over. I would need DM permissions on it to make uploads.

In that case, I'm lowering the severity to get it of the RC bug list. I'll
leave it up to you to close it (and close #926209 as well).

Ivo

Bug#926739: stretch-pu: package gpac/0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1

[Moritz Muehlenhoff]

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

Fixes a number of minor issues, same patches are also in unstable for a week.

Cheers,
Moritz

diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2016-08-04 
23:29:39.0 +0200
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2019-03-04 
23:37:26.0 +0100
@@ -1,3 +1,12 @@
+gpac (0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1) stretch; urgency=medium
+
+  * CVE-2018-7752 (Closes: #892526)
+  * CVE-2018-13005, CVE-2018-13006 (Closes: #902782)
+  * CVE-2018-20760, CVE-2018-20761, CVE-2018-20762, CVE-2018-20763
+(Closes: #921969)
+
+ -- Moritz Mühlenhoff   Mon, 04 Mar 2019 23:37:26 +0100
+
 gpac (0.5.2-426-gc5ad4e4+dfsg5-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
--- 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
1970-01-01 01:00:00.0 +0100
+++ 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
2019-03-04 23:13:09.0 +0100
@@ -0,0 +1,38 @@
+From bceb03fd2be95097a7b409ea59914f332fb6bc86 Mon Sep 17 00:00:00 2001
+From: Aurelien David 
+Date: Thu, 28 Jun 2018 13:34:08 +0200
+Subject: [PATCH] fixed 2 possible heap overflows (inc. #1088)
+
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/include/gpac/internal/isomedia_dev.h
 gpac-0.5.2-426-gc5ad4e4+dfsg5/include/gpac/internal/isomedia_dev.h
+@@ -2988,7 +2988,7 @@ GF_GenericSubtitleSample *gf_isom_parse_
+   char __ptype[5];\
+   strcpy(__ptype, gf_4cc_to_str(__parent->type) );\
+   GF_LOG(GF_LOG_WARNING, GF_LOG_CONTAINER, ("[iso file] extra box 
%s found in %s, deleting\n", gf_4cc_to_str(__abox->type), __ptype)); \
+-  gf_isom_box_del(a);\
++  gf_isom_box_del(__abox);\
+   return GF_OK;\
+   }
+ 
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/src/isomedia/box_code_base.c
 gpac-0.5.2-426-gc5ad4e4+dfsg5/src/isomedia/box_code_base.c
+@@ -619,7 +619,7 @@ GF_Err urn_Read(GF_Box *s, GF_BitStream
+ 
+   //then get the break
+   i = 0;
+-  while ( (tmpName[i] != 0) && (i < to_read) ) {
++  while ( (i < to_read) && (tmpName[i] != 0) ) {
+   i++;
+   }
+   //check the data is consistent
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/src/isomedia/box_dump.c
 gpac-0.5.2-426-gc5ad4e4+dfsg5/src/isomedia/box_dump.c
+@@ -988,7 +988,7 @@ GF_Err dpin_dump(GF_Box *a, FILE * trace
+ GF_Err hdlr_dump(GF_Box *a, FILE * trace)
+ {
+   GF_HandlerBox *p = (GF_HandlerBox *)a;
+-  if (p->nameUTF8 && (u32) p->nameUTF8[0] == strlen(p->nameUTF8+1)) {
++  if (p->nameUTF8 && (u32) p->nameUTF8[0] == strlen(p->nameUTF8)-1) {
+   fprintf(trace, "handlerType), p->nameUTF8+1);
+   } else {
+   fprintf(trace, "handlerType), p->nameUTF8);
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch   
1970-01-01 01:00:00.0 +0100
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch   
2019-03-04 23:13:47.0 +0100
@@ -0,0 +1,16 @@
+From 4c1360818fc8948e9307059fba4dc47ba8ad255d Mon Sep 17 00:00:00 2001
+From: Aurelien David 
+Date: Thu, 13 Dec 2018 14:39:21 +0100
+Subject: [PATCH] check error code on call to gf_utf8_wcstombs (#1177)
+
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/src/media_tools/text_import.c
 gpac-0.5.2-426-gc5ad4e4+dfsg5/src/media_tools/text_import.c
+@@ -259,6 +259,8 @@ char *gf_text_get_utf8_line(char *szLine
+   }
+   sptr = (u16 *)szLine;
+   i = (u32) gf_utf8_wcstombs(szLineConv, 1024, (const unsigned short **) 
);
++  if (i >= (u32)ARRAY_LENGTH(szLineConv))
++  return NULL;
+   szLineConv[i] = 0;
+   strcpy(szLine, szLineConv);
+   /*this is ugly indeed: since input is UTF16-LE, there are many chances 
the fgets never reads the \0 after a \n*/
diff -Nru 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
--- 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
1970-01-01 01:00:00.0 +0100
+++ 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
2019-03-04 23:14:31.0 +0100
@@ -0,0 +1,147 @@
+From 35ab4475a7df9b2a4bcab235e379c0c3ec543658 Mon Sep 17 00:00:00 2001
+From: Aurelien David 
+Date: Fri, 11 Jan 2019 11:32:54 +0100
+Subject: [PATCH] fix some overflows due to strcpy
+
+fixes #1184, #1186, #1187 among other things
+
+--- 

Bug#925489: marked as done (unblock: elogind/241.1-1+debian1)

[Adam Borowski]

On Mon, Apr 08, 2019 at 02:57:03PM +, Debian Bug Tracking System wrote:
> > I am aware that the debdiff against testing (239.3+20190131-1+debian1) is
> > significantly larger than you would normally want at this stage in the 
> > release
> > cycle. However, I believe it is warranted and ask for your consideration.
> 
> > The benefits of migration centre around this version of elogind providing 
> > ABI
> > compatibility between libelogind0 and libsystemd0 (see #923244). This means 
> > that
> > packages compiled against libsystemd-dev headers work correctly with either
> > libsystemd0 or libelogind0 runtime libraries. This is particularly 
> > important for
> > policykit-1 authorization of many desktop functions (particularly restart, 
> > halt,
> > suspend and for pkexec which is essential for synaptic) on non-systemd init
> > installations.

> This change is way to big to be unblocked.

I agree -- but this approach was what was requested for policykit-1.

What would you suggest instead?


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

Bug#926701: texlive-bin: FTBFS on hurd-i386

[Hilmar Preuße]

On 09.04.19 12:57, Norbert Preining wrote:
> On Tue, 09 Apr 2019, Hilmar Preuße wrote:

>> I suspect that an explicit link to lib dl (-ldl) is missing in the
>> linker statement.
> 
> Strange, and why didn't that show up back then. Thanks for reporting,
> but I have not too much ideas how to fix it ;-)
> 
The -ldl is missing in unstable too, so my first analysis is wrong. I'll
have a look at this later on. We have different linker flags in unstable
anyway.

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



signature.asc
Description: OpenPGP digital signature

Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry

[Bernhard Übelacker]

Hello Alf,
thanks for the fast response.
You can query to which package a shared object belongs by:

dpkg -S /usr/lib/x86_64-linux-gnu/libbellesip.so.0

That should show 'libbellesip0' I guess.

So, if package libbellesip0-dbgsym gets installed, another
retry should have all needed debug information to show
for each line of the backtrace debug information.

Kind regards,
Bernhard

Bug#926479: [Fwd: [Pkg-swan-devel] Bug#926479: Interesting ..]

[Paul Gevers]

Hi Christian,

On 09-04-2019 08:37, Christian Ehrhardt wrote:
> Odd for sure - at least for my local debian container tests it was a
> 100% hit rate.
> And in VMs it always worked (as does the Ubuntu CI that I linked)

Ubuntu uses VM's, Debian uses lxc. The difference is exactly
isolation-machine versus isolation-container. isolation-machine
restricts more.

> Furthermore there is a reason I never thought I'd need to add
> isolation-machine which is that it works well for Ubuntu on armhf which
> runs in LXD containers as well.

I never learned what LXD really is (it isn't in Debian).

>> But this change would be even acceptable for an unblock if it can happen
>> soon (without any other changes).
> 
> I wondered about that, but I see that it will make CI on the package
> for the lifetime of buster more helpful.

Indeed.

> Overall that would then look like this:
> diff --git a/debian/tests/control b/debian/tests/control
> index eb9e20463c..5b1ebf32c8 100644
> --- a/debian/tests/control> +++ b/debian/tests/control
> @@ -1,3 +1,7 @@
> -Tests: daemon admin-strongswan-charon admin-strongswan-starter plugins
> -Depends: strongswan, libstrongswan-standard-plugins,
> libstrongswan-extra-plugins, libcharon-extra-plugins, strongswan-pki,
> strongswan-scepclient
> +Tests: admin-strongswan-charon admin-strongswan-starter
> +Depends: strongswan, strongswan-pki, strongswan-scepclient
> Restrictions: needs-root isolation-container allow-stderr
> +
> +Tests: daemon plugins
> +Depends: strongswan-starter, libstrongswan-standard-plugins,
> libstrongswan-extra-plugins, libcharon-extra-plugins
> +Restrictions: needs-root isolation-machine allow-stderr

Ack (for the restrictions, not the depends).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#906589: inkscape: "Import Clip Art" is not working

[Mattia Rizzolo]

Control: forcemerge 926113 -1

On Tue, Apr 09, 2019 at 08:42:40PM +0200, Göran Weinholt wrote:
> I tried again and it still didn't work. I traced it through glibmm to
> glib and saw /usr/lib/x86_64-linux-gnu/gio/modules in strace. I looked
> at what files go there with apt-file and found gvfs. Installing gvfs
> almost fixed it; gvfs-backends was also needed. Now I can search for
> clipart.

mhpf.

> So maybe add Recommends: gvfs-backends? It added another 15MB to the
> disk usage for me.

this is annoying, and I should have noticed the similarity in the
message with #926113 ...

-- 
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#899128: kdepim: Limit CVE-2017-17689 (EFAIL) even more for kmail

[Ivo De Decker]

Hi,

On 04/09/2019 09:19 PM, Moritz Muehlenhoff wrote:


The tracker for CVE-2017-17689 doesn't list anything related to kdepim or
src:meta-kde for buster. Is the issue fixed in the binary kdepim (produced
by src:meta-kde) in buster? If so, that should probably be stated explicitly
in the tracker.


For buster the affected code is in src:kf5-messagelib and fixed in 4:18.08.1-1

In stretch the affected code is in src:kdepim

In Buster the binary package kdepim is now built out of src:meta-kde, but that
was never affected. That's we don't track src:meta-kde at all in
https://security-tracker.debian.org/tracker/CVE-2017-17689

Does that clarify?


Yes. I (incorrectly) assumed that the offending code had been in 
meta-kde in buster at some point. As that's not the case, there is 
nothing left to fix for buster.


Thanks for the clarification.

Ivo

Bug#926736: yad: Window icon is not displayed under Wayland

[Yvan Masson]

Package: yad
Version: 0.40.0-1
Severity: minor

Dear Maintainer,

Window icon is not found when using Wayland (wether you choose one with
--window-icon or not) but works perfectly under Xorg.

Fortunately upgrading to the last version would solve this, but I could
not find anything related in the changelog nor in the upstream issues.
Do not hesitate to ask if you want me to report this upstream.

Regards,
Yvan


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

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

Versions of packages yad depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6

yad recommends no packages.

yad suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#919929: python-scipy: autopkgtest fails intermittently

[Paul Gevers]

Hi Drew,

On Mon, 08 Apr 2019 17:52:02 +0800 Drew Parsons  wrote:
> CI testing isn't performed in buster, is it?  If it's important to get
> a clean buster CI test then those 2 tests could be switched off in
> python2 if desired.

Obviously we do *want* to use autopkgtest post release in buster as
well, i.e. for security updates and/or stable release updates. That is
why we have been unblocking autopkgtest only fixes during this freeze.
The infrastructure isn't fully implemented yet, but there are no
blockers to do that when the time comes. So yes fixing this for buster
is desirable if not too much effort.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#518750: pommed: cannot mmap memory for GMA950/GMA965

[Guillem Jover]

Control: reassign -1 pommed

Hi!

On Mon, 2009-04-13 at 20:40:13 +0200, Martin Mares wrote:
> > This bug is not present in version 3.0.3 (Lenny), it's in 3.1.2 as
> > explained above by Julien.
> 
> This is not a bug in libpci, but rather a deficiency in its documentation
> leading to improper usage in certain applications.
> 
> The pci_dev->base_addr[] array was always intended to contain the BAR
> values including the flags in lower bits and it behaved that way for
> a long time, except for the sysfs back-end which was setting them
> improperly. This bug was however fixed in pciutils-3.1.0
> (commit 6d143c3283855c474445a3cf27c65280ed7ab1b7), exposing the
> problem in applications to a much larger audience.
> 
> I have added a note to the declaration in lib/pci.h explaining
> the proper semantics.

So this is really an issue in pommed, as per the pciutils upstream
developer's comment above. Reassigning back.

Thanks,
Guillem

Bug#926732: djview4: problems with URLs

[Janusz S. Bień]

Package: djview4
Version: 4.11-1
Severity: important

Dear maintainer,

I will report the bug also upstream, but want to provide the details of
my system.

The problems actually seem to be caused by a library, as they were
inherited by our December version of djview4poliqarp, although noticed
only just now.

The problems manifestation is that the page parameter doesn't seem to
work, e.g.

http://rcin.org.pl/Content/5994/KRIJP_20296_03030430_bdelion-bezksztalt.djvu?=88,1555,470,126=1
http://rcin.org.pl/Content/5994/KRIJP_20296_03030430_bdelion-bezksztalt.djvu?=88,1555,470,126=2
http://rcin.org.pl/Content/5994/KRIJP_20296_03030430_bdelion-bezksztalt.djvu?highlight=34,1529,361,137=3

display the same page.

Trying to prepare more test data I noticed that "Copy URL" almost always don't
work. I used to paste it with C-v, but now it yields nothing (the
underlying text is however still copied and can be pasted with the
middle mouse button). Once when it worked the URL was not correct as it
contained redundant elements.

I mark the bug as important as some of us plan to work intensively with
the DjVu URLs soon.


Best regards

Janusz


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

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

Versions of packages djview4 depends on:
ii  libc62.28-8
ii  libdjvulibre21   3.5.27.1-10
ii  libgcc1  1:8.3.0-5
ii  libgl1   1.1.0-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5opengl55.11.3+dfsg1-1
ii  libqt5printsupport5  5.11.3+dfsg1-1
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-5
ii  libtiff5 4.0.10-4
ii  sensible-utils   0.0.12

Versions of packages djview4 recommends:
ii  djvulibre-desktop  3.5.27.1-10

Versions of packages djview4 suggests:
ii  djview-plugin  4.11-1
ii  djvulibre-bin  3.5.27.1-10

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed

[Scott Kitterman]

On Monday, April 08, 2019 04:50:31 PM ana wrote:
> Thanks for the update on this. It would be a shame to drop the package
> entirely from Debian. Have had a look at the packaging on salsa and I'm
> happy to take over. I would need DM permissions on it to make uploads.

OK.  Please add yourself to uploaders on salsa and close the rm bug (you can 
close this one too).

I'll want to sponsor at least one upload before I give DM permissions.  When 
you have something that needs uploading, feel free to ping me.

Also, you may want to take an interest in prompt-toolkit.  It's one of python-
softlayer's major dependencies.  It has one other DM uploader (I've dropped 
myself from that one too), but it's worth keeping an eye on to make sure it 
and python-softlayer stay compatible.

Scott K

Bug#926735: Include upstream patch for extended partition size

[Kai Lüke]

Package: libparted2
Version: 3.2-24
src:parted

Please include upstream commit c6dc6e5d from 2015 as additional package
patch because it fixes the unit of the partition resize ioctl.
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=c6dc6e5d0f49a26242d2b28622514814a53d92e1

Currently the extended partitions will be inaccessible until some
program forces the kernel to reread the partition table. See related issues:
https://github.com/storaged-project/udisks/issues/425
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1641308

Bug#906589: inkscape: "Import Clip Art" is not working

[Göran Weinholt]

Mattia Rizzolo  writes:

> Control: tag -1 moreinfo unreproducible
>
> On Tue, Sep 18, 2018 at 11:59:28AM +0200, Mattia Rizzolo wrote:
>> On Sat, Aug 18, 2018 at 03:37:42PM +0200, Göran Weinholt wrote:
>> > The "Import Clip Art" function in the File menu is not working. The
>> > dialog shows an error: "Could not connect to the Open Clip Art
>> > Library". The terminal logs an error:
>> > 
>> > ** (inkscape:12723): WARNING **: 15:35:06.393: 
>> > ImportDialog::on_xml_file_read():
>> >Failed to retrieve 'http://openclipart.org/media/feed/rss/some string'
>> >Operation not supported
>> 
>> Forwarded, see above.
>
> I just tried again, and I couldn't reproduce this error anymore.  Like
> upstream, I'm blaming something on gtkmm or glib, although I'm not sure
> on what.
>
> Could you please try again?

I tried again and it still didn't work. I traced it through glibmm to
glib and saw /usr/lib/x86_64-linux-gnu/gio/modules in strace. I looked
at what files go there with apt-file and found gvfs. Installing gvfs
almost fixed it; gvfs-backends was also needed. Now I can search for
clipart.

So maybe add Recommends: gvfs-backends? It added another 15MB to the
disk usage for me.

Regards,

-- 
Göran Weinholt
https://weinholt.se/

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[adrian15]

El 08/04/19 a las 21:29, Matthijs Kooijman escribió:
> Hi Luca & others,
> 
> I've been working on syslinux-efi support in the past weeks and just
> submitted a MR with a working implementation, along with some small
> bootloader-related cleanups and refactors:
> 
>   https://salsa.debian.org/live-team/live-build/merge_requests/19

1) What is the rationale behind removing the --templates option
explanation on manpage?

Do you remove it in any of your commits? Which one?
Or someone else did remove it?

Thank you.

Note: I will make more comments about this bug later in the week.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#926742: netdata: /etc/netdata/edit-config looks for config files in the wrong place

[Nye Liu]

Package: netdata
Version: 1.12.2-2
Severity: normal

$ sudo /etc/netdata/edit-config tcp_listen.conf
File 'tcp_listen.conf' is not found in '/usr/local/lib/netdata/conf.d'

Config files are in /usr/lib/netdata when using debian.

-- debconf information excluded

Bug#926746: libbluray: ftbfs during arch:all only build

[Andreas Beckmann]

Source: libbluray
Version: 1:1.1.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

libbluray/experimental FTBFS during the arch:all only build:

https://buildd.debian.org/status/fetch.php?pkg=libbluray=all=1%3A1.1.1-1=1554567686=0

 fakeroot debian/rules binary-indep
dh binary-indep --with javahelper
   dh_testroot -i
   dh_prep -i
   dh_install -i
dh_install: Cannot find (any matches for) "usr/share/java" (tried in ., 
debian/tmp)

dh_install: libbluray-bdj missing files: usr/share/java
dh_install: missing files, aborting
make: *** [debian/rules:21: binary-indep] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


Andreas

Bug#926740: bugs.debian.org: Subscription confirmation reply-to address length exceeds RFC-5321 limit

[Don Armstrong]

On Tue, 09 Apr 2019, Nazar Zhuk wrote:
> I subscribed to a bug (924787) and received a confirmation email asking
> me to confirm the subscription by emailing to
> 924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org
> 
> My smpt server (mailfence) rejects an email to this address with a
> message:
> 
> ---
> The recipient address
> <924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org>
> is not a valid RFC-5321 address..

Hrm; yep, that looks like a bug.

Thanks for the report!

-- 
Don Armstrong  https://www.donarmstrong.com

What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

Bug#926751: gcc-riscv64-linux-gnu: Doesn't work with all valid abi combinations.

[peterc]

Package: gcc-riscv64-linux-gnu
Version: 4:8.3.0-2
Severity: normal

Dear Maintainer,


My RISC V64 implementation doesn't have floating point, so I'm trying
to compile with
 -march=rv64imac -mabi=lp64

I see:
$  riscv64-linux-gnu-gcc -mabi=lp64 -march=rv64imac x.c
In file included from /usr/riscv64-linux-gnu/include/features.h:448,
 from /usr/riscv64-linux-gnu/include/bits/libc-header-start.h:3,
 from /usr/riscv64-linux-gnu/include/stdio.h:27,
 from x.c:1:
/usr/riscv64-linux-gnu/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-lp64.h: 
No such file or directory
 # include 
 compilation terminated.

for a simple hello world program.

It looks as if only march=rv64imafdc/mabi=lp64d is supported; please
can the other valid combinations be supported as well?

The current list is:

march=rv32i/mabi=ilp32
march=rv32im/mabi=ilp32
march=rv32iac/mabi=ilp32
march=rv32imac/mabi=ilp32
march=rv32imafc/mabi=ilp32f
march=rv64imac/mabi=lp64
march=rv64imafdc/mabi=lp64d

Peter C

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel, i386, powerpc, arm64, riscv64

Kernel: Linux 5.0.0-rc4-1-g4aa9fc2a435a (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-riscv64-linux-gnu depends on:
ii  cpp-riscv64-linux-gnu4:8.3.0-2
ii  gcc-8-riscv64-linux-gnu  8.3.0-4cross2

Versions of packages gcc-riscv64-linux-gnu recommends:
ii  libc6-dev-riscv64-cross [libc-dev-riscv64-cross]  2.28-7cross1

Versions of packages gcc-riscv64-linux-gnu suggests:
ii  autoconf   2.69-11
ii  automake   1:1.16.1-4
ii  bison  2:3.3.2.dfsg-1
ii  flex   2.6.4-6.2
ii  gcc-doc5:7.2.0-2
pn  gdb-riscv64-linux-gnu  
ii  libtool2.4.6-10
ii  make   4.2.1-1.2
ii  manpages-dev   4.16-1

-- no debconf information

Bug#926701: texlive-bin: FTBFS on hurd-i386

[Norbert Preining]

Hi HIlmar,

> The -ldl is missing in unstable too, so my first analysis is wrong. I'll
> have a look at this later on. We have different linker flags in unstable


Hmm, there aren't that many changes from unstable to current
experimental (from the texlive-source git mirror repo 
$ git log 408ab1ec3b4e6f143d26a4c9855106a619ff31c2..HEAD texk/dvisvgm/
commit edb2e98bfce1f4733eaa2b77aaa6d79052494926
Author: Karl Berry 
Date:   Tue Mar 26 22:32:47 2019 +

ZLIB_INCLUDES in AM_CFLAGS for ff-woff

git-svn-id: svn://tug.org/texlive/trunk/Build/source@50610 
c570f23f-e606-0410-a88d-b1316a301751

commit 0e0d51fcc99be7296ff91ede9f9e98908c8dfb84
Author: Karl Berry 
Date:   Mon Mar 25 17:27:50 2019 +

try pkg-config if freetype-config not available

git-svn-id: svn://tug.org/texlive/trunk/Build/source@50584 
c570f23f-e606-0410-a88d-b1316a301751

commit f6a7573dfbc2df4e34fce07c02ff21eedbaf7a8e
Author: Karl Berry 
Date:   Sun Mar 10 18:21:29 2019 +

dvisvgm 2.6.3

git-svn-id: svn://tug.org/texlive/trunk/Build/source@50315 
c570f23f-e606-0410-a88d-b1316a301751

commit 1400b7b5d6dd9974a7531cf0dcd9ec1ce0fa5694
Author: Karl Berry 
Date:   Mon Feb 25 19:13:14 2019 +

(CXXFLAGS): WARNING_CXXFLAGS and no no-mismatched-tags

git-svn-id: svn://tug.org/texlive/trunk/Build/source@50126 
c570f23f-e606-0410-a88d-b1316a301751

commit 89adfe5d34c658b678f2ec40053544661a5c5033
Author: Karl Berry 
Date:   Sun Feb 10 23:22:35 2019 +

mingw cross-compilation fixes from lscarso

git-svn-id: svn://tug.org/texlive/trunk/Build/source@49996 
c570f23f-e606-0410-a88d-b1316a301751

commit b637e295e376a0bc63baaf7501de12afc8ad86db
Author: Karl Berry 
Date:   Thu Jan 31 18:21:25 2019 +

install dvisvgm.1

git-svn-id: svn://tug.org/texlive/trunk/Build/source@49882 
c570f23f-e606-0410-a88d-b1316a301751

commit d3bbca9ba34731ee397f88b9b29e3f25f7384b4b
Author: Karl Berry 
Date:   Fri Jan 25 23:20:32 2019 +

dvisvgm 2.6.2

git-svn-id: svn://tug.org/texlive/trunk/Build/source@49819 
c570f23f-e606-0410-a88d-b1316a301751

commit 71b5b1e035db20be06aedf330204960ee4d3268a
Author: Karl Berry 
Date:   Mon Dec 24 23:22:06 2018 +

reautoconf

git-svn-id: svn://tug.org/texlive/trunk/Build/source@49496 
c570f23f-e606-0410-a88d-b1316a301751


Also looking at the actual diff, not much is jumping at me ...
The check of dlopen is still included in the .ac file.

Surely, we can simply add the -ld somewhere, but I would like to
understand why ...

Best

Norbert

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

Bug#926752: pyspf-milter: Configuration file not install, default config uses /usr/local

[Scott Kitterman]

Package: pyspf-milter
Version: 2.9.0-2
Severity: serious
Justification: causes non-serious data loss

Sigh,

As packaged, no configuration file is installed and on startup it attempts to
read the configuration from /usr/local/etc instead of /etc.  This was masked
by leftover /usr/local bits I had from pre-Debian upload development.

This isn't hard to fix, but it should definitely be fixed for Buster.  I will
upload a fix shortly.

Scott K

Bug#926760: install-info: GZIP environment variable warnings on buster

[Scott Kitterman]

Package: install-info
Version: 6.5.0.dfsg.1-4
Severity: normal

Saw this in the apt term log from a Stretch -> Buster upgrade today:

Setting up libxmlrpc-lite-perl (0.717-2) ...^M
Processing triggers for sgml-base (1.29) ...^M
Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M

I checked and libxmlrpc-lite-perl doesn't make reference to a GZIP environment
variable.  texinfo does.

Not urgent, but looks like something that should be addressed in the next
cycle.

Scott K

Bug#882324: fixed in amavisd-new 1:2.11.0-6.1

[Brian May]

On 2019-04-10 09:32, MK wrote:

Any chance of having this pushed into debian-release for buster via an unblock request? 
This seems important to anyone running a mail server with amavis in buster.


I believe it was unblocked already:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926580 


It is only 2 days old however, needs to be 5 days:
https://tracker.debian.org/pkg/amavisd-new

Bug#924291: closed by Markus Koschany (Bug#924291: fixed in netrek-client-cow 3.3.1-3)

[Helmut Grohne]

Control: reopen -1

Hi Markus,

On Sun, Mar 24, 2019 at 01:09:06PM +, Debian Bug Tracking System wrote:
>* Fix infinite loop patch. Really (Closes: #924291)

As much as I hate to say this, it still loops. You can see failing
(cross) builds at http://crossqa.debian.net/src/netrek-client-cow. All
of them were terminated by manual intervention.

Remember: I'm not asking for netrek-client-cow to cross build. I'm
asking for it to fail sanely.

The current version loops like this:

| /bin/sh: 1: ./mkkey: Exec format error
| /bin/sh: 1: attempts: not found
| /bin/sh: 1: test: -le: unexpected operator

My initial report asked for what this key is being used for. It still
seems strange to me to generate a key at build time and the distribute
it to many users. Could you provide an initial answer on the purpose of
this thing?

It feels a little strange to invest a longer thread into something that
should not be there (in my book). Would it be ok to pursue that question
first?

Helmut

Bug#926755: unblock: spf-engine/2.9.0-3

[Scott Kitterman]

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

Please unblock package spf-engine

The pyspf-milter binary is not configurable as currently in Buster.  Due to
doing upstream development and package testing on the same machine, I failed
to notice that, as packaged for Debian, no configuration file is installed and
it looks in /usr/local/etc for a configuration file.  Sigh.

There's no chance of regression with the fix.  The defaults in the now
provided config file (in /etc/pyspf-milter) are the same as the defaults
used internally by the milter if no configuration file is found.

I've tested upgrade from the broken version and fresh installs.  It's a new
binary for Buster, so there's no Stretch -> Buster upgrade path to test.

Scott K

unblock spf-engine/2.9.0-3
diff -Nru spf-engine-2.9.0/debian/changelog spf-engine-2.9.0/debian/changelog
--- spf-engine-2.9.0/debian/changelog	2019-02-05 19:06:03.0 -0500
+++ spf-engine-2.9.0/debian/changelog	2019-04-10 01:10:00.0 -0400
@@ -1,3 +1,10 @@
+spf-engine (2.9.0-3) unstable; urgency=medium
+
+  * Install pyspf-milter config file in /etc/pyspf-milter/pyspf-milter.conf
+and update the service file so it is used (Closes: #926752)
+
+ -- Scott Kitterman   Wed, 10 Apr 2019 00:28:09 -0400
+
 spf-engine (2.9.0-2) unstable; urgency=high
 
   * Add Breaks/Replaces for python3-spf-engine to fix upgrade issues (Closes:
diff -Nru spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch
--- spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch	2019-02-01 20:26:21.0 -0500
+++ spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch	2019-04-10 00:27:13.0 -0400
@@ -134,7 +134,7 @@
  Type=simple
  PIDFile=/var/run/pyspf-milter/pyspf-milter.pid
 -ExecStart=/usr/local/bin/pyspf-milter /usr/local/etc/pyspf-milter.conf 
-+ExecStart=/usr/bin/pyspf-milter 
++ExecStart=/usr/bin/pyspf-milter /etc/pyspf-milter/pyspf-milter.conf
  
  [Install]
  WantedBy=multi-user.target
diff -Nru spf-engine-2.9.0/debian/pyspf-milter.conf spf-engine-2.9.0/debian/pyspf-milter.conf
--- spf-engine-2.9.0/debian/pyspf-milter.conf	1969-12-31 19:00:00.0 -0500
+++ spf-engine-2.9.0/debian/pyspf-milter.conf	2019-04-10 01:09:32.0 -0400
@@ -0,0 +1,19 @@
+#  For a fully commented sample config file see policyd-spf.conf.commented
+
+debugLevel = 1 
+TestOnly = 1
+
+HELO_reject = Fail
+Mail_From_reject = Fail
+
+PermError_reject = False
+TempError_Defer = False
+
+skip_addresses = 127.0.0.0/8,:::127.0.0.0/104,::1
+
+# Milter specific options
+Socket = local:/run/pyspf-milter/pyspf-milter.sock
+PidFile = /run/pyspf-milter/pyspf-milter.pid
+UserID = pyspf-milter
+InternalHosts = 127.0.0.1
+#MacroListVerify =
diff -Nru spf-engine-2.9.0/debian/pyspf-milter.install spf-engine-2.9.0/debian/pyspf-milter.install
--- spf-engine-2.9.0/debian/pyspf-milter.install	2019-02-01 20:43:29.0 -0500
+++ spf-engine-2.9.0/debian/pyspf-milter.install	2019-04-10 00:27:41.0 -0400
@@ -1,3 +1,4 @@
 system/pyspf-milter etc/init.d/
 system/pyspf-milter.service lib/systemd/system/
+debian/pyspf-milter.conf etc/pyspf-milter
 build/usr/bin/pyspf-milter /usr/bin

Bug#926756: clamav-freshclam: GZIP environment variable warnings on buster

[Scott Kitterman]

Package: clamav-freshclam
Version: 0.100.2-1
Severity: normal

Stretch -> Buster upgrade today:

Setting up clamav-freshclam (0.101.2+dfsg-1) ...^M
Installing new version of config file /etc/apparmor.d/usr.bin.freshclam ...^M
Installing new version of config file 
/etc/network/if-down.d/clamav-freshclam-ifupdown ...^M
Installing new version of config file 
/etc/network/if-up.d/clamav-freshclam-ifupdown ...^M
Installing new version of config file 
/etc/ppp/ip-down.d/clamav-freshclam-ifupdown ...^M
Installing new version of config file 
/etc/ppp/ip-up.d/clamav-freshclam-ifupdown ...^M
gzip: warning: GZIP environment variable is deprecated; use an alias or script^M
Replacing config file /etc/logrotate.d/clamav-freshclam with new version^M

Not critical, but something worth looking into.

Scott K

Bug#926728: Removing the package breaks the alternative on usr-merge system

[Laurent Bigonville]

Le 9/04/19 à 18:58, Arturo Borrero Gonzalez a écrit :

On 4/9/19 6:34 PM, Laurent Bigonville wrote:

Package: ebtables
Version: 2.0.10.4+snapshot20181205-2
Severity: serious

Hello,

On system with usr-merge, removing ebtables breaks the alternative.

The postinst script install symlinks from /sbin to /usr/sbin, in the
prerm script these symlinks are removed. BUT ebtables also add itself as
an alternative for ebtables implementations.

That means that the symlinks installed by update-alternatives are
rm when the package is removed.

Not too sure how to fix this, maybe the prerm script should check if the
symlinks directly point to a real file and only remove them in that
case?


Thanks for the report!

I don't use usr-merge, so it would be great if you can provide concrete examples
of which files and which symlinks are affected by the bug you are describing,
and what would be the right state after package removal for them.


On a usr-merge system, /sbin is a symlink pointing to /usr/sbin. The 
alternative symlinks are installed in (/usr)/sbin.


In the postinst you have:

# compat symlinks for /sbin -> /usr/sbin move, to be dropped in buster+1
LIST="/sbin/ebtables /sbin/ebtables-save /sbin/ebtables-restore"

for i in $LIST ; do
if [ ! -e "$i" ] ; then
ln -sf /usr$i $i
fi
done

On a usr-merge system, this will rightfully do nothing as 
/sbin/ebtables* are already existing, so that's OK


OTOH, in the prerm you have:

LIST="ebtables ebtables-save ebtables-restore"
for i in $LIST ; do
if [ -L "/sbin/$i" ] ; then
rm /sbin/$i
fi
done

On a non-usr-merge system, the symlinks in /sbin and the symlinks (from 
the alternative system) in /usr/sbin are different. On a usr-merge 
system, they are not. That means that you end up removing the symlinks 
from the alternative system and not the one you have (supposedly) created.


AFAICS, this also impacts arptables package.

Note that usr-merge is now the default on all new debian installation.

Bug#926748: cargo: Cargo is too old

[Jeffrey Walton]

Package: cargo
Version: 0.15.0~dev-1+rpi1
Severity: normal

Dear Maintainer,

I am working on a RaspberryPi 3B+ running Raspian. I have a Python program that 
fills out a multi-page webform. To do so, I need Firefox, Selenium, WebDriver 
and geckodriver. Python-Selenium odes the heavy lifting through WebDriver.

Debian and Raspbian do not provide geckodriver so I have to build it from 
sources. That means I need Cargo and Rust.

Attempting to build geckodriver results in a lot of errors. Cf., 
https://github.com/rust-lang/cargo/issues/6836. According to the Cargo folks 
Debian's Cargo is too old.

Please consider providing a more modern Cargo.

In the system info below, Raspbian is fully patched. There is nothing to 
install or update.

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

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

Versions of packages cargo depends on:
ii  binutils2.28-5
ii  gcc [c-compiler]4:6.3.0-4
ii  gcc-6 [c-compiler]  6.3.0-18+rpi1+deb9u1
ii  libc6   2.24-11+deb9u4
ii  libcurl3-gnutls 7.52.1-5+deb9u9
ii  libgcc1 1:6.3.0-18+rpi1+deb9u1
ii  libhttp-parser2.1   2.1-2
ii  libssh2-1   1.7.0-1
ii  libssl1.0.2 1.0.2r-1~deb9u1
ii  rustc   1.24.1+dfsg1-1~deb9u2+rpi1
ii  zlib1g  1:1.2.8.dfsg-5

cargo recommends no packages.

Versions of packages cargo suggests:
pn  cargo-doc  

-- no debconf information

Bug#926750: inetutils-ping: ping --interval documentation (--help and manpage) are not correct

[Witold Baryluk]

Package: inetutils-ping
Version: 2:1.9.4-7
Severity: normal

Dear Maintainer,

ping and ping6 from this packages say in their --help:

  -i, --interval=NUMBER  wait NUMBER seconds between sending each packet

and ping6(1) manpage:

   -i, --interval=number
  Wait number seconds between sending each packet.

and ping(1) manpage:

 -i, --interval wait
 Wait wait seconds between sending each packet.  The default is to 
wait for one second between each packet.
 This option is incompatible with the -f option.


Ignoring for a moment inconsistent style of documenation, I think the
wait is actually in milliseconds.

# time ping6 --numeric --interval=1000 --count=3 google.com
PING google.com (2a00:1450:400a:803::200e): 56 data bytes
64 bytes from 2a00:1450:400a:803::200e: icmp_seq=0 ttl=55 time=0.943 ms
64 bytes from 2a00:1450:400a:803::200e: icmp_seq=1 ttl=55 time=0.751 ms
64 bytes from 2a00:1450:400a:803::200e: icmp_seq=2 ttl=55 time=0.791 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.751/0.828/0.943/0.083 ms

real0m2.006s
user0m0.002s
sys 0m0.000s
#


That is good and useful for subsecond pings counts, but documentation and
--help text seems not accurate. It is also worth nothing that it must be
an integer number of miliseconds, i.e. 0.5 will not work.

Also doing --interval=0 sends pings very quickly, which is almost
equivalent to -f, which is disabled for non users. IMHO, interval smaller
than 50ms should be protected by the same mechanism probably. Not that it
is a "real protection" (because one can just spawn 1000 of processes to
do it anyway), but I guess consistency would be useful :)




Thanks! :)



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

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

Versions of packages inetutils-ping depends on:
ii  libc6 2.28-8
ii  libidn11  1.33-2.2
ii  netbase   5.5

inetutils-ping recommends no packages.

inetutils-ping suggests no packages.

-- no debconf information

Bug#926753: fonts-noto-cjk: New version available upstream

[Kess Vargavind]

Package: fonts-noto-cjk
Version: 1:20170601+repack1-2
Severity: normal

Hello,

Noto Sans CJK version 2.001 was released yesterday.

It contains a number of fixes, and the release is timed to the Unicode 12.1
addition of U+32FF (㋿), the ligature of the new Japanese era (令和).

Kindly,
Kess



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

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

fonts-noto-cjk depends on no packages.

fonts-noto-cjk recommends no packages.

Versions of packages fonts-noto-cjk suggests:
ii  fonts-noto-cjk-extra  1:20170601+repack1-3

-- no debconf information

Bug#926754: RFP: node-evacuated-eol -- end of line api

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-evacuated-eol
  Version : 0.9.1
  Upstream Author : Ryan Van Etten
* URL : https://salsa.debian.org/themusicgod1-guest/evacuated-eol/
* License : MIT
  Programming Lang: javascript
  Description : end of line api 

Newline character converter API for javascript
Makes using endlines across platforms easier to handle.

eol is a prerequisite for node-ecstatic ( #910614 ).

Bug#926759: RFP: evacuated-property-accessors -- A mixin for declaring property accessors

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: evacuated-property-accessors
  Version : 1.1.3
  Upstream Author : Nathan Sobo
* URL : 
https://salsa.debian.org/themusicgod1-guest/evacuated-property-accessors/
* License : Expat
  Programming Lang: javascript
  Description : A mixin for declaring property accessors

(fork of property-accessors with a different upstream repo)

A mixin for defining dynamic properties.

property-accessors is a prerequisite of meteor ( #842425 )

Bug#926757: sbuild doesn't use installed keys for archive verification

[peterc]

Package: sbuild
Version: 0.78.1-2
Severity: normal

Dear Maintainer,

I'm trying to build a chroot for riscv64.

I've done
 sudo apt-get install debian-ports-archive-keyring
 sudo sbuild-createchroot --include=eatmydata,ccache,gnupg \
  --arch=riscv64 \
  sid /usr/home/sid-riscv64-sbuild \
  http://deb.debian.org/debian-ports/

and see:
Failed to fetch http://deb.debian.org/debian-ports/dists/sid/InRelease  The 
following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY DA1B2CEA81DCBC61


To fix I had to do:
 sudo gpg --no-default-keyring --keyring 
/usr/share/keyrings/debian-archive-keyring.gpg --import 
/etc/apt/trusted.gpg.d/debian-ports-archive-2019.gpg 

Looks like when sbuild invokes apt-get it's not using the right
mechanism for finding keys.

Peter C
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel, i386, powerpc, arm64, riscv64

Kernel: Linux 5.0.0-rc4-1-g4aa9fc2a435a (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.78.1-2
ii  perl5.28.1-6

Versions of packages sbuild recommends:
ii  autopkgtest  5.10
ii  debootstrap  1.0.114
ii  schroot  1.6.10-6+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.45.0-1
ii  kmod   26-1
ii  wget   1.20.1-1

-- no debconf information

Bug#855856: MR on freedesktop

[Kevin Lyda]

Apparently there's activity on this here? I got a MR in earlier this week.

https://gitlab.freedesktop.org/xorg/app/xbiff

Bug#926745: RFP: golang-salsa-themusicgod1-guest-go-duktape-dev -- Duktape JavaScript engine bindings for Go

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: golang-salsa-themusicgod1-guest-go-duktape-dev
  Version : v3
  Upstream Author : Oleg Lebedev
* URL : 
https://salsa.debian.org/themusicgod1-guest/golang-salsa-themusicgod1-guest-go-duktape-dev
* License : expat
  Programming Lang: go
  Description : Duktape JavaScript engine bindings for Go

Go bindings for Duktape, evacuated/forked from NSA/Microsoft github.

Duktape is a thin, embeddable javascript engine. 

Most of the Duktape api is implemented. 

"no need to install any external C libraries."

Bug#926747: unblock: adacontrol/1.20r7-2

[Nicolas Boulenguez]

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

Please unblock package adacontrol.

Two post-build tests have started to fail recently, causing a
"serious" bug (FTBFS).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924835

Investigation requires too much time for a freeze period.
Instead, version 1.20r7-2 skips post-build tests.
The trivial diff with 1.20r7-1 in testing follows.

The package now builds correctly in unstable.
#924835 is not closed, but it severity becomes "minor".

unblock adacontrol/1.20r7-2

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+adacontrol (1.20r7-2) unstable; urgency=medium
+
+  * Disable tests, lowering the severity of #924835.
+
+ -- Nicolas Boulenguez   Thu, 04 Apr 2019 21:13:55 +0200
+
 adacontrol (1.20r7-1) unstable; urgency=medium
 
   * New upstream release.
--- a/debian/rules
+++ b/debian/rules
@@ -54,7 +54,10 @@
 
 override_dh_auto_test-arch:
   ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
-   cd test && sh run.sh
+# Disable build-time tests so that the severity of #924835 can be
+# lowered and the package accepted into buster.  An actual fix
+# requires a bit more time and probably a longer diff.
+#  cd test && sh run.sh
   endif
 override_dh_auto_clean::
rm -fr test/res

Bug#925411: kernel-package: Not suitable for release

[Ben Hutchings]

On Mon, 2019-04-08 at 00:20 -0400, Nicholas D Steeves wrote:
[...]
> Ah, yes, thank you! :-)  Regarding documentation, should
> Debian-specific bits go on our wiki or be forwarded upstream?

The bindeb-pkg target is part of the upstream build system, not
something patched in by Debian, so the primary place to document it
should be upstream.

[...]
> Should users who track a 4.19.x-based branch use buster's
> linux-libc-dev headers, or install the ones that correspond to their
> custom kernel?
[...]

No, the only reason to install a custom linux-libc-dev package would be
to provide definitions for new UAPI added in a new kernel version.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.




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

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Akira TAGOH]

On Wed, Apr 10, 2019 at 12:00 AM Alexander Larsson
 wrote:
>
> On Tue, Apr 9, 2019 at 4:57 PM Alexander Larsson
>  wrote:
> >
> > On Thu, Apr 4, 2019 at 1:09 PM Akira TAGOH  wrote:
> > >
> > > Yes. done. hope that works well.
> >
> > Yes, this now seems to work well. I think this is good to go!
>
> Oh, and once this lands, any chance we could have a minimal backport
> of the changes to fontconfig 2.13.1 for the LTS flatpak runtimes?

Thanks for testing. for minimal backport, let me figure it out and
apply for Fedora updates. you can pull it in from there.

-- 
Akira TAGOH

Bug#926751: gcc-riscv64-linux-gnu: Doesn't work with all valid abi combinations.

[Matthias Klose]

Control: reassign -1 src:glibc

these are glibc headers.

On 10.04.19 04:05, peterc wrote:
> Package: gcc-riscv64-linux-gnu
> Version: 4:8.3.0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> My RISC V64 implementation doesn't have floating point, so I'm trying
> to compile with
>  -march=rv64imac -mabi=lp64
> 
> I see:
> $  riscv64-linux-gnu-gcc -mabi=lp64 -march=rv64imac x.c
> In file included from /usr/riscv64-linux-gnu/include/features.h:448,
>  from 
> /usr/riscv64-linux-gnu/include/bits/libc-header-start.h:3,
>  from /usr/riscv64-linux-gnu/include/stdio.h:27,
>  from x.c:1:
> /usr/riscv64-linux-gnu/include/gnu/stubs.h:8:11: fatal error: 
> gnu/stubs-lp64.h: No such file or directory
>  # include 
>  compilation terminated.
> 
> for a simple hello world program.
> 
> It looks as if only march=rv64imafdc/mabi=lp64d is supported; please
> can the other valid combinations be supported as well?
> 
> The current list is:
> 
> march=rv32i/mabi=ilp32
> march=rv32im/mabi=ilp32
> march=rv32iac/mabi=ilp32
> march=rv32imac/mabi=ilp32
> march=rv32imafc/mabi=ilp32f
> march=rv64imac/mabi=lp64
> march=rv64imafdc/mabi=lp64d
> 
> Peter C
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
> 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: armhf, armel, i386, powerpc, arm64, riscv64
> 
> Kernel: Linux 5.0.0-rc4-1-g4aa9fc2a435a (SMP w/8 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
> LANGUAGE=en_AU:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages gcc-riscv64-linux-gnu depends on:
> ii  cpp-riscv64-linux-gnu4:8.3.0-2
> ii  gcc-8-riscv64-linux-gnu  8.3.0-4cross2
> 
> Versions of packages gcc-riscv64-linux-gnu recommends:
> ii  libc6-dev-riscv64-cross [libc-dev-riscv64-cross]  2.28-7cross1
> 
> Versions of packages gcc-riscv64-linux-gnu suggests:
> ii  autoconf   2.69-11
> ii  automake   1:1.16.1-4
> ii  bison  2:3.3.2.dfsg-1
> ii  flex   2.6.4-6.2
> ii  gcc-doc5:7.2.0-2
> pn  gdb-riscv64-linux-gnu  
> ii  libtool2.4.6-10
> ii  make   4.2.1-1.2
> ii  manpages-dev   4.16-1
> 
> -- no debconf information
> 

Bug#926749: fprintd: stores user fingerprints as a standard template without encryption

[Seong-Joong Kim]

Package: fprintd
Version: 0.7.0-1
Severity: important

Dear Maintainer,

It was found that fprintd saves fingerprint template and without any
encryption, to a file with root permission on the host.
This could allow a privileged process to access the stored fingerprint.
In fprintd, MINDTCT feature extractor from the NIST Biometric Image Software
(NBIS) extracts fingerprint minutiae that are compliant to ANSI INCITS
378-2004.
The generated template file can be easily converted to ISO/IEC 19794-2 format
since it is a minor modification of the earlier ANSI-INCITS 378-2004.
Currently, it is well known threat model that the standard fingerprint template
can be reverted to original fingerprint image.
[1-5] are presented to create sophisticated and natural-looking fingerprints
only from the numerical template data format as defined in standard format.
They also successfully evaluated these approaches against a number of
undisclosed state-of-the-art algorithms and the NBIS.

As per upstream, the only way to safeguard the fingerprint data is to run with
SELinux, AppArmor or another LSM enabled one.
(link: https://gitlab.freedesktop.org/libfprint/fprintd/issues/16#note_141207)
Currently, Fedora and Red Hat Enterprise Linux have a safeguard the fingerprint
data since they uses SELinux by default while Ubuntu and Debian did not.

Once fingerprint has been leaked, victims are leaked for the rest of life since
it lasts for a life.
It is necessary to prepare for the problem.


[1] R. Cappelli et al., “Fingerprint Image Reconstruction from Standard
Templates”, IEEE Trans. on Pattern Analysis and Machine Intelligence, vol.29,
no.9, pp.1489-1503, 2007.
[2] A. Ross et al., “From template to image: Reconstructing fingerprints from
minutiae points”, IEEE Trans on Pattern Analysis and Machine Intelligence,
vol.29, no.4, pp.544-560, 2007.
[3] R. Cappelli et al., “Can Fingerprints be reconstructed from ISO
Templates?”, IEEE ICARCV 2006.
[4] J. Feng et al., “Fingerprint Reconstruction: From Minutiae to Phase”, IEEE
Trans on Pattern Analysis and Machine Intelligence, vol.33, no.2, pp.209-223,
2011.
[5] A. Rozsa et al., "Genetic Algorithm Attack on Minutiae-Based Fingerprint
Authentication and Protected Template Fingerprint Systems", CVPR 2015.



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

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

Versions of packages fprintd depends on:
ii  dbus   1.10.26-0+deb9u1
ii  libc6  2.24-11+deb9u4
ii  libdbus-1-31.10.26-0+deb9u1
ii  libdbus-glib-1-2   0.108-2
ii  libfprint0 1:0.6.0-2
ii  libglib2.0-0   2.50.3-2
ii  libpolkit-gobject-1-0  0.105-18+deb9u1
ii  policykit-10.105-18+deb9u1

fprintd recommends no packages.

fprintd suggests no packages.

-- no debconf information

Bug#926694: ibus-skk: When I use nicola layout, I can't input some Japanese Characters.

[YABUKI Yukiharu]

Package: ibus-skk
Version: 1.4.3-1
Severity: normal

Dear Maintainer,

I use skk-nicola when I input Japanese. Well, Today, I checked
ibus-skk with nicola layout again.

I am happy to find fixed bug #825936. But I found another grave bug
for nicola layout user.

I can't input modify some Japanese hirakana. For Example, I typed
s+henkan key. skk-nicola should reply "Ji", but ibus-skk replyed "Si".

It seems for me that henkan key does not work in nicola layout.

It is not only "Ji" chatactor, but others, "De", "Ge", "Ze"...

I could not write down any Japanese text.


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

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

Versions of packages ibus-skk depends on:
ii  ibus   1.5.19-4
ii  libc6  2.28-8
ii  libgee-0.8-2   0.20.1-2
ii  libglib2.0-0   2.58.3-1
ii  libgtk-3-0 3.24.5-1
ii  libibus-1.0-5  1.5.19-4
ii  libskk01.0.5-1
ii  skkdic 20190217-1

ibus-skk recommends no packages.

ibus-skk suggests no packages.

-- no debconf information

Bug#926684: tracker.debian.org: Outdated team information (here debian-tryton)

[Raphael Hertzog]

Hi,

On Tue, 09 Apr 2019, Mathias Behrle wrote:
> > It's in the «Update team» link:
> > https://tracker.debian.org/teams/debian-tryton/+update/
> > 
> > But only the team owner has access to this. Are you the team owner? (the
> > one who created it?)
> 
> No, I am not. It was created automatically (I guess). How can I become the 
> team
> owner?

It was not created automatically, no.

In [2]: t = Team.objects.get(slug='debian-tryton')

In [3]: t.owner
Out[3]: 

So you should consider joining your two accounts together or using your
other account to do this task.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#926693: fai-cd not bootable

[Christian Meyer]

Source: fai
Severity: normal

Dear Maintainer,

fai-cd creates bootable iso-images that don't boot on all (possibly older?)
computers.

The problem is in fai 5.3.6 (stretch) and 5.8.4 (buster).

The solution is already described in fai-cd's man-page, make the pen-drive's
first partition "bootable":
# parted /dev/sdb set 1 boot on

So please include this fix in the code of fai-cd as well and make the iso-image
"bootable" - before writing to a pendrive:
# parted /path/to/fai.iso set 1 boot on

I can confirm the solution works on my Lenovo L530. Without the flag set my
lapton does not boot at all, when I change the same ISO-image before dd-ing it
to a pendrive then the fai-cd starts up as expected.
So I can confirm making the image bootable fixes the issue.

On my (customized) fai-server 'parted' is not installed by default, so you
might want to add a dependency on 'parted' (or modify the image with a
different command).

Christian Meyer



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

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

Bug#926684: tracker.debian.org: Outdated team information (here debian-tryton)

[Raphael Hertzog]

Hi,

On Tue, 09 Apr 2019, Mathias Behrle wrote:
> URL: http://tryton.alioth.debian.org/
> Maintainer email: maintain...@debian.tryton.org
> 
> I couldn't find a way to update that information via 'Manage team'. 
> Could you please fix that or point me to where to fix it to

It's in the «Update team» link:
https://tracker.debian.org/teams/debian-tryton/+update/

But only the team owner has access to this. Are you the team owner? (the
one who created it?)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#147164: ping and new proposal

[Andrei POPESCU]

On Lu, 08 apr 19, 16:06:11, Thomas Lange wrote:
> > On Mon, 8 Apr 2019 16:54:21 +0300, Andrei POPESCU 
> >  said:
> > I would suggest this should read "Every document must have at least one 
> > active maintainer" (regardless of what the Maintainer: field contains).
> So you mean the usual Debian package maintainer? Then we do not need
> to mention this explicitly, but better say that every manual should
> be also a Debian package. Are there manuals which are not in Debian
> package? 

What I meant was that every document should be actively maintained 
(content wise).

Whether it's packaged is an implementation detail (in my opinion not 
even a requirement), so it doesn't really matter what the Maintainer: 
field says.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#926479: [Fwd: [Pkg-swan-devel] Bug#926479: Interesting ..]

[Christian Ehrhardt]

On Mon, Apr 8, 2019 at 8:22 PM Paul Gevers  wrote:
>
> Hi,
>
> On 08-04-2019 12:03, Yves-Alexis Perez wrote:
> > Christian replied to me and the bug but not you so in case you're not 
> > actively
> > monitoring the bug I'm forwarding it as well.
>
> Thanks, I am not watching the bug indeed.
>
> > What is your opinion on the proposal at the end?
>
> Perfect solution if the test indeed needs that. If it does, I don't
> understand why it passes sometimes, as all the workers on ci.d.n should
> be the same. Maybe the lxc leaks a bit?

Odd for sure - at least for my local debian container tests it was a
100% hit rate.
And in VMs it always worked (as does the Ubuntu CI that I linked)

Furthermore there is a reason I never thought I'd need to add
isolation-machine which is that it works well for Ubuntu on armhf which
runs in LXD containers as well.

I was logging in and checking the service status, in the Ubuntu image
it just starts.
But then - even thou Yves and I worked a lot to reduce it - there also
is some Delta left.
For example we have the kernel-libipsec plugin which allows it to run
without modules as well as a fix for [1].
Examples in our CI  - old [3] new [2].

[1]: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1780534
[2]: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/s/strongswan/20190406_005838_2bf72@/log.gz
[3]: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/s/strongswan/20190207_031313_a233f@/log.gz

i was retrying local amd64 execution with a Ubuntu 19.04 container and it
confirms that only Debian is affected by this. While I don't understand
yet why I'm glad that we found it.

Everytime I do a merge of strongswan in Ubuntu Yves and I work
together to reduce the Delta.
But the biggest chunks we postponed for after buster. Seeing the
results above I'm rather sure that would resolve the issues as well.
I was looking forward to that anyway ...

/me feels better now understanding why it fails for you, but not for
us - In hindsight, sorry Yves to pass you a test not being 100% valid
for you.

> But this change would be even acceptable for an unblock if it can happen
> soon (without any other changes).

I wondered about that, but I see that it will make CI on the package
for the lifetime of buster more helpful.

> I am seriously wondering if the last test doesn't *also* need a
> isolation-machine restriction. It seems to me that modprobe isn't
> available in a linux container.

I yesterday only looked at the one test that was reported failing.
I tested it again and the plugins test works in a container, maybe it
just doesn't need the service up.
You are still right, while it seems to work atm it might as well turn
out to be unreliable.

If we change it anyway, then I agree that it seems wise to move
"plugins" down as well to be on the safe side.

Overall that would then look like this:
diff --git a/debian/tests/control b/debian/tests/control
index eb9e20463c..5b1ebf32c8 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,7 @@
-Tests: daemon admin-strongswan-charon admin-strongswan-starter plugins
-Depends: strongswan, libstrongswan-standard-plugins,
libstrongswan-extra-plugins, libcharon-extra-plugins, strongswan-pki,
strongswan-scepclient
+Tests: admin-strongswan-charon admin-strongswan-starter
+Depends: strongswan, strongswan-pki, strongswan-scepclient
Restrictions: needs-root isolation-container allow-stderr
+
+Tests: daemon plugins
+Depends: strongswan-starter, libstrongswan-standard-plugins,
libstrongswan-extra-plugins, libcharon-extra-plugins
+Restrictions: needs-root isolation-machine allow-stderr

> Paul
>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#926452: gnome-shell: On-screen keyboard lacks several French layouts

[intrigeri]

Control: severity -1 important
Control: retitle -1 gnome-shell: On-screen keyboard lacks several French layouts

I've verified that this is a regression compared to Stretch,
where the visual keyboard supports fr_FR.UTF-8 just fine:
the displayed layout matches a fr_FR physical keyboard's
and one can input accentuated chars that are part of this layout,
such as "à" or "é" ⇒ bumping severity.

Bug#926103: Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

[Erik Brangs]

Hi,

On 09.04.19 00:14, Reinhard Tartler wrote:

Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve 
the attached debdiff, so that I can upload the fixed package to unstable.


I'm a user of the package and would like to see the fixed version in buster. I think 
you're supposed to file an unblock request (Section "Applying for an unblock" 
in the freeze policy at https://release.debian.org/buster/freeze_policy.html ).


Kind regards,

Erik Brangs

Bug#926684: tracker.debian.org: Outdated team information (here debian-tryton)

[Mathias Behrle]

* Raphael Hertzog: " Re: Bug#926684: tracker.debian.org: Outdated team
  information (here debian-tryton)" (Tue, 9 Apr 2019 08:10:32 +0200):

Hi Raphael,

thanks for the quick reaction.

> On Tue, 09 Apr 2019, Mathias Behrle wrote:
> > URL: http://tryton.alioth.debian.org/
> > Maintainer email: maintain...@debian.tryton.org
> > 
> > I couldn't find a way to update that information via 'Manage team'. 
> > Could you please fix that or point me to where to fix it to  
> 
> It's in the «Update team» link:
> https://tracker.debian.org/teams/debian-tryton/+update/
> 
> But only the team owner has access to this. Are you the team owner? (the
> one who created it?)

No, I am not. It was created automatically (I guess). How can I become the team
owner?

Cheers


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#926387: oxygen-icons5: FTBFS randomly (Directory renamed before its status could be extracted)

[Santiago Vila]

On Tue, Apr 09, 2019 at 12:29:03AM +0200, Guillem Jover wrote:
> Control: tag -1 moreinfo
> 
> Hi!
> 
> On Thu, 2019-04-04 at 10:27:29 +, Santiago Vila wrote:
> > Package: src:oxygen-icons5,dpkg-dev,tar
> > Tags: ftbfs
> 
> > I tried to build "oxygen-icons5" in buster but it failed:
> 
> > This happens randomly. Sometimes it fails, sometimes it does not. It
> > happens in other packages as well, but it happens particularly often
> > with oxygen-icons5, as shown in my build history:
> 
> > I'm using sbuild + schroot + eatmydata + overlayfs on 1-XS instances
> > from Scaleway.
> 
> Hmm, can you reproduce those results on a system not using overlayfs?

No, I confirm that the error is related to using sbuild + overlayfs.

My annoyance, however, comes from the fact that every time something
like this happened in the past it was because the tarball was
generated using "find * -type f | tar blah" (i.e. excluding directory entries).

The workaround was to include directory entries as well, making it an
"orthodox" tarball.

In this case the tarball seems to be sane, and there is no workaround other
than adding oxygen-icons5 to my "do-not-use-overlay-for-this-package" list.

Is dpkg in buster calling tar with any options that makes this
behaviour to happen more easily? Is tar in buster more prone to this
failure when using overlayfs?

Thanks.

Bug#926697: Please package version >=6.0.0 <9.0.0

[Thomas Goirand]

Package: puppet-module-puppetlabs-mysql
Version: 5.3.0-1
Severity: wishlist

Hi,

I'm currently packaging the Puppet modules for OpenStack Stein, and they all
require version >=6.0.0 <9.0.0. It'd be nice if this could be uploaded to
Experimental (during the Buster freeze). Alternatively, would you allow me
to NMU such an update?

Cheers,

Thomas Goirand (zigo)

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

[Jonas Smedegaard]

Quoting Vagrant Cascadian (2019-04-09 10:13:32)
> On 2019-04-01, Jonas Smedegaard wrote:
> > Quoting Vagrant Cascadian (2019-03-30 21:43:40)
> >> Maybe nudging some people to get the patches upstream would be 
> >> feasible; a u-boot merge window opens in a couple weeks.
> >
> > Thanks for the suggestion.  I will try get in touch with the people 
> > involved and encourage them to push (harder than they do already).
> 
> And the merge window is now open!
> 
> 
> > Feel free to ping me as soon as 2019.04 is in somewhat usable state: 
> > I'll then try rebase the teres-i patches and if succesful then it 
> > would be awesome to have it included in an experimental release.
> 
> Ok, I've just uploaded 2019.04+dfsg-1 to experimental, and updated the 
> git master branch to that.
> 
> 
> > Would it be interesting that I add wip/* branches for other 
> > potential packaging improvements I come up with, or would you prefer 
> > that I work on a separate git and only push to "your" git for after 
> > formally filing a bugreport and getting your approval for pushing 
> > it?
> 
> Feel free to add some more "wip" branches for significant changes, and 
> push trivial changes to master.
> 
> Just uploaded to unstable and experimental, so was a little hesitant 
> to respond until sorting those out, and will be working on merging in 
> the qemu branch(es) soon. But it should be settled enough for to at 
> least test your changes with 2019.04.

Great!

I will try do some good there...!


 - Jonas

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

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


signature.asc
Description: signature

Bug#926103: Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

[Ivo De Decker]

Hi,

On 4/9/19 12:14 AM, Reinhard Tartler wrote:

Hi Release Team,

Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve 
the attached debdiff, so that I can upload the fixed package to unstable.


We really prefer unblock request bugs instead of mails to the list, to 
make sure the request is tracked and doesn't get lost.


That said, please go ahead and do the upload of 3.99.5final.sp09-2 to 
unstable based on the diff you sent.



Thank you for your consideration.


Thanks,

Ivo

Bug#923606: beancount: FTBFS randomly (gpg-related race condition)

[Stefano Zacchiroli]

Hi Santiago,

On Tue, Apr 09, 2019 at 10:38:10AM +0200, Santiago Vila wrote:
> I obviously have interest to fix this before the release, because I
> can build 99.99% of packages in my setup and this is an inconvenient
> exception for me. I don't like NMUs. Should I join the Python
> Applications Packaging Team? Please tell me how I would proceed.

either way is fine, and also just submitting a merge request would do
(although please let this bug log know if you do so, to make sure it
doesn't get overlooked).

Thanks!
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#913760: python3-electrum: Add Depends on libsecp256k1-0 for faster signing and verification

[Antoine Amarilli]

Shouldn't this be a Recommends rather than a Depends, as the package is
supposed to work without it?

-- 
Antoine Amarilli

Bug#775650: gnome-shell: Brightness slider moves uncontrollably.

[intrigeri]

Control: tag -1 + upstream
Control: tag -1 + moreinfo

Hi Jonathan,

Jonathan Moreno:
> The brightness slider on the shell's top panel moves uncontrollably when 
> trying
> to adjust screen brightness.

Thanks for your patience. As you can see, the Debian GNOME team is
kind of swamped with bug reports and has a hard time processing them
all in a timely manner.

I notice that you've seen this bug while running 3.14.2-3+b1, which is
older than what we shipped in Jessie. Can still reproduce this bug
on current Debian Buster? You could try with a Live CD:

  
https://get.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-gnome+nonfree.iso

If you can still reproduce this bug, I would recommend submitting
a merge request upstream:

  https://gitlab.gnome.org/GNOME/gnome-shell/

Thanks in advance!

Cheers,
-- 
intrigeri

Bug#926695: ezquake: Configuration not stored

[Nicolas Patrois]

Package: ezquake
Version: 2.2+git20150324-1
Severity: important

Dear Maintainer,

The configuration I choose in the menus are not stored. When I run back
ezquake, the configuration is the vanilla one.
In fact, ezquake creates a symlink to /usr/share/games/quake/* and these files
and directories are not my property.
ezquake should instead create, for example, the ~/.config/ezquake/id1/
directory then symlink every file from /usr/share/games/quake/id1 except the
configuration file that should be copied too.



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

Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ezquake depends on:
ii  libc62.28-8
ii  libcurl3-gnutls  7.64.0-2
ii  libexpat12.2.6-1
ii  libgl1   1.1.0-1
ii  libgl1-mesa-glx  18.3.6-1
ii  libjansson4  2.12-1
ii  libpcre3 2:8.39-12
ii  libpng16-16  1.6.36-6
ii  libsdl2-2.0-02.0.9+dfsg1-1
ii  zlib1g   1:1.2.11.dfsg-1

ezquake recommends no packages.

Versions of packages ezquake suggests:
ii  game-data-packager  63

-- no debconf information

Bug#926387: oxygen-icons5: FTBFS randomly (Directory renamed before its status could be extracted)

[Santiago Vila]

Hmm, I said:

> Is dpkg in buster calling tar with any options that makes this
> behaviour to happen more easily? Is tar in buster more prone to this
> failure when using overlayfs?

By looking at my build logs I see that this is not really related to
buster, but related to the fact that I started to use virtual machines
from Scaleway. Apparently this is really easy to happen there.

Still, I would like to know if there is some kind of workaround other
than stopping using overlayfs.

Thanks.

Bug#926694: Not only muhenkan but also henkan key does not work in nicola layout

[Yukiharu YABUKI]

Additional information.

I tried to input Japanese text in nicola layout.

It does not work to modify muhankan key. And Henkan key does not
work to modify input characters.

--
Yukiharu YABUKI 

Bug#926696: xkcdpass: Option --wordfile ita-wiki gives English output

[Lanquil]

Package: xkcdpass
Version: 1.16.5+dfsg.1-1
Severity: important

Dear Maintainer,

Using xkcdpass with:
xckdpass -w ita-wiki
gives English output instead of Italian

-w fin-kotus
-w spa-mich
-w ger-anlx
Are instead working as expected.


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

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

Versions of packages xkcdpass depends on:
ii  python33.7.2-1
ii  python3-pkg-resources  40.8.0-1

xkcdpass recommends no packages.

xkcdpass suggests no packages.

-- debconf-show failed

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

[Vagrant Cascadian]

On 2019-04-01, Jonas Smedegaard wrote:
> Quoting Vagrant Cascadian (2019-03-30 21:43:40)
>> Maybe nudging some people to get the patches upstream would be 
>> feasible; a u-boot merge window opens in a couple weeks.
>
> Thanks for the suggestion.  I will try get in touch with the people 
> involved and encourage them to push (harder than they do already).

And the merge window is now open!


> Feel free to ping me as soon as 2019.04 is in somewhat usable state: 
> I'll then try rebase the teres-i patches and if succesful then it would 
> be awesome to have it included in an experimental release.

Ok, I've just uploaded 2019.04+dfsg-1 to experimental, and updated the
git master branch to that.


> Would it be interesting that I add wip/* branches for other potential 
> packaging improvements I come up with, or would you prefer that I work 
> on a separate git and only push to "your" git for after formally filing 
> a bugreport and getting your approval for pushing it?

Feel free to add some more "wip" branches for significant changes, and
push trivial changes to master.

Just uploaded to unstable and experimental, so was a little hesitant to
respond until sorting those out, and will be working on merging in the
qemu branch(es) soon. But it should be settled enough for to at least
test your changes with 2019.04.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#923606: beancount: FTBFS randomly (gpg-related race condition)

[Santiago Vila]

On Tue, Mar 05, 2019 at 11:10:10AM +0100, Stefano Zacchiroli wrote:

> Thanks a lot for this. I don't think it's needed to determine the actual
> fix, which is fairly obvious.  My main issue is that I also want to
> update to latest upstream release for the next package upload, which is
> a minor version update, but in which the code layout changed a bit,
> requiring other changes in the packaging. I will not have time to do so
> in time for the freeze, so I'm just trying to postpone this work
> post-freeze, and I'll address this then.
> 
> If you, or others, have time and interest to fix this before, by all
> means go ahead. The package is team-maintained, and I'm very happy to
> receive useful NMUs to "my" packages anyway.

I obviously have interest to fix this before the release, because I
can build 99.99% of packages in my setup and this is an inconvenient
exception for me. I don't like NMUs. Should I join the Python
Applications Packaging Team? Please tell me how I would proceed.

Thanks.

Bug#921266: The segfault Is defintely not caused by t-online, but linpone

[W. Martin Borgert]

Quoting Alf :

This definitely confirms that it is not related to t-online, nor to some
missconfiguration of my system.


Still, it would be interesting what leads to that behaviour.
I use Linphone as my one and only telephone and it works fine
for me on both a stretch and a buster system, both amd64. No
crashes at all. I use different providers, however.

Bug#926605: webissues FTCBFS: uses the build architecture qmake

[Patrick Matthäi]

tag #926605 + pending
thanks

Am 07.04.2019 um 20:47 schrieb Helmut Grohne:
> Source: webissues
> Version: 1.1.5-3
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> webissues fails to cross build from source, because it uses the build
> architecture qmake. The attached patch passes a suitable qmake via
> -qmake to ./configure and makes webissues cross buildable. Plase
> consider applying it.
>
> Helmut
thanks for your patch!

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#923423: dpkg: Hangs for 19 mins installing texlive-fonts-extra

[Vincent Lefevre]

Control: retitle -1 dpkg: package install can be very slow with some disks due 
to too frequent fsync

Hi,

On 2019-04-09 00:33:27 +0200, Guillem Jover wrote:
> On Tue, 2019-03-05 at 15:43:05 +0100, Vincent Lefevre wrote:
> > zira:~> iozone -a -e
> > [...]
> >   random
> > random bkwdrecordstride
> >   kB  reclenwrite  rewritereadrereadread 
> > write read   rewrite  read   fwrite frewritefread  freread
> >   64   4 1821 1987 1922 3703 3657 
> > 1770 1621  1628  1697 1707 1773  1879725  2892445
> >   64   8 1606 1684 1713 3493 3476 
> > 1700 1765  1730  1812 2135 1852  2278628  3406295
> >   64  16 1807 1823 1986 3898 3798 
> > 1977 1813  1988  1871 2049 3320  2561267  4018152
> >   64  32 1702 1714 1755 3494 3683 
> > 1741 1841  1796  1737 1633 1674  1879725  4018152
> >   64  64 1808 1790 1632 3314 3387 
> > 2254 1995  1843  1984 1789 1820  2801873  3203069
> > [...]
> 
> Ok, can we conclude this is not a problem in dpkg then? :)

I'm not sure. This may just be a slow disk after all, and in practice
(I mean except benchmarking), the problem seems specific to dpkg.
I assume that programs normally don't do a fsync at every fraction
of microsecond! I don't know what dpkg is trying to achieve with such
a frequency of fsync, but this doesn't seem to make sense to me. You
had said "which has been the solution to earlier problems with ext4",
but the real solution would be to fix ext4 (does "earlier" mean this
has eventually been fixed?).

> It seems to me either hardware, filesystem or kernel related as
> mentioned before.

I've seen https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1785020
"fsync is slow on later kernels with ext4 filesystms" but the comments
in this bug page and 4.19.28-1 kernel logs show that this has been
fixed.

FYI, I get very similar timings on the same machine, but on /boot,
which is:

/dev/sda1 on /boot type ext2 
(rw,relatime,block_validity,barrier,user_xattr,acl,stripe=4)

The fact that the main, ext4 partition is encrypted but not this
one makes another difference, but the timings are similar, so that
this doesn't seem to be related to the FS system itself and appears
to be at a lower level.

Note also that my machine is a laptop, and I couldn't do a comparison
with other laptops, just in case.

> Could you reassign where you think it would be more appropriate?

I think that this should still be regarded as a dpkg bug, based on
my first paragraph above (the fsync's occur much too often in dpkg
compared to other programs, and this doesn't seem to be useful).

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

Bug#843778: needrestart: restart systemd user daemons and user services

[Marco Steinacher]

On Debian 9.8 restarting the systemd user services as root with
"systemctl restart user@.service" works for me:

# needrestart
[...]
User sessions running outdated binaries:
 root @ user manager service: systemd[6372]
 admin @ user manager service: systemd[2398]

# systemctl | grep user@
user@0.serviceloaded active running   User Manager for UID 0

user@1000.service loaded active running   User Manager for UID 1000

# systemctl restart user@0.service
# systemctl restart user@1000.service

# needrestart
[...]
No user sessions are running outdated binaries.


I hope this helps,
Marco

-- 
OpenPGP Key ID: 0x62937F7F

Bug#926707: cups: please do not generate files under /etc but use /var/lib for that (etckeeper woes)

[Thorsten Glaser]

Package: cups-browsed
Version: 1.21.6-4
Severity: normal

With etckeeper on a laptop that often is taken around to different networks,
I see lines like these on apt-get --purge dist-upgrade all the time:

[master 48dee15] saving uncommitted changes in /etc prior to apt run
[…]
 create mode 100644 
cups/ppd/pr_bn_1og_Brother_HL_L8250CDN_Laser_Colour_Duplex_172_2.ppd
[…]

So, these files are autogenerated and not created then changed by the
local admin. (They are also automatically deleted). There’s a place for
such files in the filesystem standard, and it’s /var/lib not /etc.

Please move this stuff out of /etc, TYVM.

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

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

Versions of packages cups-browsed depends on:
ii  cups-daemon   2.2.10-5
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavahi-glib10.7-4+b1
ii  libc6 2.28-8
ii  libcups2  2.2.10-5
ii  libcupsfilters1   1.21.6-4
ii  libglib2.0-0  2.58.3-1
ii  libldap-2.4-2 2.4.47+dfsg-3
ii  lsb-base  10.2019031300

Versions of packages cups-browsed recommends:
ii  avahi-daemon  0.7-4+b1

cups-browsed suggests no packages.

-- no debconf information

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

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-04-09 10:40:31)
> Quoting Vagrant Cascadian (2019-04-09 10:13:32)
> > On 2019-04-01, Jonas Smedegaard wrote:
> > > Quoting Vagrant Cascadian (2019-03-30 21:43:40)
> > >> Maybe nudging some people to get the patches upstream would be 
> > >> feasible; a u-boot merge window opens in a couple weeks.
> > >
> > > Thanks for the suggestion.  I will try get in touch with the people 
> > > involved and encourage them to push (harder than they do already).
> > 
> > And the merge window is now open!
> > 
> > 
> > > Feel free to ping me as soon as 2019.04 is in somewhat usable state: 
> > > I'll then try rebase the teres-i patches and if succesful then it 
> > > would be awesome to have it included in an experimental release.
> > 
> > Ok, I've just uploaded 2019.04+dfsg-1 to experimental, and updated the 
> > git master branch to that.
> > 
> > 
> > > Would it be interesting that I add wip/* branches for other 
> > > potential packaging improvements I come up with, or would you prefer 
> > > that I work on a separate git and only push to "your" git for after 
> > > formally filing a bugreport and getting your approval for pushing 
> > > it?
> > 
> > Feel free to add some more "wip" branches for significant changes, and 
> > push trivial changes to master.
> > 
> > Just uploaded to unstable and experimental, so was a little hesitant 
> > to respond until sorting those out, and will be working on merging in 
> > the qemu branch(es) soon. But it should be settled enough for to at 
> > least test your changes with 2019.04.
> 
> Great!
> 
> I will try do some good there...!

The wip/teres-i branch is now rebased against master, and I can confirm 
that it works on TERES-I hardware.

I also pushed a small policy-fixing commit to master branch.


 - Jonas

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

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


signature.asc
Description: signature

Bug#926711: gnome-shell-pomodoro: pomodoro break changes system sound volume

[Keyikedalube Ndang]

Package: gnome-shell-pomodoro
Version: 0.14.0-1
Severity: normal

Dear Maintainer,

During pomodoro break, the volume of my system is changed too by the program.

For instance if I have set my system volume to 50%, gnome-pomodoro changes it
back to 100% during take-a-break notification.

Don't you think it'd be better if the program synchronizes with the system
volume?
100% volume is too loud.



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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
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 gnome-shell-pomodoro depends on:
ii  gnome-shell 3.30.2-3
ii  gnome-shell-pomodoro-data   0.14.0-1
ii  libatk1.0-0 2.30.0-2
ii  libayatana-appindicator3-1  0.5.3-4
ii  libc6   2.28-8
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libcanberra00.30-7
ii  libdbusmenu-glib4   18.10.20180917~bzr490+repack1-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgirepository-1.0-1   1.58.3-2
ii  libglib2.0-02.58.3-1
ii  libgom-1.0-00.3.3-5
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libpango-1.0-0  1.42.4-6
ii  libpangocairo-1.0-0 1.42.4-6
ii  libpeas-1.0-0   1.22.0-4

gnome-shell-pomodoro recommends no packages.

gnome-shell-pomodoro suggests no packages.

-- no debconf information

Bug#926708: unblock: otrs2/6.0.17-1

[Patrick Matthäi]

Am 09.04.2019 um 14:46 schrieb Ivo De Decker:
> Hi,
>
> On Tue, Apr 09, 2019 at 01:41:44PM +0200, Patrick Matthäi wrote:
>> Please unblock package otrs2
>>
>> It fixes a security bug along with other upstream fixes:
>> https://community.otrs.com/security-advisory-2019-02-security-update-for-otrs-framework/
>>
>> This shouldn't be a problem, since it is non-free?
> No. And you know this. You tried the exact same thing for stretch:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858891
>
> Being in non-free doesn't give you an exception to the freeze.
Sorry you are right, I totaly forget it..
It was an exception for fglrx in the past-past, but because it was also
closed source, so no fixes could be adapted.

I will prepare a diff along with other security fixes (I think there
will be one in the next time) if they are out

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/